Wikipedia:Gadget/proposals

From Wikipedia, the free encyclopedia

Shortcut:
WP:GP
Archive
Archives
Archive 1
About archives • Edit this box

This page is used to discuss the addition of user scripts as Wikipedia gadgets.

Contents


[edit] A much simpler gadget

Distinguishing links to redirects in a different colour has been a long-standing request on bugzilla (bugzilla:4709, open since 2006). Recently that bug has been fixed, in such a way that although links to redirects appear the same as links to other articles, it's now a trivial two-liner to make them appear differently:

a.mw-redirect {color:#308050}
a.mw-redirect:visited {color:#3070A0}

I'd like to propose that this be added as a CSS gadget. It should be completely portable, due to its simplicity, and is ideally suited as a CSS gadget, because it's a preference that some users will want and others won't. The only problem is in the choices of colour; I don't think that link colours differ too much between skins, but some colours might presumably work better in different skins. (In case you're wondering: nonvisited redirect, visited redirect; 'visited' means that you clicked on a link that linked to a page via that redirect.) --ais523 20:31, 18 February 2008 (UTC)

It's probably something that should be added as direct option in user preferences, but until then this would be a good solution. -- Ned Scott 18:14, 25 February 2008 (UTC)
I'm not against this code as a gadget, but given the small size and possbible other color choices, I think this makes is ideal for a simple personal CSS snippet. —AlexSm 21:30, 25 February 2008 (UTC)
I think this gadget would be very useful. Most users have no idea how to add CSS snippets to their own monobook.css and that is exactly why we need gadgets.
--David Göthberg (talk) 15:31, 23 April 2008 (UTC)
Actually, now I think that this code would indeed make a useful gadget for many users, but I think it should have a description page that would explain how to add CSS for other color choices. And it doesn't have to be complicated: we could create a direct link that would start editing user's monobook.css and on top of that offer insertable code snippets with <charinsert>; I'll try to create an example later. —AlexSm 17:29, 24 April 2008 (UTC)

[edit] Fix the sidebar

I think a lot of people are interested in the meta:Help:User style/floating quickbar (which could probably be updated...) — Omegatron 03:46, 4 April 2008 (UTC)

—AlexSm 19:34, 4 April 2008 (UTC)


Fixed positioning has been implemented in IE7,[1] so we don't want to degrade there.

Since the CSS is included in the script, javascript can be used to hide it from older versions of IE instead of the attribute selector. Whichever is the better choice. I am sure other people here are more familiar with how to do this than I am.

Yeah, it's confusing because people want the personal links as a sidebar. So we have two configurations:

  1. Personal links as a sidebar
    • Needs extra CSS to format them
  2. Personal links at the top
    • Needs extra JS to fix their position in the page structure

To keep things simple, this script will only do case 2, and move the personal links so they stay at the top like the default look.

Then an independent script can undo the move, put them back to the sidebar, and add their CSS if desired.

See User:Omegatron/monobook.js/floatingSidebar.js for the self-contained script.

importScript('User:Omegatron/monobook.js/floatingSidebar.js'); — Omegatron 01:22, 8 April 2008 (UTC)

I think you have to do more thorough testing, maybe from a different clean account? The current version (floatingSidebar.js) makes most p-tb ('toolbox') links inaccessible because your code relies on some CSS rules in your monobook.css (such as #p-logo {display:none} #column-one {padding-top:0} —AlexSm 15:52, 11 April 2008 (UTC)
I tested with and without the logo, and it wasn't affected either way. Can you describe the problem in more detail? — Omegatron (talk) 16:48, 20 April 2008 (UTC)
Oh, I see. The logo is position:absolute; which screws up the height:100% thing, which makes it not show scrollbars at the correct height when you have the logo. I'll fix it. — Omegatron (talk) 17:17, 20 April 2008 (UTC)
Both the personal links sidebar and floating sidebar scripts have been fixed. — Omegatron (talk) 17:33, 20 April 2008 (UTC)

[edit] New Gadget/Script

I would like to request a new gadget or script that allows a user to see if there are any new comments on an articles talk page since the last time they edited that page. Maybe change the color of the talk tab to another color or add a link to the header (similar to how it is for the assessment) when the page is opened. If this is not possible then maybe a user defined date (like today, last X days).--Kumioko (talk) 21:37, 14 April 2008 (UTC)

That sounds like an interesting endeavor. But what pages would this apply to? And what should "new messages" be defined as; an edit to the page since its last visit, the creation of a new section, etc.? I will attempt to work on a basic script, but I encourage others to work on it also since I am a beginner at this kind of stuff. — Parent5446 (t n c k e l) 00:48, 19 April 2008 (UTC)
I was thinking mostly for the talk page of an article. Basically, if you click on the article then a small message is displayed saying that the last message was left on XX date. Or if possible since the last time you left a message on that talk page, whichever is easier. This way you don't have to open every talk page to see if something has changed.--Kumioko (talk) 15:33, 23 April 2008 (UTC)
"if you click on the article" - does that mean "when you're on the article page"? Checking the talk page would require an extra API request to the server, on every article page, even when you're not interested in its talk page. Here's a different approach: open your contributions, filter by article talk pages, and see on which pages your edit was not the last one. Also you could simply use your watchlist. Please also see my note on using Wikipedia:WikiProject User scripts/Requests below. —AlexSm 16:09, 23 April 2008 (UTC)

[edit] Tighter page top tabs in MonoBook

At the Village pump there has been a discussion which lead to the change of the name of the "+" tab to "new section" yesterday. (A talkpage top tab in MonoBook.) The discussion showed that many admins and other users have problems to room all their extra tabs. So I would like to add a gadget with CSS only that makes the tabs tighter. Here is the code I myself currently use:

/* David's tighter page top tabs, v0.4, for MonoBook.
   Change only the second value if several values. */
#p-cactions {
        padding-left: .6em;      /* Outside left of first tab. */
}
#p-cactions li {
        margin: 0 .3em 0 0;      /* Outside of all tabs. */
}
#p-cactions li a {
        padding: 0 .6em .3em;    /* Inside of all tabs. */
}
#p-cactions #ca-addsection a {
        padding: 0 .6em .3em;    /* Inside "+/new section". */
}
#p-cactions li.selected a {
        padding: 0 1em .2em!important;   /* Inside current tab. */
}
/* Extra outside space to distinguish the tab groups. */
li#ca-talk, li#ca-history {
        margin-right: 1.0em;
}
li#ca-watch, li#ca-unwatch, li#ca-varlang-0, li#ca-print {
        margin-left: 1.0em;
}

