I could also imagine adding a configurable property to the rule to list allowed qualified name prefix, so that you could allowlist RL\ and other aliases or namespaces where it makes sense.

In T307769#7939589, @daniel wrote:

@Lucas_Werkmeister_WMDE @kostajh Can you verify that my patch fixes the issue in the extension repos and merge the patch if so? We had three people quit from the team over the last couple of months and I'm having trouble finding people to review my patches.

https://doc.wikimedia.org/WikibaseLexeme/master/php/md_docs_topics_options.html

I’m not sure if T267890 is the right parent task for this, but it seems related at least. Feel free to move this around though.

We’re writing our code using Vuex at the moment (current src/store), but I think it wouldn’t be too much work to migrate to Pinia (most of our development time so far has gone into code outside the store, I’d say).

Example links on Beta:

• https://wikidata.beta.wmflabs.org/wiki/Special:NewLexemeAlpha?lemma=abc&lexeme-language=Q456518&lexicalcategory=Q593111
• https://wikidata.beta.wmflabs.org/wiki/Special:NewLexemeAlpha?lemma=def&lexeme-language=Q456518&lexicalcategory=Q593111&lemma-language=en-gb

On the Wikidata Project chat I just happened to notice another comment that’s recognized as part of a reply to it; the unrecognized comment is again unsigned, but this time on the top level:

In T308443#7931359, @Lucas_Werkmeister_WMDE wrote:

CI should be working again (I’ll verify in WikibaseLexeme in a moment)

CI should be working again (I’ll verify in WikibaseLexeme in a moment); leaving it up to @tstarling and @Reedy whether this task should stay open (for repeating the namespace move with fewer problems) or can be closed already.

The patch includes a “ResourceLoaderContext72Hack” hack class, which is apparently supposed to work around T166010#5962098. Perhaps that hack, whatever it is, doesn’t work in Phan?

Namespaces introduced in https://gerrit.wikimedia.org/r/c/mediawiki/core/+/789789 (forgot to link that earlier).

What do you mean by “cancellation”? Reverting the edit?

Include two line breaks in the source (\n\n – you can often see that in qqq.json before the list of parameters for a message, for example), then it’ll be wikitext-parsed as a paragraph break.

That would probably work, but seems like a hacky and potentially misleading solution to me (misleading because you wouldn’t want to use this prefix in a query). I think it shouldn’t be that much more effort to implement this task “more properly”, it just hasn’t been a priority for the dev team so far. If anyone wants to work on it themselves, the relevant code would probably be in wikibase/queryService/ui/resultBrowser/helper/FormatterHelper.js, formatValue() method, and it would use a new i18n message (pointing to {{msg-mw|Wikibase-snakview-snaktypeselector-somevalue}} and {{msg-mw|Wikibase-snakview-variations-somevalue-label}} in qqq.json).

