Meta-comments:
- This task is somewhat similar to T158730, but from the end-user perspective. The end-user here is a person, or a group of people, who want to create a project in a new language, most often a Wikipedia.
- If I subscribed you to this task, I believe it will interest you. If it doesn't please feel free to unsubscribe yourself, and accept my apologies.
The current process for creating a wiki in a new language is fully documented at https://meta.wikimedia.org/wiki/Language_proposal_policy , but I'll write something brief and practical here:
- Make sure you have a standard ISO 639 language code. Don't proceed if you don't.
- Add a language to translatewiki.net (technically, to UniversalLanguageSelector's langdb and translatewiki.net's LanguageSettings.php)
-- Translate the most-used MediaWiki messages. (About 500.)
- Add a language to Incubator, by creating a main page at Wp///languagecode// (and replace "Wp" with another project code if it's not Wikipedia).
-- Get a lot of people to write a lot of articles. The current threshold for approval is not precisely defined, but a rule of thumb is ~5 people working for three months, and several hundreds of articles.
- Get the Language committee to approve the project, if the above things were done.
-- The Language committee assesses the fulfillment of the above points, and asks for approval from a third-party expert who knows the language.
- If all of the above is done, create the project. Task T158730 and the page https://wikitech.wikimedia.org/wiki/Add_a_wiki describe this long and mostly-manual technical process.
**This process could be better.**
- Adding a new language to translatewiki.net usually works well, although there were several complaints of languages that took months to get added. Usually it should take just a couple of days if the ISO code is valid. Perhaps something could be improved in this process.
- Getting to the import threshold is a bit harder, however:
-- The Most-used messages list is close to to the import threshold of ~490 core messages, but doesn't correspond to it directly, because some of the most-used messages come from extensions. This may cause a situation in which a project has all the most-used messages translated and fulfills all the other Language Committee requirements, but doesn't actually have the message imported from translatewiki.net to the core MediaWiki code repository, so the project in this language will not have proper localization unless somebody verifies that the language was added to Names.php and the import worked. I usually do it for projects that are about to be created, but there's no proper procedure here, and this could be more automatic.
- 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.
-- Some disadvantages of the current Incubator:
--- Having to write prefixes on page names and on every internal link manually 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.
-- A possible solution is to make creating an actual new experimental domain easier (T158730), but with special requirements:
--- Patroling all such domains for vandalism must be at least as easy as it is for Incubator.
--- Content Translation must work, with all its features, at least for translating into the new language. This must include the set up of all the services (cxserver, Parsoid, etc.)
--- Visual Editor must work. (Already works in Incubator, but I'm making sure that it's noted explicitly.)
--- In addition to Content Translation and Visual Editor, most usual extension 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. Preferably, this should be done 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). 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.
The biggest known technical hurdle to implementing this is, again, T158730, but it's certainly not the only one.
**Thanks for reading so far.** This is a big idea. It will take a long time. This is just the initial exploration. Everybody's thoughts are welcome.