Tag Archives: mozilla-l10n

Translation Sprint for Gaia

Last saturday i.e. 29th December 2012 we had a translation sprint for Ankur India with specific focus on Gaia localization. The last few weeks saw some volunteers introducing themselves to participate in translation and localization. The Firefox OS seemed like a popular project with them that was also easy to translate. However, the reigning confusion with the tool of choice, was not easy to workaround. The new translators were given links to the files they could translate, and send over to the mailing list/mentor for review. Going back and forth in the review process was taking time and we quickly decided on the mailing list, a date to have a translation sprint. We used the IRC channel #ankur.org.in and gathered there from 11 in the morning to 4 in the evening. The initial hour was spent to set up the repository and to decide how we were going to manage the tasks between ourselves. Two of us had commit rights on the Mozilla mercurial repository. Of the 5 translators, two participants were very new to translation work, so it was essential to help them with constant reviews. By the end of the second hour, we were string crunching fast and hard, translators were announcing which modules they were picking (after some initial overlooking of this, prolly due to all the excitement) and then pushing them into the mercurial repository. We shut shop at the closing time, but had a clear process in place which allowed people to continue their work and continue the communication over email. All it needed was an IRC channel and a fundamental understanding of the content translation and delivery cycle.

SUMMARY

Participants:

Biraj Karmakar (biraj),
Priyanka Nag (priyanka_nag),
Runa Bhattacharjee (arrbee/runa_b)
Samrat Bhattacharya (samratb),
Sayak Sarkar (sayak)

Translation Statistics:

At Mozilla Dashboard – 39% translated. (Does not include the files still being reviewed)

What worked:

Communication was live
Faster turnaround of translation -> reviews -> revision
Queries were resolved faster
Commits were immediately made into the repository
Workflow was established to ensure the committers were being notified of files ready to go into the repository
No overlapping of translation

What could have been nicer:

A simpler tool to track the translation, through *one* interface. (Discussed many times earlier, and comments can be directed to the earlier post)
Pre-decided work assignments to start things off (this was rather hastily put up)
More time

Follow up:

There is still more to do and the translation has to continue. Not just for Gaia, but for other projects as well.
A review session for all the translated content. Besides catching errors and omissions of various nature, this can be of particular benefit to the new translators who can gauge the onscreen context of the content that they had to blindly translate

Mozilla L10n – Discussion Notes

2 Replies

During the recently held Language Summit at Pune, we got an opportunity to discuss about a long standing issue related the localization process. Several discussions over various media have been constantly happening since the past couple of years and yet a clarity on the dynamics were sorely missed. A few months back a generic bug was also filed, which helped collate the points of these dispersed discussion.

Last week, we had Arky from Mozilla with us who helped us get an insight on how things currently stand in the Mozilla Localization front. Old hats like me who have been working on the localization of Mozilla products since a long time (for instance, I had started sometime around Firefox 1.x), had been initiated and trained to use the elaborate method of translation submissions using file comparision in the version control system. During each Firefox release, besides the core component there are also ancilliary components like web-parts that need to be translated on other Version control systems or through bugs. Thankfully there is now the shipping dashboard that lists some of these bits at one url.

However, recently there have been quite a few announcements from various quarters about Mozilla products being made available for translation through several hosts/tools – verbatim, narro, locamotion, even on transifex. Translators could gather files and submit translations via these tools, yet none of them deprecated the earlier method of direct submission into the servers through the Version Control Systems. The matter was much compounded with also a spate of translations coming in from new translators who were being familiarized with translation work at various local camps as part of Mozilla’s community outreach programs.

During the above mentioned session, we sought to find some clarity on this matter and also to understand the future plans that are being undertaken to reconcile the situation. Firstly, we created a list of all the tools and translation processes that are presently active.

1. Direct Submission into Mercurial or SVN

2. https://localize.mozilla.org/ – Aka ‘Verbatim‘ is essentially a version of pootle running on a server hosted by Mozilla. Used to translate web-parts, snippets, SUMO content etc.

3. mozilla.locamotion.org – Hosted by the http://translate.sourceforge.net group, and runs an advanced version of pootle. Used to translate Firefox, main.lang etc.

4. Narro – The Narro tool that allows translations of Firefox, components of Thunderbird, Gaia etc

5. Pontoon Project – To localize web content. More details from the developers here .

6. Transifex – Primarily gaia project

7. Babelzilla – Mozilla Plug-ins

