leon wrote:

I changed Names.php in r18260, someone needs to updates the subdomain, though.

That will break display of existing links, please revert.

astroviolin wrote:

(In reply to comment #1)

I changed Names.php in r18260, someone needs to updates the subdomain, though.

Thanks! I saw the result you changed... But I found out that interwiki links
still didn't change (have to use "zh-min-nan:" instead of "nan:"); and the
website didn't change, too. What's the effect of changing "Names.php" in r18260?

robchur wrote:

The effect was minimal; quite a few things have to be changed at once to do
this, and it needs to be co-ordinated with the system admin team, too.

There's are the same case as the Cantonese language, "zh-yue", which is not
specified in any of ISO639 codes, the correct code for Cantonese language code
should be named as "yue", which is specified in ISO639-3
(http://www.sil.org/iso639-3/codes.asp?order=639_3&letter=y). Please add the
names.php for the "yue" language.

However, to implement the changes for the existing Wikimedia projects, we need
to having the change of the shell to change the value of the $wpContLangCode (?)
into "nan" and "yue" respectively, and also we need some bots to have the
interlanguage links in the Wikimedia projects which fix up from the language
codes from "zh-min-nan" to "nan" and from "zh-yue" to "yue".

share2002nov wrote:

Bots are outside the scope of Bugzilla (I think). We need to contact bot
authors (mainly pywikipediabot), unless there's a master interwiki list somewhere.

robchur wrote:

We can leave old interwiki stuff in the database to do near-seamless redirects;
that isn't a problem. What is a problem is that there are multiple configuration
and server-setup issues which need to be changed more or less at the same time
for this to work, hence, a quick hack in Names.php was nowhere near sufficient
to make it all happen.

astroviolin wrote:

Dear Administrators,

May I ask what the situation is recently? Because I found out that the link of
"nan.wikipedia.org" still doesn't work; and it has been more than 2 months since
last comment. If there are any difficulties, please tell us! Thank you. :)

villadavida wrote:

This would be useful across many other projects as well, the English
Wiktionary for certain.

I've set up a redirect for nan.wikipedia.org for the moment.

The 'yue' in Names.php was added in r21200. It's also need to set up for the
subdomain, too.

HenrySYLi wrote:

Dear administrator,

Please move Cantonese Wikipedia from zh-yue to yue.  The name has been prepared.  It has been 2 months after last comment.

klneast wrote:

All non ISO-639-1 or ISO-639-3 codes should be changed right away, leaving redirects are enough.

hillgentleman wrote:

Please in the very least set up a redirect for yue.wikipedia.org , as was done for nan.wikipedia. It has been causing some discomfort when we set up interwiki links.

mickewiki wrote:

I dont know if this: http://sv.wikipedia.org/w/index.php?title=Wikipedia&oldid=6273453#Externa_l.C3.A4nkar is related to this. We hade some problems with the iw links for among others yi: and zh-yue: probalby related to these languages being written from right to left (somehow this caused the "[[" and "]]" taggs to be impossible to put at the right place). When I tried to fix this I managed to fix the link for yi: but not for zh-yue: as you can see from the link, even though the page obviously exsists.

/Micke

(In reply to comment #15)

I dont know if this:
http://sv.wikipedia.org/w/index.php?title=Wikipedia&oldid=6273453#Externa_l.C3.A4nkar
is related to this. We hade some problems with the iw links for among others
yi: and zh-yue: probalby related to these languages being written from right to
left (somehow this caused the "[[" and "]]" taggs to be impossible to put at
the right place). When I tried to fix this I managed to fix the link for yi:
but not for zh-yue: as you can see from the link, even though the page
obviously exsists.

/Micke

No, that’s related. that was just caused by the RTL starting bracket looking exactly like the LTR ending bracket. Computers see the difference, humans don’t. I fixed the interwiki link.

itsminecookies wrote:

There's are the same case as the Classical Chinese (Named as Old Chinese in ISO639-3), "zh-classical", which is not
specified in any of ISO639 codes, the correct code for Cantonese language code
should be named as "och", which is specified in ISO639-3
(http://www.sil.org/iso639-3/codes.asp?order=639_3&letter=o). Please add the
names.php for the "och" language.

However, to implement the changes for the existing Wikimedia projects, we need
to having the change of the shell to change the value of the $wpContLangCode (?)
into "nan", "och" and "yue" respectively, and also we need some bots to have the
interlanguage links in the Wikimedia projects which fix up from the language
codes from "zh-min-nan" to "nan", from "zh-classical" to "och" and from "zh-yue" to "yue".

HenrySYLi wrote:

It is nearly two years for this request, from zh-yue to yue. No action is taken at all. It should not be that hard to change the correct code. It requires to change some variables only.

Simply make old host name become a re-direction to new host name. It reduced the broken interwiki links to zero.

For correcting interwiki link, change English and Chinese Wikipedia articles first. The change of interwiki links in other projects usually fixed by other bots with reference to English or Chinese one.

kennymouse wrote:

upgraded priority due to ISO code issue.

klneast wrote:

Apart from “zh-yue” → “yue” and “zh-min-nan” → “nan”, “roa-rup” should be changed to “rup” too.

itsminecookies wrote:

http://www.sil.org/iso639-3/chg_detail.asp?id=2008-089&lang=zho

http://www.sil.org/iso639-3/cr_files/2008-089_lzh.pdf

The exactly ISO 639-3 code of Literary Chinese (Classical Chinese) is lzh, please make a redirect as lzh.wikipedia.org to zh-classical.wikipedia.org, thanks!

conrad.irwin wrote:

It would be nice if (as a first step) we could enable nan:, cmn:, yue: as inter-language prefixes on all wikis (synonyms for zh-min-nan:, zh: and zh-yue:)

This would allow for much simplification for interwiki link handling (particularly on en.wikt, but presumably elsewhere too)

conrad.irwin wrote:

See http://en.wiktionary.org/wiki/Template:wikimedia_language

What is involved in adding pseudo interwiki prefixes? As far as I can tell it just needs entries in the interwiki table, the interwiki bots and anything that already does can continue using the old codes indefinitely.

Transition on server just requires keeping a CNAME alias for the compatibility fo the old domain name prefix and the newer ISO 639-3 domani name prefix (creating the new domain on the DNS server, and then changing the old name to become this alias).
However, some maintenance is also needed in the PHP code for the list of interwikis (the old name should still be kept for some unestimated time). There should not exist a rupture in cross-site links on Internet and in search engines.

When this is done, this will help simplifying lots of language-related templates, and the benefit will also be a better presentation, and simplification for users of these languages.

Valid and standard ISO 639 codes are definitely the way to go, as Wikimedia sites (notably Wikipedia and Wiktionary) are THE platform of choice for the demonstration of ISO 639 usefulness. The rule was already applied in MediaWiki's Incubator, and this is fine.

bugs wrote:

(Cleaning up the wiki rename bugs.)

Just to recap, this bug deal with:

• zh-yue -> yue
• zh-min-nan -> nan
• zh-classical -> lzh

And that's it. We have different bugs for other language codes (see the tracking bug).

We need to see consensus from the respective wikis for this to happen.

Closing this particular bug under "one issue, one bug" rule. Each wiki should get consensus separately and open separate bugs.

bugs wrote:

That's kind of adding insult to injury, don't you think? This bug has been open since 2006 and they've been patiently waiting, and now we're just going to close it because of some rule that might not have even been around when this bug was filed? If it's that big of an issue for you, create separate bugs yourself and then link to them from here. Though that might not be the best idea, since these are all the same kind of change (if you can do one, you can do the others, it's not like "Rob can do this, Roan can do this, but that requires Tim's input") and this has a lot of history/discussion.

If consensus doesn't exist on the respective wikis (which I'm not sure it doesn't), I'm not even sure it's necessary. A wiki doesn't get to choose its language code, or what its URL, so why would we require consensus to change it?

(In reply to comment #28)

That's kind of adding insult to injury, don't you think? This bug has been
open since 2006 and they've been patiently waiting, and now we're just going to
close it because of some rule that might not have even been around when this
bug was filed?

Thanks for pointing out how one might see this... I wasn't sure anyone was still interested in this but wanted to point out how to deal with this.

it's not like "Rob can do this, Roan can do this, but that
requires Tim's input") and this has a lot of history/discussion.

But if consensus is needed then that there it isn't likely to appear simultaneously. So then three different bugs would be needed.

I've asked Ops for verification that consensus is needed. I think it is when you're creating a new URL for an old Wiki. If it is, then I'll open three new bugs.

(In reply to comment #28)

If consensus doesn't exist on the respective wikis (which I'm not sure it
doesn't), I'm not even sure it's necessary. A wiki doesn't get to choose its
language code, or what its URL, so why would we require consensus to change it?

See Bug #17047 and your comment on Bug #26725, as well as the bug this one blocks, Bug #19986.

Community consensus is needed. Since this involves 3 different wikis, that's three different bugs: Bug #28441, Bug #28442, Bug #28443. Admins can use Bug #19986 for seeing which ones are ready to be done when they are prepared to do big batches of them.

This should not be closed. At least the original request was perfectly valid. Yes we can creater 3 distinct bugs, but this bug should remain open as a tracking bug depending on these 3 separate bugs. By closing this one, you are unlinking the 3 separate bugs also from Bug #19886 tracking the wikis that are ready to perform the change (concensus reached, templates checked for compatibility to help the transition, documentation on other wikis, contacts taken for managing interwikis, bot owners informed...)
To help the transition, there should exist for some time an equivalence from the new code to the old one, to help build the transition mechanisms, and check/update templates, then reversing the link from old to new code, keeping it for some time (probably long, to avoid breaking external links from the web and maintaining the stability of searches : this requires at least one year)

By closing this one, you are unlinking the 3 separate bugs also from Bug
#19886 tracking the wikis that are ready to perform the change

I made each of the bugs depend on Bug #19886 so I don't think that is an issue. Furthermore, each bug links back here, as well.

I made each of the bugs depend on Bug #19886 so I don't think that is an issue.

Oops, I meant Bug #19986

Yes but now, you cannot mark as resolved a bug that depends on the three unresolved issues. This is an incorrect state for this bug that should remain open and shown in that state in each separate bug that are blocking this one. And You should have never marked this bug as invalid, when it was perfectly valid since long before you started splitting it...

mlleepeter wrote:

The domain name (url) "zh-min-nan.wxxxxxxxxx.org" should be changed into "nan.wxxxxxxxxx.org" too. Thanks.

mlleepeter: Different problem, that's bug 28442. See "Depends on" list.

Just saying: zh-yue.wikipedia.org -> yue.wikipedia.org has had community consensus since 2007: https://zh-yue.wikipedia.org/wiki/Wikipedia:AN#.E5.9F.9F.E5.90.8D

A technical discussion in 2011, which arose from a bug (bug 30392) that turned out to be unrelated, affirmed the consensus that we're waiting to be renamed to yue.wikipedia.org : https://zh-yue.wikipedia.org/wiki/Wikipedia:VPT#Wikipedia_talk:

SPQRobin posted in 2012 that wgLanguageCode is going to change from zh-yue to yue. Again, there were no objections. I personally replied to SPQRobin in affirmation.

In short, I can't agree with Casey Brown (2011-04-04) more. We've been sitting there in yuewiki since 2007 with a consensus, then Mark jumps in in 2011 to say "we need a consensus". We've been waiting with a consensus for almost six years. (Wikipedia is only 12 years old!)

HenrySYLi wrote:

What is the status of this bug? It could not be hard to solve this bug as it is only configuration matter, just changing the code form zh-nan to nan and from zh-yue to yue. There is long consensus on the changes.

No one takes action on this bug for many many years!!! We cannot sit here with no progress at all. Please let me know if there are any issues I can help.

This is not suddenly "immediate priority". See https://www.mediawiki.org/wiki/Bugzilla/Fields#Priority

Gerard.meijssen wrote:

How do you identify utter frustration ?

How do you identify that it seems that the people who could to this just do not care?

It is why people add "immediate priority". While you are technically right, you are not.
Thanks,

GerardM

This is getting ridiculous. This bug requires only simple configuration changes and has been blocking the development of multiple Wikipedias for 7 years. Now it's reverted back to Normal priority which means the devs are telling us it'll take more than another bloody year to take action. May I ask what is the blocking issue?

Deryck Chan: First of all no dev told you it takes a year (if somebody did, link to it).
Furthermore, immediate priority is reserved for bugs that require someone to drop what they're currently doing and address this problem really soon (2 or 3 days). This is obviously not the case here.
Please do not repeatedly reset priority as a sign of protest or frustration, otherwise your Bugzilla account might be disabled.

I'll set the priority here to normal again, as that reflects current plans.
It's not that nobody cares, it's that there are specific technical problems with renaming which are explained in bug 19986. That's the blocking issue.

(In reply to comment #42)

Deryck Chan: First of all no dev told you it takes a year (if somebody did,
link to it).

The link you shared, https://www.mediawiki.org/wiki/Bugzilla/Fields#Priority .

high [...] Depending on teams & manpower this can take between one and six months.
normal [...] would be good to get fixed somewhere in the future. [...]

These two rows combined implies that "normal" will take more than six months to get around to it.

In T10217#135716, @deryckchan wrote:

This is getting ridiculous. This bug requires only simple configuration changes

This is not true. Wiki renaming was blocked on external storage last time i checked.