Adding the following logistics note here for transparency: The completion of this task, T345751: MUL - When editing, show the popup of the onboarding element immediately and T345750: MUL - Change the position of the popup of the onboading element is necessary to proceed with upcoming user research around MUL, for which recruitment is ongoing.

I remembered yesterday that mul can already be used on monolingual text (example):

In T345083#9356287, @Lucas_Werkmeister_WMDE wrote:

I remembered yesterday that mul can already be used on monolingual text (example):

Should the changed language name also apply there?

Wait, is it intentional that it can be used there? Monolingual text in multiple languages feels ... odd.

Should the changed language name also apply there?

The "default" behavior is an addition to "multiple languages" that is only true in the context of the term box. So in other places, this should IMHO remain "multiple languages".

Wait, is it intentional that it can be used there?

It generally does make sense IMHO to have a language code for "multiple languages" for statements (e.g. if a string combines multiple languages). But if this was intended or not, I don't know. (CC: @Lydia_Pintscher)

In T345083#9356297, @Michael wrote:

Wait, is it intentional that it can be used there? Monolingual text in multiple languages feels ... odd.

It was requested in T72205#962159 and implemented in the change attached to that task.

In T345083#9356300, @Manuel wrote:

Should the changed language name also apply there?

The "default" behavior is an addition to "multiple languages" that is only true in the context of the term box. So in other places, this should IMHO remain "multiple languages".

I tend to agree, but it’ll make the implementation a bit more complicated. Also, I suppose the wbcontentlanguages API should then return different name / autonym for mul depending on the wbclcontext parameter (“multiple languages” for monolingualtext, but “default values (mul)” for term; term-lexicographical, which with the changes from T341409 “inherits” mul from monolingual text, should probably also still use “multiple languages”).

Ah interesting! I wasn't aware that mul existed there already since 2015/2016!

@Lucas_Werkmeister_WMDE: Yes, that sounds like a good plan!

For implementing this, my idea would be:

• Add a $context parameter to LanguageNameLookup::getName(), which can be one of WikibaseContentLanguaiges::getContexts() (CONTEXT_TERM, CONTEXT_MONOLINGUAL_TEXT, or 'term-lexicographical').
• Update callers to pass the right context. (In other extensions, like WikibaseLexeme and WikibaseMediaInfo, perhaps this should happen before the Wikibase change. Or Wikibase first makes the parameter optional. Not sure.)
• In LanguageNameLookup::getName(), if the context is CONTEXT_TERM and the language code is mul, return a special message instead of using LanguageNameUtils::getLanguageName(). For the autonym, we can probably just hard-code a string.

@Michael does that sound okay? (I’m not yet sure if I like extending the LanguageNameLookup interface with that extra parameter, but I think it might be the best approach.)

In T345083#9356395, @Lucas_Werkmeister_WMDE wrote:

For implementing this, my idea would be:

• Add a $context parameter to LanguageNameLookup::getName(), which can be one of WikibaseContentLanguaiges::getContexts() (CONTEXT_TERM, CONTEXT_MONOLINGUAL_TEXT, or 'term-lexicographical').
• Update callers to pass the right context. (In other extensions, like WikibaseLexeme and WikibaseMediaInfo, perhaps this should happen before the Wikibase change. Or Wikibase first makes the parameter optional. Not sure.)
• In LanguageNameLookup::getName(), if the context is CONTEXT_TERM and the language code is mul, return a special message instead of using LanguageNameUtils::getLanguageName(). For the autonym, we can probably just hard-code a string.

@Michael does that sound okay? (I’m not yet sure if I like extending the LanguageNameLookup interface with that extra parameter, but I think it might be the best approach.)

Mh, yeah, I think this is better than overengineering it at this point. That being said, where is EntitySchema getting its language names from?

That being said, where is EntitySchema getting its language names from?

