I’ve read all that documentation here:
- https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/i18n/getMessage
- https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Internationalization#Retrieving_message_strings_from_JavaScript
But it’s still not clear whether i18n.getMessage()
uses the locale i18n.getUILanguage()
or i18n.getAcceptLanguages()
returns.
So one the one hand, I’d think this:
- accept-language is basically what’s used in the HTTP header, so actually would have nothing to do with a browser/browser extension.
- UI language is what is part of the browser. And the extension is likely considered a part of the browser.
So the docs states me to change two simple prefs (both set to “de”) and. To be extra sure, I also just modified the usual visible options:
So, afterwards, as the doc correctly says: My manifest is being translated and correctly displayed in about:addons
.
However, getMessage
still returns the English strings.
BTW, in my case it’s a popup, not a notification being translated, but I thought JS is the same. I only now notice it talks about the CSS/manifest.json translation there.
Maybe the behaviour can be explained, because, the doc then states:
To change the result of getUILanguage the language pack is required, since it reflects the browser UI language and not the language used for extension messages.
That comes a bit late… So as far as I understand it, it uses intl.locale.requested
for about:addons and CSS; the browser’s UI locale for JS requests and the whole “user request” locale is still unrelated to this(?). How many locales do we even have here??
I finally tested it in stable with a German language pack installed, and voila: There it works.
I’d like these changes:
- There should be a clear statement: If you want to get the language
getMessage
uses when it localizes text, you should use XY. Or maybe one can (or should?) even use@@ui_locale
here? I.e.i18n.getMessage("@@ui_locale")
? - The testing part is confusing.
I think the fact that it seems to use the 2 (or 3) different locales is a big point of confusion. Maybe you can avoid it by clearly separating between these, as users not knowing this might think:“Okay, we have one locale for the browser UI/extensions, and that’s how they tell me to test it. Sure, website locale may be different, I don’t care.
Okay, my test does not work. Oh at the bottom it tells me the browser locale is not the one of the extension…?!”