:Great, now how can we get rid of the pointless "Mark all as read" button? No bolding means no need for that. [[User:Nikkimaria|Nikkimaria]] ([[User talk:Nikkimaria|talk]]) 04:37, 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. [[User:Nikkimaria|Nikkimaria]] ([[User talk:Nikkimaria|talk]]) 04:37, 12 May 2012 (UTC)
::I made a script for the time being if you want. Add <code><nowiki>importScript('User:Equazcion/RemoveMarkAll.js');</nowiki></code> to [[Special:MyPage/skin.js|your skin's .js page]]. '''<font face="Century Gothic" style="text-shadow:1px 1px 3px #999;">[[User:Equazcion|<span style="color:#008;">Equazcion</span>]] <small>[[User talk:Equazcion|<sup>(<span style="color:#007BA7">talk</span>)</sup>]]</small>''' 04:54, 12 May 2012 (UTC)</font>
::I made a script for the time being if you want. Add <code><nowiki>importScript('User:Equazcion/RemoveMarkAll.js');</nowiki></code> to [[Special:MyPage/skin.js|your skin's .js page]]. '''<font face="Century Gothic" style="text-shadow:1px 1px 3px #999;">[[User:Equazcion|<span style="color:#008;">Equazcion</span>]] <small>[[User talk:Equazcion|<sup>(<span style="color:#007BA7">talk</span>)</sup>]]</small>''' 04:54, 12 May 2012 (UTC)</font>
*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. <br />More importantly, as Risker said, it's not hard to see that ''[//en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&diff=491929979&oldid=491924505 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. [[User:Nemo_bis|Nemo]] 06:25, 12 May 2012 (UTC)
=== So how about those of us who actually want this? ===
=== So how about those of us who actually want this? ===
The technical section of the village pump is used to discuss technical issues aboutWikipedia. Bugs and feature requests should be made at Bugzilla (How to report a bug). Bugs with security implications should be reported to securitywikimedia.org.
This tends to solve most issues, including improper display of images, user-preferences not loading, and old versions of pages being shown.
No, we will not use JavaScript to set focus on the search box.
This would interfere with usability, accessibility, keyboard navigation and standard forms. See task 3864. There is an accesskey property on it (default to accesskey="f" in English). Logged-in users can enable the "Focus the cursor in the search bar on loading the Main Page" gadget in their preferences.
No, we will not add a spell-checker, or spell-checking bot.
You can use a web browser such as Firefox, which has a spell checker.
If you changed to another skin and cannot change back, use this link.
Alternatively, you can press Tab until the "Save" button is highlighted, and press Enter. Using Mozilla Firefox also seems to solve the problem.
If an image thumbnail is not showing, try purging its image description page.
If the image is from Wikimedia Commons, you might have to purge there too. If it doesn't work, try again before doing anything else. Some ad blockers, proxies, or firewalls block URLs containing /ad/ or ending in common executable suffixes. This can cause some images or articles to not appear.
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)[reply]
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:
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)[reply]
Search link to drop-down menu at 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)[reply]
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');
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)[reply]
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)[reply]
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)[reply]
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)[reply]
Why was it changed? Why won't they change it back? Softlavender (talk) 03:35, 24 April 2012 (UTC)[reply]
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)[reply]
I'm all for improvements, but how the heck is this an improvement? Viriditas (talk) 09:38, 24 April 2012 (UTC)[reply]
(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)[reply]
Not clear which preference you are referring to, or which is easier on your eyes. Softlavender (talk) 03:35, 24 April 2012 (UTC)[reply]
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)[reply]
OK, but for the record, which coloring is easier on your eyes? Softlavender (talk) 03:54, 24 April 2012 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
The developer community is mostly separate from our community here.--Jasper Deng(talk) 04:33, 24 April 2012 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
Sometimes it does. In 1.19 they rolled back the diff color changes. [1]Killiondude (talk) 04:55, 24 April 2012 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
The change was done using CSS actually. No changes were made to the diff engine. — Edokter (talk) — 09:45, 24 April 2012 (UTC)[reply]
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 (tlk−ctb) 05:52, 24 April 2012 (UTC)[reply]
It's shit, but you can change it back via your Preferences. Problem solved. Lugnuts (talk) 09:04, 24 April 2012 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
"Lugnuts' response is a little "I'm alright Jackish"." Got it in one! Lugnuts (talk) 12:54, 24 April 2012 (UTC)[reply]
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)[reply]
(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[Deliberationneeded] 09:40, 24 April 2012 (UTC)[reply]
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)[reply]
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[Deliberationneeded] 20:59, 24 April 2012 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
Can you give an example of the diff generator getting it wrong for comparison? - Jarry1250[Deliberationneeded] 15:38, 24 April 2012 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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[Deliberationneeded] 20:17, 24 April 2012 (UTC)[reply]
So we need to get developer crappy screens to test with, preferable at 800x600 or 1024x768 resolution. — Dispenser 23:55, 24 April 2012 (UTC)[reply]
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)[reply]
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)[reply]
Default is not optional. --Aleksd (talk) 07:58, 27 April 2012 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
I also agree! The previous view was better! --Tito DuttaMessage 00:53, 25 April 2012 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
You create a proper RFC, then advertise it across the site. Simple as :) - Jarry1250[Deliberationneeded] 16:53, 25 April 2012 (UTC)[reply]
Thanks. I must have missed the RFC which decided to make the recent big change. :-) North8000 (talk) 20:02, 25 April 2012 (UTC)[reply]
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)[reply]
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)[reply]
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.EdinburghWanderer 21:41, 25 April 2012 (UTC)[reply]
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:
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)[reply]
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)[reply]
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)[reply]
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[Deliberationneeded] 12:40, 26 April 2012 (UTC)[reply]
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)[reply]
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)[reply]
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: [2]. Someone's priorities are not correct. 86.160.221.37 (talk) 03:38, 27 April 2012 (UTC)[reply]
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)[reply]
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 (talk • contribs) 09:01, 27 April 2012 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
If we could do that, why would we be on Wikipedia? ▫ JohnnyMrNinja 21:32, 29 April 2012 (UTC)[reply]
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)[reply]
Why would any developer want to engage when this is the style of conversation?--Jorm (WMF) (talk) 21:54, 29 April 2012 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
"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)[reply]
Hi all, I just got a "new message" banner for vandalism by someone else. Now, I'm an irregular but longtime contributor, and I do understand what is going on here, and it doesn't bother me. I do also understand that shared IP address messages are necessarily going to be difficult to deliver. But it does occur to me that this would confuse most people, and we can do better.
So may I suggest that if an unregistered user has not performed an edit during their session, then the "new message" banner ought not to be shown. A "new message" banner would not be displayed unless and until someone tries to make an edit (or logs in). The rationale is:
most users are simply reading Wikipedia, the messages is certainly not to them, and there is no reason to trouble or confuse them.
the message will be delivered to someone actually making an edit, so the chances of reaching the right user on a shared IP are actually much increased,
this seems like a small change (but granted I don't know the Wiki internals),
the only way a message notification could go undelivered this way is if no user makes any further unregistered edit from that IP address, but that seems like no big loss.
My 2 cents for today. You're welcome, Wikipedia :-) --192.75.48.150 (talk) 15:41, 30 April 2012 (UTC)[reply]
Not a bad idea, but how would it get it right? Different people can edit from the same machine in rapid succession (especially if one leaves it open), and the same person can leave for a few days and come back. Is there any way to differentiate between these? — Isarra༆ 05:43, 5 May 2012 (UTC)[reply]
Why did Wikipedia change its export function so it no longer works with any other wikis?
Earlier this year Wikipedia changed Special:Export, so that everything exported is in a different format than the one it had previously used for years. This means that other wikis, such as wikia, can no longer import pages. Was that done on purpose? Why was it changed? Any way to fix it back again? DreamFocus 16:07, 1 May 2012 (UTC)[reply]
Well it works for me. Which pages are you trying to export, and what's the MediaWiki version (from Special:version) of the destination site? Andy Dingley (talk) 16:17, 1 May 2012 (UTC)[reply]
<p>Importing pages...
</p><ul>
<li>Skipping interwiki page title 'Wikipedia:Sandbox'</li>
</ul>
<p class="error">Import failed: No pages to import.</p>
Perhaps Wikia should upgrade to the latest stable (1.18.3), or perhaps this has something to do with Wikia's customizations. --Michaeldsuarez (talk) 19:58, 1 May 2012 (UTC)[reply]
Perhaps it has something to do with the difference between version 0.4 (which is what Wikia revisions are exported in) and version 0.6 (which is what Wikipedia revisions are exported in)? Version 0.6 has "ns" and "sha1" tags, but version 0.4 doesn't have them. --Michaeldsuarez (talk) 21:07, 1 May 2012 (UTC)[reply]
That error would be because "wikipedia" there is an interwiki prefix, presumably to link to us. It's the same reason you can't create a page here called "Commons:Village pump". Anomie⚔ 03:25, 2 May 2012 (UTC)[reply]
I can't import revisions from the mainspace either. "Import failed: No pages to import" is displayed. --Michaeldsuarez (talk) 11:47, 2 May 2012 (UTC)[reply]
I am the administrator of various wikis on the Wikia. I go to Special:Import and try to import anything I exported from Wikipedia, and it no longer works. Previously I had no problems at all for it. All I get is Import failed: No pages to import. So I have to talk to wikia and ask them to update their stuff then? Not sure where to even mention it. I'll post on Jimbo's wikipedia page and see. DreamFocus 22:02, 1 May 2012 (UTC)[reply]
Yeah, they really need to update their mediawiki; Wikia is still on 1.16 and the current mediawiki just isn't that far backward compatible (I thought maybe Wikia had just broken something again, but I installed a 1.16 of my own and it didn't work on that either). Your best bet is probably just to contact their staff using their wikia:Special:Contact, though, since they'd be the ones to actually deal with the sort of thing. — Isarra༆ 21:25, 2 May 2012 (UTC)[reply]
There are two new tags in the export format, <ns> and <sha1>. MediaWiki 1.16 is failing because it doesn't know how to treat them. If you really need to import in 1.16, you can manually remove those lines from the file. Also note, 1.17 has no problems with the current format. Platonides (talk) 20:27, 5 May 2012 (UTC)[reply]
1.16 wikis can import the new xml format by applying this patchPlatonides (talk) 20:43, 5 May 2012 (UTC)[reply]
Search box not working properly
Hi. I noticed that when I typed an article title into the search bar, such as Earth, it would take me to Special:Search/Earth rather than directly to the article I was looking for. The same thing happened on Uncyclopedia, but I wanted to being it up here because Wikia probably doesn't care. In older versions of MediaWiki, the search bar would only take you to Special:Search if the query didn't match any titles or if you clicked "Search" (monobook). Specs: I'm using the Vector skin in Google Chrome v18. Can someone tell me what happened, and why? 68.173.113.106 (talk) 21:27, 1 May 2012 (UTC)[reply]
I just tried it again and it took me directly to the article. Might be Wikia's corporate stupidity. 68.173.113.106 (talk) 21:29, 1 May 2012 (UTC)[reply]
While I'm not sure I understand what you're saying, if you mean this happened both places, that would most likely have been a complete coincidence. Wikia's mediawiki and Wikimedia's diverged years ago, with considerable development by both groups in the interim, creating completely different products. For reference, the matter on Wikia's wikis is explained on their blog, however. — Isarra༆ 20:21, 2 May 2012 (UTC)[reply]
Hm yes, I got slapped in the face with that one a few days ago. They do say however,This update changed the "go" button in Monobook, as well. That's a bug, and we'll get it fixed. RichFarmbrough, 01:33, 3 May 2012 (UTC).[reply]
Okay... They should make that option available in Special:Preferences. 68.173.113.106 (talk) 21:37, 5 May 2012 (UTC)[reply]
I prefer that search takes me to search results, and not to a particular page. Search suggestions are in the dropdown menu. There should be a "Go" button to take one directly to a page. --Timeshifter (talk) 15:43, 6 May 2012 (UTC)[reply]
Ads in Wikipedia
i just read the article that says Wikipedia is ad free.
however, there are at least two ads in every article; a banner separating the title from the article (this is very annoying)
and side bar ad. now, right below the ads is text reading "ads not by this site". so i think wikipedia should do something about abolishing these annoying, distracting, and cheapening advertisements. — Preceding unsigned comment added by 71.41.148.2 (talk) 13:12, 2 May 2012 (UTC)[reply]
Out of interest, you couldn't take a screen grab (or a few) and upload it to the internet (and released it under a Wikimedia compatible license)? It might make for an interesting example of malware for an article. --RA (talk) 13:49, 2 May 2012 (UTC)[reply]
Do you have some program by Corel installed? I had the exact same issues once and it turned out to be some patented adware system that gets installed if you run a program during its trial phase. I'm trying to remember what the program name was.—cyberpowerChatOnline 20:43, 5 May 2012 (UTC)[reply]
Now I remember. Open Task Manager and search for psiservice.exe under the processes tab. Right click on that process and open the folder it's in. It should be view in explorer or something like open file location. After the file location is open, in task manager click on end process, make sure psiservice.exe is still selected otherwise you may accidentally end a task windows depends on, confirm that you want to end the process. In Windows Explorer where the file is located delete the entire folder the file is in. Also follow the instructions found here to remove any remains of it. Restart the computer. You should be ad free now.—cyberpowerChatOnline 20:50, 5 May 2012 (UTC)[reply]
JP2
I have a bunch of JP2 images, I want to convert them (to png) for WP use. Irfan viewer fails. Any other good quick to learn free converters? RichFarmbrough, 01:25, 3 May 2012 (UTC).[reply]
It looks like GIMP 2.7 and up can read JP2 files (download). However, these versions are considered unstable. Probably, it will work fine, but take care. If that doesn't work, link an image and people can try other image editors they know. Superm401 - Talk 01:41, 3 May 2012 (UTC)[reply]
Thanks for that. The version I have couldn't. RichFarmbrough, 17:43, 6 May 2012 (UTC).(Using some automation)[reply]
Problem with search on mobile
To whom it may concern, Why can't I do an open search on my mobile phone? Whenever I write in a word that does not already contain an article and it automatically takes me to me to a page with the closest match. Ex. If I type he it takes me to hertz every time or even worse when it cannot find a match it leaves me repeatley hitting the search button to no avail. I thought perhaps it was my phone but this only happens on your website. This was originally posted to the help page, but it was suggested to post it here in the hope of finding a solution.It is extremely annoying, hope to hear back . Thank you — Preceding unsigned comment added by 68.84.86.149 (talk) 08:10, 3 May 2012 (UTC)[reply]
Many people are irritated when search takes them to a page, when what they really wanted was a list of search results. And since there is no easy way to get to the Special:Search page many casual readers give up their searching.
Most casual readers do not know that Special:Search exists since it is not linked anywhere on Wikipedia pages. The only way they know of it is if they happen to see the advanced search options at the bottom of a search results page. Even then they may not know that Special:Search exists as a separate page. And they still do not know how to get to it so that they can bookmark it.
Why should people have to bookmark Special:Search? It should be linked from the sidebar of every page. That would solve several problems. --Timeshifter (talk) 13:05, 4 May 2012 (UTC)[reply]
You're mixing your issues; if you have javascript enabled in the vector skin, the option to search instead of go appears when one starts typing, though I can understand that it is easy to miss since it appears below the other options. As for the mobile interface, on the other hand, that sounds like it may just need more work... — Isarra༆ 05:39, 5 May 2012 (UTC)[reply]
Hmm. Learned something new. I have been editing Wikipedia for years but only recently started using the search form again. I had long ago stopped using it due to the fact that it opens in the same tab. I used Google toolbar to do site searches until they stopped providing it for Firefox. Then I used a Firefox addon that will search a site. But in the last few weeks I added some Javascript to open all search results and suggestions in new tabs. And I have been using the search form, but did not figure out the part at the bottom. It is completely unintuitive. See:
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)[reply]
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)[reply]
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)[reply]
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)[reply]
Missing in Firefox 12.0 as well. Bidgee (talk) 01:32, 11 May 2012 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
Hi I have just received an e-mail indicating that an article on my watchlist has been changed yet I have not selected to receive e-mail when articles on watchlist have changed in my options. Is this a one off glitch? Hopefully it is or I will get swamped with e-mails. Keith D (talk) 19:38, 3 May 2012 (UTC)[reply]
There's a section above (Wikipedia:VPT#Occasional_.22mark_all_changes_as_read.22) that implies it was a recent change. When I went to my prefs I saw the checkbox was disabled, so I'm guessing someone accidentally enabled it today for a moment. tedder (talk) 19:51, 3 May 2012 (UTC)[reply]
The same happened to me. I have a huge watchlist and dozens of pages had been edited since I last visited Wikipedia but I only got one email. It was about [3] at 19:19 (UTC) to User talk:Bzweebl. Both "E-mail me when a page on my watchlist is changed" and "E-mail me when my user talk page is changed" are disabled for me at Special:Preferences. PrimeHunter (talk) 19:58, 3 May 2012 (UTC)[reply]
Same here. Strangely enough, the only notifications I am receiving are for edits made by 87.4.78.230 to Demi Lovato articles. I have 14607 articles on my list, and those edits represent 2 out of the last 100 changes or so.—Kww(talk) 20:15, 3 May 2012 (UTC)[reply]
Probably happened around 1930 UTC, right? That appears to be the "bad" period. You may still receive some, but they are queued and late and such. tedder (talk) 20:18, 3 May 2012 (UTC)[reply]
This is becoming a mail bomb. Who do we contact for an emergency fix?—Kww(talk) 20:29, 3 May 2012 (UTC)[reply]
For some odd reason, this only caused an issue for articles on the watchlist of my sockpuppet (the account I'm using at the moment). When I logged in to figure out what was going on, the check box for emails was suddenly checked. It didn't, however, cause issues for my main account. --auburnpilot'ssock 20:35, 3 May 2012 (UTC)[reply]
I got one at 19:18 UTC for this edit, which took place two minutes earlier than the email. Other than edits made by myself, the previous edit on my watchlist was at 19:05 UTC; the next at 19:24 UTC, neither of which triggered an email. --Redrose64 (talk) 20:38, 3 May 2012 (UTC)[reply]
Likewise for me in respect of this. One of about 600 pages on my watchlist, although it was the only one changed during the "bad" period. Hassocks5489 (tickets please!) 20:42, 3 May 2012 (UTC)[reply]
This indicates it was only edits between 19:15 and 19:31. That matches my mail and others who have mentioned edits or a time here. Mails may arrive with a delay. PrimeHunter (talk) 20:39, 3 May 2012 (UTC)[reply]
A single email notification leaked through?
I have just received an email that one (of the thousands) of pages on my watchlist was edited. Since I have never turned on email notification, and is is not turned on now in my preferences, I find this curious. Has the software just sent out emails to anybody else? What if it keeps this up? Will there be millions of unwanted emails sent? Speciate (talk) 21:16, 3 May 2012 (UTC)[reply]
I'm not certain about this, but could it be because of an autoblock? Graham87 02:57, 4 May 2012 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
That strikes me as outing users. Nobody Ent 13:09, 5 May 2012 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
Error Could not parse twinkleoptions.js
Resolved
Hi , can anyone help me with this problem which I am fed up of. On every wiki page including this page while typing i am getting a notice on the top saying
Could not parse twinkleoptions.js
I tried to debug User:DBigXray/twinkleoptions.js but it still persists. I even tried blanking twinkleoptions.js page and set the preference again but it did not work.
I think the problem started after i tried adding a custom template for welcoming user. Some kind of help or suggestion will be much appreciated, thank you--ÐℬigXЯaɣ 10:17, 4 May 2012 (UTC)[reply]
wow just 1 message here and problem solved. thanks --ÐℬigXЯaɣ 10:21, 4 May 2012 (UTC)[reply]
Image question
Image experts, I think an image in an infobox is not supposed to need an imagesize parameter, correct?
In Derek Flores, I selected 280px, which works, but if I leave it blank it isn't visible. I have a work around so nothing urgent, but just wondering what's up.--SPhilbrick(Talk) 03:35, 5 May 2012 (UTC)[reply]
There are sometimes hiccups which cause an image to temporarily not be rendered at a certain size. I guess that happened for you. It doesn't matter whether it's in an infobox. I currently see a 220px image in [4]. I have the default 220px in Thumbnail size at Special:Preferences#mw-prefsection-rendering. PrimeHunter (talk) 10:51, 5 May 2012 (UTC)[reply]
OK, thanks, I'll write it off as a hiccup.--SPhilbrick(Talk) 12:08, 5 May 2012 (UTC)[reply]
If you do run into this issue with a particular size not rendering, one thing to try is to go to the image description page (possibly at Commons) and purge it to cause all the thumbnails to be regenerated. Anomie⚔ 17:18, 5 May 2012 (UTC)[reply]
Power watch/unwatch
Could we have a toolserver tool that allows us to watch/unwatch pages based on their categorisation? The tool needs to accept Category:X as a starting point, watch everything in it, and then list the subcategories and ask the user if they want to watch the contents of those as well. Rinse and repeat until all sub/sub-sub/etc-categories have been processed. And an "unwatch" option to do the same in reverse. I think this would be useful, and probably not that hard. Beyond en.wp it would be particularly useful, perhaps, for smaller, less active wikis with watchlist notification enabled. Rd232talk 09:36, 5 May 2012 (UTC)[reply]
I might do it. It's not hard to query the categories or perform the watching. I don't know how to request the watch token from the user, though. It would need the user to do something like javascript:alert(mw.user.tokens.get('watchToken')) -- Platonides (talk) 21:03, 5 May 2012 (UTC)[reply]
I've dealt with it manually. Graham87 14:35, 5 May 2012 (UTC)[reply]
Wikipedia citation search
Would it be possible to have a second search option on each page for searching citations in article space? I'm thinking it might be useful for the authors of sources to easily find and check what's being said in their name. --Anthonyhcole (talk) 14:12, 5 May 2012 (UTC)[reply]
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.—cyberpowerChatOnline 20:36, 5 May 2012 (UTC)[reply]
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.—cyberpowerChatLimited Access 17:57, 7 May 2012 (UTC)[reply]
I'd post on Bugzilla, but I don't really have the heart for it.
A database error has occurred. Did you forget to run maintenance/update.php after upgrading? See: https://www.mediawiki.org/wiki/Manual:Upgrading#Run_the_update_script
Query: UPDATE `user` SET user_name = '[redacted]',user_password = '[redacted]',user_newpassword = 'redacted',user_newpass_time = '[redacted]',user_real_name = ,user_email = 'redacted',user_email_authenticated = '[redacted]',user_touched = '[redacted]',user_token = '[redacted]',user_email_token = '[redacted]',user_email_token_expires = '[redacted]' WHERE user_id = '[redacted]'
Function: User::saveSettings
Error: 1205 Lock wait timeout exceeded; try restarting transaction (10.0.6.48)
Note that without my redactions this gives away password hashes, recently compromised bitcoins hash site hash files indicate that compromised hashes are virtually equivalent to plaintext these days. Any user getting this error will effectively have their Wikipedia password and username stored in cache, as well as anywhere they post it for clarification.
Yes, it's called Wikipedia, you may have heard of it... RichFarmbrough, 01:23, 6 May 2012 (UTC).(Using some automation)[reply]
We now have a positive confirmation that this is Rich Farmbrough indeed. -DePiep (talk) 01:33, 6 May 2012 (UTC)[reply]
(ec) Ah yes, I do see the reference to "Wikipedia password" now. I assume that means the English Wikipedia, then. Probably worth a bug report when I find a moment... - Jarry1250[Deliberationneeded] 01:37, 6 May 2012 (UTC)[reply]
Indeed, thanks Jarry. RichFarmbrough, 01:47, 6 May 2012 (UTC).(Using some automation)[reply]
If it's a serious security error, more reason to list it on bugzilla, as most developers don't read the Village Pump. What were you doing when you got that error? Some changes to your account? Was it your user name? (ie. it only reveals your password hash to yourself) Platonides (talk) 20:03, 6 May 2012 (UTC).[reply]
It's hard to tell what the cause of this was without knowing the URL, but it's possible that it was an exception message shown through api.php due to $wgShowExceptionDetails being set to true. It's probably not a serious security vulnerability, since such messages are sent with Cache-Control: private, but again, it's hard to be sure without having details about where it came from. We decided to turn off $wgShowExceptionDetails to be on the safe side, the reasons it was turned on are mostly no longer relevant. -- Tim Starling (talk) 23:05, 7 May 2012 (UTC)[reply]
It was attempting to look at SmckBot's watch list. (Which was triggered by the mailflood.) So an error was not unreasonable, just the data that leaked. It did reproduce, I believe. RichFarmbrough, 01:54, 9 May 2012 (UTC).[reply]
What happened to the "Permanently disable mobile site" button?
I'm running the native Android Gingerbread 2.3.4 browser on my Droid 2 over Verizon Wireless 3G. Lately I've been being redirected to mobile versions of en.wiki pages and have to manually switch to the desktop view (the button for which is hidden within a dropdown menu - grrr). There used to be a button to permanently disable the mobile site that is no longer there and doesn't seem to be honoring previous requests either. The site does stay in desktop view over a session, but will sometimes revert back to mobile when I open a new window even if I'm already logged in. Ashanda (talk) 03:22, 6 May 2012 (UTC)[reply]
Per my response here, it should be the case that clicking "desktop view" is sufficient to achieve the same effect as the old link. However, you seem to be having problems with that - do you notice a particular pattern as to when you get directed from the desktop site to the mobile site? - Jarry1250[Deliberationneeded] 13:22, 6 May 2012 (UTC)[reply]
I'm the same sometimes it takes me straight to the desktop view other times to the mobile site. Didn't have that problem before they changed it. I'm using Safari so I don't think it's a device problem. Just a minor irattation. EdinburghWanderer 13:37, 6 May 2012 (UTC)[reply]
Again, it would be interesting to know if you've noticed any particular pattern to when you enter on the desktop site? There are two things which should influence the decision of which to send you (1) cookies (set via the "Desktop view" link) and (2) Your user-agent string (esentially what browser and browser version you're using). It sounds like (1) is being messed up in your case, but I'm not certain how. - Jarry1250[Deliberationneeded] 14:03, 6 May 2012 (UTC)[reply]
Current url
Is there any way to look at the current url within a page? RichFarmbrough, 17:41, 6 May 2012 (UTC).(Using some automation)[reply]
Yep something else. Not based on FULLPGENAME. I want to know which redirect I have come from. RichFarmbrough, 22:29, 6 May 2012 (UTC).(Using some automation)[reply]
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)[reply]
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.--GilderienChat|List of good deeds 18:28, 7 May 2012 (UTC)[reply]
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. RichFarmbrough, 01:57, 9 May 2012 (UTC).[reply]
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:
<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:
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:
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
Render multiple line-initial spaces literally : <poem> currently supports
Render multiple line-internal spaces literally : <poem> currently does not support
Render single line-breaks literally : <poem> currently supports
Render some possibly-reserved characters literally (these include "|", "/", "\", "[]", "()") : <poem> currently supports
Render markup (e.g. <ref>) as markup, not literally : <poem> currently supports
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)[reply]
Oh god. Not another update. :O.—cyberpowerChatOnline 18:42, 6 May 2012 (UTC)[reply]
Perhaps this is the wrong place to ask, but why, exactly, was extra padding added to the vector skin? It already has extra padding from monobook. The supposed issue was resolved by making the vector skin in the first place; was there any particular reason why this was not enough? -— Isarra༆ 19:19, 6 May 2012 (UTC)[reply]
They consider anything bigger than a tablet or minilaptop a 'large' display. As what I normally use is 800px tall and things are already quite cramped (add a banner and the content can literally start halfway down the page in the vector skin), I honestly have no idea why they would think a most common resolution of 768px tall is justification for cramping things further, though why extra padding is supposed to help anything even on larger resolutions is beyond me regardless. Vector most certainly was not optimised for a 800x600px screen; it may have been kept in check such that it wouldn't fail completely on it, maybe, but it also ain't monobook. Wasn't that kind of the point? -— Isarra༆ 15:11, 7 May 2012 (UTC)[reply]
Maybe they're trying to hint to certain people that it's time to buy a bigger monitor (hint hint). PS. You could toy with the padding using your vector.css page, though that of course doesn't address the concern for others. Equazcion(talk) 15:21, 7 May 2012 (UTC)[reply]
Ohhh... I've just upgraded to Firefox 12 from 3.6.28. Now I've got less than a day to locate all the behaviour changes, and so positively put the blame on Mozilla (such as the post I just made at #Edit toolbar not painting completely) - any that I discover after 18:00 UTC tomorrow I won't know whose fault it is. --Redrose64 (talk) 21:32, 6 May 2012 (UTC)[reply]
I think the constantly new release of versions makes it hard for anyone but power users (those who use multiple functions on the site daily) to identify which version the bugs started cropping up in. Is this a feature or a bug? Killiondude (talk) 21:37, 6 May 2012 (UTC)[reply]
As I understand it, releases are on a new cycle: we get updates more often, but with fewer fixes. Broken stuff gets fixed and new features are deployed more quickly, but in smaller chunks so we don't have to deal with a gazillion changes at one go. ---— Gadget850 (Ed)talk 22:26, 6 May 2012 (UTC)[reply]
Rapid release is good, in general. HPB sometimes gets through 4 or 5 releases in a day. RichFarmbrough, 22:27, 6 May 2012 (UTC).(Using some automation)[reply]
Killiondude, I believe it is easier to track the source of the bug when we have more rapid releases with fewer changes in each. Hazard-SJ ✈ 03:58, 7 May 2012 (UTC)[reply]
And it is frustrating to report a bug, have someone pay attention and work on it, shepherd it through development and testing to final resolution, then wait six months for a new release. ---— Gadget850 (Ed)talk 12:49, 7 May 2012 (UTC)[reply]
On the whole, a faster release cycle is better, because there are fewer fixes/changes in each release, so easier to spot the bug. Sympathies with RedRose64 though, the incremental changes in the Fox are only intermittently annoying, but that big jump will look a lot different and cause problems with any number of your extensions :( Elen of the Roads (talk) 13:02, 7 May 2012 (UTC)[reply]
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)[reply]
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[Deliberationneeded] 23:42, 6 May 2012 (UTC)[reply]
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)[reply]
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[Deliberationneeded] 00:58, 7 May 2012 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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[Deliberationneeded] 12:18, 7 May 2012 (UTC)[reply]
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)[reply]
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[Deliberationneeded] 22:14, 7 May 2012 (UTC)[reply]
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)[reply]
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.) RichFarmbrough, 02:02, 9 May 2012 (UTC).[reply]
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)[reply]
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)[reply]
The relevant CSS rule (in the "site" module if I interpret the URL correctly) is
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)[reply]
Actually - I can't get it to work, the TOCLimit still works. --86.180.71.140 (talk) 17:21, 7 May 2012 (UTC)[reply]
Try changing none to inline. How are you updating personal CSS without an account? ---— Gadget850 (Ed)talk 17:28, 7 May 2012 (UTC)[reply]
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)[reply]
@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)[reply]
Auto numbering in tables
Hi. I have a proposal of auto numbering in tables. If you make a wikitable and want to have numbering in the first column, you have to add it manually row by row. Now, it would be much more simple if you just write something like {| class="wikitable numbering" or {| class="wikitable numbering sortable" or {| class="wikitable # sortable" and then the software automatically adds the first column with numbers in every row. --Janezdrilc (talk) 17:05, 7 May 2012 (UTC)[reply]
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)[reply]
/* inline list of templates */.templatesUsedul,.templatesUsedli{font-size:smaller;display:inline;margin:0;padding:0;}.templatesUsedulli:before{content:"\A0\B7\20";/* nbsp, centre dot, space */}.templatesUsedulli:first-child:before{content:"\A0";}
Can't remember who I ripped this from. ---— Gadget850 (Ed)talk 22:08, 7 May 2012 (UTC)[reply]
Snazzy! Thank you :) - ʄɭoʏɗiaɲτ¢ 10:39, 9 May 2012 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
Appears to have been fixed now. The blocks listed are still glitched though. Elockid(Talk) 23:46, 7 May 2012 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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.
I don't think that is how revdel is supposed to work. MBisanztalk 16:07, 8 May 2012 (UTC)[reply]
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[Deliberationneeded] 17:31, 8 May 2012 (UTC)[reply]
It looks identical to that bug. MBisanztalk 03:12, 9 May 2012 (UTC)[reply]
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. RichFarmbrough, 00:08, 9 May 2012 (UTC).[reply]
Oh yes, and I get loads of self-edit-conflicts. RichFarmbrough, 00:09, 9 May 2012 (UTC).[reply]
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)[reply]
The edit conflicts are just WP. Hm, I guess I could test something with a different account. I'll look into it. RichFarmbrough, 21:20, 10 May 2012 (UTC).[reply]
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)[reply]
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)[reply]
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)[reply]
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.
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)[reply]
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)[reply]
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.) RichFarmbrough, 00:16, 9 May 2012 (UTC).[reply]
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)[reply]
funky error on user talk page
Anyone have any idea what's going on here[5]? 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:
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)[reply]
But why only on that one page? That's what's so weird. — kwami (talk) 09:27, 8 May 2012 (UTC)[reply]
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.
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
"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 (talk • contribs) 20:46, 9 May 2012 (UTC)[reply]
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)[reply]
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 [6] for a former version of this, and de:Wikipedia:Kurze Artikel for a German version. PrimeHunter (talk) 21:38, 9 May 2012 (UTC)[reply]
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)[reply]
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. ISBN978-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, editors (ed.). Religion and Psychiatry: Beyond Boundaries. Wiley. pp. 271–82. ISBN978-0-470-69471-8. {{cite book}}: |editor= has generic name (help)CS1 maint: multiple names: authors list (link)
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. ISBN978-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, editors (ed.). Religion and Psychiatry: Beyond Boundaries. Wiley. p. 271. ISBN978-0-470-69471-8. {{cite book}}: |editor= has generic name (help)CS1 maint: multiple names: authors list (link)
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)[reply]
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)[reply]
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)[reply]
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)[reply]
(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)[reply]
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)[reply]
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)[reply]
Gadget850, thanks for the link. I didn't know about some of these.Maile66 (talk) 01:07, 10 May 2012 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
There is of course a Bugzilla bug for this... RichFarmbrough, 21:32, 10 May 2012 (UTC).[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
Like the Village pump isn't bolded on my watchlist, and I just edited it. MathewTownsend (talk) 17:07, 10 May 2012 (UTC)[reply]
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)[reply]
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 (talk • contribs) - 17:03, 10 May 2012 (UTC)[reply]
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)[reply]
Thanks for that - it's good enough for now. SmartSE (talk) 19:10, 10 May 2012 (UTC)[reply]
No - no off-switch in My Preferences - Gadgets Arjayay (talk) 17:07, 10 May 2012 (UTC)[reply]
Where is this off-switch? I can't seem to find it. – Allen4names 17:15, 10 May 2012 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
Utterly hideous. Please make it go away. Mr Stephen (talk) 17:29, 10 May 2012 (UTC)[reply]
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 (talk ⋅ contribs) 17:32, 10 May 2012 (UTC)[reply]
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)[reply]
Far too distracting, not fit for purpose. Please remove and rethink. (Hohum@) 17:37, 10 May 2012 (UTC)[reply]
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. GRAPPLEX 17:38, 10 May 2012 (UTC)[reply]
(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)[reply]
Bold the change times, instead of the article titles. --NeilNtalk to me 17:39, 10 May 2012 (UTC)[reply]
Bold should be the exception not the norm. Secretlondon (talk) 17:40, 10 May 2012 (UTC)[reply]
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)[reply]
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. CaptainScreeboParley! 17:54, 10 May 2012 (UTC)[reply]
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(T•C•G•E) 18:05, 10 May 2012 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
With Ks0stm on this one - on Commons it's nice, here it's unmanageable. --Rschen7754 18:33, 10 May 2012 (UTC)[reply]
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)[reply]
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)[reply]
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(talk • contributions) 19:05, 10 May 2012 (UTC)[reply]
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)[reply]
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. --auburnpilottalk 19:08, 10 May 2012 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
Bold letters changed to stars—cyberpowerChatOnline 20:58, 10 May 2012 (UTC)[reply]
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. GRAPPLEX 20:56, 10 May 2012 (UTC)[reply]
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 (talk ⋅ contribs) 21:06, 10 May 2012 (UTC)[reply]
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)[reply]
Off-think, off-think, off-think. Bolding and stars, it's like throwing glitter over the watch-list to make it pretty. Ugh. --Fæ (talk) 22:22, 10 May 2012 (UTC)[reply]
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)[reply]
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?
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.
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)[reply]
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. Narutolovehinata5tccsdnew 02:16, 11 May 2012 (UTC)[reply]
The green highlighting on history pages is bloody awful. Get rid of it! MER-C 04:23, 11 May 2012 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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. CaptainScreeboParley! 19:32, 10 May 2012 (UTC)[reply]
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. --auburnpilottalk 19:03, 10 May 2012 (UTC)[reply]
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. GRAPPLEX 19:03, 10 May 2012 (UTC)[reply]
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)[reply]
Are you for real! Have you even read any of the above posts?
"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)[reply]
(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)[reply]
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)[reply]
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)[reply]
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. CaptainScreeboParley! 19:28, 10 May 2012 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
"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)[reply]
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)[reply]
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)[reply]
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)[reply]
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. GRAPPLEX 20:28, 10 May 2012 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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. GRAPPLEX 19:20, 10 May 2012 (UTC)[reply]
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)[reply]
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. GRAPPLEX 19:31, 10 May 2012 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
forceful change didn't work for me. Can't figure out why. MathewTownsend (talk) 20:50, 10 May 2012 (UTC)[reply]
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)[reply]
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)[reply]
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 (talk • contribs) - 19:40, 10 May 2012 (UTC)[reply]
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)[reply]
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 (talk • contribs) - 19:48, 10 May 2012 (UTC)[reply]
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 (talk • contribs) - 19:52, 10 May 2012 (UTC)[reply]
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 (talk • contribs) - 20:16, 10 May 2012 (UTC)[reply]
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)[reply]
I had just found that css formatting via a Google search - I should've just waited for the post here. :-) --- Barek (talk • contribs) - 20:26, 10 May 2012 (UTC)[reply]
Thanks for this code - to which page should it be added? Truthkeeper (talk) 20:29, 10 May 2012 (UTC)[reply]
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 (talk • contribs) - 20:44, 10 May 2012 (UTC)[reply]
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)[reply]
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. --Onorem♠Dil 21:06, 10 May 2012 (UTC)[reply]
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? --Onorem♠Dil 14:54, 11 May 2012 (UTC)[reply]
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 BushrangerOne ping only 21:11, 10 May 2012 (UTC)[reply]
The stars were added by Edokter twenty minutes ago: [7]. 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)[reply]
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. GRAPPLEX 21:15, 10 May 2012 (UTC)[reply]
#mw-watchlist-resetbutton{display:none} should do it. --Yair rand (talk) 21:19, 10 May 2012 (UTC)[reply]
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. --Onorem♠Dil 21:17, 10 May 2012 (UTC)[reply]
Thanks, Yair! That's me satisfied for now, anyway. Back to content creation again. GRAPPLEX 21:25, 10 May 2012 (UTC)[reply]
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. --Onorem♠Dil 22:20, 10 May 2012 (UTC)[reply]
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)[reply]
Looking for smaller stars... It's a concept. Stop stifling innovation! — Edokter (talk) — 21:10, 10 May 2012 (UTC)[reply]
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)[reply]
No, do not like green star. Distracting! --Tito Dutta✉ 21:12, 10 May 2012 (UTC)[reply]
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)[reply]
They suddenly appeared on my watchlist and my first thought was: WTF (or should I say WMF)? Where has this been announced? -- Toshio Yamaguchi (tlk−ctb) 21:13, 10 May 2012 (UTC)[reply]
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)[reply]
You don't have my permission to inflict your "innovation" on my watchlist. Roger (talk) 21:16, 10 May 2012 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
The green star seems reasonable to me, far better than the emboldening, but it needs to be smaller. MalleusFatuorum 21:15, 10 May 2012 (UTC)[reply]
Yes, smaller, and maybe a slightly less obtrusive color. --Rschen7754 21:18, 10 May 2012 (UTC)[reply]
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 BushrangerOne ping only 21:20, 10 May 2012 (UTC)[reply]
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(talk • contributions) 21:21, 10 May 2012 (UTC)[reply]
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)[reply]
Then make an advanced tab for those that want it. Who are you to say that "There's not going to be an option?" --Onorem♠Dil 21:24, 10 May 2012 (UTC)[reply]
(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)[reply]
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)[reply]
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. --Onorem♠Dil 21:23, 10 May 2012 (UTC)[reply]
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)[reply]
I assume that it would be something like adding this to your CSS: [8] --Rschen7754 21:31, 10 May 2012 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
(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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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 (talk • contribs)
If only I could touch the green star and see what it means. -DePiep (talk) 22:31, 10 May 2012 (UTC)[reply]
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)[reply]
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)[reply]
When discussion has ended, remove this tag and it will be removed from the list. If this page is on additional lists, they will be noted below.
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:
Absolutely hate this change and want it abolished.
Want the change to be revised (explain exactly how)
Want an opt-out other than a gadget
Want it to be opt-in
Do not care about the change
Support the change
When closing this RFC, please consider the discussion above.--Jasper Deng(talk) 21:40, 10 May 2012 (UTC)[reply]
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)[reply]
Opt-in: as per Hasteur. NtheP (talk) 21:53, 10 May 2012 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
Opt-in. Second choice involves deletion and salting.--Wehwalt (talk) 22:53, 10 May 2012 (UTC)[reply]
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)[reply]
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)[reply]
Exactly: that is, something not possible. --Nemo 23:58, 10 May 2012 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
Opt-out – mediawikiwiki: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)[reply]
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)[reply]
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)[reply]
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! Narutolovehinata5tccsdnew 01:31, 11 May 2012 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
Opt-in although I am strongly inclined to choose option #1 with the way this was deployed. – Allen4names 04:14, 11 May 2012 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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 doktorbwordsdeeds 07:43, 11 May 2012 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
Opt-in May be useful to some, awful for others. --RA (talk) 13:05, 11 May 2012 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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. EdinburghWanderer 16:04, 11 May 2012 (UTC)[reply]
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. Parrotof Doom 16:06, 11 May 2012 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
'Revise/Opt-in pretty much per Mangoe. It essentially keeps the items you're the least interested in looking at bolded. —Torchiesttalkedits 17:51, 11 May 2012 (UTC)[reply]
Opt-in per Tryptofish et al. Absurd, annoying and (to me) useless. BenMacDui 18:14, 11 May 2012 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
span.updatedmarker{display:none;} --Yair rand (talk) 21:54, 10 May 2012 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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 BugsWhat's up, Doc?carrots→ 05:22, 11 May 2012 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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.
"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)[reply]
In that case, the message can be changed. — Edokter (talk) — 22:04, 10 May 2012 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
Change temporarily reverted in search for better consensus
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
The "powers that be" had nothing to do with these changes. --Yair rand (talk) 22:37, 10 May 2012 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
Why so much bold? :( — foxj 07:18, 11 May 2012 (UTC)[reply]
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)[reply]
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)[reply]
Couldn't have put it more eloquently. MarnetteD | Talk 01:03, 11 May 2012 (UTC)[reply]
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 (talk • contribs) 01:09, 11 May 2012 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
Bin the Bold I echo the sentiments of the honourable and right honourable members of the project above. doktorbwordsdeeds 05:21, 11 May 2012 (UTC)[reply]
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)[reply]
You're right, I've filed your feature request under bugzilla:36761. Nemo 14:04, 11 May 2012 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
I think I can sum up the opinion above by responding with: boo! Killiondude (talk) 00:03, 11 May 2012 (UTC)[reply]
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)[reply]
"Enabled by community request". bullshitFifelfoo (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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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.
VERY much like. Thank you. This should be a gadget, at least. Equazcion(talk) 02:08, 11 May 2012 (UTC)[reply]
Brilliant idea, I'm in favor (though perhaps as an opt-in to avoid more community rage). — FoxCE (talk • contribs) 02:14, 11 May 2012 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
"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? Rd232talk 11:41, 11 May 2012 (UTC)[reply]
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)[reply]
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. Rd232talk 12:01, 11 May 2012 (UTC)[reply]
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)[reply]
"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. Rd232talk 12:12, 11 May 2012 (UTC)[reply]
How is it better? I answered that above. Equazcion(talk) 12:34, 11 May 2012 (UTC)[reply]
and the answer was? Rd232talk 13:34, 11 May 2012 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
I'm just wondering by what order of magnitude this change has increased server load? --Ohconfucius¡digame! 00:44, 12 May 2012 (UTC)[reply]
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)[reply]
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.
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
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
Why has the implementer of this not reverted their actions? Fifelfoo (talk) 23:47, 11 May 2012 (UTC)[reply]
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)[reply]
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)[reply]
If you read the bug action they relied on a construction of consensus on wikipedia. Fifelfoo (talk) 02:24, 12 May 2012 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
I probably wouldn't mind some blue fish on my GUI... ;-) --Ohconfucius¡digame! 02:50, 12 May 2012 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
I second that! HiLo48 (talk) 05:13, 12 May 2012 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
Are you including English Wikipedia admins as "developers"? --Yair rand (talk) 21:49, 10 May 2012 (UTC)[reply]
(edit conflict) If they're planning a major visual change then yes they should make it in the beta version first. Equazcion(talk) 21:53, 10 May 2012 (UTC)[reply]
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)[reply]
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)[reply]
Changes and instructions for participating in the beta could be advertised via those dandy watchlist notices. Equazcion(talk) 23:02, 10 May 2012 (UTC)[reply]
@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)[reply]
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)[reply]
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)[reply]
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)[reply]
...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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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.
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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...
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)[reply]
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)[reply]
Click "Upload file" in the toolbox, "old guided form", "a screenshot". PrimeHunter (talk) 01:15, 12 May 2012 (UTC)[reply]
Thanks, I now remember that form. (Not the screenshot part, but the earlier step) --SPhilbrick(Talk) 02:37, 12 May 2012 (UTC)[reply]
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;
}
Je veux ton amour et je veux ta revanche. But seriously, thanks. Killiondude (talk) 02:13, 12 May 2012 (UTC)[reply]
Elen, you're a beautiful person. Equazcion(talk) 02:17, 12 May 2012 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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.—cyberpowerChatOffline 03:17, 12 May 2012 (UTC)[reply]
Now we're cooking on gas. Figured out what the problem was, thanks Cyberpower
Exalt! Most useful. Many, many thanks. doktorbwordsdeeds 04:02, 12 May 2012 (UTC)[reply]
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)[reply]
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)[reply]
wikimedia.org.
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.
Resolved
Rich Farmbrough, 22:27, 6 May 2012 (UTC).(Using some automation)
Fixed--Deathlaser : Chat 16:52, 8 May 2012 (UTC)
Bold letters changed to stars—cyberpower ChatOnline 20:58, 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. --Fæ (talk) 22:22, 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)
