Youtube

Go to The Main Page Add Youtube to favorite!

Wikipedia:Village pump (technical) 

Village pumps: Policy • Technical • Proposals (persistent) • Miscellaneous
Skip to: Table of contents | First discussion | Bottom of page
Village pump technical   post
The technical section of the village pump is used to discuss technical issues about Wikipedia. Bugs and feature requests should be made at the BugZilla because there is no guarantee developers will read this page. Problems with user scripts should not be reported here, but rather to their developers (unless the bug needs immediate attention).

Newcomers to the technical village pump are encouraged to read these guidelines prior to posting here. Questions about MediaWiki in general should be posted at the MediaWiki support desk.
Shortcuts:
WP:VPT
WP:VP/T
? Frequently Asked Questions (FAQ) (see also: Wikipedia:Technical FAQ)
Click "[show]" to the right of each point to see more details.
You appear to be using an outdated version of the Internet Explorer web browser. Because of this, you may experience long page load times and possibly other bugs. Please consider upgrading to Internet Explorer 7 or using a different browser, such as Firefox, Safari, or Opera. All of these programs can be downloaded free of charge.
If you have problems making your fancy signature work, check Wikipedia:How to fix your signature.
If the section edit links are being pushed down by floated images, check Wikipedia:How to fix bunched-up edit links.
Numbers listed in parentheses in the "Recent changes" section and in your watchlist are the number of added or removed bytes.
Questions and suggestions related to www.wikipedia.org portal should go to Meta.
Please sign and date your post (by typing ~~~~ or clicking the signature icon in the edit toolbar). Please add new topics to the bottom of this page.

« Older discussions | Archives: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46

Contents

MediaWiki:Sp-contributions-footer

Would there be any objections if I were to create this particular MediaWiki: page? Examples of its use can be seen on Meta and Wikisource (see bottom of here and here) —Anonymous DissidentTalk 08:56, 10 August 2008 (UTC)

I want it I want it I want it!! Happy‑melon 20:43, 10 August 2008 (UTC)
YES! Interestingly enough I was just thinking about this too after my recent editing on WB. - Icewedge (talk) 07:25, 11 August 2008 (UTC)
Nicely done. :) Is there a particular reason MediaWiki:Sp-contributions-footer and MediaWiki:Sp-contributions-footer-anon use different images and css attributes? In particular, Image:Wikipedia-logo.svg (38px) and Image:Information.svg (40px)... and the tables themselves seem to render with slightly different widths, on my browser. I favor consistency, but have no particular preference regarding which style we keep. – Luna Santin (talk) 10:07, 11 August 2008 (UTC)
Luna Santin: You are right. I'll update both to use our standard MediaWiki message box styles, thus they will look like the MediaWiki:Sharedupload. With 100% width, standard light grey background and so on.
I have coded up examples in my user space at User:Davidgothberg/Test30. I don't know which image to choose. I am leaning towards the Wikipedia logo (it looks good), or the icon tools image (since it says more about what content the boxes have).
Note! In my examples I also suggest a slight change in the MediaWiki:Sharedupload box. (The "This is a file from the Wikimedia Commons" box.)
--David Göthberg (talk) 22:49, 11 August 2008 (UTC)
Interesting. I definitely appreciate the consistency. As far as images, I believe I would personally favor Image:Information.svg or Image:Icon tools.png (though I believe you mentioned you liked Image:Imbox notice.png previously, which is also fine with me) -- they hint nicely as to the box's contents, as you said. – Luna Santin (talk) 09:09, 12 August 2008 (UTC)
Based on the two of us it seems the Image:Icon tools.png is the choice. But I think we need some more users to look at this. So please, can more people take a look at User:Davidgothberg/Test30 and comment here?
--David Göthberg (talk) 06:25, 13 August 2008 (UTC)
I also prefer this icon; it matches the purpose of the links much better. I'd certainly prefer not to see the Wikipedia logo. Waltham, The Duke of 12:20, 15 August 2008 (UTC)

Is there any way I can add the template to the bottom of my user page? Thanks! SharkD (talk) 22:12, 18 August 2008 (UTC)

SharkD: I see that you answered yourself by making the template {{sp-contributions-footer}}.
Everyone: I think I have found a much better image to use for these boxes: Image:User-info.svg
Perhaps we should use a more colourful version of that image, but you get the idea. But these boxes are interface messages so perhaps it is good that the image looks a bit neutral. See my example boxes at User:Davidgothberg/Test30 to see how it looks in the boxes.
--David Göthberg (talk) 08:21, 19 August 2008 (UTC)
I really think that "IP user" should be substituted for the three places that "anonymous user" appears, as everyone should know that most user names are far more anonymous than IP addresses. 199.125.109.90 (talk) 17:14, 21 August 2008 (UTC)
Yes, I agree with the IP user 199.125.109.90, it is time we get rid of the misnomer "anonymous user" for the not logged in users.
--David Göthberg (talk) 17:48, 21 August 2008 (UTC)
The term "IP user" is terrible. It's incomprehensible jargon to practically anyone on the planet. Call them "unregistered users". —Simetrical (talk • contribs) 15:19, 22 August 2008 (UTC)
Not specific enough. IP user is fine, and it is well explained. It's not something that would ever be used out of context. I know I would much rather be referred to as an IP user than as an un-something. 199.125.109.64 (talk) 15:40, 22 August 2008 (UTC)
IP user is not "well explained". It's incomprehensible unless you happen to be one of the tiny technical elite who knows what an IP address is, and even then it's incomprehensible unless you realize that MediaWiki names unregistered users by IP address (which is unheard of for web software). —Simetrical (talk • contribs) 02:15, 24 August 2008 (UTC)
I like the new image; I don't mind the discreet blue colour (actually, I think I like it), and I agree that the image should look neutral. In the sandbox I notice two additional new suggestions... As I've said, I prefer this icon to one with more colour (in this case, the one wearing a red tie). As far as the black one is concerned, I get the meaning ("shady" members), but I don't think it will be appreciated much, and it stands out too much anyway.
Although I might consider it if it were stroking a white Persian cat. Waltham, The Duke of 22:16, 22 August 2008 (UTC)
As most of you probably have already noticed: I have changed to the "user info" image I show above for all the related MediaWiki messages.
Waltham: Yeah, the black one looks scary. I bet some would like it for IP users! :)) The two coloured images were the only related ready made ones I could find on Commons. I have tried with softer green versions on my own computer, but didn't upload them since they didn't look as good as the grey-blue one we are using now.
Simetrical and 199.125.109.64: Both "IP user" and "unregistered user" sounds right to me. Both are way better than "anonymous user". I think we need input from more users to decide which one is best. So people, which do you prefer: "IP user" or "unregistered user" or something else?
--David Göthberg (talk) 11:15, 23 August 2008 (UTC)
I prefer IP user as it is both shorted and as 199.125.109.64 (I think) pointed out, unregistered could be seen as negative. —Atyndall citation needed 11:17, 24 August 2008 (UTC)
I am being pedantic about semantics, but maybe use "editor" rather than "user". All editors are users, but not all users are editors (some are just readers), and there is no purpose in having "IP user contributions" for IP readers-only. — Twas Now ( talk • contribs • e-mail ) 11:39, 24 August 2008 (UTC)
Twas Now has a point there. Here are the first sentence of the message with the different namings. Version 0 being the old message:
0: This is the contributions page for an anonymous user, identified by the user's numerical IP address.
1: This is the contributions page for an IP user, identified by the user's numerical IP address.
2: This is the contributions page for an unregistered user, identified by the user's numerical IP address.
3: This is the contributions page for an IP editor, identified by the editor's numerical IP address.
4: This is the contributions page for an unregistered editor, identified by the editor's numerical IP address.
I think I prefer versions 1 and 2, but I am okay with 3 and 4 too. To me "user" sounds more friendly and welcoming than "editor". By the way, since these footer boxes are very visible I think that the naming we use in them is likely to become the standard naming we use here at Wikipedia.
--David Göthberg (talk) 15:48, 24 August 2008 (UTC)
I have no preference, but I'd like to make two observations:
  • IP user/editor is more educational, as it makes the connection with IP address and shows the Wikipedian in question what an IP user/editor is without having to be a nerd or read any help pages.
  • As far as Twas Now's point is concerned, he is right in that only those IP addresses with edits are relevant here, so it makes no sense to refer to plain readers in the toolbox. Furthermore, I think we can say that editor is a title automatically bestowed on anyone who's made an edit, not least because the two words are obviously related.
    • On the other hand, since only those who have made edits will have a contributions page (where the toolbox at the bottom appears), the IP user in question cannot be a plain reader anyway. The "this is the contributions page of an IP/anonymous user" message would only appear for editors, who do belong to the category of IP users.
