Help talk:I18n

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)

MediaWiki translation extension

Speaking of multi language support for MediaWiki. It does have an extension to support translation. See: 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)

Language namespace(s) in place of suffixes?

This discussion is about the possibility of replacing the current system of classification of the articles by language, using suffixes in the title, with a namespace-based system. This issue has currently a lower priority than #"Dummy" interlanguage links and deprecation of Template:i18n.

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).
  • Examples:
Dansk:Some Article, Dansk talk:Some Article, Magyar:Some Article, ...
Danish:Some Article, Danish talk:Some Article, Hungarian:Some Article, ...

2) There's one big namespace for non-English languages

  • There are various possible choices for the name of the namespace: "Lang", "Local", "i18n", ???...
  • The language can be separated from the title with a colon, a slash or some other punctuation mark
  • We could use language tags or full language names
  • Language names could still be suffixes or be part of the prefix
  • This solution just adds 1 namespace and its associated talk
  • Examples:
Lang:pl/Some Article, Lang talk:pl/Some Article, Lang:zh-CN/Some Article, ...
Local:Some Article (Polski), Local talk:Some Article (Polski), Local:Some Article (简体中文), ...

3) Some languages can have a proper namespace according to some objective rules based on the number of translations

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 think this can be enough for now, as you can see it's quite intricate, I don't even have a clear idea about what's my preference at the moment, let's see if somebody can help sort out the ideas.

