Page MenuHomePhabricator

Rename zh-yue -> yue
Open, HighPublic

Description

See discussion on Bug #8217 (T10217)


Version: unspecified
Severity: enhancement

Details

Reference
bz28441

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
siebrand set Security to None.Jun 18 2015, 8:50 PM
siebrand moved this task from Backlog to Wiki rename requests on the Wikimedia-Language-setup board.
Meno25 added a subscriber: Meno25.Jul 11 2015, 8:09 AM
Restricted Application added a subscriber: Matanya. · View Herald TranscriptJul 11 2015, 8:09 AM
C933103 updated the task description. (Show Details)Jul 15 2015, 10:52 PM
C933103 added a subscriber: C933103.

See bug 19986 for the discussion on why it's so difficult. (Thanks Andre Klapper)

(T21986)

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptAug 12 2015, 1:10 AM
Koavf added a subscriber: Koavf.Aug 25 2015, 6:05 AM
Restricted Application added a subscriber: JEumerus. · View Herald TranscriptFeb 22 2016, 10:50 PM
Liuxinyu970226 added a subscriber: William915.
hashar lowered the priority of this task from Medium to Lowest.Sep 14 2016, 10:12 AM

@hashar I'm afraid your action on this task will make at least @HenryLi angry, because he said this on T21986:
This ticket opened in 2009 and now it is 2016. Why does it take 7 years without anything done? While it is not urgent and not trivial, there is a date it must be done. Please raise its priority and start a project as soon as possible to streamline the renaming process. It affects the consistence of user interface and the alignment to language code standard.

@hashar I'm afraid your action on this task will make at least @HenryLi angry, because he said this on T21986:
This ticket opened in 2009 and now it is 2016. Why does it take 7 years without anything done? While it is not urgent and not trivial, there is a date it must be done. Please raise its priority and start a project as soon as possible to streamline the renaming process. It affects the consistence of user interface and the alignment to language code standard.

Okay I'll jump the queue and be the first to express "anger". Many editors of Cantonese Wikipedia have been watching this thread for 9 years and the habitual neglect of this glaring anomaly has been "adding insult to injury", to quote the other thread too.

deryckchan raised the priority of this task from Lowest to Medium.Sep 14 2016, 4:11 PM
Aklapper removed a subscriber: hashar.Sep 14 2016, 4:26 PM

I'm not sure why comments are copied from T21986 to this task, as T21986 explains the current situation and the underlying issues for any renames, and hence is the place to discuss technical blockers and how to improve progress. Could we concentrate on what's happening and needs to happen technically in T21986 to get things going, instead of discussing values of metadata fields of tickets in an issue tracker? :)

Aklapper lowered the priority of this task from Medium to Lowest.Sep 14 2016, 4:28 PM

Priority is supposed to reflect reality; as frustrating as reality might sometimes be. I expect that technically focussed discussion and progress in T21986 and its related tasks will allow increasing the priority of this task at some point (and still reflecting the reality).

@Liuxinyu970226 @deryckchan sorry I did not want to be rude. What I did on all the tasks asking for Wiki to be renamed was:

ProjectColumn
Wikimedia-Site-requestsWiki renaming
Wikimedia-Language-setupWiki rename requests

And I have set them all to lowest priority, if they had any kind of priority they would probably have been done by now.

The Cantonese wiki is not a special case here. Once the technical part is solved, all wikis will be able to be moved and T21986 is the proper place for discussion.

