One thing to consider:
- In the previous code application, Hainanese was mentioned as a thing to consider about before splitting out Teochew. There are currently request for a code for Hainanese which will probably take some times to handle, and I would not expect request for Teochew to surface before that one get created
OK. I'm assuming that (a) the concept of closing stale requests as I've proposed is generally acceptable, and (b) that at least in the cases other than Teochew I can proceed.
With respect to Teochew, I'm going to mark it as "on hold/waiting", pending a language code. But if we don't see a new request at SIL in a year, then I'm going to close. Please let me know if that is acceptable.
There are, in fact, a couple of other requests from 2010 still open. There are two requests on different Balochi projects, which I thought should wait until Satdeep finished his investigations into that. There is a request for "Southern Min in Hanji," which I intended to leave sitting until we had a discussion of when different scripts need different projects and when not. But apparently phabricator T165882 says that the community has agreed to a namespace for Hanji, so this can be closed as resolved. There is a request for Wiktionary Pitcairnese that can be closed as stale along the same lines as the others here. And there is a request for Wikipedia Chinuk wawa that is supported by a few pages in the Incubator, so I'm going to mark it eligible.
Steven
Sent from Outlook
From: Langcom <langcom-bounces@lists.wikimedia.org > on behalf of langcom-request@lists.wikimedia.org <langcom-request@lists.wikimedia.org >
Sent: Friday, January 26, 2018 7:00 AM
To: langcom@lists.wikimedia.org
Subject: Langcom Digest, Vol 52, Issue 24Send Langcom mailing list submissions to
langcom@lists.wikimedia.org
To subscribe or unsubscribe via the World Wide Web, visit
https://nam01.safelinks.protection.outlook.com/?url= https%3A%2F%2Flists.wikimedia. org%2Fmailman%2Flistinfo% 2Flangcom&data=02%7C01%7C% 7C05aaf450ec664bb95f6b08d564b4 70ee% 7C84df9e7fe9f640afb435aaaaaaaa aaaa%7C1%7C0% 7C636525648503572292&sdata=% 2BiBXFmVWLrvWtXh1dn3nGXg91eso5 05NBxZniVIv0ug%3D&reserved=0
or, via email, send a message with subject or body 'help' to
langcom-request@lists.wikimedia.org
You can reach the person managing the list at
langcom-owner@lists.wikimedia.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Langcom digest..."
Today's Topics:
1. Re: Final group of projects with requests lingering since
2010 (Phake Nick)
2. Re: Final group of projects with requests lingering since
2010 (MF-Warburg)
------------------------------------------------------------ ----------
Message: 1
Date: Thu, 25 Jan 2018 09:53:21 +0800
From: Phake Nick <c933103@gmail.com>
To: Wikimedia Foundation Language Committee
<langcom@lists.wikimedia.org>
Subject: Re: [Langcom] Final group of projects with requests lingering
since 2010
Message-ID:
<CAGHjPP+tUooqAWcJdrKA+nYNZY3Qi+MZnrJquY0ywOVYamSKfA@ >mail.gmail.com
Content-Type: text/plain; charset="utf-8"
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://nam01.safelinks.protection.outlook.com/?url= >https%3A%2F%2Flists.wikimedia. org%2Fpipermail%2Flangcom% 2Fattachments%2F20180125% 2F15bcb164%2Fattachment-0001. html&data=02%7C01%7C% 7C05aaf450ec664bb95f6b08d564b4 70ee% 7C84df9e7fe9f640afb435aaaaaaaa aaaa%7C1%7C0% 7C636525648503572292&sdata=HI% 2Bj0y% 2FEpw8BDRmkdvvuQUVOnUTkk4HqvMP CC12R9yI%3D&reserved=0
------------------------------
Message: 2
Date: Thu, 25 Jan 2018 15:36:33 +0100
From: MF-Warburg <mfwarburg@googlemail.com>
To: Wikimedia Foundation Language Committee
<langcom@lists.wikimedia.org>
Subject: Re: [Langcom] Final group of projects with requests lingering
since 2010
Message-ID:
<CAJKMOMXT_4_jeUay4aevXL+DYHniYh2bQCh6w+MzncU53W0RMw@ >mail.gmail.com
Content-Type: text/plain; charset="utf-8"
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://nam01.safelinks.protection.outlook.com/?url= >https%3A%2F%2Flists.wikimedia. org%2Fpipermail%2Flangcom% 2Fattachments%2F20180125% 2Fce56450b%2Fattachment-0001. html&data=02%7C01%7C% 7C05aaf450ec664bb95f6b08d564b4 70ee% 7C84df9e7fe9f640afb435aaaaaaaa aaaa%7C1%7C0% 7C636525648503572292&sdata= LJWae5O6mcuxsxqLY6ehalR8agYIzA iRLvGew7vQWvA%3D&reserved=0
------------------------------
Subject: Digest Footer
_______________________________________________
Langcom mailing list
Langcom@lists.wikimedia.org
https://nam01.safelinks.protection.outlook.com/?url= https%3A%2F%2Flists.wikimedia. org%2Fmailman%2Flistinfo% 2Flangcom&data=02%7C01%7C% 7C05aaf450ec664bb95f6b08d564b4 70ee% 7C84df9e7fe9f640afb435aaaaaaaa aaaa%7C1%7C0% 7C636525648503572292&sdata=% 2BiBXFmVWLrvWtXh1dn3nGXg91eso5 05NBxZniVIv0ug%3D&reserved=0
------------------------------
End of Langcom Digest, Vol 52, Issue 24
***************************************
_______________________________________________
Langcom mailing list
Langcom@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/langcom