-- Kynikos (talk) 20:48, 2 June 2012 (UTC)

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.
I'd use Template:pt/Lorem Ipsum and Category:pt/Lorem Ipsum, but Lang:pt/Help:Lorem Ipsum and Lang:pt/ArchWiki:Lorem Ipsum for special namespaces.
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).
-- Kynikos (talk) 16:16, 3 June 2012 (UTC)
Note that the format Lang:es/Title wouldn't be possible, only Lang:Es/Title or Lang:ES/Title would. -- Kynikos (talk) 14:42, 23 September 2012 (UTC)
Alternative formats (better isolate the title from the prefix, for readability when displayed in the h1 at the top of the page, especially with short titles): Lang:UK / KDE, Lang:UK KDE, Lang:UK - KDE, Lang:UK ~ KDE, Lang:(uk) KDE (parentheses should allow lowercase tags, note that square brackets would require html entities to be used in links), Lang:Українська KDE, Lang:Українська - KDE... -- Kynikos (talk) 16:11, 27 September 2012 (UTC)
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)
-- Kynikos (talk) 04:08, 16 January 2013 (UTC)
Moving here the considerations about interlanguage links and Templates/Categories (interlanguage links cannot be used directly with Templates and Categories if language namespaces are implemented):
-- Kynikos (talk) 19:36, 15 June 2012 (UTC)
More random notes:
  • {{Lowercase title}} shouldn't be converted to {{DISPLAYTITLE:...}} if the language tags are at the start of the title (right after the namespace), in fact the real title could be directly converted to the correct case.
  • A Template:Local title or similar could be created and put on every translation to prettify the localized titles through mw:Help:Magic words#Page names (would require setting $wgRestrictDisplayTitle to false).
    • For example if the titles were of the form Lang:Zh-CN/Local title/Subpage the template could be {{DISPLAYTITLE:{{lcfirst:{{PAGENAME}}}}}} to display "zh-CN/Local title/Subpage".
    • If we wanted to keep the current format, the titles could be of the form Lang:Local title/Subpage (简体中文) or Lang:Local title (简体中文)/Subpage (see also Help talk:Style#Localized subpages), and the template could be {{DISPLAYTITLE:{{PAGENAME}}}} to display "Local title/Subpage (简体中文)" or "Local title (简体中文)/Subpage". This template would require explicitly making the first letter of the title lowercase when necessary, like in the English page.
    • Quite cool and flexible, if the titles were of the form Lang:Local title/Subpage/zh-CN we could play with the tag through {{SUBPAGENAME}} and put it wherever we want (and change it in the future); for example the template could be {{DISPLAYTITLE:{{BASEPAGENAME}} [{{SUBPAGENAME}}]}} to display "Local title/Subpage [zh-CN]", or {{DISPLAYTITLE:[{{SUBPAGENAME}}] {{BASEPAGENAME}}}} to display "[zh-CN] Local title/Subpage". This template would require explicitly making the first letter of the title lowercase when necessary, like in the English page. Also, there won't be the advantage of having the pages grouped by language in article lists.
Also note that {{DISPLAYTITLE}} properly affects the HTML page title, so that the pretty format is displayed in browser tab, window title... and web search engine results!
-- Kynikos (talk) 13:50, 5 July 2014 (UTC) (Last edit: 03:31, 27 June 2015 (UTC))

Back-end changes

This reform would require two changes to the back-end: creating the new namespace and updating the local interlanguage links. The latter is trivial, but we have to make a final decision on the new namespace name, so let's put it to vote in #Poll. Only one vote per user, you can change your vote as many times as you want before the poll is closed. You can add more options if you want. Please add comments here, not under the poll. — Kynikos (talk) 01:00, 14 March 2015 (UTC)

In the discussion above, most of the considerations about DISPLAYTITLE are false, unless $wgRestrictDisplayTitle is set to false. -- Lahwaacz (talk) 08:08, 14 March 2015 (UTC)
I'd go with the "L10n" prefix, as it makes clear that translated pages are adaptations of their respective English versions [2] and must be kept as true to the original as possible. Both "I18n" and "L10n" are also common in Arch packaging [3] [4]. If we go with L10n, we should likely rename this page as well.
That said, as we're the only ones likely to vote here, we should agree on a name instead of all voting on a different one. :P
-- Alad (talk) 11:46, 25 June 2015 (UTC)
I think what also matters is how readable localized titles would look on web engine search results, e.g. in , and this probably also depends on the language prefix/suffix format we choose to enforce. If we decide for the "NS:CODE/Title" format, probably "Lang" is indeed a better-looking solution; on the other hand, if we kept language suffixes, e.g. "NS:Title (Language)", "Lang" wouldn't introduce the language code anymore, and it wouldn't look as good, so in that case "L10n" may be the best option. For this reason I think we should open a poll for the language format first. — Kynikos (talk) 04:03, 27 June 2015 (UTC)
Regarding #Poll (syntax), what does the "Local title" part mean? Shouldn't it be just "Title", i.e. the title of the relevant English page as it is now? -- Lahwaacz (talk) 12:57, 28 June 2015 (UTC)
Sorry, I blindly copy-pasted the examples above, I've fixed the poll. Allowing localized titles would be something that I wanted to discuss later on. — Kynikos (talk) 03:39, 29 June 2015 (UTC)

MediaWiki has a new related feature since 1.24, see "Manually changing page language" in mw:Manual:Language#Page_content_language. It is not enabled by default, but since we don't use the Translate extension, it would come in handy for us. -- Lahwaacz (talk) 13:29, 28 June 2015 (UTC)

I've just tested it in my local testing wiki, but I don't see much use for that feature honestly... Or maybe I haven't understood what it should do? (Not much according to the "What does it define?" section in mw:Manual:Language#Page_content_language) Also, the language doesn't seem to be set automatically based on the title, but it should be set with periodic bot runs (with an ad-hoc script). — Kynikos (talk) 13:46, 30 June 2015 (UTC)
I thought that it would produce better search results when using a search engine like Google, but it appears that the language is already recognized correctly. Anyway, fixing the lang attribute of the html tag manually "just because" is probably not worth the effort. -- Lahwaacz (talk) 14:23, 30 June 2015 (UTC)
I'm not surprised that Google detects the language of a page without relying on html attributes, anyway I didn't make the connection between your observation and my concerns about search engine results, sorry for the misunderstanding :)
But does the lang attribute really change? I've just checked in my local wiki and it stays "en" no matter what language I set for my test page... O_o
Kynikos (talk) 11:01, 1 July 2015 (UTC)

