Update Firefox desktop pages post GitHub migration (#284)

* Update Firefox desktop pages post GitHub migration

---------

Co-authored-by: Francesco Lodolo <[email protected]>

src/localization/making_string_changes.md

@@ -88,8 +88,8 @@ In this scenario, the only way to ensure that obsolete translations are ignored
 ### Firefox
 
 Things become a lot more complicated for Firefox:
-* Each localization is stored in a separate Mercurial repository.
-* The `en-US` locale is stored in the code repository (e.g. `mozilla-central`). That locale is used by the build system to build the US English version of Firefox, but it’s not used as source by the localization toolchain. In fact, in order to ship all versions of Firefox (Nightly, Beta, Developer Edition, Release, ESR) from a single l10n repository, we rely on a special [cross-channel repository](https://firefox-source-docs.mozilla.org/l10n/crosschannel/index.html) called `gecko-strings`, which includes all strings for all shipping versions of Firefox.
+* The `en-US` locale is stored in the code repository (e.g. `mozilla-central`). That locale is used by the build system to build the US English version of Firefox, but it’s not used as source by the localization toolchain. In fact, in order to ship all versions of Firefox (Nightly, Beta, Developer Edition, Release, ESR) from a single l10n repository, we rely on a special unified [repository](https://https://github.com/mozilla-l10n/firefox-l10n-source) in GitHub called `firefox-l10n-source`, which includes all strings for all shipping versions of Firefox.
+* Localizations are stored in a separate repository (`firefox-l10n`) from source strings.
 
 This is the scenario before the string change. Once again, although it already looks very busy, it’s a simplified high level view of the actual system.
 
@@ -99,7 +99,7 @@ And this is what happens if a string is changed without new ID:
 
 ![Firefox: change without new ID](../assets/images/localization/string_changes_firefox_change.png)
 
-* The string is changed in `mozilla-central`, and the en-US Nightly build will start using it. This change is reflected in `gecko-strings`, but doesn’t impact other builds (e.g. beta), because that’s not used by the build system.
+* The string is changed in `mozilla-central`, and the en-US Nightly build will start using it. This change is reflected in `firefox-l10n-source`, but doesn’t impact other builds (e.g. beta), because that’s not used by the build system.
 * As for the generic product, Pontoon reads the updated change, but doesn’t notify localizers or invalidate existing translations.
 
 In this scenario, simply removing existing translations from VCS isn’t possible, because we still need them to ship in older builds.

src/products/firefox_desktop/adding_nightly.md

@@ -16,12 +16,10 @@ Then file a new tracking bug using this [bug template](https://mzl.la/3vwVtub).
 
 Note that the tracking bug is filed under `Mozilla Localizations :: Other`, as creating the Bugzilla component is a step that will be performed when the locale is ready to move to Beta/Release. If the component for this locale is already available, the bug should to be moved directly there.
 
-To make it easier to track dependencies, also add the bug used to create the l10n-central repository (see [Adding a new locale to Pontoon](adding_pontoon.md)) as a dependency (`Depends on:` field) of the tracking bug.
-
 ## Verify content in l10n repository
 
 Before enabling the build, it’s a good idea to perform some basic checks:
-* Check `toolkit/global/intl.properties` ([en-US version](https://hg.mozilla.org/mozilla-central/file/default/toolkit/locales/en-US/chrome/global/intl.properties)) for evident mistakes.
+* Check `it/toolkit/chrome/global/intl.properties` ([it version](https://github.com/mozilla-l10n/firefox-l10n/blob/main/it/toolkit/chrome/global/intl.properties)) for evident mistakes.
 
 ## Add new locale to build configuration
 

src/products/firefox_desktop/adding_pontoon.md

@@ -1,7 +1,5 @@
 # Adding a new locale to Pontoon
 
 * If the locale is not [available](https://pontoon.mozilla.org/teams/) in Pontoon yet, [consult this document](../../tools/pontoon/adding_new_locale.md) for instructions on how to add it.
-* File a bug to create a new Mercurial repository in [l10n-central](https://hg.mozilla.org/l10n-central/) using [this bug template](https://mzl.la/3VxIZgs) (replace `%LOCALE_CODE%` with the actual locale code).
-* Push at least one change to the repository, otherwise Pontoon will not pick it up during sync. The safest change is to initialize the `toolkit/chrome/global/intl.properties` file with the correct values ([example](https://hg.mozilla.org/l10n-central/ppl/rev/b3fd0faf59b0b45b2cf30c01d85157beee2a0bd0)).
-
-Once the repository is available and contains at least one commit, the locale can be added to the Firefox project in Pontoon.
+* Enable the locale for Firefox from the [project admin interface](https://pontoon.mozilla.org/admin/projects/firefox/) by moving your locale from the Available column to the Localizable column.
+* Initialize the `toolkit/chrome/global/intl.properties` file with the correct values: ([example](https://github.com/mozilla-l10n/firefox-l10n/commit/a887bff12994779ea8e605f4abc1b240a287ccb9)).

src/products/firefox_desktop/build_system.md

@@ -4,12 +4,12 @@
 
 ## Overview
 
-Thanks to [cross-channel](https://firefox-source-docs.mozilla.org/l10n/crosschannel/index.html), we ship all versions of Firefox from a [single localization repository](https://hg.mozilla.org/l10n-central/), but each channel uses a different snapshot in time of that repository.
+Thanks to using a [single source for localization](https://firefox-source-docs.mozilla.org/l10n/singlel10nsource.html), we ship all versions of Firefox from a [single localization repository](https://github.com/mozilla-l10n/firefox-l10n).
 
- A job, called `l10n-bumper`, runs on Taskcluster every hour, and stores information on the l10n changesets to use for each build in a file called `l10n-changesets.json`:
-* For Nightly (`mozilla-central`), [l10n-changesets.json](https://hg.mozilla.org/mozilla-central/file/default/browser/locales/l10n-changesets.json) always uses the revision `default`, and it’s only updated when changing the locales available in the build.
-* Beta builds (`mozilla-beta`) still use the tip of the l10n repository, but the actual hash is stored in [l10n-changesets.json](https://hg.mozilla.org/releases/mozilla-beta/file/default/browser/locales/l10n-changesets.json) instead of `default`.
-* Before Release Candidate week, the `l10n-bumper` is [manually stopped](https://github.com/mozilla/build-relengdocs/blob/master/procedures/release-duty/merge-duty/merge_duty.rst#turn-off-beta-l10n-bumper-on-rc-day) on `mozilla-beta`. Since the configuration change lands only on `mozilla-beta`, the `l10n-bumper` will automatically restart at the beginning of the next cycle, when the standard configuration is uplifted from `mozilla-central`.
+A job, called `l10n-bumper`, runs on Taskcluster every hour, and stores information on which changeset (defined by the revision SHA of `firefox-l10n`) to use for each build in a file called `l10n-changesets.json`:
+* Nightly (`mozilla-central`) changeset: [l10n-changesets.json](https://hg.mozilla.org/mozilla-central/file/default/browser/locales/l10n-changesets.json). This always uses the latest revision of `main`.
+* Beta (`mozilla-beta`) changeset: [l10n-changesets.json](https://hg.mozilla.org/releases/mozilla-beta/file/default/browser/locales/l10n-changesets.json). This also uses the the latest revision of `main`, but it’s only updated twice a week.
+* Before Release Candidate week, the `mozilla-beta` tree is [closed](https://moz-releng-docs.readthedocs.io/en/latest/how-to/releaseduty/merge-duty/merge_duty.html#merge-beta-to-release). The `l10n-bumper` will restart at the beginning of the next cycle, when the `mozilla-beta` tree is [reopened](https://moz-releng-docs.readthedocs.io/en/latest/how-to/releaseduty/merge-duty/merge_duty.html#re-opening-the-tree-s).
 * When the Beta code is merged to Release, [l10n-changesets.json](https://hg.mozilla.org/releases/mozilla-release/file/default/browser/locales/l10n-changesets.json) moves together with the rest of the code to `mozilla-release`. That means that Release builds will use the same changesets as the last beta with the same version number, and any further change [requires code uplifts](#updating-release).
 
 ## Timeline and deadlines
@@ -30,4 +30,4 @@ When the code moves from `mozilla-beta` to `mozilla-release`, `l10n-changesets.j
 
 In case of severe issues affecting one or more locales, it’s still possible to manually update the shipping changesets. A patch needs to be provided for `l10n-changesets.json` in `mozilla-release` branch and approved for uplift by Release Drivers (see for example [this bug](https://bugzilla.mozilla.org/show_bug.cgi?id=1513259) and [associated patch](https://hg.mozilla.org/releases/mozilla-release/rev/308fd26a204e)). Note that a dot release is needed in order to ship the updated version to users. [This script](https://github.com/flodolo/scripts/blob/master/mozilla_l10n/validate_fx_changesets_uplift/fx_release_changesets.py) can be used to validate the updated JSON.
 
-The same process applies to ESR versions, as long as the associated esr repository is included in the [current version of cross-channel](https://hg.mozilla.org/mozilla-unified/file/tip/python/l10n/mozxchannel/__init__.py).
+The same process applies to ESR versions, as long as the associated esr repository is included among the [supported versions in firefox-l10n-source](https://github.com/mozilla-l10n/firefox-l10n-source/blob/main/.github/update-config.json#L2).

src/products/firefox_desktop/firefox_l10n_faqs.md

@@ -42,9 +42,9 @@ These approaches allow to ship one package and support multiple languages, but t
 
 ### I landed strings in mozilla-central, when are they going to be localized?
 
-New string changes are exported twice a day from mozilla-central into a repository called `gecko-strings-quarantine`, 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.
+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 content of the quarantine repository is pushed to the official repository, called `gecko-strings`, used by [Pontoon](https://pontoon.mozilla.org/projects/firefox/) as source reference. At this point, strings can be localized by community.
+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](https://pontoon.mozilla.org/projects/firefox/) as source reference. At this point, strings can be localized by the community.
 
 ### Can I uplift a patch to Beta or Release?
 
@@ -60,7 +60,7 @@ If version X is in Nightly, i.e. currently developed in mozilla-central, there i
 
 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](https://fx-trains.herokuapp.com/release/) with all the deadlines, including string freeze start, for current and future versions of Firefox (use the `«` and `»` near the title to change version).
+A webapp is [available here](https://whattrainisitnow.com/release/?version=release) 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
 
@@ -72,11 +72,11 @@ A document including plenty of best practices is [available here](../../localiza
 
 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](https://firefox-source-docs.mozilla.org/build/buildsystem/locales.html#exposing-strings).
 
-Once strings land in mozilla-central, they will be exposed for localization in Pontoon within a few days.
+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 Mercurial repository for each locale (`l10n-central`). Repositories are available [here](https://hg.mozilla.org/l10n-central/).
+All shipping versions of Firefox are built from a single GitHub repository called [firefox-l10n](https://github.com/mozilla-l10n/firefox-l10n), with a subdirectory for each locale.
 
 ### Can I land content without exposing it for localization?
 
@@ -94,14 +94,14 @@ No, the existing infrastructure only allows to expose strings to all locales. If
 
 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 [gecko-string repository](https://hg.mozilla.org/l10n/gecko-strings). `gecko-strings` is a repository with a [superset](https://firefox-source-docs.mozilla.org/l10n/crosschannel/index.html) of strings from all [supported versions](https://hg.mozilla.org/mozilla-unified/file/tip/python/l10n/mozxchannel/__init__.py#l31) of Firefox: nightly, beta, release, ESR.
+It might also be possible to uplift the patch if the string is still available in the [firefox-l10n-source](https://github.com/mozilla-l10n/firefox-l10n-source) repository. `firefox-l10n` acts as a single localization source for multiple builds, with a [superset](https://firefox-source-docs.mozilla.org/l10n/singlel10nsource.html) of strings from all [supported versions](https://github.com/mozilla-l10n/firefox-l10n-source/blob/main/.github/update-config.json#L2) 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 `gecko-strings` 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*).
+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](#can-i-uplift-a-patch-to-beta-or-release).
 
@@ -135,7 +135,7 @@ Given that localization is managed by community volunteers, there is no SLA or g
 
 ### 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](#who-can-i-contact-if-i-have-more-questions). They will help you identify the best channel and way to relay this information.
+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](#who-can-i-contact-if-i-have-more-questions). 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?