There could be more beyond the above.

The reason that was given for the existence of all these tools is to allow translators to choose a tool that they were ‘comfortable with‘. This however gives rise to quite a few complications involving syncing between these tools which evidently provide duplicate platforms for some of the projects and also about maintaining a trace of translations by the translation coordinators. Especially when the direct submission into VCS is still pretty much an open option for translators (coordinators) who may have not be aware of a parallel translation group working on the same project on another translation platform.

A new project called ‘ELMO‘ is aimed at rectifying this situation. This would host the top-level URI of the Mozilla Localization project, with direct links to each Language’s home page. The home page intends to list the Translation team details and urls for the projects. However, there is one big difference that seemed apparent: Unlike other Translation Projects which provide one umbrella translation team, each of the Mozilla products can have different Translation Teams and Coordinators, independent of each other. It may be a scaleable solution for manpower management, but leaves a big chance of product continuity going off-sync in terminology and translation. However, it may be a good idea to wait and see how Elmo fixes the situation.

Meanwhile there were a few action items that were fixed during the discussion (Thanks Arky!), these were:

1. A page on the mozilla wiki listing *all* the translation tools/hosts that are active and the projects that they host

2. Follow up on the discussion bug for “Process Modification”

3. A request to have automatic merging of strings modified in source content into the l10n modules in Mercurial (i.e. the strings identified via compare-locale). For instance, the comparision between the bn-IN and en-US module for the Aurora branch can be found here (cron output).

4. Explore the possibility to identify a consolidated Project calendar for all the Mozilla l10n projects. (Reference comment here)

As Arky mentioned during the discussion, there were plans that were already underway to implemention and I am quite excited to wait and see how things go. Some blogs or updates from the Mozilla L10n administration team would be really helpful and I hope those come in quick and fast.

Attendees:

Arky
Amir Aharoni
Sayak Sarkar
Ankit Gadgil
Ani Peter
Sweta Kothari
Jaswinder Singh
Rajesh Ranjan
Shankar Prasad
Nilamdyuti Goswami
Shantha Kumar
Manoj Giri
Krishnababu Krothrapalli
…(Please leave a comment if I missed your name)

Leave a reply

(Since, I would be writing a bit more in response to the comments on my earlier post, I decided to make it into another post.)

Thanks Chris for dropping by. I hope to make it clear that I do not intend to point fingers at individuals, but rather the overall scheme of things where more often than not, the results take a backseat – much like red-tapism.

“Selection of locale specific search engine plugins, RSS feeds and services is a key part of trying to give that kind of good experience and I’ve been a big proponent of trying to make sure that we don’t just have en-US selections in the UI of the locale versions. That doesn’t serve the best interest of the user, but it does create some tough work for the localization teams. Some teams love this ability to customize the browser to their locale, and some find this extra work tiresome. Where we can find people that want to get involved with the research to find the top search engines and services we definitely want to try and add them as contributors to the localization teams to help distribute the work load. “

Regarding the above statement, I remember exchanging notes with Axel during Foss.in last year (a good 2 hours, he was kind enough to spare). Especially, about the fact that the standard productization process seems to go through lots of bends. For each language. Given the headstart a few languages had gotten, a natural assumption for l10n volunteers is that the processes would be streamlined into segmented divisions over the course of time. e.g. Pooling of alternatives for indic languages, which would probably share a few resources due to their geographical relevance (RSS feeds, start pages, searchplugins etc.). Re-inventing the wheel in this case is a (re)research overhead for all parties involved. e.g. the amount of time Mic spent chasing up rediff.com for their consent for bn-IN, would be spent again for another language. Instead, if approval for all Indian languages is gained from these Indian websites at one go, all other languages could simply walk-through the process. Same for the earlier mentioned leg-work regarding the First-Run pages. Imho, not too many language groups share such a huge geographical boundary and web-presence. But we do and perhaps merit a somewhat customized localization process. I have been waiting for the FFx2 productization process to reach its end, so that I can collate all the steps that I have completed and create a documentation (checklist with pointers), for other localization teams. Especially, the parts regarding the India-specific bits.

I do not intend to be given leeway by unexplained choices for an under-baked product. Rather I’d like to see things done with precision – from both ends – to be assured of a product cured of basic failings. I do agree in a way with Axel when he says – “The right thing is to get users a sustained on-line life with mozilla, the wrong thing is to make marks on the wall and just count languages.”