Poll (namespace)


  • Lahwaacz (talk) 08:14, 14 March 2015 (UTC)
  • [vote here with ~~~~]


  • [vote here with ~~~~]


  • [vote here with ~~~~]


  • [vote here with ~~~~]


  • [vote here with ~~~~]


  • [vote here with ~~~~]

Poll (syntax)



  • Fengchao (talk) 12:45, 28 June 2015 (UTC)
  • [vote here with ~~~~]

L10n:Title/Subpage (Español)

L10n:Title/Subpage (简体中文)

  • [vote here with ~~~~]



[+ set $wgRestrictDisplayTitle to false and prettify with DISPLAYTITLE]

  • [vote here with ~~~~]

Moving Japanese pages to new external wiki

I made new Japanese community website ([5]) and its wiki ([6]). Migraiton of wiki pages has been already completed, so everything should work. Please change "ja" interlanguage link to point to$1, and I'm going to fix ja links of each page whose title was translated into Japanese in new wiki. For original Japanese pages, I'd like to put #redirect[[ja:<page title>]] in their contents rather than to delete them completely, because if these pages are linked by external websites they'll dead. Although, if that leaving redirects should be a nuisance, I will agree to remove all.

Japanese website's url is provisional, I want to move to the appropriate address ( but the domain currently acquired by someone. She or he seems to be satisfied with just getting this domain before starting to make the contents, therefore I instead started to. I'll wait until the domain be expired and acquirable or the present holder contact me (He/She might notice due to interlanguage links changing). When I find neither come (at the date of next expiration), I think to get and use other domain looking good (but `` is the best I guess). -- Kusakata (talk) 07:56, 19 February 2015 (UTC)

