#15324 closed defect (fixed)
[regression][email protected]: Loading of nls files broken for some browsers?
Reported by: | Paul Christopher | Owned by: | Rawld Gill |
---|---|---|---|
Priority: | low | Milestone: | 1.7.4 |
Component: | BuildSystem | Version: | 1.7.2 |
Keywords: | Cc: | Adam Peller, Rawld Gill | |
Blocked By: | Blocking: |
Description
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.
Attachments (3)
Change History (31)
Changed 10 years ago by
Attachment: | screenshot.png added |
---|
comment:1 Changed 10 years ago by
Component: | Dijit - Form → Dijit |
---|---|
Resolution: | → worksforme |
Status: | new → closed |
comment:2 Changed 10 years ago by
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...
comment:3 Changed 10 years ago by
Cc: | Adam Peller added |
---|
Paul, I wonder if you have a strange locale setting for those browsers (not to English).
comment:5 Changed 10 years ago by
Changed 10 years ago by
Attachment: | screenshot2.png added |
---|
comment:6 Changed 10 years ago by
Priority: | undecided → high |
---|---|
Resolution: | worksforme |
Status: | closed → reopened |
Summary: | [email protected]: Loading of nls files broken for some browsers? → [regression][email protected]: Loading of nls files broken for some browsers? |
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.
comment:7 Changed 10 years ago by
Cc: | Rawld Gill added |
---|
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)
comment:8 Changed 10 years ago by
ignore that last comment. Paul, of course, isn't going through _testCommon to set the locale. Could be a loader regression?
comment:9 Changed 10 years ago by
Owner: | Douglas Hays deleted |
---|---|
Status: | reopened → assigned |
comment:10 Changed 10 years ago by
Owner: | set to Rawld Gill |
---|
comment:11 Changed 10 years ago by
I have the same problem with custom build of dojo 1.7.2 with latest Firefox and Chrome.
comment:12 Changed 10 years ago by
Milestone: | tbd → 1.8 |
---|---|
Resolution: | → worksforme |
Status: | assigned → closed |
comment:13 Changed 10 years ago by
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?
comment:14 Changed 10 years ago by
Resolution: | worksforme |
---|---|
Status: | closed → reopened |
Take a look at the calendar month drop down in the theme tester links above. It's the only obvious piece with translated text.
comment:17 Changed 10 years ago by
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".
comment:18 follow-up: 19 Changed 10 years ago by
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'
comment:19 Changed 10 years ago by
Priority: | high → low |
---|---|
Resolution: | fixed |
Status: | closed → reopened |
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.
comment:20 Changed 10 years ago by
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.
comment:21 follow-up: 22 Changed 10 years ago by
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).
comment:22 Changed 10 years ago by
Component: | Dijit → BuildSystem |
---|---|
Status: | reopened → assigned |
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:
- How preloads work with a built layer than contains flattened NLS bundles
- 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.
comment:24 Changed 10 years ago by
I was wrong: upon further inspection, the builder was doing the correct thing. The repair is as stated above.
comment:25 Changed 10 years ago by
Milestone: | 1.8 → 1.7.4 |
---|---|
Resolution: | fixed |
Status: | closed → reopened |
Reopening for inclusion in 1.7.4. See #15710
This works for me in all browsers. I suspect a user-config issue.