Honor browser's locale when able

[mgarciaisaia]

The application always start in English. The user has to close the demo window, close the level selector, figure out that little circle is an Earth icon, understand it is a locale selector, pick his language, and just then starts understanding what he's being told.

It would be superb to default the language to the browser's preferred languages setting as much as it's possible.

[pcottle]

I'd love to do this -- unfortunately we dont have the HTTP headers available:
http://stackoverflow.com/questions/673905/best-way-to-determine-users-locale-within-browser

but do you think using the navigator language would be enough?

[mgarciaisaia]

Oh, thats a shame :(

I don't think the navigator language would solve this, but it could be better than nothing - I tend to use applications in English, but that's because I do understand English. If I didn't, I surely would be using them in Spanish.

But I think it would be better to take a shot with this service someone created for a scenario like this one.

Or, if not, to just offer some more-global menu with the locales, accessible even when the demo dialog is shown. If we can't make a real good guess, just let the user choose :)

[pcottle]

Ah yeah, that's a great find! Relying on a 3rd party service isn't ideal / slightly worrisome but I'll probably:

• start the app in en_US
• fire off a request for the headers
• if the request comes back valid and we the top language is a supported translation, switch to that (hopefully within the first few seconds)

sound good?

[mgarciaisaia]

We should test how it works, but, yes, sounds good.

I don't know if it would be better to start the app in the navigator locale, maybe. And I think none of this should avoid offering the language selector in a more visible way, accessible even when the dialogs are shown. Maybe we could add that as a separate issue.

[pcottle]

I don't know if it would be better to start the app in the navigator locale, maybe. And I think none of this should avoid offering the language selector in a more visible way, accessible even when the dialogs are shown. Maybe we could add that as a separate issue.

Right now the UI updates to locale changes live, but dialogs will not since they are sliced out from the INTL strings before generation / display :( thats part of the reason why I kept the locale changer behind the dialog view -- basically you would change locale and not see a difference until you closed the dialog and launched something else.

Intelligent defaulting though is a great start, lets try that

[pcottle]

Aight the headers fix is in production now! I tried out a few by changing my browsers language and it seemed to work like a charm

hope that helps!

[pcottle]

We have a messy mapping between locale and language (and I haven't been as strict as I should when people add translations) but it's not the worst and definitely a better start.

i still respect the URL params though if those are selected

[mgarciaisaia]

Hey, that's (even more) awesome!! :)

About the mess, I think it would be best to have the two approaches: first try using the whole locale (ie, es-es), using it in a standarized way (say, all lowercase divided with a _), and if that doesn't exist, fall back to just the two first letters (lang-code).

Today it just only concerns Chinese speakers, as there are two Chinese locales implemented (and with just only we are referring to a third of the world's population :)), but it more appear, it would be nice to handle them elegantly - say, an Spanish person would suffer a bit using my Argentinian translation.

I'm having really too little time to help with this :/

But, what the heck, this is awesome, Peter :)

[pcottle]

Nah you're right @mgarciaisaia -- I shouldn't take shortcuts, and the differences for the chinese locales is pretty significant.

It's tough because I receive an array like
["zh-CN", "zh;q=0.8", "zh-TW;q=0.6", "en-US;q=0.4", "en;q=0.2", "ja;q=0.2", "es;q=0.2", "ko;q=0.2"]

so some entries are a full locale string and others are just a language. But I just added a commit to handle the chinese chase for sure -- it adds another layer of mapping which is unfortunate but this whole project seems like a giant monkeypatch :P

[pcottle]

I do default to zh_CN if I only receive the zh language string, but now if one of the locales is specified before the other, I will intelligently select it! wohoo. Think this issue should be closed for good now

sorry for the long delay -- I seem to like doing issue sprints rather than constantly fighting off the slow drip of issues

[mgarciaisaia]

Hey, Petter, what you've already done is soooooo enough in so many ways that you shouldn't event think in apologies... :)

Thinking about the ideal case, I think the point is if it's better to show the second chosen locale, or an alternative locale to the primary language. Say, if the user chose es-ES, en-US, would he prefer es-AR or en-US, provided there's no other es-XX locale?

I don't even know if there's a generic answer to that question - I think most Spanish-speaking people would be good enough with a different locale (or, I think, English-speaking people would be the same, as there are subtle differences but the core of the language remains understandable) , but maybe that doesn't stand for Chinese-speaking people.

@mikhailusov, @xielingwang, @twmht, any other opinion about this?

[pcottle]

Yeah it's a bit of a grey area. The differences between en-US and en-GB are trivial for actual comprehension but I think that's one end of the spectrum. The differences between zh-CN and zh-TW` are probably the other end (actually introduce comprehension difficulties), or at least it seems that way from what I've heard. Would love some other insights though :P

Since I'm still relying on language for all other locales, if a user choses es-ES and en-US they will get the es-AR experience. That's off the assumption that for all non-chinese locales, the language matters more than the localization experience, but who knows! I could switch behaviors but I imagine we start splitting hairs at that point -- and the user can always of course change the locale in the command line / via the UI :P

[mgarciaisaia]

Totally agree.

I was just dreaming out loud - it would be super-duper-awesome to solve that, but what's already there is extra-cool anyway, so it's not a real priority, I think.