Hi! That's great! Your contributions in Japanese wiki are very impressive :D.
I think is also very appropriate, and it seems it's free now. Maybe you would try to obtain it now? Current owner of may don't want to share with your intentions and anyway it will expire only at summer.. =\ — blackx (talk|contribs) 09:39, 19 February 2015 (UTC)
Thank you for your suggestion, but "" domains can be obtained only by the judicial person authorized by the government (source). It takes a lot of time and money to obtain approval from a government office. Using ".jp" second-level-domains like "" is not easy. -- Kusakata (talk) 10:57, 19 February 2015 (UTC)
Great job Kusakata! In order to update the interwiki links we need to patch the database directly, so it's not an immediate thing because we have to go through a Developer, but of course I'll take care of this on high priority, considering the huge effort you've put into this :)
About the interwiki redirects, they've always been forbidden by Help:Style#Redirect pages, but I also understand the need not to break existing external links: perhaps we could keep the redirects for a while, then start progressively deleting them making sure to add the link to the .jp page in the deletion message.
Finally, can I ask you what method you've used to export/import all the Japanese articles? For example have you used the API with a bot, or Special:Export/Special:Import, or manually copy/pasted the content, or...
Kynikos (talk) 14:34, 20 February 2015 (UTC)
I'm happy you said so. Your solution about the redirects sounds reasonable to me. To answer your question, I've used the second method, roughly speaking. I had all Japanese pages exported, and I made necessary changes to their titles and categories (if appropriate, I translated them into Japanese), internal links (stripping (日本語) from [[some page (日本語)]]) with exported .xml files. After that, these .xml files were imported into new Japanese wiki. To reduce processing load, I divided into several times (category by category). However, some pages I initially set about were manually copied. -- Kusakata (talk) 03:24, 21 February 2015 (UTC)
Update: patch sent to Pierre by email.
Thanks for explaining, we've never tried a large-sized migration with the export/import tools, and it's good to see that it can work. Have you exported only the last revisions or the whole histories of the pages?
Kynikos (talk) 15:24, 24 February 2015 (UTC)
Very glad, very thankful. To include all histories of pages is undoubtedly better, thus I tried to. Although exporting went fine, importing went wrong. Somehow it's too severe for my server. I was able to export/import a page with its history, but I couldn't do several pages at once. Finally, I've exported only the last revisions. -- Kusakata (talk) 17:42, 24 February 2015 (UTC)
Special:Import is affected by PHP's limit on maximum file size for uploads, see e.g. [7]. Other import methods are described here, depending on how much control you have over the server there may be better solutions than Special:Import. -- Lahwaacz (talk) 17:51, 24 February 2015 (UTC)
I see. It appears that PHP's timeout rather than uploading limit is a problem. Despite how many revisions are included within pages, the more pages I attempt to import at a time, the longer time it takes. Other methods might helpful but I shall not do it now. Actually, the whole histories of cardinal pages were imported. -- Kusakata (talk) 08:07, 25 February 2015 (UTC)
Japanese links changed! I'm fixing/adding missing ja links, but I cannot edit the protected pages. Please edit following pages, instead of me:
Thank you. -- Kusakata (talk) 13:10, 28 February 2015 (UTC)
All done.
Let's keep this open until the interlanguage redirects will have been deleted according to Help:Style: they can be found with Help:I18n#Finding_articles_with_specific_interlanguage_links.
...or we can change the style rule and allow interlanguage (but not generic interwiki) redirects, what do the other admins think? Interwiki redirects were banned because it was deemed confusing to be thrown to another website, also in general without editing rights, after clicking on an internal link. Do we want to make an exception for interlanguage redirects? I'm a bit undecided at the moment...
Kynikos (talk) 04:33, 1 March 2015 (UTC)
Japanese templates (and perhaps also categories?) can be deleted right away. Redirects for content pages and their talk pages can stay as long as necessary, I wouldn't mind if that's forever. As for the exception from the rule, interlanguage redirects should stay under control. The state could be checked once in a while with a script (not written yet, should be simple). How about "Interlanguage redirects can be set up only with consent of the Maintenance Team"? -- Lahwaacz (talk) 20:45, 1 March 2015 (UTC)
+1 for everything (templates/categories, exception and script), I've updated Help:Style and Help:i18n accordingly. — Kynikos (talk) 03:02, 2 March 2015 (UTC)
I've just finished deleting all the categories. — Kynikos (talk) 02:32, 5 April 2015 (UTC)
The day before yesterday, domain should have expired. However, the holder of this domain has extended the term and seems not to dispose of it. I can't wait any longer. As planned, I've got another domain: Now the access to "" is redirected to "". And, I also changed our MediaWiki's URL structure to the same as "", which means$1 became$1. Please update Japanese interlanguage links again, and no further changes about Japanese website's addresses might come. -- Kusakata (talk) 16:29, 2 July 2015 (UTC)
Thank you Kusakata, I've opened a pull request for that[8]. — Kynikos (talk) 14:02, 3 July 2015 (UTC)
I confirmed interlanguage ja links updated. Thank you. -- Kusakata (talk) 17:46, 30 August 2015 (UTC)

Move/Merge articles to external wikis

