What is the best place to display the language in your URL?

Question

I have a multi-language website that makes use of pretty URLs, so called search-engine-friendly URLs.

Now there are a few places to define the language in the URL:

1. • www.example.com/en/articles/random
   • www.example.com/nl/articles/random
2. • en.example.com/articles/random
   • nl.example.com/articles/random
3. • www.example.com/articles/random?lang=en
   • www.example.com/articles/random?lang=nl

Is there any preferred way of showing this, or is there another better way that I did not include?

Tilghman

In addition to language, for some sites you may also care about country, e.g. en-us or en-ca or en-au, if your content varies based on country as well as language. – Prophecy

Country code should be uppercased, eg. en-US. – Cenobite

If you know one, please add a source for the recommendation to use uppercased country codes. – Plaided

Answer 1

I have found a nice resource from Google on the choices you can make. There is a section with pros and cons of each method you can use.

I have been struggling with the multi-lingual websites for a while now.

There are definitely some points in the article that are not mentioned in the answers mentioned. That why I felt the need to post this as an answer. I hope this helps someone out.

Tilghman

Here's another related Google blog post: How to start a multilingual site – Tellurian

Here's a third Google blog post, from 2010 (the one I mentioned above is from 2008): Working with multilingual websites – Tellurian

Answer 2

I'll tell you what is NOT best practice - using parameters (3rd one). Making users type a complicated URL is asking for trouble.

Your pages can internally use GET parameters to find the lang, but use a URL rewrite module available in your web server to make it simple such as the 1st one - www.mydomain.com/en/articles/random

Even the second one is okay, except most users type domain name and hit Ctrl + Enter.

https://addons.mozilla.org/en-US/firefox/

http://msdn.microsoft.com/en-us/default.aspx

http://www.apple.com/in/

Mozilla, Microsoft and Apple are in three different corners of the software development world, in terms of.. well.. everything. Sometimes I tend to think that those three big guys do stuff just to disagree with each other. But if they are following a common practice, it must make sense...

Chung

interestingly apple.com/de/mac works and apple.com/en/mac (or en-US) do not mid 2024--tho Apple hasn't had decent design or software overall for years so not particularly surprising imo – Barranquilla

Answer 3

If your worry is about pretty urls for search engines, first note most major search engines are able to detect the language while parsing, so unless being in a specific language is a really important aspect, you don't really need to worry about being search engine friendly.

• Approach 1: IMHO good for when you want to launch all articles in all languages simultaneously. But then, when you make changes in one place, you'll need to go in all places and do the same change.
• Approach 2: Neat for uses like wikipedia, where different languages mean actual different websites (the articles are not translations from one another, but rather another content)
• Approach 3: Good choice if you usually launch in some language, and translations come later (Google case, for instance). You can have a language as default in case the language is not specified, or even save it in the session so you have it saved among page changes.

Vergara

Answer 4

I would like to add one we've chosen for www.openimages.eu:

4)
www.mydomain.com/articles/random.en
www.mydomain.com/articles/random.nl

But best is of course to listen to the preferred language the browser communicates in its request:

Accept-Language nl,en;q=0.7,en-us;q=0.3

and per default serve your pages in that language if its available. You can provide a switch for users to do the '.en' or '.nl'-thing.

Laaland

+1 for suggesting the tool (Accept-Language) that exists for exactly this purpose – Ashleyashli

Good idea but problem is what I should do when user types "www.mydomain.com/articles/random" and has "nl" as preferred language. Redirect to ".../random.nl" or just serve language "nl" but not redirect? Redirecting is not always good idea. It's more complicated than it at first seems :-) +1 because generally webmasters to often forgot about preferred language (eg. these ugly root pages of big corporations "select your country"). – Cenobite

