Quote:
Originally Posted by ixtab
Is there anything I can do while you're at the JS part?
|
Yes. Please, be patient while I'm trying to do my best.
Parsing is already done. Experiments with XLIFF source files showed that Transifex support for XLIFF is quirky, so I've reverted to idea of outputting to MOZILLAPROPERTIES with metadata in external JSON file. (Metadata is required because JS files structure is not so uniform as Java.)
Quote:
Originally Posted by ixtab
Since we're almost there (at least conceptually), I was thinking about starting to plan for a tool which would bundle up all localized resources. A couple of questions come to mind:
- Package type: I'm in favor of providing an update*.bin as installer/uninstaller. Any other thoughts?
- Should packages include or exclude the little hack to enable the "international" settings? Pro inclusion: 1-stop-installation. Pro exclusion: independent update of that file (in case it ever becomes necessary for new firmware) + strictly speaking, it contains (modified) amazon code.
- We will need one final element for each supported language, namely the .properties file that identifies the locale (also described in the previous link). We cannot do that through transifex. But since the file is so small, I guess we can arrange for some sort of "out-of-band" mechanism to create these files.
Concerning the last topic: I suggest to place these files in a 4th directory, along with the framework, locale, and (waf/pillow?) one. Maybe "manifest" would be a good name. That directory would contain only "<locale>.properties" files for each supported locale. |
+1 for update*.bin. Yifan Lu's
KindleTool is great for this purpose.
-1 for including of UI hack into distribution (update bundle or anything).
.properties for locale identification could be generated automatically. Locale code (i.e. locale and locales.supported) could be extracted from localized resource file name and locale's name (i.e. display.name) could be extracted from mapping "locale code -> locale name" which is certainly located somewhere in Internets (and should be small enough for storing it in Git repo).
UPD: found it.
Common Locale Data Repository (or direct link to right file:
http://unicode.org/Public/cldr/2.0.1/core.zip). Whole file content is too big, information could be extracted from 'common/main/en.xml'.