[Moved from ArchWiki:Requests#Move/Merge articles to external wikisKynikos (talk) 13:08, 20 March 2015 (UTC)]

Although Finnish and Serbian have their own wikis, we're still hosting some articles in those languages:

Some users of those wikis should probably be contacted in order to complete the move/merge, replacing those articles with interlanguage links at least on the respective English pages.

-- Kynikos (talk) 16:34, 10 May 2012 (UTC) (Last edit: 03:04, 22 September 2013 (UTC))

Many language wikis moved out and died. Lots of effort is wasted in wiki page move/import.
So I now have a strong feeling that we should host all localization pages instead of pushing them out.
--Fengchao (talk) 13:45, 13 March 2015 (UTC)
Well, confirming what I wrote in ArchWiki talk:Administrators#Cite extension (very last post, the rest is unrelated), I agree with you. If we want to start implementing Help_talk:I18n#Language_namespace.28s.29_in_place_of_suffixes.3F, we need to have the new namespace configured and pushed to the repo: I opened FS#35545 a long time ago to facilitate this, and incidentally I'm currently trying to communicate with the devs for some back-end patches, hopefully making it to have that implemented too.
Kynikos (talk) 14:46, 13 March 2015 (UTC)
Great. I like namespace :) This topic could be closed. --Fengchao (talk) 12:42, 19 March 2015 (UTC)
I'm reopening it here as a reminder until we really implement the namespace thing. — Kynikos (talk) 13:08, 20 March 2015 (UTC)

Finnish and Swedish wikis

The Finnish and Swedish external wikis seem to be down for quite some time. -- Lahwaacz (talk) 12:52, 19 July 2015 (UTC)

Both still down. Would be good to remove them from quick links.
I clicked main page for all languages. The Iranian 404s, but resolves with a different link. Others are ok.
--Indigo (talk) 19:30, 28 December 2016 (UTC)

Turkish wiki unaccessible

When visiting [9] and [10], I get the following error:

MediaWiki does not function when magic quotes are enabled. Please see the PHP Manual for help on how to disable magic quotes.

-- Alad (talk) 08:03, 20 September 2015 (UTC)

That appears to be resolved. Closing. --Indigo (talk) 19:34, 28 December 2016 (UTC)

Status update

I am sorry if this is not related here. I would like to know that has any conclusion been made about changing the back-end of all I18n articles? More importantly, is translation work still encouraged here in ArchWiki? --NonerKao (talk) 13:16, 21 October 2015 (UTC)

  1. No, for the moment there's no change to internationalization rules, however any change would probably be carried out with bots, so you can keep translating normally. This also means that you're still in time to express your opinion, if you have something to add.
  2. Yes, translation work is fully supported: in the past the policy was to encourage the establishment of external wikis for non-English articles, but more recently this view seems to have changed, and for example I tend to support local translations because translators tend to bring additional improvements to English articles too, although an official stand on this issue has never been made. Note however that local translations have the disadvantage that many parts of the wiki interface aren't affected by the language preferences set by each user, so they will always be displayed in English.
Kynikos (talk) 04:05, 22 October 2015 (UTC)
OK, let me share some rough thoughts here. As a tranditional Chinese(TC below) user, actually I feel that current I18n policy is quite good and acceptable, because some of the TC users has made some conventions and newcomers like me can easily follow them. I can maintaining, translating as many pages as I want.
However I also acknowledge that it might be a totally different story for administrators for management purpose. So, I am kind of neutral about future changes on this issue. Everything is fine now, but if the current state really bothers managers, matainers and normal archers, then I would vote for change as well.
Maybe the long silence of this discussion indicates that this issue does not, in fact, bother many people. NonerKao (talk) 04:43, 22 October 2015 (UTC)

Chinese interlanguage links

[11] asked to replace the interlanguage names for the two Chinese variants that we're hosting. The language names are hardcoded in Names.php and tied to the language code. Currently we're using zh-cn and zh-tw. The generic codes for Simplified and Traditional Chinese should be zh-hans and zh-hant. This would be a huge change, which would at least require to:

  • Change the language suffix tag to all the Chinese articles;
  • Change all the interlanguage links in all non-Chinese articles from zh-cn/zh-tw to zh-hans/zh-hant;
  • Update the interwiki map from Special:Interwiki.

I think also the Chinese community should advise whether this would be worth the effort.

Kynikos (talk) 10:53, 30 November 2016 (UTC)

