Firefox L10N FAQs

This document includes a series of frequently asked questions regarding Firefox and localization, mostly targeted at developers, but useful for product managers and engineering program managers as well.

General

Who can I contact if I have more questions?

A Program Manager (L10N PM) is assigned to any Mozilla project that is localized through community. You can find this information in Pontoon for any project in the header section, and more information about the localization team is available in the Confluence page dedicated to Localization (available to Mozilla staff only).

Should I enable my feature only for English, or ship it in English for everyone?

Shipping a feature only for en-US is not great, since it creates confusion for users: features are described in SUMO articles or publicized in blog posts, but not available for more than 60% of Firefox user base.

Shipping a feature in English for everyone is not a good option either: as an English speaker, imagine starting your browser and finding a window in Chinese.

In the end, both options are a product decision, and the localization team can help assess the impact on users and community. How to ship a feature only to en-US users depends on several factors (technology, information available at the time the feature is loaded, etc.), and the best approach is to get in touch with the engineering part of the Localization team (aka “tech team”).

Builds and distribution

How can users get localized builds?

Unlike mobile products, where we ship multilingual builds by default and users can simply switch language from the app or OS settings (e.g. for iOS), for Firefox there are several ways to get a localized build, independently from the platform:

  • From mozilla.org it’s possible to download a localized build that includes a specific language (e.g. French) — for all versions of Firefox (Nightly, Developer Edition, Beta, Release, ESR). These are frequently referenced to as repacks, because this type of build is generated by unpacking the en-US build, injecting localized strings, and repackaging everything in a shippable format for each platform. For some locales, these builds also include a dictionary for spell checking, depending on the availability of a dictionary with suitable license.
  • On Beta, Release, and ESR users can also switch Firefox to another language from Settings, e.g. they download a build in English and then switch to French. Under the hood, this downloads and installs a language pack from addons.mozilla.org (AMO) for the requested language, and also installs dictionaries if they’re available for that locale.
    • Language packs are a specific type of extension that only includes localized strings, no additional code. They’re generated by the build system and uploaded to AMO via automation. Note that only official Mozilla language packs can be hosted on AMO.
    • The list of dictionaries is manually curated and stored in remote-settings.
  • On Release and ESR, users can also manually download language packs from AMO and set the preferred locale manually in about:config.

While it’s important to note that there’s no real multilingual package for Firefox — builds always include one locale, and more can be added using language packs — there are also platform specific distribution systems that work around this limit:

  • MSIX (Windows)
  • Flatpak (Linux)
  • Snap (Ubuntu Linux)

All available language packs are distributed as part of the package, but only a subset is installed based on the OS locale settings. All of these systems then rely on the the preference intl.locale.requested set to an empty string to automatically match the OS language.

These approaches allow to ship one package and support multiple languages, but there are known limitations (e.g. dictionaries are not included, and language packs cannot translate some parts of the UI).

Schedule and release cycle

I landed strings in mozilla-central, when are they going to be localized?

New string changes are extracted twice a day from gecko-dev (the git mirror of mozilla-central) into a repository called firefox-l10n-source, a unified repository that includes strings for all shipping versions of Firefox (nightly, beta, release). This repository is used as a buffer to avoid exposing potential issues to all locales working on Firefox.

Typically once or twice a week, the quarantined content (in the update branch) is pushed to the main branch which acts as the official repository, used by Pontoon as source reference. At this point, strings can be localized by the community.

Can I uplift a patch to Beta or Release?

While Nightly is always open for new strings, Beta and Release are string frozen, meaning that patches with new strings are normally not allowed to land.

Uplifts need to be evaluated case by case, but in general they should be avoided in the context of a 4-weeks release cycle. Possible alternatives are uplifting ad-hoc patches without string changes, or exposing the feature/change only to English users.

One more thing to consider is the timing of the uplift. The second part of the Beta cycle is completely frozen, meaning that we can’t take any updates to localization and ship it in that version. Anything uplifted close to the deadline, or after, will ship untranslated. For more details about the Beta timeline for l10n, see the Build system document.

I need to add new strings for version X: when is the deadline?

If version X is in Nightly, i.e. currently developed in mozilla-central, there is time to land until merge day, when the code moves from mozilla-central to mozilla-beta. Technically, the string freeze date is on the Friday before merge day, to account for possible back-outs, l10n reviews needed, etc.

The sooner you land content in mozilla-central, the higher will be the chances that the content will be localized in several languages before reaching release.

A webapp is available here with all the deadlines, including string freeze start, for current and future versions of Firefox (use the « and » near the title to change version).

Development

Where can I find guidelines for developers?

A document including plenty of best practices is available here, while specific information around Fluent is available in this document. In case of doubts, reach out to the Firefox L10N PM or localization team for clarifications.

How can I get my strings localized?

Strings need to be added to localization files in known locations within the mozilla-central tree. For all the technical details about these paths and the supported formats, see this document.

