Wikipedias with zh-* language codes waiting to be renamed (zh-min-nan -> nan, zh-yue -> yue, zh-classical -> lzh) (tracking)
OpenPublic

Description

Author: astroviolin

Description:
Dear Administrator,

I have an account in Taiwanese/Holo Wikipedia
(http://zh-min-nan.wikipedia.org/wiki/Th%C3%A2u-ia%CC%8Dh) and I'm a sysop of
Taiwanese Wikisource. Formerly we've used the code "zh-min-nan", but now we're
in the ISO 639-3 (http://www.sil.org/iso639-3/codes.asp?order=639_3&letter=n)
list, using its code "nan". We want to have our code more formally and briefly
and change it in to the new one, but we don't know how. Can you help us or tell
us what to do? I've asked User:Angela and User:Tim_Starling in Meta-Wiki, and
Angela suggest me to report here. Please help us! Thanks very much!


Version: unspecified
Severity: major
URL: http://zh-min-nan.wikipedia.org/wiki/Th%C3%A2u-ia%CC%8Dh
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=20547

bzimport added a subscriber: wikibugs-l.
bzimport set Reference to bz8217.
bzimport created this task.Via LegacyDec 11 2006, 10:33 AM
bzimport added a comment.Via ConduitDec 11 2006, 4:17 PM

leon wrote:

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

brion added a comment.Via ConduitDec 11 2006, 8:20 PM

That will break display of existing links, please revert.

bzimport added a comment.Via ConduitDec 13 2006, 8:32 AM

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?

bzimport added a comment.Via ConduitDec 13 2006, 3:37 PM

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.

bzimport added a comment.Via ConduitDec 16 2006, 7:43 AM

shinjiman wrote:

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

bzimport added a comment.Via ConduitDec 19 2006, 5:49 AM

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.

bzimport added a comment.Via ConduitDec 19 2006, 11:55 AM

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.

bzimport added a comment.Via ConduitJan 31 2007, 6:54 PM

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

bzimport added a comment.Via ConduitApr 6 2007, 7:01 AM

villadavida wrote:

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

brion added a comment.Via ConduitApr 16 2007, 4:02 PM

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

bzimport added a comment.Via ConduitApr 17 2007, 1:39 AM

shinjiman wrote:

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

bzimport added a comment.Via ConduitJun 24 2007, 2:42 PM

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.
bzimport added a comment.Via ConduitJun 26 2007, 12:30 PM

klneast wrote:

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

bzimport added a comment.Via ConduitAug 18 2007, 7:41 AM

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.

bzimport added a comment.Via ConduitMar 28 2008, 10:20 AM

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

jhsoby added a comment.Via ConduitMar 28 2008, 12:32 PM

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

bzimport added a comment.Via ConduitJul 6 2008, 1:36 PM

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

bzimport added a comment.Via ConduitJul 22 2008, 6:30 AM

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.

bzimport added a comment.Via ConduitAug 1 2008, 6:41 PM

kennymouse wrote:

upgraded priority due to ISO code issue.

bzimport added a comment.Via ConduitAug 2 2008, 3:29 PM

klneast wrote:

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

bzimport added a comment.Via ConduitJan 21 2009, 4:50 AM

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!

bzimport added a comment.Via ConduitOct 9 2009, 10:04 PM

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)

bzimport added a comment.Via ConduitDec 15 2009, 7:21 PM

conrad.irwin wrote:

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

nan=zh-min-nan
vro=fiu-vro
cmn=zh
och=zh-classical (thoguh maybe lzh, I'm not sure)
yue=zh-yue
rup=roa-rup

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.

bzimport added a comment.Via ConduitApr 14 2010, 1:02 PM

verdy_p wrote:

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.

bzimport added a comment.Via ConduitApr 17 2010, 12:33 AM

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

MarkAHershberger added a comment.Via ConduitApr 4 2011, 10:33 PM

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

MarkAHershberger added a comment.Via ConduitApr 4 2011, 10:36 PM

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

bzimport added a comment.Via ConduitApr 4 2011, 10:50 PM

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?

MarkAHershberger added a comment.Via ConduitApr 6 2011, 3:11 PM

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

MarkAHershberger added a comment.Via ConduitApr 6 2011, 3:40 PM

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

bzimport added a comment.Via ConduitApr 6 2011, 3:50 PM

verdy_p wrote:

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)

MarkAHershberger added a comment.Via ConduitApr 6 2011, 4:02 PM

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.

MarkAHershberger added a comment.Via ConduitApr 6 2011, 4:03 PM

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

Oops, I meant Bug #19986

bzimport added a comment.Via ConduitApr 6 2011, 6:22 PM

verdy_p wrote:

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

bzimport added a comment.Via ConduitJan 17 2013, 3:45 PM

mlleepeter wrote:

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

Aklapper added a comment.Via ConduitJan 18 2013, 9:01 AM

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

deryckchan added a comment.Via ConduitJan 23 2013, 12:42 AM

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

bzimport added a comment.Via ConduitDec 1 2013, 6:46 AM

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.

Aklapper added a comment.Via ConduitDec 2 2013, 10:10 AM

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

bzimport added a comment.Via ConduitDec 2 2013, 10:42 AM

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
deryckchan added a comment.Via ConduitDec 2 2013, 10:45 AM

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?

Aklapper added a comment.Via ConduitDec 2 2013, 11:52 AM

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.

deryckchan added a comment.Via ConduitDec 2 2013, 12:16 PM

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

Glaisher added a subscriber: Glaisher.Via WebJan 15 2015, 6:01 PM
jayvdb added a subscriber: jayvdb.
Liuxinyu970226 awarded a token.Via WebWed, Mar 11, 5:38 AM
Wong128hk added a subscriber: Wong128hk.Via WebSat, Mar 14, 5:24 AM
Mvolz set Security to None.Via WebSat, Mar 21, 2:51 PM
Mvolz added a subscriber: Mvolz.
waldyrious removed a subscriber: waldyrious.Via WebSat, Mar 21, 8:31 PM

Add Comment

Column Prototype
This is a very early prototype of a persistent column. It is not expected to work yet, and leaving it open will activate other new features which will break things. Press "\" (backslash) on your keyboard to close it now.