For categories whose titles begin with a local interwiki prefix, CategoryTree displays the wrong category
OpenPublic

Description

Author: md5

Description:
On English Wiktionary, there is a convention of using language codes as prefixes for topical category names in languages other than English. For example, there is a category called "Category:Fruits" for English words related to fruits, but it also has subcategories like "Category:es:Fruits" and "Category:la:Fruits" for Spanish and Latin respectively. You'll notice that these name prefixes generally match the interwiki names for the other language Wiktionaries.

The issue that I'm seeing is that when using the AJAX-based category expansion, the wrong set of categories is being returned when expanding something like "Category:la:Fruits". It effectively returns the subcategories for "Category:Fruits" instead of "Category:la:Fruits".

I tracked the issue down to the "makeTitle" function in CategoryTreeFunctions.php, but I'm not sure what the right fix is. What seems to be happening is that there is a call to Title::newFromText that looks like this:

$t = Title::newFromText( $title, NS_CATEGORY );

In the case of "Category:la:Fruits", the value of $title is "la:Fruits". Inside of "newFromText", this is passed to Title::secureAndSplit which interprets the the "la:" as an interwiki prefix and strips it, giving us "Category:Fruits" instead of "Category:la:Fruits".

In this particular case, I think it would work correctly to pass "Category:$title" to Title::newFromText, but that would end up showing weird behavior if $title already had a "Category:" or ":Category" prefix. Like I said, I'm not sure whether the right fix is in the "makeTitle" function of CategoryTreeFunctions.php or if something needs to be done in the Title class (e.g. taking mNamespace into account in the interwiki portion of secureAndSplit since "iw:PAGENAME" shouldn't actually be an interwiki link unless the default namespace is NS_MAIN). It seems like it's hard for me actually test a fix without bringing up a full MediaWiki installation that has the same interwiki map as English Wiktionary.

Here is an example URL that is used when expanding "Category:la:Fruits" in a category tree:
http://en.wiktionary.org/w/index.php?action=ajax&rs=efCategoryTreeAjaxWrapper&rsargs[]=la:Fruits&rsargs[]=0


Version: unspecified
Severity: normal
URL: http://en.wiktionary.org/wiki/Category:Latin_language

bzimport added a subscriber: wikibugs-l.
bzimport set Reference to bz10883.
bzimport created this task.Via LegacyAug 11 2007, 4:41 PM
brion added a comment.Via ConduitAug 25 2007, 12:40 PM

Fixed in r25130

Mormegil added a comment.Via ConduitJul 11 2012, 1:44 PM

The fix works correctly _most_ of the time, but not always. If the interwiki prefix in question is specifically $wgLocalInterwiki, the “Redundant interwiki prefix to the local wiki” is automatically discarded in Title::secureAndSplit(), and Title::getInterWiki() is empty afterwards. So, trying to expand e.g. Category:en:Fruits on the English Wiktionary results in expansion of Category:Fruits instead. See

http://en.wiktionary.org/w/index.php?action=ajax&rs=efCategoryTreeAjaxWrapper&rsargs[]=en:Fruits&rsargs[]=0

I am still not sure why CategoryTree::makeTitle() is so complicated, instead of just using something like
$t = Title::newFromText( "Category:$title" );

Or, passing the _whole_ title (including the Category: prefix) from the client, and not doing any magic whatsoever. (I think this is not the first bug caused by trusting Title::newFromText() would always use $defaultNamespace.)

Add Comment

Column Prototype
This is a very early prototype of a persistent column. It is not expected to work yet, and leaving it open will activate other new features which will break things. Press "\" (backslash) on your keyboard to close it now.