Talk: List of JavaScript enhancements

Scope

I've noticed some of the headers suggest certain types of script are limited to personal. For example, Interface Personalisation states: "These scripts alter the way Wikis look or behave so that it's more to your liking. Only use these in your personal JavaScript/CSS files, do not add them to the Wiki itself." I know this is not true for at least one script in that list. Similarly, Site enhancement suggests most of the scripts are only suited to site-wide installation, which again isn't true. My overall point is that grouping them under headers might make them a little confusing at times.

With that in mind, I'd like to template the entries to look something like this: HeaderLinks^[s][p] - <description goes here...>. The usage would look something like this:

{{js-entry
 | script      = HeaderLinks
 | site-wide   = yes
 | personal    = yes
 | description = <description>
}}

Thoughts? cqm 09:53, 19 May 2014 (UTC)

That would make it a lot clearer. I second this notion. -- sqm ^talk 11:24, 05.19.2014

You mean remove the headers completely and list all the available scripts in plain list form?

I am also worried about the size bloat by using the template considering the amount of scripts and the rate at which they continue to increase. Though it would be neat; but huge

I seriously feel that there is a dire need for another method to organise all the scripts in a way which would be easier to navigate and find for users

Seperating them into different pages (and tabview) or dynamically generating lists using dpl might work.~UltimateSupreme 16:13, May 19, 2014 (UTC)

Dpl is another option, but that would require some reworking of the infobox to add a type parameter and a relevant category for dpl to hook onto. Maybe we can make use of dpl's url variables to show a more specific list or some sort of js form to allow us to search for certain names, types, scope, etc? I'll get dpl enabled here so we can explore if it's suitable for what we need. cqm 17:53, 19 May 2014 (UTC)

I like having a single unified list, but it needs a lot more organization. I've been working on it, and I think it's A LOT more organized now, but it still needs more work. Does anyone have any other ideas on how it can be further organized? Code Lyoko Wiki: User: Deadcoder 18:13, May 19, 2014 (UTC)

I agree with Deadcoder, that it has been greatly improved in the last couple of months, but it definitely needs to be reworked with a new method to organize it. I don't know the specifics of how DPL works, but I think that the dynamically generated list using DPL sounds like a good option to me. It sounds to me like reworking the template would be worth it to be able to use that method. —RyaNayR ^{(talk • contribs)} 22:48, May 19, 2014 (UTC)

I think DPL might not be a good answer in this case. While its performance cost is acceptable in this case, DPL really only works well in wikis with a very good category system; which, honestly, this wiki doesn't have. This could be fixed, but I don't think it's a good solution to the problem at hand. I think we should continue the current system of tabbing, until a better solution is determined. Code Lyoko Wiki: User: Deadcoder 23:06, May 19, 2014 (UTC)

^{(reset indent)} I think that a DPL solution would be a major improvement over the current system of manually adding scripts to specific tabs. As far as a category system goes this wiki has a very minimalist tree that could easily be expanded upon with very little effort. Another benefit of DPL is the small page sizes and the ability to cache lists/queries in order to conserve server resources. Lil' Miss Rarity _{]Open Source[} ^(talk) 00:54, May 20, 2014 (UTC)

In reality, the only time we would ever need to uncache the lists generated by dpl is when a new script is published which only requires a simple null edit. cqm 09:14, 20 May 2014 (UTC)

If we improve the category infrastructure on this wiki, I would be open to using DPL on this page.Code Lyoko Wiki: User: Deadcoder 21:50, May 20, 2014 (UTC)

Rename

I still have no idea why moving pages is disabled for everyone but sysops on this wiki, but this page should probably be renamed to “List of JavaScript enhancements,” since “enhancements” is a common noun and not a proper noun.
―PapíDimmi (talk | contribs) 07:35, July 8, 2016 (UTC)

It is probably disabled because developers can change pages in the mediawiki namespace, and could potentially break existing scripts all over wikis. Beyond that, page titles do not conform to any grammar rules. People can potentially name them however they want.Dessamator (talk) 09:30, July 8, 2016 (UTC)

Yeah, you’re right. Anyway, why should page titles not follow any grammar rules? That’s silly.
―PapíDimmi (talk | contribs) 09:32, July 8, 2016 (UTC)

Simply because it makes no sense to enforce grammar rules on titles. For example, if wikiquote has a quote in which the author made a grammar mistake, and the quote is notable exactly because of that grammar mistake, then it makes perfect sense to leave it as is, instead of renaming it. See:

