Unexpected locale `en-us` after upgrade to ember-intl v6 about ember-intl HOT 6 CLOSED

Extending IntlService and overwriting private property _locale could be used as a workaround:

import BaseIntlService from 'ember-intl/services/intl';
import { tracked } from '@glimmer/tracking';

export default class IntlService extends BaseIntlService {
  @tracked _locale = 'en';
}

Maybe _locale should default to a default value specified in intl configuration?

from ember-intl.

What I didn't understand from your description, though, are:

* What issue(s) you encountered because `en-us` is present

* Why you set `_locale` to `'en'` (i.e. which public API did you need that depends on the value of `_locale`?)

Can you explain the issue(s) to me, maybe from the perspective of your end-users?

I don't think it's causing a bug from end-user perspective. I only noticed in a test, which ensures that the list of locales shown in language selector is in sync with the list of translations existing in the project. The language selector is not using IntlService.locales as the source of truth to render the options in the language selector. So no bug from end-user perspective.

from ember-intl.

Hi,

we hit the same bug, and it was visible to the end user. We used the IntService.locales property as source of truth and we had some custom logic to choose the locale based on the browser language from the list of available translations (= IntService.locales ).

In short, for language that did not have an exact match, we choose another one so that for "en-us" we would choose the "en-gb" translations.

Now there is an exact match for "en-us" the app tries to use "en-us" and then shows "missing translation" texts.

from ember-intl.

Hi, @jelhan. Thanks for reporting a bug and providing a minimal reproduction. In your repro app, I could see that en-us is added by default. (My guess is, perhaps as a fallback when a translation is missing.)

At the moment, due to another issue with ember-intl@v6 around TypeScript, I get the impression that we'll want to rethink about ember-intl's API and implementation, and whether there are ways to simplify them. (That is, it may take me a while.)

What I didn't understand from your description, though, are:

• What issue(s) you encountered because en-us is present
• Why you set _locale to 'en' (i.e. which public API did you need that depends on the value of _locale?)

Can you explain the issue(s) to me, maybe from the perspective of your end-users?

from ember-intl.

This also seems related: #1826
except this crashes the app.

from ember-intl.

I have a possible fix in #1847, but it requires a breaking change in the test helper setupIntl(). If the fix is correct, the change would be made in [email protected].

from ember-intl.