Last modified: 2014-07-06 21:21:13 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 491 - Categories need piping feature to list by alternative name
Categories need piping feature to list by alternative name
Status: PATCH_TO_REVIEW
Product: MediaWiki
Classification: Unclassified
Categories (Other open bugs)
unspecified
All All
: Low enhancement with 12 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
:
: 5116 5854 5916 6111 6542 10035 11490 61414 (view as bug list)
Depends on: 29975 1476
Blocks:
  Show dependency treegraph
 
Reported: 2004-09-15 00:09 UTC by Ellen Finch
Modified: 2014-07-06 21:21 UTC (History)
18 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Ellen Finch 2004-09-15 00:09:35 UTC
For example, for some odd reason, "Spaying" redirects to "Oophorectomy" (rather
than the other way 'round, which I'd think would make more sense. but that's not
a software issue, and this isn't the only example).  So when Oophorectomy is
assigned to a category about dogs, it shows up in the list as Oophorectomy and
there is no way to put in parens or relist it as Spaying so that people can find
it.  So I added the category to the Spaying redirect page, which now indeed
lists spaying in the category page-- BUT clicking on Spaying now displays the
Spaying page with the redirect command rather than correctly falling through to
Oophorectomy, which is what a link to Spaying would do anywhere inthe article
namespace.  (So maybe this is both a feature request and a bug report.)  (elf)
Comment 1 Michael Keppler 2005-06-10 20:56:05 UTC

*** This bug has been marked as a duplicate of 1476 ***
Comment 2 Michael Keppler 2005-06-10 21:43:49 UTC
Closing again as duplicate as I see no difference to 1476. The bug is about
adding categories on redirect pages, which is the same as 1476. The title says
something about pipes, but that is just not what the bug is all about (and pipes
for categories _are_ implemented).

Please add at least a comment why you are reopening this bug.

*** This bug has been marked as a duplicate of 1476 ***
Comment 3 Zigger 2005-06-10 21:49:59 UTC
Re-opened, as this asks for a change to the linking of categorised redirections,
to remove "redirect=no".  Categorising redirections is currently prevented by
the 1.4 change which bug 1476 asks to reverse.
Comment 4 Zigger 2005-06-10 22:24:09 UTC
To try and clear this up, in 1.3 categories in redirects work.  In 1.4 and
later, they do not (bug 1476).

On category pages in 1.3, listed pages which are redirects already do not use
"redirect=no", i.e. clicking them automatically leads to an actual article
rather than to the redirect itself.  The default listed name is the name of the
redirect page.  All this seems good, and is a solution that was once available.

Also, bug 1333 asked to be able to list multiple names for an article, as
categorising redirects cannot be done.  Even if the redirect-categorising
feature returns, there may be cases where multi-listing is useful without redirects.

The "sort text" used with the category piping feature could be used for the
listed name on the category page, or another pipe parameter added.  That is
covered here (bug 491).
Comment 5 mkail 2005-07-21 23:58:43 UTC
This feature would be very useful for musical artists.  Rap and electronic
artists commonly use a pseudonym to release their music.  In some cases one
person can have several pseudonyms.  An article could be created for each
pseudonym but that would either create redundancy or stubs.
Comment 6 Zigger 2005-07-22 04:11:40 UTC
(In reply to comment #5)
> This feature would be very useful for musical artists.  ...
> ...  An article could be created for each
> pseudonym but that would either create redundancy or stubs.

Multiple listings in a category can be done by categorising redirections.  See
bug 1476, which was fixed in 1.5.
Comment 7 lɛʁi לערי ריינהארט 2006-01-08 14:35:04 UTC
removed "Blocks" bug 1333
Bug 1333: Would like the ability to list an article under multiple names in its
categories

because bug 1333 is already marked as a duplicate of bug 1476
Bug 1476: Category tag on redirect pages does not work
Comment 8 Rob Church 2006-03-02 22:39:07 UTC
*** Bug 5116 has been marked as a duplicate of this bug. ***
Comment 9 Rob Church 2006-05-06 20:28:01 UTC
*** Bug 5854 has been marked as a duplicate of this bug. ***
Comment 10 Wolf Peuker 2006-05-12 07:20:53 UTC
This Issue is related to [http://bugzilla.wikimedia.org/show_bug.cgi?id=5908 bug
5908], I think we should have both, 
* optional default sorting in cases where naming and sorting conventions
conflict and
* alias-indexing in Categories

I think, listing alternative names could be simple. In Markup we could write
[[Category:Artist|Name]]
[[Category:Artist|Alternative Name]]
In the Database, in the table
<tt>[http://meta.wikimedia.org/wiki/Categorylinks_table Categorylinks]</tt> the
<tt>PRIMARY KEY</tt> could expand to <tt>cl_sortkey</tt>.
Comment 11 Minh Nguyễn 2006-05-12 07:29:19 UTC
There could be an issue, though, where editors have placed category tags in
non-standard places (like before the External links section), and another editor
has placed the same category tag in the standard place.
Comment 12 Wolf Peuker 2006-05-12 07:32:14 UTC
*** Bug 5916 has been marked as a duplicate of this bug. ***
Comment 13 Wolf Peuker 2006-05-12 07:38:09 UTC
I think the priority could be higher.
Comment 14 Wolf Peuker 2006-05-12 07:48:52 UTC
(In reply to comment #11)
> There could be an issue, though, where editors have placed category tags in
> non-standard places (like before the External links section), and another editor
> has placed the same category tag in the standard place.
The category tags need not to be placed in standard-places only. They can also
be included from templates.
Comment 15 Wolf Peuker 2006-05-12 08:02:27 UTC
(In reply to comment #10)
> This Issue is related to [http://bugzilla.wikimedia.org/show_bug.cgi?id=5908 bug
> 5908], I think we should have both, 
> * optional default sorting in cases where naming and sorting conventions
> conflict and
> * alias-indexing in Categories
> 
> I think, listing alternative names could be simple. In Markup we could write
> [[Category:Artist|Name]]
> [[Category:Artist|Alternative Name]]
> In the Database, in the table
> <tt>[http://meta.wikimedia.org/wiki/Categorylinks_table Categorylinks]</tt> the
> <tt>PRIMARY KEY</tt> could expand to <tt>cl_sortkey</tt>.

Oh, I was wrong about the normal syntax:
 [[Category:Artist|Sort]]
with alternative names it should be like this
 [[Category:Artist|Name|Name]]
 [[Category:Artist|Alternative Name|Alternative Name]]
or 
 [[Category:Artist||Name]]
 [[Category:Artist||Alternative Name]]
or 
 [[Category:Artist|Name|]]
 [[Category:Artist|Alternative Name|]]
Comment 16 Brion Vibber 2006-05-27 17:59:57 UTC
*** Bug 6111 has been marked as a duplicate of this bug. ***
Comment 17 Enzo D'Ambrosio 2006-05-27 22:31:10 UTC
Rad bug 6111, this feature should be very usefull on wikibooks
Comment 18 Enzo D'Ambrosio 2006-05-27 22:31:57 UTC
Read bug 6111, this feature should be very usefull on wikibooks
Comment 19 Karl Dickman 2006-08-11 23:24:14 UTC
I was looking over bug 1775, which has been marked as blocked by this one.  But
there's no reason why it should be.  The proposed system under Bug 1775 is
intended to increase the information available in categories.  The example used
there:
[[Category:Actors|Smith, John|birthdate=...|deathdate=...]]

I don't see why these bugs can't be merged, using a syntax like
[[Category:Actors|Smith, John|alternate_name=Smith,
Johnnie|birthdate=...|deathdate=...]]
Comment 20 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-08-13 02:26:41 UTC
If bug 1775 was solved, you could specify an option "page name" or something
that would include the name to be displayed . . . but that still wouldn't
replace the actual name used, I suppose, which is rather what this bug is,
you're right.
Comment 21 Matthew Flaschen 2007-01-01 09:32:05 UTC
A simple syntax for this would be a single optional caption parameter
after the the sort key. Thus,

[[Category:People|Smith, John|John Smith - American author]]

would display "John Smith - American author" in the category listing, but it
would sort using Smith, John.

If there's no caption parameter:

[[Category:People|Nye, Bill]]

MediaWiki should use the article name (Bill Nye).

(copied from Bug 6542)
Comment 22 Rob Church 2007-01-01 11:44:50 UTC
Some experimental stuff committed to a branch:
/svnroot/mediawiki/branches/robchurch/catdispnames. Could use some further
testing, but the basic idea is there.
Comment 23 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-01-01 17:13:46 UTC
*** Bug 6542 has been marked as a duplicate of this bug. ***
Comment 24 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-05-27 06:01:12 UTC
*** Bug 10035 has been marked as a duplicate of this bug. ***
Comment 25 David Lee 2008-02-27 00:03:33 UTC
Is there any progress on this?  To give a Wikipedia example which I think needs a resolution to this bug:

There is a main article about the hymn "A Mighty Fortress Is Our God".  This needs to go in "Category:Hymntunes" but appearing with the (German) title "Ein' feste Burg" (it should not appear under the English title).

There is already a simple redirect article "Ein' feste Burg" (and it should remain a simple redirect).

Borrowing the syntax of #21 I think it would need:
   [[Category:Hymn tunes|Eing' feste Burg|Ein' feste Burg]]

Or perhaps a simpler version when the sort and display texts are both the same:
   [[Category:Hymn tunes||Ein' feste Burg]]

Is this possible at present?  Or does it need a resolution to this bug?
Comment 26 Roan Kattouw 2008-02-27 09:39:00 UTC
Wouldn't it be much simpler to just move A Mighty Fortress to Ein' feste Burg, leaving A Mighty Fortress as a redirect? The difference is hardly noticeable.
Comment 27 David Lee 2008-02-28 21:30:04 UTC
Thanks for your reply.  Your thoughts are appreciated.

In this particular case, this is an English article in the English wikipedia about the English translation "A Mighty Fortress".  But inextricably linked with this is the hymn (song) tune called "Ein' feste Burg", mirroring the text's original German title and forming the name of the associated tune.  So most things about the article are English, but the tightly-bound tune name is "Ein' feste Burg".

In any printed English-language hymn collection (music edition), the "Index of tunes" contains "Ein' feste Burg" which leads straight to its one-to-one paired English text "A mighty fortress".

So almost everything about it is English, with the exception is that it is structurally right to use the article's title in its German translation as the text to be put into "[[Category:Hymn tunes]].  

That is, the category for this English article should naturally contain the German text (and equally NOT contain the English text); selecting it (link displayed "Ein' feste Burg") should lead to the English-titled article "A mighty fortress".

(From a completely different field I could imagine another use.  Suppose there was a set of articles about plants, say "Rose", "Fir", "Giant Redwood", ..., etc. The botanical world might want to have a categorisation of those English-titled articles built using their Latin genus/species names.  That category would display Latin names; selecting a name/link would lead to the English-titled article.)

The existing syntax is:
  [[Category:<catname>|<sort>]]

and it implicitly inherits the article's title for both sorting and displaying in the category.  And in most cases, "<sort>" can be null.

The proposed syntax is simply an extension:
    [[Category:<catname>|<sort>|<cat-value>]]

When <cat-value> is present it overrides that title-inheritance; and is used for both sorting and displaying (thus allowing <sort> to be null for many, perhaps the majority of, uses).

Does that help?
Comment 28 Roan Kattouw 2008-02-28 21:33:45 UTC
What if you created a redirect and categorized the redirect as well? In this example, you'd have [[Virginia rose]] as a redirect to [[Rosa virginiana]], and categorize *both* in [[Category:Roses]].
Comment 29 Daniel Friesen 2008-03-02 09:30:20 UTC
Also note that (In reply to comment #27)
> The proposed syntax is simply an extension:
>     [[Category:<catname>|<sort>|<cat-value>]]
> 
> When <cat-value> is present it overrides that title-inheritance; and is used
> for both sorting and displaying (thus allowing <sort> to be null for many,
> perhaps the majority of, uses).

Do note that currently a null (empty) sort is actively used on many wiki so sort articles that the category belongs to at the top of the category (ie: A [[Rose]] article would be located at the top of [[:Category:Roses]]). And making a ''null sort'' default to the pagename will break this extremely common and expected use.

Not to mention that it's going to cause a whole new level of confusion for newer users to add extra pipe parameters. Even the [[Image:Imagename.ext|param1|paramN|...]] format doesn't match this, as the order of the options does not matter as long as you don't duplicate things in a way which one would override the other.
Comment 30 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-03-11 17:24:13 UTC
*** Bug 11490 has been marked as a duplicate of this bug. ***
Comment 31 Matthew Koyle 2008-03-29 01:50:50 UTC
On Wikisource (and as noted in [[6111]] Wikibooks) some texts are subdirectories of a parent file-- as an example, a book of poems like [[wikisource:Littell's Living Age/Volume 129/Issue 1665/Any Poet to his Mistress]].

In category listings, this displays as "Littell's Living Age/Volume 129/Issue 1665/Any Poet to his Mistress"-- which is not what users would intend to have displayed.  

For wikisource, the easiest option to resolve this issue would be to have only the information after the final '/' appear on the category page.  Having the option to change what displays on the category pages would also be acceptable (i.e. the redirects referenced above would not quite fix this issue because that would leave the odd and confusing "Littell's Living Age/Volume 129/Issue 1665/Any Poet to his Mistress".
Comment 32 Nemo 2014-05-01 11:25:48 UTC
*** Bug 61414 has been marked as a duplicate of this bug. ***
Comment 33 Nemo 2014-05-01 11:34:28 UTC
I've changed bug 29975 a bit and now it depends on bug 17212, but this bug is currently asking to be able to set how the title of a page is displayed (on categories) even without setting its actual DISPLAYTITLE. I'm not sure why one would let users change the (category) display title but not the (h1) display title, but I guess that could be configurable.

However, if bug 17212 is fixed first I expect users will instead ask and get to open up the use of DISPLAYTITLE on Wikimedia projects sooner than they get yet another wiki markup option added to core.
Comment 34 gomoko@yahoo.com 2014-05-01 11:52:41 UTC
As given with bug 61414, duplicate of this one, there's a path proposed for this:
https://gerrit.wikimedia.org/r/#/c/104905/
Comment 35 Gerrit Notification Bot 2014-07-06 21:20:55 UTC
Change 104905 had a related patch set uploaded by Nemo bis:
Added custom label for links in category pages

https://gerrit.wikimedia.org/r/104905
Comment 36 Nemo 2014-07-06 21:21:13 UTC
*** Bug 61414 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links