To clarify, you want to tag the output of a template with language code and direction, in case it gets embedded on a page in a different language? That problem doesn't seem limited to Translate.

In T224810#5233701, @Nikerabbit wrote:

You want to tag the output of a template with language code and direction?

Yes, but it may need various ways including adding raw <div>s or <span>s, as well as passing as parameter to another template (for example to {{userbox}} in the above example), so I need to get a raw language code (getting writing direction from the language code I already have is quite easy, so no extra magic word is needed for that). The difference between Translate and non-Translate translations is that translations created with the extension are not supposed to be edited by hand in their entirety, while other translations are; furthermore, they technically don’t have a master version, so there is no page to place this magic word that gets substituted on the translation pages. On non-Translate pages one can simply hardcode the language code; they are full of technical details anyway (template call, passing parameters, {{translated tag}} template on Commons etc.).

I see your reasoning, but I think such functionality would be beneficial in MediaWiki core itself, and implemented in a way that works well with the parser.

The problem is that (IMHO) it’s less useful outside of Translate, while it would need way more substantial changes, meaning it would arrive significantly later in production. MediaWiki parser (as far as I know) has no mechanism to make changes to the text based on the properties of the transcluded page (I don’t even know what it should base its decision on, as non-Translate translations usually keep their page language English), while Translate already does a bunch of changes (pasting translations, substituting translation variables etc.), and using my approach, the page title/metadata is not a problem either, as Translate is working on exactly the page which should be queried.

I’m working with various ugly hacks to work around this almost every day lately. Waiting for a perfect solution and not implementing an acceptable one creates extra work for translation admins like me, and translators as well. What’s wrong with implementing this within Translate apart from not being the perfect solution?

What’s wrong with implementing this within Translate apart from not being the perfect solution?

Maintenance overhead. I know that the parser interfaces will have changes in near future, and I don't want to add now something that may need to be rethought, even removed, due to those changes.

Also, changing anything in the wikitext markup is very difficult and takes a lot of time. I don't want to implement something that I am not sure will last a good while.

I am also reluctant to spend time on this now, to come up with a solid solution. Possibly it will make sense to think about this when preparing for those parser changes.

I feel that you don’t want to spend time on creating a maybe provisional solution, and want to get rid of the maintenance burden, so I have to spend time on creating provisional hacks, and have to accept the maintenance burden of that. I also can’t imagine what’s that difficult in replacing {{#statictranslation:}} with its value, when Translate makes much more substantial changes by inserting translations, substituting translation variables etc. By the way, what’s the near future? Patches in the next weeks? months? years? I’d also appreciate a ticket about it instead of simply “I know that”.

I recommend to watch https://www.youtube.com/watch?v=lQGfuLP9MqA. There isn't a lot of info on the details yet, but we are hashing those out in the future.

@Tacsipacsi Can you clarify if this request is different from T254486: Add magic word for translatable unit language or whether that covers this as well?

The difference is that I want to use this outside of translation units. It should, of course, always return the language of the translation, as there’s no translation unit to test for existence.

By the way, I’ve came up with another hack in the meantime using Module:Caller title (example edit)—translators no longer need to translate a translation unit which is nonsense from their POV (this also lowers the chance of human error), but calling a module each time a page containing the translated template is parsed is quite expensive (this module is used 6M+ times only on Commons, or almost 7% of all Commons pages!), and the code is not very straightforward to understand.

Ok I think I understand now. You want something like {{PAGELANGUAGE}} but which returns the page language of the *template* translation translation page.

Change 992484 had a related patch set uploaded (by Tacsipacsi; author: Tacsipacsi):

[mediawiki/extensions/Translate@master] Allow {{TRANSLATIONLANGUAGE}} outside of translate tags

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

Change 992484 merged by jenkins-bot:

[mediawiki/extensions/Translate@master] Allow {{TRANSLATIONLANGUAGE}} outside of translate tags

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

This can be tested on translatewiki.net

Documented.

Thanks, but maybe you have a mistake?

If en is used in the text of {{1/en}} (outside of <translate> tags), it returns en.

Thanks for noticing it! Fixed. However, I’m not sure if the mistake was really on the wiki page, or {{TRANSLATIONLANGUAGE}} should respect <nowiki> tags. I’d say it should respect them – although it may not be trivial to make it do so.