Wiktionary:Grease pit/Tricky templates

Tricky templates Part I

What's going on with the entire italbrac and cattag stuff? These templates are becoming ever more complicated, each one calling another couple of templates. Are you guys sure that's all necessary? Keep in mind to keep it as simple as possible; people who come after us should still be able to understand what we're doing. If it's really necessary, then please document it thoroughly. I'm afraid saying "documentation is on meta" is not sufficient.

Here's the list of templates called for the simple tag {{chemistry}}:

• Template:cattag
• Template:cattag/category
• Template:cattag/pass1
• Template:cattag/standard
• Template:chemistry
• Template:foreach
• Template:foreach/pass1
• Template:italbrac
• Template:italbrac/pass1
• Template:x0

Although it's an amazing job what you guys are doing there, I'm sure this can be simplified. — Vildricianus 15:06, 5 June 2006 (UTC)

It could be simplified ten times if the wiki syntax had some basic functionality built in that it doesn't. The template foreach is documented on meta but it should really be a built-in construct, avoiding some of the hacking that has been done with special symbols and resulting in less literal evaluation. In fact on meta it's carried out to 150 arguments, which I considered to be a ridiculously excessive means to approach the problem. Recursion is also problematic because it isn't allowed explicitly, but it is allowed if you use redirects. In fact these were not implemented with forward thinking because some limited recursion is not necessarily evil and could be accomplished much more cleanly. As it is they've tried to avoid problems by limiting capability, which doesn't do anyone any favors. Nonetheless I think I may have discovered a way to perpetually slow down the servers that of course I don't want to test. That would perfectly exemplify why it's better to use a clean approach.

Then it's difficult to keep the code itself looking clean because extra spaces are often translated into the output. In general there is a confusion of code and data that produces too many special cases. In fact I'm taking advantage of this as the only way in my case to know the level of recursion. If there were a simpler construct such as a static variable or a way to check the call history then this would not be necessary. Of course I'm not asking for that functionality because it would just make the whole system that much more of a mess. All of this in fact is jumping through hoops to get around a bug that reassigns passed variables when undeclared variables are checked for. This system of variable passing is itself a rather nasty concoction, relying on old call by name (rather than value) and text replacement principles that have been eliminated in modern languages, whatever the meta site might claim. Davilla 07:00, 6 June 2006 (UTC)

I empathize with you, Davilla. Since we are building increasingly tall large towers from our stone knives and bear claws, it is becoming increasingly important to be able to verify template functionality after even minimal changes.

To that end, I've drafted a rudimentary functional testing pattern (with use instances at Template talk:en-infl-verb/test and Template talk:en-infl-noun/test) about which I'd appreciate any comments. The pattern is to create a test suite as one or more subpages of the template's talk page that exercise the template's functionality in a human-verifiable format. Each test obviously needs to show both expected behavior and actual results.

Immediately obvious deficiencies include caveats about namespace and pagename evaluation as well as the need for manual verification. The former is ugliness we can probably cope with and the latter can be addressed via external tools. In any event, if we improve and follow a template testing pattern, we should simplify the maintenance tasks for ourselves and for those who follow us. Rod (A. Smith) 08:17, 6 June 2006 (UTC)

It could be simplified ten times if the wiki syntax had some basic functionality built in that it doesn't.

There's a good reason MediaWiki doesn't allow much of this sort. Recursion, passes, variables and loops are beyond me I'm afraid - maths has never been my thing - but I'm talking about a general idea here.

There's also a good reason why {{foreach}} has been deleted from Wikipedia. These things do pose a strain on the servers, not yet for us, but for bigger sites with more visitors. Perhaps we get better servers, or better software before we're big enough to have problems, though. Please continue with experimenting and expanding the templates, but also keep in mind some of this stuff. — Vildricianus 18:33, 6 June 2006 (UTC)

Server strain is a perfectly good reason why foreach should be a language construct rather than a text-based evaluation. Ideally a single parameter would be treated as a single parameter and not 150 like the foreach on meta requires. When I copied it I doubted we'd ever have need for more than nine arguments to any template, so that should avoid some of the overload that Wikipedia experienced. But that could create an arbitrarily low limit as well. I'll take a look at foreach and see if there's any way to streamline it.

