Template talk:Langlist

External links problem

This template makes the external links table explode so it might be wise to not use it. Multichill (talk) 22:27, 10 July 2009 (UTC)

I think, this falls under en:Wikipedia:Don't worry about performance (in the wider sense). If the uselang links improve the usability for the user, we shouldn't care about internal technical details like the size of a database table. If it's really a problem, it should be fixed on the technical level. --Slomox (talk) 00:24, 11 July 2009 (UTC)

See http://lists.wikimedia.org/pipermail/wikitech-l/2009-July/044025.html . Multichill (talk) 00:30, 12 July 2009 (UTC)

It is ok for now, externallinks pointing to same site are very cheap now, as we simply don't record them, so it isn't much of an issue (actually, it may make sense to change other templates, like GFDL, to use fullurl). I find Slomox's "don't worry" quite fun though, when doing site-wide used-by-million-users template changes, that are quite big... Dude, we're not omnipotent. Midom (talk) 07:08, 12 July 2009 (UTC)

Wow, in retrospect that does make for some comic reading (imagining mushroom over twisted heap of metal where colo center used to be). --Dschwen (talk) 01:02, 13 July 2009 (UTC)

I find Slomox's "don't worry" quite fun though It's not "my" rule. I linked the page, it's what the developers recommend. And if you follow the thread linked by Multichill, you'll see, that "Don't worry about performance" applied fully. The problem was fixed on the technical level. --Slomox (talk) 12:24, 14 July 2009 (UTC)

But you're also talking to a developer. He's also obviously aware that it was fixed on a technical level since he came here to tell us just that. Rocket000 (talk) 05:54, 15 July 2009 (UTC)

BASEPAGENAME

this change won't work. The template is transcluded in images and at for example File:Kane QC.png the BASEPAGENAME is Kane QC.png. Multichill (talk) 10:54, 19 July 2009 (UTC)

You're right. I undid the change. Too bad there isn't an <includeonlyonfirstlevel> or something :) --Waldir ^talk 11:02, 19 July 2009 (UTC)

Of course it's not useful for templates (the parameter always needs to be set), but it does work for places like in project page headers. The template on File:Kane QC.png would still work correctly since the manually set value (GFDL/lang) overrides it. Rocket000 (talk) 03:43, 29 July 2009 (UTC)

Nevermind, I didn't realize the namespace was hard-coded... it should have been {{{1|{{NAMESPACE}}:{{BASEPAGENAME}}}}}/lang from the beginning (or {{{base|... if you must). Rocket000 (talk) 03:55, 29 July 2009 (UTC)

why uselang?

What's purpose of adding the uselang param? Should we really be changing the user's interface just because they clicked on a particular link (without giving them any indication that will happen)? I always find it annoying when it happens when coming back to Commons from an image page on a non-English projects. Now my interface is getting messed with without even leaving Commons... Rocket000 (talk) 04:25, 29 July 2009 (UTC)

I agree, and for what it's worth, there's also an aesthetic side: both the code and the display would be neater if regular internal links were used. I support removing the uselang parameter in the links. --Waldir ^talk 10:45, 29 July 2009 (UTC)

The main advantage of uselang is, that you can see the template in situ instead of the empty template. --Slomox (talk) 15:13, 29 July 2009 (UTC)

Huh? Can you clarify what you mean for me? All it does is make the interface different. The template would still appear in the different language and not be empty. Rocket000 (talk) 16:29, 30 July 2009 (UTC)

If the links didn't take you to the translated template page itself, and simply reloaded the page you were on with a different interface (so the template(s) change as well) then that would make sense. But, for example, Template:PD-old/es&uselang=es and Template:PD-old/es&uselang=sk are the same except for the interface. Rocket000 (talk) 16:45, 30 July 2009 (UTC)

You are right. I mixed it up with the mechanism implemented e.g. in Template:Assessments/lang. The links in Assessments/lang reload the page in situ, but Langlist does not. So your revert of the uselang statements was correct. --Slomox (talk) 11:01, 6 August 2009 (UTC)

Oh, yes. I remembered some template did that but I forgot which one. Rocket000 (talk) 12:11, 6 August 2009 (UTC)

Can we not use this in everything?

I can no longer edit this template with getting an server error. This is a great tool, but I don't understand why people are replacing manually made links with this. Adding a language is not that much work. You can even subst {{Lang links subst}} to do it all for you. It evens finds other missing languages. When you have tons of these on a page (e.g. every template on an image page is using it) it really slows down the page load. I don't care about the servers, you're making it worse for the user. Use this for new templates but please don't keep replacing the heavily used ones. Seriously, I'm having hard time seeing the benefit given the cost. And it's also not flexible. It's lock into a single namespace and always requires the 'base' to be set. What if I want to add a language that MediaWiki can't understand yet (and we definitely have some)? To do that I have to undo the conversion. That's a lot more work than the other way around. And since it doesn't alphabetize things, we're getting inconsistent. Rocket000 (talk) 07:16, 6 August 2009 (UTC)