I can supply code for even tighter tab spacing if that is deemed necessary. But to me it looked a bit ugly to have tighter tabs than that. The code above uses the same narrower spacing for the "+/new section" tab as for the other tabs so I think it looks okay both if the tab is named "+" or "new section". The code works in all three web browsers I have and it does not interfere with other skins.

We could of course have two gadgets:

  • "Tighter page top tabs in MonoBook."
  • "Even tighter page top tabs in MonoBook."

If you want to test the code paste it into your own monobook.css, then refresh your web browser cache, then wait about 20 seconds and then reload some page to see the change.

--David Göthberg (talk) 13:58, 20 April 2008 (UTC)

I do not think that we should add this more or less trivial change as a gadget. It clogs up the preference page and the only users interested in it must already have plenty of code on their monobook.js page. Additionally, it feels a bit too much like a statement for the linked discussion. Also, I have removed this from the gadget definition page as it has not been discussed properly. Сасусlе 00:36, 23 April 2008 (UTC)
Ehm, no, the code I suggest above have never been added to the gadget definition (yet). The gadget definitions you just deleted were other things, among others a very popular fix to add back the "+" tab instead of the "new section" tab on talk pages. And that "+" gadget was not added by me.
--David Göthberg (talk) 00:51, 23 April 2008 (UTC)
Oops, sorry for the confusion. The removed gadgets were addsection-plus and the diff-underlines. I have started new discussions for all of these below. Сасусlе 03:41, 23 April 2008 (UTC)
Is there a rule that additions have to be discussed? I would find that very surprising. It turns out there was indeed a "rule" that changes had to be discussed here. I'm going to boldy remove that bit of bureaucracy. There is no similar rule for any of the numerous more visible Mediawiki pages.
In any case, I can't see that this gadget is going to be particularly controversial, and just adding it and going on with business was reasonable enough. — Carl (CBM · talk) 03:23, 23 April 2008 (UTC)
Yes, Cacycle added that "guideline rule" right after he removed those gadgets today.
Cacycle: Since you have responded similarly to several of these gadgets I have responded to you in a separate section below named Clutters the preference page?.
--David Göthberg (talk) 05:36, 23 April 2008 (UTC)

