the new version of langprefix
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:
- I'll generate a list tonight of pages using
{{t}}
, or one of its friends, with non-mainspace language-codes. - We fix these.
- We modify
{{Xyzy}}
, changing langprefix={{langprefix|{{{lang|}}}}} to langprefix={{{langprefix|{{langprefix|{{{lang|}}}}}}}}; that way,{{langprefix}}
will not be called when langprefix= is specified. - 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}}
?
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.)