Page MenuHomePhabricator

[Task] Investigation: how to handle the rename of a site id in Wikidata
Closed, DeclinedPublic

Related Objects

View Standalone Graph
This task is connected to more than 200 other tasks. Only direct parents and subtasks are shown here. Use View Standalone Graph to show more of the graph.

Event Timeline

Tobi_WMDE_SW renamed this task from [Task] Investigation: how to rename a site id? to [Task] Investigation: how to handle the rename of a site id in Wikidata.
Tobi_WMDE_SW raised the priority of this task from to High.
Tobi_WMDE_SW updated the task description. (Show Details)
Tobi_WMDE_SW set Security to None.

Possible solutions:

  • add a new entry in the sites table with the new site id (e.g. be_tarask)
  • have a blacklist of deprecated site ids (be_x_old) that can be used to add new site links (checked in SiteLink change op?), but the allow things like old revisions with the old id to still work and allow editing unrelated things on an item
    • alternatively, would be nice to represent this in the Site objects, but not sure how quick, easy and nice this can be done.
  • have a bot migrate site links to the new site id.


  • populateSitesTable script (and possibly other things) assume database name = site id
    • it's ugly but populateSitesTable should accommodate such exceptions

Alternative solution:

  • Add a "display-id" set to "be_taraskwiki" to the IDs associated with "be_x_oldwiki". Site and SiteStore allow any number of IDs to be associated with a site, so this shouldn't be a problem.
  • For display, use the "display-id" instead of the (canonical) global id, if set
  • For input (in the UI and API) allow both, the canonical ID and the display-id.

Another possibility:

  • Start using the domain name instead of exposing internal wiki identifiers.
  • For display, use the full domain (or just the subdomain, where suitable)
  • For input (in the UI and API) allow both, the canonical ID and the domain name. See T112910.

After some discussion with Lydia, we decided to not create a second Site entry, but to "somehow" define site aliases, and use them for input and output. For details, see T114772: Allow entering Wikidata sitelinks to wikis that have non-typical wiki ID (not matching the database name)


  • changing internal ids is evil
  • we need a more flexible system anyway

Is there any update about this?

I'd love to start renaming more domains (T21986), and if I understand correctly, this is a bit of a blocker. (Renaming domains is not just a matter of ISO 639 standard purism—it actually causes other subtle bugs.)

@Addshore and @daniel, due to the huge technical challange, I don't see why these tasks are still calling "ready to go", mark these stalled and move to "monitoring or on hold" column?

Dear all: Maybe there's a good news for this problem: T209089

I wonder if this extension can be integrated with our Wikibase softwares or not.

WMDE-leszek subscribed.

This investigation have lead to some findings that have never been addressed. WMDE will look into the site renaming topic again in: T269139