mozilla/fxa-content-server-l10n: the string repository behind Firefox Accounts
translated strings for Firefox accounts website
At a glance
- What is it?
- This repository holds the Fluent strings that every Firefox Accounts server renders, and it is not meant to be edited by hand. Here is how the extraction, Pontoon and deploy loop fits together, and who should stay away from it.
- Who is it for?
- Adopt this repository only if you are localizing Firefox Accounts content through Pontoon; the README states that the string files are generated and pushed by Pontoon, so direct edits will be overwritten by the next extraction or sync. Do not clone it as a general Fluent example or as a translation memory for an unrelated product, because the locale/ tree is scoped to FxA servers and the lint tooling is wired to that layout.
- Can I use it commercially?
- Yes, with conditions. MPL-2.0 is a weak copyleft licence: you can use it inside commercial and closed-source software, but if you distribute changes to its own files, you must publish those changes under the same licence.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly Fluent, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 29, 2026, and from our analysis. They are not legal advice.
Editorial analysis
What fxa-content-server-l10n actually holds
Firefox Accounts is not one service. The README lists fxa-content-server, fxa-auth-server and other FxA servers, and says this repository contains "all translated/translatable strings for all of the FxA servers". That is the scope: one repository feeding several deployables rather than one website. The strings are written in Fluent, Mozilla's localization file format, and they live under the top-level locale/ directory. The README abbreviates this repository as L10N and the upstream application repositories as SOURCE, a distinction worth keeping in mind because almost every workflow here moves text from SOURCE into L10N and never the other way around. If you arrived looking for application code, templates, or the account flows themselves, this is the wrong repository; it contains the words, not the pages. The audience is narrow by design: Mozilla's localization team, Pontoon contributors working on the Firefox Accounts project, and release engineers who need to know which string revision a deploy picked up.
How strings travel from SOURCE to a deployed page
The pipeline has four moving parts, and the README describes each one. First, a cron job runs "on a regular basis (currently once a week)" and extracts strings from SOURCE, opening a pull request against this repository. That workflow file is .github/workflows/l10n_extract.yaml, and the README notes the same process can be triggered manually from the Actions page. Second, a member of the localization team reviews the PR for strings that would be confusing to translate, and merges it if nothing is wrong. Third, Pontoon sees the merged changes and translators work in the Pontoon interface at pontoon.mozilla.org/projects/firefox-accounts/. Fourth, and this is the part people miss, "a new copy of this repository is checked out every time a deploy happens so deployed sites have the latest strings". There is no build artifact or versioned string bundle in the flow. The deploy reads the repository as it stands, which means a merge that lands between two deploys changes the next deploy's output without any release note. The README also says Pontoon "pushes changes anytime it likes", so commits can appear outside the weekly extraction cadence.
Installing the repository and running the l10n lint
There is no install step for using the strings, because nothing here is published as a package. The package.json sets "version": "0.0.0" and describes the contents as "l10n assets for Firefox Accounts", so the only local workflow the repository defines is its own lint check. Clone it and install the dev dependencies from package.json, which are grunt, grunt-l10n-lint, load-grunt-tasks and time-grunt.
git clone https://github.com/mozilla/fxa-content-server-l10n.git
cd fxa-content-server-l10n
npm installThe package.json defines exactly one script, and it is the same command the CI test workflow runs.
npm testThat resolves to grunt l10n-lint. What you should see is the linter walking the locale/ tree and reporting problems in the Fluent files, such as malformed messages or duplicate identifiers. The README's badge table points at two additional linters hosted in a separate repository, mozilla-l10n/mozl10n-linter, with workflows named fxa.yaml and fxa_gettext.yaml, so a clean local run does not mean the project's own CI will be clean. The Gruntfile.js at the repository root is what wires the task together, and grunttasks/ holds the task definitions.
Why you should not edit locale/ by hand
The README is explicit that string localization is managed in Pontoon, and that Pontoon pushes changes on its own schedule. A pull request that edits a Fluent file directly competes with that writer. Even if it merges, the next Pontoon push or the next weekly extraction can overwrite it, and the extraction PR is generated from SOURCE rather than from your branch, so it has no knowledge of your change. The second limitation is cadence. A string added to SOURCE on Monday may not reach this repository until the weekly extraction runs, then waits for a human review, then waits for translators, then waits for a deploy to check out a fresh copy. Anyone treating this repository as a live translation API will be reading text that is up to several steps behind the source. The third case where this is the wrong tool: if you need translations for a product that is not Firefox Accounts, the locale/ tree is scoped to FxA servers and carries no reusable general-purpose Fluent corpus. The README does not document rollback for a bad string merge, and it does not describe how to pin a deploy to a specific string revision.
Compared with shipping translations inside the application repository
The obvious alternative is to keep the Fluent files next to the code that uses them, in the fxa-content-server and fxa-auth-server repositories, and let translators open pull requests there. That approach removes the weekly extraction job and the review step entirely: a string change and its translation travel in one commit, and the deploy automatically gets a consistent pair. The cost is that translators need to work inside application repositories, and each FxA server would carry its own locale/ directory, duplicating any string shared between servers. This repository takes the opposite trade: one central locale/ tree for every FxA server, a dedicated Pontoon project, and a lint pipeline that can check all locales in one place, paid for with an extraction delay and a merge gate. Neither approach is unusual. The deciding factor is whether the strings are shared across deployables, which in FxA they are.
Maintenance, licence and upgrade cost
The repository is not archived, and no last push date is given, so there is no basis for describing how frequently it changes. What can be said is structural: the maintenance burden falls on Mozilla's localization team, who review the weekly extraction PR, and on Pontoon contributors, who supply the translations themselves. For a downstream consumer the upgrade cost is close to zero, because there is no version to bump. The package.json version is 0.0.0 and the README describes no release process, so you take the default branch or a specific commit. That also means there is no changelog to read before a deploy picks up new strings. The licence is MPL-2.0, declared in package.json and in the LICENSE file at the repository root. MPL-2.0 is a file-level copyleft licence, which in practice means modifications to the licensed files stay under MPL-2.0 while larger works that combine them can be licensed differently. Translation contributions arriving through Pontoon carry their own contributor terms, which this repository's README does not restate. Treat that as something to confirm with Mozilla rather than as legal advice.
Editorial conclusion
Adopt this repository only if you are localizing Firefox Accounts content through Pontoon; the README states that the string files are generated and pushed by Pontoon, so direct edits will be overwritten by the next extraction or sync. Do not clone it as a general Fluent example or as a translation memory for an unrelated product, because the locale/ tree is scoped to FxA servers and the lint tooling is wired to that layout. Before relying on it, check the .github/workflows/l10n_extract.yaml schedule and the Gruntfile.js l10n-lint task, since those two files define when strings arrive and what the repository will reject.
Frequently asked questions
Can I edit the Fluent files in mozilla/fxa-content-server-l10n directly?
The README states that string localization is managed in Pontoon and that Pontoon pushes changes whenever it likes, so direct edits compete with that writer and can be overwritten. The documented path is to find your locale on Pontoon under Firefox Accounts and submit translations there.
How often do new strings appear in mozilla/fxa-content-server-l10n?
The README describes a cron job that runs currently once a week, extracting strings from the FxA repositories and opening a pull request that a localization team member reviews before merging. The same extraction can also be triggered manually from the GitHub Actions workflow at .github/workflows/l10n_extract.yaml.
Does mozilla/fxa-content-server-l10n cover more than the content server?
Yes. The README says the repository contains all translated and translatable strings for all of the FxA servers, naming fxa-content-server and fxa-auth-server as examples, and the strings live under the locale/ directory.
What does npm test run in mozilla/fxa-content-server-l10n?
The package.json defines test as grunt l10n-lint, so npm test runs the Grunt-based localization linter over the locale/ tree. The README's badge table also links to two additional linters in the mozilla-l10n/mozl10n-linter repository.
Is mozilla/fxa-content-server-l10n licensed for reuse?
The repository is licensed under MPL-2.0, declared in package.json and present as the LICENSE file at the repository root. The README does not restate the contributor terms that apply to translations submitted through Pontoon.