I have trouble changing the language for my add-on GroupSpeedDial.
I’ve changed general.useragent.locale value in about:config page to “sk” (for Slovak) but after restarting Firefox only addon short description in about:addons page is in Slovak, all other labels are still English.
I’ve even created new intl.locale.requested property with “sk” value and make sure intl.locale.matchOS is set to false
I’m using 58.0.2 (64-bit). I have also second profile with Firefox Nightly Slovak edition where the Slovak language works fine (in browser and the add-on).
Thank you for the link. However that bug seems to be a bit unrelated to the issue I have.
Also I don’t want a new feature, I want the existing feature that is officially documented to be working
One more question - can I implement switching language in my add-on if I’m using i18n? Because I don’t see any method to get a message in specified language or to set a different language.
This makes it sound like the documentation here about “Testing out your extension” is out of date, but I’m not sure that’s what was meant. At any rate, the bugzilla link supplied doesn’t address how to switch locales in the case of testing an extension as a temporary add-on in the browser.
I had the same issue as the OP. When I created a new intl.locale.requested property and changed it to “de” for the notify-link-clicks-i18n example, the only strings that were affected were the extension name and description as defined by __MSG_extensionName__ and __MSG_extensionDescription__. The browser.i18n.getMessage calls to set the pop-up text remained in the default language.
Installing the DE language pack fixed this problem for me, but it took me a while to try that. Maybe this should have been mentioned explicitly in the actual testing steps? Currently it’s mentioned only as a couple of notes:
The fact that the getMessage() calls won’t set the text correctly in the target language if the tester is missing the language pack seems more appropriate as essential information than an aside. Developers less familiar with how locales are resolved may not catch on immediately. (Or maybe it’s just me?? )
That’s odd. Is the 61 last supported version? Because in 62 beta and 63 alpha it says not compatible. Or is the compatibility always only latest stable release?
Anyway when you install the missing language pack, you can then use the intl.locale.requested property in about:config page to change the language of your add-on (including the UI of the Firefox). Which is what I was looking for in the place!
Is there a reason to prevent alpha and beta users to use the language packs? Also now I see what is the source of the bad reviews for the language packs . Someone should definitely fix that.
I guess each version needs a specific set of translated strings, so the restriction of one language pack (with one set of strings) to exactly the version it is made for does make sense. But the language packs should be released earlier, at least for the beta version. It’s not like there usually are tons of strings changing between versions (and I’d hope that missing strings in a pack are handled gracefully anyway).
And the profile I took the screenshot in is a pretty fresh one. Nothing happened there, so you probably do have to use that pref even if you didn’t change it before.
Check out https://firefox-source-docs.mozilla.org/intl/locale.html#locale-management for an in-depth explanation of how languages are chosen for the Firefox UI and why it sometimes just changes and sometimes doesn’t. I also think I’ve heard of some UI being planned for that, but not entirely sure.
I personally don’t care much about localization. We should all just speak one damn language, use one alphabet, one way to write numbers and dates and use one set of units. Everything else is just a huge waste of resources.
Bit until everyone agrees with that and realizes it, this UX really isn’t good.
Compatibility of language packs is an independent problem, which would require quite some changes to how we build them. Not sure when we’ll get to that.