Opened 11 years ago

Closed 11 years ago

#8029 closed defect (wontfix)

dojo widgets hijacking 'lang' attribute in markup

Reported by: lipik Owned by: Adam Peller
Priority: high Milestone: tbd
Component: Dijit Version: 1.2.0
Keywords: Cc:
Blocked By: Blocking:

Description

I have posted this in the forum, but received no replies. I do consider it a serious deficiency in the parsing system, so filing it.


Hi,

Dijit widgets take a lang attribute and try to load the localization for it, and if localization is not found, an error is thrown. But this is a problem when creating widgets through markup, since this behaviour essentially overloads the html attribute.

For example, the dojo.parser fails on following markup, with an error "validate bundle not found for lang=en":

<input type="text" id="user_email_c" lang="en" xml:lang="en" dojoType="dijit.form.ValidationTextBox" name="email" trim="true" regExpGen="dojox.regexp.emailAddress"/>

lang attribute has other legitimate functions (e.g. as a CSS selector), so not being able to use lang in the markup for the domeNode of any widget is very limiting.

I would suggest that a proper fix is to not use "lang", but invent a dojoLang attribute. Or, if this is felt to be an incompatible change, at least provide a option (set by default) that lets the widget creation go through even if the localization bundle is not found for the lang specified - though I feel this would be sub-optimal, since lang would still be overloaded.

Thanks

Change History (3)

comment:1 Changed 11 years ago by Adam Peller

Owner: set to Adam Peller

Sorry I didn't see your forum post.

We're trying to use html's lang attribute, rather than 'hijack' it, hopefully with some consistency as we do for other html attributes in our widgets. Specifying a lang attribute only works if the locale exists in Dojo's bootstrap, either as the declared 'locale' or as an 'extraLocale'. Lang doesn't actually load the localization, it only tries to reference what Dojo should have already loaded. So 'lang' is only really useful when multiple locales are used on a page, and that's an edge case to begin with.

Provided these conditions are met, you shouldn't get any error. Anything else is invalid. Does that help? If not, could you provide an example of how this is a problem?

comment:2 Changed 11 years ago by lipik

Hi,

My point is that the problem is precisely that "Lang doesn't actually load the localization, it only tries to reference what Dojo should have already loaded. So 'lang' is only really useful when multiple locales are used on a page, and that's an edge case to begin with."

Inherent in that is the assumption is that if I have specified a lang attribute on an element that has a dojoType then it must be because I want dijit widgets to localize accordingly. However, that need not be the case - the reason for lang could simply be (as in my case) that I want a certain CSS font-family to be used to render this element.

There is also the issue that even though dijit i18n system interprets lang, it has different semantics to the html lang attribute. E.g., specifying lang="en" looks for the "en" bundle, and fails because there is none, even though my build specifies "en-us" as a locale.

Net effect of these two behaviours combined is that perfectly correct HTML markup fails to render with dijit.

Hope I have clarified matters somewhat? Thanks Amit

comment:3 Changed 11 years ago by Adam Peller

Resolution: wontfix
Status: newclosed

I'm not sure I understand the use case where you would use lang to specify a font in CSS but not use the lang on your page or for that widget. Specifying HTML LANG also implies that the locale specified should be applied to the tag. Quoting the HTML spec

This attribute specifies the base language of an element's attribute values and text content... Language information specified via the lang attribute may be used by a user agent to control rendering in a variety of ways... which implies that it's for more than just CSS rules.

Dijit is applying lang to the rendering and behaviors of the widget. I don't think that's hijacking or inconsistent with the spec.

Dojo does also have the functionality of looking up locales, and falling back to 'parent' locales. If the parent locale is not there, it does not 'fail' (it results in a harmless 404 only if you do not use the Dojo build system to produce production code, see the FAQ) If you specify en-us for your page and try to load an en locale, you will get the strings for English without the US variant; by convention, the English without a variant happens to be the US variant anyway, and also by convention, that is stored at ROOT as the fallback for all locales.

If for some reason, you choose to have a CSS rule which you wish to apply with a lang rule, you can prevent a failure by adding it to the djConfig.extraLocale array. You will not, however, be able to prevent Dijit from applying the lang info to the widget in question. That's by design. You could wrap your widget in an extra DIV with this lang information if it's only for CSS purposes, but again, I'm having trouble seeing the use case.

Note: See TracTickets for help on using tickets.