Wikimedia Bugzilla is closed!

I'm not quite sure what it is you're trying to achieve here - for the first one,
why not just use a real redirect? And for the second, what is the content that
you are trying to include from where, and what is the "original page" that you
are trying not to modify?

This is asking for the same feature as bug 706, so I'm going to close it as
duplicate, but feel free to clarify what you're trying to do, in case it
requires something more (or less) than that.

*** This bug has been marked as a duplicate of 706 ***

(In reply to comment #1)
> I'm not quite sure what it is you're trying to achieve here

Sorry this was not clear from the links given:

Tourbusses are basically reading-lines. They have a starting-page and each page
to read has, minimally, a link to the next page to read. If we were to do this
by changing the actual encyclopedia pages, those visitors who were not following
the lines would see curious links telling them:
"Next on the Bluewater Line: [[Dime]]".

The Dutch Wikipedia wants to avoid this. A solution to this would be to make a
separate busstop-page for each busstop, eg. Nickel/Busstop. That busstop-page
would then contain:
"{{:Nickel}} -- Bluewater Line -- Next Stop: [[Dime/Busstop]]".

This way a separate level of navigation is created for tourbusses, as only those
reading the busstop-pages would actually see the tourbus navigation.

> - for the first one, why not just use a real redirect?
A redirect would not do as this would put the reader on the actual page, which
should not have the navigation.

> And for the second, what
> is the content that you are trying to include from where, and what is
> the "original page" that you are trying not to modify?

The content we are trying to include is the encyclopedic content of a normal
Wikipedia page. That page, the original page, is included completely in the
busstop page by way of a template. That way the on the busstop page the page
text and the navigation is visible, while at the original page just the text is.
Unfortunately, both show up in the categories the original page is in.

> This is asking for the same feature as bug 706, so I'm going to close
> it as duplicate, but feel free to clarify what you're trying to do,
> in case it requires something more (or less) than that.

Originally they weren't that related, but the remaining difference is now: In
our case the templates are actual Wikipedia pages.
- An implementation based on the Templates namespace is not a direct solution.
- An implementation that switches off the categories for the template (page)
itself would not help us.
- An implementation that doesn't work for the template (page) itself, would
still work for us.


Implementing request Bug 450, would also allow a solution to our problem, though
I do not care for that idea nor for that solution.

Clarification of the distinction between bug 706 and bug 835:

(The new syntax proposed below is just an example and might be ugly. I don't
intend to propose that we use this syntax.)

bug 706:
1) [[azbycxdw]] has the normal syntax:
	{{delete}}.
2) [[Template:Delete]] has some new syntax like:
	[[Category:Candidates for speedy deletion|Template:Delete|no_cat]]

In this case [[[Category:Candidates for speedy deletion]] lists
[[Template:Delete]] but not [[azbycxdw]].

bug 835:
1) [[dime]] has the normal syntax:
	[[Category:Currency]]
2) [[dime/bus stop]] has some new syntax like:
	{{:dime|no_cat}}

In this case [[Category:Currency]] lists [[dime]] but not [[dime/bus stop]].

bug 450 offers a (good|bad) solution for bug 706, but not for bug 835 (since
both pages are in the article namespace).

BTW in bug 706 comment 8, case 1 is what is being discussed at bug 706 and case
2 is what is being discussed at bug 835, but for the fact that case 2 of bug 706
comment 8 seems to deal only with transclusion of a page in Template: namespace
but bug 835 attempts to deal with the transcluded page being in any namespace.

Of course I meant:

bug 706:
1) [[azbycxdw]] has the normal syntax:
	{{delete}}.
2) [[Template:Delete]] has some new syntax like:
	[[Category:Candidates for speedy deletion|Template:Delete|no_cat]]

In this case [[[Category:Candidates for speedy deletion]] LISTS [[azbycxdw]] but
DOES NOT LIST [[Template:Delete]].

Sorry for any confusion.

The bug stops can be implemented in various ways. Bug 835 in a bug
450-implementation would be possible, eg:

1) [[dime]] has the normal syntax:
	[[Category:Currency]]
2) [[Wikipedia:dime (bus stop)]] has normal syntax:
	{{:dime}}

In this case [[Category:Currency]] lists [[dime]] under Articles, but it lists
[[Wikipedia:dime (bus stop)]] under Policy and meta-documents. That is, the bus
stops no longer polute the Articles categories; instead, they polute a different
section. (Bug 450 does not fulfill the requests bug 706 and bug 835; it just
puts their unintended listings in a less prominent location.)

