Multi Language, Multi Top-Level-Domain Webapp

Given, a similar setup like ebay...

Domains:

domain.com
domain.de
domain.it
domain.ru
domain.xyz
....

BUT: A user can view the page in german and can create english content, which get's listed in the english catalogue.

My Question: How to design the language switch, url's for the webapp:

Example 1: (Like Amazon)

domain.com -> english catalogue
domain.de -> german catalogue

Example 2: (Locale inside url)

domain.com/en/ -> english catalogue
domain.com/de/ -> german catalogue (redirect the .de domain)

Example 3: (Locale inside cookie)

domain.com -> english
domain.de -> redirect to example.com/?locale=de, set a cookie

Example 4: (Do you h开发者_开发知识库ave more?)

Which one would you prefer, and why?

Thanks for all responses...

Do you have more? Of course I do. But first...

Ad 1. Amazon has different catalogs because in fact Amazon Deutschland (its German subsidiary), Amazon UK (its British subsidiary) are in fact different companies (on legal basis). Their offer tend to differ, and of course legal requirements (i.e. taxes) differs substantially. Therefore these sites are similar (I am pretty sure that they are running common software and they are using common infrastructure) but not exactly the same (DB backend probably differs).
If you are building site for similar company, it makes sense.

Ad 2. Redirect to language based domain makes sense in exactly the same case like in the first example - if you have substantially different offer for International Customers.

Ad 3. Using URL parameter and setting cookie is actually best practice but please be aware that this should only be the part of the workflow (more on this later). It especially make sense if your web site is actually exactly the same application & content does not differ for all users but you just want to translate it.

Example 4. Sometimes (see CNN) people use local domain part, i.e. http://english.example.com/, http://arabic.example.com/. This could be viewed as a variation of 3 - you would actually use some kind of URL Filter and set the language in a cookie.

Example 5. For typical Web Applications/ Web Sites (same content everywhere), in my opinion it is best to actually use some kind of Locale detection workflow. In that case, specific domain or not, you would serve the content in any language.
BTW. You might want to split your infrastructure geographically, so that server pool located in Russia responds to http://example.ru/ and these pool contain only Russian resources - in that case you would definitely use redirect. If you have one, central server pool, it actually does not make much sense.
Going back to detection workflow...

1. Detect Locale from Web Browser (after all there were some reasons for HTTP Accept-Language header to be introduced). This should be predominant: user usually want to see content in his/her language. And it is already set in Web Browser preferences, so why we want to force user to choose it again?
   After detecting the language (on whatever domain), you would simply set the session cookie, so that all subsequent requests use this information (unless...).
2. If your application holds user profiles, it is good idea to allow changing user's default UI language and Formatting language in the profile. It is also a good place to store preferred Time Zone. Please be aware, that browser Locale should be good defaults for these settings - for UI Language, you would use fall-back mechanism (I would dive into it later), so if user prefers de-AT (German, Austria) Locale, it would be simply de (common resources for German language), Formatting Locale would not fall-back, so it would be de-AT (or de_AT, depending on actual Locale representation). The Time Zone is more problematic but it is not the subject of this answer.
   Obviously this should override Web Browser's Locale.
3. You can use either URL parameter (i.e. http://example.com/index.html?lang=de) or lower level domain name (i.e. http://deutsch.example.com/) to override whatever current selection would be. This is important for two reasons: one is to allow users bookmark the link in given language, second is to allow selecting precisely given language which might be useful during tech-support sessions (imagine that some Help Desk Engineer remotely control web browser on Chinese locale - how to switch the language?).
4. Optionally, you might want to implement language switching drop-down menu. Obviously it could simply redirect to i.e. http://deutsch.example.com/.

Example 6. Some web sites, although I am highly against it, use user IP Address to assess his/her geographical location in order to redirect him/her to localized web site. Geolocation could also be used for this purpose. Again, it might make little (just little) sense if your local web sites are significantly different.

Now onto language fall-back. Usually HTTP Accept-Language header looks like:

Accept-Language: da, de;q=0.8, fr;q=0.7

The most preferred language in that case is Danish but user seem to understand German and French as well. So it would not be appropriate to fall-back to English if you cannot find resources for Danish but actually have German ones. You should walk through the list and fall-back to your application default only when nothing fits.
This also shows another problem: sometimes there is no information about country in this header. So what Locale should one use to format dates, numbers, etc? I don't think there is a good answer to this question - in that case user profiles are really a good solution. The problem is, if you already have some user base, it would be hard to force them to set up this information.