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:
- Wikipedia for Indigenous Communities (slides)
- Wikipedia for Indigenous Communities (video) (the whole video is recommended, but the biggest difficulties with using the Incubator are described after minute 26)
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:
- Many comments at https://incubator.wikimedia.org/wiki/Incubator:Reform_discussions and pages linked from it, but no objections in principle. The main issue is a requirement for convenient vandalism monitoring.
- No significant objections at https://meta.wikimedia.org/wiki/Talk:Small_Wiki_Monitoring_Team/Archive_3#Incubator_reform