Talk:Wiki Translation

Translating messages in Template:Languages?

I don't feel we needed to translate the message displayed by Template:Languages and related. Because it is usually prepared for other language user. For example, If you see "まだない言語", "用意されてる言語" in Japanese version pages, can you (other language user) understand the meaning of the bar? OSM Wiki editor will understand the meaning from the format of the bar, but can a new comer understand it? The message must be in English because that can be read by any other language users. This template is for internationalisation not for localisation like Template:Map Features:highway.--Nazotoko 22:42, 28 June 2009 (UTC)

I agree actually. Although it's all very clever, we don't actually need or want this feature. The words in the links to the translations, should not themselves be translated, otherwise on an english page there will be a link saying "Japanese" which a japanese person won't understand! We should just always display these words translated into the relevant language. Simple and effective. -- Harry Wood 11:07, 30 June 2009 (UTC)

I had assumed that Nazotoko was talking about the "Available Languages" and "Missing Languages" (and in the UK interface example "purge cache" and "help") messages, rather than the names of the languages themselves. I agree that the languages don't need translating, but am less sure about the headings -- EdLoach 12:53, 30 June 2009 (UTC)

Ah ok I was misunderstanding. -- Harry Wood 13:34, 30 June 2009 (UTC)

Yes. Those Japanese terms are "Missing Languages" and "Available Languages", relatively. The link names should be written in native languages because the user must be familiar with it. But the bar title "Missing/Available Languages" should be written in one language which can be read by all languages users. Although I was the who made the Template:Fi:Languages/Interface from old Template:Fi:Languages, I felt it should not be used when I was editing it. I felt necessary to discuss Finnish people to stop using it. --Nazotoko 18:00, 30 June 2009 (UTC)

Alternative solution

I have developed an extension for translating wiki pages. Are you interested? – Nikerabbit 06:58, 29 June 2009 (UTC)

From a quick look, that appears to be a fairly big change to the way the wiki works. Does it clutter up the english pages with comment tags? Seems messy, and not very robust. I could be misunderstanding though. Is there a demo wiki where this is used? In general though I'd say we're not really interested in any features along those lines for this wiki, because it's overkill. -- Harry Wood 11:11, 29 June 2009 (UTC)

The markers are there for reason. Each paragraph is tracked individually for changes. This way we know if translations are up-to-date or not. The other reason is smaller blocks for translation. I would not call it overkill, just something that is already done to keep things from going to unmaintainable mess. It is used on few pages at translatewiki.net, and I am in the process of setting up test wiki if anyone wants to play around with it. I admit that the extension does not suit all cases, but I think it could be useful here at OSM wiki, for controlled page translation.– Nikerabbit 11:41, 29 June 2009 (UTC)

To complete the need: I am voting to use this nice extension (more informations about installation and features : here). You can get a sample which implements this extension with the great and fumous KDE project and its web sites for users (userbase.kde.org) and for developers (techbase.kde.org). I'm registered to translate from english to french. And I believe it's the good solution to keep tranlations updated from wiki pages. I browse to the wiki in my language and it is very difficult to get the good informations... This is the solution to have a better coherence beetween the different languages. Else do not hesitate to contact me too! (So thanks Nikerabbit) -- JulienM 16:02, 1 September 2011 (BST)

Declare content language for e.g. search engines

The only place where we currently declare a language automatically is the "html"-tag of the generated pages, which always sets a lang="en" declaration. This might cause search engines not to perform language specific operations on page content for translated pages. I have now created Template:Ar that wraps the text that follows it in a div with lang="ar" and used it on Ar:MainPage, but I'm not convinced this is the best way to do this. Any better ideas around? --Lyx 09:46, 19 December 2009 (UTC)

Requests for translation

Is there a page or category for the placement of pages which have been requested to be translated? For instance, see Altitude. --Ceyockey 09:54, 29 March 2010 (UTC)

Is there a way to see pages that are using the template Template:Languages and are missing pt-br, for example? vgeorge 21:32, 19 April 2010 (UTC)

Well this seems to have been sorted now into the various sub-categories of Category:Translation. Does that give you what you need? -- Harry Wood 19:16, 4 October 2010 (BST)

Pages which are only in a non-English language

from Ceyockey — Consider for example the page 2008.12.27 - prvo okupljanje. Should this page be moved to HR:2008.12.27 - prvo okupljanje (from Google translate, this page appears to be in Croatian) so that the main namespace is a home for English language pages only? I have not done any page moves like this so far; I came to this question while I was considering how the page may be categorized. Thanks for considering this. 01:40, 29 January 2011 (UTC)

