Talk:Wiki Translation

From OpenStreetMap Wiki
Jump to: navigation, search

Contents

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)

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)
Yes check.svg  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)

Personal tools
Namespaces
Variants
Actions
site
Toolbox