Forum:Namespaces?

Forums: Index &rarr; Wiki Talk


 * Heh. We hashed over this issue pretty extensively already.  Space, I admit, is one of the more questionable ones, here -- at some point, it will probably be moved to a science fiction trope.  Still, there was a lot going into this:


 * We wanted to get closer to Wikipedia's names, so that the majority of the Wikipedia links would work without adjustments. There are certain cases where it will only get you close, but still only a click away.  (No, we are not becoming wikipedia ... we are providing a link to go there if you want to see encyclopedic information.  It's like outsourcing.)
 * The namespaces where essentially arbitrary anyway. And you'd have to remember which was which, anyway.
 * If a work had multiple adaptations, you'd have to know that if an anime was Anime First, started as a manga, or started as a light novel when making a link. Or was was it a Miyazaki anime over in the Film namespace?  That sort of mess discourages casual editing, and possibly even casual browsing.
 * Most of what the namespaces were separating are handled by mediawiki categories.
 * You seem to be in the habit of checking the URL to find out what something is. But we have newer, better ways of doing it.
 * How can you tell if something is a trope or work, even if it's potholed? Well, you can't on TVT without highlighting the link and reading the URL.  But here?  You can just turn on one of the two Trope Highlighting gadgets.  Links to Tropes and YMMV tropes appear to be a different color.
 * Want more info? Turn on the Navigation Popups gadget.  A small preview of the page gives you an idea of its content.
 * Note: this Navigation Popups isn't actually working right now, but it's pretty slick on Wikipedia. Getting it to work on Mediawiki 1.22.3 is a priority for us.
 * I'm tempted to make it read Laconic instead, but those are often pretty bad...
 * Namespaces make for more work when editing. Of course, some of that can be negated by the Auto Complete gadget -- but the more namespaces, the more cluttered that gets.  Requiring namespaces for everything makes for worse Huffman coding.

So, that was my thinking going into this. But you're seeing some headaches emerging from the idea of getting rid of namespaces. But it's worse without them, because unless everything is written very clear, it's impossible to tell what is what from links, and it may or may not be obvious even halfway through the article: is it self-demonstrating, starting with an example, and other in media res - or is it a work? And then, there are common terms with several possible uses.
 * Unless you're using gadgets...
 * So how exactly do namespaces solve bad writing? I mean, those are pretty much problem pages anyway IMO.  If we haven't gotten into "Topic is a X" territory by the second paragraph... ugh.  It might be possible to modify the trope template to put a note that something is a trope in the title bar -- would that be useful?  I suppose I could do something similar with major work namespaces.
 * I don't see how renames are going to effect confusion between similar terms, one way or the other. We're either going to need misambiguation pages, notes at the top of the page, and/or some separate namespaces on those anyway.

It's not that namespaces were a bad idea on TVT, given that they're using Pmwiki. But the wiki we use has a different software paradigm, and generally expects to be used more like wikipedia does. And they have pages on the majority of our works, too.

To be honest, you're not going to convince me to change it back, because I've invested >100 man hours into getting rid of the namespace suffixes. But if there are specific headaches that I'd be able to mitigate with software, then let me know, and I'll try to think of a way to address them. Vorticity (talk) 06:14, 25 March 2014 (UTC)

Namespaces make for more work when editing. Of course, some of that can be negated by the Auto Complete gadget -- but the more namespaces, the more cluttered that gets. ... I don't see how renames are going to effect confusion between similar terms, one way or the other.
 * Same as with coding: if errors are immediately obvious, it saves time even if you have to type slightly more. Namespaces make certain sorts of problems quite unlikely to appear in the first place: it's either an existing type in plain text or it's a red link.
 * Example: there's "Death_Star". If an editor had to use "Novels/Death_Star" while writing each of 112 links, would this be too much work to do? I'm reasonably sure they weren't written all at once, either. Now, want to bet how many times you will have to fix links using "[[Death Star]]" alone as a trope because someone guessed from context and didn't bother to check, or just mixed up names?
 * ...and since many, many tropes are named after works and things in works, and both use common words a lot, and easy to mix up, such confusion is going to be all-pervasive.
 * Autocomplete is the root of many and ugly evils. :) "More work" by copypasting 1 short word is not.
 * Lack of namespaces means every link strongly relies on the context. Which makes links on pages that don't give context at all almost useless - and this includes everything from "one word obvious trope" junk to big technical pages, especially search, including "What links here": unless an user already remembers what each name is, links have to be checked one by one to find anything particular. Namespaces instantly filter out lots of misses here, and for works referring to other works they may well narrow hundreds of found results down to 1-2 wanted right away, without checking every single one.