First, I suspect that most users having problems with 'p-caction' width are those users that added some extra personal tabs. Which means they should have no problems editing their monobook.css. Second, this CSS makes tabs look a bit ugly in IE6. Third, when I tested it, I saw it actually breaking other skins: in Modern the tabs become wider, in Simple the tabs (which are located in SideBar) become misaligned. —AlexSm 15:09, 23 April 2008 (UTC)
And I'm not sure this interfering with other skins is fixable at all. —AlexSm 17:29, 24 April 2008 (UTC)

This doesn't work at all for me. I've got "six tabs" and twinkle, maybe that's why. Equazcion •✗/C • 18:14, 25 Apr 2008 (UTC)

The default tabs, for an administrator using the default settings* on a watchlisted project page with a new section tab, are 908 pixels wide. And the first tab starts at pixel #203. I'm actually considering proposing making the spacing tighter for everyone. It's disingenuous to assume that this is only people who are adding personal tabs that have a problem with this.
*p-cactions computed font size is 16.2px and the actual tab computed font size is 15.333px. computed font family is sans, actual typeface is arial.
This is not a comment on the merits of a particular solution, merely noting that there is a real problem
--Random832 (contribs) 03:58, 28 April 2008 (UTC)

I don't get the "disingenuous" part of your message ... if we make tabs tighter for everyone, this would only prove my point that we didn't need this code as a gadget. —AlexSm 04:23, 28 April 2008 (UTC)
I sometimes use words incorrectly - I looked up "disingenuous" and it doesn't mean what I was trying to get across. --Random832 (contribs) 13:16, 28 April 2008 (UTC)

[edit] Diff underlining or borders

Some days ago the devs added a function to Wikipedia that caused red dotted borders around text that had changed in the diff views. This made it possible to see where spaces had been added or removed and made it much easier to find small changes like changes in punctuation. (Which can be crucial in template coding and sometimes even in article layout.) However, many disliked the red dotted borders so the new function was removed again. But many had good use for it and wanted to keep it. I have coded up three variants of this function that can be added as gadgets so those that want it can easily turn it on:

  • Red dotted borders. Exactly like the original function.
  • Red underlining. Less intrusive but still very clear.
  • Yellow-green underlining. Even less intrusive since the diff view is yellow to the left and green to the right. But still pretty clear. I use this one myself.

These gadgets are based on CSS code only. They need no javascript so they are very compatible and work in all web browsers I have tested them in, including my old Internet Explorer 5.5 from 2001. And it works in all the skins I have tested it in.

Here is the CSS code for the three gadgets:

.diffchange {
    border: 1px dotted #f00;          /* Red dotted border. */
}
 
.diffchange {
    border: none;
    border-bottom: 1px solid #f00;     /* Red underlining. */
}
 
.diffchange {
    border: none;
    border-bottom: 1px solid #6AD500;   /* Yellow-green underlining. */
}

I already added these gadgets today since I thought they were uncontroversial and many had expressed that they liked the red dotted borders etc. But I was reverted by Сасусlе.

--David Göthberg (talk) 04:43, 23 April 2008 (UTC)

