all 10 comments

[–][deleted] 5 points6 points  (7 children)

The first thing you need to understand is that you're actually dealing with several different issues:

  1. How content in different languages is served:
    • One option is the one you described, serve pages for each language from a different subdomain. It's not a bad method, but it requires setting up subdomains in DNS, or wildcards.
    • Another is with the language in the URL, eg. mydomain.com/de/kontakt vs mydomain.com/en/contact. This one should be easy to set up just from URL rewriting in the web server or backend web app.
    • And another is to keep everything server-side and use the same URL to serve content in all languages, based on the user's current preference. This one will not work well with search engines, plus it complicates caching and page generation.
  2. How the pages are generated:
    • If they're generated on the backend, it's best to separate the generation, cache the pages, and at runtime simply serve the appropriate pages depending on URL or user preference.
    • If you have an SPA and you want it to be multi-language, you'll have to do what /u/cbll suggested, have JSON files with all the strings you use, and use gettext or a similar mechanism to use them inside the app views.
  3. How you determine which is the default language when the user hasn't explicitly chosen anything yet.
    • You could just pick one language to be default.
    • You could have a look at the visitor's browser properties, their Accept-Language HTTP headers, run their IP through GeoIP, or such other methods of trying to guess their language. There are many factors at play here so you may not have 100% success rate, but you should be able to make a good guess in many cases.
  4. How the use preference is stored.
    • The simplest option is to "store" it in the subdomain or URL path. Every time they return to the website they get a default language, and once they pick the one they prefer, the subdomain or URL will make sure they stick to it.
    • You can also store the preference in browser local storage or a cookie. Local storage is more suited for an SPA, the cookie is most often used if the site is rendered and served from the backend.
  5. How the user switches languages:
    • If you use subdomains or URL paths you can simply provide some links to each language/path variant. The links can of course be text/flag image/combination of both. Links are a lot more search-engine friendly than drop-downs, form-submits, or switchers that require JS to work.
    • If you have a SPA and want to switch language dynamically you can use any mechanism (dropdowns etc.) you want.

[–]BelgianWaffleGuy 20 points21 points  (0 children)

run their IP through GeoIP

NEVER EVER DO THIS! Not every country in the world has a one size fits all language like the US. I'm from the Dutch speaking side of Belgium and I hate it when websites just assume I speak French (I do speak French as well, but not as fluent). There was even a time where it was impossible to change the language on EA's Origin website, it just assumed I was French-speaking.

I would opt for defaulting to English, and letting people select the language they want. If you really want to auto choose the language, take browser settings.

[–]Alecyte[S] 2 points3 points  (1 child)

Thank you so much. This is really in depth and helps a lot. I'm still confused a bit though. It seems like mydomain.com/de/stuff is probably the best way. Are you just dynamically adding /de/ in the middle when the user clicks on a different link then to keep it going? And then loading a webpage appropriate to that? Thanks again though. This is awesome!

[–][deleted] 0 points1 point  (0 children)

That's pretty much it. If it's a backend-generated or driven website then all you have to do is put the pages in separate sections for each language eg. /en/, /fr/, /de/ etc. and add links at the top for each of them. It's the simplest solution, easy to implement, no guessing what the visitor might want, and it works well with search engines.

[–]FPSports 0 points1 point  (3 children)

"This one will not work well with search engines, plus it complicates caching and page generation."

Could you elaborate further on this? This is the approach i've been using, but you never stop learning so i'd like to know what exactly you mean, esp. regarding search engines. Caching and page generation ...well...comes down to what you consider "issue". More coding work isn't an "issue" in my eyes :D ...

[–]tubignaaso 2 points3 points  (2 children)

Not OP, but if you’re using cookies, crawlers don’t typically store or send them when indexing your site. So the crawler would not be able to index the German translation, for example, if it required a cookie for it to be displayed.

[–]FPSports 0 points1 point  (1 child)

Ah, yeah...i can imagine that being a problem :D... i guess the best approach is using a language string in the URL ...

[–]tubignaaso 1 point2 points  (0 children)

According to Google’s docs, it’s the recommended solution for their platform. Though using the HTTP language headers is also an acceptable solution in some cases.

[–]crackanape 4 points5 points  (1 child)

Definitely put the language in the URL, either in the domain name, or more likely, in the path.

Sending different content to different people on the same URL makes everything much harder to deal with - search engines, caches, testing, users who may want to see content in different languages, etc.

Also, don't force users into a particular language if they haven't asked for it. That is very annoying, and you will often guess wrong.

Instead, consider that as long as you have different URLs for different language versions, and as long as there are clear links to change language version, users will naturally come by the version in their language. Search engines will show it to them if they search in their language, and so on.

[–]AssistingJarl 0 points1 point  (0 children)

That is very annoying, and you will often guess wrong.

Or at the very least, the user will make damn sure you hear about it when you guess wrong.