Help talk:I18n

From ArchWiki
Revision as of 19:41, 15 June 2012 by Kynikos (talk | contribs) ("Dummy" interlanguage links and deprecation of Template:i18n: clarify)
Jump to navigation Jump to search
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 #"Dummy" interlanguage links and deprecation of Template:i18n and #Language namespace(s) in place of suffixes? for more recent discussions. -- Kynikos (talk) 16:06, 3 June 2012 (UTC)

Officializing ArchWiki Translation Teams?

The Italian and Spanish translation teams have just decided to standardize the titles of their project pages: ArchWiki Translation Team (Italiano) and ArchWiki Translation Team (Español). Is it possible to link those pages here thus somewhat officializing the translation projects, maybe involving other languages too in the future? This could also help finding other people interested in joining the teams. -- Kynikos 09:24, 25 April 2011 (EDT)

I support your idea. I've been meaning to write a translation guidelines section (recording the translation date on an article's talk page, something about avoiding starting translations unless planning to complete it, etc.) This is also where I'd like mention the translation projects. I'd appreciate your input. -- pointone 15:04, 29 April 2011 (EDT)
Uhm I really don't want to dishearten you about this, but I think that translation-specific guidelines should be left to each language translation team: for example the Italian community uses tables to sum up translation dates, maintainers, notes and so on, and I don't think that writing to avoid starting translations unless planning to complete them would really change users' behaviour... It's already hard to make people follow generic style guidelines, which, by the way, should really be written down as we were discussing a bit of time ago. I want to make me understood: a style guideline would not make sure that everybody respects it at all, but it would allow administrators and occasional correctors (like I am sometimes) to have a definite reference for making corrections to edits and articles in general. You could start a Style Guide page, and then users could add new rules over time (under your supervision), so you wouldn't have to do all the job. I also remind you that there was that discussion on the possibility of restyling the templates.
Anyway, about this discussion, you could add a "Translation Team" field in the table at the bottom, with a link to the relative translation team for each language which has one. Then you could add a subsection to Guidelines similar to this:
Translation teams
Some languages have started collaboration projects (see table below) to efficiently organize the translation of the articles. Please consider joining your language's Translation Team or at least informing it when you are starting translating an article.
(I know, I'm not very inspired tonight ihih) If I'll happen to think of other (maybe better) ways of highlighting the translation projects I'll suggest them here ;) -- Kynikos 19:28, 29 April 2011 (EDT)
IMHO the non-English wikis should be separate from the main one, as it is with French, German and Polish. You have your own forum already. -- Karol 05:03, 30 April 2011 (EDT)
That would be the ideal situation. Anyway at least the Italian translation project (I don't know about the other languages) is completely independent from, where as far as I know it was asked some time ago to implement a wiki, but for some reason it came to nothing. -- Kynikos 05:55, 30 April 2011 (EDT)

Related: ArchWiki Translation Day. Mention external wikis and Translation Teams there. -- Kynikos 05:25, 31 January 2012 (EST)


About Article Title

ID+title in l18n+(l18n in english) would be better than the present.

1、the ID is the same with the id of the english original article

2、title in locale language would be convenient and friendly for the people who is not familiar for english.

3、l18n in english will help the admin to learn which article hasn't been translated.

so, with the help of the new subject style , the admin would learn the translated subject of article and the locals would get the native subject for convinient, perfect!

The current i18n situation is not ideal, but this proposal seems needlessly complex. Please find our ongoing internationalization discussion at International Wikis (2010 edition). -- pointone 11:54, 24 February 2011 (EST)
The same / similar idea was presented here. -- Karol 18:17, 25 August 2011 (EDT)


Clarification needed: there are currently articles tagged with Srpski (Serbian Latin) and others with Српски (Serbian Cyrillic). Are there objections to tagging Srpski articles with Српски instead? (For example: Main Page (Srpski) to Main Page (Српски)) Would this be confusing?

It is my understanding that most Serbians are literate in both scripts, and Cyrillic is considered the "official" script.

-- pointone 16:11, 17 January 2010 (EST)

Localized templates, categories and special pages?

As Archlinux Turkiye team we will begin translations on wiki soon. It is very hard to organize Turkish pages with currenti i18n policy. Non-english speakers are always confused and told us that they lost themselves while trying to reach knowledge here. Currently we decided to use official wiki instead of create a localized wiki on our server. Lack of manpower :). We need to ease things in current i18n policy but need advice and help. So;

  • Should we create localized templates? Instead of "Warning (Türkçe)" ==> "Uyarı" for example? -- tarakbumba 10:03, 28 March 2012 (EDT)
Localized template names should only be redirects to the standard title, so in your example "Uyarı" should be a simple redirect to "Warning (Türkçe)" -- Kynikos 06:16, 29 March 2012 (EDT)
  • Should we create localized categories? If we can, it will help Turkish users to find what they seek to. We can group certain translated articles into their respective localized categories. -- tarakbumba 10:03, 28 March 2012 (EDT)
I understand the need for localized categories, but currently they're not allowed, although I'm perfectly aware that there are many. You've already noticed that internationalization is still quite messy, please stick to the current rules in any case until they change if they ever do, otherwise we're messing things up even more :) You must understand that the MediaWiki engine is not made for hosting multilanguage projects, even Wikipedia uses different databases for the various languages, so there's always the need for workarounds for handling translations: here we're currently using the "language suffix" method, which means that all pages should be named with the English title followed by the proper language suffix, and then they should use Template:i18n for enabling navigation between translations. This must be done for ease of maintenance, because the Turkish team is not the only one lacking manpower... :D Other i18n methods have been discussed in the past and also the present, just see the note at the top of this very page, and I'm also aware of the forum thread you started, but these changes require lots of time and efforts, and we're currently unable to manage them. -- Kynikos 06:16, 29 March 2012 (EDT)
  • Should we create localized Special pages? As this wiki talk mentioned some templates automatically add articles to special pages. We need to gather i.e. articles those marked to be translated into Turkish and will use localized translateme template to achive this. Is that right way to do this? -- tarakbumba 10:03, 28 March 2012 (EDT)
