Template talk:Languages

From OpenStreetMap Wiki
Jump to: navigation, search

Only for English pages

You can use it only to point from English page to others.

For other languages we can point to the English version, as a main page.

--Rodrigo 19:14, 21 November 2006 (UTC)

OK I've just implemented that for OpenStreetMap License. So I've translated the words 'English and other languages' into different languages (using babelfish) and used this as the link text to point back to the English version. That seems to be satisfactory, at least you can navigate between the pages properly and consistently. A better solution might be possible, the one suggested below perhaps. -- Harry Wood 16:58, 3 May 2007 (BST)

Redesign of the Language Linker

I wrote another version of the language linker, which allows translated pages to have proper names instead of <langcode>:<english_title>. Aditionally, it can be included in non-english pages. The new linker should be downward compatible, so it could replace this template without problems.

You can find the template (including documentation) here: Template:Language Links experimental

--Fnord 15:38, 8 February 2007 (UTC)

So this is better than Template:Language Links, because it's a bit rubbish having to work with english page names. And on (for example) a german page you would ideally have links to the italian page etc, rather than only linking back to the english page. In other words it makes it a bit less english centric.
It has the disadvantage that it is harder to use. It's a more unweildy messy block of wiki text appearing at the top of the page, which makes any editing of the page a more confusing experience for wiki-newbies.
I think one thing to consider is that if translation and other wiki activity in other languages were to ramp up, and the project became much less english centric, then english users (and indeed all users) would start to find all the other language activity on 'Recent Changes' would be an irritation, and there would be calls for a proper multilingual implementation wikipedia style, with an entirely separate wiki database for each language (technically quite tricky to acheive). That's the extreme multilingual end of the scale. At this stage it's obviously a predominantly english speaking project, and the more simplistic template reflects that. The Template:Language Links experimental is a kind of half-way solution, but not without its disadvantages as I say.
Just some thoughts. I think if we make sure the Template:Languages is used properly (it should only be placed on the base english pages) then it would be clearer to see why the more complex template might be better -- Harry Wood 14:14, 21 May 2007 (BST)

Mediawiki Magic_words

I tried to use {{PAGENAME}} (See Mediawiki:Help:Magic_words) but it seems that some language-namespaces like DA an JA are not registered correctly and {{PAGENAME}} returns "Da:Sitename" instead of "Sitename" --Phobie 11:24, 2 December 2008 (UTC)

Change layout

I would change this template to look like Template:Languages. Benefits are: same look, not so prominent, much easier to read or change. -- ck3d 17:43, 20 December 2008 (UTC)

+1 --Phobie 15:37, 21 December 2008 (UTC)

Template talk:LanguageNew

This is a template that lists all languages available. It is based on parser functions from mediawiki. The problem is that it is using a naming scheme of PAGE_NAME/LANG, e.g. Mainpage/sv instead of sv:Mainpage or sv:Huvudsida.

Some one needs to understand how this works before it's used. Erik Johansson 12:21, 19 August 2008 (UTC)

ACK. I'm not able to use it :-( Stammfunktion 09:33, 10 October 2008 (UTC)
I've created a new template that works ok, although there is room for improvement. It's nearly ready for prime time. Template:LanguageTest. Preview it here: Test. For English pages, it gives precedence to [[En:Page]] over [[Page]] for the moment. -- Firefishy 10:47, 10 October 2008 (UTC)

Thoughts

I think it that this system is not very intuitive. It demands that all the pages ("files") have the original English name as title, with the prefix for the language code. The problem is many people in other languages do not know the appropriate English name for the concept that they are looking for. Also, it looks awkward to generate a namespace just for the language code. That does not look nice (De:Map Features). Also, it makes it very difficult to find a page with the in-build search box (if you do not know the English name). I prefer the appropriate page titles of each page, which are then combined as links in the multilanguage template ("the old system"). The disadvantage is that you have to generate a template for each topic page which has to be added to if there is a new language version. The benefit is that the page title is more intuitive. Longbow4u 11:22, 30 August 2008 (UTC)

Better use redirect-pages if a localized name is needed. I.e. de:Karteneigenschaften --> de:Map_Features. If you do not know any English it will be very hard to use OSM anyways! --Phobie 18:52, 18 December 2008 (UTC)

ToDo

Test, Newarticletext, Bot, NS, lang- ersetzen/löschen.

simplify the language template

  • remove text "Other languages"
  • remove text "Missing languages:"
  • always show all languages (you can see which languages are missing because the links are red)

--Phobie 03:56, 5 January 2009 (UTC)

Well I quite like the way it's hiding the red links, but it does need simplifying or rearrange to use less vertical space. 'Other languages' could appear to the left of the language list, and we could have a 'show missing languages' link on the right. That way it would all fit on one line.
I might have a play around with this at some point, but need to be careful not to break it. -- Harry Wood 10:11, 7 April 2009 (UTC)
I also think that we should remove the "Missing languages:" bar but keep the "Other languages". A link to the missing translation page is only interresting once for translators who can anyway find out the right page name. -- Pieren 10:49, 4 May 2009 (UTC)
I dont like the gray "missing-languages"-bar. I would prefer:
Title-bar: "Available languages" plus smaller: "Help" and "Missing languages"
Box: with all the available languages. --Markus 19:07, 4 May 2009 (UTC)
My suggestion does not work, because the PullDown does only work with content enclosed directly under the title bar.
May be we delete the gray "missing languages", put the link "show missing languages" in the first gray "languages"?
and somebody writes a tool which opens an other window with the missing languages? --Markus 15:39, 7 June 2009 (UTC)

I do not care about the design. My proposal is about speed. You should have a look at wikipedia:Wikipedia:Template_limits#Expensive_parser_function_calls Category:Pages_with_too_many_expensive_parser_function_calls! The "#switch" and the "#ifexist" functions costs much time. The solution is to always show all languages or to use a bot which runs once a day! --Phobie 15:29, 19 June 2009 (UTC)

I agree that Phobie said first. The numbers of "#switch", "#if" and "#ifexist" become over 100 which is the maximum limit of parser function. So a part of "Missing languages:" box don't work correct now. I tried to reduct the number of conditions however it seems to reach a limit. By simply just deleting "Missing", the count become the half. I don't agree with using bot. Bots are going to make too many Template:language-xxx like before using this template, right? I didn't like the way. --Nazotoko 20:05, 19 June 2009 (UTC)
No, a bot does not need many templates. It could extend Template:Languages. After a first full-page-run it only needs to run on page creation. Just removing "Missing languages:" is not a good solution! While we get below the 100-limit the template would be still time-consuming. --Phobie 23:45, 19 June 2009 (UTC)
It looks worse idea than many templates. Do you really think that scripting such a long script like Template:Language-mp on top of each pages are useful? Although they can save processing time, they consume much data storage and editors' concentrations. I think checking page existences are not hard for Mediawiki, because it always checks existences for each links. The count limit is set for a security reason to prevent from endless loops. So Wikipedia just increased the limit to 500 for heavy templates. Even if checking cost are small, we meet the fact that the Missing Box doesn't work now. Increasing the limit to 500 by an administrator is the easiest solution, I think. --Nazotoko 03:19, 20 June 2009 (UTC)
The Languages template at mediawiki.org manges without #ifexist. --Wynndale 15:52, 20 June 2009 (UTC)
You are right. If we give up to separate the "Missing Languages", we don't need to use #ifexist and bots. --Nazotoko 07:22, 21 June 2009 (UTC)

