Template:Pagelang
Usage
This stuff template for check language of translated subpage (for translatable pages). Used for automate substitution localized values, that will match the language of the current page. Also used to help defining text direction (with using with {{dir}}).
Called from other templates. Examples of common use in translated pages or templates:
<!--
Display the language name of the given the language code in parameter 1,
in the same language as the current translated page
with a tooltip showing the language name in the user's preferred language.
--><span lang="{{BCP47|{{int:lang}}}}" title="{{#language:{{1}}|{{int:lang}}}} ({{{1}}})"><!--
--><span lang="{{BCP47|{{pagelang}}}}" dir="{{dir|{{pagelang}}}}" class="autonym"><!--
-->{{#language:{{1}}|{{pagelang}}<!--
--></span></span>
<!--
Align the floatting image to the correct side,
depending on the language of the current translated page
-->[[File:Example|{{dir|{{pagelang}}|left|right}}|30x30px]]
Technical note
When a subpage page contains any (single or double) quotes or ampersands, it is not a valid language code; PAGENAME and SUBPAGENAME normally HTML-encodes these characters in their return value, so they are safe to use as input of #language. But #titleparts restores these quotes or ampersands by HTML-decoding them.
But then #language will produce a fatal server error when it is used with "language codes" with single quotes
- Proof
This still works:
{{#language: fr|{{#titleparts:There's a fatal bug in MediaWiki|1}}}}
This does not work either:
{{#language: fr|{{PAGENAME:There's a fatal bug in MediaWiki}}}}
Nor does this:
{{#language: fr|There's a fatal bug in MediaWiki}}
This is a critical bug of the #language parser function, and apparently a severe security issues that could be caused by some clever insertion of code in PHP after the quote.
This bug only occurs in the second parameter of #language (the target language into which to give the name of the language specified by the code in the first parameter). Only the first parameter is checked for validity, but not the second one. Here, where #language cannot find the name of the language, in any target language, it should return the native language name, as in:
{{#language: fr|invalid language}}
- français
- Word-around used in this template
To avoid this severe bug, we want to detect these damned quotes (or ampersands) in subpage names, as they are invalid anyway in any language code, in order to return an empty string and not the subpage name: such subpage name cannot be a language code anyway.
One way to detect subpages that cannot be safe language codes is to check if their value filtered by #titleparts is equal to their value filtered by PAGENAME: if they aren't equal that's because they contained ampersands, or quotes.
- Why we use titleparts and not just SUBPAGENAME ?
Titleparts is used in this template instead of using SUBPAGENAME, but using SUBPAGENAME would not avoid the bug either, because it could as well return the full page name containing the damned quotes ! (SUBPAGENAME only works in namespaces where subpages have been activated (so it does not work in the main namespace to see if it has been translated using a language code suffix).
See also
- mw:Manual:PAGENAMEE encoding
- {{TNT}}
- {{LL}}
- {{BCP47}}
- {{dir}}