en shown instead of en-US

[manuel-reil]

Hi,

thanks for this great addon.
However, we are struggling in setting up 3 different locales: 'en' (means en-GB), 'en-US' and 'de'.
We read #256 .

While 'de' is working properly, switching to 'en' or 'en-US' always leads to the locales defined in 'en'. No indications for missing translations.

What are we doing wrong?
Thank you.

Our setup:

• environment.js: ENV.i18n = { defaultLocale: 'en' }
• 3 directories under locales, named 'en', 'en-US' and 'de'.
• Inside one translations.js and one config.js per directory

Versions:

• Ember : 1.13.10
• Ember Data : 1.13.13
• jQuery : 2.1.4
• ember-i18n installed last week

[jamesarosen]

Thanks for submitting this. There are several tests that cover changing locales within a tree, so I'm surprised there's a bug. I have a few hypotheses, though (mostly around modifying translation dictionaries as we compile them for a locale instead of copying before modifying).

First we'll need to understand what your translations look like a bit. Can you provide just a small segment of each of the three translations files that represent the same keys? For example,

// app/locales/en/translations.js:
"welcome": "Welcome to Great Britain",
"hello": "Hello"

// app/locales/en-US/translations.js:
"welcome": "Welcome to America",
// no "hello"

// app/locales/de/translations.js:
"welcome": "willkommen in Deutschland"
"hello": "hallo"

So I'm looking for at least one key where they all differ and one key where only en and de differ; en-US has no override.

Given that, I'd like to know what the following code outputs:

i18n.set('locale', 'en');
i18n.t('welcome');
i18n.t('hello');

i18n.set('locale', 'en-US');
i18n.t('welcome');
i18n.t('hello');

i18n.set('locale', 'en'); // back to en
i18n.t('welcome');
i18n.t('hello');

i18n.set('locale', 'de');
i18n.t('welcome');
i18n.t('hello');

i18n.set('locale', 'en-US'); // back to en-US
i18n.t('welcome');
i18n.t('hello');

[manuel-reil]

Thank you for your efforts.
Let me list the results and my observations while outputting intermediate steps within utils/locale.js of ember-i18n.

Code outputs you wished

SafeString {string: "Welcome to Great Britain"}
SafeString {string: "Hello"}

SafeString {string: "Welcome to Great Britain"}
SafeString {string: "Hello"}

SafeString {string: "Welcome to Great Britain"}
SafeString {string: "Hello"}

SafeString {string: "willkommen in Deutschland"}
SafeString {string: "hallo"}

SafeString {string: "Welcome to Great Britain"}
SafeString {string: "Hello"}

Other observations
I let console.log the the id and the translations object wihtin 'getFlattenedTranslations' in utils/locale.js.

• First always there is the "en" with the complete translations of file locales/en/translations.js.
• Just after that in a row: the currently set locale incl. translations: In case of en-US selected, id seems to be correct, but translations is an empty

Switching to en-US

id: "en"
translations: {"welcome":"Welcome to Great Britain","hello":"Hello"," "..." : "..."}
id: "en-US"
translations: {}

Switching to de-DE

id: "de"
translations: {"welcome":"willkommen in Deutschland","hello":"hallo"," "..." : "..."}
id: "de-DE"
translations: {}

[jamesarosen]

Thanks. I think this confirms my hypothesis. I know where to fix this.

One thing that might help us know what happens if you change the order of languages -- default to en-GB, then switch to en.

This will tell me if its a hierarchy problem or an order problem. I think it's the latter.

[jamesarosen]

I'm going to take a guess that your translations are actually in app/locales/en-US/translations.js.

Ember-I18n asks the Container for the translations. Ember's Container.lookupFactory first asks the resolver to normalize the name of the translation file to be looked up. Ember-CLI's Resolver normalizes names by calling dasherize. dasherize lowercases strings:

Ember.String.dasherize('en-us'); // 'en-us'
Ember.String.dasherize('en-US'); // 'en-us'

So you would need to move your translations to app/locales/en-us/translations.js.

I'm going to add some tests around switching locales to ensure other problems don't surface here.

[manuel-reil]

James, that solved it. How could I missed that?
Sorry for opening this as an issue and thank you for your prompt help.

Manuel

[jamesarosen]

Sorry for opening this as an issue

Not at all! It revealed expectations I didn't know I was making. And I added some tests :)