Tue, May 10
"Hani" simply mean "Chinese[Han] characters".
"vi-Hani" mean "Vietnamese, written in Chinese[Han] characters".
Chu Nho, despite widely used in Vietnam in ancient time, are written according to Classical Chinese grammar, and as such should classify as Classical Chinese text, with code "lzh", similar to comparable works from Japan, Korea, and other neighboring regions.
The existence of ISO code Jpan is for the mixed use of Kana together of Kanji in Japanese text, which is still the common writing system for Japanese system nowadays.
The existence of the ISO code Kore is for the mixed use of Hangul together with Hanja in Korean text. Although Hanja's role in Korean language have greatly diminished, it is still not unexpected to see Hanja in modern Korean text, hence the code "Kore" which represent Hanja+Hangul is still the default code for Korean language writing system, at least in South Korea.
On the other hand, I do not think the mixed use of Han characters with other writing systems, say Latin alphabets, is an expected usage in Vietnam nowadays, hence I don't think it is necessary to apply for a new ISO 15924 code for such mixed use to reflect this.
Apr 16 2022
Apr 7 2022
Mar 26 2022
I have removed the Korean part of the ticket and focus on Vietnamese writing, due to problem of ambiguity of "Kore" script tag in ISO 15924, as mentioned in December 2020.
Mar 18 2022
Mar 16 2022
I *might* have encountered the same issue in Meta, where I do hnot have the GoogleTrans widget, but this cannot be reproduced reliably
Mar 11 2022
I tested locally and if the site is read-only and you try to save your edit (assuming you opened the edit page before read-only), The response still contains the edit and you can simply click on the Submit button, nothing gets lost according to my test.
I found that, the cause of the event is likely due to https://en.wikipedia.org/wiki/User:Endo999/GoogleTrans this widget being enabled.
Feb 24 2022
Feb 20 2022
Feb 19 2022
But not the other way round. I have modified the task description accordingly.
So with the example from July 7 last year, why isn't this request proceeding?
Feb 15 2022
Conversion table used in the wiki currently:
traditional to simplified: https://zh-yue.wikipedia.org/wiki/MediaWiki:Gadget-tradsim-trad2simcore.js
simplified to traditional: https://zh-yue.wikipedia.org/wiki/User:William915/Gadget-tradsim-src2tradcore.js
Feb 12 2022
Feb 11 2022
I think this part of the original ticket
Feb 2 2022
Note that the same wishlist also have another user requesting a <del>dark</del> yellow mode. (Edit: Typo)
Jan 24 2022
Jan 21 2022
Jan 20 2022
Jan 16 2022
Note that Cantonese Wikipedia also experience similar phenomenon vs Chinese Wikipedia, according to on-site discussion record.
Note that in addition to multilingual wiki, there are also wikiprojects like Wikipedia for Min Nan, where same article on same subject are being written in same language in multiple different article using multiple script, due to technical difficulty making automatic conversion between these different articles impossible.
Currently, wikidata can only handle one site link to one script version of article on such sort of Wikipedia, and linking to another article through another wikidata QID entity, making article in the other script cannot be easily accessed through interlanguage link.
Jan 6 2022
Jan 2 2022
Sep 8 2021
Jul 2 2021
Jun 24 2021
First, according to my understanding, Wikimedia Maps doesn't use Mapnik
There were projects that used Mapnik to render arctic area by changing projection and modifying how features are rendered according to special characteristics of polar area. I am not sure whether the project still survive now, but it indicate it is noy that hard to achieve.
There are other renderers using vectorized tiles which allows easier navigation.
Still, editing maps around poles is difficult with iD or even with JOSM (without using custom plugins), and many people can't use something else. Adn there are still issues for representing objects crossing the international dateline (not solved at the OSM Serverside API, requires adaptation by the client editor to make necessary adaptations).
I think, the lack of renderer have inhibited editor software willingness to improve support for polar area rendering, and wikimedia maps as an openly available tile supporting it could help boost editors support
And nowadays editing users can edit information in the area using tools like Level 0.
Jun 15 2021
Autonym for nan-hani:
Jun 6 2021
Other than font size, font type should also be cutomizable, for people with different needs
Feb 24 2021
Dec 23 2020
and this must be easy to rename to a standard domain (languagecode.wikipedia.org) once the Language committee grants a full approval. And again, it's OK if it's just languagecode.wikipedia.org right from the start as long as patroling for vandalism works reasonably well.
Not really. There are multiple over-a-decade-old request on changing language code of a wiki and only one get achieved, and that one achieved renaming caused so much problems that all other requests are still not doable after they have been requested for over a decade
The T172035 have to be solved first
Should the task be spilt to two?
Sep 27 2020
join the two tables together.
What I mean in term of "multiple language converter" is a script level conversion separate from vocabulary level conversion. Currently the language converter in Chinese Wikipedia actually merged two different things together to handle it, that's difference in script and different in vocabulary. It might be possible for a resident in China Maimland desiring to use Traditional Chinese but use Mainland China vocabulary, but the current language conversion scheme cannot cater such list and it wouldn't make sense to add a separate conversion table just for those minority users who might have complicated family and language leaening background and thus prefer different scropts from the one they currently use
Is it currently possible to offer conversion through language converter to convert between Indian Lakh and English Million?
Jun 3 2020
I have just realized something.
Are those codes supposed to be case-sensitive?
Because, if so, then that pull request wouldn't work
And that's also what I am seeing
May 25 2020
Why "consider" instead of just requesting it this way?
May 12 2020
It seems like the custom dark vector css skin I am using now will become unusable in a while due to some breaking changes being made to css properties in mediawiki.
I think it's now a good time to introduce one of those existing skin update it and turn them ibto an official option.
(I am not really sure about why some people are arguing that it's going to be difficult when there are already something like that made by various users floating around for years)
Mar 9 2020
As mentioned in the upstream issue, the Leaflet have a "rotate" branch that can do the required thing.
Feb 23 2020
Apr 21 2019
Apr 6 2019
Mar 26 2019
Also, somewhat related, when rendering the map at https://maps.wikimedia.org/?lang=zh#15/10.6986/106.7430 , the name of openstreetmap relation 7157197 was rendered without an appropriate character, and resulted in a "tofu" empty box character instead of the character it's supposed to be rendered. The text are 茹𦨭县 which should be rendered as https://i.imgur.com/g3gfUew.png but it is currently rendered as https://i.imgur.com/S3AlPC2.png
Mar 21 2019
There were definitely >100 languages affected if language fallback didn't work in all languages, but if it's only for those that fallback to zh, and a few other languages that utilize script tag in Mediawiki project but utilize an alternative language tagging style in OSM projects, then the scope of the task could have been smaller than anticipated.
Mar 19 2019
See Also https://github.com/gravitystorm/openstreetmap-carto/issues/2208
And this also affect some other languages, see the link for further details
Is the system case-sensitive? Because the document use "zh-hans" and "zh-hant" while relevant keys in OSM are usually "zh-Hans" and "zh-Hant"
Mar 15 2019
Example link: https://maps.wikimedia.org/?lang=zh#12/24.4542/118.0906
Current text shown: https://i.imgur.com/dc5O9J2.png
Expected text shown: https://i.imgur.com/CqJmSlN.png
Jan 31 2019
Please consider the following email response given to @Liuxinyu970226 when they asked certain linguistic expert about their opinion on the matter: https://imgur.com/a/YT8bnzJ (I am not sure whether sufficient permissions have been obtained by the user for me to link the mail on the public internet but let's just look at it for now)
Well, as mentioned, the code cmg previously suggested as possible alternative is actually not appropriate according to email exchanges you have conducted with professors that know more about these terminology. And given the email exchange also confirmed that the current ISO language codes for Mongolian languages doesn't really make much sense either, it would also be wrong to use individual language code for such purpose. So following the convention already used by others should be the most sensible way to represent such text string in the wiki. But then, if certain member of Langcom stand firm on their position and unwilling to change, then no amount of sensibility can force them to change.
Nov 26 2018
Yes that could be a browser specific conversion as my Chrome browser is converting "ß" into "ss". Then again it shows that it is necessary to look at browser implementation on normalization instead of just standards.
Some characters, like "ß", "。", "｡" from the list linked above , would not normalize to become regular ASCII character even if the NFKC normalization is applied despite they can still be identified and converted into ASCII characters by browser. And the list was not extensive thus more characters could escape the NFKC normalization. Especially note worthy thing is that the two ideographic full stop would be treat as a dot by browsers and thus it can still be used to bypass blacklist of almost all url in spam blacklist.
And then for the longer term solutions, browsers may not follow standardized way in RFCs fully and might have their own way to normalize links for users and that might need to investigate behavior of each browsers
Nov 17 2018
@Liuxinyu970226 Not sure why are you asking me this here when you yourself have stated that this seems to be an inappropriate place. Anyway I think it depends on projects and communities of each projects might also have different opinions
Nov 14 2018
There are already some websites that sue Chinese-based captcha around, however it is a really really bad idea to me personally. As someone who can read and write Chinese and is also a native language user of one of the Chinese languages, it's very complicated for me to type Chinese text into computer dependent on environment and the input method available. Worse case scenario I would have to use Google Translate or Google Search to find out those matching characters over the internet and then copy them over in order to finish a localized captcha challenges. Please DO NOT implement such troublesome thing.
Nov 11 2018
Nov 5 2018
Nov 1 2018
Oct 4 2018
@Popolon I believe Monguor and all that do not/no longer use Mongolian Script in writing so that's not really relevant to the context.
Oct 2 2018
@Popolon According to my understanding assuming they are correct understanding, using Arabic as analogy, what you propose would be like making different monolingual value for "Libyan Modern Standard Arabic", "Egyptian Modern Standard Arabic", "Tunisian Modern Standard Arabic". Yes, Libyan/Egyptian/Tunisian Arabic are all different and could be considered as different languages, however there are only one single literary standard here. Surely, there are different phonetic literary standard that more closely reflect individual languages, like the Cyrillic alphabet being used to spell different Mongolic languages, which would warrant the establishment of wiki in each of their individual languages, however there are only one Classical Mongolian Script just like there are only one Modern Standard Arabic. You can say mvf is closest to Classical Mongolian in the same way as Egyptian Arabic being closest to the standard of Modern Standard Arabic, however they are not equal.
Sep 29 2018
Sorry for late reply,
@Liuxinyu970226 If the concern of ISO639's RA is "users of the codes understand that part 2 of the standard has a code that includes several coded languages in part 3.", then probably what can be done is ask for cancellation of the mvf code and khk code in the ISO639-3?
Sep 20 2018
I think I am able to edit lead section on mobile mediawiki site without js enabled using the js-less editor, because I have just tried that on English Wikipedia and it seems like it is working?
Sep 19 2018
It's also an annoyance to me as well as my current user name is supposed to start with a small letter
All these characters can also be typed into Wikipedia as part of a url, bypassing blacklist, and then get accepted by browsers which would convert them into basic ascii alphanumeric characters, and then send users to the blacklisted webpage.
Aug 30 2018
Actually my original ticket could be a little clearer...
Like clarifying that the "example" there was meant to mean there are articles in cdo/nan/hak wikipedia that are written in alternative script and thus there should be related monolingual code that would allow recording of those article names in wikidata language field.
Thus I would like to bump the request for monolingual language code cdo-hani and nan-hani.
And then for hak... Can someone verify that "Hakka (Traditional Han script)" and "Hakka (Simplified Han Script)" are proper way to describe how Hakka speakers would write their language in Han scripts?
Aug 29 2018
- If a new site is to be created for each incubator site, how will WMF turn them into a full site once they become eligible? Last time I heard about it, such redesignation seems to be very cumbersome and that's also why wp/yue and wp/nan still haven't be moved to the desired domain name after almost a decade from their initial proposal. Will it also take a decade for any new projects to get a full site if the proposal is to be adopted?
- Is it going to lengthen the entire wiki creation process, and also requires more bureaucratic processes, as well as requiting more manpower to handle each and every applications? Now it is incubator→Full site, in the proposal it will be incubator→Experimental site→Full site.
- Are those goals unachievable by overhauling incubator itself? It seems like Wikia is now going to change the url of their non-English wiki in order to save the SSL certification cost by changing urls in format of zh.community.wikia.com to community.wikia.com/zh, and each of these different language edition sites are still independent. Is that not achievable in Incubator?
- Likewise, is it possible to create such new experimental site in a way as easy as creating a new wiki site on wikia?
Aug 20 2018
The wikidata property proposal https://www.wikidata.org/wiki/Wikidata:Property_proposal/coordinate_location_GCJ02 would depend on this property datatype.
If there's no way to fix the internationalized format now then please change the format into ISO date format as a temporary fix. There's currently no way for me to tell which day a date value actually represent without trying to edit it and see the calendar pop up.
May 6 2018
Is it possible to use language converter with specific conversion group on most messages and correct them only when language converter get it wrong?
Feb 24 2018
Dec 11 2017
If I understand correctly, while this api should be internal to applications and not used by user, however it'd be used by things like mobile clients, visual editor, content scrapper, and such to obtain information for user's viewing which might still subject to some of the limitations I mentioned above?
Remove Japanese Kyujitai request as might be using variant subtag instead of script subtag could be a better idea? Although there are also problems in using variant subtag
Dec 10 2017
Remove Nushu as use case related to the language and script can be covered by using monolingual code mis due to the lack of language code for Tuhua
Dec 9 2017
As mentioned by others, it've been almost a decade since the issue was raised
Those "raising" actions are illegal, please see Bug management/Phabricator etiquette, especially:
Report status and priority fields summarize and reflect reality and do not cause it. Read about the meaning of the Priority field values and, when in doubt, do not change them, but add a comment suggesting the change and convincing reasons for it.
Sorry, a better term would be, "since the issue was submitted".
Is it possible to do the renaming task for those wikis as of current status first and then deal with whatever bugs that would appear after the renaming is to be done? As mentioned by others, it've been almost a decade since the issue was <del>raised</del>submitted, and there will be more and more legacy issue need to deal with the longer it drags on (CX didn't even exists back in the day). Things like CX would be broken but those seem to be less important.