I oppose this; the vast majority of wikis have no use for parsing dependent on the user's language - only a small sample of multilingual wikis do, hence there's no reason to allow it.

And T377410, T377411 and T378060 does not see much action

If you think that should be done for those wikis you are welcome to write a patch and schedule it for deployment yourself. That step doesn't require any special permissions; the fact that nobody has done so merely indicates that nobody cares enough to do so, probably because most site-request folks don't like doing changes without an explicit community discussion.

My personal opinion is that we should decline T377411 (since the comments there show it seems to be conflating two distinct concepts) and also decline T377410 and only do T378060 - that is only enable this on wikis that have either explicitly (with a formal community discussion) or implicitly (by creating MediaWiki:lang subpages) signaled they want this.

In T406057#11230969, @Pppery wrote:

I oppose this; the vast majority of wikis have no use for parsing dependent on the user's language - only a small sample of multilingual wikis do, hence there's no reason to allow it.

It is not really a problem that this magic word is enabled but unused. But it is a problem that it behaves in a way user does not expect (see point 2 in task description).

In T406057#11230987, @Pppery wrote:

And T377410, T377411 and T378060 does not see much action

If you think that should be done for those wikis you are welcome to write a patch and schedule it for deployment yourself. That step doesn't require any special permissions; the fact that nobody has done so merely indicates that nobody cares enough to do so, probably because most site-request folks don't like doing changes without an explicit community discussion.

My personal opinion is that we should decline T377411 (since the comments there show it seems to be conflating two distinct concepts) and also decline T377410 and only do T378060 - that is only enable this on wikis that have either explicitly (with a formal community discussion) or implicitly (by creating MediaWiki:lang subpages) signaled they want this.

I believe T378060: Enable USERLANGUAGE magic word on wikis using int:lang hack is not a good task - "multilingual wiki" is not a well-defined concept. Why is dewiki a multilingual wiki?

But it is a problem that it behaves in a way user does not expect (see point 2 in task description).

And it will be more a problem once we have global templates (T121470: Central Global Repository for Templates, Lua modules, and Gadgets), since having such setting makes one template unintendedly behaves differently in different wikis. This is why I suggest to remove this setting completely.

P. S. the global template proposal may also have ways to adapt templates for use in different wikis.

"multilingual wiki" is not a well-defined concept

It's quite clear what that task meant.

T378060#11231817

In T406057#11231823, @Pppery wrote:

"multilingual wiki" is not a well-defined concept

It's quite clear what that task meant.

T378060#11231817

Well, but list is not really stable (new multilingual wiki can be set up or a wiki be added int:lang hack). So I suggests preemptively enable it in all wikis even it can be unused (which has no negative effect).

But it is a problem that it behaves in a way user does not expect (see point 2 in task description).

Templates are often copied from one wiki to another and copy a template using {{USERLANGUAGE}} to a wiki with $wgParserEnableUserLanguage disabled will make template behave strangely

I disagree with the premise behind this entirely. The idea that it should be possible to copy templates from one wiki to another without any local adaptation is inherently misbegotten as I see it - different wikis inevitably do things differently. And even accepting the premise the conclusion still does not follow - templates copied from multilingual wikis to monolingual ones will switch from behaving as you would expect on a multilingual wiki (using the user language) to behaving as you would expect in a monolingual wiki (always using the wiki language).

I'm going to stop arguing with you here since neither of us are final decision makers and it's clear neither of us will convince the other one of us so there's no point.

This is a bad idea. Oppose.

(3) "Accessing the user language using this feature reduces the efficiency of the parser cache." but (a) {{int:xxx}} splits parser cache too

But there is a significant difference: the {{int:lang}} hack has to be set up by the interface administrators of the wiki; by contrast, enabling $wgParserEnableUserLanguage on wikis that don’t have {{int:lang}} set up allows any user to degrade the site performance immediately, with no consensus from the community.

(2) Templates are often copied from one wiki to another and copy a template using {{USERLANGUAGE}} to a wiki with $wgParserEnableUserLanguage disabled will make template behave strangely.

No? With $wgParserEnableUserLanguage disabled, {{USERLANGUAGE}} will expand to the page content language, so the template should just behave the same as if the user was viewing it in that language.

allows any user to degrade the site performance immediately, with no consensus from the community.

I say here again: If it is enabled in Commons, then it is not likely a big problem in other wikis.

Note that there is a lot of discussion of these points in https://gerrit.wikimedia.org/r/c/mediawiki/core/+/508295 and https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1143498 when {{USERLANGUAGE}} was added, and I get the impression that the issue was pretty decisively settled when that implementation was merged.