Full circle. :-) Waltham, The Duke of 13:04, 25 August 2008 (UTC)
So glad Version 0 is getting looked at. I much prefer "IP editor" to any other option."Hey look, you're already an editor. One of us. One of us". Seriously, it is much more personal, friendly and instructive than "IP user" (my second choice). Hopefully affording us the title will rub off on both IPs and those registered. Dream the dream. 86.44.24.10 (talk) 02:32, 29 August 2008 (UTC) is pimping his sidebar proposal
User is standard terminology on Wikipedia. Note: User:Dream, User:Duke, User:David. If Wikipedia had been using Editor:The Duke of Waltham then IP editor would be appropriate. Since WP uses User:The Duke of Waltham, then it should be IP user for consistency. 199.125.109.96 (talk) 06:31, 2 September 2008 (UTC)
Good point. Considering this, and Mr Göthberg's view, I think I'll also choose user over editor; I still agree with Twas Now's view, but I have already mentioned that I don't find it very relevant.
Additional benefit of IP user: it is the shortest available option (not a factor I considered in my choice, though).
Having said that, I believe we have consensus on the IP part. Waltham, The Duke of 15:27, 4 September 2008 (UTC)
I agree, 199.125.109.96 has a very good point when he points to that user pages are named "User:". Previously I only had a slight preference for "user" over "editor", but now my preference is much stronger. And yeah, it seems most of us prefer "IP" over "unregistered" (darn that is hard to spell!).
Waltham: Right, "IP user" is the shortest term we have that still is clear. And I believe that is a bigger benefit than you might think. Since when Wikipedians discuss things on talk pages they tend to use as short forms as possible. (They are way too lazy for their own good!) So it is good if we standardise around a short but still clear form, thus the same form can be used all over the place (including in documentation) and thus causing less confusion. So on talk pages using "IP user" is much better than the current all too common short form "anons".
--David Göthberg (talk) 12:14, 5 September 2008 (UTC)

Advanced search is hard to find

I did not notice right away, but advanced search is at the bottom of the regular sidebar search results. Could a link to "advanced search" be put in the sidebar of all pages?

Or at the very least, at the TOP of the regular sidebar search results too, and not just at the bottom. --Timeshifter (talk) 23:05, 24 August 2008 (UTC)

Hitting the "Search" button (next to the "Go" button) takes you to that page; a link already is on every page. EVula // talk // ☯ // 13:29, 25 August 2008 (UTC)
Thanks, but very few people know that, I believe. I have been editing Wikipedia almost 3 years and have over 14,000 edits and did not know that until now. I have always entered a search term or phrase and then clicked either button. I don't remember clicking either the "go" or the "search" button without entering search terms. Or it was so rare that I did not remember where it sent me too.
Most of the time I use the Google toolbar to search the Wikipedia site anyway: the "Search only the current Web site" button. I would have liked to have used the advanced search more since there is more specificity in what it can search for in some cases. But I disliked the extra steps I had to take to hunt up the bookmark. So this is good to know. Many other people would probably like to know this.
No offense, but nerds who work a lot in an area (for example the Wikipedia sidebar and interface), tend to lose sight of how others perceive that area. They don't realize how unintuitive some things are. I have my areas I focus on in nerdlike fashion, and fresh perspectives have been very helpful at times. --Timeshifter (talk) 16:38, 25 August 2008 (UTC)
  • Just to say I second the suggestion to add a Special:Search link somewhere in the sidebar ("toolbox", I guess). Sardanaphalus (talk) 21:18, 25 August 2008 (UTC)
Yes, good idea to put it in the "toolbox" section of the sidebar of wikipedia pages. I hope it is named "Advanced search" since that is a search tool name people are familiar with. So the link could be in this form: Advanced search. That is also the name used on the submit button on that search page. --Timeshifter (talk) 21:45, 25 August 2008 (UTC)
Yes, I too would like an Advanced search link in the toolbox since I want to be able to right click it and choose "Open link in new tab", and I can't do that with the [Search] button.
--David Göthberg (talk) 00:42, 26 August 2008 (UTC)
If this doesn't get implemented generally, anyone who wants it can easily do it with personal javascript. Algebraist 01:39, 26 August 2008 (UTC)
If whatever you search for doesn't exist, the "Advanced search" thing is at the bottom of the search results page. Mr.Z-man 01:47, 26 August 2008 (UTC)
Yes, the OP said that in his first sentence. The issue is whether it should be more visible. Algebraist 01:49, 26 August 2008 (UTC)

