rxaviers/README.md

## README.md

      
    Raw
  

              README.md
            
          
    @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.