I realised the summary was actually saying the wrong thing, because it implied
the syntax would be in the template:
[OLD:] "category syntax such that the page the syntax is in IS categorized but
other pages transcluding it AREN'T"
What we want is syntax to go in the *containing* page that prevents it
inheriting categories from "templates" (by which I mean transcluded pages,
whether or not they're in the Template: namespace)
[NEW:] "syntax to transclude a page without the containing page being categorised"

Note that bug 1110, which I'm going to mark as a dupe of this, suggests
__NOTEMPLATECAT__, which is slightly different from any of my suggestions at bug
706 comment 8, in that it would presumably allow directly entered
"[[Category:Foo]]" to categorise the page. I'm not sure, however, how easy this
would be with the current structure of the code, because I think transclusion
are just "folded in" before any other parsing of things like categories is done,
so there's no way of the parser knowing whether a particular link was
transcluded or is in the "real" page.

*** Bug 1110 has been marked as a duplicate of this bug. ***

(In reply to comment #6)
> Note that bug 1110, which I'm going to mark as a dupe of this, suggests
> __NOTEMPLATECAT__, which is slightly different from any of my suggestions at bug
> 706 comment 8, in that it would presumably allow directly entered
> "[[Category:Foo]]" to categorise the page. I'm not sure, however, how easy this
> would be with the current structure of the code, because I think transclusion
> are just "folded in" before any other parsing of things like categories is done,
> so there's no way of the parser knowing whether a particular link was
> transcluded or is in the "real" page.

Any solution to this bug requires some processing during the "folding in" before
parsing other things. How about inserting "special" delimiters for start & end
of template text while "folding in" and letting the parser handle these regions
specially later on?

e.g. "foo {{templ}} bar" is currently replaced by "foo contents of
Template:templ bar". Instead replace it with "foo {{contents of Template:templ}}
bar". When the parser sees the "{{" (unless it is within <nowiki>) it'd know it
is processing code from within a template (Apart from this, it ignores the
"{{"). It remembers it is within the template until it reaches the *MATCHING* "}}".

If "foo {{nocat|templ}} bar" is used, the parser sees "foo {{nocat|contents of
Template:templ}} bar". After the "{{nocat|", category tags are ignored until the
*MATCHING* "}}".

(In reply to comment #8)
> e.g. "foo {{templ}} bar" is currently replaced by "foo contents of
> Template:templ bar". Instead replace it with "foo {{contents of Template:templ}}
> bar". When the parser sees the "{{" (unless it is within <nowiki>) it'd know it
> is processing code from within a template (Apart from this, it ignores the
> "{{"). It remembers it is within the template until it reaches the *MATCHING*
"}}".

In some ways, this *would* be a sensible approach, but unfortunately the current
parser isn't really a parser, and doesn't work in a "sequential" manner of that
kind. It mainly consists of global pattern-matching substitutions, or splitting
the entire page into sections beginning with each occurrence of a particular
pattern (e.g. links are dealt with by splitting the text on every occurrence of
"[["). 

So anything involving "process differently from here ... up to here" has to
involve processing that section seperately, and then re-assembling things
afterwards. And we can't do that with templates without breaking the way people
use them: e.g. "{{template w/ start of table}} {{template w/ middle of table}}
{{template w/ end of table}}" only works because the parser does the
substitutions *before* looking at the table syntax.

This is why I suggested in bug 706 comment 8 that __NOCAT__ was very easy but
rather inflexible. The only way I can think of doing the other suggestions
("__NOTEMPLATECAT__", "<nocat></nocat>", and even "{{nocat:foo}}") would be to
go through and delete everything matching "[[Category:.*]]" in the affected bit
of text before the replaceInternalLinks() function has a chance to spot them.
Being careful, of course, to do so *after* all "<nowiki></nowiki>" sections have
been hidden from the parser.

Perhaps in Parser::braceSubstitution() [which handles the actual transclusion]
we could add something like:
if($no_inherit_cats) { <remove anything that looks like a Category tag> };
somewhere just after "$text = $this->strip( $text, $this->mStripState );"

This is still rather awkward, because it means writing a function specifically
for spotting [[Category:Foo]], which will presumably need its own check to
exclude [[:Category:Foo]] (that's normally dealt with by the link substitution
function, and I'm not sure Title.php will reliably tell the difference)


Apologies for the above being a) an odd mix of "beginner's guide" and "technical
overload" and b) a bit of a stream of conciousness. I may try hacking up a patch
in a moment.

> So anything involving "process differently from here ... up to here" has to
> involve processing that section seperately, and then re-assembling things
> afterwards. And we can't do that with templates without breaking the way people
> use them: e.g. "{{template w/ start of table}} {{template w/ middle of table}}
> {{template w/ end of table}}" only works because the parser does the
> substitutions *before* looking at the table syntax.

I didn't understand you. Of course, the substitutions must be done *before*
looking at the table syntax. That's how it is even if my approach is
implemented. Probably what I meant was that after the "fold in all templates"
pass, there should be a pass for "handle categories within {{...}}" and only
after that everything else should be done. Any problems with this approach still?

(In reply to comment #10)
> [...] Probably what I meant was that after the "fold in all templates"
> pass, there should be a pass for "handle categories within {{...}}" and only
> after that everything else should be done. Any problems with this approach still?

The problem I was originally thinking of was that we can't just say "oh, we've
come upon a <nocat> tag, don't process categories until we reach the </nocat>
tag" because the parser doesn't go through the text in order like that. (Which
was what you seemed to imply in comment 8: "...remembers it is within the
template...") It's more like "first, we deal with all the transclusions in the
entire text; next, we do all the italics and bold in the entire text; next, we
do all the internal links in the entire text; etc" [that order may not be right,
BTW]

But thinking about it, we can still replace every section matching "<nocat> ...
</nocat>" with its contents after [[Category:*]] tags have been removed. As in:
preg_replace ($text, "<nocat>(.*)</nocat>", "remove_category_tags($1)"); - no
"remembering we're inside", but roughly the same result. Which may or may not
make more sense than doing it just *before* dumping the template's content into
the article, I'm not sure. Still requires a function that spots and removes
Category tags, though.

(In reply to comment #5)
> In this case [[Category:Currency]] lists [[dime]] under Articles, but it lists
> [[Wikipedia:dime (bus stop)]] under Policy and meta-documents. That is, the bus
> stops no longer polute the Articles categories; instead, they polute a different
> section. (Bug 450 does not fulfill the requests bug 706 and bug 835; it just
> puts their unintended listings in a less prominent location.)

Hey, we totally forgot about the uglier problem -- A page listing templates (&
transcluding each of them) gets all the categories the individual templates
refer to (e.g. [[Wikipedia:Template messages/All]]). And this problem is not
addressed by bug 450.

(In reply to comment #12)
> Hey, we totally forgot about the uglier problem -- A page listing templates (&
> transcluding each of them) gets all the categories the individual templates

I meant lists all these categories at the top/bottom/(wherever acc. to the skin).

> refer to (e.g. [[Wikipedia:Template messages/All]]). And this problem is not
> addressed by bug 450.

*** Bug 1576 has been marked as a duplicate of this bug. ***

Syntax suggestion:

{{disp:template}}

"disp" stands for "display", since the primary purpose of this is to display the
template only, not have it be included in categories. This is consistent with
the "subst" modifier. I think it's best to be consistent here rather than invent
new syntax.

*** Bug 1691 has been marked as a duplicate of this bug. ***

(In reply to comment #16)
> *** Bug 1691 has been marked as a duplicate of this bug. ***

Just like the containing page not inheriting category tags, some want it not to
inherit interlanguage links. This allows interlanguage links to be used on
template pages to track templates doing the same thing in different language-wikis.

Probably just like a __NOTEMPLATECAT__ we could have a __NOTEMPLATEINTERLANG__
or just like a {{foo|no_cat}} we could have a {{foo|no_cat|no_interlang}} or
just like a {{no_cat:foo}} we could have a {{no_cat:no_interlang:foo}} (For some
reason the third option looks promising w.r.t. creating new problems...)

*** Bug 2338 has been marked as a duplicate of this bug. ***

Tim Starling has apparently coded a feature which fits this bug - a
"<noinclude>" tag.
See http://mail.wikipedia.org/pipermail/wikitech-l/2005-August/031123.html

compare with

bug 706: syntax such that a (template) page can be un-categorized, but still
categorise pages transcluding it

(In reply to comment #19)
> ... <noinclude>[[Category:Fruit]]</noinclude> ...

Resolving this bug as FIXED.

(In reply to comment #21)
> Resolving this bug as FIXED.

There are still some issues with nested templates:
<noinclude>...</noinclude> works only one level. This complicates template design.
See: http://epov.org/wd-gemet/index.php/Template:User_he

It did not make sense to include <noinclude>...</noinclude> in Template:User_lang:
http://epov.org/wd-gemet/index.php?title=Template%3AUser_lang&diff=392268&oldid=392032

Requesting that the code between <noinclude> and </noinclude> would not
transclude in the template namspace but in anything else is probably another
request / option.

best regards reinhardt [[user:gangleri]]

I'm quite surprised to see this bug closed. On closer inspection I find this was
because of the implementation of - syntax for a page to allow transcluding it
without the containing page inheriting categories, interlanguage links - which
is close, but no cigar.

To use the solution given here, we'd have to drop the original requirement that
the orginal, transcluded page is not modified for the sake of the bus stop.
Implementing it this way, the next editor to come along would wonder why there
was a noinclude on that page, and possibly remove it.

Or for the case of a template: to use this solution means a non-selective
choice: if something, eg. a category, should not be included for a certain page
then it's never included.

~~~~

*** Bug 4407 has been marked as a duplicate of this bug. ***

We appear to have about four suggested options here.

1) When called: <nocat>{{template}}</nocat>
2) When called: {{nocat:template}}
3) On caller page: __NOCAT__
4) In template: [[Category:Catname|Exclude:listofpagenames]]

3 is much too inflexible, and 4 scales terribly.  I would suggest option 2,
since it will in almost all cases be shorter to type than 1 and anyway fits with
what we currently have; it should preferably be combinable with existing subst:,
etc., although this is noncritical.

I would suggest the feature not automatically exclude interlanguage links,
however; they're different enough that they don't deserve to be lumped in with
categories.  (If anything, they should *never* be transcluded.)

(Note: removed testme, since the feature has obviously not been added.)

I also support option 2.

The original issue of 4407 was "template lists". A simple
trick allows this: {{{category|[[Category:target-cat]]}}}

The example usage of template {{X}} in list Y would add Y
to target-cat. But {{X|category=}} doesn't. 

(In reply to comment #27)
> The original issue of 4407 was "template lists". A simple
> trick allows this: {{{category|[[Category:target-cat]]}}}
> 
> The example usage of template {{X}} in list Y would add Y
> to target-cat. But {{X|category=}} doesn't. 

Sure, but that's hacky, confusing, and requires a lot more user-end maintenance
(does *this* template have the hack working yet? how about *this* one? oh, this
needs {{edit protected}} . . .).  A software solution would be much better.

*** Bug 6720 has been marked as a duplicate of this bug. ***

*** Bug 6293 has been marked as a duplicate of this bug. ***

*** Bug 9763 has been marked as a duplicate of this bug. ***

I agree with Simetrical's latest statements, in particular,
  "(If anything, they should *never* be transcluded.)"

And note that this bug is closely related to #167.

*** Bug 15941 has been marked as a duplicate of this bug. ***

(In reply to comment #25)
> We appear to have about four suggested options here.
> 
> 1) When called: <nocat>{{template}}</nocat>
> 2) When called: {{nocat:template}}
> 3) On caller page: __NOCAT__
> 4) In template: [[Category:Catname|Exclude:listofpagenames]]
> 
> 3 is much too inflexible, and 4 scales terribly.  I would suggest option 2,
> since it will in almost all cases be shorter to type than 1 and anyway fits with
> what we currently have; it should preferably be combinable with existing subst:,
> etc., although this is noncritical.
> 
> I would suggest the feature not automatically exclude interlanguage links,
> however; they're different enough that they don't deserve to be lumped in with
> categories.  (If anything, they should *never* be transcluded.)
> 
> (Note: removed testme, since the feature has obviously not been added.)

How would {{subst:nocat:template}} work? Would it just work as if the categories were wrapped in <noinclude> and not add them in the wikitext where its subst'd? <nocat>{{subst:template}}</nocat> seems like it would make more sense for this, as the result of substitution would just be the entire page text wrapped in <nocat>, which should still work as expected (preventing the categories from working) until the <nocat> tags are removed.

Reasonable point.  <nocat> might be the better idea.

<nocat> seems to be the best option. There are different cases to consider though.

Sandboxes, draft pages, etc should not show up in categories. However, they should show the categories at the bottom of the page so that new users see how it works.

In maintenance pages and for certain other applications, the page should not show up in categories and also be removed from the bottom of the page.

So we need two tags:
<nocat> that removes the page from wrapped categories (including transcluded ones) but let them visible on the page.
<hidecat> that hides the wrapped categories on the page (including transcluded ones) but let the page categorized in them.

I think I like {{nocat:...}} better than <nocat>. Semantically, the concept "transclude this page, but don't transclude categories" sounds very much like a sub-option of transclusion, rather than a whole separate operation.

>How would {{subst:nocat:template}} work?

Logically, it would do an in-place expansion of the template, and every template reference transcluded would have "nocat:" inserted. For example:

Page 1:
----
Testing.
{{subst:nocat:Page 2}}
----

Page 2:
----
I am transcluded. 
{{stub}}
[[Category:Transcluded pages]].
----

Stub:
----
This page is a stub. 
[[Category:Stubs]]
----

Page 1 would be saved as:
----
Testing.
I am transcluded.
{{nocat:stub}}
----

The alternative proposed above would lead to Page 1 being saved as:
----
Testing.
<nocat>
I am transcluded.
{{stub}}
</nocat>
----

Advantages of <nocat>:
- You can do <nocat>[[Category:Foo]]</nocat>, which seems, um, pointless.
- You can do <nocat>{{template1}}, {{template2}}</nocat>. Is this useful? Do we often want to transclude multiple pages, and ensure that none of their categories apply? This is probably only useful on pages that serve as lists of templates, and there would be other solutions, like creating a {{tpl-nocat}} template or something.

Advantages of {{nocat:...}}:
- Semantically cleaner.
- Uses less characters (for a single transclusion, anyway).

As for <hidecat>, is this really needed? We have __HIDDENCAT__, so <hidecat> would mean "transclude page X, and although page X is in some categories which aren't normally hidden, hide them anyway". Can you give an example why this is useful?

I just read #36 more closely:

> <nocat> that removes the page from wrapped categories (including transcluded ones) but let them visible on the page.

Eep. I thought <nocat> would mean "Don't transclude categories at all". Sounds like we need four distinct ways of transcluding categories:

- Normal: Add page to category, show on page.
- Nocat: Don't add page to category, or show on page.
- Hidecat: Add page to category, but don't show on page.
- ??? (nogroup?): Don't add page to category, but show on page.

Obviously these are two independent flags (hide/show, categorise/don't categorise), but I don't know if that would be more useful.

Steve

(In reply to comment #37)

> Page 1 would be saved as:
> ----
> Testing.
> I am transcluded.
> {{nocat:stub}}
> ----
> 

Except that's inconsistent with how everything else works. If you subst one page onto another, you get *exactly* what's on that page, minus anything wrapped in <noinclude>, this would be transcluding something different.

And what happens if you have something like
----
{{subst:nocat:template1}}
----
where template1 consists of:
----
{{<includeonly>subst:</includeonly>template2}}
----
and template2 is something complicated like
----
{{#ifeq:{{NAMESPACE}}|{{TALKSPACE}}|This template should not be used on talk pages|[[Category:{{#ifeq:{{NAMESPACE}}|{{ns:6}}|Files|Content}} using template2]]}}
----

<nocat> would still work the same, but {{nocat:}} gets somewhat convoluted, and I'm sure I could find a lot more complex examples on enwiki.

>Except that's inconsistent with how everything else works. If you subst one
page onto another, you get *exactly* what's on that page, minus anything
wrapped in <noinclude>, this would be transcluding something different.

That's not a convincing argument. Subst always works the same way because it doesn't have any options. Adding an option of course violates the principle that it always behaves the same way: that's why you have options.

>And what happens if you have something like

<snip>

><nocat> would still work the same, but {{nocat:}} gets somewhat convoluted

That is a convincing argument.

{{nocat:subst:...}} seems mildly cleaner semantically, but would (I think) be a real bitch to code, for the reasons given here, so probably isn't worth it.

So, can we agree on:
- <nocat>...</nocat>: no categories that appear between the start/end tag, whether by transclusion, substitution, or otherwise, will be shown on the page, or have the page grouped in them
- <hidecat>...</hidecat>: page is grouped in any categories, but not shown.
- <???>...</???>: cats are shown, but no grouping (need a name for this)

Also, what happens when:
- a page that contains some <nocat>...</nocat> or <hidecat>...</hidecat> is itself transcluded? I guess the simplest rule would be that once hidden, categories remain hidden. Best not to implement a <showcat> or something then.

nocat: looks like it would be a pain to implement, so <nocat> seems like the better choice, yes.  Having to find all templates and so on in the source code and add nocat: before each invocation would be a pain, and it wouldn't even necessarily work if some non-template construct adds a category as a side effect.

Question: if some construct with <nocat> around it adds the page to [[Category:Pages with too many expensive parser function calls]], or [[Category:Hidden categories]], or some similar thing, should that be suppressed?  My inclination would be not.

As for <hidecat>, what would the use-case be for that again?  We already have __HIDDENCAT__; why would we want to hide the category from some pages and not others?  It sounds like it could be chaotic.

And <???> seems completely strange, outright deceptive in fact.  If a category is listed, the page should be in the category.  That's the point of the category list, not to serve as some kind of list of arbitrary categories that the current page may or may not be in.

Wouldn't it make more sense for 'suppressed' categories to show up as internal links, in the same way that image inclusions 'suppressed' by the bad image list are converted into (admittedly usually nonsensical) links? This strikes me as a similar concept.  I agree that there seems to be very little use for <hidecat>. 

(In reply to comment #42)
> Wouldn't it make more sense for 'suppressed' categories to show up as internal
> links, in the same way that image inclusions 'suppressed' by the bad image list
> are converted into (admittedly usually nonsensical) links? This strikes me as a
> similar concept.

The use-cases here are things like "include a template into a page that lists templates, while not including its categories, since those are meant for where it's actually used".  In such cases you clearly don't want links being randomly scattered about the place, you want it to display as it usually does (just not categorize).

>And <???> seems completely strange, outright deceptive in fact.

I agree. The use case was for sandbox pages, but I don't think it's compelling.

So, all in favour of implementing <nocat>, and leaving the others until there is some serious demand for them?

I see that there are good reasons both to show and not show the "disabled" categories in the category footer box at the bottom of the page. To show them would be confusing for instance on the pages under [[Wikipedia:Template messages]]. But would be good when testing templates in sandboxes.

So I did a little thinking: If you have enabled to see hidden categories in your settings, then they are shown on a second line in the category footer box prefixed by the text "Hidden categories:". The disabled categories could be listed in the same way, say prefixed by the text "Disabled categories:". 

And to avoid anyone misunderstand what I mean: I think the disabled categories should always be shown like that, there is no need for an option to hide them. Since if they are prefixed like that they are no longer confusing.

I would like if the "disabled categories" list were surrounded by a div tag with some id and class so we can style them, for instance to use smaller text.

As far as I understand, this comment #45 just debates whether or not to display the <nocat>'ed categories, without regard to whether or not to implement <nocat>.

>If you have enabled to see hidden categories in your settings, then they are shown on a second line in the category footer box prefixed by the text "Hidden categories:". The disabled categories could be listed in the same way, say prefixed by the text "Disabled categories:". 

To clarify, I think by "hidden category" you mean any category that has __HIDDENCAT__ in its page text, and by "disabled category", you mean any category *reference* that is not parsed because it is ultimately surrounded in a <nocat>...</nocat> tag.

>I think the disabled categories should always be shown like that, there is no need for an option to hide them.

Is there a benefit? The <nocat> tag would be there to avoid spurious category links being formed or shown. If "hidden" categories can be shown, it's because the page really *is* in that category. But the page is *not* in a "disabled" category. I don't see the value of displaying it.

A list of which categories have been suppressed on a page would be invaluable for both debugging and abuse-monitoring.  Perhaps they should be listed with the other 'metadata' on the edit page? 

(In reply to comment #46)
> As far as I understand, this comment #45 just debates 
> whether or not to display the <nocat>'ed categories, 

Correct. But yes, I would find the <nocat> </nocat> tags very useful. And <nocat> would be much more useful than the other suggested methods.

> To clarify, I think by "hidden category" you mean any category 
> that has __HIDDENCAT__ in its page text, and by "disabled category",
> you mean any category *reference* that is not parsed because it 
> is ultimately surrounded in a <nocat>...</nocat> tag.

Correct.

> > I think the disabled categories should always be shown like that, 
> > there is no need for an option to hide them.

> Is there a benefit? The <nocat> tag would be there to avoid 
> spurious category links being formed or shown. ...
> ... I don't see the value of displaying it.

There are two issues here: 
1: To avoid that a page gets put in a category by a template only displayed, discussed or tested on a page.
2: To avoid making users think that the page has been categorised when it has not been categorised.

And two usage cases:

1: Templates often do pretty advanced category magic. Thus we need to test and show that category magic. Thus we need to see what categories the template causes, even on test pages. But preferably without the page actually getting categorised. And that means we can leave such demonstrations "forever" without the demonstration page showing up in the category.

2: On pages such as the pages under [[Wikipedia:Template
messages]] on the English Wikipedia, where lots of templates are demonstrated, we also don't want the templates to categorise the page. And ideally we wouldn't want to see the categories there. But more importantly we don't want users to think that the page has been categorised.

Thus if we list the "disabled categories" separately, prefixed by "Disabled categories:" we fulfil all our needs at once. (Albeit it is a compromise.)

The next step could be to make a magic word that makes the "Disabled categories:" list not show at the bottom of the page. Thus the same <nocat> </nocat> tags can be used on such a page, making things simpler both for the users of those tags and for the MediaWiki coders. But such a magic word is not especially necessary, it would just be a luxury.

I think the 2 separate use cases would be best served by 2 separate features:

(1)
Requirement: For demonstrating templates or other convoluted syntax that would normally categorise a page, such as on an instruction page or list of templates. 

Proposed solution: <nocat>...</nocat> construct that strips all [[Category:...]] links out of the text it surrounds, so that the page is not added to any of the categories mentioned, and those categories are not displayed in any way.

(2)
Requirement: For testing templates, category syntax, etc, such as on a sandbox or tutorial.

Proposed solution: __UNCATEGORISED__, which would stop the entire page being added to any categories, but continue to show the "Categories:" list at the bottom of the page.

We could have an additional note saying something like "This page is not actually included in any categories, but would be included in the following:"

The advantage of having __UNCATEGORISED__ at the page level is that it could be included in {{Please leave this line alone (sandbox heading)}} and similar, whereas simply opening a <nocat> section would rely on no-one closing it prematurely.

It would even allow one to test the <nocat> feature on the sandbox, since [[Category:Foo]]<nocat>[[Category:Bar]]</nocat> would show only "Foo" in the list of categories at the bottom of the page.

Just to confirm:
A  <nocat>...</nocat> construct would fulfil our original request.

To summarize, I think we need:
*A global magic word __DECATEGORIZE__ that removes the page from all categories, but still displays them as normal at the bottom of the page.
*A tag <decat> </decat> that removes the page from all wrapped categories, but still displays them as normal at the bottom of the page.
*A tag <nocat> </nocat> that removes the page from all wrapped categories, and remove them from the bottom of the page.

Uses:
*__DECATEGORIZE__ (used with the intermediary of a template {{DECATEGORIZE}} like __HIDDENCAT__) could be used, essentially, for the thousands of sandboxes and draft pages that pollute categories and related changes. However, for convenience and especially in the interest of newbies, it's better to display categories on the page.
*<decat> would be used, for example, for [[WP:AFC]] pages, that are categorized by the [[Template:AFC submission]], but that shouldn't include categories added by the user as part of the proposed article.
*<nocat> would be used for many maintenance pages that transclude templates temporarily or indefinitely and hence add themselves to categories. 

__DECATEGORIZE__, though less flexible, has several advantages on <nocat> : it's searchable, it's global so cannot be canceled out like <nocat>, it's cleaner for global use. It also seems to be the easiest to compute, and the most needed.

>*A tag <decat> </decat> that removes the page from all wrapped categories, but
still displays them as normal at the bottom of the page.
>*A tag <nocat> </nocat> that removes the page from all wrapped categories, and
remove them from the bottom of the page.

This naming isn't going to work - "decat" and "nocat" sound totally synonymous to me. At least "hidecat" refers to the visual effect.

>*A global magic word __DECATEGORIZE__ that removes the page from all
categories, but still displays them as normal at the bottom of the page.

The more I think about this, the more it seems of limited use. Even a page that primarily includes other pages is likely to want to be categorised in some categories of its own. So it might be better as a "from this point on" tag.

But, anyway, there is a lot of consensus for a nocat and hidecat/decat tag. Is there a formal process for requesting that it be implemented?

Steve

(In reply to comment #52)
> But, anyway, there is a lot of consensus for a nocat and hidecat/decat tag. Is
> there a formal process for requesting that it be implemented?

Yes, file a bug.  If that doesn't get it done quick enough, either find some developers to nag about it or write the functionality yourself.

"File a bug"? Like bug 835, opened: 2004-11-06 17:30 UTC, you mean? Oops, it seems I forgot the anniversary cake again. Well, maybe on the fifth anniversary.

Yes.  Sorry if I wasn't clear, my point is that there is a formal process and it has been followed (since this bug was in fact filed).  The formal process that exists will not guarantee that your bug gets fixed -- there's not enough developer manpower out there for that to be possible.  Further progress on this will require someone to do some coding.  If you aren't willing or able to do that, you're going to have to try to get other people to, one way or another; there's no formal process for doing that beyond what's already been done.

Created attachment 5696 [details]
nocat: implementation

This patch allows the {{nocat:}} functionality. If a template is called by being prefixed with nocat: it ignores the categories in the template.

Not sure how optimal this implementation is but it works.

Created attachment 5720 [details]
Parser tests

Created attachment 5721 [details]
Parser tests 2

Due to bug 17100 these tests have to be split up and can't be integrated into the main parserTests.

+			if ($nocats ) {
+			$text = preg_replace('/\[\[category:.*?\]\]/i','',$text);
+			}


That isn't very elegant.

It will fail at least in the case of foreign languages and extra whitespace (the latter is trivial to correct, though).  And possibly other things as well, although I can't think of them.  This very much seems like the wrong approach overall.  But don't ask me what the right one is, I have no idea.

It cannot handle pages with dynamically transcluded templates and would be difficult to use for sandboxes and draft pages, which is almost all the use for this on enwiki (we have thousands, see for example [[Wikipedia:Database reports/Polluted categories]]).

There is only <nocat> ... </nocat> that can handle this, and <decat> ... </decat> for demonstration/new user pages such as sandboxes, articles for creation...

I think the names are different enough, nocat for No Category, and decat for decategorize. __DECATEGORY__ and __NOCATEGORY__ are not especially needed if we have the tags.

Another concern with categorization due to templates that may be addressed by nocat tags are user css or js. They are sometimes incorrectly categorized, for example see [[en:Category:Wikipedia pages with incorrect protection templates]].

A tag <decat> </decat> that keeps the page out of all wrapped categories, but does display such categories, would satisfy our original request.

A global magic word __DECATEGORIZE__ that keeps the page out of all
categories, but does display them, would too, in theory. In practice, however, it would prevent us from categorising the busstop pages in e.g. a [[Category:Busstops]]. I suggest this alternative be dropped.

A tag <nocat> </nocat> that keeps the page out of all wrapped categories, and doesn't show such categories either, would also satisfy our original request. The differences with decat are a trade-off issue, and might depend on the specific audience of a busstop.
For the naming similarity, this one could be <nocats> instead, assuming that name isn't in use for some other function as yet.

~~~~

By help pages illustrating the output of templates would be nice a tag <nocat> </nocat> that keeps the page out of all wrapped categories.

I suggest these magic word names, excuse me for my English:
1. __NOTRANSCLUDEDCATS__ and __NOTRANSCLUDEDINTERWIKIS__ to block all transcluded stuff on a given page, or

An alternative solution may be:
2. __NOCATSABOVE__ and __NOINTERWIKISABOVE__ to block all categories and interwikis (be them written or trancluded) appearing *before* the magic word itself in the wikitext, but accepting those appearing (as usually) at the end of the page.

{{transcluded page with its own cats being blocked}}
__NOCATSABOVE__
[[category for this page]]

-keyword need-review, +keyword reviewed per comment 53.

A no category transclusion method should work on a deeper level than just regexing out the categories from the input text.

Created attachment 9788 [details]
Add {{nometa:some templat|arg1|arg2|....}} syntax to disable transcluding categories and interlanguage links

Hmm, this is difficult to do, since the category/interlanguage links are expanded after templates are expanded. Maybe the new parser work would make doing such things easier (I'm not paying attention at all to whats happening with that stuff, so I have no idea if it'd change things or not).

The best way of implementing this I could think of:
*Save all the interlangs and categories
*Parse the template (in a recursiveTagParse type of way), and put it in the page at right spot
*Reset the interlangs/categories to the way they were before doing that.

So this patch adds a new parser func that looks more like its modifying the template call then being an actual parser func. It looks like {{nometa:Some template|args...}} (I didn't use a hash to make it look like int:, raw:, msgnw: etc).


Personally I like the name nocat: better, but nometa: is more generic in terms of applying to interlanguage links too. One minor issue is that it also stops tracking categories. I also wasn't sure if it should deal with {{DISPLAYTITLE:}}, {{DEFAULTSORTKEY:...}}, __NOTOC__, etc. As it stands, my patch lets those types of behaviour switches through.

It feels mildly icky to save and reset parts of the parser output, and I'm generally just nervous about things that touch the parser (Although this doesn't directly touch it really), hence I'm posting this as a patch instead of directly committing. (as an aside, if its decided this approach isn't an acceptable solution, this can trivially be turned into an extension for those who really want it).

So, thoughts?

Since it looks like this is not going to be a trivial feature to implement, perhaps it's better worth the time to invest in bug 167 (storing meta data outside of wiki page contents and versioning it separately) - which would make this bug 835 redundant and also prevents making the syntax more complicated.

(In reply to comment #68)
> Since it looks like this is not going to be a trivial feature to implement,
> perhaps it's better worth the time to invest in bug 167 (storing meta data
> outside of wiki page contents and versioning it separately) - which would make
> this bug 835 redundant and also prevents making the syntax more complicated.

bug 167 imho has its own issues which make it more complicated then this one. Most people on that bug don't even agree what they want the feature to look like (Everything from including hot cat in core, to fully having the cats out of wiki text is suggested). There's issues with how conditional inclusion would work (which is not a feature I could imagine the Wikipedian's wanting to give up).