I have removed diff_red_underline, diff_yellow-green_underline, and diff_red_dotted_border which have been added today and for which I could not find a previous discussion.
To start the discussion here: I think this is actually very useful, but having three minor design variants is overkill and just clutters the preference page. Сасусlе 03:37, 23 April 2008 (UTC)
Cacycle: Since you have responded similarly to several of these gadgets I have responded to you in a separate section below named Clutters the preference page?.
--David Göthberg (talk) 05:37, 23 April 2008 (UTC)

I think this would be really useful as a gadget. Kaldari (talk) 18:34, 28 April 2008 (UTC)

[edit] Addsection-plus

This is about the gadget that puts back the MediaWiki default "+" to the "new section" talk page top tab. The gadget was created by Random832.

The addsection-plus gadget has been added last weekend [2] without any discussion here (there was a mini-discussion on Village pump (proposals). I have removed the gadget, requesting a discussion here (unfortunately, it has since been added back, again without discussion [3]).

To start the discussion: I think this is a trivial task that should not be added as a gadget as it clogs up the preference page and the only users interested in it must already have plenty of code on their monobook.js page. Сасусlе 03:37, 23 April 2008 (UTC)

I don't really have a lot of active code on my monobook page (at least none that affects the number of tabs I have), but I think that the change is useful for two reasons:
  1. At lower resolutions, space can be a real concern...
  2. There was fairly broad-based support for changing the tab to "new section", but numerous regular editors – including some who favoured the change – expressed a preference for "+" (for reasons ranging from extra space to ease of use) or, in some cases, a strong dislike for "new section".
While this is certainly not a critical change, I feel that it's sufficiently worthwhile. Black Falcon (Talk) 04:04, 23 April 2008 (UTC)
This gadget was discussed and supported in a much more public place than this usually very inactive page. The gadget puts back the well established MediaWiki default "+" to the "new section" talk page top tab. I fully support this gadget.
Cacycle: Since you have responded similarly to several of these gadgets I have responded to you in a separate section below named Clutters the preference page?.
--David Göthberg (talk) 05:39, 23 April 2008 (UTC)
First of all, that Gadget was written by Random832, not me - I noticed it in the discussion leading to the tab text change and enabled it momentarily before I actually changed the tab text, so that users who preferred the original version would have a "personal revert" button, as it were. It greatly decreased opposition to the change, which is good as the change is a usability improvement for newbies. I, among other users, am using it, and I think that it should therefore not be removed. Nihiltres{t.l} 16:55, 23 April 2008 (UTC)

[edit] Alternate idea

Honestly, how many editors past the "autoconfirmed" stage actually use that button? By the time an account is autoconfirmed, I'm fairly certain that they understand how to make a header, and to add to the bottom of a talk page.

So how about not have the preferences, but just have the button "disappear" once an account is autoconfirmed? Sounds like the best of both worlds to me : ) - jc37 06:37, 23 April 2008 (UTC)

No, since some of us have slow computers and/or slow connections. So we don't like to edit the whole page just to add a new section at the bottom. Using the "+/new section" button loads much faster for us. Some talk pages are hideously long.
And it avoids edit conflicts totally. Very nice, especially if you for some reason write English slowly, like not being a native English speaker.
--David Göthberg (talk) 08:35, 23 April 2008 (UTC)
I also find it irritating when people do a section edit of the final section of a talk page to create a new section, and don't fix the default edit summary. Another benefit of the + tab is that the default edit summary is always correct. — Carl (CBM · talk) 12:56, 23 April 2008 (UTC)
Ah, I see. Thanks for the clarification. - jc37 15:58, 23 April 2008 (UTC)

[edit] Clutters the preference page?

Cacycle has today removed several gadgets and several times written similar comments above. So I want to respond to that here in one place.

Cacycle wrote:

It clogs up the preference page and the only users interested in it must already have plenty of code on their monobook.js page.
I think this is actually very useful, but having three minor design variants is overkill and just clutters the preference page.
I think this is a trivial task that should not be added as a gadget as it clogs up the preference page and the only users interested in it must already have plenty of code on their monobook.js page.

