Message: language inheritance (original: "root" resolution when loading vs dereferencing)

[donlampert]

Hello,

I've come across an issue regarding how the "root" gets resolved when we load vs. how it's handled when we dereference messages. Essentially, this stems from my desire to be able to load some default messages into "root" and have all locales fall back to those messages if locale-specific messages are not available. With that goal in mind, it appears that loadMessages does the following:

locale = new Cldr( locale );
customData[ "globalize-messages" ][ locale.attributes.languageId ] = json;
Cldr.load( customData );

By creating the new locale with the "unresolved" functionality of cldrjs, "root" basically resolves to "en". This seems acceptable, since the other root CLDR data is based on "en". However, this means that message data loaded into "root" actually gets loaded into "en" in that second and third line of code above.

If I then set my locale to "sv" and attempt to get messages, cldrjs resolves from "sv" to "root" and stops looking up the tree since we are at the root. In such a situation, I cannot get default messages from the root (aka, "en").

My questions regarding this are: 1) Is my use case reasonable? 2) Is there a better way to load default messages, instead of trying to load them into root? 3) Would a fix involve changing the way Globalize loads messages for root, or would it involve changing cldrjs to go further when resolving and make it resolve root as well?

Please let me know if you have any questions regarding my issue.

Thanks!

[rxaviers]

I understand your use case. But, before getting into that...

"root" basically resolves to "en"

Nope, root is the last fallback of a resource bundle lookup. Eg. en-IN ➡ en-GB ➡ en ➡ root.

It happens that cldr.js executes such lookup for main items, but not for the custom-Globalize-message-ones. If such custom data were put into main, your idea would work. Check this example https://gist.github.com/rxaviers/11223930.

Having said all of that, I am not sure what a proper solution should be at this moment. Do you have any reference of other implementations? How they deal with that? Our goal is to move towards ICU MessageFormat. So, anything on that path is preferred.

[donlampert]

I will see if I can find some good reference implementations that might help.

Thank you for that example! In order to still use the messages module, something I did to partially work around this situation involved loading my resources into root before loading the supplemental/likelySubtags file. By doing that, the default strings I wanted loaded directly into root. Then, I loaded likelySubtags and other resource files. After that, any fallbacks to root seemed to load the defaults as desired. Therefore, it seems like cldrjs handles falling back in the case of messages as well, it just doesn't evaluate root any further, even though it seems to when we attempt to instantiate a root after getting likelySubtag data (which matches it to "en").

[rxaviers]

@lamp1440 I am back to your issue and I have provided this a fix. Please, see the example at https://github.com/jquery/globalize/blob/6d3a5a57c56fd0afb93e20340905a435d1650341/doc/api/message/load-translation.md#example

Just let me know on any problem.