Implement a default locale setting for l10n

NEW
Unassigned

Status

Add-on SDK
General
P2
normal
6 years ago
7 months ago

People

(Reporter: ochameau, Unassigned)

Tracking

(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

6 years ago
Currently, l10n module will return the key if the key is not translated in the selected property file.
Consider an addon, that had only one "v1_key" for its first version,
but then introduced a second "v2_key" in a future version:
  _("v1_key");
  _("v2_key");
And we have:
# en.properties:
v1_key = Hi
v2_key = Bye
# fr.properties:
v1_key = Bonjour

So in this example, french localization file hasn't been updated for the very last addon version, so that v2_key is missing.
Current behavior is that _("v2_key") will return "v2_key".
We would prefer to return the existing engligh key!

So in order to adress this, we need to find a way to define the "default language". i.e. the fallback language that we should use when the key is not translated in current language.
I'm wondering if we should:
- add an attribute in package.json, like "default-locale" that developer will set to define its main/fallback language. It will allow to know which language is hardcoded if the developer uses gettext pattern. So if a key is not translated, we will check if the key is translated in this specified language.
- and/or go through all browser languages list by priority order when a key is missing? In order to return the best matching language that has the key translated ? [we may end up having more than 2 displayed languages in very exotic cases]
(Reporter)

Comment 1

6 years ago
Will> You mentioned this issue in one of your mail. Your feedback is welcomed :)

Updated

6 years ago
Priority: -- → P2
Whiteboard: [good first bug]
Depends on: 935290
Blocks: 958990
We currently use the 'user default' locale which is determined from these prefs: `general.useragent.locale`, `intl.locale.matchOS, and `intl.accept_languages`) at add-on load time.

I'd like to see this procedure:

1. Check user preferred pref
2. Check default prefs (listed above)
3. Check developer/user defined fallback

The 2nd is derived by Firefox, and the 1st and 3rd would be derived by simple-prefs.

Since we have a hidden pref type now, the 3rd can by either hidden or user changeable this way, and developers can opt-in to steps 1 & 3 by providing these simple-prefs.

Thoughts?
Flags: needinfo?(rFobic)
Flags: needinfo?(poirot.alex)
(Reporter)

Comment 3

4 years ago
There is two things here:
- having a fallback mechanism if the key doesn't match anything in the properties file. If nothing changed since I left, we only check into one properties and just display the key if nothing matched. Ideally we would fallback from property files to another until we match.
- be able to know which locale is the default one, which in most cases means this is the developer one and has a 100% key coverage. We may assume that english is the default one, but that may not be true for non-english developers...

Here you are talking about user locale preferences, this is already implemented in sdk/l10n/locale.getPreferedLocales(). This function returns an ordered list of locale sorted by relevance. I talked to some l10n folks to validate this precise ordering.
Flags: needinfo?(poirot.alex)
(In reply to Alexandre Poirot (:ochameau) from comment #3)
> Here you are talking about user locale preferences, this is already
> implemented in sdk/l10n/locale.getPreferedLocales(). This function returns
> an ordered list of locale sorted by relevance. I talked to some l10n folks
> to validate this precise ordering.

This is a global setting, and not a per add-on one which are what I'd like the prefs used in step 1 & 3 to be.  I should have been more clear about that difference.
(Reporter)

Comment 5

4 years ago
Sounds good to me, it should address the original report and user locale selection.
My only concern is that it may significantly increase the scope of this bug,
but it also looks like you can easily iterate on this.
One more thing to consider here is the time and memory used on loading fallback locales. From my understanding before it was limited to one language that was loaded async before add-on is started,
now we're talking of tripling amount of time before add-on starts and memory it will use & all this
just to have a just in case fallback.

We can try to be smart about it and optimize for a common case, maybe merge locales it add-on install
time ? In such case I think proposed fallback scheme would be acceptable. If not I would suggest to
perform some measurements before jumping onto implementation.

Also note that described issue very much can be addressed by localization tools (which may also mean
copy & paste) by copying missing keys.
Flags: needinfo?(rFobic)
Removing priority so we can triage it again.
Priority: P2 → --

Updated

4 years ago
Priority: -- → P2

Comment 8

7 months ago
Because of the difficulty finding mentors and the expected life span of the SDK, we are removing [good first bug] from remaining SDK bugs.

Updated

7 months ago
Whiteboard: [good first bug]
You need to log in before you can comment on or make changes to this bug.