Update index.js

[tomekstach]

Fix problem on Safari with short codes for some languages e.g. pl-pl

[stasm]

@zbraniecki Can you take a look at this please?

[zbraniecki]

That's not how we want to solve it. We want to do the proper language negotiation. With Intl.getCanonicalLocales, we can do this fairly cheaply, but we really want Intl.getParentLocales as well - tc39/ecma402#87

We can't just remove '-' because it often will mean we end up with different/wrong locale ('zh-TW' can't be shortened to zh)

[tomekstach]

@zbraniecki Yes, but Intl.getCanonicalLocales doesn't work in the other browsers (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/getCanonicalLocales). If your idea is to prepare something similar to the Intl.getCanonicalLocales from scratch?

[zbraniecki]

I'm arguing that the solution to your problem is to provide proper language negotiation, not a dummy one. Proper one requires locale canonicalizations and the API in question is being implemented for other browsers and we may have to polyfill it for a while.

[tomekstach]

OK, I understand that you are talking about algorithm for finding the parent locale https://github.com/rxaviers/cldrjs/blob/master/src/bundle/parent_lookup.js#L7-L26
I will try to use it instead of the code which I prepared.

[tomekstach]

@zbraniecki Sorry, but I am too short for this.

I used cldrjs and I loaded likelySubtags.json but I always get null when I run
var langCode = new Cldr(languages[i]); languages[i] = langCode.attributes.bundle;

If I run
var langCode = new Cldr(languages[i]); languages[i] = langCode.attributes.minLanguageId;
I get en for pl-pl in Safari.

[tomekstach]

@zbraniecki What do you think about this #132 ?

[zbraniecki]

same as the original [0] language negotiation strategy - that we're not ready to inflate the bundle size that much to carry it with us.

What we could do is a naive implementation that does:

1. to lower case (instead of full canonicalization)
2. builds a ParentLocale list ('ab-CD' -> ['ab-CD', 'ab'])
3. does part of [0] -PrioritizeLocales, LookupAvailableLocales and BestAvailableLocale but without the regexp step in LookupAvailableLocales

That would give you a reasonable language negotiation that covers your need without inflating our library too much.

[0] https://github.com/l20n/l20n.js/blob/v1.0.x/lib/l20n/intl.js

[tomekstach]

@zbraniecki thank you very much :) [0] is a wonderful example of the 'RFC 4647, section 3.4.' implementation - I was looking for something like this!

I have only one questions to you: why you wrote 'to lower case (instead of full canonicalization)'? What you mean? E.g. if I get 'en-US' that I should change it to the 'en-us'?

[zbraniecki]

I have only one questions to you: why you wrote 'to lower case (instead of full canonicalization)'? What you mean? E.g. if I get 'en-US' that I should change it to the 'en-us'?

Because the full canonicalization requires a lot of regexp code that I'd prefer not to ship with our bundles at the moment.

E.g. if I get 'en-US' that I should change it to the 'en-us'?

That would be my idea. Alternatively, you can make it so that the second token is always capitalized, and the first is always small caps and leave it at it.
I'm trying to find a way that provides basic language negotiation without the whole boilerplate.

[tomekstach]

OK - I will try to do this.

[tomekstach]

@zbraniecki Please look at #136 and #137. Sorry but I am fresh and I don't know how to combine 2 commits in a one pull request :-/

[tomekstach]

Hi, any updates on this?