Directly from LanguageNameUtils::getLanguageName(), I think. (Also, LanguageNameUtils::isSupportedLanguage() seems to be the test for whether a language is allowed or not, so mul wouldn’t be accepted anyways AFAICT.) Wikibase’s LanguageNameLookup is only used for the LanguageFallbackIndicator when formatting EntitySchema values using their labels.

In T345083#9356523, @Lucas_Werkmeister_WMDE wrote:

That being said, where is EntitySchema getting its language names from?

Directly from LanguageNameUtils::getLanguageName(), I think. (Also, LanguageNameUtils::isSupportedLanguage() seems to be the test for whether a language is allowed or not, so mul wouldn’t be accepted anyways AFAICT.) Wikibase’s LanguageNameLookup is only used for the LanguageFallbackIndicator when formatting EntitySchema values using their labels.

Thanks for digging that up! I guess this is another thing we need to eventually align, because, as I understand it, EntitySchema is required to have the same behavior in its Termbox as Items/Properties (aside from being for now the pilot for using the Vue Termbox on desktop). I think it was also explicitly confirmed somewhere that EntitySchema will get mul too (and it makes sense). But I guess by then we can just switch to using the WikibaseRepo.LanguageNameLookupFactory service in EntitySchema as well.

Hmph, the “context” idea has a hitch: several places use LanguageNameLookup::getName() to get the name of a site language, which doesn’t really correspond to any of the existing WikibaseContentLanguages contexts. (SitesModuleBase, SpecialItemByTitle, and SiteLinksView. That’s actually more callers than the one place that gets the language name of a monolingual text language: that happens in MonolingualHtmlFormatter and nowhere else, AFAICT.)

Perhaps it would be more honest to just have a boolean flag for “is this language name used for terms or not” – after all, that’s all we would use the context for, too. We can still change it to a more fine-grained context later if we really need it.

(By the way, at least Wikidata isn’t connected to any sites that actually have mul as the language, AFAICT. metawiki, commonswiki etc. are all just set to English.)

In T345083#9356750, @Lucas_Werkmeister_WMDE wrote:

Hmph, the “context” idea has a hitch: several places use LanguageNameLookup::getName() to get the name of a site language, which doesn’t really correspond to any of the existing WikibaseContentLanguages contexts. (SitesModuleBase, SpecialItemByTitle, and SiteLinksView. That’s actually more callers than the one place that gets the language name of a monolingual text language: that happens in MonolingualHtmlFormatter and nowhere else, AFAICT.)

Perhaps it would be more honest to just have a boolean flag for “is this language name used for terms or not” – after all, that’s all we would use the context for, too. We can still change it to a more fine-grained context later if we really need it.

I guess either that or have a TermLanguageNameLookup produced by the factory. But for this single problem, I think I would still go for the boolean flag. We can always refactor it later when we get an usecase that warrants it.

(By the way, at least Wikidata isn’t connected to any sites that actually have mul as the language, AFAICT. metawiki, commonswiki etc. are all just set to English.)

Don't give people ideas 😅

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

[mediawiki/extensions/WikibaseLexeme@master] Pass NOT_FOR_TERMS to LanguageNameLookup

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

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

[mediawiki/extensions/WikibaseMediaInfo@master] Pass NOT_FOR_TERMS to LanguageNameLookup

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

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

[mediawiki/extensions/WikibaseCirrusSearch@master] Pass FOR_TERMS to LanguageNameLookup

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

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

[mediawiki/extensions/Wikibase@master] Clean up LanguageNameLookupTest

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

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

[mediawiki/extensions/Wikibase@master] Change name of mul language when used for terms

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

(Not moving into review quite yet – I’ll probably have to fix a few CI issues on Monday. Just wanted to get this uploaded before the weekend.)

In T345083#9356947, @Michael wrote:

In T345083#9356750, @Lucas_Werkmeister_WMDE wrote:

[...]
Perhaps it would be more honest to just have a boolean flag for “is this language name used for terms or not” – after all, that’s all we would use the context for, too. We can still change it to a more fine-grained context later if we really need it.

