Closed Bug 1788818 Opened 3 years ago Closed 3 years ago

Make sure up-to-date country names are appearing in drop-down menus

Categories

(Release Engineering :: Applications: Shipit, defect)

defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: dnazer, Assigned: flod)

References

(Blocks 1 open bug)

Details

Some of our menus are showing an out-of-date name for North Macedonia. E.g. here: https://www.mozilla.org/en-US/products/vpn/invite/

At least on other menus on mozilla.org appears to be more up-to-date: see https://relay.firefox.com/premium/waitlist/ (which correctly list North Macedonia).

This suggests at least some of our public-facing menus are not being sourced with up-to-date data (possibly being sourced from here?: https://searchfox.org/mozilla-central/source/toolkit/locales/en-US/toolkit/intl/regionNames.ftl#152). I believe our preferred practice is to use CLDR data.

Here's a related Unicode bug about this issue: https://unicode-org.atlassian.net/browse/CLDR-11199 (and the corresponding GENC data: https://nsgreg.nga.mil/genc/view?i=291171)

See Also: → 1788851

I think product-details used to pull data from mozilla-central (language names, region names), but there's no trace of the scripts that used to do that.
https://github.com/mozilla-releng/product-details

One quick fix is to change the name for mk in the en-* locales. In general, I'm not a fan of having multiple lists in multiple places, because they tend to go out of sync very quickly.

I know there are some parts of the org pushing back against using CLDR, but I still think that's the right solution, because it's centralized and up to date (the Macedonia->North Macedonia change happened 3 years ago). In case, the fix could happen either in product-details or bedrock.

Cyrus, if it is indeed from product-details, is that something releng can update? thanks

Flags: needinfo?(cbond)

(In reply to Francesco Lodolo [:flod] from comment #1)

... there's no trace of the scripts that used to do that.
https://github.com/mozilla-releng/product-details

I think this is the script: https://github.com/mozilla-releng/ship-it-archived/blob/master/scripts/sync-and-check-l10n.py

Based on Hector's comment (thanks for digging up that script!), it seems shipit used to pull that data from m-c. It's unclear to me whether we should keep doing that (adjusting for new shipit and new location of regionNames.ftl), or switch to a different source?

Sorry all, when I opened this bug I'd misunderstood another thread and thought we'd made a decision to use CLDR data - I've removed that from the title. I didn't meant re-open that issue or make a decision for the company. [Edit to add: Happy to defer to subject matter experts like :flod on that]

I do think we need to make sure we are sourcing data for menus like this from a source that is accurate and up-to-date. Whether that is CLDR data or GENC data is fine - just so long as it's not some list on m-c that's three years out of date.

To wrap things up, since conversations happened a bit all over the place:

  • The agreement was to switch to CLDR data (from GENC), ideally using that data directly. That didn't change, the wiki page should be updated, and this process should probably have an owner (not engineering wise, more policy wise).
  • For now, the solution is to update the obsolete region names in m-c (done), and restore a script to pulls data from m-c into product-details.

That doesn't prevent us from switching both m-c and product-details to CLDR in the future.

Component: Release Automation: L10N → Applications: Shipit
QA Contact: aki → gabriel

We could do something between this and flod's script in the product-details worker. If we did, the locales would sync with the m-c data when the API is re-build from shipit on release days.

Flod's PR was merged to product-details and the vpn invite page now shows North Macedonia.

Assignee: nobody → francesco.lodolo
Status: NEW → RESOLVED
Closed: 3 years ago
Flags: needinfo?(cbond)
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.