One .DTD and two .properties parsers

DTD and .properties parsers work, tests for them (mostly reused from JavaProperties parser) do pass. The substitution of translated strings into “template” (the original file to be localized, with all its comments and formatting) also works, making it possible to correctly upload and download l10n files, even half-translated. And, of course, the fabulous online editor Lotte shines its goodness on good ol’ addon localization files.

Through to brew the code in my fork to the state when it can yield the patch ready to be filed, two things need to be done:

  • Upgrade Silme to July’s version (currently rev 629 is used), which was just this day reworked by Zbigniew and now works on top of new shiny library for handling mozilla things, currently formats. BTW, last time I checked, my pet l10nmerge.py also required fixes to work with recented pyast-powered silme, and a little more complex than the one needed for r629.

  • Solve the conflict with JavaProperties handler. That is trickier, as this handler uses the same file extension as Mozilla one, yet it differs in two important matters:

    • it supports many more features of the format than Mozilla’s one do, namely multiline strings, using : for specifying pairs besides of = etc.
    • it reads and outputs Latin-1.

JavaPropertiesHandler’s format tolerance is not a problem, and neither is its habit of expecting Latin-1. I can try two of them in turn, Java and Moz, one after another, checking for ability to decode incoming file. Java will accept Latin, Moz will accept UTF8, everybody happy.

But who will be in charge of outputting the content? It will not be possible to judge target platform by file-to-be-localized extension, and neither by its encoding : usually those are in English, and only in some cases they carry fancy characters like Unicode ellipsis.

Speaking of the screenshot above, it shows a picture unusually rarely seen in Transifex, yet so common on Babelzilla and so natural for a localizer to see. Tx experience is organized as Project-Resource-Language-edit, and the “Localizer’s view” where you see all the files in your language and their status — the thing that obviously interests you the most — is hidden in Teams tab (when teams are enabled!), and is not the one you go back after editing a resource. Haven’t found a bug on that, gonna file one.

Also hacked a prototype for addon-repacker, the python script which will be adding localized resources (dtd/properties) to given xpi files for ease of testing. As its purpose is testing and testing only, final shipping is author’s business anyway, it uses very straghtforward approach: adds files into someaddon.xpi/tx_locale/code/ and fiddles with chrome.manifest to expose new locale for the same content package other locales are. Might fail for complex files with multiple content packages being localized, but that seems quite uncommon.

This entry was posted in gsoc, mozilla. Bookmark the permalink.

Comments are closed.