I guess either that or have a TermLanguageNameLookup produced by the factory. But for this single problem, I think I would still go for the boolean flag. We can always refactor it later when we get an usecase that warrants it.

Ah, I would have expected this to just be an evil public function getName( string $languageCode, bool $forTerms = false ): string. (Which could be slightly less evil if we were already on PHP 8)

Looking at Change name of mul language when used for terms (I7dbd94be), I wonder if it would not be better to have two new public methods on LanguageNameLookup like getNameForTerms( string $languageCode ) and getNameNotForTerms( string $languageCode ). getNameNotForTerms() would then just directly call the now private getName() method and nothing else. getNameForTerms() would check if $languageCode === 'mul' and based on that either return a special name or also directly return the result of getName().

What do you think?

In T345083#9357025, @Michael wrote:

In T345083#9356947, @Michael wrote:

In T345083#9356750, @Lucas_Werkmeister_WMDE wrote:

[...]
Perhaps it would be more honest to just have a boolean flag for “is this language name used for terms or not” – after all, that’s all we would use the context for, too. We can still change it to a more fine-grained context later if we really need it.

I guess either that or have a TermLanguageNameLookup produced by the factory. But for this single problem, I think I would still go for the boolean flag. We can always refactor it later when we get an usecase that warrants it.

Ah, I would have expected this to just be an evil public function getName( string $languageCode, bool $forTerms = false ): string. (Which could be slightly less evil if we were already on PHP 8)

That’s what I had in mind at first too, but then I realized that a constant could make it more readable.

Looking at Change name of mul language when used for terms (I7dbd94be), I wonder if it would not be better to have two new public methods on LanguageNameLookup like getNameForTerms( string $languageCode ) and getNameNotForTerms( string $languageCode ). getNameNotForTerms() would then just directly call the now private getName() method and nothing else. getNameForTerms() would check if $languageCode === 'mul' and based on that either return a special name or also directly return the result of getName().

What do you think?

Perhaps getNameForTerms() is nicer than getName( $languageCode, LanguageNameLookup::FOR_TERMS ), yeah. (It’s shorter, at least.) getNameNotForTerms() sounds strange, though. What if we just keep getName() public and add getNameForTerms() on top of it? This doesn’t force callers to choose between one or the other like the other approaches do (callers that use getName() can keep using it without even realizing the interface changed), but I think that’s okay (the meaning of getName() would be the same as before, and we already have Gerrit changes updating all the callers, so I don’t think we’re missing any).

In T345083#9358631, @Lucas_Werkmeister_WMDE wrote:

In T345083#9357025, @Michael wrote:

Looking at Change name of mul language when used for terms (I7dbd94be), I wonder if it would not be better to have two new public methods on LanguageNameLookup like getNameForTerms( string $languageCode ) and getNameNotForTerms( string $languageCode ). getNameNotForTerms() would then just directly call the now private getName() method and nothing else. getNameForTerms() would check if $languageCode === 'mul' and based on that either return a special name or also directly return the result of getName().

What do you think?

Perhaps getNameForTerms() is nicer than getName( $languageCode, LanguageNameLookup::FOR_TERMS ), yeah. (It’s shorter, at least.) getNameNotForTerms() sounds strange, though. What if we just keep getName() public and add getNameForTerms() on top of it? This doesn’t force callers to choose between one or the other like the other approaches do (callers that use getName() can keep using it without even realizing the interface changed), but I think that’s okay (the meaning of getName() would be the same as before, and we already have Gerrit changes updating all the callers, so I don’t think we’re missing any).

I was concerned that it might be confusing for someone who needs to make use of this in the future. But now I think it should be fine if we explain the purpose/usage instructions of getName() vs getNameForTerms() in their respective doc comments.

Change 977255 abandoned by Lucas Werkmeister (WMDE):

