OSC
Automate localizations
1.8+ has a Chinese localization. We may have others contributed in the future. It would be useful to provide some type of automation around identifying:
- what en.yml strings do not have a corresponding localization for zh-CN.yml (what keys in en.yml do not exist in zh-CN.yml)
- what keys in zh-CN.yml do not exist in en.yml - these would be old keys in zh-CN.yml that may need removed, or they are misspelled keys
- if an en.yml string gets updated/modified, to flag which strings in zh-CN.yml need updated (this requires a clever git blame to determine the line number in the YAML file where a key starts and ensure the commit date of zh-CN.yml for a given key is greater than the commit date for the same key in en.yml. if en.yml is later that indicates that for this key the translation has been updated or modified and may need to be updated or modified for zh-CN. NOTE: a problem with this is if there is a false positive... like we fix a typo in the English or word it better but the Chinese is good and needs no update.. we could figure that out later). Could use https://www.rubydoc.info/github/libgit2/rugged/Rugged/Blame for this
- what strings in the application have not be internationalized (these strings are hardcoded)
There are many tools and approaches for this, but we want to keep deployment simple. The yaml files mean the translations stay with the code which is nice. Could probably use for_line. This also might encourage us to avoid multi-line strings in the locale files.
Maybe a rake task is sufficient to start.
Also worth searching for existing tools that might assist with this as an alternative to writing our own.
┆Issue is synchronized with this Asana task by Unito
Take a look at "Translation management systems" (TMS). There are also tools like https://github.com/pejuko/i18n-translators-tools to convert the default Rails yaml into other formats for easier translation. We could also consider future versions of OnDemand using gettext. gettext doesn't use keys like the Rails yaml does, and just takes the full sentence and provides a translation for it. Most TMS support this out of the box, though there may also be examples of TMS projects that work with the Rails yaml formats. Another benefit of the gettext PO format is that its language/framework independent so if at some point we drop Rails or still have a mixture of Rails and other language/framework for apps in OnDemand, or want to translate error strings in Apache and/or NGINX as well, we can handle all of that in an language independent way.
Examples: http://pootle.translatehouse.org/, http://zanata.org/ (RedHat product with free open source project support)
Search for "open source translation management systems" to see many options.
Still thinking about this. Seems we can use https://github.com/glebm/i18n-tasks and some translation service like openapi or google to generate files. Then it's just a matter of making the pull request like we do for the chagnelog or dependencies.