Yes, I warmly suggest you to use ArchWiki Translation Team (Türkçe) for organizing translations, you can also take example from what other languages are already doing. -- Kynikos 06:16, 29 March 2012 (EDT)

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)

"Dummy" interlanguage links and deprecation of Template:i18n

With this discussion I'd like to propose the implementation of "dummy" interlanguage links also for the languages hosted in as initially proposed (as far as I know) by User:pointone in FS#17580. Such a system would replace Template:i18n.

I've revived this idea because with the latest developments to my bot (Wiki Monkey) I can now handle the transition with relative ease, see also #Bot algorithm below.

Using interlanguage links instead of Template:i18n would give several advantages:

Since version 1.11.0, Wiki Monkey should allow users to synchronize the interlanguage links of an article with the others of its "ring", although of course this feature hasn't yet been tested on large scale and will probably need to be fine tuned.

Anybody interested? :)

-- Kynikos (talk) 11:57, 1 June 2012 (UTC)

I fully support this idea. I would like to suggest at this point, since we are already considering a massive restructuring project and have a dedicated technical maintainer (thanks, Kynikos!) that we also migrate to the "namespace" solution at the same time. How much harder would this be to implement? -- pointone (talk) 14:34, 2 June 2012 (UTC)
Thank you for your support! About the namespace solution, it would be a lot harder to implement it at the same time of the dummy links thing, so let's discuss it in #Language namespace(s) in place of suffixes, also because it's not so straightforward and there are some aspects that should be evaluated carefully.
I'd like to read here possible opposing arguments to the dummy links idea, and instead, I'd like people in favour to answer #Dummy links format, #Interlanguage links sort order and possibly help with #Bot algorithm.
-- Kynikos (talk) 17:32, 2 June 2012 (UTC)
One problem I foresee is related to migration of a language to an external wiki. Once we are using dummy interlanguage links, it becomes more difficult to migrate content to an external wiki because there is no simple way to have both internal interlanguage links and external interwiki links for that language at the same time. Once the migration is complete, we would update the interwiki table to point to the external site, but during the migration (which has lasted months, in some cases) we would need a temporary solution. -- pointone (talk) 14:06, 3 June 2012 (UTC)
Good point, a possible solution I can think of is to create temporary interwiki links (e.g. ko-temp:Article) so that regular interlanguage links (e.g. ko:Article) still point to the local articles (e.g. Article (한국어)), which can in turn redirect to the respective external articles, if existing, through the temporary interwiki links. Ugly, but I guess working. -- Kynikos (talk) 16:06, 3 June 2012 (UTC)
Note that this solution would require updating the Names.php file in order to recognize the prefix as a language link rather than a random interwiki link. -- pointone (talk) 16:51, 3 June 2012 (UTC)
I'm not sure I get it, I can make redirects work even with regular interwiki links (e.g. #REDIRECT [[wikipedia:Main Page]]), at least in edit previews ^^ Unless I didn't explain well my idea, which, I remark, is not aimed at making temporary interlanguage links, only redirects.
A possible question could be instead if we should apply this method also for the few existing French, Finnish and Swedish articles (my position is "no").
-- Kynikos (talk) 17:30, 3 June 2012 (UTC)
Of course, I misunderstood your idea. Ignore me! With regards to existing languages in transition I think we should be working harder to contact members of their respective communities to put together a coordinated effort to finish-off the migrations! (So, I agree -- "no.") -- pointone (talk) 16:28, 9 June 2012 (UTC)
Ok, the plugin for the bot is practically ready: this discussion hasn't received objections, asking for feedback on the English forum wouldn't make sense, and opening threads in non-English forums would require too much effort, so I'm considering this plan admin-approved.
I'll announce the change in ArchWiki:News once I'm ready to start.
-- Kynikos (talk) 11:45, 10 June 2012 (UTC)
I think the transition is complete, except for the fact that I will delete the instances of Template:Temporary i18n progressively over the next days.
Please report any bugs that may have arisen. A known bug is that the removal of Template:i18n and repositioning of existing interlanguage links has revealed a gap at the top of some articles that had the elements in the header misplaced: removing the responsible empty line fixes the problem, in fact there should be no empty line before the first line of content.
-- Kynikos (talk) 19:36, 15 June 2012 (UTC)

