| Status | Subtype | Assigned | Task | |
|---|---|---|---|---|
| · · · | ||||
| Open | None | T112426 [Bug] Querying Wikipedia for langlinks doesn't work for be-tarask, but works for be-x-old | ||
| Open | None | T202602 Consider renaming language identifier (i.e. on the left of sitelinks of items) of Cantonese from "zh_yue" to "yue" | ||
| Open | None | T174160 Language code(s) for nowiki should be changed to nb | ||
| Declined | None | T112647 [Task] Investigation: how to handle the rename of a site id in Wikidata | ||
| · · · |
Event Timeline
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.
Issues:
- 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)
Rationale:
- 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.)
@Amire80 basically, blocked on T113034: RFC: Overhaul Interwiki map, unify with Sites and WikiMap
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.
This investigation have lead to some findings that have never been addressed. WMDE will look into the site renaming topic again in: T269139