Template:Pagelang/doc

Usage

edit

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}}). It is designed to be called from other templates.

Template parameters

This template prefers inline formatting of parameters.

ParameterDescriptionTypeStatus
Page title1

Page title to get language for. By default the title of the current page.

Page nameoptional

Examples

edit
  • {{Pagelang}}


  • {{Pagelang|Page name}}


  • {{Pagelang|Page name/ja}}

ja

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

edit

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
Work-around used in this template

To avoid this severe bug, we want to detect 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 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

edit