@michael-fischer wrote: (see Ref globalizejs/globalize#357 (comment))
@rxaviers,
Short version:
I guess my thought boils down to that if you use the Language-Region your message table still needs to be keyed of the language So even if you use .Globalize( "de-DE" )
you still need to have the language in your json.
Longer version:
You don't. You can use var globalize = Globalize( "de-DE" ) just fine.
I concede this point as using the Language subtag was my way of working around the problem that I was really trying to solve. Namely, the disconnect between using Language-Region when calling LoadMesssage. I assume internally globalize.cldr.attributes.languageId
is used so the loaded JSON can't use Language-Region. Or at least I have only had success with:
{
"root": {
"actions": "Actions",
"activityNotes": "Activity Notes",
...
},
"de": {
"actions": "Aktionen",
"activityNotes": "Aktivitätshinweise",
...
}
}
as opposed to
{
"root": {
"actions": "Actions",
"activityNotes": "Activity Notes",
...
},
"de-DE": {
"actions": "Aktionen",
"activityNotes": "Aktivitätshinweise",
...
}
}
Note, I changed your example to "de-DE" from "en-US" since en-US gets loaded into "root" as a fallback and therefore just works.
Before going too deep here, what's your use case? I understood your client-side detects the user's browser locale and then fetches the needed CLDR data dynamically on your server. Is that the case? I also assume your problem is that you're willing to fetch "cldr/main/en-US/ca-gregorian.json" instead of "cldr/main/" + globalize.cldr.attributes.languageId + "/ca-gregorian.json". Is that correct? If so, I understand your pain. Otherwise, please could you clarify?
My use case is slightly more complicated that than but we can boil it down we use the browsers locale. I actually build what to download using a string similar to that. I just don't get the value from the globalize.cldr.attributes.languageId
. However, doesn't your example have a chicken before the egg problem? Is it possible to initialize globalize prior to fetching the CLDR data? However, I could do something like the following demo code:
var culture = "de-DE"; // hard coded for example only.
var globalize = Globalize(culture);
var language = globalize.cldr.attributes.languageId;
var jsonData = $.ajax({
url: "json/DB2-" + culture + ".json",
async: false,
cache: false,
dataType: 'json'
}).responseText;
var strings = JSON.parse(jsonData);
// Hack the language key here.
if (strings.hasOwnProperty(culture) && language !== culture) {
strings[language] = strings[culture];
delete strings[culture];
}
Globalize.loadMessages(strings);
This would make the hack local to the client where it details with CLDR and not something sprinkled through the system. Still something that I shouldn't need to do but an acceptable workaround.
@michael-fischer, when you download
"json/DB2-" + locale + ".json"
, do you get all the messages (including other locales and root), or do you get the messages of the requested locale only?