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)

Real namespaces are not the problem, they can be made lowercase by editing some variables in LocalSettings.php! The virtual namespaces could be improved with <span>{{DISPLAYTITLE:{{lcfirst:{{PAGENAME}}}}}}</span>. I think a wiki-server-admin should create namespaces for all used languages. --phobie m d 18:38, 6 April 2013 (UTC)

I created Template:Lowercase namespace and added it to Template:Languages. Please report bugs on Template talk:Lowercase namespace! Discussions on its reasonability should be done here! If the wiki-server-admin changes the real namespaces to lowercase, we can further simplify that template. --phobie m d 12:27, 11 April 2013 (UTC)

note: Hungarian namespace is/was moved (today) - see User_talk:Phobie#What_are_you_trying_to_achieve_with_page_moves.3F. --Aseerel4c26 (talk) 19:19, 16 April 2013 (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/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)

This was done 3 days ago, but the Translate Extension is not installed yet. --Andi 09:53, 15 February 2013 (UTC)

This is now more than 1,5 years ago, is there any chance for a small Trans-Revolution? Hakuch (talk) 15:24, 9 October 2014 (UTC)

Posted the situation on Talk:Wiki (here) to get more attention to it. --Dhiegov (talk) 14:31, 6 March 2019 (UTC)

Welp, turned down in about a month leaving us with status quo: No automatic way for detecting when translations are out of sync, a weird combination of article name prefixes and per-language namespaces, no simple interface for translating and most likely an impressive number of translations which are out of sync but which haven't been noticed yet. At least there are no markers in the source code for English "core" articles. --Nw520 (talk) 19:42, 5 August 2020 (UTC)

Different numbers of languages in the language bar

From time to time I find pages with different numbers of languages in the language bar of a page, e.g Beginners_Guide_1.0:

• 8 languages are shown in the english version as well as in the DE-, ES-versions, in the other languages there are 11 languages shown in the language bar (if they have a language bar)
• When I added {{Languages}} into the RU-version the language-bar appeared with 11 languages.
• When I tried the same in the HU-version the language-bar appeared with one language only (english) and no working link to the english page (so I did not save that).

Maybe similar problem: AZ:Beginners'_guide:

• The language bar is available but the AZ-language (Azerbaijan) is not shown in that language bar. If you use a link in the language bar the Azerbaijan language is not shown there eighter.

What are the problems behind that and how can I fix that problems?

--Rennhenn 12:45, 26 January 2013 (UTC)

Because the language prefix for Hungarian has not been configured as a namespace known to Mediawiki the base page name needs to be passed to the {{Language}} template as an argument.

The language prefix for Azeri is Az: with a lower case z; it is worth pointing this out to the author of the pages.

The language prefix for Hungarian was similarly Hu: until a non-Hungarian-speaking editor arbitrarily changed it. Andrew 14:20, 26 January 2013 (UTC)

Thanks. Regarding AZ: I sent out a short notice and a positive reply.

Regarding HU: I will probably not solve the general problem from point of view of a root cause. (Template is able to wor forward to HU but not backwards from HU).But I found a way to "repair" this special case:

   I did not use {{Languages}} but {{Languages|Beginners_Guide_1.0}}

--Rennhenn 07:15, 30 January 2013 (UTC)

Regarding "8 languages are shown in the language bar of some language-versions, 11 languages in others": Unfortunately there are 2 pages intermixed and interlinked via redirect or other tools: Beginners_Guide_1.0 and Join_the_community. This is working well in the english version but not in all other languages. I will probably not solve that problem completely (I feel not experienced enough).

• I will fix it for the DE-versions as this was one of my translation projects. It is not finished yet because of waiting for a reply. Knowing now of the confusion which the 2 "versions" can cause I will fix it the next days.
• I think we can live with that for a certain time. But the users working on an update of the "Beginners Guide" should take that into account when they finish their task.

--Rennhenn 07:15, 30 January 2013 (UTC)