Once strings land in mozilla-central, they will be exposed for localization in Pontoon typically within a week or sooner.

Where can I find the localized strings?

All shipping versions of Firefox are built from a single GitHub repository called firefox-l10n, with a subdirectory for each locale.

Can I land content without exposing it for localization?

If your content is not stable, or you want to iterate quickly over it before exposing it for localization, it’s possible to land a string file outside of the known paths, and access it from the code.

For Fluent, you can follow examples like this patch, where the FTL file is stored outside of the localizable paths, and loaded as “preview”.

If you follow this approach, make sure to have a bug on file — or an explicit task in your roadmap — to expose this file to localization with sufficient lead time for translation before the targeted release.

Can I get content translated only in selected languages?

No, the existing infrastructure only allows to expose strings to all locales. If a feature is exposed for localization, it will get localized in all supported languages.

Can I restore an old string?

It’s always possible to restore an old string that was removed from code, as long as the text remains the same, and the string is used exactly in the same context.

It might also be possible to uplift the patch if the string is still available in the firefox-l10n-source repository. firefox-l10n acts as a single localization source for multiple builds, with a superset of strings from all supported versions of Firefox: nightly, beta, release, ESR.

Consider this example:

  • The original string landed in Firefox 85, and was removed later in Firefox 92.
  • The list of support versions in cross-channel includes: ESR91, 92, 93, 94.
  • The string is restored in Firefox 94.

The string will still be available in firefox-l10n-source until ESR91 becomes unsupported, since the string was removed after that release (in Firefox 92). This patch could be uplifted without creating any issue to localization (it would be a no-op).

If the string is not available anymore, this is effectively a new string, and must be treated as such.

Should I remove obsolete or unused strings?

Strings that are unused, or become obsolete as a consequence of code changes, should always be removed from the en-US files. Tools like Pontoon will remove them from localized files once these strings are not used in any supported version of Firefox (see the previous question for more details).

It might seem useful to keep them around — we could use them again later and it would spare localizers some time — but there’s no guarantee that the new context and usage will be exactly the same. Removing them also prevents new locales, or locales that fell behind over time, from working on translations that will never be used.

How can I test a different locale?

The answer depends on the version you want to test.

Official builds:

  • On Beta and Release, you can switch the UI language directly from Firefox settings. You can also download localized builds from mozilla.org.
  • On Nightly and Developer Edition this feature is disabled, since language packs are not reliable. You can still manually install language packs for the version you’re using directly from FTP (Nightly, DevEdition changing the build in the URL), then enable the language switcher by setting intl.multilingual.enabled to True in about:config.

Local builds:

  • If you’re using Fluent, you can test your feature for localizability issues, like layout constraints or hardcoded content, using pseudolocales.
  • If you’re building locally, you can try installing the latest language pack for Nightly (it might not work as expected if you’re adding new strings, or break after an update). Language packs are stored on FTP inside the linux-x86_64/xpi/ folder for daily builds, or latest-mozilla-central-l10n.
  • You can build directly in a different locale (no support for artifact builds).
  • It’s possible to add specific l10n repacks to a Try Server push. For example, to add French: select Add new Jobs, then select the fr locale in L10n-Rpk. Once the job is completed, builds will be available as artifacts under L10n (BsX), where X changes depending on the locale.

Translation completion and community

Is my feature going to be localized in language X before launch?

Each community will localize new content at different times: some locales will have a complete localization within hours, while others might take weeks or months. Our continuous localization infrastructure allows us to release Firefox with incomplete translations falling back on a backup locale in case of missing strings or errors.

Given that localization is managed by community volunteers, there is no SLA or guarantee that a product will be completely localized before launch. For more information, see this page on Confluence (available to Mozilla staff only).

How do I communicate with localizers about my feature or patch?

If there is some specific information that you want to convey to localizers, like testing instructions or particular issues to look out for, get in touch with the L10N PM for Firefox Desktop. They will help you identify the best channel and way to relay this information.

I see pending suggestions in Pontoon, how can I get them approved?

Standard users in Pontoon can only provide suggestions: these translations are visible in Pontoon, but don’t get committed to repositories or ship in products.

For each locale there are translators and managers that can review these suggestions, and eventually approve them. The timing depends on each locale’s workflow.

How can I check if my feature is localized?

There’s no easy way to see this information in Pontoon. If all the strings are stored in a single file, only used for that feature, or you have a detailed list of all the strings used, it’s possible to extract this data manually. Get in touch with the Firefox L10N PM for more information.

How can I see all translations available for a specific string?

Pontoon doesn’t allow to see all translations for a specific string, but you can use Transvision for it:

  • Search for the string (by ID or text), making sure that Firefox is selected as repository.
  • In the results, click on the green all locales tag close a string to see all available translations. Results are also available via API (linked at the bottom of the page).