Wiki trolls throw mud: Page name prefix debate

Gawd if we're that stuck I'll awk it.

If someone is going through all the pages, it is a good time to fix the templates; kill two birds with one systematic pass. I feel a tinge of guilty about this mess.

I prefer to such tasks manually for the same reasons Strife cites; to kill two birds with one stone

are we REALLY going to wait until March 7th before implementing the decision?

I hope not.

I think we need to finish identifying the issues, look at all the solutions presented, and pick the best one. We REALLY need to leave the personality baloney out of it, though. As such, either leave the big, ugly egos under your big, ugly hats, or close this thread, as we don't need this kind of behavior.

I agree that LOTS of disambiguation pages (where a sizable majority of searches end up on a DA page, rather than at content) is a Bad Thing (tm). DA pages should be for general subjects and exceptions, and should rarely (if at all; ambiguity sux, but welcome to natural langauge) be encountered at all.

I think I can agree that a pseudo-namespace is not a good idea overall, and if we HAVE to use some kind of partitioning to avoid masses of collisions, then a real namespace, at least for some of the specific parts of the LSL Portal, would be a good idea. I admit that I don't know all the pros and cons of doing this, which is why I think we need to get things better laid out in the Wiki Talk discussions so we can pick the "best of breed" solution to our specific problems.

"Proper" Namespace

Pros:
* A "proper" namespace would remove the requirement for templates doing script-fu on the {{PAGENAME}} variable.
* Instant disambiguation

Cons:
* "LSL" would still be displayed within the page title.
* Segragation of content, counter intuitive search
* Alteration to MediaWiki install would have to be made, however if the result of this poll indicates the community wishes an "LSL" namspace to be added, then https://jira.secondlife.com/browse/WEB-22 should be re-opened (although not until then)

Pseudo-namespace

Pros:
* Instant disambiguation
* No wait time for "installation"
* Short-term gain of "L" being displayed in correct letter casing without extra templates being emplyed
* Should make things go a bit smoother if/when a "proper" namespace is chosen (although I'm not sure what happens if a pseudo-namespace is used in an existing article when a custom namespace is activated- you want to test that on your installs Strife ?)

Cons:
* "LSL" would still be displayed within the page title.
* Inability to restrict searches to a particular namespace
* complex script-fu or attention-to-detail manual edits would have to be used to get articles to sort correctly
* Will be a pain in the ass to fix when MediaWiki supports mixed-letter casing.

Prefix or suffix

Pros:
* Instant disambiguation
* No wait time for "installation"
* Short-term gain of "L" being displayed in correct letter casing without extra templates being emplyed

Cons:
* "LSL" would still be displayed within the page title.
* Inability to restrict searches to a particular namespace
* complex script-fu or attention-to-detail manual edits would have to be used to get articles to sort correctly
* Will be a pain in the ass to fix when MediaWiki supports mixed-letter casing.

No namespace (pseudo or otherwise), no prefix

Pros:
* No wait time for installation
* increases intuitiveness
* Future-proofs the wiki against mixed-letter case support in the MediaWiki platform (e.g. the first letter being allowed to be uppercase or lowercase)
* No extra junk in the page title
* script-fu only has to strip out the initial "ll" to sort articles automatically, while manual editing can still be employed.

Cons:
* the first letter in the page title will be displayed as "L"
* potential for collisions with OSSL functions.


Did I miss anything ?

That looks right to me Signpost. I think it's clear from your summary the no namespace option is the best choice. Especially since there's an easy workaround for the capital L issue.

I don't think we should pay attention to the results of this poll. Technical decisions should be made on technical merit, not by democracy (if you can even call this poll that). I'm not just saying that because prefixing is currently winning, I think we should ignore it either way.

Hi folks....could someone please post the Javascript first letter lowercase hack as a JIRA task? I'll address the problem there.

The fact that MediaWiki automatically uppercases is an annoying misfeature. Not fatal; as has been pointed out before, MediaWiki will be around years from now, thus making it the safe choice. It also happens to have a lot of really good templating features which are certainly getting a lot of use now, has quarterly releases each of which introduce pretty good features, and has pretty good performance characteristics.

With respect to the "LSL llEmail" versus "llEmail", my statements quoted above still apply. My preference (not edict) is for the latter, but having an uppercase "LSL" is an interesting workaround for the uppercase letter problem. One thing that hasn't been considered yet is that people may naturally try to drop [[llAdjustSoundVolume]] into their prose, so having something at the generated link, even if it's just a redirect to "LSL llAdjustSoundVolume", is probably a good thing.

One thing that I do want to make sure we do is smart disambiguation. As I implied with my earlier comment, two pages that differ only in naming convention (e.g. "LlEmail" and "LSL llEmail" should either be merged or renamed to titles that reflect the difference between the pages (e.g. "llEmail" for the documentation page and "llEmail (specification)" for the specification page, with the page more likely to be referenced getting the shorter title. See http://en.wikipedia.org/wiki/Charlotte for an example of this style of disambiguation.

I think that brings the issue some much more clearly to the fore.

Looks a lot like "LIEmail" to my eyes.

His summary is obviously biased toward the no namespace option, as in every choice he lists having a LSL prefix as a 'CON'. And yes, please lets ignore what everyone wants, as the elite few know better what makes sense obviously. Having the actual fuctions partitioned off with a LSL prefix makes much more sense, to anyone with any common sense. But we seem to be very lacking in that respect in this thread. Have fun with your Wiki.

I don't want to wait that long either. Hows Monday sound to close the vote? Do we want to head the vote, there was the mention of it being biased.

It is important to me that we should keep in mind what the community says.

About SM's Pro/Con split:
The same script-fo for proper sort order applies to all solutions and should be stripped as a reason for or against any solution.

On a side note, there is a template currently, LSLC, that automatically determines the proper sort name for most situations (the exception would be for the Detected category; coming up with an automatic solution would be less then optimal for categories like 'String' and 'List'). It isn't that complex only a couple of #if's

The main decision here is:

Does the miscapitalization (ex. Llfrand instead of llFrand) throw off people who are trying to learn LSL coding ?

I'd say: yes; in a coding language where capitalization is god ("llsay" won't get you anywhere if the code is "llSay", we have to be REALLY careful about this.
Newbs can get thrown off by alot, last thing we need is for the volume of "this isn't working" spam to triple and setting a bad example won't help.

So to summarize:
Choice between "LlEmail" and "llEmail": the latter
choice between "LSL_LlEmail" and "llEmail": the latter
choice between "LSL_llEmail" and "LlEmail: the former

I'm not in favor of the "LSL" prefix, but it beats the miscapitalization of "LlEmail".

No, there is no decision anymore. We have the javascript patch already on the wiki to let us do proper capitalization. That eliminates pretty much the last con for flattening the namespace.

/54/88/166640/1.html

I've posted a new poll that reflects the current situation, now that the capitalization thing is fixed.

Darien, the LSL prefix IS a con. It breaks searching, it breaks linking, it breaks everything and solves nothing. We have a patch to allow lower case first letters now, see the other thread for an example of a page I moved.

Both voting options are idiotic.

LL should use software that suits the purpose. Until they do, I'll continue using the mirror. I suggest we abandon the LL version unless they come to their senses.

hacks are hacks are hacks. Excuses may be interesting and have technical merit etc. but they're hacks and unsuitable for the reasons mentioned above.

The function entries should be named identically to the function names.

Hmm, evidently my post is already out of date. Good!