In order to setup Rails applications locales on a per request basis, we ought to get such information in a Restful way. That means to always include the desired locale in the URL in order to correctly share context among users through simple links.
That said, Rails internationalization guideline already provides a complete list of options from which we have to choose one. In this document I aim to explain the rationale behind the decision.
I strongly suggest using the optional scope approach, e.g. URLs would looks like "http://www.napratica.org.br/e/es/dashboard". Bellow there's a list of arguments to sustain it:
- It does not break the URLs people already use since the scope "es" would be optional. URLs like "http://www.napratica.org.br/e/dashboard" would still work as expected.
- We don't need to purchase other domains at different top levels, for example "org.es", "org.uk". This reduces the work to manage, renew and spares us from any additional costs. Remember we would be required to acquire SSL certificates and renew then as well.
- It's coherent with information architecture, where the languages is the top most information and not just some extra query string.
- It does not requires changes in web server configuration to support extra languages, as the subdomain approach "http://es.napratica.org.br" would. Besides that, it would require and extra SSL certificate if ours is not a wildcard one.
Although it might seem to be a solved problem, I suggest a complete review of URL helpers usage based on the `urlfor`, in order to preserve the scope in the URL generated. I would pay special attention to e-mails.
scope "(:locale)", locale: /en|nl/ do
resources :books
end
It would not be incorrect, though there are better options, as presented above.
Refer to item 2.
Refer to item 4.
It's complementary to the solution proposed here. It's one more feature, that might be build after the internationalization, if required.
http://www.w3.org/International/questions/qa-lang-priorities
Another optional complementary feature. Would set the language automatically based on the Accept-Language header.
http://dev.maxmind.com/geoip/legacy/geolite
Another optional complementary feature. Automatically change the language based on users IP.
We could also translate URL's paths as well, in order to provide friendlier URL's such as "http://napratica.org.br/e/es/salpicadero" for "dashboard"'s URL.
https://github.com/enriclluelles/route_translator https://github.com/francesc/rails-translate-routes https://github.com/svenfuchs/routing-filter/tree/master