Last modified: 2014-02-23 06:34:22 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 10883 - For categories whose titles begin with a local interwiki prefix, CategoryTree displays the wrong category
For categories whose titles begin with a local interwiki prefix, CategoryTree...
Product: MediaWiki extensions
Classification: Unclassified
CategoryTree (Other open bugs)
All All
: Normal normal with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
Depends on:
  Show dependency treegraph
Reported: 2007-08-11 16:41 UTC by Mike Dillon
Modified: 2014-02-23 06:34 UTC (History)
1 user (show)

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


Description Mike Dillon 2007-08-11 16:41:29 UTC
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:[]=la:Fruits&rsargs[]=0
Comment 1 Brion Vibber 2007-08-25 12:40:58 UTC
Fixed in r25130
Comment 2 Mormegil 2012-07-11 13:44:23 UTC
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[]=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.)

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