Involving Mozilla copywriters and translation vendors in localization

Hi everyone,

Last year we announced some big changes coming to the project. These changes aimed to accomplish the following:

  • Cleaner, easier to navigate mozorg project in Pontoon,
  • Less content to translate,
  • Content localization priorities centered around helping users discover where to download your localizations of Firefox,
  • Fewer content changes, as more pages exposed in Pontoon will have longer lifespans.

Some of these changes have been less successful than others. We do feel like these changes have been helpful to prioritize the most important content to translate to make Firefox downloads more discoverable to users, and generally we’ve tried to avoid adding content that has a really short lifespan. Unfortunately, the amount of content hasn’t stabilized. That, combined with the fact that content on the site has a unique set of requirements, timelines, and workflows, there are clear challenges and an unacceptable amount of unpredictable, unnecessary pressure placed on volunteer communities to translate. In collaboration with the marketing team, we’ve tried many approaches to overcome these challenges and ease the demand on the l10n community over the years. Two years ago, we made the decision to classify content in specific categories and create standardized l10n processes and policies for each. This included outsourcing specific content types with challenging localization requirements to vendor partners. In order to address some of these challenges, we will experiment with adding mozorg content to the list of content types we outsource to our vetted vendor partner, Mother Tongue.

This will not be a sweeping change, and for most of you, you won’t even notice a difference in Pontoon. However, in the next week or so, a small set of communities will no longer see the mozorg project in their Pontoon dashboard. Content on mozorg for these locales will be covered by Mozilla staff and Mother Tongue. Staff and Mother Tongue linguists have been trained on Mozilla’s brand and l10n style guides and have access to terminology and translation memory resources to ensure they maintain consistency with what each community has contributed in the past.

Should there be errors, communities can report them in their Bugzilla component (using this template for individual errors and this template for batches of errors) and Mother Tongue & Mozilla staff will address them in their translation management system. I will update the localizer documentation to include this feedback loop and links to these bug templates. I will also reach out individually to community managers whose locales are included in this change.

Through the remainder of 2021, we will observe how this change impacts metrics related to active site sessions, download rates, and new Firefox profiles for these languages. We hope that by consistently producing more content and keeping it at a 100% localized status, Firefox’s search discoverability will improve, and we’ll see more users flock to your Firefox localizations. If this proves successful, we’ll likely roll this change out to more locales.

We’re happy to take your comments and questions about this phase of this mozorg project. Please feel free to share below. As always, we’re very grateful for the free time you spend with us to ensure that browser language is not a barrier to entry to the Open Web.



Jeff, can you clarify which locales will be affected?

Hey Selim, I can follow up with an answer to that question after I’ve reached out to those communities individually.

Just wanted to follow up here, now that everyone’s been notified. The locales are:

  • Arabic
  • Hindi
  • Indonesian
  • Japanese
  • Malay