[mediawiki/extensions/WikibaseMediaInfo@master] Pass NOT_FOR_TERMS to LanguageNameLookup

Reason:

NOT_FOR_TERMS is now the default behavior for getName(), see comments on linked task

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

Change 977254 abandoned by Lucas Werkmeister (WMDE):

[mediawiki/extensions/WikibaseLexeme@master] Pass NOT_FOR_TERMS to LanguageNameLookup

Reason:

NOT_FOR_TERMS is now the default behavior of getName(), see latest comments on linked task

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

Change 977257 merged by jenkins-bot:

[mediawiki/extensions/Wikibase@master] Clean up LanguageNameLookupTest

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

Change 977258 merged by jenkins-bot:

[mediawiki/extensions/Wikibase@master] Change name of mul language when used for terms

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

Change 977256 merged by jenkins-bot:

[mediawiki/extensions/WikibaseCirrusSearch@master] Use LanguageNameLookup::getNameForTerms()

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

@Manuel @Sarai-WMDE This can now be verified on beta-wikidata.

There is one known issue that on some special pages, like Special:NewItem, in the language selector it is displayed as "default values (mul) (mul)":

I hope this is still acceptable for testing.

Oh, looking at the task description, I think we might have missed updating the copy of the onboarding popup. I'll quickly create a change for that too.

Change 977999 had a related patch set uploaded (by Michael Große; author: Michael Große):

[mediawiki/extensions/Wikibase@master] Update copy of MUL onboarding popup to "default labels"

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

Thank you, Michael! I found some minor things during testing.

Visible in the user tests:

• The copy of the popup is still unchanged.
• The linked URL is still the old one.

Not visible in the user tests:

on some special pages, like Special:NewItem, in the language selector it is displayed as "default values (mul) (mul)"

This would not be an issue for the first release, imho, and definitely not an issue for testing, thank you for pointing it out though!

There was another strange thing that I noticed: If I am not logged in, I still see the "multiple languages" string:

Purging the cache didn't help. When I log in, it works, when I log out again, it's back to "multiple languages".

In T345083#9362613, @Manuel wrote:

There was another strange thing that I noticed: If I am not logged in, I still see the "multiple languages" string:

Purging the cache didn't help. When I log in, it works, when I log out again, it's back to "multiple languages".

I quickly looked at this and I notice that in the static HTML generated by the server, it is correctly displaying "default values (mul)", but in the Termbox then rendered in javascript it still has the old values.

