Set locale based on Accept-Language header #420

stardust66 · 2018-01-11T21:03:25Z

This used to be Intimaria#1.

Context

A solution to language switching discussed in Spanish translation #413.

Summary of Changes

Set locale based on the Accept-Langauge header of the request, which is usually set by the browser. According to the rails guide on i18n

The Accept-Language HTTP header indicates the preferred language for request's response. Browsers set this header value based on the user's language preference settings, making it a good first choice when inferring a locale.

Now, the language of the page will change to fit with the preferred language setting of the browser.

Change Setting

Chrome Settings

This is a good option because the header is usually set by the user's browser language preferences. Code from http://guides.rubyonrails.org/i18n.html

If the header is nil, default to English.

DeeDeeG · 2018-01-11T22:43:59Z

Thanks for re-doing this.

I did find out while working on #419 that this breaks if the user requests a locale we don't have.

Here is a screenshot when requesting the ru (Russian) locale:

We need some way of defaulting to something we actually have, probably en, when we don't have the top user-accepted language.

Fortunately there are ways of handling this, such as: https://github.com/iain/http_accept_language That is a gem we can add and then have it select the best locale we provide, selected amongst users' requested locales. I am hoping the gem lets us fall back to a default locale when we match none of the user-accepted languages, but it's not super clear so we would have to test. Seems like most browsers might accept en as the bottom choice, regardless of locale, but we don't want to break if users manually delete the en language in their preferences.

Or if this can be done without installing another gem that's fine by me.

DeeDeeG · 2018-01-11T23:07:30Z

app/controllers/application_controller.rb

+        "en"
+      else
+        request.env['HTTP_ACCEPT_LANGUAGE'].scan(/^[a-z]{2}/).first
+      end


This sets the locale to be the top-preferred locale of the user's browser, whether we have that locale translated or not. Unfortunately, if the top-preferred locale is one we don't have, users see the translation key names in the page, rather than translated strings from an actual locale.

I think we should

Go through each of the user's preferred locales and use the first one we have.

Find a way to revert to en when the user's requested locales aren't ones we have.

Can use a gem to handle this, or do it directly in custom Ruby logic.

The gem automatically chooses the optimal language to set, as the user usually provides a list of languages in order of preference. This also makes sure that the locale is set to the default when the requested locale isn't present.

stardust66 · 2018-01-12T00:06:34Z

I used the gem you suggested. With this, the locale gets set to the correct value and when a locale that we don't support gets requested, it defaults to the value of config.i18n.default_locale which defaults to :en.

We tell rails which locales we supported by setting config.i18n.available_locales.

DeeDeeG · 2018-01-12T00:48:30Z

Looks good! Going to give it a quick test with the ru locale again just to see what happens.

Also, I'm interested in possibly using language_region_compatible_from(languages). If it does what it says it's supposed to, then that would support zh_ch and zh_tw, whereas compatible_language_from(languages) apparently would treat both as the same thing. Who knows, maybe someday we will have multiple regional versions of the same language.

DeeDeeG · 2018-01-12T00:53:30Z

app/controllers/application_controller.rb

@@ -14,17 +14,7 @@ def mobile_filter_header
  end

   def set_locale
-     I18n.locale = extract_locale_from_accept_language_header
+     I18n.locale = http_accept_language.compatible_language_from(I18n.available_locales)
   end


Consider using http_accept_language.language_region_compatible_from(I18n.available_locales)?

According to this README:

language_region_compatible_from(languages): Returns the first of the user preferred languages that is also found in available languages. Finds best fit by matching on primary language first and secondarily on region. If no matching region is found, return the first language in the group matching that primary language.
vs:
compatible_language_from(languages): Returns the first of the user_preferred_languages that is compatible with the available locales. Ignores region.

DeeDeeG · 2018-01-12T01:16:21Z

Okay, it looks good. This is what I get with the ru locale preferred, followed by es-ES and es, and furthermore, I even deleted en-US and en from my accepted languages.

The site still gave me the en locale (verified in developer tools):

Edit to clarify: That's good, because on this branch we only have English. English is better than displaying only the translation key names!

DeeDeeG · 2018-01-12T02:00:39Z

This looks reallly good in further testing. First, I configured the app to believe it supported English, generic Chinese, Chinese specifically for Taiwan [aka traditional Chinese], and Chinese specifically for China [aka simplified Chinese] in config/application.rb.

config.i18n.available_locales = [:en, :zh, 'zh-TW', 'zh-CN']

Here were my results:

Preferred languages	What the site gave me	Correct behavior?
ru, es-ES, es	en	☑️
zh, ru, es-ES, es	zh	☑️
zh-CN, zh, ru, es-ES, es	zh-CN	☑️
zh-TW, zh-CN, zh, ru, es-ES, es	zh-TW	☑️
zh-CN, zh-TW, zh, ru, es-ES, es	zh-CN	☑️

Update: more testing

I configured the app to belive it supported only generic English and Chinese specifically for China...

config.i18n.available_locales = [:en, 'zh-CN']

