Earlier this week I came back from the Ljubljana Localization Hackathon which took place over the weekend. It was an inspiring meetup focused on translating Mozilla projects. I left full of energy and ideas and happy to have met many amazing people contributing to Mozilla.
Almost thirty participants from Armenia, Bulgaria, Greece, Hungary, Macedonia, Romania, Serbia and Slovenia gathered in Ljubljana for three days. We discussed the current state of localization, the future of the localization process and technology at Mozilla. There was time for each of the communities to work on their goals as well as time for everyone to talk to each other and have fun.
The morning of the first day was dedicated to a series of updates from the Localization Drivers team. I started out by announcing the team’s updated mission statement which is all about becoming an efficient localization provider for Mozilla. I also summarized the recent changes in the team which is now divided in two working groups: the Technical Project Management group (Delphine, Francesco, Jeff and Peiying) and the Technical group (Axel, Matjaž, Staś and Zibi).
Francesco (flod) explained the thinking behind the new release process and the plan to use single repositories for each locale for all release channels. Right now there are five different versions of Firefox: Nightly, Dev Edition Aurora, Beta, Release, and ESR and each localization exists across four different repositories. After the migration there will only be one canonical repository for each locale. This will greatly simplify the setup for the localization teams.
Delphine then took the stage to introduce MQM which was well received. MQM is a framework for evaluating translation issues. It provides structure to the process of reviewing localizations and makes it easier to give constructive feedback to the localizers as well as track the quality of the localization over time. A central piece of MQM is a good and up-to-date style guide. Many localization teams spent the Saturday and Sunday afternoon working on their style guides. Delphine also mentioned new Transvision features available to the localizers: the Translation Consistency view and the Unchanged Strings view.
The main theme of the morning updates was simplicity and quality. We’re making a lot effort to reduce the complexity of the localization process at Mozilla and to create approachable quality benchmarks. We want to close the feedback loop between the current localizers and new contributors; help them connect, discuss and encourage participation. The reviewers should be able to explain why a suggestion was rejected. There needs to be an easy and contextual communication layer between new localizers and the reviewers.
An important part of this strategy is careful planning of the work load for the localization teams. In the past we ran an experiment involving Firefox for iOS: the localizers weren’t required to manually sign off on any particular changeset. It turned out to be a big success. Delphine announced that going forward there will be no more sign-off requests done by localizers themselves. Instead the Localization Drivers will verify that the changesets work and sign off on them, thus reducing the overhead for the localizers.
Without signoffs we’ll need a better way of tracking progress and understanding the state of completion for each locale. Francesco briefed everyone on the plan to group strings into so-called buckets. Buckets will be based on how visible strings are or who their target audience is. The likely candidates for individual buckets include: the main browser UI, Developer Tools, DOM/CSS Parser errors etc. Buckets will have priorities and will allow us to track progress separately per bucket.
Saturday morning is also when we took it outside to do an exercise called a spectrogram. If you’ve followed the blog posts about the previous hackathons or you have been to one, you’re likely familiar with the concept. Spectrograms allow us to have a laid-back conversations on different topics. We start off by asking a question. Depending on how strongly they feel about the answer the participants then move along an imaginary line. The line allows us to capture the subtleties in opinions and feelings. That is, the whole spectrum of responses.
A number of responses stood out to me during the exercise. We talked about the communication inside of the localization teams and between the localization teams and the Drivers team. People were generally happy with how quick they got their answers in IRC and the mailing list. However a few contributors expressed a concern that it is not clear to the new-comers how to contact their locale’s team.
We asked how people felt about the amount of work they did and the number of projects there were to localize. Everyone ended up in the middle of the spectrum and Stoyan from Bulgaria offered an interesting explanation: it’s because localizers like what they do and they choose to do it themselves. Related to this was a question about deadlines: are they too short? A sentiment that resonated with a lot of participants was that they didn’t mind the deadlines—but rather the amount of time it takes for a translation to reach the users. This turned out to be an important insight closely related to Live Updates to Localizations that we’re working on as part of the effort to port Firefox to L20n (more on that later).
Goce from Macedonia recalled an experience which I feel we should all remember about and try not to repeat in the future. Back in the Firefox OS days there was a big rush to get a lot of content localized before the launch. In the end the release was delayed and canceled. It’s important for all involved stakeholders to have a good visibility into the release planning. Precise time estimates help prioritize community work and make sure efforts beyond the call of duty that we often see from the community aren’t in vain.
The question about mentoring new contributors vs. localizing alone spurred a long conversation with many take-aways. Fredy from Greece admitted that reviewing someone’s translations can sometimes be the same amount of work then just doing the whole translation from scratch himself. He wondered if translations could have their Discussion pages similar to definitions in Wikipedia which would be then publicly accessible and easy to reference in the future. Matjaž noted that reviewing might be in fact rather easy, but it’s giving meaningful feedback to the translators that is hard and time-consuming. MQM will definitely help in this respect. We’re working on prototyping the UI for Pontoon to make it easy to use for everyone.
Balázs from Hungary then quipped that there are two kinds of people: those who are willing to contribute and those who are able to do it. Usually these two kinds don’t overlap. The role of authoring tools like Pontoon and Pootle is to help those who are willing bridge the gap of not being able to.
The conversation about mentoring and evaluating new contributors ended on a high note with a great story from Slovenia’s very own Lan. Lan is a SUMO localizer and he was able to attract a new contributor to the Slovenian localization a year ago. When he started reviewing their contributions he realized the translations weren’t as good as he had hoped. Lan didn’t get discouraged though. He took his time to review all translations, corrected them and then asked the new contributor to go through the fixes to get an idea of how to improve. This turned out to be a good investment of Lan’s time; today the new contributor is still active and their translations are much better!
(Lan’s story is even more impressive if you consider that he is still in high school. In fact two very active members of the Slovenian community, Lan and Amadej, are both very young. I can’t wait to see what Mozilla will have become when they’re my age!)
While it’s clear that chaperoning new contributors could help foster the community growth, the group was divided with respect to how to actually do it. Some prefer to give out small independent assignments to localize real existing projects and nurture the sense of ownership. Others would rather create a single testing project with a known good translation and evaluate new contributions in reference to it.
The question about the preferred frequency of contribution always leads to interesting findings. The two extremes of the spectrum are “I want to localize small numbers of strings daily” and “I want to localize a big number of strings once a year”. In Ljubljana most of the participants chose to stand somewhere in the middle. A smaller group preferred daily assignments that could be completed during a coffee break. Another group would rather see the frequency of localization aligned with the frequency of releases of the software. One person in the middle was Marko from Serbia who summarized his choice by saying that he liked seeing the results of his work on a regular basis.
The last question that I would like to highlight here was about testing. We wanted to know how the localizers test their localizations. The responses covered the entire spectrum. Some localization communities have dedicated QA teams while other localizers dogfood their own work by using the software themselves. Another group wasn’t sure how to test nor where to find the nightly builds. This suggests that we can do better with documenting the best practices for testing. Matjaž also suggested that this kind of information for each project could be displayed by Pontoon.
The difficulties in testing often stem from the fact that some translations are hard to come by in regular usage and only show up in rare situations. The experiences from localizing Firefox for iOS prove that automated screenshots are an invaluable tool in such situations, in addition to being useful overall.
Pontoon and L20n
On Sunday morning Matjaž and I took the stage to represent the Technical group of the Localization Drivers team. Matjaž presented Pontoon which had already been used by some of the localization teams. There have been many improvements to performance and usability of Pontoon as of late: faster sync, bulk actions, more readable diffs, better filtering, suggestions from other languages, support for L20n’s syntax and more! Looking into the future, one of the most important tasks ahead of us is the merger of Pontoon and l10n.mozilla.org. We want to make sure all information relevant to localization is in one place.
The L20n presentation was divided into two parts. I introduced L20n’s new syntax, FTL, and recommended the L20n by Example and the FTL Tinker as the learning resources. I then showed a few use-cases where L20n really shines. The first one was according past participles with the gender of the subject. The second one was about particles governing the grammatical case of nouns. My audience could easily relate—their native languages are among the ones with the most complex grammars in the world. In fact, it was an incredible diverse gathering of languages! We had a strong group of Slavic languages (Bulgarian, Macedonian, Serbian, Slovenian), followed by a Romance language (Romanian) as well as two of the oldest languages in the world: Greek and Armenian. And don’t forget Hungarian which is one of the few European languages that isn’t part of the Indo-European family of languages.
In the second part I showed a build of Firefox ported to L20n and demoed Live Updates to Localization. It seems like the ability to push translation updates and fixes almost live without having to wait for the next software update really is a game changer. The feedback I got afterwards was very positive.
Working in Groups
Both afternoons on Saturday and Sunday were dedicated to working in groups. All the participating localization teams had set goals leading up to the hackathon. The goals ranged from catching up with localizations to reviewing suggestions to discussing the health of the community to creating style guides. The list of goals is available in the wiki.
The Bulgarian community deserves a special mention here. During the hackathon Ognyan transferred the leadership of the localization team to Stoyan (first from the left in the picture below). Congratulations, Stoyan! Ognyan and Stoyan then quickly proceeded to update the Bulgarian localization of Firefox Desktop to 100% complete.
Notice the Mozilla l10n photo frame above? Make sure to check out more pictures with it taken by Nino. We also had custom-made name badges and other visual accessories. All design materials were created by Mozilla Slovenija community designer Rok. They are available on GitHub for other teams and hackathons to reuse.
Fun and Rest
Ljubljana is a beautiful city. It’s very friendly to pedestrians; almost everything was in walking distance from the venue. It’s also very green and inviting when it comes to spending time outdoors. After a period of focused effort it was great to take a short stroll across the city.
Thanks to the amazing organizer and host, Gašper, each evening was full of activities and opportunities to get to know each other. We tasted traditional dishes from Prekmurje, a region of Slovenia close to the Hungarian border. We visited the Ljubljana castle which offers fantastic views on the mountains surrounding the city. We even competed at a kart racing circuit!
Helping Gašper was Nino, also from Slovenia, who managed the hackathon’s presence on social media. He took over the Mozillagram Instagram account for the weekend which resulted in a 10% increase in followers. Nino’s work was highlighted during the Weekly Meeting on Monday. I would also like to give a special shout-out to Jobava from Romania who did a great job taking notes during the whole weekend. Having a dedicated person in charge of the note taking was instrumental to making everyone’s time productive. Jobava managed to capture a lot of details and insights. I often looked into his notes when writing this blog post. Hvala, Nino and Jobava!
The hackathon was an astounding success. It was diverse, educational and inspiring. A huge Thank you! to everyone who participated and helped organize it. I couldn’t be more excited for the future of localization at Mozilla!