Unfortunately cattag is rather complicated and there's not much I can do to eliminate the extra templates. In fact I would like to create more because there's so much shared code which would be easier to read as subroutines, but I've refrained as per your request. I'll see if I can reduce the number of calls to category from four or five down to two, which will make inlining that template feasible, but that's about all that can be done. A higher priority right now is making sure that the categorization is completely functional.

As for italbrac and italbrac-colon, they seem simple enough to be rolled into cattag and other functions once they've been proven and weather tested. In fact I sort of had to do that already, but opted to split italbrac into several parts (first, inner, separator, and last, in addition to pass1) to allow them to be customized. If I had hard-coded it into cattag I don't think anyone would have wanted to touch it. But I'll roll them in eventually. Davilla 19:13, 6 June 2006 (UTC)

Thanks for considering it. I'm merely concerned with 1/ complexity of things (i.e. if the few people here that understand it decide to leave all of a sudden, everyone else is stuck); 2/ server strain (per below); 3/ possible vandalism targets (see also below). Other nuisance is the list of templates used on a page getting ever bigger, making it harder to find out which are actually used.

Also of note, if we're going to keep this the way the tag templates work, all their meta-templates will have to be protected, if not fully, then at least semi. Once these templates become more widespread, any change to any of their meta-templates will create a job queue of a couple of hundred thousand articles. — Vildricianus 09:42, 7 June 2006 (UTC)

Agreed, agreed, agreed. I'm afraid though that once cattag is established the only way to make any changes will be to replace the system in full. The reason it has to be so complicated is that it relies on the existence of other templates to know what the parameters should expand to. Because of language limitations this isn't an easy task. I'll take a fresh look at cattag to see if it can't at least be simplified, maybe reducing the strength of some of the error checking. I'm used to the typical input/compute/output model and there's a strange way of looking at wikicode that allows functions to be inserted mid-sentence. In some cases if it's done right then separate sections can be combined, avoiding duplicity or eliminating the need for subroutines, and making the code more readable and therefore editable. I'm also open to suggestion on how to format without stripping out all extra whitespace. Davilla 15:58, 7 June 2006 (UTC)

Have you considered Rod's <!--

--> trick ? That allows spaces and blank lines. — Vildricianus 19:31, 7 June 2006 (UTC)

I feel pretty strongly that Rod's suggestion above is most relevant. cattag should not be doing all this verification - that should be done offline.

I am alarmed to see so many separate calls. Even if the optimization is as good as people say it is (which I can believe, but choose to doubt) there are still that many recursive calls for each page edited. This should be subst:'ed up into their parent template(s) wherever possible. Where not possible, offline verification should be considered.

On the other hand, I do like the clever features I see being added. It is a pretty tough call, but I think we can get this back into one single template if we put our collective intelligence to it. --Connel MacKenzie T C 05:45, 9 June 2006 (UTC)

cattag

I've been trying to get cattag to work so that if {{lex}} produces {{italbrac|lexicography}} then {{cattag|lex|dated}} produces {{italbrac|lexicography|dated}. Right now I use {{cattag|lex}} at template:lex and have a magic list at cattag/standard that substitutes lexicography for the parameter lex. But the magic list I think is troublesome because it has to be maintained. What I'd like to do is use the label templates themselves as magic lists. That is, if a template exists, for instance {{math}}, and if the content is different from the template name, in this case mathematics, then use the content of the template rather than the abbreviated parameter. But the content of the template is actually {{cattag|mathematics}} unevaluated and (mathematics) evaluated, and I don't know how to strip the parenthesis or any of that other junk off. Davilla 17:05, 3 June 2006 (UTC)

added two SA words, kaalgat and gatvol with the catagory, but it hasn't shown up on the catagory page. Any ideas why? Andrew massyn

Categories take up to five minutes to refresh, some times. Also, kaalgat does not seem to use the cattag template. --Connel MacKenzie T C 19:14, 4 June 2006 (UTC)

If you use cattag, as you should for more than one label, or if you use any of the label templates that (should) call cattag, then the category will not be added if the category does not exist! This is meant to avoid the creation of categories that might duplicate ones alternatively worded, such as Category:South African English instead of Category:South Africa. I am working out some kinks with abbreviations as in the above text, and then I will document how to indicate categories when the name differs. Davilla 14:31, 5 June 2006 (UTC)

