Wikipedia:Village pump (technical)/Archive 99

Current url

Is there any way to look at the current url within a page? Rich Farmbrough, 17:41, 6 May 2012 (UTC).(Using some automation)

Like these urls, //en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)/Archive_99 or https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)/Archive_99 or /wiki/Wikipedia:Village_pump_(technical)/Archive_99, or something else? -— Isarra 17:53, 6 May 2012 (UTC)
Yep something else. Not based on FULLPGENAME. I want to know which redirect I have come from. Rich Farmbrough, 22:29, 6 May 2012 (UTC).(Using some automation)
That wouldn't work well with page caching and it isn't mentioned at mw:Help:Magic words so I assume it's impossible. PrimeHunter (talk) 13:01, 7 May 2012 (UTC)
Do you mean the URL of the page you are on? If you click "Read" at the top it sends you to the actual page, not the REDIRECT URL. If you have been redirected, the URL of the redirect is the one that displays in the adress bar.--Gilderien Chat|List of good deeds 18:28, 7 May 2012 (UTC)
Thanks, I want to access it programatically, so that I can take different actions depending on which redirect was used (or indeed if no redirect was used). As PrimeHunter says it looks impossible with the current software. Rich Farmbrough, 01:57, 9 May 2012 (UTC).

can we view recent transclusions?

Is it possible to view transclusions of a template created after a certain date? I suppose a crude way would be to see what's at the end of the 'what links here' list, assuming that hasn't been alphabetized recently. But is there a more straightforward way? I'd like to be able to look at recent additions of {{infobox language}}, which has 6,700 transclusions, to see that it's being used properly. — kwami (talk) 23:24, 6 May 2012 (UTC)

Additions to the templatelinks table are not dated; consequently, it is difficult to resolves your query. The only way to do so, in fact, would be to take snapshots yourself to cover the present and future dates; to get past what was transcuded at past dates, one would have to scan the full dumps, a processor intense (but not impossible) operation. - Jarry1250 [Deliberation needed] 23:42, 6 May 2012 (UTC)
This information wouldn't be available to any normal editor, but I wonder, could the details of which articles call which templates be available (and timestamped) in the history of the job queue? I'm not familiar with the guts of MediaWiki, but it seems like something that at least could be recorded. Someguy1221 (talk) 00:51, 7 May 2012 (UTC)
Well, job queue jobs can be logged depending on setup, but I doubt they are in Wikimedia's case - hundreds of thousands of jobs are performed everyday; I mean, it's got to be easier to analyse the dumps (unless you need more regular historical lists than monthly, but it doesn't sound as if you do). - Jarry1250 [Deliberation needed] 00:58, 7 May 2012 (UTC)

It does appear that new transclusions are tacked onto the end of the 'what links here' list. At least, the end of the list now is the articles that I've recently added. Is it actually that predictable? Could I count on being able to start at the end of the list and working back until I reach the articles I'm familiar with? — kwami (talk) 03:15, 7 May 2012 (UTC)

Can't answer that question but one possible way to tackle this would be to have the template place the article in a category as, through the API, you can get members of a category by time they were added to the category. Obviously this is of no use for existing uses. And I wouldn't be surprised if someone more knowledgeable than me comes along and says there's problems with this method. Dpmuk (talk) 03:28, 7 May 2012 (UTC)
The existing transclusions are mostly okay, I think, except maybe where someone has messed them up. I'm more concerned about new transclusions being improperly formatted and getting lost in the existing 6,700.
I have no clue when it comes to the API, but it might be worth looking into. It would also be nice if it weren't just available to me, but was s.t. anyone at the languages WP could check up on once in a while. — kwami (talk) 07:44, 7 May 2012 (UTC)
Apologies if I was confusing before, it's fairly trivial to get a report which says "which transclusions were added since the last report" - it's the historical data that's difficult to get hold of. If you would like such a report, I suggest asking at WP:Bot requests. - Jarry1250 [Deliberation needed] 12:18, 7 May 2012 (UTC)
Just realised I may have been being dumb. Jarry1250 - Are you suggesting getting a list of transclusions, storing it and the using it for the next report, because you're right that would be very trivial. Don't know why it didn't occur to me. Dpmuk (talk) 20:31, 7 May 2012 (UTC)
Yes, I was suggesting that was the easiest way. You could also - because they are stored in order - only note the last entry, but that seems prone to bugs. - Jarry1250 [Deliberation needed] 22:14, 7 May 2012 (UTC)
I had been doing this last, and was also worried about bugs. The comparison report would work very well for me, but not so well for the project as a whole, unless I can upload it somewhere. I'm not sure how much actual use it would get, though, and doubt that many people would ever be aware of it, which is why I was hoping for the ability to sort by date. — kwami (talk) 09:30, 8 May 2012 (UTC)
Kwami, this functionality already exists apart form a couple of tweaks in FemtoBot task 6. The tweaks are basically not to crunch the list, so that history can do a nice diff. (The crunching is to reduce page size.) Rich Farmbrough, 02:02, 9 May 2012 (UTC).

TOCLimit

I come here to basically ask this which is: Is there a way (using .js/.css) to override the TOCLimit template on all pages - but just for yourself? --86.180.71.140 (talk) 16:48, 7 May 2012 (UTC)

It should be possible with CSS, since all the template does apparently is applying a CSS class. It wouldn't be difficult either to make the class dynamically changeable with JavaScript. Ucucha (talk) 17:09, 7 May 2012 (UTC)
The relevant CSS rule (in the "site" module if I interpret the URL correctly) is
.toclimit-2 .toclevel-1 ul, .toclimit-3 .toclevel-2 ul, .toclimit-4 .toclevel-3 ul, .toclimit-5 .toclevel-4 ul, .toclimit-6 .toclevel-5 ul, .toclimit-7 .toclevel-6 ul {
   display: none;
}
Ucucha (talk) 17:13, 7 May 2012 (UTC)
Would it be possible to know how to do it with CSS? I'm not really very good at them, at all. Thanks! --86.180.71.140 (talk) 17:14, 7 May 2012 (UTC)
Actually - I can't get it to work, the TOCLimit still works. --86.180.71.140 (talk) 17:21, 7 May 2012 (UTC)
Try changing none to inline. How are you updating personal CSS without an account? ---— Gadget850 (Ed) talk 17:28, 7 May 2012 (UTC)
It would be better to use display: block; instead. Both Chrome and Firefox users can edit a stylesheet that can change the appearance of web pages. The only concern is that such changes will affect all pages that use those classes. – Allen4names 06:11, 8 May 2012 (UTC)
@Gadget850 - its on another wiki, but everyone here is much more helpful/knowledgeable when it comes to.js and .css. I'll try both those thanks! --86.169.148.192 (talk) 15:09, 8 May 2012 (UTC)

funky error on user talk page

Anyone have any idea what's going on here[1]? Every time I try saving on Taivo's talk page, I get an error. I can edit his user page, and other people's talk pages, just not his talk page. Problem's still happening; I finally realized I should ignore the error, as the save is going through.

It's the usual 'Our servers are currently experiencing a technical problem' message. I just made a whitespace edit and got the following details:

Request: POST http://en.wikipedia.org/w/index.php?title=User_talk:Taivo&action=submit, from 10.64.0.126 via cp1014.eqiad.wmnet (squid/2.7.STABLE9) to 10.2.1.1 (10.2.1.1)
Error: ERR_ZERO_SIZE_OBJECT, errno [No Error] at Tue, 08 May 2012 07:44:59 GMT

kwami (talk) 07:47, 8 May 2012 (UTC)

I am getting those with every edit as well, and yet my edits still go through. I suspect it has something to do with the new build as mentioned a couple of threads above. --Saddhiyama (talk) 09:12, 8 May 2012 (UTC)
But why only on that one page? That's what's so weird. — kwami (talk) 09:27, 8 May 2012 (UTC)
I have gotten it on different pages today and always on edits that were saved correctly. Many people have gotten it today at Wikipedia:Help desk. Here is an example of the complete message I get:


Wikimedia Foundation
Error
Our servers are currently experiencing a technical problem. This is probably temporary and should be fixed soon. Please try again in a few minutes.
You may be able to get further information in the #wikipedia channel on the Freenode IRC network.
The Wikimedia Foundation is a non-profit organisation which hosts some of the most popular sites on the Internet, including Wikipedia. It has a constant need to purchase new hardware. If you would like to help, please donate.
If you report this error to the Wikimedia System Administrators, please include the details below.
Request: POST http://en.wikipedia.org/w/index.php?title=Wikipedia:Help_desk&action=submit, from 91.198.174.45 via sq77.wikimedia.org (squid/2.7.STABLE9) to 10.2.1.1 (10.2.1.1)
Error: ERR_ZERO_SIZE_OBJECT, errno [No Error] at Tue, 08 May 2012 11:58:29 GMT
"try again" is a link to submit the edit again. I only clicked it once where it gave an edit conflict. I imagine it would usually give an edit conflict or a null edit but if it was creation of a new section with a "New section" link then the section may be created once more at the end of the page. Some IP's who are not used to our flaky software submitted the same section many times. Six times in Special:Contributions/174.44.139.155 and thirteen (with minor changes in some of them) in Special:Contributions/75.162.4.130. If the message knows that it was an attempted save which lead to the message then it should say to check whether the edit was actually saved before trying again. PrimeHunter (talk) 12:35, 8 May 2012 (UTC)
Me too; variant info is:
Request: POST http://en.wikipedia.org/w/index.php?title=User_talk:Redrose64&action=submit, from 91.198.174.44 via sq60.wikimedia.org (squid/2.7.STABLE9) to 10.2.1.1 (10.2.1.1)
Error: ERR_ZERO_SIZE_OBJECT, errno [No Error] at Tue, 08 May 2012 18:55:09 GMT
The edit did go through. --Redrose64 (talk) 18:57, 8 May 2012 (UTC)
I also got this error at the help desk and I made kind of a mess because of it (although I am not an IP :)) see
2012-05-08T20:52:59
2012-05-08T20:53:18
2012-05-08T20:53:27
2012-05-08T20:53:48
2012-05-08T20:54:19
2012-05-08T20:54:34
2012-05-08T20:55:44
-- Toshio Yamaguchi (tlkctb) 19:13, 8 May 2012 (UTC)
I'm also getting this message, except on Wikipedia:Edit filter/False positives/Reports. However, the edit would still go through. Reaper Eternal (talk) 02:01, 9 May 2012 (UTC)

Huggle

Huggle is not working, Help!--Deathlaser :  Chat  16:18, 8 May 2012 (UTC)

  Fixed--Deathlaser :  Chat  16:52, 8 May 2012 (UTC)

Contributions page incorrectly showing user as blocked

This page: https://en.wikipedia.org/wiki/Special:Contributions/203.100.3.82 shows the pink box indicating that the user is blocked. But the user is currently able to edit. The user was blocked for one month on 9-March, but that block has long since expired. HumphreyW (talk) 02:43, 4 May 2012 (UTC)

I'm not certain about this, but could it be because of an autoblock? Graham87 02:57, 4 May 2012 (UTC)
I was guessing that it was purely a failure of the previous block to expire, so I blocked everything (even email) for one second. A minute later, it was still showing everything as being blocked, so I felt helpless until I realised that there was a simple "unblock" option. I've followed it, and the pink box is gone. Nyttend (talk) 03:05, 4 May 2012 (UTC)
I have no idea, but I noticed the same phenomenon with 202.45.119.35 (talk · contribs · WHOIS) recently. The IP is now blocked by me, but before I did so the red box was insisting that Drmies' (expired) block was still active. I've also noticed it on a handful of other occasions. It appears that the actual blocks themselves are expiring correctly and allowing the IPs to edit, but the red box lags for some reason. --Bongwarrior (talk) 03:10, 4 May 2012 (UTC)
I believe this has come up before (someone who cared enough could look through the archives). If I recall correctly it was some form of weird caching. Killiondude (talk) 05:24, 4 May 2012 (UTC)

Generally this is a sign of an autoblock: the IP is blocked as a result of the user being blocked, which triggers the software to display the latest block in the log. It doesn't check whether that latest block is actually in effect or not. It's an invaluable tool for correlating IPs to disruptive users, so I hope no one fixes it.—Kww(talk) 11:59, 4 May 2012 (UTC)

That strikes me as outing users. Nobody Ent 13:09, 5 May 2012 (UTC)
Not really, because it does not link the IP to the blocked account. That's all background that we don't see. — The Hand That Feeds You:Bite 13:51, 9 May 2012 (UTC)
If it was related to autoblock then I would expect that the user could not edit. But in this case the user could edit and thus was not blocked. HumphreyW (talk) 04:03, 7 May 2012 (UTC)

I don't think it's an autoblock. I think it may be related to the phenomenon that when showing a previous page of contribs, the software will sometimes display the block that was active at the time, not the current block. Elen of the Roads (talk) 13:09, 7 May 2012 (UTC)

Pages transcluded onto the current version of this page

When editing a page, a list of templates or pages transcluded onto the page being edited appears beneath the edit window. I have my preferences set to display the page preview at the bottom, and often this list can become unweildingly long. Is there any way to set a custom css or js code that would make this into a collapsible list? - ʄɭoʏɗiaɲ τ ¢ 20:00, 7 May 2012 (UTC)

/* inline list of templates */
.templatesUsed ul,
.templatesUsed li {
    font-size: smaller;
    display: inline;
    margin: 0;
    padding: 0;
}
.templatesUsed ul li:before {
    content: "\A0\B7\20"; /* nbsp, centre dot, space */
}
.templatesUsed ul li:first-child:before {
    content: "\A0";
}

Can't remember who I ripped this from. ---— Gadget850 (Ed) talk 22:08, 7 May 2012 (UTC)

Snazzy! Thank you :) - ʄɭoʏɗiaɲ τ ¢ 10:39, 9 May 2012 (UTC)

Problem with templates using plainlist class

Until I fixed it, if a section contained {{Shortcut}}, which uses the plainlist class, it was impossible to create a nested bulleted list (one with "**" in it). I fixed this in the case of the shortcut template by changing the list markup to pure HTML; see Template talk:Shortcut#Changing wiki-markup to pure HTML in lists. Is there any particular reason why that fixed the problem? Please reply at the template talk page rather than here, to keep discussion in one place. Graham87 08:01, 9 May 2012 (UTC)

RFC: Deploying 'Start date' template in infoboxes

Please see: Wikipedia talk:Bot requests#RFC: Deploying 'Start date' template in infoboxes. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:32, 9 May 2012 (UTC)

Obnoxious must be the new black

Is there any way to suppress Template:TFA-editnotice which is created in HUGE letters on at least one article when the edit button is pressed? (1) After almost ten years of contributing content, I've learned how to tell when I'm editing an article. (2) This template is fucking obnoxious -- vulgarity intended. -- llywrch (talk) 15:58, 9 May 2012 (UTC)

It tells how to hide it on the template page you link to. And I think it's meant to be obnoxious to make it obvious. It should only be being used on today's featured article, so one article at a time. Being on the front page this article will obviously get a lot more hits from new editors and it's intended to make sure they realise they really can vandalise wikipedia. Dpmuk (talk) 16:13, 9 May 2012 (UTC)
You can suppress the message by adding the following line to either Special:MyPage/skin.css or Special:MyPage/common.css:
#TFA-editnotice { display: none; }
And people are supposed to know not only this, but to hack their .css file how again? (I looked at the talk page. Nothing relevant to this but an ignored thread about how obnoxious this template is.) And contributors like me are supposed to put up with this eyesore for the benefit of braindead newbies who can't tell an edit page from their rear end? Wanna explain to me why, after encountering crap like this, established & knowledgeable editors should keep contributing to Wikipedia once again? -- llywrch (talk) 20:46, 9 May 2012 (UTC)
Wikipedia has around 4 million articles and one of them, the one most visible to new users due to being Today's featured article on the Main page, has this edit notice. Template:TFA-editnotice#Hiding the message tells how to hide it by copying a line into Special:Mypage/skin.css. Most established & knowledgeable editors are probably able to copy a line to a linked page. Template documentation is always on the template page and not the talk page. PrimeHunter (talk) 02:26, 10 May 2012 (UTC)
But, you state "at least one article" - can you point to any article other than Today's Featured Article which is presently showing this message during an edit? --Redrose64 (talk) 20:06, 9 May 2012 (UTC)
"At least one" includes the value of one. I was so surprised to see that eyesore I really didn't think I needed to look at any other article to see if it had infected — Preceding unsigned comment added by Llywrch (talkcontribs) 20:46, 9 May 2012 (UTC)

a magic word to prevent pages from showing up on Special:Shortpages?

Sometimes we want to prevent pages from showing up on Special:Shortpages. Right now, the only way to do this is to add a long comment to the page in question. However, that seems a little awkward. Therefore, I am proposing the use of a behavioral switch that would exclude a page from Special:Shortpages regardless of its length (something like __NOSHORTPAGES__ would be a good choice). What do my fellow Wikipedians think? --Ixfd64 (talk) 16:52, 9 May 2012 (UTC)

Previous similar suggestions have been rejected for performance reasons. See bugzilla:15341, and bugzilla:5177 for discussion about a suggested patch. If an extra database field was added by a magic word or something else like being in a specific category then I guess performance would be better. There is also Special:Longpages which should probably be considered at the same time. A filtered version of ShortPages could also be generated periodically by a bot. See [2] for a former version of this, and de:Wikipedia:Kurze Artikel for a German version. PrimeHunter (talk) 21:38, 9 May 2012 (UTC)

Block mirrors

I am tired of doing a search and coming up with a gazillion mirrors of Wikipedia. I want to block a group of pages in Google search. meta:Mirror filter has a filter list but OptimizeGoogle is dead and CustomizeGoogle is not available for Firefox 12. ---— Gadget850 (Ed) talk 20:49, 9 May 2012 (UTC)

1.20wmf2 deployment complete

Hi everyone, the 1.20wmf2 deployment announced above is now complete. For a list of features, see the MediaWiki 1.20wmf2 page. Let us know if you see problems introduced by this release. -- RobLa-WMF (talk) 18:12, 7 May 2012 (UTC)

Blocks stopped showing and do not appear in logs

Is this a new feature or glitch of the new deployment? Blocked IPs/users such as Openhost101 (talk · contribs) and 86.135.201.142 (talk · contribs). For non-admins, you need the blocking identifying script to verify that these IPs/users are blocked or popups. For admins, it will appear as "change block". The IP is listed is NOT autoblocked. The bots also indicated that the listed IP and user are blocked: diff 1 and diff 2. Elockid (Talk) 22:47, 7 May 2012 (UTC)

Something weird happened when I blocked Openhost101. I got back an SQL error (sorry, I should have saved it, but I didn't) after I clicked the block button. I just tried to "correct" the block log by unblocking Openhost101 and reblocking: the unblock worked, but when I went to reblock, I got another error, though different than the first. Ugh, well, he's blocked, so I wasn't going to worry too much about it. -- Gogo Dodo (talk) 23:19, 7 May 2012 (UTC)
I saw something about that on ANI. I think it is a security bug, for reasons that should be apparent. 64.160.39.217 (talk) 23:32, 7 May 2012 (UTC)
Appears to have been fixed now. The blocks listed are still glitched though. Elockid (Talk) 23:46, 7 May 2012 (UTC)

templates not expanding

I tried adding a report to WT:WPSPAM using the Template:Link summary template, and for some reason the template isn't expanding on the rendered page, even though it expands in the preview display before I save the edit. I see a lot of other unexpanded templates on that page too. Something is wrong. 64.160.39.217 (talk) 22:17, 7 May 2012 (UTC)

The page is in the hidden Category:Pages where template include size is exceeded. I will manually archive some sections to fix it. PrimeHunter (talk) 22:28, 7 May 2012 (UTC)
(edit conflict)The template include size is exceeded. The templates are not being parsed and the page is in the hidden category Category:Pages where template include size is exceeded. See Wikipedia:Template limits. ---— Gadget850 (Ed) talk 22:30, 7 May 2012 (UTC)
Ah, thanks. 64.160.39.217 (talk) 23:33, 7 May 2012 (UTC)

rollback issue

All my rollbacks result in a page that says it couldn't be performed because there was already another edit to the page. But the rollback actually has been performed. Equazcion (talk) 07:18, 8 May 2012 (UTC)

Is this still occurring? If so can you try to find steps to reproduce? I'm not able to reproduce this.--Eloquence* 02:13, 10 May 2012 (UTC)

You have new messages failure

Overnight, I was sent seven messages. When I logged in this morning, I didn't get the orange "You have new messages" box. At least one of those seven should have triggered it, so if all seven failed to fire it off, I'd say it's a bug. --Redrose64 (talk) 15:03, 8 May 2012 (UTC)

Another user has just sent me a message, and made five further edits to it. None of them triggered "you have new messages". --Redrose64 (talk) 19:01, 8 May 2012 (UTC)
I've filed bugzilla:36662. --Redrose64 (talk) 21:01, 8 May 2012 (UTC)
Thanks! It is working for me, but if anyone is having similar problems, it would help if you follow up on the bug. (And, please use the Tracked template when you file a bug in Bugzilla.) -- MarkAHershberger(talk) 15:36, 9 May 2012 (UTC)

You have new messages email

When this revdel was done, I got an email telling me the

Email content

"Dear MBisanz,


The Wikimedia UK page User talk:MBisanz has been created on 8 May 2012 by Fæ, see http://uk.wikimedia.org/wiki/User_talk:MBisanz for the current revision.

This is a new page.

Editor's summary: remove troll using edit comments

Contact the editor: mail: http://uk.wikimedia.org/wiki/Special:EmailUser/F%C3%A6 wiki: http://uk.wikimedia.org/wiki/User:F%C3%A6

There will be no other notifications in case of further changes unless you visit this page. You could also reset the notification flags for all your watched pages on your watchlist.

Your friendly Wikimedia UK notification system

-- To change your e-mail notification settings, visit http://uk.wikimedia.org/wiki/Special:Preferences

To change your watchlist settings, visit http://uk.wikimedia.org/wiki/Special:EditWatchlist

To delete the page from your watchlist, visit http://uk.wikimedia.org/w/index.php?title=User_talk:MBisanz&action=unwatch

Feedback and further assistance: http://uk.wikimedia.org/wiki/Help:Contents"

I don't think that is how revdel is supposed to work. MBisanz talk 16:07, 8 May 2012 (UTC)

Is this covered by bug #14901, or is there another factor at play as well e.g. you weren't expecting a talkpage email at all? - Jarry1250 [Deliberation needed] 17:31, 8 May 2012 (UTC)
It looks identical to that bug. MBisanz talk 03:12, 9 May 2012 (UTC)

Grinding browsers into the dust

Dunno if this is v 20, but my browsers (primarily Chrome and Palemoon) are struggling tremendously - crashes and "oh smap!". Never had it this bad before. Rich Farmbrough, 00:08, 9 May 2012 (UTC).

Oh yes, and I get loads of self-edit-conflicts. Rich Farmbrough, 00:09, 9 May 2012 (UTC).
Are you experiencing these problems on other sites or just Wikipedia? If it's just Wikipedia, can you try if your experience is any different when using a new unmodified user account, or restoring all default settings if you're comfortable with the latter? That would help isolate whether any specific gadgets/settings might be causing your experience to degrade.--Eloquence* 02:20, 10 May 2012 (UTC)
The edit conflicts are just WP. Hm, I guess I could test something with a different account. I'll look into it. Rich Farmbrough, 21:20, 10 May 2012 (UTC).

Vcite book

Since the page isn't very active, I hope someone here will know how to fix this. The Template:Cite book template returns a pp for plural pages and a p for singular but Template:Vcite book doesn't return the plural pp. Samples:

  • Vcite book, plural (this is the one that needs fixing-- pages should yield a pp for consistency with other citation templates.)
van Megen HJGM, den Boer-Wolters D, Verhagen PJ. Obsessive compulsive disorder and religion: a reconnaissance. In: Verhagen P, Van Praag HM, López-Ibor JJ Jr, Cox J, Moussaoui D, editors. Religion and Psychiatry: Beyond Boundaries. Wiley; 2010. ISBN 978-0-470-69471-8. p. 271–82.
  • Cite book, plural
van Megen HJGM, den Boer-Wolters D, Verhagen PJ (2010). "Obsessive compulsive disorder and religion: a reconnaissance". In Verhagen P, Van Praag HM, López-Ibor JJ Jr, Cox J, Moussaoui D (eds.). Religion and Psychiatry: Beyond Boundaries. Wiley. pp. 271–82. ISBN 978-0-470-69471-8.
  • Vcite book, singular
van Megen HJGM, den Boer-Wolters D, Verhagen PJ. Obsessive compulsive disorder and religion: a reconnaissance. In: Verhagen P, Van Praag HM, López-Ibor JJ Jr, Cox J, Moussaoui D, editors. Religion and Psychiatry: Beyond Boundaries. Wiley; 2010. ISBN 978-0-470-69471-8. p. 271.
  • Cite book, singular
van Megen HJGM, den Boer-Wolters D, Verhagen PJ (2010). "Obsessive compulsive disorder and religion: a reconnaissance". In Verhagen P, Van Praag HM, López-Ibor JJ Jr, Cox J, Moussaoui D (eds.). Religion and Psychiatry: Beyond Boundaries. Wiley. p. 271. ISBN 978-0-470-69471-8.

SandyGeorgia (Talk) 21:01, 9 May 2012 (UTC)

The doc page states: "In accordance with the Vancouver style, this will be displayed with a leading "p. ", regardless of whether the argument is a single page number or several numbers" and is referenced. I took a look at the other Citation Style Vancouver templates and they all use the same style. I am sure you realize that Citation Style 1 and Citation Style Vancouver use different styles and should not be mixed. ---— Gadget850 (Ed) talk 00:12, 10 May 2012 (UTC)
Ah, thanks :/ Am I imagining things or was there no doc page when I checked a few hours ago? Did you just link it? Anyway, thanks, I couldn't find that when I inquired. SandyGeorgia (Talk) 00:15, 10 May 2012 (UTC)
You are welcome. The doc page has been there. The Vancouver templates are not well used, and I am not really an expert on them, but I have done some classification and categorization. ---— Gadget850 (Ed) talk 08:59, 10 May 2012 (UTC)

Mass rollback script is not working

I cannot seem to get User:John254/mass rollback.js to work (see my vector.js).--Jasper Deng (talk) 04:51, 10 May 2012 (UTC)

Do the other scripts on your vector.js work? - Jarry1250 [Deliberation needed] 13:57, 10 May 2012 (UTC)
Jasper: this seems really a problem on your side if the afc script is not working, the mass rollback, and who knows what else and nobody is reporting similar problems... mabdul 22:16, 10 May 2012 (UTC)
All the other scripts work.--Jasper Deng (talk) 22:21, 10 May 2012 (UTC)

new functionality

I want to suggest wiki functionality that allows for more social interaction similar to the way news sites allow users to "share" the article via other social networking hubs. I find interesting things on the wiki and I have to do the extra step of copying the url to facebook. A built in functionality would encourage more use of wikipedia. — Preceding unsigned comment added by 199.209.144.225 (talk) 16:27, 10 May 2012 (UTC)

See User:TheDJ/Sharebox, and Wikipedia:Village pump (proposals)/Archive 87#Share button for the most recent of many discussions to add a feature by default. PrimeHunter (talk) 16:36, 10 May 2012 (UTC)

How to cite different pages using the same ref tag in different places?

I want to use the same reference tag in different places aka. <ref name="smith" />, but citing different book pages in each different place in the article. How to do? -Stevertigo (t | c) 00:43, 10 May 2012 (UTC)

I also want to know that.·ʍaunus·snunɐw· 00:47, 10 May 2012 (UTC)
See Wikipedia:Citing sources#Citing multiple pages of the same source. PrimeHunter (talk) 00:51, 10 May 2012 (UTC)
(Cutting in) Using short citations is an option - the result is similar to using parenthetical citations, al la "(Smith p.10)" etc. But is there a way to use the same linked citation tag but with different pages? -Stevertigo (t | c) 00:57, 10 May 2012 (UTC)
Well, here's how I do it: Minnie Fisher Cunningham. I put the books down in the References section. The individual page references (reflist template) are up under Notes. In the edit toolbar, there is an icon that looks like an open book with a red ribbon down the middle of the page. Click it. And that's what enables you to create the individual page reference. I learned it as you type in Author, Year, Page number(s). Hope this helps.Maile66 (talk) 00:54, 10 May 2012 (UTC)
Yes it looks like you use short citations at that article. Were looking for a way to use the linked citations functionality. -Stevertigo (t | c) 00:59, 10 May 2012 (UTC)
You did not state which variation of the footnote system you are using, but Help:References and page numbers should cover them all. ---— Gadget850 (Ed) talk 00:59, 10 May 2012 (UTC)
Gadget850, thanks for the link. I didn't know about some of these.Maile66 (talk) 01:07, 10 May 2012 (UTC)
You are welcome. This is a common question, but the answer depends on which system you are using, or you might want to make a change after seeing the options. After answering this a few times, I created the help page. ---— Gadget850 (Ed) talk 01:40, 10 May 2012 (UTC)
Yes, basically there is no way of doing what we want which is combine shortref with named refs. Harvard citations is the only way to make it work I think.·ʍaunus·snunɐw· 01:02, 10 May 2012 (UTC)
Yeah I see that now. Different page citations will still need to print on different lines. So short citations it is. Thanks all, -Stevertigo (t | c) 01:05, 10 May 2012 (UTC)
There is of course a Bugzilla bug for this... Rich Farmbrough, 21:32, 10 May 2012 (UTC).
If you mean T15127, I added it to the help page. ---— Gadget850 (Ed) talk 11:46, 11 May 2012 (UTC)
You can use {{rp}} along with each use of <ref name="smith" /> that way you'll just have one reference to Smith in the relist but in the text each use will have a separate page number. NtheP (talk) 11:31, 11 May 2012 (UTC)
As documented at Help:References and page numbers. ---— Gadget850 (Ed) talk 11:46, 11 May 2012 (UTC)

In need of a Delete and CRV button

It took me very long to nominate a article for deletion and even longer to get to the point that I know how to deal with copy right violations. Is there any good way to deal with these problems without reading all that pages? Tagging and turning away also seems not to be an option, because than it takes ages before something happens. --Stone (talk) 07:53, 11 May 2012 (UTC)

It was not 100% Copyright violation and 5% were valid. So deleting the 95% and not making it obvious that this particular editor has done it in other articles to is also not the best solution.--Stone (talk) 08:56, 11 May 2012 (UTC)
If it's not outright deletion you seek, you should simply remove the offending text (and perhaps replacing it with a {{copyvio}} tag), and notify the editor who performed the copy and paste. --Ohconfucius ¡digame! 09:09, 11 May 2012 (UTC)

Creating a new account; text did not save

I'm not sure where to report this, since Outreach:ACIP is apparently inactive, so I'll try here. I just created this alternate account, and when I was prompted to enter information for my user page, I did (via this page). However, when I clicked next, the text did not carry over, but instead it just contained the default text:

<!-- BELOW IS THE TEXT ABOUT YOU. YOU CAN CHANGE IT COMPLETELY OR IN PARTS AND THEN COME BACK TO IT. AFTER YOU ARE DONE, SCROLL DOWN A BIT FURTHER AND CLICK "SAVE PAGE".-->{{New user bar}} Replace this example text with information about you. <!-- NOW, CLICK THE "SAVE PAGE" BUTTON. CONGRATULATIONS, YOU'VE JUST MADE YOUR FIRST EDIT TO WIKIPEDIA. -->

Any idea if this is just a local glitch or a more prevalent problem? I doubt many new users have the wherewithal or knowledge to submit a bug report, or contact anyone for that matter. I'm using Windows 7 w/ Firefox 12, so it isn't exactly an unusual configuration. I feel like this should be fixed, since every little bit of coddling for new users helps. -Runningonsocks (talk) 04:31, 11 May 2012 (UTC)

I have seen this bug before as well. The ACIP tests should probably just be shut down so any permanent enhancements can be worked on. Thanks for bringing this up, Steven Walling • talk 23:40, 12 May 2012 (UTC)

Why no cursor in special search?

Just a suggestion: If I go to Special:Search I have to place the cursor into the search box. It's an extra step, and for someone (me) that doesn't use keyboard shortcuts it means maneuvering a mouse to the box, and clicking, then returning my right hand to the keyboard. Not a web writer, but I know that it's easy to add a line of code so when the page opens the user can just type in the search term. Just a suggestion... — Preceding unsigned comment added by Bennoro (talkcontribs) 17:30, 11 May 2012 (UTC)

That seems a good idea to me.
--Nnemo (talk) 18:56, 11 May 2012 (UTC)
Yup, me three. I've been meaning to comment, since going to Google the cursor is already positioned like this. — Quondum 08:03, 12 May 2012 (UTC)

See "No, we will not use Javascript to set focus on the search box." in the FAQ box at the top of this page. Johnuniq (talk) 08:05, 12 May 2012 (UTC)

This FAQ answer deals with the main Wikipedia page, where it makes sense not to auto-land the user in the search box, because there are a lot other things to see on the page. [Although personally I would like the auto-landing in the search box on the main page. Can I have it ?] But this FAQ answer does not apply to the page Special:Search ; on this page, there is only one interesting thing : the search box.
--Nnemo (talk) 11:03, 12 May 2012 (UTC)
And we have a gadget that will focus on the search box for the Main page. ---— Gadget850 (Ed) talk 18:42, 12 May 2012 (UTC)

Now I have the cursor auto-landing in the search box on the Wikipedia main page. Cool ! :-) --Nnemo (talk) 00:55, 13 May 2012 (UTC)

Bots at WP:RM

I think it would be better if related bots performed listing at WP:RM not by subst:Requested move, but by the {{movenotice}} itself with the talk thread link, placed in the article. Basically the current shortcoming is that when you forget to tag the talk thread with subst:Requested move, the article will not appear at WP:RM even if there is a movenotice (an instruction creep, which may lead to limited feedback or no feedback at all). Thoughts? Brandmeistertalk 23:10, 11 May 2012 (UTC)

WT:RM might be a better place to discuss this. Jenks24 (talk) 07:21, 12 May 2012 (UTC)

Random text insertions

I've been active on Wikipedia for quite a while and I've never had this problem before: on two separate occasions, after editing an article, a random piece of text or a reference gets inserted somewhere in the article. I certainly didn't do it myself, I didn't even edit those paragraphs nor did I CTRL-C them; I've also checked my computer for viruses (it's clean) and I've got a firewall in place. Might this be a server-side error? Examples:

  • [3] (the insertion of the 'kidnapping' item was the intended edit; the insertion of the random reference in the middle of the word "Latakia" wasn't)
  • [4] (replacing the wrong diacritics with the right ones was the intended edit; copying the article's "language sample", "see also" and "notes" sections and pasting them randomly in the references section wasn't)

- TaalVerbeteraar (talk) 12:28, 12 May 2012 (UTC)

Database lag

623 seconds so far. Taking all bets. Equazcion (talk) 00:43, 13 May 2012 (UTC)

1,039 seconds. Equazcion (talk) 00:57, 13 May 2012 (UTC)
It peaked at 1,253 seconds for me. May have been a (D)DOS attack, since I see nothing in the server admin log on Wikitech.--Jasper Deng (talk) 00:59, 13 May 2012 (UTC)
Alright. Who's jamming the server?

Due to high database server lag, changes newer than 1,253 seconds may not appear in this list.—cyberpower ChatOnline 01:01, 13 May 2012 (UTC)

That's the first I've actually seen MediaWiki:Lag-warn-high in use, actually. I saw it myself while looking at a contributions page.  Hazard-SJ  ✈  01:09, 13 May 2012 (UTC)

Twinkle and other JavaScript tools intermittently fail!

I don't know why ever since the update, JavaScript addons fail to load. Especially Twinkle. Every time I want to activate Rollback on Twinkle, it never loads but it does load when I don't need it. My JavaScript scripts fail to load as well and at times the skin to Wikipedia doesn't load at all. I've been on a Wiki break for the past two weeks so if I missed a thread about this, feel free to point me to it.—cyberpower ChatOnline 20:36, 5 May 2012 (UTC)

On IE 9?--Gilderien Chat|List of good deeds 20:44, 5 May 2012 (UTC)
Firefox.—cyberpower ChatOnline 21:09, 5 May 2012 (UTC)
I use Firefox 12 without problems. What version do you use? Have you tested with another browser?  Hazard-SJ  ✈  22:50, 5 May 2012 (UTC)
Firefox 12.0.—cyberpower ChatOnline 18:38, 6 May 2012 (UTC)
Cyberpower, is this fixed now? Elen of the Roads (talk) 13:06, 7 May 2012 (UTC)
Seems to be working now but the toolbar in the editor is now gone. Hit the reload button several times but the toolbar won't appear.—cyberpower ChatLimited Access 17:57, 7 May 2012 (UTC)

Is this issue related to "session failure" errors with Twinkle? The error message reads: There seems to be a problem with your login session; this action has been canceled as a precaution against session hijacking. Go back to the previous page, reload that page and then try again. (Firefox 12 is my browser) Senator2029 (talk) 17:24, 13 May 2012 (UTC)

Problem on a server

Hello, Houston, we have a problem !

Try to edit the last section of the article en.wikipedia.org/wiki/Montreal. Make a change, and try to save. This fails : error :

“Request: POST http://en.wikipedia.org/w/index.php?title=Montreal&action=submit, from 91.198.174.41 via sq78.wikimedia.org (squid/2.7.STABLE9) to 10.2.1.1 (10.2.1.1) Error: ERR_ZERO_SIZE_OBJECT, errno [No Error] at Fri, 11 May 2012 12:56:53 GMT”

Can someone please fix that ? It must be three days now.

Thanks !

--Nnemo (talk) 13:13, 11 May 2012 (UTC)

Could not reproduce -RunningOnBrains(talk) 18:17, 11 May 2012 (UTC)
Just kidding, I missed that you had to save a change. Wow, that's bizarre, maybe Wikipedia:Bug reports and feature requests is the place to go? -RunningOnBrains(talk) 18:20, 11 May 2012 (UTC)
I didn't get that error, but I did get an "unable to continue, servers busy" or some such. The edit was actually saved though. Apparently, so was RunningOnBrains and a couple of other people doing test edits (someone's going to get a templated warning soon from a patroller not paying attention). SpinningSpark 19:47, 11 May 2012 (UTC)


Sam Reed tells me he just deployed a fix for this. It was a regular expression in some of our code run amok. Roan Kattouw fixed the bug last night, and the deployment should actually address this. Let us know if this is still a problem. Thanks! -- RobLa-WMF (talk) 19:55, 11 May 2012 (UTC)

Those logs are really cool - show how much work it takes to keep this show on the road. Elen of the Roads (talk) 23:05, 11 May 2012 (UTC)
Thanks for the repair !
And now, for something slightly different… it's down again ! :-)
“Request: POST http://en.wikipedia.org/w/index.php?title=Montreal&action=submit, from 81.57.201.53 via amssq41.esams.wikimedia.org (squid/2.7.STABLE9) to 91.198.174.41 (91.198.174.41) Error: ERR_READ_TIMEOUT, errno [No Error] at Sun, 13 May 2012 18:21:42 GMT”
--Nnemo (talk) 18:25, 13 May 2012 (UTC)

Screenshot upload page

What's the deal with this page? I've never seen it before. I wanted to find a friendlier url, but don't know how. I wondered how one would get to this page, so naturally I looked for "What links here" and I don't see it.

How does one get to this (other than the obvious, someone saves a link)?--SPhilbrick(Talk) 01:04, 12 May 2012 (UTC)

Click "Upload file" in the toolbox, "old guided form", "a screenshot". PrimeHunter (talk) 01:15, 12 May 2012 (UTC)
Thanks, I now remember that form. (Not the screenshot part, but the earlier step) --SPhilbrick(Talk) 02:37, 12 May 2012 (UTC)
That link is really long because includes the information that is pre-loaded in the input box (if you weren't aware). Killiondude (talk) 23:08, 13 May 2012 (UTC)

Raising issue again: Page exceeded the expansion depth

Category:Pages where expansion depth is exceeded continues to gain entries (310 subcategories and 12,363 pages as of now). All the articles that I've checked don't have obvious expansion depth errors, i.e. all the templates appear to have produced the correct output and not terminated early. Is anyone investigating this situation? Should it be reported elsewhere? Peter coxhead (talk) 08:28, 12 May 2012 (UTC)

Many templates will only produce something at the deepest expansion levels in certain circumstances, for example some string templates when the strings happen to have certain lengths (not necessarily the longest), so it's hard to tell from the result whether all templates were completely evaluated. Evaluation will only skip the expansion levels which are too deep. Later code of the template with less expansion can still be evaluated. And the red error message "Expansion depth limit exceeded" is only produced in some circumstances. I guess it happens when whatever could not be expanded was supposed to be rendered. If it's elsewhere like in a condition then there may be no indication beyond the category that the expansion depth was exceeded. Unless somebody can produce an example where manual evaluation of the code indicates that the 40 levels should not have been broken, I will assume the category is generated correctly. PrimeHunter (talk) 13:21, 12 May 2012 (UTC)
Those of us making regular use of {{clade}} have been nesting it to produce trees (cladograms) with leaf nodes up to 20 deep. Leaf nodes at depths of 21 and above don't appear; a red error message may or may not be produced. Testing shows that actually only trees (cladograms) with leaf nodes up to 19 deep don't exceed the expansion depth limit. A cladogram with leaf nodes exactly 20 deep renders the deepest node, but generates an expansion depth limit.
So, if I understand correctly, this means that after outputting the node of depth 20, the software attempts to expand something which would not produce any output (e.g. a #if: expression which would generate an null/empty result). This fails, but doesn't matter as far as the output is concerned.
Does it matter if pages do this? Is there an extra cost to exceeding the expansion depth limit if it is certain that no output has been lost? Peter coxhead (talk) 20:00, 12 May 2012 (UTC)
The software doesn't evaluate expansions beyond level 40 so it doesn't know what they would have produced if they had been evaluated. See meta:Help:Expansion depth. When the 41st expansion should have been made, the software produces <span class="error">Expansion depth limit exceeded</span> at that place in the wikisource instead of evaluating the expansion. It gives the same result as if the 41st expansion in the wikisource had been replaced by the code <span class="error">Expansion depth limit exceeded</span>. What that result is depends on the context. For example, if the 41st expansion would have been rendered unaltered if it had been text then <span class="error">Expansion depth limit exceeded</span> is rendered. This produces Expansion depth limit exceeded with the way the error class is defined. If the 41st expansion is the condition part in an #if then the #if evaluates to true because the produced <span class="error">Expansion depth limit exceeded</span> is non-empty. PrimeHunter (talk) 22:48, 12 May 2012 (UTC)
It appears a lot of the articles in Category:Pages where expansion depth is exceeded are caused by analysis of the image_plan/Lageplan parameter in {{Infobox German location}}. If all other parameters are removed then the category is still there. If the parameter is removed and everythning else kept then the category disappears. The infobox code includes:
  |<!-- Test whether an imagemap template exists, using the district code in the location map file name (field "image_plan" or "Lageplan")
  -->{{#ifexist: Template:Imagemap Germany district {{#ifeq:<!-- 
     The district code is extracted from the file name, with a special case when the district code is only one letter, e.g. "V" 
  -->{{str find|{{substr_any|{{{image_plan|{{{Lageplan}}}}}}|{{#expr:{{str find|{{{image_plan|{{{Lageplan}}}}}}|.svg}}-4}}|3}}|n}}|1|<!-- 
     The district code has only one letter
  -->{{substr_any|{{{image_plan|{{{Lageplan}}}}}}|{{#expr:{{str find|{{{image_plan|{{{Lageplan}}}}}}|.svg}}-2}}|1}}|<!-- 
     The district code has two or three letters
  -->{{substr_any|{{{image_plan|{{{Lageplan}}}}}}|{{#expr:{{str find|{{{image_plan|{{{Lageplan}}}}}}|.svg}}-4}}|3}} }}|<!-- 
     The imagemap template exists, and is used 
  -->{{Imagemap Germany district {{#ifeq:{{str find|{{substr_any|{{{image_plan|{{{Lageplan}}}}}}|{{#expr:{{str find|{{{image_plan|{{{Lageplan}}}}}}|.svg}}-4}}|3}}|n}}|1|{{substr_any|{{{image_plan|{{{Lageplan}}}}}}|{{#expr:{{str find|{{{image_plan|{{{Lageplan}}}}}}|.svg}}-2}}|1}}|{{substr_any|{{{image_plan|{{{Lageplan}}}}}}|{{#expr:{{str find|{{{image_plan|{{{Lageplan}}}}}}|.svg}}-4}}|3}} }}|<!-- 
        No imagemap template exists, a normal location map is used 
-->{{{image_plan|{{{Lageplan}}}}}}|240x240px}}|[[Image:{{{image_plan|{{{Lageplan|Dummy flag.png}}} }}}|240x240px]] }}
  }}<!--endifeq image_plan=x -->
It uses string templates to make the test mentioned in the opening comment. Something should be modified to use fewer expansion levels but I'm not trying to do it. PrimeHunter (talk) 14:54, 12 May 2012 (UTC)
Hmm, that's a pretty hardcore piece of code. But the underlying principle is fairly straightforward, and it should be possible to simplify. It's not surprising that there are depth problems; that last {{str_find}} at the end is seven levels deep just in the fragment you've copied. Happymelon 23:37, 13 May 2012 (UTC)
As I mentioned above I see this bug as the result of clicking "Show preview" after opening Southwest Chief for editing. 68.165.77.191 (talk) 17:47, 13 May 2012 (UTC)
It's a limitation and not a bug. Category:Pages where expansion depth is exceeded has thousands of pages which will correctly display "Page exceeded the expansion depth" when they are previewed. PrimeHunter (talk) 22:10, 13 May 2012 (UTC)
Implementing a template that routinely violates such a limitation (by "routinely" I mean, violates the limit when transcluded at or near a depth implied by its intended functionality) is itself a coding error which must be detected and corrected during testing. That is what we have sandbox and testcases pages for. --Mirokado (talk) 22:20, 13 May 2012 (UTC)
But there's a difference between a template which when used once (i.e. not nested) generates such an error and one like {{clade}} is designed to be used nested, i.e. like this:
{{clade |1=leaf1 |2={{clade |1={{clade ... }} ... }} ...}}
We can't re-write {{clade}} to prevent an editor nesting it more than 19 times; the documentation only can advise not doing so and suggest checking the message during preview. Peter coxhead (talk) 22:54, 13 May 2012 (UTC)
Thanks for the recap. FWIW, the expansion depth problem goes away in the Southwest Chief article I mentioned if I take out the route map, which suggests the problem is in either {{Infobox rdt}} or {{Southwest Chief}}, probably the latter (or perhaps a design issue about the layering of templates). Same problem with Adirondack (train) and {{Adirondack}}. I see no consensus that this matters, but if it does, maybe a template editor active in WP:RR might be interested in tackling it. 68.165.77.170 (talk) 03:26, 14 May 2012 (UTC)

Remove rollback from watchlist now gone

Now the script to remove the rollback feature on the watchlist seems to be broken. Truthkeeper (talk) 18:43, 13 May 2012 (UTC)

see WP:CUSTOMWATCH, there is a CSS hack which works (at least here). mabdul 22:00, 13 May 2012 (UTC)
That's the one I'm using but it stopped working today. Truthkeeper (talk) 23:30, 13 May 2012 (UTC)

Scansion markup

This is a pre-request for new (or altered) markup. Meaning, I think it's worth-while for technical people to vet the request while I make sure (on our end) that we're really requesting what we want. (Anomie has kindly helped me clarify several details, but of course if this description is incompetent you must blame me!)

Background

WikiProject Poetry is reviewing standards for graphically displaying scansion. Our current best practice uses monospaced characters signaled by line-initial spaces, thus:

× / × / × / [/] × / × / × / [/] There is beyonde the Alps, | a towne of auncient fame [1]

But there is some frustration that these lines cannot be better integrated into regular text (e.g. eliminate the box and shading, and allow indentation), while retaining WYSIWYG editing. Line-initial spaces, <tt>, <pre>, and <poem> all provide some, but not all of the necessary functionality. Of all these markups, <poem> seems to come closest to our requirements, so we take that as the "foundation" of the following discussion.

There seem to be 2 paths which can provide the features we would like to see:

  1. ^ Brooke: Romeus and Iuliet, 1

Path 1: tweak <poem> functionality

<poem> will do exactly what is needed IF: multiple line-internal spaces can be made to render literally, just as multiple line-initial spaces currently do. Our full opening code would then be:

<poem style="font-family:Courier;margin-left:2em">

Pros: It could be argued that <poem> should in principle render line-internal spaces, irrespective of its convenience for scansion: some modernist poems like the first published version of Pound's "In a Station of the Metro" implicitly require wide line-internal spaces, and multiple space characters may be easier to handle editorially than e.g. {{pad|1em}}

The apparition   of these faces   in the crowd  :
Petals   on a wet, black   bough   . [1]

Cons: Altering the <poem> standard could mess up any number of existing implementations which rely on its current formulation. Also since scansion is its own thing, it is probably appropriate for it to have its own markup.

Path 2: new markup

A new markup can be developed... presumably tagged with <scan> or <scansion> if these are available. We assume it will be based on <poem>, but that of course is up to the developer. The requirements would be:

  1. Render as monospaced characters (e.g. Courier) : <poem> currently supports as an optional "style" element. In the new scansion markup, this should be the default
  2. Render multiple line-initial spaces literally : <poem> currently supports
  3. Render multiple line-internal spaces literally : <poem> currently does not support
  4. Render single line-breaks literally : <poem> currently supports
  5. Render some possibly-reserved characters literally (these include "|", "/", "\", "[]", "()") : <poem> currently supports
  6. Render markup (e.g. <ref>) as markup, not literally : <poem> currently supports
  7. Allow the application of a left margin : <poem> currently supports as an optional "style" element. In the new scansion markup, there might be a default left margin (of, say, 2 em), but it should also be adjustable using "style".

Thanks for your consideration. Phil wink (talk) 17:55, 6 May 2012 (UTC)

I can check a database dump and see if any existing <poem /> instances would be likely to be affected by the first path (they might be affected if they have multiple spaces?). I don't think the second path (adding another element to the parser) is likely to be popular with the developers, nor do I think it's necessary. Cheers, — madman 05:19, 13 May 2012 (UTC)
Phil wink, please check the Wikimedia developers' mailing list, the mailing list for discussion of wikitext markup, and the tech request tracker -- you might get more discussion and interest regarding this proposal if you use one of those media to discuss this proposal with developers. You can also get developer access to suggest changes directly via the Git source control system. Best wishes. Sumana Harihareswara, Wikimedia Foundation Engineering Community Manager 08:00, 14 May 2012 (UTC)

Vector beta testing skin

It seems we don't have a good system for determining whether people will actually like changes prior to their implementation. I propose creating a Vector Beta skin. Developers can announce that a beta change has been made there, and editors can switch to it to try out the changes and provide feedback. What say you? Equazcion (talk) 21:44, 10 May 2012 (UTC)

  • Perhaps this could become the true meaning of the "exclude me from feature experiments" option in our preferences. Support.--Jasper Deng (talk) 21:47, 10 May 2012 (UTC)
  • Doomed to fail. There will never be a change that will be supported across the board; it is simply impossible. Edokter (talk) — 21:49, 10 May 2012 (UTC)
    • No one said unanimous approval was required. This would however avoid changes that are clearly unpopular, as were the first two that occurred today. Trial-and-error in a live environment isn't a great idea, as most developers should be aware. A beta program is always better. Equazcion (talk) 21:53, 10 May 2012 (UTC)
  • Are you including English Wikipedia admins as "developers"? --Yair rand (talk) 21:49, 10 May 2012 (UTC)
  • Support. I'd get killed if I carried out testing in our live environments, the way someone is doing it here. Get a test environment, and a pool of testers. That way at the very least, you'll get fast feedback on the "god, that hurts the eyes" type changes, and you have an opportunity to point people at what you are trying to do. It's hitting reload and having it look different without warning that is the problem here. Elen of the Roads (talk) 22:33, 10 May 2012 (UTC)
    • Good idea in principle but carries significant risk that the pool of testers suffers from selection bias. Beta tests should be open and widely advertised, or sadly like too many areas here become the "property" of a small interested but not necessarily neutral group of editors who may then claim that there small sample size represents consensus for wide reaching changes. Look at the discussion at Wikipedia:Village pump (proposals)#Watchlist bolding about this very set of changes to see the argument about "you didn't participate in the original discussion therefore you cannot/should not complain when a change is introduced". A discussion that doesn't appear to have been participated in by more than 2 dozen users yet affects every single editor on this wiki. One of the best things about WP is that it is the encylopaedia everyone can edit but that can also be one of it's biggest faults. I project manage software development for a living and if I enacted changes especially big visual changes without thorough consultation with end users first, I'd either be jobless or have developed rhino skin - hopefully it's still neither. NtheP (talk) 22:59, 10 May 2012 (UTC)
      • Changes and instructions for participating in the beta could be advertised via those dandy watchlist notices. Equazcion (talk) 23:02, 10 May 2012 (UTC)
@NtheP, I was envisaging an open pool of testers - anyone who was interested and would keep hitting refresh for an hour while Erwin fiddled with it - and also that having carried out the initial trial, the test environment could then be available for anyone to look at and comment for a short period before implementation.Elen of the Roads (talk) 23:11, 10 May 2012 (UTC)
That's fine but I think the durations might need to be longer due to the global nature of this community. Let's say I wanted to be really sneaky and make Australian English the default language (I know not a css issue) I could skew the beta test period to be when most US & European editors were asleep and gain my consensus that way. NtheP (talk) 08:48, 11 May 2012 (UTC)
  • Strongly support - Beta testing changes in a live environment is like painting a giant bulls-eye on you, having neon arrows pointing towards said bulls-eye with 1KM high letters within saying "SHOOT HERE" and being surprised when you end up with a nuke dropped on you! Having a separate beta which is not the actual live environment that EVERYONE sees by default makes quite a lot of sense. Barts1a / Talk to me / Help me improve 01:30, 11 May 2012 (UTC)
Collapsed an exchange regarding the watchlist change, rather than this proposal
The following discussion has been closed. Please do not modify it.
  • Well, most of this stuff *is* beta tested - how many people who have posted here today on this page have *ever* participated in beta testing of various features? The bolded watchlist has been enabled on quite a few projects for a while, for example; it's not like it's an unknown quantity. The green stars I missed entirely, though. Risker (talk) 02:30, 11 May 2012 (UTC)
    • ...and yet it wound up causing problems anyway, was hastily changed, twice, reverted, then implemented again. Maybe beta testing even for features already implemented on other projects is still a good idea for the largest project of them all. Equazcion (talk) 02:35, 11 May 2012 (UTC)
I'm not sure it caused problems. It caused complaints. From what I read above, the green stars weren't part of the original design and were implemented because people complained about the original design; if that is correct, then perhaps that part was a little hasty and off-the-cuff. So, will you be participating in beta testing in the future? To be perfectly honest, the beta testing had already been done, and there does not appear to be any technical issue with it, only a difference in taste. It looks like almost as many people have posted above that they *like* the change as don't like it, which is actually unusual in that most people who like changes don't bother to comment at all. Risker (talk) 03:13, 11 May 2012 (UTC)
The complaints are the problem. It is symptomatic of the community being caught unawares although this change to the watchlist is ironically supposedly a 'community decision'. How to fix? The change to vector skin was well handled, so maybe that's the model to pursue. --Ohconfucius ¡digame! 03:48, 11 May 2012 (UTC)
I would debate that. This is more WP:IDONTLIKEIT than anything else; the fact that there are so many people saying "thanks for this change" says an awful lot. I'm hard-pressed to think that the massive amount of publicity that came before the really major change to the Vector skin should be required for a comparatively minor change like how the watchlist reads; for that matter, lots of people complained about all the publicity at the time, despite the fact that the change still came as a shock to many. In the past couple of years, we've had at least three other equally significant changes to the watchlist with no more discussion than what happened here. The Vector skin change affected the interface for *all* logged-out users/readers, and became the default skin. Do you really think that a change to how the watchlist reads (affecting perhaps a few thousand active editors) is a change of the same magnitude?

Realistically, the issue here is that we do not have a centralized place where people can keep up with anticipated changes without having to swim through walls of text arguing for or against something. I'm not surprised in the least that this change has not been rolled back; revdelete wasn't either, despite the fact that the community was in the middle of an RFC to reconsider the previously filed bugzilla at the time that revdelete was installed. Risker (talk) 05:02, 11 May 2012 (UTC)

Yes, this is IDONTLIKEIT. Of course, since this isn't a deletion discussion or even an article issue, the essay link doesn't really fit. "I don't like it" is a perfectly reasonable argument against interface changes. There are no policies to follow there -- the interface should reflect what people will find the most useful. Equazcion (talk) 05:05, 11 May 2012 (UTC)
This one is not so much a matter of a beta; it's the implementation process that's flawed. Yes, I've already stated for the record that I don't like it. Previously, every tenth or so click of mine was for the watchlist, now I don't want to go there any more until the worst is disabled. I also put forward a model of how the process could work better in future, but you think that's a 'sledgehammer' for our 'nut'. You have to admit that the changes to vector were quite a bit less radical, and in addition it turned out to be a bit of a damp squib compared to what was billed. Such change to a watchlist is very largely a matter of form, but its visual impact is nothing short of dramatic. I know there's no pleasing everyone; this one is a 'love-it-or-hate-it'. Surely it is time to make this an opt-in, and urgently? --Ohconfucius ¡digame! 06:23, 11 May 2012 (UTC)
  • Comment, dunno if I missed something, but since the Watchlist is a feature of all skins, we would need a beta skin for all skins. (nostalgia, modern, monobook, etc.) (oh and support) mabdul 12:47, 11 May 2012 (UTC)
  • Support Surprising features and changes that break established functionality should be kept to a minimum. Having a beta skin seems like a good way to test many changes (and announce implemented features to the community) without breaking the 'pedia. --Philosopher Let us reason together. 20:14, 13 May 2012 (UTC)
  • Support I sometimes like to use betas if they're reasonably stable. When it's something I use regularly, it makes an interesting variation, and I like to see ahead what might be coming--not just as a discussion of it, but the intended implementation. But I also want to know what I'm doing, so if I am doing something important I want to do as quickly and routinely as possible, I can use the regular program and count on everything being the same as usual. DGG ( talk ) 21:57, 13 May 2012 (UTC)
  • Strongly support: major changes should not go live without testing. Some major changes require direct user experience in the editing environment before they can truly garner consensus. Fifelfoo (talk) 02:19, 15 May 2012 (UTC)

section headings on transcluded pages

Hello all: The page Wikipedia:Articles for deletion/Mitt Romney Cranbrook incident (or any other AFD page) is transcluded at various other pages, such as Wikipedia:Articles for deletion/Log/2012 May 11. However, If there are top level section heading in an AFD page, the page where it is transcluded puts all these sections as separate headings. This results in the sections of an AFD page transcluded as seperate AFD entries.
Question: What is the the correct way for section headers on pages that are transcluded? EngineerFromVega 07:25, 14 May 2012 (UTC)

All subsequent headings on AfD pages should be subsections of the first level 3 heading. I have fixed it.[5] PrimeHunter (talk) 11:42, 14 May 2012 (UTC)
Thanks very much. EngineerFromVega 06:29, 15 May 2012 (UTC)

Mysterious sorting

  Resolved

Please assist Somehow, Voiced pharyngeal fricative is sorted *, which I found in Category:Articles containing non-English language text. Can someone properly sort it? Thanks. —Justin (koavf)TCM 09:04, 14 May 2012 (UTC)

Fixed. {{Approximant-fricative}} should not have contained {{DEFAULTSORT:*}} outside of a <noinclude>...</noinclude> element. — Richardguk (talk) 12:48, 14 May 2012 (UTC)

Problem with thumbnail preview

Hi. I have problem with this image: http://commons.wikimedia.org/wiki/File:Kalmykia03.png The last thumbnail shows the old image version from 2006 instead the latest one, and old version could be also seen in the articles which using this image: http://en.wikipedia.org/wiki/Kalmykia#History I tried to purge the page (in accordance with this guideline: http://en.wikipedia.org/wiki/Wikipedia:Purge ), but it does not work. I had similar problems with some other images over a year ago and I think that these images fixed themselves in few weeks after the upload. However, is there some faster way of updating last image thumbnail? PANONIAN 09:53, 14 May 2012 (UTC)

OK. Forget this post - problem was solved somehow (although, I have no idea how). PANONIAN 12:25, 14 May 2012 (UTC)

Which ISO 15924 template?

I asked this at the help desk and was told to bring it here...

I need to import a template to Wikibooks that will turn a name of a script into its ISO 15924 code. (For example, LatinLatn). There are many ISO 15924 templates on Wikipedia, but I am not sure which one does what I want. Please advise on the one that will best do what I want. Thanks,  Liam987  14:16, 10 May 2012 (UTC)

 Liam987  13:53, 14 May 2012 (UTC)

I think you will need to modify an exsiting template such as {{ISO 15924 alias}}. Copy the wiki-text to a text file, swap the parameter/value pairs, and save the new template with an edit summary like "Saving new template based on [[:en:Template:ISO 15924 alias]]". Note that the inter-wiki link may need to be modified. – Allen4names 16:02, 14 May 2012 (UTC)
Thank you, that is exactly the template I needed.    Liam987  16:26, 14 May 2012 (UTC)

Template formatting

Is there any website where you can study formatting for creating new templates? Im not interested in any already present templates. Pass a Method talk 17:35, 14 May 2012 (UTC)

If you mean testing template code and it's for potential use in Wikipedia then you can do it in user subpages, for example Special:MyPage/sandbox, Special:MyPage/sandbox2, Special:MyPage/sandbox3, ... See Help:Template for how to make template code. PrimeHunter (talk) 20:16, 14 May 2012 (UTC)

Updating numbers of edits on the Home page

Hi

Is there any reason why the numbers of edits on the WP home page (The one with the globe) is stuck and does not update automatically? Just now the English language is showing some 40,000 pages less than it really is! Thanks Apwoolrich (talk) 19:45, 14 May 2012 (UTC)

All Wikipedia pages have a globe. I guess you mean http://www.wikipedia.org/ although it doesn't show number of edits. It shows number of articles. For English it says "3 907 000+ articles". That notation with "+" means at least 3 907 000. I don't think the page is supposed to be updated continually. The HTML source at English says in a comment "Rankings from http://stats.wikimedia.org/EN/Sitemap.htm (data from 31 January 2012)". PrimeHunter (talk) 20:08, 14 May 2012 (UTC)
If you are wondering why it doesn't just use the same update system as the top of Main Page then that number is made with the magic word {{NUMBEROFARTICLES}} which is available in wiki pages but not at http://www.wikipedia.org/. {{NUMBEROFARTICLES}} shows the number of articles in the wiki where it's used. PrimeHunter (talk) 20:23, 14 May 2012 (UTC)
Actually, it's updated by a wiki page at meta:Www.wikipedia.org template, so you can request an update to the current totals on that talk and /temp page. MBisanz talk 20:26, 14 May 2012 (UTC)

Navigation popups

Has anybody else's navigation popups stopped working? Mine were working at lunchtime today, but now aren't working at all. I haven't changed any scripts/browsers/any other factor I can think of. (IE9) --Gilderien Chat|List of good deeds 19:20, 14 May 2012 (UTC)

Yeah, there was a bad change - just a typo I think - so I've reverted until MSGJ can redo the edit minus said typo. - Jarry1250 [Deliberation needed] 19:27, 14 May 2012 (UTC)
Oh, thanks, it seems to be working again now :-).--Gilderien Chat|List of good deeds 19:29, 14 May 2012 (UTC)
  • Navigation popups aren't working for me now. Anybody else?
  • Also, the edit toolbar seems to be on the blink of late. Sometimes it appears, sometimes it doesn't. JN466 13:13, 15 May 2012 (UTC)

Move summary

I am unable to leave a summary when moving a page. Anyone else having this problem? The form doesn't accept text on my browser. — Martin (MSGJ · talk) 20:48, 14 May 2012 (UTC)

It works for me and many others at Special:Log/move. What is your browser? Does it display a "Reason" field? What happens when you click in the field? Try to clear your entire cache. PrimeHunter (talk) 22:28, 14 May 2012 (UTC)
The move reason field is broken in Opera as of mw1.20wmf2, something about an errant javascript or some such preventing any input. Someone who feels comfortable doing so should submit a bugzilla thingy. -— Isarra 05:27, 15 May 2012 (UTC)
Yes, it was opera I was using. Thanks for the information. A bug should certainly be submitted. I'll take a look. — Martin (MSGJ · talk) 14:03, 15 May 2012 (UTC)

newikipedia.org

Does anyone know anything about this? It isn't Wikipedia, but I don't see it listed in Mirrors and forks--SPhilbrick(Talk) 21:10, 14 May 2012 (UTC)

This is a new mirror, but the logo use constitutes a trademark violation.--Jasper Deng (talk) 22:07, 14 May 2012 (UTC)
Michelle Paulson, Wikimedia's Legal Counsel has been sent an email about this, so the Legal and Community Advocacy (LCA) team are working on it. Thanks. The Helpful One 22:18, 14 May 2012 (UTC)
Yes, I sent it to her, or maybe one of more than one. However, I was surprised to see the new message banner pop up, something I've never seen on a mirror.--SPhilbrick(Talk) 22:25, 14 May 2012 (UTC)
Makes me want to think that it is a mirror that simply iframes Wikipedia with some modifications (the changes made to the HTML are not that hard to make via scripting). This is the kind of mirror that the WMF hates.--Jasper Deng (talk) 22:27, 14 May 2012 (UTC)
Also on that I dislike. What is the purpose of all that orange highlighting and I assume Chinese writing?  Hazard-SJ  ✈  02:28, 15 May 2012 (UTC)
It's Japanese. Pass it through Google translate; it's way odd. --jpgordon::==( o ) 05:02, 15 May 2012 (UTC)

Legal issues aside, it's actually kind of cool. Click on an English word, and you get the Japanese definition for it. Orange Suede Sofa (talk) 06:14, 15 May 2012 (UTC)

There are web services such as rikai.com or zurukko.jp that add similar functionality to any web sites. I don't see a point for creating a Wikipedia specific service. --Kusunose 08:04, 15 May 2012 (UTC)

Jpgordon: Pass any Japanese text through Google Translate, and the results are likely to be odd (and occasionally hilarious). Jafeluv (talk) 10:38, 15 May 2012 (UTC)

Tables not sorting

List of beaches in Hawaii seems to have been set up as sortable tables within the sections. But nothing sorts. Any clues?Maile66 (talk) 13:36, 15 May 2012 (UTC)

Check out the edit I just made. The class should be "wikitable sortable". I also removed the inline CSS that defines the style for the header row – this overwrote the wikitable sortable styling so the sorting was removed. I've only fixed one section, but feel free to go ahead and do the others. matt (talk) 13:49, 15 May 2012 (UTC)
Help:Table#Sorting should help too. You can also specify which columns are not sortable. matt (talk) 13:52, 15 May 2012 (UTC)
And note the exclamation marks used to distinguish header cells in the first row from data cells in subsequent rows. (Also, it's probably best not to specify the widths at all, as different readers will have browsers with very different screen widths.) — Richardguk (talk) 14:00, 15 May 2012 (UTC)
Thank you both. It would appear the exclamation marks by themselves were the bugger. I've created some tables, but when something doesn't work, I know what I did. It's harder to spot something like this after-the-fact tables-by-committee contributions over the years. Thanks a lot.Maile66 (talk) 14:06, 15 May 2012 (UTC)

Problem with the site

Site look weird to anyone else right now? My toolbar's missing and there's a 24 at the top of the screen. The skin just plain isn't loading. Ten Pound Hammer(What did I screw up now?) 01:18, 16 May 2012 (UTC)

I just got this too, affected here and www.wikipedia.org for sure. Skin sometimes failed to load, but not always. Seems gone now. Looking at the source code for I think it was www.wikipedia.org, there was a 24 appended at the very beginning of the file like so:

24<!DOCTYPE html>

Chris857 (talk) 01:22, 16 May 2012 (UTC)
  • It's happening to me as well. --Ixfd64 (talk) 01:19, 16 May 2012 (UTC)
  • It's loading fine for me now, but comments on #wikipedia-en show it's still off for some people. Ten Pound Hammer(What did I screw up now?) 01:21, 16 May 2012 (UTC)
  • The 24 is gone but I am losing navigation bars and javascript. Was kicked out of my AWB as well. Said server connection errors. If it occurs again I will post the specific error. ChrisGualtieri (talk) 01:21, 16 May 2012 (UTC)
  • Yeah it's just a few seconds at a time. Seems to screw up RFC bot's notifications, causing it to blank pages? [6]. Equazcion (talk) 01:24, 16 May 2012 (UTC)
If its doing that, why not shut off the bot if its blanking pages repeatedly? Its done a bunch. [7]ChrisGualtieri (talk) 01:27, 16 May 2012 (UTC)
It seems to be okay now. I think it only happens when the glitch occurs. I rolled back the affected edits. Equazcion (talk) 01:29, 16 May 2012 (UTC)
  • Got beaten to the reverts. Seems like the matter is fixed. I'm not on IRC, but I assume ChrisG knows about it? (We are different people, btw) ChrisGualtieri (talk) 01:32, 16 May 2012 (UTC)
There's currently an issue with the API servers which Tim Starling is working on. This is intermittently affecting Bots and various scripts and gadgets that use the API like Twinkle, ArticleFeedback, WikiLove, etc. This is completely separate from the '24' issue, which I imagine was accidentally caused by an admin on meta, but I haven't looked into it. Kaldari (talk) 04:21, 16 May 2012 (UTC)
Should be resolved now. Kaldari (talk) 06:17, 16 May 2012 (UTC)

New "diff" view is horrible and illegible

Please restore the normal "diff" view in bright colors that was so easy to read and discern. This new one with pale blue and even paler beige and otherwise white is ridiculously difficult to read, much less scan. Why do these things get tinkered with without discussion or rhyme or reason? It was perfect the way it has been for years so please restore it. Softlavender (talk) 03:25, 24 April 2012 (UTC)

See #Diffs. You can change back to the old style of diffs by using a gadget, but I think it's unlikely the devs will change the default diff view back. Jenks24 (talk) 03:30, 24 April 2012 (UTC)
Why using a gadget? When it was so much pretty easy before. It is like "Ok, we broke it but here you are a fixing "gadget"" :) this is ridiculous. --Aleksd (talk) 07:07, 27 April 2012 (UTC)
The default behaviour of the diffs was altered by some of the MediaWiki developers (a.k.a. "the devs"). So far as I know, they have not yet said that they "broke it", nor have they offered a gadget in replacement. There is a new gadget, yes, but it was not written by the devs. It was put together by Edokter, a regular contributor to this page. I expect that he noted the many comments, or disliked the new appearance himself - either way, he actually went and did something about it instead of just complaining. --Redrose64 (talk) 20:27, 27 April 2012 (UTC)
Why was it changed? Why won't they change it back? Softlavender (talk) 03:35, 24 April 2012 (UTC)
Someone who follows the mailing lists and so on will probably be able to give you a better answer, but my understanding is that the WMF developers have been trying to make an "improved" diff view for some time now (I believe there were concerns about the old red/green being difficult for people with colourblindness, but don't quote me on it). Anyway, the new diff viewer has been released as part of the mediawiki 1.20 rollout. I'm not saying the devs definitely won't change it back, but I've watched the last few mediawiki rollouts (from maybe 1.16 onwards) and the devs generally don't reverse something unless it's unambiguously wrong – if it's just a preference, and even if that preference is supported by a consensus of editors, they generally won't reverse it because their preference trumps ours. Jenks24 (talk) 04:11, 24 April 2012 (UTC)
I'm all for improvements, but how the heck is this an improvement? Viriditas (talk) 09:38, 24 April 2012 (UTC)
(edit conflict)I wish that this could be a preference option, especially since I find the coloring easier on my own eyes. For now, you can use the "enhanced diff view" gadget (see the Gadgets section of your preferences).--Jasper Deng (talk) 03:32, 24 April 2012 (UTC)
Not clear which preference you are referring to, or which is easier on your eyes. Softlavender (talk) 03:35, 24 April 2012 (UTC)
I mean, I don't mind, but I feel that the diff colors should be something users could set in their preferences.--Jasper Deng (talk) 03:37, 24 April 2012 (UTC)
OK, but for the record, which coloring is easier on your eyes? Softlavender (talk) 03:54, 24 April 2012 (UTC)
The new one.--Jasper Deng (talk) 04:33, 24 April 2012 (UTC)
Of course it is easier on the eyes. And that means, you can't tell what content was changed or removed! Is anyone home? Viriditas (talk) 09:48, 24 April 2012 (UTC)
I also have to ask, Why was this changed? The new diff approach has scrollbars, no idea why, barely visible colorations, and no advice on how to modify these things back. Just change it back and to quote Wikipedia... get CONSENSUS from the community for the change. Forcing it into the project without adaquate explanation isn't a good approach. -- Avanu (talk) 04:05, 24 April 2012 (UTC)
Also, quoting Jenks24 above, who said it is "unlikely the devs will change the default diff view back". If they won't change it back by simple request, then how do we begin a formal request to undo this change? -- Avanu (talk) 04:07, 24 April 2012 (UTC)
The developer community is mostly separate from our community here.--Jasper Deng (talk) 04:33, 24 April 2012 (UTC)
well, as far as I can remember Jimbo has a talk page here, so they are not some separate entity that may not be contacted in no way or should not be questioned on their 'design' :) Besides my own vision is that when you do something you should be interested of how it affects people, that mean in coding too. So they should probably better have some way of getting information of editors visions. --Aleksd (talk) 07:29, 27 April 2012 (UTC)

I wanted to give myself some time to get used to it, but so far I find the new color scheme much more difficult to scan. Before I could just glance at the diffs to get an overall impression. Now I have to study them. — kwami (talk) 04:09, 24 April 2012 (UTC)

Ugh. I completely agree with you, kwami. You know, this also bugs me because I often have to contact OTRS "customers" and abuse-contacts for ISPs, and it's easy to tell them, the text that changed within a paragraph is highlighted in red. Now I guess I'll tell them, what? The text that changed is highlighted in a slightly different color from everything else? Maybe this is just five years of conditioning on my part, and I'm coming off as an old fart, but I'm glad they at least let us switch back. Someguy1221 (talk) 04:21, 24 April 2012 (UTC)
In theory, I like that it shows the addition or removal of spaces, but in practice the shading is so light that I have to peer really closely to find it. I wonder if this couldn't be tweaked to a slightly darker shade. (My vision and color vision are normal.) Rivertorch (talk) 04:28, 24 April 2012 (UTC)
Count me in the "me too" category. I saw the change suddenly this afternoon, then saw the section mashed in with everything else up above, and I said "ok, I'll give it a shot and see if I adjust to it". Unfortunately, I think that the concerns brought up regarding accessibility are valid, since myself and apparently many others share them (which is ironic, considering that accessibility is one of the main reasons to change it). This isn't my first exposure to this diff engine either, since I've seen it on the MediaWiki server for a while now, so it's not as though this is just shock at any change speaking. I'm certainly surprised to see the new diff code in use here though, since the version on MediaWiki seemed so obviously "not ready for prime time". I guess that I should have said something earlier, but I had no clue that rolling it into the updated version of the software was even being considered. Someone seriously dropped the ball on this one.
— V = IR (Talk • Contribs) 04:32, 24 April 2012 (UTC)

Ranting won't help; just have a poll and change it back via Common.css Choyoołʼįįhí:Seb az86556 > haneʼ 04:51, 24 April 2012 (UTC)

Sometimes it does. In 1.19 they rolled back the diff color changes. [8] Killiondude (talk) 04:55, 24 April 2012 (UTC)
I don't think that we're "ranting" at all.   This was all done through CSS? That's more information about this change than has been available before now... and I suspect that it's not the whole story.
— V = IR (Talk • Contribs) 04:57, 24 April 2012 (UTC)
No, it wasn't done via css, but can be "un-done" via css. That was a comment to the people who claim we are slaves to the devs. We're not. Choyoołʼįįhí:Seb az86556 > haneʼ 05:00, 24 April 2012 (UTC)
I don't think that (using CSS to "undo" these diff changes) would be wise at all. Creating a situation where the "left hand" is undoing the work of the "right hand" is never the way to go. We'r enot slaves to developers at all, but if nobody gives them any (constructive) feedback then they're just going to do whatever they think is best.
— V = IR (Talk • Contribs) 05:37, 24 April 2012 (UTC)
The change was done using CSS actually. No changes were made to the diff engine. Edokter (talk) — 09:45, 24 April 2012 (UTC)

Well, personally I think the new diff view is much better than the old one. Some changes, especially if they included for example only the removal of a single character, such as a . or , were barely visible and this can be seen much better in the new diff view. -- Toshio Yamaguchi (tlkctb) 05:52, 24 April 2012 (UTC)

It's shit, but you can change it back via your Preferences. Problem solved. Lugnuts (talk) 09:04, 24 April 2012 (UTC)
Problem solved for editors who just so happen to visit this page at this particular time. Which is what, 0.001% of editors? Softlavender (talk) 09:12, 24 April 2012 (UTC)
Quite right Softlavendar. Lugnuts' response is a little "I'm alright Jackish". This strikes me as one of those changes that looks great on the 50cm desktop screens the developers used, but hasn't been subjected to any usability testing on netbooks. And what's the reason for the change? HiLo48 (talk) 09:29, 24 April 2012 (UTC)
I don't think any explanation has been given, but numerous editors have guessed that it was made to accommodate the colourblind. If that is true one wonders why it couldn't have been the other way around, making it so if you had problems viewing coloured difs on account of colourblindness you could change it in your preferences, considering that at most the colourblind make up 10% of the editors. --Saddhiyama (talk) 09:35, 24 April 2012 (UTC)
"Lugnuts' response is a little "I'm alright Jackish"." Got it in one! Lugnuts (talk) 12:54, 24 April 2012 (UTC)
Oh, common, they change coloring for color-blinded people who cannot see it anyway (there is still red on it)? Should listen to your own logic. And by the way... nobody can see it now... :) that's king of a "successful solution against display discrimination". Adding a '+' to the old view should have been pretty much enough. And what do you mean by developers, this is design, are the developers making design here or designers? Must make it clear. --Aleksd (talk) 07:44, 27 April 2012 (UTC)
(ec) The change was prompted by the fact that red-on-green is incredibly hard to pick out for a non-negligible proportion of humanity (and for another chunk, red-on-yellow lacked the requisite contrast). And no, it wasn't trialled exclusively on 50cm screens, but yes, I'm sure if there are suggestions for tweaking the CSS to display better on narrow screens, they've get adopted. To answer the other points, people who don't like it will come to this page, and will find the instructions on how change it, believe me. Personally, I like the new style. - Jarry1250 [Deliberation needed] 09:40, 24 April 2012 (UTC)
Bullshit. Most people who don't like probably don't even know this page exists. Massive arrogance/ignorance/lack of perspective on display there. HiLo48 (talk) 20:51, 24 April 2012 (UTC)
Gee, lovely tone you've got there. As someone who routinely helps out on all manner of help desks around Wikipedia, I can only try to reassure you that people who query these kinds of changes anywhere publicly do get an informative response. Admittedly, that leaves two issues (i) if you think that new editors won't know what they're missing (ii) existing editors who notice, don't like the new style, but have no idea how to query that (or know how but don't bother looking into it. I think (i) is genuinely pertinent, (ii) less so. - Jarry1250 [Deliberation needed] 20:59, 24 April 2012 (UTC)
It's nice that you help people elsewhere. That you see any point in doing that just further shows the silliness of saying "people who don't like it will come to this page..." Most won't. They'll just say to themselves "Yet another unexplained, silly IT change that I never asked for and can't see the point of", be annoyed, and get on with their, now ever so slightly more difficult, lives, thinking even less of IT professionals. NOTE: I'm one too, and I would prefer our image to be improving. HiLo48 (talk) 21:15, 24 April 2012 (UTC)
Worst change ever. Viriditas (talk) 09:42, 24 April 2012 (UTC)
For those (eg Toshio Yamaguchi) who have trouble seeing small changes (eg single character, especially punctuation) but want the old diff scheme: try using wikEdDiff or wikEd (under Preferences, Gadgets, Editing), which give a little "delta" button that shows a "better" diff - I find it helps locate small changes. Mitch Ames (talk) 13:18, 24 April 2012 (UTC)

This has been available as a preference since 21:34 UTC yesterday; you need to switch on Preferences → Gadgets → Display diffs with the old yellow/green colors and design. --Redrose64 (talk) 11:10, 24 April 2012 (UTC)

  • In my view, I think the ideal solution would be prefs so people can set their own colours. For me, the new colours work fine and I find them easy to see, but everyone's eyes are different and no fixed colour scheme will please everyone. But apart than the colours, I think the functional changes to the new diff are a great improvement - it's really good to finally be able to see single-character changes and the addition/removal of white space quickly. -- Boing! said Zebedee (talk) 11:56, 24 April 2012 (UTC)

Change it back. New one is much much harder to read. Color is very useful and most computer screens are now color so it's not too radical of an idea to use color, no need to take out color indication of changes.  :-) North8000 (talk) 12:08, 24 April 2012 (UTC)

I also dislike the new default diff. As well as the colours being harder to read (for me), it takes more vertical space. (This example uses 25% more vertical space on my screen.) My eyes are not good, so my video is configured for larger and thus fewer pixels on the screen - extra space used by the coloured border means less text fits on the screen. Mitch Ames (talk) 13:11, 24 April 2012 (UTC)

Btw, the new scheme becomes illegible for people with yellow-blue blindness. If MediaWiki is aiming for the minority then why not aiming for the absolute minority and change it back to a red-green scheme so people with yellow-blue blindness can read the diffs again properly? :) Nageh (talk) 13:25, 24 April 2012 (UTC)

Instead of leaving the default for the average person they handed out eye patches to everyone, incl. the one eyed ones (a minority served at cost of another minority).TMCk (talk) 13:27, 24 April 2012 (UTC)

I don't like the new Diff, but calling the old Diff "better" is like saying that, of the Three Stooges, Curly is the intellectual Stooge. Why do I have to scan an entire paragraph to find that someone changed two spaces to one? See https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Arbitration/Requests/Case/Race_and_intelligence/Review/Proposed_decision&curid=35089626&diff=488988825&oldid=488988590 for an example of the new Diff getting it right (but with hard-to-see pastel shading). --Guy Macon (talk) 15:31, 24 April 2012 (UTC)
Having viewed your linked diff with both the old and the new style I can't really see where it is that the new style is supposed to be getting it right? The edit was just as visible (more of course on account of the colour scheme) with the old style. --Saddhiyama (talk) 15:37, 24 April 2012 (UTC)
Can you give an example of the diff generator getting it wrong for comparison? - Jarry1250 [Deliberation needed] 15:38, 24 April 2012 (UTC)
The new diff "look" sucks. Please don't force us into it! and make it obvious for new users they have a choice. Electron9 (talk) 19:01, 24 April 2012 (UTC)
I think the last thing newcomers would have on their minds would be the colors of the diffs. --MuZemike 19:29, 24 April 2012 (UTC)
I really don't like the dismissive "there's a gadget!" attitudes here. There's a problem, let's deal with it. Quit trying to dodge the issue and dismiss everyone's concerns, and lets have a discussion in order to come up with an actual resolution. I've removed the condescending "note" that someone placed at the top of this section, since that's not what the section is about, and we all know that there's a gadget already.
— V = IR (Talk • Contribs) 19:02, 24 April 2012 (UTC)
Actually, someone else was arguing they didn't think the availability of the gadget was obvious enough; I'm not sure I can square those two sentiments.
In any case, the availability of said gadget means we could indeed have an informed debate abut the default setting, safe in the knowledge that no-one is bound by that. Maybe even a poll. (Yay, it's Vector all over again.) - Jarry1250 [Deliberation needed] 20:17, 24 April 2012 (UTC)
So we need to get developer crappy screens to test with, preferable at 800x600 or 1024x768 resolution. — Dispenser 23:55, 24 April 2012 (UTC)
Add me to the list of those who hate this change! While there is an improvement in seeing some changes that were not really visible before, the use of colors makes the new screen virtually useless! If anyone really thinks that this is actually an improvement, make it optional so that those who want it can use it. Vegaswikian (talk) 21:52, 24 April 2012 (UTC)
It is optional - in gadget prefs, "Display diffs with the old yellow/green colors and design" -- Boing! said Zebedee (talk) 22:23, 24 April 2012 (UTC)
Default is not optional. --Aleksd (talk) 07:58, 27 April 2012 (UTC)
  • Just in case any devs are reading this thread, I have to agree: it's pretty terrible looking. I'm going to change it back to the old style view. Be sure to let us know if you make any major changes to it, so that we can try it out again. ‑Scottywong| gossip _ 23:08, 24 April 2012 (UTC)
  • I just want to say that the css code listed earlier that adds a red-green style with a colored background is a big help. Chris857 (talk) 23:11, 24 April 2012 (UTC)
Developers, these shades are indistinguishable from white
#F3F3F3
#F4F4F4
#F5F5F5
#F6F6F6
#F7F7F7
#F8F8F8
#F9F9F9
#FAFAFA
#FBFBFB
#FCFCFC
#FDFDFD
#FEFEFE

The table on the right shows colors that I cannot tell apart from white in a side-by-side comparison. It gets worse when I adjust brightness, contrast, move the windows to different hotspots, or simply change the viewing angle. Other people have similar experiences. It isn't limited to ancient CCFL LCDs as my netbook LED LCD similar problem. Blacks are better as I can distinguish up to #040404.

This affects all colors, a good approxiation as I can tell from CRT is to simply scale up 5%. So The light gray non-changed background is white. Our text highlight, removed #FEEEC8 appears as #FFFAD2 and #D8ECFF appears as #E3F8FF on my LCD. — Dispenser 23:55, 24 April 2012 (UTC)

CRTs, in my experience, tend to be darker, not lighter, than LCDs... but maybe that's just me. I do have washed-out issues on some of my crappier monitors, though. But those are all LCDs. Isarra 00:38, 25 April 2012 (UTC)
I also agree! The previous view was better! --Tito Dutta Message 00:53, 25 April 2012 (UTC)
The new dif look is so pretty! And completely useless! I complement the interior designers who created the new look, and ask that they now step aside and yield to someone who actually uses difs in their work around here. HuskyHuskie (talk) 01:44, 25 April 2012 (UTC)
I frequently read Wikipedia on a laptop with a TFT monitor, and I don't always bother to tilt the thing for maximum contrast. It doesn't take much of an off-axis view to cause the pale blue and brown of the new diff style to blend in with the white of the background. --Carnildo (talk) 01:37, 27 April 2012 (UTC)

An alternative maybe

Because I hate change, I previously merged a bunch of the different styles together for my own use back when the first ones were changing over, but perhaps it might work for other folks too? It does seem to also address at least some of the concerns raised about the lot of the previous ones (stuff seems like it would show up for colourblind people; it fits on my damn screen; red stands out enough to see, but has enough black that it's still visible without the red; that bloody highlighting that irks me half to death ain't there; there's a clear distinction between context and diffs; space characters do show up, even if it is subtle), well, uh, what do you think?

 

Actually that's not quite what I'm using, but this version has less confusing colours (as in, not green and blue). Source is here, though, if anyone wants to use it or yell at me for writing such a horrible stylesheet or make it darker or what have you. Isarra 00:38, 25 April 2012 (UTC)

These colors are exactly what I was fighting when I first changed diff colors (though the current version isn't based on my design): red on yellow or green hurts my (as well as other colorblind peoples') eyes. Max Semenik (talk) 22:54, 25 April 2012 (UTC)

Where do we go to get this fixed?

The feedback looks overwhelming here, but where to we go to get it fixed / returned to the previous design? North8000 (talk) 16:50, 25 April 2012 (UTC)

You create a proper RFC, then advertise it across the site. Simple as :) - Jarry1250 [Deliberation needed] 16:53, 25 April 2012 (UTC)
Thanks. I must have missed the RFC which decided to make the recent big change.  :-) North8000 (talk) 20:02, 25 April 2012 (UTC)
Feedback would be overwhelming here. This is where people complain. People without gripes don't always search for a forum to not-gripe in. ▫ JohnnyMrNinja 20:56, 25 April 2012 (UTC)
I'd support an RFC, but please make it constructive. Screeching "put it back!" isn't very helpful, and is likely to just be ignored (especially since the developers have covered their bets by adding a gadget). We definitely need to get the (default) colors changed, and it would certainly be nice to have the design... er, redesigned slightly.
— V = IR (Talk • Contribs) 21:35, 25 April 2012 (UTC)
I agree with Johnny this is where people come to complain when something is wrong not when they like it. So feedback here is not necessarily reflective of community support. I personally like this change especially for viewing where blank space has been removed which was very tricky to see on the old diff screen. It can be turned off as a gadget equally as much as it could be turned on when the old diff screen was live. Basicly what I'm saying is someone is always going to be alienated here.Edinburgh Wanderer 21:41, 25 April 2012 (UTC)
It's possible to have something very similar to the old diff appearance and show where spaces have been added/removed. Set the OldDiff gadget as noted elsewhere on this page, and then add these two lines either to Special:MyPage/skin.css or to Special:MyPage/common.css:
td.diff-deletedline .diffchange {background-color: #cfc; }
td.diff-addedline .diffchange { background-color: #ffa; }
What this does is to give a different background colour to the red text (which denotes changes), whilst leaving the background of the black text alone. The two colours that I've chosen here mean that changes on the left will get a green background, whilst changes on the right get a yellow background. This produces the following effects:
Default background for unchanged text Green #cfc for old version unchanged text . Default background for unchanged text Yellow #ffa indicates the new text unchanged text.
i.e. the background colours are exchanged when changed text is shown. You can of course vary those colours. Spaces show up because of the different background colour, even though there is no red text at that position: look just before the full stop of the left-hand side. --Redrose64 (talk) 23:03, 25 April 2012 (UTC)
Yes, yes, yes, we're all well aware that there are a variety of work arounds for adjusting the way that the new diffs look. What does that have to do with the subject of this section? This spamming "fixes" on every section that is even remotely related to the diff change is annoying, if not outright disruptive.
— V = IR (Talk • Contribs) 23:17, 25 April 2012 (UTC)
Please demonstrate that I "spam fixes on every section". Unlike the MediaWiki devs, I don't force you to use any new ideas. People keep posting threads that say, in essence, "I liked the old way, change it back" or "I like some of the new features, but mostly the old". They ask for help: I offer it. If you don't like it, you don't have to take it. This particular suggestion was in response to the comment "especially for viewing where blank space has been removed which was very tricky to see on the old diff screen". I was demonstrating that the old method can be configured to reveal added or removed spaces.
As for the OP's "where to we go to get it fixed / returned to the previous design" - it's bugzilla:. The devs will ignore anything else, including an RFC. But don't complain to me when they close it "WONTFIX". --Redrose64 (talk) 12:23, 26 April 2012 (UTC)
Well, it depends what the intention is. If you want the *default* MediaWiki diff schema to be changed back, Bugzilla is the place to go. I presumed this thread was referring instead to changing the English Wikipedia back, which is a local matter that can be handled by local sysops - you just need an RFC to establish the consensus in the first place. - Jarry1250 [Deliberation needed] 12:40, 26 April 2012 (UTC)
Please continue to "spam fixes on every section" - particularly the CSS fixup for the recent inaccessible diff change (I wish I had hyper-sensitive eyes like a web designer). It saves the rest of us having to work them out for ourselves and they're certainly needed - and appreciated. Andy Dingley (talk) 12:43, 26 April 2012 (UTC)

Matching spaces is horrible in between text that doesn't match otherwise (the Tetris look mentioned above). The solution is to make the diff a bit smarter: show whitespace diffs when they are not bordering any modified alphanums, otherwise oppress them. Nageh (talk) 23:15, 25 April 2012 (UTC)

  • Cosmetic fiddling, introduction of very unwelcome horizontal scrollbars, and yet obvious bugs outstanding for years, whereby diff generator incorrectly flags large chunks of text as having changed when they are actually identical, are still not fixed: [9]. Someone's priorities are not correct. 86.160.221.37 (talk) 03:38, 27 April 2012 (UTC)

Editors are confused

I wanna add to that: editors are finding hard to follow other editors changes and that may rise arguments, I think functionality should not be violated for the mere "design", and who cares of design when this is not on top page but is only for those who follow the content? It really makes editing tricky and blindfolded.

And also design should not be a start of user's arguments. If you cannot follow this simple psychological pattern on your own, I can explain it for you: some things really irritate people and they are (1) not able to read text on paper or screen (too big or too small), (2) being taken something they liked - the previous way of displaying, (3) too much design sometimes rises stupidity - this is always a must in design "don't go on too much design esp. when not needed", maximum functionality and then maximum design not the vice versa, (4) when they don't understand other editor's changes they think the editors are doing something wrong on the page: that rises arguments. Also I don't like the 'new' menus, some other new stuff previously added, and there is an overall change in design now that is not only on diff views that makes it all crappy. I edit wiki just on habit but I'm sure with a little bit more effort like that you can stop people from editing :) if that is not actually the initial intend. --Aleksd (talk) 07:17, 27 April 2012 (UTC)

There we go again

OK I haven't edited for months now, and I haven't developed for weeks, but in al honesty; shouldn't we just call it quits ? Let's just call the Wikipedia software finished and NEVER EVER EVER EVER change it anymore, because no matter what you change, people simply are inconsiderate to anyone else's need other than their own personal rusty taste and go into the 'i'm used to this and whatever anyone else has thought up that I didn't think up just plain sucks'-mode. Really I have had it. Wikipedia is done, over, end-of-life as far as I care. Let's just put it back to MediaWiki 1.14, so the MediaWiki developers can just get on with developing MediaWiki again. Let's just fork the shit because this way MediaWiki will never EVER get anywhere. We should also stop informing the community, since they have a tendency of not reading that information anyway and then complaining about it (clearly demonstrated here). (Yes i'm having a bad day, and yes reading this discussion wasn't helping). —TheDJ (talkcontribs) 09:01, 27 April 2012 (UTC)

With all due respect, since you are having a bad day you should probably have waited before commenting, because you are completely misreading the complaints. Noone has said anything about not updating the Wikimedia software, on the contrary, these updates are badly needed. These particular complaints are about one specific design feature which for the most part obviously has made functionality worse, and as such is fairly controversial. That no ordinary Wikipedia editor has had a chance to provide input or voice their opinion on that particular matter before hand doesn't make it any better. --Saddhiyama (talk) 09:13, 27 April 2012 (UTC)
And by the way, new bigger font is awful, you can go on 90% view in Latin alphabet but Cyrillic looks terrible. Bet developers didn't think of that too, oh, yeah, this time it was not for the color-blinded but for those having myopia but of course you know that only the books for children have that big fonts... oh, well, who cares, you have a bad day. --Aleksd (talk) 10:33, 27 April 2012 (UTC)
DJ, I know that you are a voluntary developer, and I appreciate all the work you spend on this. But with all due respect, and I'm a regular reader of the Signpost and I am more or less trying to follow active discussions that affect Wikipedia in its entirety, but please show me any discussion that was widely publicized (via an RFC or whatnot) on this Wikipedia and where MediaWiki developers were actively seeking input from the community on the further development of the software. In contrast, I had regularly seen discussions where users were complaining about the new diff scheme, suggesting that it only be optional, yet the new scheme has been implemented without any way to switch back. No-one is saying MediaWiki development should be stopped; what we are saying is that before large efforts are being spent on new functionality some feedback should be sought from the community. This would potentially reduce a lot of frustration on both sides. Nageh (talk) 13:54, 27 April 2012 (UTC)

Scroll bars

I followed RedRose's advice to get the old look back, but it doesn't get rid of those distracting scrollbars. I really need the contrast in colors because my eyesight isn't that good and I need all the help I can get.— Vchimpanzee · talk · contributions · 20:13, 27 April 2012 (UTC)

I presume that by "my advice" you mean that you switched on Edokter's new gadget (Display diffs with the old yellow-and-green colors and design). Which scroll bars are these? --Redrose64 (talk) 20:31, 27 April 2012 (UTC)
This is the advice:

This has been available as a preference since 21:34 UTC yesterday; you need to switch on Preferences → Gadgets → Display diffs with the old yellow/green colors and design. --Redrose64 (talk) 11:10, 24 April 2012 (UTC)

This is what I tried, since it was in the discussion.— Vchimpanzee · talk · contributions · 20:45, 27 April 2012 (UTC)
I checked another diff and it didn't have scrollbars. So apparently what I saw to begin with is unique.— Vchimpanzee · talk · contributions · 21:34, 27 April 2012 (UTC)
Vchimpanzee, can you post a photo for that?
Or is that like this or this?
At first I think it's problem of bigger font of Chinese, but now it seems not...Justincheng12345 (talk) (urgent news here) 06:50, 28 April 2012 (UTC)
Cause found in the new CSS (table.diff td div: { overflow: auto }) with comment "As fallback (FF<3.5, Opera <10.5), scrollbars will be added for very wide cells instead of text overflowing or widening." This also casues IE (not FF or Chrome) to display scrollbars seemingly random, so perhaps this should be removed. Edokter (talk) — 10:15, 28 April 2012 (UTC)
So, FF(newest version) shouldn't get this kind of scroll bars?Justincheng12345 (talk) (urgent news here) 15:43, 28 April 2012 (UTC)
Correct. Tested in FF 12. Edokter (talk) — 21:41, 28 April 2012 (UTC)
So I'm the special cases..I'm also FF12..Never mind....not a big deal :)....Justincheng12345 (talk) (urgent news here) 12:14, 29 April 2012 (UTC)
I'm on Firefox. No scrollbars. I was on IE9 at home.— Vchimpanzee · talk · contributions · 19:13, 29 April 2012 (UTC)

Thanks for the new diffs

I heard the the new diffs were comiing because of an article in the SignPost a couple months ago. I read about it again at the techblog a couple weeks ago. Then I saw it deployed on the other projects a couple days ago. I like the new color scheme and find them much easier to read. I appreciate all the long hours the devs have put in to this update and just wanted to say thanks for all your work. Thanks. 64.40.54.80 (talk) 14:10, 28 April 2012 (UTC)

What a ridiculous post. I looked at the link provided by the anonymous developer editor in the previous post, and my reading of this Signpost article from only a month ago was that there were still problems, and that any new scheme would go through "a fresh round of discussions which it will have to survive if it is to make it onto Wikimedia wikis". And these discussions were where? And lasted how long? HuskyHuskie (talk) 20:55, 28 April 2012 (UTC)
What a pathetic post. Nobody could predict that the new diff scheme would be the default one with no option to switch back. Nobody could predict how broken the new diff scheme would be, exemplified by this diff. What the Signpost link you posted does show is that changes were being discussed on the wikitech-l mailing list rather than with its users. Nageh (talk) 21:19, 29 April 2012 (UTC)
Wow. I think ya'll's tone could be reduced a bit. Could you imagine talking like this to a real human, in person? --Jorm (WMF) (talk) 21:22, 29 April 2012 (UTC)
If we could do that, why would we be on Wikipedia? ▫ JohnnyMrNinja 21:32, 29 April 2012 (UTC)
Yes, I could imagine talking like this to someone in person, and no, I don't see a reason to tone down my comment. When even the developers understand that some change could be controversial then get to talk with its users if and how it will be implemented! Install it at mediawiki.org and invite users to test it! Even if new releases are first deployed at mediawiki.org, how should we know? Note that this case is not the only reason why I feel that the MediaWiki developers are pretty remote from its users, which I have expressed elsewhere as well. Nageh (talk) 21:45, 29 April 2012 (UTC)
Why would any developer want to engage when this is the style of conversation?--Jorm (WMF) (talk) 21:54, 29 April 2012 (UTC)
I think that's exactly it. You would think that writing content under a free license, that working in a collaborative space that invites anyone to join as equals, you would think it be humbling. Make you realize how replaceable editors are. Instead it is a seething nest of entitlement. There are so many editors that are considerate, or helpful, but their voices tend to get lost in the din. And Heaven forbid you want to make slight changes to functionality!!! Again, people that support or don't care are drowned by "solution in search of a problem" or similar garbage. The only measures that seem to get solid support are those limiting the abilities editors not currently in the community. Developers are paid to improve Wikipedia, and that is what they are attempting to do. No new feature has ever crashed the Wiki. They're worried that new editors aren't staying as long as they used to. If these changes make all of the angry, reactionary editors leave, that's two birds dead. ▫ JohnnyMrNinja 01:12, 30 April 2012 (UTC)
"No new feature has ever crashed the Wiki." Yeah, right. --Redrose64 (talk) 13:01, 30 April 2012 (UTC)
That's exactly the kind of attitude developers seem to be taking. They are like "oh, we are being payed, why should we listen to the opinions of mere voluntary, unpaid editors if they don't please us?". Sorry for the harsh tone, but this is the impression your last post is giving me. I think a lot of criticism presented on this page about the new change is substantial and constructive, so feel free to dismiss my complaint even though I certainly think it is warranted. And I really don't understand why Johnny accuses me of complaining about a change of functionality; what I am complaining about is a reduction of functionality (as exemplified), the seeming pathetic post of the OP in light of this new functionality (apologizes to the OP for my attack), and last but not least the ignorance of developers to user input prior to the deployment of 1.20wmf1 such as with this bug report, which causes TeX output to be broken and was acquitted with "This alone wouldn't be a high priority.". Thinking my complaint was unwarranted? Yeah, alright. I just get the feeling again that developers won't care simply because they don't need to. Sigh. Nageh (talk) 09:46, 30 April 2012 (UTC)
Btw, I am really curious as to why Jorm comments only and solely in this discussion which was not even directed at the developers on this whole page of technical discussions much more directly directed at developers. Nageh (talk) 09:52, 30 April 2012 (UTC)
I commented because the comments left by yourself and HuskyHuskie were rude and I felt that I should point that out. Calling the IP editor's opinion "pathetic" and "ridiculous" is simply rude, and I see it far too often. This style of conversation is exactly why few developers voluntarily engage. It isn't that anyone on staff feels like they're superior, or don't need to listen to volunteers - far from it. It's because of the hostility.--Jorm (WMF) (talk) 16:14, 30 April 2012 (UTC)
You know, in a way the OP was saying "the information was dissipated all over places long enough, you just were too stupid to see it". This is what got me upset. The person who can demand an excuse for me calling his post "pathetic" was the OP, and I apologized for this exactly because it was unnecessarily hostile. While you may point out my mistake, I really would have appreciated if you had commented what part of my comments concern you as a developer instead of only pointing fingers. As I said, there are lots of comments left unanswered by developers on this page, and I am still waiting for this to happen if you actually are listening to volunteers (no insult here). For future controversial changes in the MediaWiki software, how about taking home a humble suggestion to test more radical changes at mediawiki.org first, and invite users via the Signpost to try it over there before it is being deployed on the Wikipedia? Well, thank you for your input and reply after all. Nageh (talk) 17:08, 30 April 2012 (UTC)

There may be the slightest possibility of a tiny chance that my post is exactly what it is. That I like the new diffs and wanted to thank the devs for their efforts. But I could be mistaken. I'll let you be the judge. 64.40.57.160 (talk) 02:29, 30 April 2012 (UTC)

Anon, you may actually be an editor and nothing more. But I would venture to say that most editors who not only read the Signpost regularly, but who also frequent tech blogs, likely have an account and a user name, and would therefore be willing to lend that extra bit of weight to their comments. Given that your reaction is clearly in the minority here, your anon status, combined with your extensive awareness of prior discussions on this matter (discussions which most of us had not heard of), all of this just combines into the possibility that you are something more than a simple editor like the rest of us who comment here. If I'm wrong, sorry, but, contrary to what User:Jorm (WMF) implies, I don't think my tone was in any way out of line. The developers have engineered a change that reduces functionality (not merely "changes" it), and that is naturally frustrating to those editors whose voluntary work is dependent upon a tool which has now been compromised, such as those editors who will now have greater difficulty discerning stealth vandals. HuskyHuskie (talk) 03:45, 30 April 2012 (UTC)
Thanks for the apology, HuskyHuskie. I appreciate it. For the record, I've been editing since 2003. I spend most my time referencing articles and cleaning up BLPs I have a concern about. I rarely stray into meta areas because of WP:ABF issues I've dealt with in the past, but I do offer encouragement to others when I think it will help a situation. That's why I posted the thanks message here. I was obviously wrong about it helping the situation, so if somebody would like to hat this section, I wouldn't mind. Whatever people think is best. 64.40.57.160 (talk) 04:30, 30 April 2012 (UTC)
Well, heaven knows that on several occasions I have unintentionally flared up a situation that I meant to calm down; indeed, much more than this small matter. Sorry for all the fireworks. I would guess that yours, like most today, is a dynamic IP, so I can't say I'll necessarily see you around, but I can say I was glad to have made your acquaintance here today. Happy trails. HuskyHuskie (talk) 04:59, 30 April 2012 (UTC)

I for one love the new diff scheme; it's far easier on the eyes. The old diff scheme used colors that clashed. The old scheme made my eyes want to tear. The scheme that provides the greatest levels of accessibility and useability should obviously be the default, and the new scheme aids colorblind users, so the new scheme is the most assessable and useable of the two schemes. --Michaeldsuarez (talk) 20:10, 6 May 2012 (UTC)

"The scheme that provides the greatest levels of accessibility and useability should obviously be the default". I agree, that is why I want the old scheme back. --Saddhiyama (talk) 20:25, 6 May 2012 (UTC)
Apparently you did not quite grasp what accessibility means. — The Hand That Feeds You:Bite 13:25, 9 May 2012 (UTC)
Apparently you don't. The new scheme is not usable by anyone with (reasonable) normal color vision; from what I understand, it's usable by people with the most common type of colorblindness. — Arthur Rubin (talk) 16:54, 16 May 2012 (UTC)
I can't believe you mean to say that "The new scheme is not usable by anyone with (reasonable) normal color vision" because clearly many editors do use it. Presumably you mean to say it's *less* usable, or somesuch. - Jarry1250 [Deliberation needed] 17:05, 16 May 2012 (UTC)
It's not usable to find the actual differences, although the paragraph display is still potentially usable to find the paragraphs that differ. My vision is not perfect, but, before I disabled the new version, I couldn't see the differences at all. — Arthur Rubin (talk) 20:05, 16 May 2012 (UTC)
How did you disable the new version? I can't seem to find the setting.—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); May 16, 2012; 20:16 (UTC)
I used the gadget "Display diffs with the old yellow/green colors and design." — Arthur Rubin (talk) 20:21, 16 May 2012 (UTC)

WP:RefToolbar (Edit toolbar) problems

Edit toolbar not painting completely

In the last couple/several weeks, I notice the "Edit toolbar" is not painting correctly each time the page is loaded. So when one edits a page, the toolbar only appears with about 1/2 to 2/3 its buttons. Bug? — Sctechlaw (talk) 09:44, 3 May 2012 (UTC)

P.S.: This occurs in Firefox 12 / Win 64, and it occurs most of the time, but some of the time the entire toolbar paints correctly, however, it seems pretty random. — Sctechlaw (talk) 09:46, 3 May 2012 (UTC)
I've just upgraded to Firefox 12 from 3.6.28 (sticking with Windows XP). Prior to upgrading, Wikipedia:RefToolbar 1.0 behaved properly, showing 23 buttons; now, the problem described above has appeared, and there are now only 12. The missing ones are from #R to <ref>...</ref> inclusive. --Redrose64 (talk) 21:30, 6 May 2012 (UTC)
I'm having the same problem in IE9, the "Cite" button went missing, so I had to install MediaWiki:RefToolbar.js manually. There was an edit done on 2 May, would that have been the problem?? I'm not knowledgeable in the code. Please help! --Funandtrvl (talk) 00:56, 11 May 2012 (UTC)
Missing in Firefox 12.0 as well. Bidgee (talk) 01:32, 11 May 2012 (UTC)
I don't believe this is related to the edit on the 2nd, especially since Sctechlaw reports the problem from several weeks before the 3rd. It seems the problem may be specific to the old-style monobook edit toolbar and could have been caused by one of the recent MediaWiki upgrades. I'll look into it. In the meantime, you may want to try switching to the enhanced Vector toolbar and see if that works for you. Kaldari (talk) 06:13, 11 May 2012 (UTC)
See T38753 for more info. Kaldari (talk) 07:35, 11 May 2012 (UTC)
Reading the Bugzilla entry leaves me a bit confused: are both bugs now supposedly fixed? The discussion appeared to leave out how the bug was fixed, although they are both now marked as resolved in Bugzilla. However, when I edited this section, I got the whole toolbar on the first go, yet when I previewed before saving the page, the toolbar did not paint correctly. — Sctechlaw (talk) 11:49, 11 May 2012 (UTC) PS, I use Monobook because it's much more accessible visually. (Getting old squinty eyes, meh) Switching to Vector or any of the others leaves me in a visual quandry. — Sctechlaw (talk) 11:53, 11 May 2012 (UTC)
The problem is that the en.wiki admins never implemented the fix here. I've edited edit.js to implement the fix, so it should be good now. Kaldari (talk) 18:43, 11 May 2012 (UTC)
I still can't get it to work w/o installing the .js script for the Reftoolbar. I've left a comment at: Wikipedia talk:RefToolbar 2.0#Cite button. --Funandtrvl (talk) 20:32, 11 May 2012 (UTC)
How should I manually install the toolbar. Vensatry (Ping me) 07:18, 12 May 2012 (UTC)

I just succeeded in getting all 23 buttons to show in Firefox 12, although they were in a funny order. Coincidentally, this occurred whilst posting to Wikipedia talk:RefToolbar 1.0#Cite button so I've noted my observations there.
  Note: I'm no longer watching this page because of all the stuff from #Watchlist - bold letter article titles! onwards. --Redrose64 (talk) 08:41, 12 May 2012 (UTC)

  • I used firefox 12 with no such problems, so I don't think it's firefox. MathewTownsend (talk) 23:59, 12 May 2012 (UTC)
The problems I'm having is with RefToolbar 2.0, it's turned on in my preferences (and is supposed to work w/o having to add script to my preferences page), and the "Cite" button shows up on the enhanced toolbar in all the namespaces, except the main article space, when the "Edit" button is used. Does anyone know how to fix this? See also: Wikipedia talk:RefToolbar 2.0#Cite button. I use IE9. Thanks, --Funandtrvl (talk) 16:45, 14 May 2012 (UTC)

Today the MonoBook standard edit toolbar is painting correctly once again (yay, as the non-painted bar was really annoying). One difference on my end is the 12.01 update to Firefox, but since IE users had this problem too, I'm not sure whether the update contributed to the fix or not. Thanks, in any case, to all who worked on and fixed the problem. — Sctechlaw (talk) 09:07, 16 May 2012 (UTC)

Yes, I use IE9, but today I set "My preferences" back to default, and then deleted any custom css and js code from my vector skin. And voila, it works!! Now I just have to figure out which gadget or js code was causing the conflict, or if it was something changed behind the scenes here. :) --Funandtrvl (talk) 20:55, 16 May 2012 (UTC)

Cite button

The "Cite" option often disappears from the window while editing. I can't figure out the issue. Any help will be much appreciated! Vensatry (Ping me) 15:46, 11 May 2012 (UTC)

Ask at WP:REFTOOLBAR. ---— Gadget850 (Ed) talk 15:48, 11 May 2012 (UTC)
Is this related to the above issue at Edit toolbar not painting completely? — Sctechlaw (talk) 05:30, 12 May 2012 (UTC)
This is starting to happen to me, as of this morning. The "Cite" option comes and goes on the toolbar. However, I also have Provelt as a gadget preference - at the bottom of the page, not on the toolbar - and that comes and goes, but not necessarily in conjunction with the Cite option. Sometimes I have either-or, sometimes both are there, sometimes neither are there. And it just flips back and forth as I open Edit screens.Maile66 (talk) 12:29, 13 May 2012 (UTC) Reposted this at WP:REFTOOLBAR Maile66 (talk) 12:38, 13 May 2012 (UTC)

Cite not shown on the toolbar on top of the editbox

Can anyone explain why the cite option does not appear on the toolbar on top of the editbox as shown in the screenshot here. Although it should reappear after a reload but as said by some users even a reload is not helpful. This issue came up after a discussion here. Some light on this will be very much appreciated thanks-- ÐℬigXЯaɣ 06:02, 14 May 2012 (UTC)

I also experienced the same problem while I was citing Ahmedabad. Though with me, a reload worked and it appeared again after F5. TheSpecialUserTalkContributions 07:00, 14 May 2012 (UTC)
The conversation about this is happening at RefToolbar_1.0#Cite_button. -Maile66 (talk) 17:41, 14 May 2012 (UTC)
Correction: The above discussion is about RefToolbar 2.0, not 1.0. Please see: Wikipedia talk:RefToolbar 2.0#Cite button for further discussion. --Funandtrvl (talk) 17:20, 15 May 2012 (UTC)

Feedback tool clarification

A few questions about the feedback tool:

  • How do you place the feedback box in an article manually? I tried adding Category:Article Feedback 5 Additional Articles but I still don't see it.
  • Why does the feedback box only show up randomly for me?
  • Is the "Improve this page" button (bottom-right) related? And why has this never shown up for me?

These are based on my own curiosity, but I'd also like to improve Wikipedia:Article Feedback Tool based on the answers, since I couldn't find them there (or through its links). Equazcion (talk) 12:57, 14 May 2012 (UTC)

You did right by adding Category:Article Feedback 5 Additional Articles in [10], but it appears Article Feedback Tool Version 5 has recently changed from asking for feedback to encourage editing. Version 5 is experimental and only shown on relatively few pages. See Wikipedia:Article Feedback Tool/Version 5/Help#Can I enable/disable AFTv5 on individual articles?, Wikipedia:Article Feedback Tool/Version 5/Help#Is data generated by the Article Feedback Tool publicly available?, Wikipedia:Article Feedback Tool/Version 5/Feedback evaluation. "Improve this page" is only shown on Version 5 articles. Do you see it on Eduardo Saverin if you log out? It doesn't appear you have done so but registered users can remove the link without disabling the whole feedback widget by adding this line to Special:MyPage/common.css (applies to all skins) or Special:MyPage/skin.css (your current skin):

#articleFeedbackv5-bottomrighttab{display:none}

PrimeHunter (talk) 13:28, 14 May 2012 (UTC)
Thanks for the info -- I tried logging out, and also disabled Adblock Plus which I have installed, but I still didn't see any feedback/encourage thing or the improve link. I guess you're saying it should show up and this must be a client-side browser issue for me. I do see it from time to time though on random articles. Guess I'll tinker with my settings and see. Equazcion (talk) 13:36, 14 May 2012 (UTC)
Looks like it shows up for me in Chrome, whether I'm logged in or not, with adblock enabled -- but not in Firefox (12) at all. Odd. Equazcion (talk) 13:45, 14 May 2012 (UTC)
I see it in Firefox 12. PrimeHunter (talk) 13:51, 14 May 2012 (UTC)
  • Can I request that people please not add this to articles? One of the reasons it's deployed so rarely is because we're still testing it, working out issues and (most importantly) doing research. Adding and removing articles from the categories alters the sample, which is not good for data reliability. Okeyes (WMF) (talk) 12:42, 15 May 2012 (UTC)
If additions are unwanted then Wikipedia:Article Feedback Tool/Version 5/Help#Can I enable/disable AFTv5 on individual articles? should also be reformulated. It says: "As we are using these samples for experimentation we kindly ask you not to manually remove articles from these lists. If you wish to enable AFTv5 on a supplementary article, you can do so by adding it to this category."
Another matter, IP's and everybody else get to Wikipedia:Article Feedback Tool/Version 5/Help/Feedback page Editors by clicking "?" and then "Learn more >>" in the "Help improve this article" box at ATFv5 pages, for example at the bottom of Eduardo Saverin. It starts with This is a help page for the willlink|Article Feedback page, aimed at those with the "oversighter" userright. If you are seeing this and do not have that userright, or have any questions about the tool, please email okeyes@wikimedia.org. But everybody can see that text. Later it makes reference to seeing feedback which I don't see but I'm not an oversighter. Also, the whole page assumes there is feedback, but ATFv5 currently has no feedback feature. It only encourages editing. PrimeHunter (talk) 13:18, 15 May 2012 (UTC)
Good points all; I'll try to get to them in a tick (I'm stuck in the Netherlands datacentre and my laptop is dying. So many machines, none useable!) Okeyes (WMF) (talk) 13:20, 15 May 2012 (UTC)
Okay, it turns out that the answer to the first point is "Ollie is an idiot"; I misunderstood the restrictions on adding articles to the categories. You're welcome to add things to "additional articles"; so sorry for all the fuss! The other things are on today's to-do list. Okeyes (WMF) (talk) 06:37, 16 May 2012 (UTC)
Thanks for the correction. Equazcion (talk) 11:15, 16 May 2012 (UTC)

Find specific edit tool

At some point in the past couple days the miszabot config in WP:ANI was changed -- an "f" was added to the 700K in the maxarchive section. Is there a tool that can find the diff that generated that specific edit? Nobody Ent 10:32, 16 May 2012 (UTC)

I love a challenge. It appears to have happened in this edit by User:The Blade of the Northern Lights, so it was likely a stray mistype, probably during an edit conflict. PS. I don't know of any tool, but I use my own LiveDiffLink script to aide in diff research. Equazcion (talk) 10:49, 16 May 2012 (UTC)7
Drat. Just found it myself. I used WP:WikiBlame - although I think there was a lauded replacement but I don't recall what it was called. Grandiose (me, talk, contribs) 10:51, 16 May 2012 (UTC)

Wayback/Webcite

Is there a bot or app that will let me trigger Webcites for all of the citations in an article? I just wrote an article and a lot of the citations are to sources that are unlikely to last. I'd like to get archived copies of them, but it's annoying to do one by one. MBisanz talk 16:30, 16 May 2012 (UTC)

I'd be interested in knowing this as well. I doubt it for the Wayback Machine, they don't seem to constantly crawl, but someone might have something for WebCite. --joe deckertalk to me 16:32, 16 May 2012 (UTC)
User:Δ has requested via IRC that I inform you that he has a tool for this and that someone email him about it. *slips back out of sight* Bob the WikipediaN (talkcontribs) 16:39, 16 May 2012 (UTC)

Expiry parameter in protection templates doesn't seem to support UK date format

The subject line says it all, really. this edit to Sexual reproduction to change the date format of the expiry parameter in {{PP-vandalism}} has removed the page from Category:Wikipedia pages with incorrect protection templates. This behaviour is obviously not ideal. How can it be fixed? Graham87 01:44, 17 May 2012 (UTC)

They seem to support it fine. Since the protection template was logged as being added within three seconds of the actual protection, I suspect they were actually submitted at the same time by Twinkle and the template thought the page wasn't protected when the page was parsed. Any edit, even a null edit, probably would have fixed it. Anomie 02:40, 17 May 2012 (UTC)
Thanks, makes sense. I've added some instructions to this effect to the category page. Graham87 03:21, 17 May 2012 (UTC)

Watchlist bolded articles!

I have an override in place for the anti-bold override that's currently in place for unwatched changes in my watchlist. What happened to the bold?—cyberpower ChatOffline 02:28, 17 May 2012 (UTC)

See two sections up. Anomie 02:41, 17 May 2012 (UTC)
It's working again. Thanks!—cyberpower ChatOffline 02:49, 17 May 2012 (UTC)

Page exceeded the expansion depth?

Today I noticed that, when I edit some pages, the message "Page exceeded the expansion depth" appears at the top of the page in red. I've never seen this before. I understand about expansion depth but this is something new and I doubt if it applies to the pages in question. –droll [chat] 01:08, 8 May 2012 (UTC)

I've tracked the problem to {{infobox coord}} which transcludes {{coord}}. {{Infobox coord}} has not changed recently. –droll [chat] 01:20, 8 May 2012 (UTC)
I'm not sure what you know about the expansion depth limit. See meta:Help:Expansion depth and Wikipedia:Avoiding MediaWiki expansion depth limit. You didn't give a link but maybe it's about an article using {{Infobox coord}} inside several other structures adding to the expansion depth. PrimeHunter (talk) 01:43, 8 May 2012 (UTC)
You should take a look at {{Location mark+}} as that was just changed by droll. It might be some pipes | in the #if statement that need to be replaced with {{!}}. --Bamyers99 (talk) 01:51, 8 May 2012 (UTC)
I'm familiar with the depth limit of 40. {{infobox coord}} is used inside infoboxes and so the expansion depth is high. I'm wondering if the new message has something to do with the deployment of 1.20wmf2. Maybe it's been an unnoticed problem. The test case is here and it does not transclude {{Location mark+}}. I just noticed that it is in Category:Pages where expansion depth is exceeded.
This is the third report of this issue today: on on the HD and one above. Category:Pages where expansion depth is exceeded now has 3,837 pages. ---— Gadget850 (Ed) talk 02:21, 8 May 2012 (UTC)
I also noticed the previously red Category:Pages where expansion depth is exceeded so I created the category page with an explanation. It may be new that pages are added to this category. I don't work with coordinates but I noticed your test case here works if the decimals are removed from lat_d and long_d. I haven't investigated it further. PrimeHunter (talk) 02:27, 8 May 2012 (UTC)
The tracking category is indeed new. mw:MediaWiki_1.20/wmf2 says: "(T24887) Add warning and tracking category for preprocessor errors". PrimeHunter (talk) 03:13, 8 May 2012 (UTC)
I have a fix at Template:Infobox coord/sandbox and I requested an edit to the protected template on the talk page. I had to remove some error checking to reduce the expansion depth. This is far form ideal. If an admin could do the edit it will reduce the number of pages in the error category significantly. –droll [chat] 02:37, 8 May 2012 (UTC)
Most of these are "my" monthly clean-up categories. They use some fairly intensive templating, which is perfectly safe on rarely rendered pages. (To-whit: the progress boxes.) Rich Farmbrough, 00:16, 9 May 2012 (UTC).

I wonder if there's some bug in the new version of the MediaWiki software. I have worked on the {{clade}} template and so at User:Peter_coxhead/Test/Clade#Example_5 I have a test cladogram which has always failed to display because of the expansion depth being exceeded (and actually generates a visible error message which doesn't always happen). User:Peter_coxhead/Test currently has a cladogram which is the correct size to display fully, which it does. However when I look at the generated HTML, both pages have the hidden category Category:Pages where expansion depth is exceeded added to them. My guess is that this error message is being generated at a threshold lower than the actual threshold for expansion depth. When I drastically reduce the size of the cladogram the hidden category disappears; it seems to appear before the actual expansion depth is exceeded. Peter coxhead (talk) 13:45, 8 May 2012 (UTC)

If its a bug, it is still there, for select articles. I get "Page exceeded the expansion depth" as the result of clicking "Show preview" after opening Southwest Chief for editing. 68.165.77.191 (talk) 17:27, 13 May 2012 (UTC)
I found this thread by searching Wikipedia help for the error message. I get this error while previewing edits for Heligoland. I don't know what, if any, display problems this is causing (there is nothing glaringly obvious), or how to go about fixing it, 86.179.113.84 (talk) 20:34, 17 May 2012 (UTC) See additional comment at [11]

I had the same problem on 8/2/2013 with Te Uku Wind Farm, but it seems to make no difference to the final appearance.

TeX-like drawing language for WP?

Looking at some of the explanations on the WP:Reference desk subpages (esp. mathematics) and feeling they'd at times be more easily understood with a diagram, plus at times me too wanting to sketch things in explanation but not having a suitable tool for generating a PNG/SVG, I find I long for a text-editable TeX-like language supported by WP for putting together quick diagrams, as well as for producing simple diagrams for articles. I guess the best starting point would be some existing language of this nature (as was the case with TeX), but am not personally familiar with such. Is anyone aware of something along these lines that could sensibly be adapted for use on WP? — Quondum 08:53, 13 May 2012 (UTC)

In principle, TeX supports drawings with the picture environment. It is, however, fairly horrible - so horrible that I have gladly forgotten all about it. Likewise, SVG can be hand-written, though I've never tried. For tree- and graph-like applications, I found the DOT language to be very useful. --Stephan Schulz (talk) 09:40, 13 May 2012 (UTC)
Don't, ever, suggest anyone using the picture environment. :) For a really nice LaTeX drawing package, use PGF/TikZ. Nageh (talk) 09:44, 13 May 2012 (UTC)
SVG is easy to understand, but easily gets complex with all the XML nesting. I suppose any such functionality won't come anytime soon. If it will, be sure that many will complain about its complexity and demand a visual editor, which probably will never come given the delay of the promised WYSIWYG editor. Nageh (talk) 09:48, 13 May 2012 (UTC)
Thanks for bringing me up to speed on this. I get the impression that the most workable option for WP for some time to come will be SVG. I see that SVG-edit, as a generally available browser-based editor that I had not been aware of, may actually allow one to easily edit pictures created by others; I should perhaps look into this a bit more closely for the intent that I described. — Quondum 10:40, 13 May 2012 (UTC)
Is the math extension (i.e.  ) not good enough? — Blue-Haired Lawyer t 10:53, 13 May 2012 (UTC)
We now have MathJax. Preferences → Appearance → MathJax. ---— Gadget850 (Ed) talk 11:01, 13 May 2012 (UTC)
We have working MathJax for more than 2 years now: User:Nageh/mathJax. ;) Nageh (talk) 11:27, 13 May 2012 (UTC)
(ec) It was an extension of <math> that I was thinking of for simple diagrams, graphs etc. beyond the normal formula-expression capability (such as TikZ seems to give). There are times when words become a little clumsy when explaining to someone who is a little scared of or unfamiliar with math. Once one can assume a math-comfortable reader, the utility of diagrams diminishes, but simple diagrams still seem to have a place. — Quondum 11:09, 13 May 2012 (UTC)
See this thread on wikitech and mw:Extension:SVGEdit. Helder 17:38, 13 May 2012 (UTC)
Have you tried PostScript? It's not too similar to TeX, but it is a programming language you can use for creating vector graphics. These can then be converted to SVG. InverseHypercube (talk) 00:52, 18 May 2012 (UTC)

Move the "mobile view" link from bottom of page to the top

for the love of god can someone move the "mobile site" link from the bottom of the page to the top. Its a stupid place to put since one has to load entire damn page to get to it, THEN switch to mobile since I'm no longer automatically directed to the mobile wikipedia on my itouch anymore — Preceding unsigned comment added by 24.118.60.18 (talk) 12:27, 15 May 2012 (UTC)

If your not getting automatically redirected then this is a totally different issue. Clear your cache and then follow this link .. It'll make it permanent — Preceding unsigned comment added by Tfinc (talkcontribs) 19:02, 17 May 2012 (UTC)Tfinc (talk) 19:04, 17 May 2012 (UTC)

Error on loading page (2)

Hi. This may be related to Wikipedia:Village pump (technical)/Archive 95#Error on loading page or it may be a new problem. Using Vector skin in IE8, when loading the articles Pakistan and The Doon School, I get the following error:

Webpage error details
User Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; Sky Broadband; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; .NET4.0C)
Timestamp: Wed, 16 May 2012 16:04:03 UTC
Message: 'console' is undefined
Line: 358
Char: 1
Code: 0
URI: http://meta.wikimedia.org/w/index.php?title=MediaWiki:Wikiminiatlas.js&action=raw&ctype=text/javascript&smaxage=21600&maxage=86400

and Ucucha's duplinks tool doen't appear in the sidebar. Loading this VP/T page, duplinks also fails to appear, but no error is reported. On many other pages, all is well. These errors are consistent today, not intermittent, but I was having no problem with Pakistan up to 22 April, when I copy edited it, so I guess this must be something recent. Demographics of Croatia, to which the archived problem related, still loads error-free and has duplinks today. Hoping you can help, and thanks. --Stfg (talk) 16:16, 16 May 2012 (UTC)

Looks like some sort of JavaScript loading problem. My script shouldn't appear on this page, because it adds the link only on mainspace and userspace pages. Ucucha (talk) 17:37, 16 May 2012 (UTC)
I can't reproduce the error on either of those pages in Firefox 12. Ucucha (talk) 17:42, 16 May 2012 (UTC)
Hmm, console.log is clearly a debugging line left in by the script's author. I'll take a look later. - Jarry1250 [Deliberation needed] 17:54, 16 May 2012 (UTC)
Okay, so I pinged the script's maintainer, Dschwen, and he removed the offending line. Thus, this problem should be officially fixed :) If it's not, then do say, obviously. - Jarry1250 [Deliberation needed] 01:52, 17 May 2012 (UTC)
Many thanks, Jarry1250. Yes, on purging the cache it's fixed; no page loading error, and duplinks is now present on them. --Stfg (talk) 09:26, 17 May 2012 (UTC)

Special page - related changes

Using the related changes special page should show articles that are in your watchlist in bold text. It appears to be now displaying all without any bolding. I guess this could be something to do with the watchlist changes but would be good to get it back so you can easily scan the changes not on your watchlist. Keith D (talk) 01:20, 17 May 2012 (UTC)

Yes, the CSS added to override the bolding on the watchlist is also overriding the bolding on Special:RecentChanges. It's easy enough to target it more specifically, but unfortunately that will also break everyone's overrides for the override. If your override for the override has broken, you will probably be able to fix it by changing your CSS selector from strong.mw-watched a to .mw-special-Watchlist strong.mw-watched a. Anomie 02:15, 17 May 2012 (UTC)
Thanks. Keith D (talk) 11:35, 17 May 2012 (UTC)

List of titles by namespace

Dumps? I tried to look through the database dumps and offline versions, but I couldn't seem to find what I wanted: is there any way to just get a (plain-text) list of the content on en.wp by namespace? It would be nice if it was in the format:

ns-0
*[[:!]]
*[[:!!!]]
...

ns-1
*[[:Talk:!]]
...

but not strictly necessary. Can someone help me here? —Justin (koavf)TCM 02:50, 17 May 2012 (UTC)

Poke someone who can run a Toolserver query for you (Jarry1250 seems to be helpful!). Or you can run the appropriate API query yourself (search for action=query). That might be more tedious if you aren't familiar with that stuff. Killiondude (talk) 06:09, 17 May 2012 (UTC)
I have been informed by Betacommand that he is generating a list, and that users who want to see it should email him. →Στc. 06:31, 17 May 2012 (UTC)
That's nice of you to say :) looks like I was a few hours late on this one though. - Jarry1250 [Deliberation needed] 16:12, 17 May 2012 (UTC)
Excellent E-mail sent. If I don't hear back or if he's not generating the list, I'll get back with you, Jarry. Thanks! —Justin (koavf)TCM 17:14, 17 May 2012 (UTC)

Navigation popups 2

Are navigation popups working for anyone at the moment? JN466 03:08, 17 May 2012 (UTC)

Yes. Firefox 12. Orange Suede Sofa (talk) 03:10, 17 May 2012 (UTC)
Anyone with Chrome? JN466 06:05, 17 May 2012 (UTC)
There was a clash with an AFC helper script, apparently now fixed. See Wikipedia talk:Tools/Navigation popups#Popups Has Stopped Working. — Richardguk (talk) 08:25, 17 May 2012 (UTC)
Thanks. Doesn't seem to be fixed; popups work for me in Firefox 12 now, but not in Chrome. (And the edit toolbar doesn't appear most of the time in either browser.) JN466 11:38, 17 May 2012 (UTC)
Bypassing the cache seems to help with the edit toolbar problem. --JN466 11:51, 17 May 2012 (UTC)

[70cc2217] 2012-05-17 08:58:26: Fatal exception of type MWException

What's this? I tried to save a revision of Nevljica with no special code except the wikicode (see User:Eleassar/Sandbox2) and got this message. --Eleassar my talk 09:01, 17 May 2012 (UTC)

I couldn't reproduce it. Was there any other information with the error message? Ucucha (talk) 09:43, 17 May 2012 (UTC)
I don't know what the deal was, but I had a similar problem. Lasted for a couple minutes. Couldn't save anything. Seems gone now. - jc37 09:48, 17 May 2012 (UTC)
Reply to Ucucha: No, it was simply a blank page with this text in the upper left corner. --Eleassar my talk 10:32, 17 May 2012 (UTC)

Trouble logging into Commons

I just activated the unified login option under "My preferences" here on Wikipedia, but cannot seem to login to the Commons site. When I try (using my Wikipedia username and password) I get the following error message:

Login error
<

The user name "My Core Competency is Competency" has been banned from creation as it matches one or more blacklisted character strings.

>

Any ideas on what I am doing wrong? Thanks in advance for your help! ---My Core Competency is Competency (talk) 12:51, 17 May 2012 (UTC)

Your username is 32 characters (excluding the User: prefix), which exceeded Commons' titleblacklist restriction of 30 (including the User: prefix). I've increased it to 40 so you should be fine now. However length restrictions on usernames should really be enforced in Meta's blacklist, not on local projects - and the software should be amended to not included the "User" prefix in the count, as it varies by project language (anyone know if there's a bug for that?). Rd232 talk 14:51, 17 May 2012 (UTC)
Thank you so much! ---My Core Competency is Competency (talk) 15:35, 17 May 2012 (UTC)

Last table in page rendering below references section

Noticed an issue with the List of awards and nominations received by Breaking Bad article, where the table in the "other awards" section is being rendered below the "references" section. Tried to edit the page to fix it only to find that in the source, it seems to be laid out correctly. Not sure what's going on here. Firefox 12, Windows 7. 174.0.87.221 (talk) 17:42, 17 May 2012 (UTC)

Resolved, the table wasn't closed properly. NtheP (talk) 17:49, 17 May 2012 (UTC)
Awesome, thank you! Thought maybe it was something simple like that but I don't know enough about tables. 174.0.87.221 (talk) 18:21, 17 May 2012 (UTC)

Global blocking interface message needs reconstruction

In a recent update of the GlobalBlocking extension, MediaWiki:Globalblocking-ipblocked has superseded MediaWiki:Globalblocking-blocked. Can an admin please fix this? The number of parameters is not the same (5 on the new message, 4 on the old one).--Jasper Deng (talk) 23:23, 17 May 2012 (UTC)

sortable table, with multiple header rows?

I like to make a sortable table, but have the sort indicator in the third row, not the first. All the examples in Help:sorting have the top row the sort indicator.

As an example of the table. see automatic bids

I know how to make it sortable when there is a single header row, see for example, the table in First and second rounds, but I'm not sure how to make it happen if I have two or three header rows.

I know I have to use "!" to indicate header, as opposed to data rows, but I'm not doing well when I try to do formatting such as colspan, in the header rows.

See my sandbox, for a mess:


Is this possible?--SPhilbrick(Talk) 17:36, 17 May 2012 (UTC)

I have put a solution in your sandbox. -- Dianna (talk) 07:13, 18 May 2012 (UTC)
Wow, thanks, that's great!--SPhilbrick(Talk) 10:41, 18 May 2012 (UTC)

Need Some Technical Assistance

Am having a problem with the coding on my userpage. It has gone all haywire and I didn't touch anything. Fine last night, today, it's all messed up. Not sure if someone goofed something in the main templates I use, but can someone help? - NeutralhomerTalk • 21:56, 17 May 2012 (UTC)

It looks OK to me but I don't know whether it's supposed to look different. Please describe the problem better. "all haywire" and "all messed up" is vague for people who don't know what it looked like last night. PrimeHunter (talk) 22:21, 17 May 2012 (UTC)
OK, to me, it the boxes on the left are waaaay down the page from the ones on the right. Normally they are side-by-side. I am using Firefox 12.0, so I am not sure if that is the problem or not. - NeutralhomerTalk • 22:31, 17 May 2012 (UTC)
This is how it looks to me currently - File:MyUserpage_05172012.PNG. - NeutralhomerTalk • 22:36, 17 May 2012 (UTC)
I'm using Firefox 12.0 as well, and it looks fine to me. What's your screen resolution? Malleus Fatuorum 22:38, 17 May 2012 (UTC)
1024x768. - NeutralhomerTalk • 22:50, 17 May 2012 (UTC)
I've wrapped things in another table. Does it help? -- WOSlinker (talk) 22:51, 17 May 2012 (UTC)
Yeah, that took care of it. Thanks! :) - NeutralhomerTalk • 23:01, 17 May 2012 (UTC)
Actually, it didn't take care of the problem. The drop-down menu boxes I use were having problems (they should only drop on one side, not both), so the problem continues. I have gone through each and every link in all the coding I use to see if there is a problem, nothing. I think something was changed to the Wikipedia software that has changed the way the menu coding I use works, as in someone goofed something up. I'm at a loss as to what to do. - NeutralhomerTalk • 03:32, 18 May 2012 (UTC)
But your page looks fine to everyone else including me, who also uses Firefox 12.0. What does it look like when you're logged out? Malleus Fatuorum 03:45, 18 May 2012 (UTC)
Same as when I am logged in. This is what it looks like to me at the present moment. - NeutralhomerTalk • 04:45, 18 May 2012 (UTC)
I can get the same result by zooming in (control +) on the page. Your widths should not be specified as a fixed number, but as a percentage; then it won't truncate like this. I will set the skinny box at 32% and the wider one at 67% -- Dianna (talk) 06:04, 18 May 2012 (UTC)

Diannaa‎ fixed it, for real this time. :) Thanks! :) - NeutralhomerTalk • 07:05, 18 May 2012 (UTC)

What is the lower case "c" on the Watchlist?

I know uppercase "N" means new page. Lowercase "b" means bot generated, and lowercase "m" means the change was minor. Is this new little "c" meaning change? I don't mind. It's a nice touch, if that's what it's for. Maile66 (talk) 17:42, 18 May 2012 (UTC)

A developer imposed this [12] even while a discussion was ongoing regarding the possibility of a similar feature, and despite outcry the last time a similar change was made. here. Equazcion (talk) 17:45, 18 May 2012 (UTC)
Let me guess. There isn't an option to switch this off either? - X201 (talk) 17:47, 18 May 2012 (UTC)
Not without some CSS customization, no. Equazcion (talk) 17:48, 18 May 2012 (UTC)
Really? After the last outcry and while a discussion of this very topic is taking place, another unilateral change has been made? What is this person smoking? --R'n'B (call me Russ) 17:49, 18 May 2012 (UTC)
Jeez. Can you (whoever is responsible this time) please stop playing around? Hasn't there been clear consensus that opt-in is the way to go? Nageh (talk) 17:52, 18 May 2012 (UTC)
I don't know if the discussion at the RFC is going anywhere, but it's really bad call to change the source of the problem before people have had their say in the matter. What does the C stand for anyway? Jared Preston (talk) 17:55, 18 May 2012 (UTC)
See my comment at Wikipedia talk:Requests for comment/Watchlist survey#A comment on the "opt-in" option. Edokter (talk) — 17:58, 18 May 2012 (UTC)
ARGH FUCK YOU EDIT CONFLICT ONCE AGAIN LOSING WHAT I TYPED. Ahem. It's probably the least annoying try so far, but the curvature of the c, plus the fact there's no quiggly line under it makes it stand out more than the m's or b's. Either that, or it's a different font. Why not n for new, though? ♫ Melodia Chaconne ♫ (talk) 17:59, 18 May 2012 (UTC)
What I find really annoying about this whole saga is the constantly changing styles which means to opt-out we keep on having to tweak our own style sheets. I don't care whether it's enable or not but let's make a decision on style before we enable it so that people that want to opt out easily can and don't keep on seeing something they thought they'd disabled due to yet another change to the style. Dpmuk (talk) 18:00, 18 May 2012 (UTC)
Argument about profanity

Doesn't Wikipedia have policies against editors posting with profanities on this page? It's offensive. Maile66 (talk) 18:07, 18 May 2012 (UTC)

I find it offensive when people find nothing but to call for censorship. Nageh (talk) 18:20, 18 May 2012 (UTC)
Not really, there's no anti-profanity policy. Equazcion (talk) 18:10, 18 May 2012 (UTC)
There is WP:CIVIL. Edokter (talk) — 18:14, 18 May 2012 (UTC)
Cursing out an edit conflict is hardly uncivil, but I think we digress. Equazcion (talk) 18:17, 18 May 2012 (UTC)
Isn't it about time that Arbcom put a stop to this nonsense? Not only has something else appeared which yet again disrupts the positioning of the article title links, it appears to have been done in yet a different way and lots of people will now be wasting their time trying to find out how to disable it again (or writing here which is obviously also a waste of time but at least makes us feel better). Actually, I have just realised that in order for me really to feel better I need to say "Fucking stop it already!" Now I feel better. --Mirokado (talk) 18:25, 18 May 2012 (UTC)
I don't follow a lot of the higher level drama boards, so I may be wrong, but I don't believe that Arbcom has any jurisidiction with regard to developers. --joe deckertalk to me 18:37, 18 May 2012 (UTC)
Edokter was able to make this change because he's an administrator. Administrators have access to edit certain interface elements (MediaWiki: pages). Arbcom would have jurisdiction over that. I'm not sure if he's an "actual" developer with access to edit the PHP. Equazcion (talk) 18:39, 18 May 2012 (UTC)
Ahh, I was imply taking someone else's word that he was a developer. As to who "wins?" discussions like this? We will see. Perhaps WP:ACTRIAL, where the WMF and developers in some combination overrode (perhaps with good reason) a community consensus without before or even after engaging the community with a discussion on the merits? Perhaps that left me the wrong impression about how things work in such cases. --joe deckertalk to me 18:45, 18 May 2012 (UTC)
No, you had the right impression, at least in the case of ACTRIAL. But that was a requested change from the community that would've required intervention from people with PHP and database access, and they didn't want to do it. Also it was apparently shot down by the WMF subsequently, not any single person, developer or otherwise. What we have here is just one guy acting on what he likes best, and that's probably a reasonable arbcom issue. Equazcion (talk) 18:54, 18 May 2012 (UTC)

We've gotten along without this feature for eleven years. We can wait for the conclusion of the RfC (hopefully resulting in a consensus-backed solution). More importantly, we can wait for an implementation (whether permanent or temporary) that doesn't cause problems. I doubt that I'm the only user for whom the unexplained appearance of a "c" within every watchlist item (inexplicably included as part of the actual page link, which was particularly apparent with underlining enabled) was downright perplexing.
I found the bolding annoying, but failure to appreciate its significance wouldn't cause confusion; it would simply come across as arbitrary styling. Conversely, the "c" obviously was intended to convey something in particular. That thing eluded me. And having read all of the relevant comments here and on Edokter's talk page, I still don't know what word or phrase "c" stood for. ("Contribution"?) —David Levy 18:33, 18 May 2012 (UTC)

(edit conflict) I'm betting it stood for "Change" in Edokter's mind. Equazcion (talk) 18:35, 18 May 2012 (UTC)
Ah, you're probably right. —David Levy 18:43, 18 May 2012 (UTC)

Would Edoktor please read WP:CONSENSUS and try to remember that we are a community. A fractious one yes but not a community of 1. If this keeps up I can foresee a WP:RFCC coming down the pike. MarnetteD | Talk 18:35, 18 May 2012 (UTC)

We're not talking about editorial content here. Software issues are not necessarily subject to community consensus, especially those that affect new editors that have yet to become part of said community. Edokter (talk) — 19:13, 18 May 2012 (UTC)
Yes, they are. Equazcion (talk) 19:24, 18 May 2012 (UTC)
Maybe it's time for that RFCC. --joe deckertalk to me 19:57, 18 May 2012 (UTC)
Then who, exactly, is the software for? Orange Suede Sofa (talk) 19:35, 18 May 2012 (UTC)

Wow. Now I'm seeing how the heck it is that people like Betacommand and Rich Farnborough keep getting chance after chance when they've made it clear that they don't care about getting consensus for their bots... rdfox 76 (talk) 22:47, 18 May 2012 (UTC)

please re-offer an "inverted colors" view (black background + very bright letters)

dear wikipedia dears,

why don't you develop a switch to allow readers to read wikipedia articles in "inverted colors" (very dark background + very bright letters)?

both windows and linux offer a system-wide switch to "inverted colors", but web pages are not affected...

when one reads a very bright page the pupil-sphincter muscle has to stay chronically contracted to limit the amount of entering light.

with "inverted colors" the muscle remains relaxed, which does not wear down the pupil-sphincter muscle as much.

the wikipedia technical team told me that they used to offer such a skin for logged-in users, but it's not available anymore... :(

best

marcos

PS. also the adobe PDF reader offers the "inverted colors" option... but it inverts photos as well which is not good... — Preceding unsigned comment added by Marcos.alberto (talkcontribs) 21:14, 18 May 2012 (UTC)

Not a bad idea, maybe as a skin option. My sphincter does tend to remain tightened when I'm on Wikipedia. Equazcion (talk) 21:19, 18 May 2012 (UTC)
We still offer "black background, green text" to registered users which I know people use (though I don't personally). Incidentally, I'm not entirely convinced your reasoning makes a great deal of sense (though there are many reasons why green-on-black could be better for individuals), but that's a question for the reference desk, not here. - Jarry1250 [Deliberation needed] 23:49, 18 May 2012 (UTC)

Watchlist - bold letter article titles!

See also Wikipedia:Village pump (proposals)#Watchlist bolding

Suddenly, the article titles in watchlist are in bold letters. I dislike the use of bold letters, since the article titles are not important, but the changes have been made are important in watchlist. --Tito Dutta 16:51, 10 May 2012 (UTC)

Just hit the button that says mark all viewed. The bold is to show which you have visited and which you haven't. I don't really like it either so I just hit the button every once in a while. Kumioko (talk) 16:55, 10 May 2012 (UTC)
I absolutely hate having to do that!--Jasper Deng (talk) 16:55, 10 May 2012 (UTC)
Fully Agree - makes the Watchlist page much more difficult to read, not easier. Don't know whose idea it was, but it wasn't bust, so you haven't fixed it. Please revert to the old layout or at least provide a switch in My Preferences to turn it off. Arjayay (talk) 16:58, 10 May 2012 (UTC)
I expect there is a way to turn it off in preferences but its locked at the moment. If you look under gadgets there's probably a new feature box to turn it off. Kumioko (talk) 17:00, 10 May 2012 (UTC)
But an article I'v just been editing doesn't show up bold. And articles that I watch and have never edited show up as bold. I don't think it's working right. It's awful. MathewTownsend (talk) 17:02, 10 May 2012 (UTC)
Like the Village pump isn't bolded on my watchlist, and I just edited it. MathewTownsend (talk) 17:07, 10 May 2012 (UTC)
I'm pretty sure the bolded pages are ones you haven't viewed since they were last updated, while the non-bolded ones are ones you have viewed since they were last updated. I think that is the way it is intended to work, but I too would like an option to turn the bolding off. Calathan (talk) 17:11, 10 May 2012 (UTC)
So ... ugly, non-useful, and distracting is the default which can only be gotten around by a manual action each time the page gets viewed? Not good. Should be a setting added to User Preferences.
While we're on the subject of ugly, non-useful, and distracting changes ... adding green-blocked text on the history tab should also be a User Preference setting. Hopefully a .css setting can be changed to at least change that back to the standard background color. --- Barek (talkcontribs) - 17:03, 10 May 2012 (UTC)
You can try this CSS code in your common.css page.
strong.mw-watched { font-weight: normal !important; }
Hopefully this won't be needed long. – Allen4names 17:05, 10 May 2012 (UTC)
Thanks for that - it's good enough for now. SmartSE (talk) 19:10, 10 May 2012 (UTC)
No - no off-switch in My Preferences - Gadgets Arjayay (talk) 17:07, 10 May 2012 (UTC)
Where is this off-switch? I can't seem to find it. – Allen4names 17:15, 10 May 2012 (UTC)
He said there is none, apparently. But if this change is permanent, a gadget or preference to shut it off will probably be added soon. Equazcion (talk) 17:18, 10 May 2012 (UTC)
Chances are it won't last. They try this every once in a while and it always gets turned off after a while (due to bugs I think). If they do finally keep it around this time, you'll get used to it. It's like everyone complaining about facebook changes, then a week later they can't remember how it used to be. Equazcion (talk) 17:13, 10 May 2012 (UTC)
Your right I agree. IMO they would be better off adding User:Equazcion/CatListMainTalkLinks as a standrd than this though. Kumioko (talk) 17:22, 10 May 2012 (UTC)
Take this damned eyesore away! Why are such New! Brighter! Whiter! "improvement" crap always inflicted on us without notice - then we are forced to jump through hoops to turn the bloody irritants off! They should be opt-in choices, not opt-out. Roger (talk) 17:23, 10 May 2012 (UTC)
  • Ugh, I participated in the discussion where it was decided this should be enabled (Wikipedia:Village pump (proposals)/Archive 83#Enable "Show changes since last visit" on watchlist) and was assured that if activated there would be a gadget/preference where I could switch it off. Why can't whoever's implementing this make being able to switch it off the first priority instead of the last? Jenks24 (talk) 17:23, 10 May 2012 (UTC)
  • Just adding my voice to those who say this is harder to read. Would appreciate some way of being able to switch it off. SlimVirgin (talk) 17:26, 10 May 2012 (UTC)
  • Utterly hideous. Please make it go away. Mr Stephen (talk) 17:29, 10 May 2012 (UTC)
  • Agree. This is very annoying. I don't need a bold face telling me that I need to click on every diff from Helpful Pixie Bot or AnomieBot or MiszaBot. –Roscelese (talkcontribs) 17:32, 10 May 2012 (UTC)
  • It looks the worst when you have a whole day of unviewed changes and the page is full of bold text. Good idea, bad appearance. Chris857 (talk) 17:35, 10 May 2012 (UTC)
  • Far too distracting, not fit for purpose. Please remove and rethink. (Hohum @) 17:37, 10 May 2012 (UTC)
  • Just another voice of disapproval, I genuinely despise this change, having been glad when I joined wikipedia that it wasn't used here (I've seen it used on other wikis using similar software before). A way to remove it would be hugely appreciated. GRAPPLE X 17:38, 10 May 2012 (UTC)
  • (copying from my comment at accidental dupe thread) I really, really would like a way to turn this off. For users like me, who do a lot of their pageviews and diff views through popups, this "unread" bolding misses the point entirely, and results in nearly my entire watchlist being perpetually bold. I understand it could be a useful feature for others, and I can live with it being enabled, even by default, for that reason but pleeeeease give me a way to turn it off in my prefs. A fluffernutter is a sandwich! (talk) 17:39, 10 May 2012 (UTC)
  • Bold the change times, instead of the article titles. --NeilN talk to me 17:39, 10 May 2012 (UTC)
Bold should be the exception not the norm. Secretlondon (talk) 17:40, 10 May 2012 (UTC)
  • This feature would be a useful tool if one could opt-IN rather than being forced to opt-OUT. Sctechlaw (talk) 17:43, 10 May 2012 (UTC)
  • Yes, and it would be helpful if some sort of banner informed us of the impending change, just logged out did a Ccleaner to check that it wasn't some malware fugging around, and then figured that if it wasn't at the Help Desk, it'd be here. Yuk! Make it go away. CaptainScreebo Parley! 17:54, 10 May 2012 (UTC)
  • I dislike this. I'm all for making it easier to remember which pages have changes I haven't viewed yet, but for a watchlist with 900+ items on it this is a bit excessive...there's no way I'm going to visit all of those pages regularly even if they get changed. It's great for projects I only visit once and a while like Wiktionary or Wikinews, but on English Wikipedia this feature gives me more hassle than I get benefit. An option to turn off this feature would be nice, but not urgent. Ks0stm (TCGE) 18:05, 10 May 2012 (UTC)
  • Yet AGAIN something that's a SUBJECTIVE change where they don't give a CHOICE. Make it an option and make the OLD way default (and remove that hideous gray button too). ♫ Melodia Chaconne ♫ (talk) 18:14, 10 May 2012 (UTC)
  • Another vote for the dislike camp. This sort of change would be so much better if it were opt in. This makes the page harder to read. - X201 (talk) 18:14, 10 May 2012 (UTC)
  • Ugh! Please turn it off. Rivertorch (talk) 18:25, 10 May 2012 (UTC)
  • Well, hey, just so it doesnt seem like everyone hates it. I think it's a good idea though I'll admit I don't read all the pages on my watchlist anymore. But if I did then it's good to be able to know where I've been. Soap 18:27, 10 May 2012 (UTC)
  • With Ks0stm on this one - on Commons it's nice, here it's unmanageable. --Rschen7754 18:33, 10 May 2012 (UTC)
  • Adding to my earlier comment - I have almost 2000 watchlist items. I, at most, look at only one in ten of the items on my watchlist on any given day. I can actually tell the difference between visited and unvisited links - a colour change has been a standard feature of browsers since Microsoft's head office was in dad's garage! No change should ever be permitted to "go live" without a working disable switch but in any case they should always be opt-in, not opt-out. Why were we not all given a prominent notification of this in the form of a banner? Do the software geeks even live on the same planet us we lowly "unworthy of being consulted about such highly important and sophisticated technology" users? Finally; where should we send the hate-mail? Roger (talk) 18:35, 10 May 2012 (UTC)
  • Make it stop, please :( ~~ Lothar von Richthofen (talk) 18:38, 10 May 2012 (UTC)
  • I agree, please turn it off by default or at least allow us to switch it off. Regards SoWhy 18:52, 10 May 2012 (UTC)
  • Sadly, a poor solution to what was not really a problem. Implementing the feature might have had consensus, but I don't think there was consensus for it to be on by default, and there was certainly no consensus to not allow editors to disable it at all. At the very least, let us turn this off; I would suggest that, unless consensus is established otherwise, the default is to be switched off. ItsZippy (talkcontributions) 19:05, 10 May 2012 (UTC)
  • Kill it with fire, but please first disable the feature so I don't have to see the change where it was killed be bold. I dislike when others tell me (and especially change) what part of a display deserves my attention and don't let me control that (I also see where this concern was explicitly raised in the discussion leading to it!). My use of watchlist is not centered around "what changes have I not examined yet?", which is what this bolding emphasizes. And by keeping already-viewed not-bold, those pages become essentially invisible, lost in the wall of non-bold text that includes all the details of the changes (who/when and links). If the goal is to help us find pages whose changes we haven't seen yet, how about a checkbox to filter the list on exactly that criterion? I use popups to see the [diff] of the change and to browse the [history] of recent changes so it's quite likely that I will never click on the link for the page itself, so "changes I've seen" are not registered and the page stays bold. That's functionally broken, not just "bold is annoying". DMacks (talk) 19:07, 10 May 2012 (UTC)
  • Really annoying. I use popups to view diffs on my watchlist and rarely view the full link. Please disable, make Opt-in, or provide a gadget to make this go away. --auburnpilot talk 19:08, 10 May 2012 (UTC)
  • Get rid of it! I don't like it as I think it's completly unnessecary and distracting and why were we not informed before this was thrust upon us? The C of E. God Save The Queen! (talk) 19:33, 10 May 2012 (UTC)
  • The thing is, I don't want to check each page that has changed. About half of the pages that pop up in my watchlist are vandalism reverts, some others are on discussions that don't bother me. I usually open all the changes that interest me in a separate tab before I'm reading them, so this change doesn't help me in any way. If it is kept it should be made optional. It could also help to mark viewed pages in italic letters, which are far less distracting. Nageh (talk) 19:35, 10 May 2012 (UTC)
  • Do not want! Seriously... This is something that the Engagement group would have nailed to the wall in early user acceptance ad completely un-acceptable. Please let me know when the people who were sent to sack the sackers have been sacked. Hasteur (talk) 19:38, 10 May 2012 (UTC)
  • There has beena big discussion on bolding of epsiode titles for episode list template and it was removed as it was agreed it conveys MOS and also makes it harder to read witha screen reader, altohugh i personally like bolding this is to far even for me with dsylexica i dnt need it highlight in bold to knwo there a change since i generally know what time i was last on so i look at all changes i feel are relevent to look at and review them from the pop up for history, either make it not default or give the abilty to turn it off, very bad idea that has made it nearly unreadable to disable users like myself--Andrewcrawford (talk - contrib) 20:08, 10 May 2012 (UTC)
  • Just a thanks to those who explained how to override this change. I've got no desire to argue about pros-cons of this in general, but I was definately looking for a way to turmn it off.--Cube lurker (talk) 20:45, 10 May 2012 (UTC)
  • Turn it off by default. It's useless for anyone who uses Popups. And as far as community opinion goes, you're getting it here, now.  —SMALLJIM  20:48, 10 May 2012 (UTC)
      Bold letters changed to starscyberpower ChatOnline 20:58, 10 May 2012 (UTC)
  • Brilliant. As soon as a kludge arises to deal with some of the changes, said changes are replaced with something else instead; rather than spending time coding green stars instead of bold links, just devise an opt-out function and the problem's solved. GRAPPLE X 20:56, 10 May 2012 (UTC)
  • The stars are annoying for similar reasons. They're less cluttersome to the watchlist, but as I said before, I don't need the interface telling me "LOOK AT THIS BOT EDIT or MINOR EDIT, DON'T YOU WANT TO SEE IT, WHY DIDN'T YOU LOOK AT IT YET." –Roscelese (talkcontribs) 21:06, 10 May 2012 (UTC)
  • Please turn this off! The green stars are only marginally less annoying and perhaps equally as annoying as the bolded text. Each time I log in today I see something different. We have masses and masses of discussions about the smallest things here, but three major changes in a day? What happened to Wikipedia where consensus rules? Truthkeeper (talk) 21:12, 10 May 2012 (UTC)
  •   Off-think, off-think, off-think. Bolding and stars, it's like throwing glitter over the watch-list to make it pretty. Ugh. -- (talk) 22:22, 10 May 2012 (UTC)
  • I would get rid of this entirely, but if this is to stay, or for the interim, can we change updated since my last visit in page histories to green stars as well?--Fuhghettaboutit (talk) 22:26, 10 May 2012 (UTC)
    1. Why is this not optional for those who want it, and not off by default for those who don't even know what it is?
    2. Why is there no legend or something explaining what it means? It's very disorienting, and it wasn't easy to find out what it was about.
    3. Why is it so difficult (non-obvious) to shut off? CüRlyTüRkeyTalkContribs 23:17, 10 May 2012 (UTC)
Because we have always had a problem where the developers make sweeping changes without any real community input—the change from the Monobook Skin to the Vector Skin being a sterling highlight (the alleged community input and testing there was an absolute sham).--Fuhghettaboutit (talk) 23:21, 10 May 2012 (UTC)
  • Seeing text on your watchlist in boldface must be an eyesore, especially if your watched pages are heavily edited and you weren't aware of the change earlier, isn't it? I knew we should always be bold, but not like this. Narutolovehinata5 tccsdnew 02:16, 11 May 2012 (UTC)
  • The green highlighting on history pages is bloody awful. Get rid of it! MER-C 04:23, 11 May 2012 (UTC)
  • Even though pretty much everything has been mentioned, I wanted to add that it's hard to read (on this (admittedly small) monitor I'm currently using, anyway). Also, it will be crap to deal with after my two-month wikibreak I'll be taking in about two weeks. - Purplewowies (talk) (How's my driving?) 04:35, 11 May 2012 (UTC)
  • Kill with fire This is awful. It makes the watch list more difficult to read. A particular mistake is that it makes assumptions about how people use the watchlist and what they do when they visit a page. It sounds like something that would make a nice gadget - maybe some people would like it or find it useful, but it is a great assumption that many or everyone would. --RA (talk) 12:44, 11 May 2012 (UTC)

Positive feedback here!

The change took me by suprise as well, but the community wanted this change. Instead of a mass-call for disabling it again, post some opinions on how you want changed pages to look on your watchlist. Perhaps a green star in front of the page name? Edokter (talk) — 18:58, 10 May 2012 (UTC)

Sorry just butting in here but what community? the overwhelming reaction is WTF, OMG, this is spawnbreath etc., i.e. people seem fairly upset and hostile to this community decision. CaptainScreebo Parley! 19:32, 10 May 2012 (UTC)
This community, the English Wikipedia community. --Yair rand (talk) —Preceding undated comment added 20:27, 10 May 2012 (UTC).
I don't want changed pages to look like anything. The fact that they appear on the watchlist is signal enough that a change has occurred. No? I use popups to view diffs and rarely click through to the entire page. This change is annoying. --auburnpilot talk 19:03, 10 May 2012 (UTC)
Honestly, I would rather there was no additional change. I can tell when a page I'm interested in has been changed simply by checking who the last contributor was; or simply by seeing that the "diff" link has already been viewed based on its colour. I understand that this change can be useful for some editors but by surprising everyone with it without notice it's basically forced a lot of us to put up with a nuisance while a fix is found for those who dislike it; an opt-in, rather than opt-out change would have been much more welcome from all parties as those who benefit would be able to use it and those who don't wouldn't have to take extra measures to avoid it. GRAPPLE X 19:03, 10 May 2012 (UTC)
  • I highly disagree. There are people who want it and people who don't, and I personally think it is only effective on small wikis, not the largest one in the world (this one). I know what's new and what's old, I don't need a second annoying reminder! That proposal actually needed an RfC.--Jasper Deng (talk) 19:06, 10 May 2012 (UTC)
Are you for real! Have you even read any of the above posts?
Here's my positive feedback:
"but the community wanted this change"[citation needed]
"post some opinions on how you want changed pages to look on your watchlist" The short answer is that everyone who complained above want their watchlists to look the way they used to look just a few hours ago! We don't need no steenkin' bolding or green stars or other shit! Roger (talk) 19:09, 10 May 2012 (UTC)
(edit conflict)(edit conflict)The watchlist was fine as it was; any change is just a massive eyesore. I keep a lot of pages watchlisted just to keep an eye on them if anything out of the ordinary happens, and I don't need some ugly function to let me know when some bot adds an interwiki or some random person fixes a typo. The pages that I'm involved actively in I already know when someone does something. ~~ Lothar von Richthofen (talk) 19:10, 10 May 2012 (UTC)
How I want to change it: Okay, 1) Add an option Show/Sort unread the way we have options like Hide minor edits | Hide bots | Hide anonymous users | Hide logged-in users | Show my edits | Hide patrolled edits in watchlist. or 2) Add a "U" to show unread the way bot edits are shown by "b" and minor edits by "m" --Tito Dutta 19:23, 10 May 2012 (UTC)
remove bolding. The fact that a page is on my watchlist is enough. It's already a burden to deal with my watchlist, even without the bolding. Motivates me to cut my watchlist down. MathewTownsend (talk) 19:22, 10 May 2012 (UTC)
Agree with all the above repliers after skimming the replies, I know where I've been (different shaded links), I know where I want to go (where I want, thanks) and I hate "you're absolutely gonna love this" changes without being informed in advance. CaptainScreebo Parley! 19:28, 10 May 2012 (UTC)
So where the fuck are the "recent discussions" and the community wide notification that such dicussions were happening? These type of discussions should not be allowed to take place in some deliberately obscure hidden corner of the site. Our overlords love inflicting fugly banners on us when they want money but they can't be botherred to place similar banners notifying everybody of such far-reaching proposals. I'm sorry but such underhanded bad faith actions by the technical cabal are totally unacceptable. Roger (talk) 20:17, 10 May 2012 (UTC)
It's called the proposals section of the Village Pump, and if you don't pay attention to it, you're going to miss some things. It was also listed in the Centralized Discussion list. That is not "deliberately obscure", that's as publicized as it gets around here, short of watchlist notices and horrid sitewide banners. --Yair rand (talk) 20:34, 10 May 2012 (UTC)
Agree with statement directly above. Kill it. Good intentions but turned out to be a bad idea. Mugginsx (talk) 23:24, 10 May 2012 (UTC)
"Horrid sitewide banners" is exactly what we do want for proposals with such drastic consequences that affect all users. Roger (talk) 20:50, 10 May 2012 (UTC)
Drastic consequences? Really? Changing the formatting of one element in a list is "drastic consequences" in your books? WhatamIdoing (talk) 23:37, 10 May 2012 (UTC)
  • All I can say is, good change, but it took me coming here to figure out what the bold meant. Please don't disable it, but if you could make a "disable" button in preferences I'm sure ^some people^ would appreciate it.-RunningOnBrains(talk) 20:11, 10 May 2012 (UTC)
  • Don't change a bloody thing - This change was supported by the community 6 months ago, and it has simply taken that long to actually implement it. Provide an opt-out option for those who don't like it, but keep recent changes on as default. Within a few days, people will forget. Ugly? How? Not useful? Are you kidding me?! Consensus was for this, those who didn't participate probably don't participate in VP discussions until after a change takes place that they dislike. - ʄɭoʏɗiaɲ τ ¢ 20:24, 10 May 2012 (UTC)
    Likely because the first time many of us knew about such a discussion was six months after it was over. We can get incessant watchlist notices about the Muhammad RFC but none about a change which affects every editor? If these discussions were as widely advertised as narrow RFCs are there'd be a much higher turnout, and complaints like these would be tempered by the fact that there'd have been six months to devise a shut-off fix. GRAPPLE X 20:28, 10 May 2012 (UTC)
    Or if people added the four village pump pages and WP:CENT to their watchlist, and actually kept abreast of what's going on, it wouldn't need to be. Why don't we just get rid of all these boards, the RfC process, and centralized discussion, and just place a list of upcoming changes into a banner that appears at the top of every page. I'm certain that this would not receive any complaints, and that nobody would minimize the banner until after reading it daily. - ʄɭoʏɗiaɲ τ ¢ 13:54, 13 May 2012 (UTC)
What does it take to get somebody/anybody to just post a link to the alleged consensus discussion! Roger (talk) 20:33, 10 May 2012 (UTC)
It was posted above: Wikipedia:Village pump (proposals)/Archive 83#Enable "Show changes since last visit" on watchlist. PrimeHunter (talk) 20:37, 10 May 2012 (UTC)
  • To answer the question at the top of the thread - I think that by default having a page show up on a watchlist indicates that it's been changed. Not sure why we need to have the bolding, but I will say this: for someone who doesn't have great eyesight, the bolded pages (ones I rarely check) are making the unbolded ones (ones I frequently check) nearly invisible. So it's very difficult to see much, except a sea of bolded purple. Having Helpful Pixie bot on a rampage at the moment isn't much help b/c my entire watchlist has been hit in the past few days which is unusual. Anyway, not a fan of this at all, but can't think of how watched changes should look - other than having them show on the watchlist? Truthkeeper (talk) 20:44, 10 May 2012 (UTC)
    This doesn't show that it's been changed since you last edited the page. It shows that it's been changed since you last read the page. If it's not in bold, then there is no need for you to check the page at all, because it has not been changed since the last time you checked it. WhatamIdoing (talk) 23:39, 10 May 2012 (UTC)
  • Give it a day or so, and you'll adjust. This is exactly how my e-mail clients (yes, plural), newsreaders, etc. work. Items that have changed since you last visited them are in bold. I support this, but oppose the fidgeting with the CSS to add/change the display. Leave it be, and at worst, add a button next to the "Mark all pages visited" button to shut it off for people. Imzadi 1979  21:03, 11 May 2012 (UTC)
  • Is this where I voice my support for these changes? We already have bold titles in recent changes for articles on your watchlist. Seems like there's precedence for bold titles in watch lists. Maybe it's unclear why they're bold but it's not ugly and certainly not hideous. Please do not take away the functionality for aesthetic reasons. If you pull your head out of your everyday experience, you'll see that the watchlist is already plenty ugly. I am often away from Wikipedia for days and before this feature I've had to manually track what I had and had not reviewed. I would prefer that bolding was used in both the watchlist and in article histories to indicate unreviewed changes. Failing that, please put some sort of unreviewed indicator near the links on the left hand side of the entries. I want the indicators to be near the links I click in response to seeing them --Kvng (talk) 13:35, 13 May 2012 (UTC)

How to forcefully revert this change

Is there a script or simalar kludge method to "sabotage" this change? I want it gone, dead, destroyed, terminated, extinguished, whacked, sleeping with the fishes asap! Oh and btw does anyone know where to send the hate mail? Roger (talk) 19:19, 10 May 2012 (UTC)

There's a change listed above that can remove the bolding by adding a line to your custom CSS page; but it still leaves the "mark all pages visited" button sitting there. GRAPPLE X 19:20, 10 May 2012 (UTC)
Found it, thanks, but you're going to have to talk slowly in words of no more than two syllables: Where is my "custom CSS page" and how do I add the script to it? (I need "paint by numbers" instructions) Roger (talk) 19:26, 10 May 2012 (UTC)
Click "my preferences", and then click the "appearance" tab. There should be a line which reads "Shared CSS/JavaScript for all skins: Custom CSS | Custom JavaScript". The "Custom CSS" part should be a red link; click it to be brought to an edit screen for your personal CSS settings. It'll be blank as I'm assuming you've never created one. Paste the above code into it and save it; that'll create the page and apply that code regardless of which skin you're using. Check your watchlist afterwards to be sure it's worked. GRAPPLE X 19:31, 10 May 2012 (UTC)
Your custom css page is right here. --illythr (talk) 19:34, 10 May 2012 (UTC)
Probably worth pointing out that the above link works for everyone. It should look something like this when you're done. SmartSE (talk) 19:37, 10 May 2012 (UTC)
It works! Yay! Now all that remains is the little matter of sending some hate mail... <evil smirk> Roger (talk) 19:38, 10 May 2012 (UTC)
Seriously, do the software coders cabal have a talk page where we can directly communicate our unhappiness about this? Roger (talk) 19:47, 10 May 2012 (UTC)
Oh, that's going to be a big help. The devs respond to a consensus-backed community request, and since there weren't enough people who were aware of the community discussion, they get lots of non-consensus-backed complaints and undo-requests on something that the community could deal with themselves if necessary. Sheesh. Make a simple proposal to undo the change on VPR, and if the community supports it, an admin can add the CSS to common.css. --Yair rand (talk) 20:15, 10 May 2012 (UTC)
Thanks worked, if there was anything positive in the change I couldn't see it because blinded by a hundred bold lines. --Tikiwont (talk) 19:51, 10 May 2012 (UTC)

forceful change didn't work for me. Can't figure out why. MathewTownsend (talk) 20:50, 10 May 2012 (UTC)

The line at the top of your CSS (// remove bolding of watchlist) is breaking it. CSS comments don't work like that. --Yair rand (talk) 21:27, 10 May 2012 (UTC)
Thanks! MathewTownsend (talk) 21:36, 10 May 2012 (UTC)
Nasty, brutish and short, thanks to that code. Please accept that this is the best idea since New Coke.--Wehwalt (talk) 22:44, 10 May 2012 (UTC)
I wouldn't compare bolding watchlist items to New Coke... The forced switch to the Vector skin, on the other hand... - ʄɭoʏɗiaɲ τ ¢ 13:57, 13 May 2012 (UTC)

Related changes

At the same time that the watchlist change went into effect, there was also a change to the history tab on articles. To see it, from your watchlist, click the "Hist" link for any article you haven't yet viewed. Next to every new edit is text with a bright-green background that states "updated since my last visit". Does anyone know the css change that can, at the very least, kill the background coloring? --- Barek (talkcontribs) - 19:40, 10 May 2012 (UTC)

I see it in ordinary text, no green, so the above script must have killed it too. Roger (talk) 19:45, 10 May 2012 (UTC)
I still see it, and I'm using the above script. I'm using the Monobook skin though, so maybe that change was kept out of Vector? I'll need to test. --- Barek (talkcontribs) - 19:48, 10 May 2012 (UTC)
Confirmed ... this lovely "enhancement" was reserved as a special treat just for us hold-outs that are still using the MonoBook skin ... the Vector skin was mercifully spared this eye-sore.
For those of us on MonoBook yet, anyone know how to kill this one? --- Barek (talkcontribs) - 19:52, 10 May 2012 (UTC)
It's from http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/skins/monobook/main.css?view=markup which says:

span.updatedmarker { color: black; background-color: #0f0; }

PrimeHunter (talk) 20:02, 10 May 2012 (UTC)
I don't know much CSS but this in Special:MyPage/monobook.css changes the background from green to white for me:

span.updatedmarker { background-color: white; }

PrimeHunter (talk) 20:12, 10 May 2012 (UTC)
Thanks for finding the source! I just added:

span.updatedmarker {background-color: transparent; }

And that seems to fix it for me (I tried using white at first, but the normal background appears to be off-white, so was still noticeable). --- Barek (talkcontribs) - 20:16, 10 May 2012 (UTC)
If you want to get rid of it entirely, you can use span.updatedmarker{display:none;}. --Yair rand (talk) 20:21, 10 May 2012 (UTC)
I had just found that css formatting via a Google search - I should've just waited for the post here. :-) --- Barek (talkcontribs) - 20:26, 10 May 2012 (UTC)
Thanks for this code - to which page should it be added? Truthkeeper (talk) 20:29, 10 May 2012 (UTC)
Add it to Special:MyPage/monobook.css as said above. PrimeHunter (talk) 20:31, 10 May 2012 (UTC)
That's only for users of the monobook skin. For everyone else, use Special:MyPage/common.css. --Yair rand (talk) 20:51, 10 May 2012 (UTC)
I realize this is probably the wrong place to ask for css tips ... but, instead of hiding entirely, is there a way to replace the text "updated since my last visit" with something more compact, like a single bold asterisk or other symbol/character? I can see a potential use for this one ... but the initial implementation was just too distracting to be effective. --- Barek (talkcontribs) - 20:44, 10 May 2012 (UTC)
How about this: .updatedmarker{overflow:hidden;display:inline-block;height:1em;width:10px;}span.updatedmarker::before{content:'*';font-weight:bold;font-size:20px;width:10px;display:inline-block;} It's a bit hack-y, but it'll work, I think. --Yair rand (talk) 21:04, 10 May 2012 (UTC)

It made its way to default now too...except in green text instead of a green background. I don't need help figuring out what has changed since I last viewed a page. Please tell me there are options to shut off these page cluttering stars and annoying notes. --OnoremDil 21:06, 10 May 2012 (UTC)

It's no longer green, which I actually find more annoying because I now keep thinking it was an intentional part of the edit summary left by the person making the edit. Is there a css fix to getting rid of the 'updated since my last visit' annoyance? --OnoremDil 14:54, 11 May 2012 (UTC)

Seeing stars

Both the "bold hears the go-away bird" and "green box-b-gone" scripts are brilliant, and thank you very much. :) But...is there a script for banishing those horrid green stars from the watchlist? - The Bushranger One ping only 21:11, 10 May 2012 (UTC)
The stars were added by Edokter twenty minutes ago: [13]. CSS to get rid of the stars: strong.mw-watched a{background:none;padding-left:0;}. Anyone want to make that into a gadget? --Yair rand (talk) 21:13, 10 May 2012 (UTC)
Thank you!!! - The Bushranger One ping only 21:18, 10 May 2012 (UTC)
On the subject, is it possible to hide that "mark all pages visited" button too? If I can just hide the changes and resume the functionality of the previous version I'll be happy to go on my merry way, but only hiding half of the changes isn't really doing it for me. GRAPPLE X 21:15, 10 May 2012 (UTC)
#mw-watchlist-resetbutton{display:none} should do it. --Yair rand (talk) 21:19, 10 May 2012 (UTC)
Thank you so much for the css workaround. It was incredibly annoying to find a workaround for the bold ugliness suddenly worthless due to a starry ugliness. --OnoremDil 21:17, 10 May 2012 (UTC)
Thanks, Yair! That's me satisfied for now, anyway. Back to content creation again. GRAPPLE X 21:25, 10 May 2012 (UTC)

And now the bold is back. Make up your fucking minds so I know which bullshit workaround I need to use. The one that stops the bold watchlist screws with how watchlisted articles appears in the recent changes list. --OnoremDil 22:20, 10 May 2012 (UTC)

Green star invasion

Now the watchlist has been invaded by fugly green stars! We need a starblaster script. Roger (talk) 21:08, 10 May 2012 (UTC)

Looking for smaller stars... It's a concept. Stop stifling innovation! Edokter (talk) — 21:10, 10 May 2012 (UTC)
Wikipedia is not a sandbox. If they really had to do this for that purpose, they should've done this on a test wiki and recruited people from this wiki.--Jasper Deng (talk) 21:30, 10 May 2012 (UTC)
No, do not like green star. Distracting! --Tito Dutta 21:12, 10 May 2012 (UTC)
The stars are kinda cute. But all I see is people asking for an off-button. I guess the devs just thought, "Hey, everyone likes stars right? Just bombard them with stars until they shut up." STARS. (on an off note, I will support the stars if I can make them different colours. Rainbow stars). OohBunnies! Leave a message 21:14, 10 May 2012 (UTC)

They suddenly appeared on my watchlist and my first thought was: WTF (or should I say WMF)? Where has this been announced? -- Toshio Yamaguchi (tlkctb) 21:13, 10 May 2012 (UTC)

I agree. I was able to get rid of the watchlist bolding with the CSS code, but now there are green stars by the article title names and still the "updated since my last visit" text by revisions on the history page. I'm hoping there will soon be a way to kill these additions as well. After working on Wikipedia for more than two and a half years, I've gotten used to a certain setup, and I wish to continue editing the way I am used to. I'd really prefer a gadget over more code I am not generally familiar with. —Sgt. R.K. Blue (talk) 21:15, 10 May 2012 (UTC)
You don't have my permission to inflict your "innovation" on my watchlist. Roger (talk) 21:16, 10 May 2012 (UTC)
UAT - the secret to great implementation. One day, I'll teach the developers what it means lol. The bolding of unread changes was a bit eyewatering, but fitted with custom and practice elsewhere - email clients generally do it, forums generally do it. But hey guys, green stars DO NOT WANT.--Elen of the Roads (talk) 21:19, 10 May 2012 (UTC)
Funky stuff-Watchlist stars-posting on a user talk page
  • I now have cute little stars on my watchlist. Kind of like them.
  • When I try to post on a user page - and it's only one user - I get that full-screen Wikimedia error message about the servers being busy. I can post on any other talk page I've tried as a test. But not this one. Maile66 (talk) 21:10, 10 May 2012 (UTC)
Green star

I like the changes. Well, I don't entirely understand them. I instantly liked the use of bold letters to indicate unread changes, as soon as it happened, because I'm accustomed to it from Commons. Suddenly I'm getting a green star instead of bold; my guess is it does the same thing. My preference would be for slower changes, but anyway I won't go along with my fellow old fogies who instantly hate anything they don't instantly understand. I'm confident it will take only a little study to turn these novelties into tools to increase my pleasure and efficiency. Jim.henderson (talk) 21:13, 10 May 2012 (UTC)

The green star seems reasonable to me, far better than the emboldening, but it needs to be smaller. Malleus Fatuorum 21:15, 10 May 2012 (UTC)
Yes, smaller, and maybe a slightly less obtrusive color. --Rschen7754 21:18, 10 May 2012 (UTC)
The green stars are a much better idea than the bolding, I'll admit. But there does need to be a "canonical" on/off switch for us old farts who like our MonoBook and our watchlist The Way They Were, thankyaveddymuch. ;) - The Bushranger One ping only 21:20, 10 May 2012 (UTC)
The green starts are better than the bold. But that's not the point - just gives us an option to turn them off. Better - let us choose between bold, stars, off, and whatever else people come up with. That way everyone's happy. ItsZippy (talkcontributions) 21:21, 10 May 2012 (UTC)
Smaller star found. There's not going to be an option. If every change needs an option to turn it off, there's going to be a gazillion options, which will totally overwhelm new users. Edokter (talk) — 21:22, 10 May 2012 (UTC)
Then make an advanced tab for those that want it. Who are you to say that "There's not going to be an option?" --OnoremDil 21:24, 10 May 2012 (UTC)
(edit conflict) There are already a gazillion options and I'm still overwhelmed by them after 6 years. A gazillion and one doesn't bother me. In fact I'm comforted to know that when I want to find an option, it's probably there, since there are so many. Equazcion (talk) 21:25, 10 May 2012 (UTC)
  • Green makes me think "These are the ones you've already checked". Star makes me think "These are of particular interest". They should be black bullet points instead. Or just give us a bunch of options. Equazcion (talk) 21:21, 10 May 2012 (UTC)
It's all reasonable, as an option or if implemented with the option to not have it forced on you. I'm comfortable changing my css pages...even if I haven't done it much and screwed up with my first attempt today...but many people aren't. Have a damn checkbox in preferences ready if you (not you, Malleus) decide to change what options I have. --OnoremDil 21:23, 10 May 2012 (UTC)

How to banish the Green Star Invasion: Step 1 navigate to your CSS stylesheet for the theme you're using. Step 2, Add strong.mw-watched a { background: none; padding-left:0px;} to the list of CSS rules. Step 3, send Hasteur some hummus, for I am hungry. Hasteur (talk) 21:25, 10 May 2012 (UTC)

  • I assume that it would be something like adding this to your CSS: [14] --Rschen7754 21:31, 10 May 2012 (UTC)
Adding strong.mw-watched a {background: url(//upload.wikimedia.org/wikipedia/commons/thumb/b/b3/Asterisk.png/13px-Asterisk.png) no-repeat left;} to your CSS will change it to use the image File:Asterisk.png. Just replace Asterisk.png with any other file name to use a different image. You can find tons of star images on Commons. --Yair rand (talk) 21:38, 10 May 2012 (UTC)
Thanks! I'm very grateful. OohBunnies! Leave a message 21:40, 10 May 2012 (UTC)
I want the choice to not have stars! These changes may be useful for some people - those with only a handful of watched pages who habitually look at every change as it comes up on their watchlists. But for many of us that watch thoudsands of pages and only examine a few of every day's listings it is a major eyesore. Roger (talk) 21:25, 10 May 2012 (UTC)
  • I am a little amused that we react to a change described as undiscussed and obtrusive by... rushing into a different change which is similarly intrusive, four hours after the first complaint. That said, I don't really mind either version (and the mark-as-viewed functionality is potentially useful), but... if we're keeping the green stars, could we align them? At the moment they're on the right of the "m" and "b" watchlist notes for minor and bot edits, so what would be a clear vertical line showing viewed or not becomes a ragged line that's much harder to skim down. Andrew Gray (talk) 21:36, 10 May 2012 (UTC)

Other way around. It's precisely us obsessive-compulsive noodges with 5,534 watched pages who can benefit by this feature to tell us which of the two hundred on the screen we have already examined. It's a big help for me in Commons (where it's done by bold; no big difference to me) and I have long hoped en would catch up. Jim.henderson (talk) 21:40, 10 May 2012 (UTC)

Jim - if you used Popups to look at your diffs, you'd be able to whizz through them much quicker, and you'd see why any form of flagging changes like this is so annoying, because the flag doesn't go away when you've looked at the change.  —SMALLJIM  22:01, 10 May 2012 (UTC)
  • (ec) Please get rid of the green stars. I have 900 pages on my watchlist. Too many green stars, and what are they supposed to do anyway? MathewTownsend (talk) 21:42, 10 May 2012 (UTC)
    The stars indicate that you haven't viewed the page since the last edit to it was made. --Yair rand (talk) 21:44, 10 May 2012 (UTC)
    But this page has a green star after it on my watchlist and this is my third or fourth edit to it in the last hour. MathewTownsend (talk) 21:50, 10 May 2012 (UTC)
  • As I'm getting used to seeing it, I kind of like being able to see at a glance which pages on my watchlist have changed since I last visited them, and which haven't changed. But I also am sympathetic to the negative opinions about how intrusive the display is. How about making the stars blue, like the rest of the font characters? --Tryptofish (talk) 22:10, 10 May 2012 (UTC)
    But you can see that anyway by the bytes added or subtracted. I'm going to take this page off my watchlist to get rid of some of the stars. MathewTownsend (talk) 22:20, 10 May 2012 (UTC)
    No, you can't. (-24) does not tell me "you've already looked at that change". The bold/green stars/whatever tells me which pages I've read in their current state. WhatamIdoing (talk) 23:48, 10 May 2012 (UTC)
    Actually the fact that the hyperlink has changed from blue to purple is an indication that I've already looked at it. This has been a standard feature of practically all web browsers since the original Mosaic (web browser) first appeared. 00:01, 11 May 2012 (UTC) — Preceding unsigned comment added by Dodger67 (talkcontribs)
    Yes, that tells me whether I've looked at the page (in my case) sometime during the last 30 days. That's not helpful if I want to know whether a busy page, like this one, has changed since the last time I looked at it, which was probably only a couple of hours ago. WhatamIdoing (talk) 02:19, 14 May 2012 (UTC)

If only I could touch the green star and see what it means. -DePiep (talk) 22:31, 10 May 2012 (UTC)

A sorting option please

I change my opinion. Green stars are much better! Also I suggest to add an option Show/Sort unread the way we have options like Hide minor edits | Hide bots | Hide anonymous users | Hide logged-in users | Show my edits | Hide patrolled edits in watchlist.--Tito Dutta 21:29, 10 May 2012 (UTC)

Yes, the third change in an hour is better. But I'd get shot if I started testing in a live environment, which is plainly what someone is doing here. --Elen of the Roads (talk) 21:34, 10 May 2012 (UTC)

RFC

To actually get the whole community's opinions, I'm starting an RFC on this:

Please describe your view of this new change. Indicate whether you:

  1. Absolutely hate this change and want it abolished.
  2. Want the change to be revised (explain exactly how)
  3. Want an opt-out other than a gadget
  4. Want it to be opt-in
  5. Do not care about the change
  6. Support the change

When closing this RFC, please consider the discussion above.--Jasper Deng (talk) 21:40, 10 May 2012 (UTC)

  • Opt-in: Unless it's something that is required to be in place technical wise, it's always better to give users an option to opt-in. Announce/incentiveize/convince all you like, but it's the User interface you're putzing with here. Hasteur (talk) 21:47, 10 May 2012 (UTC)
  • Opt-in: as per Hasteur. NtheP (talk) 21:53, 10 May 2012 (UTC)
  • Opt-in: In fact I think it should policy that all user interface changes should be strictly on an opt-in basis only. Roger (talk) 21:52, 10 May 2012 (UTC)
  • Opt-in: Want to opt in! Want a newsletter like signpost which will inform about the new features like this and allow us to opt in --Tito Dutta 22:05, 10 May 2012 (UTC)
  • Opt-in: Sctechlaw (talk) 22:11, 10 May 2012 (UTC)
  • Opt-in personally I find it very annoying and virtually useless, it's obvious lots of people feel the same way, and the previous discussion didn't get enough participation for such a change. Hut 8.5 22:14, 10 May 2012 (UTC)
  • Opt-in. A real good way to avoid getting the kinds of complaints showing up here, just common sense. Ironically, people will tend to like something more when they have chosen to opt into it. This should always be the process. But I kind of like the feature, just wish that it were less visually intrusive. I suggested above that the stars be made blue instead of green. --Tryptofish (talk) 22:15, 10 May 2012 (UTC)
  • Opt-in (What the fuck is going on? I lost my edit because of the edit conflict, and now I see hidious green on the history page. Is someone high? Because obviously someone is trying to sabatoge WP to make things more difficuly and ugly all around) ♫ Melodia Chaconne ♫ (talk) 22:18, 10 May 2012 (UTC)
  • Opt-in: As per Roger. Maybe it should even be policy that user interface changes should be gradually deployed, starting with opt-in, and switching to opt-out or default as per community consensus based on live experience. Nageh (talk) 22:21, 10 May 2012 (UTC)
  • Change The functional specification for the current changes appears to be "display all unread items in the watchlist differently". This may be useful for some users, but is no help at all for someone who uses popups to decide whether each changed item needs to be inspected in greater detail or knows that it is not necessary to open every single one of the helpful pixie's ISBN updates. I suggest the following function: "Remember the latest time the watchlist was refreshed and display the first subsequent entry (only) differently next time". This would make it rather easier than at present to see which items have not previously been displayed. It would also be only a single per-user datum to manage. --Mirokado (talk) 22:26, 10 May 2012 (UTC)
  • Leave as is, but give instructions for opting out in MediaWiki:Watchlist-details. I don't particularly like it here, due to the nature of my watchlist, so I've opted out. On the other hand, it's been on Commons for some time, where I find it more useful (as the stuff I watch tends to only change occasionally). Giving people something new to try, then allowing them to opt out if it doesn't suit them, is better than hiding a new option where people won't be aware of it.  An optimist on the run! 22:46, 10 May 2012 (UTC)
  • Opt-in. Second choice involves deletion and salting.--Wehwalt (talk) 22:53, 10 May 2012 (UTC)
  • Opt-in. I like Wehwalt's second choice too. ~~ Lothar von Richthofen (talk) 22:58, 10 May 2012 (UTC)
  •   Comment:: all "opt-in" comments above don't make any sense as there's no way for this feature to be opt-in. Also, this is a very standard feature of MediaWiki, so it would be nice for it to be available in standard ways and not with obscure, user-unfriendly and unusable hacks. Nemo 23:04, 10 May 2012 (UTC)
    • Opt in, in this case, is referring to the fact that this feature should be disabled and presented as an one time offer to the user as part of the configuration or as part of options a user may change at any time (on or off). Hasteur (talk) 23:45, 10 May 2012 (UTC)
      Exactly: that is, something not possible. --Nemo 23:58, 10 May 2012 (UTC)
      Rubbish! Of course it is possible - the code just has to be rewritten to impliment it that way. Roger (talk) 00:09, 11 May 2012 (UTC)
  • Support I have been looking for something like this after years of manually inserting bookmarks into my watchlist. Although there could still be discussion on improving the look and an opt-out for those that don't want it. Opt-in is bad - new users typically don't start off by scrabbling through the settings finding useful things to turn on. SpinningSpark 00:14, 11 May 2012 (UTC)
  • Opt-in please. This truly is migraine inducing - a page splashed with bolded bright purple is difficult to bear. If it stays like this I'll probably delete my entire watchlist and work without one. Truthkeeper (talk) 00:21, 11 May 2012 (UTC)
  • Opt-outmediawikiwiki:Manual:$wgShowUpdatedMarker – This is the default, and it has been the default for years. Encyclopedia Dramatica, Commons, dewiki, Meta, and others have this setting set to "true". It makes it much easier to tell the difference between pages one has visited and pages that've changed since one has last visited it. I find it useful outside of enwiki, and I hope to make use of it on enwiki. I find that Wikipedians resent technical changes, even when those changes are progressive. An opt-out option should be available to those don't wish to open their minds to change. --Michaeldsuarez (talk) 00:46, 11 May 2012 (UTC)
  • Opt-in and can we please stop having these dumped on us without any warning. We put banners on the at the top of our screens for all manner of things including requests for moeny. We should certainly be able to use them to advise us of changes like this. MarnetteD | Talk 01:01, 11 May 2012 (UTC)
  • Revert to this revision and NEVER renable bolding. Having your watchlist in bold in VERY distracting and does NOT make a good style for the encyclopedia. Barts1a / Talk to me / Help me improve 01:21, 11 May 2012 (UTC)
  • Opt-in This is simply an eyesore to use, since my watchlist has a lot of heavily-edited Wikipedia pages (noticeboards, reference desks etc.) What makes it worse is that I was completely unaware of this change until just now, even if there were discussions last December! At lease a message on my watchlist saying "Effective (date), (feature) will be enabled." For now at least, change the code so that it will be opt in! Narutolovehinata5 tccsdnew 01:31, 11 May 2012 (UTC)
  • Abort (option 1) I really don't see the point of the massive use of bolding in the watchlist. I know the devs will scream because apparently the community asked for this feature, and now we're all up in arms. Well, actually, reading the previous discussion that had maybe a dozen participants, that was a rather fanciful wish-list feature with little thought of just how it would be in real life. There ought to have been a further discussion as to its scoping and roll-out. I intensely dislike the 'new' watchlist. I find the bolding is rather obtrusive. Most people who use the watchlist will tell you that ften, it's not the article itself which is the most important link appearing. Frequently, it's the editor, or the diff itself. The highlighting of the titles gives totally the wrong emphasis. I would qualify my vote by saying that I could be persuaded to support it as an opt-in feature (option 4), and definitely not as an opt-out. There is no question to my mind that users who are not logged in ought to be exposed to this at all. More useful features could be 'highlight IP edits' or 'show/hide edits by User:Example' --Ohconfucius ¡digame! 01:43, 11 May 2012 (UTC)
    Well put. My lost comment touched on that too -- checking the watchlist isn't about what articles were changed, it's about what the changes were. I can't be the only one who checks my watchlist by clicking all the DIFFs. Highlight those (though perhaps less 'bold'ly) and we might be getting somewhere. ♫ Melodia Chaconne ♫ (talk) 04:14, 11 May 2012 (UTC)
  • Support: I like it, though I use pop-ups to review the watch-list and seldom actually visit the diffs themselves. The "mark all pages visited" button makes the bold go away and then I can tell where I left off. But the stars were much cuter than the bold. And I have a very small watch-list, less than 500 items, so what works for me likely will not work for everyone. -- Dianna (talk) 03:44, 11 May 2012 (UTC)
  • Opt-in Seriously, stop forcing these things on us when they are only useful for a very small number of people. Make it opt-in so those people can use it and everyone else can ignore it like they want to. SilverserenC 03:46, 11 May 2012 (UTC)
  • Opt-in I LOVE that this feature has been added so I don't have to use ANOTHER script for this functionality (the script isn't all that user-friendly, either). However, because some people use their watchlist differently, make this an opt-in feature (not opt-out, opt-in [I refer you to the WikiLove tab disaster]). --Nathan2055talk 03:56, 11 May 2012 (UTC)
  • Opt-in although I am strongly inclined to choose option #1 with the way this was deployed. – Allen4names 04:14, 11 May 2012 (UTC)
  • If it's done in an unobtrusive way (see below) then I don't care. But at the moment, this is just another nasty surprise. Revise per Eloquence or kill. MER-C 04:18, 11 May 2012 (UTC)
  • Opt-in because some editors like it. Second choice: Option 1. Introduces visual clutter that makes use of the watchlist harder. Some changes to a watched article (such as bots adding interwikis and hyphenating ISBNs) do not require a visit to the page and therefore the bolding remains. It also remains when people use pop-ups instead of loading the page. Therefore reduces functionality. Also the green "changed since last visit" in page histories does not go away unless one actually visits the page; viewing the history page should suffice to have it removed, since viewing teh history page itself constitutes a visit to the page for checking purposes. Yngvadottir (talk) 04:26, 11 May 2012 (UTC)
  • Opt-in or abort entirely. Nikkimaria (talk) 04:41, 11 May 2012 (UTC)
  • Opt In Whoever created this mess should be hauled up and forced to justify themselves. Some people don't understand programming language or code, so all these "fixes" are confusing and potentially dangerous. I don't want bolding, stars, green lines or anything else. I want things reverted back to normal. Without programming language, without code, without fiddling about under the bonnet. Change it all back, and do it immediately. 78.86.102.100 (talk) 04:42, 11 May 2012 (UTC)
  • Opt-out or opt-in. It should be plain to see there there needs to be an option, though I don't particularly care which is the default. I think there should also be display options for when it's on, like the subtle dotted underline suggested by Elonka, instead of the bold. Equazcion (talk) 04:58, 11 May 2012 (UTC)
  • Support Commons has bolded text in the watchlist and can't see why it is a big deal, far better then the green stars. It allows me to look at the articles that are in my watchlist and look at the changes without having to guess if I've viewed it. Bidgee (talk) 05:06, 11 May 2012 (UTC)
  • Support I have long wondered why en couldn't do something Commons has done for years. Yes, if the developers want to write and test some code making it optional, no problem but newbies ought to see it this way, so it should be opt-out for those of my fellow old farts who can't tolerate a change that won't be useful until they study it a little. Jim.henderson (talk) 05:33, 11 May 2012 (UTC)
    • The nature of Commons and of Wikipedia pages are fundamentally different. Commons' simplicity, and the relatively lower number of users, is much better suited to this type of monitoring than the often complex WP articles, maintained by a much larger army of editors. To leave the feature in place unchanged, or to insist that it be an opt-in because "English Wikipedia ought to be the same as Commons" would be a failure to recognise these fundamental differences and thus the way editors work. --Ohconfucius ¡digame! 08:59, 11 May 2012 (UTC)
  • Opt-in. Such dramatic changes should almost always be implemented on an opt-in basis whenever technically possible. That means that those who want the change can get it, and those who don't want it won't be offended by its suddenly being thrust upon them. In other words, everyone is happy. Instead, the default method seems usually to involve inflicting it on everyone across the board. Regarding this latest infliction (i.e., the bolding—I missed the stars and have no idea if I'd have liked them), it's typographically inept. By that, I mean that bold type of that size, set with that tight a leading, is ugly and hard to read; one's eyes tire quickly of it. (The preceding lines I am deliberately putting in boldface to illustrate what I just said—I hope not in violation of WP:POINT but certainly in violation of easy readability and good typographic practice.) Rivertorch (talk) 05:35, 11 May 2012 (UTC)
  • Opt-in. These mass changes where people are scrambling to find out how to turn them off is kind of annoying when it keeps happening. A bolded watchlist may be okay for very short watchlists but for longer ones there's just a mass of bold that's hard to read. Less is more. SlimVirgin (talk) 06:10, 11 May 2012 (UTC)
  • Opt-in. Some people like it so let them have it. Some people hate it so let them be without it. Bolding stuff is far too distracting for me. I hope my message is not too distracting for you to read. HumphreyW (talk) 06:18, 11 May 2012 (UTC)
  • Opt-in, per WP:Argumentum ad Jimbonem. Any changes to the software must be gradual and reversible (Statement of principles). EngineerFromVega 06:33, 11 May 2012 (UTC)
  • Leave as is (but with a user preference to disable it). Get used to it, people. Things change. It's not as if the watchlist mas been removed on the grounds of server load. We should welcome, not spurn, extra functionality. — This, that, and the other (talk) 07:30, 11 May 2012 (UTC)
  • Hate the change and want it reverted I've made my case in other forums already. This is one of the worst decisions I've experienced here. It's a mess, a colossal, hideous and unjustified mess. Please revert it. No opting in, no using coding or progamming, no fiddling about - just revert it doktorb wordsdeeds 07:43, 11 May 2012 (UTC)
  • Opt-in. All interface changes should be opt-in. At the very least, an off switch in User Preferences must be a prerequisite before future changes are implemented. - X201 (talk) 08:12, 11 May 2012 (UTC)
  • Opt-in. I understand that this change might be useful to some editors, who should have the option to use it. But, like many others above, I view my watchlist using pop-ups, and this feature does not recognise this. Consequently, it is useless, misleading and obtrusive for me. I can click on the Mark All as Read button; but I would rather that disappeared from my watchlist too, leaving more space for actually useful information. RolandR (talk) 08:20, 11 May 2012 (UTC)
  • Opt-in, or at the very least give us a way to opt-out without having to alter our .css files. — foxj 08:28, 11 May 2012 (UTC)
  • Abolish as first choice, Strictly opt-in as second choice. Use the "principle of least astonishment", here - don't change the way a functioning system works without an extremely good reason! --Christopher Thomas (talk) 08:56, 11 May 2012 (UTC)
  • Opt-in. No point in stopping people using it, if anyone really wants to. However, all such changes should be switchable in User Preferences, with the default as off. Many WP users are not Techies, and expecting them to add text to CSS pages is totally unacceptable. Even for those happy to add code, the problem is knowing the code exists, and being able to find it - many such options are hidden away on obscure pages, or in archives.Arjayay (talk) 10:20, 11 May 2012 (UTC)
  • Opt-in but No Bold is better. Can't believe anyone in their right mind would think that it is a good idea to use bold to support this (in itself) sensible functionality. What is this; 1995? Making it bold makes the page much busier and therefore much harder to read (as well as more hideous). Anyone with even a basic understanding of website usability (and that should include those working on Wikipedia) knows that this is an absolute no-no. --Wolbo (talk) 10:30, 11 May 2012 (UTC)
  • Opt-in - came home from work a few hours ago, checked my watchlist and it now looks like an email client in-box instead of what I was otherwise expecting. No green stars, tho. (Firefox 12.0, WinXP) --Shirt58 (talk) 10:44, 11 May 2012 (UTC)
  • Opt-in There's no reason to get rid of access to it entirely entirely for those who actually want it but this should never have been presented as a fait accompli. I find it actually painful to view my watchlist.--Fuhghettaboutit (talk) 11:13, 11 May 2012 (UTC)
  • Opt-out. I do like the feature for a simple reason: Previously, I needed to check every page twice: first to see the last bunch of edits, and second time to mark the last watched edit visible in my browser (and moving from office to home may be a problem). Now I only need to do it once. Opt-in is not sufficient, since most people would not bother. For me, changing the .js files is a serious technical challenge. At the very least, it should be available as a option in preferences. BTW I would also prefer to have edits appeared since my last visit marked green, in my case they only show up as plain text.--Ymblanter (talk) 11:54, 11 May 2012 (UTC)
  • Opt-out: I supported this feature before and still do, but opt-out doesn't hurt as every one doesn't seem to find it constructive to their own editing. --lTopGunl (talk) 12:17, 11 May 2012 (UTC)
  • Opt-out: I don't mind the concept, but I personally don't like it, so I would really like a way to turn it off through gadgets rather than random CSS hacks. Yoenit (talk) 12:52, 11 May 2012 (UTC)
  • Opt-in May be useful to some, awful for others. --RA (talk) 13:05, 11 May 2012 (UTC)
  • Opt-out. Any editor sophisticated enough to be using a watchlist can figure out how to opt out, so long as there's an option to do so. Mike Christie (talk - contribs - library) 13:35, 11 May 2012 (UTC)
  • Op-in Seems to me my watch-list shows changes by default anyway, the last x number of changes; why do i need bold or stars or anything else to see it; let it stay, if others like it, but has to be opt-in, not opt out. Just because this is default elsewhere doesn't necessarily make it a good thing. Now looking at my watch-list or a history page is painful to mine eyes. Cheers, LindsayHello 13:40, 11 May 2012 (UTC)
  • Opt-in (or opt-out). I don't find it useful, more of an eyesore than anything else. There should at least be an option to disable it. OohBunnies! Leave a message 14:46, 11 May 2012 (UTC)
  • Opt-in doesn't seem all too helpful to me, and my first instinct when seeing the bolding is to assume it's a page or change I already viewed. Hot Stop 15:03, 11 May 2012 (UTC)
  • Opt-out. This has been in place for years on other wikis like Commons, where I spent more of my time, and I've found it extremely useful over that period of time, nor have I ever seen anyone complain about it in any forum. I believe new users who are not so accustomed to the old watchlist styling will also find it useful. A feature that is off by default is a feature that is almost never discovered and therefore of minimal utility. However, I think an option to turn it off would be reasonable deference to those with a strong personal preference. I would also reluctantly accept a compromise in which it is opt-in for existing users, and opt-out for new users. Dcoetzee 15:06, 11 May 2012 (UTC)
  • Opt-out. I appreciate that some people will use it however there really needs to be either a gadget or an opt out. I find it very distracting and for me it makes the watchlist difficult to follow. The bolding should be turned off why this is happening. Edinburgh Wanderer 16:04, 11 May 2012 (UTC)
  • Absolutely hate this change and want it abolished. I'm not stupid, I have something called a "memory" which enables me to understand which links I've clicked and which I haven't. Parrot of Doom 16:06, 11 May 2012 (UTC)
  • Opt-in or "Absolutely hate this change and want it abolished": The choice says it all, but for the 'not a vote' crowd: the continuous bold gives me a headache. Bielle (talk) 16:50, 11 May 2012 (UTC)
  • Dump it or Make it Optional - Right now, my watchlist contains many times more its normal load, due to various factors like bots, or assessment projects, whatever. It's all in bold, and it's hurts my eyes. My watchlist lately is one big page of bold type. Maile66 (talk) 17:07, 11 May 2012 (UTC)
  • Revise/Opt-in The big issue for me, as nearly everyone seems to be observing, is that everything I decide isn't worth looking into stays bolded, so that the bold (besides its obstrusiveness, which is also something of an issue) doesn't give a good indication of what to look at. If it is to be retained, it needs to have a "clear" function so that the user can tell the bold to go away on items that he judges don't need to be looked into. Mangoe (talk) 17:14, 11 May 2012 (UTC)
And, sure, you can manually click on "Mark all pages as visited" to clear the bolding. A nanno second later, something else can pop up on the watch list. Especially when bots are running out there. Nobody wants to spend all day clicking the option to clear the bolding.Maile66 (talk) 17:25, 11 May 2012 (UTC)
I've looked at the watchlist, and at preferences, and I still haven't been able to find how to 'mark all as viewed'. Even if I were to use it, busy pages like ANI, BLPN, RSN, RM and this one continue to light up like Christmas trees. It really needs to have an on–off switch. --Ohconfucius ¡digame! 00:29, 12 May 2012 (UTC)
There's a big "mark all pages visited" button on top of the watchlist which is very hard to miss, unless some admin or other user script has removed it for you. --Nemo 06:06, 12 May 2012 (UTC)
  • 'Revise/Opt-in pretty much per Mangoe. It essentially keeps the items you're the least interested in looking at bolded. Torchiest talkedits 17:51, 11 May 2012 (UTC)
  • Opt-in per Tryptofish et al. Absurd, annoying and (to me) useless. Ben MacDui 18:14, 11 May 2012 (UTC)
  • Opt-in - stress-inducing and useless to me, and above all, Tell us what is going on if ever you change the appearance of everyone's watchlist: there was no explanation of this, just a sudden headache of bold text shouting at me. PamD 18:34, 11 May 2012 (UTC)
  • Opt-in or opt-out, either way is fine with me, but please make it a choice, not an absolute!! An opt-in or opt-out would be much easier for us techno-phobes who do not want to have to copy complicated .js stuff into our preferences!! --Funandtrvl (talk) 19:57, 11 May 2012 (UTC)
  • Opt-in (off by default) is my first choice. If that is not easily doable, just undo the change. Distant 3rd would be to go back to the star instead of bolding. --ThaddeusB (talk) 00:44, 12 May 2012 (UTC)
  • Opt-in. For experienced users, who typically have large watchlists and many high-traffic pages on them, there are too many cases where the natural reaction to a watchlist change is something other than visiting the page, making the whole idea of highlighting based on visited status not really useful. There should also less visually distracting ways of implementing the highlighting, if you wanted it. Fut.Perf. 06:42, 12 May 2012 (UTC)
  • Opt-in Damn nuisance. I know what I'm doing in my watchlist. This refers to the bolding - I can't remember seeing any stars anywhere, green or whatever. Don't want any, either. Peridon (talk) 14:18, 12 May 2012 (UTC)
  • Support as opt-out feature. The first couple of times bold showed up on my watchlist for brief intervals, I couldn't figure out what it meant and the changes were distracting (maybe the feature wasn't working properly). However, in its full implementation I found it very helpful. New users who get this by default are unlikely to complain because they will find it helpful, but opt-out should be available. (PS - There are plenty of other recent interface changes that I find annoying, but this one was helpful.) --Orlady (talk) 15:30, 12 May 2012 (UTC)
  • Opt in. Could be useful for some, but I find the forced implementation based on a limited discussion of something that affects every single registered user annoying. oknazevad (talk) 05:24, 13 May 2012 (UTC)
  • Opt out. This will by far be most useful to new users and leaving it as an opt in absolutely defeats that purpose. As has been noted the default in email readers is for bold to be unread messages and many new users will be expecting that. There is no reason to disable or leave it as an opt in other than to take "revenge"(?) on the awful devs and to make sure that "your" way is the "right" one. Tradition is a terrible excuse to keep things stationary. Chico Venancio (talk) 06:42, 13 May 2012 (UTC)
  • Opt in This feature may be welcome by some, but I suspect more find it a nuisance than a benefit. Personally I have no use for this, since I check the diffs with navigation popups, not by clicking through to the articles. ThemFromSpace 17:44, 14 May 2012 (UTC)
  • Change per Mirokado. Instead of seeing lots of green stars (the best version so far), have the script find either the last refresh of the watchlist page, or the earliest green-star change, and on that change line only, add a second (divider) line consisting of a horizontal rule with central text like "last visit 00:00, 00 Mmm 0000 (UTC)". Picking out a single HR rather than navigating the starfield is much clearer. Note: this applies in spades to the change listing "updated since my last visit" in green prior to every "(undo)" link, which is absolutely horrid. Looking for the earliest green line when it's not at the beginning or end of the line and looks almost black on a laptop is much much worse than an unobtrusive horizontal rule. (And when I look at the page via choosing a diff link in history rather than visiting the page directly, this "service" guesses wrong anyway, but that wouldn't be such a frustration with an easy-to-find HR). Sidenote: the vast sentiment for "opt-in" does not mean "opt-in" is the winner, it means the winner is "the UI guys tried too many changes too fast and scared us". If more discussion of technical capability occurs and more users are drawn in, a second straw poll would probably give a different result. The solution is that future major UI changes should get a dismissible announcement note where users can comment "hate it" during the trial period until people stop hating it. I hated italicized titles for a long time until I realized my concerns were illusory. JJB 20:15, 15 May 2012 (UTC)
  • Opt out Apparently some people think it has functionality, but many others including me find it both useless and annoying. I was finally able to figure out the instructions for deleting the stars and the green tag manually (I re-posted the method below in the "Now getting green 'updated since last visit' message in page history" section), but it shouldn't be that hard. Please provide a click-here button for those who want to turn off both new features: the bolding and the "updated since my last visit" tag. (At first I thought that was something which was being added by the editor making the edit, and I almost contacted them to ask "why are you using that as your edit summary?") --MelanieN (talk) 22:10, 15 May 2012 (UTC)
  • Opt-in. If other folk want it, then fine; but I don't, and cannot fathom why it should be imposed by default. Those who are least adept at dealing with UI tweaks and preferences are most likely to be uncomfortable with the change (this is why I'd say opt-in rather than opt-out). Personally, I'd treat an incredibly busy live environment as live, and restrict my tinkering to a test environment, but what do I know? bobrayner (talk) 09:14, 16 May 2012 (UTC)
  • Support this is a very useful feature for editors like myself who don't always visit Wikipedia every day. I don't understand what is so intrusive about titles conditionally being displayed in boldface. There is precedent for bold titles as an indicator in Special:RecentChanges. I request that bold be used as an indicator both in watchlists and in article version histories. --Kvng (talk) 19:39, 16 May 2012 (UTC)
  • Support Opt-in. mabdul 12:49, 17 May 2012 (UTC)
  • Opt out or support (per Kvng) - this is great funkcionallity I know from other WM projects it relieves the user from lot of re-reading. Those who comment about having too much of pages in watchlist for this - I believe it just the other way, because I do have simply too much of pages in the watchlist I want to know instantly which of them I did visit already. I want this option back ASAP. please! Reo + 20:26, 17 May 2012 (UTC)

A note about "opt-in"

Let's be clear; this feature only adds a marker to indicate that a page has been changed. I cannot imagine how that could not be good functionality. As for the styling, that has yet to be decided, but there is absolutely no reason to have it disabled in any way, just becuase of a conservative mindset. If everything new is made opt-in, the preferences section is going to be too overwhelming to new users. That is something we absolutely do not want. The feature is there based on earlier consensus. It was also decided the styling was to be discussed at a later date. Right now, all the nay-sayers want it disabled or made opt-in purely based on what it looks like, while not a single comment has been made on the functionality, so those comments are likely to be discarded pre-emtively.

So, let's be really constructive and decide how we want changes to be visualized, because there is one thing I can guarantee you: configuration options that have been enabled by default on this (or other) project(s) can and will never be opt-in. Edokter (talk) — 08:04, 13 May 2012 (UTC)

Re "Right now, all the nay-sayers want it disabled or made opt-in purely based on what it looks like, while not a single comment has been made on the functionality, so those comments are likely to be discarded pre-emtively.": Aesthetics and functionality are inseparable in this case. When how something looks compromises its functionality, then there is a problem. I have the bold watchlist on Commons, and I don't take any issue with it; I only have a few things watchlisted, so the bold is pretty unobtrusive. Here, however, I have dozens and dozens of pages watchlisted. Logging in after a day and seeing a wall of blue and purple bold is just not helpful at all. The design impairs the usefulness. ~~ Lothar von Richthofen (talk) 21:06, 14 May 2012 (UTC)
Well, it would appear this one is opt-in as of now. As for which change specifically we're discussing, that's semantic. People clearly don't want the visual style that's been implemented here forced on them. That should be opt-in (and is right now) since the discussion on styling didn't take place beforehand, as it probably should have, especially if the need for that discussion was foreseen prior to implementation.
Seeing as the people have spoken, it would appear that the default visualization should be no visualization. I don't think those voting for opt-in care if some extra code they can't see is implemented, so that should stay. Visualization should be implemented as a preference/gadget, or set of them for different style options. Equazcion (talk) 08:14, 13 May 2012 (UTC)
The fact that its opt-in is because some admins apparently feel intimidated by the current backlash. Had it been left in place, I'm sure most commenters would be accustomed by the change real quick (as some already have). The fact fact that the option was turned on took us all by suprise, so there was no time to discuss beforehand (it even looked like it wasn't going to be implemented at all). Now that it has been enabled, it is here to stay. Elen of the Roads has put up a survey page to poll the various options, and I'm interested to see where this is going. But again... opt-in is not an option, because configured MediaWiki behaviour should never be hidden by default. Edokter (talk) — 19:33, 13 May 2012 (UTC)
We appear to have made it an option. Intimidating admins with backlash? Opt-in is not an option? Are you hearing yourself? First of all, if intimidating admins with backlash is what it takes to make the interface reflect community consensus, then so be it. That doesn't bother anyone (except the admins? and again who cares). Secondly, you're no one to say that anything is not an option, especially in the face of all this feedback. Third, Elen of the Roads had a very clear rationale for instituting the override, which she's expounded on repeatedly, and there was no intimidation involved (I don't think Elen is capable of being intimidated and you should apologize to her for suggesting as much).
Anyone who's looking at your responses here and following the situation can tell that you're feeling spited by the massive lack of support for something you were involved in. It must suck and I'm sorry. But don't start dictating what can and can not happen, nor brushing off the response as typical this or that. You can supply your input like everyone else, and implement the community's decision in the end; aside from that, please sit down. You're not in charge here. Equazcion (talk) 19:43, 13 May 2012 (UTC)
No, we appear to be outraged over a configuration change, which triggered a change (by me) which was reverted, then disabled allthogther. People don't like the bolding? Fine. But when those same people demand it be disabled or made opt-in, they are purely expressing their personal opinions, without realizing the consequences for other people. As an admin, I realized I cannot allow that. I have to see beyond those opinions and their ramifications; making a core functionality hidden by default for all users, including new ones? I'm sorry... that's simply not an option.
Yes, I originally proposed the option be turned on, which was met with approval. But again, the community is not in charge of disabling/hiding functionality once enabled. I simply don't understand the outrage for something that can be really unobstusive. There is simply no point in making it opt-in. It only adds another layer of complexity that we can surely do without. Edokter (talk) — 20:16, 13 May 2012 (UTC)
The community is in charge of interface changes, and you being an admin does not allow you to override a demonstrated consensus in favor of your own views of what's best. Call it outrage or whatever else you like, but your characterization of why the change is being rejected is of no consequence. It was claimed that a demonstrated consensus brought this change in the first place, not you (as it should be); and now a much larger consensus is now being demonstrated against it. So now it's off by default (as it should be). What to do now is being discussed, but barring another consensus to switch it back on by default in some form or another, it doesn't happen. It is not your place to declare that it should be on by default because you know better than everyone else. Adminship doesn't grant you that privilege. Equazcion (talk) 00:21, 14 May 2012 (UTC)
The community is in charge of interface changes
Where's the policy that says that? I can't find one. More to the point, where's the agreement from the WMF that they agree with this statement? I can't find one, and I can find multiple counterexamples, e.g., the WP:Article feedback tool, which is definitely an "interface change" and which was definitely continued despite people yelling about how much they hate it. WhatamIdoing (talk) 02:29, 14 May 2012 (UTC)
WMF retains the right to override the community on nearly any issue, including interface changes (though they say in general they don't do that). I don't see any evidence that this decision comes from them. On the contrary, this was shown to have been enacted via a community discussion -- and an even broader community discussion now shows a different outcome. So it goes. Should the foundation decide to override it, we'll deal with that then. Edokter doesn't speak for them just because he's an admin, any more than I do. Equazcion (talk) 02:40, 14 May 2012 (UTC)
Is this one opt-in as of now? Where do I opt in? Jim.henderson (talk) 12:32, 14 May 2012 (UTC)
See Wikipedia:Customizing watchlists Equazcion (talk) 12:48, 14 May 2012 (UTC)

Is it really that important that traditional users not have to check off one box to have their traditional style in place? 4 days of some users screaming in the Village pump is enough to constitute "clear consensus"?

Has anyone tried to scream at Google for making this behavior the Gmail default? At Microsoft for doing it in Hotmail? This hadn't been the default here for fear of performance issues but over at ptwiki and at others projects it has been used for ages. In fact users complained a lot over the brief time it was disabled in order to get better performance metrics about the new watchlist emails. But hey, the world will end if you have to check a box off to get old behavior back. Chico Venancio (talk) 17:04, 14 May 2012 (UTC)

There's a huge difference between emails, which are singular specific entities, and marking bold if you have simply not VISITED a page. As someone pointed out above, bolding the title of the article gives weight to the wrong thing. If I check my watchlist, and then go visit an article after the last change to read something, it's pretty dumb to have it not bolded because of that, don't you think? ♫ Melodia Chaconne ♫ (talk) 18:08, 14 May 2012 (UTC)

I don't think so. Articles are indeed distinct entities, as are changes, and the question of whether I've already seen them is as important as in E-mail. And yes, if I check my mail, and visit somewhere else and return, the one I've read is marked as been read. Easy to remember when it's only one or two to which I might return. Yes, marking things as been read is more important here in en than in either E-mail or Commons, because en is busier than either (for me, anyway) and this is where my old and feeble brain needs all the help it can get. Anyway, I've now got it thanks to the helpful note of User:Equazcion and it will help me in sorting out all the irritating little changes made by Helpful Pixie. However, the smarter editors than me ought to be the ones who have to dare to customize to omit this information. Jim.henderson (talk) 22:03, 14 May 2012 (UTC)

Significant comments about the opt-in vote appear in my vote above. JJB 20:15, 15 May 2012 (UTC)

Now getting green "updated since last visit" message in page history

Presumably this is linked to the changes made on watchlists but now there are green messages appearing on page histories indicating that the page has been changed since my last visit. Any way to opt out of this one as well? NtheP (talk) 21:50, 10 May 2012 (UTC)

strong.mw-watched a { background: none; padding-left: 0; } cf User_talk:Edokter#Green_stars. Rd232 talk 21:52, 10 May 2012 (UTC)

History, not watchlist stars. --OnoremDil 21:53, 10 May 2012 (UTC)
(edit conflict)This is related to the above.--Jasper Deng (talk) 21:54, 10 May 2012 (UTC)
span.updatedmarker{display:none;} --Yair rand (talk) 21:54, 10 May 2012 (UTC)

I use Vector skin and I have the green message on the history page. I can't follow the above discussions. What am I supposed to do to get rid of it? Please be explicit, i.e., go to here, put this code here, etc. Thanks.--Bbb23 (talk) 23:02, 10 May 2012 (UTC)

And what's absolutely and truly STUPID about this is that it showed new edits to this page in green when I pushed history after clicking the diff four minutes earlier (and then checked the rest of my watchlist). So a whole bunch of edits that are new are not shown in green while only a couple are. ♫ Melodia Chaconne ♫ (talk) 01:22, 11 May 2012 (UTC)
And even MORE dumb is that hitting the back button shows only the updates since I posted, not the intervening edits between me clicking on the batch of diffs from the history and reading and then making the above posts, which I of course never actually saw. So how is this supposed to be helpful again? ♫ Melodia Chaconne ♫ (talk) 01:53, 11 May 2012 (UTC)
  • Lose the commons-like bold stuff and green highlighting - and see if you can get rid of it at commons also. It's very annoying. ←Baseball Bugs What's up, Doc? carrots→ 05:22, 11 May 2012 (UTC)
  • It certainly is jarring. Seems to me it could be toned down considerably. After all, if we can have diff colors so subtle you practically need to wear special glasses to see them, there's no reason we couldn't have a gentle, low-saturation green here. And perhaps smaller type. Rivertorch (talk) 05:44, 11 May 2012 (UTC)
The green notification might be useful if it was done properly. Currently it displays itself for every revision that I supposedly haven't seen. And on some pages that can mean many copies of the same green box. It is completely taking over the page and makes it look awful IMO.
Perhaps better if the box was be be placed only once at the eldest revision that I haven't seen. And the text can then be changed to something like "Changes above this notification bar are new. Changes below this notification you have already seen". HumphreyW (talk) 07:30, 11 May 2012 (UTC)
  • Actually this is great, mine wasn't green so I changed to a green highlight by editing common.css. :D --lTopGunl (talk) 14:36, 11 May 2012 (UTC)
  • I have the same opinion as HumphreyW: it's useful to have a line drawn across the revisions, not so useful to label every revision more recent than the last visit, given that there's already a lot of clutter on each line.
  • I have the same question: I don't find the green "updated since my last visit" note helpful, and I do find it annoying. Is there some way to opt out of it? I see that this subject has been here for the better part of a week, with questions but no replies; are the tech gods even listening? Update: For some reason someone just reverted my comment, without explanation. If there are instructions somewhere in this thread for opting out (maybe the line of code posted by Yair Rand?), they are not evident or helpful without more detail about what to do with that code or where to put it. --MelanieN (talk) 15:22, 15 May 2012 (UTC)
P.S. Looks like Bbb23 has the same problem. --MelanieN (talk) 15:24, 15 May 2012 (UTC)

OK, I found some instructions many paragraphs above this one and I think they worked. Here they are, for those who like me came directly to this section, copied from above with the code pasted in:

Click "my preferences", and then click the "appearance" tab. There should be a line which reads "Shared CSS/JavaScript for all skins: Custom CSS | Custom JavaScript". The "Custom CSS" part should be a red link; click it to be brought to an edit screen for your personal CSS settings. It'll be blank as I'm assuming you've never created one. Paste in the code span.updatedmarker{display:none;} and save it; that'll create the page and apply that code regardless of which skin you're using. Check your watchlist afterwards to be sure it's worked.

--MelanieN (talk) 15:56, 15 May 2012 (UTC)

Far too complicated. HiLo48 (talk) 17:22, 15 May 2012 (UTC)
I agree a straightforward opt-out feature would be better, but this is better than nothing. --MelanieN (talk) 17:24, 15 May 2012 (UTC)
Only very very slightly. HiLo48 (talk) 10:50, 16 May 2012 (UTC)
Significant comments about why this is absolutely horrid and a horizontal rule would be much better appear in my straw-poll vote above. JJB 20:19, 15 May 2012 (UTC)
The version of any evolution automatically spewing gratuitous clutter will eventually be manually corrected by a programmer. Until the defeat the graffitist's "updates since my last visit", there are not enough volatile words to coerce the furtherance of the version that would ever make it so: repulsive, inhumane, unaffiliated defilement. — CpiralCpiral 21:40, 21 June 2012 (UTC)

"Changes related to" pages all gone wrong

It should be that Changes to pages on your watchlist are shown in bold, but they are not. Items not on my watchlist don't get a green star; items on my watchlist do get a green star - but I just marked all pages as visited, so I guess they shouldn't have. Not good. Mr Stephen (talk) 21:57, 10 May 2012 (UTC)

In that case, the message can be changed. Edokter (talk) — 22:04, 10 May 2012 (UTC)

Use dotted underline instead of stars

strong.mw-watched { font-weight: normal; border-bottom:1px dotted #000; }

The stars don't work for me. Instead looking a word, I'm looking at a column of green stars. Random link would be so much better since it would focus the users' attention on the word instead of an area to the left of the word. --Michaeldsuarez (talk) 22:07, 10 May 2012 (UTC)

Use italic text instead of stars

strong.mw-watched { font-weight: normal; font-style:italic; }

The stars don't work for me. Instead looking a word, I'm looking at a column of green stars. Random link would be so much better since it would focus the users' attention on the word instead of an area to the left of the word. --Michaeldsuarez (talk) 22:07, 10 May 2012 (UTC)

Italics are harder to read than either plain (Roman) text or bold-faced text. I don't think we want to increase the visual challenge involved in reading the most important words on the page, especially given the number of users we have who have significant visual impairments. WhatamIdoing (talk) 23:50, 10 May 2012 (UTC)

Use a check mark instead of stars

A tick-mark (✓, ✔, ☑, etc.) for verified pages would make more sense to me. Not only is it less obtrusive, but the mark itself is mnemonic and clearer in meaning. The drawback is the need to insert a character in the text. Regards, RJH (talk) 18:25, 14 May 2012 (UTC)

Change temporarily reverted in search for better consensus

See also Wikipedia:Village_pump_(proposals)/Archive_83#Enable_.22Show_changes_since_last_visit.22_on_watchlist

I have reverted this change because it was clearly not discussed widely enough. The number of people commenting after the change to Common.css is more than double the number that originally commented on the proposal. The stars are particularly too bold a change for a function that is used by basically every active editor. Steven Walling • talk 22:17, 10 May 2012 (UTC)

Oh. So is it currently at bolding? Because the stars really were better than the bold. OohBunnies! Leave a message 22:19, 10 May 2012 (UTC)
I have fully reverted, though it was the green stars that I first noticed. In any case, I fully support people proposing radical change to the watchlist. But only in the spirit of Bold, revert, discuss. Update: I am an idiot and didn't see that the bolding is not in Common.css at all. Steven Walling • talk 22:26, 10 May 2012 (UTC)
  • Whomever started this process needs a kick in their britches. There are many ways to solicit attention to proposals of forced change in visual design. One way to implement them is to not fuck with the live copy. The annoying bold text is still present, and is still degrading my user experience. Fifelfoo (talk) 22:19, 10 May 2012 (UTC) 22:34, 10 May 2012 (UTC)
  • The bolding is back and it's really hard on the eyes - also it induces an instant migraine. Each time I've logged off and logged back in today the watchlist has been different. It's extremely annoying. Truthkeeper (talk) 22:31, 10 May 2012 (UTC)
  • Agree with Fifelfoo, all these changes need to be reverted and the proposal(s) needs to go back to the start. I hope the "powers that be" have learnt out of this "epic fail" that we do want projectwide wall-to-wall notification of proposals that have such a drastic effect on all editors' experience of working on the project. Roger (talk) 22:30, 10 May 2012 (UTC)
    The "powers that be" had nothing to do with these changes. --Yair rand (talk) 22:37, 10 May 2012 (UTC)
    Whoever managed this process and implimented these changes are "the powers that be" for the purposes of this discussion, or have the WMF servers achieved self awareness and now write their own code? Roger (talk) 22:51, 10 May 2012 (UTC)
    As you can see from the discussion on the bug request the developers were just fulfilling a community request backed by a consensus. People would be pretty mad if they just refused the change too, so I don't think anyone can lay some blame on their laps here. Steven Walling • talk 23:10, 10 May 2012 (UTC)
The problem was, those who had taken part in the original discussion had said "yes, let's have something, preferably an opt in gadget." There wasn't actually a discussion about how it was going to work, or when it would be done, so when Erwin starts trying to see how it might work, people were surprised, didn't like the first couple of tests, and had in many cases been expecting something else entirely. It was ever thus, but having a space to test out how it might work before changing the interface for everyone might have been really useful, and saved a lot of flak. Elen of the Roads (talk) 23:26, 10 May 2012 (UTC)
  • Put an option in userprefs and then leave it alone. My watchlist style changed at least 4 times today between 3 different styles, which is more annoying than either bold or stars. Kilopi (talk) 23:00, 10 May 2012 (UTC)
  • There's a misunderstanding I think, the change has not been reverted completely yet, only the stars (!) have been removed. There's a consensus for the status quo, default feature (normal bolding and green text), drastic changes like these (no bolding and different style in histories, besides weird stars) need a vast consensus after a discussion of at least some days at usual, not such hasty decisions and rapid changes, as pointed out also by Kilopi above. Nemo 23:12, 10 May 2012 (UTC)
      • Where is there consensus on this page for "normal bolding"? The status quo is no bold. ~~ Lothar von Richthofen (talk) 00:08, 11 May 2012 (UTC)
    • Since it appears the CSS hack to remove the bolding on watchlists is breaking bolding elsewhere, I think it may be wise for me to set Commmon.css back to what it was before either Erwin or I edited it. If people want to fight out the configuration change referenced in the bug, then let them have at it. Steven Walling • talk 23:40, 10 May 2012 (UTC)
    A "consensus" of only 20 support !votes to impose a radical user interface change (that has no easy "off switch") on all ninety-odd thousand active editors[2] is not a true consensus. Such proposals should require thousands of support !votes before anyone sane could call it a true consensus. Twenty users is a cabal, not a consensus. (IMHO the threshold should be in the region of ten thousand !votes.) Roger (talk) 23:42, 10 May 2012 (UTC)
    I agree it should probably be discussed more. I cannot do anything about it personally though. Steven Walling • talk 23:44, 10 May 2012 (UTC)
    Surprises seem to bring out the worst in active Wikipedians, but I think, based on the experience of many other websites with visible, function-enhancing changes, that the thing to do would be to leave it in place for a month or two, and only then ask people what they thought. Think about the "Tell Facebook to revert its changes" pages that spring up every time that website changes anything. Tens of thousand of users sign up on these protests, and a month later, most of them can't even remember what the old version looked like. WhatamIdoing (talk) 23:56, 10 May 2012 (UTC)
    No, I'm sorry, that's just plain dumb. Sites like Facebook and Youtube do that because they exploit the fact that they have a "captive audience". Wikipedia is very much a user-oriented site, and not giving an option violates that fundamental spirit of the project. ~~ Lothar von Richthofen (talk) 00:06, 11 May 2012 (UTC)
    Facebook also has a beta testing program where they make sure changes are reasonably acceptable to their audience before implementing them, rather than testing new stuff live. Equazcion (talk) 00:12, 11 May 2012 (UTC)
    But here you actually have the option of sticking with old settings. I am using MonoBook with green/yellow diff styling. Meanwhile, I am dreading the day when Mark Zuckerberg is going to finally shove that Timeline monstrosity down my throat for good. ~~ Lothar von Richthofen (talk) 00:18, 11 May 2012 (UTC)
    Why so much bold? :( — foxj 07:18, 11 May 2012 (UTC)
    What, you don't like the bold? It doesn't make things easier to notice? What if I throw in some green, does that make it better? ~~ Lothar von Richthofen (talk) 13:52, 11 May 2012 (UTC)
  • Can we please get rid of the fucking bold again, already. I don't wake up and shit all over your user-interface and then play hissy-fit games about consensus. Fifelfoo (talk) 00:34, 11 May 2012 (UTC)
  • I agree that we should revert all these changes until a consensus can be reached for their implementation. We need a wiki-wide surveying for single articles like Muhammad and Pro-life/pro-choice yet technical changes that actually affect us are sandboxed around Facebook-style? I don't appreciate it, and most others here would agree. — FoxCE (talkcontribs) 01:09, 11 May 2012 (UTC)
  • GET RID OF THE BOLD!. Constantly having every-fucking-THING on your watchist in bold if you just started the day's editing is EXTREMELY distracting and does NOT make a good work environment. Hopefully this bolded paragraph will be able to aptly demonstrate what I mean! Barts1a / Talk to me / Help me improve 01:16, 11 May 2012 (UTC)
  • Revert immediately. Clearly a case of inadequate discussion and hasty implementation. I don't want to look at that eyesore of my watchlist for a second longer. As the net number of complainants now far exceeds the number who participated in the original decision, can someone please revert now and discuss now that we have the undivided attention of "the community"? --Ohconfucius ¡digame! 02:11, 11 May 2012 (UTC)
  • GET RID OF THE BOLD! Please!. It makes the page really hard to read and gives me a headache. All that bolding takes its power away as a highlighter while, at the same time, confusing the reader. Bold has to have a reason; there is no logical reason for this use. The titles were perfectly clear. Bielle (talk) 02:10, 11 May 2012 (UTC)
  • Bin the Bold I echo the sentiments of the honourable and right honourable members of the project above. doktorb wordsdeeds 05:21, 11 May 2012 (UTC)
  • Don't reset &days= – I don't mind this feature, except that pressing the button "Mark all pages visited" a) does more than that – it also brings up pages which have changed since the list was previously generated and already unbold them, which is confusing; b) forgets what value I had used for the &day= parameter. In short, pressing the button will issue the default Special:Watchlist action, which makes long watchlists much harder on the browser. As it is, the button has more downsides than upsides; I guess I have to learn not to use it. -- Michael Bednarek (talk) 09:39, 11 May 2012 (UTC)
    You're right, I've filed your feature request under bugzilla:36761. Nemo 14:04, 11 May 2012 (UTC)
  • The users who are now contesting the consensus for implementing this change clearly didn't participate in the consensus where it was almost unanimously determined to implement this change (and yes, those who didn't participate gave it a silent consensus too). It is right that a notice should have been added or something to inform atleast of what was going on (I was already using a script for the bolding so I got confused too), but I don't think that this was blatantly applied without a consensus. The changes are good, instead of removing them, an opt-in or opt-out feature should be added so that it doesn't hurt those who don't want it. --lTopGunl (talk) 14:44, 11 May 2012 (UTC)
    • Silence does not imply agreement or disagreement. As pointed out by others above, this is an issue that affects thousands upon thousands of users, and for such discussion to have real mandate, the participation rate needed to be a lot higher than the approximately dozen votes that caused this feature to be implemented. --Ohconfucius ¡digame! 00:33, 12 May 2012 (UTC)
      That page doesn't say what you attribute to it: «This page in a nutshell: Consensus is assumed when there's no evidence of disagreement». You need another essay to prove that lack of consensus is proved when there's evidence of disagreement. Thanks, Nemo 07:28, 12 May 2012 (UTC)

This actually fixed a bug

See also Wikipedia:Village pump (technical)/Archive_98#Occasional "mark all changes as read"

Not only the feature "Show changes since last visit" was enabled by community request, as said above (it's also the MediaWiki default, by the way), but as far as I can see it was also needed to fix some bugs reported a few sections above, see link. Without this default feature, MediaWiki behaves inconsistently; with it, nothing is broken. --Nemo 23:24, 10 May 2012 (UTC)

I think I can sum up the opinion above by responding with: boo! Killiondude (talk) 00:03, 11 May 2012 (UTC)
As far as I'm concerned—and I think many others will agree with me—that thread does not in any way constitute a "community consensus", so stop pretending like it is. An RfC is the most transparent way of going about determining consensus here, and that is what is being done above. ~~ Lothar von Richthofen (talk) 00:15, 11 May 2012 (UTC)
"Enabled by community request". bullshit Fifelfoo (talk) 00:40, 11 May 2012
  • This is not a "fix." This is simply making the bug 24/7.--Jasper Deng (talk) 01:12, 11 May 2012 (UTC)
    Wasn't the reported bug about an inconsistent behaviour and confusing info? I don't see any of that. Nemo 14:07, 11 May 2012 (UTC)
Agree with Fifelfoo completely. It's really absolutely terrible and needs to become an opt-in option in preferences. Also, can someone please stop Helpful Pixie bot while this his happening to cut down on the watchlist burden. Truthkeeper (talk) 01:23, 11 May 2012 (UTC)
  • We had basically the same reaction from Nemo on "[Bug 34961] Performer's username is shown twice in page move entries on the history": it's not a bug, it's a feature! A poor feature, wanted in principle but very badly implemented. Additionally, the button "Mark all pages visited" sadly does more than that alone; I usually have clicked on "hide my edits" and on "show all bots" to reverse the defaults, but using the "mark" button undoes that preference and sets everything back to its default setting. This is unwanted behaviour. Fram (talk) 11:51, 11 May 2012 (UTC)
    If you consistently change the defaults, it's advised to do so in the preferences. As said above, I've filed this feature request under bugzilla:36761. Nemo 14:07, 11 May 2012 (UTC)
  • The manner in which this was implemented made many people irate; and now, no matter how many bugs were fixed, or how effective they were, the implementation debacle totally overshadows the bug fixes. --Ohconfucius ¡digame! 00:38, 12 May 2012 (UTC)
    No. The number of users who like and need the feature totally overshadows the number of complaining users. Moreover, the implementation debacle of hasty and confusing changes to the watchlist style by some admins totally overshadows the (supposed) benefits in terms of (unproven) consensus compliance. Nemo 06:54, 12 May 2012 (UTC)

Community and consensus-focused development

If you want to spend some time raising awareness about problems with watchlist, why don't you spend a minute e.g. voting on one of these actual bugs? It's very annoying that attention is drawn on unimportant things the large community doesn't care about/agree on while the problems reported by the community sit unnoticed, isn't it? For instance, bug 9790 – Watchlist doesn't show earlier normal edits when hiding bot edits, own edits or minor edits. (Perhaps now no developer will fix such bugs, being afraid to be shot at by users who consider buggy software to be better than functioning software as long as it respects habits and tradition?) Nemo 07:00, 12 May 2012 (UTC)

But just remember that the number of votes for a bug is not that important... Helder 01:41, 13 May 2012 (UTC)

HOWTO: Subtle marker / no marker

If you'd prefer a subtle marker to the bold text, insert the following into your common.css.

.mw-watched {
   border-bottom: 1px dotted #999;
   font-weight: normal !important;
}

This will cause the markers to appear as dotted gray underlines instead of bold text, like so:

 

If you'd prefer no marker, use:

.mw-watched {
   font-weight: normal !important;
}

In both cases note that this will also affect display of watched pages on Special:RecentChanges.

HTH,--Eloquence* 02:07, 11 May 2012 (UTC)

VERY much like. Thank you. This should be a gadget, at least. Equazcion (talk) 02:08, 11 May 2012 (UTC)
Brilliant idea, I'm in favor (though perhaps as an opt-in to avoid more community rage). — FoxCE (talkcontribs) 02:14, 11 May 2012 (UTC)
see that tiny "mb" to the left of the diff in your image example? That's another pre-existing example of a low-intrusiveness inclusion of one bit of information. Fifelfoo (talk) 02:16, 11 May 2012 (UTC)
A bit of info which you wouldn't be able to customise. ;-) But if you want yet another letter instead of the bold everyone is accustomed to, you can file the request on bugzilla:. Nemo 14:09, 11 May 2012 (UTC)
  • Thanks, this is an excellent alternative. I can now use it along with User:Ais523/watchlistnotifier.js without confusion. --lTopGunl (talk) 15:04, 11 May 2012 (UTC)
  • Thanks for the workarounds. CaptainScreebo Parley! 19:29, 11 May 2012 (UTC)
  • That works nice. I don't mind a subtle marker, but the bold was a bit much for me. Offering some options on a gadget that updated your css (you want jazzy, subtle, little green stars, blue fish...?) would be a really nice feature. Elen of the Roads (talk) 22:56, 11 May 2012 (UTC)

{{sudo}} Can the underlined version be made the default please? MediaWiki:Common.css just needs a quick edit. --MZMcBride (talk) 00:33, 12 May 2012 (UTC)

It seems a very bad idea: as pointed out elsewhere, bold is the standard, other options are very user-unfriendly and would increase confusion. A more of focused discussion on if and how to change the style should happen with less haste when this discussion (and the users' habits) settles down. Nemo 06:04, 12 May 2012 (UTC)
"Standard" really doesn't mean anything. It's the MediaWiki default and can remain that way, but nothing precludes a local community from overriding the default behavior.
I agree that a more focused discussion should take place. That doesn't mean that leaving the bolding on in the meantime is a good idea. For smaller watchlists, it's not so bad. But for active users with a lot of watchlist entries, the bold is simply overwhelming. --MZMcBride (talk) 15:27, 12 May 2012 (UTC)
I've never found it overwhelming even with tens of thousands of items in the watchlist, and I don't see how the number of items in the watchlist matters, it's more about the percentage of visible text which is bolded.
Why isn't holding the default in the meantime a good idea? As written elsewhere, users were already getting used to it, while now only very few users will ever notice this feature and propose something else if needed. Nemo 18:39, 12 May 2012 (UTC)
When you have a larger watchlist, the percentage of bolded items is higher. Usually on a directly proportional basis. That's the overwhelming part. It's very similar to an e-mail inbox that you simply can't ever get ahead of. Not on a project as active as this one, at least. Meta-Wiki is manageable.
The underlining is vastly less awful. It gives a cue without punching the user in the face. I think it would make sense to use the bold for users with smaller watchlists and something less awful for users with larger watchlists. This could be accomplished through a user preference, implicit controls (less than 1,000 items, bold, etc.), or some other means.
That said, this is actively causing a problem for established users, so it should be a fairly high priority to make the site less awful for them. When you have the chief tech guy at Wikimedia posting hacks to make the site less awful, you really question the default, at least as a default for everyone using the site. But obviously Erik's focus is the entire site while my focus is largely people like myself (users with large watchlists). --MZMcBride (talk) 18:50, 12 May 2012 (UTC)
The size of watchlist should be proportional to your interest/ability to follow it; if it isn't, and "unread" items just increase and increase, there's something wrong in yor selection, very similarly to how an inbox as described by you would be plainly broken, and not by its style.
I don't know what Erik's intervention means, I agree that established users should be heled and I think the update markers are very useful for those with a big watchlist (unless they have the memory of Pico della Mirandola). Speaking of the style, I agree of course that it could be changed, although it's difficult to imagine something better than bolding; see for instance the recent comment on #A note about "opt-in". Nemo 18:36, 13 May 2012 (UTC)
  • Thanks for that script. It's brought the watchlist back to how it was early yesterday. This should be added to gadgets to allow a choice between a bolded or unbolded watchlist. Truthkeeper (talk) 01:46, 12 May 2012 (UTC)

Move this discussion?

User:Rd232 has made several attempts to move this discussion to Wikipedia talk:Customizing watchlists. I've reverted them pending discussion. I feel the new location is obscure and this move unwarranted. Would like to get other opinions. Equazcion (talk) 09:10, 11 May 2012 (UTC)

  • Looks like a graveyard over there. I knew to come straight to VP, and I think many others did too. It seems natural enough to host the issue here, unless there's a better alternative. Suitable notifications should be posted at other potential landing points for queries and comments, such as Help talk:Watching pages. --Ohconfucius ¡digame! 09:14, 11 May 2012 (UTC)
    • "graveyard" - what? I centralised the discussion there from VPR and VPT, leaving the original thread titles and a note about the move, and put the RFC on WP:CENT. This discussion is nearly 100k (about half of VPT), and now that there's an RFC, it's probably going to continue for days and weeks. How the hell is that appropriate for VPT? Rd232 talk 11:41, 11 May 2012 (UTC)
      • The problem is that CENT and RFCs don't work as ideally as they should. People who notice interface changes generally come to VPT to see what the deal is. I don't see how it being long means it needs to be moved. Maybe the RFC section alone could be moved to an WP:RFC subpage, or maybe VPR, only because they might be more appropriate venues? I don't agree with shuffling the entirety of discussion off to an obscure newly-created page though. The general discussions seem fine where they are either way. Equazcion (talk) 11:49, 11 May 2012 (UTC)
        • It's irrelevant whether the discussion is moved to a VPT subpage, the talk page of a new help page documenting the issue under discussion, a user subpage, or the arse end of Mars - as long as links to the new destination are placed in appropriate places. The only difference with leaving the content on VPT, rather than a link, is that all other VPT discussions are crowded out. Rd232 talk 12:01, 11 May 2012 (UTC)
          • Crowded out? I don't see how. Links at CENT etc. are great but aren't as noticeable; I think it's far more helpful to hold a discussion in the place where it's most likely to be looked for. Equazcion (talk) 12:05, 11 May 2012 (UTC)
            • "Crowded out" is too obvious to explain. Now how is it better to have the discussion at VPT instead of at a VPT subpage pointed to from VPT? That's the question you need to answer, made very specific. Rd232 talk 12:12, 11 May 2012 (UTC)
              • How is it better? I answered that above. Equazcion (talk) 12:34, 11 May 2012 (UTC)

and the answer was? Rd232 talk 13:34, 11 May 2012 (UTC)

Well, aside from the fact that there's no reason to move the discussion to begin with (this is the correct venue for it and its length doesn't hamper other discussions -- I've seen much worse and people seemed to get along fine), VPT is where people go when they see interface changes, especially unwelcome ones. Moving things off this page just makes the discussion more difficult to find. A header and line kept around doesn't suffice, and while it's true we can link from CENT and we have the RFC listing, those aren't terribly prominent; many if not the majority of people don't know to check those. It makes sense to keep it displayed prominently here; also for the reason that developers etc. need to be reminded of what people's current concerns are, and it's harder for them to ignore a big discussion at VPT than a subpage or some new WP: space page made just for it that no one is watching yet. Prominence here should match the amount of attention an issue has garnered, and this one's got a lot of attention. Equazcion (talk) 14:02, 11 May 2012 (UTC)
  • Where is the RfC? Do you mean the vote happening at #RFC or is there another page somewhere? Nemo 14:16, 11 May 2012 (UTC)
    • Yeah he means the vote above. An RFC tag was placed at the top of that section, so that makes it listed automatically at WP:RFC. Those listings don't get as much attention as one might hope though. The discussion's presence on this page is actually much more of a draw than the RFC listing (as you've actually demonstrated :) ). Equazcion (talk) 14:19, 11 May 2012 (UTC)
It's ironic that the cause of this whole discussion is exactly the fact that things are "hidden" in obscure walled gardens inhabited only by uber-geeks. If an anouncement about the original proposal of six months ago was properly distributed to all user in the first place this "long" topic would not exist. Now you want to sweep this under the rug too! If WP was a commercial organisation the people responsible for this epic fail would have been unemployed today. As for the "crowding out" argument - utter bollocks! This page is not made of paper - it can stretch to accomodate practically any amount of text. Roger (talk) 14:18, 11 May 2012 (UTC)
Now now, let's not be mean to Edokter. The problem is that while there was approval of the theory - "let's have something that allows you to highlight changes you haven't looked at in your watchlist" - nobody really sat down and hammered out the details "how bold? Different colour? Is subtler better? Do we need a css tweakeria? Can we make it a gadget? No? What can we do instead? Would little icons work? Which icons? What colour?" and all the dozens of possible combos. And no-one did the stakeholder communication plan. I know this stuff seems like fantastical bureaucracy when you just want to get in there and tweak code (and the code tweakers are seldom the right folks to do the project plan - everyone has their own set of skills and should be respected for that), but this is what happens if you don't have something. Elen of the Roads (talk) 15:22, 11 May 2012 (UTC)
I can't help but feel that some of this is being done the wrong way round. Is there a problem with the basic skin (of whatever hue)? Not that I can see but there is obviously a demand by a number of users for enhancements to, in this case, the way the watchlist is presented. That is fine and a valid demand but the way forward isn't to make a universal change which is bound to be unsatisfactory to all. With the ability to create user specific custom.css, shouldn't there be an advertising of services available which allow users make changes that suit their needs? On this page since yesterday there have been several options for displaying the watchlist, a shopping list like that, that people can choose from to place on top of the vanilla stylesheet is surely better than enforced changes that few are happy with? NtheP (talk) 16:00, 11 May 2012 (UTC)
Yes. I think there are lessons to be learnt here. Highly-visible changes to functionality need greater sign-off by the community. I don't think needs to be a big-burden process. For example, if a change gets consensus then, before rolling it out, there could be a process to (a) advertise the change on watch lists, (b) link to a page describing the change (with reasoning, descriptions, screen shots, how to opt-out/opt-in/disable the change and, if possible, a staging area), (c) if there is no big fuss after two weeks then deploy the change.
I'm not saying what I described should be the process but some process of this kind may prevent the sudden "WTF!" reaction that this change brought. --RA (talk) 15:51, 11 May 2012 (UTC)
Design by consensus doesn't work. You need someone with vision who understands how the site works at every level and is willing to implement small changes in a way that doesn't upset people. The problem here is that the person or people doing this are going about it in the wrong way. Viriditas (talk) 23:25, 11 May 2012 (UTC)
Not talking about design by consensus. I talking about sign-off and process (i.e. going about it in the right way). --RA (talk) 01:23, 13 May 2012 (UTC)

How does this work, anyways?

I just cleared my cookies. It still knows what pages I visited (and didn't). Where is this (apparent) tracking-information stored and for how long? Choyoołʼįįhí:Seb az86556 > haneʼ 21:17, 11 May 2012 (UTC)

I think it's stored in the server somewhere. Privacy questions related this have been brought up on meta in this discussion. Killiondude (talk) 21:23, 11 May 2012 (UTC)
It is stored in the server. The watchlist table in the database has a field on each watchlist entry for when an email was last sent (or would have been sent, if you had that preference turned on) about changes to the watched page. Whenever an edit is made to a page, this field in all the watchlist entries pointing to the page is set if it doesn't already have a value. Then when you view the page (or view a diff against the current version of the page), it clears out that field for your watchlist entry. The watchlist-bolding feature uses this same field to determine which entries to mark. Anomie 22:02, 11 May 2012 (UTC)
I'm just wondering by what order of magnitude this change has increased server load? --Ohconfucius ¡digame! 00:44, 12 May 2012 (UTC)
I'm not a developer, but this has been enabled in careful steps to measure the server load (which was the only reason it wasn't enabled on some Wikimedia wikis, unlike all the other wikis), and the worries seem to have been proven unsubstantiated. I think this is the graph to look at (database master for en.wiki), and there's no noticeable impact to any component, except a peak for a few minutes after the feature was enabled, to set it up in the database. Nemo 06:15, 12 May 2012 (UTC)

Day 2 of this shit

Perhaps the implementers of this change fail to understand consensus at a basic level, I am not waiting a month for them to revert a bold change that has been overwhelmingly rejected, simply because there is technical apparatus standing in the way of AnyUser reverting this shit.

  1. The discussion implementing this solicited in the range of 20 users' input here on WP:VPP. The discussion did not describe the effects on the user interface
  2. The snow grade level above indicating this should be opt-in only is a big clue, as is the depth of outrage at sudden and poorly implemented UI changes
  3. Why has the implementer of this not reverted their actions? Fifelfoo (talk) 23:47, 11 May 2012 (UTC)
because they don't have to. There is consensus editing, but not consensus developing; they can do whatever they want. Choyoołʼįįhí:Seb az86556 > haneʼ 00:18, 12 May 2012 (UTC)
Yes, I recall that being the status on development. But surely that means they can develop what they want, but we can still ignore it? We did manage to get date autoformatting disabled, eventually ;-) --Ohconfucius ¡digame! 00:50, 12 May 2012 (UTC)
If you read the bug action they relied on a construction of consensus on wikipedia. Fifelfoo (talk) 02:24, 12 May 2012 (UTC)
  • The problem is, Steve Walling has tried to revert Edokter, and it hasn't worked as expected. I can have a go at resetting it, but I can't figure out why Steve's reverts didn't work how he expected. Let me see if I can give it a go to turn it off entirely - with apologies for testing in a live system. Elen of the Roads (talk) 01:13, 12 May 2012 (UTC)
Something has worked as all the bolding is gone. Whether it stays this way or not I want to say thanks to you EotR and/or anyone else who gave my eyes a rest - even if it is only temporary. Thanks again. MarnetteD | Talk 01:51, 12 May 2012 (UTC)
It was me. Not sure if this is a permanent fix, but I've given a number of options at the bottom of the page for folks who want the markers back. Elen of the Roads (talk) 02:12, 12 May 2012 (UTC)
Thank you for this action Elen. The concealment of process, and change structure, from the community was disturbing. While the option appears to be fruitful, if needing a lot of UI development, the process so far has not been optimal. It is good to see the Revert section of BRD applied properly to the process at last. Hopefully the discussion will improve the options related to the watchlist greatly. Again thank you. Fifelfoo (talk) 02:24, 12 May 2012 (UTC)
  • Thank you for restoring the vanilla watchlist. Now let's talk about the changes item by item. --Ohconfucius ¡digame! 02:32, 12 May 2012 (UTC)
    • Just to say I was happy when I refreshed my watchlist this morning and the dreadful bolding went away :) Thank you for your work on this. Secretlondon (talk) 10:24, 12 May 2012 (UTC)
At least now people have a choice as to how to display their watchlist. Turning on the option wasn't the problem, it was that it by default altered the appearance, which people hadn't anticipated. In the future, I expect someone who is a better script kiddie than I will create a gadget that allows you to choose if you want neon stripes or blue fish. Elen of the Roads (talk) 02:36, 12 May 2012 (UTC)
I probably wouldn't mind some blue fish on my GUI... ;-) --Ohconfucius ¡digame! 02:50, 12 May 2012 (UTC)
Thanks from me too, Elen. I'm much less likely to miss things this way. Now if we can get the colour of links we have visited to be a little more visibly different from that of links we have not visited, I'll be a happy camper. I'm one of those who looks at the colour of the diff link. Yngvadottir (talk) 04:18, 12 May 2012 (UTC)
Great, now how can we get rid of the pointless "Mark all as read" button? No bolding means no need for that. Nikkimaria (talk) 04:37, 12 May 2012 (UTC)
I made a script for the time being if you want. Add importScript('User:Equazcion/RemoveMarkAll.js'); to your skin's .js page. Equazcion (talk) 04:54, 12 May 2012 (UTC)
  • This is absurd, there's no consensus to disable this feature for everyone. The discussion about this has been opened for a short while and has not reached any conclusion: as was repeated by many, it's a very bad idea to change this back and forth before any stable conclsion, it confuses users a lot. Besides, even if you considered the #RFC above to be a valid consensus (and it isn't), this change does not make is an "opt-in" feature, which as pointed out by the proposers themselves would require some coding; the complete disabling of the feature was supported by a very tiny minority.
    More importantly, as Risker said, it's not hard to see that the vast majority of users like this change, because many said so in this page although users liking something usually don't come here to comment, unlike people wanting to complain. Nemo 06:25, 12 May 2012 (UTC)
    • It's not absurd. The burden of consensus lies in making the change to begin with. There doesn't actually need to be consensus to roll it back when there was no demonstrated consensus to implement it in the first place. Equazcion (talk) 08:26, 12 May 2012 (UTC)
      There was consensus to enable the feature, and there's no consensus to disable it (in fact no complete disabling has been asked to the devs). There's no consensus for any particular style other than the default one, which should be restored until a proper consensus has been found on an alternative. --Nemo 13:07, 12 May 2012 (UTC)
      • A good many people would seem to disagree with you that there was adequate consensus, and that said consensus was for the change the way it's actually been implemented. The discussion wasn't very widely advertised nor did it get broad participation. Many of the support !votes it did get were on the condition that a preference be added for it too. Equazcion (talk) 13:13, 12 May 2012 (UTC)
        • My bolding seems to be gone, thankfully, but I would like to point out I never heard of this so-called community discussion. This was a hijacking by a minority. In the future, everyone should hear about this sort of discussion...Smarkflea (talk) 17:56, 12 May 2012 (UTC)

Watchlist styles

OK, at great expense and enormous loss of life, I have made the bolding effect invisible in the common css as a temporary measure.

  • If you want no bolding but small green stars against the unwatched items add this to your common.css (just click, add and save)


 /* Styling for update markers on watchlist and history pages */
   span.updatedmarker {
   background-color: transparent;
   color: #006400; } strong.mw-watched a {
   font-weight: normal;
   /* @embed */
   background: url(//upload.wikimedia.org/wikipedia/commons/thumb/a/ac/Pentagram_dis.svg/13px-Pentagram_dis.svg.png) no-repeat left;
   /* @noflip */    padding-left: 16px;
}
  • If you want a dotted line under the unread ones, add this
.mw-watched {
border-bottom: 1px dotted #999;
font-weight: normal !important;
}


  • If you want the unread in italic , add
 .mw-watched {
font-style: italic !important;
}

If you want anything else, put in a request.Elen of the Roads (talk) 02:08, 12 May 2012 (UTC)

Je veux ton amour et je veux ta revanche. But seriously, thanks. Killiondude (talk) 02:13, 12 May 2012 (UTC)
Elen, you're a beautiful person. Equazcion (talk) 02:17, 12 May 2012 (UTC)
I've grown fond of the bolding. When I add the code snipit into my common.css, the bolding doesn't return. Bgwhite (talk) 02:26, 12 May 2012 (UTC)
I can't get bolding to work either. Looks like any bold attempt is being overridden, I guess by common.css? Other styles do work. I'm not complaining though. Considering the response I think it's better reverted anyway. Equazcion (talk) 02:44, 12 May 2012 (UTC)
Most odd. I can get it in italics (see code above) but not bold. I'll see if I can get something that looks similar to the bold. Elen of the Roads (talk) 03:00, 12 May 2012 (UTC)
Everything works fine for me although I placed my own style in before this thread was opened. Goto User:Cyberpower678/vector.css and copy the code from there. It bolds and stars at the same time making it actually look good in my opinion. After every technical change made to .js or .css config files, you need to purge your cache.—cyberpower ChatOffline 03:17, 12 May 2012 (UTC)

Now we're cooking on gas. Figured out what the problem was, thanks Cyberpower

  • To get the bold back, use
span.updatedmarker {
   background-color: transparent;    color: #006400;
}
strong.mw-watched a {
   font-weight: bold;
}
  • And for a really jazzy experience, try
strong.mw-watched a {text-shadow:1px 1px #000080;}

(won't work in Internet Exploder) Elen of the Roads (talk) 03:36, 12 May 2012 (UTC)

Glad I could help.—cyberpower ChatOffline 03:46, 12 May 2012 (UTC)
Exalt! Most useful. Many, many thanks. doktorb wordsdeeds 04:02, 12 May 2012 (UTC)
If you want to hide the "Mark all as read" button too, add importScript('User:Equazcion/RemoveMarkAll.js'); to your skin's .js page. Equazcion (talk) 05:05, 12 May 2012 (UTC)
Of course, you could also just use plain CSS to remove the button: form#mw-watchlist-resetbutton { display: none }. Nageh (talk) 11:16, 12 May 2012 (UTC)
Thank you Elen and Cyberpower. I hated the bold at first, but now find it extremely useful. Nice to have it back. Equazcion, I could never get your new category script to work, but found your LiveDiffLink.js script to be very convenient and now I get to add your "Mark all" script. Bgwhite (talk) 05:20, 12 May 2012 (UTC)
«I hated the bold at first, but now find it extremely useful» (bold added ;) ). Yeah, such a common and obvious thing. Too bad that the bold has been disabled for everyone and now the vast majority of users who would like it will never discover it, only because a tiny minority complained about it being unable to wait for a day to get used to it (as all MediaWiki users already are). Nemo 06:37, 12 May 2012 (UTC)
Yes, as someone experienced in change management I have to say that the reactions here should have been expected, and not over-reacted to themselves. Very shallow behaviour on both sides. Sad. It was a good change. HiLo48 (talk) 07:02, 12 May 2012 (UTC)
Many of us are experienced there too, as can be especially said for Elen of the Roads. As much as a negative reaction could've been expected, not every negative reaction is merely par for the course and should be brushed off as such. This one was more warranted due to the flawed development cycle it resulted from. Firstly, the change wasn't discussed (or was barely) -- and even though that usually isn't something users of a site are brought in on, it is something that has to happen here; the developers are not supposed to have the power to decide on changes merely due to their technical ability to implement them. The change was also not tested on a pool of this project's audience in beta fashion, and was instead tested live, where it was also rapidly tweaked several times, again with no testing. This rollback isn't a judgment of the feature or a mere reaction to outcry, but I would say in part it's a demonstration of the fact that Wikipedia is not Facebook. We're a community that discusses and decides on interface changes ourselves, rather than having them thrust upon us. When a more proper discussion and test occurs, or it is simply provided as an extra opt-in feature (or at the very least an opt-out, as even that wasn't provided), a less contentious rollout of this feature (or one like it) can then occur. Equazcion (talk) 08:10, 12 May 2012 (UTC)
  • Now, is there any way to get in the history pages unread from the last visit back on a green background, like it it done on Commons by default?--Ymblanter (talk) 07:22, 12 May 2012 (UTC)
    • I think Elen's CSS code above is supposed to remove those too, but I updated my script to remove them as well: add importScript('User:Equazcion/RemoveMarkAll.js'); to your skin's .js page if you want to try it out. It also removes the "Mark all" button on your watchlist, since that would be useless if you don't have the bolding (or similar) enabled. Equazcion (talk) 08:20, 12 May 2012 (UTC)
      Actually, I do not want to remove them (an Ellen's code does not remove them), I want to make them stronger (like it was yeaterday for a couple of hours - black text on green background). I am on the side which likes the new appearance.--Ymblanter (talk) 08:24, 12 May 2012 (UTC)

Thanks for all the code guys, really appreciated. Could someone please tell me how to remove "updated since my last visit" from when I'm looking at the history of a page (I'm on vector)? Jenks24 (talk) 07:38, 12 May 2012 (UTC)

(I meant to reply to this comment originally instead of the one above) You can add importScript('User:Equazcion/RemoveMarkAll.js'); to your skin's .js page. This also removes the "Mark all" button on your watchlist, since that would be useless if you don't have the bolding (or similar) enabled. Equazcion (talk) 08:20, 12 May 2012 (UTC)
Yes, I am using that to get of the button (thanks). But what I'm asking about is when I look at the history of a page I am seeing "updated since my last visit" in green next to edits that have occurred since I last looked at the page; how can I get rid of that? Jenks24 (talk) 08:53, 12 May 2012 (UTC)
Yes, I updated my script since I first advertised it here -- it should now be removing those green notices on history pages too. Try hitting Ctrl-F5 to make sure the update is in effect. Let me know on my talk page if it's still not working. Equazcion (talk) 08:57, 12 May 2012 (UTC)
Yep, just had to purge my cache, thanks. Jenks24 (talk) 09:27, 12 May 2012 (UTC)
Note that I also just updated the script so that if the bolding is ever re-enabled by default, the script will automatically disable it without any CSS needed. See User:Equazcion/RemoveMarkAll. Equazcion (talk) 11:39, 12 May 2012 (UTC)

This will give a light grey background to unread items:

.mw-watched {
   background-color:#e0e0e0;
   font-weight: normal !important;
}

DoRD (talk)​ 19:16, 12 May 2012 (UTC)

Cool. We need to update Wikipedia:Customizing watchlists with all these options (perhaps not the text shadow one!!) with screenshots, so that people realise they have all these choices. Elen of the Roads (talk) 19:24, 12 May 2012 (UTC)
Actually, that's only one part of the issue. Fact is that many users are not technically comfortable in using all these scripts (and since they're on individual user pages, it is impossible to ensure that they are all updated properly - which is a major problem). As well, even if people are comfortable in using them, they may have technical reasons why they are suboptimal. I've wound up disabling almost every script I ever put into my .css because it did not function properly due to some interaction with (a) other scripts or (b) something in a mandatory hardware or software setting. Gadgets work okay, most of the time. So they should either be gadgets (which are usually maintained and kept compatible with upgrades), or standard.

In the case of this particular change, I believe that the main reason there are so many complaints is that so many of the editors on this project are using skins other than Vector - in fact, I think I saw a stat somewhere that said over 70% of users who were editing pre-Vector continue to use Monobook or some other skin. This change looks fantastic in Vector, but is less pleasant on Monobook (the bolding goes beyond making the entries stand out, and can make it difficult to pick out the unbolded entries). Probably what needed to be done here was tweaking of the non-Vector skins - I note there isn't much discussion of what skin/OS/browser was being used that might relate to this issue. Risker (talk) 15:41, 13 May 2012 (UTC)

Good point about different skins. Each skin can of course have its own sitewide default. I did suggest over in The Other Place This Discussion Is Also Happening (For No Obvious Reason) that we make a gadget to apply the styling, so everyone can do what they want, and then collect stats on user choices to inform the default. If we did that we should be able to collect data split by skin, so different skins can have different defaults. On the other hand, if we do Elen's survey, that's a lot of screenshots (different options for different skins)... Rd232 talk 16:45, 13 May 2012 (UTC)
Good point. Should add that to the survey. I use modern, and it looked bloody awful - exactly the same as Truthkeeper's description of a migraine attack. So an alternative would be to check in each skin and alter the css to get a toned down effect. I do think there is a style out there that is sufficiently unobtrusive for most people not to be bothered if it is on or off - we just have to find it. Elen of the Roads (talk) 18:38, 13 May 2012 (UTC)
Hey, I have no clue how I ended up here or how I managed to understand any of this, but the green star bolding works now! Thanks cyberpower! — Preceding unsigned comment added by Keraunoscopia (talkcontribs) 04:38, 19 May 2012 (UTC)

So how about those of us who actually want this?

I personally loved the bolded titles for recent changes, and in my opinion, given how minor of a change it was, it should not have prompted such vexatious responses. Can this be made into an option in the watchlist tab of user preferences? - ʄɭoʏɗiaɲ τ ¢ 05:11, 12 May 2012 (UTC)

  • I second that! HiLo48 (talk) 05:13, 12 May 2012 (UTC)
  • Me too! Oda Mari (talk) 07:23, 12 May 2012 (UTC)
  • Like the new diff display, this took me about a day to adjust to, and now it's gone. I would like it back! Imzadi 1979  07:32, 12 May 2012 (UTC)
The ability to highlight the changes is still there. See above, or the page below, for plenty of ways to customise it to suit your eyes and watchlist. If you need a hand, give me a ping. I'm hoping we can get some kind of gadget out of this that just allows people to pick from options, which is what the original discussion actually wanted. --Elen of the Roads (talk) 12:54, 12 May 2012 (UTC)
I don't want to ping anybody. I liked the change. I can never find options and gadgets on this far too complicated site anyway. Don't make this a site for nerds. Make it friendly to newbies. HiLo48 (talk) 08:25, 13 May 2012 (UTC)
The style used seems to have caused a lot of people to have accessibility difficulties. Part of that seems to be that the entries on the watchlist are on a tight linespacing, and part that the colours are very bright. I'm betting there's a style out there that most people would find non-intrusive enough to accept as the default, but it'll be less bright. It's unfortunate that there isn't a simple way to switch it on/off, as this would end all these arguments, but there isn't. It's either on for the whole wiki or off for the whole wiki. --Elen of the Roads (talk) 14:58, 13 May 2012 (UTC)
How about this as a default (for the watchlist part only). Others can remove or adjust. The lime underline is minimally visible in the line spacing and doesn't seem to have any reducing effects on that (even the grey one seems fine to me). I think new users will never know about it if we make it an opt in feature. --lTopGunl (talk) 15:27, 13 May 2012 (UTC)
I'm collecting options. Certainly add that to WP:CUSTOMWATCH Elen of the Roads (talk) 17:44, 13 May 2012 (UTC)
  • Me too! Those who actually liked the change will be more likely to by shy and reluctant to go around like you to see what had happened, why it came to their watchlist and why it disappeared again. I want it back, I want it back (without reading through tons and tons of mostly negative comments). It was saving me lot of time (the thing I have the least of) Reo + 20:38, 17 May 2012 (UTC)

Wikipedia:Customizing watchlists

A new page to try and collect the ever-shifting sands of this styling thing in one place: Wikipedia:Customizing watchlists. Contains instructions to disable, enable, and use alternative styles. Rd232 talk 10:26, 12 May 2012 (UTC)

Next steps

Appreciate input here as to next steps with communicating this, moving to a more permanent outcome etc. --Elen of the Roads (talk) 13:57, 12 May 2012 (UTC)

Communication suggestion now posted at User:Elen_of_the_Roads/Watchlist_survey. Comments, brickbats etc here or at Wikipedia:Village_pump_(proposals)#Next_steps. We have to put out something to let users know that the facility is available should they wish to use it. At the same time, some of the folks who took part in the very first discussion are still of the opinion that it should just be switched on as most users either like it or would get used to it, so we need to find out if that is the case as well. --Elen of the Roads (talk) 12:13, 13 May 2012 (UTC)
Final version with images now done. I'll leave it 24hrs for comments (I notice people have started to fill it in), then move it out of userspace and ask for a watchlist notice, unless anyone objects. --Elen of the Roads (talk) 00:30, 14 May 2012 (UTC)

Real life has intruded

I'm having r/l time issues. Could someone ship this out into rfc space and list it to see if we can have a watchlist notice. So we don't lose any more time. Elen of the Roads (talk) 21:04, 15 May 2012 (UTC)

Fake Edit Summaries

A request was made above for a way to disable the fake edit summaries that came with this change. I for one would really like a way to do so, as its extremely annoying when you have an edit occur with no summary, and then look to see what the justification for the edit was, only to find the stupid message informing you the change occured since you last looked, which as your looking is REALLY OBVIOUS. So is there a way to get rid of them? Monty845 18:35, 13 May 2012 (UTC)

You mean the green "changed since your last.." message. I do believe there is a way to make it invisible as a js hack. --Elen of the Roads (talk) 20:16, 13 May 2012 (UTC)
That is what I'm referring to, do you know if anyone has one working? Monty845 01:42, 14 May 2012 (UTC)
Add this to Special:MyPage/common.css (applies to all skins) or Special:MyPage/skin.css (your current skin):
span.updatedmarker{display:none;}
PrimeHunter (talk) 01:43, 14 May 2012 (UTC)

Overriding to plain text

  Unresolved

I think the turning off of bold text has something to do with overriding the js scripts which no longer bold the specific links. Is there a way around that? Shouldn't this be fixed? --lTopGunl (talk) 01:32, 14 May 2012 (UTC)

I think you need to explain the question better. Bold text where. What links. If you mean watchlist links, the whole (lengthy) explaination is either above or in the archive. --Elen of the Roads (talk) 21:05, 15 May 2012 (UTC)
I'm using User:Ais523/watchlistnotifier.js which notifies of changes on the watchlist while being on other pages as well as bolds the lines that appear after last reload of watchlist. After the the watchlist changes were enabled (which bold the unvisited pages rather than just the newly loaded ones) and the was set to normal text as default... I chose to use a subtle underscore version of it so that the new changes after reload can still be bold and do not confuse. The issue is that the new lines are still getting a bold font as per the script minus the page titles in the watchlist which if unvisited do not get bold even though the js script is set to bold the full line. --lTopGunl (talk) 21:44, 15 May 2012 (UTC)

Restore watchlist bolding after the new change to Common.css on May 17

Is this the right place, or has a whole page somewhere been devoted to this topic? Anyway I woke to find that my bolding had gone away. This was a valuable tool. It didn't come back even when I inserted the necessary material into User:Jim.henderson/vector.css. Help; I am much more easily confused going through my excessively long recent changes list without the system telling me which of the hundreds of changes I've already seen. Jim.henderson (talk) 09:50, 17 May 2012 (UTC)

Fixed it for you (you may need to bypass your cache). See #Special page - related changes below for details on why the old change stopped working. Anomie 16:14, 17 May 2012 (UTC)
Anomie's latest change to Common.css was here on 17 May. Anomie had previously explained what to do at Wikipedia talk:Customizing watchlists#Changes needed. I made the recommended change to my vector.css and it restored the bolding as promised. EdJohnston (talk) 16:28, 17 May 2012 (UTC)
Thank you kindly. Returned tired and sunburnt from pedalling a daylong, 30 mile, umm 50 km photo trip, and felt much better to turn on the home computer and see a friendly face of watchlist. Hope a simple opt-out button in Preferences can soon do such things. And for that matter, in the list of diffs, a similar scheme would be better than words saying a page has been "updated since last visit". Jim.henderson (talk) 23:51, 17 May 2012 (UTC)

What's going on? It just doesn't work

Whether we like the bolding in the watchlist or not, what we currently have just doesn't seem to work. My watchlist states "Pages which have been changed since you last visited them are shown in bold", and yet nothing is bold. There is also a "Mark all pages visited" button, which seems to have absolutely no effect (and in any case, it's unlikely that there'd be any pages on my watchlist which I haven't ever visited). These "features" should either be fixed or removed. Bazonka (talk) 07:41, 18 May 2012 (UTC)

The bolding itself was de-activated temporarily due to backlash while a more permanent solution is being considered. See Wikipedia:Customizing watchlists for instructions on removing the other remnants of this feature for yourself, or re-enabling the bolding, whichever you prefer. Equazcion (talk) 08:15, 18 May 2012 (UTC)
Being able to customise stuff is all well and good if that's what you want, and if you know what to do. But the default uncustomised state should at least make sense, without non-functional buttons and irrelevant messages. I shouldn't have to "remove the remnants". The button and message should only appear if they work, whether this be by default or following customisation. Bazonka (talk) 09:43, 18 May 2012 (UTC)
We are in complete agreement. The developers responsible for these changes were either unable or unwilling (it's unclear) to undo them. This temporary override was initiated by Wikipedia's administrators, who have more limited access, as a last resort. Equazcion (talk) 09:58, 18 May 2012 (UTC)
I've filed a bug for this. I don't think this was tracked otherwise, so there is no chance to get it fixed. — MarkAHershberger(talk) 15:29, 18 May 2012 (UTC)
I use this and it works fine with me. With the bolding in the watchlist, no message and no button. Oda Mari (talk) 06:17, 19 May 2012 (UTC)
Good for you Oda, but you're missing my point. Most users won't want or know how to use css code. It should just be correct, without the need to resort to this kind of workaround. Bazonka (talk) 08:18, 19 May 2012 (UTC)

Seems Thomas (activist) keeps defaulting back to a version of the page over 7 days old. Problem comes when viewing as an anon from an external website (see here, for example). I have purged the article numerous times over the last week. Any ideas? Nirvana2013 (talk) 19:05, 17 May 2012 (UTC)

What exactly is different on your end (as an anon)? I checked it and don't see anything. In general, however, anonymous users use cached versions of pages but it normally isn't more than just a few edits behind the live version. Killiondude (talk) 19:14, 17 May 2012 (UTC)
This is the page when not signed in and when directed from external site. Nirvana2013 (talk) 21:14, 17 May 2012 (UTC)
The bottom of pages say "This page was last modified on ...". That part is missing in your screenshot but it does look like an old version. If purging doesn't help then it may be your ISP. See Wikipedia:Bypass your cache#Internet Service Provider Cache. Try adding a '?' to the url as in http://en.wikipedia.org/wiki/Thomas_(activist)? PrimeHunter (talk) 22:15, 17 May 2012 (UTC)
The page says "This page was last modified on 1 May 2012 at 10:22." The article is now 18 days out of date! If you can see the updated page as an anon, then you must be right that it is my ISP (which is BT in the UK). Any ideas on how to rectify for good, rather than adapting the url? Nirvana2013 (talk) 13:40, 18 May 2012 (UTC)
It seems to be only one day outdated for me, as logged in I see 18 May, yet logged out I see 17 May.  Hazard-SJ  ✈  03:03, 19 May 2012 (UTC)
Thanks Hazard-SJ. I do not know what is going on with BT's cache. "BT is the largest ISP in the UK with currently 4,600,000 broadband users." This does not seem very good for a number of potential Wikipedia readers. Nirvana2013 (talk) 10:01, 19 May 2012 (UTC)

"This Is A Tool Icon" on the with Beacon Hill article

at the Beacon Hill Article (http://en.wikipedia.org/wiki/Beacon_Hill), there's a cross halfway down on the right hand side with an X, labled "This Is A Tool Icon", that floats with page scrolling.

Looking at the edit box, I could not see what was causing it

tested on Firefox 12 and Internet Explorer 10

81.149.182.210 (talk) 15:19, 19 May 2012 (UTC)

See also WP:Help desk#Strange tool icon on "World's largest universities" page. From the comments there, I'd guess it has something to do with development of the "New Pages Feed" (the "mwe-pt-toolbar" and other tags mentioned there come from the PageTriage extension). Anomie 16:29, 19 May 2012 (UTC)
I've turned off the extension for now. Kaldari (talk) 18:47, 19 May 2012 (UTC)

Preference for opening search result list or search suggestion in new tab

I propose a gadget (in preferences) for opening search results and suggestions in new tabs. I suggest basing it on the JavaScript found here:

It works great on both Wikipedia and the Commons. For implementation and more info read the talk page here:

I also proposed this here:

I started this Bugzilla thread: "Bug 35974 - Preference to open search results and suggestions in new tab".
https://bugzilla.wikimedia.org/show_bug.cgi?id=35974
But that may take a long time. Is there any reason this can't be implemented as a gadget now on English Wikipedia? Many people want it. --Timeshifter (talk) 16:23, 14 April 2012 (UTC)
After adding the JavaScript mentioned above, clicking the search icon when the form is empty takes one to Special:Search in a new tab.
So this proposed gadget solves many problems. Also, there are many suggested search enhancements discussed here:
commons:Commons:Requests for comment/improving search. Some of them depend on getting to Special:Search. --Timeshifter (talk) 15:40, 6 May 2012 (UTC)

Search link in sidebar would fix the problem too

Putting an "advanced search" (Special:search) link in the sidebar would fix the problem too. People could right-click it to open it in a new tab. Most readers do not know much about how to find stuff on Wikipedia. They try the search form, but soon see that it covers up the page they are looking at. Many people stop using the search form after that, and use Google Toolbar instead for site searches.

But Google Toolbar does not allow one to pick and choose namespaces to search. Special:search does do this. Also, Google no longer makes Google Toolbar for Firefox. So, putting an "advanced search" link in the sidebar would solve many problems. --Timeshifter (talk) 05:35, 23 April 2012 (UTC)

Or search link in a drop-down menu at the top

In preferences there is a gadget (in the appearances section of the gadget tab) called "Add page and user options to drop-down menus on the toolbar." The search link could go there in the drop-down menu. That may be the simplest way to get searches done in a new tab. Also, it does not take up any valuable real estate in the sidebar or at the top. Any thoughts? --Timeshifter (talk) 14:48, 29 April 2012 (UTC)

Can now be imported into any-language Wikipedia

Here below is what people can add to en:Special:MyPage/common.js - for me that ends up here: en:User:Timeshifter/common.js. The JS links are for English Wikipedia (en). Change the links as necessary for other-language Wikipedias.

/* Open search results list and search suggestions in new browser tab */
/* commons.wikimedia.org/wiki/MediaWiki_talk:Search-results-new-tab.js */
mw.loader.load('//commons.wikimedia.org/w/index.php?title=MediaWiki:Search-results-new-tab.js&action=raw&ctype=text/javascript');

For more info about the JS import code go here:

Popular Firefox search addon opens results list in new tab

Featured, popular Firefox search addon: Context Search. From its description:

Once the search engine menu is visible:
- Left click to search in a new background tab.
- Middle click to search in a new tab and switch to that tab immediately.
- Ctrl+click to search in a new tab and switch to that tab immediately.

If you have Firefox set to switch to new tabs immediately, the above key combinations will have the inverse effect.

Shift + click opens search results in a new window. (End of description quote).

This is one of the most popular Firefox search addons. I believe part of the reason it is so popular is that it opens the results list page in a new tab. That is the default setting. So search never interferes with what you are doing or what page you are reading. On the other hand the results from Wikipedia's search form at the top right of every article page cover up the article that one is reading. It is very annoying to many people. --Timeshifter (talk) 22:22, 15 May 2012 (UTC)

Ctrl-click does not work to open search result list in a new tab

At least in Firefox for Wikipedia this is true. Neither does shift-click, nor ctrl-shift-click, nor alt-click. --Timeshifter (talk) 23:57, 20 May 2012 (UTC)

Hamletbot considered desirable

Reading a page that I came across via Special:Random, I noticed that it described Moose Bay as a hamlet instead of a hamlet. After I fixed it, I decided to see get an idea of how many other hamlets have this problem, in case it was a small enough number that I could reasonably fix them all.

Well, according to "What links here", there are approximately 4,500 pages that link to Hamlet. At least 300 of these appear to be pages for places, half of them in the province of Saskatchewan and half in various other states, provinces, and countries. I therefore suggest that practically all of these are talking about hamlets and not Hamlet.

But 300+ pages is too many to conveniently fix by hand. So I had another idea: links intending to point to the play will almost certainly spell it [[Hamlet]], whereas those intending to talk about a hamlet will almost certainly spell it [[hamlet]].

Therefore if someone would please write a bot to scan through all links to Hamlet, find the ones spelled [[hamlet]], and just change those into [[hamlet (place)|]], it might introduce a few errors but I'm sure it would be a big improvement on the current situation.

Whether this bot should be a once-only thing or whether it should run regularly in case someone generates a bunch more pages about hamlets in some state, province, or country is a decision I'll happily leave to others. Likewise the question of what degree of human checking is appropriate, and of whether there are any other words/names that need similar treatment.

But I do say that it should be written and should be run once on "Hamlet", anyway.

--76.69.138.214 (talk) 08:09, 19 May 2012 (UTC)

I've started to go through the pages manually - most of them are fairly easy to spot so I haven't had to look at each and every article. But it's a bigger job than I'd anticipated, and it won't get finished immediately. A bot would certainly help, but it could end up introducing new errors, e.g. linking to Hamlet (place) when the correct link would be Hamlet (fish). Bazonka (talk) 12:49, 19 May 2012 (UTC)
I found that there are 122 articles in the Category:Saskatchewan geography stubs that contain links to Hamlet. I think it's pretty safe to assume without hand-checking that all of these should link to hamlet (place) so I'm correcting them. I suspect there may be one or two other cases like this. That category appears to be unique; any remaining errors will have to be detected some other way. --R'n'B (call me Russ) 13:21, 19 May 2012 (UTC)

Should the links be fixed, though, or perhaps the pages renamed? Why is a play more important than the thing the guy the play is named after is named after, when that is a general term? -— Isarra 18:25, 19 May 2012 (UTC)

So you'd rather break 4,500 links than fix 200 of them? OK, that was a rhetorical question. Anyway, the question isn't what's "more important"; the question is whether one of these is the primary topic for the ambiguous term "hamlet." --R'n'B (call me Russ) 20:18, 19 May 2012 (UTC)
I've now gone through the entire list of articles that link to Hamlet and fixed about 250 or so. I think that between us R'n'B and I have probably fixed the bulk of this problem, although undoubtedly some will still remain incorrect. There are also quite a few like "X was an actor who played Hamlet" where the link is to the page for the play - arguably it should link to the character, Prince Hamlet. However, I guess that this isn't a real problem because at least they link to something relevant. Bazonka (talk) 16:02, 20 May 2012 (UTC)
I guess we have different views of long-term significance. -— Isarra 17:02, 20 May 2012 (UTC)
Maybe, but in the end we should both be guided by consensus. If you think the current naming is wrong, feel free to propose moves of the articles about the play and about the community. (I presume we both agree that the fish is not in contention.) However, if there is a consensus favoring such moves, someone will need to take the responsibility of fixing all affected links either before or contemporaneously with the moves. --R'n'B (call me Russ) 17:08, 20 May 2012 (UTC)
Hamlet the character is only notable because of the play. Arguably, the type of place is more important than the play, but I would disagree - at best they are of equal importance. However, we need to take into account the collateral damage of changing the scope of the Hamlet article, and this would be huge if it changed from anything but the play. It's just not worth it. Bazonka (talk) 17:21, 20 May 2012 (UTC)

Monobook

Morning. My monobook scripts used to give me a nice citation button, where once you inserted a URL it would auto-populate the reference. This seems to have vanished. Anyone up to kindly perusing my script here and working out what's wrong with it? 'Caure I'm a dunderhead. S.G.(GH) ping! 09:02, 20 May 2012 (UTC)


RefToolbar is now enabled by default. Remove importScript('User:Mr.Z-man/refToolbar.js'); and reload per the instructions at the top of your JS page. ---— Gadget850 (Ed) talk 14:16, 20 May 2012 (UTC)
Ah, that's back again - but still not auto-populating? S.G.(GH) ping! 20:38, 20 May 2012 (UTC)

A question for CSS specialists

How can I remove the three humongous sections on a edit page, namely 'Please Note', 'Pages transcluded onto the current version of this page' and 'This page is a member of 2 hidden categories'. Is there a CSS tag to remove these?
Thanks in advance! EngineerFromVega 17:35, 20 May 2012 (UTC)

You could try the following, assuming we're talking about the Vector skin:
div#editpage-copywarn2 { display: none; }
div.templatesUsed { display: none; }
div.hiddencats { display: none; }
--R'n'B (call me Russ) 17:50, 20 May 2012 (UTC)
"This page is a member of 2 hidden categories" is probably dealt with the preference in the Appearance tab at Special:Preferences labeled "Show hidden categories". --Izno (talk) 00:10, 21 May 2012 (UTC)
Nope, that preference refers to viewing the article normally, not in the edit window. Graham87 02:03, 21 May 2012 (UTC)
Thanks everyone. I've tried these to put in monobook.css but I don't get the desired results. I'm using the vector skin. Please take a look at User:EngineerFromVega/monobook.css. EngineerFromVega 03:56, 21 May 2012 (UTC)

  Done After putting the same in vector.css, all these sections are now gone in a puff of smoke. :) Thanks for the help. EngineerFromVega 04:00, 21 May 2012 (UTC)

Perl call to get search results

Is there a Perl call that can pick up the results of a Wiki search? If I perform this search are there a few lines of Perl that get the results so I can then look through them? Thanks. History2007 (talk) 20:31, 20 May 2012 (UTC)

See mw:API, particularly mw:API:Search. Anomie 22:37, 20 May 2012 (UTC)
I will take a look. Thank you. History2007 (talk) 04:44, 21 May 2012 (UTC)

Major problems with new Wikipedia mobile site - Please revert back

Someone posted this in another section and didn't re-post this here, so I am doing it for them. I am also having major problems on the new mobile site on my Android phone that mirror these and make it nearly unusable. It worked fine before!!



The new Wikipedia mobile website is really bad. It has many problems when viewed on Android mobiles: If you scrolll down while the page is loading, it scrolls back up to the beginning after page loads, unexpectedly. Why does it forcefully scroll the page when the user didn't request it? The arrow button (in each section for "Show more content") is hard to press, because it's too small. The previous version had a proper "Show" button which was bigger. Sometimes the full content doesn't appear when you press the arrow button. It might show only the first half of a paragraph, for example. When you use the arrow button a few times, it's virtually impossible to escape out of the page with the Back button. You have to press it so many times, and it's difficult to tell what's going on. Using an arrow button is not good for usability anyway, because you can't tell what it's supposed to do. The link "Jump back a section" usually does nothing. Please could someone revert it back to the old mobile version ASAP, which didn't have any of these problems.


Adding to this: when you press the arrow or text to expand a section, it takes forever to open. You aren't sure if anything is happening, so often you will press it again, only to have it quickly open and then re-close because the re-close operation registers nearly immediately.

Really, it's terrible. Even my girlfriend, who is not technical, was using it the other day and mentioned it was different and wasn't working correctly. — Preceding unsigned comment added by Georgiabiker (talkcontribs) 14:19, 15 May 2012 (UTC)

  • Sorry about the problems with the recent deployment of the mobile site. A lot of unexpected problems crept in. The fixes to most of the problems should be deployed today. --Philinje (talk) 17:52, 15 May 2012 (UTC)
  • Yeah I also seem to be having some problems, even though I use an iPod Touch. I'm also probably the only person who browses Mobile Wikipedia on a computer though. Anyway, aside from the fact that sometimes the whole page doesn't load (just a few sections), another problem I have is if I try to open a new tab, when I go back to the old tab, it goes back to the top of the section! Very, very, very annoying. Narutolovehinata5 tccsdnew 01:28, 16 May 2012 (UTC)
We haven't seen any more of these issues creep up after last weeks pushes. Let us know if you see any more. Tfinc (talk) 22:07, 21 May 2012 (UTC)

Interwiki BOTs

Can someone take a look at Leigh Francis as for the last 4 days a number of interwiki BOTs have been adding then removing the interwiki links. Looks like something is causing a problem on one of the wiki's entry. Keith D (talk) 12:04, 21 May 2012 (UTC)

I've stopped the bots for now (I hope), but I don't think they were misbehaving. Looks like a malicious user is creating stubs on this Leigh Francis guy on multiple Wikipeida wikis only for them to be deleted shortly afterwards, presumably on speedy notability grounds. This causes the interwiki bots to chase each other around adding and then removing the corresponding articles (for example). Looks like it the work of a blocked user, User:Onelifefreak2007. — Blue-Haired Lawyer t 13:59, 21 May 2012 (UTC)
Thanks for taking a look, thought there had to be a simple explanation. Keith D (talk) 17:23, 21 May 2012 (UTC)

MediaWiki 1.20wmf3 deployment happening shortly complete

Hi everyone! Yet another deployment in our bi-weekly deployment cycle will soon be underway (in 30 min, at 18:00 UTC). See mw:MediaWiki 1.20/wmf3 for release notes. Let us know if you encounter problems caused by this deployment. Thanks! -- RobLa-WMF (talk) 17:27, 21 May 2012 (UTC)

Done now -- RobLa-WMF (talk) 18:22, 21 May 2012 (UTC)

Bug with RevDel

When you go to look at a blocked user's contributions (for example, Special:Contributions/Block me) you no longer see the (del/undel) link to hide the block event. Instead, you see a checkbox, which I presume has to do with the update of log event hiding. However, the button to hide the selected events does not appear. Thanks! Reaper Eternal (talk) 18:58, 21 May 2012 (UTC)

The same issue occurs with deleted pages (example). Reaper Eternal (talk) 19:01, 21 May 2012 (UTC)
I just noticed this while deleting File:Morgan Strebler silverware bending.jpg. As far as I can see, the boxes up top have no effect; when I selected all of them (while leaving all of the boxes at the bottom of the screen unchecked) and undeleted, it restored everything (just as if I'd not selected any boxes at all), and the same thing happened when I selected just one box up top and none below. Nyttend (talk) 01:19, 22 May 2012 (UTC)

Date sort screwing up

The table below is copied from Help:Sorting#Dates:

Date sort mode
07 Apr 2001
16 Apr 2007
16 Mar 2007
05 Apr 2007
04 May 2007
18 Mar 2007
27 Mar 2007
20 Aug 2006
22 Jul 2006

Notice that Apr 2007 gets sandwiched between two Mar 2007 entries upon sorting. Now, I'm honestly not sure if this table is supposed to be an example of a non-working setup or what, because frankly, the help section on date sorting is so completely fucked that it hurts my brain to imagine the individual that considered it helpful. I plan to nuke it once this is clarified to me. How exactly does one make a table sortable by date? Equazcion (talk) 13:44, 20 May 2012 (UTC)

Thanks for posting this here, Equazcion. I posted a Q over at the Help Desk because I couldn't really figure out the explanations either. Hopefully someone'll know! :) Salvidrim! 15:12, 20 May 2012 (UTC)
Try something like <span style="display:none;">{{#time:Y-m-d|{{{date1}}} }}</span>{{{date1}}} etc. in a template although I note that there are two ambiguous dates listed. Is it d-m-Y (15-04-2024) or m-d-Y (04-15-2024)? – Allen4names 15:31, 20 May 2012 (UTC)
This is copied from the help page, so I'm not sure what the original intent was. If this table is meant to work, it could conceivably take the format of the entries with named months as indication that they're all d-m-y. My main question though is, are the hidden labels always necessary? Is there a way to do this by grouping d-m with wikilinks? The help page seems to indicate something like that, and might even be saying that isn't necessary, but I can't tell because it seems to have been written by someone with some sort of neurological disorder. Equazcion (talk) 15:38, 20 May 2012 (UTC)
P.S. The template is {{Dts}}. – Allen4names 15:40, 20 May 2012 (UTC)
I think the moral here is - be consistent with your date formats and it'll be alright on the night. NtheP (talk) 15:42, 20 May 2012 (UTC)
The only all-number date allowed by WP:MOS is yyyy-mm-dd. (Also tweaked the above for full year as there is also an 07 April entry and poor me got confused.) --Mirokado (talk) 15:45, 20 May 2012 (UTC)
Consistency doesn't seem to work on its own, I've tried. The template Allen4names posted is the only thing that seems to have worked so far, so thank you very much for that, Allen. I'd still like to know what's up with this though. I want to clean up that help section so it looks less like a schizophrenic clown's pubic hair (I'm running out of ways to insult this thing, sorry). Equazcion (talk) 15:50, 20 May 2012 (UTC)

The interpretation is described in the help page section "Sort modes", with some errors and vagueness. The main ideas seem to be that it only works with formats like "25-12-1987", "25-12-87", "25 Dec 87", or "25 DEC 1987". All it does is create a character string by moving various characters around. Plus, if the year is only two digits, it interprets everything below 50 as in the 2000's and everything above 50 as in the 1900's. So the examples I gave would be transformed to "19871225", "19871225", "1987De25", and "1987DE25". Then the resulting character strings would be sorted.

So all the dates in the table must be consistent within the table. Further, of the 4 formats allowed by MOS, three don't work. Of the 6 formats allowed by this function, 4 are forbidden by MOS. This is so horrible, I'm not sure whether it would be better to plaster the help page warning not to do this, and only use the information for correcting any article that contains this abomination, or to file a bug to have this crap completely ripped out of Wikipedia source code, and let any tables that contain it fail. Jc3s5h (talk) 15:58, 20 May 2012 (UTC)

I edited the table above to be consistent as [dd month yyyy], which according to your interpretation of the help page, should work. It doesn't seem to though. Equazcion (talk) 16:03, 20 May 2012 (UTC)
It seems to work if every month is given as three letters. The letters can be first-letter capitalized ("Sep") or all-caps ("SEP"). It does not work if the months are spelled out (September). Jc3s5h (talk) 16:34, 20 May 2012 (UTC)
Sorry I should've said [dd Mmm yyyy]. The table above is currently formatted as you suggest, but the sorting still screws up. Give it a try. Equazcion (talk) 16:37, 20 May 2012 (UTC)
OK, so it seems to be translating the month abbreviations to a number, but sorting first on the year, then on the day-of-month, and last on the month, so it is indeed broken. And, in my view, not worth fixing. Jc3s5h (talk) 16:41, 20 May 2012 (UTC)
  • Whoa, what? When is any bug not worth fixing? Even the most minor bugs need to be corrected. The whole point of creating and maintaining any kind of system is make it as error-free as possible, and ignoring or dismissing errors certainly runs contrary to that goal. Salvidrim! 16:49, 20 May 2012 (UTC)
    • From Jc3s5h's other comments above, it seems he means that the whole feature should be tossed out since it's in such bad shape -- not quite that it should be ignored. I'd love to demolish that help section myself to make it clear that this feature isn't worth any attempt to use except with the {{dts}} template. Equazcion (talk) 16:53, 20 May 2012 (UTC)
Yes, my view is that the feature should be removed; let the table editor either put in date strings that are directly sortable (YYYY-MM-DD) or use the dts template. Any effect in existing tables would be a benefit, since its better to have an obvious error that a subtle one. Jc3s5h (talk) 17:32, 20 May 2012 (UTC)
Ah, I get it. :) Salvidrim! 17:37, 20 May 2012 (UTC)

Yes, table sorting is borked. When 1.18wmf1 was deployed last fall, it included a new tablesorter module that should have made the sorting templates obsolete. Unfortunately, it is dependent on HTML5 and when that was enabled, it broke so many things that HTML5 was disabled after a few hours. T33527 ---— Gadget850 (Ed) talk 17:43, 20 May 2012 (UTC)

I just took a wrecking ball to Help:Sorting#Dates. Equazcion (talk) 18:16, 20 May 2012 (UTC)
(edit conflict) We are using the new tablesorter module, we just can't take advantage of the explicit column tagging feature until HTML5 is enabled. This bug is unrelated: the date sorting of the tablesorter module could easily determine that "1 Apr 2012" is DMY order and "Apr 1 2012" is MDY order, but for some reason it doesn't. It just converts them to "1 4 2012" and "4 1 2012", respectively, and then assumes MDY or DMY order based on the global wiki configuration. Anomie 18:19, 20 May 2012 (UTC)
My SWAG is that the new tablesorter without HTML5 makes it attached to another object by an inclined plane, wrapped helically around an axis. ---— Gadget850 (Ed) talk 18:42, 20 May 2012 (UTC)
I should think that would've been obvious. Equazcion (talk) 18:50, 20 May 2012 (UTC)
I'm pretty sure the axis referred to by Gadget850 is normal to a toilet bowl rim. Jc3s5h (talk) 19:11, 20 May 2012 (UTC)
I almost fell over laughing when I read "the new tablesorter without HTML5 makes it attached to another object by an inclined plane, wrapped helically around an axis." A while back I spent a few days trying to figure out just a few problems with table formatting for sorting. It nearly drove me nuts. I did manage to add some accurate (at the time) info to Help:Sorting. I did not even attempt to figure out full date sorting though. I did manage to figure out a few permutations of year-only sorting. Also, I figured out some of the numerical sorting problems. --Timeshifter (talk) 10:31, 22 May 2012 (UTC)

File redlink should not lead to godawful upload form

Why do file redlinks lead to the upload wizard? It is such a pain to try fix deleted image issues now, because you have to cut the filename out of the target page URL, or open up the page to cut it out of the code, then search for it and click from the link from there, or paste it into a fresh URL. It should show the page logs with an option to go to Special:Upload or the upload wizard (which is designed for the uninitiated). Why are we encouraging editors to re-upload images that were deleted, instead of showing them why they were deleted? That seems disruptive. ▫ JohnnyMrNinja 20:58, 20 May 2012 (UTC)

As an admin it's also annoying because I might want to track patterns of those deleted images (all I want is the deletion log-entry and associated links). When one follows a redlink to an article (or other text-content) page that has been deleted, there's a pink "A page with this title has previously been deleted." box with log entries, etc. Seems like this same UI feature would be just what we need on the first upload-page one gets when following a redlink to an image. DMacks (talk) 21:10, 20 May 2012 (UTC)
Yes, that makes sense. I think they changed it because it was pointless to encourage edits to "create" file pages, instead of uploading files. Why not create a hybrid? Show the page logs at the top (like a normal redlink), and the upload links at the bottom (instead of an edit field)? Clicking the edit tab should still allow you to create a file page, so everyone would win. ▫ JohnnyMrNinja 21:17, 20 May 2012 (UTC)
Is there any chance of a script/preference workaround for this? Could the navigation popup catch this as a special case and display something about the wpDestFile instead of telling us about the upload wizard? -- John of Reading (talk) 16:17, 21 May 2012 (UTC)
In principle, the WP:FUW page itself could be made to recognize the wpDestFile= parameter and include a message with the deletion log etc if necessary. However, for this to be possible, it would be necessary to make the script globally available through one of the global script files. But the better option is certainly to have the redlinks point somewhere else from the start, see for options below. Fut.Perf. 06:31, 22 May 2012 (UTC)
Until Future Perfect at Sunrise decided to rename the page three months ago, there was always a link to the deletion log at Wikipedia:Upload. I've never seen the benefits of moving the page, but this is a clear downside to having it moved. Nyttend (talk) 01:30, 22 May 2012 (UTC)
I pinged FutPerf. DMacks (talk) 02:19, 22 May 2012 (UTC)

I was going to ask the same question when I returned from the trip I'm on. Although I agree this may be helpful for new users, and have no problem with it being the default, it would be nice if there was a user option to instead have it show the name "deleted page" page, essentially for the same reasons as DMacks although I think it could also be beneficial to other users who are unlikely to upload an image but for whom the deletion log may be useful (people investigating sockpuppets, copyright etc). Dpmuk (talk) 02:26, 22 May 2012 (UTC)

This was discussed a few months ago. I quite agree the image redlinks should not lead to the upload wizard. I want to make clear though that the change I made when introducing the wizard is not what causes this behaviour. If we reverted that change today, image redlinks would instead lead to the page that is currently at Wikipedia:Upload/old (because image redlinks go to Wikipedia:Upload, and that's what was at that page before I redirected it to Wikipedia:File Upload Wizard.) This page would not show the deletion log either, because (unlike Special:Upload) it can't react to the filename parameter in the Url any more than the FUW can. If it seems my change coincided with another change in linking behaviour, this must be because it happened to coincide with a change in the Mediawiki software, where there were some tweaks made to image redlinks around the introduction of v.1.20 (iirc). I'll need some time to dig up the links to the old discussion and related pages on bugzilla about the Mediawiki changes. If I remember correctly, there is a Mediawiki variable whose behaviour was changed, and which we might want to set differently in order to point the redlinks elsewhere. But I'm not quite sure what the best target would be. Fut.Perf. 05:11, 22 May 2012 (UTC)

For illustration, here's several options of how file redlinks could currently be handled:

Out of curiosity, which of these corresponds to what people remember was the normal behaviour for (non-coloned) redlinks prior to February? Because I really don't know. Fut.Perf. 06:22, 22 May 2012 (UTC)

So, if moving the page back to the previous title wouldn't help, what would? All I know is that it stopped appearing exactly at the same time as when you moved and rearranged the page substantially. Nyttend (talk) 12:13, 22 May 2012 (UTC)
What would help would be to get the MediaWiki variable that governs the behaviour of these redlinks changed to point to one of the url types listed above. I forget what it was called, but there is such a variable. It's something that has to be requested on Bugzilla and done by the devs, but other than that it's fairly easy. We just need to decide which of the above we want. Fut.Perf. 13:52, 22 May 2012 (UTC)

Images overlapping with table

Can someone have a look at List of Sheffield United F.C. players and see how to amend it so as the table refs don't overlap with the photos? I'm using Safari on ipad. The first photo opposite the table (Barclay) displays fine, but then on all the others (except Needham) the photos overlap with the Ref column. Thanks. Eldumpo (talk) 21:23, 20 May 2012 (UTC)

I added a {{clear}} that solved the issue on Safari, and was going to come here to comment that since a) I didn't see the problem with other PC browsers I tried, b) the overlap only appeared with PC Safari with a fairly narrow window sizing, and c) it leaves a hideous amount of whitespace on all browsers at all window sizings, I was going to say it might not be worth it, but now see that my "fix" was immediately reverted as "unacceptable solution", so not sure what to suggest. (Well, I have a theory about breaking the table up alphabetically and having one image/clear per sub-table, but that kinda defeats the purpose of having a sortable wikitable, and again, given the limited number of users affected, probably wouldn't fly, either.) 71.197.246.210 (talk) 01:23, 21 May 2012 (UTC)
Thanks for responding and trying something. I can see how the whitespace was a problem, and yes splitting it up would not work as you would not be able to sort. I'd like to think there is a technical solution, as I've seen pictures on the right on similar articles. Eldumpo (talk) 07:39, 21 May 2012 (UTC)
Pictures on the right of tables is oftentimes a problem. A gallery section would solve the problem. See Wikipedia:Gallery tag:
<gallery> </gallery>
You can eek out a little more space for photos on the right by putting the sorting icons above the header text. See the last part of this section: Help:Sorting#Header styling, links, and markup --Timeshifter (talk) 10:42, 22 May 2012 (UTC)

New pages bug?

When I clicked the link to review the new page Long Ding I got a page saying "The page Long Ding&action=markpatrolled&rcid=504963624&token=9993d1607d61778bcd5415f0 does not exist". What is going on?  Liam987(talk) 15:10, 21 May 2012 (UTC)

Where are you clicking this from? Special:NewPages or somewhere else? This wiki or another wiki? (The problem seems to be with the use of a non-standard & character.) - Jarry1250 [Deliberation needed] 15:31, 21 May 2012 (UTC)
When coming to an unpatrolled page from Special:NewPages, a link appears at the bottom that says [Mark this page as patrolled]. See Wikipedia:New pages patrol/patrolled pages  Liam987(talk) 19:46, 21 May 2012 (UTC)
Happened on Bostan Khan as well  Liam987(talk) 20:21, 21 May 2012 (UTC)
Has anyone else had this happen?  Liam987(talk) 13:38, 22 May 2012 (UTC)
Special:NewPagesFeed was apparently just deployed, along with MediaWiki 1.20wmf3 (below), so maybe it has something to do with one of those. I just tried patrolling a page and didn't get an error; I don't know if you're getting it every time or just intermittently? Equazcion (talk) 13:47, 22 May 2012 (UTC)
It's only happened several times, and not on all pages.  Liam987(talk) 17:50, 22 May 2012 (UTC)

Massive vertical break in Signpost News and notes display mode

I wonder whether anyone with the right technical expertise could respond to User:Dweller's query. Vagaries in display, especially concerning images vs. text, are a problem with the current WM software, and advice as to the options for minimising visual distortions would be most welcome. I see no distortion on my system, but that's not the point here. Thanks. Tony (talk) 14:26, 22 May 2012 (UTC)

Thanks Tony. I'm running IE 7.0 (though I wish I wasn't) if that's any help. --Dweller (talk) 14:48, 22 May 2012 (UTC)
Big gaps before files or section breaks are something I've often noticed when using IE7 recently - I don't remember it from a couple of years back, so it may be due to a recent change, but it's certainly not just you! No idea for a solution, sadly... Andrew Gray (talk) 22:21, 22 May 2012 (UTC)

Template:Playmate: rework or delete?

The template has simply stopped working. May be it's because Playboy.com has changed. But, whatever the reason is, the template either needs serious rebuilding or a total deletion. Otherwise it makes so sense. Aditya(talkcontribs) 17:56, 22 May 2012 (UTC)

Wikilinking to a subsection?

My apologies if this has been answered elsewhere and I'm simply unable to locate; I'm curious if and/or how one can create a wikilink to a sub-section ===3=== or lower? The syntax for doing so would be very appreciated. Thank you. Buddy23Lee (talk) 19:14, 22 May 2012 (UTC)

As long as the subsection name's is unique, you can append the section name after a "#" symbol in the name. For example, this section, I can wikilink as [[Wikipedia:Village pump (technical)#Wikilinking to a subsection?]] Alternatively, or if the title's not unique, you can use the template {{anchor}} right after the section header, which you can assign any name, and then link to that anchor name instead. So for example if you put {{anchor|this spot}} in the section you want to link to, you can then link to it via [[ThatPage#this spot]]. --MASEM (t) 19:23, 22 May 2012 (UTC)
And just adding that this is irregardless of how deep the header is; it is based on the textual content not the level of outline. --MASEM (t) 19:24, 22 May 2012 (UTC)
Thank you, the 'anchor' was exactly what I was looking for. :) Buddy23Lee (talk) 19:35, 22 May 2012 (UTC)
I think these days you have to encode punctuation, that test link of yours doesn't seem to work in my browser. - Jarry1250 [Deliberation needed] 21:03, 22 May 2012 (UTC)

Reviewing link bug

Hey, all. I just noticed a page review link or some annoying "This page has been reviewed" text at the bottom of a lot of pages. What gives? Is this part of the New Page Feed trial? --Nathan2055talk 00:10, 23 May 2012 (UTC)

Turning Sharebox into a gadget

We still get requests like this once in a while, so I think turning Sharebox into a WP:Gadget may be a good idea. Personally I strongly dislike Facebook, but that is just my POV. Please voice your opinion here. Arcandam (talk) 01:47, 23 May 2012 (UTC)

Headers

Up until yesterday, there was a drop-down menu to insert Headers (L1, L2, L3...). It wasn't there when I woke up this morning, I rubbed my eyes and thought I may still be dreaming. I've now had a strong black coffee and the drop-down menu is still missing. Can anyone tell me what's going on? --Ohconfucius ¡digame! 02:36, 23 May 2012 (UTC)

If you have Wikipedia:refToolbar 2.0 with a right pointing triangle at "Advanced" then click Advanced to see Heading and other options. PrimeHunter (talk) 03:44, 23 May 2012 (UTC)
THanks, that's what I was looking for. --Ohconfucius ¡digame! 04:46, 23 May 2012 (UTC)

Talk pages messed up for IE 7

I don't know what other users are seeing right, but IE 7 renders Talk pages as a mostly blank page, with only the section headers (and a few other things like sidebars) visible. The positioning of the top div element of the page seems to be off as well, overlapping text underneath. I suspect a CSS fault somewhere. Hopefully it's only my browser, but perhaps other users might be complaining. (Until this is fixed, I won't be able to read any responses here.) — Loadmaster (talk) 18:05, 22 May 2012 (UTC)

Why haven't you tried another browser then, instead of leaving us to guess what your problem is? --Aspro (talk) 20:50, 22 May 2012 (UTC)
I'm at work, where we are limited to only IE 7. — Loadmaster (talk) 15:58, 23 May 2012 (UTC)
I gave IE7 a quick spin; can't reproduce. Any specific pages you're seeing this on? Does it happen when you're logged out? Any errors reported by the browser? Any other odd behavior on other sites? Any suspicious-looking purple gorillas nearby?--Eloquence* 21:30, 22 May 2012 (UTC)
The problems seem to be gone now, so I'll guess that it was my browser and/or configuration. None of the article pages was affected, and only about half of the Talk pages seemed to be affected. The primary effects were: 1) the first box below the title line appeared to overlay text underneath; 2) the entire page contents did not load, stoppping somewhere at 50%–80% of the page; 3) only the section titles, tables, and images were visible, while none of the normal text was; 4) in the editing pages, most things were visible but some things like the symbol selection div were not. Like I said, the problem appears to be gone now (another day, another reboot), I suspect a local caching problem here on my company's side, but perhaps my experience can be useful to others in the future(?). — Loadmaster (talk) 15:58, 23 May 2012 (UTC)

Make it possible to show different content to different users

It would be nice to be able to show different content to different user groups (and possibly even individual users). Howzabout implementing that in wiki-syntax? The first proposed use would be to get rid of AIV backlog warning on the admin noticeboards for non admins... If this is better in bugzilla pleas say Egg Centric 16:43, 23 May 2012 (UTC)

I don't know if it's easy to detect if the current user is an admin, but conditionals exist in MediaWiki, we make a fair use of this set of conditions, for example. --joe deckertalk to me 18:25, 23 May 2012 (UTC)
Do you mean the class="sysop-show" from MediaWiki:Group-sysop.css and MediaWiki:Common.css? Helder 19:17, 23 May 2012 (UTC)

Fixing redirected pages

Is there a tool that can be used to sort out redirects? I need something that will work through the links in a page, and make the piped link point to a new address where the article has been moved to? So for example, at List of township-level divisions of Hebei, Longguan is piped to Longguan, Chicheng County; but as the article has now been moved to Longguan, Hebei, it's preferable for the pipe be so modified. [[Longguan, Chicheng County|Longuan]] will become [[Longguan, Hebei|Longuan]]. Cheers, --Ohconfucius ¡digame! 18:13, 23 May 2012 (UTC)

You should probably consider whether the changes you want to make are in accord with WP:NOTBROKEN, first. Happymelon 19:43, 23 May 2012 (UTC)
Yes, they are. I asked Ohconfucius to make these changes because many of the articles listed at that page will likely be deleted and re-created (see the ANI thread on User:Jaguar). Better to fix the links now and have the future re-creations at the WP:NC-ZH-compliant titles rather than leaving them as they are and forcing users like me to move them again. GotR Talk 21:29, 23 May 2012 (UTC)

Template:Split media

Is there a template like {{Split media - processed}} or {{Split media}} for non-free images? I've uploaded new versions of non-free files, and I'd like to request the deletion of the older versions. ▫ JohnnyMrNinja 21:50, 23 May 2012 (UTC)

Not sure exactly what you mean, but I think you might be looking for {{Orphaned non-free revisions}}. →Στc. 00:33, 24 May 2012 (UTC)
That's exactly it. I wouldn't have expected it would serve that function based on the name. Thank you. ▫ JohnnyMrNinja 01:39, 24 May 2012 (UTC)

REVISIONID

Sorry if this is in the wrong place. I recently made a request at Wikipedia:Bot requests/Archive 47#Link to a diff when clean-up tags are applied to provide a link to the diff when a cleanup tag was applied. It was suggested the {{REVISIONID}} magic word would accomplish this, but it doesn't seem to work. Maybe someone here knows a bit more about how to do this or can point me in the right direction. There might even be another way to accomplish the same thing. AIRcorn (talk) 01:04, 16 May 2012 (UTC)

I hope you realise that it only works after the page is saved, and updates after the page is edited each time, so you might want to substitute it.  Hazard-SJ  ✈  02:02, 16 May 2012 (UTC)
No I didn't. That won't really work as cleanup templates aren't substituted. Is there another way to link to the diff that added the template? AIRcorn (talk) 00:03, 17 May 2012 (UTC)
Can't one do something like {{tag|1=[urlpart{{subst:REVISIONID}} added in this edit]}}? Something more refined, obviously. But I still think it's doable. Killiondude (talk) 18:56, 17 May 2012 (UTC)
Yes this could have been done, unfortunately I am not allowed to do it. Rich Farmbrough, 01:22, 24 May 2012 (UTC).
I was trying to do something similar yesterday: creating a template like this for use like this? But didn't work, because the magic word returned an empty string (although I think in a previous MW version it used to return the id of the revision just saved). Helder 14:56, 24 May 2012 (UTC)

Template parsing

Has anyone created a function that can parse wikitext and return a template with its parameters? Alternatively, does an API query exist for that?

{
    "Template:X3":
    {
        "bla{h":"Hello!"
    }
}

Something like this, taken from https://en.wikipedia.org/w/index.php?title=Wikipedia:Sandbox&diff=prev&oldid=492475629

Στc. 04:16, 17 May 2012 (UTC)

You should be able to do that with Regex pretty easily I imagine. Could you give us a little more detailed description of what you are trying to do. It could just be me and my tired 1AM brain but its kinda unclear from the description what your trying to do. Kumioko (talk) 04:27, 17 May 2012 (UTC)
What I'm trying to do is capture a template from wikitext, that looks something like {{Foo|bar={{baz|b{oo=far}}}} Regex cannot be used for this purpose, because there are nested templates and uneven braces. So that leads to my question, is there already a method of extracting the template? →Στc. 05:19, 17 May 2012 (UTC)

Using regex is horrible, don't do it. It's like drugs; seems like a great idea at the time, but in the long run you end up with more problems than its worth. Even simple things like a link in the template (e.g. {{foo|[[bar|foobar]]}}), can break the regex unless it is very well written. Assuming you're using PHP, here is my hack of a solution to parsing templates:

Collapsed long code snippet, click "show" to the right
<?php
class template implements Iterator {
	private $name;
	private $params;
	private $pos;
	
	public function __construct ($name, $params) {
		$this->name = $name;
		if (empty($params)) {
			$this->params = array();
		} else {
			foreach ($params as $key => $value) {
				$this->params[] = array($key,$value);
			}
		}
		$this->pos = 0;
	}
	
	public function getByKey ($key) {
		if (!isset($this->params[$key]))
			return false;
		return $this->params[$key];
	}
	
	public function __toString () {
		return $this->name;
	}
	
	public function current () {
		return $this->params[$this->pos][1];
	}
	
	public function key () {
		return $this->params[$this->pos][0];
	}
	
	public function valid () {
		if (isset($this->params[$this->pos]))
			return true;
		return false;
	}
	
	public function rewind () {
		$this->pos = 0;
	}
	
	public function next () {
		$this->pos++;
	}
}

// Look, don't even bother and read this, just accept that it parses
// $text, and returns an array of templates.
// Yes, it is horrible in every possible way; but it works.
function parsetemplates ($text) {
	$text = str_split($text);
	$template_level = $args = 0;
	$template = $templates = array();
	$ignore_next_char = $in_link = false;
	$arg_name = null;
	
	for ($i=0;$i<count($text);$i++) {
		$prev = $text[($i - 1)];
		$next = $text[($i + 1)];
		$char = $text[$i];
		if ($char=='[' && $prev == '[') {
			$in_link = true;
		} elseif ($char==']' && $next == ']') {
			$in_link = false;
		}
		if ($char=='{' && $prev == '{') {
			$template_level++;
			if ($template_level==1) {
				$start = $i;
				$code = '{{';
				continue;
			}
		} elseif ($char=='}' && $next == '}' && !$ignore_next_char) {
			$template_level--;
			$ignore_next_char = true;
			if ($template_level==0) {
				$args = 0;
				$code .= '}}';
				$template['name'] = trim($template['name']);
				$tmp_args = array();
				if (!empty($template['args'])) {
					foreach ($template['args'] as $tArg) {
						$tmp_args[] = trim($tArg);
					}
				}
				$templates[] = new template($template['name'],$template['args']);
				$template = array();
				continue;
			}
		} elseif ($ignore_next_char) {
			$ignore_next_char = false;
		}
		if ($template_level==1) {
			$code .= $char;
			if ($char=='|' && !$in_link) {
				$args++;
				$arg_name = null;
				continue;
			} elseif ($char=='='  && $arg_name==null) {
				$arg_name = $template['args'][$args];
				unset($template['args'][$args]);
				continue;
			}
			if ($args==0) {
				$template['name'] .= $cont.$char;
			} elseif ($arg_name!=null) {
				$template['args'][$arg_name] .= $cont.$char;
			} else {
				$template['args'][$args] .= $cont.$char;
			}
			$cont = '';
		} elseif ($template_level > 1) {
			$cont .= $char;
			$code .= $char;
		}
	}
	return $templates;
}
?>

It runs like so:

<?php
$templates = parsetemplates($wikicode); // Returns an array of template objects
foreach ($templates as $template) {
        echo "$template\n"; // The name of the template
        foreach ($template as $argument => $value) {
              echo "\t\"$argument\" => \"$value\"\n";
        }
}

I wrote parsetemplates() one night, very late when I was frustated by this exact problem. It's a horrible function, but, it works for all the wikicode i've encountered so far. That said, try not to find anything that breaks it ;) --Chris 07:15, 17 May 2012 (UTC)

That's a fun piece of code. Haven't tested it at all, but it looks like it doesn't handle template parameters ({{{param_name|default}}}, etc), although I guess that's not a common sight on article pages. More generally I think it won't like multiple sets of braces put together; things like {{template|foo={{bar}}}} or especially {{{{WorkOutWhichTemplateToCall}}|foo=bar}} will make it go in or out too many levels. Also image captions can contain links: [[File:Foo.jpg|thumb|This caption [[contains a|link]] which confuses things]]. But a valiant effort nonetheless! :D Happymelon 14:03, 17 May 2012 (UTC)
It deliberately doesn't deal with template parameters, it's just way too ugly (and lets face it, if you're trying to parse actual templates, you're going to need something beefier than this, that can handle all the parser functions etc). Image captions with links it can deal with, and {{template|foo={{bar}}}} is also fine (I actually wrote it specifically for that purpose, so that I could parse templates that have templates as arguments). However, you are right {{{{WorkOutWhichTemplateToCall}}|foo=bar}} doesn't work. Damn. --Chris 16:30, 17 May 2012 (UTC)
Actually, strike that about the images with captions. This version can't deal with them (although your example does work, this code [[File:Foo.jpg|thumb|This caption [[contains a|link]] which confuses things|right]] doesn't). I have a different version that does actually deal with that problem, however it breaks with other things, and is not ready for primetime yet. --Chris 16:50, 17 May 2012 (UTC)
I have similar code (but in Perl) at User:AnomieBOT/source/d/Templates.pm. My version uses a callback architecture, so giving it {{foo|{{bar}}}} will call the callback for bar and then for foo, and the callback can return new wikitext to directly replace the template if desired. It also tries to handle <nowiki>, <ref>, and so on in a reasonable manner. Anomie 01:52, 18 May 2012 (UTC)

Thank you for your ingenious solutions to this problem. →Στc. 03:37, 19 May 2012 (UTC)

There is a solution for this in PerlFAQ, number 6, I think. Rich Farmbrough, 14:29, 24 May 2012 (UTC).

Template talk:NDB

The website of the Neue Deutsche Biographie changed and that ruined the template is it possible to change it from [15] to [16]? Thanks — Preceding unsigned comment added by Stone (talkcontribs) 08:50, 22 May 2012‎ (UTC)

German Wikipedia already updated theirs, so I copied their code over here. Let me know if there are any problems, I'm still checking through some transclusions. Equazcion (talk) 09:01, 22 May 2012 (UTC)
Some links don't appear to be working this way. I don't know enough about this to fix it (or to tell if the invocations are wrong). Could someone else have a look? {{NDB}}, German version is here: http://de.wikipedia.org/wiki/Vorlage:NDB. Equazcion (talk) 09:14, 22 May 2012 (UTC)
I reverted and tried just changing the URL prefix but that doesn't seem to be working either. See Andreas Schlüter, Daniel Gabriel Fahrenheit. Equazcion (talk) 09:31, 22 May 2012 (UTC)
I also tried it in the sandbox but I could not get it to work, this is why I turned here.--Stone (talk) 12:21, 22 May 2012 (UTC)

Fix a url in a template

Is here nobody capable to fix the url in the Template talk:NDB? If not who is the person for that job? Thanks.--Stone (talk) 08:21, 23 May 2012 (UTC)

I've looked at Template talk:NDB and I see no problem. What is wrong with it? --Redrose64 (talk) 09:25, 24 May 2012 (UTC)
I don't know why Stone mentions the unused talk page. The post refers to an issue with Template:NDB, mentioned above in #Template talk:NDB. PrimeHunter (talk) 11:26, 24 May 2012 (UTC)
The problem is not necessarily with Template:NDB (the German template being de:Vorlage:NDB) - it might lie in the subtemplates. There are two which are used to build portions of the URL, these are Template:ADB/MDZ-ID and Template:ADB/Nativeno - the German equivalents are de:Vorlage:NDB/MDZ-ID and de:Vorlage:NDB/Seite. Even if we ignore the fact that the string 0001/bsb000 is in the main template at en.wp but a subtemplate at de.wp, we see that the numbers generated by the subtemplates are very different. --Redrose64 (talk) 14:07, 24 May 2012 (UTC)
Possible red herring, but I notice that the German template de:Vorlage:NDB uses subtemplates de:Vorlage:NDB/MDZ-ID and de:Vorlage:NDB/Seite, whereas the English template Template:NDB uses subtemplates Template:ADB/MDZ-ID and Template:ADB/Nativeno even though Template:NDB/MDZ-ID and Template:NDB/Nativeno exist. DH85868993 (talk) 16:36, 24 May 2012 (UTC)
I think I got it now. I copied the German code again, but only copied the code within the link this time. For some reason this seems to have worked -- and on checking the resulting diff, Redrose and DH's observation seems to have been the issue. Post back if there are still problems. Equazcion (talk) 17:02, 24 May 2012 (UTC)

Database lag

Lag has been increasing steadily for the past hour or two. It's currently at 736 seconds. Equazcion (talk) 15:50, 22 May 2012 (UTC)

Someone had been pegging our API servers with requests, causing a replication lag on db12 (contributions). The offender has been blocked now, replag seems to be dropping. Max Semenik (talk) 15:59, 22 May 2012 (UTC)
I see it is indeed dropping now. Thanks for the quick info :) Equazcion (talk) 16:03, 22 May 2012 (UTC)
Ummm, didn't stay dropping for long, continuing to poke up: [17], 12806s. --joe deckertalk to me 05:28, 23 May 2012 (UTC)
  • The problem seems to be continuing, and not getting any better, at least for me. It's really difficult to pull up my watchlist or any edit histories. --Tryptofish (talk) 21:45, 23 May 2012 (UTC)
According to #wikimedia-tech, it was apparently the same server today that was causing the problem yesterday. It's an older machine that just isn't up to serving en.wp, so it has been removed from duty until it is replaced in a few weeks.[18] ​—DoRD (talk)​ 22:47, 23 May 2012 (UTC)
Thanks. It's much better now. --Tryptofish (talk) 23:08, 23 May 2012 (UTC)
Yep, it's hell getting old...even for computers, I suppose ;) ​—DoRD (talk)​ 13:07, 24 May 2012 (UTC)

Watchlist gremlins

I sought help for this issue at the WP:Help Desk, but to no avail. Recently, I've been experiencing intermittent disappearances of entries when I display my watchlist. In other words, I have an article on my watchlist, but when I display the watchlist, the most recent edit to it doesn't show up, even though it happened in the time frame my watchlist displays. Then, usually, some time later, it starts showing up again for no apparent reason. It's baffling. Also, it's disturbing because I have a lot of pages on my watchlist, and it's hard to notice the absence of an entry, so, for all I know, this is happening more often than I'm aware of.--Bbb23 (talk) 22:34, 23 May 2012 (UTC)

At the top of my watchlist, I have "Hide minor edits | Show bots | Hide anonymous users | Hide logged-in users | Hide my edits | Hide patrolled edits". What do you have there? - Jarry1250 [Deliberation needed] 23:10, 23 May 2012 (UTC)
Hide minor edits | Show bots | Hide anonymous users | Hide logged-in users | Hide my edits | Hide patrolled edits --Bbb23 (talk) 23:19, 23 May 2012 (UTC)
Your question raised a question for me. I have Show bots above. That means it hides any edits by bots. Does that also mean that if the last edit was by a bot, it won't show the edit just before the bot edit, i.e., it shows nothing?--Bbb23 (talk) 23:25, 23 May 2012 (UTC)
Exactly. That's why I posted this to your original question at Wikipedia:Help desk#Watchlist: "Make sure you are not hiding some entries at Special:Preferences#mw-prefsection-watchlist". It appears you ignored that and instead came here claiming you didn't get help at the help desk. PrimeHunter (talk) 00:03, 24 May 2012 (UTC)
My apologies. I didn't "ignore" it, though, I failed to look before I came here and mistakenly thought the last edit to the topic was the one before yours. Still, my fault for not checking. That explains it perfectly because I recently changed that setting. I don't suppose there's a way to hide bot edits but still see the latest non-bot edit? And to expand on my apology at the risk of sounding fawning, I almost always get the help I need at the help desk. It is hands down my favorite place on Wikipedia.--Bbb23 (talk) 00:09, 24 May 2012 (UTC)
Sorry if I sounded harsh. I don't think you can hide some types of edits and still see the latest edit not of those types. bugzilla:9790 is about it. Hiding works better if you choose "Expand watchlist to show all changes, not just the most recent" at Special:Preferences#mw-prefsection-watchlist. See Help:Watching pages#Options. PrimeHunter (talk) 00:31, 24 May 2012 (UTC)
Yes you can. There is a kickass script that does this - and more - courtesy of User:Uncle Douggie. WP:HIDEBOTS for details. Rich Farmbrough, 15:55, 24 May 2012 (UTC).

files in wikipedia and commons with same name

I was trying to add an image from the commons to Recanati winery, only to discover that there was an identically named image in wikipedia, which is obviously the image that was displayed. (They were different pictures). I managed to resolve the issue by requesting a file rename for the image in the commons which was approved, although this broke the file's usages in other wikipedias which I had to go fix manually. I feel like there must be a better way. Is there a way to link directly to the commons, ignoring files in the local wikipedia? --Bachrach44 (talk) 06:28, 24 May 2012 (UTC)

No, there isn't: the same syntax is used whether the image is on the local wikipedia or on commons - the MediaWiki parser looks locally first, and then on commons.
Generally, where there is a filename clash, it's best to rename the local image, not the one on commons, because there is likely to be much less work involved. --Redrose64 (talk) 09:21, 24 May 2012 (UTC)
Thanks for the info. I'll take your advice next time. --Bachrach44 (talk) 10:01, 24 May 2012 (UTC)

Yet MORE idiocy thrust on us?

I imagine this is part of the "MediaWiki 1.20wmf3 deployment" but seriously, whose bright idea was it to change the title page when looking at DIFFs to 'Difference between revisions of "(X)"'? I mean, are people TRYING to drive out editors in droves by making stupid and ugly interface changes that just make things worse? ♫ Melodia Chaconne ♫ (talk) 22:07, 21 May 2012 (UTC)

Meh, I quite like it (why so much hate?). Also it changes the title tag (displayed in your tabs) to make it more obvious which tabs are diffs and which aren't. It's quite clearly a more informative title that what preceded it, anyhow. Ugly, maybe, but certainly more functional (i.e. hardly "stupid", IMHO). It was bug #33928, by the way. - Jarry1250 [Deliberation needed] 22:41, 21 May 2012 (UTC)
I think the important thing here is that we continue to oppose every single change that ever happens to the interface with a response that is out-of-proportion with the change itself. Indeed, it is important to keep in mind that the developers are purposely trying to make Mediawiki worse so that people will no longer want to contribute to Wikipedia, and we also need to keep in mind that there is no such thing as a good change. Change is always for the worst, and for that reason we must oppose it, and we must also use inflamatory language and act far more personally incensed than we have the right to be. Or maybe we shouldn't do that. --Jayron32 23:06, 21 May 2012 (UTC)
This change was also discussed on commons, and an improvement made as a result. Specifically, Amir is changing it so that the title of the article will precede the explanatory text. That should roll out with 1.20wmf4, which is due in two weeks. -- RobLa-WMF (talk) 00:09, 22 May 2012 (UTC)
Per Jayron32: We must also oppose editors editing articles in a manner that changes something that previously existed, because the prior state will then only exist in the article history. We must not allow editors to edit articles such that the prior intent of an earlier editor is overridden. Previous editors know better than current editors, so established revisions of articles must always be retained. Nothing must ever be lost if someone put it in an article before someone else got there. Assume that previous editors were right and that anyone who makes a change, has made a mistake. See also: Happy-melon and Jorm (below); such technical people should be restricted to code they can develop by carving wood with chisels so that everyone can have a chance of understanding it. Change is bad; usually blockably so. Br'er Rabbit (talk) 09:19, 23 May 2012 (UTC)
What Jayron said. The horrific technological inertia that is developing within the community is only going to lead to two possible outcomes (or some even-less-sustainable combination of the two). Either the developers abandon any hope of satisfying the community and stop bothering to even try to engage with it, or they stop trying to develop beneficial features at all. Either approach has only downsides and (ironically) even less chance of the issues the community genuinely feels strongly about being addressed. Is making such a strong statement about the change of the title of a non-reader-facing page really proportionate? Happymelon 00:17, 22 May 2012 (UTC)
^This.--Jorm (WMF) (talk) 00:22, 22 May 2012 (UTC)
Well it was quite a shock, and as it's something I have to look at many times a day it's jarring. Right now I have seven tabs that say "Difference betw..." on them. No idea which is which, so how can I know which are likely to be quick checks and while I want to save until the end to spend more time of them? If the article name will be moved to the front, I guess that solves that issue, at least. But what's the point of it anyway? It's completely redundant driven by the fact that the grey and green is above the article, which means that it's very easy to glance and see it's a diff in the first place. ♫ Melodia Chaconne ♫ (talk) 01:34, 22 May 2012 (UTC)
When editing or moving pages, the page title changes to "Editting (x)" or "Move (x)", similar to the way DIFFs are currently titled. Were there any complaints about it? If you are viewing several editors contributions at once, it has been difficult to distinguish them by tabs alone because they are titled "User contributions of (User name)". Do you wish them to be changed as well? Or new ones (DIFFs) only? --Kusunose 02:41, 22 May 2012 (UTC)
You know, we can easily change this by editing the appropriate MediaWiki-namespace page. I've taken the liberty of changing MediaWiki:history-title, MediaWiki:difference-title, and MediaWiki:difference-title-multipage to match the change linked above by RobLa-WMF (please delete those pages when 1.20wmf4 is live). Also, I agree with Happy-melon above. Anomie 02:54, 22 May 2012 (UTC)
Thanks, I just noticed that change. It's much better to have the article title first as that is what is important, and it's the only thing visible when have many tabs. Johnuniq (talk) 03:08, 22 May 2012 (UTC)
The point previously made about mistaking "Revision history" for part of the title (in this new version, where the quotes are removed and the page action put after the title, separated by a colon) - is a good point. Which is one of the reasons I very much dislike this re-ordered construction, entirely. To make tabbed browsing easier, We normally use a reversed breadcrumb in the page title (Action < Page name < Site name). Up until now that was the case for all actions and special pages. But this is now broken for Diff and History. For example, right now I see tabs "Editing User:Kr..", "My Watchlist - W..", "Wikipedia:Villag..", "Wikipedia:Villag.." and "Wikipedia:Villag..". I can't tell which of these last three is view, Diff or History. Now one could make a similar point when saying you have tabs "Difference ..", "Difference .." and "Difference ..". So I doubt there is really much of a gain for either. But whatever the case, consistency throughout the interface is most important. And right now these "Diff" and "History" are inconsistent with all other titles, because those titles (Edit, Move, Delete, View source, What links here, ...) all put the action first and quote the page title (which has so far always prevented most confusion about which part the page name is). Krinkle (talk) 03:18, 25 May 2012 (UTC)
How many different types of views are there? I have no clue what type of work it takes to change stuff like this, but do we need 'Difference between revisions' instead of just 'Diff' or even just 'D'? 'Hist' or 'H' instead of 'Revision history'? I'd think we could come up with some system that would allow several tabs to be up at once showing what type of view and for which page at the same time. Do we need such long descriptions? --OnoremDil 04:23, 25 May 2012 (UTC)
Remember that we want the titles to be transparent to new users as well. "D" and "H" certainly don't fit that bill. Anomie 11:36, 25 May 2012 (UTC)
Beyond all that, it really breaks my brain sometimes. I keep thinking "Difference between revisions" is part of the title. But once again, I ask what the POINT of it is in the first place? It's 100% clear that it's a diff by virtue of the extra stuff at the to[p so why is a title change even needed? As for history, that's also become very annoying for reasons said above. If I have a bunch of tabs open I can't tell which I've clicked the history tab for -- and it seems odd because history pages aren't the article. I shudder to think this will change for editing and moving too. And yeesh, how about talk? That's a tab too. Imagine if the title said, say, "Peanut:Talk" at the top instead of "Talk:Peanut" . Is there ANY possible way to remove it from the diff pages and switch it back on the history pages? ♫ Melodia Chaconne ♫ (talk) 13:19, 25 May 2012 (UTC)
I have the same brain breakage with the diff pages. OTOH, I've long used a small script to remove the "Revision history of" bit on history pages for the same reason the devs changed the default message now: lots of tabs all saying "Revision his..." are useless. There is a way to change both messages: get consensus and we can edit the appropriate MediaWiki-namespace pages to say whatever we want. Or use a script to rewrite the page title and <h1> tags on history and diff pages, if you can't get consensus to change it for everyone. Anomie 16:31, 25 May 2012 (UTC)
I wanted to respond to Happy-Melon's remarks. I don't really see anything wrong with this particular change FYI. However, as someone who participates at VP Proposals and basically always has, I'd just like to point out that the developers would probably find themselves getting better responses if they worked on changes the community has been requesting. Realizing full-well that they're mostly volunteers and can spend their time the way they like, I think a better job could be done in encouraging development of what the community wants, rather than their own whims regarding what is best for the community. They've become a little too comfortable with the latter over the years for my taste, and it would appear I'm not alone in feeling that. Most rights-wielding users have been more-or-less trained to be sensitive to the fact that their privileges are only there to serve the community's decisions. I feel this much less from developers. Perhaps it's a disconnect that started with the use of bugzilla, a forum outside of Wikipedia, where development business is discussed outside the purview of the average user (even most non-average users). The argument could be made that that's a good thing, and certainly that bugzilla's features are more conducive to development talk. I just don't know if keeping things status-quo is worth risking the kind of breakdown Happy-Melon describes, which does seem plausible. Equazcion (talk) 04:35, 22 May 2012 (UTC)
Huh? This was a community requested change, not a developer "whim" about what's best for the community. In fact pretty much all of the development projects that are going on right now are community requested (visual editor, new templating system, PageTriage, etc.), mostly from the English Wikipedia community. In fact, we do so much development specifically for the English Wikipedia community that the other languages and projects are often upset at being neglected. I agree that Bugzilla isn't ideal, but it's much more efficient than hanging out on the Village Pump all day ;) Kaldari (talk) 05:42, 22 May 2012 (UTC)
I was speaking more in general terms, but if you could point me to the discussion on this change, that might help. Surprised you'd bring up triage though, considering that was hardly the community's first choice. I wasn't prescribing any particular solution, least of which handing development discussions entirely over to VP. But if you want idea seeds: Some sort of automated cross-posting of promising bugs to a page that doesn't require a separate login from Wikipedia; or some sort of "transclusion" of them here, as it were (have a page here read their database). More communication, more visibility, more accountability. Creation-of and adherence-to a policy on Wikipedia for proposing, discussing, and implementing interface changes that affect Wikipedia's defaults. That's just off the top of my head. Equazcion (talk) 06:00, 22 May 2012 (UTC)
Except from en.wikipedia isn't the only MediaWiki wiki, so having MediaWiki development discussions here isn't really the best option. Having an external forum from any particular implementation of MediaWiki is actually quite important, in my opinion. And there is no reason why the MediaWiki developers should have to follow some policy the community on Wikipedia make up for them. - Kingpin13 (talk) 07:34, 22 May 2012 (UTC)
As far as I'm concerned, the developers can feel free to make whatever MediaWiki changes they want, with the notable caveat that anything default is disabled on Wikipedia until the community agrees to it via a process. Equazcion (talk) 07:36, 22 May 2012 (UTC)
Addendum: I'm not claiming to have all the answers. Nevertheless, Happy-Melon brought up a valid point. Whether or not you agree that people's reactions are justified in these situations, we can't change the way people react just by telling them they should be reacting differently. Why not attempt to address this issue in a way that has a chance of improving it? I'm open to suggestions, but considering there is an incongruence between MediaWiki's development as standalone software vs. its effects on a website purported to be run by a very large community whose interests may differ, I think discussing a policy governing the way MediaWiki changes affects Wikipedia could be a good start. Equazcion (talk) 07:50, 22 May 2012 (UTC)
"And there is no reason why the MediaWiki developers should have to follow some policy the community on Wikipedia make" is exactly the sort of attitude which is giving rise to the frequent and voluminous complaints about changes to the MW software, interface etc. The general feeling is that someone suggests a change, a small coterie of editors agree with the principle without adequately thrashing out the practical, implementation and other issues, and it appears the developers then go ahead on exactly the same basis, and as if "the community" has given carte blanche. Then they recoil in horror when "the community" rejects the change loudly the moment such change 'goes live'. I'm not suggesting the everything needs to have the same degree of community approval, nor that I am unhappy about the subject of this particular discussion. Crux is that editors feel the developers are acting without accountability. The best recent example is the bolding applied to the Watchlist. Of course, it makes little sense to discuss these solely on en.wp as development changes affect other wikis. but the current process (cycle of request–development–trial–roll-out) is not working properly right now, because there is currently no such procedure. --Ohconfucius ¡digame! 08:11, 22 May 2012 (UTC)

"the developers can feel free to make whatever MediaWiki changes they want, with the notable caveat that anything default is disabled on Wikipedia until the community agrees to it via a process"

We should make that official policy. (No, I am not kidding, those green stars that popped up on my watchlist recently and of which I (fortunately) got rid is a strong argument in favor of that). -- Toshio Yamaguchi (tlkctb) 07:56, 22 May 2012 (UTC)

  1. The green stars were not a change in MediaWiki, but on English Wikipedia itself.
  2. Anyone can bookmark a bugzilla query which generates a list of recently fixed (or opened) bugs (check e.g. 130 created during the last week or these 33 bugs fixed during the last month). Then, it is easy to check periodically and mention here on VP any request which seems controversial for the English wikipedia (e.g.: in case it was a request of one of the many other WMF wikis, which may happen to have different needs from enwiki), in order to have more discussion prior to "fixing" the bug.
  3. I think it is even possible for someone which the appropriate knowledge to write a bot to check bugzilla periodically and list the recent bugs in a Wikipedia page, so that people can watch it without leaving the wiki (there is also a MW extension for this: mw:Extension:Bugzilla Reports). Helder 12:55, 22 May 2012 (UTC)
  1. The preceding change that resulted in the backlash that preceded the rash move to green stars was the result of a developer move to change a MediaWiki config option for Wikipedia. It makes little difference either way. That that change could occur the way it did, and the backlash, were the result of a lack of governance of interface changes.
  2. You're saying users here can keep an eye on bugzilla if they want. That incurs the same problem. The ones who would take that upon themselves aren't the ones whose reactions we're looking to deal with here.
  3. This one sounds like a good start. But only a start. Equazcion (talk) 13:10, 22 May 2012 (UTC)
I think this really boils down to giving users a choice whether they want certain changes to apply or not, at least initially. In most cases it would be relatively easily to allow the user to check a box or uncheck a box for a given function to apply. If the user wants it great and if not thats ok too. Changes are notoriously hard to implement in WP for Anything but generally better accepted if its opt in or out based on the user. Lets remember that Users are different and I mean this in no derogetory way but some can see better than others, some see colors different, some have trouble reading certain fonts and some of us like things a certain way and once we are used to it get rather irritated when it changes. Same applies here. Kumioko (talk) 14:00, 22 May 2012 (UTC)
Surely the standard option should be the basic, with users able to add whatever embellishments they choose, whereas currently I, and many other users, have to use code to turn things off. This gives longer refresh times and annoying jumps - e.g when the "Mark all pages visited" button initially appears, and then disappears. This is particularly pronounced and frustrating with a poor connection. Presumably this "provide then hide" also adds to the server load, slowing the system down for everyone. The developers seem to have forgotten the KISS principle. Arjayay (talk) 14:26, 22 May 2012 (UTC)
The "KISS principle" apparently does not mean what you think it means, if you think adding a user preference and much conditional code is somehow simpler than just enabling the feature and allowing people to override it with styling. Also note that this "provide then hide" probably adds less to the server load than would "don't provide then issue extra requests to load it extra" would. Anomie 15:34, 22 May 2012 (UTC)
@Kumioko: Had people not jumped the gun and disabled the bolding for everyone, we'd certainly have a gadget by now that disabled it with a single checkbox click, and then people who wanted different styling could start from either state in their personal CSS. But as it is, we've got the incomplete hiding in the site-wide CSS and massive arguments over whether it should be shown again and how exactly it should look that we'd now need 7 or 8 checkboxes to turn on each of the different style options to satisfy people. Anomie 15:34, 22 May 2012 (UTC)
@Equazcion: Recall that the enabling of this feature was overwhelmingly requested at VPR among people who bothered to comment. What "governance" do you imagine that would avoid the "Oh noes! I can't abide change!" comments from people who didn't bother with the original discussion? Anomie 15:34, 22 May 2012 (UTC)
It would appear "overwhelmingly" is a subjective term. The response following the change was noticeably more "overwhelming" than the proposal discussion, which got 20 support votes -- some of which included the condition that a preference setting for toggling the feature accompany its implementation, which was ignored. I've outlined above some ideas for "governance". Equazcion (talk) 15:47, 22 May 2012 (UTC)

So back to the topic at hand, while the header has been switched, it's AlSO been switched on the revision history page...so is there any way to make it go back to old behavior with CSS? ♫ Melodia Chaconne ♫ (talk) 13:31, 22 May 2012 (UTC)

Where on history pages do you see this? Equazcion (talk) 14:14, 22 May 2012 (UTC)
If you're talking about that the history page titles changing from "Revision history of "$1"" to "$1: Revision history", that change was coming anyway in 1.20wmf4. It can of course be changed back (or to something else), but is there a reason besides "Oh noes! I can't abide change!"? Anomie 15:34, 22 May 2012 (UTC)

It is ironic:

  1. First English Wikipedia users request the feature to be enabled (me included);
  2. Then in order to get that the feature on enwiki, it has to be disabled other wikis where it was already in use for years, causing complains for ~one week.
  3. After that, the feature gets enabled and enwiki just "disable" it locally again...

Helder 18:28, 22 May 2012 (UTC)

break 1

Yeah, it's been almost 4 weeks since I flipped and called it quits on en.wp. Disappointing that the first time I dare to open VPT again, I find the exact same problem. This confirms my conviction that I should no longer spend time on this community as a developer/editor. Stuff like this is supposed to be fun and interesting. When it starts becoming so much of a frustration, I'd better steer clear of it. —TheDJ (talkcontribs) 18:43, 22 May 2012 (UTC)

The whole idea that every user and wiki should be able to opt out of every single change to MediaWiki is why doing any sort of development takes ages. Not only do we have to make sure that our software works in 200+ languages (including right-to-left), but we also have to make sure that it works in all the ancient MediaWiki skins, that it supports all 3 versions of the editing interface (old, older, and oldest), that if the user disables any dependencies or JavaScript it degrades gracefully, and we even have community members demanding that all features work in text-only browsers. Frankly, it's a miracle that any changes to MediaWiki ever actually get deployed. And for the record, we try really hard to get community feedback before changes are deployed (with some notable failures). Most of the development teams do weekly IRC office hours, and spend a huge amount of time responding to bugzilla threads, listserv threads, and on-wiki threads discussing ideas for features. And we devote special attention to English Wikipedia in particular: frequently advertising projects on the Signpost and Village pumps. And that's just what we do publicly. We spend inordinate amounts of time discussing community feedback and potential community reaction to features in development meetings, often skyping or IRCing with community members for real-time feedback on ideas. And for all our efforts, we still get chewed out for every single change without fail. I'm not saying the community isn't entitled to griping about the process, but you should realize it's a 2-way street, and both sides should work towards better collaboration. Demanding that all changes be opt-in or that all MediaWiki-related discussions happen on en.wiki isn't realistic or helpful. And calling our work "idiocy" isn't going to make developers take community input more seriously. Kaldari (talk) 19:27, 22 May 2012 (UTC)
I feel your pain and my heart bleeds for you. I'm only being partially sarcastic. Nevertheless, if you think telling people about this here is going to solve the problem, you're being very optimistic. This thread did become the recent developments complaint discussion, though my comment that more or less began it was to address something more fundamental. The issue you and DJ outline is the problem. Evidently, if you're trying really hard to get community feedback, the current system apparently limits your ability to do that, to the point that your changes still don't reflect the community's wishes -- or they hate them because they still didn't know they were coming, but either way it makes no difference. We have a problem, whether or not your intentions and efforts are noble. Maybe we should look for ways to address it. Equazcion (talk) 19:40, 22 May 2012 (UTC)
I'm all for that. Right now, there are so many different venues for discussion it's rather unmanagable. I also think one of the big problems is that we have a very hard time getting people to beta test things for us. We usually have working prototypes of new features up on test.wiki or one of the prototype wikis weeks before they are deployed to en.wiki, but it seems no matter where we advertise it, we generally only get significant community feedback after the features are deployed. When I was first hired, I pushed for getting more of our work covered in the Signpost, which I think has had some positive impact, but not a lot. We've also started using "community liasons" for projects, which I also think has had some success. Of course part of the problem is none of these solutions scale well to 800+ projects. I'm interested in more ideas though. Kaldari (talk) 20:04, 22 May 2012 (UTC)
I suggested a Vector Beta skin somewhere above (if it hasn't been archived yet) where changes could be tested by the community simply by switching skins. Advertising of changes could be done via watchlist notices. Feedback could be handled via a newly-created forum here. Equazcion (talk) 20:09, 22 May 2012 (UTC)

Obviously, the current situation isn't satisfying for either side, developers and editors alike. Many users including me have expressed a lack of communication between the two sides, and obviously we need to think about how to improve this. We cannot expect developers to monitor all our village pump discussions, and many of us don't even know where to look and comment on the progress of the MediaWiki development. Sure, there are the occasional Signpost notifications, but they often read like "beware, we are gonna deploy this new feature soon, whether you like it or not". I still don't understand why the new diff scheme got deployed after all the opposition it received when we were still at MW 1.18, and then when it eventually was made available as an opt-in in MW 1.19 that option was taken away with the latest version. What I expect is something like a 3-step process:

  1. Developers notifying the community on a central page which new features are going to be implemented, with the possibility for the community to comment on these changes. The notification page could be at mediawiki.org, but some means (e.g., a bot) would be needed to forward notifications to a page on the English Wikipedia (unless we get global watch list functionality). Discussions can take place at the mediawiki.org page. Notifications replicated at the en.wiki page include feature requests (and bug reports) submitted via Bugzilla, using mw:Extension:Bugzilla Reports as suggested above.
  2. Prior to the mass deployment of a new MW release, it is installed locally at mediawiki.org (or maybe some Wikimedia Labs space?), and the community gets notified, having the ability to provide feedback for fine-tuning the new version as well as to catch some late bugs.
  3. Mass deployment of the new MW release.

Does that approach sound sensible? Is it implementable? Nageh (talk) 20:12, 22 May 2012 (UTC) (PS: I see that some of the ideas have already been thrown up in the discussions immediately above. Nageh (talk) 20:17, 22 May 2012 (UTC))

Re testing: I pointed out a blocking bug in the new math extension prior to the deployment of MW 1.20wmf1, yet it was ignored and I still don't get any feedback by MW developers. So testing alone isn't sufficient when developers don't care. Nageh (talk) 20:19, 22 May 2012 (UTC)

Comment Why can't we just have one page here on en.wiki where significant changes to MediaWiki or Wikipedia are announced beforehand? Why can't changes be rolled out on some test Wiki first and only later being deployed on en.wiki? If we already have one of those two or both then I must have missed that. -- Toshio Yamaguchi (tlkctb) 20:29, 22 May 2012 (UTC)

MediaWiki deployments to the WMF cluster go through about four generations of testing before they are deployed to enwiki, usually consisting of [19], [20], then deployment to [21], then one or two tranches of other WMF wikis (for 1.20wmf3, all 121 wikibooks wikis), before finally hitting enwiki. I don't think it's a generalisation to say that most enwiki editors missed that entire process, simply because they do not generally have cause to look outside enwiki (and of course there's no reason why they should).
In terms of your first comment, remember that context and ask why enwiki is more deserving of notifications than any of those 124 other sites. Of course it is, and as Ryan says above, substantially more effort is put in to engaging with enwiki than other communities. The WMF sysadmins, and MediaWiki developers, are certainly happy to work to make that engagement more efficient and effective; but enwiki is far from the sole community deserving of their time, and the extent to which many enwiki users think it should be, is stretching many developers' patience. Happymelon 20:54, 22 May 2012 (UTC)
I think a single notification page that could be watched would already be a huge step forward. Some way to provide feedback would be needed as well. Nageh (talk) 21:04, 22 May 2012 (UTC)
I think so too, because although such notifications are already made, they are made to VPT and it's clear that that is not being effective at spreading the word to those that want to know. But it is important that whereever such notifications are made, that venue is clearly laid out and well-publicised, which is where the discussion Equazcion exhorts above is needed. A comprehensive discussion amongst the enwiki community about how it wants to best organise its interaction with the MediaWiki community, would certainly have the full support of said MediaWiki community. Happymelon 21:09, 22 May 2012 (UTC)
"I think a single notification page that could be watched would already be a huge step forward."
  Like -- Toshio Yamaguchi (tlkctb) 10:25, 23 May 2012 (UTC)

break 2

I wasn't going to participate any further in this discussion, in the same vein as DJ; but Equazcion's comments above have reassured me that some sort of coherent discussion is possible. I think a very large number of people here don't have a clear awareness of how much less 'important' the English Wikipedia is in the community of MediaWiki wikis than they think it is. We can track from only the public internet nearly 40,000 separate MediaWiki instances, comprising a quarter of a billion pages and 63 million users; that's not including an unknown number of corporate internal wikis each with potentially entire workforces as users. Enwiki claims less than 6% of the total MediaWiki article count and somewhere in the region of 2% of its userbase (the proportion of active users on enwiki, at 0.8%, is vastly lower than the MW average, which is something like 12%). Is enwiki the single largest wiki in the community? Yes, obviously, and that's unlikely to ever change. Is enwiki larger even than the next two put together? No; enwikt and frwikt have more articles between them. The top four non-WMF wikis have both more articles, and more active users, than enwiki.

Everyone in this community badly needs to wake up to the fact that enwiki isn't the centre of the MediaWiki universe, and hasn't been for for years. And not only is it not the centre of the universe, it's not even close; I think many people believe that enwiki is the 'large minority', when in fact it is only a small slice of the WMF wikis, and an even smaller slice of the entire community. In actual fact, enwiki probably gets substantially more attention than it strictly deserves; out of precedent; the fact that the majority of developers are English speaking; and yes, the fact that enwiki is the most vocal and voluminous proponent of MediaWiki developments.

Broadly, it's a mistake to think that enwiki inherently 'deserves' any significant control over developments to the MediaWiki software. Don't think, Ohconfucius, of developers either taking or needing "carte blanche" or consensus from the enwiki community, to implement any change. Rather, enwiki exercises influence over MediaWiki by its direct relationships with developers, who can be enticed to develop features that are beneficial to enwiki and at worst mostly harmless to the rest of the MediaWiki community. The enwiki community does itself no favours by alienating those developers, still less by suggesting that enwiki should be able to claim even more of their time by virtue of some sort of divine right.

Now of course, this is a very unsatisfactory lowest-common-denominator of interaction. As Ryan says above, the MediaWiki developers interact substantially more with the enwiki community than they do any other wiki community, and are always happy to increase that interaction further. The WMF sysadmin staff (and it's important to also be cogent of the distinction between the WMF and MediaWiki) interact far more with the enwiki community than they do any other WMF wiki. Equazcion is absolutely right to say that there is a discussion to be had about how that interaction process can be streamlined and made more effective, and enwiki will certainly have the support of the MediaWiki community in doing so. But it's important not to lose track of the big picture when framing that discussion, which is that the discussion is about how enwiki can best organise itself to punch above its weight in the MediaWiki community when liaising with the developers. Happymelon 20:41, 22 May 2012 (UTC)

And how often are the small wiki communities requesting new features for MW? Where do all the ideas for new features come from? From the developers? From editors on the English Wikipedia? If the fraction of the latter is significant I think it is just fair to at least have a way to comment on the MW progress. Thank you. Nageh (talk) 20:47, 22 May 2012 (UTC)
Certainly not nearly as vocally, or regularly, as enwiki; and of course the majority of features are positive developments for all wikis. But it was disappointing to see the 1.18 release criticised for being light on frontend changes, when it was merely that the majority of said frontend changes (improved text-directionality and gender support, for instance) were merely targeted at languages other than English.
It is absolutely appropriate for enwiki editors to be involved in the MediaWiki development process, to propose changes and even to oppose them. What needs to change is the attitude in the community when participating in that interaction, which needs to have more of an embassadorial feel and less of the Divine Right of Kings. Happymelon 21:04, 22 May 2012 (UTC)
I tend to agree with your last sentence. Let's hope that better ways for intercommunication and a better attitude go hand-in-hand. Nageh (talk) 21:10, 22 May 2012 (UTC)
The first part of your comment is clearly a resource problem (it's impossible to deliver everything everyone wants within a short timeframe with the people we have), not a problem of ideas or input and where they come from. The second part... well you got to comment on the process right ? It's just that your comments weren't picked up in a timely and expedient manner, giving you the feeling that you were not heard.... So that is where any focus of the discussion should be (visibility of the process).
How do developers convince people they are listening and that they are giving priority to issues, without continuously being in debate. And is achieving this goal more important than the actual process of developing the software (Are we gonna allow the pace of the development pace to drop in order to give this visibility) ? The only thing that I can come up with is coupling a much more advanced and usable system than bugzilla (such as the commercial Jira for instance) and significantly integrating it with wiki communities. If the developers can then force themselves to do any actual time accounting and planning in this tooling and that makes the development prices more visible to the community. Such a change would go a long way to making the process more visible. But that is gonna require a huge investment in customizing and switching tooling for the development process and probably still won't work very well for the volunteer developers. —TheDJ (talkcontribs) 21:15, 22 May 2012 (UTC)
Better visibility doesn't necessarily imply a slowed down software development pace. I'm not requesting that all activities are accounted for in detail. A tighter integration of the bug tracking system with Wikipedia certainly will help, but even interim solutions such as the extension mentioned above and a rough but up-to-date progress plan pushed to en.wiki will possibly already improve things quite a bit. Nageh (talk) 21:27, 22 May 2012 (UTC)
So basically the "this month in tech" blog post, but then integrated into every WMF wiki and with more detail and planning, with a 'direct feedback' option for a wiki reader (that does not overload the developers) and without overwhelming the reader. Would likely also require separating the volunteer effort from the WMF effort (which is hardly plannable) and making that a WMF decision on when to include certain sets of volunteer work (roadmap that inclusion process separately for WMF). I don't see a way to do that without significantly diverting resources to that plan for at least the next 2 year to enable this, because otherwise we will be having the same conversation again in 3 more months. —TheDJ (talkcontribs) 21:39, 22 May 2012 (UTC)
I cannot see any intent for efforts in this post. What would be so painful to assemble a list of features the developers are planning to implement for their next (major) MW release, with a possibility to comment on these ideas??? I'm at loss. Other than that, it would already be a step forward if editor-requested bugzilla feature requests would be disseminated to the community via above-mentioned extension. Nageh (talk) 22:25, 22 May 2012 (UTC)
Since all major projects take time to develop, it's usually quite easy to track their progress. For example WMF sponsored projects on such a scale are all referenced extensively in the (aforementioned in other people's comments) monthly engineering reports on the WMF blog (if you're not happy with commenting there, there is also a MediaWiki talkpage you can use). If there are non-WMF-sponsored large projects on the go (these are rarer), generally you're reliant on en.planet.wikimedia.org or on posts to the wikitech-l mailing list (though this isn't the case with Wikidata, for example, which gets included in the WMF's monthly reports. For more imminent upcoming deployments, see Software deployments (no way to comment there, admittedly); for more distant upcoming deployments, see Roadmap (which has a talkpage). For small (in coding time) tweaks, you can consult commit logs, or the easiest way is to wait for mw:MediaWiki_1.20/wmf4 to be created, like wmf3 has already been - this usually happens well before deployment to enwiki. There's a talkpage attached wherre you can comment. Finally, if that all sounds like a bit too much, I try to summarise upcoming projects of all sizes in the Signpost'ss weekly Technology Report, and people are quick to comment on articles there with their thoughts, which have a surprisingly high developer response rate. I'm also open to suggestions on how to improve the report. - Jarry1250 [Deliberation needed] 22:51, 22 May 2012 (UTC) Apologies if you personally knew some of the above Nageh -- I just wanted to be complete(ish) so people reading this could get a feel for the difference avenues available. - Jarry1250 [Deliberation needed] 22:56, 22 May 2012 (UTC)
There's nothing painful about assembling release notes; indeed the developers do it all the time (see mw:MediaWiki 1.20/wmf3, for instance). The question is how to bring that information to enwiki, and the 45,999 other wiki communities, without the very process of notification taking up huge chunks of developers' time. And even whether it's reasonable of enwiki to expect that information to be brought to them, as opposed to 'merely' placed on a neighbouring wiki which shares user accounts and logins with enwiki. Happymelon 22:57, 22 May 2012 (UTC)
I think these are some very useful ideas. Clearly we need a higher-profile and more stream-lined venue of communication between the community and developers. In the meantime, if you want to get detailed information on what's coming down the pipe, probably the best place to look is http://www.mediawiki.org/wiki/MediaWiki_1.20 and related subpages. Specifically you can see what new changes are in the latest release (for example, http://www.mediawiki.org/wiki/MediaWiki_1.20/wmf3#What.27s_new), and when they are going to be deployed to en.wiki (for example, http://www.mediawiki.org/wiki/MediaWiki_1.20/Roadmap). These pages are updated every two weeks. Maybe there's some way this could be set up as a feed that gets picked up by other wikis. Kaldari (talk) 23:15, 22 May 2012 (UTC)
Global watchlists would be invaluable for this. Happymelon 23:55, 22 May 2012 (UTC)
Take a look at Project Echo --Jorm (WMF) (talk) 01:01, 23 May 2012 (UTC)

Regarding en.wiki not being the center of the universe: I get that. Other than the communication and visibility issue, there's currently a bit of ambiguity regarding how development of the software should affect the sites that use it. For example, if en.wiki were a standalone site with no relationship to MediaWiki, we would be looking at updates to the wiki software we use and determining how, and even if, to apply those updates; furthermore, if they are to be applied, how we might customize them to fit our site. The ties we maintain with the software development is partly responsible for the problems we're seeing.

We currently look to the developers and request MediaWiki changes when we want something changed, and to my understanding, that's currently our only option (aside from our copy of MediaWiki's config switches, which by the way are also set by MediaWiki developers). Our administrators can't customize our PHP files, and when such changes are requested of developers, I think both parties assume that the change must be judged as either good for MediaWiki or bad for it, when that might not necessarily be the right question to ask. We here are only concerned with en.wikipedia. Although I respect that you can't afford to be, maybe that means the separation between MediaWiki and en.wikipedia needs to be made less subtle. MediaWiki was originally developed as "our" software, but now it's not, and continuing to maintain this quasi-bond could be hurting.

As an IT/web guy I know that care needs to be taken when customizing a local installation of web software, otherwise applying future update releases can become a problem, but there is a right way to do it. I don't know if there are currently people in position who could handle something like that, but it might be worth asking. I'm envisioning the posting here of plain-english release notes for an update, describing how users will be affected; noting which changes are optional to the installation; allowing a period for comments on what to do with them; and if non-optional features are proven unpopular enough, discussing whether or not a deeper customization is warranted. Also adding an area where new features and changes specific to en.wiki could be discussed. Features that might work well for MediaWiki as a whole could still make their way to bugzilla. This is all just brainstorming though. Equazcion (talk) 05:13, 23 May 2012 (UTC)

As long as we're on the subject, you may want to take a look at what WMF developers are going to be working on for the next year Kaldari (talk) 22:49, 24 May 2012 (UTC)
  1. ^ Pound: "In a Station of the Metro"
  2. ^ [22]