Page MenuHomePhabricator

Allow creating an independent "incubator wiki" instead of hosting all new wikis in one Incubator wiki with prefixes
Open, Needs TriagePublic

Description

This is a a subtask of the task T165585: Make creating a new Language project easier. See that task for a description of the general and for many discussions about it. This task here focuses only on the main technical issue involved with that project: Allow creating a whole "incubator wiki" instead of hosting all new wikis in one Incubator wiki with prefixes. I'm creating it to focus the discussion on the technical solution, and to separate it from other issues, such as translatewiki configuration, language code policies, Language committee discussion process, etc. It can become a big task itself, and it may have further technical subtasks.


The Wikimedia Incubator is hard to use.

Its advantage is that having all the tiny new projects in one wiki makes it easier for the sysops to combat vandalism. However, it has many disadvantages:

  • Having to manually write prefixes on page names and on every internal link, category, and template is very tedious.
  • Counting pages is tedious.
  • Categorization is tedious and redundant.
  • Interlanguage links are problematic: they can only be added the old way and not with Wikidata (T54971).
  • ContentTranslation doesn't work, even though it could be one of the most useful features for the Incubator. It's fixable (T89089), but requires resources.

This means that writing in the Incubator is much harder for newbies than writing in a non-Incubator wiki site. This is particularly, acutely problematic given that the people writing in the Incubator are usually new to editing wikis or using the web in general. It should be easier for them, and not harder.

The problem is discussed in detail by @Pgallert in his Wikimania 2018 presentation:

The proposed solution is to make creating an actual new experimental domain easier (T158730). This domain should have special requirements:

  • Patroling all such domains for vandalism must be at least as easy as it is now for Incubator.
  • Content Translation must work, with all its features, at least for translating into the new language. This must include the setting up of all the services: cxserver, Parsoid, MT if relevant, etc. (This point applies only to projects in the families for which Content Translation is adapted in the first place. At the moment this is only Wikipedia. In the future this may include Wikivoyage and other projects.)
  • Visual Editor must work. (Already works in Incubator, but I'm making sure that it's noted here explicitly.)
  • In addition to Content Translation and Visual Editor, most usual default extensions need to be installed and configured, if they are installed on wikis in most other languages.
  • The MediaWiki translations should be exported from translatewiki.net. (It would be nice to do it even before reaching the import threshold.)
  • Internal search must work. Noting it here because this was an issue several times with newly-created projects in the past.
  • The domain must be temporary, for example for a year. It must be easy to destroy the domain without a difficult closing process if it proves to be inactive, spammy, or too prone to vandalism. This would include removing all the services configuration, search indexes, Wikidata edits in this language, etc. (This shouldn't have to be done if the content that was written is actually good.)
  • The domain may have a special configuration of visibility to search engines. (This actually shouldn't be a hard requirement. Is it really harmful if Google indexes it? Probably not.)
  • The domain may have a different URL structure from a usual project. For example, languagecode.incubator.wikipedia.org. However, this must not disturb the services, 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.

This proposal has been supported by several relevant people and groups:

Event Timeline

Amire80 updated the task description. (Show Details)Jul 23 2019, 1:43 PM
Amire80 updated the task description. (Show Details)Jul 23 2019, 1:49 PM
Ebe123 added a subscriber: Ebe123.Jul 23 2019, 6:05 PM

Hmm. This is essentially "skip the creation of incubator wikis and instead just start them immediately", with some policy changes about what would be considered "a wiki". There's no real technical blocker at all, AFAICS.

Creating foo.incubator.wikimedia.org wikis and then moving them, however, would create some exceptional technical issues (renaming wikis is essentially impossible to do without breaking things) and add burdens to all read requests on all other wikis (any new fourth-level domain, and particularly any domain under wikimedia.org, bloats the CORS/etc. headers).

Hmm. This is essentially "skip the creation of incubator wikis and instead just start them immediately", with some policy changes about what would be considered "a wiki".

Something like that, yes. Of course, I recommend allowing this only for eligible languages, and I'm not suggesting any changes in the requisites for eligibility.

I'm just trying to prevent a situation in which some well-meaning people will get a domain created, then find that maintaining it requires more work than they thought it does, and abandon it. This already happened with dozens of languages, and there should be a policy for easier deletion or downgrading. The downgrading can even be only on the level of policy, for example "no local admins".

As far as I'm concerned, there should be as few differences between an "incubator" and a usual wiki as possible, except the possibility of speedier deletion or archival. In theory, this is also a matter of policy, but deletion happens so rarely now that the technical preparedness for this could possibly be improved. (There were very few deletions in the whole history of the WMF: I can only recall Tokipona, Klingon, Siberian, and Moldovan, and there are a few locked wikis, such as Afar and Yi.)

There's no real technical blocker at all, AFAICS.

In theory—yes, because that's how wikis are already created now. In practice, however, it sometimes takes many weeks to create a wiki, and there are issues even after creation: no Wikidata, broken search, etc. And this brings us back to T158730.

Creating foo.incubator.wikimedia.org wikis and then moving them, however, would create some exceptional technical issues (renaming wikis is essentially impossible to do without breaking things) and add burdens to all read requests on all other wikis (any new fourth-level domain, and particularly any domain under wikimedia.org, bloats the CORS/etc. headers).

No problem. The domain name doesn't have to be different, as I noted in the task description.

jijiki added a subscriber: jijiki.Aug 8 2019, 3:20 PM

Suggest the domain be languagecode.wpincubator.org so its clear its not a full functioning wikipedia it would also force the focus to be on one project rather than spread effort to multiple projects

Make it so that IP's cant edit no exception, again as a space to deliver viable projects to create a new language it already necessitates that there is the interest and support.

Incubator can be a site option with language code on WikiData making easy for a bot to run the change to the project when it happens... or remain if the alternative is to archive the site and prevent editing