Best solution would be to make the word "search" (above the search box) link to Special:Search rather than adding it to the bullet list. — CharlotteWebb 17:54, 26 August 2008 (UTC)

Hmm. I was wondering why there were 2 buttons, one labeled "Go" and one labeled "Search". I think one of them could be removed. Then a simple link labeled "Advanced search" could be put in its place. A link, not a button. A link can be right-clicked as David Göthberg suggested, and the advanced search page can be opened up in a new tab. I dislike having to open it over the original existing page. That wastes bandwidth and time if I have to go back to the original page. --Timeshifter (talk) 18:18, 26 August 2008 (UTC)

They serve different purposes. "Go" (a.k.a. "I'm feeling lucky") loads a page with a title exactly matching your input, if one exists, and "Search" will give you a list of pages containing text similar to your input. I'm just suggesting that we change the text above the sarch box from:

<h5><label for="searchInput">Search</label></h5>

to

<h5><label for="searchInput"><a href="Special:Search.html" title="Advanced search">Search</a></label></h5>

— CharlotteWebb 18:55, 26 August 2008 (UTC)

OK. That would work. Not sure that everyone will understand that the box below the link is not for advanced search though. But this idea of putting the "Advanced search" link just above the search box is much better than before. --Timeshifter (talk) 01:28, 27 August 2008 (UTC)
Oh dear no! The Wikipedia:Manual of Style explicitly states that section headings in articles "should not normally contain links", since most editors think that is ugly. So please don't link the box headings in the interface. Also, renaming that box heading to "Advanced search" would be misleading about the box content, and not renaming it would be misleading about what the link means.
The advanced search is mostly for us editors who want to search other name spaces. (Well, and for experienced readers who want to right click and open a new tab.) So put the link in the toolbox. There are plenty of vertical space in our sidebar, since most pages are far longer than the boxes in the sidebar. (And I have a very slow computer but loading and rendering some extra text is no problem, so it's not a performance issue either.)
And keep both the [Go] and [Search] buttons. They are both useful and I have seen my non-geek friends use them and understand them without problems.
--David Göthberg (talk) 12:45, 27 August 2008 (UTC)
I can only hope your appeal to the MOS is a sarcastic one. — CharlotteWebb 15:26, 28 August 2008 (UTC)
OK. Maybe if the "Advanced search" link was put at the top of the "interaction" section then it would be close enough to the search box to be noticed right away by people who want to do a search. Or better yet, put the link at the bottom of the search box below the "go" and "search" buttons. --Timeshifter (talk) 16:40, 28 August 2008 (UTC)
CharlotteWebb: No, I don't use sarcasm. I know the MOS doesn't apply to anything but articles. But it is still a good reference for what many Wikipedians think is good style.
Timeshifter: You got a point that it would be nice if the Advanced search link is put somewhere close to the search buttons. I tried it in my image editor and it doesn't look that good in the search box (below the search buttons). So I suggest either at the top of the "interaction" menu, or perhaps more fitting at the bottom of the "navigation" menu. (And adding it to any of those two menus is just a simple edit to MediaWiki:Sidebar, while adding it to the search box is probably more complex.)
--David Göthberg (talk) 19:24, 29 August 2008 (UTC)
The sole commonality is the coincidental use of a <h[number]> html tag for each, so comparisons are tenuous at best. — CharlotteWebb 16:02, 30 August 2008 (UTC)
Yes, the bottom of the navigation menu sounds good. Search is definitely a navigation tool. And the "Advanced search" link would be directly adjacent to the search box. I have another problem. When I enter a search term into the search box the popup suggestion box that drops down covers the "go" and "search" buttons. This makes it almost impossible to actually do a search! So putting the "advanced search" link above the search box is better. This allows people to go some place where they can do a less-encumbered search. --Timeshifter (talk) 02:45, 1 September 2008 (UTC)
Timeshifter: When you type in a word and don't want to do an actual search instead of just clicking one of the alternatives that pop up in the drop-down list, then all you have to do is to click anywhere outside the box (on the page) to close the drop-down list, then you can click "Search". The word you typed will still be in the text field.
Everyone: It seems most of us want to have a link to Advanced search in the sidebar, and that some of us think the best place is at the bottom in the "navigation" menu. So I will add it there now.
--David Göthberg (talk) 03:49, 1 September 2008 (UTC)
Thanks! SharkD (talk) 03:51, 1 September 2008 (UTC)
Y Done - The Advanced search is now in the "navigation" menu in the sidebar. If you don't see it on a page you visit and feel impatient then you can purge the page. About a week from now all pages will have timed out in the cache and will have re-rendered and then everyone (including IP users) will see the Advanced search link on all pages.
--David Göthberg (talk) 04:17, 1 September 2008 (UTC)
Thanks! I see it. Is there a way to make the dropdown menu (the one with search suggestions) open up so that it doesn't cover up the "go" and "search" buttons. Maybe make it open up a little to the right? Also, could the search results for regular searches open up in a new tab? --Timeshifter (talk) 07:00, 1 September 2008 (UTC)
Is there a way to add hotlinks for some of the more advanced function, like there is on edit pages? Or, at least provide a short key/legend? SharkD (talk) 04:13, 1 September 2008 (UTC)
Which advanced functions? —AlexSm 04:21, 1 September 2008 (UTC)

I have to say I oppose this addition. So far I saw two arguments:

  1. some users never find advanced search fieldset. Solution: add a jumping-down [[#powersearch]] shortcut to MediaWiki:Searchresulttext which is displayed above search result
  2. some users need a direct link to advanced search. Solution: a bookmark in your browser.

By the way, a little tip: if you want to search in one particular namespace, just type it as a prefix, e.g. typing "wp:apple" and clicking "Search" will look for "apple" in "Wikipedia:" namespace. —AlexSm 04:21, 1 September 2008 (UTC)

SharkD: I don't know what you meant by "hotlinks". But do you mean that on the Special:Search page you want to add some more explanations how it works? I looked around and there is at least the MediaWiki:Searchresulttext which seems to be the message that is placed at the top of Special:Search, so seems we can add more text easily.
--David Göthberg (talk) 04:32, 1 September 2008 (UTC)
Maybe the question was about insertable characters (aka edittools)? Certainly possible as a gadget. —AlexSm 04:39, 1 September 2008 (UTC)
AlexSm: Your first suggestion above is good. I checked the rendered page code and there is an id at the advanced search box at the bottom of the page, so yes, we can add an anchor link from the message at the top of the page.
Your second suggestion does not help people who read or edit from public computers. And does not help people who don't know the link Special:Search in the first place.
Your third suggestion does not help the millions of people who don't read this Village pump page.
--David Göthberg (talk) 04:52, 1 September 2008 (UTC)
Yes, I want more of an explanation of how it works on the search page itself (a terse cheat-sheet with examples should suffice). And possibly the insertable characters like can be found on the edit pages. SharkD (talk) 05:08, 1 September 2008 (UTC)

Benefit to readers?

I don't see the benefit to non-editors. The only people who really care about namespaces other than the main namespace are editors. If I was a casual reader and saw "advanced search", I would assume it was actually more advanced than the normal search in a way that actually matters to me. It's not. --- RockMFR 23:18, 2 September 2008 (UTC)

I tend to agree, the "Advanced search" isn't really useful for non-editors. In fact, calling it "Advanced search" at all is somewhat misleading. All it does is search namespaces that aren't the default one, or what you have set in your preferences, other than that its the same search, it really doesn't give any advanced options like Yahoo's or Bugzilla's. The only real advanced options (Boolean search and category intersections) are available via the normal interface. Mr.Z-man 23:34, 2 September 2008 (UTC)
The most beneficial feature for readers is the ability to search Wikipedia using Google. Algebraist 23:37, 2 September 2008 (UTC)
I dislike the addition too. It doesn't seem special enough for its new shiny home. Ian¹³/t 15:57, 3 September 2008 (UTC)
Have you guys noticed that the Special:Search has a drop down box where you can choose to do a Wikipedia site search with Google, Yahoo, Windows Live, Wikiwix and Exalead? And there is much more to Special:Search than most people know, read all about it at Wikipedia:Searching. What that page currently lacks is some added explanations of all the advanced options there really is. Anyway, since the advanced search at the moment does not come with a proper explanation then you guys are right that it is mostly useful for our editors.
So, how would you guys feel about if we only added the Advanced search link for logged in users? (Disregarding the fact that many of our editors edit as IP users.)
--David Göthberg (talk) 12:27, 5 September 2008 (UTC)
Just because some people don't see a use for advanced search is not a reason to remove it for those of us who see a use for it. Many people will use it to search talk pages, or images, or help, or categories. A very big benefit is that it allows people to right-click the link and open a search page in a new tab. Many, many people will use it just for that reason alone. Especially dial-up users who do not have the time and bandwidth to use the regular search. Regular search opens up in the same page, and one has to use the back arrow and reload the page to go back to the page. Over time many more people will use Wikipedia's search tools if there is an advanced search link. If you don't like calling it "advanced" then just use the name "search". The point is to make it easier to use search. Right now it is very difficult for many people for the reasons I discussed earlier. And how can people navigate the site best without search? So the search link belongs in the navigation section of the sidebar. --Timeshifter (talk) 02:26, 6 September 2008 (UTC)
Timeshifter explains it very well. And using a less strong title for the link is probably a good idea. But to differentiate it from the "search" heading I suggest we call it for instance Extended search. That is not as a strong name as "Advanced search".
--David Göthberg (talk) 14:10, 6 September 2008 (UTC)
Maybe, since the WP:Manual of Style does not apply to the sidebar we can go ahead and make "search" clickable. This way we are not adding more text or more length to the sidebar. I read all the relevant guidelines at WP:MOSHEAD and WP:ACCESS#Links and none of it applies to making the search heading clickable in the sidebar. --Timeshifter (talk) 19:21, 6 September 2008 (UTC)

Proper consensus?

I don't really think there is much use for it either, and I'd to get some kind of consensus from a wider audience. Per above, it seems only useful to editors who need to search for something they've lost in the Wikipedia namespace and such, not much use to the majority of our visitors. If we could have some discussion of what the community actually thinks of this, that would be perfect. Byeitical (talk · contribs) 16:02, 3 September 2008 (UTC)

Proposal: add "my sandbox" link to top navbar

I propose that a "my sandbox" link be added to the top navbar, in between "my talk" and "my preferences". This might encourage users to work on articles in their sandbox before moving them to article space. SharkD (talk) 04:52, 28 August 2008 (UTC)

Perhaps a Gadget? --MZMcBride (talk) 06:11, 28 August 2008 (UTC)
Yes, that would work too. Still, I'd like it if it were considered for all registered users. SharkD (talk) 06:14, 28 August 2008 (UTC)
This would be a very good feature for all users. I like the placement of the link that SharkD suggests, between "my talk" and "my preferences". And I like the suggested name "my sandbox".
It should not be a gadget since this is exactly for the kind of users who still probably have no idea what a gadget is. Instead we can make a gadget to turn off the link for those who don't want/need it anymore.
We should probably make it so the sandbox link isn't red. (For instance by using my sandbox instead of my sandbox.)
What page name should the sandbox have?
That is, upper or lower case first character? And should we name it "/Test1" to make it clear that one can make more test pages? (When I tell people to "Please try it in your own user space first" then I link them to Special:Mypage/Test1.) On the other hand, that "/Test1" link kind of gets wrong once one has more test pages, so simply "/sandbox" is perhaps more timeless? For "/Test1" I have a slight preference for upper case. While for "/sandbox" I have a slight preference for lower case since that is our standard naming for template sandboxes.
This feature could also be good for IP users. But we perhaps need to think a bit about where the IP user's sandbox should be placed.
--David Göthberg (talk) 11:59, 28 August 2008 (UTC)
Perhaps IP users should just be pointed to THE sandbox with logged-in users pointed to their own?
—Preceding unsigned comment added by Clubjuggle (talk • contribs) 12:23, 28 August 2008
I agree with Sharks' original proposal and second Clubjuggle's IP suggestion - X201 (talk) 12:43, 28 August 2008 (UTC)
I agree with directing IPs to THE sandbox. I disagree with David Göthberg in that I don't think that the links need to be forced into blue links. Both the user and user talk pages start out as red links for newly-joined users until they actually get around to creating these pages. The same can be true for user sandboxes. SharkD (talk) 13:56, 28 August 2008 (UTC)
I think /Sandbox (upper case) would be fine. A custom message could appear there when starting the page describing how to create multiple (and sub-hierarchical) sandboxes, kind of how a custom message appears before creating any other aritcle. SharkD (talk) 14:02, 28 August 2008 (UTC)
There are some of us who have multiple sandboxes or other subpages. I have a couple of pages of notes for articles I want to create or develop, and several I use to test templates or tables. --—— Gadget850 (Ed) talk - 12:55, 28 August 2008 (UTC)
Gadget850: Well, there's nothing preventing you from having more sandboxes, and even from putting a link list on your "my sandbox" page to your other sandboxes and test pages. :)
Everyone: Linking IP users to Wikipedia:Sandbox might be a slight problem. Since already now that sandbox gets so frequently edited that I think those poor newbies must get edit conflicts all the time. But since we probably will be adding the "sandbox" link using javascript, then we can make it so it points to many different sandboxes. For instance we could have say 32 different sandboxes. (And we can increase that later if needed.) But we shouldn't choose the sandbox randomly, since the same user will expect to see the same sandbox the next time he/she visits it. So we could use the first byte in the user's IP address to choose which sandbox to use. That means the same user will usually see the same sandbox even when he visits some time later, since usually only the lower bytes in the IP address changes between sessions. I think that should be a no-brainer for our javascript coders to fix.
--David Göthberg (talk) 13:11, 28 August 2008 (UTC)
Take a look at my sandbox page: User:SharkD/Sandbox. It serves more as a directory for all my other sandbox pages, which are stored as sub-pages under the main sandbox page. SharkD (talk) 13:59, 28 August 2008 (UTC)

Where are we going to put the sandbox link for IPs? Algebraist 13:13, 28 August 2008 (UTC)

The link could go in the same place, but direct to the wiki sandbox. SharkD (talk) 13:59, 28 August 2008 (UTC)

Simple JS implementation:

addOnloadHook(function () {
    addPortletLink('p-personal', wgArticlePath.replace("$1", "Special:Mypage/Sandbox"), 'My sandbox', 'pt-sandbox', 'Your personal sandbox', null, document.getElementById('pt-preferences'));
});

Of course, if we added it to the sidebar instead, we could do it without JavaScript. —Ilmari Karonen (talk) 14:15, 28 August 2008 (UTC)

I think it would be great to have a "my sandbox" or (for (IP editors) a "sandbox" link on the navbar. I don't think it's so critical to explain to editors how to create multiple subpages; I'd much prefer the message box that shows up (when someone clicks on the red link) to simply explain that this is a personal subpage for testing of editing, with a link to WP:SUB for those who might be interested. But that's just details to be worked out later; the core concept seems really good.
As for IP editors, having their "sandbox" link go to one of 100+ sandboxes, depending on the first block in the IP address, has pluses and minuses. On the plus side, it minimizes edit conflicts that occur when lots of people are editing the standard sandbox simultaneously; on the minus side, it means that the bot or bots doing the cleanup need to cover 100+ pages. But again, I think this is a secondary issue; it would be great to be able to tell IP editors to just click the "sandbox" link at the top of their screen rather than provide them with a link to WP:SAND, and I think there is a reasonable chance that we'd have fewer "test" edits on real pages if there was a "sandbox" link visible at the top of screens. And maybe we'd even get a few more people to realize that they can edit Wikipedia. (On a lot of other wikis, if you click the "edit" tab, you just get a message saying that you have to log in first to edit.) -- John Broughton (♫♫) 21:06, 28 August 2008 (UTC)
John Broughton: Right, the IP user sandboxes needs to be cleaned regularly by a bot, just like the current Wikipedia:Sandbox. And I can imagine there are cases when an admin has to delete the sandbox to get rid of especially nasty stuff from the edit history of the sandbox. And that was why I suggested using a fairly low number of such sandboxes. And by the way, I suggest naming them Wikipedia:Sandbox1 and so on.
Ilmari Karonen: Right, we could put the link in the sidebar. Although I think this is an important enough feature that it should probably be put on the navbar at the top of the page. (SharkD's original suggestion above.)
Ilmari and our other javascript experts: Does javascript have access to the IP user's name or IP number so we can use it to pick which sandbox to send the IP user?
--David Göthberg (talk) 18:38, 29 August 2008 (UTC)
Special:Mypage/sandbox seems to work just fine for anon users (lower case is better IMHO, in the same form as skinname.css/js) --Splarka (rant) 08:04, 30 August 2008 (UTC)
@David Göthberg: JavaScript has no way of finding a user's IP address alone - one has to use server-side code (i.e. PHP) or (ugh) a Java applet. x42bn6 Talk Mess 04:09, 31 August 2008 (UTC)
Splarka: Yes, Special:Mypage/sandbox works for IP users too. But that would mean after a year or so we would have perhaps a million IP user sandboxes, some of which might hold pretty nasty content. And some search engines do index all pages on Wikipedia...
x42bn6: Ouch, seems you are right. I checked around, the "wgUserName" javascript variable is only filled in for logged in users. And since those variables are set in the rendered page header it would probably destroy the squid caching if the user name (IP number) of IP users were set in the page header. So for now it seems our best option is to direct the "sandbox" link for IP users to Wikipedia:Sandbox.
For the logged in users I prefer we use lower case "/sandbox" for the "my sandbox" link. Since as Splarka mentioned above, we already use lower case for the user's own monobook.js and monobook.css. And we use lower case for the now standardised subpages for templates such as "/doc", "/sandbox" and "/testcases".
Then after some weeks if people like these things then I suggest we request the making of a special page named Special:Sandbox that links to Special:Mypage/sandbox for logged in users and to a numbered public sandbox for IP users. But let's leave that aside for now.
Since all comments above have been so positive I think we can declare a consensus to do this. The only thing that remains is to decide on upper case or lower case "/Sandbox" or "/sandbox". (Sorry to be picky about this, but we can not change that spelling later since then a lot of users will have a problem to find their old /sandbox.)
--David Göthberg (talk) 15:28, 31 August 2008 (UTC)
I am not even a javascript programmer, but I have figured out how we can do the numbered sandboxes for the IP users: When a new user visits we can randomly assign one of the numbered sandboxes, and then store the result in a javascript cookie. Then if the user comes back an hour later we can assign the same sandbox to that user. Of course, if the user has set his browser to clear cookies between sessions then he gets assigned a new sandbox. But at least the user will see the same sandbox in all open windows during the same browser session, which is more important than seeing the same sandbox some hours later. It seems simple enough that I could cut and paste some cookie examples I found on the web to do it. But to not break anything I should probably leave that to our javascript experts.
But I'll deploy a simpler code at MediaWiki:Common.js first. See the code I am showing at MediaWiki talk:Common.js#"My sandbox" link for the personal tools menu.
--David Göthberg (talk) 20:25, 1 September 2008 (UTC)
Sounds good. SharkD (talk) 06:02, 2 September 2008 (UTC)
This suggestion has met resistance over at MediaWiki talk:Common.js.
--David Göthberg (talk) 13:07, 5 September 2008 (UTC)

Excluding editors unlikely to vandalize from filtered recent changes

I often use Lupin's anti-vandalism tool to scroll recent changes for vandalism. The tool works great, but the feed is cluttered with perfectly legitimate edits and vandalism reversions that get caught b/c it operates with a bad-words list. One way I've often considered to exclude these is to create a whitelist of admins and others whose edits don't get picked up by the tool. The AWB checkpage and rollbackers would be a good start to such a list (this isn't by any means an effort to create a new "trusted" user class). Would it be possible to implement this somehow, as all Lupin's code appears to be in his userspace? (I would contact Lupin, but he or she hasn't edited in almost eight months.)--chaser - t 22:58, 31 August 2008 (UTC)

The User:Lupin/recent2.js tool grabs data from the Special:Recentchanges RSS feed [1], which currently allows you to ignore bots, anons, etc. with &hidebots=1, &hideanons=1, etc. in the url. Adding more options for other access levels e.g. &hideadmins=1, &hiderollbacker=1, &hideboardvote=1, etc. would be the most efficient way to ignore certain user-groups, because loading only the diffs you want to see is less wasteful than loading all of them and telling the script to disregard many of them, and would require only minimal changes to the script (namely the url it grabs from). Talk to the devs about this. — CharlotteWebb 14:12, 1 September 2008 (UTC)
Whether a change was made by a user who's anonymous or a bot is stored in the recentchanges table. Whether they're an admin, rollbacker, boardvote, etc. is not. It would require a join to the user_groups table and would be a lot less efficient. In some cases you'd probably have to scan the whole table, too: try searching for edits by developers . . . Bots and anons are "efficient enough" because you can expect a substantial but not overwhelming percentage of edits to be by each group. So at most you should have to scan two or three or ten times as many rows as you really need, not thousands of times as many. —Simetrical (talk • contribs) 21:18, 1 September 2008 (UTC)
Okay, failing the first option, how about including the user-rights of each user whose edits appear in the RSS feed? Then the script would know which edits to assume good (ignore) without having to hit the API or whatever for each unrecognized name. — CharlotteWebb 22:34, 1 September 2008 (UTC)
It could be done, sure, if there's enough demand for it. —Simetrical (talk • contribs) 14:10, 2 September 2008 (UTC)

Did you read Simetrical's reply above? He clearly says that, when generating the recentchanges table, checking for those things is not conducive to reasonable performance. It could, of course, be included in the recentchanges table, but it seems like a bit of a big ask for minimal benefit. OTOH, I'm working on some new fields for recentchanges, so it could be snuck in there, presuming there was sufficient demand/need for it. — Werdna • talk 06:20, 2 September 2008 (UTC)

It would be an issue to filter by it. It wouldn't be an issue to just provide the data. One extra query on all the user_id's would do it. (Joining would be a bad idea because it would repeat rows.)

You couldn't include it in the recentchanges table unless you did something ugly like concatenating the group names, because users can have multiple groups, so it should really be in its own table. Plus you'd have to maintain it, if it were denormalized like that, which would be a pain. —Simetrical (talk • contribs) 14:10, 2 September 2008 (UTC)

If I'm the only person asking about this, there's probably not sufficient demand (unless there's a super-easy way!). Anyway, thanks everybody for your time.--chaser - t 07:04, 3 September 2008 (UTC)

When editing a page, whitespace above editing box

When editing a page (that is, on the page you get to after clicking the "Edit this page" link), there is some whitespace above the editing box that wasn't there before today, which I think is caused by something like:

<div id="wikiPreview"></div>

getting changed to:

<div id="wikiPreview"></div><p><br /></p>

Where was this change made?

—Lowellian (reply) 04:15, 1 September 2008 (UTC)

In EditPage.php: look at the comments to rev:40184 and maybe some other revisions as well. —AlexSm 04:24, 1 September 2008 (UTC)
Thank you for the info, AlexSm. But this is not cool at all; that unnecessary whitespace is very annoying and shoves the edit box down too far. As far as I can tell from looking at the revisions, under the previous code, the
<p><br /></p>
part was only generated when there was actually a Preview DIV with content in it (which makes sense, because if there is a Preview block, we want there to be some space between the Preview block and the edit box for visual clarity). But now, that whitespace is generated even when there is no Preview (that is, you haven't clicked the Preview button, so there is only a Preview DIV with no content). This is unnecessary whitespace that looks rather glaring. Any idea how to get the attention of the developers to fix this, or alternatively, how I can modify my monobook.css to get rid of the whitespace?
—Lowellian (reply) 19:36, 1 September 2008 (UTC)

Saying "I don't like it, for the following reasons" would be sufficient to express your displeasure with the change. — Werdna • talk 07:13, 2 September 2008 (UTC)

Yes, but who should I contact to get this changed? Or like I said, alternatively, how I can modify my monobook.css to get rid of the whitespace? —Lowellian (reply) 17:40, 2 September 2008 (UTC)
It seems the extra whitespace has been removed by now, exactly by revision that I linked above. —AlexSm 15:17, 3 September 2008 (UTC)
Oh, okay, I see, the fixed revision just took a few days to take effect. That's great news. Thank you, developers; I really appreciate this. :) —Lowellian (reply) 23:32, 3 September 2008 (UTC)

Custom edit messages

Per the August 11 Signpost, we can now add custom edit notices per page. This looks like a much better solution than using comments in the article. Does anyone understand how to implement this? --—— Gadget850 (Ed) talk - 11:47, 1 September 2008 (UTC)

If MediaWiki:Editnotice-2 is created, it will appear when editing any user-page. If MediaWiki:Editnotice-2-Gadget850 is created, it will appear when editing your user-page. Try it . — CharlotteWebb 14:40, 1 September 2008 (UTC)
Check out template {{editnotice}}. It has documentation that explains how this works. (And no, I didn't make that template.) One thing worth mentioning is that only admins can create editnotices since they are placed in the fully protected "MediaWiki:" namespace.
--David Göthberg (talk) 15:10, 1 September 2008 (UTC)
Ah well thanks for that link. Now I feel stupid for going to read the source code . On the other hand if the notices are being added through a template it would be possible to make certain messages editable by regular users (or at least auto-confirmed) by using a vivid array of parser-functions and template sub-pages. Strictly by the "it's a wiki, get over it" principle this wouldn't be a bad idea if the key intent is to at least partly replace <!-- hidden html comments --> which can be added or removed by anyone. I don't see it happening though. — CharlotteWebb 15:33, 1 September 2008 (UTC)
Thanks to all. This will be helpful in maintaining list articles that have criteria for inclusion. --—— Gadget850 (Ed) talk - 15:49, 1 September 2008 (UTC)
CharlotteWebb: Well, I too went reading the source code and figured out that the naming was something like "MediaWiki:Editnotice-Namespace-Pagename". But how to write the namespace and the pagename was not clear. So I decided to search with Special:PrefixIndex/MediaWiki:Editnotice to see if someone else already had tried the different spellings. And thus I found the existing notices and the template used on them. Now afterwards I feel slightly silly since it would have been much simpler to use Special:Search and search all namespaces for "editnotice".
Gadget850: Yeah, this will be very useful. But I think the devs have been a bit too fast in deploying this one. Even though I have worked a lot with namespace detection I find it confusing to work with namespace numbers. Sure, it makes the server code simpler, but it can't be that much code to translate between local namespace names and the numbers. Using namespace names would be much more user-friendly.
--David Göthberg (talk) 15:55, 1 September 2008 (UTC)
And the template is even more useful when I remove #talkpagetext {display:none} from my .css. I can't remember what I was testing with that. --—— Gadget850 (Ed) talk - 16:15, 1 September 2008 (UTC)
I've removed the id from the template - I don't know why it was there. --Random832 (contribs) 18:45, 3 September 2008 (UTC)
Yeah, it would probably better to omit the namespace number and just use the {{FULLPAGENAME}} e.g. "Editnotice-Wikipedia:Village_pump_(technical)" instead of "Editnotice-4-Village_pump_(technical)". — CharlotteWebb 16:21, 1 September 2008 (UTC)
If we want to have the naming convention changed it should be done now, not after we have thousands of these message pages. — CharlotteWebb 16:26, 1 September 2008 (UTC)
I would favour this change, assuming there's no technical problem with it. Has anyone posted it to Bugzilla yet? Algebraist 18:27, 1 September 2008 (UTC)
I'm sure the impending response would be "but namespace titles might change, especially on foreign language projects with incomplete localization is incomplete (or at least needing better translation by a more fluent speaker)", however I doubt a project would reach the point where it needs Editnotice pages (certainly not in a level of bulk where renaming the namespaces would be a big deal) without already having high volume of editing and hopefully a critical mass of native/near-native speakers who have already straightened out all the L10n issues. But I could be wrong. Even so it would be easy enough to automatically rename directly from the database whenever namespace are changed.
I have asked Krimpet to comment here as she is the one who created this feature. — CharlotteWebb 19:14, 1 September 2008 (UTC)

(Could this be applied/adapted to the request at MediaWiki talk:Common.js#Disambig editintro? I would guess not, from the implementation explanation [it looks page specific, not generalizable to page-groups], but someone who knows this might be able to help me with that. :) -- Quiddity (talk) 18:12, 1 September 2008 (UTC)

Guessing not would be correct. — CharlotteWebb 19:15, 1 September 2008 (UTC)

CharlotteWebb asked be to comment - I'm back after being away for a few days, so here I am. :) I chose this somewhat nomenclature for edit notices for several reasons. The foremost is that, indeed, namespace names can be easily altered by system messages. Due to MediaWiki's architecture, it's desirable to be as non-dependent on namespace names as possible. (Imagine, for example, if we decided to add an extension of some sort to deploy identical editnotices from a centralized location on different wikis with different namespace names.) Also, the name of MediaWiki: messages is already subject to some arbitrary limitations (slashes cannot be contained in messages, for example, hence messages for subpages must replace '/' with '-'); thus, the full page name cannot be used in the message name. For this reason, I adopted the current "Editnotice-#-TITLE" nomenclature. (If tracking down names of messages proves to be too confusing, perhaps putting all the notice in the per-namespace notice, along with a ParserFunctions switch to select the desired message per page, would be better?) krimpet✽ 18:22, 3 September 2008 (UTC)

I thought that mediawiki had standard namespace names (what we use here in english, but "Project" instead of "Wikipedia") that exist independent of localization. --Random832 (contribs) 18:31, 3 September 2008 (UTC)

Not for custom namespaces (e.g., "Portal"). To be honest, though, I think it probably makes more sense to use the localized canonical namespace name here ― what's the problem if it gets changed? Some custom edit notices don't work for a couple of days? —Simetrical (talk • contribs) 15:45, 5 September 2008 (UTC)

Do we have a policy on letting users have edit notices on their own userspace pages? I've worked out a system for allowing a non-admin to maintain the editnotice without requiring a protected edit request every time and without allowing anyone else to edit it. (should this be allowed?) --Random832 (contribs) 18:39, 3 September 2008 (UTC)

This is a new feature, so we don't appear to have any guidelines. I can't see any issues with edit notices on a user page that we don't already address, such as civility. Many users have notices of some sort on their talk page addressing centralized discussion and the like. I used {{UserTalkReplyhere}} before edit notice. --—— Gadget850 (Ed) talk - 20:30, 3 September 2008 (UTC)

Rather than condoning every man and his dog creating a new MediaWiki: page, why don't we put something at MediaWiki:Editnotice-3 that checks for a .js or .css subpage for that user and loads it as the editnotice if it exists? I think something like:

{{#ifexist:User:{{PAGENAME}}/editnotice.css|{{User:{{PAGENAME}}/editnotice.css}} }}

would be sufficient. It's a bit of a hack of the .css-page-edit-restrictions, but sensible under the circumstances. It's essentially what Random833 has already implemented. (also)Happy‑melon 07:54, 4 September 2008 (UTC)

Hacks are :-/ And having a parser function called on every &action=edit is not great for performance... --MZMcBride (talk) 08:09, 4 September 2008 (UTC)
It would only be a parser call on edits to the User: namespace. On the other hand, given that the existing pseudo-editnotices are not protected, perhaps there's no need to make it a .css subpage. On the other hand, the who-can-edit-what-in-userspace system could do with a complete overhaul... (also)Happy‑melon 08:19, 4 September 2008 (UTC)
A typical action=edit is followed by an article save, which doesn't just run a single parser function, it runs the whole parser on a potentially very large page. I wouldn't worry about performance here. However, I'm not sure what the implications are of allowing unprotected pages to be displayed as interface messages . . . there are probably none, but it worries me slightly. Is this already done elsewhere? —Simetrical (talk • contribs) 15:47, 5 September 2008 (UTC)
Simetrical: Yes, there seems to be a serious security issue with the system messages. They are sent to the browsers without going through the proper parsing. For instance HTML tags are not converted to XHTML tags, which to me indicates that it might be possible to add other non-allowed HTML instructions and script code and other things in MediaWiki messages. Things that normally is filtered away by MediaWiki when someone tries to put that in a page. Things that make it possible to attack the browsers. Although I have not tested yet if MediaWiki still do the security filtering on the MediaWiki messages. Before we have checked that we should not open up those notices for anyone to edit.
--David Göthberg (talk) 16:11, 5 September 2008 (UTC)

Heading structure broken

Just a heads-up, as I've also been advised to take the following to MediaWiki. Per Wikipedia:Help desk#Heading structure broken:

The heading structure on every page appears to be broken. There is an H1 (the page title) immediately followed by an H3 ("From Wikipedia, the free encyclopedia" - which isn't even a heading, and should probably be marked up as a paragraph); and the page ends with a bunch of H5s ("Views", "Personal tools", "Navigation", "Search", "Interaction", "Toolbox") with no parent other than H1 (and the last headings in the article, which are not meant to apply to it).

Headings should follow a strict hierarchy, H1 > H2 > H3, and so on. WCAG says:

3.5 Use header elements to convey document structure and use them according to specification. [Priority 2]
For example, in HTML, use H2 to indicate a subsection of H1. Do not use headers for font effects. ([2])

and:

Since some users skim through a document by navigating its headings, it is important to use them appropriately to convey document structure. Users should order heading elements properly. For example, in HTML, H2 elements should follow H1 elements, H3 elements should follow H2 elements, etc. Content developers should not "skip" levels (e.g., H1 directly to H3). Do not use headings to create font effects; use style sheets to change font styles for example. ([3])

See also Wikipedia talk:Accessibility#Headings in page template. Andy Mabbett | Talk to Andy Mabbett 17:57, 1 September 2008 (UTC)

bug 457http://bugzilla.wikimedia.org/show_bug.cgi?id=457 —Simetrical (talk •  contribs) 21:45, 1 September 2008 (UTC)
Thank you - you beat me to it, because I am still waiting for my bugzilla registration confirmation e-mail to arrive. It's very disappointing to see that the bug was raised on 12 September 2004, just short of 4 years ago, and yet a fix has not yet been implemented. Andy Mabbett | Talk to Andy Mabbett 21:59, 1 September 2008 (UTC)
You realize that there are 3087 unresolved bugs for MediaWiki and Wikimedia? What exactly makes you think that every problem is likely to get fixed within four years of being reported? This particular one doesn't cause any real problem that I've heard of, but fixing it would break all sorts of user scripts and custom styles. —Simetrical (talk • contribs) 14:14, 2 September 2008 (UTC)
It causes the real problem that you will have heard of, when you read the cited WCAG guidance, above. Where did I say that I thought that every problem would be resolved within four years? If your latter assertion is true, then the lesson is to be stricter in adhering to such guidelines in the first place. Andy Mabbett (aka Pigsonthewing); Talk to Andy Mabbett; Andy Mabbett's contributions 00:10, 3 September 2008 (UTC)
Violating WCAG guidance is not a "real problem" unless people actually complain that in some way their browsing experience has been harmed by it. There have been no complaints I've heard except by standards purists, no complaints by anyone who actually felt that the dubious behavior was harmful to them in some way. I completely agree that it's wrong and should be changed at some point, but it shouldn't be surprising that it receives very low priority, since it would be a pain to fix (breaking some unknown amount of CSS/JS) and there are no concrete benefits. Nothing is "broken" here, we just don't completely adhere to relevant standards. —Simetrical (talk • contribs) 14:51, 3 September 2008 (UTC)
Everyone whose browsing experience is mucked up because they use screen readers (which treat heading structures as they should be treated) will disagree with you that nothing is broken and that fixing the problem will have no concrete benefits. It is difficult to imagine any CSS that would be broken by fixing this, and I'm skeptical that any system-wide JS would be effected either. That user-created tools will need to be updated should not be a major factor (if one at all) in WikiMedia following basic web standards. If anything, by following them more closely it will make it easier for third-party developers and everyday JS-using editors to write tools for WikiMedia sites, since things will work as expected instead of weirdly and requiring exceptions. Argument to expediency is rarely a strong argument, and almost never a good one in a standards and development discussion, since every corner cut is very likely to lead to problems down the road that simply grow over time and become harder to resolve the longer they sit unresolved (i.e. the user scripts fixes you are certain will be required). — SMcCandlish talk cont ‹(-¿-)› 01:41, 4 September 2008 (UTC)
PS: All that needs to happen to resolve this is changing the abused h3 to some other block element like a p or div, depending on the exact code context (I'd have to look at the source to be sure). It could even keep the same id, class and/or other CSS information associated with it, with only minimal if any changes to the .css files. The fix strikes me as almost ridiculously trivial to implement, and also trivial for script writers to update for. — SMcCandlish talk cont ‹(-¿-)› 01:44, 4 September 2008 (UTC)
You would probably receive more sympathy if you were less condescending and self-righteous. We've received no reports from users of screen readers, or anyone else, saying that they're experiencing an actual problem from this. If you're going to claim it is one, you need to give a concrete case of someone whose browsing experience was affected, not make up further chains of hypotheticals that really serve to mask the fact that your objection is based on the fact that we're violating standards per se. I have no objection to fixing things merely for being standards violations, but they have deservedly lower precedence than fixing things that actually cause problems.

You seem to have missed the fact that Monobook also misuses h5 in the portlets, by the way. And maybe other places I don't know of offhand. I have broken user scripts before by committing "ridiculously trivial to implement" document st