Do all browsers get their Accept-Language handling right enough for that to be a viable approach? (And there's always a need to override the standard preferences too; I normally want English, but not always.) – Conventual

In our setup an editor specifies the language their publishing in f.e. an article, page etc. Their is a default choice (en), but they can change it (f.e. nl). The url falls back to the (first published) default language of a content when it is only published in one language. The default spot is www.mydomain.com/articles/random. Only when a visitor specifies a preferred language the url changes and he/she gets content in their preferred language if its available. – Berners

@Donal Fellows I believe yes that 'Accept-Language' is very common in modern browsers. – Berners

@André: In that case (my detailed knowledge of web programming is very rusty) I'd go for having the language override as an optional parameter, which is a nuanced version of #3. – Conventual

unfortunately this doesn't seem to address the scenario specific to URL paths, where the path itself is translated eg /ruta/a/ubicación vs /path/to/location, leading me to think that overall having the leading part of the path is the best place for the language code (likely ignoring it in the app routing internals--somewhat like using a versioned API); works great for static assets though, especially in a small project – Barranquilla

Answer 5

I think it would depend on your environment. Are you generating the same pages in multiple languages using a web framework with a database or do you have static pages?

In many common web frameworks (rails or symfony) you could set up routing rules for #1 that would automatically populate a parameter with the language which the controller would then use to generate the appropriate content. Three would work as well, of course but it's a little distracting in my opinion.

2 is particularly appropriate if you were causing redirection at the web server level and has the advantage of allowing urls from / without potentially "losing" your user's language setting. In other words a link to /home would take you to the correct language version of the "home" page.

One last option is to store language as a user preference in a cookie and not populate it in the url at all.

Romanticize

Answer 6

I am far away from knowing the "right" answer (I assume there isn't any) but as you ask for comments, here is mine:

A URL (or URI) is something that describes or identifies a resource. If I remember correctly the URL should not depend on how the resource should be displayed (HTML, XML, JSON, etc.).

You could also consider the language as a way to specify how the resource should be displayed.

So in my opinion, the last option, namely specifying the language as a parameter would be more appropriate.

Jacobite

Answer 7

The first one makes more sense. Because if someone wants to go to directly to you page and s/he can just type in blabla.com/en and reach what s/he wants...

Gina

Answer 8

I don't know if there's any "best practice" in this case, since it probably just comes down to personal opinion.

For me, I would tend to favour the third option since it's really the same page that's loading, you're just modifying the content with a GET parameter. Using a separate URL (rather than a parameter) would signify to me that it's a completely separate page/resource, which in this case it wouldn't be. You'd also probably get search engines indexing the page multiple times in various languages, etc. (Although maybe that's what you want).

Citizenry

I guess you haven't heard of Apache mod_rewrite or IIS URL Rewrite. – Chung

Actually I use mod_rewrite a lot. I'm not talking about the URL the server see's, where indeed mod_rewrite could be used to just populate the GET param from a friendly URL. I'm talking about the URL people use to visit the resource. The URL should identify the resource, not how it's displayed. To me, altering the language is just changing how that resource is displayed (with some obvious exceptions, like wikipedia, etc), so should be a parameter. It doesn't mean you couldn't use a friendly URL, it's just that that would mean you have separate URLs for what is effectively the same page. – Citizenry

Answer 9

Search engines consider sub-domains to be independent Web sites. I am not sure how it impacts the SEO though.

Encase

Answer 10

If you're looking for "search engine friendly" and "pretty" URLs, you should be avoiding unmasked GET parameters. They don't look as good to the eye as a sub-domain or sub-directory, and are not exactly SEO-friendly.

With that in mind, I would choose the sub-domain. You get a simple, conventional "switch" to modify the displayed language, and it's not buried in the middle of your URL. Very easy to spot and alter.

Koph

The subdomain would have other side effects though (different cookies, some search engines might think it's a different site, etc.). – Homophone

Answer 11

I would definitely go for

www.mydomain.com/articles/random?lang=en
www.mydomain.com/articles/random?lang=nl 

because is more natural to say: "this link (the full link) is in English or Dutch".

Otherwise (domain/lang/restof url) gives the impression that you have some sort of structure that contains different things for en and nl. The same applies to lang.domain/...

Rakes

This approach is the least favoured from the Google guidelines at time of writing, see the table at support.google.com/webmasters/bin/… – Plaided