This in general reminds me of
https://phabricator.wikimedia.org/T4085.
Also, if page content can vary based on user language, what to do about bug
reports that Special:WhatLinksHere, category listings, file usage data at
the bottom of file description pages, and so on don't report a
link/template/category/file that only exists on the page when it's viewed
in a non-default language? Yeah, we already have that with {{int:}} hacks,
but you're talking about making it more of a feature.
On Tue, Nov 10, 2015 at 2:07 PM, Daniel Kinzler <daniel(a)brightbyte.de>
wrote:
Hi all!
Tomorrow's RFC discussion[1] on IRC (22:00 UTC at #wikimedia-office) will
be
about my proposal to use Parser::getTargetLanguage to allow wiki pages to
be
generated in different languages depending on the user's interface
language [2].
I would like to take this opportunity to gather some input beforehand
about how
we can improve MediaWiki's support for multilingual wikis on the parser
level.
In particular, I'm interested to learn about the implications my proposal
has
for the Translate extension, the templates currently used on commons,
sites that
use automatic transliteration, etc.
Some context: Currently, MediaWiki doesn't really have a concept of
multilingual
content. But some wikis, like Commons and Wikidata, show page content in
the
user's language, using a veriety hacks implemented by extensions such as
Translate and Wikibase. It would be nice to make MediaWiki aware of
multilingual
content, and add some limited suppor for this to core. Some bits and pieces
already exist, but that don't quite work for what we need.
One issue is that parser functions (and Lua code) have no good way to know
what
the target language for the current page rendering is. Both ParserOptions
and
Parser have a getTargetLanguage method, but this is used *only* when
displaying
system messages in a different language on pages like MediaWiki:Foo/fr.
I propose to change core so it will set the target language in the parser
options to the user language on wikis/namespaces/pages marked as
multilingual.
This would allow parser functions and Lua libraries to generate content in
the
desired target language.
There is another related method, which I propose to drop, or at least move:
Title::getDisplayLanguage (resp ContentHandler::getDisplayLanguage). This
seems
to be used by wikis that apply transliteration to page content, but it's a
but
the semantics ar ea it unclear. I propose to drop this in favor of
ParserOptions::getTargetLanguage, since the display language is not a
property
of the page, but an option defined for the rendering of the page.
Another related issue is anonymous browsing of multi-lingual content. This
will
either go past the web cache layer (as is currently done on commons), or
it's
simply not possible (as currently on wikidata). I have put up an RFC for
that as
well[3], to be discussed at a different time.
[1] <https://phabricator.wikimedia.org/E89>
[2] <https://phabricator.wikimedia.org/T114640>
[3] <https://phabricator.wikimedia.org/T114662>
-- Daniel Kinzler
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
--
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation