Michael.Keppler wrote:

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

Michael.Keppler wrote:

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 ***

zigger wrote:

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.

zigger wrote:

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).

mkail wrote:

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.

zigger wrote:

(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.

gangleri wrote:

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

robchur wrote:

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

robchur wrote:

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

peu wrote:

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.

peu wrote:

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

peu wrote:

I think the priority could be higher.

peu wrote:

(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.

peu wrote:

(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. ***

ilklamo wrote:

Rad bug 6111, this feature should be very usefull on wikibooks

ilklamo wrote:

Read bug 6111, this feature should be very usefull on wikibooks

ingoolemo wrote:

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=...]]

ayg wrote:

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)

robchur wrote:

Some experimental stuff committed to a branch:
/svnroot/mediawiki/branches/robchurch/catdispnames. Could use some further
testing, but the basic idea is there.

ayg wrote:

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

ayg wrote:

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

t.d.lee wrote:

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.

t.d.lee wrote:

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.

ayg wrote:

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

mkoyle wrote:

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.

gomoko wrote:

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

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

Spectacularly badly written feature request, makes it somewhat difficult to understand what is proposed exactly, but I think I understand.

I've updated the description of T31975 to include a detailed proposal of how to implement names in categories, so closing as duplicate of that.