The missing languages box works again, because the count of #ifexist are reduced to 83. I have made another template which has the same format but a half number of #ifexist. The count become 42, so we get capacity for another 58 languages. The processing time was reduced from 1.2 seconds to 0.8 seconds. Accuracy 0.8 seconds is long for server. For example, a heavy page Map Features takes just 0.4 seconds to generate the whole page. However, it is not so long to damage server's CPU and it is short time for people. --Nazotoko 07:22, 21 June 2009 (UTC)

I applied the new template to this. Because the links in the template was changed, mediawiki server updates its connection database at the first template call. It takes very long time but from 2nd call, the processing time becomes less than 1 second. --Nazotoko 05:48, 22 June 2009 (UTC)

EdLoach, revert the template. Your template is not simple. your template use 89 #ifexist, 2 #switch and it is hard to understand where we should write a script for a new language. And it consuming 1.2 seconds for each page. You can get those information from the html source. This templates is one of the most linked templates. Take care for the processing time. I think what you want to do is just adding translations of the messages but I deny it for the reason on "Talk:Wiki Translation#Translating messages in Template:Languages?". --Nazotoko 23:16, 28 June 2009 (UTC)

OK - I hadn't spotted this talk section before, and had tried emailing you about your changes before I made any but you don't seem to have an email address linked to your wiki account. I am fairly new at wiki editing, so reading the above about the number of parser functions now makes a bit more sense about your previous changes. The problem as I saw it with the version I overwrote was the difficulty in adding new languages - when you added Esperanto the other day to the English interface I then added it to the Fi and De interfaces; if it gets to the stage where we have an interface per language then adding support for a new one becomes a fairly time-consuming task. I was trying to make this so that the template would only use one list of languages, so adding say {{{eoe|}}} and {{{eom|}}} could be done in one place. I realise now that the way I've done it has doubled the number of ifexist calls, so will revert it as you suggest. But if there is some way that the interface can be simplified so adding a language can be done without the need for modifying every interface template that would be an improvement. --EdLoach 07:43, 29 June 2009 (UTC)
I didn't notice my email access of the wiki was closed. I opened it. By the way, discussions about common things should be opened for all. You should use my talk page instead of emails. Template of Mediawiki is a dull program language. The grammar don't allow templates and parser functions to make new {{anotherTemplateCalling}} nor {{{parameterSubstitution}}} because it is technically too complicated and danger to cause a stack memory flow. Although it looks stupid, we should write {{{are|}}} {{{bge|}}} ... {{{zh-twe|}}} in each Interfaces. To reduce the number of #ifexist, I use a little advanced technique, variable parameters. Template:LanguageExisting selects the parameter name from 'xxe' or 'xxm' by the existence, so the interface templates are assumed to have a pair of 'xxe' and 'xxm'. You cannot separate the pair from interfaces. The Template:Languages/Interface is required to work this technique. The interface selector (2nd parameter) is just a extra function. I assume it to be used for more big redesigning than message translations, for example showing them in table, side-bar or itemizing. However, the default interface must be simple because of the problem about processing time. --Nazotoko 21:35, 29 June 2009 (UTC)

There was bunch of changes made by User:Verdy p yesterday which seem to relate to performance of this template. Not sure what's going on here, but I notice that all pages are now reporting the 'too many expensive parser functions' message. -- Harry Wood 15:23, 4 January 2012 (UTC)

Bot

It would be fine to run a bot, implementing the template in all pages... --Markus 19:07, 4 May 2009 (UTC)

Parameters

Who understand the usage of the two parameters? and can explain it in the Doku? Thanks, --Markus 15:39, 7 June 2009 (UTC)

Language addition

Can anyone add "Simplified Chinese", "Traditional Chinese" and "zh-hk" parameters for "简体中文", "繁體中文" and "中文(香港)"? I noticed that some of the articles in this wiki are in the above namespaces, and is inconvenient to change the names. AdeKaka' 09:56, 13 June 2009 (UTC)

I think "Simplified Chinese" and "Traditional Chinese" are too long for namespaces. I counted the pages which have the namespace "Simplified Chinese" or "Traditional Chinese". They are just 9 and 12. So I recommend to move them to "zh-hans" and "zh-hant". --Nazotoko 20:05, 19 June 2009 (UTC)

Template:Languages embedded in Template:ValueDescription

While I think this is a good idea, I noticed that because it is embedded as {{Languages|1=Tag:{{{key}}}={{{value}}}}} the Proposed Features pages which also sometimes use the template don't (and can't) use this for translations of proposals.

I was wondering whether perhaps the best solution to this was to have a Template:ValueDescriptionPF which had the template embedded as {{Languages|{{PAGENAME}}}} or similar?

Of course we then may also need translations of that template as there are for ValueDescription.

--EdLoach 10:26, 30 June 2009 (UTC)

I am not sure what did you want to discus. Do you want to make translations of the proposals? If you want to, discussing on Template:Proposed feature is better. But I think nobody wants to make them. They are temporary articles like news and discussions. Most of people think those should be in English. Did you read DE:Proposed_features (Google Translate Logo.png translate) ? It says "The proposals are regularly written in English in order to make everybody to understand.." in "Wie also vorgehen?". If you want to use this template for pages named "Prefix:lang/suffix", you need to extend templates from Template:LanguageExisting and Template:LanguageLink. But you should not apply them to this Template:Languages, because it must increase the processing time. Make it as another template. Statistics of the wiki tells me that 1 view request is in 3.6 seconds. It means if the average processing time for each pages exceeded 3.6 seconds, the sever could not answer for all requests, and it would be down everyday. Do you understand how serious we are for the processing time? --Nazotoko 01:38, 2 July 2009 (UTC)

Category "Pages with language links"

Why does this category exist? Imo, no reader of the wiki will look for pages with language links, so the category unnecessarily clutters category lists. Especially so as the What links here tool can tell you where this template is being used as well, without any categories. --Tordanik 15:27, 16 July 2009 (UTC)

