Template:Pagelang/doc

Usage
{	"description": { "en": "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 ). It is designed to be called from other templates.", "cs": "Tato šablona pro kontrolu jazyka přeložené podstránky (pro přeložitelné stránky). Používá se k automatickému nahrazování lokalizovaných hodnot, které budou odpovídat jazyku aktuální stránky. Také se používá k definování směru textu (s použitím s ). Je navržen pro volání z jiných šablon.", "tr": "Çevrilen alt sayfanın kontrol dili için malzeme şablonu (çevrilebilir sayfalar için). Geçerli sayfanın diliyle eşleşecek yerelleştirilmiş değiştirme değerlerini otomatikleştirmek için kullanılır. Ayrıca metin yönünü tanımlamaya yardımcı olmak için de kullanılır ( ile birlikte). Diğer şablonlardan çağrılmak üzere tasarlanmıştır." },	"format": "inline", "params": { "1": {			"label": { "en": "Page title", "cs": "Název stránky", "tr": "Sayfa başlığı" },			"description": { "en": "Page title to get language for. By default the title of the current page.", "cs": "Název stránky pro získání jazyka. Ve výchozím nastavení název aktuální stránky.", "tr": "Dili alınacak sayfa başlığı. Varsayılan olarak mevcut sayfanın başlığı." },			"type": "wiki-page-name" }	} }

Examples


Examples of common use in translated pages or templates:

Technical note
When a subpage page contains any (single or double) quotes or ampersands, it is not a valid language code;  and   normally HTML-encodes these characters in their return value, so they are safe to use as input of. But  restores these quotes or ampersands by HTML-decoding them.

But then  will produce a fatal server error when it is used with "language codes" with single quotes.


 * Proof

This still works:

This does not work either:

Nor does this: This is a critical bug of the  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  (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  cannot find the name of the language, in any target language, it should return the native language name, as in:




 * Word-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  is equal to their value filtered by  : if they aren't equal that's because they contained "ampersands", or quotes.


 * Why we use  and not just  ?

is used in this template instead of using, but using   would not avoid the bug either, because it could as well return the full page name containing the quotes (  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).