Improved browser language (navigator.language) support #3904
Conversation
…ble locales Before this change, we simply generated an error. For example: - if the browser sent 'ru-RU', but Etherpad has 'ru' available, select 'ru'; - if the browser sent 'zh', but we have 'zh-hans' available, use 'zh-hans'. Fixes ether#3882.
|
Needs a rebase :) |
|
Travis CI failing with: SAUCE_USERNAME is unset - exiting. (env vars need to be set). rebased |
|
Yea, we're aware of that, don't worry about it. It's a quirk with how we do automated testing. |
|
What happens here if the user changes their language and that is stored in the cookie? Is it respected? |
|
yes, priority has not changed. Cookie language still takes priority over browser language, it's just not set to the server lang default when theres no cookie present, allowing browser language to apply. |
|
This was already the case for the home page. However pads were getting overridden to server default as if there was no existing language cookie, one was being set, using lang from settings.json. |
|
+1 should be good to merge @iquidus did you run the front end tests btw? ''/tests/frontend'' in browser. Just wanna be sure we don't miss something obvious :D |
|
passes: 96 |
|
This seems sufficiently small to pose no risk if integrated. Scheduling for 1.8.3. |
src/static/js/html10n.js
Outdated
| if (lang.indexOf('-') > -1) { | ||
| var msg = 'Couldn\'t find translations for '+lang | ||
| lang = lang.split('-')[0] // get root locale incase variant (e.g ru-RU) | ||
| if (!data[lang]) { // check root locale (e.g ru) | ||
| var l | ||
| for(l in data) { // try similar (e.g zh-hans) | ||
| if(lang != l && l.indexOf(lang) === 0 && data[l]) { | ||
| lang = l | ||
| break; | ||
| } | ||
| } | ||
| if(lang != l) return cb(new Error(msg)) | ||
| } | ||
| } | ||
| if(lang != l) return cb(new Error(msg)) |
There was a problem hiding this comment.
This code is clever.
Could you add a description in natural language of what this section is doing?
An example would be ok.
Imagine to have a nitwit in front of you.
There was a problem hiding this comment.
Also, the var is a bit flinky in such deep scopes in js, but in this case we can live without let. Just saying.
|
I have pulled in the first commit (7ec3be6), on respecting browser's preferred language on first pad load). I am waiting for the comments on the code before merging the second one (on language variants). Thanks. |
|
Thanks @iquidus. I will merge this ASAP. |
|
Merged, thanks. |
589b174
On a users first visit (no cookie present) the language cookie was being set to padOptions.lang (from settings.json on server). Removes this behavior, allowing l10n to localize based on priority (cookie, navigator.language, navigator.userLanguage, 'en'), the users first visit will instead have no language cookie, giving browser language priority unless another language is selected in the menu (setting language cookie)
77a3059
Better handling of locale variants (e.g when browser language is ru-RU)
closes #3882