After quite a while — new Babelzilla was launched officially!
A week ago I was presenting Adofex to the crowd of happy localizers. The room was packed tight and the air was sparkling with excitement. Kinda 🙂
The presentation was centered on features of Adofex, telling people about the new features and UI that will make their lives easier both as translators and as addon maintainers. Wladimir Palant, the author of Adblock Plus, was eager to try and also to hack the new system. That is really inspiring!
Also, the community raised a very valid point about team ownership. As one of important features of the new system over the old one, I wanted to see unified translation teams. One-language-one-team. Yes, per-project teams are also totally possible, just are not the default.
With that setup, all members of language team would
- get some place to be listed (look as a team)
- help each other on totally any addon (work as a team)
- have to be approved only by global language maintainers, who are expected to be much responsive and responsible then per-project team-mainteners – who are often unreachable or have quite a view on translation standards. (able to act like a team).
With all that said, I have a confession to make. I am actually looking at this from the boss side of the table. I am a maintainer of Ukrainian localization, have been localizing Firefox itself and few key addons for ages, and I get frustrated when I am not able to fix typos/mistranslations/missing strings in addons owned by other people. And filing “join team” requests, then waiting for them never to get a response was not an encouraging thing.
So, I created my own system, with blackjack and whistles, the one that fits the workstyle of a WikiGnome perfectly: once you are in a team, you are free to improve whatever you want.
Thing is, not everybody is a Gnome. Most people are Maintainers, and some are even Trolls. Maintainers are the ones who care about their favorite addon, they are added to the list of localizers in credits section and they do not want any outsiders to mess around. Trolls are the who guys care more about language purity and ‘proper’ term usage than doing hard work of translating kilobytes of text. One Troll autoreplacing “center” with, say, “centre” with no ability to roll that change back can easily alienate many Maintainers.
And, actually, in an environment (Launchpad) where I do not have the master switch in my hand, and where any of my pet translations can be (and are) edited by some guys whom I have never asked to – I do not like it myself.
To give people sense of satisfaction and well-earned fame – they should be able control the results of their work. Outsourced projects still is a useful feature to have, because Adblock Plus and Adblock Hiding Helper should really have the same teams working on them. But whether to outsource every new project to global team – that is a question. At least until someone implements translation history (#705) for Transifex – which would at least explain who changed what.
A feedback here would be greatly appreciated.
PS: for those who haven’s seen that great show, the source of team joke is IT Crowd.
UPDATE year later: It went live and welcomes translators!
P.P.S. Seems that the picture in the top of the post was brought bad mojo into it. I really hope it ended.
The summer has ended, results are submitted, yet the Adofex evolves on. Since last report following changes happened:
- Users can now download Translations and Resources as ZIP files
- Translated locale can be repacked on top of existing XPI file, to easily test your work
- Both are substituting English strings for untranslated entities
Transifex as a project evolved from Fedora translation system emphasizes Resources too much, paying less attention to the Languages. As a temporary measure against it, an always-present Release called ‘All-Resources’ exists, and it has stats for all the languages and can serve as an entry point.
- It was given more prominence, it is no longer buried under the fold. And Resource list is visible only to project maintainer.
- It is now editable (#782), a feature that is gonna die with it through, when proper per-Language view lands.
- Date inputs are spiffed with a jquery magic. Unfortunately, that breaks Tx’s autocompleter, so at the moment is used only for ‘All-Resources’.
- Few layout improvements – fancy sticky footer was unaware that page can change its height dramatically when translation editor/viewer gets loaded
- Pushed upstream tiny cleanups in Tx templates: #781, #783, #785.
- Global ‘Mozilla’ project was created to host all the official teams
- All newly created project start by their teams outsourced to Mozilla project by default.
As some of my patched were getting checked in, and some required refreshing, forked transifex repo was no longer a good option. So,
Importing data from Babelzilla could never been easier:
Reskinned transifex with support for Mozilla formats deployed at adofex.clear.com.ua, addons imported through management command, I am finishing UI for uploading them.
- Patch to ticket #89 in Transifex is filed
- Previous patch reworked completely, Silme is not used anymore:
- .properties reader was already in place, and supported more features of the format than Silme did. Except comments (which were absent), but handled multiline strings more correctly (did not forget to strip slashes and merge lines).
- including entire library just for reading of .dtd files (writing was handled by Tx anyway) seemed like an overkill and unneeded complexity.
- New and old handlers were compared on entire set of dtd and properties files living in mozilla-aurora.
- Difference in behavior in Java and Moz-style properties is resolved in configuration. May be Glezos would want to make Moz-behavior main one, but anyway the ability to have both is a plus.
- Comments are read for both kinds of .properties and in .dtd.
Not so good news: The project-creation wizard (import from github/bitbucket), dashboard etc – “stuff that makes transifex.net interesting” – are closed source addons. Also, navigation issues and general unfriendliness to a localizer are all mine – no one else is currently working on them.
Thus, to make that cutie the next and better Babelzilla – a little more than the format support is needed. Dashboard, streamlined navigation, XPI-based newproject wizard (every addon author have an xpi, even if he does not have a source repo, so xpi-reading seems to be more important), just to name some. Working on.
Finalizing the patch, reading zamboni code.
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.
I am still working on dtd reader, taking existing java .properties one as an example how Handler class should be implemented. Hopefully will finish this part on this weekend.
So far so good. My current task on the project is extending the Transifex system with new format, as an obvious start point and a foundation for the ongoing work. I enjoy working with Tx code (development tip), it is well commented and organized. Had few issues while installing the project (requirements.txt was out of date), but other than that the experience was smooth.
Among the other format readers there is Java .properties reader, which unfortunately works only with ISO 8859-1 encoding (other characters have to be represented as Unicode escapes). I plan to replace its reading code with Silme calls, along with writing DTD reader. The one thing to check is whether Silmefied .properties reader would supersede original one totally, or I would have to check which one to call. I would like to avoid that, as currently Tx picks file reader only by extension and magic number, which is obviously the same for Java and Mozilla .properties file.
Rounded up a few things besides of GSoC during during start of June, like the studies, and Thunderbird/Calendar localized release and can devote more time to the project now.
Next talk with mentor is scheduled to June 21th, and I hope to have working prototype by then.