Yes, remove the cat. and add your link to the proposal description! --Phobie 03:52, 18 July 2009 (UTC)
"proposal description"? Do you mean the template description? If yes, isn't the link in the "toolbox" on the left enough? --Tordanik 13:26, 18 July 2009 (UTC)
Yes, sorry, it was too late... --Phobie 02:50, 19 July 2009 (UTC)
I don't think this category is needed either, but note that there are other templates using this category, for example Template:Languages. --Nazotoko 16:51, 18 July 2009 (UTC)

This category is useful for translators. Keep it! --Lulu-Ann 09:41, 31 July 2009 (UTC)

Please state a concrete use case for something that is possible with this category and not with a "What links here"-check. --Tordanik 12:57, 31 July 2009 (UTC)
A translator is a person able and willing to translate, in this case wiki pages. Looking for new tasks, he/she will work on the pages listed in this category. I would even propose to have a category for each language missing and already translated, so translators can have a look at their languages only while non English understanding users can find pages in their languages.

--Lulu-Ann 10:23, 3 August 2009 (UTC)

Your use-case fails the "and not with a 'What links here'-check" part. It's a non-issue anyway, because we have so many pages without translations that looking for new tasks requires nothing but Special:Random or simply using the wiki for a while (which has the advantage of letting you find out what pages are actually worth translating).
And I have yet to see users without a knowledge of English that come along saying "hey, I want to find a page in my language, I don't care about the content", rather than "I want to find a page in my language about X". The latter is perfectly possible using the wiki search (you can select namespaces there) and does not require categories at all. --Tordanik 13:45, 3 August 2009 (UTC)
I have added Macedonian to the template now the main page uses it, and have taken the opportunity to remove the category at the same time so that there’s only one regeneration.--Wynndale 16:44, 2 September 2009 (UTC)

Language Addition: Amharic

Hi!

how is the process of adding a language? I added "am" already to the template - when will it appear in the list of (missing) languages for a page? Can anybody check/fix this? Thanks! --Alexm 16:17, 10 October 2009 (UTC)

I am sorry to answer it late. I have added your language, Amharic. You were needed to edit Template:Languages/Interface, too. --Nazotoko 19:26, 11 November 2009 (UTC)

Languages and politics

User:Thehada recently translated the Potlatch primer into Serbo-Croat but unfortunately saw fit to put it into the “BS” namespace on its own. This kind of action may, for instance, discourage other Serbo-Croat speakers from keeping it up-to-date, which would leave out-of-date information where new users will see it. I have therefore removed the “BS” namespace from the template and asked for the page to be put in the same namespace as the other Roman Serbo-Croat pages. Andrew 20:09, 14 February 2010 (UTC)

