Opened 8 years ago

Closed 7 years ago

Last modified 7 years ago

#15324 closed defect (fixed)

[regression]DateTextBox@NightlyBuilds: 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)

screenshot.png (140.1 KB) - added by Paul Christopher 8 years ago.
15324.jpg (69.3 KB) - added by Douglas Hays 8 years ago.
screenshot on IE9 that is working
screenshot2.png (92.9 KB) - added by Paul Christopher 8 years ago.

Download all attachments as: .zip

Change History (31)

Changed 8 years ago by Paul Christopher

Attachment: screenshot.png added

comment:1 Changed 8 years ago by Douglas Hays

Component: Dijit - FormDijit
Resolution: worksforme
Status: newclosed

This works for me in all browsers. I suspect a user-config issue.
screenshot on IE9 that is working

Changed 8 years ago by Douglas Hays

Attachment: 15324.jpg added

screenshot on IE9 that is working

comment:2 Changed 8 years ago by 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...

comment:3 Changed 8 years ago by bill

Cc: Adam Peller added

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

comment:4 Changed 8 years ago by Adam Peller

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

comment:5 Changed 8 years ago by 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].

Changed 8 years ago by Paul Christopher

Attachment: screenshot2.png added

comment:6 Changed 8 years ago by Adam Peller

Priority: undecidedhigh
Resolution: worksforme
Status: closedreopened
Summary: DateTextBox@NightlyBuilds: Loading of nls files broken for some browsers?[regression]DateTextBox@NightlyBuilds: Loading of nls files broken for some browsers?
Last edited 7 years ago by Adam Peller (previous) (diff)

comment:7 Changed 8 years ago by Adam Peller

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 8 years ago by Adam Peller

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

comment:9 Changed 8 years ago by Douglas Hays

Owner: Douglas Hays deleted
Status: reopenedassigned

comment:10 Changed 7 years ago by bill

Owner: set to Rawld Gill

comment:11 Changed 7 years ago by myersjj

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

comment:12 Changed 7 years ago by Rawld Gill

Milestone: tbd1.8
Resolution: worksforme
Status: assignedclosed

comment:13 Changed 7 years ago by 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?

comment:14 Changed 7 years ago by Adam Peller

Resolution: worksforme
Status: closedreopened

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:15 Changed 7 years ago by cjolif

I have the same issue in Firefox with French locale.

comment:16 Changed 7 years ago by Rawld Gill

Resolution: fixed
Status: reopenedclosed

In [29123]:

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

comment:17 Changed 7 years ago by 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".

comment:18 Changed 7 years ago by 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'

Last edited 7 years ago by Adam Peller (previous) (diff)

comment:19 in reply to:  18 Changed 7 years ago by Rawld Gill

Priority: highlow
Resolution: fixed
Status: closedreopened

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 7 years ago by 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.

comment:21 Changed 7 years ago by 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).

comment:22 in reply to:  21 Changed 7 years ago by Rawld Gill

Component: DijitBuildSystem
Status: reopenedassigned

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.

comment:23 Changed 7 years ago by Rawld Gill

Resolution: fixed
Status: assignedclosed

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

comment:24 Changed 7 years ago by Rawld Gill

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

comment:25 Changed 7 years ago by Adam Peller

Milestone: 1.81.7.4
Resolution: fixed
Status: closedreopened

Reopening for inclusion in 1.7.4. See #15710

comment:26 Changed 7 years ago by Rawld Gill

Resolution: fixed
Status: reopenedclosed

In [29322]:

backport [29259]; fixes #15324; !strict

comment:27 Changed 7 years ago by Colin Snover

In [29758]:

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

comment:28 Changed 7 years ago by Colin Snover

#16088 is a duplicate of this ticket.

Note: See TracTickets for help on using tickets.