Naming conventions / When to use namespace/context disambiguation in a title
From WhyNotWiki
[edit] When to use
(Or "When to use subpages and when to use categories")
[edit] Option 1: Use categories instead of sub pages, with few exceptions
[edit] Option 2: Use subpages if some disambiguation/context is necessary
For example: Ruby / Blocks if Blocks by itself would be ambiguous.
I'm actually now leaning towards putting the context/scope in the title even more frequently than that.
It spares us from a lot of the thinking that would otherwise be involved in choosing a title: in particular:
- deciding whether the context is even necessary (for disambiguation)
- deciding what preposition to use
For example, I used to have a page/category called "File management on GNU/Linux". I've now dropped the preposition (on) and just put renamed it to "GNU/Linux / File management". This conveys the necessary information (this is a subtopic of "GNU/Linux"), without cluttering things up with some arbitrary preposition (on) that really doesn't matter or tell us much.
A lot of the time, it's hard deciding on the perfect preposition. "Regular expressions in Ruby", "Regular expressions with Ruby", "Regular expressions using Ruby"? "Testing in Ruby", "Testing Ruby code"? Easier/better/simpler just to put the scope and a slash:
- Ruby / Regular expressions
- Ruby / Testing
There may be exceptions, in which the preposition does tell us something extra/useful... I'll deal with them when I see them (and will list them here)...
Most of the time I'd just rather not have to think about the exact relationship between a [subtopic] with its [parent topic], and leave it unspecified (unless it's ambiguous and needs disambiguation).
There would oftentimes be many equally acceptable titles for the same article: We could call it Category:Templates in MediaWiki, Category:MediaWiki templates, for example, but it seems simplest to me to just call it Category:MediaWiki / Templates and be done with it. Nice and consistent (at least if used consistently!), and easy to remember.
Categories
Can be used for categories (for example, Category:Ruby / Performance) in addition to articles! In fact, now that I am tending more towards having a one-to-one correspondence between articles and categories, this is going to become the norm around here...
[edit] Option 3: Be like Wikipedia and never use subpages. Use parentheses in titles for disambiguation.
[edit] [Examples (category)]
| No slash | With slash | |
|---|---|---|
[edit] Case study: Software development
Software development has a lot of categories. Most of them are in the top-level namespace, but are categorized neatly under a subcategory of Category:Software development...
[[| ]] ([[:Category:|category]])
[edit] [Exceptions (category)]
The following exceptions currently exist. I will try to identify which ones are legitimate and which ones are [deprecated (category)] and will need to be changed.
| Currently | Change to? | Decision | Rationale |
|---|---|---|---|
| Ruby libraries | Ruby / Libraries | ||
| Rails plugins and libraries | Rails / Plugins and libraries | ||
| Software development concerns | Software development / Concerns | ||
| Applications written in Ruby | Ruby / Applications ? | ||
| Software development | Software / Development? | Leave as is! | |
| Testing (category) | Software / Testing (category) | Leave as is! | |
| Software problems | Software / Problems | ||
| Intellectual property issues in software (category) | Software / Intellectual property issues (category) or Intellectual property / Software (category) | Leave as is for now. | It's hard to know which should be the parent topic and which the subtopic!! |
Why not use a slash for all of these?
Maybe I should change some/all of them...
At worst, it might mean that we have 3 levels in the title (Rails / Plugins and libraries / Database-level) sometimes instead of only two (Rails plugins and libraries / Database-level), but that doesn't seem so terrible... It might even be a good thing (?)!
Ruby / Applications is a little bit ambiguous (in what way). Applications written in Ruby is okay for now.
Software development doesn't feel like a direct subtopic of Software. I mean sure, it is in some ways a subcategory of Software. But it feels more independent, more like it ought to / needs to have an identity of its own. In the same way that Programming (a near synonym of Software development) is not Software / Programming. That fact that the first word of Software development is "Software" seems merely coincidental, not indicative of any need to turn "Software" into a context for the subtopic "Development". That would be yuck. So we don't do it. Software development is a legitimate stand-alone / top-level topic.
Use, not for the following reasons:
- That's usually what I'll be referring to when I say "Testing". (Use disambiguation titles for other pages if we ever need to refer to other meanings of "testing")
- It's a major topic. Plan to have many sub-topics/sub-pages:, ...
[edit] [Naming conventions (category)]
"context / specific subtopic"
The delimiter to be used is " / " -- that is, a space followed by a slash followed by another space.
Other delimiters considered:
- ":" : Nothing wrong with this delimiter, except that with "/" we get MediaWiki's subpage parent-link feature for free. And the ":" is sort of ambiguous, because that's the same delimiter used for namespace prefixes (
Template:,Category:, ...). - "/" (with no spaces): The spaceless slash is reserved for uses such as Category:Traffic/transportation problems, where it means "or". We don't want the same symbol to mean both "or" and "parent of"/"scope"/"context", because that would be ambiguous.
Besides, it just looks prettier to have the space surrounding the " / ".
This is different from Wikipedia's convention, which would be to use parentheses: "specific subtopic (context)" (Blocks (Ruby)). I like to consistently follow the convention Most significant information first, however, and this is no exception. It's like navigation breadcrumbs: most general topic, more specific, more specific, etc...
[edit] Backreferences
The "subtopic" title may occasionally need to make a reference to its parent topic. In this case, the pronouns "it", "they", etc. are allowed, as appropriate.
Examples:
Other alternatives:
- Could use something like $1 or \1, commonly used for backreferences in regular expressions...
