Hello. Digital storage size unit symbols are not expressed according to the language set in Firefox

Conditions:

• Linux OS locale: English non-alike.

In Firefox | in about:preferences#general

• language set: English (US)
• option Use your operating system settings for “suomi (Suomi)” to format dates, times, numbers, and measurements.: not checked.

Observed effects
in about:preferences#privacythe sizes reported in section Cookies and site Data the measure units are expressed according to my OS locale, not the language set in Firefox. Then either tavua or t, respectively for byte and bytes are exhibited instead of the correct forms which are byte and B.

I expect you switched languages at runtime. We're loading the localized string for the byte units from your selected Firefox locale, so presumably it was originally set to Finnish and cached. I expect a restart of Firefox will fix it. If not, that would be interesting to know - as would knowing if using about:support and clicking "clear startup cache" there (followed by another restart) addresses it.

Your assumption is correct. Observing the instructions addressed it. Then i learned something. I had assumed that the function about:preferences#privacy's Clear data was precisely to globally clear data at runtime as well the startup cache.

(In reply to lamalbrut from comment #2)

I had assumed that the function about:preferences#privacy's Clear data was precisely to globally clear data at runtime as well the startup cache.

Right - "Clear data" is listed under "Cookies and Site Data" because it only removes website related data, not Firefox configuration/caching data. :-)

Greg, for my edification: under what circumstances do .properties reads get updated at/after a live language switch? Although of course migrating this particular bit to Fluent will help, there are many of these cached bundle references in the codebase... did we consider wiping caches and invalidating previously fetched stringbundles at the point of a live language switch and/or are there reasons that's not possible?

The string bundles have multiple cache mechanisms, so it depends on the situation of how they get loaded as to how they get reloaded. There are a subset of bundles that get loaded into shared memory. These can never be changed until restart. If you hold a reference to a bundle, e.g. through a lazy loader, then these will never be updated. Many different parts of code hold on to a reference to the string bundle with their own retaining reference.

So in the case where you directly load a string bundle not in shared memory after a live language switch, you will get the new language's bundle.

Here is where SharedStringBundle is created: https://searchfox.org/mozilla-central/rev/a26af613a476fafe6c3eba05a81bef63dff3c9f1/intl/strres/nsStringBundle.cpp#895

Could we use https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/NumberFormat/NumberFormat#options style unit for unit formatting?

This appears to have been a typo introduced in bug 1737926.

These strings are only used from browser, so it doesn't make sense to keep them under toolkit.

Depends on D158465

Depends on D158466

The downloadsFolder string is left in the downloads.properties file, at least for now, as it's also used from C++ code.

Depends on D158467

The stack of patches I just submitted for this does not use NumberFormat with style: "unit", as I couldn't find a way of doing so while retaining the same strings in all languages for download rates. At a brief glance, at least our Basque, Estonian and Tibetan translations use expressions for "foo of bar" that do not simply concatenate the value with its unit.

Landing just the typo fix for now; the rest of the stack will probably not land until 108, as I'll be away for a couple of weeks after this one.

https://hg.mozilla.org/mozilla-central/rev/9122c36cdf19

https://hg.mozilla.org/mozilla-central/rev/fcd7f4dad307
https://hg.mozilla.org/mozilla-central/rev/313e4bf53438
https://hg.mozilla.org/mozilla-central/rev/cff746cab1b2

Hi, lamalbrut! Could you please take a look at this bug and check if the issue is fixed on the latest Beta 108 builds?

Unfortunately, I was not able to reproduce the issue described in comment 0, using an affected Nightly build 2022-09-16, with Win 10 x64 or Ubuntu 18.04 x64.

on | Windows 11. Firefox 109.0a1 (2022-11-19)

Unlike the behaviour in the version originally tested, in that version the newly selected language is not applied at all at runtime. Therefore there is no relevant observation to be made during runtime.