Unfortunately using the UI language splits the parser cache by UI language, which can easily lead to an uncontrollably growing disk usage. It’s not by chance that {{UILANGCODE}} works only on translatewiki.net and not on WMF wikis. So if this feature gets implemented, we should get a green light from the Performance-Team before enabling it in Wikimedia production—and I fear we won’t get it. However, it doesn’t mean that the feature shouldn’t be implemented; if you’re comfortable with enabling it on translatewiki.net, it can be feature-flagged. If it gets green light on WMF, I’d be more than happy, as several templates use various workarounds to appear in UI language (one of them below), and they could be cleaned up.

Another hackish solution, which is widespread on mediawiki.org and Meta, and at least results in clean wikicode at the calling place (i.e. https://translatewiki.net/wiki/Project:News in this case) and keeps WhatLinksHere useful, is using a huge #switch around the actual template, like this:

{{#switch:<translate></translate>
|=<!-- here comes the actual template -->
|#default={{Archive link{{#ifexist:Template:Archive link/{{UILANGCODE}}|/{{UILANGCODE}}|}} | {{{1|}}} }}
}}

or, on Wikimedia wikis,

{{#switch:<translate></translate>
|=<!-- here comes the actual template -->
|#default={{#invoke:Template translation|renderTranslatedTemplate|template=Template:Archive link|uselang={{int:lang}}|noshift=1}}
}}

(Wikimedia wikis don’t have {{UILANGCODE}}, but they—at least the major multilingual ones—have Module:Template translation).

These codes work because the <translate></translate> code

• doesn’t create a translation unit because it’s empty, so translators don’t see phantom translation units;
• is removed in translations, so the first part (“if empty”) appears when the translation is transcluded;
• but isn’t removed when directly transcluding the translation original, so the second part (“if not empty”) appears, which then in turn transcludes the correct translations.

(Edit: if you’re to use this, pay attention to turn translation-aware transclusion off, otherwise the translation original will never be transcluded.)

There are some templates setup on GovWiki and Meta-Wiki that work around this - but this would be a handy feature to have as that method can sometimes be prone to errors. Example templates:

• https://meta.wikimedia.org/wiki/Template:MovedToFoundationGovWiki
• https://foundation.wikimedia.org/wiki/Template:Contribute
• https://foundation.wikimedia.org/wiki/Template:Babel_header
• https://foundation.wikimedia.org/wiki/Template:Archived

Thinking if implementation, should this be a property of the template, or something specified at the place of transclusion (which would require some new syntax)?

There are some templates that use the UI or the page language depending on the context (e.g. UI language on talk pages, page language on subject pages), which wouldn’t be served by this feature if the mode was the property of the template. On the other hand, they are and will continue to be served by the non-translation-aware-transclusion mode, so maybe serving this minority isn’t worth complicating the syntax.

There’s another aspect that needs to be considered: whether to apply language fallback. Currently, translation-aware transclusion doesn’t respect the language fallback chain, which is consistent with how its predecessor {{TNT}} works, but it’s different from how {{Autotranslate}} works. I think user-language transclusion should definitely apply the language fallback chain (I’m also questioning whether, since otherwise setting the UI language to a little-translated variant (de-at, hu-formal, zh-hans) would end in a mostly English interface instead of mostly using the base language. As far as I see, this is not possible with the current setup: PageTranslation\Hooks::fetchTranslatableTemplateAndTitle is called up to three times by the parser (but only twice if a redirect has been resolved before hitting our code), which is not enough to traverse the entire fallback chain (we can do only one step per call, otherwise some red template links wouldn’t be recorded). So either the parser should be more flexible, allowing us to traverse the fallback chain (e.g. by providing a by-ref array parameter to which we can add all red links), or this is the reason for inventing a special syntax.

See also T114640 where a new {{#wrapLang}} parser function was proposed.

It seems like https://translatewiki.net/wiki/Template:Related is similarly implemented as a multilingual template but it currently always renders in English. Many other templates on translatewiki.net are implemented via duplicating their markup on hundreds of subpages which are translated by hand. Maybe the way this can be implemented is via a magic word to mark the page as a transcludable translation page, which would then make transclusions be displayed in the user language if they exist? That way it would be an opt-in mechanism for wikis that enable it (still fragmenting parser cache, of course, but translatewiki.net’s parser cache is already fragmented beyond belief because of the nature of the wiki).