LCIDs in the URI remove ambiguity about which language to serve (do you use Accept-Language? Or IP sniffing? Or user prefs in cookies?), they remove ambiguity about which storefront to show for a market and - most importantly - they make alternate language/markets indexable by search engines because each has a distinct URI.
Why are Apple, IBM, Amazon, Google doing it if it's such a terrible design?
> do you use Accept-Language? Or IP sniffing? Or user prefs in cookies?
How do you think they picked which language to serve me in the first place? ;) What you're saying is true about eliminating ambiguity but parent commenter just linked to microsoft.com.
When I had to do this for a site, the waterfall I settled on was:
1. Did they just manually pick a language/is it in the URL? (serve that language, set cookie)
2. Do they have a cookie? (serve that language)
3. Do we support any of their Accept-Language prefs? (serve that language, set cookie)
4. Serve en-us (fallback)
My points being a) Microsoft.com is using langauge-accept (probably) and b) you can support URL picking & language-accept and not always have an ugly URL.
EDIT: oops, changing my language to ``es``, clearing cookies & revisiting microsoft.com didn't change the language. I guess they are just serving everyone at .com English :p
Accept-Language is clearly the correct solution. It's easy to set in browsers (at least it is in Opera, if it's not in some other browser then I contend that's a UI bug), and OEMs should set it to a sane default for the region in which the browser is distributed.
The indexability is an interesting argument, but my response is that there should be a standard mechanism to query, via HTTP OPTIONS, in which languages a resource is available. By doing so, a user agent or search engine can easily index all versions of a resource.
Whether or not such a standard exists I do not know, but Google certainly has the clout to standardize such a mechanism (viz. sitemaps and #!).
Unfortunately Accept-Language simply doesn't work - if you talk to engineers at Google they'll tell you that they've done the research and an enormous number of browsers have the incorrect setting and hence send an inappropriate header.
What would you propose when, as translations have to be done manually, the available content for different pages is out of sync?
For example, maybe that latest product announcement hasn't been translated to French yet. If I send a product list URL to my french-speaking buddy, should the product disappear from the product list?
I guess it relates to the issue discussed here a day or two ago about redirection ("am I suddenly Japanese" or something like that; should have been "think I'm turning Japanese" ...). The default.aspx could be an affirmation of the backend being used so that when you see that elsewhere you know the server tech is MS, a sort of advertising/brand presence decision.
What I find interesting is that the new logo is not on the en-gb or fr-fr pages in the header bar and they use the old Microsoft trademark typeface. They also use the old Windows logo on, it seems, all but the en-us page. Complete mess in terms of brand presentation.
The default.aspx could be an affirmation of the backend being used so that when you see that elsewhere you know the server tech is MS, a sort of advertising/brand presence decision.
I thought of that too, but that's sort of like Toyota advertising what sort of engine a car has by leaving the muffler off of all the showroom models. Gearheads can tell the engine by the cacophony in the showroom lot, but everyone else will get the impression that Toyota's cars are noisy.
That will happen more as they move from Asp.net webforms to ASP.NET MVC. the aspx extension has become shorthand for "someone still needs to upgrade that"
What is wrong with that url (except default.aspx)? It's widely used and I like if I'm not forced to some region or locale based on my IP and Accept-Language. Well, I still am but I can change it easily if they give me this url (or even better link on a page).
Accept-Language is trivial to change; on Opera, it's one of the three things on the first tab of Preferences, and I can set it for all sites rather than on a per-site basis.
The content is (should be) identical, and the recipient of your link would most likely want to read the content in his/her preferred language.
If you really wanted to point out to them some discrepancy in the content of some particular language, then just tell them "switch your language to Chinese and look at xxx here".
On sites where linking to a particular language version of some resource makes sense (e.g. Wikipedia), by all means, accept a ?lang=de parameter… it's exactly as much mechanism as a directory component, but it doesn't imply any hierarchical structure, and can be dropped to obtain a "canonical" URL.
Microsoft itself provides a prime example for this: Knowledge-Base articles are often poorly translated and you really want to link to the english version if there is no translation available. Implicit content switches are really bad for the user experience.
Also, language versions of big websites often differ hierarchically as well, with the differences in hierarchy being directly bound to the language. On Wikipedia, the problem is so big that it is actually moved to the domain (the highest level of the hierarchy).
(should be): yes. It should be. In the ideal world of people that constructed RFCs. Sadly, there is a real world out there.
In the end, with my users hat on: I don't care. I want to send a link and I assume that my peer sees exactly what I see. I don't want to care about the details of your technical implementation of your website and whether it is structurally sound in the grand scheme of the interwebs. I also don't want to say "and switch to..." every time I send a link.
Not to mention it won't even load for me; I guess they don't cache this stuff either.