Last modified: 2014-09-08 06:10:33 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 8217 - Wikipedias with zh-* language codes waiting to be renamed (zh-min-nan -> nan, zh-yue -> yue, zh-classical -> lzh) (tracking)
Wikipedias with zh-* language codes waiting to be renamed (zh-min-nan -> nan,...
Status: REOPENED
Product: Wikimedia
Classification: Unclassified
Language setup (Other open bugs)
unspecified
All All
: Normal major with 14 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
http://zh-min-nan.wikipedia.org/wiki/...
: ops, tracking
Depends on: 21915 28441 28442 28443 8599
Blocks: tracking wikis-to-rename
  Show dependency treegraph
 
Reported: 2006-12-11 10:33 UTC by Phokgôan Chio̍h
Modified: 2014-09-08 06:10 UTC (History)
28 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Phokgôan Chio̍h 2006-12-11 10:33:03 UTC
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!
Comment 1 Leon Weber 2006-12-11 16:17:39 UTC
I changed Names.php in r18260, someone needs to updates the subdomain, though.
Comment 2 Brion Vibber 2006-12-11 20:20:25 UTC
That will break display of existing links, please revert.
Comment 3 Phokgôan Chio̍h 2006-12-13 08:32:42 UTC
(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?
Comment 4 Rob Church 2006-12-13 15:37:40 UTC
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.
Comment 5 Shinjiman 2006-12-16 07:43:43 UTC
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".
Comment 6 a-giau 2006-12-19 05:49:38 UTC
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.
Comment 7 Rob Church 2006-12-19 11:55:23 UTC
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.
Comment 8 Phokgôan Chio̍h 2007-01-31 18:54:48 UTC
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. :)
Comment 9 David Augusto Villa 2007-04-06 07:01:35 UTC
This would be useful across many other projects as well, the English 
Wiktionary for certain.
Comment 10 Brion Vibber 2007-04-16 16:02:32 UTC
I've set up a redirect for nan.wikipedia.org for the moment.
Comment 11 Shinjiman 2007-04-17 01:39:45 UTC
The 'yue' in Names.php was added in r21200. It's also need to set up for the 
subdomain, too.
Comment 12 Henry Li 2007-06-24 14:42:33 UTC
Dear administrator,

  Please move Cantonese Wikipedia from zh-yue to yue.  The name has been prepared.  It has been 2 months after last comment.
Comment 13 sl 2007-06-26 12:30:18 UTC
All non ISO-639-1 or ISO-639-3 codes should be changed right away, leaving redirects are enough.
Comment 14 hillgentleman 2007-08-18 07:41:01 UTC
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.
Comment 15 Micke Nordin 2008-03-28 10:20:46 UTC
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
Comment 16 Jon Harald Søby 2008-03-28 12:32:38 UTC
(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.
Comment 17 Dylan Wong 2008-07-06 13:36:13 UTC
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".
Comment 18 Henry Li 2008-07-22 06:30:13 UTC
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.
Comment 19 Kenny Pang 2008-08-01 18:41:34 UTC
upgraded priority due to ISO code issue.
Comment 20 sl 2008-08-02 15:29:28 UTC
Apart from “zh-yue” → “yue” and “zh-min-nan” → “nan”, “roa-rup” should be changed to “rup” too.
Comment 21 Dylan Wong 2009-01-21 04:50:42 UTC
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!
Comment 22 Conrad Irwin 2009-10-09 22:04:09 UTC
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)
Comment 23 Conrad Irwin 2009-12-15 19:21:27 UTC
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.
Comment 24 Philippe Verdy 2010-04-14 13:02:33 UTC
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.
Comment 25 Casey Brown 2010-04-17 00:33:36 UTC
(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).
Comment 26 Mark A. Hershberger 2011-04-04 22:33:49 UTC
We need to see consensus from the respective wikis for this to happen.
Comment 27 Mark A. Hershberger 2011-04-04 22:36:25 UTC
Closing this particular bug under "one issue, one bug" rule.  Each wiki should get consensus separately and open separate bugs.
Comment 28 Casey Brown 2011-04-04 22:50:53 UTC
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?
Comment 29 Mark A. Hershberger 2011-04-06 15:11:12 UTC
(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.
Comment 30 Mark A. Hershberger 2011-04-06 15:40:49 UTC
(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.
Comment 31 Philippe Verdy 2011-04-06 15:50:35 UTC
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)
Comment 32 Mark A. Hershberger 2011-04-06 16:02:31 UTC
> 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.
Comment 33 Mark A. Hershberger 2011-04-06 16:03:40 UTC
> I made each of the bugs depend on Bug #19886 so I don't think that is an issue.

Oops, I meant Bug #19986
Comment 34 Philippe Verdy 2011-04-06 18:22:14 UTC
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...
Comment 35 mlleepeter 2013-01-17 15:45:40 UTC
The domain name (url) "zh-min-nan.wxxxxxxxxx.org" should be changed into "nan.wxxxxxxxxx.org" too. Thanks.
Comment 36 Andre Klapper 2013-01-18 09:01:27 UTC
mlleepeter: Different problem, that's bug 28442. See "Depends on" list.
Comment 37 Deryck Chan 2013-01-23 00:42:03 UTC
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!)
Comment 38 Henry Li 2013-12-01 06:46:51 UTC
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.
Comment 39 Andre Klapper 2013-12-02 10:10:51 UTC
This is not suddenly "immediate priority". See https://www.mediawiki.org/wiki/Bugzilla/Fields#Priority
Comment 40 Gerard Meijssen 2013-12-02 10:42:36 UTC
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
Comment 41 Deryck Chan 2013-12-02 10:45:41 UTC
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?
Comment 42 Andre Klapper 2013-12-02 11:52:24 UTC
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.
Comment 43 Deryck Chan 2013-12-02 12:16:52 UTC
(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.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links