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

Tobi_WMDE_SW updated the task description. (Show Details)
Tobi_WMDE_SW raised the priority of this task from to High.
Tobi_WMDE_SW set Security to None.
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.
aude added a comment.Sep 17 2015, 3:08 PM

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
daniel added a subscriber: daniel.Sep 18 2015, 11:20 AM

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: [Task] Implement SiteIdMapper service


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

Restricted Application added a subscriber: JEumerus. · View Herald TranscriptFeb 14 2016, 4:49 PM

I'll bump it.

Liuxinyu970226 added a subscriber: Addshore.EditedNov 2 2018, 5:00 AM

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