Wikipedia subpages pros and cons/Talk

Can we restrict subpage discussion to this location from now on? I think there are 10 different pages on this topic floating around. - MB

I agree. Though I think the other pages should be refactored, and any real arguements they contain should be moved here. Perhaps I'll have time to start on that tomorow. --MRC

• Having a "magical" character in the title is unpleasant, creates "parent" pages that shouldn't exist, and therefore prevents some article titles from being what they should: for instance [[8 1/2]], [[Gnu/Linux]], etc. (Who has said this? This doesn't make any sense to me. --LMS)
  • I (KQ) said that--well actually, just the part after "unpleasant,"--What I mean is that 8 1/2 is a movie by [Federico Fellini]?, but if I link to it like that it thinks I'm on a subpage of [[8 1]], and that the subpage is called [[2]]. The same things happen with [[Face/Off]] and at least 2 other entries I created, though I'd be hard pressed to tell you which they were (I've been around for the last 7 months). --KQ
  • For the record, it was the part before "unpleasant" that was the part I thought didn't make any sense. :-) --LMS
    • It was I who wrote that, in an attempt to be fair to the issue, even though I'm pro subpages. The unpleasantness is aesthetic: no other character plays a special role in the title except slash. It's potentially unclear to newbies, and it's a "magical", ad-hoc solution (why slash? why not the semicolon for instance?) that offends my aesthetic sensibility (I do think, however, that advantages of subpages greatly outweigh the drawbacks) --AV
      • If I understand your reaction correctly, I'd say its unpleasantness is almost wholly due to the fact that, in the context of a wiki, the slash has no clear meaning. It's an aesthetic problem rooted in semantics. :-) --LMS

• I think that it's separate from the semantic problem. It's not that the slash has unclear meaning (that's not a problem of the slash, that's the problem of the subpage concept), it's that it's the only character with an extra-textual meaning. It wields special powers: add a semicolon in the title, and nothing much happens; add a slash, and all kind of crazy stuff is suddenly going on ;) why a slash? why only a slash? There's arbitrariness in that that's bugging me. --AV

• Oh. Well, then I can't help you. <g> "Unpleasant" is too imprecise for me to know exactly what the author meant--I think it was along the same lines as what I added, but I'm not sure. --KQ

---

• Can be used to create standardised mini-schemes facilitating organised treatment of the same kind of relationship; for a trivial but by no means exhaustive example, consider "X/Childhood" in a biographical article versus competing schemes "Childhood of X" and "X's Childhood" creating confusion and unnecessary complication.
  • I've removed this from the list because it just doesn't make any clear sense. Put differently, I could just as easily have made it a "contra subpages" point. There are going to be competing schemes with or without subpages. E.g., we can just as easily imagine "X/Childhood" as "X/Upbringing" and "X/Childhood and Youth," etc. Besides, we shouldn't make this decision based on what can be easily standardized: we aren't standardizing yet and nothing about the software or our habits militates against some future standardization. --LMS

• I disagree and believe it does make clear sense. Put simply, pick any 100 personalities on whom we'll have large biographical articles. In absence of any standartization (and I'm not saying these things can't be standartised, see below) and in absence of subpages, perhaps half of them will have "Childhood of X" articles and the other half "X's Childhood", or some other proportion perhaps. I think we can agree that that would be undesirable? With subpages, this particular confusion does not arise: "X/Childhood?" it will be, "Childhood/X" is clearly absurd and will not be used. Now it's true that someone may use "X/Childhood? and Youth" or whatever, but that's not an argument against subpages: the very same confusion may arise without subpages, with "Childhood and Youth of X", "Upbringing of X", etc. etc.

• To sum up: whenever a page's title needs to transmit the idea of "the aspect B of A", where A is clearly the primary object and B is clearly its aspect, as in X and their Childhood, subpage-based naming allows us to unambiguously present the relationship without leading to likely confusion between different schemes in the English language, such as "B of A", "A's B", etc.

• Now, in absence of subpages these things may of course be standartised. I'm not saying they can't be, but it's additional work for something we already have for free with subpages (which of course has other advantages in my opinion). And this standartization may prove difficult because of the multitude of different kinds of relationships we'll have to standartize on. Suppose we agree that "X's Childhood" is better than "Childhood of X"; but what about when X is country -- "Geography of X" does seem to be slightly better than "X's Geography". We'll have to consciously decide on any such issue and wade through existing pages, fixing their titles - one-choice-for-all is unlikely to work. Retaining subpages, on the other hand, eliminates this particular problem completely. --AV

• Can be used to separate out meta-pages from the contents of the encyclopedia proper
  • This, again, is not an advantage specific to subpages. In Magnus's PHP wiki software, theoretically, we could get rid of subpages entirely while still, as we are planning to, using a "Wikipedia:" namespace for Wikipedia-related articles. --LMS
    • This is the counter-point to the subpages create-a-hierarchy argument. Strictly speaking, one could create a hierarchy of page names with or without subpages, they just make it a little more intuitive to do so. Sometimes this is bad (Electromagnetism/Charge?), sometimes this is good (Electromagnetism/Talk). That's all.
      • The argument isn't just that they can be used to create a hierarchy, which of course a no-subpages system could be used to create. The argument is that the hierarchy is hard-wired and difficult to change. That is what I wrote at [1] (which of course I don't expect you to have read, but I've made the point there anyway). --LMS

---

I'd like to point out a technical thing: In the UseModWiki, subpages are treated differently that regular pages (on the storage level), while in the PHP wikipedia, subpages are defined as pages that have a "/" in the title. "GNU/Linux" will be a page as real as all the others, no matter if I allow subpages or not. Thus, subpage functions consist of

• the ability to write "/Talk" instead of "September 11, 2001 terrorist attack/Talk"
• the display of the "hierarchy" in the QuickBar?

If we decide to keep the "/"s in the titles (which Larry already said we should do), I should just replace "/Talk" with "September 11, 2001 terrorist attack/Talk" everywhere during conversion, and turn off the "typing saver" feature? As I said before, I consider myself (almost) neutral in this question, but this does sound a little thin...

That might work (I'm not sure I entirely understand though :-) ). I still think, though, that we should have an automatic "talk" link hard-wired onto every page, which links to a "talk" namespace (I guess--you tell me how that should work). This will help ensure that in the future, we need not add ugly "/Talk" (or "Talk:" or "t:") links to the bottom of every page. It'll automatically be there. If we do put talk on a talk namespace, as I think would be groovy, it would be a great public service to copy all foo/talk? pages, delete foo/talk?, and create [[talk:foo]]. Can't be too complicated, can it? :-) --LMS

I'd like to suggest some things I could do instead (or additionally):

• Disable the "plain text links": "/Talk" remains, but "[[/Talk]]" becomes a link.
• On every "Save", a sequence (e.g., "[[.../") is replaced by the "master page" title, like my signature feature ("~~~"). So, "[[.../Talk]]" on the HomePage will become "[[HomePage/Talk]]".
• A "replace this subpage" function. That will be a lot of work to hack! But then, we could go and click on that function when viewing a subpage, and everywhere on the "master page" and the other subpages, the "shortcuts" will be replaces by "real" links. That way, we could keep subpages where they are useful, and alter them where they aren't. Of course, we could always help ourselves with REDIRECTs...

Just trying to find a compromise here ;) --Magnus Manske

---

Well, I think we should entirely get rid of subpages. The arguments against them are far stronger than the arguments for them; the arguments for them have many flaws, and the opponents of subpages have yet to point out any significant flaws in several of the most important arguments against them. --LMS