See T105999: Redirect yue.wikipedia.org to zh-yue.wikipedia.org

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

In T30441#2637078, @Liuxinyu970226 wrote:

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

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? :)

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

• Make sure they have both Wikimedia-Site-requests and Wikimedia-Language-setup
• Adjust their columns on the work boards:

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 :-(

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)

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

agree

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.

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?

In T30441#6210198, @Hello903hello wrote:

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.

In T30441#6213240, @Ladsgroup wrote:

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

In T30441#6214672, @Marostegui wrote:

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.

In T30441#6184574, @Sanmosa wrote:

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.

yue.wikipedia.org already exists in DNS

DNS is not the problem. We need T172035 being addressed and then we can work on this.

I didn't claim it was. But this fact made this ticket different from the other ones that had missing DNS and were just added yesterday. This was an outlier in that it already exists.