I think this first set of five Wikipedia requests from 2012 is pretty straightforward, even if I am going to leave three of them open for a week to make sure nobody has a problem with my proposed disposition of the requests. However, do please start keeping an eye on these, because the next couple of sets are going to raise some policy questions that I am really going to need LangCom as a whole to address. Thank you.
----
Wikipedia Mi'kmaq<https://meta.wikimedia.org/wiki/Requests_for_new_languages/Wikipedia_Micmac> (mic): Aboriginal language of New England and the Atlantic Provinces of Canada. 7200 native speakers. Test has over 200 pages, albeit mostly one-liners with pictures. Eligible.
Valencian Wikipedia<https://meta.wikimedia.org/wiki/Requests_for_new_languages/Wikipedia_Valenc…>: This is described as the main language of the autonomous community of Valencia in Spain, and has 2.4 million speakers. It has no langcode, and a request for one was rejected in 2006, on the grounds that Valencian is simply a variety of Catalan. (SIL/Ethnologue still describes this as a dialect of Catalan.) Catalan Wikipedia apparently allows content in Valencian. Holding for one week for LangCom comments, but I propose to reject, while encouraging potential contributors to contribute to Catalan Wikipedia.
Wikipedia Prussian 2<https://meta.wikimedia.org/wiki/Requests_for_new_languages/Wikipedia_Prussi…> (prg): Prussian went extinct in the 18th century, but there are serious revival efforts underway, and apparently a first, new native speaker. Test has had some modest activity in recent months. I'm thinking we should mark as eligible, while noting that if and when it actually comes to a point of approval—it has fewer than 20 pages right now—we'd hope to see that the language revival is continuing outside WMF.
Wikipedia Khinalug<https://meta.wikimedia.org/wiki/Requests_for_new_languages/Wikipedia_Khinal…> (kjj): Endangered language of Northeast Caucasus with about 1,000 speakers. Test has about 100 pages. Eligible.
Wikipedia Romanized Khowar<https://meta.wikimedia.org/wiki/Requests_for_new_languages/Wikipedia_Romani…>: (1) There is no evidence that there is really a community needing this, particularly as a separate project. (Further, there's no evidence it couldn't be done by script converter.) (2) This is another project by RA Chitrali, whom we had trouble with on the original Khowar Wikipedia project not too long ago. Propose to reject. (On-wiki, I'm just going to use explanation 1 above. Explanation 2 is simply an additional reason to be skeptical.)
Steven
Sent from Outlook<http://aka.ms/weboutlook>
The fourth proposal on this list (Wikipedia Pinyin) has some serious policy-related questions. If you respond on nothing else, please provide an opinion on that one.
Wikipedia Simple Chinese<https://meta.wikimedia.org/wiki/Requests_for_new_languages/Wikipedia_Simple…> (zh-simple): I have a query out (in two places) to the original requestor, as well as to the Meta community, as to whether a true "simple" version really exists. However, no one has cited one on the request page over the last six years, and in any case per current policy this would incubate within Chinese Wikipedia. I'm going to give two more weeks to hear a response to that query. If the answer is "no", I will reject. If the answer is "yes", I think I would put on hold, pending some evidence that "simple" content is starting to be added to zhwiki. (And if zhwiki has a community discussion and decides it doesn't want to do this, then I will reject.) If this ends in rejection, I will encourage anyone truly interested to start at Incubator Plus.
Wikipedia Southern Ndebele<https://meta.wikimedia.org/wiki/Requests_for_new_languages/Wikipedia_South_…> (nr): An official language of the Republic of South Africa, spoken by over 2 million speakers (L1 + L2). Test has about 20 pages, but was periodically active as late as 2016. Marking as eligible.
Wikipedia Kari Seediq<https://meta.wikimedia.org/wiki/Requests_for_new_languages/Wikipedia_Kari_S…> (trv): Aboriginal language of Taiwan with about 20,000 speakers. Test has well over 1,200 pages, and had a stretch of four months in late 2016–early 2017 when it had sufficient activity to be approvable. (There is no localization yet, however.) Marking as eligible.
Wikipedia Pinyin Chinese<https://meta.wikimedia.org/wiki/Requests_for_new_languages/Wikipedia_Chines…> (coded for now as cmn, Mandarin Chinese): Here's a proposal that I think needs some serious discussion. Please read the discussion on the linked Meta page.
Arguments against:
* No separate ISO 639-3 language code
* It is proposed that this can be handled with a script converter, per (for example) T193366<https://phabricator.wikimedia.org/T193366>.
* One respondent objected to such a project taking manpower away from other Chinese-language projects.
Arguments supporting:
* Extremely widely used, and much on-line work in Chinese happens in Pinyin, not in ideographic characters.
* Proponents state (I cannot confirm) that there are many people who are "illiterate" in Chinese, not having mastered 3000 characters, who can potentially contribute to such a project. If so, that is closer to the ideal of creating projects that "anyone can edit".
I would also note that several other Chinese projects use Romanized Chinese. (All the min-nan projects are exclusively in Romanized language—see Wikipedia here<https://zh-min-nan.wikipedia.org/wiki/Th%C3%A2u-ia%CC%8Dh>; Min Dong Wikipedia<https://cdo.wikipedia.org/wiki/T%C3%A0u_Hi%C4%95k> has pages in both scripts.)
If this project is deemed eligible, I'm pretty sure that it should not be coded with "cmn". (I can let it stay that way in Incubator for now, or give it a q-code.) Test has 250 mainspace pages, and has been active periodically. Last period of substantial activity was during summer 2017.
I am going to hold back my opinion on this just yet.
Wikipedia Mesopotamian Arabic<https://meta.wikimedia.org/wiki/Requests_for_new_languages/Wikipedia_Mesopo…> (acm): In principle, as eligible as any other variety of Arabic. Test has only two pages, both created in 2016. Placing on hold pending additional contributions.
Steven
Sent from Outlook<http://aka.ms/weboutlook>
OWTB makes some good points.
* There needs to be a consultation with the Incubator admins, and then there needs to be at least one general community discussion. Concerning Incubator admins, three are here (MF-Warburg, Robin and me). Three others are at least reasonably active on Incubator (including OWTB, who is very active), another is responsive to specific requests, and two others haven't made an edit or had a logged event in over a year. Do we want that consultation to be on-wiki (public)? Or should we invite any/all of them to have temporary rights to this list, and discuss it semi-privately here first.
* I don't know if the community discussion should be on Incubator (and advertised at Meta [and Beta]), on Meta (and advertised on Incubator [and Beta]), or if there should be two. And when do we start it? Thoughts?
As far as substantive issues go, there are really two separate issues (or constituencies) that partially overlap that are being conflated here.
* I am strongly in favor of moving the strongest, most active test projects into incubation subdomains. I think that's a great idea. Giving those projects more complete functionality, especially access to WD, and getting rid of Incubator peculiarities like prefixes, is all certainly worthwhile for them. None of the downsides I'm going to point out below really apply to them. So if we can manage an admin interface that continues to let us help them manage spam, bots, etc., and if there are no more than about 20 of them, I think this would be fantastic.
The other issue (which OWTB doesn't mention) is the creation of brand new test projects. The idea is to make it easier for new test wikis, to give them all of the associated functionality that full projects have, and that without all of Incubator's peculiarities. And in principle, that's a great idea. Still, I think there are also a lot of potential problems with this.
* How do we decide what constitutes a serious enough request to press the button? For "subsequent projects in existing languages", it would be easy enough to require some activity history in the existing wiki(s). But for new languages, how do you do that? Yes, deciding the language is "eligible" is a necessary condition. But sufficient?
* Even now, there continue to be LTA's coming and creating new requests that are effectively spurious. They're valid on their face—language is eligible—but requesters don't speak the language, and no community exists. (It happens less now that I am patrolling there, but it still happens.) For now, at minimum we wait until there are people around who create some content before saying, "eligible". That at least demonstrates that a couple of people are present and actually creating content that appears to be in the right language.
* I am extremely worried that this will turn into the "bad old days", where just about anyone could create a project, and many fell into disuse (and/or were never serious). Do we want "The Wild West" again?
* Yet the idea of making things easier for outright newbies is a very worthwhile one.
I think many of these things have to be discussed, by us and by the Incubator admins, and then by the community, before pulling the trigger for anything except moving the largest, most active wikis. (Even that should also be discussed, of course, but that is likely to be more straightforward.)
In the meanwhile, I think there are three things that we can do right now to see if we can alleviate some of the current editing issues on Incubator right now:
1. Turn on the "Add Prefix" gadget by default. It doesn't make all the prefix-related problems go away, but it simplifies them quite a lot. Just about everyone except sysops (and similar people who do a lot of maintenance) ought to have this on. [I can open a discussion on Incubator about this today, and trigger it in seven days unless there are objections.]
2. Use the authority of LangCom to set a priority to get some kind of access to Wikidata turned on right away. I think a lot of what is holding that up is the challenge of multiple iw links from Incubator. So let's simply not allow/demand/require that for now. Most of the capability currently exists somewhere within the WMF world to allow Incubator's pages (a) to call information from Wikidata into things like infoboxes, and even (b) to produce an iw list to appear on our pages. Much of that capability includes the possibility of calling information from Qxxx even when the page you're editing is associated with Qyyy; all you have to do is add "|q=xxx" as a parameter. So we simply require such a parameter. Access to WD would help a lot.
3. Less important, but useful: Finish fixing some of the problems with Incubator extension (like the default info pages and especially their links to Wikipedia projects).
We can see how much some of these things help while we start practicing on the less controversial, bigger test projects. And then we can decide where to go.
Steven
Sent from Outlook<http://aka.ms/weboutlook>
Hi,
In February we discussed the Western Armenian Wikipedia.
Here's the request:
https://meta.wikimedia.org/wiki/Requests_for_new_languages/Wikipedia_Wester…
As a reminder, it is a somewhat special case, because the current pages are
not in an incubator, but in categories in the Armenian Wikipedia.
MF-Warburg said that they can be imported to a new domain just as easily.
Here are the links to the collections of current pages, which I received by
email:
=============
Articles: https://hy.wikipedia.org/wiki/%D4%BF%D5%A1%D5%BF%D5%A5%D5%
A3%D5%B8%D6%80%D5%AB%D5%A1:%D4%B1%D6%80%D5%A5%D6%82%D5%B4%
D5%BF%D5%A1%D5%B0%D5%A1%D5%B5%D5%A5%D6%80%D5%A7%D5%B6_%D5%
B5%D6%85%D5%A4%D5%B8%D6%82%D5%A1%D5%AE%D5%B6%D5%A5%D6%80_%
D5%A1%D5%B5%D5%A2%D5%A2%D5%A5%D5%B6%D5%A1%D5%AF%D5%A1%D5%B6_
%D5%AF%D5%A1%D6%80%D5%A3%D5%B8%D5%BE
Templates: https://hy.wikipedia.org/wiki/%D4%BF%D5%A1%D5%BF%D5%A5%D5%
A3%D5%B8%D6%80%D5%AB%D5%A1:%D4%BF%D5%A1%D5%B2%D5%A1%D5%BA%
D5%A1%D6%80%D5%B6%D5%A5%D6%80_(%D5%A1%D6%80%D6%82%D5%B4%D5%BF%E2%80%A4)
Categories: https://hy.wikipedia.org/wiki/%D4%BF%D5%A1%D5%BF%D5%A5%D5%
A3%D5%B8%D6%80%D5%AB%D5%A1:%D4%BF%D5%A1%D5%BF%D5%A5%D5%A3%
D5%B8%D6%80%D5%AB%D5%A1%D5%B6%D5%A5%D6%80_(%D5%A1%D6%80%D6%
82%D5%B4%D5%BF%E2%80%A4)
=============
The translation of all the most used messages in translatewiki is now
complete.
Can we move towards approving it? Does anybody know an Armenian language
expert to verify this?
Thanks!
--
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
http://aharoni.wordpress.com
“We're living in pieces,
I want to live in peace.” – T. Moore
I responded to the security/monitoring question at phabricator. With some tweaks, it's probably a reasonable way to start. Again, though, even though I think that your biggest concern (perhaps rightly so) is the creation of brand new wikis, there seem to be a whole lot of good reasons to test this whole idea first. And the well-established, near-enough-to-approval tests, are the best ones to test on.
Steven
Sent from Outlook<http://aka.ms/weboutlook>
________________________________
From: Langcom <langcom-bounces(a)lists.wikimedia.org> on behalf of langcom-request(a)lists.wikimedia.org <langcom-request(a)lists.wikimedia.org>
Sent: Sunday, July 29, 2018 4:39 AM
To: langcom(a)lists.wikimedia.org
Subject: Langcom Digest, Vol 58, Issue 16
Send Langcom mailing list submissions to
langcom(a)lists.wikimedia.org
To subscribe or unsubscribe via the World Wide Web, visit
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.wik…
or, via email, send a message with subject or body 'help' to
langcom-request(a)lists.wikimedia.org
You can reach the person managing the list at
langcom-owner(a)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: Please read: Fixing Incubator (Amir E. Aharoni)
----------------------------------------------------------------------
Message: 1
Date: Sun, 29 Jul 2018 11:39:25 +0300
From: "Amir E. Aharoni" <amir.aharoni(a)mail.huji.ac.il>
To: Wikimedia Foundation Language Committee
<langcom(a)lists.wikimedia.org>
Subject: Re: [Langcom] Please read: Fixing Incubator
Message-ID:
<CACtNa8s9UbgVja-_URLJpuxT711oHNeGKFk__CRbzigWaPJ2Yw(a)mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
As promised, a more detailed reply. (Sorry it took me a bit—my laptop was
crashing strangely.)
Arjan's main question was about monitoring vandalism across multiple
incubator wikis, which are suggested in the proposal. And my answer is
no—at the moment I don't have more details about it.
Obviously, this cannot be done without a clear and agreed solution to this
problem, or at least an agreement to make a temporary conditional
experiment. That's why I wrote in the Phabricator task: "Patroling all such
domains for vandalism must be at least as easy as it is for Incubator". I
don't have a complete solution to this, but it's clear that it's a
sine-qua-non condition for moving forward.
My plan was to bring this up at Incubator's own community discussion pages.
The closest thing that I have currently to a written proposal to monitor
wikis is the one by Martin Urbanec at his comment on Phabricator:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fphabricat…
Does this sound like a beginning of something sensible and feasible? Or is
it too technical and complex and inappropriate?
--
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Faharoni.wo…
“We're living in pieces,
I want to live in peace.” – T. Moore
2018-07-26 11:32 GMT+03:00 Arjan Verheijden <arjanverheijden(a)hotmail.com>:
> Hi!
>
>
> I have to tell that I am not very happy about this being discussed without
> consulting the admins of the Incubator. There has been no announcement
> about this discussion, nor even a simple message on admin's talk pages
> about this. If I weren't subscribed to the LangCom mailing list, I wouldn't
> even have known this discussion was taking place.
>
>
> As a lot is pretty technical, I can only comment on what I think this
> proposal is about.
>
>
> I agree that there are some major issues on the Incubator concerning edit
> comfort (prefixes, standard templates/modules, wikidata, etc.). If I
> understand correctly, the idea is to split off the most active tests into
> own semi-subdomains. A big problem that will have to be addressed with this
> is that separate domains require way more monitoring. Now, with all tests
> in one wiki, it is easy for the Incubator team to remove spam, vandalism,
> errors in pages, etc, and easy to run bots for broken redirects etc. With
> separate domains, that will become an impossible task, unless somekind of
> admin interface is created in which all tests can be monitored from one
> Recent Changes.
>
>
> I saw in the Phabricator task: "Patroling all such domains for vandalism
> must be at least as easy as it is for Incubator." Is anything known about
> the status of this? Has a solution already been found?
>
>
> Greetings,
>
> Owtb
>
>
> ------------------------------
> *Från:* Langcom <langcom-bounces(a)lists.wikimedia.org> för Amir E. Aharoni
> <amir.aharoni(a)mail.huji.ac.il>
> *Skickat:* den 26 juli 2018 07:42
> *Till:* Wikimedia Foundation Language Committee
> *Ämne:* Re: [Langcom] Please read: Fixing Incubator
>
>
>
> 2018-07-25 20:04 GMT+03:00 Steven White <Koala19890(a)hotmail.com>:
>
> >... I really don't want this
> >discussion to go in the direction of arguing about historical languages
> >policy. ...
>
> Me, either. But for the moment Incubator needs to continue to serve those
> test projects.
>
>
> No problem.
>
>
> >... I even welcome you to create semi-artificial
> >criteria that would put the number of the first test wikis at around 50 :)
>
> I can manage that.
>
> >I guess that I'd do one of the following:
> >
> >1. Define what does "a while" mean. For example, we can decide, somewhat
> >arbitrarily, that a project under incubator.wikimedia.org
> <https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fincubator.…>
> in which there
> >were no edits for over a year, will be considered "dormant" and that a
> test
> >wiki won't be created for it until somebody asks.
> >2. Just use case by case intuition.
>
> Right now I am using a blend of the above. I tend to use page creations,
> not edits, because from time to time you get random edits from people who
> sweep through and update the name of the current prime minister in the
> infobox, without really doing anything else, and I'm not sure those really
> reflect "activity".
>
>
> They don't. It should all be done in Wikidata, for a lot of reasons, and
> this is one of those reasons.
>
>
> That said, I also ignore page additions by certain people I know are doing
> maintenance (me, Liuxinyu970226, others). I also ignore cases where the
> only page addition comes from the automatic creation of a redirect after a
> page move. Finally, for this purpose, we ignore single page creations from
> IPs.
>
> >> - Conversely, many tests open with a flurry of activity (over 1
> day
> >> to 2 months), then go dormant.
> >
> >So, here's my theory behind the whole proposal: In the current incubator,
> >people quickly create a bunch of articles on topics that interest them,
> >sometimes with some boilerplate (cities, countries, animals), but but then
> >they get tired of the prefixes, the outdated translation techniques, the
> >weird searching, the missing templates, etc., and give up. Perhaps with a
> >single wiki these difficulties will be alleviated. I know it sounds a bit
> >too optimistic, but at least I want to get rid of these most glaring and
> >arbitrary difficulties, with the hope that it will help people remain
> >active.
>
> You may be right. I just don't know. Do we have feedback saying so? Or is
> this just everyone's gut instinct. (Mind you, I can't possibly say I
> disagree.)
>
>
> Observing people in real life editing in Incubator, many times. In
> particular, in Kabardian, Adyghe, Fon, and Dinka, with which I've had a
> closer relationship.
>
> And a few days ago there was a presentation at Wikimania that makes pretty
> much the same complaints: https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.youtu…
> v=yMOS19Dj7rU&t=29m
> <https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.youtu…>
> .
>
>
>
>
> That said, this approach doesn't solve all the problems you describe. In
> particular, this won't automatically create basic templates and modules,
>
>
> Yes. I'm working on that in a separate initiative. It's complicated, but
> much-needed.
>
>
> And at the end of the day, contributors to new tests still have to write
> or translate pages.
>
>
> Of course, as they do in usual wikis. It's not without issues, but at
> least it will have proper search, Wikidata, and Content Translation, and no
> prefixes.
>
>
>
> >Yes, I tend to think that we should allow to create new subdomains for
> >*eligible* languages right away, so that all of them will get equal
> >treatment as early as possible, from the very first page.
>
> In order to do this, then, a few things would have to happen in fairly
> short order, once we're ready to approach the problem like that.
>
>
> - The "Requests for new languages" system on Meta will have to have
> teeth, and to be the arbiter for whether a project is (a) eligible for an
> incubation subdomain, (b)(interim, at least) should start on Incubator, or
> (c) is not eligible. IF THAT IS TO BE MEANINGFUL, I NEED LANGCOM MEMBERS TO
> RESPOND TO MY SUBMISSIONS ON SUCH MATTERS, or to go to Meta and mark
> projects eligible themselves. I appreciate that people are generally
> allowing me to call those shots right now, but since just about anyone can
> start a test project on Incubator, the stakes on decisions about "eligible"
> aren't all that high right now. The stakes will become higher under this
> new regimen.
>
>
> Yes, this is pretty obvious.
>
> I do envision that the incubator wiki creation will a mostly automatic
> process. There is no good reason for it to require any manual intervention
> from Ops engineer, as it happens now. There should be a simple form
> somewhere on one of our other wikis, probably Meta or
> wikitech.wikimedia.org
> <https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwikitech.w…>
> , where one will have to fill project family (pedia, voyage, etc.),
> language code, autonym, text direction, logo file name—and push a button.
> The interesting question is who should have the permission to fill this
> form and push the button. My immediate thought is "language committee
> members", of course, but other ideas are welcome.
>
>
>
> - FWIW, in clearing the backlog at RFL, we're almost to the end of
> requests dating to 2012 or earlier, and have addressed almost all of the
> 2017 and 2018 requests (except those in the last month or so).
>
>
> Have I mentioned how much do I appreciate what you do there? It's truly
> wonderful that you are taking care of this backlog.
>
>
> _______________________________________________
> Langcom mailing list
> Langcom(a)lists.wikimedia.org
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.wik…
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.wik…>
------------------------------
Subject: Digest Footer
_______________________________________________
Langcom mailing list
Langcom(a)lists.wikimedia.org
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.wik…
------------------------------
End of Langcom Digest, Vol 58, Issue 16
***************************************
My comments also inline, with unnecessary portions redacted.
Steven
>> - As of the last major evaluation of Incubator (last winter), there
>> were 1,020 tests on Incubator with at least one valid page of content. One
>> was the most recently exported project, which we generally keep as a
>> duplicate on Incubator for administrative reasons. Of the other 1,019:
>>
>0. Woah, I didn't think it's so many.
>1. Having these numbers is super-valuable, thanks.
>2. How did you count? Is there a tool?
>> -
>> - 502 (49%) were either "active" (defined as one new page creation
>> since the beginning of 2017) or "substantial" (defined as having at least
>> 25 mainspace pages), or both. This included two that were approved but
>> awaiting creation at the time.
>>
>1. Again, how did you count?
>2. Are the terms "active" and "substantial" defined anywhere? Or did you
>coin them ad hoc for this thread?
>3. 500 is quite a lot. If we suddenly create wikis for all of them
>according to my proposal, this will be a huge sudden addition of languages
>to the interlanguage links list, at least in a few hundreds articles, and
>this may be too many to add at once.
>4. Do you know what is the per-project breakdown—Wikipedia, Wikivoyage,
>Wikibooks, etc.?
Breakdown is available at https://incubator.wikimedia.org/wiki/Template:Test_status_statistics#28 February 2018. (The "almosts" are usually in comments inserted within the various subtemplates of "Template:Tests" on Incubator.) I first created those terms/criteria when I did my first review in the summer of 2017, except that at the time the date for new page creation was the mid-2016. I rolled that forward in the winter review. The criteria are arbitrary, but for my purposes as admin on Incubator, what I needed was (a) a good idea of what was going on, not necessarily perfection, and (b) to make sure that I was construing tests as active or substantial whenever that was reasonable. For a purpose like this, those criteria may be too generous.
I count the tests by hand, which is very labor intensive, and means I probably get some wrong. (The advantage, I guess, is that I have found tests whose content is invalid and deleted them over the course of time.) There used to be a tool for at least part of it, but it hasn't been maintained for a long time, and I don't know how. It takes 6–8 weeks to do this, and I have a day job—which is why I only do it about twice a year.
Not all of the 500 are new languages. Some are second projects in existing languages. But there are plenty of new languages in that group, to be sure.
>Let's approve them[1] :)
I know that's a joke. FWIW, they all have other reasons not to be approvable. But I wanted to keep a closer eye on such projects.
>... I really don't want this
>discussion to go in the direction of arguing about historical languages
>policy. ...
Me, either. But for the moment Incubator needs to continue to serve those test projects.
>... I even welcome you to create semi-artificial
>criteria that would put the number of the first test wikis at around 50 :)
I can manage that.
>I guess that I'd do one of the following:
>
>1. Define what does "a while" mean. For example, we can decide, somewhat
>arbitrarily, that a project under incubator.wikimedia.org in which there
>were no edits for over a year, will be considered "dormant" and that a test
>wiki won't be created for it until somebody asks.
>2. Just use case by case intuition.
Right now I am using a blend of the above. I tend to use page creations, not edits, because from time to time you get random edits from people who sweep through and update the name of the current prime minister in the infobox, without really doing anything else, and I'm not sure those really reflect "activity". That said, I also ignore page additions by certain people I know are doing maintenance (me, Liuxinyu970226, others). I also ignore cases where the only page addition comes from the automatic creation of a redirect after a page move. Finally, for this purpose, we ignore single page creations from IPs.
>> - Conversely, many tests open with a flurry of activity (over 1 day
>> to 2 months), then go dormant.
>
>So, here's my theory behind the whole proposal: In the current incubator,
>people quickly create a bunch of articles on topics that interest them,
>sometimes with some boilerplate (cities, countries, animals), but but then
>they get tired of the prefixes, the outdated translation techniques, the
>weird searching, the missing templates, etc., and give up. Perhaps with a
>single wiki these difficulties will be alleviated. I know it sounds a bit
>too optimistic, but at least I want to get rid of these most glaring and
>arbitrary difficulties, with the hope that it will help people remain
>active.
You may be right. I just don't know. Do we have feedback saying so? Or is this just everyone's gut instinct. (Mind you, I can't possibly say I disagree.)
That said, this approach doesn't solve all the problems you describe. In particular, this won't automatically create basic templates and modules, and especially not ones customized by language. (To that end, I've started to collect a handful of really basic templates—not modules—in the fictitious Wp/qdp test, which people can subst: and then customize within their tests. But I haven't done nearly as much as I would like on that; there's too much else to do.) And at the end of the day, contributors to new tests still have to write or translate pages.
>Yes, I tend to think that we should allow to create new subdomains for
>*eligible* languages right away, so that all of them will get equal
>treatment as early as possible, from the very first page.
In order to do this, then, a few things would have to happen in fairly short order, once we're ready to approach the problem like that.
* The "Requests for new languages" system on Meta will have to have teeth, and to be the arbiter for whether a project is (a) eligible for an incubation subdomain, (b)(interim, at least) should start on Incubator, or (c) is not eligible. IF THAT IS TO BE MEANINGFUL, I NEED LANGCOM MEMBERS TO RESPOND TO MY SUBMISSIONS ON SUCH MATTERS, or to go to Meta and mark projects eligible themselves. I appreciate that people are generally allowing me to call those shots right now, but since just about anyone can start a test project on Incubator, the stakes on decisions about "eligible" aren't all that high right now. The stakes will become higher under this new regimen.
* It will also have to respond fairly quickly to new requests.
* FWIW, in clearing the backlog at RFL, we're almost to the end of requests dating to 2012 or earlier, and have addressed almost all of the 2017 and 2018 requests (except those in the last month or so).
>... I don't think that the current Incubator makes anything
>easy for anyone, but hey, I may be missing something.
It doesn't. But remember that before the current policies and practices were in place, it almost became too easy. I'm mostly with you on making things easier for people who have never done this before. But I don't want to make it so easy that we get a lot of frivolous requests, incubations and projects. And believe me, there have been a lot of them over time. (I removed three new, frivolous requests just today.)
1. Marking request for Khorasani Turkic as "on hold" for up to one year until test is converted to Perso-Arabic.
2. Michael: Have you looked into Prussian yet?
Steven
Sent from Outlook<http://aka.ms/weboutlook>
>I do envision that the incubator wiki creation will be a mostly automatic
>process. There is no good reason for it to require any manual intervention
>from Ops engineer, as it happens now. There should be a simple form
>somewhere on one of our other wikis, probably Meta or wikitech.wikimedia.org,
>where one will have to fill project family (pedia, voyage, etc.),
>language code, autonym, text direction, logo file name—and push a button.
>The interesting question is who should have the permission to fill this
>form and push the button. My immediate thought is "language committee
>members", of course, but other ideas are welcome.
Right now, both members of the global group "New wikis importers" are also LangCom members (MF-Warburg and SPQRobin). But I think in principle anyone in that group, even if not on LangCom, could appropriately do this. (Beyond that, it might depend on just what the criteria are for someone to make a valid request for an incubation subdomain. But that's a discussion for another time.)
>Have I mentioned how much do I appreciate what you do there? It's truly
>wonderful that you are taking care of this backlog.
As they say where you come from ... בבקשה!
Steven
As I wrote at the phabricator task, I agree in principle. But the devil is in the details, of course, and as one of the couple of people who are de facto running Incubator right now, I need to be involved in all of this.
One of the things that this discussion has me thinking about, though, is whether Incubator should actually be effectively closed and locked, or whether there should be three tiers: projects, incubating projects, and then Incubator. Here's why I'm thinking along these lines (even if only as a transition step):
* As of the last major evaluation of Incubator (last winter), there were 1,020 tests on Incubator with at least one valid page of content. One was the most recently exported project, which we generally keep as a duplicate on Incubator for administrative reasons. Of the other 1,019:
* 502 (49%) were either "active" (defined as one new page creation since the beginning of 2017) or "substantial" (defined as having at least 25 mainspace pages), or both. This included two that were approved but awaiting creation at the time.
* Of the remainder, only 15 had sufficient activity to meet the project approval activity requirement. Perhaps another 15 or so were pretty close.
* My estimate (purely an estimate) is that there are rarely more than 40–50 tests with substantial activity at any point in time.
* Incubator also provides a certain buffer zone around tests that are kind of borderline with respect to the current Language Proposal Policy. Many such projects are all the same very legitimate tests with communities working on them, and meet Incubator's less restrictive rules for creating tests.
* See https://incubator.wikimedia.org/wiki/Category:Incubator:Test_wikis/open-but…. Many of the projects in this category are Wikipedias in historical languages, and a handful of those are quite active.
* Looking at the above, I'm pretty sure that at least at the beginning, we should only move out the most active projects, perhaps 20 to no more than about 50. This way, we can get the bugs out without having created 500 or so incubation subdomains. Certainly during that period of time Incubator would stay open as usual for all other tests. After that, I think there are some serious things to think about:
* If a test is fairly substantial (25 pages? 100 pages?), do we create the incubation subdomain even if the test has been dormant for a while?
* Conversely, many tests open with a flurry of activity (over 1 day to 2 months), then go dormant. Going forward, do we really want to create incubation subdomains for these right away, and then have them go dark? Or do we want there to be some kind of threshold for creating incubation subdomains? And if there's some kind of threshold, then Incubator needs to remain alive for projects not yet there.
What I think makes a lot of sense is for the most active, close-to-ready tests to move into incubation subdomains, where they can start having access to Wikidata, get rid of prefixes, and so forth. I'm not sure that means there isn't a place for Incubator as a place for projects to get started in the extreme early stages.
Steven
Sent from Outlook<http://aka.ms/weboutlook>
No one ever commented again on this, leaving one member supporting (Michael) and one opposing (Gerard). I want to close this somehow. Remember that the test project itself is small, and nowhere close to approval.
Based on policy, I think that we should mark this eligible--since the language is eligible--and add a comment (on the request page) that the project will not likely be approved until/unless it is converted to Perso-Arabic script, at least at parity to Latin script.
I don't actually think that there are policy grounds to reject this, since the language is eligible. The alternative approach, to me, is to mark this as "on hold, pending a community working to convert this to Perso-Arabic script", and then rejecting as stale if that doesn't happen in a year.
Thoughts?
Steven
Sent from Outlook<http://aka.ms/weboutlook>