How Mozilla Ships Firefox Accounts Translations Through a String Repository

What This Repository Actually Holds

The name says content server l10n, but the README is explicit: this repo contains translated and translatable strings for all FxA servers, not just the content server. That includes fxa-content-server and fxa-auth-server, among others. The repository is abbreviated as L10N, while the main codebase is SOURCE. Every string that appears in the Firefox Accounts website or its backend services is expected to live here eventually. The primary language is Fluent, which is Mozilla's translation format, but the repo also tracks gettext strings, as indicated by the separate gettext linter workflow. This is not a code repository in the usual sense. It is a translation asset store that sits between the source code and the localization platform.

The Weekly Extraction Pipeline

The flow is automated but not continuous. Once a week, a cron job runs a GitHub Actions workflow called l10n_extract. That job extracts all strings from SOURCE and opens a pull request to merge them into L10N. A human from the localization team reviews that PR. The review is not a formality: the README says the reviewer looks for strings that are confusing to localize. If nothing looks problematic, the PR is merged. Only after that merge does Pontoon see the new strings and allow translators to work on them. This means there is a built-in delay between a developer adding a string in the source code and that string being available for translation. The delay is at least the time until the next weekly cron run, plus review time. If a string is urgent, the extraction can be triggered manually from the Actions tab, but that requires someone to remember to do it.

How Pontoon Fits Into the Workflow

Pontoon is Mozilla's web-based localization tool. The README points to a specific Pontoon project for Firefox Accounts. Translators do not submit translations via pull requests to this repository. They use Pontoon's interface. Pontoon then pushes changes back to L10N, and the README says it does so anytime it likes. That phrasing suggests the push is event-driven rather than scheduled. The repository is the passive recipient of two directions of data: incoming strings from SOURCE via the weekly PR, and outgoing translations from Pontoon. This separation keeps translators away from GitHub mechanics, which is a deliberate choice. It also means the repository's commit history is a mix of automated extraction merges and Pontoon pushes, not hand-written commits.

What Happens at Deploy Time

The README describes a specific deployment behavior: a fresh copy of this repository is checked out every time a deploy happens. That guarantees deployed sites use the latest strings that have been merged into L10N. There is no build step that embeds translations into the main source bundle at compile time, at least not as described here. Instead, the translation files are pulled alongside the code. This has a practical consequence: if a translation is merged into L10N after a deploy, it will not appear on the live site until the next deploy. The cadence of deploys is not specified, so the freshness of user-facing strings depends on how often the FxA team ships. For a service that handles account-related emails and pages, stale strings could mean users see untranslated or outdated text for days.

Getting Involved as a Translator

If you want to contribute translations, the README gives a clear path: find your locale on the Pontoon project page for Firefox Accounts. The instructions for submitting translations live on Pontoon, not in this repository. You do not need to clone this repo or open a pull request to add a translation. That lowers the barrier for non-technical contributors, which is a sensible design for a large volunteer community. However, it also means that as a translator you have no direct visibility into whether your translation has been merged into L10N and when it will reach production, unless you track the repository's commits. The README does not explain how to check the status of a specific translation, so you would have to rely on Pontoon's own UI for that.

The Linter Workflows and Quality Checks

The README includes a table with two linter workflows. One is a general L10n Linter, and the other is a gettext-specific linter. Both run under the mozilla-l10n/mozl10n-linter repository's Actions, not under this repo's own Actions. That is an unusual setup: the quality checks are hosted elsewhere, which means contributors to this repo may not see lint results directly in their PRs unless they know to look at that external workflow. The test workflow in this repo runs its own tests, but the README does not specify what those tests cover. The presence of both Fluent and gettext linters suggests the repository supports two translation formats, which can be a source of inconsistency if a string is only updated in one format. The README does not explain how the two formats are kept in sync, which is a gap in the documentation.

Maintenance and License Considerations

The repository is licensed under MPL-2.0, the Mozilla Public License. That means the translation files are open source and can be reused, but you should be aware that the strings themselves are tied to Mozilla's product. The maintenance cost is low for a reader: the only regular activity is the weekly cron and the manual review. But the review step is a bottleneck. If the localization team is busy, a PR with confusing strings could sit for days, delaying translations. The repository is not archived, and the default branch is main, but the last push date is unknown. There are no recent releases, which is consistent with a repository that never tags versions. It is a living asset, not a versioned product. For someone adopting the workflow, the key cost is not the code but the process: you need a Pontoon instance, a cron job, and a human reviewer to make this pattern work.

Alternatives and When This Pattern Is the Wrong Fit

A common alternative is to keep translations directly in the source repository, as many projects do with Fluent files in the same tree. That eliminates the need for a separate sync step and the weekly delay. For example, a small project could use Fluent's built-in tooling to extract strings and let translators submit PRs to the same repo. The trade-off is that you lose the separation between code changes and translation updates, which can clutter code reviews. Another alternative is a continuous localization service like Crowdin or Transifex, which push and pull strings on a schedule or via webhooks. These services often have their own review workflows, but they are external dependencies. The Mozilla approach is more manual and Mozilla-specific, tied to Pontoon. If you do not use Pontoon, this repository is not directly useful. It is also the wrong tool if your project needs real-time translation updates, because the weekly cron and deploy-time checkout introduce latency.

Editorial conclusion

Adopt this repository if you are a Mozilla localization contributor or a developer deploying Firefox Accounts and need to track the source of translated strings. Do not use it as a template for a standalone l10n pipeline without adapting it to your own deployment cadence, because it relies on a weekly cron and manual reviews that may not suit faster release cycles. Before relying on it, verify that the latest extraction PR has been merged and that the deploy process in your environment checks out a fresh copy, as the README indicates this is how deployed sites get current strings. The repository is MPL-2.0 licensed, so you can reuse the workflow concepts, but the actual strings belong to Mozilla's localization community.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. README
4. Releases