Some wikis, such as meta.wikimedia.org, are multilingual (that is, they don't
use separate language-specific wikis in separate directories or subdomains).
Generally, each page is in a single language. However, there are two problems
with this:
1) The interface texts are always in the default language.
For example, meta.wikimedia.org is in English by default. However, when one
visits a non-English page, such as the German-language
<http://meta.wikimedia.org/wiki/Hauptseite>, the portlets and action tabs are
still in English. This is sensible if the user is logged in and has specified
English as his preferred interface language, but for anonymous users this is
inappropriate.
2) The XHTML source code incorrectly specifies that all pages are in the default
language.
For example, meta.wikimedia.org is in English by default, so the XHTML
container is specified as follows:
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"
dir="ltr">…</html>
This is incorrect for pages in other languages, and has important
implications for a variety of applications. For example, a search engine may be
misled by the incorrect language and inappropriately index the page as if it
were English, or skip indexing the page altogether because it is looking for
pages in another language. Another example: a web browser with text-to-speech
capability (for the blind, for example) may select the wrong pronunciation
settings and try to read the text as if it were English. (Editors can currently
work around this problem by wrapping the whole wikitext in <div
lang="xx">…</div> tags, though this is not optimal as some search/indexing
applications won't bother reading past the opening <html> tag to determine the
page's language if the <html> tag already specifies it.)
A solution for both these problems is to allow the user to somehow tag a page to
indicate that it is in particular language other than the default language.
Perhaps this could be done with some sort of directive in the wikitext (e.g.,
[[lang:de]] or __LANG:DE__.) However, it might be easier to implement a system
whereby wiki system administrators could simply specify that an entire
namespace, or prefix, or page title matching a particular pattern, is in a
particular language. For example, one could specify that all pages with the
prefix "de/" are in German.

At least, it has to be about the languagein which a page is parsed.
It can generally be specified inside the page by wrapping the entire page content in a <div lang= XML:lang= dir="..."> ... </div> container, but usually isn't.
I can be taken from the last subpage part of the page title such as /bat-smg for some pages on meta, for the entire MediaWiki: name space and several more so such *except for English pages*.
For some non-wmf-wikis, e.g. creative commons, it can be taken from a prefix string in the page title, such as de:
In the Multilingual MediaWiki proposal, it is stored in the data base. We must take care to keep full locales (en-scouse, kk-Cyrl, ku-Arab, ku-TR-Latn, etc.) since this may be relevant for directionalities, GENDER, GRAMMAR, sorting orders, etc.. We must implement a way to alter/reset locales inside page so as to accomodate citations across languages, true multilingual pages such as language courses etc.. We must make sure that parser hooks and templates receive both the page language and the current language at the place they are called in addition to wiki and user languages, for the same reasons.
Message handling must return the true language used. Assuming, we were marking a language switch inside a text with __lang:xzz__ and the switch back to the prvious language with __lang:*__ and there was no localization for the message xyzzy, then:
This is in french: __lang:fr__un {{int:xyzzy}} fiche__lang:*__ which means...
should render something like:
This is in french: <span lang="fr" XML-lang="fr" dir="ltr"> un <span lang="en" XML-lang="en" dir="ltr">paper</span> fiche</span> which means...
There could or should imho be an option - for multilingual wikis at least - making the interface language go with the page language by default, but that should be deselectable by users.

See http://www.mediawiki.org/wiki/Language_in_MediaWiki for the recent improvements.
Since MW 1.18 the html tag gives the lang & dir attributes of the user interface language. The page content got a lang & dir attribute of the "page content language", which is by default in most cases the wiki content language, but can be changed by extensions through a hook.

(In reply to comment #6)
> See http://www.mediawiki.org/wiki/Language_in_MediaWiki for the recent
> improvements.
>
> Since MW 1.18 the html tag gives the lang & dir attributes of the user
> interface language. The page content got a lang & dir attribute of the "page
> content language", which is by default in most cases the wiki content language,
> but can be changed by extensions through a hook.
From what I understand, this means it would be trivial to make an extension that added a special page allowing people to change the "page language" of a page.

(In reply to comment #8)
> From what I understand, this means it would be trivial to make an extension
> that added a special page allowing people to change the "page language" of a
> page.
Hmm, I don't think a special page is a good way to handle this. Imho ideally each page should have a selector where you can change the page language, which is then stored in the database as a "property" of the page, possible using [[mw:ContentHandler]] which Nemo_bis linked above.
Title::getPageLanguage() would read that data and that would set everything correctly (i.e. what I've worked on step by step the last year or so).

(In reply to comment #13)
> Id63573a7f introduces page content language as an integral part of a Page
> entity.
The patch needs rebase and it's still labeled "PoC/DON'T MERGE"; it seems it's blocked on https://gerrit.wikimedia.org/r/#/c/62227/1 getting a solution about qqq and qqx being removed from $wgDummyLanguageCodes.

(In reply to comment #14)
> (In reply to comment #13)
> > Id63573a7f introduces page content language as an integral part of a Page
> > entity.
>
> The patch needs rebase and it's still labeled "PoC/DON'T MERGE"; it seems
> it's
> blocked on https://gerrit.wikimedia.org/r/#/c/62227/1 getting a solution
> about
> qqq and qqx being removed from $wgDummyLanguageCodes.
Given that the changes don't seem related, its not that hard to rebase it in a way so it no longer depends on the other change.
(In reply to comment #9)
> Hmm, I don't think a special page is a good way to handle this. Imho ideally
> each page should have a selector where you can change the page language,
> which
> is then stored in the database as a "property" of the page, possible using
> [[mw:ContentHandler]] which Nemo_bis linked above.
By special page, I was more just thinking as opposed to a {{#page_language:foo}} parser function in wikitext. Although my original reasoning was based on what (I believe) is a misconception on page language affecting the translation of parser function magic words.

(In reply to comment #16)
> Not sure what's wanted now, but does my extension
> https://www.mediawiki.org/wiki/Extension:PageLanguage resolve the issue?
No, that extension doesn't work, at least not for the two problems originally reported. All it does is to set lang="xx" for the mw-content-text div. The language setting doesn't apply to the rest of the content on the page, such as the article title (i.e., the content of the "firstHeading" h1 element). It also doesn't apply to the top-level html element -- that still has the default xml:lang and lang attributes. The web server still returns the default language in the Content-language HTTP header. And of course the MediaWiki user interface language isn't changed.

This is tentatively fixed by https://gerrit.wikimedia.org/r/136623 , pending further polishing. We can close this when the feature is enabled by default, I guess (or is that not desired? I'm not sure if bug 22985 requires it even without Translate). Then we can see at bug 35489 what else Translate needs.
Next step: schema change and configuration patch for translatewiki.net, to test more.

kunalgrover05: Do you plan to further work on this?
(In reply to Nemo from comment #20)
> This is tentatively fixed by https://gerrit.wikimedia.org/r/136623
Patch was abandoned. Hence also removing Target Milestone which was set when linking to this patchset.

This was brought up on mailing list earlier today. I am pleased to hear that this is near completion. The Affiliations Committee has committed to helping Wikimedia movement affiliates utilize this extension to help increase transparency via Meta-Wiki. This feature not yet existing remains the remaining barrier for numerous affiliate pages.