With a template that transcludes as a newline, using {{#tag:}} for this seems to work well on my local wiki:

{{#tag:syntaxhighlight|#!/bin/sh{{newline}}echo "hello"|lang=sh}}

In T298150#7920905, @Lucas_Werkmeister_WMDE wrote:

Moving back to doing because I noticed we’re including the suggested items in the search offset, meaning some search results get skipped.

Pull requests:

• https://github.com/wmde/new-lexeme-special-page/pull/184
• https://github.com/wmde/new-lexeme-special-page/pull/186
• https://github.com/wmde/new-lexeme-special-page/pull/187
• https://github.com/wmde/new-lexeme-special-page/pull/188
• https://github.com/wmde/new-lexeme-special-page/pull/189

Our current plan is to sort only by descending page ID temporarily, and later sort by ascending namespace and descending page ID. So I recommend either removing the mention of the sort order from the message entirely, or to make it a bit more vague, e.g. “newer pages are listed first” (without specifically mentioning the page ID).

I would prefer to avoid interpreting the constraint too much, and limit the message to something like “Use the value video game developer instead.” The user can hopefully make a better decision about what a correct fix looks like. (But yes, making the replacement value invalid when no replacement property is given would also be an option, I think.)

Note that it’s also possible to have only a replacement value but no replacement property. Query of conflicts-with constraints with replacements. (Also, the message documentation should make it clear to translators that “instead” needs to be as vague as it is, because looking at that query, it seems like $3 should sometimes be used “instead of $1” and sometimes “instead of $2” – this needs to be left to the interpretation of the human reader of the message, I think.)

In T307328#7924922, @Krinkle wrote:

I think with that context, it might make sense to exclude maintenance categories and other categories marked as "hidden". To my knowledge as a user and administrator of Wikimedia Commons, these are primarily monitored (if at all) through navigating to that category to work off the list in real-time, e.g. categories with missing information or requests for speedy deletion etc., not through one's watchlist where it would remain long after the request for information or admin action is dealt with.

In T305517#7924810, @AnneT wrote:

Migrating existing projects that use Vuex 4 to Pinia might be low priority, but new projects built in Vue 3 that require a state management library should probably use Pinia. Should we open a separate task for this, mostly to make sure we can get a timely security review of Pinia if we decide to use it (which seems likely)?

Hrm, but Codesearch reveals the following extensions were also using Wikibase/.phan/stubs:

Marking this as high priority, but not UBN, since (I think) it only affects one extension.

Yes, my hope is that the new messages will completely replace the old ones in NewLexemeAlpha, and then we can remove the old messages together with the old special page. (But until then, we need both to exist at the same time, so we need something in the name to distinguish them – but ideally something that won’t look too out of place once the new messages are the only ones left, either.)

Fixed (UBN was already resolved with the first change, I’d say).

Well, we want to use the messages for both JS and no-JS, so that would be misleading.

We talked about this in the documentation coffee time and concluded that we can add the options in the repository for now (rendered on doc.wikimedia.org), keeping @danshick-wmde in the loop (already subscribed here). So probably docs/topics/options.md just like in Wikibase.

Moving back to doing because I noticed we’re including the suggested items in the search offset, meaning some search results get skipped.

This is live on Beta with three lexical categories: noun, adjective, adverb.

In T307443#7913378, @Lucas_Werkmeister_WMDE wrote:

Per the note in T302877, we’ll probably introduce new messages for this (since we don’t want to add the code to look up the right label to the old special page); I think we can relatively nicely insert item or itemid into the old message key wikibaselexeme-newlexeme-language-placeholder to produce wikibaselexeme-newlexeme-language-item-placeholder (likewise for wikibaselexeme-newlexeme-lexicalcategory(-item)-placeholder).

No issues detected.

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

• input placeholder texts on the JS version of the page continue to use the labels of the respective Items

I think this is done: T307869: Request for new search profile for Wikidata that boosts Items for languages

Backlog refinement note: This probably doesn’t need to be configurable, we can just replace all the code on master and let it roll out with the train.

Backlog refinement note: we probably won’t have the new search profile on Beta or Test Wikidata, but we can test this task in the dev entry point, which searches real Wikidata (as soon as the new profile exists there, potentially before the new special page is enabled in production).

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.

There’s every chance that there’s an existing task for this bug, but I couldn’t find it.

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 an alternative we should consider is to remove the mention of the sort order completely (instead of changing it to “ascending”). The descending sort order was an intentional feature at the time; the ascending sort order isn’t really a feature on its own, but is rather dictated by the requirements of the database query, which has to be efficient. What do you think?

Affected extensions include:

In T298150#7907140, @Lucas_Werkmeister_WMDE wrote:

Hm, but the search results might include one of the suggested/prioritized lexical categories even when we didn’t match it without the search API (e.g. it matches an alias while we only check labels, or it matches in another language). What happens in that case?

Unassigning myself, the patch above is failing in CI and I’m not sure what the fix is. Needs someone who’s actually familiar with what’s happening in the config schema, I think.

I can reproduce this locally (with OAuth instead of CentralAuth); git bisect says it broke with rMW67c0766a8477: Use inverted schema definition for fast loading. (Gerrit) by @daniel for T300129: SettingsBuilder: replace DefaultSettings.php.

In T298150#7903910, @Lydia_Pintscher wrote:

In T298150#7902581, @ItamarWMDE wrote:

• Are lexical categories filtered against the search results in the same way that the spelling variants are filtered (i.e. there's a word starting with the search term, in the name)? @Lydia_Pintscher

I'd say it should behave the same way with the lexical categories prioritized as without. So that'd be matching on the start of words.

Thanks @EBernhardson and @brennen!

In T209859#7881777, @gerritbot wrote:

Change 786267 merged by jenkins-bot:

[mediawiki/extensions/CirrusSearch@es68] Prevent negative weights on BoostedQueriesFunction

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

@dcausse I think y’all have been doing some work on elasticsearch compatibility in (Wikibase)CirrusSearch (T288765 and some other changes), any chance this could be related? I don’t see anything in the Wikibase.git log that looks like a likely culprit. (The issue can still be reproduced on Test Wikidata, e.g. search for a. I can’t reproduce it locally yet, which I assume is because I don’t use CirrusSearch locally.)