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.mydomain.com/en/articles/random
www.mydomain.com/nl/articles/random

2)
en.mydomain.com/articles/random
nl.mydomain.com/articles/random

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

Is there any preffered way of showing this, or is there another way better that I did not show. I would like to hear your comments on this.

Answer 1

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.

Answer 2

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.

Answer 3

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...

Answer 4

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).

Answer 5

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

Answer 6

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...

Answer 7

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.

Answer 8

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.

Answer 9

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.

Answer 10

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/...

Answer 11

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.