the new version of langprefix

That is a bit surprising. The speed of {{catboiler}} was significantly improved when we moved away from the switch. And I think a loads a bit faster too, but I'm not sure.

If I had to guess, it's probably due to the way {{does-template-exist}} works.

It's the best alternative we have for #ifexist. We could eliminate it... but only by creating a subpage for every possible code. Is that viable?

Dammit. One of the prereqs for {{does-template-exist}} is that the template does have to exist. Did you even read the description on that page? It has a huge honking warning about this.

The restriction on #ifexist: is there to protect the wiki. {{does-template-exist}} is a workaround that circumvents that restriction; when you use it, it is your responsibility to make sure you're using it responsibly.

(I knew that it was a mistake for me to create {{does-template-exist}}. We have too many admins who simply don't give a damn about damaging things, as long as they get to have fun while doing it.)

Of course it would be even better if we didn't need langprefix at all. But Ruakh would probably object.

He would. Ruakh has a personal vendetta against me and will oppose anything I do, and anything any of my friends do, including you. I created {{Xyzy no langprefix}} long ago, but Ruakh would not let me use it.

With language codes he seems to think that it's inherently better to make a template break when the wrong code is used, instead of using policy to restrict usage. Which I think is naive, considering that there are always workarounds. Here's one! bīdanan :)

Personally I think the best solution that will cause us the least headaches in the long run is by having all code templates (except scripts) share a single common naming scheme. Including templates for families, so that we can eliminate the #ifexist's from {{etyl}} and {{derivcatboiler}}. We already have an alternative for figuring out what 'type' of thing the code refers to, the /type subtemplate. If we decide to rename the templates, we could also decide to prefix them all with something like code: or code/. That would them allow us to use any template name freely without worrying whether it conflicts with a code.

I suppose all you say is true. If it weren't for those people up there, ... *shrug*

This is a wiki and there are two of you and one of him. There are other template-savvy editors here, too. If your ideas are better than his, bring them up in the GP and outvote him! As it is, I wouldn't accuse anyone of having a personal vendetta; I think you just have different philosophies, which leads you to be on different sides of issues. (For some of the issues, like whether to design our templates to suit our few big pages or our many small pages, I think the solution is just to have two sets of templates. But where a template has to be used site-wide, there's no objectively right answer, and the philosophy with the most voting adherents wins.) - -sche (discuss) 21:13, 21 October 2012 (UTC)

Also — my objection to {{Xyzy no langprefix}} was twofold:

• It's silly to have two separate templates, {{Xyzy}} and {{Xyzy no langprefix}}, with no rhyme or reason for which one is used.
• After {{Xyzy}} was modified to use {{langprefix}}, it happened over time that other pages started depending on that. You didn't even try to fix that; you apparently felt that it was A-OK to break existing pages by performing mass migrations from {{Xyzy}} to {{Xyzy no langprefix}}.

Ultimately, {{Xyzy}} should look more or less like how {{Xyzy no langprefix}} currently looks. (I think we can agree on that much?) The problem with your edits was simply that they didn't help toward that goal; they broke things, but you offered no ideas for how those things could ever be fixed.

Some templates should not, and do not, ever, depend on langprefix. I mean those like {{t}}, which should never have a non-mainspace language code as its first parameter.

I think you're right about the "should not"; but I'm not sure how you can assert the "do not", since we've established that you don't know how to consult the database-dumps, and I'm pretty sure I'd remember it if you had ever modified {{t}} to create a cleanup-category or something.

I propose this:

1. I'll generate a list tonight of pages using {{t}}, or one of its friends, with non-mainspace language-codes.
2. We fix these.
3. We modify {{Xyzy}}, changing langprefix={{langprefix|{{{lang|}}}}} to langprefix={{{langprefix|{{langprefix|{{{lang|}}}}}}}}; that way, {{langprefix}} will not be called when langprefix= is specified.
4. We modify {{t}} and its friends to specify langprefix= (as blank).

I think that will accomplish (almost) everything that you intended with {{Xyzy no langprefix}}?

Actually, I see now that you changed {{t}} et al. to bypass {{Xyzy}} anyway. I think that was a mistake, but whatever. *shrug*

Yes, I did that for performance reasons. Xyzy is a slow template, so bypassing it makes pages a whole lot faster. I used it on a lot of "high-profile" templates like {{t}} and {{l}} that do not benefit from the italics for English terms (the only reason why one would use Xyzy over that). And I see that you reverted it, in the case of l.

I doubt that.

I could well imagine that [[water]] is made faster by micro-optimizations like this, but it's not representative, and we shouldn't make Wiktionary-wide design decisions based on it.