As I've commented on User_talk:Wynndale, please stop this madness. Croatian and Bosnian and Serbian are three different languages. The so-called "Serbo-Croat" Yugoslav standard for group of languages ceased to exist 20 years ago with the bunch of intra-Yugoslavian wars. (see wikipedia:Serbo-Croatian for example). Note that current standard ISO3166-1 and ISO639-1 defines only "HR" for Croatian, "SR" for Serbian, and "BS" for Bosnian. There is no such thing defined as "SH" for Serbo-Croatian.
Additionally, starting such enormous actions (as renaming namespaces!) without even trying to contact interested parties (for example http://lists.openstreetmap.org/listinfo/talk-hr lists for Hr: namespace) is very bad thing to do, even if you are sure it is such a bright idea (which it is not). Yeah; average Croat might understand over 70% of Serbian language out of the box (but only if rewritten in Latin script instead of Cyrillic, as Serbian is usually written), but so might average Swede understand the Norwegian, and nobody is pushing "Swedish-Norwegian" language. Add to that the political tensions (ex-Yugoslavian countries were in open war not that long ago, killing each other for years over exactly such issues !), and you'll see it is hardly a smart move, especially if you pull it without consulting with interested parties. I've undone most of the damage done today to Hr: namespace, but please revert the other stuff you've damaged without consulting with interested parties. Thanks. --mnalis 18:21, 28 February 2010 (UTC)
Croatian, Bosnian and Serbian are very similar dialects (like Bavarian and Low Saxon). So for linguistic reasons it is a good idea to join them into one namespace here (like we have only en and not en-gb and en-us).
ISO 639 defines Serbo-Croatian as macrolanguage with the code hbs the old code sh has been deprecated, but it is still a good code because off sh.wikipedia.org!
The average Croat might understand over 99% of Serbian language out of the box.
Swedish and Norwegian are much more different then Serbo-Croatian languages! See wikipedia:North Germanic languages! Serbian to Croatian is more like Bokmål to Nynorsk.
The central government made war against splitting regions (and lost). Differences in the dialects where not involved into the conflicts! Later they have been used as delimitation for political reasons.
Perhaps you should read wikipedia:Shtokavian dialect.
--phobie m d 13:32, 23 July 2012 (BST)
no, Croatian/Bosnian/Serbian are not dialects, nothing like that (the rfc5646 for example mentions macrolanguage similarities - they are programmer thingy to make translations easier, and not implications that the language is the same and need not be translated). They are separate languages. You have several dialects of Croatian (and then several accents - and those are not accents in the simple English meaning), and a thing called "Standard Croatian" which is what is used in HR: namespace in order for it to be completely intelligible to all Croats. The linguistic issue is extremely complex here, even for native people who spent decades on the subject, so please do not presume that few hours of web surfing might give you even the passable idea of the problem. I will not go here into deep discussions over the language here (nor do I think it is possible - it would take extreme amounts of time and effort to explain, much more than I'm likely to write even over few months of dedicated work, and probably much more than you're likely to read), I will only reiterate that there are extremely strong feelings and political tensions over the language issue (and yes, Croatia for example did get in the war in considerable part over being denied official use of their language and identity).
So again, please, follow the BCP and be absolutely sure to reach the consensus in *all three* "sides" (on respective mailing lists, and not somewhere where almost nobody is following the discussion) before attempting any kind of massive namespace renaming, no matter how good the thing you think you're doing. Doing otherwise is only likely to provoke edit wars, high tensions and many lost hours of everybody work which might have been much better used to improve OSM. Thanks. --mnalis 11:38, 2 August 2012 (BST)

Haitian Creole

I have added this language to support the OSM translation project at Crisis Commons. [1] Andrew 20:09, 14 February 2010 (UTC)

Broken for no further languages

Hi, as some might already noticed, the template became broken due to the very last edits of user:Verdy p. Is anybody able to fix it, please? --!i! This user is member of the wiki team of OSM 09:36, 18 January 2012 (UTC)

This template doesn't work in category namespace?

Resolved

I tried to replace {{Language-Howto_Map_A}} with {{Languages}} at http://wiki.openstreetmap.org/wiki/Category:Features without any success.

It links to Features, RU:Features (article pages) instead of Category:Features, Category:RU:Features

Can anybody fix it to work with Category: namespace? Thank you! Xxzme (talk) 11:17, 22 July 2014 (UTC)

I tried to add this language bar in Category:Out of date and also wasn't able to (I came here to report this issue).
I added {{Languages|ns=:Category:|Out of date}} and had a partial success, where the English category was correctly linked, the language of the current category was correctly identified, but categories in other languages had a line-break that broke the link. I assume the problem is related to the colon (:) prefix used to link to each category without categorizing the page.
--Jgpacker (talk) 15:03, 30 October 2014 (UTC)
I took a deeper look and was able to isolate the problem. It happens when using Template:LanguageLink with a namespace parameter (ns) that starts with a colon (in this case :Category:). It is related to an old bug in MediaWiki. Since I'm not an expert in MediaWiki templates, I'm asking for help on StackOverflow. --Jgpacker (talk) 16:19, 30 October 2014 (UTC)
Ok, I just made a "quick" change to Template:LanguageLink and Template:LanguageLinkEn and was able to make it work now! Use {{Languages|ns=Category:|Out of date}} without a colon as a prefix (changing "Out of date" to the name of the category in english). --Jgpacker (talk) 19:48, 30 October 2014 (UTC)

Many missing languages

  • BS (minor; wrong, use "Bs:"; template name used the incorrect prefix and has been fixed)
  • ES (template updated)
  • Ge (wrong, use "Ka:")
  • HR (minor; wrong, use "Hr:")
  • Sq (also minor; template name used the incorrect prefix and has been fixed)
  • Zh-tw (no supported as wanted: use "Zh-hant:" instead for Traditional Mandarin; in fact "zh-tw" designates several languages, including Traditional Mandarin, Min Nan...)

Unsupported by templates? But why? Xxzme (talk) 13:09, 10 November 2014 (UTC)

Some templates have different capitalisation from what this template expects to generate links to them, which doesn’t affect their use as templates. Zh-hant is preferred to Zh-tw.--Andrew (talk) 13:24, 10 November 2014 (UTC)
Only 7 language codes are fully capitalized for historic reasons (those that have dedicated namespaces in this wiki: DE, ES, FR, IT, JA, NL, RU; no more will be added, but if this ever occurs, they will not be fully capitalized), all others are lowercased (but the initial only is implicitly capitalized in page titles). — Verdy_p (talk) 03:12, 29 April 2016 (UTC)
Works for me: Sq, ES,
HR, BS also work, however they are minor languages, so due to technical limitations you have to click the "show" link to see them, even if they exist.
It seems Zh-tw isn't widely accepted (see [#Language_addition])
Ge isn't present. I think we could add it as a minor language. Do you know which language is that?
--Jgpacker (talk) 14:19, 10 November 2014 (UTC)
I have no clue about Ge. For some reason it is used in Ka: namespace. I asked question at talk page here: Talk:Ka:Map_Features#Ka vs Ge? Xxzme (talk) 14:52, 10 November 2014 (UTC)
I may be wrong, but it seems it is the Georgian language. There is ka.wikipedia.org, but there isn't a ge.wikipedia.org, so I think KA is the correct language code, and Ge shouldn't be added here. --Jgpacker (talk) 15:22, 10 November 2014 (UTC)
Do we use language code or country code? If language code then, ISO 639-1 is ka but SO 639-2 is geo AND kat... No clear choice for me. Xxzme (talk) 16:11, 10 November 2014 (UTC)
We don't use country codes anywhere for namespace-like prefixes, but only language codes
Country codes may be used for country-specific articles but not in the namespace-like prefix.
Preferably those countries should better be represented by their name...
... except in some OSM keys using country codes, e.g. "Key:FR:school" for schools in France, described in English; these articles will translatable in any language with a prefix (e.g. the article about schools in France is translatable to French as "FR:Key:FR:school" German as "DE:Key:FR:shool"). In such case those country codes prefixing some OSM keys should be fully capitalized, but language codes used for suffixing OSM keys such as "name" should be fully lowercased. — Verdy_p (talk) 03:25, 29 April 2016 (UTC)
The Georgian Map Features was originally created at GE:Map Features with a hand-crafted link from the old {{Language-Map Features}} template. When we changed to using the {{Languages}} template everywhere I moved the Map Features page but not the templates that it uses. The templates aren’t really any use as they are just untranslated snapshots of the English pages at the time it was created. Like Wikipedia we use the two-letter code when there is one.--Andrew (talk) 17:40, 10 November 2014 (UTC)
That page was moved to Ka:Map Features. Note that this wiki documents features in languages independantly of the country where they are used. If a feature is specific to a country, the tags used should use a capitalized country prefix, but the articles about these tags will not use it in the first namespace-like prefix, but always after "Key:" or "Tag:", so there's no possible confusion and these articles remain translatable to more languages. — Verdy_p (talk) 03:25, 29 April 2016 (UTC)

Template doesn't work at El:FAQ

No idea why. Xxzme (talk) 10:54, 2 May 2015 (UTC)

Fixed. --Jgpacker (talk) 20:28, 2 May 2015 (UTC)

Note: "This Template is used on a lot of pages." should be in source code.

The Note: "This Template is used on a lot of pages. ...." should be a part of the templates source code. When clicking somewhere EDIT nobody reads it on this talk page. Please delete this after copying the notice in. --Hb 09:59, 20 May 2015 (UTC)

Proposed rewrite

I have been rewriting this template) fix problems in what we have now. There is a fuller description at User:Wynndale/language test.

  1. The bar makes extensive use of the #ifexist parser function, which is expensive in Mediawiki and limited in the number of times it can be called. Most of the pages in Category:Pages with too many expensive parser function calls are at least exacerbated by the presence of a language bar.
  2. To mitigate the issue above, minority languages are hardcoded into the hidden lower box even when translations exist. Up to now, the only response available for criticism of the banishment [2] has been to adjust the choice of languages tested for display at the top.
  3. The red links are hidden by a script that is only executed when the page has loaded. This is a particular nuisance on mobile devices where it can take up most of the screen.
  4. The list of languages is spread over three locations with an intricate syntax and different ways of entering them depending on the size of their presence in OSM.

Instead of splitting links into upper and lower bars, every link goes together in one sequence, with red links hidden by CSS. A link has been added to “Other languages” (more discoverable than a “show” link) to unhide the links.

I’m interested to know whether you think this is a good idea and how it can be improved. You are welcome to improve it yourselves under less pressure than editing a live template.--Andrew (talk) 08:50, 7 June 2015 (UTC)

Your rewrite seems very sensible and does seem to have drawbacks, so very broad community approval should not be necessary (perhaps post on forum?). One question: Are there any plans to unite the "real" and "virtual" namespaces? What would be the gains, what work would it be?--Jojo4u (talk) 17:36, 20 August 2015 (UTC)

New language template

There is a development version of this template at User:Wynndale/Languages and some pages have been adjusted to use it.

