Category talk:LSL Library

Rules for posting

Question was brought up: "Who enforces/decides the rules?

Anyone in the community may decide an article should be stripped but if a dispute arises it needs to be settled by the community at large or by a Linden who is arbitrating the debate (which would require the Linden to have been briefed by both sides). -- Strife Onizuka 06:29, 3 May 2007 (PDT)

I've removed some excessive (and slightly random) formatting bloat from the page. While I can appreciate the efforts made, not all contributors to these pages are active wiki editors, and it's VERY bad form to modify credited submissions, or their credits; Please, leave that to the individual users when credited. I also repaired a few links, and removed the links to named lindens (since company policy has removed their respective pages). if someone wants too try and confirm if the rest of the redlinks are either typos that need correction, or simply links to unsupported pages that need to be removed, that'd be great.
-- Void ^{(talk|contribs)} 15:06, 9 November 2012 (PST)

---

Discussions from Pre-Category era of this Talkpage

Category or normal page?

Shouldn't this be a category instead of a normal page?

The Wiki will automatically update the directory if it's a category.

Same with Examples. Gigs Taggart 15:23, 27 January 2007 (PST)

^^; didn't think of that before, lets use a catagory instead of a normal page then.Strife Onizuka 20:31, 27 January 2007 (PST)

Apparently Signpost didn't get the memo, and has moved everything into a subpage and turned this back into a normal page, that must be manually maintained. What he doesn't want to admit is moving everything into subpages breaks the category feature completely. Gigs Taggart 18:34, 19 February 2007 (PST)

If it was going to be a category-based setup, then why on earth was the author/description table still there if the prime claim of category-fu was

The Wiki will automatically update the directory if it's a category.

Same with Examples. Gigs Taggart 15:23, 27 January 2007 (PST)

It seemed to me, that in practice nobody really cared about the automatic updates.

SignpostMarv Martin

The table was still there because I left it there until ALL of the items that were listed on it had been created and tagged with the category, nor did I have the time right then to write up a new header since, at the moment the Library page was of much lower concern then the functions. But yet again you take it upon yourself to restructure things however you please, without discussion. And as another aside... We went to all the trouble of Removeing the "LSL_Library_" from all those pages because the complaint was that the "Psuedo-Namespace" would make it hard for linking, violated the whole "Simple Links" rule of the wiki etc. And what do you do? You put it back as "LSL_Library/". Thraxis Epsilon 00:22, 20 February 2007 (PST)

1. All the items listed in the table had been created and tagged with the category. Since the article was not in a sandbox, it was inappropriate to link to articles that did not exist.
2. LSL_Library is not a pseudo-namespace.

1. 1. Residents are automatically alerted when an article is edited. (RSS/ATOM)
   2. Residents are not automatically alerted when an article is added to a category. (unless I missed something)
2. The LSL Library is intended to be a repository of LSL2 code that can be used freely by all.
3. By not using the automatic updates feature of the categorisation system, other Residents are more likely to look over new additions to the library, check it for errors and malicious behaviour.
4. 1. The table provides more useful information than the category ever will.
   2. Since the description of a script cannot and should not be embedded into page titles, the table is more suited to new comers to LSL who wouldn't be able to guess what a script does based on the name.
   3. Nobody seems to have paid attention to this in the "memo" which I, as you point out, wasn't aware of.

SignpostMarv Martin 06:57, 20 February 2007 (PST)

Since when is it "inappropriate to link to articles that did not exist"? "the table is more suited to new comers"... the table isn't mutually exclusive with using the category the way it was meant to be used. The only thing that is incompatible with the category is your fucked up idea of moving them all into subpages. Gigs Taggart 09:36, 20 February 2007 (PST)

1. It confuses Residents.
2. It encourages people to commit copyvio- library scripts that are not yet up should be placed on a to-do list in the talk page, not in the article.
3. Duplicating data is bad.
4. 1. the subpages are not incompatible with categorisation.
   2. Having the table on the same page as the category listing would make a big mess as the Library expanded
      • See above point of "duplicating data is bad"
      • You'd be forcing people to load a page that was heavier than it needed to be.
   3. I'm not seeing any arguments that "the table sucks, get rid of it".

SignpostMarv Martin 10:11, 20 February 2007 (PST)

Just because you put something in a numbered list doesn't make it true. The table does suck, it's manually maintained and sure to get out of date, and like you said, is basically a duplication of the category listing. That is beside the point of moving the articles into subpages though. Gigs Taggart 17:52, 20 February 2007 (PST)

