New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Localization for Survey #844

Closed
brew opened this Issue Nov 28, 2016 · 0 comments

Comments

Projects
None yet
1 participant
@brew
Member

brew commented Nov 28, 2016

During implementation of the new template design and survey strategy for the 2016 survey, localization wasn't explicitly supported. Much of the supporting code is in place, but new strings need to be marked for translation, and Transifex updated.

The strategy for localizing loaded content (Questions, Datasets, etc) has changed. Site admins are encouraged to manage Questions and Datasets within tabs within a single Google Spreadsheet doc (rather than extending a global Questions doc with translated columns).

For local sites where more than one language is supported, the multi-column translation strategy can still be used.

  • Prepare strings for general site-wide translations (#858)
    • Mark all template strings for translation
    • Mark all strings in code for translation
  • Strings in jsx files (see #864)
  • Ensure loaded content can be localized, loaded, and used in browser
    • Questions (see #788)
    • Datasets (#860)
      • Dataset characteristics (see #859)
    • Multi-language switcher is available where appropriate
  • Update localization instructions in documentation (http://census.okfn.org/en/latest/site-admins/#localization) (#863)
  • Update README instructions for compiling translations (#863)
  • Upload new pot file to Transifex

@brew brew added this to the Survey Post-Launch milestone Nov 28, 2016

@brew brew referenced this issue Nov 29, 2016

Closed

Question Translations #788

3 of 3 tasks complete

brew added a commit that referenced this issue Dec 7, 2016

[#844] Fix gulp script to extract i18n strings
Was pointing to old template directory and needed to include more
special handling of 'or' use in nunjucks templates.

Also, don't extract from `format` keyword. Instead use `gettext` within
format function where approparite. Otherwise, some unnecessary strings
are extracted, like url concatenation.

brew added a commit that referenced this issue Dec 7, 2016

[#844] Mark strings for translation within templates
And extract strings to messages.pot template.

brew added a commit that referenced this issue Dec 7, 2016

brew added a commit that referenced this issue Dec 8, 2016

brew added a commit that referenced this issue Dec 8, 2016

[#844] Extract i18n strings from js files
Use gulp-filter to treat html and js files separately. Exclude some
directories as sources for the pipeline to speed things up a little.

brew added a commit that referenced this issue Dec 8, 2016

brew added a commit that referenced this issue Dec 8, 2016

[#844] Manually add pot headers
These get lost when concatenating the pot files together, so manually
add the defaults.

brew added a commit that referenced this issue Dec 8, 2016

brew added a commit that referenced this issue Dec 8, 2016

[#844] Fix gettext in create template.
Execution order means I can't include nunjucks markup in gettext calls.

brew added a commit that referenced this issue Dec 8, 2016

[#844] Don't call gettext from 500 controller
Keeping the 500 controller action simple.

brew added a commit that referenced this issue Dec 9, 2016

[#844] Add locale to req.params.
This is used when retrieving data to determine whether and which
translations to use.

brew added a commit that referenced this issue Dec 9, 2016

[#844] Fix `translated` method
- use arrow function to `this` is scoped correctly
- use `get` for the sequelized object, which doesn't support
  `hasOwnProperty`.

brew added a commit that referenced this issue Dec 9, 2016

[#844] Use `req.locale` to set locale in data options
`req.params.locale` doesn't get changed by the language switcher.

brew added a commit that referenced this issue Dec 9, 2016

[#844] Load dataset.name in preference to .title
The database uses `name` as the field to hold the title value. So the
`title` column in the CMS was mapped to the db `name` field. This meant
`Title@LC` translation columns in the CMS didn't work as expected. This
commit updates the MigrationNotes doc to warn that `Name` should be used
in the CMS instead of `Title`. Title is still loadable, but won't be
translatable.

brew added a commit that referenced this issue Dec 9, 2016

[#844] Ensure there's a translated value
If the translated entry is empty, don't use the translation, falling
back to the default value.

brew added a commit that referenced this issue Dec 9, 2016

brew added a commit that referenced this issue Dec 9, 2016

[#844] Add test asserts for translated content
Content loaded from the CMS is translated correctly.

brew added a commit that referenced this issue Dec 13, 2016

[#844] Update site-admin docs
- localization
- new site config setttings
- typos and sentence fixes
- location of new template spreadsheet

brew added a commit that referenced this issue Dec 13, 2016

[#844] Update README and settings template
- update Registry spreadsheet url
- various typos and sentence fixes

@brew brew self-assigned this Dec 13, 2016

@brew brew closed this Dec 15, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment