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

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: Unknown Object (MLST).
bzimport set Reference to bz8217.

leon wrote:

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

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

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.

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

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

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.

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.

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.

Mvolz set Security to None.Mar 21 2015, 2:51 PM
Mvolz added a subscriber: Mvolz.
Dzahn added a subscriber: Dzahn.May 7 2015, 12:19 AM

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.

Restricted Application added a subscriber: Matanya. · View Herald TranscriptAug 19 2015, 8:19 PM
Koavf added a subscriber: Koavf.Aug 25 2015, 6:01 AM
Restricted Application added a subscriber: JEumerus. · View Herald TranscriptFeb 17 2016, 12:09 AM
Kaihsu raised the priority of this task from "Normal" to "High".Sat, Apr 2, 8:23 PM
Kaihsu added a subscriber: Kaihsu.

This bug is nearly a decade old. Could we please get some impetus to fix it?

Restricted Application added a subscriber: Dereckson. · View Herald TranscriptSat, Apr 2, 8:23 PM
Kaihsu awarded a token.Sat, Apr 2, 8:27 PM
Aklapper lowered the priority of this task from "High" to "Normal".Sun, Apr 3, 9:06 AM

The priority of this task was increased.

@Kaihsu: As priority reflects reality and does not cause it, could you please elaborate why this task has suddenly become more urgent? If you increased priority because you plan to work on this task (thanks!) please claim the task by setting yourself as assignee. Thank you for your help!

Kaihsu added a comment.EditedSun, Apr 3, 12:14 PM

It has not suddenly become urgent. For the users, it has been urgent for a decade. The earlier comments show that the users who raised this issue were ignored. Because of this bug, the users have not been able to take advantage of some advances in software. For example, this link does not go to the correct mobile version: https://nan.m.wikipedia.org/ cf. https://fr.m.wikipedia.org/

The bug should be assigned to someone who has the knowledge and system access to make the correct changes, so this can actually be fixed.

It would help if it can be explained what is blocking the issue and who to contact to solve the problem.

It has not suddenly become urgent. For the users, it has been urgent for a decade. The earlier comments show that the users who raised this issue were ignored. Because of this bug, the users have not been able to take advantage of some advances in software. For example, this link does not go to the correct mobile version: https://nan.m.wikipedia.org/ cf. https://fr.m.wikipedia.org/

It is obvious that the bug should be assigned to someone who has the knowledge and system access to make the correct changes, so this can actually be fixed.

It has not been explained clearly what is blocking the issue and who to contact to solve the problem.

Is T31186#1625347 helpful?

Dzahn removed a subscriber: Dzahn.Mon, Apr 11, 5:31 PM

Add Comment