1760013 - Migrate intl.properties prefs from .properties

Status: NEW

(Core :: Internationalization, task)

Description

[Eemeli Aro [:eemeli]]

Strings from the platform-specific files should be gathered together, using PLATFORM() to switch between the platforms if it turns out that the intl.ellipsis string should indeed have a platform dependency.

Comment 1

[Francesco Lodolo [:flod]]

This is a weird file, and more often than not, I think it shouldn't be a localizable file at all (it should be configurations centrally stored).
https://searchfox.org/mozilla-central/source/toolkit/locales/en-US/chrome/global/intl.properties

Is migration going to cope well with empty values?

Comment 2

[Eemeli Aro [:eemeli]]

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

This is a weird file, and more often than not, I think it shouldn't be a localizable file at all (it should be configurations centrally stored).
https://searchfox.org/mozilla-central/source/toolkit/locales/en-US/chrome/global/intl.properties

Is there an existing alternative for storing locale-specific data/configuration other than, well, localisation?

Is migration going to cope well with empty values?

Yes, an empty string maps to an empty string.

Comment 3

[Francesco Lodolo [:flod]]

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

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

This is a weird file, and more often than not, I think it shouldn't be a localizable file at all (it should be configurations centrally stored).
https://searchfox.org/mozilla-central/source/toolkit/locales/en-US/chrome/global/intl.properties

Is there an existing alternative for storing locale-specific data/configuration other than, well, localisation?

Search plugins and protocol handlers (bug 1733497) used to live in l10n repositories, they now live in mozilla-central. Some other data is implicitly centralized via CLDR (e.g. plural rules)..

intl.properties comes from a period where CLDR wasn't a thing, and most localizers were very technical, working directly on files via text editor and VCS. That's really not true anymore.

On top of that, a lot of the options in this file were created to cater for one local (Japanese). So, variations are mostly exceptions (example), and would result in a very simple configuration, instead of 100+ strings across 100+ repositories.

Last but not least: having these stored in l10n repositories makes tracking hard, and regressions way too easy (that's why I ended up creating scripts…). Let's say a locale starts displaying access keys all the time: first you need to track if the key changed and when, then when that specific revision started shipping in products (including cross-channel in the picture). If it was stored in mozilla-central, it would be bound to a specific version of Firefox and, more importantly, it would only be changed with good reasons in a bug.

Comment 4

[Eemeli Aro [:eemeli]]

Okay, that makes sense. Renamed to not imply that these need to go to Fluent.

One of the "strings" in the file is pluralRule, which is used by PluralForm (both intl/locale/PluralForm.jsm and devtools/shared/plural-form.js) and compare-locales. We really ought to be able to get rid of it as well, but that may well turn out to be easier to do once all plural messages are migrated from .properties to Fluent.

Comment 5

[Eemeli Aro [:eemeli]]

Having looked through the actual data, the value of intl.ellipsis is currently platform-independent, and consistently \u2026 in all locales except for ja and ja-JP-mac, which use ..., i.e. three period-characters, for all platforms.

I think adding a similar JSON config as was done to replace region.properties is the right move here.