This page is for debating of topics relevent to the wiki as a whole. If you think there should be a debate on some topic please add it. Please put all comments in the text of this page.
Italic Page Names
| Pros | Cons |
| Easy to see the word in the text which the article is about | Tacky - Overkill |
If you don't know what your reading about italics aren't going to help you; in limited use I can see it is beneficial but every occurance of the word is overkill. -- BW
I would agree. I'm used to italics being sparsely used, and only as a point of emphasis and stress, so I keep on thinking a specific contrast is being illustrated. I prefer simple and uncluttering conventions in references so I can read over without having to think about the intent ofthe wiki's or even author's style. Besides, if you don't have the short term memory to remember what page you're looking at... [complete sentence yourself] :) --IL
Lowercase Links
| Pros | Cons |
| Simplifies caching | The wiki engine instructs the web browser not to cache pages, thus caching is a none issue |
| Mirrors how other case-sensitive wiki engines work | WakkaWiki isn't case sensitive. |
| Improves WakkaWiki's intended link design. | Goes against the intended design of the WakkaWiki engine (to use CamelCase). |
| CamelCase can still be used for multi-word links, if necessary. | Makes the vast majority of the older links harder to read. |
| | Requires the recoding of every page. |
SL requires a high speed internet connection and bandwidth to download gigibytes of data in short periods of time. Caching of a webpage is a non issue compaired. Wakka isn't case sensative, why should we have to conform, especialy when it makes the vast majority of links harder to read. If the links weren't made to be read by humans, why were they given human readable names? -- BW
I don't see a problem with how things are. Maybe minor inconsistency, but I hadn't noticed any, and I don't think people are going to attach much significance to slightly different casing. Since wikipedia/mediawiki convention cannot be adhered to (no spaces, case semi-sensitivity in redirects when unambiguous) another way of significantly splitting words is nice - I don't mind camelcase.
Please explain what does caching have to do with the difference. [...cut for space...]? --IL
The argument is based on that your browser would download both Debate & debate as seperate pages; and that this is wasteful. Mediawiki is case sensitive. There are places on Wikipedia where there are different pages for a term based on its case (like the lowercase would be about the term and the upper case about the movie). There has been some movement to get LL to move to MediaWiki but it hasn't happened :-/ (IMHO the web developers are pretty low on the totem pole at LL.) --BW
Then indeed it's fairly silly to hack around Wakka behaviour with a lot of editing (copy, paste, backlink check, deletes?, etc) when it's an order of magnitude or five less bandwidth than SL itself. Something to think about and put in the style guide of a new wiki perhaps, but a pretty gainless bother now.
I guess if someone has nothing better to do they could... Still, you'd need to settle on things like how to handle different types of nouns, differently cased links because of sentence position, etc; there's probably no significantly cleaner solution. I sort of like the current case insensitivity, oh-my-I-justdownloaded-5K-twice. Laziness, impatience, hubris, right?:P --IL
It's about GOOD habits, people. Developers are getting lazier and lazier as they have access to more and more memory, CPU/GPU power, etc. This needs to stop. Intelligent link design is only one small part of this overall developer laziness. SL is VERY bandwidth-wasteful; there's no reason the LSL Wiki needs to be too. -
EepQuirk
I've just looked at the HTTP headers that wakka sends, the pages are all 'no-cache'. Every time you view a page your browser downloads it; reguardless if it were visited 10 days ago or 10 seconds ago. As per this new evidence, the underlying assumption of reduced bandwidth has been overturned. On a side note, I cannot see how this impoves the design if it goes against the design. The key tennon of programing is lazyness. The greatest programers are lazy. If programers weren't lazy, they would all be programing in assembly because you can always write better code in assembly then can be produced by a compiler. The trouble with writing an application in assembly is it takes forever, it doesn't scale. A lazy programer recycles code, a lazy programer writes & uses libraries so they can use them in bigger projects. Lazyness is what makes programers great, it drives them to write more advanced languages and libraries. Time spent on plumbing, like getting your links rights, is wasted time. It's time that could be spent creating. Lazy programers are productive programers. If the language isn't case sensative, you shouldn't force a style that requires it. - BW
Are we talking about all links... as in function links included? LSL functions must be formatted in CamelCase to compile, so with a lowercase link policy, wouldn't that confuse people? And if LSL is the exception, wouldn't that also confuse people? - BurnmanBedlam
Root Links
| Pros | Cons |
| easier/quicker to code | doesn't look pretty |
I think pretty in this case is more important then easy/speed. It doesn't entail much extra work, simple copy and paste and a bit of trimming; if you can handle wiki tags and have the constitution & time to edit the wiki you can do it right. (Funny, you were argueing above against lazyness) -
EepQuirk
I assume by "Root Links" what is ment is events vs events. Of course i advocate lazyness in programing but i do not think it should be all prevailing in authorship (because really isn't it just easier to just write nothing?). This is about something the user will notice (The above is about legislating something the user will most like never notice). Pretty is better IMHO - BW