Dummy links format

If the "dummy" links idea is approved, there are two ways they can work:

  1. Links add the language suffix implicitly (so for example the interlinks in Xfce would be bg:Xfce, cs:Xfce...)
    • this way is neater, but if one day we want to implement the "namespace" method for managing local translations instead of the current "suffix" method, Templates and Categories won't be able to use interlanguage links, and will probably need special i18n templates
  2. Links must be added with the language suffix (so for example the interlinks in Xfce would be bg:Xfce (Български), cs:Xfce (Česky)...)

Thoughts? -- Kynikos (talk) 11:57, 1 June 2012 (UTC)

I like the first idea. Links or title with foregin characters are much harder to maintain. I can not read them or edit them or even see them if the fonts are missing. Even as a Chinese user, open chinese pages is takes more time when searching because I have to swith between input method. To ease this task, I always search and open English page first and then click on i18n link. zh_CN:Xfce is easier to type and already contain all language info. -- Fengchao (talk) 07:21, 2 June 2012 (UTC)
Adding the language suffix automatically makes more sense to me. With regards to templates and categories, this is only a problem if we have a single "local" namespace, right? If every language has its own namespace, I don't see why this would cause problems. -- pointone (talk) 14:06, 3 June 2012 (UTC)
No, solution 1) prevents interlanguage links to templates and categories in every case: if each language has its namespace and we want to make it implicit in interlinks, these will have to be designed like$1, thus making it impossible to link to templates and categories :) -- Kynikos (talk) 16:06, 3 June 2012 (UTC)
An alternative to special i18n templates for Categories and Templates, in case of solution 1) with language namespaces, would be to create a redirect for each category and template: for example Lang:it/Category:Laptops redirects to Category:it/Laptops and this would make it possible to use an interlanguage link like it:Category:Laptops from e.g. Category:Laptops. -- Kynikos (talk) 15:16, 9 June 2012 (UTC)
Well, solution 2 is indeed flexible, but doesn't make much sense, and solution 1 has workarounds for templates and categories, so (1) is approved. -- Kynikos (talk) 11:45, 10 June 2012 (UTC)
Also note that solution 2 would make the possible transition to language namespaces much more difficult, in fact when renaming an article, all its interlanguage backlinks should be updated, and that's not as easy and safe as updating normal backlinks. -- Kynikos (talk) 12:54, 10 June 2012 (UTC)

Link sort order

For what I've seen around, the sorting order of interlanguage links is a common problem in many wikis: what will be our standard? I think there are 2 main choices:

  1. Sorting alphabetically based on the local language name (e.g. fr:Article comes before fi:Article)
  2. Sorting alphabetically based on the language tag (e.g. fi:Article comes before fr:Article)

I vote for 1). -- Kynikos (talk) 17:32, 2 June 2012 (UTC)

I vote for (2) -- sorting alphabetically based on the language tag -- in the name of simplicity! For those not using a bot, it is much simpler to look at the first letter overall than the individual article language names. Also, we eliminate the problem associated with sorting non-Latin characters. -- pointone (talk) 14:10, 3 June 2012 (UTC)
Ok, method 2 is approved: the sort order will have to be documented in Help:i18n, Help:Style... -- Kynikos (talk) 11:45, 10 June 2012 (UTC)

Bot algorithm

If the "dummy" links idea is approved, this is the bot algorithm that will be used for automating the transition: please help make it as smart as possible (no signatures required for edits to this section).


The bot will be run on lists of articles (e.g. categories) and it will process every article one by one.

  • For every article in the list:
    • If the article is not detected as English go to the next article in the list
    • If it's detected as an English article:
      • A) Collect the titles of all the existing articles that have the same English title for the other languages (avoid the languages that have local articles but also their own wiki, like French, Finnish and Swedish)
        • For each of these titles (including the English one):
          • If it's a redirect, follow the redirect and recurse at A)
          • If it has an i18n template and the title in the i18n template doesn't correspond to the one of the article (except for the language suffix), use that title to recurse at A)
          • If the title has the Temporary template (see below) raise an error and request manual intervention
          • If a conflict is found (a title for a language that already had another title in the collection) raise an error and request manual intervention
    • Once the collection is ready, create the string with the actual interlanguage links and add it to every article in the collection, either at the index of already existing interlanguage links, or in place of Template:i18n or by default at the top of the article; also add a temporary template to inform users of the change in i18n method

Once the bot reaches the end of the list:

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 either.

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 templates.
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)
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)