I put things in numbered lists so I don't ramble. Would you rather read through a numbered list or figure out what the hell I'm talking about ? :-P

Actually, it's integral to the sub-pages concept

• Manual editing, as said before encourages peer review of code.
• The table is a more descriptive index of the library than the category is, since you can't "encode" descriptive "data" into the article name without it being more "butt ugly" than it currently is.

In a cost/benefit analysis, providing the most helpful information manually far outweighs providing the least information automatically. Unless you're willing to write, design, and advocate all templates, data formats and Wiki-bot code necessary to have the helpful information built semi-automatically based on new additions to the category.

By not using the descriptive table, you're forcing the Residents to click through every single script in the library to see what each one does, but by using it, you help speed up browsing considerably, as they can skim over the table looking for what they want in the description column- offsetting some of the queries in SoSL for "does anyone have a script which does this".

SignpostMarv Martin 21:17, 20 February 2007 (PST)

Regardless of your personal opinion on how the wiki should be structured, the move to use a Category was proposed, it was seconded and carried out without any dissent. Your change however was never officially proposed, nor was it seconded, nor has it gained any approval other then your own rhetoric about how much better it is. Thraxis Epsilon 23:45, 20 February 2007 (PST)

I haven't read everything here and I don't agreed with everything I've read, but I'm like minded with Thraxis. My thoughts are these: Having both a table and category listing allows for ease of adding pages to the category, provides a link at the bottom of all pages back to the script library, and nice and the table can be updated as people feel the need. All the categories should be designed as such IMO. Having the category tells you what should be in the table. As to the prefix/namespace, I'm neither here nor there though a proposal would have been nice. If i didn't know better i'd say we were having an edit war. Strife Onizuka 00:27, 21 February 2007 (PST)

Meh. I screwed up :-D

Suggestion: Do both, but keep the table on a separate article, linking to it in the category description.

SignpostMarv Martin 02:27, 21 February 2007 (PST)

Nesting Breaker

Numbered lists make things look credible!

1. It's not an edit war, no one is reverting it back and forth. We are discussing it.
2. I think the table has drawbacks, like I said above, but I'm fine with the idea of table in the category page, like it was.
3. I deleted a similar table from the function category page, because that had all the same drawbacks and none of the benefits.
4. We should move the pages back out of subpages, because it breaks category sorting unless you use hacky stuff
5. I still don't see any real benefit to subpages.

Gigs Taggart 07:47, 21 February 2007 (PST)

re point 4. That's perfectly fine unless you want to:

1. sort articles by what they do, not how they're titled. Basic Encryption Modules should be sorted under E for Encryption, not B for Basic.
2. prevent people from gaming MediaWiki by naming creating an alt called Aardvark and titling all their scripts "Aardvark's script what I done learnt in class today". Or something along those lines :-P

SignpostMarv Martin 08:02, 21 February 2007 (PST)

These are non-issues to me. Gigs Taggart 10:32, 21 February 2007 (PST)

No matter what system you design, it can be gamed. Best to make a system that can be gamed in a reasonable manner. A little hacking with sort orders is ok, but should be kept as simple as possible IMHO.Strife Onizuka 11:23, 21 February 2007 (PST)

So.... you'd rather let an automated system waste peeps time by making them look through the entire list for something, rather than reviewing each script on a case-by-case basis and editing the sort order accordingly....

"Best to make a system that can be gamed in a reasonable manner" o_O

SignpostMarv Martin 18:09, 21 February 2007 (PST)

Issue with alphabetic ordering (to-do)

I just realised that the alphabetic ordering is broken.

Well... it has been broken for a long time, sure. I thought it was just a question of fixing some whitespace or something simple. It isn't.

The problem is that the first column (for the page links) can take (at least) two forms...

1. A regular wiki page (where alphabetic ordering will work); 2. A user page, under the user's namespace (breaks alphabetic ordering).

Now, user pages have been (and I supposed that they continue to be) encouraged, in general. For scripts, they have the additional advantage that the namespace itself provides the credits.

However, because such links start differently from "regular" wiki pages, those who have opted to publish under their user namespace will be listed first — and unordered, too.

I have no idea if that is the kind of thing that is "fixable" using the current version of MediaWiki and the very limited set of extensions installed by LL.

One possibility would be to create a special template for all entries, which would somehow do some wiki-fu on the link names in order to allow them to be alphabetically ordered in a correct way. I'm afraid that I'm not quite sure how to accomplish that in "pure" wiki syntax...

Until then, all we can have is a broken ordering.

— Gwyneth Llewelyn (talk) 16:52, 5 December 2023 (PST)