The rewrite is intended not to fill Category:Pages with too many expensive parser function calls, not to permanently hide minority languages out of sight, to hide red links immediately and to be easier to add extra languages and to add the template to a page.

Longer explanation (discuss).

This soft launch is an opportunity to revise the template without as much pressure as working on the live version, however please discuss any major changes.

--Andrew (talk) 10:34, 29 February 2016 (UTC)

New template going live

The new version of the template is now live. It is designed for several objectives including long term maintainability. Please discuss any changes first. There are a number of opportunites for subsequent cleanup, the first is to reindex unreindexed pages, especially ones outside the main namespace, by null edits.--Andrew (talk) 19:24, 21 September 2016 (UTC)

I fixed (again) the LanguageLink tempalte that was again broken (by you), notably it did no longer handle the template namespace (and possibly others). You wanted to simplify it too much;
Now you pretend I'm bullying it, but all this was signaled here since long, and you persist in ignoring the issues, notably in significant spaces, and I don't understnad why you want excessive indentation which is also incorrect in various places, and so does not really help editors, and certainly does not help the server as well (notably if this template is widely used, it should be compacted, we have on this wiki very large pages and ther's no need to add unnecessary junk spaces or newlines , except the minimum (only standard indentation, privided it is done in really safe locations, where they are not significant).
Everywhere we keep just the minimum needed (even for long term: what is necessary is only to have coherent indentation where braces and vbars line up correctly).
You affirmed in your comment that I don't understand the wiki, that's plain false, in fact since long this template was maintained by me before you started to propose something else (but broke it repeatedly in your tests, ignoring all my signaled errors). I've also taken thje performance considerations, and also preserved the compatibility to allow conversion, but you reverted multiple times these needed tweaks. And you don't test things properly unlike what I do (and I commented each one). It's difficult to progress when you constantly ignore every corrections, even when they are signaled and justified (not in my "imagination"). — Verdy_p (talk) 08:55, 22 September 2016 (UTC)
Visibly you have a strange idea of what "maintainability means". It does not mean breaking functionalities and not caring at all about them. You are abusing by not listening any one even when problems were demosntrated and discussed repeatedly. — Verdy_p (talk) 16:37, 22 September 2016 (UTC)

Italian translation

I'm trying to improve the Italian translation. The Category:Pages unavailable in Italian would be a useful tool, but I don't want to overload the server: I've seen this edit war between Verdy_p and Wynndale.
Are there any alternatives to make a list of pages not translated in Italian? My main purpose is to translate the most used tag/key documentation pages. --NonnEmilia (talk) 14:28, 22 March 2017 (UTC)

Those that request it can have it. It has been disabled in some languages, but it can be enabled in Italian if you wish. Just follow the model... — Verdy_p (talk) 14:43, 22 March 2017 (UTC)
I've seen that you already enable it. Thanks. --NonnEmilia (talk) 15:52, 22 March 2017 (UTC)
I did it on request, and the comment is clearly refering to this discussion. — Verdy_p (talk) 18:13, 22 March 2017 (UTC)

Wrong categorisations for missing translations

It looks to me as if the current version of the template also assigns some German pages to Category:Pages unavailable in German. One example would be DE:Feuerwehren in Österreich. A more complicated one is Template:Relation/doc. How can we fix that? --Tigerfell This user is member of the wiki team of OSM (Let's talk) 00:11, 30 October 2018 (UTC)

The first line of the page is {{Languages|Fire stations in Austria}}, which expects a redirect to the German page from DE:Fire stations in Austria. The red link is masked by logic in the template that makes the current language a bold non-link even when the name is different, not relying on Mediawiki. The page may not really need to be maintained in any language other than German and the template is then pointless and can be removed, or you could add a redirect. Perhaps we can get rid of this issue if we move to Wikibase.--Andrew (talk) 09:13, 30 October 2018 (UTC)

Ups, this error was so obvious that I did not see it. But how about Template:Relation/doc? This is an English page and the German page is located at Template:De:Relation/doc. I translated this page yesterday and the German page name was suggested by the template. --Tigerfell This user is member of the wiki team of OSM (Let's talk) 10:06, 30 October 2018 (UTC)

I think I know what is happening but this needs more discussion of what the preferred fix is.--Andrew (talk) 13:24, 2 November 2018 (UTC)
Languages with namespaces known to our Mediawiki installation appear as block capitals (DE:) but can be accessed in lowercase (De: or de:) like other language prefixes. Language prefixes in any other namespace are never known to Mediawiki and have no alternative capitalisations apart from the first letter. Verdy p, who is now permanently blocked from editing here, created large numbers of language-specific categories with capitalised prefixes; as a result, when I rewrote the template to hide red links with CSS instead of #ifexist I special cased categories (only) to have capitalised links. There is no technical reason apart from compatibility with existing page titles to have capitalised links'. Because people were working round breakage to the default linkage from Map Features templates in some languages by reinstating the ns= parameter I rolled everything back to the version I had originally committed, which ignored most of the unsolicited edits Verdy p had made in my namespace but left the capitalised check for missing translations. So, the solution for the remaining loose ends depends on the preferred capitalisation of page titles.--Andrew (talk) 19:24, 12 November 2018 (UTC)

How should I solve this problem? There are templates in Spanish (Template:ES:Template_name) which are not recognized by the languages template. If you try to create the Spanish translation again using the language template, you create a new page with the prefix "Es" (Template:Es:Template_name), duplicating the translation. I am creating the pages using the languages template and redirecting them to the existing Spanish translations (Template:ES:Template_name). I do not know if this solution is the right thing (it is cumbersome). Before it worked correctly. --Daniel Capilla (talk) 15:23, 29 January 2019 (UTC)

We need to decide on preferred capitalisation for templates.--Andrew (talk) 16:51, 30 January 2019 (UTC)
Moving all the existing pages in Spanish from "ES:" to "Es:" will take time, including pages, templates and categories. When will it be decided? The names of pages in Spanish are using the capitalization "ES" by default when they are created using the languages template. Also the categories (Category:ES:). I only found the problem with the namespace "Template". The templates already translated (Template:ES:) are not recognized by the languages template. --Daniel Capilla (talk) 19:56, 30 January 2019 (UTC)

Would it be possible to create new pages with the standard capitalisation Template:Aa:Template_name for all languages and change the language bar to check for traditional capitalisation first or is this to costly with regards to expensive parser functions? --Tigerfell This user is member of the wiki team of OSM (Let's talk) 19:09, 30 January 2019 (UTC)

It would be a good solution. It would solve the current problem and give us time to make the necessary changes if it is decided to change from "ES" to "Es", for example. The links would continue to work correctly in the meantime. --Daniel Capilla (talk) 19:56, 30 January 2019 (UTC)

Lua rewrite

I've been eyeing this template for a rewrite in Lua ever since Scribunto was installed here last year. I finally got around to it: a new template is available at Template:Languages/sandbox, though the template itself is uninteresting compared to Module:Languages, which powers most of its functionality. The main benefits are better maintainability and faster performance. I'm proposing to cut over to the new version, which will affect almost all pages on this wiki.

In terms of maintainability:

  • The sea of curly braces is gone.
  • Administrators can add and remove languages at Module:Languages/config, which is hopefully intelligible to nonprogrammers. The module has a convenience function for automatically sorting the languages by name.
  • Module:Languages/testcases contains a number of unit tests to ensure that the page title–related functions in Module:Languages correctly handle cases that have broken in the past. (Purge Module talk:Languages/testcases to rerun the tests.)

The new version comes with some fit-and-finish improvements as well:

  • The module is flexible with regard to missing translation detection, accepting either Template:ES:… or Template:Es:…. This is the only reason it ever checks for page existence.
  • The template uses a {{Flatlist}} so that screenreader users can more easily skip over the language list without hearing "bullet" a bunch of times. This is important because the language bar almost always appears at the top of the page. As a bonus, the list looks a little cleaner to sighted users too.

As much as possible, I tried to retain features that are in use but discard features that are no longer used on this wiki:

  • The EN: special case is unsupported because I moved or deleted the last remaining pages using that prefix.
  • The namespace parameter is unsupported because I similarly removed every occurrence of that parameter from the content namespaces.
  • Of the 115 languages previously supported, 44 have been removed because only a few empty categories or redirects are nominally written in those languages, most of them created by a single user to justify listing the language in the language bar. If by some stroke of luck a community of Interlingue speakers gets involved with OSM, we can easily add to the language list.
  • Unlike {{Languagename}}, this template doesn't need to translate language names.
  • The documentation doesn't digress into the minutiae of obscure language codes.

The new version performs markedly better than the current one:

The performance improvements came from a number of places, but the general theme is that various things are only calculated once per page or once per template inclusion, compared to dozens or hundreds of times per template inclusion with the current template.

If I've inadvertently removed any feature that you depend on, please let me know. Chances are we can implement it much more efficiently in the new version. I'm continuing to investigate further performance improvements, such as gutting {{LangSwitch}} usage in favor of MediaWiki interface messages.

If all goes well, I'd like to replace Template:Languages with the new version sometime in the next week or so. At the same time, I'll apply cascading protection to the template, to prevent someone from overloading the job queue or spamming the entire wiki by modifying a single template. After that point, any requests for changes can be tagged with {{Edit request}} to get the attention of an administrator.

 – Minh Nguyễn 💬 10:27, 19 June 2019 (UTC)

@Tigerfell @Wynndale I'm particularly interested in your feedback, since you've both looked into the current system of templates and may know of edge cases I haven't considered. – Minh Nguyễn 💬 10:40, 19 June 2019 (UTC)
This looks promising. The process to ask to add another language to the template will need to be documented somewhere.
The present template orders pages without the language prefix (unless defaultsort=no is added), the project to tidy up explicit use of DEFAULTSORT using it was interfered with. Ideally this could work in other namespaces (but not language-specific namespaces) as well.
Are flatlists useful for navbox templates such as {{Traffic signs}}?
--Andrew (talk) 08:43, 20 June 2019 (UTC)
Thanks, I added instructions for modifying the language list. Once that module gets protected (due to its use in this template), clicking View source will reveal instructions for requesting an edit using {{Edit request}}. I missed the DEFAULTSORT: usage in {{Languages}}. I'll add that; it should be easy to make it work in other namespaces too. {{Flatlist}} is indeed useful for other navbox templates; feel free to update them to use it. – Minh Nguyễn 💬 16:18, 20 June 2019 (UTC)
{{Languages/sandbox}} now adds a DEFAULTSORT with the noreplace parameter, which turns it into a no-op if a DEFAULTSORT already appears somewhere earlier on the page. Then again, it isn't uncommon to transclude {{Languages}} at the top of the page and specify a DEFAULTSORT at the bottom of the page. There's no problem if the two DEFAULTSORTs specify the same sort key. However, if the keys differ, then MediaWiki displays an error. DEFAULTSORT takes a noerror parameter that suppresses this error. This template also supports |defaultsort = no, but it should be unnecessary given the noerror option. – Minh Nguyễn 💬 05:52, 21 June 2019 (UTC)
Take care to avoid feature creep. --Andrew (talk) 12:21, 21 June 2019 (UTC)
Not to worry, I don’t intend to add any more features to this already featureful template. It’s a best practice for any template that inserts a DEFAULTSORT to add either noerror or noreplace; otherwise, any DEFAULTSORT usage on the page itself throws an error. As I went through cleaning up deprecated |ns = usage, I saw about a dozen pages with DEFAULTSORT-related errors. This change doesn’t necessarily eliminate those errors but makes it possible to do so by editing those pages. – Minh Nguyễn 💬 16:30, 21 June 2019 (UTC)
Looks ready to go. Make sure to stand by just in case though. --Andrew (talk) 16:41, 21 June 2019 (UTC)
First of all, thanks for looking at this template. Some things I noted while looking at it (numbered for future reference):
  1. The performance figures indicate that the number of calls to Template:Calendar/event on Main Page has decreased by one. Might be a strange incident, but maybe you used wrong figures by accident?
  2. When previewing Fa:Wiki (RTL language) with the new language bar, I get the output {{DEFAULTSORT:Wiki|noreplace}} after the list of languages.
  3. (feature request) Could you remove the last bullet behind the last list element? That looks a bit strange to me.
  4. p.namespacedLanguageName() in Module:Languages looks like it duplicates mw.language.fetchLanguageName().
  5. Selection of languages: something is wrong with Serbian. Sr seems to be the current code, but it looks like you used Sr-latn which has fewer pages. In the past, not all language codes followed the standard because they did not have a code in the standard yet or there was some confusion, I guess, but this should be clarified. I have not checked the page content though.
  6. Please update the 7th column of Template:Wiki language table which documents if a language is available in the language bar after changing {{Language}}. Feel free to include the template in the doc. --Tigerfell This user is member of the wiki team of OSM (Let's talk) 22:55, 21 June 2019 (UTC)
Thank you for the detailed feedback.
  1. How observant of you! :^) The number of calls to {{Calendar/event}} and {{Event date}} increased by one because of this added event that came between the before and after. I'll rerun the numbers after all the changes to provide a more solid benchmark for future changes, but that should only result in marginal adjustments.
  2. This is expected. Apparently, the existing template adds {{DEFAULTSORT:Wiki}}. The noreplace parameter avoids errors when the page itself tries to set a default category sort key, as explained above.
  3. It does look strange. It's a downside of relying on CSS instead of JavaScript or Lua to hide redlinks. The existing template has a leading interpunct instead. This stylesheet change hides the trailing interpunct as long as the box is expanded, but I'll experiment with some JavaScript hacks to hide the trailing interpunct when it's collapsed.
  4. config.namespacedLanguageNames is specifically the English-language names of the eight languages that have their own namespaces and thus get the special "Category:Pages unavailable in" treatment. We could fetch these names from mw.language.fetchLanguageName(), but the table needs to be based on category names, not MediaWiki's names of languages. So if we decide to rename Category:Pages unavailable in Spanish for some reason, this table needs to be updated. I changed Module:Languages/config to store the category names, which is hopefully less confusing. It does already use mw.language.fetchLanguageName() for the actual link labels.
  5. Thanks, not sure how I missed that there are actual content pages in sr:, but it's fixed now. Note that sr: sorts with the Cyrillic-script languages, not next to sr-latn:. I'll double-check the rest of the languages I removed. I started out by checking the list of exceptions in Template:Languagename/doc, but only a couple of them require special cases in Module:Languages/config.
  6. I haven't deleted any languages from the wiki, just unnecessary links from the template. In the past, we've apparently called that "deprecating" a language. The table still lists deprecated locales like Brazilian Portuguese. Should it reflect all the languages available on the wiki, even nominally, or should it track {{Languages}} specifically?
 – Minh Nguyễn 💬 00:05, 22 June 2019 (UTC)
Regarding 2: Not sure if we talked about the same issue. I meant to say that one can see the text {{DEFAULTSORT...}} on the page.
Regarding 3: It was just an idea. Better having a managable template than an exceptionally pretty one.
Regarding 6: The column major (tested) documents which languages are included in {{Language}}. This is the sole purpose of the column. Even the current language template does not include all languages. If I remember it correctly, "deprecating" a language code referred to the act of moving the content to a different prefix and updating all documentation. The table lists those languages as well, so everyone can see the current prefix in column 3. The table is supposed to list all languages ever used in this wiki and their current prefixes to establish consistancy. --Tigerfell This user is member of the wiki team of OSM (Let's talk) 15:21, 22 June 2019 (UTC)
Huh wow, the DEFAULTSORT code appeared when previewing a modified Fa:Wiki, but not when entering Fa:Wiki and {{Languages/sandbox}} into Special:ExpandTemplates as I had been doing. I guess ExpandTemplates evaluates the wikitext an extra time, which would be a MediaWiki bug. In any case, this change should fix the issue. – Minh Nguyễn 💬 23:30, 23 June 2019 (UTC)
Wiki Translation is daunting. I'm not sure a user who needs guidance on how to use a redlink – especially a non-native English speaker – would be comfortable translating an article after reading the walls of text that follow in "Language prefixes and namespaces". I suspect very little of the section is actually needed for translating into a new language. We should move inessential details elsewhere or remove them.
As a first step, I've rewritten the template as {{Wiki language table/sandbox}} using a module that automatically synchronizes with Module:Languages/config. Now it indicates three statuses: "listed" languages that are listed in the language bar, "unlisted" languages that are in use but not listed in the language bar, and "deprecated" languages that we've stopped using. A key to these statuses will need to be added to Wiki Translation. The rest of the language codes are omitted from the table; Wiki Translation already has a link to the full BCP 47 standard to look up additional languages. The eight namespaced languages are in bold, but this is a detail that translators shouldn't have to worry much about. Due to a limitation in Scribunto, it isn't possible to generate the right-to-left column automatically, but a translator should already know whether their language is written right-to-left. Translations of Wiki Translation will have to retranslate the template by passing parameters into {{Wiki language table/sandbox}}. There's no reason to centralize translated phrases using {{LangSwitch}} and {{Langcode}}, because the template is only included in a single page and its translations.
 – Minh Nguyễn 💬 23:30, 23 June 2019 (UTC)
Wiki Translation was written by many users and iteratively changed over time. I agree that it is lengthy. Even though I actually read parts of the page before my first translations, I never read the whole page and I could imagine that there is content duplication. After doing some template work on the weekend, I actually found DE:Wiki Translation which contains information about maps in the wiki and images from Commons vs. local files as well as information about which information belong to Wikipedia and which belong here, but that is completely unrelated to translations. I guess it is time for a clean-up. The whole point of Template:Wiki language table was avoiding diverging information about prefixes in the translations. The new version looks not so messy as the old one. That is a good change, I appreciate it! I think RTL info is mostly obsolete since users can change the page language property, so they do not rely upon templates like {{Fa}} anymore. --Tigerfell This user is member of the wiki team of OSM (Let's talk) 22:35, 24 June 2019 (UTC)

I just discovered there's a way to hide parts of a page from the search engine. That's nice because currently the results for "language" and "english" are quite poor. This change hides the language bar from the search engine and also hides it from the printable version of each page, since links are of little use there. – Minh Nguyễn 💬 23:30, 23 June 2019 (UTC)

Great, I did not want to ask for that because there are tons of other features in the template already. I hope this also avoids the template's text showing up in the search results as surrounding text like then the search term matches the first word of the article right below the language bar. --Tigerfell This user is member of the wiki team of OSM (Let's talk) 22:35, 24 June 2019 (UTC)
Yes, this change also prevents the language links from appearing in search result snippets. – Minh Nguyễn 💬 02:05, 25 June 2019 (UTC)

As I mentioned above, I plan to cascade-protect {{Languages}} after deploying the rewrite at {{Languages/sandbox}}, causing any template it transcludes to also be protected from edits by non-administrators. While the wiki doesn't have as severe a history of vandalism and spam as other wikis, it's still important to protect this template as much as possible, because it appears almost everywhere, and even reverting a bad edit can overwhelm the job queue, preventing categories from updating promptly.

Protecting the templates does make it more difficult for translators to translate them into their own language. For this reason, I've replaced usage of {{Available languages}}, {{Missing languages}}, and {{Purge}} with MediaWiki:Mobile-frontend-languages-header-page, MediaWiki:Mobile-frontend-languages-structured-overlay-all-languages-header, MediaWiki:Allmessages-filter-translate, a hand-crafted MediaWiki:Osm-wiki-translation-url, and {{Purge/sandbox}} (to be moved in place at the same time). These interface messages are similarly restricted to only administrator edits, but language coverage should be better than under the old templates. The old templates were largely translated by a single non-native speaker who is now blocked from editing the wiki, so I have more confidence in the translations coming from MediaWiki. These changes also eliminate remaining usage of {{LangSwitch}} and {{Langcode}} from the template, further improving performance.

On the other hand, relying on interface messages also means that the templates are localized based on the interface language, not the current page's language. So DE:Hauptseite ends up saying "Translate" unless you customize the interface language to German in Special:Preferences, append uselang=de to the URL, or append setlang=de to any URL. If this is a problem, I can add a line of code to MediaWiki:Common.js and MediaWiki:Mobile.js that appends uselang= to every link in the language bar.

 – Minh Nguyễn 💬 01:17, 24 June 2019 (UTC)

I guess no one really minds if you use cascading protection, but good-faith editors also need an administrator to change them. IMHO there were some situations where admins were needed and none of them was available. This is one reason why there are so few protected pages.
Regarding the language switch: I guess this technique would be especially interesting for file and licensing templates. --Tigerfell This user is member of the wiki team of OSM (Let's talk) 22:35, 24 June 2019 (UTC)
Commons uses interface messages extensively in things like common headers, though the licensing templates themselves use the w:Commons:Template:Autotranslate system, which relies on w:Commons:Template:LangSwitch. It's no coincidence that we wound up with a similarly named {{LangSwitch}}, though the Commons version has since been modernized so that w:Commons:Module:LangSwitch uses mw.language.getFallbacksFor() instead of a large switch statement. But more importantly, Commons structures localized templates quite differently than we do: for instance, for w:Commons:Template:PD-textlogo, w:Commons:Template:PD-generic/layout defines the layout common to all languages, and translations are kept separate at templates like w:Commons:Template:PD-textlogo/en. This ensures that only one set of translations is ever evaluated for a given page in a given locale. In short, {{Languages}} is just the tip of the iceberg. :^) – Minh Nguyễn 💬 02:05, 25 June 2019 (UTC)
I would be inclined to prefer Wikidata’s version of LangSwitch, which the Metawiki also uses, as cleaner and more tightly integrated with the underlying fallback system. --Andrew (talk) 06:25, 25 June 2019 (UTC)
Maybe I'm missing something, but d:Module:LangSwitch looks identical to w:Commons:Module:LangSwitch other than some differences in coding style. – Minh Nguyễn 💬 21:33, 25 June 2019 (UTC)
I am thinking more about Module::Fallback that powers it. --Andrew (talk) 06:51, 26 June 2019 (UTC)
d:Module:Fallback was copied from w:Commons:Module:Fallback before it was split up into w:Commons:Module:Autotranslate, w:Commons:Module:LangSwitch, and w:Commons:Module:Fallback. Looks like the two wikis have diverged a bit since then, including getting translations from item labels (which aren't available in a meaningful form on this wiki). It sure would be nice to put these core modules under source control, like some popular gadgets are, so we can keep better track of forks. – Minh Nguyễn 💬 01:34, 27 June 2019 (UTC)
Is TemplateData worthwhile? Deployment shouldn’t have to wait for it though. --Andrew (talk) 19:51, 26 June 2019 (UTC)
Template:Languages/sandbox/doc has template data, and I've added it to Template:Wiki language table/sandbox/doc as well. – Minh Nguyễn 💬 22:13, 26 June 2019 (UTC)
Your list of nominally present languages isn’t complete; there are more in languages I removed from the template in last October’s rollback. --Andrew (talk) 20:10, 26 June 2019 (UTC)
Thanks, I added all of them as minor languages except for Bihari (bh), which is unused, and Tagalog (tl), which turns out to just barely qualify for inclusion in the language bar. – Minh Nguyễn 💬 22:13, 26 June 2019 (UTC)

What is this waiting for before it can go live? --Andrew (talk) 08:38, 23 July 2019 (UTC)

Now live. --Andrew (talk) 08:36, 3 August 2019 (UTC)
@Wynndale There is some issue now that categories contain themselves as subcategories like in Category:ES:Páginas de documentación de plantilla. I could not really figure out the issue, but maybe it is related to the category issue I tried to fix in Special:Diff/1868211/1886359? The job queue seems to be quite long, too (> 630000 jobs). --Tigerfell This user is member of the wiki team of OSM (Let's talk) 19:07, 7 August 2019 (UTC)
@Wynndale Thanks for taking care of the upgrade. I had intended to do some more testing first (for instance on categories) but didn’t find the time for it. Tigerfell, if anything, I think your edit would fix that issue. We’ll see once the job queue subsides. – Minh Nguyễn 💬 04:19, 8 August 2019 (UTC)
@Tigerfell Looks like your fix did the trick, thanks! – Minh Nguyễn 💬 09:12, 8 August 2019 (UTC)

More specific categories

Both the current template and the proposed Lua version add pages to some of the subcategories of Category:Pages with missing translation – limited to just the ones corresponding to languages that have dedicated namespaces, for performance reasons. But even this approach is wasteful, populating the tracking categories with redundant pages. For example, if "Foo" is available in English, Italian, and Czech, three pages end up in Category:Pages unavailable in French, three end up in Category:Pages unavailable in German, etc. To deal with category bloat, pages are sorted by language code rather than page name.

I don't think this system serves translators well, because they have to sift through unlikely language pairs to find relevant pages awaiting translation. Meanwhile, the category system is of no use to anyone who wants to ensure translation coverage in a language that doesn't have a language namespace.

Instead, we could identify language pairs that are likely targets for translation. For example, if this wiki has enough users who are in both Category:User cs and Category:User it, then {{Languages}} could automatically add Italian pages to Category:Pages unavailable in Czech. In the example above, "Foo" would appear fewer times in Category:Pages unavailable in Czech. But if the category is still too unwieldy, we could get more specific, adding Italian pages to Category:Pages needing translation from Italian to Czech. Even this level of granularity wouldn't result in the sort of performance problems we saw when every page was being added to every language category.

 – Minh Nguyễn 💬 17:22, 19 June 2019 (UTC)

Or we could limit the categories to English pages when available, falling back to pages in other languages. That way each topic is represented only once in each “Pages unavailable in” category. Translators who need to translate from a language other than English could use the language bar in addition to the tracking category. – Minh Nguyễn 💬 20:59, 19 June 2019 (UTC)

I think we should discuss handling translation requests in general some time. Regarding EN <-> DE, we have numerous templates and categories like Category:Translate to German, Category:Translate from German, Category:DE:Unvollständige Übersetzungen, Category:DE:Translations out of sync...
From my POV, it would be adequate to categorise the English pages only to avoid clutter.
There are also categories for users mastering two languages like Category:Users hu en-3, but that depends on the Babel template you use (like me, I am not in Category:Users de en-3 because I use user boxes). Based on the number of users in the categories, I guess we can estimate some useful language pairs, but it might be better to ask users to request them to avoid useless categories. --Tigerfell This user is member of the wiki team of OSM (Let's talk) 21:18, 21 June 2019 (UTC)

Wrong categorisation for missing languages

Resolved: It was actually an untranslated wiki label triggering categorisation. --Tigerfell This user is member of the wiki team of OSM (Let's talk) 19:30, 14 August 2019 (UTC)

DE:Wiki organisation is included in Category:Pages unavailable in German. Looks like a capitalisation error. --Tigerfell This user is member of the wiki team of OSM (Let's talk) 19:11, 14 August 2019 (UTC)