Template talk:Template parameter value

Is using this going to cause problems?

This template is now used in a template {{Annotated link}} with the potential of being used several hundred times in some articles (that is several hundred times in the same article) and in hundreds or possibly thousands of articles. I have just seen the deletion discussion, and it does not fill me with confidence. Will this do what I want it to, or is something going to break spectacularly? Please ping with reply. Cheers, · · · Peter (Southwood) ^(talk): 11:15, 15 September 2018 (UTC)

@Pbsouthwood: Taking a look at the documentation, I see no reason why this would break. It'll do what you want. It's already in used in hundreds of articles in {{Aired episodes}} with no issues. -- Alex^TW 11:26, 15 September 2018 (UTC)

Thanks, I will take your word for that as I do not have the detail knowledge to work it out for myself. Cheers, · · · Peter (Southwood) ^(talk): 12:00, 15 September 2018 (UTC)

Bug with pipped links

Moved from Module talk:Template parameter value

 – * Pppery * _{it has begun...} 23:21, 24 October 2019 (UTC)

There is currently a bug with piped links, see example below:

• {{Template parameter value|Charmander|Infobox video game character|1|firstgame|1}} ->

The result should have been [[Pokémon Red and Blue|''Pokémon Red'' and ''Blue'']]. --Gonnym (talk) 19:48, 1 February 2019 (UTC)

I am aware, and I've been looking into fixing this. Cheers. -- /Alex/₂₁ 22:49, 1 February 2019 (UTC)

Not handling nesting correctly

Moved from Module talk:Template parameter value

 – * Pppery * _{it has begun...} 23:21, 24 October 2019 (UTC)

If a parameter value includes a single nested transclusion (multiple ones are not handled), the last match() does not work correctly. In my fork, I have changed

content = string.match(content, '^([^|}]*{{[^}]+}}[^|}]*)|') or string.match(content, '([^|}]+)')

to

content = string.match(content, '^([^|{}]*{{[^}]+}}[^|}]*)[|}]') or string.match(content, '([^|}]+)')

The next line then preprocess()es the transclussion correctly, as was its intention. This was likely not found before, because short-descriptions shouldn't have such, but my fork does.

Dpleibovitz (talk) 23:34, 12 May 2019 (UTC)

Problem when unnamed parameter is labeled with number

In some cases, it is necessary to label an unnamed parameter with a number, like |1=. A common case is when the parameter's value contains an equals sign (=).

When this template attempts to extract the value of the first unnamed parameter, it does so incorrectly. This invocation:

{{Template parameter value|Outline of bicycles|Short description|1|1|1}}

should yield:

Overview of and topical guide to bicycles

But it instead yields:

1=Overview of and topical guide to bicycles

This is causing trouble with {{Annotated link}}. See Template talk:Annotated link for details.

Can someone please attempt to fix this bug? – Jonesey95 (talk) 16:37, 19 January 2020 (UTC)

Well crap, I just spent an hour debugging what turns out to be exactly this same situation (the 1= trick to pass a parameter containing an equals-sign breaking weirdly in the short-description/annotated-link handlers). DMacks (talk) 17:54, 10 March 2021 (UTC)

And it's actually worse than just an explicitly-numbered positional parameter. In:

{{foo|x=y}}

the positional {{{1}}} parameter is null, but {{template parameter value}} returns "x=y". That's in the first slot after the template-name, but it's named to other than parameter "1". DMacks (talk) 18:01, 10 March 2021 (UTC)

• {{SDlink}} was created to work around this problem — GhostInTheMachine ^{talk to me} 10:56, 14 March 2021 (UTC)

Redirects

This template works great for me--truly a Godsend!--except if pages get moved/renamed, as it doesn't recognise redirects. I took a stab at adding that functionality in the module's sandbox, but so far have failed (it shouldn't be too hard; just my Lua is now rusty). Can a blessed soul please shed some light? Cheers. — Guarapiranga ☎ 12:13, 8 May 2022 (UTC)

Broken instance

Trying to use {{Template parameter value|Template:Adminstats/GorillaWarfare|Adminstats/core|1|ed}} at Molly White (writer), I'm getting no result:

Any idea what I'm doing wrong or what's broken? {{u|Sdkb}} ^talk 17:36, 30 May 2022 (UTC)

No clue why TPV isn't working, but it isn't necessary here -> {{Adminstats/GorillaWarfare|style=raw ed+del}} -> 25424. That is, if it's appropriate to include a live-updating edit count at all, which I'm not convinced of (do any sources make that connection?). * Pppery * _{it has begun...} 17:52, 30 May 2022 (UTC)

... and the template in question hasn't been updated since 2013 for some reason. * Pppery * _{it has begun...} 17:55, 30 May 2022 (UTC)

Thanks, @Pppery! That's a much simpler solution lol. And yes, I noticed the lack of updating; I assume that's because the template wasn't used anywhere, so I'll put it in my sandbox for a day or two and see if it updates. On necessity, I'm going to have it round to a more approximate count, the same as it currently does. {{u|Sdkb}} ^talk 18:44, 30 May 2022 (UTC)

There is now a case insensitive version of this template...

... in the sandbox. And

are test cases. — Guarapiranga ☎ 23:13, 15 June 2022 (UTC)

Expensive call

An issue was brought up at Template talk:Annotated link#Is this template very expensive, or am I doing it wrong? {{Annotated link|Table of bases}} makes two calls (I think) of {{Template parameter value|Table of bases|Short description|1|1|1}}. A single call has "Lua time usage 5.500/10.000 seconds". Two calls fails with "The time allocated for running scripts has expired". Table of bases has a table with around 9000 cells. PrimeHunter (talk) 13:04, 19 November 2022 (UTC)

in case it is relevant, table of bases has a WP:short description of "none", for which the template has special handling. --𝕁𝕄𝔽 (talk) 18:51, 19 November 2022 (UTC)

That was yesterday.[1] It currently says {{Short description|0 to 74 in base 2 to 36}}. PrimeHunter (talk) 23:46, 19 November 2022 (UTC)

Improved version

Aidan9382 has been working on an improved version in Module:Template parameter value/sandbox with a new ignoreSubtemplates option, and some other improvements. Aidan, please give the details :) — Martin (MSGJ · talk) 13:08, 21 February 2023 (UTC)