But there is no lack of space in the preferences page. If the number of gadgets become many we can add more detailed subsections for more types of gadgets. We can not request that all users learn to handle javascript and CSS code and how to handle their monobook.js and monobook.css pages. Most don't even know about those subpages in their user space. Why should we deny all those users this functionality?

The whole purpose of the gadget system is that we programmers can package functionality in convenient gadgets that less knowledgeable users can choose to enable by just a click in their preferences.

--David Göthberg (talk) 05:30, 23 April 2008 (UTC)

"must already have plenty of code on their monobook.js page." Which is why I recently nuked it and started fresh after some tools stopped working. The gadget options for Twinkle and Friendly are welcome since I don't have to clutter up my monobook.js. If there are gadgets that make the WP experience better, then give us the option. --— Gadget850 (Ed) talk - 11:32, 23 April 2008 (UTC)
I think that we need some more definite ideas of what Gadgets should be. Here are the facts:
  • Gadgets are, effectively, extra preferences; part of the interface.
  • Gadgets can use JavaScript and/or CSS.
  • Gadgets are either enabled or disabled, with only a checkbox.
This leads me to some general conclusions:
  1. Gadgets, as, effectively, part of the interface, must be stable and fail gracefully where applicable.
    1. If a Gadget can be used with its own preferences, it should gracefully change to default preferences when these are not specified.
  2. Gadgets should either be broadly compatible with major Internet browsers, or, if not, follow an official standard (e.g. the font Gadget works only in Safari at present, but uses a web standard recommended by the W3C). Exceptions can be made here as some browsers, like Internet Explorer, can be awful this way. If this is the case, the exception must be made plain to all users and fail gracefully.
  3. Gadgets should bypass the user difficulties in using monobook.js and monobook.css, since not bypassing the manual solutions defeats part of the purpose of the feature: to let technologically-illiterate people easily use advanced features.
  4. No two Gadgets should interfere with each other, and where one Gadget would override another, this should be made plain.
As a general idea, I would support as many Gadgets which fit these criteria to be implemented. We have no space limit, and anything useful is a worthwhile addition. We can use sections and subsections to sort Gadgets into different "categories" and allow users to pick and choose their user experience. Nihiltres{t.l} 17:15, 23 April 2008 (UTC)

I mostly agree with Nihiltres and the existing rules, but I miss a very important consideration: There are hundreds of existing user scripts and many more to be written. While it would be technically possible to add them all as gadgets, we must keep the user preferences interface manageable for normal users. This implies that we have to find criteria for inclusion that are also based on user interest, quality, and usefulness. Please see my comment here. Сасусlе 03:09, 25 April 2008 (UTC)

Forgive me as I haven't read the discussion up until now; but I just wanted to chime in nonetheless. I think gadgets should be limited to those scripts that have proven to be the most widely used. Every little customization doesn't need to be placed there. These are listed in preferences, which means they get seen by everyone as, in a way, "official" functions of Wikipedia, and we should make sure it's a quality listing of features. That means only listing scripts that have been tested extensively, and discussing all additions. This isn't the place to just add something yourself just cause you think everyone would find it useful, without actually discussing it first. Especially, new or unheard-of scripts shouldn't be made gadgets without further testing and discussion. And yes, it should be a rule that new gadgets must first be discussed. This is preferences, the most widely-used "page" on Wikipedia, and it needs to be taken very seriously; it shouldn't change erratically, be subject to wheel-warring, etc. Equazcion •✗/C • 18:12, 25 Apr 2008 (UTC)
Equazcion: The problem here really isn't if gadgets should be discussed first or not. The problem is that Cacycle and AlexSm is trying to enforce that all gadgets should first be suggested and "discussed" here at Wikipedia:Gadget/proposals precisely since this page doesn't get many visitors, since then they can control this area and prevent any new gadgets from being added. It seems they don't like anything that makes their own gadgets become less prominently exposed.
I say any further discussion of which gadgets should be added or not should go on the Wikipedia:Village pump (technical). And I say that any consensus reached on the village pump has to be respected, since that overrules any local "consensus" (usually including only Cacycle and AlexSm) in less visited pages such as these. And this discussion itself probably should be moved to the village pump.
--David Göthberg (talk) 10:32, 26 April 2008 (UTC)
I'd agree there. If it's merely a choice between requiring discussion here vs. a more general place like VP, definitely VP should be the place. This page should be deleted, in that case. Equazcion •✗/C • 15:26, 26 Apr 2008 (UTC)