(as a side note https://wikitech.wikimedia.org/wiki/Rename_a_wiki_database created in 2011 originated from a discussion I had with the author).

Sorry :-(

Krinkle changed the task status from Open to Stalled.Apr 30 2017, 3:55 AM
Krinkle added a subscriber: Krinkle.

Stalled since renaming (T21986) is blocked on T145535 (e.g. T112426.).

Krinkle removed a subscriber: Krinkle.Aug 23 2017, 6:12 PM
Restricted Application added a subscriber: jeblad. · View Herald TranscriptAug 25 2017, 12:53 PM
Elitre added a subscriber: Elitre.Aug 29 2017, 5:14 PM

FYI another new editor has brought up the issue of renaming zh-yue again. The discussion again resulted in a consensus to push for the ISO-639-3 code "yue" to be made canonical. (Permalink to discussion)

cscott added a subscriber: cscott.Dec 8 2017, 9:02 PM

Pinging this topic again, since identification of language variants in RESTBase/Parsoid requires distinguishing zh-yue (interpreted as using language converter to convert zh content to yue) and yue (native yue content, no use of language converter). See discussion at https://phabricator.wikimedia.org/T122942#3031430

Restricted Application added a subscriber: alanajjar. · View Herald TranscriptJan 29 2018, 4:31 AM
Meno25 removed a subscriber: Meno25.Nov 23 2018, 7:36 AM

This has recently been brought up again at the Cantonese Wikipedia. (discussion here)

Referring to the discussion deryckchan mentioned above, I can see that a strong consensus is made in Cantonese Wikipedia. I hope that the renaming will get done as soon as possible if there are no technical issues.

Sanmosa changed the task status from Stalled to Open.Jun 2 2020, 11:02 AM
Sanmosa raised the priority of this task from Lowest to High.

A user in yuewiki suggested another way to do this. (https://zh-yue.wikipedia.org/wiki/Wikipedia:城市論壇_(提議)#Yue.wikipedia.org) Is it possible to create yue.wikipedia.org and import all pages from zh-yue?

A user in yuewiki suggested another way to do this. (https://zh-yue.wikipedia.org/wiki/Wikipedia:城市論壇_(提議)#Yue.wikipedia.org) Is it possible to create yue.wikipedia.org and import all pages from zh-yue?

As one of the three "new wiki importers" in Wikimedia (i.e. those with the technical access and the know-how to do it), I'm afraid I have to say absolutely not.

I understand where the idea is coming from, but the tools we have for importing are already not functioning well for small wikis imported from the Incubator (typically around 1,000–2,000 pages total). For yuewiki, which has more than 200,000 pages, this would simply be technically impossible, and the worst possible way of doing this. And that's without even mentioning the fact that except for page histories, all other logs, deleted page revisions, etc. will be lost. So this is simply not a feasible way to do it.

Another way which may work though, is for someone with the correct database access to copy (not move or rename) the entire database for zh_yuewiki and name it yuewiki, which would give us two identical copies. After this is set up and bugs sorted out, the domain could be switched as the final part. But I have no idea about the doability of any of that – I think @Ladsgroup is probably the best person to ask.

Oh, we renamed one wiki only (be-x-old to be-tarask) years ago and it's still causing issues (last week its interwiki links broke altogether) and for example lots of it doesn't still work (like T235505: Rename be-x-old as be-tarask in Wikidata). Renaming a wiki is almost impossible and really hard. That being said, if we revisit the problems we might be able to do it better this time.

  • The DNS fix is not hard, we can redirect the traffic of yue.wikipedia.org to read zh_yuewiki (the old db name), it doesn't solve the wikidata's problem and some other bits though.
  • Fixing database is the tricky part, We can duplicate the database, close the old wiki and ask people to use the new wiki and once we are sure everything works fine, redirect the DNS traffic and drop the old database (hopefully this would take only a couple of hours). Does that work?

. It might require a read-only time period for all of small wikis (s3) plus collaboration with the cloud team to get it fixed in toolforge replicas. Duplicating the database might cause some unforseen side-effects, let me give an example, imagine some parts of the database store the db name as prefix for example when hashing the password. Just duplicating the database wouldn't be enough and would cause every one to lose their passwords (this wouldn't happen at our setup because we don't put the wiki's db name in the password hash). I should scan the whole database to see if there's anything obvious. But I'd say let me ask our DBAs like @Marostegui to make sure duplicating the database would work because they will be the ones who will do it.

Oh, we renamed one wiki only (be-x-old to be-tarask) years ago and it's still causing issues (last week its interwiki links broke altogether) and for example lots of it doesn't still work (like T235505: Rename be-x-old as be-tarask in Wikidata). Renaming a wiki is almost impossible and really hard. That being said, if we revisit the problems we might be able to do it better this time.

  • The DNS fix is not hard, we can redirect the traffic of yue.wikipedia.org to read zh_yuewiki (the old db name), it doesn't solve the wikidata's problem and some other bits though.
  • Fixing database is the tricky part, We can duplicate the database, close the old wiki and ask people to use the new wiki and once we are sure everything works fine, redirect the DNS traffic and drop the old database (hopefully this would take only a couple of hours). Does that work?

. It might require a read-only time period for all of small wikis (s3) plus collaboration with the cloud team to get it fixed in toolforge replicas. Duplicating the database might cause some unforseen side-effects, let me give an example, imagine some parts of the database store the db name as prefix for example when hashing the password. Just duplicating the database wouldn't be enough and would cause every one to lose their passwords (this wouldn't happen at our setup because we don't put the wiki's db name in the password hash). I should scan the whole database to see if there's anything obvious. But I'd say let me ask our DBAs like @Marostegui to make sure duplicating the database would work because they will be the ones who will do it.

So how much time is needed to fix the issues mentioned? I hope you may notice that the site name change delay has already caused a great dissatisfaction and anger in the site.

It is not only copying metadata, but also the data on the external store hosts, which means we also have to put those on read_only (exactly at the same moment) and wait for the data to be spread (which might cause replication lag).

It could cause lots of unexpected issues, cache corruptions and things like that. Copying the database from one place to another requires read-only on the sXX itself, external store hosts, x1... - but the worst part would be consequences it could have MW-wise which are unknown (and that makes it very risky).

It is not only copying metadata, but also the data on the external store hosts, which means we also have to put those on read_only (exactly at the same moment) and wait for the data to be spread (which might cause replication lag).

It could cause lots of unexpected issues, cache corruptions and things like that. Copying the database from one place to another requires read-only on the sXX itself, external store hosts, x1... - but the worst part would be consequences it could have MW-wise which are unknown (and that makes it very risky).

Yeah, renaming on db-level is not possible. Then we need to pull off another be-x-old. It seems T172035: Blockers for Wikimedia wiki domain renaming needs to be resolved (or at least addressed to some degree) so we can rename the wiki on DNS level only. Lots of it is Wikidata stuff. I can talk to our PM for moving this forward.

I'd very much welcome this proposal: copy all of the existing zh-yue.wp
into a new database called yuewiki / yue.wikipedia.org . Once we decide on
a plan I should be able to help iron out the issues from the front-end.

Referring to the discussion deryckchan mentioned above, I can see that a strong consensus is made in Cantonese Wikipedia. I hope that the renaming will get done as soon as possible if there are no technical issues.

Same as Literary Chinese Wikipedia. See T30443 for more details.