1037052 - Create a new compare-locales for gaia l20n format

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::L10n, defect, P2)

Description

[Zibi Braniecki [:zbraniecki][:gandalf]]

We need a new compare-locales that will work with the l20n format that we want to introduce for Gaia.

Comment 1

[Zibi Braniecki [:zbraniecki][:gandalf]]

I got a POC of the new compare-locales.

Summary of what's there:
 * written in JS
 * reuses as much of gaia build/utils and l20n's parser as possible
 * works with locales inside app directory
 * works with locales in separate directory
 * supports .properties and .l20n
 * uses HTML linked resources to build langpack's resource list
 * recognizes multi-value entities

Usage:

./bin/compare-locales.js ../gaia/apps/clock fr

This will compare default locale (en-US) against fr stored in ../gaia/apps/clock/locales/fr

================

./bin/compare-locales.js ../gaia/apps/settings/index.html fr

This will compare only index.html's langpack en-US vs. fr

================

./bin/compare-locales.js ../gaia/apps/settings ../gaia-l10n/master/fr fr

This will compare whole settings app against fr stored in ../gaia-l10n/master/fr

====================================================================================

This is a very POC approach. I experimented with using the notion of Langpacks, building them out of HTML resources and keeping GaiaApp as a new type of app (Gecko app would be another).

One major missing area is that because I build Langpack's resources by scanning HTML files, I do not report obsolete files in localizations.
One way to support that in the future would be to build all resources for app's directory and report resource files not used in any HTML file (or not present in en-US Langpack) - this would still need a separate "app" for shared directory. Didn't dwell deep enough into this.

Pike, stas, I think that the next step is for you guys to take a look at this. The code is not documented but small enough that you should be able to get an idea of how it is supposed to work just by skimming over files and function names (usually 3-4 functions per file in 7 files total).

I'd love to start working on refactoring it into more production ready code, and document it on the way, but would prefer to first get a consensus on the general approach.

Comment 2

[Axel Hecht [:Pike]]

That's a lot of code to reverse engineer.

For the elmo part, the approach is not directly working. I don't have html files in any of my automation repos, for starters.

I still want to see a design spec, and a description of how that'd be used, and where.

Comment 3

[Staś Małolepszy :stas]

I gave most of my feedback last week when Gandalf was in Warsaw.  To repeat it here:  I like that the code is small and already quite modular, although I'd like for it to be even more modular, with pluggable modules for running health checks for instance.

The parsing of the HTML files is a nice innovation, but I think it'll need some work to get all the paths right, especially in shared/ and apps/communications.  Maybe we could get the list of relevant HTML files from the manifest's entry points and activities fields.  However, it looks like for integrating it with Elmo right now, we'll mostly need an equivalent of compare-dirs.

In the future, we might want to move away from keeping an up-to-date gaia-l10n/en-US repo in favor of running compare-locales against the real Gaia repo and converting paths on the fly.  That is to say, a new string in apps/system/locales/system.en-US.properties could be reported as missing from apps/system/system.properties in the localizer's locale.

As far as code review goes, I committed most of my comments to the repo :)  I'll keep working on rewriting the util functions to their async counterparts.

Great job, G.!

Comment 4

[Zibi Braniecki [:zbraniecki][:gandalf]]

Ok,

I believe that compare-locales.js is ready.

The master branch at https://github.com/l20n/compare-locales.js is currently fully operational and compatible with the old compare-locales

Marking this one as fixed and opening new bug for landing the new c-l.js in Elmo - bug 1158976.