Problem solved for Azeri and Hungarian. PLEASE use only lowercase language codes for prefixes everywhere'. This will help everyone and will simplify templates a lot. Pages can now be cleaned up, but for as long as this is not done, the redirects are kept to preserve working links.

When creating new pages or editing them, you should replace all codes using lowercase only for page names, template names, including when linking to articles written in the few languages that have a dedicated namespace (in my opinion, even those namespaces should be presented with lowercase only, but anyway the letter case of these namespace names are not significant, so nothing needs to be changed, this is presentational only). — Verdy_p ^(talk) 19:40, 7 June 2013 (UTC)

Missing default english page

Is there a way to for the Language template to populate a category "Need Translation to English" if the page has no equivalent english namespace page? Or will this demand too much resources? --Skippern (talk) 16:54, 2 February 2013 (UTC)

Category:Pages unavailable in English --phobie m d 18:08, 11 April 2013 (UTC)

Localized templates

See http://forum.openstreetmap.org/viewtopic.php?id=20672 --Andi 10:45, 1 April 2013 (UTC)

Proposal for removing the en: and EN: namespaces

Currently the virtual namespaces are only used for 30 pages (EN: 12 and en: 18). T:Languages can't handle those namespaces! The only sane solution for wiki-translation is to have a clear separation of languages. If there is English content, it should always be at Page_name. If there is no English translation yet, Page_name should be a redirect to the main-article at <code>:Page_name. --phobie m d 18:44, 17 April 2013 (UTC)

you need to fix it. English pages without prefix. Others have.--dr&mx (talk) 19:26, 17 April 2013 (UTC)

Proposal for removing WikiProject prefix

The page-name-prefix WikiProject has been used for several country pages, but not for cities or states which are also wiki-projects. This is inconsequently and Category:WikiProject might fit better. --phobie m d 19:04, 17 April 2013 (UTC)

it's just the name of such pages. leave as is --dr&mx (talk) 19:29, 17 April 2013 (UTC)

Changes off Wiki Translation on 2013-04-14

User:Dr&mx gave the advice to move all pages with translated content to translated page-names. This would be ok on wikipedia, but this is a English-documentation-wiki with translations of English content. It is much easier to maintain the translations if they use the same page-name with a prefix. Also it is impossible to support native names in T:Languages correctly. If users want to show a native name on a translated page, we could use this template {{native|Grodno|ru|Гродно}} which could show a text like {{main|Гродно}} does. --phobie m d 09:36, 19 April 2013 (UTC)

Dr&mx’s explanations should be reinstated. OSM aspires to be a map of the whole world and having pages in multiple languages is part of this aspiration. Mediawiki is intended to be used with natural page titles; what is more natural than a title in the same language as the contents? Going on a rampage through the wiki moving pages with aggressive summaries doesn’t help anything either. Andrew (talk) 11:47, 19 April 2013 (UTC)

Interesting to see a reaction of you here. Ever tried to post one on your talk-page?

Yes, having the English documentation translated to as many languages as possible is part of this aspiration. But we need to keep those translations in sync! Mediawiki is intended to serve the needs of Wikipedia (separated encyclopaedias for every language without direct translations). As you can see on the MediaWiki-documentation-wiki translations of documentations does not use native page-names. We should try to get the same good translation status as the MediaWiki-Wiki already reached. Naive page-names does not help reaching this effort. BTW. Neither I see a rampage nor aggressiveness in my summaries. I think all summaries should be written in English and since this is not my first language there might be some errors. --phobie m d 14:51, 19 April 2013 (UTC)

What would be the problem with the practice that has worked before: Page_title, Xx:Page_title -> redirect translated_title, translated title = content? From previous experience, the languages template doesn't care if Xx:Page_title is content or redirect, and the content in any other language has the proper title. Alv (talk) 21:45, 19 April 2013 (UTC)

what is the difficulty of sync? name in another language? Redirect? The articles have a category. On the category page has a list of all its articles. You advise me to people who do not know English display the names of only a foreign language? nonsense. I and other users to track changes in the English article and change it if necessary, Russian article.Some articles will never be a copy of the English. There are some features in the Russian Community for certain moments. Russian articles will match the understanding of Russian society. In view of English articles. Do not copy. --dr&mx (talk) 15:56, 19 April 2013 (UTC)

