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.

I don't actually think this task is too difficult, and could be a potential Google-Code-In-2016 task. However, it might not be appropriate to insist that the patch be merged before accepting the task, because I can imagine a passionate discussion about what the variable should be called or something...

For what it's worth, {{PAGELANGUAGE}} seems like a fine name to me, and ties in well with {{PAGENAME}}, {{PAGEID}}, and friends, as well as Special:PageLanguage, the special page used for setting this property.

By far the easiest and sanest implementation would be showing the page language of the final displayed page (this is Seb35's number 2, as best as I can tell). The semantics would be absolutely identical to {{CURRENTMONTHNAME}} and friends, which you can play with at testwiki (all users can change page languages there).

As a bonus, it doesn't look we'll need to modify Parsoid! Nice.

Indeed, this should be easy to implement technically, and the final language (the language the parser is actually using for magic words, number formatting) is a good implementation.

There has been discussions that one page could actually contain multiple different languages. Thinking ahead, we might need a new parser word for getting the language of the current section we are in, or re-purpose this one. But that feature is not a blocker for this.

Actually, you might have several languages in the same sentence. For example in this Esperanto translation of the Perligata paper (work in progress), one can find:

Por diri "''{{lingvo|en|The food gave the boy the dog}}''" (La manĝaĵo donis al la knabo la hundon), oni povus skribi "''{{lingvo|la|Puero canem esca dedit}}''".

So in the same sentence you have Esperanto (main language), and both English and Latin quoted utterances (with appropriate metadata indication).

In T59603#2922741, @Psychoslave wrote:

Actually, you might have several languages in the same sentence.

This task is asking for a magic word/variable to expose the language of the current page, which has applications in the Translate system used on multilingual wikis like Meta. This page language is an attribute of the page itself, and can't be changed simply by editing the wikitext.

If you think there should be a magic word to obtain the language of the current section of text, you should file a new task for that. You'd need to provide a rationale for why that would be necessary, and you'd also need to be aware that such a magic word would be troublesome to implement.

Actually, as far I as can see, for translation units, content with several language should be a problem. But maybe others might see some problems I'm unaware of. Sticking to the example, the translation preparation might look like.

<translate>
Por diri "''<tvar|english_utterance><span lang="en">The food gave the boy the dog</span></>''" (La manĝaĵo donis al la knabo la hundon), oni povus skribi "''<tvar|english_utterance><span lang="la">Puero canem esca dedit</span></>''".
</translate>

Regarding {{#time}}, here is what I suggested to @Johan in order to make invariant in the translators point of view a recurrent message in technews which had just some date varying from one news to the other:

Maybe you could go with a solution which require some user to change the date format, and give a link to the #time documentation in the qqq inline help. Also, you probably might use an ISO 8601 formated date, and make that explicit in the qqq message. Something like:

{{#time:<tvar|default_format>d xg</>|<tvar|date1>2016-12-13</>|<tvar|format_language_code>{{#translation:}}</>}}

So some languages might reuse $default_format as is, while other will have to go through the documentation and adapt it a bit, but the next time translation should make a 100% match.

In T59603#2922894, @Psychoslave wrote:

I had a bit of a look into {{#translation:}}. It returns a forward slash followed by the language code, as you say. The colon is just a red herring: in fact, any text after the colon is ignored. The feature was added in T70385; that, the commit message at rETRA3e2b946ba, and the single example at MW.org, might be all the documentation we have.

However, {{#translation:}} returns nothing on the "main" (source-language) translation page; the leading slash renders it less useful for the Tech News #time situation [1]; on non-translatable pages it naively returns the subpage name if it happens to be a valid language code; and of course, it is not available at all on wikis without Translate installed.

{{#translation:}} certainly has its place, but I think we can offer a better solution with a new {{PAGELANGUAGE}} variable in MediaWiki core.

[1] Okay, you can do {{#titleparts:{{#translation:}}|1|2}}, but that's silly...

Change 330982 had a related patch set uploaded (by Divadsn):
Add a new {{PAGELANGUAGE}} variable for use in wikitext

https://gerrit.wikimedia.org/r/330982

I was not able to create a test in tests/parser/parserTests.txt, as my editor was crashing each time I tried to change the file on my remote machine using network shares. I will follow up this patch with the missing test soon.

Change 330982 merged by jenkins-bot:
Add a new {{PAGELANGUAGE}} variable for use in wikitext

https://gerrit.wikimedia.org/r/330982

Change 331106 merged by jenkins-bot:
Additional test for {{PAGELANGUAGE}} magic word

https://gerrit.wikimedia.org/r/331106

Sent https://lists.wikimedia.org/pipermail/translators-l/2017-January/003762.html

Thanks @divadsn and others who contributed to the discussion, I’m exited about the new possibilities it opens in the translations.

Well, I also thank you all who contributed to the discussion with more details. Without you, I wouldn't be able to implement this feature properly! :)

Does this actually work with the Translate extension?
https://meta.wikimedia.org/wiki/Special:ApiSandbox#action=query&format=json&prop=info%7Crevisions&meta=&titles=Portada%2Fes
shows pagelanguage=en which isn't correct, it should be es. Is our API lying to us?

Change 334195 had a related patch set uploaded (by C. Scott Ananian):
WIP: Implement {{PAGELANGUAGE}}

https://gerrit.wikimedia.org/r/334195

In T59603#2970423, @cscott wrote:

Does this actually work with the Translate extension?
https://meta.wikimedia.org/wiki/Special:ApiSandbox#action=query&format=json&prop=info%7Crevisions&meta=&titles=Portada%2Fes
shows pagelanguage=en which isn't correct, it should be es. Is our API lying to us?

That page doesn't use the Translate extension; it is manually translated. Someone could, and probably should, manually set the language to es using Special:PageLanguage.

API prop=info does work for actual Translate pages:
https://meta.wikimedia.org/wiki/Special:ApiSandbox#action=query&format=json&prop=info%7Crevisions&meta=&titles=Bot%2Fes
As does the {{PAGELANGUAGE}} magic word: https://meta.wikimedia.org/wiki/Special:ApiSandbox#action=parse&format=json&title=Bot%2Fes&text=%7B%7BPAGELANGUAGE%7D%7D

ok, cool. I'll make sure these examples work for parsoid.

Change 334195 merged by Arlolra:
[mediawiki/services/parsoid] Implement {{PAGELANGUAGE}}; fix language code in HTML <body>

https://gerrit.wikimedia.org/r/334195

Mentioned in SAL (#wikimedia-operations) [2017-03-08T21:27:19Z] <arlolra> Updated Parsoid to dec47257 (T59603)