Changing language of add-on

Hello,

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 read:


https://support.mozilla.org/en-US/questions/1190204
https://support.mozilla.org/en-US/kb/use-firefox-interface-other-languages-language-pack

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).

Is this a bug or I’m doing something wrong?

1 Like

@zbraniecki is working on that. Let’s see if this sends a ping.

Probably didn’t. But then, also, bugmail flew by.

Does that comment help? Won’t do much good on 58, but on 60?

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 :slight_smile:

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.

The second paragraph of the linked comment explains how to switch the UI language.

That official feature is no longer a feature and documentation hasn’t been updated.

No, all you could do is manually reading the messages.json files in your extension and get the strings from there. Shouldn’t be too hard.

I was also looking for a method to switch language with i18n. Maybe this discussion can help you :

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?? :blush:)

How did you found and install language pack? All language packs seems to be not compatible anymore:
https://addons.mozilla.org/en-US/firefox/addon/deutsch-de-language-pack/

You can install it in the current release version (61), but it doesn’t seem to do anything:


The UI is obviously still English (after a restart).

1 Like

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!

Ah, Just activating the language pack (like a theme) should do that …

And it looks loke the language pack is released just-in-time for the current release version, or something: https://addons.mozilla.org/en-US/firefox/addon/deutsch-de-language-pack/versions/

Maybe I already screwed my about:config :smiley: , because it doesn’t work for me unless I set “intl.locale.requested” to “de”.

Regarding the compatibility - why would they use such a restriction for a language pack:

This is from the manifest file:

"gecko": {
  "strict_min_version": "61.0", 
  "id": "langpack-de@firefox.mozilla.org", 
  "strict_max_version": "61.*"
}

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 :smiley: . 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.

The pre-release language packs are available on archive.mozilla.org

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.

Edit: or when nowhere to be found on archive.mozilla.org there probably are some langpacks hidden in taskcluster: https://tools.taskcluster.net/index/gecko.v2

Thanks for the information.

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.

https://bugzilla.mozilla.org/show_bug.cgi?id=1425941 is about changing the UX of changing languages and installing new ones.

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.