• https://www.scribendi.com/advice/movie_quotes_that_are_grammatically_incorrect.en.html
• http://theweek.com/articles/465231/9-famous-quotes-that-are-technically-grammatically-incorrect

In fact, a page may be considered grammatically accurate one day and be wrong a few years later as those discussions about Shakespeare note. It still wouldn't make sense to change Shakespeare's books just because they are "grammatically" inaccurate.

Anyway, back on topic. I think the codeeditor group has still retained the right to move pages, although I'm not really sure.

Dessamator (talk) 21:38, July 8, 2016 (UTC)

Of course direct quotes shouldn’t be changed. A page on a public wiki should, though. This is not an extension page, so grammar should matter in the title.
―PapíDimmi (talk | contribs) 12:46, July 9, 2016 (UTC)

I don't see any issues whatsoever with the pagetitle. --Sajuuk 18:42, July 9, 2016 (UTC)

My apologies for the late reply. Anyway, “Enhancements” should not be capitalized, since it’s not a proper noun.
―PapíDimmi (talk | contribs) 13:19, July 20, 2016 (UTC)

Why does it matter if it's a proper noun or not? --Sajuuk 14:16, July 20, 2016 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ It shouldn’t be capitalized and therefore is grammatically incorrect.
―PapíDimmi (talk | contribs) 22:03, July 20, 2016 (UTC)

It sounds like there are two good reasons to rename this page, then:

1. It will keep pedants like PapiDimmi happy.
2. It will put an end to this debate, and the related DISPLAYTITLE edit war.

DarthKitty (talk) 23:51, July 20, 2016 (UTC)

Done. --Saftzie (talk) 02:44, July 21, 2016 (UTC)

Incorrect; there was one good reason to rename this page: it was grammatically incorrect. ’Course it made me happy; I’m a god damn grammer god. I never make any grammatical mistakes.
―PapíDimmi (talk | contribs) 18:51, July 22, 2016 (UTC)

NO TABBERS PLOX

• Do not use tabber. It doesn't work on mobile versions.
• Use a floating TOC and an back to top button on this page for easier navigation.

yhynerson1talk 06:34, July 13, 2016 (UTC)

I removed the tabbers about a month-and-a-half ago because, as yhynerson1 noted, they're detrimental to mobile users. Furthermore, tabbers cannot be edited using the VisualEditor, and are an annoyance for source-mode editors like myself. ("Wait, where was that redlink again??") There's also that annoying overlapping problem if you have "too many" tabs.

I get that the other layout wasn't pretty, but I don't think "restoring" tabber was the right solution either. Maybe a "card"-based design would work better? By that I mean something like the one I was experimenting with a few months ago. Either way, I'll refrain from fixing the problem so that we can talk about alternatives.

DarthKitty (talk) 00:45, July 18, 2016 (UTC)

I agree that tabbers should not be used on this page. The overlapping tabs look worse than the headers in my opinion.

I like the Card design, however, the page may become too large (visually) due to the size of the cards and the amount of JS scripts. Perhaps sections of cards could be collapsible? I don't know. Anything another than these tabs is fine with me.

-- Monochromatic Bunny 15:52, July 18, 2016 (UTC)

I find simple is better especially since this is just a list. How about some sort of collapsible organization where we put scripts under headers like we do now but instead of using tabbers we just stick them in collapsible lists?

Lil' Miss Rarity ^(message) • Monday, July 18th 2016, 17:39

Do you mean something like this? DarthKitty (talk) 19:13, July 18, 2016 (UTC)

I think DarthKitty's design should be used. I made a test design, but his is probably better.

-- Monochromatic Bunny 19:40, July 18, 2016 (UTC)

^{(reset indent)} Okay, I think I'm done tweaking the CSS and stuff. :p Any additional/new thoughts on my mockup? DarthKitty (talk) 21:14, July 18, 2016 (UTC)

I prefer the module cards cards over collapsing boxes. yhynerson1talk 16:27, July 23, 2016 (UTC)

@Yhynerson1 - You probably should have discussed your ideas on the talk page before changing the layout. We were already discussing alternate designs.

Anyway, I still prefer DarthKitty's design, and I think we should go through with implementing his layout.

-- Monochromatic Bunny 18:49, July 23, 2016 (UTC)

