Template talk:If in category

Alternative methods?

@Sdkb, do you think some alternative methods of checking if the page contains a category would be worth trying? For example, {{Find page text}} doesn't require a hacky article transclusion ({{:PAGENAME}}), and as I recently found out, modules can be used to recursively expand templates, which might help with indirect categorisation (see {{ExpandTemplates}}). Qwerfjkl talk 10:29, 29 May 2022 (UTC)[reply]

PINGFIX @Sdkb. ― Qwerfjkl talk 10:31, 29 May 2022 (UTC)[reply]

Would searching for the page in the {{categorytree}}, instead of looking for the category in the page text, be one such alternative (which, as a bonus, can include subcategories, might work with pages added through templates, and not be as expensive)? I tried that here, but didn't quite get it there yet. — Guarapiranga ☎ 01:51, 30 May 2022 (UTC)[reply]

I'd definitely be open to alternative methods if you can get them to work; have at it! {{u|Sdkb}} ^talk 05:12, 30 May 2022 (UTC)[reply]

OTOH, Galobtter reckons this template would probably be cheaper if done purely as a module... [and it] only search[ed] the last section of the article. — Guarapiranga ☎ 06:10, 30 May 2022 (UTC)[reply]

Probably just using {{Find page text}} would help a lot since it's a module that pretty much does what is needed here. Galobtter (pingó mió) 06:17, 30 May 2022 (UTC)[reply]

Here's a {{Find page text}} example:

{{#if:{{Find page text|title=Amastra subsoror|%[%[ ?[Cc]ategory:Extinct gastropods%]%]|plain=false}}|Dead as the dodo|Perhaps it's still alive}}

Producing 'Dead as the dodo' ― Qwerfjkl talk 06:59, 30 May 2022 (UTC)[reply]

Like that, Qwerfjkl? — Guarapiranga ☎ 08:59, 30 May 2022 (UTC)[reply]

And here's a Module:String example:

{{#if:{{#invoke:string|match|s={{nowiki|1={{:Amastra subsoror}}}}|pattern=%[%[ ?[Cc]ategory:Extinct gastropods%]%]|nomatch=}}|Dead as the dodo|Perhaps it's still alive}}

Producing 'Dead as the dodo' ― Qwerfjkl talk 08:00, 30 May 2022 (UTC)[reply]

module:string#match vs module:string2#findpagetext: is there a difference in performance? — Guarapiranga ☎ 09:03, 30 May 2022 (UTC)[reply]

@Guarapiranga, 0.783 and 0.0308 respectively, in terms of real-time usage (seconds) as an average over 5 tests. ― Qwerfjkl talk 11:56, 31 May 2022 (UTC)[reply]

25x faster?? That's huge! Sure about that, Qwerfjkl? To me this indicates module:string#match has some serious implementation issues (it seems string2 has really pulled some strings on string 😅). What about the sandbox version? Works? — Guarapiranga ☎ 12:06, 31 May 2022 (UTC)[reply]

┌─────────────────────┘
@Guarapiranga, I think it's because String recursively substitutes the text it's given, whereas String2 fetches the current content t on a page title. Theoretically, String could detect indirect categorisation; I haven't tested it though. I'll test the sandbox later. ― Qwerfjkl talk 12:21, 31 May 2022 (UTC)[reply]

The sandbox isn't really comparable because it's a template taking parameters, not simply wikitext, but it took about 0.7-8 s, and 0.002 s when substituted. ― Qwerfjkl talk 10:17, 1 June 2022 (UTC)[reply]

@Qwerfjkl and Guarapiranga: I think if you want this different version to work, you are gonna need to put the entire thing in lua. In it's current state, its forced to transclude the entire article. This leads to a lovely little "Warning: Post-expand include size is too large" should a somewhat large article be checked (Like if Earth is checked twice), and the other stats in the Parser profiling data aren't looking to pretty. A lua implementation would probably dodge a lot of the current issues with the existing implementation. Note that modules like Module:Transcluder already exist that can help with something like this. Could this be a potential thing worth working on? Aidan9382 _(talk) 05:08, 6 June 2022 (UTC)[reply]

@Aidan9382, as I mentioned above, the sandbox is way less expensive. ― Qwerfjkl talk 07:11, 6 June 2022 (UTC)[reply]

@Qwerfjkl: Oh god. It seems im extremely unlucky. I happened to pick a rare edge case in category detection which made me assume {{Find page text}} wouldnt work without full transclusion (It was a category that went [[Category:XYZ| ]]). I've gone ahead and fixed that, though for some reason LUA regex is acting funny with me today, so I'd like it if you double checked that. Note though that, now that it seems fine, why hasnt this version been put into use? Aidan9382 _(talk) 07:28, 6 June 2022 (UTC)[reply]

Given that {{If in category}} is used in exactly zero mainspace articles, I don't see why not, Aidan. — Guarapiranga ☎ 09:50, 6 June 2022 (UTC)[reply]

@Qwerfjkl: If you're done giving it some final changes, could you move everything to the live version? This new version also helps solve a new problem with {{Featured picture}}, and I'd like to get that patched up. Thanks! Aidan9382 _(talk) 10:20, 6 June 2022 (UTC)[reply]

Done ― Qwerfjkl talk 10:30, 6 June 2022 (UTC)[reply]

How about this to accommodate redirects? — Guarapiranga ☎ 01:40, 7 June 2022 (UTC)[reply]

┌─────────────────────┘
Well, I (stress) tested it here, with no problems, so went ahead and committed it (since it wasn't yet used in mainspace anyhow--and now it is!) — Guarapiranga ☎ 03:40, 7 June 2022 (UTC)[reply]

Discussion at Wikipedia talk:Lua § Category detection (using new feature!)

You are invited to join the discussion at Wikipedia talk:Lua § Category detection (using new feature!). Sdkb ^talk 15:24, 16 August 2024 (UTC)[reply]

I think I did it. See Module:If in category, {{if in category/sandbox}}, and testcases. I will note that the category checking function is considered WP:EXPENSIVE by MediaWiki, though still much less costly than the old version.

This implementation is slightly different from the original template, but I think the new way is better. It has the following changes:

It assumes we are checking the current page unless given an explicit |page= parameter. This is a breaking change (previously this was the first unnamed parameter), but I think this is a more intuitive way of doing it. In particular, by naming this parameter, you don't need to remember if the category or the page goes first: You just mimic the syntax of all the various behavior switch parser functions, putting the test first and then the results second and third. I realize that {{#ifeq}} does have two "test" inputs, but the order does not matter.
It accepts both Category:Foo and Foo as equivalent
If mimics the behavior of {{yesno}} when handling returns: If not given anything to return, it returns yes if it evaluates to true and nothing if it evaluates to false. This is handy for dealing with {{#if}}, and can be easily overridden by passing |3=no (or whatever you want it to return when false)

Best, House Blaster (talk • he/they) 16:49, 5 September 2024 (UTC)[reply]

Fantastic, @HouseBlaster! Those changes all sound good to me. Sdkb ^talk 17:36, 5 September 2024 (UTC)[reply]

Including parent categories?

In {{as of}}, it would be useful to check if the current page is in a subcategory of Category:Use mdy dates (e.g. Category:Use mdy dates from October 2024) to automatically select the correct date formatting style - see Template talk:As of#date formatting. {{If in category}} almost does this, but can only test for direct, not transitive, membership. Thoughts on adding something like |parents=yes to recursively walk the category tree, instead of just checking one level? With @HouseBlaster's new Lua implementation, it seems this might be feasible. DefaultFree (talk) 22:23, 18 October 2024 (UTC)[reply]

This would be possible, yes. page.categories (the Lua function which makes this possible) is an WP:EXPENSIVE parser function, so that would max us out at 500 very fast (exponential growth and all). Checking one parent level is probably acceptable, but going all the way until we reach Category:Contents is a no. House Blaster (talk • he/they) 04:30, 19 October 2024 (UTC)[reply]