There remains the question of how to exactly design a language
selector that everybody can understand. All I can say is the
aforementioned "real websites" offer very good examples there on the
footers of their pages!

http://www.google.com/ 's approach is somewhat different... but still usually there at the bottom of the page.

We currently have 380 languages, So you would need to store a cache for each
one of those languages (depending on your setup), You would need a nice
language selector.

Although I don't see the need in most cases, Since in most wikis I have come
access, The user language is usually the same as the content language.

This would be absolutely trivial to do in a cache-friendly way... in a sufficiently redone JavaScript application UI. But I don't think jidanni would find it to work in lynx. :)

(In reply to comment #4)
No worry, I'm with the 99% on this issue. What's good for the real sites is good for me!

There's a major difference between Wikipedia and those sites you listed: Wikipedia has different sites for contents in different languages, and those websites have an only global site with contents in mixed language.

So on those websites, people using completely different language use the same site, so it's important to provide a language selector. While on Wikipedia, normally (I mean, except for those people doing crosswiki work) only people who know the content language come to the site and since the interface language defaults to the content language, it's safe to assume that people can understand the default interface language.

However it can be useful for wikis with mixed contents, eg, http://wikimediafoundation.org/wiki/Home .

just a slight note from the IRC channel, for anyone that may want to attempt this:

[11:31] <p858snake|l> brion: I believe commons tried to do it a cache friendly way and couldn't get it to work properly for anons (although we have a slightly more complicated cache setup than normal)
[11:33] <brion> p858snake|l, yeah the "right" way is to make the frontend a javascript app that uses the api, and only has to fetch UI messages once etc ;)

(In reply to comment #6)

There's a major difference between Wikipedia and those sites you listed

So how would you suggest owners of read-only databases who would like
their database to be accessible in more than one language proceed? Hack
up some xx.example.com massive redirect nightmare? One can't always
assume "well the content has that problem too" so there is no need to
make the interface accessible. I mean I keep reading about the efforts
to make things internationally accessible, e.g.,
http://blog.wikimedia.org/2012/01/09/end-of-sprint-6-translate-and-other-goodies/
but at the same time there is no path in ones language from a MediaWiki
Main Page through the many steps to set up the correct preference... if
indeed a given MediaWiki allows logging in in the first place.

By database I mean e.g., a ham radio frequency database or a database of Latin names for plants, etc. that the owner has chosen to use MediaWiki as the platform.
I.e., the content is just numbers or other language neutral items, so why can't the interface (MediaWiki) be language neutral from click 1?

There are some efforts going on designing a language selector UI by integrating language tools to it. See https://www.mediawiki.org/wiki/Universal_Language_Selector for a draft specification.

I'm just going to mark this as fixed. ULS provides this functionality, and there is no mention about WMF where this functionality cannot currently be enabled.

(In reply to comment #11)

I'm just going to mark this as fixed. ULS provides this functionality, and
there is no mention about WMF where this functionality cannot currently be
enabled.

Fixing dependencies and component then.