The tabber interface is the easiest to use among these suggestions, primarily because it prevents the need for scrolling which with the abundance of content items is incredibly tedious. Tabbers do not load on mobile but it is no different than using basic headings. Collapsible divisions do not work on mobile either. Moreover, any viewer interested in installing scripts on their wiki would very likely be accessing the wiki using a PC, and if not, the mobile full site option would almost always be resorted to where tabbers remain functional. CSS can be used to fix the sloppy default layout that has the tabs overlap when exceeding one line. Subheadings can be used to edit specific sections.

Hackey5 (talk) 05:01, July 29, 2016 (UTC)

CSS shouldn't have to be used as a workaround due to the tabber's "sloppy default layout". The simplicity of headers and/or collapsible boxes is better in my opinion. Also, scrolling on this page won't be tedious due to navigation elements that can be used. —Monochromatic Bunny | ☎ 04:32, July 30, 2016 (UTC)

The statement "tabbers do not load on mobile but it is no different than using basic headings" is provably false. Basic headers are visible on the mobile skin, while tab titles are not. You can test it for yourself with the mobile preview button, or by using the query string useskin=wikiamobile.

Additionally, the mockup I made a few weeks ago takes up less vertical space than the most recent, tabber-based layout. If scrolling is your problem, then my suggestion is currently the best solution. Though honestly, I think this page will always be "too long", since we're trying to list every script ever. I wonder if we could break it up, somehow...?

DarthKitty (talk) 05:44, July 31, 2016 (UTC)

I do not understand this unwillingness to use tabbers. In fact, tabber titles are visible as shown here for the mobile display. Therefore, it does not matter which display is adopted for mobile as they will all be rendered the same with plain headings. For PC, however, the tabber display is the easiest display to navigate. All tab titles are visible with which the viewer can select any to access its content. Sometimes down-and-up scrolling is necessary for long items, but that is all the scrolling one must perform, and any tab title can be readily selected from the same location on the page. Collapsible elements scatter the headings down the page, making it more difficult to locate and navigate items, not to mention having to expand and collapse each section which requires even more scrolling and tedious fidgeting. This is not simple, this is not efficient, this is not easier. The only advantage I see to collapsible elements in this instance is that collapsed, they neatly hide all content. Otherwise, tabbers among these display options benefit viewers the most.

It is irrelevant that editing might be made slightly more tedious for editors. It is their responsibility to use the source editor (the VisualEditor being incompatible is not an excuse) to the necessary extent to add their scripts to the article. Ease of access for viewers takes precedence. Hackey5 (talk) 07:43, July 31, 2016 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ It seems like scrolling in general is tedious to you, but it's a normal part of any website. The collapsible boxes design has minimal scrolling; you can collapse the box if you think the page is getting too long. Also, would you suggest all pages use tabbers? You included that the headers are scattered down the page, but most pages on wikis use headers to organize information. —Monochromatic Bunny | ☎ 08:13, July 31, 2016 (UTC)

A tabber is one means of organising non-sequential information of a large volume. You have not justified how collapsible elements are able to do better job at this than tabbers do, specific to this case. Therefore, until alternatives are proposed which can significantly improve the content display of this article, it would be preferable to readopt the tabber display, especially over the current headings which are certainly not making it easy to navigate. Hackey5 (talk) 10:45, July 31, 2016 (UTC)

@Hackey5 I'll admit, your apparently-working example had me stumped for a few minutes. At first, I thought that Wikia made some change to their mobile skin that fixed the problem. However, a bare-bones test proved otherwise:

<tabber>
|-|Title 1=content 1
|-|Title 2=content 2
</tabber>

Paste that into any page and press the "Mobile" preview button. I'll wait. Adding the selfsame code to my test wiki and useskining made no difference, so I knew this wasn't a case of broken previews.

My next assumption was that you used some obscure trick when "restoring" tabber, one that I didn't know about, to make the titles show up anyway. To test that possibility, I made a copy of this page as it appeared a few weeks ago. Even though both pages (apparently) used the same code, my copy didn't have headers on mobile.

Switching between your example and my copy, however, I noticed something odd: the hatnotes were different! It dawned on me that User:SuperSajuuk tweaked the hatnote after User:Yhynerson1 re-removed the tabbers (see diff). That meant that either your example or my copy was actually using more modern code.