[edit] Edit button for Infoboxes and Persondata

I would like to suggest a new Gadget to add a plus sign or edit button to to infoboxes and persondata templates. This would allow that infobox or persondata template to be modified more easily than opening up the whole page or section.--Kumioko (talk) 15:35, 23 April 2008 (UTC)

This page is mostly for discussions which existing scripts are to be made as gadgets. I think it would be better to places requests for new scripts at Wikipedia:WikiProject User scripts/Requests, (optionally with announcement on this page). —AlexSm 16:01, 23 April 2008 (UTC)

[edit] Requesting rollback options

While this isn't a "gadget", it's a request for something on the preferences page, and it's something that currently can only be done by js. So this seems as good a page as any.

I'd like 2 options for rollback added to preferences. Users shouldn't have to use javascript for this finctionality.

A checkbox as to whether clicking rollback would open an edit window and prompt for an edit summary, or not.

An "inpuboxline" to input a raw text default summary (similar to the inputbox used for custom signatures).

I (and I presume others) would find these to be very useful. - jc37 17:15, 23 April 2008 (UTC)

Yes, that's what I meant. js isn't an option for some, for one thing. And since rollback is now available on request to most editors, I think that having these two preferences would be comparable to having the preferences for the watchlist or custom signatures (for example). - jc37 17:55, 23 April 2008 (UTC)
From #wikimedia-tech:
[17:56:37] <MrZ-man> brion: what are your thoughts on adding a user preference to prompt for an edit summary when using rollback?
[17:59:19] <brion> MrZ-man: my general thought is that rollback is supposed to have a minimally-invasive ui so you can do things in bulk very quickly
[17:59:31] <brion> and that adding user prefs is evil ;)
[17:59:45] <brion> if you want to leave a summary you can just click the revision, edit, and save
--Mr.Z-man 18:25, 23 April 2008 (UTC)
Which is quite a few more "clicks". I guess it doesn't make sense to me that attempting to foster communication and clarity is more difficult than not.
Also, I'd argue that this would be "higher priority" to be on preferences than more than a bit of the rather lengthy gadgets section (among quite a few others).
That aside, since it's Brion, does this mean that this has no chance whatsoever?
(I prefer to avoid brick walls, whenever possible : ) - jc37 18:57, 23 April 2008 (UTC)

[edit] Anti-vandal tool

Someone has probably said this before, but Lupin's Anti-vandal tool? 79.75.137.77 (talk) 19:15, 24 May 2008 (UTC)

[edit] A few scripts i use

Wikipedia:WikiProject User scripts/Scripts/Six tabs -- Very simple, is useful. User:Alex Smotrov/histcomb.js -- Combines a users group of edits to a page when looking at the history

would there be any objections to implementing these two scripts as gadgets? The Placebo Effect (talk) How's my editing? Please contribute to my editor review. 16:40, 27 May 2008 (UTC)

[edit] Transparent skin

Cobi has created a new stylesheet, that gives a sorta "transparent" look to MonoBook. I am using it right now, and all that you need to put into a gadget is something like this:

if (navigator.appName != "Microsoft Internet Explorer")
 {
     importStylesheet('User:Cobi/transparent.css');
 }

What do people think about this? Feel free to shoot it down, it would still be a nice thing to add to gadgets. Soxred 93 20:57, 27 May 2008 (UTC)

[edit] Gadget to move the section edit links right next to the headings