GSoC 2014 proposal for page migration under the Translate extension

Hello everyone!

I am Pratik Lahoti (User:BPositive) from Pune, India. I am willing to participate in the Google Summer of Code this year. I am interested in the project titled - “Tools for mass migration of legacy translated wiki content”.

My mentors for this project would be Niklas Laxström and Federico Leva.

With their help, I have drafted the first version of my proposal page. You can find it here:

https://www.mediawiki.org/wiki/Extension:Translate/Mass_migration_tools

This project is a blessing in disguise for all the translation administrators, as it completely automates the tedious manual task of preparing the pages for translation as well as importing the translations. The proposal page mentions the Project Outline and the approach/solution towards the problem statement. I am done with most of the sections and left with the Project Schedule (which I will finish off when everything is finalized).

Please have a look at the proposal and give your valuable feedback/suggestions. While I have no problems in replying to the suggestions put forth over here, I would appreciate if you can do the same on the [2] of the proposal, so that all the feedback is at one single place. Looking forward to hearing from you, Thank you! BPositive (talk) 19:23, 4 March 2014 (UTC)

Support Tr namespace

Hi, can anybody plz help over at the OSM support for that issue? https://help.openstreetmap.org/questions/38648/how-to-change-a-wiki-page-content-language

Moving (renaming) pages is unavailable

The section Translated pages with a title in a non-English language suggests that in order to rename a page we have to move it using a new pagename. The problem here is that I don't see the "Move" command where it should be, next to History and the watch-star, like in other wikis (eg. Mediawiki). Is it possible by the administrators to add this feature to the site, so that the translation process is achieved in less time?

Nikolakis (talk) 16:45, 3 May 2016 (UTC)

The Move command should be available from the drop down menu under “More”.--Andrew (talk) 17:05, 3 May 2016 (UTC)

After having tested it in IE, Chrome and Edge, the "More" menu is not displayed. From a look at the HTML code, I see that it is hidden because of the div class emptyPortlet. Moreover, the code into the div does not contain the Move command. This seems to have been removed technically from the php, but I can't figure out why. Could the webmaster restore it, please? --Nikolakis (talk) 10:39, 4 May 2016 (UTC)

It is disabled only if you are not logged in on this wiki. The menu popup DOES WORK and is displayed in IE, Edge, Chrome, Firefox, Opera native Android browser, iOS native browser...

If not, may be you are using an old browser on an old OS. — Verdy_p ^(talk) 11:49, 4 May 2016 (UTC)

If you got to your preferences Special:Preferences, set an email address, and click the confirmation link you receive, then I think you'll see the 'Move' menu option. ...I think

I think what's happening is that yours is a very new wiki account so it is not "confirmed" and as such has reduced access to some features. The quick way to fix it (I think) is to set up your email address. Otherwise your account would become "auto confirmed" after you have made at least 10 wiki edits and after at least 4 days have elapsed (with the settings for this wiki as they are)

So welcome to the wiki by the way! You might also edit your user page User:Nikolakis to tell us a bit about yourself and link to your OSM user account

-- Harry Wood (talk) 11:56, 4 May 2016 (UTC)

Your point about my wiki account that was a very new one was right. That was exactly the case. After having set up my profile and having made a few contributions my account was upgraded! What a relief, now I'll be able to do all these moves I need for the proper translation in my language! Thank you for your support!-- Nikolakis (talk) 20:47, 4 May 2016 (UTC)

{{DEFAULTSORT}} in translated pages

We (Japanese speakers) use {{DEFAULTSORT:sort key}} for translated pages to be sorted and classified correctly. Unlike many of European languages, a page named Japanese (or other some languages) needs another sort key; it should be sorted and classified in category pages by the reading (written in katakana), not the display name (i.e. written in kanji). And the reading can't be determined automatically from the display name. e.g. 道路 should be sorted as ドウロ and classified in ド, not 道. However, 道 should be sorted as ミチ and classified in ミ.