Sure. I've been working on a major change to the module to try and make it more robust compared to the current implementation, which can quickly fall apart given a complex situation for a number of reasons. There are a lot of changes, so I've tried to summarise the key points below.

• Bug fixes
  • Template grabbing is now correctly restricted. Instead of grabbing all wikitext to exist beyond the start of the template, it will now stop at the end of the template to avoid processing further. This is mainly to prevent extreme GIGO.
  • Numerical indexes can now be grabbed regardless of if they are referred to as |1=XYZ or |XYZ. Numerical index grabbing should also be far more reliable in general for the reason provided below.
  • The entire fetching of parameters has been changed, using Module:Transcluder's getParameters function instead of regexs, which ensures parameters are grabbed faithfully, avoiding unreasonble cutoffs (having the value {{{1|XYZ}}} becoming {{{1 or having grabbing W from {{XYZ|W={{ABC|1|2|3}}}} return {{ABC), making subtemplate grabbing possible.
• New features
  • ignore_subtemplates or ist (better name suggestions welcome) - enabling this will avoid capturing the parameters of any subtemplates. This allows for much safer targetting (E.g. instead of looking for the 3rd occurance of _P in the first occurance of PT in {{PT|1={{T1|_P=A}}, {{T2|_P=B}}|_P=C}}, which could easily be broken by a number of changes (moving of the _P, adding another subtemplate involving _P, etc), you can simply look for _P in PT while ignoring subtemplates), which rules out most chances for GIGO or later maintenance.
  • A module entry point (p.getValue) to allow this to be used by both modules and templates (how the options table works will be properly documented in /doc if implemented).
