Opened 7 years ago

Closed 3 years ago

#15630 closed defect (patchwelcome)

Localization fails in dijit/nls/loading.js

Reported by: hungerburg Owned by: Adam Peller
Priority: undecided Milestone: 1.13
Component: Internationalization Version: 1.7.3
Keywords: Cc: bill
Blocked By: Blocking:

Description

Today I updated my staging server to 1.7.3. Dojo only started working for me, after I removed the lang attribute from my pages. Attached the smallest sample, that I could get at, to reproduce the issue.

The bug is triggered by the lang="de" attribute to the html entity. It does not happen when the tabContainer does not have a contentPane. It does not happen when async:true is not set above. It does not happen when attribute value is "de-de", but then opera and chrome fail.

I cannot test with CDN, because they do not have 1.7.3 yet. This is with my custom build. Though that should not matter, because I have changed nothing in the source, or should it?

Attachments (2)

local.html (926 bytes) - added by hungerburg 7 years ago.
minimal page to trigger error
LocalizationFailure.png (139.9 KB) - added by hungerburg 7 years ago.
Thank you Peller, I did search the reports, but have not found a precedent. It is not Ticket #15288. Attached a screenshot of the backtrace in firebug.

Download all attachments as: .zip

Change History (15)

Changed 7 years ago by hungerburg

Attachment: local.html added

minimal page to trigger error

comment:1 Changed 7 years ago by Adam Peller

Resolution: invalid
Status: newclosed

You must set the dojo config to use your locale, otherwise it will not load. Please support requests to the dojo-interest mailing list.

comment:2 Changed 7 years ago by hungerburg

This is not a support request. I do not want to know, how to force dojo into a certain locale. The html lang attribute has a use outside of dojo. Dojo uses this attribute to gain information on what nls bundle to load, I suppose, and if an otherwise valid use of the attribute breaks dojo, then that is a bug.

On the positive side with 1.7.3 I can tell, that opera now works flawlessly.

comment:3 Changed 7 years ago by Adam Peller

Resolution: invalid
Status: closedreopened

ok, fair point. There is another issue on this, but I cannot find it right now. I'll keep this open until I find it.

comment:4 Changed 7 years ago by Adam Peller

Cc: bill added

Changed 7 years ago by hungerburg

Attachment: LocalizationFailure.png added

Thank you Peller, I did search the reports, but have not found a precedent. It is not Ticket #15288. Attached a screenshot of the backtrace in firebug.

comment:5 Changed 7 years ago by Paul Christopher

comment:6 Changed 7 years ago by bill

I bet the bug would happen without the TabContainer, and just with a ContentPane... because:

  1. the parser is cascading the lang setting down to the ContentPane
  2. parser calls new ContentPane({lang: "de"})

Not sure why that's causing a problem, but I bet it's related.

comment:7 Changed 7 years ago by Adam Peller

Paul, yes, that's the ticket I was thinking of. I think the conclusion was that setting the lang attribute anywhere (on an HTML tag or on an individual ticket) without also setting the locale or extraLocale in data-dojo-config to match was not supported.

comment:8 Changed 7 years ago by hungerburg

Bill, you are right, just the contentPane is sufficient to trigger the exception. Paul, that ticket describes something very similar, but the consequences are drastically different: Here not only will messages mix two languages, but the widget/the whole page will not display at all, if a (unknown?) locale is specified. Peller, setting the locale also in data-dojo-config will not prevent the exception.

Reasons to set HTML lang attribute: tell the hyphenator (css3) which patterns to apply, help tts speech synthesizers with pronunciation.

Stepping through the code I think this is where the fun starts:

  • postMixInProperties dojo.js.uncompressed.js:23330
  • var messages = i18n.getLocalization("dijit", "loading", this.lang);

In firefox messages will be filled with the german catalog when lang="de-de", with lang="de" it will fail in doLoad (dojo.js.uncompressed.js:16044) down the stack, because "root" there will not be defined then.

In opera messages will be filled with the english catalog, when lang="de", with lang="de-de" it will fail in doLoad (dojo.js.uncompressed.js:16044) down the stack, because "root" there will not be defined then.

So opera and firefox behave exactly the opposite, and chrome behaves the same as opera. I did not find where in the scope "root" would be defined.

Kind regards

Peter

comment:9 Changed 7 years ago by hungerburg

When I omit the async:true from data-dojo-config, "root" in "doLoad" will reflect the contents of "dijit/nls/loading.js" in firefox. Then "messages" will be filled with the german catalog, even when lang="de" in firefox, and will be filled with the german catalog in opera, when lang="de-de", but still with the english catalog when lang="de".

Only now I realize, that line numbers above are a waste, because this is with a custom build, sorry for the noise. postMixInProperties is in the declaration of the contentPane widget. doLoad is in the definition of "dojo/i18n".

Correction from my previous post: html lang="de" PLUS data-dojo-config "async:true,locale:'de'" will not produce the error in any of firefox, opera, chrome. (A script node in the head of the document will be created that pulls in "dojo/nls/dojo_ROOT.js".)

If what comment:7 says is to be the way it works, that has to be documented very prominently, because if not followed, release 1.7.3 will break all the sites, that specify a lang attribute in their pages and that use a contentPane, wont it?

Nevertheless, I want to thank you for the goodness of dojo: even a single person can deliver a state of the art user experience.

comment:10 Changed 7 years ago by Adam Peller

see also #15768

comment:11 Changed 7 years ago by Adam Peller

The data-dojo-locale setting is necessary whenever HTML LANG is set, and this needs better documentation, but it sounds like there may also be a regression. Looking at neek's example in #15768, when running configured with an 'en-us' locale, shouldn't requests for 'en' succeed?

comment:12 Changed 7 years ago by Paul Christopher

See my question on http://dojo-toolkit.33424.n3.nabble.com/Setting-a-different-lang-attribute-on-a-widget-seems-not-work-in-release-mode-td3991395.html

Serving a page with html lang="en + dojo locale='en' and setting a different lang-attribute on a single widget (e.g. lang="en-gb") fails in relase mode with a built layer. Even no separate ajax request is fired. The error message is rather meaningless and does not give you any hint that this might be related to i18n. In my case it gave me a "this.Button is undefined" (you might get different error messages). Strange...

comment:13 Changed 3 years ago by dylan

Milestone: tbd1.12
Resolution: patchwelcome
Status: reopenedclosed

Given that no one has shown interest in creating a patch in the past 3+ years, I'm closing this as patchwelcome.

Note: See TracTickets for help on using tickets.