Last modified: 2011-07-28 23:50:33 UTC
A discussion tab is incorrectly shown for all pages in custom namespace X, which has been created without a companion 'talk' namespace. The tab has the link :{{PAGENAME}} whcih is clearly wrong. I looked at Bug 2033, but that suggests to remove the Discussion tab using CSS - something that would affect all discussion tabs, not just the tab for a custom namespace, so it doenst quite fit.
You can't create a namespace without an associated talk namespace, or MediaWiki will go slightly crazy in a variety of ways. This should be documented on the wiki page about creating new namespaces if it isn't already.
I CAN create a namespace without an associated talk namespace - all I'm saying is that the discussion tab shouldnt be visible if there is no talkspace defined. I don't understand why this is a problem. Well, if you'd share how MW goes slightly crazy, that'd be helpful to understand the context of your answer. Since I'm creating many namespaces, I really would be interested in knowing more about this... thanks much.
(In reply to comment #2) > I CAN create a namespace without an associated talk namespace Yes, but you shouldn't. MediaWiki doesn't support this use case. > Well, if you'd share how MW goes slightly crazy, I don't have the details because I've never tried. But your weird talk tab would be one symptom.
I'm not so convinced that MW "doesn't support this use case".... http://www.mediawiki.org/wiki/Manual:Using_custom_namespaces states: ...It is *RECOMMENDED* that you define a discussion namespace with each custom namespace... (*EMPHASIS ADDEDED*) To me that doesn't sound like a 'fie on you' if a subjectspace doesnt have a talkspace! Aren't we just talking about an "if" statement here, another "if" statement there, so I don't appreciate yet the thinking behind the pushback. Maybe one part that worries you is the code for pages with talk content that are moved into a namespace without a talkspace. One conservative approach -- what I would recommend -- is to abort the rename until the user first (manually) deletes the talkspace page. In terms of the need for this, let me be more clear. I am building a series of wikis which use namespaces very extensively, as in the high hundreds each. These namespaces equate to types of wikipage, eg Person is a namespace that contains only pages for individuals, with its own security profile. This design allows my software to quickly ascertain the type of a page, far faster and better than crawling among multiple folksonomic categories for a page. What is the impact of forcing a talkspace for every custom namespace? By doubling the number of namespaces, it clogs up the user interface, slows performance and hampers user training, but most important it can frustrate designers' ability to implement talkspaces differently than MW does. What's so bad about that? LQT is coming with a release that works in ANY namespace, and SMWHalo's Collaboration puts talk (more conveniently) after article content, not mentioning another 24 packages (see mw:Category:Discussion_and_forum_extensions). So the need to me is clear, to help wikis creatively use custom namespaces -- as custom namespaces are critical/central functionality in MW. Please don't ask wikis like mine to "suck it up" with literally hundreds of useless unwanted namespaces. thanks for your reply, and cheers! jmc
MediaWiki is designed to pair all non-virtual namespaces into subject & talk pairs. Behavior when talk namespaces are missing is explicitly undefined.
(Note that in general, the existing talk page system needs to be wholly replaced. I'm not arguing with the notion that lots of talk page namespaces clutter the UI and are confusing -- they are. Just don't expect things to work reliably if you leave them out in today's MediaWiki -- it's not designed for it and you can expect to encounter bugs.)
