the new version of langprefix

Fragment of a discussion from User talk:CodeCat
Jump to: navigation, search

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.

20:22, 25 October 2012

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}}?

21:23, 25 October 2012

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

23:14, 25 October 2012

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.

21:41, 26 October 2012

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.)

23:00, 26 October 2012

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?

09:31, 27 October 2012

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

13:45, 27 October 2012

Rather, it will be?

13:45, 27 October 2012

Er, let me rephrase:

I don't think that is the alternative.

13:53, 27 October 2012