• Notes
  • In terms of backwards compatability and replicated existing behaviour, I've tried as hard as I can tokeep the behaviour of the current module the same as it was. For this reason, the ignore subtemplates option is off by default, as this is how the existing implementation functions in practice. Most existing implementations should, therefore, not require maintenance. However, there are some intentional breaking changes.
    • One is that templates will no longer match if just the start of the name is the same, instead requiring the entire name of the template to match. This means that examples like one on the doc page ({{Template parameter value|Vikings (season 4)|Episode list|2|LineColor}}, since changed) would not work, as the template it actually wants is Episode list/sublist, and the template parameter would need to be modified to accomodate this.
    • Another is that numbered parameters are handled differently. This means the behaviour seen in the above section, #Problem when unnamed parameter is labeled with number, would no longer occur, as instead of looking for the 3rd pipe, it will instead look for the parameter 3. This doesn't present concerns if the entire template uses numerical parameters, but if it was to use both numbered and not numbered, this could quickly cause problems with not grabbing what it initially did, but there's no way to fix this in the code without making the functionality objectively worse, so these should also be manually fixed.
  • Note, however, that I've looked through most of the 59 active uses (the rest are indirect transclusions) of the template as of now, and can't find a case where these changes cause problems (except for this which I've fixed), so this should be fine. Infact, this would fix some issues on current pages (See here and here). There may also be other breaking changes I haven't noticed given the lack of available testcases other than whats available on the /doc (tested here), but this should be unlikely.
  • Couple of questions for those technically knowledgable about this module: is there any specific reason for this line which removes newlines or this line which preprocess the text? I'm confused what purpose the first one has and I can't think of a good reason to keep the second since it feels excessive (what if we want the raw? what do we do then?). I've left them implemented for now, but I'd be willing to remove them if there's no reason to keep them around.

These changes could also render {{Get parameter}} redundant, as the premise of that template was one that, while worse than this one in most situations, could supposedly handle more complex syntax than what this originally could. Considering this is no longer the case, chances are that template could probably be merged/replaced with this one if the change is implemented. I've left below a comparison using the example given on it's doc page to show it's up for the job.

{{Get parameter}} vs live and sandbox of {{Template parameter value}}
{{get parameter|inventors|Infobox instrument|Template:Infobox saxophone}} → Adolphe Sax {{Template parameter value|Template:Infobox saxophone|Infobox instrument|inventors}} → Adolphe Sax {{Template parameter value/sandbox|Template:Infobox saxophone|Infobox instrument|inventors}} → Adolphe Sax

Thougts? Aidan9382 _(talk) 18:10, 21 February 2023 (UTC)

@User:Alex 21 would you like to comment? — Martin (MSGJ · talk) 22:09, 21 February 2023 (UTC)

Oh absolutely, if there's a more improved version then I absolutely support it replacing this version. I always meant to get around to fixing it properly, as I do recognize how buggy this template is, given that I created it almost five years ago. -- Alex_21 _TALK 22:35, 21 February 2023 (UTC)

@MSGJ and Alex 21: If there's no issues with the new version, I'll probably go ahead and implement it into live soon. But before that - Alex 21, whats the purpose of this line removing newlines from the content? was it some limitation of the previous regexs used or is there some other reason to not want newlines? Aidan9382 _(talk) 20:59, 1 March 2023 (UTC)

If I recall properly, this version would only work if all the content was on the same "line", as it were, in case parameter values were spread across multiple new lines. (I think. It's been five years since I created this infernal mod.) If, however, the new version does not need this, then by all means I'm fine with its removal. -- Alex_21 _TALK 06:52, 2 March 2023 (UTC)

I can't imagine a reason the new system needs to worry about newlines screwing anything up, so I've gone ahead and removed that. Thanks for the input. I'll probably release the update within a few hours, just doing a final check to make sure nothing falls apart (I've re-added preprocessing to the Template's entry point after realising text like {{{ABC|XYZ}}} doesn't get evaluated automatically into XYZ when coming out of a module, which I wasn't expecting). Aidan9382 _(talk) 14:06, 2 March 2023 (UTC)

I've pushed the changes and updated the docs with some details and templatedata (feel free to expand upon it, as I'm quite bad at explaining things). Hopefully this new version helps out. Aidan9382 _(talk) 21:56, 2 March 2023 (UTC)

Thanks for your work on this! — Martin (MSGJ · talk) 21:58, 2 March 2023 (UTC)

Error at List of The Great North episodes

@Aidan9382: Could you look into why this is happening? The minimal reproducer seems to be {{template parameter value|The Great North|Infobox television|1|num_episodes|1}}, which worked in the old version but not the new version. * Pppery * _{it has begun...} 00:07, 3 March 2023 (UTC)

@Pppery: The issue appears to be coming from the comment inside the infobox, <!--Please do NOT change to {{Plainlist| as this is [...]-->. The new version doesn't want to overgrab content, so it will try match from the start to the end of the template using {%b{}}, but the comment means the template never finishes matching cause the count is unbalanced. In this case, Infobox television will be the only template there that doesn't get picked up, and all other templates capture fine. I'll work on something to temporarily remove comments during processing, which should get around this issue. Surprised I hadn't caught this during testing though - sorry about that. Aidan9382 _(talk) 04:50, 3 March 2023 (UTC)

Should be fixed for that page, as well as any other similar failed case involving comments. If you find any other processing errors I missed, do let me know. Thanks! Aidan9382 _(talk) 05:10, 3 March 2023 (UTC)

Ignore blank values

Is there any way to find the first non-blank parameter? For example on the page

{{WPBS|
{{WikiProject Fungi|class=|importance=low}}
{{WikiProject Rabbits|class=stub|importance=low}}
}}

I would like

{{template parameter value|{{FULLPAGENAME}}|WPSB||class}}

to equal "stub" rather than blank. Any ideas? — Martin (MSGJ · talk) 21:17, 28 April 2023 (UTC)

There's no existing way to do this right now. I have 2 ideas in mind - either a parameter like ignoreblank in which the code would just pretend blank parameters don't exist, or an option to have it return all the parameters under the requested template and let whatever is using it figure out what it wants itself (though I'm not sure how this would work for the template entry point). Thoughts? Aidan9382 _(talk) 22:40, 28 April 2023 (UTC)

I could see the utility in both options. For now, ignoreblank would probably do exactly what I need. But I could certainly see the use case for returning a table of all values in case further processing was needed. I think we had a similar conversation about ignoring blank values on another talk page, but can't quite remember what we decided ... — Martin (MSGJ · talk) 21:58, 29 April 2023 (UTC)

You might be thinking about User talk:Aidan9382#Question, though that was more about there not being a parameter period. I've implemented some test code that should create the effect you asked for. Using {{Outer| {{Inner1|class=}} {{Inner2|class=a}} {{Inner3|class=}} {{Inner4|class=b}} }} as an example input, the output currently goes as follows:

Examples

{{Template parameter value|PAGE|Outer||class}} -> Blank {{Template parameter value|PAGE|Outer||class|2}} -> a {{Template parameter value|PAGE|Outer||class|4}} -> b {{Template parameter value|PAGE|Outer||class|ignore_blank=y}} -> a {{Template parameter value|PAGE|Outer||class|ignore_blank=y|2}} -> b {{Template parameter value|PAGE|Outer||class|ignore_blank=y|4}} -> No parameter found, since there's only 2 non-blank parameters

Does this sound right? Aidan9382 _(talk) 07:22, 30 April 2023 (UTC)

Looks great. I assume this will work with positionals too? — Martin (MSGJ · talk) 17:09, 30 April 2023 (UTC)

Assuming you mean {{Template|X||Z}}, yes, since positionals are treated like every other parameter. Aidan9382 _(talk) 19:42, 30 April 2023 (UTC)

Please let me know when this feature is available, thanks — Martin (MSGJ · talk) 11:37, 2 May 2023 (UTC)

I'll leave a reply here once it's up and active. Aidan9382 _(talk) 15:36, 2 May 2023 (UTC)

Question: if |ignore_blank=true and only blank parameters are found, should success be returned true or false? — Martin (MSGJ · talk) 14:30, 2 May 2023 (UTC)

The success state will continue to return true regardless of if a non-blank parameter is found, as it only returns false when the template or page itself can't be found. That behaviour is based off of the conversation on this thread on my talk page, down near the end. Aidan9382 _(talk) 15:36, 2 May 2023 (UTC)

Show only subtemplates

One more small request. Would a show_only_subtemplates parameter be possible, to complement ignore_subtemplates? — Martin (MSGJ · talk) 12:47, 2 May 2023 (UTC)

I can probably make this, yes, though I may not name the option that exactly. I'll see what I can work up in the sandbox. Aidan9382 _(talk) 15:36, 2 May 2023 (UTC)

I've implemented this in the sandbox as only_subtemplates. If the functionality for this and ignore_blank seem fine, I'll go ahead and push these changes. Aidan9382 _(talk) 18:59, 2 May 2023 (UTC)

Haven't tested extensively, but seems to work well for my use case. I'm sure there is a good reason to use different parameter names for the invokable vs direct call, i.e. only_subtemplates vs onlySubtemplates, but it keeps confusing me ... — Martin (MSGJ · talk) 21:11, 2 May 2023 (UTC)

There is no good reason, I just had ended up doing it that way when I was initially making it. Infact, I've now made it accept both forms for the module entry point to fix the inconsistency of the module entry point without breaking existing uses. Aidan9382 _(talk) 05:47, 3 May 2023 (UTC)

Great - I've switched my uses to the underscore method if you want to settle on that form — Martin (MSGJ · talk) 11:36, 3 May 2023 (UTC)

Thanks for that. I'll likely work on migrating away from camelCase entirely over time and then eventually removing it from the code to match the template usage, but for now I'll support both through the module entry point. I've gone ahead and pushed the changes to live aswell, so both ignore_blank and only_subtemplates are now available. I'll update the documentation later when I've got time. Aidan9382 _(talk) 12:09, 3 May 2023 (UTC)

Many thanks — Martin (MSGJ · talk) 13:39, 3 May 2023 (UTC)

Case sensitive

{{article assessment}} and {{Article assessment}} refers to the same template, but currently this module does not treat them the same. Please could you make the first letter case-insensitive? — Martin (MSGJ · talk) 12:02, 29 June 2023 (UTC)

@MSGJ  Done I believe this should work now. (Any other Lua programmer, correct me if I've done anything wrong.) -- Alex_21 _TALK 12:55, 29 June 2023 (UTC)

Works a treat, thank you! Bit surprised I didn't discover this earlier — Martin (MSGJ · talk) 07:54, 30 June 2023 (UTC)

Bizarre and inexplicable bug

This just plain deadass does not work on Wikipedia:Wikipedia Signpost/Templates/Signpost-article-header-v2. I have extensively tried to debug this and not come up with anything at all. I'll post my research on this below. jp×g🗯️ 00:23, 23 December 2023 (UTC)

Essentially:

{{Template parameter value|Wikipedia:Wikipedia Signpost/Next issue/Arbitration report|Signpost draft|1|piccyfilename|1}} works fine.

Exact same formatting of same parameter with same value on a different page with a different template.

{{Template parameter value|Wikipedia:Wikipedia Signpost/2023-11-06/Arbitration report|Wikipedia:Wikipedia Signpost/Templates/Signpost-article-header-v2|1|piccyfilename|1}}: BUSTED!

Returns nothing. This is completely fixed if I change the name of the template in the article's code to {{Asdfasdfasdf}} and then change the template parameter value to be scraping params out of Asdfasdfasdf and run it on the exact same page. Same params, same page, same code. But different template name!

{{Template parameter value|Wikipedia:Wikipedia Signpost/2023-11-06/Arbitration report|Wikipedia:Wikipedia Signpost/Templates/RSS description|1|1|1}}

This works fine -- same page. Every template can be parsed out of the page except article-header-v2 for some reason.

• Title issues, parsing other stuff wrong and getting the wrong pages, etc. No because it gets the RSS fine.
• Module can't process linebreaks in template No because it does it fine for the draft template params.
• Weird thing with the {{{1|title goes here}}} thing No because it also completely woofs on the piccy params which are totally normal. In fact they are LITERALLY THE EXACT SAME in the draft article and in the article article (whitespace etc) but work for the draft and not the article.
• Module requires templates to start with Template: Then why does it work for Wikipedia:Wikipedia Signpost/Templates/RSS description?
• Module woofs when there's wikitext in a template: This is possible, the RSS template has no wikitext and the article header template does. Hmmmm.

Yeah there's no wikitext at all in the draft template. If I add some will it break? Then I will know it's this.

NO: it works fine when I put link text in the draft template, and the article one doesn't work even when I remove all wikitext from the header template.

What is going on here? Does anybody have any idea why this specific header template would cause the module to fail completely? jp×g🗯️ 00:28, 23 December 2023 (UTC)

@JPxG: After a quick look, the issue appears to be how the wanted template text is handled (the template name is getting treated like a regex, and - is a lua regex term that is equivilant to *? in standard regex). The module probably shouldn't be automatically treating inputs as regex and instead escaping them beforehand unless specified otherwise, so I'll work on implementing that, just need to make sure it won't break any existing uses first. Aidan9382 _(talk) 07:02, 23 December 2023 (UTC)

After getting distracted for long enough doing other things, I've done what I said above (your use case should now work fine), and left in treat_as_regex (better naming ideas welcome) to allow treating the template name as a regex match (which no existing use cases appear to do anyways). Aidan9382 _(talk) 14:17, 23 December 2023 (UTC)

Wow, it's beautiful. Excellent! I wouldn't have dreamed of a fix the next day -- I figured I was just whining into the void. Thank you very much for this. jp×g🗯️ 14:21, 24 December 2023 (UTC)

Can it just detect if the template is there

Hi, I looked everywhere for a template or module that can simply detect whether a template exists on a page, and couldn't find one; basically I'd like something similar to Cirrus hastemplate except returns boolean. My use cases involve searching for templates on redirect pages; for example, I'd like to do something like this:

• {{hastemplate|Transgender history in Australia|R with possibilities}} ⟶ 1
• {{hastemplate|Transgender history in Cambodia|R with possibilities}} ⟶ 0 (or maybe better, return empty, for #if test)

If you know of a template that does this, can you link it for me? Otherwise, tmpv already knows whether a template is on the page, so could we extend parameter usage a bit to do this?

• {{tmpv|Transgender history in Australia|R with possibilities}} ⟶ 1 if the template exists on the page, else empty
• {{tmpv|Transgender history in Australia|R with possibilities|8}} ⟶ 1 if the template exists 8 (or more) times on the page, else empty

If the top one is problematic due to param value defaulting, then maybe this to make it explicit:

• {{tmpv|Transgender history in Australia|R with possibilities|0}} ⟶ 1 if the template exists on the page, else empty

I could probably brute-force this with a couple of functions in Module:String, but it seems a shame when something like this either exists as a template already, or might be a not too complex enhancement to tmpv. Thanks! Mathglot (talk) 22:20, 14 February 2024 (UTC)

Yes, the getValue function in Module:Template parameter value will return false if the template does not exist on the page — Martin (MSGJ · talk) 22:45, 14 February 2024 (UTC)

Perfect! Thank you. Maybe it's worth wrapping that, unless there's a reason not to. Mathglot (talk) 22:56, 14 February 2024 (UTC)

I'm getting a missing param error with:

{{#invoke:Template parameter value|getValue|Transgender history in Australia|R with possibilities}}

That gives me falseMissing required parameters 'templates' and 'parameter', which seems consistent with line 92. Or am I invoking it wrong? The module doc is rather thin, and it's hard to tell. Mathglot (talk) 23:07, 14 February 2024 (UTC)

getValue is designed to be a module entry point, while main is designed to be a template entry point (essentially a wrapper for getValue). Invoking getValue as a template will never work, since you can only ever pass the frame, and getValue expects 2 arguments at least. Also, main currently returns an empty string upon failing in any way, so testing for errors via that will not work either.

I could see adding a simplified version of the getValue function called hasTemplate or something similar as a new template method, which would purely test if the wanted template exist, or modifying getValue and main to support no parameter given to mean a template test (though the usage of such a thing may appear unintuitive, as something called "parameter value" wouldn't be doing anything with parameters), or just having main report its errors through the template method. Do any of these sound particularly useful? Aidan9382 _(talk) 07:21, 15 February 2024 (UTC)

Possibly, but before we get to that, let me start with the failed call above. I was trying to follow what MSGJ was telling me, but I think I made a mistake because it didn't work, so what did I do wrong? I don't absolutely need to have a template that works around it and am happy to invoke the Module alone, if I can get it to work. In the direct module invocation above, what am I doing wrong? I am not using the 'main', I'm using the getValue entry point but it still fails to return a value, because, if I understand correctly what the code near line 91 is doing, you cannot use getValue without a parameter name in arg3. Am I reading that right? Mathglot (talk) 07:34, 15 February 2024 (UTC)

main is simply a wrapper that provides the parameters from a frame into getValue. Yes, getValue itself will not run without a parameter to look for (which is arg 3 in a template invocation or parameter 2 in a module invocation), since that's a core part of the current functionality. I think MSGJ was probably talking about using it from a module perspective for getting false and the error message to return, as this isn't something you can currently do via a template invocation (see line 162). Aidan9382 _(talk) 07:39, 15 February 2024 (UTC)

We can make an invokable function for you. hasTemplate is probably a good name for it as Aidan suggested — Martin (MSGJ · talk) 10:43, 15 February 2024 (UTC)

Yes, that sounds ideal. Mathglot (talk) 18:33, 15 February 2024 (UTC)

I notice that Aidan has been tinkering in the sandbox, so you might like to test it.

{{#invoke:Template parameter value/sandbox|hasTemplate|Transgender history in Australia|R with possibilities}}

makes "yes"

{{#invoke:Template parameter value/sandbox|hasTemplate|Transgender history in Cambodia|R with possibilities}}

makes "" — Martin (MSGJ · talk) 21:45, 15 February 2024 (UTC)

Oh cool; this is really helpful, I'm going to do some more tests, but what you show above is spot-on. Mathglot (talk) 21:52, 15 February 2024 (UTC)

It also includes checking if N templates exist (arg 3) and replacing the default returns of "yes" and "" using args 4 and 5 (I'll update the module docs with all of this once sandbox is moved over to make it clear). If there's no other feature requests or issues in regards to this, I'd say its ready to be put into live. Aidan9382 _(talk) 22:13, 15 February 2024 (UTC)

Great, thank you. I do have another request, but will probably be better to make it a fresh request, as I don't want to hold anything up. I would like to be able to detect if a template is nested inside a certain other template. For example, a WikiProject banner template inside WikiProject banner shell. — Martin (MSGJ · talk) 22:21, 15 February 2024 (UTC)

Unfortunately, with how the current system works, there isn't a nice simple way to tell if a template is inside another template, nor can I think of a good way to generalise such a feature to work in this module (unless you have some suggestions or a more specific use case). However, the module does expose its methods like getTemplate, getParameters, and getAllParameters, which might help you do whatever you intend manually if this is via a module (E.g. if your intention is to get the parameters of templates only when under a specific template, you could look towards a combination of getTemplate(parentTemplate) and getAllParameters(template, false, true), or if it's literally just to check for presence, getTemplate(parentTemplate) and a basic regex check, etc. etc.). There is also technically Module:Wikitext Parsing's ParseTemplates method, which has the concept of template children, but it's a little intensive (and likely overkill). Aidan9382 _(talk) 06:29, 16 February 2024 (UTC)

That's fine. It's not urgent, so plenty of time to think about it. I thought perhaps that some of the logic was already there, with the only_subtemplates option — Martin (MSGJ · talk) 09:08, 16 February 2024 (UTC)

(edit conflict) I'm very appreciative of this; thank you. Working on Draft:HasTemplate as we speak. Basic functionality is working; more to come. Will move to Template: space only when I get the green light here. Mathglot (talk) 22:27, 15 February 2024 (UTC)

Looks good. I was just thinking it might make sense to use named parameters in the module, rather than 1, 2, 3, 4? — Martin (MSGJ · talk) 22:31, 15 February 2024 (UTC)

Looks like they are already are; see main module entry point at line 91. Did you mean the template? All template parameters have names as well as positional id's, as shown in the doc, so you can specify them either way. Mathglot (talk) 06:03, 16 February 2024 (UTC)

I've added the ability to use named parameters on top of positional parameters at the module level in the sandbox, if that's what you meant. Aidan9382 _(talk) 06:29, 16 February 2024 (UTC)

Perfect. I've updated the template doc to use named parameters too. — Martin (MSGJ · talk) 09:09, 16 February 2024 (UTC)

Aidan, I'm now finished with the initial version of Draft:HasTemplate, and ready to move it to Template space, which should happen after two conditions are met:

• the Module sandbox is released to live, and
• you (and any interested parties) have had at least a glance at Draft:HasTemplate, and don't see any objections to its release.

This has been a great collaboration, will help readers (ultimately) and editors (sooner; on WikiProjects especially, imho) and I'm very happy about how this has all unfolded. No hurry whatever, but lmk when we're good for Draft template release. Mathglot (talk) 08:31, 16 February 2024 (UTC)

One of the major advantages of Lua modules is that we don't need to pass every parameter because the module can look "beyond the template" to the parent frame. So I have simplified your template somewhat. If this "follow redirects" functionality is going to be used, we could add that to the module too? — Martin (MSGJ · talk) 09:10, 16 February 2024 (UTC)

I need to understand better how that "beyond" business works, because I can see that the module is picking up args that aren't mentioned in the template code. Do you have a link that explains that? I imagine it's on mw: somewhere? Thanks, Mathglot (talk) 10:00, 16 February 2024 (UTC)

Perhaps try Module:Arguments#Frames and parent frames — Martin (MSGJ · talk) 10:11, 16 February 2024 (UTC)

Thanks! Mathglot (talk) 20:54, 16 February 2024 (UTC)

Depending on the discussion below about handling parameters, I could definitely look at implementing this in hasTemplate at the module level. It would be weird to have follow be an option at a template level but not the #invoke: level. Aidan9382 _(talk) 21:44, 16 February 2024 (UTC)

The only issue I'm noticing during testing is that since both hastemplate and the module use arg 4 for different purposes, there's a little bit of overlap in functionality and it generates some odd behaviour. We should probably either make hastemplate only support "follow" and not "follow/4" or make the module only support "yes/no" instead of "4/5", or even both for parameter clarity. Thoughts? Aidan9382 _(talk) 17:21, 16 February 2024 (UTC)

Given the "beyond frame" business that I was and am unfamiliar with, I get the gist that it is advantageous to have the template and module params aligned in order to preserve an economy of coding in the template—is that the main point?—but there is a flip side for template editors, in that it is very unclear what's going on and makes modification of the template more difficult to a certain extent. Even if all the params were scrambled, say, with template#4 pointing to module#1, and all the other params specifically coded in the template and similarly reversed, this would pose no problems to a template editor, and a template user consulting the template doc page would similarly have no problems as that is all that they would see. I guess what I am saying is, two things:

• What is the benefit of the current compact template code (that is, rev. 1208041529 or the even briefer 1208029309‎), as opposed to rev. 1208016105‎ which specifically coded each of the four params and passed them to the module in such a way as to elicit the proper response in all cases, vs. the admittedly much shorter (is efficiency an issue here? I kind of doubt it) and perhaps more elegant from a module point of view in version 1208028565‎ without mentioning params 2 and 3 (and which didn't work, in the "follow redirects" case; since fixed)?
• Not sure I follow the "follow/4/5", but I'm always in favor of more power or functionality if we can get it, so what is that about? Guessing, here, I had considered on the template side whether it would be useful to be able to follow a redirect chain (and how far), but then I thought, there's a bot in Wikipedia that removes double redirects, so in theory, there should only ever be a small number of them. Do we want to be able to crawl a chain of redirects anyway? I decided it was pointless, mostly because it would make it slightly more confusing for the template user reading the doc and trying to use the template, but if there's a good reason to have it, I'm not opposed. That said, there's a clear need for the template user to be able to follow at least one redirect, and I have no strong objection to providing the ability to traverse a redirect chain to a user-specified limit, if others see value in that. (But maybe I guessed entirely wrong about what you meant, there.)

Not even sure I've answered your question, but as you are familiar with the module, as well as by now the template as well I assume, including the part that's still tricky for me about how unmentioned params in the template end up getting passed anyway, I think I'd just defer to your judgment on this, as long as we are optimizing the overall design in both places in this priority: general reading public first (probably doesn't apply in this case), template users, module users, template editors, module editors (not everyone agrees with my philosophy on that, and you don't have to, but that's my priority chain). Please ask again if I've gone off on a tangent here. Maybe I could respond better if I knew what the "follow/4" or "4/5" meant, as I was mostly guessing. Mathglot (talk) 20:54, 16 February 2024 (UTC)

Sorry, that's mostly my fault for not explaining in detail. I'll try mention all the details I can (I'll address both of your bullet points).

• Regarding the compact template code, there isn't specifically a benefit for doing it compact or not afaik, at least in this case, beyond very minor speed improvements in Module:Arguments (which is a non-issue here). That one is mostly just a visual preference. Other templates like {{pp-dispute}} do the same. Personally, I wouldn't agree that Special:Diff/1208029309 is a benifit, since positional arguments in this context should be easy to infer and wouldn't hamper readability, and would make the template easier to use (specifically with changing page to just named, since that actually breaks using follow and 1).
• Let me explain what I mean by follow/4/5. Currently, the template has 4 arguments - In order, these are the page, the template, the template index (optional), and if the page is followed if it is a redirect (optional). The module has 5 arguments - In order, these are the page, the template, the template index (optional), alternative text for yes (optional), alternative text for no (optional). When you attempt to specify that you want to follow a redirect by using argument 4 in the template, it also triggers the module into using alternative text for if the template is found. My question was whether to remove the positional parts of one or both of those (E.g. only allowing {{{follow}}}, not {{{follow|{{{4}}}}}}, and using parameters called yes/no instead of position 4/5 for giving alternative text for success and failure). I was specifically asking which should be replaced, or if both should be replaced (I think having these be positional arguments could be confusing behaviour for on-looking template editors, and I'd say I pretty much agree with your design priority ordering, so I think forcing both to be named parameters would be a good choice for readability and usage). Hopefully that's a bit clearer.

As for the whole frame and parent frame thing, I don't have a great explanation I can come up with off the top of my head, but the short gist of it is that a module is able to access the arguments from both the module invocation and (I think) the highest level template invocation, which could be helpful in some circumstances (I can't think of any off the top of my head but if one comes to mind I'll link it here). The best explanation I can find is mw:Extension:Scribunto/Lua reference manual#frame:getParent, which is only loosely related. Aidan9382 _(talk) 21:38, 16 February 2024 (UTC)

If it helps make my bullet point 2 any clearer, I'm proposing Special:Diff/1208245183 and Special:Diff/1208245490. Aidan9382 _(talk) 21:46, 16 February 2024 (UTC)

My gut reaction is that that sounds good. Iiuc, the first three template params would remain positional or named, and the "follow" would be named-only; that makes sense to me, and is kind of analogous to the {{sfn}}-page param that I alluded to earlier (but lower down on the page) in a different context. I appreciate the detailed explanation, and because a lot of this is new to me, I haven't entirely digested it yet and am going to go through it in more detail, so conceivably I would learn something that might change my response, but at this point, I'm comfortable with your proposal and it seems like a natural design for the template. Let me think about this a bit more, but I think your proposal seems like the best one, and I support it. Mathglot (talk) 22:48, 16 February 2024 (UTC)

To be clear what I'm agreeing with , it's to only allow {{{follow}}}, not {{{follow|{{{4}}}}}} in the template. As far as only "yes" or "no" I wouldn't support that, due to a tradition of allow yes/y/Y/YES/1/true and so on; see highly-used template {{yesno}} and variants for why this is so. Mathglot (talk) 22:53, 16 February 2024 (UTC)

After a bit of a think about it, I've considered that changing the outputs of the module in the module is probably a bit excessive. This can just as easily (and probably more intuitively when looking at it from a distance) be done by a simple {{#if:}} wrapping. I've removed that code, which makes the parameters far simpler. Aidan9382 _(talk) 07:41, 17 February 2024 (UTC)

Sounds good; I'm all for simpler. Mathglot (talk) 07:46, 17 February 2024 (UTC)

I have a personal dislike for unnamed parameters, although I have used them myself on ssveral occasions in limited circumstances :) For one, you have to remember which order to put the parameters, which is unnatural and that makes is more likely that you will need to read the template/module documentation again before using. Secondly, it causes problems if any of the parameters are blank because then all the parameters move position unless you explicitly enter a blank parameter. (That is part of the problem with the 4/5 above I guess.) So all in all, I recommend the named parameter approach — Martin (MSGJ · talk) 21:58, 16 February 2024 (UTC)

That would overturn custom and convention of decades of template usage at Wikipedia. That seems a futile undertaking, but if you wished to do that, this isn't the venue. Many templates have positional-only params, many have a mix of positional and named, such as the ubiquitous and crucial-for-verifiability {{sfn}} template, which provides only positional params for citing the key verifiability fields of author and year of publication. There's also an economy of space in using positional params, many templates have a natural or customary order (and when only some of the parameters have a natural or customary order, then, like {{sfn}}, there is a combination of positional and named parameters–e.g. named in the case of page number–which nobody has any problem with), and finally, the original version of Draft:HasTemplate gave you the ability to use either positional or named parameters, so that it already provided for your preference, so why change that just to remove the ability to use positional params? I understand your preference for named params and I don't object to your using the template exclusively with named params whenever you employ it; please don't make it impossible for users to use positional params if they have a different preference. Mathglot (talk) 22:36, 16 February 2024 (UTC)

I would strongly recommend you to use named parameters to make your template code clearer and easier to understand for other editors. Just because other templates have been used with positional parameters does not mean it is necessarily a good idea :) I am not interested in changing the whole of Wikipedia, but it seems a good opportunity whenever new templates are created. You will find that all most templates (other than the most simple) use named parameters, for this reason. Yes {{sfn}} is a ghastly example of what not to do, and unnecesarily increases the complexity of template code! — Martin (MSGJ · talk) 23:11, 23 February 2024 (UTC)

This is the wrong venue for this discussion. I'd be happy to respond if you start a discussion at a centralized venue. Mathglot (talk) 01:32, 24 February 2024 (UTC)

Disposition

How is everyone feeling about this? On the one hand, there's no particular hurry, but on the other, discussion appears to have quiesced, and the module and template are now in sync, with Draft:HasTemplate being as lean as it can get. From my PoV, I'm happy with both the current Module sandbox, and the Draft template. Should we wait to see if anyone weighs in, or would it be better to release it to see if that elicits further feedback once it's live? Mathglot (talk) 02:44, 20 February 2024 (UTC)

This template isn't particularly watched, so I don't imagine anyone else is likely to weigh in here unless you advertise something. At this point I'm fine with the state of the module and am happy for the new code to be pushed to live if there's no more suggested changes to the current behaviour. Aidan9382 _(talk) 10:39, 23 February 2024 (UTC)

Thanks. I just released the draft to Template:HasTemplate, and I believe I've handled all necessary post-move housekeeping, except for one: once the module sandbox goes live, I'll make one more update to the template to invoke the module instead of the sandbox. Mathglot (talk) 11:44, 23 February 2024 (UTC)

I've pushed the sandbox version to live. If there's any weird behaviour, let me know, but all should be good to go. Aidan9382 _(talk) 23:30, 23 February 2024 (UTC)

Thanks, and I noticed you adjusted the template to live as well, so thanks for that as well. And not least, for the great collaboration in this whole effort, which I am convinced will open up some new and productive areas for WikiProject monitoring, reporting, and collaboration. Cheers, Mathglot (talk) 01:45, 24 February 2024 (UTC)

Hidden Templates, parameters, or param values

I was getting misleading values from tmpv from this call:

{{tmpv|Talk:Thomas Jefferson|User:ClueBot III/ArchiveThis|1|minarchthreads}}

using old rev. 1213886417 of Talk:Thomas Jefferson, which previously had this param embedded within HTML <!--comment delimiters--> (not on the same line):

|minarchthreads=1

I've removed the hidden template code entirely from Talk:Thomas Jefferson so {{tmpv}} doesn't see the commented-out param anymore, and now it works correctly again. Would it be difficult to avoid returning false positives in cases where templates, params, or their values are hidden? Not asking for a perfect solution with every edge case handled, but if we could nip off the low-hanging fruit, that would be a help. Thanks, Mathglot (talk) 02:10, 20 March 2024 (UTC)

Module:Wikitext Parsing (which this module uses) is meant to sort that exact issue of commented out or nowiki'd content. I've copied the content into my personal sandbox here and tried to replicate the bug but it wouldn't pick up the ClueBot template, so I'm not sure why you supposedly were. Do you think you could try pull off a more limited testcase or just find another currently broken page? I might be missing something. Aidan9382 _(talk) 07:25, 20 March 2024 (UTC)

I'll try to do so, assuming I didn't screw something up, which if you couldn't replicate, seems likely. Will get back to you eventually, and subscribe here, in case there are more developments in the meantime. Appreciate your trying it, and don't waste any more time on it for now. P.S., that's a very handy module; I may have some use for that elsewhere. Thanks again, Mathglot (talk) 07:41, 20 March 2024 (UTC)