1605216 - Track Fennec and Fenix locale parity

Status: RESOLVED WONTFIX

(Mozilla Localizations :: Other, task)

Description

[Delphine Lebédel [:delphine - Use needinfo]]

Mobile Product and EPMs have expressed interest in gaining better visibility into Fennec and Fenix locale parity, given the planned migration work.

The main interest is in knowing:

• which locales are currently shipping on Fenix, vs Fennec (maemo-locales).
• the current status of the Fenix locales (both shipping and not shipping), in terms of localization completion

I will let Betty chime in if there are any other aspects to this that we could help with.

Comment 1

[Axel Hecht [:Pike]]

There's a few caveats here:

Fennec l10n status:

We only have limited visibility into the translation status of Fennec at this point. Given it's shipping on ESR, and we don't have dedicated ESR dashboards, we only know so much about what the actual status is.

Fenix l10n status:

This is a composite state of the following:

Fenix l10n on master. We don't have any dashboards tracking what's actually on master in Fenix. We don't have a display on Pontoon for just Fenix right now, either.

Android Components as they were when the release was cut that's currently in m-m/fenix. That can be easily a week old.

GeckoView translation status at the point it shipped, as included in Fenix. I have no grip on GeckoView myself, I filed bug 1605358 on behalf of the mobile team to get a translation effort figured out for GeckoView.

Technical summary:

Space-time is involved. If the resulting data is OK to be off by a couple of weeks, we can probably use current snapshots of data to provide translation status. If we need detailed and precise insights, we'll not only need to track the translation status of the various release bits, but also change the data as Fenix updates its dependencies.

There might be ways to do that process in a way that keeps track of l10n stati, involving release automation. Not sure if that's realistic, nor realistic by when.

Alternatively, there's probably manual ways to figure out what we're shipping, what l10n stati that had, and then put that into spreadsheets or so. This holds true for the state of Fenix to the granularity we want on ESR 68, as well as for Fenix, composed of Fenix, GeckoView, Android Components.

Comment 2

[Jeff Beatty [:gueroJeff]]

(In reply to Axel Hecht [:Pike] from comment #1)

There's a few caveats here:

Fennec l10n status:

We only have limited visibility into the translation status of Fennec at this point. Given it's shipping on ESR, and we don't have dedicated ESR dashboards, we only know so much about what the actual status is.

I don't think we need this bit, luckily.

Fenix l10n status:

This is a composite state of the following:

Fenix l10n on master. We don't have any dashboards tracking what's actually on master in Fenix. We don't have a display on Pontoon for just Fenix right now, either.

Could you describe this more? I know we talked about it, but I don't think I can describe the interpretation of what we actually see in https://pontoon.mozilla.org/projects/android-l10n/tags/fenix/ , but let me take a stab at it anyway:

I know there are effectively two string totals in the dashboard: some locales have 671 strings, others have 175. The green status bar and completion % is misleading due to this discrepancy. Could you remind me where the 175 number comes from?

Comment 3

[Axel Hecht [:Pike]]

175 are locales that are not enabled on Fenix.

Tags are tags are tags. Here's what happens: Our project tags contain the project strings.xml file, as well as the android-components files, if needed. Which means that any locale that has one project with a-c is shown on all projects tag pages. So, nn-NO is only enabled on FxR, and on a-c as that's needed for FxR. And thus, if you look at https://pontoon.mozilla.org/nn-NO/android-l10n/tags/, it shows all tags that include a-c, notably Fenix, Reality, and Lockwise.

This behavior could be useful in other scenarios where we'd use tags, I guess. Though I can't state one ad-hoc.

Comment 4

[Jeff Beatty [:gueroJeff]]

Thanks @Pike.

Alternatively, there's probably manual ways to figure out what we're shipping, what l10n stati that had, and then put that into spreadsheets or so.
This holds true for the state of Fenix to the granularity we want on ESR 68, as well as for Fenix, composed of Fenix, GeckoView, Android
Components.

It sounds like this is the short-term solution to pursue. How would Fenix dev or release automation need to adjust in order to make it more feasible to create a precise, real-time Fenix dashboard? Is there specific metadata they could generate to make those moving targets more easily identifiable?

Comment 5

[Axel Hecht [:Pike]]

(In reply to Jeff Beatty [:gueroJeff] from comment #4)

How would Fenix dev or release automation need to adjust in order to make it more feasible to create a precise, real-time Fenix dashboard? Is there specific metadata they could generate to make those moving targets more easily identifiable?

That's probably a couple of release engineers, depending on the data paths. It would start with running compare-locales as part of the release flows to generate a json asset with the translation state, and then "somehow" carry that forward.

Comment 6

[Francesco Lodolo [:flod]]

Delphine, what's the status of this bug?

Comment 7

[Delphine Lebédel [:delphine - Use needinfo]]

We can close this, thanks for flagging!