(If need be, we can just take a DUDES ALREADY KNOW ABOUT CHICKENS approach to that entry.)

The alternative would be specifying sc=Latn over and over on large pages. (Yes, this actually reduces server load considerably!) I don't think that is what you want, is it?

I don't think that is "the alternative".

Rather, it will be?

Er, let me rephrase:

I don't think that is the alternative.

It would be bizarre if I objected, seeing as I myself have repeatedly complained that {{langprefix}} should not exist.

(And I don't have a vendetta against either of you. I have a vendetta against some of your opinions, but you shouldn't take that personally.)

Well you did say this: The whole point of those prefixes is to draw a distinction between real, attested language and fake or unattested ones — a distinction which has always enjoyed a strong community consensus. - suggesting you'd like to keep everything as it is, including the langprefix template.

Not at all. {{langprefix}} is an attempt to paper over the distinction, and I have always objected to it. If we want a given template to support both mainspace entries and appendical ones, then that should be controlled in an editor-visible fashion at the point where the template is called; it should not happen as an implicit and automatic consequence of what language-code is used.

You have repeated this many times but you have never considered the consequences of having to either duplicate or modify every template that takes a language code.

Firstly: Not that many templates take a language code, and of those that do, most don't need this. ("Form-of" templates, translations-templates, etc., don't need to support appendix-only languages.)

Secondly: You and others have already duplicated or modified (or both!) all of these templates, repeatedly, as part of your campaign to paper over the distinction between first-class-citizen languages and appendix-only languages. It's not that I haven't "considered the consequences" of fixing that mess; it's that I consider those consequences to be positive consequences, manifestly superior to the status quo.

Form-of templates do need it. See *þat. Again you have repeated this many times, but I still don't understand how you expect your system to work in practice, nor do I understand how you think your system is more editor-friendly than what we have now. And if it is not intended to be editor-friendly, what is the point? Why would we agree to have something that makes it harder for us to do things?

See google:"explicit is better than implicit" and "similar things should look similar; different things * different". I hold that distinctions such as these:

• a language that we want in mainspace vs. a language that we allow only in appendices
• a link to a mainspace entry vs. a link to an entry-like appendix

are fundamental distinctions that should always be visibly evident — and, in fact, that are visibly evident, when you navigate the site as a reader. We require our readers to understand these distinctions (if they want to find what they're looking for), and we require our editors to understand them (if they want to create the right pages in the right locations); therefore, a template that papers over these distinctions in the edit-window is doing a disservice by making things look more similar than they are, and by having radically different behavior depend on superficially near-identical wikitext.

drama woo!

Now to the actual thing:

where is the problem in just writing ex. {{etyl|proto:gem-pro|de}} or similar? I fail to see it. Or am I missing something here?

There is absolutely no problem with {{etyl|proto:gem-pro|de}}, either in theory or in practice. In fact, that already works; it's just that {{etyl|gem-pro|de}} also works.

But {{etyl}} is a special case, since (1) its argument isn't necessarily a language code, or even a fake language code — we can write {{etyl|Vulgar Latin|fr}}, for example — and (2) we can simultaneously have {{etyl:el}} and {{el}}, for example, if we want {{etyl|el}} to display "Modern Greek" while {{onym|el|foo}} links to [[foo#Greek]]. The etyl: templates really belong to {{etyl}}; probably we should have made them explicit subtemplates, by using names like {{etyl/Vulgar Latin}} instead of names like {{etyl:Vulgar Latin}}. The only connection between etyl: and proto:/cons:/etc. is that the former was apparently the inspiration for the latter.

A more typical case is {{term}}. Currently, something like {{term|...|lang=proto:gem-pro}} does not work. The problems are: (1) it doesn't know to link to an appendix (which can be fixed, by having it check for initial proto:); (2) it will actually put lang="proto:gem-pro" in the HTML (which would be easy to fix if we had Scribunto; since we don't, I think we'd have to create a new set of language subtemplates, called e.g. {{fr/HTML lang}} or whatnot, for mapping e.g. fr to fr and proto:gem-pro to x-gem-pro — though if we want, we could avoid creating it for mainspace languages . . . suffice it to say, if we want to go this route, I have some thoughts on the subject); (3) it uses the script-template {{Eror}} (because, for reasons I can no longer recall, {{Xyzy/script}} won't try e.g. {{fr/script}} if it finds that the language-code includes URI-special characters; that's easy to "fix", in theory, by removing that check, but I'm loath to do so without remembering why it was included to begin with); and (4) possibly other problems I haven't thought of. These problems are surmountable if we want to do it this way; personally, I think I'd prefer something like {{term|...|langprefix=proto|lang=gem-pro}}, but there are multiple valid approaches.