I think a clear language separation is a good thing. So the root namespace should only contain English pages. It is ok to use redirects to native language pages. I would also move wikiproject pages... --phobie m d 17:24, 15 September 2011 (BST)

Not necessarily; but at least, all the non-English pages in the root namespace should always use a language code prefix (in lowercase !), even if those languages do not have (for now) a dedicated namespace.

Also I really don't think that translations should change the article name. There's another solution to replace the page title (that appears as the level 1 section header at the top the page, and in the title element) by a title in another language than English, without having to name the page differently than the English page that it translates, and without having to rename pages (the only requirement is to use the correct language code in the prefix).

Thanks. — Verdy_p ^(talk) 03:10, 19 February 2012 (UTC)

Language codes in lowercase

I wonder if it would be a good idea, in the page titles, to display 2-letter language codes in lowercase instead of capital. For example "fr:Wiki Translation" instead of "FR:Wiki Translation". Capital letters are more adapted to display coutries like in the ISO 3166-1 alpha-2 codes (FR is for France) ; whereas lowercase is for ISO 639-1 language codes (fr is for French). With the mediawiki software the first letter of a title is in capital by default ; so we could use a template like this one in wikipedia: title Template:Lowercase_title. For a language like Brasilian Portuguese, the code would be written pt-BR. Would this change be too invasive and source of other problems? Damouns 09:33, 13 September 2011 (BST)

As a related issue, namespaces such as FR: and DE: that are known to our Mediawiki installation are in capitals but ones like Da: and Uk: that don’t have enough pages for a full setup are lowercase. People are regularly confused by this when they name pages. Andrew 13:29, 13 September 2011 (BST)

Since language-prefixes with its own namespace are always uppercase we should use uppercase letters for all languages! I already changed some prefixes to uppercase to avoid further confusions. The best solution would be to add namespaces for all languages because they are case-insensitive. --phobie m d 17:16, 15 September 2011 (BST)

Please don’t move any pages without discussing things. Andrew 09:27, 16 September 2011 (BST)

Why that? It is much easier to revert controversial edits than to discuss on everything first. That is what wiki stands for. My former "to-upper-moves" did not raise any objections, so others don't care or are fine with it... --phobie m d 15:53, 16 September 2011 (BST)

It of course makes sense to use the same convention regardless whether or not a namespace exists. So with the current namespace setup, your edits make sense. But why are the namespaces fully uppercase to begin with? --Tordanik 17:24, 16 September 2011 (BST)

IMHO MediaWiki forces the first character to be upper-case. Probably the admin decided that all-upper-case is better than mixed-case. I would also prefer all lower-case name-spaces, but I think it is more important to avoid mixed-case-name-spaces. --phobie m d 19:45, 17 September 2011 (BST)

Such things like Uk: are confusing because the United Kingdom is a country and not a language. For France-relative pages we use WikiProject:France subpages, and for pages in French we use FR: prefix pages. If I understand right, everybody would agree if those prefixes were in lowercase, but the restriction is just technical? Damouns 09:27, 19 September 2011 (BST)

Uk is Ukrainian.

Pages about France and coordinating mapping in France, can be found by navigating Mapping projects -> WikiProject France yes. That information may or may not be in French, and may or may not have translations. There shouldn't be all that much information that is specific to France. Mostly the French community needs the same kind of documentation found on the rest of the wiki (with 'FR:' prefixes for French). Makes sense no? The only somewhat untidy aspect of that is that we end up with some french language pages, under WikiProject France, without the FR: prefix, and this means for example a search in the french language namespace wont include that content.

