Managing localization strings (ex: Updated Italian localization strings)

[pettarin]

Updated Italian localization strings, based on current en_US/messages.json

[pettarin]

Yesterday I made this pull request, but now I realize that the i18n string set is actually still work in progress --- so my contribution might need some update soon.

In general, I think it would be beneficial to the project if RF could define a policy for contributing the i18n strings, so that they can make into the "stable" releases (of Readium.js or the Chrome extension).

My suggestion is to maintain a list of previous i18n contributors and notify them directly (i.e., by email) once the en_US/messages.json is stable (at least 1 week before the build due date), so that they can update the i18n/messages.json for the respective languages. I can volunteer for the Italian language.

Alternatively, the RF might want to release a public "call for translation", suitably before the build due date (say 2 weeks in advance?).

[danielweck]

• some food for thoughts regarding this issue -

Missing language keys are currently reported in the console, when using the Readium Chrome extension or the online "cloud" reader:

https://github.com/readium/readium-js-viewer/blob/develop/i18n/Strings.js#L50

This can help detect basic l10n errors, i.e. missing translations from the default English "master" set of strings. In an ideal world, Readium contributors should be able to monitor i18n changes, for example via an automatically-generated HTML page that displays a "grid" of all supported languages (with highlighted cells to emphasise missing translations).

Dan

[pettarin]

I have updated the title of the issue.

I second Daniel's suggestion. I add that for Menestrello I use PO files, and then convert them into JS(ON) dictionaries with po2js(on).

Moreover, let me remark that this only affects the mechanics of how localizations strings should be provided, but not the management of the process. Even if I track the devel branch, I have no clue whether the current code base is stable and ready to be released, nor the corresponding time window to provide the translation. Again, if the RF wants to have as many translations as possible, the easier and clearer the RF makes the process, the higher the chances to get translators are.

[datalogics-bhaugen]

One service I have been looking into for managing translations is OneSky. They have some sort of github integration that I have not experimented with.

[rkwright]

Feature request that we need to consider more carefully, but not for 0.22

[rkwright]

Way stale.