To make a short story long and boring, the mobile skin apparently doesn't support the oldid query string. Instead, you always get the most recent version of a page. You can test it for yourself by clicking on this link (the example you gave), and then clicking on the pencil icon in the top-right corner. You should see the following code:

:'''''Note''': Please visit the [[Help:Advanced CSS and JS|Advanced CSS and JS]] help page for more information on how to use JavaScript and CSS on your wiki.''

<div class="hidden" style="border: 1px solid #ccc; display: block; float: right; margin-left: 0.5em; padding: 0.5em 0.75em 0.25em; width: 155px;">
    <div style="text-align: center;">'''Contents'''</div>
    <ul style="margin-left: 1.45em;">
        <li>[[#Tools|Tools]]</li>
        <li>[[#Site Enhancements|Site Enhancements]]</li>
        <li>[[#Dev tools|Dev tools]]</li>
        <li>[[#Talk Tools|Talk Tools]]</li>
        <li>[[#Wikia Skin Bolt-ons|Wikia Skin Bolt-ons]]</li>
        <li>[[#Editing Tools|Editing Tools]]</li>
        <li>[[#User Management|User Management]]</li>
        <li>[[#Site Integration|Site Integration]]</li>
        <li>[[#Chat Extensions|Chat Extensions]]</li>
        <li>[[#Page and File Management|Page and File Management]]</li>
        <li>[[#Translations|Translations]]</li>
        <li>[[#Non-Recommended Installations|Non-Recommended Installations]]</li>
    </ul>
</div>

This is a list of JavaScript enhancements categorized by type.

That HTML mess is the custom table of contents that Yhynerson1 wrote. Since the mobile skin ignores the __NOTOC__ magic word, I made sure our custom one is invisible there (see diff). If you click on various other pencil icons, you'll see that there are no tabbers. A couple of grammar mistakes that should be present in the old version are also missing (e.g. "a arrow").

tl;dr Tab titles don't work on mobile, and your "example" is actually what the page looks like right now.

Now then, let me reiterate my previous question: Would it be a good idea to break this massive page into several smaller ones?

DarthKitty (talk) 13:28, July 31, 2016 (UTC)

Store data and display page data in a structured format using lua

Personally, I'd suggest scrapping the whole design of this page, and generating it with lua. This is the developer wikia so there should theoretically be no lack of technical expertise, and all data on this page is structured and can be stored in a data module. This has some benefits, for instance we can store data about the authors of the scripts, the categories, and automatically update it and the documentation page's infobox with author information or link to scripts that share the same "category". 

This would also make it easy to document the scripts without needing to add information to 2 pages, the script  page, and this one. Documenting in two places also means double work, and the fact that the docs can fall out of sync when changes are made, or the script is deleted for instance.

Generally speaking, few developers (at least I don't do it often) seem to take the time to add their scripts to this list. Dessamator (talk) 08:21, July 31, 2016 (UTC)

Well, that's a new take on it. I'm open to anything, besides tabbers, for this page. Your idea increases accuracy all across the board, so I support it. —Monochromatic Bunny | ☎ 08:34, July 31, 2016 (UTC)

This is a really interesting idea, but I'm not sure how it would solve the immediate problem (layout). Even if we create a central repository for scripts, we still need at least one user-facing page to list 'em. Whiiiiiiiich means the tabs-versus-no-tabs debate will rage eternally!!! Mwahahaha...

*Ahem*

I mean, that would be terrible.

DarthKitty (talk) 13:28, July 31, 2016 (UTC)

Personally I don't see any debate, I see one user with 4 edits on the main namespace (all on this page) of this wiki with an opinion that noone else seems to share.

Changing it to be lua generated will definitely end the discussion, because few users can actually write stuff in lua, so they won't know how to fix the issue anyway. Short of reverting it back to its pre-lua version and possibly edit-warring over it. Dessamator (talk) 14:05, July 31, 2016 (UTC)

I entered this discussion because one day I returned to browse for scripts and found the article distastefully difficult to navigate since the tabber had been removed. If that's the case, I'm sure many others would be feeling the same way. I simply decided to have a say about it. My edit count is irrelevant.

Generating data using Lua is a logical step. How this data is presented to the viewer is what I would like to see managed efficiently. @DarthKitty, thanks for identifying the discrepancy in my claim earlier. To answer your question, I always think it is best to confine relevant information to one primary source where it can be easily viewed and managed. Splitting things between multiple pages just makes it more difficult for viewers to navigate and find things. I prefer the use of a tabber here because it keeps relevant information close together with browsing being a simple and minimal-scrolling process, essential for those seeking to find suitable scripts among a boatload. Now, there seems to be a concern due to a lack of generated headings, and I'm assuming Wikia haven't created a class that can be applied to elements so they can be viewed on mobile only, which would solve that issue. Unsolved, I personally do not find it pressing, as I explained earlier, with this wiki likely to be hosting far more PC technical editors than casual mobile viewers, although I imagine that my argument wouldn't weigh up for those insistent on universally optimal functionality. In that case, I emphasise that whichever layout option is decided on is equally convenient for the viewer. Headings nor collaspsible elements in their currently suggested forms achieve this. I would be interested to know how @Dessamator intends to have this article's content presented under a new page design, in addition to the handling of the content itself as previously mentioned. Hackey5 (talk) 15:11, July 31, 2016 (UTC)

> My edit count is irrelevant.

Edit counts are irrelevant but the nature of the edits are very relevant. If someone claims that they know what's best for a page they've never edited people will certainly be skeptical, regardless of how skilled they may think themselves to be.

Furthermore you stated that "It is irrelevant that editing might be made slightly more tedious for editors". This comment is made about a page you only edited to push your point of view. Wiki pages are a balance between the needs of editors and the needs of readers, and few users would likely edit any page if it was filled with unintelligible markup.

>I would be interested to know how @Dessamator intends to have this article's content presented under a new page design

Well, the page would be improved in stages. The first stage would involve importing all data about scripts to a lua module. The second would involve moving content that is is irrelevant for an average reader such as non-working scripts to a separate page, and possibly incorporating some of Shining Armor's ideas[1] to improve the layout. Finally, the last stage would involve an assessment of whether separate pages and tools such as collapsible sections and so forth are still necessary, and if so they'd be incorporated into the design. Dessamator (talk) 08:14, August 1, 2016 (UTC)

I clarify my statement, it is of lesser significance that editing be made slightly more tedious for editors in terms of being prevented from using the VisualEditor and having to scroll through the source editor than being able to click into heading sections, in comparison to viewer convenience. I will certainly push my point of view and justify my points accordingly. However, I would like to see productive changes actually implemented. Bringing up Shining Armor's October 2015 thread, those are indeed some good suggestions, yet, following months after its creation, few of them have been implemented. I understand that proceeding to change significant aspects myself will likely lead to complaints, so I am taking the time to discuss suggestions beforehand. Here, I do wish to carry out the proposed translations and non-recommended installations changes, as well as changing 'co-installable' to 'general'. If no one is opposed, I can get to it and tweaks can be made afterwards where necessary. At least it is one step in the right direction before we proceed to undertake a design overhaul of some sort. Talk is good, but it amounts to nothing without resulting action. Hackey5 (talk) 09:27, August 1, 2016 (UTC)

@Hackey5:

Bringing up Shining Armor's October 2015 thread, those are indeed some good suggestions, yet, following months after its creation, few of them have been implemented.

The reason for that was simple, Shining armor made suggestions but didn't followup on it, and didn't even reply to another user's comment. Also, the author labelled it as a rant, and didn't even add a link to the talk page which is the "appropriate venue" for discussing changes to an article. Heck, you don't seem to have noticed it until recently, despite the fact that it was below the article (and I added that link long ago).

Here, I do wish to carry out the proposed translations and non-recommended installations changes, as well as changing 'co-installable' to 'general'

Agreed. Dessamator (talk) 09:39, August 2, 2016 (UTC)

Take another look at the "Translations" section: some of the scripts listed there have i18n'ed descriptions. The problem with @Shining-Armor's proposal is, those descriptions would have to be removed—at that point, only English-speakers could browse for new scripts.

I think a better idea would be to create a new page for each language, e.g. List of JavaScript enhancements/es. Then we could use Template:Languages for navigation. This is how scripts like AjaxBatchDelete are organized, and I think it would let us remove redundant links.

I think we should probably remove the so-called "non-recommended installations" from these pages. If we don't want people to install old scripts, why list 'em? Maybe we could use a tracking category to organize the outdated stuff, something like Category:Deprecated modules.

We could probably get rid of the "expanded list" section, too. There's no reason to list CSS on a page called List of JavaScript enhancements, and @Dessamator's database plan might make the JavaScript bit redundant. Speaking of databases, this is what we're looking at so far:

<syntaxhighlight lang="lua">
{
    {
        name = "",
        description = {
            en = "",
            (...)
        },
        deprecated = false
    },
    {
        name = "",
        description = {
            en = "",
            (...)
        },
        deprecated = false
    }
}

Does that sound all right? DarthKitty (talk) 12:50, August 2, 2016 (UTC)

In regards to the thread I made several months ago it should be noted that it was never meant to be a perfect solution wrapped up in a neat little bow. It was a list of suggestions and pet peeves about the way we present scripts here. It's wasn't perfect and the thread was supposed to facilitate discussion on this topic which never got more than one reply with misc. commentary from one user, which, did not warrant a reply.

らり牛ちゃん (talk) 18:02, August 14, 2016 (UTC)

Threw together another mockup, in case I didn't explain that very well. I think it's a little better than the current version! DarthKitty (talk) 13:00, August 2, 2016 (UTC)

Yes, separate pages i18n for "Javascript enhancements" would make sense. Right now it is a confusing mix of several languages.

> I think we should probably remove the so-called "non-recommended installations" from these pages. If we don't want people to install old scripts, why list 'em? Maybe we could use a tracking category to organize the outdated stuff, something like Category:Deprecated modules

Agreed. Over time, deprecated scripts should be re-evaluated and deleted if there is no need for them, or possibly if they contain security exploits that were discovered later on (and no one is willing to fix them). Also, since this is stored in a structured format, it would be trivial to make it "re-appear" once it is useful. For example, an experimental script may eventually be completed, and be ready for use.

The database also requires a field for type or category of the script , e.g. "site enhancement", "dev tools", etc . It also requires scope.

[
--Current schema
{
    "name": "ShowHide",
    "description": "Script for collapsible tables/divs using jQuery",
    "authors": "",
    "scope": "",
    "languages": ""
}
]

We'll probably need some validation for types to avoid typos, so it might make sense to use a separate data module to define allowed types.

Later on, the infobox javascrip can be changed to use the values from the lua module if the user hasn't overwritten them. Dessamator (talk) 14:00, August 2, 2016 (UTC)

'Co-installable' has been changed to 'General'.

Over half the scripts in the Translations section were not even translations but scripts that had language support. Even less had foreign descriptions on the page itself. I've included links to script articles that are of a foreign language beside their respective items in the main scripts section in accordance with previous suggestions. Dedicated language support on the article does not seem necessary in mind of how few scripts are actually translated at present. A few links need to be included in the generated list of chat scripts and are temporarily located under an additional heading.

Since no tabber is planned on being installed, I've moved certain script type sections around so that those more likely to be sought after such as those designed for navigation efficiency, maintenance and improved visuals are positioned towards the top while more advanced scenario scripts are lower down.

The non-recommended scripts section has been fit into a collapsible box since most people will not find them relevant and it is not primary content. Removing them from the article and marking them with some kind of 'pending stable release' category is a nice idea.

I've updated a bit of wording. One issue is that there should be no use of pronouns and the article will require additional inspection and correction in such instances. Hackey5 (talk) 14:39, August 2, 2016 (UTC)

I made a couple of small improvements:

• I removed CSS from the "Expanded list" section, since the page is about JavaScript. There's a link to the same content (Category:CSS) in the main navigation, so that shouldn't be a big deal.
• I removed the "Scripts" header because it was kinda redundant. Doing so let me "dedent" the other headers, and I think that made the page a little easier to read.

DarthKitty (talk) 03:20, August 3, 2016 (UTC)

@Darth: Nicely done.

@Hackey: As far as translations are concerned, it may be best to add them only when needed. If anything having a page in one language would be confusing when someone clicks a link only to find a page in another language. It is just a drawback of multilingual wikis like this one.

Also, it may be better to have an expanded name of the language, "vi" doesn't particularly carry a lot of meaning unless you know beforehand that it is a language code. This can either be added as a full language name, or a language autonym. Dessamator (talk) 08:59, August 3, 2016 (UTC)

Super-simple page splitting proposal

I think there's a major problem with @Dessamator's plan. Wikia is apparently working on some sort of "extract data from your infoboxes" thing, and that sounds like it would make our database redundant. Since building a database would be a lot of work (even with a hypothetical bot that could parse wikitext), we're probably better off waiting.

Now, in my opinion, tabber is a code smell. It means that you're trying to squeeze too much content into a small amount of space, rather than breaking it into logical sections. If each section is really meaty, as in our situation, then I think it's better to use separate pages instead of headers.

I think our case is especially clear. We have 10 lumps of content on this page, and most of them have subheadings. However, we've gone to great lengths to hide those level three headers:

• @Cqm and (much later) @Hackey5 abused description lists (; and : in wikitext)
• @KurwaAntics created a custom table of contents

That's why I suggested splitting the page earlier. However, this is the only response I got:

I always think it is best to confine relevant information to one primary source where it can be easily viewed and managed. Splitting things between multiple pages just makes it more difficult for viewers to navigate and find things.

Hackey5

I think we can break the page up, and ensure that it's easy for people to find what they're looking for. Here's how:

1. Create the following ten pages:
   • List of JavaScript enhancements/User tools
   • List of JavaScript enhancements/Page and file management
   • List of JavaScript enhancements/Site enhancements
   • List of JavaScript enhancements/Editing tools
   • List of JavaScript enhancements/User management
   • List of JavaScript enhancements/Talk tools
   • List of JavaScript enhancements/Oasis skin enhancements
   • List of JavaScript enhancements/Chat extensions
   • List of JavaScript enhancements/Site integration
   • List of JavaScript enhancements/Development tools
2. Edit MediaWiki:Wiki-navigation thusly:

   * |Scripts
   ** List of JavaScript enhancements|JavaScript
   *** List of JavaScript enhancements/User tools|User tools
   *** List of JavaScript enhancements/Page and file management|Page and file management
   *** List of JavaScript enhancements/Site enhancements|Site enhancements
   *** List of JavaScript enhancements/Editing tools|Editing tools
   *** List of JavaScript enhancements/User management|User management
   *** List of JavaScript enhancements/Talk tools|Talk tools
   *** List of JavaScript enhancements/Oasis skin enhancements|Oasis skin enhancements
   *** List of JavaScript enhancements/Chat extensions|Chat extensions
   *** List of JavaScript enhancements/Site integration|Site integration
   *** List of JavaScript enhancements/Development tools|Development tools
   

3. Move content from List of JavaScript enhancements to the appropriate subpage. Make sure each one of those links to the others.

This proposal will make navigation a breeze, since people can go directly to what they're looking for. Want a chat script? Bam, you're there. Editing tools? Easy. If the page you're on doesn't have what you're looking for, you can easily go to another.

DarthKitty (talk) 09:42, August 15, 2016 (UTC)

Wikia is apparently working on some sort of "extract data from your infoboxes" thing, and that sounds like it would make our database redundant.

Personally, I think that is wishful thinking and I'm not holding my breath for that. Wikia staff told me more than a year ago that they were planning on having structured data, and yet it is still not available. Cqm also suggested[2] that perhaps we would have proper scribunto documentation support, and it would be better to "wait" than to do something that will be broken later on. Strictly speaking structured data using infoboxes isn't likely to work all that well anyway because it would probably lack a centralized location to update information, unless they implement it differently.

I don't disagree with the idea of splitting the page, but it seems to me that it will not fix the main problem. This page will always be outdated, unless people make a herculian effort to always confirm that it contains the same content as the Category:JavaSript pages.

The easiest solution would in fact to ditch the notion of generating this page manually, and use javascript that CAN currently parse information from portable infoboxes. Of course that would mean that we would be giving the finger to mobile users unless something like a simple DPL fallback is added.

The proven idea of using scribunto modules will work because instead of relying on updating infoboxes directly people would actually make changes to a data module which would update both the infobox, this page, and any other page that may need that data. Even if wikia deploys their "structured data for infoboxes" it wouldn't take much time to adapt it, or to ditch these modules. In fact, I had already started coding the module : Module:Scriptlist.

Dessamator (talk) 10:16, August 15, 2016 (UTC)

Splitting the page is the worst alternative if we are aiming to improve convenience and centralise where script developers can include links to their articles. It is most likely that viewers do not know what types of scripts they are searching for. Browsing will become immensely more difficult having to navigate between pages and through tiresome loading times. Less viewers will take the time to do so if related information is not presented to them accessibly. When I first used the article, I went through, opening dozens of tabs for scripts which appeared useful, later inspecting each after picking them all out. The tabber at the time made it easy to browse the types of scripting without having to fidget around with scrolling or tables of contents, let alone jumping between articles which serve only as points of navigation to the actual articles of interest. Moreover, for editors, good luck trying to monitor and maintain multiple pages. Far beyond that of having certain edit section links being absent from tabbers, keeping things consistent will become a nuisance.

I respect good coding practices, but choosing not to use description lists which do not register as items in the table of content for the sake of usage integrity is yet another thing preventing the article from suiting viewers' convenience. Not using a tabber due to a lack of specific headings on only the mobile non-full site view (which for a wiki of this nature is unlikely to facilitate the majority of viewer traffic compared with knowledgeable PC editors) is questionable if these other alternatives require far more steps for all users. I support the implementation of data modules for improving the management of content, but if the presentation of this content makes browsing a tedious drawn out process, people will not bother to do so at all. That can be decided with just one thought of there being too many pages with too many links to a wide variety of scripts which may or may not be of interest. Hackey5 (talk) 15:52, August 19, 2016 (UTC)

@Hackey:I think the problem here is people misunderstanding what this page is for. The page simply exists because of the awful wiki search engine, and so it acts as a sort of index. The proof for that is of course that every single thing on this page is really a copy or paraphrase of the content in each individual script page. The only novelty of this page is an organization by types, which should really be part of script pages, either as a parameter in the infobox or as a category or both.

Regardless of how desperately you want this page to be some sort of mini search engine, that's something that it will never be. Even with javascript it would never be as efficient.

One way to somewhat improve search would be to move all these pages to a "JavaScript" namespace much like how mediawiki api pages work (mw:API) since we can't search by categories. Of course that will require admin involvement, and in the past Cqm has been reluctant to add new namespaces for documentation.Dessamator (talk) 18:26, August 19, 2016 (UTC)

Indeed, I've emphasised enough why presentation is important. Let's focus on data management alternatives beyond manual listing. Now, I'm not an advanced coder and don't know much about how wikis function internally, nor what Wikia wikis are or are not capable of at that level. Please bear with a few basic questions. On the index article, the chat scripts are generated rather than listed manually. Are they included through categorisation or called by a parameter input from a template like you have suggested, or are the items simply stored elsewhere rather than on the page itself? If a script article is categorised, is it possible to include category lists of each type on the index article? What additional capabilities are there to the said JavaScript namespace? Lastly, depending on what method is chosen, possibly, to what lengths would existing script articles need to be attended to to update them to work with the newer standard? Hackey5 (talk) 03:22, August 20, 2016 (UTC)

Are they included through categorisation or called by a parameter input from a template like you have suggested, or are the items simply stored elsewhere rather than on the page itself?

They are added using an extension mw:Extension:DynamicPageList_(third-party) by extracting a list of pages from Category:Chat Scripts.

If a script article is categorised, is it possible to include category lists of each type on the index article?

Yes, as noted above.

Lastly, depending on what method is chosen, possibly, to what lengths would existing script articles need to be attended to to update them to work with the newer standard?

Pure data modules would require people to actually edit the module page, e.g. like Module:Country/data. Using dpl and lua which is something I was actually considering, it is entirely possible to automatically update this list whenever someone edits the script pages or whenever cache refreshes. So in essence, people would stop editing this page completely. A whole lot more options are available using javascript, it all comes down to time, skill or interest. Although that is the hardest option to maintain because it will require security reviews, people skilled with javascript, and admins here to support it.Dessamator (talk) 09:02, August 20, 2016 (UTC)

What additional capabilities are there to the said JavaScript namespace?

Every single benefit that you get from a normal namespace, listing pages e.g. Special:Allpages, searching, filtering special maintenance reports, etc etc.Dessamator (talk) 11:13, August 20, 2016 (UTC)

Considering the above, it would seem relatively simple to replicate the DPL like what is being used for the Chat Scripts category for the other scripts types, although these categories would need to be added to every script. Of course, all brief descriptions on the index article would be omitted if this method was chosen, and that would highly disadvantage viewers. So, we would be looking towards the Description parameter inputs of the script infoboxes also being called to the index page, and this would then require a module to be developed. A design that works by a script author correctly configuring the infobox on their script article, which then has the relevant information automatically included on the index article, is what I would suggest and seems to follow along with your suggestions. Would categorisation be a good point to start off from, or do you have anything else specific in mind? Hackey5 (talk) 10:24, August 21, 2016 (UTC)