MediaWiki forces the first character to be uppercase, so yes it seems likely that in the early days of providing/sorting out wiki translations, someone decided that all-upper-case is better than mixed-case (not necessarily an admin decision. Everyone's a wiki admin! The only sysadmin intervention here involves setting up proper wiki "namespaces" for language prefixes)

I don't see all uppercase as a big problem. Isn't it just a very minor, largely cosmetic, problem? If fixing it involves moving many many pages... then it's probably not worth fixing.

-- Harry Wood 10:40, 19 September 2011 (BST)

"Uk is Ukrainian." -> oops sorry! This is why the distinction between language and country must be done with casing differences. "UK" is not "uk". And "Uk" is nothing, in my opinion. Damouns 08:07, 21 September 2011 (BST)

I found a possible solution to allow lower-case prefixes and perhaps also namespaces: $wgCapitalLinks = false; --phobie m d 10:50, 20 September 2011 (BST)

That's interesting, particularly if it also works for namespaces. I wonder, though, whether renaming an existing namespace would require moving the pages, or whether MediaWiki only cares about the numerical namespace ID anyway. --Tordanik 16:06, 20 September 2011 (BST)

Namespace renaming does not require page moves. A namespace is a separate table on the database represented by a number. Its name (i.e. "FR") is just associated to this number and not part of the pagenames in that table. A server-admin should change wgCapitalLinks to false and all namespace-prefixes to lowercase. If wgCapitalLinks works with namespaces we can work with lowercase prefixes. If not we should only use uppercase prefixes. --phobie m d 16:59, 21 September 2011 (BST)

I also approve this change.

For consistency, all language codes should be usable in lowercase. But for the transition (and avoiding breaking uncorrected links that still use the uppercase codes), you can still keep the uppercase alias for the existing namespace names (it just has to be listed after the lowercase name), because Mediawiki will treat them as synonyms (there are already synonyms each time a wiki installation is localized to another language than English as its default language, and then both the English and localized names can be used, even if the English name remains as an alias and not the canonical name).

Thanks. — Verdy_p ^(talk) 03:04, 19 February 2012 (UTC)

One note: if you change $wgCapitalLinks to false, this will apply to ALL articles, and there will be a difference between article names starting by a capital and those starting with a small letter. You don't need to perform this change (that will break many English page).

Note that ALL namespaces are already not significant in their lettercase (so you can as well write "Image:" or "image:" or "IMAGE:", or you can write "UsEr:" or "User:" or "user:"; and so you can already write "DE:" or "de:" because this is already a namespace, and not just a prefix used in the article name.

In other words: we can already write all language codes in lowercase, independantly of the fact they are used as prefixes or as namespaces.

the only exception remaining is "CS:" which is still not in a dedicated namespace, so it is still a prefix (also identical to "cS:" because $wgCapitalLinks is true), but distinct from "cs:" (which is also identical to "Cs:" because $wgCapitalLinks is true)

— Verdy_p ^(talk) 22:05, 5 March 2012 (UTC)

At least one Mediawiki site has a lowercase namespace without $wgCapitalLinks: http://www.dkosopedia.com/wiki/dKosopedia:Community_Portal --Andrew 08:39, 6 March 2012 (UTC)

Template:Languages vs. Template:Language

After an hour of debugging a different template, I finally noticed there are two almost identical templates, Template:Languages and Template:Language. I believe Template:Languages is the correct one, while Template:Language is a misplaced unmantained copy&paste. However, it is used quite a lot as well, so I want to be sure before changing anything: I propose to redirect Template:Language to Template:Languages (or delete it altogether after replacing all usages with the correct template). Any objections? --Mormegil 16:57, 19 December 2011 (UTC)

• I approve this proposal. Damouns 07:52, 21 December 2011 (UTC)

Your proposal seems sensible to me, but I guess the thing to do is ask Oroick (User talk:Oroick) why he created the copy -- Harry Wood 01:59, 22 December 2011 (UTC)

User:Verdy p redirected the template. --Mormegil 14:47, 2 January 2012 (UTC)

Note: For easing the translation of many pages through autotranslatable templates, I'd really like that a wiki administrator adds/imports the few small messages support for {{int:lang}} to work properly; currently it just generates : ⧼lang⧽

See Mediawiki talk:lang for what to do when creating the very small but missing Mediawiki:lang message and its subpages.

With that, we could support a true internationalisation like in Wikimedia Commons or Wikimedia Meta within much simpler templates, and we would simplify a lot the translation of many contents without having to maintain lots of pages for distinct translations, and without also having to give to everyone an access to the messages translation (in the Mediawiki: namespace) for everything that appears on this wiki.

Only one message in "MediaWiki:lang/*" is needed, and it just has to contain the few letters of the language code (exactly the same letters as used in the subpage name each message). All languages currently imported to support the MediaWiki interface (ans listed in the users' Preferences page), should be created.

This addition/import can be performed by a simple bot (if there's an approved bot that can write in the "Mediawiki:" namespace, i.e. that has both the Bot and Admin privileges, at least temporarily for performing this import), or by the bot that has already been used to import new MediaWiki messages (when installing or upgrading the MediaWiki software or installing a Mediawiki plugin/extension).

Thanks. — Verdy_p ^(talk) 02:59, 19 February 2012 (UTC)

Category:Translate to German

Why someone created this category "Category:Translate to German" ? Why the category is appearing in some english wiki pages and not on others ? Who cares that a page has to be translated into German when you are not German ? Why not a category "Translate to French", "Translate to Italian", "etc..." ? Can we drop this category and replace it by a simple list in a simple wiki page ? --Pieren 13:33, 7 May 2012 (BST)

Yes, adding non-English categories to the main-namespace is problematic. Better add a category into Template:DE:Translation out of sync. And add suggestions to a page like Wiki Translation/desired German translations --phobie m d 12:36, 23 July 2012 (BST)

Translate extension

Three years after #Alternative solution, the Translate extension which powers Translatewiki.net (used to translate most of OSM software) can be called the only proper way to translate content in a MediaWiki wiki. There have been many improvements to page translation since then, there is now extensive documentation and several big wikis are using it and are happy about it, see for instance KDE UserBase which along with other KDE wikis is migrating all translations to it (there's also a recording of a presentation given at Akademy 2012). Is there interest in trying it here? You can also start small with some pages and then increase its usage if you like it, and Translatewiki.net's staff is happy to help with installation, configuration, migration plans etc. --Nemo 10:13, 16 August 2012 (BST)

I think it would be the right solution to replace the templates with an extension. I have no experiences with this extension, but it got recommended by some Wikipedia editors, I know. You may ask User:Firefishy if he can install this extension, or if some additional discussion is needed. --Andi 12:01, 16 August 2012 (BST)

This sounds like a promising option for managing translations. However, the main objection from #Alternative solution (that it clutters pages' source code, which is somewhat incompatible with the idea that wiki text formatting should be unobtrusive) still appears to be valid. To me, these marker comments seem like an unnecessary burden for authors editing the original pages. Besides, do you know from experience how well this works with content in infoboxes and similar templates, which we are using extensively on some types of pages? Before deciding to use it, we would of course also need a proper migration strategy for the large amount of existing translations (moving them to the new page titles, creating redirects from the old page titles, and so on). --Tordanik 15:09, 16 August 2012 (BST)

Markers don't seem particularly obtrusive to me, especially compared to ref tags or similar stuff which is in wide use and also requires to be understood, while markers only need to be ignored and left alone: what is the concern exactly?

As for infoboxes, Category:Infobox templates is probably incomplete, but if your infoboxes are like Template:Software2Translated there's no problem, you'd only have to put all parameters' text (or the whole template) for translation or find some magic to provide the template with the correct "lang" parameter. What the extension doesn't provide is automatical transclusion in the correct language of a translated template, because templates continue to work exactly in the same way. --Nemo 15:52, 16 August 2012 (BST)

Thanks for your explanations regarding the infoboxes (the category is very incomplete indeed). Aside from not being self-explanatory, a problem with markers is that you can only leave them alone if you limit yourself to minor edits. As soon as you start to merge sections, create a new structure for the page, move content to other pages etc., this will conflict with the existing structure of the markers - and yes, that happens quite often. Most pages simply don't have such high quality and stability that it would be good to freeze their structure. Oh, and by the way: I would say that ref tags are also pretty obtrusive, but we (almost) never use them in the OSM wiki. --Tordanik 18:00, 16 August 2012 (BST)

Indeed, as I wrote below, page translation shouldn't be used for pages which are likely to be heavily refactored as you say. However, if that happens, the user should still ignore the tags and it would be a translation administrator's duty to remove them all (if it's not been done yet), "recycle" the markers which can be recycled and mark the page for translation again. The simple user which rightly ignores how to manage the page translation edge-cases won't be able to mess things up and doesn't need to worry.

As for the markers, again, I think we have also to consider that they're way less obtrusive and user-unfriendly than for instance the current super-confusing system of translation templates (I know how they are, I'm among the few who know how to use them on Meta-Wiki...). --Nemo 18:49, 16 August 2012 (BST)

Well, I'm not yet fully convinced that these markers are user-friendly (or indeed necessary), but right now I have three more questions:

• It seems like the extension would give us localized page titles (e.g. [1]). Can you confirm this for our use case?
• Is it possible to filter search results by language? We currently have crude filtering based on namespaces, which is hardly satisfying, but at least better than nothing. I cannot find such a feature in the KDE wiki.
• How does the system deal with a page where the English version is not the original text? For example, we have quite a few pages that are German-only at first. So if a page starts out in German, an English translation is created later, and translators might add more versions based on either the German or English version afterwards - how would this workflow look with the extension? Is it a problem if later updates first appear in the German version of the page?

--Tordanik 00:07, 18 August 2012 (BST)

Hello, thanks for your questions. :-)

• Yes. This is usually considered better than the namespaces, for instance Meta-Wiki just got rid of them. The only piece missing so far is altering the title shown in categories, w:bugzilla:29928. This is not super easy to fix but will probably fixed at some point, especially if there's much interest for it.
• It's somewhat possible, also in RecentChanges, but improvements are in the works. See for instance filtered search and filtered RC thanks to CleanChanges extension.
• Sadly this is currently not possible and there are no concrete plans to change it, w:bugzilla:35489. Are there many pages like this, does much translation happen from languages other than English? If a page is "structurally" in German first, there's not much to do but not using the extension for it; if this is an ephemeral status, non-English pages can be allowed to grow or change more by making more flexible translatable pages, i.e. by preventing the extension from splitting them in translation units too much (if not, the worst which can happen is that you can't refactor the page in German, only add content in the same structure).

I hope this helps, Nemo 00:58, 18 August 2012 (BST)

There are many pages that are only in a single, non-English language - for example Passau/Mappertreffen or Tours, which are pages by local users about regional matters. I guess these are less of a problem because as long as no translation is happening at all, we can just leave them as they are. (But is this compatible with the filtered search?) Pages that start out in a non-English language and are translated later are quite rare in comparison, but they do exist, e.g. WikiProject Austria/EN:geoimage.at. As you can see from that example, though, they are sometimes not using the current standard templates either, so maybe a perfect solution is just not actually necessary. --Tordanik 16:34, 18 August 2012 (BST)

As for filtered search etc.: no, that wouldn't work with the current system; however, you could just move them to subpages like Passau/Mappertreffen/de for consistency (as we do with English pages on some wikis), it doesn't usually give any problem. As for the rest, yes, probably perfection is the enemy of good here! --Nemo 17:59, 18 August 2012 (BST)

I agree that we should start using this. We could start using it gradually with some pages, as I suppose it could be difficult to start with pages that are already translated and with differing content in the various translations. How would you go about implementing it gradually? --Guttorm Flatabø 16:07, 16 August 2012 (BST)

There are many ways to be gradual, it all depends on what is considered important. In general, it's wise to translate only reasonably stable pages. Adding new pages to translation with the extension is easy (easier than with templates), so you could decide to start with the "long tail" of completely untranslated pages by mass adding them as first thing. You could decide that all new pages are translated with the extension. You could select a few high-traffic pages that you want more translations of and start with those (it was w:m:Terms of use for Meta).

In general, what requires most work are 1) selection of the pages to translate, 2) import of old translations in the new system (directly proportional to the number of translation units unless the translations are very structured and you find some semiautomation). --Nemo 16:36, 16 August 2012 (BST)

Regarding "1) selection of the pages to translate" Thinking about priority pages to translate (not particularly using any new mechanism, but just which pages are the most important) We discussed this briefly in a Communications Working Group meeting on one occasion. We thought maybe it would be good if CWG came up with a list of top translation priorities (e.g. top 20 pages). Because it's a subjective judgement, maybe it's helpful for us to do this, rather than everyone debating what the priority pages are, and then we can track progress with translating them. Do you guys think that would be helpful? -- Harry Wood 15:28, 20 August 2012 (BST)

With the generally positive feedback, I think this extension deserves a chance. My preferred approach would be to have it installed, but limit its use to a set of yet-to-be-determined pages at first and decide whether it works for us. Preferably, this initial set of pages should not include controversial tagging documentation, and nothing that requires bots or parsing software using template content to be modified (another argument against the tagging docs, but also against things like software pages). Tutorial pages might be a good choice as these are predominately text-based, not used for automated parsing, and useful content to have available in local languages. Of course, this requires support by an administrator who is actually able to install the extension. So how do we proceed? --Tordanik 09:48, 28 August 2012 (BST)

I will install the extension when I upgrade the install of MediaWiki. -- Firefishy 13:32, 3 September 2012 (BST)