Okay I've found a crazily complex work-around and rolled in this new version. Using {{cattag|label1|label2|etc.}} will produce the same result as {{label1}} + {{label2}} + {{etc.}} whenever the templates exist, provided they call cattag themselves, and just the plain text otherwise. Oh, plus categories when they exist as well. Try out the new system and see how well it works and if there are any special considerations that should be addressed. Davilla 19:26, 6 June 2006 (UTC)

This is a crazy thing, I'm tellin' ya. What's the difference between {{cattag|chemistry}} and {{chemistry}}? — Vildricianus 19:28, 14 June 2006 (UTC)

Tricky templates Part II

This is the list of templates "in use" when I use one of the new verb templates (in the form of {{en-verb|itemiz|es}}). Page tested is User:Vildricianus/PageX/4, which has only said template.

• es
• itemiz
• valid
• Template:,
• Template:ARchar
• Template:Arabic font size
• Template:Arabic fonts
• Template:bottom
• Template:en-infl-verb/getPast
• Template:en-infl-verb/getPastP
• Template:en-infl-verb/getPres3rdSg
• Template:en-infl-verb/getPresP
• Template:en-infl-verb/isValidPageName
• Template:en-verb
• Template:gender period
• Template:isValidPageName
• Template:m
• Template:mid
• Template:n
• Template:see
• Template:seeCites
• Template:serial and
• Template:top

This is not to criticize the work that has be done, hardly so. On the contrary, I'd like to find out how we can preserve it by making the above list shrink. "Shrink", that is, both physically and visually.

1. Physically: how the heck do I get ARchar, m, mid, seeCites and friends used by {{en-verb}}?

   Already found: because of es. Why is es said to be a template here? It's a parameter. Is there any way they could be excluded from that list?

2. Visually: could there be any way that the "templates in use on this page" is trimmed, displaying only the templates primarily used on the page, so not the secondary ones like /getPast etc.? Should I attempt this at bugzilla? — Vildricianus 21:39, 17 June 2006 (UTC)

Yes, that's an annoyingly long list of templates. The "es" and "itemiz" seem stange. It looks like they could be the result of some bug in {{en-verb}}. I will look into that. As for the others, I split up the functionality of {{en-verb}} into subroutines because I think that makes the template itself easier to read, but if the editor community desires, I could flatten the subroutines into the top level template. Rod (A. Smith) 22:40, 17 June 2006 (UTC)

What would be a real solution is if there were a software-based enhancement for it. If it's not going to happen (likely), I don't think it's really necessary to re-include the subtemplates into the main one. It's up to you. — Vildricianus 23:00, 17 June 2006 (UTC)

The easiest way to do this would be to give templates subpages, and simply not list the subpages if the template itself is listed. Davilla 12:07, 18 June 2006 (UTC)

That's the reaction I've gotten as well, which is unfortunate because subroutined do make the code easier to read. A lot of your calls are only made once, so they would be very easy to roll in. What does isValidPageName do? I don't see any comments in the code. Davilla 12:07, 18 June 2006 (UTC)

I really like the suggestion that the MediaWiki software not list sub-templates.

I should have commented "isValidPageName". FYI, it determines whether its argument is a valid page name. It fills a gap missing from our lacking StringFunctions. The inflection templates use "isValidPageName" (or they would use "StringFunctions" if they were available) to determine whether an argument includes markup. They then wikilink valid page names and do not wikilink others. So, "{{en-verb|'''[[has]] '''or, archaic,''' [[hath]]'''|having|had}}" automatically links "having" and "had" but leaves the "'''[[has]] '''or, archaic,''' [[hath]]'''" text unadorned. Rod (A. Smith) 17:41, 18 June 2006 (UTC)

I recommend filing a feature request aksing for different CSS classes around directly included template names and indirectly included template names. That way we can for example globally hide the indirect ones and people who want them all can have them all and other wikis which don't want anything changed won't see any changes. Somebody could even trivially come up with a JS extension that provides a button to hide/show the various levels. — Hippietrail 02:38, 20 June 2006 (UTC)

For this situation I think there's probably a more direct solution. The cattag mess will also be completely revamped when string functions are available to extract a tag from its parenthesis. Davilla 04:05, 20 June 2006 (UTC)