1908460 - When selecting Japanese, MacOS users end up with the ja langpack, and not the ja-JP-mac langpack

Status: NEW

(Core :: Internationalization: Localization, defect, P3)

Description

[Eemeli Aro [:eemeli]]

Using a non-Japanese MacOS build, the about:preferences listing for UI languages provides only one option for Japanese, "日本語". Selecting this installs the ja langpack, rather than the ja-JP-mac langpack.

Similarly, the langpack listing page on AMO only lists one Japanese langpack, the ja one. From the link on bug 1450107, I was able to find this ja-JP-mac langpack, but its most recent version is 59.0.

Installing a repacked MacOS browser does provide the expected ja-JP-mac localization.

Based on bug 1810985 and bug 1812105, it looks like at least about two years ago we were building ja-JP-mac langpacks, but it's not clear if they're made available anywhere.

:willdurand, any ideas?

Comment 1

[Bryan Olsson [:bolsson]]

Confirming that the text being displayed when a langpack is downloaded is the ja locale text, while when downloaded from mozilla.org that the correct ja-JP-mac text is displaying (as long as a langpack isn't installed).

Comment 2

[Francesco Lodolo [:flod]]

(In reply to Eemeli Aro [:eemeli] from comment #0)

Based on bug 1810985 and bug 1812105, it looks like at least about two years ago we were building ja-JP-mac langpacks, but it's not clear if they're made available anywhere.

We are still building them (note the ja-JP-mac.xpi)
https://ftp.mozilla.org/pub/firefox/releases/128.0/mac/xpi/

At this point, I'm not sure if the logic in Settings ever accounted for ja-JP-mac (bug 1469696). An API call for fx59 to AMO only has one Japanese.

Comment 3

[William Durand [:willdurand]]

It doesn't look like we publish any listed versions of the ja-JP-mac langpack on AMO production. This page exists for me (with elevated privileges) but it has 0 listed versions: https://addons.mozilla.org/en-US/firefox/addon/japanese-langpack-mac/versions/. :eemeli's link in comment 0 was AMO stage (not prod!). The fact that we have no listed version is not unexpected according to https://searchfox.org/mozilla-central/rev/91f6127b6f591da4037821791c345147d9a575da/taskcluster/kinds/release-push-langpacks/kind.yml#33-34.

From what I can see on AMO (again, with privileges), we publish unlisted versions of this ja-JP-mac langpack every day. Since the AMO API (mentioned in comment 2) only returns listed add-ons, not having ja-JP-mac in the response makes sense. I am wondering what would happen if AMO were to return it, though.

Is there macOS-specific logic to use ja-JP-mac instead of ja in the code that calls AddonRepository.getAvailableLangpacks()?

Comment 4

[Eemeli Aro [:eemeli]]

(In reply to William Durand [:willdurand] from comment #3)

The fact that we have no listed version is not unexpected according to https://searchfox.org/mozilla-central/rev/91f6127b6f591da4037821791c345147d9a575da/taskcluster/kinds/release-push-langpacks/kind.yml#33-34.

Chasing down that link's changes leads to bug 1459050 from 2018 as the reason for ja-JP-mac langpacks not being public:

Due to the potential user confusion around finding "ja-JP-mac" language pack on AMO and in the future ideal of no longer needing a seperate language pack for OSX.

Flod, Bryan: I think this means that we ought to either reaffirm that the above rationalisation still makes sense (and close this as WONTFIX), or figure out how to make MacOS builds use the ja-JP-mac langpack. At this point, unifying the locales depends on porting our .properties strings to MF2; if we want to push for it, that could be done in 2025.

Is there macOS-specific logic to use ja-JP-mac instead of ja in the code that calls AddonRepository.getAvailableLangpacks()?

None that I can see, as selecting Japanese from the dropdown generated with this data provides the ja langpack. But adding a platform-dependent filter here for Japanese specifically should be pretty easy, if the server can provide the data -- or the platform could be encoded in the URL that's fetched.

Comment 5

[Francesco Lodolo [:flod]]

If I checked the data correctly, we have less than 10k installations of Japanese langpacks on macOS (vs ~300k reported from AMO). Note that I can't tell if they're actually in use, just installed, so the actual number of impacted users could be smaller.

History tells that we're not very good at making predictions on large changes — like completely dropping .properties — and that the corner cases will take a lot longer than the bulk of migration. So, I don't think we should treat "migrate to MF2" as a potential solution to this, also considering that the work required is much larger (migrating localized content, update tools used by the community, migrating existing users from ja-JP-mac builds).

So, the options for me are:

1. Keep the status quo, given the relatively small number of users affected.
2. Fix the code to serve ja-JP-mac langpacks to users on macOS.

Can we get a more precise estimate of how much work is required for option 2?

From what I can see on AMO (again, with privileges), we publish unlisted versions of this ja-JP-mac langpack every day. Since the AMO API (mentioned in comment 2) only returns listed add-ons, not having ja-JP-mac in the response makes sense. I am wondering what would happen if AMO were to return it, though.

Just to make sure I understand: we already have language packs available in the back-end, so there wouldn't be any work required for RelEng? How can we test what happens if we make the langpack listed?

Comment 6

[William Durand [:willdurand]]

I believe it's the other way around, we'd need RelEng to submit this langpack as listed, like the other ones. And from there, we could see how that would work. That being said, we probably still need to make a change in Firefox to pick ja-JP-mac when the platform is macOS.