In 2017, teams across Mozilla began using the OKR (Objective, Key Result) goal setting framework, including the l10n team. At the beginning of last year, we wrote a post about the OKR goals for l10n, particularly focusing on the impact of Firefox Quantum on l10n work during the year. Being very focused on supporting the Firefox Quantum release at the end of last year, our planning for this year began much later. While we may not have a Quantum-level release this year, we have a lot of reasons to be excited about l10n and many diverse opportunities for community to be involved!
Fluent migration in Firefox
We’ve talked about it for nearly a decade, but we’ve never been in a better position to migrate Firefox to the Fluent l10n system than we’re in right now. If you’re not yet familiar with Fluent, it is a run-time l10n system by Mozilla. Fluent enables us to do a lot of cool things, for example:
- Localizers can provide dynamic and more natural translations for UI strings,
- Fluent can substitute missing translations in a user’s language for a translation in another preferred non-English language (i.e., language fallback),
- Localization updates can be sent to users outside of the official release cycle (i.e., less time for bug fixes to ship).
Beginning with Preferences, Firefox will be migrated to Fluent. This is a dependency of a few other Firefox engineering projects and we’re excited to have the support of the Firefox team to accomplish this. With Fluent in place, we’ll also be able to add cool features like on-the-fly language switching to the browser (aka, multilingual Firefox). Expect to see the browser transform into a linguistically more dynamic product, more capable of meeting the needs of a multilingual global user base.
New Pontoon features
Pontoon’s translate view will receive its first full refresh in five years! Included in that refresh will be a localizeable UI, a rich editor for Fluent strings, workflows for a review/translate feedback loop, and (potentially) themes.
Additionally, Pontoon will see a better string organization system for Firefox. Using the string tiers concept from last year, we have classified strings as being high or low priority based on user visibility and target audience. With this in place, localizers will be able to make more consistent decisions about what to localize and what not to localize for Firefox and how to best spend their limited available time.
Finally, concerning l10n quality, Pontoon will incorporate compare-locales checks, allowing it to do QA checks on translations on-the-fly rather than waiting until they hit the repository. We will also add terminology management and suggestion features.
Centralized language resources
Last year, we made a lot of good progress on centralizing localization style guides and creating a basic terminology database (i.e., termbase). This year, we’re enlisting the help of the SUMO, MDN, and UX teams to create a process for identifying and defining new terms for the termbase and merging all language-specific style guides from all areas of Mozilla into one, central location. We’re also working with the Legal, Creative, and Product Management teams to define an updated policy for translating Mozilla brand and product names, storing data about this policy within the centralized termbase.
Continuous localization for more Mozilla projects
With the success of cross-channel for Firefox desktop and Fennec, we’re looking to expand continuous localization to more projects. The idea behind continuous localization is to unblock the string supply chain. In other words, source strings are made available to localize as quickly as possible, and target strings are used in projects as quickly as possible, creating a continuous “green light” status for source and target strings.
To do this, we need to centralize our localization infrastructure into one place. This means eliminating multiple, redundant dashboards as well as expanding compare-locales to run QA on all project types. This foundation will enable us to perform more automated tasks within the string supply chain and QA processes in the future.
Standardize l10n community roles
With the help of the Open Innovation team, we’re exploring how to standardize l10n community roles. Over the years, the lack of clarity in l10n community roles has led to a number of conflicts and problems, among them:
- Localizers placed in roles they didn’t ask to be in (e.g., leadership roles),
- Unclear or un-navigable project ownership or role advancement processes,
- Misaligned expectations between localizers and l10n-drivers about role-specific responsibilities,
- Unclear responsibility for feedback and mentorship of new contributors,
- Community Participation Guideline violations brought on by the stress of the problems listed above (e.g., arbitrary gatekeeping, hostile behavior, etc.).
We’ve initiated a pilot project to co-create l10n community roles with the community, starting with a subset of locales and expanding to larger sets over time. It’s critical to us to have the community’s buy-in, so we plan to involve localizers along the way.
Last, but not least, community workshops.
From 2014-2017, the l10n-drivers assumed responsibility for organizing localization sprints, hackathons, and workshops. We went from hyper-local meetups to large-scale meetups (in Berlin’s workshop last year we had 50+ localizers present). Feedback from the community last year taught us that the format of these workshops had grown stale and localizers desired to have more opportunities to self-organize their own meetups.
With that in mind, we’ve decided to remove ourselves from organizing these meetups this year while preserving the annual budget for these workshops. We’re working with the Mozilla Reps to define a unique process for core localizers to organize their own community meetups. The l10n budget would fund these meetups and the Mozilla Reps process would be used to moderate requests (moderated by l10n-drivers, not Mozilla Reps), make financial transactions, and ensure accountability for money spent. We do not yet have the process defined, but will publish that process in the coming weeks.
We also intend to organize some small, focused l10n meetups. These meetups will be organized around accomplishing a specific task with a small group of localizers. For example, one such meetup that we’re hoping to plan is to test prototypes of the new translate view UI in Pontoon. These meetups will be on an as-needed basis, meaning that we won’t be able to anticipate how many, when, or where these meetups will take place throughout the year. We will, however, make sure the wider community is aware of them as early as possible.
This is a big year for l10n as we work to centralize and automate more of the localization process. We’re very much looking forward to this year being the fulfillment of promises from years past. Thank you to all our community for your help. We’re looking forward to seeing what we can accomplish together as passionate, dedicated Mozillians.