I think it should be used in the top of a page (before the {{Languages}} template) although DEFAULTSORT tends to be used in the bottom of a page. The main reasons are below:

• DEFAULTSORT is a meta information belong to the page name rather than for category, because a page can have several categories, but it can have only one DEFAULTSORT.
• If it is used in the top of a page, it can overwrite a sort key defined in templates. Some templates (e.g. {{Languages}}) overwrites DEFAULTSORT for a reason (and they doesn't often consider languages which needs sort keys). Using it in the top of a page can overwrite the behavior of the template and it can avoid to be overwritten accidentally (And I recommend to use {{DEFAULTSORT:sort key|noreplace}} in templates then the "defaultsort=no" parameter in the {{Languages}} template will become unnecessary). When it is used in the bottom of a page, it can't overwrite the templates' behaviors.
• The main reason to avoid to use DEFAULTSORT in a page, but in a template, is to avoid to break the sort key when a page is moved or copied. (See also WikiProject Cleanup#Pages with ns argument to the languages template.) Putting DEFAULTSORT in the top of a page makes easier to be realized it.

So I propose to describe the usage of {{DEFAULTSORT}} in this page as below.

• If you want to set the default sort key different from the page name for categorize, you can use {{DEFAULTSORT:sort key}} in the top of the translated page.
  • Sort key is needed in Japanese or other some languages because translated pages in the language should be sorted and classified by another sort key, e.g. 道路 should be sorted as ドウロ and classified in ド, not 道.

Please comment it if there are any problems. --Mfuji (talk) 06:19, 18 November 2016 (UTC)

This is not specific to Japanese, sort keys have to be set in many languages when their titles are translated in other languages than English (e.g. in Latin accents are to be ignored in the sort order for most languages, with just exceptions for overlay slash diacritics used in Nordic languages, or the Umlaut over vowels in German that should sort as the base vowel followed by an "e", or the ess-tsett in German sorting as "ss"). Sort keys are specific to each language, not just Japanese (but it's true that the default sort order has to be changed alsmost always when the title contains Kanjis, to be sorted with kanas, there's no disagreement at all about this).

In Korean using the Hangul alphabet, precombined clusters are automatically decomposed into Jamos for sorting them. In Chinese, translators may want to use Bobomofo sortkeys, or most probably Roman sortkeys according to their national standard because the wiki cannot guess the reading as well and there's no dictionnary to support it here: we are not on Wikipedia that has extensions for Chinese, inclujding support for Simplified Han/Traditional Han transliterators of Hanzi clusters in Mandarin). Cantonese (code: yue), other sortkeys may be needed. Cyrillic or Greek generally does not need sortkeys unless they are written with diacritics (rare in Cyrillic, but Greek may need leading acute accents for tones, not significant for sorting; Arabic or Hebrew titles should use sort keys if they use optional diacritics for vowels or cantillation, but this is rare in titles and for technical texts like on this wiki: we are not writing a wiki about Biblic or Talmudic or Islamic religious texts). Anyway this wiki does not have integrated the support for collations per language, or even per namespace (Japanese uses a specific namespace but only for the main article space and its talk pages, not for categories, templates, user pages, user talk pages and some other special namespaces). The "File:" namespace is unsortable and most images are in fact from Commons and not sorted on this wiki (their categories are visible on Common only)

Most English pages provide the place for it, along with other categories (like in all other wikis using default sort keys, because each listed category can also provide an override for fewer terms than the full category name for sorting them appropriately (e.g. dropping leading common terms, dropping optional articles before some nouns of countries...). Most often a single DEFAULTSORT will match all sortkeys for individually listed categories. Translators only have to look at them at one predictable place, and categories are sconsistently at bottom of pages (also because the traling newline after each one will be dropped at end of pages, as the categories don't generate any content at this location. But the default sortkey at top will frequently insert significant newlines before the rest if what follows it is not a div or table: the newline following it is not automatically ignored. depending on what follows it.

Even the Japanese Wikipedia or other Japanese wikis follows the convention of placing DEFAULTSORTKEY at end, just before categories they will affect, never at top of pages. Many Japanese translators will expect to see these sortkeys there, if not they will add it there without looking at the top of pages where they are known to cause frequent undesired vertical margins. This convention is used universally, including on this wikis on many untranslated pages.

As well translation status banners that are specific to a language should still be below the interlanguage bar (listing many unrelated languages not concerned at all by these status banners). All these banners fit well, include when the language bar is in a Place template (the Place tempalte is separately translatable and is not concerned by the banner related to the rest of the page). — Verdy_p ^(talk) 06:49, 18 November 2016 (UTC)

talk's very verbose comment just seems to say: "Because we have did so". But where does it described? Or only in his head?
And I think it should be changed if it became a hindrance of something. As I said first, following this aesthetics makes several templates complicated and brings heavier loading on servers. This factor is different from the Wikipedia or other wikis.
I want to hear other people's opinions. --Mfuji (talk) 01:34, 2 December 2016 (UTC)

Placing tit at top or bottom of page does not make templates more complicated and does not cause any additoinal load on the server. This is purely a convention used across wikis to put it at bottom along with categories (alos because at top it generates an additional undesired newline). That's not in my head, it is used on all Japanese wikis I've seen (on Wikimedia or not), becuase this is where most users expect to find it (and it is also like this that it is documented everywhere including in standard MEdiaWiki wiki's documentation.

I've never said that the defaultsortkey should not be placed in pages themselves (in fact it is the prefered place rather than inside templates, something that I have not supported at all but some other users insist on doing: in "feature" templates, the automatic addition of default sort keys is cuirrently disabled by default, because I really know this is a problem). — Verdy_p ^(talk) 02:50, 2 December 2016 (UTC)

Support for Tagalog

To support translation of wiki pages into Tagalog to promote local language use for the Philippine mapping community, I want to include Tagalog on the existing languages supported. I am starting translations of Philippines-related wiki pages to Tagalog, but that seems to be not supported yet. TagaSanPedroAko (talk) 13:38, 6 July 2017 (UTC)

Which language code do you intend to use ? Officially Tagalog is the historioc name of the language written in its historic script, but today it most commonly refers to the modern language written in Latin, and officially name "Pilipino". ISO 639 distinguishes the two language tags, but in ISO 639-1/2 they were not distinguished, the distinction starting since ISO 639-3 and update to BCP 47.

I don't see why you think that language is not supported, unless you select the wrong language code, not assigned in ISO 639-1/2/3 and not registered in the IANA registry for BCP 47 language subtags. The code "tl" is working, as "{{#language:tl}}" returns "Tagalog". So use the "Tl:" language prefix for pages (and in OSM data you already have tags using this code such as "name:tl=*").

For you I just initiated the root category for Tagalog in Category:Tl:Categories. — Verdy_p ^(talk) 13:45, 6 July 2017 (UTC)

New header image

OSM translation logo.

Hello! I would like to change the image that appears on the Wiki Translation pages for this one. What do you think? --Daniel Capilla (talk) 16:51, 6 May 2018 (UTC)

Why not for the image at top of Wiki Translation, however you should be aware that for the wiki, the translation is also largely based on MediaWiki translation made on translatewiki.net (where you translate the interface, and various OSM subprojects also use translatewiki.net, without necessarily using MediaWiki for themselves, or depending on this wiki).

This page is only about translating this wiki, and other OSM projects use other tools (not necessarily and exclusively for OSM projects), they have their own translation methods that this page does not describe. There's a more general category on this wiki about the various OSM translation projects.

There's also separate propjects for translating OSM editors, for example done in Transifex, or other development sites such as GitHub. The various Web sites for local communities have also their own tools, or are sometimes just translated by submitting translations to some email or mailing list.

So you should be clear about which page you want to place this icon. And be aware that we also use another smaller icon (the one you see at top of page for the "Universal Language Selector" near the user name and user icon is from MediaWiki itself, it was made to be readable at small size, but your proposal would not fit very well and would be confusable with a generic OSM icon). — Verdy_p ^(talk) 18:11, 6 May 2018 (UTC)

Hi, Verdy_p! Thank you! I would only like to change the image on this page, Wiki Translation. I wrote "pages" (plural) because the page has versions in several languages, although I only referred to one page. I know that the translation of the contents of this wiki is not the only translation project in progress. I propose only to change the image on this page. Thank you again! --Daniel Capilla (talk) 21:23, 6 May 2018 (UTC)

Maybe this logo would be better on the Translation page. --Daniel Capilla (talk) 13:27, 30 May 2018 (UTC)

Weird tag pages with few occurences in Category:Translate from German

Hello,

there are many (tag) pages in this category which seem weird to me:

• Key:AlpinRes ID: usage according to Taginfo 4 nodes
• DE:Key:biosphärenwirt: The German page says that most info is found on DE:Tag:biosphärenwirt=yes and there is this umlaut in the key, plus usage 5 times
• DE:Key:city_limit basically the same as DE:Tag:traffic_sign=city_limit, usage 650 times.
• DE:Key:monument:genesis, usage 32 times
• OSMsuspects!: the English version redirects to the German one which says that the webpage is out of service since June 2018...
• DE:OSM Drohne is suggested for translation, but there is a newer page available in English (UAV).
• RU:OSM-4D has translate from German, but does not feature any Russian text (why does this page even exist?)

Do these pages actually need a translation at all? --Tigerfell  (Let's talk) 16:52, 1 September 2018 (UTC)

Using an additional native namespace for Farsi

Could we use an additional prefix for Persian pages? I want to use 'فا'. This is mainly because Persian is RTL and the prefix 'fa' is LTR. If we can use 'فا' It will reduce problems/difficulties in regard to bidirectional writing. Then we will write 'Fa:Quality_assurance' or 'فا:تضمین_کیفیت' and not 'Fa:تضمین_کیفیت'. -- iriman (talk) 11:22, 13 October 2018 (UTC)

Which problems do you encounter right now? (Sorry, I have no knowledge regarding LTR and MediaWiki).

I can see two problems in your request (regarding templates and translation):

1. Having two namespaces for a language would mean that templates (like Template:Language) would need to find out the linking to the appropriate page every time.
2. All templates that use automatic language detection determine the language of a page by the prefix in the title. This would need to be changed. This is somewhat more difficult as most of them fall back to English, if they do not detect anything valid.

--Tigerfell  (Let's talk) 12:04, 15 October 2018 (UTC)

The problem is about the way we write in wiki. We should put some extra efforts to translate or write a new article. It includes repetitive switching keyboard layout and more important working with a mixed text of rtl and ltr words, and, add to this, mixing with punctuation symbols of syntax, that totally makes edditing/creating Persian wiki a boring task. What goes in my mind is to translate wiki syntax to Persian. for example to get sth like {{فا:تگ|highway|service}} or even better {{تگ|highway|service}} which is equivalent to {{tag|highway|service}}. Then, at the end, we would have less ltr words (keys and values of tags, links, some other) within persian (rtl) which makes it easier to edit in text mode. But existence of namespace 'fa' before names stops me to do so. -- iriman (talk) 17:05, 17 October 2018 (UTC)

Okay, I see. You could already use a template like that. Templates are in their own namespace Template. Therefore, if you would create a page named Template:فا:تگ which only contains the text #REDIRECT [[Template:Tag]], you could use that template. The prefix "Fa:" is mainly relevant for translated pages, so that the translation templates can find out the language. --Tigerfell  (Let's talk) 14:40, 19 October 2018 (UTC)

Moving translation table into a separate template

I would like to move the translation table on the Wiki page into a separate template to assure that all translations are always up to date. Objections? --Tigerfell  (Let's talk) 17:38, 6 December 2018 (UTC)

Very good idea. I was thinking the same. :)

We should do the same with other articles. Remember to internationalize table titles --Władysław Komorek (talk) 08:10, 7 December 2018 (UTC)

Well, I still have hope to get this Translate extension going. This would make this step useless. I just intended to change this page because some user complained about Pt-br pages being created. You can find a draft of the template at Special:Permanentlink/1705554. --Tigerfell  (Let's talk) 22:06, 7 December 2018 (UTC)

Looks OK. Good job. --Władysław Komorek (talk) 14:38, 8 December 2018 (UTC)

Thank you. I am done now. --Tigerfell  (Let's talk) 15:09, 8 December 2018 (UTC)

Native name within the side template KeyDescription, ValueDescription

Can we add the parameter |nativekey = in Template:KeyDescription, |nativekey = and |nativevalue = in Template:ValueDescription as a name internationalization project?

Many names in English are very unclear with any translation (e.g. in Google).
I have been adding it for a long time in Polish versions, but I have to use my own modified templates.
I would prefer to use standard templates, as well as other people from Poland.

An additional name in the native language inside the template, it will help them quickly understand names for people who do not know any of the languages describing a given key or tag and simplify the search.
Maybe someone knows a better way to show these native names in side templates?

E.g:

{{ValueDescription
|key=
|value=
|nativekey=<name in native language>
|nativevalue=<name in native language>
.
.
}}

Thank you for your understanding. --Władysław Komorek (talk) 18:04, 8 December 2018 (UTC)

I understand the situation. The template was recently changed completely to draw its informations from Wikibase (see the announcement at Talk:Wiki). That is why I suggest to add the data to Wikibase. I guess OpenStreetMap talk:Wikibase would be the correct place to discuss this. --Tigerfell  (Let's talk) 16:03, 9 December 2018 (UTC)

Any help for Open Food Facts community?

Hi there! OpenStreetMap community is older and bigger than us, the Open Food Facts community. We're about to migrate and rebuild our old MediaWiki, and language management here is very inspiring for us.

I would like to talk to tech people that build the language architecture here. I've already read a lot but I have few questions:

• Why did you change from Template:Languages/div to Module:Languages? Performance issues? I'm a bit scared about adding Lua scripts in our wiki. Wouldn't your old method with Template:Languages/div fit better to our little wiki (only thousands of pages)? Is one of these two solutions easily replicable in our wiki. Is it well documented?
• Why don't you use Translate:extension? Is it because it seems to force "Test/fr" naming convention, while you/we would like to use namespaces (such as "FR:Test"). Is it possible to use namespaces instead of “/fr”?

Thanks for your support. --CharlesNepote (talk) 14:35, 19 March 2020 (UTC)

The switch to Lua mostly happened for performance reasons and because users were interested in tuning it, but I do not think there was a specific issue. You can read the discussion at Template_talk:Languages#Lua_rewrite (latest changes.) Template:Languages is used on 51000 pages only, so I do not see that much of a difference to your wiki. I would guess that importing the templates is easier, because you would not need to install Lua first. Beware that the templates are specific to this wiki, meaning that they are made to handle language prefixes as well as language namespaces and mixtures like Category:ES:Images. Translate extension provides a language bar, so you would not need to take care of it.

I investigated the question whether it is possible to use our naming conventions with Translate extension and I think it is not possible (especially with the namespaces for some languages). The last discussion about translate extension is available at "When are we going to migrate to Translate extension?". It also includes links to many previous attempts to install the extension. Some users disliked the additional markup like <!-- T1 -->. Secondly, Translate assumes that there is one major language, all information is available in this language, and that all other languages are just translations. This is not the case in this wiki. Lastly, one system administrator was not interested in installing the extension. (Sorry for the bitter tone, but if a system admin blocks something, it is simply not going to happen and this smashes every previous statement). The whole system of language namespaces is simply a historical debt that is very difficult to leave behind. --Tigerfell  (Let's talk) 22:14, 19 March 2020 (UTC)

Confirmation code to create new translated pages?

I was going to translate Relation:street into Russian, but after entering its title preceded by language code Ru and inserting into the editing space Template Languages or simply the word Languages, confirming on a pop-up prompt creating a new page I saw an empty text box asking for confirmation code. How do I get one? Lesno (talk) 21:46, 5 February 2021 (UTC)

This is an error which occurs when using mobile edit and CAPTCHA protection in combination. It was reported to the developers, but no solution has been published yet. You should be able to avoid this issue if you create the page using the desktop version. You can edit it with mobile edit afterwards. --Tigerfell  (Let's talk) 11:10, 7 February 2021 (UTC)

Position of the "Translated" template on translated page

Regarding this change by @Artoria2e5: (Thank you!), I consider it more appropriate to suggest that the template be placed at the bottom of the page, not at the top (I will change it on the "Wiki translation" page). Information about the version of the translation or who did the translation is interesting information, but it is auxiliary information, not a fundamental or main content of the particular page. It is better to place it at the bottom as auxiliary information. On Wikipedia it is placed at the bottom or in the "External links" section.--Dcapillae (talk) 11:40, 20 February 2021 (UTC)

I agree with the reason for this change, but the text included by the template in the page is written to be placed at the top of the page, so it must be changed to be consistent: now it says "Insert all new information or information which are specific to your place before this notice." and it must say "Insert all new information or information which are specific to your place after this notice." . On the other hand, the end parameter no longer makes sense if placing the template at the end. --Robertogeb (talk) 08:06, 26 September 2021 (UTC)

Not able to see my language under "Other languages"

I want to start translating in my language, Marathi (मराठी) "mr". As per the below instruction mentioned here,

"Click on the Other languages link in the language template and follow a red link to the language you want in order to begin creating the new wiki page. You will see that the new page will have the same title, but a language code prefix added."

I was expecting to see मराठी present there in red colour, but it is not. Also not sure if it is related, but I noticed that Marathi is mentioned as "unlisted" in the table here. Please tell me how I can get the language to be displayed there, so that I can start translating. Thanks. -- Warkari (talk) 14:43, 22 May 2022 (UTC)

Unlisted does indeed mean there isn’t a link offered to Marathi (because you are the first person to want one). I have added a link below the table to the documentation of how to make a language listed (at Module:Languages/config) Andrew (talk) 17:30, 22 May 2022 (UTC)

I have added Marathi to the template. Happy documenting! Andrew (talk) 18:53, 22 May 2022 (UTC)

Thanks! I have started documenting pages in Marathi, but I ran into one issue (which I quickly reverted back). I want to change the namespace for Marathi from default "Mr" to upper case "MR". To do this I added to the Module:Languages/config the line `["mr"] = "MR",` in the table "namespacesByLanguage" but that broke the language bar. Later I realised that maybe I also need to add `["mr"] = "Pages unavailable in Marathi",` in the table "unavailablePageCategoryNames". Just want to be sure before I make this change, so that I don't break anything again! :) Warkari (talk) 13:44, 27 May 2022 (UTC)

It is okay we can undo it back if something breaks :-). No, please do not change the namespace to uppercase. There is a separate setting for that inside the MediaWiki configuration. We can not access it. It was a huge mistake that namespaces in upper cases were created. It is just too much work and would involve the hidden configuration so we can not change it back. The whole system relies on lower case namespaces except for the seven exceptions. --Tigerfell  (Let's talk) 17:34, 27 May 2022 (UTC)

Osm Go! is looking for translators and developers

The Osm Go! team is looking for translators in any languages & developers.

• Translations are done on POEditor, just read the instructions here.
• Developers feel free to make some PR. Guidelines available here.

-- Binnette (talk) 14:35, 17 June 2022 (UTC)

As the title says, this page is about the wiki translation. If you want to find new translators, you can list you project at Translation#Editors_and_other_contributing_tools. Do not forget to update the translations, too. --Tigerfell  (Let's talk) 18:03, 17 June 2022 (UTC)

Revision number

We are strongly recommended to note the revision we are translating by adding {{Translated|revision=NUMBER}} to the bottom of the translated page. However, the text in this template says "The following text is a translation of the original article in ..." To me that looks a little strange when it is placed at the bottom of the page (after the text). Shouldn't it be something like "The text above", "The preceding text" or "The previous text"? --Fugit Hora (talk) 20:37, 25 October 2024 (UTC)