Last modified: 2014-07-06 21:21:13 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)
*** This bug has been marked as a duplicate of 1476 ***
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 ***
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.
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).
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.
(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.
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
*** Bug 5116 has been marked as a duplicate of this bug. ***
*** Bug 5854 has been marked as a duplicate of this bug. ***
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>.
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.
*** Bug 5916 has been marked as a duplicate of this bug. ***
I think the priority could be higher.
(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.
(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|]]
*** Bug 6111 has been marked as a duplicate of this bug. ***
Rad bug 6111, this feature should be very usefull on wikibooks
Read bug 6111, this feature should be very usefull on wikibooks
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=...]]
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.
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)
Some experimental stuff committed to a branch: /svnroot/mediawiki/branches/robchurch/catdispnames. Could use some further testing, but the basic idea is there.
*** Bug 6542 has been marked as a duplicate of this bug. ***
*** Bug 10035 has been marked as a duplicate of this bug. ***
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?
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.
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?
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]].
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.
*** Bug 11490 has been marked as a duplicate of this bug. ***
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".
*** Bug 61414 has been marked as a duplicate of this bug. ***
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.
As given with bug 61414, duplicate of this one, there's a path proposed for this: https://gerrit.wikimedia.org/r/#/c/104905/
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
