Not to mention it won't even load for me; I guess they don't cache this stuff either.
Not to mention it won't even load for me; I guess they don't cache this stuff either.
Why are Apple, IBM, Amazon, Google doing it if it's such a terrible design?
http://www.apple.com/ca/fr/mac/
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
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 #!).
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?
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.
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.
I'm not convinced that normal people care at all about the addition of a few characters in a URL that gives away what tech stack its working on.
For example: http://msdn.microsoft.com/en-us/library/tt0cf3sx
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.
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.
Microsoft isn't the only website that does this. It seems like most websites use the URL to specify this kind of thing.