Skip to content

i18n.getMessage() language fallback paths #296

@carlosjeurissen

Description

@carlosjeurissen

Not all browsers handle language fallbacks the same. Considering the following situation:

An extension is using the native i18n APIs with "default_locale": "en" in manifest.json, and three messages.json files in the languages en, pt and pt-BR.

Both en and pt include the message ids message1 and message2. While pt-BR includes only message1.

In the above situation, browsers handle fetching i18n.getMessage('message2') different.

Chromium first checks pt_BR/messages.json, if the message is not present, it checks pt/messages.json, and finally, if the message is still not found, it will check the default_locale, in this case en/messages.json. In the above situation, this means it gets the message2 value from pt.

In Firefox, however, the browser first checks pt_BR/messages.json. If the message is not in this file, it will directly fallback to default_locale. so it checks en/messages.json. Resulting in message2 value becomes the one from en.
Edit: The behaviour of Firefox has been changed and now aligns with Safari and Chrome.

Interestingly enough, in Firefox, if pt_BR/messages.json is not present in general, it will check pt/messages.json first, before checking en/messages.json.

What is the behaviour we want in these cases?

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions