Fix MNTOR-1795 - Add ADR for L10N workflow updates (#3097)

* Fix MNTOR-1795 - Add ADR for L10N workflow updates

* Add support images

* Add revised doc

* Adjust last updated date

* Update docs/adr/0006-localization-workflow.md

Co-authored-by: Francesco Lodolo <flodolo@mozilla.com>

* Update docs/adr/0006-localization-workflow.md

Co-authored-by: Francesco Lodolo <flodolo@mozilla.com>

* Update docs/adr/0006-localization-workflow.md

Co-authored-by: Francesco Lodolo <flodolo@mozilla.com>

* Update docs/adr/0006-localization-workflow.md

Co-authored-by: Francesco Lodolo <flodolo@mozilla.com>

* Update docs/adr/0006-localization-workflow.md

Co-authored-by: Francesco Lodolo <flodolo@mozilla.com>

* Update docs/adr/0006-localization-workflow.md

Co-authored-by: Francesco Lodolo <flodolo@mozilla.com>

* Code review revisions

* Fix spelling and punctuation

* Update status/last edited

---------

Co-authored-by: Kaitlyn Andres <kandres@mozilla.com>
Co-authored-by: Francesco Lodolo <flodolo@mozilla.com>
Co-authored-by: Francesco Lodolo <flod@lodolo.net>

docs/adr/0006-localization-workflow.md

@@ -0,0 +1,75 @@
+# L10N Workflow
+
+- Status: Accepted
+- Deciders: Monitor Team, L10N Team
+- Date: 2023-07-11
+
+Technical Story: [MNTOR-1795](https://mozilla-hub.atlassian.net/browse/MNTOR-1795)
+
+## Context and Problem Statement
+
+The current L10N workflow is a complex, multiple manual-step process to sync strings between two branches. This process is error-prone. Because of its lack of automation, it also often does not give the L10N team enough time to localize strings.
+
+## Decision Drivers
+
+- With the React refactor, this is a good time to revisit our processes, and determine what works the best for everyone.
+  - This is also a chance to better align with other Mozilla projects.
+
+## Considered Options
+
+- Separate Repo / git Submodules (Relay)
+- Separate Repo / Automated Syncing
+- Leave as-is (Dedicated branch on repo)
+
+## Decision Outcome
+
+Separate Repo / Automated Syncing because is has the best experience (that process/security allows) for both developers and localizers.
+
+Final process is an automated pull request workflow. The automation runs once a day, and creates a PR that needs to be manually reviewed.
+
+_See [this document](https://docs.google.com/document/d/12dRW85DNZpljmoS-U9KrZqV1nBDrT2g8WTpvTAM0HgY/edit?usp=sharing) for additional details on why complete automation is not currently possible._
+
+## Pros and Cons of the Options <!-- optional -->
+
+### Separate Repo / git Submodules (Relay)
+
+Instead of having Pontoon read and write translations from a separate branch, Relay uses a separate l10n repository, which is then imported as a git submodule in the main repository. [A GitHub action](https://github.com/mozilla/fx-private-relay/blob/main/.github/workflows/l10n-sync.yml) is used to automatically update the submodule revision once a day.
+
+- Bad, git submodules are complex and have led to complex merge conflict issues in the past.
+- Bad, The developer cannot add new English strings to the repository, they need to be added to the l10n repository.
+  - This led the Relay team to create a [pendingTranslations.ftl](https://github.com/mozilla/fx-private-relay/blob/main/frontend/pendingTranslations.ftl) file to fill this gap. These strings are not tracked by L10N team and this files contents should constantly be removed/blank.
+- Bad, Adding new strings to the l10n repository is a manual process (pull request).
+
+### Separate Repo / Semi-automated Syncing
+
+The proposal is to use a separate l10n repository instead of a separate branch, then use automation to sync only the relevant files between the two repositories instead of a git submodule.
+
+_For additional sensitive considerations, see [this document](https://docs.google.com/document/d/12dRW85DNZpljmoS-U9KrZqV1nBDrT2g8WTpvTAM0HgY/edit?usp=sharing)_
+
+- Good, There are no changes for development compared to the existing workflow.
+- Good, This workflow doesn’t block developers from landing code in the main branch as part of code pull requests.
+- Good, It also allows queuing multiple changes before exposing them for localization, since strings are exposed through a pull request, which is manually reviewed by the localization EPM.
+- Good, There is no need to have a separate [localization review instance](https://monitor-localization.herokuapp.com/) for localizers.
+
+### Leave as-is (Dedicated branch on repo)
+
+Currently, all new translations are committed to the `localization` branch via Pontoon. To expose new English strings for localization, the updated English (en) FTL file needs to be added in this branch (manually).
+
+- Good, The same branch is also used to publish a [special instance of Monitor](https://monitor-localization.herokuapp.com/) for localization for localizers to review.
+- Bad, Pontoon commits every 10 minutes, and once per locale, polluting the repository’s history.
+- Bad, Pontoon needs write access to the target branch, it doesn’t support a pull request workflow. (Must be excluded from branch protection rules).
+- Good, Developers can land content and code without exposing it immediately for localization.
+- Bad, Since the localization branch is used also to deploy a separate instance, it needs to periodically be synced with main to import new code.
+- Bad, The sync between localization and main is completely manual, easy to forget, and can lead to errors (merge conflicts).
+
+## Links <!-- optional -->
+
+- [Full proposal from @flodolo](https://docs.google.com/document/d/1vc2TV9iMHY8lpDDd9aJUYAvhu-Ms1RcZBG80LqqDH0E/edit?usp=sharing)
+
+## Images
+
+Monitor workflow proposal
+![monitor-workflow-proposal](/docs/adr/images/0006-localization-workflow/monitor-workflow-proposal.png)
+
+Current Monitor workflow
+![monitor-workflow](/docs/adr/images/0006-localization-workflow/monitor-workflow.png)