Per local consensus.
Please note: for the Conversion Group, if zh-my option is not present, they would request to use the zh-sg option before zh-cn option and before the zh-hans option.
This would also be (and alter) the language preset of Malaysian editors who did not set their language and Malaysian IP address. For Malaysian IP address readers, their option will turn into zh-my instead of zh-sg.
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| Enable zh-my variant on zhwiki | operations/mediawiki-config | master | +0 -1 |
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | RazeSoldier | T193983 Enable zh-my language localization at the Chinese Wikipedia | |||
| Resolved | Urbanecm | T198371 All "zh-my" variant page views get 404 Not Found on zh.wikipedia.org |
Note two more things: zh-sg option should change its name to : 新加坡简体 , and zh-my option with the name 大马简体
Pinging active langcom members @Amire80 @jhsoby @StevenJ81 @millosh @GerardM and @Doc_James for possible agreement or veto, if no veto-like comments from them comming, then I can drop my oppose comment (which is shown as the only one in that list)
Anyway, priority should not be changed just by yourself (unless if you are actually working on this task by code level, in this way please assign this task to yourself and submit a gerrit patch for that).
I request a re-evaluation of this task. This task is of high priority at local logic.
As a general rule here: Priority reflects reality and does not cause it, so if you really wanna this have a high priority, please please and please 1. assign this task to yourself; 2. submit a gerrit patch; 3. ask the related develop team that if your patch is OK for them or not.
Personally, it's also a wrong case that "Priority" field can be public editable, I suggested to limit the rights to change that, to the Trusted-Contributors membership.
I do not understand the issue. Why do they want this ? What service does this provide?
My google-translated page didn't (obviously) show that there was community consensus on this. But I don't speak Chinese, and @Liuxinyu970226 does. So I can't really argue. What I can't tell is how serious the variants are.
Gerard, I think they're trying to suggest that there are local variants in the language, and that they'd like their "home" language to be their local (Malaysian, or at least Singaporean) version. But as this would only affect the interface and not the content, I'm not sure why it's that huge a deal.
Related to this: Is there an interface translation set available in zh-my (or zh-sg)? And how different is it from zh-cn?
They want this as the Malays would want to get their own Chinese Language Variant, which was completely logical. There is community consensus apart from Liuxinyu970226, who opposed it. This could be seen at the discussion page, in which all but him ( @Liuxinyu970226 ) opposed. Thus I would say there is a community consensus for this problem.
Replying @StevenJ81 : We need to enable local translation set as there are differences seen at local word choice in terms of names, objects and so on. These problem would be solved by enabling one more set dedicated to Malaysia, as the differences in between Malaysian Chinese and Singaporean Chinese is obvious for Malaysian editors.
Replying @GerardM : It provides localization possibility as stated above: some of the names were different in between Singaporean and Malaysian Chinese, thus Malaysian editors would want to add the language variant.
The language variant is enabled at Meta-wiki but is hidden at local settings
This does affect the content as we use NoteTA to alter local content, which is the major reason of enabling the variant
@1233thehongkonger Why do you think enabling interface translations is also good to you? Why you want T51898 to be happened again?
I didn't see the difference. The bug is resolved, and most importantly, the localization is already in place but it is just blacklisted.
The main point is about local content: it can now be correctly convert to a more localized version, which is done by noteTA.
Hoi,
Do I understand that in addition to traditional and simplified we now are
to have content different by country ?
Thanks,
GerardM
The content is slightly different in each language variant because of naming methods in different countries. For example, in Hong Kong, we get a set of British names which are not used in other regions, and we would use noteTA to do the conversion.
This is the case already, which means that adding this new variant would give a higher flexibility for names that are used currently in Malaysia but different at Singapore
So, as consensus exists, please enable the varient zh-my as soon as possible.
Stang: 以上关于启用zh-my的讨论是否已达成共识？
Sanmosa: Stang，应该是的。概观以上之讨论，至少绝大部分人同意启用zh-my参数。
Stang: 现进行为期7天的公示，如有意见请速提出
As @Wang_Qiliang had mentioned me, I shall translate the conversation into English:
Stang: Is there any consensus made in the discussion of enable zh-my language localization?
Sanmosa: Stang, it shall be certain. As I can see in the discussion above, most of the users joining the discussion agreed enable zh-my language localization.
Stang: Now we start a 7-day publicity, please raise if you have any comments.
Please enable zh-my as soon as possible, and also zh-sg should change its name to 新加坡简体.
the localization is already in place but it is just blacklisted.
[citation needed] because I don't see any zh-my.json files In any core and/or extensions repositories.
Please enable zh-my as soon as possible
Still waiting langcom approval.
According the code logic, zh-my fallback languages are zh-hans, zh-sg and zh-cn. It looks like we need to add zh-my.json.
There are also zh-tw.json and zh-sg.json existing in core i18n directory, but how they are maintained in the past years? If there's no significant reason that at least a community member pledges to maintain differents, and only differents (which is the reason for zh-hk but I don't see it's also for others), then I don't see how unfreezing them are having benefits.
PS: that zh-tw.json, tbh, is also just what zh-hant.json handleable, because contributors of /zh-hant messages are generally from Taiwan instead of HK.
For the title of this task, just remove the line 13705 in InitialiseSettings.php to make zhwiki supports zh-my.
Change 440651 had a related patch set uploaded (by 星耀晨曦; owner: 星耀晨曦):
[operations/mediawiki-config@master] Enable zh-my variant on zhwiki
"zh-my" is still blacklisted by Chinese Wikipedia site for unknown reason. How to solve?
The change wasn't enabled. It was just proposed. We must wait for a deployment window, then it'll be deployed.
Definitely not in this week, because this is not a emergency deploy and there's SRE Offsite in this week. It will be probably deployed in the week of June 25. I will announce exact date when I will know it. Best, Martin
Change 440651 merged by jenkins-bot:
[operations/mediawiki-config@master] Enable zh-my variant on zhwiki
I have deployed the configuration change and managed to set my user preference on https://zh.wikipedia.org/ to use the zh-my variance. So I guess it is all good now ?
Mentioned in SAL (#wikimedia-operations) [2018-06-26T13:36:42Z] <hashar@deploy1001> Synchronized wmf-config/InitialiseSettings.php: Enable zh-my variant on zhwiki - T193983 (duration: 00m 57s)
@hashar Selecting the zh-my variants (next to talk page link) and get page not found. See https://zh.wikipedia.org/zh-my/Wikipedia:%E9%A6%96%E9%A1%B5