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 <[email protected]>
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
> [email protected]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
--
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
_______________________________________________
Wikitech-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
