Requests for new languages/Wikipedia Istriothttps://meta.wikimedia.org/wiki/Requests_for_new_languages/Wikipedia_Istriot: Currently on hold. There are a few pages on Incubator, but nothing added in several years. Propose to reject as stale, without prejudice for a new request if a community comes back to work on a project.
Requests for new languages/Wikipedia Teochewhttps://meta.wikimedia.org/wiki/Requests_for_new_languages/Wikipedia_Teochew: Currently on hold due to no ISO code. Code was rejected at SIL in 2009. At the time, SIL expressed some sympathy for the idea of retiring "nan" and splitting it. But as the code request did not cover the full breadth of "nan", the request was rejected. There has been no recurrent request, to the best of my knowledge. Suggest reject per policy, with an invitation to create a new request if a code is ever created.
Requests for new languages/Wikipedia Unserdeutsch 2https://meta.wikimedia.org/wiki/Requests_for_new_languages/Wikipedia_Unserdeutsch_2: About 100 L1 speakers left, mostly living in Australia. No test project, and no evidence of native speakers. If this were a new request, I'd probably mark as "on hold". As it is, we should probably reject as stale, without prejudice for a new request if a community comes back to work on a project.
Requests for new languages/Wikipedia Pandan Bikol (Northern Catanduanes Bikol)https://meta.wikimedia.org/wiki/Requests_for_new_languages/Wikipedia_Pandan_Bikol: About 78,000 speakers. No evidence of any native speakers present since request was made. Also member of a macrolanguage (Bikol): bik. Within macrolanguage, existing Wikipedia for Central Bikol (bcl), fairly developed test projects for Miraya Bikol (Wp/rbl) and Rinconada Bikol (Wp/bto), though no substantive additions since 2015. This language's test has a single page that might not even be in the language. Should probably reject this as stale, without prejudice for a new request.
Requests for new languages/Wikipedia Simple Hebrewhttps://meta.wikimedia.org/wiki/Requests_for_new_languages/Wikipedia_Simple_Hebrew: Reject: (a) If a project like this is ever to exist, current policy is that it must incubate at the corresponding project, in this case Hebrew Wikipedia. (b) If such an incubation wants to get out of the base project, that can only happen if the project (or namespace) uses an externally defined simple version of the language, and I'm not aware that one even exists in Hebrew.
Sent from Outlookhttp://aka.ms/weboutlook
Is there a reason for preferring "reject as stale" over "on hold, waiting for native speakers [or something else]", other than looking better in the "last action" column? I don't mind either way.
2018-01-22 17:27 GMT+01:00 Steven White Koala19890@hotmail.com:
Requests for new languages/Wikipedia Istriot https://meta.wikimedia.org/wiki/Requests_for_new_languages/Wikipedia_Istriot: Currently on hold. There are a few pages on Incubator, but nothing added in several years. Propose to * reject as stale*, without prejudice for a new request if a community comes back to work on a project.
Requests for new languages/Wikipedia Teochew https://meta.wikimedia.org/wiki/Requests_for_new_languages/Wikipedia_Teochew: Currently on hold due to no ISO code. Code was rejected at SIL in 2009. At the time, SIL expressed some sympathy for the idea of retiring "nan" and splitting it. But as the code request did not cover the full breadth of "nan", the request was rejected. There has been no recurrent request, to the best of my knowledge. Suggest *reject* per policy, with an invitation to create a new request if a code is ever created.
Requests for new languages/Wikipedia Unserdeutsch 2 https://meta.wikimedia.org/wiki/Requests_for_new_languages/Wikipedia_Unserdeutsch_2: About 100 L1 speakers left, mostly living in Australia. No test project, and no evidence of native speakers. If this were a new request, I'd probably mark as "on hold". As it is, we should probably *reject as stale*, without prejudice for a new request if a community comes back to work on a project.
Requests for new languages/Wikipedia Pandan Bikol (Northern Catanduanes Bikol) https://meta.wikimedia.org/wiki/Requests_for_new_languages/Wikipedia_Pandan_Bikol: About 78,000 speakers. No evidence of any native speakers present since request was made. Also member of a macrolanguage (Bikol): bik. Within macrolanguage, existing Wikipedia for Central Bikol (bcl), fairly developed test projects for Miraya Bikol (Wp/rbl) and Rinconada Bikol (Wp/bto), though no substantive additions since 2015. This language's test has a single page that might not even be in the language. Should probably *reject this as stale*, without prejudice for a new request.
Requests for new languages/Wikipedia Simple Hebrew https://meta.wikimedia.org/wiki/Requests_for_new_languages/Wikipedia_Simple_Hebrew: *Reject:* (a) If a project like this is ever to exist, current policy is that it must incubate at the corresponding project, in this case Hebrew Wikipedia. (b) If such an incubation wants to get out of the base project, that can only happen if the project (or namespace) uses an externally defined simple version of the language, and I'm not aware that one even exists in Hebrew.
Sent from Outlook http://aka.ms/weboutlook
Langcom mailing list Langcom@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/langcom
2018年1月23日 00:27 於 "Steven White" Koala19890@hotmail.com 寫道：
Requests for new languages/Wikipedia Teochew: Currently on hold due to no
ISO code. Code was rejected at SIL in 2009. At the time, SIL expressed some sympathy for the idea of retiring "nan" and splitting it. But as the code request did not cover the full breadth of "nan", the request was rejected. There has been no recurrent request, to the best of my knowledge. Suggest reject per policy, with an invitation to create a new request if a code is ever created.
Note that, in Wikimedia's language proposal policy, the reason being put forth for reqiring an ISO 639-3 code for the language is that, "*The information that distinguishes this language from another must be sufficient to convince standards organizations to create an ISO 639 code.*". In this case, the standardizing body is convinced that the language is sufficiently unique, despite they're not able to create the code due to problems of other nan variant. Which mean the underlying rationale behind the reason for requesting a ISO639 code is fulfilled despite the lack of code.
As, in the language proposal policy, it is said that "The committee can skip steps in the procedure if they consider a request to have already met the objectives of those steps.", I would suggest member of language committee consider marking Teochew as eligible according to this principal.
Well, but it's equally true (and written) that "If there is no valid ISO 639 code, you must obtain one. The Wikimedia Foundation does not seek to develop new linguistic entities". We do absolutely not want to invent our own codes, because that gets really messy, especially when at some point a language does get a real code.
2018-01-23 20:49 GMT+01:00 Phake Nick c933103@gmail.com:
2018年1月23日 00:27 於 "Steven White" Koala19890@hotmail.com 寫道：
Requests for new languages/Wikipedia Teochew: Currently on hold due to
no ISO code. Code was rejected at SIL in 2009. At the time, SIL expressed some sympathy for the idea of retiring "nan" and splitting it. But as the code request did not cover the full breadth of "nan", the request was rejected. There has been no recurrent request, to the best of my knowledge. Suggest reject per policy, with an invitation to create a new request if a code is ever created.
Note that, in Wikimedia's language proposal policy, the reason being put forth for reqiring an ISO 639-3 code for the language is that, "*The information that distinguishes this language from another must be sufficient to convince standards organizations to create an ISO 639 code.*". In this case, the standardizing body is convinced that the language is sufficiently unique, despite they're not able to create the code due to problems of other nan variant. Which mean the underlying rationale behind the reason for requesting a ISO639 code is fulfilled despite the lack of code.
As, in the language proposal policy, it is said that "The committee can skip steps in the procedure if they consider a request to have already met the objectives of those steps.", I would suggest member of language committee consider marking Teochew as eligible according to this principal.
Langcom mailing list Langcom@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/langcom
2018年1月25日 03:49 於 "MF-Warburg" mfwarburg@googlemail.com 寫道：
Well, but it's equally true (and written) that "If there is no valid ISO
639 code, you must obtain one. The Wikimedia Foundation does not seek to develop new linguistic entities".
My understanding on the description of "does not seek to develop new linguistic entities" is that WMF does not seek to develop new language and thus it would like confirmation from ISO standard regulation body, instead of the code itself.
We do absolutely not want to invent our own codes, because that gets
really messy, especially when at some point a language does get a real code.
Why not tentatively use e.g. ISO639-6 code as a working code in incubator or for the project before it could get a 639-1/2/3 code? after it get a code in ISO 639-1/2/3 then it should be possible to move things over. Although all the code change requests have been piled up for years in phabricator but that should hopefully be sorted out one day.
2018-01-25 2:53 GMT+01:00 Phake Nick c933103@gmail.com:
2018年1月25日 03:49 於 "MF-Warburg" mfwarburg@googlemail.com 寫道：
Well, but it's equally true (and written) that "If there is no valid ISO
639 code, you must obtain one. The Wikimedia Foundation does not seek to develop new linguistic entities".
My understanding on the description of "does not seek to develop new linguistic entities" is that WMF does not seek to develop new language and thus it would like confirmation from ISO standard regulation body, instead of the code itself.
The best confirmation is that the regulation body gives them a new code. Everything else is just in limbo and they could change their opinion later. That will be a mess then.
We do absolutely not want to invent our own codes, because that gets
really messy, especially when at some point a language does get a real code.
Why not tentatively use e.g. ISO639-6 code as a working code in incubator or for the project before it could get a 639-1/2/3 code? after it get a code in ISO 639-1/2/3 then it should be possible to move things over. Although all the code change requests have been piled up for years in phabricator but that should hopefully be sorted out one day.
I wouldn't count on that. Temporary solutions always have a tendency to become permanent.