Sorry. I fixed the image permissions.

https://www.wikidata.org/wiki/Special:Nearby#/coord/52.4973925,13.3365673 is around my place. With interface set to English:

This might become a bit worse with the introduction of the mul language code.

From today's task triage: We should verify if we actually still want to do anything here

Removing it from WD dev team board as this will need to be handled by WIT.

Removing it from WD dev team board as this will need to be handled by WIT.

Removing it from WD dev team board as this will need to be handled by WIT.

Removing it from WD dev team board as this will need to be handled by WIT.

Removing it from WD dev team board as this will need to be handled by WIT.

Removing it from WD dev team board as this will need to be handled by WIT.

Removing it from WD dev team board as this will need to be handled by WIT.

Thank you, @Nikki!

Is there anything left to do here?

We are looking into improving the size of the dumps. This is covered in T88991. I am closing this in favor of the more general ticket.

Thank you for filing the ticket. This looks to me like a data modelling topic that should be discussed with the editors on Wikidata. https://www.wikidata.org/wiki/Wikidata:Project_chat is likely a good start.

Ah i18n...

👀 WTH does it insist on readding the tag... It is not a Wikidata Team task.

I would like us to keep the current one for the website as it's being used for that by at least me and a number of editors. If we want we can create a new one for the extension.

The goal was to handle issues specific to Wikidata.org the website like configuration changes and other stuff that doesn't apply to other Wikibase instances.

In T143486#9679789, @hoo wrote:

As far as I remember we deliberately chose not to auto-create users back then initially implementing this. I don't think this would be very hard to add this (in a nice way), but I haven't checked.

Let's rather allow filtering by label. There is a different ticket for it.

There is now a board for Wikidata UX tickets

This will be superseded by T303677.

Nah let's close it.

I think this was mainly about understanding why more specialized functions are not used and which more specialized functions are missing. The goal was to move people away from the more expensive calls where possible.

Good to go from my side :)

https://commons.wikimedia.org/wiki/File:05-00-Wikidata-JWB.png has a past screenshot showing it as superscript.

Can confirm that this is still an issue.

In T351968#9602082, @Lucas_Werkmeister_WMDE wrote:

Most of the subtasks here are done, but I think there’s still a big open question about the rollout. In T343800, we found that temporary accounts, once created on a wiki with IP Masking enabled, were also “logged in” and available on other wikis via CentralAuth, which worked well for us. But this has changed in the meantime (T342475) – now, you’ll still be an IP on wikis that don’t have temporary accounts enabled. So what happens with cross-wiki edits now?

• If IP Masking is enabled on Wikidata but not on a client wiki: Suppose an anonymous user makes an edit on Wikidata, with a temporary account. The edit affects a page on a client wiki, so it gets dispatched there, and added to the recentchanges table (type RC_EXTERNAL). Which actor do we assign this row to?
  • It can’t be the temporary account, because they’re not supposed to exist on the client wiki.
  • It can’t be the user’s IP address, because we don’t know it anymore (and shouldn’t leak it in any case).
  • I guess we could reassign all such edits to a system user or something? (But that still leaves the problem that it looks like a registered edit to the client wiki when it really isn’t, which IIUC was the main argument against just letting temporary accounts be shared via CentralAuth like they used to.)
    • Or some kind of special IP address(es), somewhere in a private network block?
• If IP Masking is enabled on a client wiki but not on Wikidata: Suppose a user acquires a temporary account on a client wiki (e.g. with a normal edit), then edits Wikidata from the client wiki. What should happen?
  • I think there’s no actual scenario where this happens. The LinkItem widget is not available to unregistered users, including temporary accounts (see T351971); the data bridge is currently broken (T354750); some wikis have gadgets to edit Wikidata (e.g. WE-Framework), but temporary users won’t be able to enable them.
  • Even if there’s a way for anonymous users to edit Wikidata from a client wiki that I missed – it’s probably okay(ish) if the outcome is just “it doesn’t work”.

Comparing these two alternatives, I wonder if we should just enable IP Masking on Wikidata last of all wikis, so that the first set of problems never applies…

I just tried to reproduce it in Firefox and can't seem to recreate the issue. It works as intended.
Can anyone else reproduce it?

Now published at https://www.wikidata.org/wiki/Wikidata:SPARQL_query_service/Alternative_endpoints