Regression in 1.13? dijit/form/DateTextBox not Localized

I have a problem with localization in dijit/form/DateTextBox. It doesn’t seem to be working quite right.

Here’s a working sample page:

If you select a date using the picker, it’s inserted in US format (mm/dd/yyyy) not (dd/mm/yyyy). If you examine the content of the page, i’m setting lang=“en-gb” at the HTML tag level, the dojoConfig level, and even at the html element level.

I’ve got another page set for en-au:

It works as expected. Can someone help me understand why the localization isn’t working as expected?

I dug into this some more. What I found is in my dijit/nls/MHSdijit_en-gb.js file, there’s an incorrect value.


Can anyone help me understand where this value comes from and why is it wrong?

After much digging, the problem is the silly LDML files don’t have dateformats defined for en_GB, or en_IE but they do for en_AU. There’s just no rhyme or reason to it.

Hi George, has this changed from 1.12.x to 1.13.x? It’s possible something didn’t go as expected with the build and no one noticed. Also could you tell me what LDML is?

I’ve enabled GitHub issues for Dojo and Dijit, so it would be fine to open an issue in either repo as well if needed.


ldml is part of the localization code as documented here:

I opened a ticket about this years ago:

Also, here’s a thread on the unicode consortium mail list where i discuss the issue.

The problem now is that the Unicode consortium has re-structured their files again, and not even en_GB builds right any more.

Ok, obviously this may not be an easy fix. We are just about done with the 2.0 release, so we will try to look into this shortly thereafter.

This restructuring of formats is rather frustrating, but is probably pretty easy to fix once we dig into it.


I did get some ideas from the folks at cldr on how to build fully resolved files. When I get a chance, I’ll take a look to see how hard it would be to fix myself.