In T352695#9384102, @kostajh wrote:

@Lucas_Werkmeister_WMDE thanks for filing this. I see the same behavior when running extensions/DiscussionTools/tests/phpunit/ThreadItemStoreTest.php, I am on MariaDB 11.1.3.

None of the extensions had any composer dependencies that needed updating. The remaining outdated dependencies for WikibaseQualityConstraints are blocked for the same reason as for WikibaseLexeme: https://github.com/wikimedia/mediawiki-extensions-WikibaseLexeme/blob/master/README-dev.md#chore-dependency-updates

Everything that we can update has been updated.

There are no outdated composer dependencies.

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?

As far as I can tell, the string dlc no longer exists in the cldr extension, so I think this is done indeed.

As far as I can tell, this task is "Done" by virtue of the root cause being identified: the Primary Sources gadget being broken. (see also T237925: Primary sources tool left without maintainers)

See https://wikidata.beta.wmflabs.org/wiki/Lexeme:L4563 for a prepared example.

See https://github.com/wmde/new-lexeme-special-page/pull/579

@Tchanders Thank you so much for those details! This helps us a lot with planning the next steps better 🙏

Thank you! 🙏

I tried it out (check experimental) on a Wikibase change and it quickly failed with the following:

This is not great yet, but the list is a start. It contains things for us to work through and add tests as needed. Additional tests obviously will be needed/added for all the code we touch. This is list is more for the overall due diligence.

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?

In T352109#9362696, @Manuel wrote:

@ItamarWMDE , @Michael, @Lucas_Werkmeister_WMDE : Is this about the main repo or about the clone T351072 that you found?

@Aklapper Please review the script that you're using to create these tasks. The pings via Phabricator accounts did not work. (At least I assume that was intended to be phabricator pings from the context.)

Then I misunderstood it moving forward. I'm sorry, my bad!

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".

Not sure where to move this. We can pick it up again in the new year and click +2 on the change that drops the styles.

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.

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

In T351974#9357702, @Lydia_Pintscher wrote:

@ItamarWMDE @Michael I'm not entirely sure what the current state is. Can you help me flesh out this ticket?

There is a whole bunch of API endpoints and Special Pages on the Wikidata side of things that do changes that currently cause an anon user's IP address to be logged and displayed. Many, but not all of them go through repo/includes/EditEntity/MediaWikiEditEntity.php and I guess WIP example: Create a temporary user from ApiSetClaim (I57075e88) outlines the fundamental work that will need to be done, eventually.

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).

It would be better if the browser settings (Accept-Language) and/or geolocation would be considered.

On that Grafana panel, I wonder if we do not want to switch the axis for Forms and Lexemes. We have way more Forms than Lexemes. So Lexemes are by default almost invisible as are all the other Entities that are not Forms. Or maybe switch to a log y-axis?

What version of Wikibase are you running?

In T348831#9356360, @Lucas_Werkmeister_WMDE wrote:

It fired (and resolved) four times yesterday afternoon btw: ca. 13:47, 14:47, 14:52 and 16:10 (all UTC; grafana_state_reason = NoData each time).

I wonder if it would make sense to change the query from “now-5m to now” to “now-6m to now-1m”? I don’t think we usually respond within a minute anyway. (But I don’t know if that would make NoData conditions less likely.)

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.

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.

Side note: How come https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/WikibaseLexeme/+/605c2ed9bde1b624f76eab833f4c0e33c6640de0/resources/special/new-lexeme-dist/SpecialNewLexeme.cjs.js did not get picked up by the above search? This file is directly checked into the WikibaseLexeme directory as a normal file, and it contains the string compatConfig a bunch of times. 🤨

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.

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.)

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

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?

In T230729#9352305, @awight wrote:

Can I ask where the evaluation results landed? I see that the blog post mentions some trouble when getting Cypress integrated into Wikimedia CI, was there any other activity we can learn from?

My context is that my team has tried Cypress locally and it seems good--better than selenium, we have a docker command which can run the tests headless, and I see a small amount of cypress peppered around Wikimedia repositories, mostly in an experimental way.

Those numbers look good! Now I'm expecting a sharp increase in Grafana for our panels about counting forms and senses.

Special:BadTitle/M123 would be also ok with me. For me, it would be not so much depending on the entity type, but rather that it should have some sensible "not found" response. Redirecting to the (missing) page of a non-exisitng entity is sensible. Showing a completely unrelated page just because its page-id happens to match the numeric part of the entity-id is not sensible to me.

There seems to be a problem with LibraryUpgrader, see: T345930: LibUp hasn't run since 5 June 2023. Should we somehow mention that in the respective section of the README as well?