Template talk:Category handler/Archive 1

Archive 1

About ((cat handler))

Per suggestion from Willscrlt: We have renamed this template from {{cat handle}} to {{cat handler}}, most of the text in the messages below have been updated with the new name to avoid confusion for future readers. --David Göthberg (talk) 16:31, 15 November 2009 (UTC)

This discussion was moved here from Wikipedia talk:Category suppression. --David Göthberg (talk) 04:57, 15 November 2009 (UTC)

I am currently designing a template that will make category suppression very simple and mostly automatic. When I have coded, tested and documented the template I will do as I always do: Wait some time before I start to use it, to give others proper time to test it and suggest improvements.

There are probably more usage cases than I know about, so here are some of my thoughts so far, so we can discuss them:

1: I am thinking of calling it {{cat handle}}.

2: The most basic usage will be like this:

{{cat handler| [[Category:Somecat1]][[Category:Somecat2]] }}

3: The default should be to categorise in most namespaces, except those where templates are often just demonstrated or listed and thus should normally not categorise. Thus it will categorise in main, file, help, category and portal space. But it will not categorise in talk, user, wikipedia and template space. So most templates that use {{cat handler}} can probably use the basic syntax above.

4: With some simple parameters one can tell it what namespaces one want it to categorise in. And one will be able to feed different categories for different namespaces, if needed. The parameters will perhaps be similar to how {{namespace detect showall}} works. See example at point 7 below.

5: It will use a blacklist placed on say "Template:cat handler/blacklist". Pages and page types that should not have categories can be listed there, like for instance the subpages of Wikipedia:Template messages and "/archive" pages. If a template that uses {{cat handler}} is placed on a blacklisted page, then the template will not add any categories. The blacklist will use pattern matching on the pagenames, so the specification will look something like this:

/archive* = hide
Wikipedia:Template messages/* = hide

For its pattern matching it will use the meta-template {{if pagename}} which is very efficient. Category suppression is one of the reasons why I created {{if pagename}}.

6: {{cat handler}} will of course understand the "nocat" parameter. But since it will have the blacklist, in most cases users will not need to use the "nocat" parameter.

7: Here is the full syntax for a really complex usage case:

{{cat handler
| 1 = [[Category:Somecat1]][[Category:Somecat2]]
| 2 = [[Category:Somecat3]]
| 3 = [[Category:Somecat4]]
| main = 1   <!--Already default, this line not really necessary-->
| help = 2
| user = 2
| talk =     <!--No categories on talk pages-->
| other = 3
| nocat = {{{nocat|}}}
}}

I know how to code the above. But I am not sure if that is the syntax I will use. I am investigating several other ways to specify what namespaces to categorise in. I'm trying to make it more user friendly, but still not causing too nasty code inside {{cat handler}}.

8: I can add the option to feed pagename patterns to {{cat handler}}, so that it can be made to categorise or not categorise on specific groups of pages. Similar to how {{if pagename}} works. This is for individual templates, while the blacklist sets the default for all usage of {{cat handler}}. Here's an example:

{{cat handler
| 1 = [[Category:Somecat1]][[Category:Somecat2]]
| /doc  =             <!--No categories on /doc pages-->
| /archive* = 1       <!--Categorise on archives, even if they are blacklisted-->
| other = 1           <!--Categorise in all namespaces, but not on blacklisted pages-->
| nocat = {{{nocat|}}}
}}

But I hope that is not needed, since it would make the documentation of {{cat handler}} scary.

I'd love any feedback about what functionality this template needs.

--David Göthberg (talk) 13-14 November 2009 (UTC)

Since Willscrlt asked me to explain more, below are some examples how templates could be using {{cat handler}}. The examples show the full code for those templates. Note that these new examples use a slightly improved syntax compared to the explanations in my message above, since I now have figured out how to make {{cat handler}} handle that.

Example 1:

{{ambox
| text = This is some message box used on articles.
}}{{cat handler
| [[Category:Somecat1]]
}}<noinclude>

{{documentation}}
<!-- Add categories and interwikis to the /doc subpage, not here! -->
</noinclude>

Since the category for the above box is fed to {{cat handler}}, that box will only categorise when in main, file, help, category and portal space. It might seem silly that it categorises in all those namespaces, but an article template is hardly ever placed in those namespaces. But it will not categorise in talk, user, wikipedia and template space. And that is good, since in those namespaces most templates are just demonstrated or listed, not used.

The simple syntax shown above can be used for templates meant for any of the namespaces main, file, help, category and portal. Thus covering most of the templates we use. But for templates meant for talk, user, wikipedia or template space, see the examples below.

Example 2:

{{tmbox
| text = This is a talkpage message box.
}}{{cat handler
| talk = [[Category:Somecat2]]   <!--Only categorise in talk space-->
| nocat = {{{nocat|}}}   <!--So "nocat=true" works-->
}}<noinclude>

{{documentation}}
<!-- Add categories and interwikis to the /doc subpage, not here! -->
</noinclude>

The above box will only categorise in talk space. But it will not categorise on /archive pages since they are blacklisted. That is, {{cat handler}} has an "/archive* = hide" rule in its blacklist. And if you need to demonstrate (discuss) that box on a talkpage, then you can feed "nocat=true" to prevent that template from categorising, like this:

== My new template ==
Hey guys, have you seen my new talkpage template?
{{mytemp|nocat=true}}
Nice, isn't it?
--~~~~

Example 3:

{{ombox
| text = This is a box for the top of WikiProject or Guideline pages or similar.
}}{{cat handler
| wikipedia = [[Category:Somecat3]]   <!--Only categorise in wikipedia space-->
| nocat = {{{nocat|}}}   <!--So "nocat=true/false" works-->
}}<noinclude>

{{documentation}}
<!-- Add categories and interwikis to the /doc subpage, not here! -->
</noinclude>

The above box will only categorise in wikipedia space. It will not categorise on "Wikipedia talk:" pages. And it will not categorise on for instance Wikipedia:Template messages/Wikipedia namespace that lists such templates, since that page is blacklisted. That is, {{cat handler}} has a "Wikipedia:Template messages/* = hide" rule in its blacklist. And if you need to demonstrate that box on another page in wikipedia space, then you can feed "nocat=true" to prevent that template from categorising. But we hardly ever demonstrate such boxes on other wikipedia space pages, so the "nocat = {{{nocat|}}}" line in that box is not especially needed, so it doesn't matter much if the template programmer forget to add that line.

If you need the box to categorise when on a blacklisted page, then simply feed "nocat=false" to skip the blacklist check. Note that this will not cause the box above to categorise on for instance a talk page, it will just cause categorisation in namespaces for which it has data.

Example 4:

{{mbox
| text = This is a box used in several namespaces.
}}{{cat handler
| main = [[Category:Somecat1]][[Category:Somecat2]]
| 1 = [[Category:Somecat3]]   <!--For help and user space-->
| help = 1
| user = 1
| talk =     <!--No categories on talk pages-->
| other = [[Category:Somecat4]]   <!--For all other namespaces-->
| nocat = {{{nocat|}}}   <!--So "nocat=true/false" works-->
}}<noinclude>

{{documentation}}
<!-- Add categories and interwikis to the /doc subpage, not here! -->
</noinclude>

In the above example we use a numbered parameter to feed one of the categories, and then we tell {{cat handler}} to use that numbered parameter for both the help and user space.

Example 5:

{{mbox
| text = This is a box used in all namespaces.
}}{{cat handler
| other = [[Category:Somecat1]]   <!--Categorise in all namespaces, but not on blacklisted pages-->
| nocat = {{{nocat|}}}   <!--So "nocat=true/false" works-->
}}<noinclude>

{{documentation}}
<!-- Add categories and interwikis to the /doc subpage, not here! -->
</noinclude>

The above example will categorise in all namespaces, but not on blacklisted pages. If you feed "nocat=true" it will not categorise. And if you feed "nocat=false" it will categorise even on blacklisted pages.

--David Göthberg (talk) 17:52, 14 November 2009 (UTC)

Ok. It is making more sense to me now. Thanks! :-)

1. A potential problem I see is that the category should be overridable in each instance (|other={{{other|[[Category:Somecat1]]}}}). This isn't a problem with the template itself, but it would need to be clarified in the docs. The reason is that, let's say I embed the category in a template, and then the template is used on a page where the default category is not the correct one; I should be able to override it. For that reason, "default", "main", etc. may not be the best attribute name choices. Maybe, since {{cat handler}} is pretty much always going to be called by other templates, all of its attributes/variables should be prefixed ("c_default", "ch_default", etc.) as you would inside of a class in a OOP language.
2. The template name reminds me of a basket handle, a door handle, or something else you grab onto. I assume that your use of "handle" is short for "handler" (meaning a template that handles all the category stuff for you). If so, then let's not skimp on the extra letter when it could make things more confusing. If it's a handler, then I'd call it {{cat handler}} or maybe {{cat processor}}, {{cat display}}, {{cat output}}, or something like that.
3. Using "other" as the attribute name for "all namespaces" is a little obscure. Perhaps an attribute named "all" (for "all namespaces") would be a bit more clear?
4. I like being able to use the numerical attributes as references. I assume that you aren't limited to a single number, but could define several (3 at least) to handle different namespaces with a single call. Nifty.
5. Let's say that I want categorize using the default namespaces, but I also want the template to categorize in Projectspace. Could you show me an example of how to add to the defaults rather than replace them?
6. Does "talk=" mean any talkspace (e.g., talk, file talk, project talk) or specifically ns:1 (article talk)? If it means only ns:1, is there an easy way to specify all talkspaces? Or the reverse, only ns:1?

Those are my first impressions. I will continue to look over this and post more questions/suggestions as they occur. :-) —Willscrlt ( “Talk” ) 04:45, 15 November 2009 (UTC)

End, messages moved here from Wikipedia talk:Category suppression. --David Göthberg (talk) 04:57, 15 November 2009 (UTC)

I have now implemented {{cat handler}} and done the first tests. Everything seems to work. And I have initiated its blacklist with some rules. Everything I describe in the two messages above should now work, except that I have not added the pagename matching I describe in point 8 in the first message above. I hope we will not need that matching, since it would be messy to add and document. But the blacklist does have such pagename matching.

I must say I am surprised that I could implement it that quickly. Of course, it builds on some pretty powerful meta-templates such as {{namespace detect}} and {{if pagename}}.

Willscrlt: I will respond to your above message within an hour or so.

--David Göthberg (talk) 04:57, 15 November 2009 (UTC)

Willscrlt: Oh, good questions!

2: You are right, {{cat handler}} is a better name. (English is just my second language.) And your assumption what I meant with the name is spot on. And of the ones you suggest I like {{cat handler}} the best. I will move this template to that name, unless you prefer some other name? (Tell me what you think, but leave the moving to me since this template has some sub-templates which is called from the code.)

1a: By override I assume you mean like this: There is a template named say {{mytemp}} which internally uses {{cat handler}}, and someone places {{mytemp}} on a page like this:

{{mytemp
| othercat = [[Category:Some other cat]]
}}

As I understand you that should mean that on that page the category "Category:Some other cat" should be used, and {{mytemp}} should not add any of its normal categories. Well, there are two ways to do that. The simpler solution is that {{mytemp}} doesn't support this, and instead the user simply puts this on the page:

{{mytemp
| nocat = true
}}
[[Category:Some other cat]]

As you can see, there's really no need to feed the new category to the template.

But if you anyway want to feed the new category into {{mytemp}}, then {{mytemp}} could be coded like this:

{{ambox
| text = This is the "mytemp" box.
}}{{#if:{{{othercat|}}}
| {{{othercat|}}}
| {{cat handler
  | [[Category:The mytemp cat]]
  | nocat = {{{nocat|}}}   <!--So "nocat=true/false" works-->
  }}
}}<noinclude>

{{documentation}}
<!-- Add categories and interwikis to the /doc subpage, not here! -->
</noinclude>

If we add that handling into {{cat handler}} the code could look like this:

{{ambox
| text = This is the "mytemp" box.
}}{{cat handler
  | [[Category:The mytemp cat]]
  | nocat = {{{nocat|}}}   <!--So "nocat=true/false" works-->
  | othercat = {{{othercat|}}}
  }}
}}<noinclude>

{{documentation}}
<!-- Add categories and interwikis to the /doc subpage, not here! -->
</noinclude>

But I don't see any reason to feed the override category into the template. Since it is so simple to just use "nocat=true" and put the new category directly on the page.

1b: The parameters that {{cat handler}} has are only used inside other templates. They are never visible outside those other templates. Except for "nocat" of course. So there is no real name collisions.

3: The parameter names for the namespaces and the "other" parameter for the rest of the namespaces are well established, see {{namespace detect}} and its sister templates. Well {{main other}} etc uses unnamed parameters, but they have the names in the template names. Many hundreds of templates already use {{main other}} and {{image other}} etc for their category handling, so if {{cat handler}} uses the same parameter names the conversion to {{cat handler}} will be easier.

4: {{cat handler}} currently understands the numbered parameters 1 to 10. We won't need more since it only has eleven namespace types: main, talk, user, wikipedia, file, mediawiki, template, help, category, and other. If you want to feed eleven different types then just feed directly to the namespace parameters.

5: Yes, the current version of {{cat handler}} can do that. Although that "feature" is mostly a side effect. And projectspace is the other name for wikipedia space, so I assume that is what you mean. Note that feeding unnamed and numbered parameters to a template is the same thing. Thus the two calls you see below mean the same thing:

{{cat handler
| [[Category:Somecat]]
}}

{{cat handler
| 1 = [[Category:Somecat]]
}}

Anything fed to parameter 1 will be used on the default categorisation namespaces. But the data is still available as parameter 1. So you can use that to achieve what you wanted:

{{cat handler
| 1 = [[Category:Somecat]]   <!--Categorise in the default namespaces-->
| wikipedia = 1   <!--And also in wikipedia space-->
| nocat = {{{nocat|}}}
}}

That is one of the more strange features I will have to describe in the documentation. However, if you instead feed the data to parameter 2 or higher it will only categorise where you explicitly tell it to. Or if "other" is defined (empty or has data), then the default namespaces won't be used. That is, "other" overrides the defaults. Like this:

{{cat handler
| 1 = [[Category:Somecat]]
| wikipedia = 1   <!--Only categorise in wikipedia space-->
| other =    <!--Don't categorise in the other namespaces-->
| nocat = {{{nocat|}}}
}}

Here's another odd combination:

{{cat handler
| 1 = [[Category:Somecat]]   <!--Categorise in the default namespaces-->
| main =          <!--But not in main space-->
| wikipedia = 1   <!--But add wikipedia space-->
| nocat = {{{nocat|}}}
}}

In the documentation I will recommend to avoid using parameter 1, to not accidentally get the default categorisation.

6: Right, "talk" means any talk space. As far as I know we hardly ever keep different talk spaces apart. That's why all the namespace-detection templates treat all talk spaces as one type, except for {{talkspace detect}}. That is the only meta-template we have to keep different namespaces apart, and we have had that one for some time now, still it is only used in one single template. So keeping talk spaces apart seems to be a rare thing. But if you want to keep the talk spaces apart, then you can use that one. Like this.

{{cat handler
| user = [[Category:Somecat1]]   <!--Categorise in user space-->
| talk =
  {{talkspace detect
  | user = [[Category:Somecat1]]  <!--And in user talk space-->
  }}
| nocat = {{{nocat|}}}
}}

Or like this:

{{cat handler
| 2 = [[Category:Somecat1]]
| user = 2   <!--Categorise in user space-->
| talk =
  {{talkspace detect
  | user = 2   <!--And in user talk space-->
  }}
| nocat = {{{nocat|}}}
}}

The above example is a little weird, since {{talkspace detect}} itself doesn't understand numbered parameters. But in that example, when on a "user talk" page, {{talkspace detect}} will return "2", which means {{cat handler}} then sees "talk = 2". And since that is such a strange usage I just tested it to make sure: It works!

--David Göthberg (talk) 06:47, 15 November 2009 (UTC)

Arbitrary break

2. {{cat handler}} works for me. Just as a funny aside (since you mention English is not your native language--though you could have fooled me!), with computers, I often mention a particularly difficult task is like "herding cats" or "wrangling cats". I guess that "cat handler" is somewhat similar to "cat wrangling or herding" ("to herd", "to wrangle", and "to handle" are all similar in meaning in English). That was a long explanation to let you know that the new name makes me smile every time I read it. :-)

1a. At this time, I don't see the need to implement overrides as long as the work-around is documented (so that people like me who try to make things more complicated are shown the easier route to take instead).

1b and 3. Ok. That makes sense. I've just been customizing some templates and ran into issues where the attribute names from one were reused in another using the same names, but for slightly different purposes. It made tracking the logic between different templates a bit tricky. It would have been nice if they had used the same name for the same thing or else distinguished between the different uses somehow. But, since there is already a well-established standard, let's stick with that. At least it sounds like they are all being used for the same thing, and that's good!

4. Ok. Cool.

5. Haha. Nice side effect. That's what most software developers would call a "feature" (a bug that is documented isn't a bug, it's a feature!)

As to "Wikipedia" space vs. "Project" space… sorry. About half of my templating work is cross-wiki template development and conversion. I don't even think of it as the "Wikipedia" space, because on fr.wiki it's "Wikipédia" and on some of the others it is "Vikipedia" or something else. Then you have Commons"("Commons") and Meta ("Project"), and so on. I always refer to it internally (in my brain) as Project space. I know that confuses more en.wiki-centric people, because they think of Projects as WikiProjects. *shrug* I suppose that's how it is with people from the U.S. always thinking that "American" means from the U.S., instead of being from the Americas (Brazilians are Americans, too, of course).

One of the main reasons I use "Project" instead of "Wikipedia" in my template development is that it is one fewer thing that has to be localized (or rather "un-localized" back to the generic) when I move a template to another language or project. I'm hoping that {{cat handler}} will port fairly easily. It will be nice to use it on Meta and other projects.

6. Wow! That last example is awesome. You have a really great mind for twisted logic puzzles. No wonder you are interested in cryptography. I'll take your word that distinguishing between talk spaces is not significant. But it's nice to know that there is an example of how to use it.

Perhaps there should be two doc pages. "Basic instructions" and "advanced tips". The basic instructions should be clear and easy for beginners. The Advanced tips could be just a collection of odd/complex examples like you have shown here. Then whenever someone brings up an unusual implementation, it can be added to the tips for future reuse. Better than reinventing the wheel. And, it doesn't overwhelm the average user.

Looks great. It will be a nice feature. And don't worry. I won't touch that template. I'm just working on establishing the related WikiProject for now. —Willscrlt ( “Talk” ) 08:33, 15 November 2009 (UTC)

2: So {{cat handler}} it is. And nice that it makes you smile. I too see its "cat wrangler" meaning. But hey, I like cats. I will do the move to {{cat handler}} tomorrow, after I had some sleep...

5: Yeah, "It's not a bug, it's a feature" is a well known expression among programmers all over the world. I did spend a lot of time thinking about how to handle parameter 1 before I coded {{cat handler}}. In the end I decided it was simpler to just leave that side effect. And hey, some people might have good use for it.

Yes "project" space is the standard MediaWiki name for it. I had already added "image" as an alias for "file" in the template. So since you like "project" I have now added it as alias for "wikipedia". And as you point out, that will make it clearer when porting to other projects. So now you can feed data like this: "{{cat handler| project = [[Category:Somecat]] }}".

6: Haha, yeah, some of the examples are pretty far out. But I think that for the majority of cases this template will be very easy to use.

7: And yes, writing good documentation for this will take some thinking and work. I too like to start with a section for the beginners, and then further down I put stuff for the advanced users (or as you say in this case we might need a subpage).

8: That leaves two questions: Have I chosen the right namespaces for default categorising, or does that need any adjusting? Or as I like to see it: What namespaces should we not categorise in per default? And what pages, and types of pages, should be in the blacklist? There's no hurry to answer these questions, I can easily adjust both things later on. Especially the blacklist is meant to be amended and appended over time. Edit {{cat handler/blacklist}} to see the current blacklist rules.

9: And finally, thanks for all the questions and feedback. Your initial questions helped me decide on what syntax to use, and your later questions made me sure that this template will be able to handle pretty much all usage cases. And now I know better what to put in the documentation.

--David Göthberg (talk) 09:42, 15 November 2009 (UTC)

Default supression in main name space

I think as a general rule, templates should not wind up in the main category name space for categories that they include. I read through this but I don't think I saw any place where this action can be set as the default or can be optionally set other then through the old include only. Vegaswikian (talk) 06:38, 20 November 2009 (UTC)

Do you mean this: A template that adds categories when in template space has the problem that the template itself gets categorized. And right, then using <includeonly></includeonly> tags is the best way. Sure we could add a parameter where one feeds the template's name, which would stop it from categorizing on the template. But that would not really be simpler than using the <includeonly></includeonly> tags, and would cause extra code.

But the good news is that most templates don't need to categorize at all when in template space. So we have set the default for {{cat handler}} to not categorize in template space. Thus most templates that use {{cat handler}} will not have this problem, and won't need <includeonly></includeonly> tags.

Oh, we should probably add <includeonly></includeonly> tags where needed in the examples in the "Advanced usage" section of the documentation. Thanks for bringing this up.

--David Göthberg (talk) 09:27, 20 November 2009 (UTC)

Special case for {{{1}}}

Are you sure it's a good idea to treat {{{1}}} as a special case? It seems like it would avoid a lot of complicated explanation in the documentation if you used {{cat handler|default=[[Category:Something]]...}} instead of {{cat handler|[[Category:Something]]...}}/{{cat handler|1=[[Category:Something]]...}}. (Of course, that would mean that you have to explicitly call default=, instead of using the unnamed first parameter.)

Since {{cat handler}} is only likely to be used when constructing/updating other templates, I don't think there's any harm in removing the special case. Besides, by specifying default=, you reinforce the idea that this is the default behaviour, and that other options are possible—that will remind editors of exactly what the template is going to do when they transclude it. TheFeds 02:57, 22 November 2009 (UTC)

Incidentally, for completeness, it seems like the individual talk namespaces should have their own parameters (e.g. usertalk, projecttalk, etc.), so that you can prevent (for example) a user talk template from doing anything in file talk space. Also, there should be an explicit option all for categorizing in all namespaces (for the rare situations where that's desirable). TheFeds 03:04, 22 November 2009 (UTC)

I'll have to answer this in a different order than you wrote it:

We already have a parameter for if you want to categorize in all namespaces: {{cat handle|other=[[Category:Somecat]]}}. When "other=" is used alone it looks a bit odd, but the name makes more sense if you see that it can also be used together with the other parameters, then it means "the other namespaces" as in "the rest of the namespaces". This is established naming for it from the namespace detection templates such as {{namespace detect}} and {{main other}}.

Regarding parameter 1: People mess up the auto-categorization in their templates all the time. One of the main points of this template is to make it easy to handle that. So for most cases it is enough to just add {{cat handle|[[Category:Somecat]]}}, and the template takes care of the rest. Forcing people to use a special parameter for the normal case that covers most templates would mean we loose the simplicity.

Those users that need more advanced categorization will hopefully read the part "avoid parameter 1". They don't need to understand why to avoid parameter 1. By the way, if you feed the "other=" parameter, then parameter 1 works just like any of the other numbers, since "other=" overrides parameter 1. So in many cases it doesn't even matter if people anyway use parameter 1.

But I agree, parameter 1 is a bit strange. I can add code to detect if any of the other parameters have been fed (main, talk, user and so on), and if so then parameter 1 would not cause any default categorization. That costs 12 lines of code. I should perhaps do that? Yeah, thinking of it I should probably do that! As you say, that will shorten the documentation, and prevent mistakes.

Regarding talk spaces: Well, people often ask about separating the talk spaces in the {{namespace detect}} template too (and I myself have been tempted to add that). But when I ask them if they need it themselves they always say no, they just want it for completeness. So adding parameters for all the talk spaces will only enlarge the code and documentation for no gain. I am only aware of one template that separates the talk spaces, and that one uses the {{talkspace detect}}, which is designed for that purpose. See further up on this page how to combine {{cat handler}} with {{talkspace detect}}.

--David Göthberg (talk) 06:37, 22 November 2009 (UTC)

I had noticed that behaviour of other, but it's not really the most obvious solution either. (Plus, the documentation wasn't clear whether other with no additional parameters was intended to be used to mean the same thing as the proposed all, or if it just conveniently provided that function.)

I still think that (especially given that this is a new template) there isn't going to be much trouble asking editors to use {{cat handler|default=[[Category:Something]]...}}. They'll all have to consult the docs page at this point, so I don't think there's a major possibility for confusion. And this template will only be used occasionally in specialized contexts—because it's you only transclude it when you're editing another template—so there's not a huge advantage to providing the simplified syntax for the default case. In my view, the advantage of not having to deal with a special case when learning the template outweighs the small benefit of a short form for {{{1}}} only. TheFeds 16:27, 22 November 2009 (UTC)

First of all, thanks for staying in this discussion, you are helping me to get this documentation and these functions right. So your input is much appreciated.

Yes, I see now that I haven't explained the "other" parameter properly in the doc. But I wouldn't like to have two parameters doing the same thing, so having both "all" and "other" would be bad. So it seems we have two options to make it clearer: Either we explain better in the doc what "other" does and why it is named as it is. Or we rename it to "all" and then in the rest of the examples we place it before the rest of the parameters. Here's some examples how we could show the "all" usage, and in the middle an example without "all", for comparison:

{{cat handler
| all = [[Category:Somecat]]   <!--Categorize in all namespaces-->
}}

{{cat handler
| main = [[Category:Somecat1]]   <!--Categorize in main (article) space-->
| talk = [[Category:Somecat2]]   <!--Categorize in talk space-->
}}

{{cat handler
| all = [[Category:Somecat1]]     <!--Category for all namespaces-->
| main = [[Category:Somecat2]]    <!--But use this in main space-->
| talk =     <!--But no categories on talk pages-->
}}

{{cat handler
| all = [[Category:Somecat1]]
| main = [[Category:Somecat2]]
| talk = 
}}

The first example looks good. But compare the two last examples, they use the same code, but the last one has no comments. Then it looks like in main space one will get "[[Category:Somecat1]] [[Category:Somecat2]]". And it looks like for talk space the user simply didn't bother to feed any category, thus one would expect to get "[[Category:Somecat1]]".

So using "all" instead of "other" is perhaps more confusing. And note that the first example above should be the most unusual, people should normally not set their templates to categorize in all namespaces.

Another option is to have both the "all" and "other" parameter, and let "all" actually mean all namespaces, and then have the "other" parameter meaning "the rest" as it does now. (Perhaps that's even what you meant?) But again, to categorize in all namespaces should be unusual and I don't want to encourage that. And if possible I don't want to add more parameters. But ouch, I just realised there are legitimate such cases, and then without a real "all" parameter one would have to feed the category several times which would be messy. (If one is also feeding special categories to some of the other namespaces.) Then people might resort to placing the category outside of {{cat handler}}, but we don't want that since we want the blacklist and "nocat" to still be able to operate on that global category. Gah! Perhaps we need a true "all" parameter too... :((

And regarding "default" or using parameter 1: Well, even using "default" is a special case, and it is slightly more complex to use than parameter 1. It's even hard to spell "default" for us non-native English speakers. And I already have a fully working version of {{cat handler}} in the /sandbox that detects the difference between basic usage (only parameter 1), and advanced usage (using the namespace parameters and possibly parameter 1).

--David Göthberg (talk) 20:53, 22 November 2009 (UTC)

Fixed - But not exactly like how TheFeds wanted it. I have updated this template so it now only uses default categorization for parameter 1 when it is the basic usage case. And it now has a true "all" parameter, in addition to the "other" parameter.

--David Göthberg (talk) 08:00, 24 November 2009 (UTC)

Sorry I didn't get back to you with detailed feedback—but I like your solution. TheFeds 16:59, 24 November 2009 (UTC)

Subpages

I am planning to add one or two new parameters, and I would like some feedback on their naming and values. Here's a first example:

{{cat handler
| [[Category:Somecat]]
| subpage = no    <!--Don't categorize on subpages-->
}}

{{cat handler
| [[Category:Somecat]]
| basepage = no    <!--Don't categorize on basepages-->
}}

I have just been testing to add {{cat handler}} to some templates. (I just edited their /sandbox pages to use {{cat handler}} instead of their old categorization code.) I discovered that some templates don't want to categorize on subpages, for instance to avoid categorizing on /doc and /sandbox pages. And I know many of the Wikipedia space pages have subpages with the page header, and then we don't want templates to categorize on those header subpages. So I am thinking of adding a parameter (or two) so one can choose if this template will categorize on subpages or not. I don't know if there is any cases with the opposite, where one would only want to categorize on subpages, but we should probably support that case too when we are at it.

We could also use a single parameter to handle both cases. That would be convenient if a template wants to forward the parameter, since then only one parameter needs forwarding to do both things. But it causes slightly more complex values. Like this:

{{cat handler
| [[Category:Somecat]]
| subpage = no    <!--Don't categorize on subpages-->
}}

{{cat handler
| [[Category:Somecat]]
| subpage = only    <!--Don't categorize on basepages-->
}}

{{cat handler
| [[Category:Somecat]]
| subpage = {{{subpage|}}}   <!--So "subpage=no/only" works-->
}}

Adding this function to {{cat handler}} is easy and fairly efficient. And if I do it right then it has additional benefits such as that the "page" parameter can be used to test also the basepage/subpage categorization of a template.

--David Göthberg (talk) 08:46, 24 November 2009 (UTC)

I'd go so far as to say the default should be categorize on base pages only, and then if subpage=yes, do the subpages too. Almost every template can be expected to have a /doc page, and many have /code and other subpages that aren't meant to be directly used. And usually, the category specifically refers to what the main template does, not to the function of the subpages.

For the unusual situation where you want to categorize subpages only, subpage=only is a good feature. TheFeds 17:07, 24 November 2009 (UTC)

Yes, I have thought more about this now. It should only be one parameter, so it is easy to forward. So we'll have to use "subpage=only" and "subpage=no (or yes)".

Oh! Not categorizing per default on subpages? That's an interesting idea. What I have been thinking of already from starters is to perhaps add rules in the blacklist that stops categorizing in subpages named /doc, /sandbox and /testcases. But you definitely got a point that perhaps all subpages might be a way. I'll have to think about that for a while.

Let's see: Stopping subpages in Template and Wikipedia space seems good. WikiProjects often have many subpages, but they perhaps mostly don't need auto-categorization there. And I have already blacklisted /archive pages for all spaces. And we don't use subpages much in the other namespaces anyway. In User space it would stop user boxes from categorizing on subpages, which mostly would be a good thing, since most users transclude their /userbox page onto their main user page. But some users don't transclude their /userbox page, so they need categorization there.

But I don't want to have too hard defaults, since then it might start to annoy people. After all, having a few extra items in a category usually isn't much of a problem. So it's a tough choice.

And you are right that we then should have the "subpage=yes" option. (Note mostly to myself: Stopping all subpages should not be done from the blacklist, since then one would have to use "nocat=false" which would cause categorizing on other unwanted pages too.)

--David Göthberg (talk) 00:05, 25 November 2009 (UTC)

I have added the "subpage=no/only" option and documented it. For the reasons described above I choose the default to categorize in subpages. This is of course not set in stone. I still would like to hear what people think about the parameter and its naming etc.

And since I think people will sooner or later ask about the code I used for it: If one puts the call to {{basepage subpage}} outside the "subpage=no/only" check, then yes we get fewer code lines. But then {{basepage subpage}} would be called on every usage of this template, which costs database lookups and would cause more damage if someone does a bad edit to {{basepage subpage}}. So putting the call inside the "subpage=no/only" check uses less resources and is more robust.

--David Göthberg (talk) 09:51, 25 November 2009 (UTC)

Too heavy

This template is way too heavy. The ability to tell a template not to categorise is trivially implemented; all it requires is to wrap your categories in a single #if statement. But this template binds it up with all manner of rarely-needed functionality, making a great many pages unnecessarily heavy on the processor. It think it is a solution looking for a problem, and should be dumped. Hesperian 23:48, 29 November 2009 (UTC)

For some cases yes, then just using an #if-statement can be enough. I am actually going to add a section to the documentation named "When not to use this template", where I will show more efficient methods for the cases where those methods fit. (Mainly if you are only to categorize in main or file space, which actually is the majority of templates.) But when you need to categorize in for instance Wikipedia space, or in a combination of namespaces then it quickly gets ugly code if you try to hard-code it. And from what I have seen out there, people all too often screw that code up. Then using {{cat handler}} is much easier.

And {{cat handler}} is much more efficient than you might think when just looking at the code. Since only parts of the code is used on each instance, and most of the comparisons are done on empty strings. Also the template {{if pagename}} that this template uses to handle the blacklist is very efficient. For instance, look at this fairly normal usage case:

{{cat handler
| main = [[Category:Somecat1]]   <!--Categorize in main (article) space-->
| talk = [[Category:Somecat2]]   <!--Categorize in talk space-->
| nocat = {{{nocat|}}}   <!--So "nocat=true" works-->
}}

The "NewPP limit report" is a measurement that the MediaWiki servers put in a comment in the rendered page code. It tells what resources the templates on a page costed to render. The report for the code above when used on this page is this:

Preprocessor node count: 165/1000000
Post-expand include size: 496/2048000 bytes
Template argument size: 105/2048000 bytes
Expensive parser function count: 0/500

That's a very low report. For comparison, take look at the NewPP limit report for a single usage of the tag:

Preprocessor node count: 237/1000000
Post-expand include size: 955/2048000 bytes
Template argument size: 167/2048000 bytes
Expensive parser function count: 0/500

That's also a low report, still {{cat handler}} beats that. So really, when it comes to {{cat handler}}, then you don't need to worry about performance. Of course, the reason that {{cat handler}} is so efficient is that I tend to worry about performance, so I have learnt a number of methods to make template code efficient. :))

--David Göthberg (talk) 06:30, 30 November 2009 (UTC)

Yes, that is a much lower cost than I had expected; I'll grant you that. I look forward to seeing the "when not to use this template" documentation, though I suspect that in many cases there will be no freedom to choose not to use it because it will be invoked via other meta-templates like {{userbox}}, {{infobox}} and {{navbox}}. Hesperian 06:51, 30 November 2009 (UTC)

Well, it is in meta-templates that {{cat handler}} is the most useful, since it is hard to make a meta-template handle all possible cases properly when hard-coding the category logic. While {{cat handler}} has that packaged neatly, with blacklist and easy to feed "nocat={{{nocat|}}}" option and so on.

--David Göthberg (talk) 08:57, 30 November 2009 (UTC)

Agree with that; that is basically the point I am making. The contexts where it is most useful are also the contexts where there is very little freedom not to use it. Anyone who creates a userbox will use {{userbox}} and therefore {{cat handler}}, regardless of whether this template offers their userbox anything. But I suppose it doesn't really matter, so long as it remains very light-weight.... Hesperian 11:22, 30 November 2009 (UTC)

Template code cleanup

Regarding the value 'h0#384!5nea+w9', I assume this is just a non-empty, never-be-used-as-a-parameter value. Can we use something better? I have a bot that really gets confused and many templates use the value '¬' in this case. Actually this template does too some lines above. Or is this some magic code that I'm missing? Hopperpl (talk) 19:53, 29 November 2009 (UTC)

Right, that is just a value that I use internally to efficiently test if all the namespace parameters are undefined. That test only fails if "h0#384!5nea+w9" is fed to one of the parameters. But that anyone would ever feed "h0#384!5nea+w9" is exceedingly unlikely. (And it can never even be a category name since it lacks "[[Category:]]" and it contains "#" which can't be used in page names in MediaWiki.) There is no reason it should confuse your bot, since that value should never be fed to the template, it is only used internally. So your bot should never see that value.

Here is a simple version of that magic code, to show how it works:

{{#ifeq: h0#384!5nea+w9 | {{{talk| {{{user| h0#384!5nea+w9 }}} }}}
| <!--Both "talk" and "user" are undefined-->
| <!--"talk" and/or "user" has data or is empty but defined-->
}}

When checking many parameters this is a more efficient method. Otherwise I would need two lines of code for each parameter.

And right, for the "cagegory =" parameter we have the option to feed "category = {{{category|¬}}}". But ouch! You made me reread the code and study the category parameter. The backwards compatibility with "category =" was added afterwards, since some users asked for it. But I see now that we have a parameter name collision. This template already used "category =" to mean "don't categorize in category space". I have disliked that ugly "category = {{{category|¬}}}" hack from starters, and now I see it collides with the name of the namespace, it is evil! Hopperpl: Thanks for making me find this bug. I have to ponder what to do with that.

--David Göthberg (talk) 05:42, 30 November 2009 (UTC)

I have renamed the suppression parameter "category" to "category2", to avoid name collision with the category selection parameter "category".

--David Göthberg (talk) 18:25, 2 December 2009 (UTC)

Suggestion: Existence of a user subpage to determine user's category preferences

Thoughts on this? For example, ifexist "BASEPAGENAME/catno" it would not categorize, and ifexist "BASEPAGENAME/catyes" it would categorize. –xeno^talk 16:21, 16 December 2009 (UTC)

Since normal users can't delete pages, it is better to use a subpage named say "/categorize" and put "yes" or "no" in it. Then the user himself can modify the value when needed, without having to ask an admin. (We can easily check the content of a subpage like that by using template code, we have already tested this for another template.)

I assume you mean this could be used for instance for these cases:

1: A user has a subpage where he lists or tests a bunch of templates. He doesn't want the templates to categorize on that page. So he has "User:Example/Test 1", and he creates "User:Example/Test 1/categorize" and puts "no" in it.

2: A user has a subpage where he puts all his user boxes, and then he transcludes the subpage onto his user page to display the user boxes. He doesn't want the user boxes to categorize on the subpage, but he wants them to categorize on his user page.

Technically this is easy to implement. And for user space we can't use the blacklist since there are too many user pages that might use this. But it might be feature creep. Do we really need this? I have to think about this for a while. What do the rest of you guys think?

We can even later extend this to work similarly to the blacklist, so we can put other values in the "/categorize" subpage, like the value "all no" to prevent categorization on the page and all its subpages, or the value "subpages no" to only prevent the subpages to categorize but not the page itself. (Or perhaps the shorter values "no+" and "no*", but that is perhaps to cryptic.) This could also be useful in other spaces than user space, although for the other spaces the blacklist already works well. And of course if we feed "nocat=false" to a template it should not check the "/categorize" subpage just as "nocat=false" overrides the blacklist.

--David Göthberg (talk) 15:21, 18 December 2009 (UTC)

Yes, those are good examples, and perhaps even further a user would never want to be categorized by a userbox - so they would set "no" as a blanket. There is also {{ubxrand}} which can't take individual parameters for the matrix of random userboxes it displays. And using a single page set to yes or no (or other values) is an even better way to go about it. –xeno^talk 15:27, 18 December 2009 (UTC)

This function will probably sometimes cause confusion, since people will wonder why a pages doesn't get categorized no matter what they do with the templates they place on it. So if we add this function then I would like to make it so {{cat handler}} adds "Category:This page has automatic category suppression" to the page when the blacklist or the /categorize "no" is preventing categorization. ( {{Cat handler}} should not add that category when it suppresses categorization based only on namespace, since that is normal usage.) And on that category page I will put an explanation about why some pages don't show categories. That would give users a chance to figure out what is going on.

It might seem odd to add a category when not categorizing, but this means just one category instead of perhaps a lot of categories on the page. And it still means the page doesn't show up in the wrong categories. And we could perhaps make that category hidden, since admins and advanced users usually see hidden categories, and when editing a page the hidden categories are listed no matter what kind of user you are. But I think I slightly prefer to have the category visible.

--David Göthberg (talk) 17:23, 18 December 2009 (UTC)

Sure, that's another good idea, but I would suggest a more standard form of "Pages with automatic category suppression". –xeno^talk 17:49, 18 December 2009 (UTC)

Yes, that category name works pretty well too. We use a similar approach for error reporting in many other templates, see for instance Category:Wikipedia message box parameter needs fixing. Such category names really are not category names in the normal sense, instead they are a message on the page telling what is going on on the page. Thus I slightly prefer the category name "This page has automatic category suppression" since it indicates more clearly what is going on. That the name is non-standard and looks a bit odd probably increases the chance that people will read it and click on it to find out more. Of course, in this case the category will usually remain on the page forever, so the name should also not be too intrusive, which speaks for your suggestion "Pages with automatic category suppression". So since I just slightly prefer my naming I think you outvote me, so I will use your naming. Does anyone else have any comments?

--David Göthberg (talk) 18:24, 18 December 2009 (UTC)

I was just looking through my to-do list. There I have noted the idea of naming the category "Category suppressed pages". I think I prefer this, since it is shorter and still fairly clear.

--David Göthberg (talk) 04:15, 21 December 2009 (UTC)

nocat parameter

Would it be possible to allow |nocat=yes to work as well as |nocat=true ? Thanks. -- WOSlinker (talk) 23:35, 6 January 2010 (UTC)

Note: There is an existing discussion about this over at Wikipedia talk:Category suppression#Oooh.

Technically it is fairly easy to add. But I am hesitant since it is a new value. It means we would have to support it forever or things will break. If we in the future decide to remove it then we have to clean up all usage out there, but that usually takes some weeks of work, I know from experience.

Since we need to be backwards compatible we already have several methods to feed that. And all those methods are already bloating the code and the documentation.

Personally I would like a new parameter named "categorize=no" since I find that clearer. But adding a new method probably is bad, so for now I prefer the old method "categories=no" which {{cat handler}} already understands.

--David Göthberg (talk) 00:02, 7 January 2010 (UTC)

Adding the Main Page

{{editprotected}} Since there has been no opposition on the technical village pump and the main page shouldn't be categorized by templates, could you add |Main Page=hide <!-- don't categorize the main page --> to {{Cat handler/blacklist}}? This edit would also reduce the harm of possible mistakes when someone mistakenly adds a template to the main page. --The Evil IP address (talk) 21:52, 2 June 2010 (UTC)

 Done HJ Mitchell | Penny for your thoughts? 01:22, 3 June 2010 (UTC)

Sandboxes

I think that the black list should also excempt the sandbox and related pages, e.g. {{X1}} or {{X2}}. Categorization there is often pointless. --The Evil IP address (talk) 19:13, 25 May 2010 (UTC)

I agree that categorisation on the central Wikipedia sandbox pages probably often is pointless. But I think it might be unnecessary to add those pages to the blacklist. Since the default behaviour for {{cat handler}} is to not categorise in "Wikipedia:" and "Template:" space. Of course, if/when the all, wikipedia or other parameters are used then {{cat handler}} does categorise in the Wikipedia:Sandbox. However, those sandboxes are regularly cleaned, so those pages will only occasionally be visible in some categories. So I hope it is not much of a problem?

Note: I would like to keep the blacklist fairly small if possible, since the size of the blacklist adds to the size of the {{cat handler}} template and in turn to the size of all templates that uses it.

--David Göthberg (talk) 07:45, 18 September 2011 (UTC)

On second thought, you're probably right. The categorization of the sandboxes is so short and trivial that we may even allow that. --The Evil IP address (talk) 15:18, 18 September 2011 (UTC)

Edit request from Crazymonkey1123, 21 May 2011

This discussion was moved here from Template talk:Cat handler/blacklist. --David Göthberg (talk) 17:47, 18 September 2011 (UTC)

Where it shows: | Wikipedia:Template messages/* = hide <!-- Don't categorise on its subpages --> | /archiv* = hide <!-- Don't categorise on /archive pages --> <!-- Don't categorise on centralised cascade page or its subpages --> | Wikipedia:Cascade-protected items/+ = hide | Main Page = hide <!-- Don't categorise the main page --> categorise should be spelled categorize. centralised should be spelled centralize. /archiv should be spelled /archive Crazymonkey1123 (Jacob) ^{T or M}/_{Sign mine} 20:40, 21 May 2011 (UTC)

Categorise and centralised are simply the English spelling, which hardly matters enough to make it worth changing, and I suspect /archiv* is like that for a reason, since its always been that--Jac16888 ^Talk 20:52, 21 May 2011 (UTC)

As Jac pointed out "categorise" and "centralised" is the spelling used in Britain, Australia, New Zealand, and probably also in Ireland and India. I created {{cat handler}} and {{cat handler/blacklist}}, and I use that spelling since I live in Europe.

And Jac is also right that changing /archiv* to /archive* would break things. The blacklist uses {{if pagename}} to do the pattern matching. Here's a quote from its documentation:

The partial matching only supports matching on 4, 6 and 8 characters. Thus using "/some*", "/someth*" and "/somethin*" works, but using "/som*" or "/somet*" doesn't work.

The reason that {{if pagename}} only supports matching on some lengths is that checking each length costs some lines of code, so adding more lengths would make {{if pagename}} less efficient and more complex. (Normally we should not worry about performance, but that template is used on 2 million pages, and might be used several times on each page.)

--David Göthberg (talk) 07:26, 18 September 2011 (UTC)

Name of this template

I think it would be clearer if this template were called Template:Category handler. Someone reading "cat" might not associate it to categories. Any objections to moving it? — Martin (MSGJ · talk) 16:35, 22 September 2011 (UTC)

As there was no opposition to this idea, I have moved it over. — Martin (MSGJ · talk) 14:10, 30 September 2011 (UTC)

Even though I was the one who choose the name {{cat handler}} I think I concur with the change to the clearer name {{category handler}}. Or to be precise, I started out with the somewhat silly {{cat handle}}, Willscrlt then suggested {{cat handler}}.

--David Göthberg (talk) 22:34, 5 October 2011 (UTC)

Additional blacklist

I'd add User:UBX and all subpages thereof. Userboxes should categorize only in userspace, but not the userspace templates themselves. ⇔ ChristTrekker 13:53, 5 October 2011 (UTC)

Y Done - Yes, seems like a good idea. Since userboxes do categorise in user space, so the default behaviour by {{category handler}} to not categorise in user space doesn't help.

--David Göthberg (talk) 22:24, 5 October 2011 (UTC)

Thanks! That was quick. ⇔ ChristTrekker 13:43, 7 October 2011 (UTC)

I'm confused. I am still seeing User:UBX/Christian (the userbox template itself) listed in Category:Christian Wikipedians. It shouldn't be there. ⇔ ChristTrekker 19:57, 7 October 2011 (UTC)

Fixed - Haha, that was a sneaky one. It took me a while to figure out what was going on: Back in November 2007 User:Angel David added [[Category:Christian Wikipedians]] far below the template code. Too far down to be visible on the first page of the edit window. You had to scroll down to see it. And it seems none of the later editors of that template had noticed it.

--David Göthberg (talk) 20:56, 7 October 2011 (UTC)

Doh! I should have been more thorough myself. Sorry. Kind of funny I'd run across an instance of that while trying to determine the effects of the blacklist update though. ⇔ ChristTrekker 21:04, 7 October 2011 (UTC)

It was a good thing you stumbled on this case, since I now looked closer at Category:Christian Wikipedians and noticed several "User talk:UBX/Userboxes/Religion..." talkpages listed there. As usual people are demonstrating/discussing the templates on some of the templates' own talkpages. So I have now also blacklisted the "userbox talk space", that is "User talk:UBX" and all its subpages.

That alone doesn't remove all those talkpages from the categories, since many of the userboxes are not built using {{category handler}}, or using one of the {{userbox}} meta-templates that in turn use {{category handler}}. But blacklisting those talk pages at least is a start.

--David Göthberg (talk) 21:28, 7 October 2011 (UTC)

I need to review the userboxes I've created (or have taken over maintenance of) to see if they're all using {{userbox}} yet. For several of the lesser-used ones, I highly doubt it. Getting this kind of thing "for free" would be nice. ⇔ ChristTrekker 14:55, 10 October 2011 (UTC)

There's no need to blacklist User talk:UBX as anything using {{Userbox}} won't categorise when placed on a talk page. -- WOSlinker (talk) 15:37, 10 October 2011 (UTC)

WOSlinker: Not all userboxes use the {{userbox}} meta-template. And many userboxes do categorise on purpose on user talkpages, since many users redirect their "User:" page to their "User talk:" page and then place all their info such as userboxes on their talkpage. So there is a legitimate need for userboxes to categorise on user talkpages, but not on User talk:UBX and its subpages. So {{category handler}} should support that.

--David Göthberg (talk) 06:01, 11 October 2011 (UTC)

I've never seen any userboxes that don't use {{userbox}} but do use {{category handler}} and even if they did, they would do something as below:

{{category handler
| user = [[Category:Somecat1]]
| nocat = {{{nocat|}}}
}}

Which doesn't categorise into user talk pages. -- WOSlinker (talk) 18:51, 11 October 2011 (UTC)

Switch of mbox templates and category handler to Lua

I've made a request over at Template talk:Mbox about switching all of the {{mbox}} family templates, plus the {{category handler}} template, to use Lua modules. These templates have millions of transclusions, so I would appreciate comments and some more eyes on the code. Please let me know what you think over at the request page. — Mr. Stradivarius ^{♪ talk ♪} 15:10, 15 October 2013 (UTC)

The proposed changes are now up live - this template is now using Module:Category handler. — Mr. Stradivarius ^{♪ talk ♪} 13:05, 20 October 2013 (UTC)

Error in Implementing this Module

Moved from Module talk:Category handler. — Mr. Stradivarius ^{♪ talk ♪} 07:05, 10 April 2014 (UTC)

I copied this module to my local wiki (Tamil). When I use this in {{mbox}} as {{#invoke:Message box|mbox}} , I get the following error:

Lua error in Module:Category_handler at line 231: attempt to call field '_main' (a nil value).

Backtrace:
   Module:Category_handler:231: ?
   (tail call): ?
   Module:Message_box:409: in function "setBoxParameters"
   Module:Message_box:539: ?
   (tail call): ?
   mw.lua:553: ?

I can see that the error is in this module at line number 231: Which is:

local data = nsDetect._main(ndargs)

Can someone please help me? --Jayarathina (talk) 15:15, 17 November 2013 (UTC)

I'm no Lua expert; you may want to ask the user who actually wrote this module, Mr. Stradivarius. At a glance the problem seems to be that this module tries to call a field that doesn't contain a value. This field seems to come from Module:Namespace detect. Did you copy that module to the Tamil Wikipedia, too? If not, that's likely the reason for the error. Huon (talk) 15:37, 17 November 2013 (UTC)

Huon, Thanks a lot. It was already copied, but it was of an old revision of the Module:Namespace detect. I updated it and the error vanished. Thanks a lot. --Jayarathina (talk) 15:48, 17 November 2013 (UTC)

Default parameter names

There's a discussion at Wikipedia:Village pump (technical)/Archive 125#List of all namespaces on WMF wikis that might interest people here. It concerns possible new default parameter names for Module:Category handler to allow it to be more easily ported to other wikis. — Mr. Stradivarius ^{♪ talk ♪} 07:08, 10 April 2014 (UTC)

Protected edit request on 18 April 2014

42.104.12.212 (talk) 10:18, 18 April 2014 (UTC)

Not done: it's not clear what changes you want made. Please mention the specific changes in a "change X to Y" format. — Mr. Stradivarius ^{♪ talk ♪} 10:37, 18 April 2014 (UTC)

Update to the module

I've written a new version of Module:Category handler, located at the following pages:

• Module:Category handler/sandbox
• Module:Category handler/config
• Module:Category handler/data
• Module:Category handler/shared
• Module:Category handler/blacklist

The new module tries to expand as few parameters as possible to save on performance, in contrast to the current module which automatically expands all of them. This should solve the issue mentioned at Template talk:R from Unicode#Bad code?. It also loads as much data as possible with mw.loadData, to increase performance when it is used many times on a page. The cached data includes the module configuration, the blacklist check results and the list of namespace alias parameters. It is pretty much a complete rewrite; I have reworked it with an object-oriented framework using Module:Middleclass, and I'm getting the arguments with Module:Arguments. Only a small amount of code is reused. Test cases are at Module:Category handler/testcases (run tests). Please let me know if you have any comments or questions about it; if there are no problems, I plan to update the main module in the next few days. — Mr. Stradivarius ^{♪ talk ♪} 02:16, 8 July 2014 (UTC)

I've now put this up live. Please let me know if you notice any strange category-related behaviour that may be due to the rewrite. — Mr. Stradivarius ^{♪ talk ♪} 09:13, 13 July 2014 (UTC)

Protected edit request on 13 July 2014

Please make these changes, to remove an unnecessary dependency without affecting any functionality. Jackmcbarn (talk) 17:35, 13 July 2014 (UTC)

 Done -- WOSlinker (talk) 17:57, 13 July 2014 (UTC)

Documentation: Category handler, technical details look outdated Suggestion

Check Template:Category_handler#Technical_details:

The centralised category suppression blacklist is in the sub-template {{category handler/blacklist}}. To see or update the blacklist, go there. For its internal parameter processing, this template uses the sub-template {{category handler/numbered}}.

The information seems to be obsolete since the template was ported to Lua in 2011, Module:Category_handler neither uses {{category handler/blacklist}} or {{category handler/numbered}}.

--Escalator~enwikibooks (talk) 07:57, 22 June 2016 (UTC)

Protected edit request on 27 July 2018

Redirect Template:Cat handler/blacklist to Module:Category handler/blacklist instead, to fix a double redirect. SkyGazer 512 ^{Oh no, what did I do this time?} 13:15, 27 July 2018 (UTC)

 Done — xaosflux ^Talk 16:06, 29 July 2018 (UTC)

subpageOnly

Is it possible to add more than you parameter for cfg.subpageOnly?, such as cfg.subpageOnly = {'only', 'Only'}. I'm aking because I'm trying to update the code to another language. —CaiusSPQR (talk) 01:05, 30 January 2019 (UTC)