WE - i18n could use a getAddonLanguage() function

Add-ons Development
#1

In order to add multilingual support to your WebExtension, you need to add localized messages to _locales/*/messages.json files (* is a language code id). This allows to get a localized message using the i18n API by referencing your keys like so __MSG_MessageKey__.

Unless I didn’t miss something, the current multilingual support is somewhat limited. As described in https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Internationalization you can auto-translate text inside your manifest.json (this works) and css files (didn’t try that myself). Unfortunately, loading HTML files as sidebar pages, page action popups, browser action popups, … won’t auto-replace message keys within them.

– Please let me know if that is supposed to work or not

One way to have such localized pages could be to load a generic page that contains no localized text, but message keys and then search-and-replace these once the page is loaded; i.e. potentially lots of calls to i18n.getMessage(“MessageKey”).

Another way could be to place already localized pages inside the _locales/* folders and load the right version as needed. The problem with this approach is, that there does not seem to be a safe way to determine from which folder to load the localized resource; i.e. which language code do you have to use when calling browser.runtime.getURL(_locales/*/some.resource)?

i18n.getUILanguage() might trick you into using it to answer that question. The issue is, that your WebExtension could have a _locales/en folder, but no _locales/en_US folder and still get “en_US” as result. So getUILanguage()'s result might only be useful to construct URLs for external sites. The same applies to i18n.getMessage(@@ui_locale), which seems to be functionally equivalent to .getUILanguage().

The only workaround seems to be to add a (AddonLocale: “en”) message definition to the _locale/en/messages.json file and similar ones to all the others. This allows to use .getMessage(“AddonLocale”) to determine the location of a localized resource. That approach is of course error prone as the actual message must always correspond to the name of the parent folder.

So i18n could use a function that allows a WebExtension to detect from which folder to load a localized resource. A i18n.getAddonLanguage() function could return “en” as result if a WebExtension has a _locales/en folder and if _locales/en/messages.json is the current message file in use.

#2

I find the best way, and most brainless way, is to use React or Angular. I don’t even realize this is a limitation, as all the text is coming from Javascript anyways. In Angular, due to the HTML template, it will be more apparent, but in React it is invisible.

#3

The localization story for web-extensions is currently sub-optimal, sadly.

The mozilla l10n team is working on this, but sadly now isn’t the time to put much of our resources to it. We’re starting off with testing out our approach with webextensions we write in mozilla internally, before we roll this out to a WE API.

#4

I have never used one of them before. From looking at the tutorials/guides, I look at Angular as being too time-consuming to learn for a simple extension. I will take a closer look at React because it seems worth the effort; so thanks for that pointer.

#5

IMHO, libraries and frameworks unnecessarily bloat the code. Often, the user ends up with a code that is 1000s (or 10,000s) of lines long for something that can be done with few lines of pure JavaScript.

It is worth noting the libraries and frameworks are also JavaScript. So a new step is created in processing the code from Lib code to JS (instead of direct to JS).

There is no doubt that i18n lacks a number of necessary functions but Libs do not provide a magic solution. They provide the same solution available to everyone. The difference is that someone has already written then code. The bloatware will also impact performance considerably.

Furthermore, using a code that the developer has no control over can result in maintenance difficulties when the Lib changes.

As a reviewer, I regularly see addons with literally 10,000s lines of code for something that could be done with 100.

Personally, I have never found a situation that required me to use a Lib or framework… but that is my personal experience and my personal view. :slight_smile: