Template talk:Lang links

Missing space and unnecessary template use

~~{{editprotected}}~~

Please replace:

                                                                  <!--
default -->{{#ifexist:{{{1|{{NAMESPACE}}:{{BASEPAGENAME}}}}}/en|
[[{{{1|{{NAMESPACE}}:{{BASEPAGENAME}}}}}/en{{!}}{{#language:en}}]]&nbsp;{{!}}|
[[{{{1|{{NAMESPACE}}:{{BASEPAGENAME}}}}}|{{#language:en}}]]&nbsp;&#124;&#32;}}
}}

with:

                                                                  {{
#ifexist:{{{1|{{NAMESPACE}}:{{BASEPAGENAME}}}}}/en|
[[{{{1|{{NAMESPACE}}:{{BASEPAGENAME}}}}}/en|{{#language:en}}]]&nbsp;&#124;&#32;|
[[{{{1|{{NAMESPACE}}:{{BASEPAGENAME}}}}}|{{#language:en}}]]&nbsp;&#124;&#32;}}
}}

To point out the important parts, here's the middle line again: [[{{{1|{{NAMESPACE}}:{{BASEPAGENAME}}}}}/en|{{#language:en}}]] | |

The red & green are the changes. The green is the missing space. Thanks. 71.155.242.65 09:45, 4 March 2009 (UTC)[reply]

Done Rocket000(talk) 20:22, 12 March 2009 (UTC)[reply]

Perhaps this template could generate the list using {{Langlist}}, which would not only create code that's easier to read and maintain, but also standardize the display of these lang links. --Waldir ^talk 23:27, 18 May 2009 (UTC)[reply]

I'm not sure I see point of that. {{langlist}} was created as an manual way of doing what this template does. That one makes you type in the codes, this one does it automatically. In what way would it standardize the display? It looks the same already but it would be better to change it directly instead of calling another template that's not any easier to read. Trying to make it use {{langlist}} would make it even harder on the servers (and code wouldn't look much better). All you would be doing is passing around parameters for no reason. As far as maintenance goes, it doesn't really need much but adding a language is pretty simple. If we had it call the other template, adding a language would be more complicated since both would have to be updated. Rocket000 (talk) 00:47, 19 May 2009 (UTC)[reply]

Oh yeah, I forgot {{langlist}} has bullets, not pipes.... well, if you want to standardize them, change those back to pipes since that's what the majority use. You could also use {{int:pipe-separator}} which is meant to be internationalized (how you translate a pipe? I don't know). Rocket000 (talk) 00:55, 19 May 2009 (UTC)[reply]

First of all, LOL to the internationalization of pipes :P (Note: I did change that, thanks for the suggestion)

Now, to clarify: I meant that the code in the /lang subpages would be easier, not in {{lang links}} or {{langlist}}. I didn't mean to suggest using langlist instead of lang links; each has its own purpose. For low-traffic templates, lang links would work fine (and I actually wish it was possible to use the automated approach for all templates), but since for more heavily linked templates (which naturally happen to be the most translated ones) a manual list has to be maintained, usually there's no need to use lang links since at most there's one or two new links to be added, which can be done by hand, arguably almost as easily as using lang links.

Now, what I'm saying is we could use the langlist to do the formatting for us instead of having the list with full markup, which in practice eventually comes to differ in small parts from template to template, and makes updating more prone to error. This would be useful since most of the time the list is updated manually instead of through subst'ing {{lang links}}.

Of course, you could argue that people should use {{lang links}} which is slightly easier and virtually immune to human error, but as I said above, that would be a little overkill to, say, add a single new translation.

That said, what I proposed is that lang links generated output in the langlist format, to make future manual update of the /lang pages easier. But of course, that is not a necessity. I'd like to hear your opinion on the use of langlist to replace the manual lists with all that markup. :) --Waldir ^talk 09:23, 19 May 2009 (UTC)[reply]

Oh, I just got what you meant, lol. You're talking about {{Lang links subst}}. I hope no one's subst'ing this template! We could make the subst version leave behind the langlist template instead of the actually code, but personally think if someone's already using an automatic way of generating the links, leaving behind a slightly less convenient format is ok (and better for performance) since they can just subst the template again when it needs updating (of course not everyone is aware of this and will add new languages manually so in that case the {{langlist}}-format is better). Maybe creating a subst version of langlist would be a good idea. Something like {{subst:make langlist}} that does exactly what you're talking about? Rocket000 (talk) 16:05, 30 July 2009 (UTC)[reply]

Latgalian

Please add line with ltg codes after line with lt codes, thx --Dark Eagle (talk) 17:39, 2 April 2010 (UTC)[reply]

Missing languages

Please add following lines in the template:

#ifexist:{{{1|{{NAMESPACE}}:{{BASEPAGENAME}}}}}/de-at|
[[{{{1|{{NAMESPACE}}:{{BASEPAGENAME}}}}}/de-at|{{#language:de-at}}]] | }}{{
#ifexist:{{{1|{{NAMESPACE}}:{{BASEPAGENAME}}}}}/de-ch|
[[{{{1|{{NAMESPACE}}:{{BASEPAGENAME}}}}}/de-ch|{{#language:de-ch}}]] | }}{{
#ifexist:{{{1|{{NAMESPACE}}:{{BASEPAGENAME}}}}}/de-formal|
[[{{{1|{{NAMESPACE}}:{{BASEPAGENAME}}}}}/de-formal|{{#language:de-formal}}]] | }}{{

Thanks --Labant (talk) 12:02, 4 November 2010 (UTC)[reply]

Done, Also added de-at and de-ch to {{Ll}} (de-formal was already there). These three are also in {{Lle}}. –Krinkle^talk 21:10, 6 November 2010 (UTC)[reply]

Please add "ml" (Malayalam). Teofilo (talk) 16:54, 12 February 2011 (UTC)[reply]

Done --Mormegil (talk) 14:24, 16 February 2011 (UTC)[reply]

Please add "az" (Azerbaijani). --Art-top (talk) 15:41, 7 May 2011 (UTC)[reply]

Done -- Common Good (talk) 18:30, 13 May 2011 (UTC)[reply]

Please add "diq" (Zazaki). --Erdemaslancan (talk) 09:17, 12 August 2012 (UTC)[reply]

Could somebody please add "dsb" and "hsb"? (And also the "diq" requested above?) My template skills are a bit rusty, and I'd rather not muck around with this template myself. Lupo 12:25, 13 May 2013 (UTC)[reply]

Now void. Autoupdating using LUA now. See #Using LUA -- Rillke^(q?) 17:35, 15 May 2013 (UTC)[reply]

This section is resolved and can be archived. If you disagree, replace this template with your comment. Rillke^(q?) 17:35, 15 May 2013 (UTC)

Using LUA

We should use a LUA module for generating all these language templates, shouldn't we? -- Rillke^(q?) 12:48, 13 May 2013 (UTC)[reply]

So I made some tests and came up with 2 different approaches:

Template:Lang links/using prefixindex wich makes use of Special:PrefixIndex and does not add any expensive parser function but it is possible that it fails when Special:PrefixIndex changes or if there are too many subpages.
Template:Lang links/all 391, which has a complete set of all language codes supported by MediaWiki (391 currently) and adds 391+1 expensive parser functions. The limit is 500. The limit will be exceeded at the template page itself.

What do you think? Should we go on manually editing each page or should we use one of the automatic ways.

Test at Special:Permalink/96223155

-- Rillke^(q?) 15:29, 14 May 2013 (UTC)[reply]

What are the expensive function calls in the 391 version? #ifexist? What if we rewrote Module:Languages to not use that but construct proper title objects and then use title.exist on them? Would that help? Lupo 21:58, 14 May 2013 (UTC)[reply]

mw:Extension:Scribunto/Lua_reference_manual#Title_library → mw.title.new and mw.title.makeTitle (subPageTitle calls makeTitle) : This function is expensive. So I guess this won't help. Should I try it anyway? -- Rillke^(q?) 09:43, 15 May 2013 (UTC)[reply]

No, if creating the title objects is expensive, we won't gain anything. We'd still have to generate 391 title objects. In that case, go with the prefixindex solution. Maybe check in Module:Page first whether the namespace has subpages enabled at all. If it hasn't, you might get back non-subpages. (For instance, en-WP has articles en:A and en:A/B testing, but the latter is not a subpage of the former because the main namespace has subpages disabled.) Lupo 09:59, 15 May 2013 (UTC)[reply]

Done. Should we convert the language names to upper case? -- Rillke^(q?) 15:30, 15 May 2013 (UTC)[reply]

Yes, please, even though currently, they're not. Lupo 15:57, 15 May 2013 (UTC)[reply]

Thanks for your help. There would be a way to "trick" the parser to get around the expensive parser function limit: Create wikilinks; one for each language, send them to the parser and the look whether the resulting <a>-nodes have class="new" applied. Should we try this way? -- Rillke^(q?) 17:46, 15 May 2013 (UTC)[reply]

Doesn't seem to work; the list is empty on MediaWiki talk:Gadget-HotCat.js. Maybe the "subpage enabled" test wasn't such a good idea. Lupo 21:17, 15 May 2013 (UTC)[reply]

So I disabled the "subpage enabled" test when searching for languages. What about the other questions? -- Rillke^(q?) 22:20, 15 May 2013 (UTC)[reply]

Actually, I like the idea of creating the 391 links and then checking for class="new". It's less prone to fail if there should be many "subpages", and is probably also more stable than the HTML-scraping of the output of Special:PrefixIndex. But it'll need updating of that list of language codes whenever a new one gets added. Time for a bug report requesting that mw.site contain also the list of known language codes? Lupo 07:37, 16 May 2013 (UTC)[reply]

Bugzilla:47833 suggests adding a global variable or function returning all language codes supported by MediaWiki. Locally, we have Module:Languages/List. -- Rillke^(q?) 08:09, 16 May 2013 (UTC)[reply]

The parser returns wikilinks when passed wikilinks. The only reason html links are sometimes exposed to Lua is because of strip markers and their expansion with mw.text.unstrip(). BugZilla:47137 requests a way to iterate over all subpages in Lua, but is likely to remain a low priority because I've demonstrated there are already ways to do it that can work in most cases. --dark lama 13:13, 16 May 2013 (UTC)[reply]

As for the links, it works: There are mw.message.newRawMessage and mw.message:parse(). I am sure you know that it would be desirable avoiding "screen scraping" like done with the prefixIndex-solution. Just imagine some minor changes in the output (e.g. changing the order of the attributes). -- Rillke^(q?) 15:19, 16 May 2013 (UTC)[reply]

I was thinking you meant to use some method of the frame table. Raw messages didn't come to mind. I consider being able to iterate over pages without relying on some fragile approach desirable. I consider any approach fragile while either feature request hasn't been addressed. Something like mw.site.languages is needed to find all supported languages, and mw.title.new(...).subpages('regexp') is needed to find all matching subpages. There are ways to reduce dependency on the order of attributes to html links, but I think depending on html links in general is a bad solution. I opted for special:prefixindex because it was the first solution I could think of, and even with the newPP stats below, it seems to be best overall in having the lowest counts except for expansion depth for some reason. --dark lama 16:04, 16 May 2013 (UTC)[reply]

Using links and parsing those works like a charm. See Special:Permalink/96338175. It adds only 1 to the expensive parser function count. So I suppose, I should apply {{Lang links/using links}} here? The parser-quota output does also endorse this or a combined solution (first try prefixindex; if there are too many subpages, fall back to the link-approach):

NewPP limit reports using the three different approaches; measured at COM:SAND

{{Lang links/using prefixindex|1=Template:No_source_since}}
<!-- 
NewPP limit report
Preprocessor visited node count: 72/1000000
Preprocessor generated node count: 357/1500000
Post‐expand include size: 10402/2048000 bytes
Template argument size: 92/2048000 bytes
Highest expansion depth: 6/40
Expensive parser function count: 2/500
Lua time usage: 0.050s
Lua memory usage: 479 KB
-->


{{Lang links/all 391|1=Template:No_source_since}}
<!-- 
NewPP limit report
Preprocessor visited node count: 877/1000000
Preprocessor generated node count: 6857/1500000
Post‐expand include size: 6740/2048000 bytes
Template argument size: 10296/2048000 bytes
Highest expansion depth: 4/40
Expensive parser function count: 392/500
Lua time usage: 0.449s
Lua memory usage: 535 KB
-->


{{Lang links/using links|1=Template:No_source_since}}

<!-- 
NewPP limit report
Preprocessor visited node count: 70/1000000
Preprocessor generated node count: 351/1500000
Post‐expand include size: 10367/2048000 bytes
Template argument size: 92/2048000 bytes
Highest expansion depth: 6/40
Expensive parser function count: 2/500
Lua time usage: 0.341s
Lua memory usage: 832 KB
-->

Now I went the way with the Hybrid-Solution:
- I was impressed by the speed with which the Darklama's PrefixIndex-method worked but not with its limits (e.g. at Commons:Picture of the Year/2010 which has >1000 sub page)
- I took the advantage of link-parsing instead of using {{#ifexist: regarding expensive parser function limit.
Hopefully nothing broke, will not break and will work as expected. This is my first LUA experience at all so please report, if something does not work as expected.
Here are the statistics for the Hybrid solution:

NewPP limit reports using the Hybrid solution

{{Lang links|1=Template:No_source_since}}
<!-- 
NewPP limit report
Preprocessor visited node count: 72/1000000
Preprocessor generated node count: 357/1500000
Post‐expand include size: 10402/2048000 bytes
Template argument size: 92/2048000 bytes
Highest expansion depth: 6/40
Expensive parser function count: 2/500
Lua time usage: 0.045s
Lua memory usage: 480 KB
-->

{{Lang links|1=Commons:Picture of the Year/2010}}
<!-- 
NewPP limit report
Preprocessor visited node count: 69/1000000
Preprocessor generated node count: 351/1500000
Post‐expand include size: 9786/2048000 bytes
Template argument size: 116/2048000 bytes
Highest expansion depth: 6/40
Expensive parser function count: 3/500
Lua time usage: 0.579s
Lua memory usage: 830 KB
-->

If WMF-wikis use the default config, we have 50 MB and 7 s.
Thank you. -- Rillke^(q?) 21:17, 16 May 2013 (UTC)[reply]

A few more improvements are possible to avoid the need for a hybrid solution. {{special:prefixindex}} can be passed parameters like |hideredirects=true to avoid needing to pattern match for it, and |from=page to get more subpages beginning from the last one found. --dark lama 13:35, 18 May 2013 (UTC)[reply]

One will never know how many sub pages there are (so it could be more expensive in the end or we must listen to LUA quotas while processing [which is currently not possible?]).

Could you write a method that allows iterating over all subpages? HTML has to be unescaped (I just saw quotes but any character that is allowed in titles should be considered " > < &lrm;). -- Rillke^(q?) 15:11, 18 May 2013 (UTC)[reply]

The subpage iterator now iterates over all subpages, decodes HTML entities, no longer depends on the attributes in html links, and can pass options to {{special:prefixindex}}. The language_subpages function ignores any subpages with a length greater than 4 since language codes cannot be that long. Performs better than the other methods even with Commons:Picture of the Year/2010. --dark lama 18:58, 18 May 2013 (UTC)[reply]

That's top! Thanks a lot. Nonetheless, I would be still pleased to see an option to quit (e.g. after 20 prefixindexes were requested or after xx subpages were processed; the LUA execution time for the POTY-page was 0.475s with the subpages approach). -- Rillke^(q?) 20:59, 18 May 2013 (UTC)[reply]

Using, os.clock(), I found a way to prevent running until the quota exceeded. Also, I think redirects should be listed; the old template did this and users may have stored the page containing the translation under a translated name and just redirected the subpage to that page. -- Rillke^(q?) 15:01, 28 May 2013 (UTC)[reply]

It's empty again at MediaWiki talk:Gadget-HotCat.js... Lupo 21:50, 19 May 2013 (UTC)[reply]

Both, the label/tag/description section and the gadget-script-i18n-section show langlinks for me. What I am missing? -- Rillke^(q?) 15:25, 20 May 2013 (UTC)[reply]

Yep, they're back again. Strange. Server hiccup? I had tried shift-reload and purging, but they remained AWOL. (Shortly after I had added MediaWiki:Gadget-HotCat.js/ce.) No idea why they were gone. Lupo 20:00, 20 May 2013 (UTC)[reply]

I had to make it ignore that the namespace doesn't support subpages. I wonder if that should be the default and instead have an option to force checking whether the namespace supports subpages. --dark lama 23:20, 20 May 2013 (UTC)[reply]

Nope, I don't think it should be the default. The operation is called "subpages", so it should return subpages. In namespaces that do not have subpages, it should return nothing. Ignoring the "may have subpages" setting of a namespace should be the exceptional thing that should need to be enabled explicitly through an option. Lupo 07:00, 21 May 2013 (UTC)[reply]

Use on templates

I see in the documentation for this template:

This template should not be used on templates to avoid hitting the "expensive parser function" or the "LUA execution time" limit on pages with other expensive templates.

Does anyone know of any cases where this template hit the "expensive parser function" or "LUA execution time" limits? I'm curious to know where this happened, so I can look at what other "expensive templates" were in use, if any, and whether there is more that could be done to improve Module:Languages. I have already made some improvements for one of that Module's dependency at Module:Page/sandbox, which may help reduce the execution time, but that still needs something to test against. --dark lama 21:56, 13 May 2014 (UTC)[reply]

I see this is an "old"(?) method alternative for /lang subpages? For example this can here be removed!? Template:Redeye/layout ↔ User: Perhelion (Commons: = crap?) 15:34, 18 June 2015 (UTC)[reply]

Lint

{{Edit protected}} Can the two lines below be changed from

-->{{#if:{{{suppressaddlink|}}}|<!-- no edit link -->|{{{addlink|{{edit|{{NAMESPACE}}:{{BASEPAGENAME}}/lang}}}}}}}
</span>

to

-->{{#if:{{{suppressaddlink|}}}|<!-- no edit link -->|{{{addlink|{{edit|{{NAMESPACE}}:{{BASEPAGENAME}}/lang}}}}}}}<!--
--></span>

which will reduce some lint errors in Special:LintErrors/misnested-tag -- WOSlinker (talk) 09:45, 24 February 2018 (UTC)[reply]

Done --Jarekt (talk) 12:55, 22 March 2018 (UTC)[reply]

Expensive parser function count

For example on Help:Gadget-ImprovedUploadForm there was a count of 584 (limit is 500). After creation of Help:Gadget-ImprovedUploadForm/lang (empty dummy) the count is 80. I think this is not intended. Any option to omit? -- User: Perhelion 18:21, 26 July 2018 (UTC)[reply]

I also reduced the count from Commons:Templates from near 1000 calls to 113, by only exclude this template on 2 templates!![1][2]

You can find more on: Category:Pages with too many expensive parser function calls -- User: Perhelion 19:48, 26 July 2018 (UTC)[reply]

Expensive parser function count

{{Lang links |1= Template:Taken with ...}} uses up 494 expensive function calls out of 500 allowed. We need to fix this template or retire it.--Jarekt (talk) 01:21, 17 February 2022 (UTC)[reply]

Template talk:Lang links

Contents

Missing space and unnecessary template use

Langlist

Latgalian

Missing languages

Using LUA

Use on templates

Lint

Expensive parser function count

Expensive parser function count

Navigation menu

Template talk:Lang links

Missing space and unnecessary template use

Langlist

Latgalian

Missing languages

Using LUA

Use on templates

Lint

Expensive parser function count

Expensive parser function count

Navigation menu

Search