Regarding ArchWiki internationalization: There have been a number of discussions about this over the years: 2006, 2007, 2009, and 2010. In short, there are a number of potential solutions; none are perfect. Currently, the interwiki implementation is considered "best" because it provides non-English users with a fully-localized experience and isolates each language. Other "good" solutions include the creation of language-specific namespaces or migration to a different wiki which provides "better" internationalization options -- but require more effort to implement. -- pointone 16:07, 21 October 2011 (EDT)
See also #Language namespace(s) in place of suffixes? for a more recent discussion. -- Kynikos (talk) 16:06, 3 June 2012 (UTC)

Contents

MediaWiki translation extension

Speaking of multi language support for MediaWiki. It does have an extension to support translation. See: http://translatewiki.net/wiki/Main_Page. Here is forum proposal [1] and bug FS#26638. As a user of KDE userbase and techbase, I think this extension is exactly what Arch wiki need. But again, lack of man power to do it.

Exactly, time's not ripe for talking about this. Please for now let's use the suffix method as consistently as possible: if one day another method will be enforced, it will be much easier to handle at least some parts of the transition automatically with bots or other scripts. -- Kynikos 06:01, 30 March 2012 (EDT)

The main advantage would be that it would be possible to have only English articles as results when using the search engine, and, depending on the implementation of this idea, it may be possible also to select the language of the search.

Another advantage would be that in article-list pages (such as those in Special:SpecialPages) that list articles alphabetically, all the articles for a language would be grouped together.

There are many ways we can implement this solution, and each has its advantages and disadvantages; I'd like to also keep the current suffix solution in the discussion, for comparison and also because it has its advantages too.

1) Every language has its own namespace

This can be done either with local or English language names. Note that it's not possible to have namespaces named like interlanguage links! For example an article named Ru:Some Title could currently be created, but once the ru interlanguage links are activated, that article won't be accessible anymore, and it will be possible to edit/delete it only via the API using its ID (this has already happened with an article that was named with "tr:...").

This solution would create 2*N namespaces (where N is the number of languages) because every namespace must have a _talk namespace; I don't know what effect this would have on select menus and other interfaces that list the namespaces (e.g. in special pages filters).

Note that the namespace solution wouldn't be able to separate the languages completely, in fact we'd have to keep mixed Template and Category namespaces: how would we deal with those cases? Case 2) may have the simplest solution by using Template:es/Lorem Ipsum and Category:es/Lorem Ipsum or something like that, and we'd still have the advantage of having templates and categories grouped by language in alphabetical lists. About the Help and ArchWiki namespaces we could do something similar.

Note that solution 2) would break the use of Template:Lowercase title in non-English articles. The only way to solve that problem would be using an extension that can parse substrings, or force using {{DISPLAYTITLE:...}}.

The bot algorithm to implement such a change should avoid creating redirects for every title, and instead it should update all the backlinks of every article (Wiki Monkey should be able to do that, it has already done a similar thing when removing the English suffix from category names, although in this case it would be a much bigger job).

I like (2) -- a single non-English namespace. I had never even considered this option before! This will solve the biggest problem with our current implementation -- non-English articles polluting search results and other special pages -- whilst still promoting external wikis with interlanguage links as the "ideal" solution.

(We must keep in mind that, in the end, separate external wikis is the only complete solution to provide non-English readers with a fully-internationalized interface (as long as we are running MediaWiki, that is). Everything else at this point is simply a stepping-stone toward that goal.)

Creating separate namespaces for each language would quickly complicate maintenance, as you note, and add little benefit over the single-namespace solution. -- pointone (talk) 14:27, 3 June 2012 (UTC)

Yeah I too tend to prefer solution (2), especially in the form of Lang:pt/Lorem Ipsum because that would group articles by language in alphabetical lists.

The bot should be able to convert {{Lowercase title}} to {{DISPLAYTITLE:...}} in existing articles, but when a user copies an English article for translating it, he should remember to do that conversion by himself. Alternatives can be abolishing Template:Lowercase_title or using parser functions to detect the actual title (without the prefix).

Some considerations about restricting searches to a particular language:

both solutions (1) and (2) would give English-only results by default;

solution (1) would allow to select the right language namespace in the advanced search interface;

solution (2) would require to add the name of the language to the search keywords (this is how it's already working), but only if the full language names are retained in the titles (i.e. they aren't replaced by language tags like in Title (Español) -> Lang:ES/Title)

It's online now, but it seems almost empty? I archived it at [2] to be on the safe side. Nemo bis (talk) 12:51, 21 October 2013 (UTC)

Good idea archiving it! And thanks for updating this thread, probably they lost the database somehow... Anyway it's not something we can fix here, I'm closing this discussion. -- Kynikos (talk) 13:43, 22 October 2013 (UTC)

Those languages don't meet the requirements of Help:I18n#Adding local interlanguage links. Maybe not supported in the Subtag column in the table is confusing, it seems that the tag itself is not present in the registry, while support is actually lacking for interlanguage links in our wiki. Do you have an idea to clarify this thing?

Anyway, just so you know how it works, once a language meets the criteria in that section, we prepare a patch for [3] and just submit it to the bug tracker.

Sorry, I missed that - I was going through some templates and suddenly there was no subtag to add proper interlanguage link. From this point of view these languages are really unsupported, to make it clearer I'd use a superscript reference1 in the table cell and add a clarifying note below the table (note that Vietnamese is an external wiki, so the note should probably be different - another thing I missed...).

Out of curiosity, what is the minimum number of translated articles? There are some languages with a subtag and quite few pages (Hebrew - 8 pages, Thai - 15 pages), whereas Esperanto has 5 pages, so the difference is not that high.