Last modified: 2014-07-07 11:30:08 UTC
I propose the creation of a magic word {{CURRENTCONTENTLANGUAGE}} returning the language of the current page. It would be particularly useful for the Translate extension (probably the only way to currently set the language of a specific page, in the translations) in order to better localise the translations. For instance a date could be localised in the translation using a syntax: {{#time:j F Y|2013-10-02|{{CURRENTCONTENTLANGUAGE}}}} This would give "2 October 2013" on the English original page and "2 octobre 2013" on the French translation, without the need of asking the translators to translate it. If no language is indicated, the user language is used (possibly different of the page content language), leading to the same sentence (e.g. in English/site-wide content language) on each translated page; currently, for instance, an anonymous user would always see the same sentence (in the side-wide content language) even on a translated page.
I implemented an Ersatz of such a magic word on Meta [[meta:Template:CURRENTCONTENTLANGUAGE]], and [[meta:Module:Template translation]] also internally implements this behaviour.
The Translate extension already sets the page content language, so this tag is should not needed on translatable pages. If there is valid use case, it should rather be called pagelanguage or pagecontentlanguage.
The purpose of this magic word would be exactly to retrieve this property "page content language" for use in the translation in order to obtain a final page with everything in the translation language (opposed to some things in the source language or the user language). I have no preference for the name of the magic word; I chose this one because there exists {{CONTENTLANGUAGE}} (site-wide) and to differentiate the proposed magic word from this site-wide magic word.
(In reply to comment #3) > I have no preference for the name of the magic word; Good; switching summary. > I chose this one because > there exists {{CONTENTLANGUAGE}} (site-wide) and to differentiate the > proposed > magic word from this site-wide magic word. Actually, apart from [[mw:Help:Magic words#Date and time]], the only CURRENT* magic word *is* site-wide: {{CURRENTVERSION}}. We have a few PAGE* magic words for properties of the current page, so that's consistent; I don't think that users need to learn MediaWiki jargon like "content language".
Ideally such a magic word should also return the selected language ("data-language"/"data-targetlangcode" not the same as $wgPageContentLanguage) from Special:Translate so that documentation messages using the magic word renders as expected. I.e. from https://translatewiki.net/w/i.php?title=Special:Translate&group=core&language=es&filter=&action=translate it should return "es". [Can be broken out as a separate bug if you feel its to far from the original request]
To clarify, page language, user language and content language are three different types of languages (content language already has a magic word). Its possible for a specific page to have a user language, content language and page language that are all different. Its kind of unclear which language type this bug is about.
I don't think it's unclear at all. :P The bug about user language has existed for a long while and it's separate.
The high number of involved languages in a page is a bit difficult to follow. In my mind, this bug is about the "page language", i.e. the "content language of the specific page". Perhaps this magic word would have been better named as {{CONTENTLANGUAGE}} but unfortunately this is already reserved for the "global content language" (i.e. generally "en" for multilingual wikis), and I don’t think it’s possible to modify its meaning for compatibility reasons. Thinking more about this question, this new {{PAGELANGUAGE}} magic word could have two or three different meanings from the point of view of the template transclusion: 1. either the page language of the frame (when the page is used as a template), 2. either the page language of the final displayed page, 3. either the whole stack of the page language of the different frames. We should choose what meaning this magic word will have. For the third possibility, it could be added a parameter to specify which frame is wanted: e.g. {{PAGELANGUAGE:0}} for the page language of the frame, {{PAGELANGUAGE:1}} for the page language of the parent frame, and {{PAGELANGUAGE:Inf}} for the page language of the final displayed page. I don’t think the third point would be useful, but anyway it would be more difficult to manage from the caching point of view; the second point would be also difficult from the caching point of view since it would add a parameter external to the rendered page.
Imho the more intuitive and practical meaning of this magic word (by reference to my comment 8) is the first: page language of the frame. Hence the pages, called as template, would have a consistent language even if called from a page in another language. For instance a template could be translated in Arabic, called from an English page, and an expression {{#time:j F Y|2013-10-02|{{PAGELANGUAGE}}}} would be displayed in Arabic -- in fact I find the default language should be Arabic in this case and not English as it is currently the case, but this would be another bug. It is also easier to implement since there are no caching problems. With this solution, the entire logic for choosing the better fallback language of a template is let to the calling page (e.g. with the resolution of the bug 45096, or with the fallback mechanisms already on Commons). It would forbid the conversion of the templates to auto-select the better language according to the displayed page, but I don’t think it would be a drawback since it’s a new feature, and there are already hacky ways to achieve that if one wants (e.g. by parsing {{PAGENAME}}).
I just wanted to say that today I copied Seb35's [[meta:Template:CURRENTCONTENTLANGUAGE]] and [[meta:Module:Template translation]] to my personal project because they provide what I was looking for: a way to create templates that offer content in the same language as the page where they are rendered. If someone has a multilingual wiki, it is only a matter of time that they will miss this type of multilingual templates. fwiw, the template (transcluded) in action: https://espiral.org/wiki/Special:MyLanguage/Spiral:News PS: I started searching in [[mw:Help:Magic words]], then in the [[mw:Extension:Translate]] documentation, and somehow I ended up in Meta, in some page linking to this bug report where I was already CCed. :)
Also see bug 53756 comment 2 in the bug report about the PageLanguage extension. Request sounds like one potential implementation for bug 9360 to me.
