[regression][email protected]: Loading of nls files broken for some browsers?

[Paul Christopher]

Description

Since a few days(?), in some browsers, the nls files are not loaded correctly(?), i.e. the months field gives e.g. just "5" and not "May" (true for IE9, Opera 11.62, Chrome 18). Strangely it works in some browsers (Firefox 12, Safari 5.1.5).

Steps to reproduce the issue

Visit ​http://archive.dojotoolkit.org/nightly/dojotoolkit/dijit/themes/themeTester.html with different browsers. Look at the calendar widget in the left sidebar. In some browsers it has translations, in some it does not.

[Douglas Hays]

This works for me in all browsers. I suspect a user-config issue.

[Douglas Hays]

screenshot on IE9 that is working

[Paul Christopher]

Strange. I have just tested this with another PC, and it shows the same odd behavior: Translations are missing on IE9. "5" instead of "May". However they are there in Firefox...

[bill]

Paul, I wonder if you have a strange locale setting for those browsers (not to English).

[Adam Peller]

Paul, check dojo.locale in the console and see what it says

[Paul Christopher]

The console in IE9 gives me 'de' for dojo.locale. But I have just checked dijit/tests/form/test_DateTextBox.html and it works there in IE9 (whereas it still doesn't work in the theme tester) [both test conducted with the latest nightlybuilds].

[Adam Peller]

Confirmed on Chrome

​http://archive.dojotoolkit.org/dojo-2012-05-01/dojotoolkit/dijit/themes/themeTester.html?locale=de

but not

​http://archive.dojotoolkit.org/dojo-2012-04-01/dojotoolkit/dijit/themes/themeTester.html?locale=de

yet the built ​DateTextbox test works fine.

[Adam Peller]

In the themetester case, dijit_all_ROOT.js is loaded Perhaps it's the way _testCommon.js sets the locale? (which occurs after the dojo.js tag)

[Adam Peller]

ignore that last comment. Paul, of course, isn't going through _testCommon to set the locale. Could be a loader regression?

[myersjj]

I have the same problem with custom build of dojo 1.7.2 with latest Firefox and Chrome.

[Paul Christopher]

Using ​http://archive.dojotoolkit.org/nightly/dojotoolkit/dijit/themes/themeTester.html, IE9 and "de" as locale, it still doesn't work for me.

The bug has already be confirmed by peller. rcgill, could you please check again?

[Adam Peller]

Take a look at the calendar month drop down in the theme tester links above. It's the only obvious piece with translated text.

[cjolif]

I have the same issue in Firefox with French locale.

[Rawld Gill]

In [29123]:

changed default locale de-de to de for default build; fixes #15324; !strict

[Rawld Gill]

The default build was flattening the locale "de-de" and not the locale "de" (note that this was the default for the previous builder). Therefore, there was no localization available for "de" and the i18n routines properly fell back to root.

It is strange that the previous builder specified de-de as a default since the dijit tree does not mention this locale.

This simple workaround is to explicitly specify the profile variable localeList.

[29123] removes "de-de" and replaces it with "de".

[Adam Peller]

Although Dojo and Dijit do not provide variant translations for locales like 'de', dojo/cldr does. In this particular case, the de-de is probably considered the default in cldr, so there may be no difference between de and de-de, but there are other de- variants when the full cldr is generated (they're just not checked into svn)

I thought perhaps the old build system generated flattened bundles for the specified variant as well as all of its 'parents'

[Rawld Gill]

Replying to peller:

I thought perhaps the old build system generated flattened bundles for the specified variant as well as all of its 'parents'

That's a good observation, and I don't know the answer. Whatever the answer, this seems like a good design. I'm going to reopen and make the builder work as such.

[Adam Peller]

Speculating further, I think the old code used to say, if there aren't any strings specific to this variant, just look for the closest parent which matches, and don't bother generating an identical bundle. So if a user requested de-de-frankfurt (if there were such a thing), there probably wouldn't be anything specific to this variant, so de-de or perhaps even just de would be picked up at runtime.

[cjolif]

Adam, I think that later part still works? (i.e. if I have de it will match when I request de-de). Otherwise it sounds like a bug because that's the usual i18n fallback people expect to work? (the problem described here was different, i.e. de-de not matching when requesting just de which is understandable).

[Rawld Gill]

Replying to cjolif:

Adam, I think that later part still works? (i.e. if I have de it will match when I request de-de). Otherwise it sounds like a bug because that's the usual i18n fallback people expect to work? (the problem described here was different, i.e. de-de not matching when requesting just de which is understandable).

There's a little confusion here (I think) because there are two separate issues:

1. How preloads work with a built layer than contains flattened NLS bundles
2. How bundles are loaded with no preloads present.

afaik, 2 works as it always has. If you ask for de-de, and only de exists, then that's what you get. As I've written elsewhere (e.g. #15604), imo preloads are complicated and more trouble than they're worth with AMD. That said, I understand we have to support for 1.x.

With preloads, the i18n plugin will preload whatever the builder tells it to preload given the runtime locale. If a flattened bundle doesn't have the proper contents, then there is no fallback to an unflattened bundle. So the original error was consequent to the building being instructed to flatten de-de, when no such locale existed, and further, failing to fall back to de *when constructing the flattened bundle at build-time*. In short, a bug or enhancement (not sure what the old builder did exactly) for the flattening routines in the builder.

In any event, I'm marking it a bug so I can fix for 1.8.

[Rawld Gill]

In [29259]:

fix preloads to load the flattened bundle to the flattened locale id instead of the current locale id, thereby allowing the normal algorithm to load an unflattened bundle for the current locale (if available) when a flattened version is not available; fixes #15324; !strict

[Rawld Gill]

I was wrong: upon further inspection, the builder was doing the correct thing. The repair is as stated above.

[Adam Peller]

Reopening for inclusion in 1.7.4. See #15710

[Rawld Gill]

In [29322]:

backport [29259]; fixes #15324; !strict

[Colin Snover]

In [29758]:

changed default locale de-de to de for default build; fixes #15324; !strict
Backport to 1.7.

[Colin Snover]

#16088 is a duplicate of this ticket.