Change 755445 had a related patch set uploaded (by Lucas Werkmeister (WMDE); author: Lucas Werkmeister (WMDE)):

[mediawiki/extensions/Wikibase@master] WIP: Add rudimentary version of mul language code

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

Change 755453 had a related patch set uploaded (by Lucas Werkmeister (WMDE); author: Lucas Werkmeister (WMDE)):

[operations/mediawiki-config@master] Configure `mul` language code on Test Wikidata and its clients

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

it should be possible to save mul labels in some way (even if it’s only via the API or Special:SetLabel for now)

It looks like using ?uselang=mul and then editing the termbox will also work (in fact you can do this already on Wikidata, you’ll just get an error when saving), though ?setlang=mul doesn’t work.

Change 758857 had a related patch set uploaded (by Lucas Werkmeister (WMDE); author: Lucas Werkmeister (WMDE)):

[mediawiki/extensions/Wikibase@master] Add CSS class to mul fallbacks

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

Change 755445 merged by jenkins-bot:

[mediawiki/extensions/Wikibase@master] Add rudimentary version of mul language code

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

Moving back to doing; once next week’s train (wmf.21) reaches group0, the config change can be deployed.

Change 758857 merged by jenkins-bot:

[mediawiki/extensions/Wikibase@master] Add CSS class to mul fallbacks

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

Change 755453 merged by jenkins-bot:

[operations/mediawiki-config@master] Configure `mul` language code on Test Wikidata and its clients

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

Mentioned in SAL (#wikimedia-operations) [2022-03-31T13:08:09Z] <lucaswerkmeister-wmde@deploy1002> Synchronized wmf-config/InitialiseSettings.php: Config: [[gerrit:755453|Configure mul language code on Test Wikidata and its clients (T297393)]] (1/2) (duration: 00m 51s)

Mentioned in SAL (#wikimedia-operations) [2022-03-31T13:09:13Z] <lucaswerkmeister-wmde@deploy1002> Synchronized wmf-config/Wikibase.php: Config: [[gerrit:755453|Configure mul language code on Test Wikidata and its clients (T297393)]] (2/2) (duration: 00m 50s)

For some reason, with my interface set to en-gb and mul added to my babel box, mul appears in the termbox only briefly and then disappears. It works if my user interface is set to en or de. Also, adding en-gb to my babel fixes it. Thank you Nikki for making us aware of this!

The inline search is unable to find mul labels or aliases. Also: https://test.wikidata.org/w/index.php?search=haslabel%3Amul

It feels like a workaround to have to put mul in one's Babels. We should probably enable mul in the termbox for every editor before we put it in production.

T135871: MUL - Language fallback not applied to item/property heading after editing terms will get more visible after release.

Another thing to consider: Will removal of existing labels degrade ElasticSearch result (and thus term lookup)?

In T297393#7881319, @Manuel wrote:

For some reason, with my interface set to en-gb and mul added to my babel box, mul appears in the termbox only briefly and then disappears. It works if my user interface is set to en or de. Also, adding en-gb to my babel fixes it. Thank you Nikki for making us aware of this!

I think there’s more general weirdness going on here… on my local wiki, with Babel de-N,en-3,pt-1,mul-0, the termbox goes from en-gb,en,de,mul,pt…

Filed T307808: Wikibase classic termbox (entity terms view) drops last user babel language if interface language is not in babel for the termbox language shuffle.

Using mul to indicate the preferred fallback conflates two different things: language and fallback. I would prefer to see what type of language/script is displayed as a fallback. Example: Latin (e.g. for some scientific plant name), English (e.g. for the title of some academic paper), Vietnamese (e.g. for the name of some person), or mul (e.g. for some Unicode emoticon). This would mean that in addition to the mul language code we would also need a way to indicate what language code is the preferred fallback.

The point of having 'mul' is to be able to reduce edits/per item.

A person doesn't have a different name in Vietnamese than they have in English and thus storing the name in 'mul' instead of storing it in both 'en' and 'vi' saves edits. We are not displaying either the English or the Vietnamese name but something that's true for both (multiple) languages.
Saving edits are valuable because of technical performance limits. It's also valuable because those edits take up space on the watchlist and the history of the items.

'mul' is not designed for storing information about Unicode emoticons. It's by it's nature designed for content that's language. 'zxx' would be the official code for the content that's not in any language like Unicode emoticons.

Currently, when I search on test.Wikidata https://test.wikidata.org/w/index.php?search=John+Doe+II&search=John+Doe+II&title=Special%3ASearch&go=Go&ns0=1&ns120=1 for an item that only has a name "John Doe II" in 'mul' but not in any other language its name gets displayed on the search page as "John Doe II multiple languages (Q57591)". It would be desirable to not display "multiple language" here and present the item the same way it would have been if "John Doe II" would be the English label of the item.

Thank you @ChristianKl!

In the scenario that I had in mind, we would only have the "vi" and no identical "mul" Label for that person. Instead, we would have a way to mark the "vi" Label as the general fallback (instead of only mul). I mainly noted it down for the future, as we will not be able to make that kind of change any time soon.

Good catch with the awkward search results!

In case the Release-tag does not fit, please let me know.