CLI utility to check coverage of a locale

[yookoala]

It is currently quite hard to keep track on the translations. Strings spread across source code of Ruby and Javascript. It is hard for a translator to tell if a language translation is completed.

I propose we can add some CLI utility that will compare a given locale with the English (presume the English translation file is complete coverage). Then translator can have a reference how complete their work is.

I am willing to write such tool. But what language should I use? Ruby or Nodejs?

Also, where should I put such script?

---

• I searched or browsed the repo’s other issues to ensure this is not a duplicate.

[mjankowski]

Running i18n-tasks health gets some of this.

[Gargron]

i18n-tasks health is for this, although it only deals with Ruby localizations. The react-intl story is more complex. There are packages that are supposed to make managing translations easier, but they do not work with Browserify, or at least I could not get them to work. So it's connected to #1712

[ghost]

The guides should mention the tools that are available for this. I'm having a hell of a time keeping the translation up to date. Things are not only being added, but they are also being changed. I'm able to catch all the additions so far by using a YAML merge tool I found, but I'm missing out on any changes to existing strings, which can be a huge problem. Does the Ruby tool you mention deal with changes? I'm thinking it can't really be solved unless a diff can be performed against different commits of the *en.yml files to check for that.

[ghost]

As for JSX I'm temporarily converting the files to JSON and using a JSON merge tool on them to catch new strings from the English version. However, this will, as with the YAML merge, overwrite changes to existing strings with old localized strings.

Some kind of 3-way merge with Git commit IDs is needed.

Proposed algorithm:

1. Compare old and new versions of the English locale files.
2. Produce new localized files that include new strings from the English files, but not any strings now missing from the English files. (Takes care of simple additions and removals.)
3. Find any changed strings in the English files and overwrite those to the localized files. (Takes care of updated strings.)
4. Produce a report of these changes.
5. Translator can now review and edit the localized files in a text editor.

[ghost]

The YAML is probably easy to parse. The JSX files are a problem. Why not use YAML? I mean, I'm sure there are 934895834 YAML parsers that could run in a browser at this point.

[ghost]

(JSON is another possibility, but the syntax is strict, and no comments are allowed.)

[yookoala]

browserify, and hence browserify_rails does not have ability to support bundling files other than js.

If we were to use YAML in javascript translations, I think we need to use rollup.js or webpack. They both have plugins to extend functionality beyond JS bundling. And I found YAML support in both cases. If things goes well, we may simply import those YAML files and have the bundler do the translations.

Rollup.js is a new bundler and has a much easy config to work with. Webpack is much older and hence more available plugins for other future development.

YAML support for rollup.js

• https://www.npmjs.com/package/rollup-plugin-yaml

YAML support for webpack

• https://www.npmjs.com/package/yml-loader
• https://www.npmjs.com/package/yaml-loader

[ghost]

Working on something here: https://github.com/thor-the-norseman/mastotran

[mjankowski]

FYI, there is a WIP branch here which is moving to webpack, which will impact how i18n works.

[Gargron]

1. i18n-tasks health for YAML
2. yarn run manage:translations for JS