Please add namespace name "Category" to categories listed at [[Special:UnusedCategories]]. This makes it easier to copy all category names and paste it to a file to be used by bots (like to nominate all these categories for deletion) instead of having to add the namespace name manually.
Current:
Requested:
Version: unspecified
Severity: normal
URL: http://en.wikipedia.org/wiki/Special:UnusedCategories
Hello,
I'm offering to add a setting in MediaWiki to control this output.
[ Technical part - add a setting in MediaWiki ]
Configuration name: $wgPrependCategoryInCategoriesSpecialPages
I'm also offering to offer a consistent output in the following special pages:
I would prefer to let [[Special:Categories]] untouched (ie no prefix), as it's the way to browse through categories.
Feedback is welcome on this proposition.
[ Social part - get a local consensus ]
If this new setting is validated and added to MediaWiki core, we'll have to set it as false by default (no prefix) and true to en.wikipedia.
This is a site configuration change, and that requires a local consensus. Please discuss the matter the way you feel appropriated on the wiki.
If the en.wikipedia community validates your proposition, please open a second ticket on Bugzilla with the following values:
So in a nutshell, I'm coding the setting, and meanwhile, you ask your community (en.wikipedia) if they want to have this Category: prefix on these pages.
I can't see any reason why you would ''not'' want the namespace name on any of those special pages.
(In reply to comment #0)
Please add namespace name "Category" to categories listed at
[[Special:UnusedCategories]]. This makes it easier to copy all category names
and paste it to a file to be used by bots (like to nominate all these
categories for deletion) instead of having to add the namespace name manually.
This isn't a valid use-case as far as I'm concerned. You should be using the API to retrieve these lists, not copying and pasting. The GUI is for presentation, not scripting.
(In reply to comment #1)
I'm offering to add a setting in MediaWiki to control this output.
[ Technical part - add a setting in MediaWiki ]
Configuration name: $wgPrependCategoryInCategoriesSpecialPages
I don't understand the purpose for implementing this additional configuration variable. What problem is this intended to solve? And why do you believe a configuration variable is the best way to solve this problem (or these problems)?
(In reply to comment #5)
(In reply to comment #0)
Please add namespace name "Category" to categories listed at
[[Special:UnusedCategories]]. This makes it easier to copy all category names
and paste it to a file to be used by bots (like to nominate all these
categories for deletion) instead of having to add the namespace name manually.This isn't a valid use-case as far as I'm concerned. You should be using the
API to retrieve these lists, not copying and pasting. The GUI is for
presentation, not scripting.
A software is used by users, so it's up to them to use the tools the more convenient for them. For example, there are several JS gadgets like VisualFileChange in Commons where you could copy/paste a set of pages title to perform batch operation.
(In reply to comment #1)
I'm offering to add a setting in MediaWiki to control this output.
[ Technical part - add a setting in MediaWiki ]
Configuration name: $wgPrependCategoryInCategoriesSpecialPages
I don't understand the purpose for implementing this additional configuration
variable. What problem is this intended to solve?
If we see the bug report, we see there are two ways to present categories.
The setting allows to choose one or the other.
Current:
- Catname1
- Catname2
- Catname3
$wgPrependCategoryInCategoriesSpecialPages = false;
Requested:
- Category:Catname1
- Category:Catname2
- Category:Catname3
$wgPrependCategoryInCategoriesSpecialPages = true;
And why do you believe a
configuration variable is the best way to solve this problem (or these
problems)?
There are arguments for both versions.
Without, it's simpler to read.
With, it's more accurate and allow copy/paste in a tool an easier way.
So, I would like to have the choice in a MediaWiki installation to use one of the other.
(In reply to comment #6)
This isn't a valid use-case as far as I'm concerned. You should be using the
API to retrieve these lists, not copying and pasting. The GUI is for
presentation, not scripting.A software is used by users, so it's up to them to use the tools the more
convenient for them. For example, there are several JS gadgets like
VisualFileChange in Commons where you could copy/paste a set of pages title to
perform batch operation.
The point of these Special pages viewed via (the implicit) ?action=view is to show users a graphical report of particular wiki data. If users want to re-use this content in another script or program, the reports' data _must_ be accessed via the API, not via copy and paste. This has become a fundamental principle of MediaWiki development.
There are arguments for both versions.
Without, it's simpler to read.
With, it's more accurate and allow copy/paste in a tool an easier way.
It's not more accurate, it's just redundant (as conceded by you in comment 4). :-)
So, I would like to have the choice in a MediaWiki installation to use one of
the other.
Global configuration variables have a pretty high cost. The benefit here is very, very limited (in my opinion, a valid use-case for adding the prefixes still hasn't even been presented). If users want the prefixes, they can and should write a simple JavaScript gadget or similar. I don't see a reason to implement a configuration variable here.
(In reply to comment #7)
Global configuration variables have a pretty high cost. The benefit here is
very, very limited (in my opinion, a valid use-case for adding the prefixes
still hasn't even been presented). If users want the prefixes, they can and
should write a simple JavaScript gadget or similar. I don't see a reason to
implement a configuration variable here.
Indeed, this does not need a configuration variable.
I don't rightly care one way or the other if the namespace is actually there, but pick one or the other and just do that for everyone.
Hashar offers also an alternative in a Gerrit comment:
"Would it make sense to add a feature to QueryPage so that users can have that list displayed as text or download the current list ?"
Absolutely not. If people want the list in a text format (eg: for parsing or programming with or something) then people should use the API.
We should support all query pages via the API, and if we don't, that's another bug.
This bug is a silly bug bikeshedding over whether we should use prefixed names or not when displaying a special page (which I don't even care about, I've only invested time to prevent poor solutions from being implemented).
We've a consensus not to fix this bug.
I'm opening a new bug to standardize output across pages and abandoning proposed Gerrit change.