I'm afraid I was the main (if not the only) responsible for the recent conversions. The reckless conversion of Template:PD-old/lang without accounting for the extra links that got cut off was the final straw. You are evidently right. The current manual system is nowhere near perfect, but as you say, it's not that hard to add a new language. I'll stop doing these conversions, and start using {{Lang links subst}} instead. --Waldir ^talk 09:42, 6 August 2009 (UTC)

I have not yet experienced any slownesses, but of course that does not mean, that they don't exist. But as Langlist does not use any costy parser functions, I don't think, that this template is the main culprit for slownesses.

It [..] always requires the 'base' to be set How is this unflexible? It's not technically possible to make it work without specifying a base. And the manual links even need the base specified redundantly for every single link.

It's lock into a single namespace That's true and is not easily fixable without either using expensive ifexists or changing all inclusions so far. But as very few templates will ever be transferred to different namespaces Langlist is still useful to be used in templates.

I can no longer edit this template with getting an server error. What kind of server error? If it's a timeout error: that is quite normal for heavily-used templates. A timeout error does not mean, the template is too complex. It just means, that Mediawiki has to insert many cache invalidations into the job queue. That happens with every heavily-used template, independant of how complex or simple the template is.

What if I want to add a language that MediaWiki can't understand yet (and we definitely have some)? Langlist is not restricted to any set of codes. You can specify whatever code (existant in ISO or not) you want. Test with some Google interface languages: elmer fudd | bork, bork bork! | hacker | klingon | piratese | +/-

And since it doesn't alphabetize things, we're getting inconsistent. It doesn't, that's true. Alphabetization has to be done manually. But how is this a disadvantage to fully manually inserted language links? They are alphabetized manually too, aren't they? --Slomox (talk) 11:28, 6 August 2009 (UTC)

Many of those things were pointing out that it doesn't really offer any benefit besides making it a little easier to add a language. Benefit vs. cost thing. It is limited in the sense of using language codes and having {{#language:}} convert it, but I forgot it would still return anything so I guess it doesn't matter. Costy parser functions effect the server more than us (it seems), but post-expand size and just the amount of data we have to receive and load effects the user. not technically possible to make it work without specifying a base. True, for any links you transclude, but all non-template translations links don't need it. Why limit a template like this to one namespace? I pointed out the error to show how heavily used this template is already. I didn't mean anything about how complex or simple it is. Rocket000 (talk) 12:05, 6 August 2009 (UTC)

One more addition to my previous claim, that the template supports non-MediaWiki language codes: Something like {{Langlist|gil|base=Langlist}} would work, but not really nicely: gil | +/-

showing the code 'gil' instead of 'Kiribati'. This could be fixed by some code like {{#ifeq: {{{1|}}} | {{#language: {{{1|}}} }} | {{Language| {{{1|}}} }} | {{#language: {{{1|}}} }} }}. If {{{1|}}} is a language supported by MediaWiki, the name will be shown. If it's not supported, it will show the output of the template {{Language}} (or the native name equivalent of it. Do we have a template returning native names of non-MediaWiki languages?).

Why limit a template like this to one namespace? That was no intentional decision. It was created having templates in mind and it did not occur to the creator, that it would also be useful for non-templates. If we want the same functionality for non-templates, let's just create another template with the same functionality, but without the limitation. If we want to, we can afterwards also change all inclusions of Langlist to the new template to avoid redundancy of the two templates. --Slomox (talk) 15:00, 6 August 2009 (UTC)

Heh, I like how you used 'gil' for the example. ;) Actually, I was working on a {{Language2}}. See the code before I deleted it (the reason I gave for deleting it didn't really make sense since that's a translated template, but basically it was because it wasn't used). It was an extension of {{#language:}}, not {{language}}. You're right on the other points too, but keep in mind I was only talking about using it in really heavily-used /lang templates, not usage of it in general. It's still a good template. Rocket000 (talk) 19:59, 6 August 2009 (UTC)

I already have a bot somewhere to keep /lang templates up to date using {{subst:Lang links subst}}. I'll have the bot work on some templates to show how it works. Rocket000, could you check if the template includes all languages? Multichill (talk) 20:09, 6 August 2009 (UTC)

Yes, I will. I know it's missing a couple. Rocket000 (talk) 21:16, 6 August 2009 (UTC)

You can find a list here. Multichill (talk) 04:55, 7 August 2009 (UTC)

I'm planning to do a thorough search to what we actually need. For example, I know we don't need 'tokipona' and certain regional ones like 'zh-hk' and 'zh-tw' are no longer used (although there's still a couple that need renaming). For the most part, I try and keep Template:language/en as our ultimate list (i.e. I saw them in use somewhere) but there's some we don't need for this. (I also have User:Rocket000/Languages). Rocket000 (talk) 08:41, 7 August 2009 (UTC)

Regarding last revision

{{editprotected}}

I reported this being broken earlier and {{langlist}} was replaced. Now I found {{PD-user-fi}} and {{Cc-by-sa-2.0-fr}} having the same problem, so I suspect this template here being broken. If I'm not mistaken it's that previous revision had line feed before </span> covered with <!-- --> but current one hasn't. 195.50.197.68 16:43, 7 August 2009 (UTC)

 Done Thanks for reporting that. Rocket000 (talk) 08:04, 8 August 2009 (UTC)