Skip to content

Instantly share code, notes, and snippets.

@rcillo
Last active August 29, 2015 14:18
Show Gist options
  • Star 1 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save rcillo/daded9ec4468058ce661 to your computer and use it in GitHub Desktop.
Save rcillo/daded9ec4468058ce661 to your computer and use it in GitHub Desktop.
Internationalization

Internationalization

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.

Important first

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:

  1. 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.
  2. 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.
  3. It's coherent with information architecture, where the languages is the top most information and not just some extra query string.
  4. 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

Query String

It would not be incorrect, though there are better options, as presented above.

Top level domain

Refer to item 2.

Subdomain

Refer to item 4.

User profile

It's complementary to the solution proposed here. It's one more feature, that might be build after the internationalization, if required.

Accept-Language

http://www.w3.org/International/questions/qa-lang-priorities

Another optional complementary feature. Would set the language automatically based on the Accept-Language header.

Geo location

http://dev.maxmind.com/geoip/legacy/geolite

Another optional complementary feature. Automatically change the language based on users IP.

Internationalize complete URLs

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment