Closed Bug 1694430 Opened 5 years ago Closed 4 years ago

[Website + Add-on][Firefox Relay] Please enable pontoon localization

Categories

(Mozilla Localizations :: Other, task)

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: groovecoder, Assigned: maxx)

Details

Firefox Relay has been live since July '20 and we would like to localize it.

Codebase is at https://github.com/mozilla/fx-private-relay

The website code is python + Django.

There is also an add-on codebase in the extension/ directory:

Our original Relay PRD is here, but it's out-dated. :(

Relay will be part of a new offering that will likely include other Privacy & Security tools that are already localized (e.g., Monitor and VPN) so we would like to localize Relay in order to have as much language parity as we can.

Any movement on this? We're looking at combining and integrating Monitor and/or VPN in some combination with Relay, so we'd like to have all 3 of them translated into a bunch of the same languages if possible.

Hey Luke, unfortunately, we've met our bandwidth and can't prioritize supporting Relay until after May. After a cursory look at the repo, there's quite a bit of work the Relay team will have to do to make it possible to localize the project. Here are some of the things that need to be scoped and added to your roadmap:

  1. Strings need to be externalized into one of the string resource files that Pontoon supports. You may need to use different file types for the add-on (likely .json) vs the django app (maybe using django-ftl, I think that's what mozilla.org is using).
  2. The repo needs to be structured to have a parent resource directory and one child directory per locale. That's how Pontoon knows where to pull content from and where to push translated content to. See the Facebook Container add-on repo for an example.
  3. It should be possible for localizers to perform manual l10n testing the add-on and the site. For the add-on, having a pre-release nightly would do, and the site would need an accessible staging server.
  4. Several locales will require support for right-to-left (RTL). This involves mirroring the extension/site design for RTL and ensuring that any text input fields support RTL and bidirectionality (e.g., cursor knows to go RTL for Arabic words, and knows to switch to LTR when English is inserted. This is especially common for brand names and proper nouns, as they're not transliterated from Latin script to Arabic script).

For the time being, this is what comes to mind as next steps. Happy to try to answer any questions to help you scope out these requirements to add this to the Relay roadmap.

Thanks, this is a great list to work on. We've got experience doing all of these various pieces for Monitor & Facebook Container already, so we should be able to use our knowledge from those code-bases here too. We'll aim to have these done well before May.

Jeff – This road map is great!

I wanted to share a progress update for this feature — I stubbed out adding django-ftl into the Relay django app.

This is definitely only a first step. I would like to consult with someone from the l10n team on how the FTL files should be structured. Specifically, Firefox Monitor's files are structured very differently than Bedrock(A few shared files, rather than a very page-by-page system).

Additionally, I'm not sure how to best to share FTL resources between the Django app and the add-on too (which has not been stubbed in this PR yet).

:CocoMo and :flod – I would love to get y'all's perspective on this first draft. May I please tag one of you in the PR for a quick review? I'm also happy to jump on a call to talk through everything.

Flags: needinfo?(francesco.lodolo)
Assignee: nobody → mcrawford
Flags: needinfo?(pmo)

A quick premise: unfortunately, as Jeff anticipated in comment 2, we're still not in a position where we can assign resources to Relay, or prioritize it. And I might not be the l10n PM assigned to it when we can finally triage this bug.

With that said, I think I can give provide a few pointers.

I wouldn't look at mozilla.org as a good structure for a smaller website, Monitor is a better example:

  • mozorg has 100+ files, 3k+ strings. Splitting content in smaller files, and grouping brand names, is basically a necessity.
  • mozorg needs to be able to know if a page is localized sufficiently to be enabled in production. That can only happen at scale if the strings are contained in a separate file for each page.
  • the amount of brand names on mozorg is potentially too large. In particular, combining different brand names — e.g. to obtain "Microsoft Edge" — should be avoided.

So, please don't copy over the branding file from mozilla.org. Start with one file for the whole website and define only the brands you really need as part of that file. If needed, you'll create a separate file later.

The other thing is that you might need two separate repositories/projects, since the add-on will use the native JSON file for localization, while the website uses Fluent. Also, for the add-on it makes only sense to enable locales that are actually available in Firefox (there's no locale switcher for add-ons), while for the website you have more freedom.

Flags: needinfo?(francesco.lodolo)

:flod - thanks for the info. Is there an example of a project that has a clean, easy, and productive separation of repositories for l10n files?

Flags: needinfo?(francesco.lodolo)

(In reply to Luke Crouch [:groovecoder] from comment #6)

:flod - thanks for the info. Is there an example of a project that has a clean, easy, and productive separation of repositories for l10n files?

You refer to separation of add-on and website in two separate repositories? In that case, not really, it's usually one or the other, not a mix that requires splitting everything.

It would basically be two separate projects (think the equivalent of Facebook Container and Monitor).

Flags: needinfo?(francesco.lodolo)

:flod - ah okay. That makes sense. I was thinking about a project that uses a different repository to separate their l10n files from the rest of the code.

But I think I see now - we need 2 separate repos: 1 for pontoon/fluent to look for JSON files for the add-on and 1 for pontoon/fluent to look for FTL files for the website.

Is there any way those could show up in the same project in pontoon? To help keeps translations of the add-on and website in closer sync.

Any way to share any messages between the JSON & FTL files in the cases where we have UI content that's shared between them?

Flags: needinfo?(francesco.lodolo)

(In reply to Luke Crouch [:groovecoder] from comment #8)

:flod - ah okay. That makes sense. I was thinking about a project that uses a different repository to separate their l10n files from the rest of the code.

We have plenty of those. VPN Client and Website use l10n repos separated from the code repo
https://github.com/mozilla-l10n/mozilla-vpn-website-l10n
https://github.com/mozilla-l10n/mozilla-vpn-client-l10n

Then you need to figure out how to move back content into the main repository (git submodule, scripts, or something else).

But I think I see now - we need 2 separate repos: 1 for pontoon/fluent to look for JSON files for the add-on and 1 for pontoon/fluent to look for FTL files for the website.

Is there any way those could show up in the same project in pontoon? To help keeps translations of the add-on and website in closer sync.

No, that's not possible.

Any way to share any messages between the JSON & FTL files in the cases where we have UI content that's shared between them?

No, Translation Memory is supposed to help for those cases. Also, the final output might be the same, but variables and markup might be different depending on format.

Flags: needinfo?(francesco.lodolo)

Following up on this – we have a PR ready to land for the Relay website that moves all English strings into a FTL file. We have also moved the Relay add-on into its own repo.

I tagged Peiying in the website PR and she specifically called out that "…since the project is not set up in Pontoon, nothing will be picked up there, so you can keep your work here". Per that comment, we are ready to merge this into main.

All that said — I'm wanting to proceed cautiously. Please let me know if we need to NOT merge in. I do not want to create any work for anyone, per Jeff's comment above.

Flags: needinfo?(pmo) → needinfo?(francesco.lodolo)

We have also moved the Relay add-on into its own repo.

I plan on adding the same Fluent-capabilities (but not added to Pontoon) to the add-on next week. Basically, getting everything READY for localization.

Confirmed! Push on to prod!

Flags: needinfo?(francesco.lodolo)

This project has not been triaged yet, please hold on until that happens, and it's clear who's assigned to what. Feel free to ping me for more details over Slack.

@Maxx, I will be taking the project and flod will be my backup. There are a lot to learn about from my perspective, especially FTL. Flod and I will go over the strings early next week and provide feedback if any. I will be your POC moving forward. Thank you for your patience.

(In reply to Peiying Mo [:CocoMo] from comment #14)

@Maxx, I will be taking the project and flod will be my backup. There are a lot to learn about from my perspective, especially FTL. Flod and I will go over the strings early next week and provide feedback if any. I will be your POC moving forward. Thank you for your patience.

Thanks, Peiying. Take all the time you need. We are going to hold on merging our PR until y'all have a chance to formally review. We don't want to make any extra work on you or your team!

Pretty sure this was completed.

Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.