the new version of langprefix

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.