In T291590#7373077, @matmarex wrote:

[…]

ResourceLoaderContext's msg() function uses inLanguage():
```lang=php, name=[mediawiki/core]/includes/resourceloader/ResourceLoaderContext.php
	public function msg( $key, ...$params ): Message {
		return wfMessage( $key, ...$params )
			->inLanguage( $this->getLanguage() )
			// Use a dummy title because there is no real title
			// for this endpoint, and the cache won't vary on it
			// anyways.
			->page( PageReferenceValue::localReference( NS_MAIN, 'Dwimmerlaik' ) );
	}

And inLanguage() turns off the interface flag!

[mediawiki/core]/includes/language/Message.php

	/**
	 * Request the message in any language that is supported.
	 *
	 * As a side effect interface message status is unconditionally
	 * turned off.
...
	 */
	public function inLanguage( $lang ) {
...
		$this->interface = false;
...
	}

This behavior was added in 2010 in commit rMWe5941506f9c3: Tidy up the class, which doesn't explain the reason why, other than asserting that it is "better handling for languages".

In T291590#7373188, @Legoktm wrote:

We phased out Dwimmerlaik in the API a few years ago in favor of Special:Badtitle/dummy title for API calls set in api.php, it's probably time for ResourceLoader to do the same. As a side-effect this would probably fix this too since no one is adding NS_SPECIAL as an extra signature namespace?

Having said that, it is a mystery to me why this is turned off by Message::inLanguage() in the first place, so we should look at why that was, and more importantly look at the current state of the world in terms of when something checks Message::$interface and how that affects MessageCache and Parser today. Once we understand that, we'll know if it is actually sensible to restore this in RL or to do it everywhere.

I did some archaeology. It appears that this behavior was added when the Parser could only parse wikitext in content language or interface language, and this flag simply controlled the target language. But since 2008 (92363755ce) you can set any target language, so clearing the flag in inLanguage() / inContentLanguage() is not necessary. There is still some vestigial code in Parser that uses the flag that way if the target language is not set (see Parser::getTargetLanguage()), but the Message class doesn't rely on that.

The interface flag has some other effects, but I don't think anything relies on them.

Change 727630 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[mediawiki/core@master] ResourceLoaderContext: Set message 'interface' flag and unique 'title'

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

Change 727630 merged by jenkins-bot:

[mediawiki/core@master] ResourceLoaderContext: Set message 'interface' flag and unique 'title'

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