I think there should be a gadget to move the section edit links right next to the headings as they are in the German Wikipedia. It makes it easier to navigate by headings for screen reader users, as the word "Edit" is spoken after the section name instead of before it. It is in my Monobook.js for that reason. Some sighted users must like it too because it has been added to a few projects such as the German Wikipedia and the English Wikiversity. The code is as follows:

//== Change section heading links ==//
 
 // ============================================================
 // BEGIN Moving of the editsection links
 
 /*
 * moveEditsection
 * Dieses Script verschiebt die [Bearbeiten]-Buttons vom rechten Fensterrand
 * direkt rechts neben die jeweiligen Überschriften.
 * This script moves the [edit]-buttons from the right border of the window
 * directly right next to the corresponding headings.
 *
 * Zum Abschalten die folgende Zeile (ohne führendes Sternchen) in die eigene
 * monobook.js (zu finden unter [[Special:Mypage/monobook.js|Benutzer:Name/monobook.js]]) kopieren:
 * var oldEditsectionLinks = true;
 *
 * dbenzhuser (de:Benutzer:Dbenzhuser)
 */
 function moveEditsection() {
     if (typeof oldEditsectionLinks == 'undefined' || oldEditsectionLinks == false) {
         var spans = document.getElementsByTagName("span");
         for(var i = 0; i < spans.length; i++) {
             if(spans[i].className == "editsection") {
                 spans[i].style.fontSize = "x-small";
                 spans[i].style.fontWeight = "normal";
                 spans[i].style.cssFloat = "none";
                 spans[i].style.marginLeft = "0px";
                 spans[i].parentNode.appendChild(document.createTextNode(" "));
                 spans[i].parentNode.appendChild(spans[i]);
             }
         }
     }
 }
 // onload
 addOnloadHook(moveEditsection);
 
 // END Moving of the editsection links
 // ============================================================

Is there any reason not to add this as a gadget? Graham87 09:03, 28 May 2008 (UTC)

This is a very good idea, thank you. I would like to have this functionality in all Mediawiki Wikis and hope, there is no reason against it. This would be a huge improvement for the usability experience of blind screen reader users. -- Lalue (talk) 11:08, 28 May 2008 (UTC)
Wouldn't CSS be more appropriate than JavaScript for this gadget? —Remember the dot (talk) 01:26, 29 May 2008 (UTC)
Sounds like an excellent idea to me. Is there any reason not to go the way of the German Wikipedia (which, thanks apparently to Lalue here, seems to have a better grasp on accessibility than us) and just incorporate it into the software? I actually think it looks much more streamlined that way. L'Aquatique[talk] 15:49, 1 June 2008 (UTC)
  • sounds good to me. Jeepday (talk) 15:56, 1 June 2008 (UTC)
Please could somebody check that if there is a way to move the edit link to the right while keeping the screenreader order. If so, then this should become part of the software/skin, not a gadget. Also, it might not be compatible with other gadgets (such as the first paragraph edit link). Otherwise, it is fine to have this accessibility gadget.Cacycle (talk) 13:17, 2 June 2008 (UTC)
Actually, see bug 11555 for more information about this. The edit link shouldn't even be part of the heading, and that's the way it was before October 2006. This is just a temporary solution for screen reader users until the bug gets fixed, which should happen relatively soon because it's marked as an accessibility bug. Graham87 14:07, 2 June 2008 (UTC)
Fixing the bug would be the best solution, especially for the masses of blind readers without an account. Because nobody knows when this problem could be fixed, a gadget would be a solution for the remaining time. Although it's an accessibility bug, we perhaps have to wait for a long time for a fix. Brion and his team have lots of other things to do. @L'Aquatique: I was not the person who made or inspired this improvement at the German Wikipedia, I just noticed the difference between the German Wikipedia and all other Mediawiki based Wikis and after that I informed my partners from our accessibility project about the issue and user Revolus extracted the JS-snippet from an already existing JS-modification. Best, Lalue (talk) 10:23, 3 June 2008 (UTC)
Languages