Thats the expected behaviour. $wgCategoryPrefixedDefaultSortkey just changes the sort order, not what is displayed. So if Talk:Foo is in a category, setting $wgCategoryPrefixedDefaultSortkey to false will cause it to be filed under F instead of T (assuming no alternate sortkey has been specified). However it will still be displayed as Talk:Foo no matter how $wgCategoryPrefixedDefaultSortkey is set.

However, in regards to the core issue you are having:
Showing the category prefix for each item on the subcategory list appears to be something thats new in 1.16. (specifically it seems to have been introduced in r53780 , potentially accidentally) I'm not sure if this is a behaviour we want or not.

Ignore what I said about r53780. I'm not sure what caused the change in behaviour, but that revision couldn't of been it since the old behaviour of not showing category was present after that revision

burobjorn wrote:

Mhhm how can I help in determining what the cause was of the current behaviour? I would like to have a way to remove it which is 'compatible' with the rest of the Mediawiki developments so it does not regress in a newer version.

Created attachment 7747
patch that removes the category prefix from the subcategory listing.

ok, it was caused by r53780. I got confused as the bug wasn't present on wikipedia, and wikipedia is running post-r53780 code. However, that is because wikipedia is using categorytree which overrides the category page display. If you disable categorytree, the bug is present - http://en.wikipedia.org/wiki/Category:Canada?notree

I'm attaching this as a patch instead of committing it since I currently know nothing about the language converter, and have no idea what r53780 was doing. Thus I need to take a moment to read up on lang converter before committing to make sure I'm not doing something stupid/wrong.

Attached:

burobjorn wrote:

@Bawolff: Could you explain to me how I can safely patch 1.16 (aka the last stable version)? AFAIK r53780 is part of it. It seems to me your patch expects some other changes as well which are already part of trunk?

(In reply to comment #5)

@Bawolff: Could you explain to me how I can safely patch 1.16 (aka the last
stable version)? AFAIK r53780 is part of it. It seems to me your patch expects
some other changes as well which are already part of trunk?

Replace the null on line 158 of CategoryPage.php (second argument to $this->getSkin()->link) with $title->getText();

burobjorn wrote:

Bawolff, works like a charm! Thanks for your help! I hope this gets fixed in the trunk as well :)

Crap, totally forgot about this.

fixed in r78071