Integrate Transifex l10n platform for Extensions
Tim Babych
Short description: Give extension localizers and authors the best web-localization platform around — the Transifex system.
Abstract
The aim of this project is to provide extension localizers with better tools to do their work efficiently, and extension authors with smoother experience in that field.
Personal details
Name: Tim Babych
Email and gtalk: tim.babych@gmail.com
Site: http://clear.com.ua
Phone: +3050 181 96 25
IRC: tymofiy @ irc.mozilla.org #l10n
Project Background
There is a great need for a good tool to allow extension authors and localizers to easily collaborate. That spot is currently so-so filled by Babelzilla system, but for years it has been unreliable and cumbersome. As a member of localizer community I often hear complaints about it, and talking with developers I also feel that they are not happy with it either.
Localizers badly need more streamlined interface and ability to organize themselves in teams, while developers need data access API (some tech-savvy localizers would benefit from it too) and both groups want more stability, and less data-losses.
That issue has already been raised as bug 369070
Project Proposal
I propose officially endorsing Transifex as our L10N platform and promote its Mozilla-branded and tweaked instance on AMO. Transifex is chosen because:
- it is widely used and has great UI
- it has API and client access tools
- it is written in Python/Django, which goes in line with mozilla webdev technology choice
- Mozilla already had good experience with Transifex (it was chosen for CommonJS strings l10n at MozillaLabs)
Subtasks
Transifex .properties and .dtd support.
Add mozilla l10n format support to Transifex. Currently it is not supported, through there already is a ticket for it, but marked "sometime". I talked with Glezos, the core developer of Transifex, and he was happy to get help here. Silme library should greatly help and the fact that Transifex 1.0 now uses database storage instead of file-based storage also simplifies the task.
This task alone would greatly simplify life for addon authors and localizers, because they will be able to use Transifex.Net service.
Addon repacker.
Create addon rebuilder, to ease the testing process for localizers. Addon source and manifest parsing are already implemented in AMO, supposedly some of that implementation could be reused. That can be implemented either as a django-addon (Transifex-developed way for extending its functionality) or as a fork.
Integration with AMO.
Exact level of integration with AMO would have to be discussed and worked out with AMO developers and community (would there be common userbase on general AMO and L10N servers, would addons be automatically submitted for localization etc), but as the bare minimum there would be:
- An indicator on AMO's addon page about its level of localization into current locale
Like, if user is on /fr/xyz-addon/ page and xyz-addon is not localized into French, there should be a link telling about it and asking for user's help. - An ability to import l10n sources from AMO
Currently Transifex can read any public http-readable or version-controlled resource and import l10n source from there, which is more than enough for authors who have source of their addons on github/bitbucket. But still there are people who do not use open repos, and AMO should provide them with a way to publish localizeable strings for Transifex. So that each extension author wishing to ask people to localize his addon (either with Mozilla's Transifex or Transifex.net) would just have to enable this feature in addon properties and copy-paste source URL.
Schedule of Deliverables
During the summer, I would be able to devote about 15-20h a week to the project. The final deliverables of the project will be:
Transifex code:
- An accepted patch to Transifex that adds support of mozilla l10n format to it.
- An "addon repacker" that is either a pluggable django-addon or a patch that can be applied on top of trunk Transifex.
AMO code:
- Ability for an addon author to state URL, where l10n of his addon is taking place
- Indicator of addon l10n completeness for a given language
- Exporting of addon l10n files in Transifex-acceptable format
The planned schedule for 16 weeks of GSoC time is:
1-3 weeks: getting to know the Transifex code, discussing the project with mentors and community
4-5 weeks: adding support of properties/dtd to Transifex
6-7 weeks: implementing addon rebuilder
8-10 weeks: studying AMO(zamboni) code
11-12 weeks: adding fields and UI needed for advertizing addon l10n
13-14 weeks: adding l10n source publishing
15-16 weeks: rounding up, documenting, slot for additional tasks that might pop up.
I would be happy to get involved into deeper integration effort if there would still be time.
Open Source Development Experience
I have been leading Ukrainian Mozilla l10n team since 2007 and participated (filed an accepted patch) in Silme library development. Also I developed a Firefox addon for reading e-books in FB2 format. And, of course, I was and still is a Mozilla tester and I file bugs when I encounter them. Besides a Firefox addon, I have written a few userscripts and a PyGTK app. Also I submitted patches to several python/django apps like CleverCSS, django-css, django-cache-util, django-csv-serializer.
Work Experience
I have beed doing web-development since 2002, and last three years of it in Python/Django. Also I have been doing lot of frontend HTML/CSS/JS coding and that is how I got involved with Mozilla products in the first place. My full CV is available on my site.
Academic Experience
I obtained my Bachelor degree back in 2002th, and two years ago went to university to obtain my Master's degree. I am finishing my thesis (about word stemming in Ukrainian language) this spring.
