I'm curious if there are any plans to consider this on the Wikidata roadmap. Not only are many external links currently passed through a Toolforge tool, that dependency is passed along to infoboxes or other re-users who want to rely on Wikidata for formatting URLs. See for an example the infobox https://no.wikipedia.org/wiki/12_Monkeys, where the IMDB link is formatted using the toolforge script. This seems like it should be a first-class feature and the use of a toolforge script deprecated.

Fantastic news, thank you Valerio!

@valerio.bozzolan Was this audit completed and, if so, were its findings published anywhere?

Awesome, thanks very much for your work on this! Seems to work exactly as advertised and should make it possible to build some nicer suggesters with a single query. :)

As someone using the wbsearchentities API in another application, I just want to express that I'd very much appreciate this functionality -- the internal usage descriptions on some items are distracting and make them significantly less useful for any kind of integration, as users outside the Wikidata context have no idea what Q or P numbers are. Thanks! :)

However, when I attempt to login as 'erik' I get a different error message: 'Invalid username or password.'

I don't know whether this was the case before, but both 'erik' and 'eloquence' users seem to exist, producing the same results:

I get the same error message regardless of capitalization. The number (4136 in my original report) ticks up with each attempt.

Since Jared is no longer at WMF after the end of this month, this feature needs to transition to new ownership. Pinging @Tnegrin since this rationally makes sense within the scope of the Readership group.

@daniel Any update on the ETA yet? Should we push it to May/June, or is last week of April realistic?

@kaldari I am guessing this is actually happening this week, given that the bot was just approved, correct?

Moving to next week in roadmap since Chinese deployment is still pending.

@Ironholds do you have bandwidth to take a look?

@DarTar, if you and Oliver can work out a plan that works for both of you, I am fine with it.

@Slaporte is the tech liaison from legal now that Luis runs community. Daniel and/or Andre, my recommendation would be that you set up a quick time with him to walk him through this data release. If he sees no flags, this is fine with me.

Per Mark's endorsement, this NDA request is approved.

Ah, thanks for pointing that out, James. Daniel asked me about this ticket and I assumed (given the ticket description and Daniel's explanation) that the proposal is still to rename to store.wikipedia.org. If store.wikimedia.org as the canonical URL is fine, that addresses the security concern and there should be no major blockers to change from shop.wikimedia.org to store.wikimedia.org. Renames are fun :-)

Terrifying options may warrant some consideration, but I'll loop back with Victoria that this may be trickier than anticipated. @csteipp any thoughts on how security issues could be mitigated, and/or the suggestion above?

Ah, I see. So, to recap -- the concern is:

The branding has already been updated, there's a Twitter account "wikipediastore", etc., so all that remains to be done is changing the canonical URL. I can't speak for Victoria, but I'm guessing that this rename is due to the greater brand recognition of the Wikipedia brand and due to the store mainly selling Wikipedia products. In any case, it's up to the shop team to pick the name for the thing :)

Nice find, Stu. We may need a #CSI-Cyber project to track these references. ;)

Oh wow, that timestamp link is totally obscure -- but not what I mean either, because it's a permalink to only that part of the topic. What I mean is a link to the whole topic, but with the new comment highlighted (and possibly with the viewport scrolled to the new comment).

@Mattflaschen Note that T94962 does not describe exactly the same thing, even if we make the descriptions more helpful, the actual link should point to a page that highlights what's new (similar to the links from the notifications panel); especially in a large topic it's otherwise not very useful to understand what's going on.

@Legoktm are you owning this one? If so is it going out next week? Thanks.

@Lydia_Pintscher, can you help with tracking the ETA on this?

@kaldari it looks like this is still blocked on bot approval, shall we target next week for now?

@Deskana, can we project a revised release date yet?

I understand this process is starting next week per https://www.mediawiki.org/wiki/Flow/LQT_conversion_process so moved there in the roadmap for now.

OK, let's schedule to a specific week once we have confidence on the ETA.

@Joe, do we need to push this to next week?

Please create new tasks for future deployments so they can be tracked on the roadmap.

@DarTar can give many examples -- how we handle article titles and disambiguation pages is probably the biggest area for improvement. While it's true that the actual titles aren't a technical issue, there are technical mechanisms we can consider to improve discoverability of content through external search engines. An example would be improved public data of the "How do people get here" variety -- helping users optimize titles and primary topics according to the needs of our readers. Similarly, there are many strategies that can be used to improve page metadata, discoverability of multilingual content, etc.

If we don't have bandwidth to do a proper test, let's just remove it for a week or two and see if it depresses actions we care about. This animation is annoying enough that we should kill if it unless we have evidence that it benefits users.

(Roadmap is currently for significant functionality that reaches users & developers, let's discuss outside the context of this task if we want to add events, and if so, in what form.)

(Discussed already a bit with i18n team, this is a big enough potential win that I want to make sure we have eyeballs on it.)

Scheduled for 3/30

(Tag was inherited and not intentionally added, removing.)