So how exactly do namespaces solve bad writing?
 * Nothing solves bad writing, ever - or "fanfic" could not be used as an indecent word. ;) But a good site structure (whether via URL or tags) may have the inevitable problems contained and thus make them matter less. A reader searches for a trope page, and it's a work page - next, please! No need to dig through. Thus, less users are affected by this problem, and less problems affect a specific user. Also, this applies not only to bad writing as such - just as styles clarifying everything from the start aren't necessarily all good. Some ambiguous lines may be acceptable if a reader can determine whether it's most likely the right place before digging in.

It's not that namespaces were a bad idea on TVT, given that they're using Pmwiki. But the wiki we use has a different software paradigm, and generally expects to be used more like wikipedia does. To be honest, you're not going to convince me to change it back, because I've invested >100 man hours into getting rid of the namespace suffixes. TBeholder (talk) 07:45, 25 March 2014 (UTC)
 * The thing is, trope-wiki most likely will not, or even can not be used the same way. While wikipedia does provide easy reference to the One True Notion on anything that is Notable (in the One True...), beyond "surface" entries it can afford to make just about every common word a disambiguation page and still camelword-link to them. :) Trope-wiki by its very nature relies on internal cross-references all the time.
 * The implementation of namespaces is another matter. Not that TVT version was too good or too bad, just convenient enough to support structurization needs on basic level. "Name_(Media)" format is obviously less convenient, but still much better than nothing.
 * In fact, optimization on the "choose wiki engine" level is a joke. Any wiki or similar engine is inherently suboptimal for troping purpose due to the nature of content: its own structure being tables of entries - mostly (trope, work) - forcing it into linear text form is both prone to leaving pages too long for editing, and necessarily makes almost every entry duplicated to appear on both (trope) and (work) sides.
 * "People should think, machine should work".(c) ;)

Same as with coding: if errors are immediately obvious, it saves time even if you have to type slightly more. I agree with this sentiment, but writing is not the same thing as coding. (Although there are some very good arguments that they are quite similar.) When you make a mistake in coding, consequences can range from incorrect results to compiler errors to inadvertent features. But the first result is typically very bad. In the context of an incorrect wiki link going to not quite the right page... well, the user will get to read a slightly different page.

I don't think worrying about linking errors is as important of a goal as is natural writing. Most of our users are non-technical, or should be, so I want to follow the principle of least surprise. One of those surprises includes typing in the name of a work in the URL bar and having nothing come up. That's what red text means.

...and since many, many tropes are named after works and things in works, and both use common words a lot, and easy to mix up, such confusion is going to be all-pervasive. Cool story bro, but I think I need evidence on that one. As if such things weren't confusing already, and wouldn't continue to be confusing under any naming scenario. In an ideal world everyone will be able to classify things correctly and not complain about it, but I'm simply shooting for controlled chaos. Making most of the people happy most of the time is the goal.

Keep in mind that namespaces aren't going away where there is ambiguity. They're just unnecessary where there is none. And I don't feel like paying the penalty on every link is necessary for the relatively few cases where there is ambiguity. After all, if ambiguity is introduced later, we can always apply a bot to the links later on.

necessarily makes almost every entry duplicated to appear on both (trope) and (work) sides. Sadly, I'm not in the mood to write *that* software monstrosity. Besides, I think natural language doesn't lend itself to that kind of double-linkage.