“On-life sustenance” comes from the fact that the basic foundation of the product is strong enough to withstand the expectations from users. What those expectations can be is a matter of homework in the right direction. Marks on the wall always look good, but are not always in the deepest shade.

Secondly, about the messaging. I would agree that restricting the press coverage is not an option. However, correct packaging of the message is important. That is what I intended to convey. From my personal experience of having to explain how-open-source-projects-work, to various audience levels, I can say that the analogy to be used, differs widely. Mainstream media, to most extent do not understand the concept of “volunteer-driven-open-source-projects”. Its a shade of gray, that does not belong to their black and white world. Passion-driven projects are the ones equated with NGOs or hobbyist groups (intended without a commercial motive). Hence, relative circumstances would probably play a huge part in customization of the jargon.

Thanks Seth for your comment and post. A review of the team standings and itemizing of issues would certainly help. Especially, if the flags can be identified and raised from the past experiences.

Motivation is not always the keyword

4 Replies

A recent article published in a leading daily here in India touched quite a few raw nerves. Besides talking about the presence of the Gujarati and Punjabi localized versions of Firefox in its latest version, the article somewhat prominently highlights the absence of quite a few other languages due to “a lack of motivation”. Needless to say, there was quite a flutter amongst the volunteer-driven localization communities, who were quick to exchange notes on various mailing lists. So much so, that Chris Hofmann had to come forward with his apologies. Given all the hullaballoo, even I wanted to add my 2 paisa to the entire episode, in my own way.

First up, its important to understand how the Firefox Localization process works. It is rather different from most other localization projects and can pose quite a challenge even for old-hats. I shall try to summarize it, in the best way I can.

During the process of Firefox localization, two variants of localized components would surface:

A Language Pack: – This is essentially the translations of the user interface messages and can be downloaded as an add-on. In essence, it is like an additional appendage for the Firefox version that one is running.

An Official Build: These would be the translations+extra components (like the translations for the various default pages displayed by Firefox), which would be shipped as part and parcel of a Firefox release. ie. (using a similar analogy as earlier), it is like an arm that is part of the body since birth.

Each language shipped with Firefox, goes from the “Language Pack” stage to the “Official Build” stage in a phased manner. Unlike other translation projects (e.g. Gnome, Fedora), a new language is not included for the offical development version rightaway. Rather, one has to first work on the previously released stable version (so for Firefox 3, one needs to get the Firefox 2 source), complete all the translation and other tidbits, and only then would a language be accepted as official or as its called “productized”.

This is where most of the fun starts. The tidbits include quite a few default pages for Firefox (Complete List is here). The pages are in English and provide the templates for the localized versions. Yet, while translating one has to ensure that the local effects are maintained. For eg. The FireFox First-Run page. Notice the links to “Hype Machine” and “Yelp“. Now try figuring out the Indian equivalent for each of them. Yelp could be mapped to burrp.com. But after hunting all over the place for something similar to Hype Machine, finally it was decided to go with an internet Radio station instead. Enter RadioVeRVe. Same goes for search plugins etc. These bits and pieces of the productization part is tracked and submitted through various bugs, which are handled by different Mozilla Developers. I have been working on the Bengali India productization for quite sometime now. Bug id – 398992. As mentioned earlier its a Firefox 2 productization bug and there has been quite a bit of back-and-forth action on the bugs. There is a bug for Firefox 3 as well, but it would only come into effect once the Firefox 2 productization is complete. Bug id – 415575. So it might be a while before all the nitty gritties are worked out and issues finally ironed out. Since Rajesh and I have been closely working with each other, it is quite understandable why the newspaper article came as a mighty blow to him.

However, what I do find disturbing is the nonchalance on the part of the mainstream media before making such blanket comments. Little knowledge is always a bad thing. Especially in matters like community driven projects, which are to this day an unfamiliar or at best a hazy idea for most people watching things from outside the perimeter of the action. Perhaps it might have helped, if credentials of the commentator could have been judged prior to the interview, so that the messaging would have been drafted in a comprehensible format of the audience. Damage control measures are not always a way out. As are not single points of coordination and failures.

The Indian community of Localization volunteers are probably one of the most closely knit group of people. With a common culture and geographic proximity that bonds us at a personal level, friendships have been forged, experiences shared and help is always at hand. More than anything, its personal for us. Very very personal and its about time people understand it.

The Complete process of making an Official Firefox Build.