I vote for the change but work loading could be reduced greatly by skipping step 1.
There is no need to change zh-cn suffix, 简体中文 is actually zh-hans.
For zh-hant, the twainess want to call them 正體中文 instead of 繁体中文 here in China mainland. While I personally do not agree with this, there is no harm to keep current 正體中文.
So work needed is:
  • Add zh-hans/zh-hant into Special:Interwiki. zh-hans URL should be the same as zh-cn and zh-hants url should be the same as zh-tw.
  • Change all the interlanguage links in all non-Chinese articles from zh-cn/zh-tw to zh-hans/zh-hant; This could be done by a bot.
  • Remove zh-cn and zh-tw in Special:Interwiki.
--Fengchao (talk) 23:46, 25 December 2016 (UTC)
I don't see how we could easily skip step 1. Note that the binding between the article titles and language tags is determined by the Special:Interwiki table (which can be easily modified), but the language names that appear in the left column are determined by Names.php, as pointed out by Kynikos. I think it's in our best interest to keep these two mappings equivalent by giving up to MediaWiki and using their names even in the article titles. -- Lahwaacz (talk) 09:28, 26 December 2016 (UTC)
See below table of current setting, the Names in left column is actually different with the suffix in URL.
Interlanguage link Names in left column URL in Special:Interwiki The suffix in URL
zh-cn 中文(中国大陆)$1_(%E7%AE%80%E4%BD%93%E4%B8%AD%E6%96%87) _(简体中文)
zh-tw 中文(台灣)$1_(%E6%AD%A3%E9%AB%94%E4%B8%AD%E6%96%87) _(正體中文)
What need to be changed is the Names in left column. No need to change the suffix in URLs. New settings should be :
Interlanguage link Names in left column URL in Special:Interwiki The suffix in URL
Changed Auto changed throughNames.php No change No change
zh-hans 中文(简体)$1_(%E7%AE%80%E4%BD%93%E4%B8%AD%E6%96%87) _(简体中文)
zh-hant 中文(繁體)$1_(%E6%AD%A3%E9%AB%94%E4%B8%AD%E6%96%87) _(正體中文)
繁體 is the same 正體 by language standard, they are just different words used between Chinese mainland and Tawin. We could use above setting to keep the change small.
--Fengchao (talk) 05:28, 27 December 2016 (UTC)
Hmm, that's an interesting point - I always assumed that these names were the same for all languages, but since they're not... -- Lahwaacz (talk) 08:32, 27 December 2016 (UTC)
Thank you Fengchao for the explanation, I'm in favor of the "simplified" change then. Also, it's a minor thing, but for completeness' sake I'm adding a reminder to update Help:I18n#Languages as well. — Kynikos (talk) 00:17, 28 December 2016 (UTC)
  1. Add zh-hans and zh-hant into Special:Interwiki : Done
  2. Update Help:i18n#Languages: Done
  3. Update inter language sync code in wiki monkey.
  4. Update all languages s/zh-cn/zh-hans/ and s/zh-tw/zh-hant/
  5. Remove zh-cn and zh-tw in Special:Interwiki.
I have done first two tasks. It seems task 3 and task 4 should be done at the same time. If not, zh-cn pages link will be lost after task 3 and before task 4. --Fengchao (talk) 05:31, 10 January 2017 (UTC)
I may have a working temporary plugin at [12], see Special:Contributions/ for the first successful tests, however I'll test it more thoroughly tomorrow. It's based on Help:I18n#Finding_articles_with_specific_interlanguage_links and will need to be run repeatedly because I've written it quickly and for example it doesn't try to do the "continue" queries and collect all the results at once. Also, it doesn't change both zh-tw and zh-cn links in the same pass yet, but that should be easy to add. — Kynikos (talk) 16:19, 10 January 2017 (UTC)
Ok, I think 3 and 4 are done too now, so I've also done 5, closing. — Kynikos (talk) 11:13, 11 January 2017 (UTC)
Great! Thank you. --Fengchao (talk) 07:22, 15 January 2017 (UTC)
Return to "I18n" page.