Nothing solves bad writing, ever - or "fanfic" could not be used as an indecent word. I'm still waiting for someone to tell me how bad my own fanfic is. I've had a few good reviews but I don't believe them.

Autocomplete is the root of many and ugly evils. :) "More work" by copypasting 1 short word is not. &lt;snip&gt; "People should think, machine should work".(c) ;) Heh, nice contradiction. I think I'm going to like you, TBeholder.

Vorticity (talk) 03:42, 26 March 2014 (UTC)

writing is not the same thing as coding. [...] When you make a mistake in coding, consequences can range from incorrect results to compiler errors to inadvertent features. But the first result is typically very bad. In the context of an incorrect wiki link going to not quite the right page... well, the user will get to read a slightly different page.
 * Errors in cross-links require more prevention because rooting them out once they are in place is harder. Text can be spellchecked, markup can be also syntax-validated, code can also be tracked, but bad links to existing targets are detectable only by an actual reader, and even then unreliably. If someone messes up links, this isn't obvious from context, but can be immediately noticed only by someone looking at the link and remembering what the linked page is about. Even following it doesn't automatically alert the reader - at this point one still may mistake it for an obscure, but valid reference or joke. And once detected, they can be only removed, because who knows what the editor actually meant?

I don't think worrying about linking errors is as important of a goal as is natural writing. Most of our users are non-technical, or should be, so I want to follow the principle of least surprise. One of those surprises includes typing in the name of a work in the URL bar and having nothing come up. That's what red text means.
 * What do you mean under "natural writing"? It's in 'wiki markup' syntax to begin with.
 * It's sensitive to capitalization either way, and works use the same names (looking on imdb.com how many unrelated movies are named "Deja Vu" was a little bewildering). And work/article ambiguousness on top of that. So with a few exclusions, getting there by editing URL bar is still luck, and otherwise it's down to search anyway.
 * Of course, the best solution would be to automatically format/color-code links to disambiguation pages and redirects, much like it's done with red-links.

Cool story bro, but I think I need evidence on that one. As if such things weren't confusing already, and wouldn't continue to be confusing under any naming scenario.
 * The last work vs. common word / possible article name ambiguousness encountered (today): Monk. :D Do you really think it's exactly what everyone editing it into URL bar would mean?
 * For work vs. article clash - Death Star above.
 * For potential article vs. work clashes after we exclude common words - yes, it's not that often. But e.g. "Sgt. Rock" is an abbreviation for what was named after it.
 * Generally, Trope Namers are this waiting to happen: if something was a name proper or a catchy phrase in Book 1 of The Grey Mountains Saga, and was worth a mention, by Book 50 it's as likely as not to get on the cover, no? Serials being fountains of creativity with output pumped back to input. Or, for example, would you bet that in the next handful of Chiropterous Man comics one will not be named "Joker Jury" or "Bruce Wayne Held Hostage", or one of the other phrases trope-wikis grabbed?.. ;)

Heh, nice contradiction. It's not a contradiction, it's an example. "Guess for me what I want to type" obviosly counts as throwing away IBM principle. :] TBeholder (talk) 06:45, 4 April 2014 (UTC)

I'm still waiting for someone to tell me how bad my own fanfic is. I've had a few good reviews but I don't believe them. Narrow niche (and for crossovers it may be more intersection of sets than union) is one of the reasons the reviews are limited and amount of meaningful ones is not great, yes. The sad thing, it's despite fanfics theoretically giving more opportunities to improve due to direct feedback from the pre-existent interested community. Of course, for the original/serial works it's as often as not more about slapping some epigony off Boris Vallejo (or worse) on the cover. Fanfics look uglier in average mostly because the publishers' editors usually perform at least basic checks - obviously, the worst writing doesn't vanish, it just stays between these poor souls, those who inflict it on them and wastebasket (real or sprite). Which is why my point is "nothing solves bad writing": you can only filter out some of it. TBeholder (talk) 06:45, 4 April 2014 (UTC)