Page MenuHomePhabricator

Please create {{PAGENAME}}-type variable for FALSE namespaces
Closed, DeclinedPublic


Author: kellen

On wikibooks, we're in need a of a variable similar to {{PAGENAME}} for false

On the Cookbook, we're using "Cookbook:" as a false namespace. We have set up a
template [ Template:Recipe] to
include on each recipe page which will add a small bit of navigation and, more
importantly, include each recipe in a category (so we can have an easily
maintainable recipe index), specifically
[ Category:Recipe]. Our template
currently uses [[Category:Recipe|{{PAGENAME}}]] to achieve this, but since each
page is prefixed by "Cookbook:", everything is indexed under "C". I realize we
could use {{1}} to pass in a value, but we're trying to avoid having to edit the
sort key for every page every time, so a variable which returns only the page
name after the false namespace would be invaluable.

There is a bug request [ here]
which requests a "Cookbook:" be a proper namespace, which would alleviate this
particular occurrence of the problem, but it might resurface if we include false
namespaces under a proper "Cookbook:" namespace, e.g. with

Version: unspecified
Severity: enhancement
OS: Linux
Platform: PC



Event Timeline

bzimport raised the priority of this task from to Lowest.Nov 21 2014, 8:34 PM
bzimport set Reference to bz2296.
bzimport added a subscriber: Unknown Object (MLST).

Pseudo-namespaces should not be used in the first place, so I'm inclined to mark
this WONTFIX and work on a better solution instead. I strongly advise not to
create a "Recipe" pseudo-namespace within a pseudo-namespace, and to use
categories instead for that purpose.

MediaWiki 1.5, which should go live within weeks, will have two changes that are
important to you:

  • number of real namespaces will no longer be limited to 128
  • new database schema makes changes to page titles easier

The second is important because it allows us to relatively trivially convert the
existing "Cookbook:" pages into a real namespace. I'd be willing to do this once
we've switched to 1.5 (someone else might do it before then). I'd ask you to be
patient until this point.

kellen wrote:

I've stuck pretty much to my corner of wikibooks thus far so I don't think I'm
familiar with the reasons why pseudo/false namespaces should not be used.

For our indexes in the Cookbook I thought (though others have disagreed with me)
that having namespace-enabled categories would be a relatively elegant way to
deal with organization (specifically to encode the meaning of a category). e.g.:

  1. Category:Cookbook
  2. Category:Cookbook:Recipe
  3. Category:Cookbook:Recipe:Breakfast
  4. Category:Cookbook:Recipe:Cuisine:African
  5. Category:Cookbook:Recipe:Cuisine:Caribbean

Perhaps if we have unlimited namespaces this is no longer an issue.

rowan.collins wrote:

See also
(and its replies), which describes that in a future version (perhaps 1.6.x)
namespace management will be exposed through the web interface, so it will no
longer be necessary to rely on developers to make appropriate changes like
putting Wikibooks projects into namespaces.

As for why pseudo-namespaces are a bad idea, it's precisely because they lead to
this kind of request - there's no point reinventing all the features of
namespaces in order to apply them to naming schemes that look like namespaces
but aren't. Or, to put it another way, every advantage of having namespaces
built in to the code (and indeed the database structure) is a disadvantage of
using "false" namespaces instead.

As for something like "Cookbook:Recipe:", that's taking namespaces to a whole
new level, and I wonder if it wouldn't be better just to use categories for that