Results:

Preferred languages	What the site gave me	Correct behavior?
zh-CN, zh-TW, zh, ru, es-ES, es	zh-CN	☑️
zh-TW, ru, es-ES, es	zh-CN	☑️
zh-TW, ru, es-ES, es, en	zh-CN	☑️
en, zh-TW, ru, es-ES, es	en	☑️

stardust66 · 2018-01-12T02:05:12Z

Thanks for all your testing @DeeDeeG!

Intimaria · 2018-01-12T22:50:45Z

Wow this is fantastic. I admire all of this work!

DeeDeeG

This works, and all tests pass in Travis CI.

Thoroughly tested in Vagrant.

Makes us ready for new translations, while being totally backward-compatible to our existing locale, which is just en.

Deletes extra copy of mobile_filter_header definition in app/controllers/application_controller.rb Missed this when reviewing #420.

…tion Set locale based on Accept-Language header. Uses the http_accept_language gem to intelligently pick the most-preferred locale we have. Makes us ready to start accepting and testing new translations. Still desirable would be to have an in-app language-switcher.

Deletes extra copy of mobile_filter_header definition in app/controllers/application_controller.rb Missed this when reviewing RefugeRestrooms#420.

…tion Set locale based on Accept-Language header. Uses the http_accept_language gem to intelligently pick the most-preferred locale we have. Makes us ready to start accepting and testing new translations. Still desirable would be to have an in-app language-switcher.

Deletes extra copy of mobile_filter_header definition in app/controllers/application_controller.rb Missed this when reviewing RefugeRestrooms#420.

stardust66 added 3 commits January 11, 2018 16:01

Correct indentation for config/application.rb

3c14d91

Set website locale from Accept-Language header

bca00e5

This is a good option because the header is usually set by the user's browser language preferences. Code from http://guides.rubyonrails.org/i18n.html

Make sure the accept-language header is not nil

39060ab

If the header is nil, default to English.

DeeDeeG reviewed Jan 11, 2018

View reviewed changes

Use http-accept-language gem to set locale

d4232c0

The gem automatically chooses the optimal language to set, as the user usually provides a list of languages in order of preference. This also makes sure that the locale is set to the default when the requested locale isn't present.

DeeDeeG reviewed Jan 12, 2018

View reviewed changes

Support different regions for the same language

b9e531d

DeeDeeG mentioned this pull request Jan 12, 2018

Spanish translation #413

Closed

DeeDeeG approved these changes Jan 13, 2018

View reviewed changes

DeeDeeG merged commit 868f53f into RefugeRestrooms:develop Jan 13, 2018

DeeDeeG mentioned this pull request Jan 13, 2018

Translations for REFUGE RESTROOMS #396

Closed

DeeDeeG added a commit that referenced this pull request Jan 13, 2018

app/controllers: Remove extra mobile_filter_header

6b36350

Deletes extra copy of mobile_filter_header definition in app/controllers/application_controller.rb Missed this when reviewing #420.

stardust66 deleted the language-detection branch January 13, 2018 12:33

stardust66 restored the language-detection branch January 13, 2018 12:33

stardust66 deleted the language-detection branch January 30, 2018 02:36

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Set locale based on Accept-Language header #420

Set locale based on Accept-Language header #420

stardust66 commented Jan 11, 2018 •

edited

Loading

DeeDeeG commented Jan 11, 2018 •

edited

Loading

DeeDeeG Jan 11, 2018

stardust66 commented Jan 12, 2018 •

edited

Loading

DeeDeeG commented Jan 12, 2018

DeeDeeG Jan 12, 2018

DeeDeeG commented Jan 12, 2018 •

edited

Loading

DeeDeeG commented Jan 12, 2018 •

edited

Loading

stardust66 commented Jan 12, 2018

Intimaria commented Jan 12, 2018

DeeDeeG left a comment

Set locale based on Accept-Language header #420

Set locale based on Accept-Language header #420

Conversation

stardust66 commented Jan 11, 2018 • edited Loading

Context

Summary of Changes

Change Setting

DeeDeeG commented Jan 11, 2018 • edited Loading

DeeDeeG Jan 11, 2018

Choose a reason for hiding this comment

stardust66 commented Jan 12, 2018 • edited Loading

DeeDeeG commented Jan 12, 2018

DeeDeeG Jan 12, 2018

Choose a reason for hiding this comment

DeeDeeG commented Jan 12, 2018 • edited Loading

DeeDeeG commented Jan 12, 2018 • edited Loading

stardust66 commented Jan 12, 2018

Intimaria commented Jan 12, 2018

DeeDeeG left a comment

Choose a reason for hiding this comment

stardust66 commented Jan 11, 2018 •

edited

Loading

DeeDeeG commented Jan 11, 2018 •

edited

Loading

stardust66 commented Jan 12, 2018 •

edited

Loading

DeeDeeG commented Jan 12, 2018 •

edited

Loading

DeeDeeG commented Jan 12, 2018 •

edited

Loading