Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Automate localizations #657

Open
ericfranz opened this issue Aug 27, 2020 · 2 comments · May be fixed by #4003
Open

Automate localizations #657

ericfranz opened this issue Aug 27, 2020 · 2 comments · May be fixed by #4003
Assignees
@HazelGrant
Labels
area/tech debt enhancement This is functionality that builds upon existing functionality. good first issue
Milestone
4.1

Comments

@ericfranz
Copy link
Contributor

ericfranz commented Aug 27, 2020 •
edited by sync-by-unito bot
Loading

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:

  1. 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)
  2. 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
  3. 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
  4. 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
@oscwiag oscwiag added this to the Needs Triaged milestone Aug 27, 2020
@johrstrom johrstrom modified the milestones: Needs Triaged, Backlog Sep 29, 2020
@ericfranz
Copy link
Contributor Author

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.

@ericfranz ericfranz modified the milestones: Backlog, OOD2.1 Mar 15, 2021
@johrstrom johrstrom modified the milestones: 2.1, Backlog Feb 14, 2022
@lukew3 lukew3 added the enhancement This is functionality that builds upon existing functionality. label Jun 29, 2022
@johrstrom
Copy link
Contributor

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.

@johrstrom johrstrom changed the title Automate a way to assist in maintaining Chinese localization Automate localizations Mar 12, 2024
@johrstrom johrstrom modified the milestones: Backlog, 4.0 Mar 12, 2024
@matt257 matt257 moved this from Waiting to Reviewed, Scheduled in GitHub Issue Review Project Sep 5, 2024
@johrstrom johrstrom modified the milestones: 4.0, 4.1 Oct 10, 2024
@HazelGrant HazelGrant self-assigned this Dec 6, 2024
@HazelGrant HazelGrant linked a pull request Dec 10, 2024 that will close this issue
Draft
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@HazelGrant HazelGrant

Labels
area/tech debt enhancement This is functionality that builds upon existing functionality. good first issue
Projects
GitHub Issue Review Project
Status: Reviewed, Scheduled
Milestone
4.1
Development

Successfully merging a pull request may close this issue.

657 automate localizations OSC/ondemand
6 participants
@ericfranz @johrstrom @HazelGrant @oscwiag @lukew3 @KinanAlAttar