Naming conventions / When to use namespace/context disambiguation in a title

From WhyNotWiki
Jump to: navigation, search

Contents

When to use

(Or "When to use subpages and when to use categories")

Option 1: Use categories instead of sub pages, with few exceptions

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...

Option 3: Be like Wikipedia and never use subpages. Use parentheses in titles for disambiguation.

[Examples (category)]

No slash With slash

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...


Currently using No slash With slash
Both: Software development / Concerns (category)

Software development concerns (category)

Software development concerns (category) style="background: #FFBBBB" Software development / Concerns (category)
Programming language concepts (category) Programming language concepts (category) Programming languages / Concepts (category)
Programming language features (category) Programming language features (category) Programming languages / Features (category)
Authentication (category) Authentication (category) Software development concerns / Authentication (category)

or Software development / Concerns / Authentication (category)

Localization (category) Localization (category) Software development concerns / Localization (category)

or Software development / Concerns / Localization (category)

Performance (category) Performance (category) Software development concerns / Performance (category)

or Software development / Concerns / Performance (category)

User interface (category) User interface (category) Software development concerns / User interface (category)

or Software development / Concerns / User interface (category)

Software development philosophy (category) Software development philosophy (category) Software development / Philosophy (category)
Software development problems (category) Software development problems (category) Software development / Problems (category)
Software development tools (category) Software development tools (category) Software development / Tools (category)
Source code dissections (category) Source code dissections (category) style="background: #FFBBBB" Software development / Source code dissections (category)

[[| ]] ([[:Category:|category]])


[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:, ...


[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...

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...
Ads
Personal tools