FWIW, I didn’t expect to be done with this yet… the wbcontentlanguages API wasn’t updated yet (as planned in T345083#9356336), and for the legacy termbox it looks like we need to update wikibase.getLanguageNameByCode.js.

Then I misunderstood it moving forward to ready for peer review. I'm sorry, my bad!

Moving back to In Development for wikibase.getLanguageNameByCode.js; the wbcontentlanguages API could be done in parallel, I think, if you want.

Hmph, wb.getLanguageNameByCode is also used for both term and non-term contexts (glosses in WikibaseLexeme), just like the PHP version, so I think we’ll have to do the same split there. Call it wb.getLanguageNameByCodeForTerms, I guess?

Is “enter a label in default values (mul)” okay as the placeholder?

In T345083#9364064, @Lucas_Werkmeister_WMDE wrote:

Is “enter a label in default values (mul)” okay as the placeholder?

Definitely not great. It doesn't feel right to break the pattern, but maybe we could say "Enter a default label"? att: @Manuel

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

[mediawiki/extensions/Wikibase@master] WIP: Change name of mul language for terms in JS

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

In T345083#9363884, @Lucas_Werkmeister_WMDE wrote:

Hmph, wb.getLanguageNameByCode is also used for both term and non-term contexts (glosses in WikibaseLexeme), just like the PHP version, so I think we’ll have to do the same split there. Call it wb.getLanguageNameByCodeForTerms, I guess?

Meh. But wb.getLanguageNameByCodeForTerms works, I agree.

In T345083#9364107, @Sarai-WMDE wrote:

In T345083#9364064, @Lucas_Werkmeister_WMDE wrote:

Is “enter a label in default values (mul)” okay as the placeholder?

Definitely not great. It doesn't feel right to break the pattern, but maybe we could say "Enter a default label"? att: @Manuel

Also, that placeholder currently defacto says "enter a label in multiple". (placeholders do not cause line breaks/ellipses, they're just cut off unceremoniously.)
So "Enter a default label" is definitively an improvement and might even be short enough in English to be shown in full.

And also the a11y aria-label doe for the mul-description in the Termbox might potentially benefit from some special handling.

enter a label in default values (mul)

It might do for the user test, but ultimately what Sarai says: "Enter a default label"

Change 977999 merged by jenkins-bot:

[mediawiki/extensions/Wikibase@master] Update copy of MUL onboarding popup to "default labels"

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

The JS patch (which I think includes mobile termbox) should be ready for review; wbcontentlanguages remains TBD (maybe tomorrow).

Change 978094 merged by jenkins-bot:

[mediawiki/extensions/Wikibase@master] Change name of mul language for terms in JS

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

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

[mediawiki/extensions/Wikibase@master] Use LanguageNameLookup in wbcontentlanguages API

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

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

[mediawiki/extensions/Wikibase@master] Use ApiTestCase in MetaContentLanguagesTest

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

Change 979320 merged by jenkins-bot:

[mediawiki/extensions/Wikibase@master] Use LanguageNameLookup in wbcontentlanguages API

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

Change 979321 merged by jenkins-bot:

[mediawiki/extensions/Wikibase@master] Use ApiTestCase in MetaContentLanguagesTest

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

We still have the literal copy "A description is not applicable for Multiple Languages." for the title= attribute of the - in the description cell for mul when viewing the legacy Termbox and the same copy for the aria-label= attribute when editing it. Should we adjust that as well?

In T345083#9378215, @gerritbot wrote:

Change 979320 merged by jenkins-bot:

[mediawiki/extensions/Wikibase@master] Use LanguageNameLookup in wbcontentlanguages API

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

This changed the API behavior a bit: The API could previously return a language name or autonym as null to indicate that no data was available; now it’ll always return some name, falling back to a copy of the language code if nothing else is available, just like the rest of Wikibase. Should we announce this change? (I think it could be considered a significant change to the API… but probably not a breaking one.)

@Michael:

Should we adjust that as well?

Yes, please! What would be a good copy? "Default values for descriptions are not applicable." maybe?

@Lucas_Werkmeister_WMDE:

Good point. I guess we should not announce it for the tests, but maybe later in our communication, before the release? (CC: @Lydia_Pintscher)

Good point. I guess we should not announce it for the tests, but maybe later in our communication, before the release? (CC: @Lydia_Pintscher)

It’s going to take effect next week, not when we release the rest of the MUL work. (And Wikidata is also affected: a bunch of monolingual text languages have language names – via $wgExtraLanguageNames, I think, see T273627 – but no autonyms: https://www.wikidata.org/w/api.php?action=query&meta=wbcontentlanguages&wbclcontext=monolingualtext&wbclprop=name|autonym&formatversion=2) So IMHO we should announce it soon, if we announce it at all.

I see, thank you for bringing this up. To understand the issue better: Who could in practice be affected by the change? If you still think that we should announce the change, what would the message be?

The affected group is anyone who uses the wbcontentlanguages API (action=query&meta=wbcontentlanguages). The announcement would be that, starting this week, the language name or autonym can no longer be null (if no better name is known, they fall back to the language code); users can remove any special code they have to handle null autonyms or language names. (On Wikidata, this only affects autonyms; language names should be known for all languages, thanks to the cldr extension.)

According to @Lydia_Pintscher we should have announced it, since that is what our policy says. But given the circumstances for this specific case, we discussed it and decided to skip the announcement.