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]
Or search link in a drop-down menu at the top
In preferences there is a gadget (in the appearances section of the gadget tab) called "Add page and user options to drop-down menus on the toolbar." The search link could go there in the drop-down menu. That may be the simplest way to get searches done in a new tab. Also, it does not take up any valuable real estate in the sidebar or at the top. Any thoughts? --Timeshifter (talk) 14:48, 29 April 2012 (UTC)[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');
Popular Firefox search addon opens results list in new tab
Featured, popular Firefox search addon: Context Search. From its description:
Once the search engine menu is visible:
- Left click to search in a new background tab.
- Middle click to search in a new tab and switch to that tab immediately.
- Ctrl+click to search in a new tab and switch to that tab immediately.
If you have Firefox set to switch to new tabs immediately, the above key combinations will have the inverse effect.
Shift + click opens search results in a new window. (End of description quote).
This is one of the most popular Firefox search addons. I believe part of the reason it is so popular is that it opens the results list page in a new tab. That is the default setting. So search never interferes with what you are doing or what page you are reading. On the other hand the results from Wikipedia's search form at the top right of every article page cover up the article that one is reading. It is very annoying to many people. --Timeshifter (talk) 22:22, 15 May 2012 (UTC)[reply]
New "diff" view is horrible and illegible
Please restore the normal "diff" view in bright colors that was so easy to read and discern. This new one with pale blue and even paler beige and otherwise white is ridiculously difficult to read, much less scan. Why do these things get tinkered with without discussion or rhyme or reason? It was perfect the way it has been for years so please restore it. Softlavender (talk) 03:25, 24 April 2012 (UTC)[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]
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]
(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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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. — Dispenser23: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]
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]
Feedback would be overwhelming here. This is where people complain. People without gripes don't always search for a forum to not-gripe in. ▫ JohnnyMrNinja20: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.EdinburghWanderer21: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)
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]
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]
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. ▫ JohnnyMrNinja01: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]
Apparently you don't. The new scheme is not usable by anyone with (reasonable) normal color vision; from what I understand, it's usable by people with the most common type of colorblindness. — Arthur Rubin(talk)16:54, 16 May 2012 (UTC)[reply]
I can't believe you mean to say that "The new scheme is not usable by anyone with (reasonable) normal color vision" because clearly many editors do use it. Presumably you mean to say it's *less* usable, or somesuch. - Jarry1250[Deliberationneeded]17:05, 16 May 2012 (UTC)[reply]
It's not usable to find the actual differences, although the paragraph display is still potentially usable to find the paragraphs that differ. My vision is not perfect, but, before I disabled the new version, I couldn't see the differences at all. — Arthur Rubin(talk)20:05, 16 May 2012 (UTC)[reply]
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]
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]
The problems I'm having is with RefToolbar 2.0, it's turned on in my preferences (and is supposed to work w/o having to add script to my preferences page), and the "Cite" button shows up on the enhanced toolbar in all the namespaces, except the main article space, when the "Edit" button is used. Does anyone know how to fix this? See also: Wikipedia talk:RefToolbar 2.0#Cite button. I use IE9. Thanks, --Funandtrvl (talk) 16:45, 14 May 2012 (UTC)[reply]
Today the MonoBook standard edit toolbar is painting correctly once again (yay, as the non-painted bar was really annoying). One difference on my end is the 12.01 update to Firefox, but since IE users had this problem too, I'm not sure whether the update contributed to the fix or not. Thanks, in any case, to all who worked on and fixed the problem. — Sctechlaw (talk) 09:07, 16 May 2012 (UTC)[reply]
Yes, I use IE9, but today I set "My preferences" back to default, and then deleted any custom css and js code from my vector skin. And voila, it works!! Now I just have to figure out which gadget or js code was causing the conflict, or if it was something changed behind the scenes here. :) --Funandtrvl (talk) 20:55, 16 May 2012 (UTC)[reply]
This is starting to happen to me, as of this morning. The "Cite" option comes and goes on the toolbar. However, I also have Provelt as a gadget preference - at the bottom of the page, not on the toolbar - and that comes and goes, but not necessarily in conjunction with the Cite option. Sometimes I have either-or, sometimes both are there, sometimes neither are there. And it just flips back and forth as I open Edit screens.Maile66 (talk) 12:29, 13 May 2012 (UTC) Reposted this at WP:REFTOOLBAR Maile66 (talk) 12:38, 13 May 2012 (UTC)[reply]
Cite not shown on the toolbar on top of the editbox
Can anyone explain why the cite option does not appear on the toolbar on top of the editbox as shown in the screenshot here. Although it should reappear after a reload but as said by some users even a reload is not helpful. This issue came up after a discussion here. Some light on this will be very much appreciated thanks--ÐℬigXЯaɣ06:02, 14 May 2012 (UTC)[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.—cyberpowerChatOnline20: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 Access17:57, 7 May 2012 (UTC)[reply]
Is this issue related to "session failure" errors with Twinkle? The error message reads: There seems to be a problem with your login session; this action has been canceled as a precaution against session hijacking. Go back to the previous page, reload that page and then try again. (Firefox 12 is my browser) Senator2029 (talk) 17:24, 13 May 2012 (UTC)[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".
I can check a database dump and see if any existing <poem /> instances would be likely to be affected by the first path (they might be affected if they have multiple spaces?). I don't think the second path (adding another element to the parser) is likely to be popular with the developers, nor do I think it's necessary. Cheers, — madman05:19, 13 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 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]
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]
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.
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]
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]
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'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]
I found this thread by searching Wikipedia help. I get this error while previewing edits for Heligoland. I don't know what, if any, display problems this is causing (there is nothing glaringly obvious), or how to go about fixing it, 86.179.113.84 (talk) 20:34, 17 May 2012 (UTC)[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)talk00: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)talk08: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]
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)talk01: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]
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... mabdul22: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]
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.
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]
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]
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. GRAPPLEX17: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]
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]
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]
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. --auburnpilottalk19:08, 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. —SMALLJIM20:48, 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. GRAPPLEX20: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. Narutolovehinata5tccsdnew02:16, 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. --auburnpilottalk19: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. GRAPPLEX19: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]
"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]
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. GRAPPLEX20:28, 10 May 2012 (UTC)[reply]
Or if people added the four village pump pages and WP:CENT to their watchlist, and actually kept abreast of what's going on, it wouldn't need to be. Why don't we just get rid of all these boards, the RfC process, and centralized discussion, and just place a list of upcoming changes into a banner that appears at the top of every page. I'm certain that this would not receive any complaints, and that nobody would minimize the banner until after reading it daily. - ʄɭoʏɗiaɲτ¢13:54, 13 May 2012 (UTC)[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]
Is this where I voice my support for these changes? We already have bold titles in recent changes for articles on your watchlist. Seems like there's precedence for bold titles in watch lists. Maybe it's unclear why they're bold but it's not ugly and certainly not hideous. Please do not take away the functionality for aesthetic reasons. If you pull your head out of your everyday experience, you'll see that the watchlist is already plenty ugly. I am often away from Wikipedia for days and before this feature I've had to manually track what I had and had not reviewed. I would prefer that bolding was used in both the watchlist and in article histories to indicate unreviewed changes. Failing that, please put some sort of unreviewed indicator near the links on the left hand side of the entries. I want the indicators to be near the links I click in response to seeing them --Kvng (talk) 13:35, 13 May 2012 (UTC)[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. GRAPPLEX19: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. GRAPPLEX19:31, 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]
I wouldn't compare bolding watchlist items to New Coke... The forced switch to the Vector skin, on the other hand... - ʄɭoʏɗiaɲτ¢13:57, 13 May 2012 (UTC)[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 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.
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]
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♠Dil21: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♠Dil14: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 only21:11, 10 May 2012 (UTC)[reply]
The stars were added by Edokter twenty minutes ago: [3]. 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. GRAPPLEX21:15, 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♠Dil21:17, 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♠Dil22:20, 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]
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 message21:14, 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]
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 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]
(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♠Dil21: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]
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. —SMALLJIM22: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]
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)
Yes, that tells me whether I've looked at the page (in my case) sometime during the last 30 days. That's not helpful if I want to know whether a busy page, like this one, has changed since the last time I looked at it, which was probably only a couple of hours ago. WhatamIdoing (talk) 02:19, 14 May 2012 (UTC)[reply]
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]
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: 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.522: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]
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. Nemo23: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]
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. SpinningSpark00: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 | Talk01:01, 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! Narutolovehinata5tccsdnew01: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. SilverserenC03: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]). --Nathan2055talk03:56, 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-C04: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 doktorbwordsdeeds07: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]
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]
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, LindsayHello13:40, 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 Stop15: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. Dcoetzee15: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. EdinburghWanderer16: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 Doom16: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. --Nemo06:06, 12 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. PamD18: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]
Opt-in. For experienced users, who typically have large watchlists and many high-traffic pages on them, there are too many cases where the natural reaction to a watchlist change is something other than visiting the page, making the whole idea of highlighting based on visited status not really useful. There should also less visually distracting ways of implementing the highlighting, if you wanted it. Fut.Perf.☼06:42, 12 May 2012 (UTC)[reply]
Opt-in Damn nuisance. I know what I'm doing in my watchlist. This refers to the bolding - I can't remember seeing any stars anywhere, green or whatever. Don't want any, either. Peridon (talk) 14:18, 12 May 2012 (UTC)[reply]
Support as opt-out feature. The first couple of times bold showed up on my watchlist for brief intervals, I couldn't figure out what it meant and the changes were distracting (maybe the feature wasn't working properly). However, in its full implementation I found it very helpful. New users who get this by default are unlikely to complain because they will find it helpful, but opt-out should be available. (PS - There are plenty of other recent interface changes that I find annoying, but this one was helpful.) --Orlady (talk) 15:30, 12 May 2012 (UTC)[reply]
Opt out. This will by far be most useful to new users and leaving it as an opt in absolutely defeats that purpose. As has been noted the default in email readers is for bold to be unread messages and many new users will be expecting that. There is no reason to disable or leave it as an opt in other than to take "revenge"(?) on the awful devs and to make sure that "your" way is the "right" one. Tradition is a terrible excuse to keep things stationary. Chico Venancio (talk) 06:42, 13 May 2012 (UTC)[reply]
Opt in This feature may be welcome by some, but I suspect more find it a nuisance than a benefit. Personally I have no use for this, since I check the diffs with navigation popups, not by clicking through to the articles. ThemFromSpace17:44, 14 May 2012 (UTC)[reply]
Change per Mirokado. Instead of seeing lots of green stars (the best version so far), have the script find either the last refresh of the watchlist page, or the earliest green-star change, and on that change line only, add a second (divider) line consisting of a horizontal rule with central text like "last visit 00:00, 00 Mmm 0000 (UTC)". Picking out a single HR rather than navigating the starfield is much clearer. Note: this applies in spades to the change listing "updated since my last visit" in green prior to every "(undo)" link, which is absolutely horrid. Looking for the earliest green line when it's not at the beginning or end of the line and looks almost black on a laptop is much much worse than an unobtrusive horizontal rule. (And when I look at the page via choosing a diff link in history rather than visiting the page directly, this "service" guesses wrong anyway, but that wouldn't be such a frustration with an easy-to-find HR). Sidenote: the vast sentiment for "opt-in" does not mean "opt-in" is the winner, it means the winner is "the UI guys tried too many changes too fast and scared us". If more discussion of technical capability occurs and more users are drawn in, a second straw poll would probably give a different result. The solution is that future major UI changes should get a dismissible announcement note where users can comment "hate it" during the trial period until people stop hating it. I hated italicized titles for a long time until I realized my concerns were illusory. JJB 20:15, 15 May 2012 (UTC)
Opt out Apparently some people think it has functionality, but many others including me find it both useless and annoying. I was finally able to figure out the instructions for deleting the stars and the green tag manually (I re-posted the method below in the "Now getting green 'updated since last visit' message in page history" section), but it shouldn't be that hard. Please provide a click-here button for those who want to turn off both new features: the bolding and the "updated since my last visit" tag. (At first I thought that was something which was being added by the editor making the edit, and I almost contacted them to ask "why are you using that as your edit summary?") --MelanieN (talk) 22:10, 15 May 2012 (UTC)[reply]
Opt-in. If other folk want it, then fine; but I don't, and cannot fathom why it should be imposed by default. Those who are least adept at dealing with UI tweaks and preferences are most likely to be uncomfortable with the change (this is why I'd say opt-in rather than opt-out). Personally, I'd treat an incredibly busy live environment as live, and restrict my tinkering to a test environment, but what do I know? bobrayner (talk) 09:14, 16 May 2012 (UTC)[reply]
Support this is a very useful feature for editors like myself who don't always visit Wikipedia every day. I don't understand what is so intrusive about titles conditionally being displayed in boldface. There is precedent for bold titles as an indicator in Special:RecentChanges. I request that bold be used as an indicator both in watchlists and in article version histories. --Kvng (talk) 19:39, 16 May 2012 (UTC)[reply]
Opt out or support (per Kvng) - this is great funkcionallity I know from other WM projects it relieves the user from lot of re-reading. Those who comment about having too much of pages in watchlist for this - I believe it just the other way, because I do have simply too much of pages in the watchlist I want to know instantly which of them I did visit already. I want this option back ASAP. please! Reo+20:26, 17 May 2012 (UTC)[reply]
A note about "opt-in"
Let's be clear; this feature only adds a marker to indicate that a page has been changed. I cannot imagine how that could not be good functionality. As for the styling, that has yet to be decided, but there is absolutely no reason to have it disabled in any way, just becuase of a conservative mindset. If everything new is made opt-in, the preferences section is going to be too overwhelming to new users. That is something we absolutely do not want. The feature is there based on earlier consensus. It was also decided the styling was to be discussed at a later date. Right now, all the nay-sayers want it disabled or made opt-in purely based on what it looks like, while not a single comment has been made on the functionality, so those comments are likely to be discarded pre-emtively.
So, let's be really constructive and decide how we want changes to be visualized, because there is one thing I can guarantee you: configuration options that have been enabled by default on this (or other) project(s) can and will never be opt-in. — Edokter (talk) — 08:04, 13 May 2012 (UTC)[reply]
Re "Right now, all the nay-sayers want it disabled or made opt-in purely based on what it looks like, while not a single comment has been made on the functionality, so those comments are likely to be discarded pre-emtively.": Aesthetics and functionality are inseparable in this case. When how something looks compromises its functionality, then there is a problem. I have the bold watchlist on Commons, and I don't take any issue with it; I only have a few things watchlisted, so the bold is pretty unobtrusive. Here, however, I have dozens and dozens of pages watchlisted. Logging in after a day and seeing a wall of blue and purple bold is just not helpful at all. The design impairs the usefulness. ~~ Lothar von Richthofen (talk) 21:06, 14 May 2012 (UTC)[reply]
Well, it would appear this one is opt-in as of now. As for which change specifically we're discussing, that's semantic. People clearly don't want the visual style that's been implemented here forced on them. That should be opt-in (and is right now) since the discussion on styling didn't take place beforehand, as it probably should have, especially if the need for that discussion was foreseen prior to implementation.
Seeing as the people have spoken, it would appear that the default visualization should be no visualization. I don't think those voting for opt-in care if some extra code they can't see is implemented, so that should stay. Visualization should be implemented as a preference/gadget, or set of them for different style options. Equazcion(talk)08:14, 13 May 2012 (UTC)[reply]
The fact that its opt-in is because some admins apparently feel intimidated by the current backlash. Had it been left in place, I'm sure most commenters would be accustomed by the change real quick (as some already have). The fact fact that the option was turned on took us all by suprise, so there was no time to discuss beforehand (it even looked like it wasn't going to be implemented at all). Now that it has been enabled, it is here to stay. Elen of the Roads has put up a survey page to poll the various options, and I'm interested to see where this is going. But again... opt-in is not an option, because configured MediaWiki behaviour should never be hidden by default. — Edokter (talk) — 19:33, 13 May 2012 (UTC)[reply]
We appear to have made it an option. Intimidating admins with backlash? Opt-in is not an option? Are you hearing yourself? First of all, if intimidating admins with backlash is what it takes to make the interface reflect community consensus, then so be it. That doesn't bother anyone (except the admins? and again who cares). Secondly, you're no one to say that anything is not an option, especially in the face of all this feedback. Third, Elen of the Roads had a very clear rationale for instituting the override, which she's expounded on repeatedly, and there was no intimidation involved (I don't think Elen is capable of being intimidated and you should apologize to her for suggesting as much).
Anyone who's looking at your responses here and following the situation can tell that you're feeling spited by the massive lack of support for something you were involved in. It must suck and I'm sorry. But don't start dictating what can and can not happen, nor brushing off the response as typical this or that. You can supply your input like everyone else, and implement the community's decision in the end; aside from that, please sit down. You're not in charge here. Equazcion(talk)19:43, 13 May 2012 (UTC)[reply]
No, we appear to be outraged over a configuration change, which triggered a change (by me) which was reverted, then disabled allthogther. People don't like the bolding? Fine. But when those same people demand it be disabled or made opt-in, they are purely expressing their personal opinions, without realizing the consequences for other people. As an admin, I realized I cannot allow that. I have to see beyond those opinions and their ramifications; making a core functionality hidden by default for all users, including new ones? I'm sorry... that's simply not an option.
Yes, I originally proposed the option be turned on, which was met with approval. But again, the community is not in charge of disabling/hiding functionality once enabled. I simply don't understand the outrage for something that can be really unobstusive. There is simply no point in making it opt-in. It only adds another layer of complexity that we can surely do without. — Edokter (talk) — 20:16, 13 May 2012 (UTC)[reply]
The community is in charge of interface changes, and you being an admin does not allow you to override a demonstrated consensus in favor of your own views of what's best. Call it outrage or whatever else you like, but your characterization of why the change is being rejected is of no consequence. It was claimed that a demonstrated consensus brought this change in the first place, not you (as it should be); and now a much larger consensus is now being demonstrated against it. So now it's off by default (as it should be). What to do now is being discussed, but barring another consensus to switch it back on by default in some form or another, it doesn't happen. It is not your place to declare that it should be on by default because you know better than everyone else. Adminship doesn't grant you that privilege. Equazcion(talk)00:21, 14 May 2012 (UTC)[reply]
The community is in charge of interface changes
Where's the policy that says that? I can't find one. More to the point, where's the agreement from the WMF that they agree with this statement? I can't find one, and I can find multiple counterexamples, e.g., the WP:Article feedback tool, which is definitely an "interface change" and which was definitely continued despite people yelling about how much they hate it. WhatamIdoing (talk) 02:29, 14 May 2012 (UTC)[reply]
WMF retains the right to override the community on nearly any issue, including interface changes (though they say in general they don't do that). I don't see any evidence that this decision comes from them. On the contrary, this was shown to have been enacted via a community discussion -- and an even broader community discussion now shows a different outcome. So it goes. Should the foundation decide to override it, we'll deal with that then. Edokter doesn't speak for them just because he's an admin, any more than I do. Equazcion(talk)02:40, 14 May 2012 (UTC)[reply]
Is it really that important that traditional users not have to check off one box to have their traditional style in place? 4 days of some users screaming in the Village pump is enough to constitute "clear consensus"?
Has anyone tried to scream at Google for making this behavior the Gmail default? At Microsoft for doing it in Hotmail? This hadn't been the default here for fear of performance issues but over at ptwiki and at others projects it has been used for ages. In fact users complained a lot over the brief time it was disabled in order to get better performance metrics about the new watchlist emails. But hey, the world will end if you have to check a box off to get old behavior back. Chico Venancio (talk) 17:04, 14 May 2012 (UTC)[reply]
There's a huge difference between emails, which are singular specific entities, and marking bold if you have simply not VISITED a page. As someone pointed out above, bolding the title of the article gives weight to the wrong thing. If I check my watchlist, and then go visit an article after the last change to read something, it's pretty dumb to have it not bolded because of that, don't you think? ♫ Melodia Chaconne ♫ (talk) 18:08, 14 May 2012 (UTC)[reply]
I don't think so. Articles are indeed distinct entities, as are changes, and the question of whether I've already seen them is as important as in E-mail. And yes, if I check my mail, and visit somewhere else and return, the one I've read is marked as been read. Easy to remember when it's only one or two to which I might return. Yes, marking things as been read is more important here in en than in either E-mail or Commons, because en is busier than either (for me, anyway) and this is where my old and feeble brain needs all the help it can get. Anyway, I've now got it thanks to the helpful note of User:Equazcion and it will help me in sorting out all the irritating little changes made by Helpful Pixie. However, the smarter editors than me ought to be the ones who have to dare to customize to omit this information. Jim.henderson (talk) 22:03, 14 May 2012 (UTC)[reply]
Significant comments about the opt-in vote appear in my vote above. JJB 20:15, 15 May 2012 (UTC)
Now getting green "updated since last visit" message in page history
Presumably this is linked to the changes made on watchlists but now there are green messages appearing on page histories indicating that the page has been changed since my last visit. Any way to opt out of this one as well? NtheP (talk) 21:50, 10 May 2012 (UTC)[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]
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]
I have the same opinion as HumphreyW: it's useful to have a line drawn across the revisions, not so useful to label every revision more recent than the last visit, given that there's already a lot of clutter on each line.
I have the same question: I don't find the green "updated since my last visit" note helpful, and I do find it annoying. Is there some way to opt out of it? I see that this subject has been here for the better part of a week, with questions but no replies; are the tech gods even listening? Update: For some reason someone just reverted my comment, without explanation. If there are instructions somewhere in this thread for opting out (maybe the line of code posted by Yair Rand?), they are not evident or helpful without more detail about what to do with that code or where to put it. --MelanieN (talk) 15:22, 15 May 2012 (UTC)[reply]
OK, I found some instructions many paragraphs above this one and I think they worked. Here they are, for those who like me came directly to this section, copied from above with the code pasted in:
Click "my preferences", and then click the "appearance" tab. There should be a line which reads "Shared CSS/JavaScript for all skins: Custom CSS | Custom JavaScript". The "Custom CSS" part should be a red link; click it to be brought to an edit screen for your personal CSS settings. It'll be blank as I'm assuming you've never created one. Paste in the code span.updatedmarker{display:none;} and save it; that'll create the page and apply that code regardless of which skin you're using. Check your watchlist afterwards to be sure it's worked.
Significant comments about why this is absolutely horrid and a horizontal rule would be much better appear in my straw-poll vote above. JJB 20:19, 15 May 2012 (UTC)
"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]
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]
Use a check mark instead of stars
A tick-mark (✓, ✔, ☑, etc.) for verified pages would make more sense to me. Not only is it less obtrusive, but the mark itself is mnemonic and clearer in meaning. The drawback is the need to insert a character in the text. Regards, RJH (talk) 18:25, 14 May 2012 (UTC)[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 • talk22:17, 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 • talk22: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]
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]
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. Nemo23:12, 10 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 • talk23: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]
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]
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]
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 improve01: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]
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]
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]
That page doesn't say what you attribute to it: «This page in a nutshell: Consensus is assumed when there's no evidence of disagreement». You need another essay to prove that lack of consensus is proved when there's evidence of disagreement. Thanks, Nemo07:28, 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. --Nemo23:24, 10 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
Wasn't the reported bug about an inconsistent behaviour and confusing info? I don't see any of that. Nemo14: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]
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]
No. The number of users who like and need the feature totally overshadows the number of complaining users. Moreover, the implementation debacle of hasty and confusing changes to the watchlist style by some admins totally overshadows the (supposed) benefits in terms of (unproven) consensus compliance. Nemo06:54, 12 May 2012 (UTC)[reply]
Community and consensus-focused development
If you want to spend some time raising awareness about problems with watchlist, why don't you spend a minute e.g. voting on one of these actual bugs? It's very annoying that attention is drawn on unimportant things the large community doesn't care about/agree on while the problems reported by the community sit unnoticed, isn't it? For instance, bug 9790 – Watchlist doesn't show earlier normal edits when hiding bot edits, own edits or minor edits. (Perhaps now no developer will fix such bugs, being afraid to be shot at by users who consider buggy software to be better than functioning software as long as it respects habits and tradition?) Nemo07:00, 12 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:. Nemo14: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. Nemo06:04, 12 May 2012 (UTC)[reply]
"Standard" really doesn't mean anything. It's the MediaWiki default and can remain that way, but nothing precludes a local community from overriding the default behavior.
I agree that a more focused discussion should take place. That doesn't mean that leaving the bolding on in the meantime is a good idea. For smaller watchlists, it's not so bad. But for active users with a lot of watchlist entries, the bold is simply overwhelming. --MZMcBride (talk) 15:27, 12 May 2012 (UTC)[reply]
I've never found it overwhelming even with tens of thousands of items in the watchlist, and I don't see how the number of items in the watchlist matters, it's more about the percentage of visible text which is bolded.
Why isn't holding the default in the meantime a good idea? As written elsewhere, users were already getting used to it, while now only very few users will ever notice this feature and propose something else if needed. Nemo18:39, 12 May 2012 (UTC)[reply]
When you have a larger watchlist, the percentage of bolded items is higher. Usually on a directly proportional basis. That's the overwhelming part. It's very similar to an e-mail inbox that you simply can't ever get ahead of. Not on a project as active as this one, at least. Meta-Wiki is manageable.
The underlining is vastly less awful. It gives a cue without punching the user in the face. I think it would make sense to use the bold for users with smaller watchlists and something less awful for users with larger watchlists. This could be accomplished through a user preference, implicit controls (less than 1,000 items, bold, etc.), or some other means.
That said, this is actively causing a problem for established users, so it should be a fairly high priority to make the site less awful for them. When you have the chief tech guy at Wikimedia posting hacks to make the site less awful, you really question the default, at least as a default for everyone using the site. But obviously Erik's focus is the entire site while my focus is largely people like myself (users with large watchlists). --MZMcBride (talk) 18:50, 12 May 2012 (UTC)[reply]
The size of watchlist should be proportional to your interest/ability to follow it; if it isn't, and "unread" items just increase and increase, there's something wrong in yor selection, very similarly to how an inbox as described by you would be plainly broken, and not by its style.
I don't know what Erik's intervention means, I agree that established users should be heled and I think the update markers are very useful for those with a big watchlist (unless they have the memory of Pico della Mirandola). Speaking of the style, I agree of course that it could be changed, although it's difficult to imagine something better than bolding; see for instance the recent comment on #A note about "opt-in". Nemo18:36, 13 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]
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? Rd232talk11: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. Rd232talk12: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. Rd232talk12:12, 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]
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]
Not talking about design by consensus. I talking about sign-off and process (i.e. going about it in the right way). --RA (talk) 01:23, 13 May 2012 (UTC)[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 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. Nemo06: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
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 | Talk01: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]
Just to say I was happy when I refreshed my watchlist this morning and the dreadful bolding went away :) Thank you for your work on this. Secretlondon (talk) 10:24, 12 May 2012 (UTC)[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]
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]
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. Nemo06:25, 12 May 2012 (UTC)[reply]
It's not absurd. The burden of consensus lies in making the change to begin with. There doesn't actually need to be consensus to roll it back when there was no demonstrated consensus to implement it in the first place. Equazcion(talk)08:26, 12 May 2012 (UTC)[reply]
There was consensus to enable the feature, and there's no consensus to disable it (in fact no complete disabling has been asked to the devs). There's no consensus for any particular style other than the default one, which should be restored until a proper consensus has been found on an alternative. --Nemo13:07, 12 May 2012 (UTC)[reply]
A good many people would seem to disagree with you that there was adequate consensus, and that said consensus was for the change the way it's actually been implemented. The discussion wasn't very widely advertised nor did it get broad participation. Many of the support !votes it did get were on the condition that a preference be added for it too. Equazcion(talk)13:13, 12 May 2012 (UTC)[reply]
My bolding seems to be gone, thankfully, but I would like to point out I never heard of this so-called community discussion. This was a hijacking by a minority. In the future, everyone should hear about this sort of discussion...Smarkflea (talk) 17:56, 12 May 2012 (UTC)[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;
}
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]
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.—cyberpowerChatOffline03:17, 12 May 2012 (UTC)[reply]
Now we're cooking on gas. Figured out what the problem was, thanks Cyberpower
Of course, you could also just use plain CSS to remove the button: form#mw-watchlist-resetbutton { display: none }. Nageh (talk) 11:16, 12 May 2012 (UTC)[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]
«I hated the bold at first, but now find it extremely useful» (bold added ;) ). Yeah, such a common and obvious thing. Too bad that the bold has been disabled for everyone and now the vast majority of users who would like it will never discover it, only because a tiny minority complained about it being unable to wait for a day to get used to it (as all MediaWiki users already are). Nemo06:37, 12 May 2012 (UTC)[reply]
Yes, as someone experienced in change management I have to say that the reactions here should have been expected, and not over-reacted to themselves. Very shallow behaviour on both sides. Sad. It was a good change. HiLo48 (talk) 07:02, 12 May 2012 (UTC)[reply]
Many of us are experienced there too, as can be especially said for Elen of the Roads. As much as a negative reaction could've been expected, not every negative reaction is merely par for the course and should be brushed off as such. This one was more warranted due to the flawed development cycle it resulted from. Firstly, the change wasn't discussed (or was barely) -- and even though that usually isn't something users of a site are brought in on, it is something that has to happen here; the developers are not supposed to have the power to decide on changes merely due to their technical ability to implement them. The change was also not tested on a pool of this project's audience in beta fashion, and was instead tested live, where it was also rapidly tweaked several times, again with no testing. This rollback isn't a judgment of the feature or a mere reaction to outcry, but I would say in part it's a demonstration of the fact that Wikipedia is not Facebook. We're a community that discusses and decides on interface changes ourselves, rather than having them thrust upon us. When a more proper discussion and test occurs, or it is simply provided as an extra opt-in feature (or at the very least an opt-out, as even that wasn't provided), a less contentious rollout of this feature (or one like it) can then occur. Equazcion(talk)08:10, 12 May 2012 (UTC)[reply]
Now, is there any way to get in the history pages unread from the last visit back on a green background, like it it done on Commons by default?--Ymblanter (talk) 07:22, 12 May 2012 (UTC)[reply]
I think Elen's CSS code above is supposed to remove those too, but I updated my script to remove them as well: add importScript('User:Equazcion/RemoveMarkAll.js'); to your skin's .js page if you want to try it out. It also removes the "Mark all" button on your watchlist, since that would be useless if you don't have the bolding (or similar) enabled. Equazcion(talk)08:20, 12 May 2012 (UTC)[reply]
Actually, I do not want to remove them (an Ellen's code does not remove them), I want to make them stronger (like it was yeaterday for a couple of hours - black text on green background). I am on the side which likes the new appearance.--Ymblanter (talk) 08:24, 12 May 2012 (UTC)[reply]
Thanks for all the code guys, really appreciated. Could someone please tell me how to remove "updated since my last visit" from when I'm looking at the history of a page (I'm on vector)? Jenks24 (talk) 07:38, 12 May 2012 (UTC)[reply]
(I meant to reply to this comment originally instead of the one above) You can add importScript('User:Equazcion/RemoveMarkAll.js'); to your skin's .js page. This also removes the "Mark all" button on your watchlist, since that would be useless if you don't have the bolding (or similar) enabled. Equazcion(talk)08:20, 12 May 2012 (UTC)[reply]
Yes, I am using that to get of the button (thanks). But what I'm asking about is when I look at the history of a page I am seeing "updated since my last visit" in green next to edits that have occurred since I last looked at the page; how can I get rid of that? Jenks24 (talk) 08:53, 12 May 2012 (UTC)[reply]
Yes, I updated my script since I first advertised it here -- it should now be removing those green notices on history pages too. Try hitting Ctrl-F5 to make sure the update is in effect. Let me know on my talk page if it's still not working. Equazcion(talk)08:57, 12 May 2012 (UTC)[reply]
Actually, that's only one part of the issue. Fact is that many users are not technically comfortable in using all these scripts (and since they're on individual user pages, it is impossible to ensure that they are all updated properly - which is a major problem). As well, even if people are comfortable in using them, they may have technical reasons why they are suboptimal. I've wound up disabling almost every script I ever put into my .css because it did not function properly due to some interaction with (a) other scripts or (b) something in a mandatory hardware or software setting. Gadgets work okay, most of the time. So they should either be gadgets (which are usually maintained and kept compatible with upgrades), or standard.
In the case of this particular change, I believe that the main reason there are so many complaints is that so many of the editors on this project are using skins other than Vector - in fact, I think I saw a stat somewhere that said over 70% of users who were editing pre-Vector continue to use Monobook or some other skin. This change looks fantastic in Vector, but is less pleasant on Monobook (the bolding goes beyond making the entries stand out, and can make it difficult to pick out the unbolded entries). Probably what needed to be done here was tweaking of the non-Vector skins - I note there isn't much discussion of what skin/OS/browser was being used that might relate to this issue. Risker (talk) 15:41, 13 May 2012 (UTC)[reply]
Good point about different skins. Each skin can of course have its own sitewide default. I did suggest over in The Other Place This Discussion Is Also Happening (For No Obvious Reason) that we make a gadget to apply the styling, so everyone can do what they want, and then collect stats on user choices to inform the default. If we did that we should be able to collect data split by skin, so different skins can have different defaults. On the other hand, if we do Elen's survey, that's a lot of screenshots (different options for different skins)... Rd232talk16:45, 13 May 2012 (UTC)[reply]
Good point. Should add that to the survey. I use modern, and it looked bloody awful - exactly the same as Truthkeeper's description of a migraine attack. So an alternative would be to check in each skin and alter the css to get a toned down effect. I do think there is a style out there that is sufficiently unobtrusive for most people not to be bothered if it is on or off - we just have to find it. Elen of the Roads (talk) 18:38, 13 May 2012 (UTC)[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]
The ability to highlight the changes is still there. See above, or the page below, for plenty of ways to customise it to suit your eyes and watchlist. If you need a hand, give me a ping. I'm hoping we can get some kind of gadget out of this that just allows people to pick from options, which is what the original discussion actually wanted. --Elen of the Roads (talk) 12:54, 12 May 2012 (UTC)[reply]
I don't want to ping anybody. I liked the change. I can never find options and gadgets on this far too complicated site anyway. Don't make this a site for nerds. Make it friendly to newbies. HiLo48 (talk) 08:25, 13 May 2012 (UTC)[reply]
The style used seems to have caused a lot of people to have accessibility difficulties. Part of that seems to be that the entries on the watchlist are on a tight linespacing, and part that the colours are very bright. I'm betting there's a style out there that most people would find non-intrusive enough to accept as the default, but it'll be less bright. It's unfortunate that there isn't a simple way to switch it on/off, as this would end all these arguments, but there isn't. It's either on for the whole wiki or off for the whole wiki. --Elen of the Roads (talk) 14:58, 13 May 2012 (UTC)[reply]
How about this as a default (for the watchlist part only). Others can remove or adjust. The lime underline is minimally visible in the line spacing and doesn't seem to have any reducing effects on that (even the grey one seems fine to me). I think new users will never know about it if we make it an opt in feature. --lTopGunl (talk)15:27, 13 May 2012 (UTC)[reply]
Communication suggestion now posted at User:Elen_of_the_Roads/Watchlist_survey. Comments, brickbats etc here or at Wikipedia:Village_pump_(proposals)#Next_steps. We have to put out something to let users know that the facility is available should they wish to use it. At the same time, some of the folks who took part in the very first discussion are still of the opinion that it should just be switched on as most users either like it or would get used to it, so we need to find out if that is the case as well. --Elen of the Roads (talk) 12:13, 13 May 2012 (UTC)[reply]
Final version with images now done. I'll leave it 24hrs for comments (I notice people have started to fill it in), then move it out of userspace and ask for a watchlist notice, unless anyone objects. --Elen of the Roads (talk) 00:30, 14 May 2012 (UTC)[reply]
Real life has intruded
I'm having r/l time issues. Could someone ship this out into rfc space and list it to see if we can have a watchlist notice. So we don't lose any more time. Elen of the Roads (talk) 21:04, 15 May 2012 (UTC)[reply]
Fake Edit Summaries
A request was made above for a way to disable the fake edit summaries that came with this change. I for one would really like a way to do so, as its extremely annoying when you have an edit occur with no summary, and then look to see what the justification for the edit was, only to find the stupid message informing you the change occured since you last looked, which as your looking is REALLY OBVIOUS. So is there a way to get rid of them? Monty84518:35, 13 May 2012 (UTC)[reply]
It appears that this template ({{Help me}}) is being used somewhere other than a talk page. Please remove this instance of the template.
This template is meant for use on talk pages. Your user talk page can be found here. If you added this template, please remove this template and re-add it on your user talk page. If you did not add this template, please remove it from this page.
I think the turning off of bold text has something to do with overriding the js scripts which no longer bold the specific links. Is there a way around that? Shouldn't this be fixed? --lTopGunl (talk)01:32, 14 May 2012 (UTC)[reply]
I think you need to explain the question better. Bold text where. What links. If you mean watchlist links, the whole (lengthy) explaination is either above or in the archive. --Elen of the Roads (talk) 21:05, 15 May 2012 (UTC)[reply]
I'm using User:Ais523/watchlistnotifier.js which notifies of changes on the watchlist while being on other pages as well as bolds the lines that appear after last reload of watchlist. After the the watchlist changes were enabled (which bold the unvisited pages rather than just the newly loaded ones) and the was set to normal text as default... I chose to use a subtle underscore version of it so that the new changes after reload can still be bold and do not confuse. The issue is that the new lines are still getting a bold font as per the script minus the page titles in the watchlist which if unvisited do not get bold even though the js script is set to bold the full line. --lTopGunl (talk)21:44, 15 May 2012 (UTC)[reply]
Restore watchlist bolding after the new change to Common.css on May 17
Is this the right place, or has a whole page somewhere been devoted to this topic? Anyway I woke to find that my bolding had gone away. This was a valuable tool. It didn't come back even when I inserted the necessary material into User:Jim.henderson/vector.css. Help; I am much more easily confused going through my excessively long recent changes list without the system telling me which of the hundreds of changes I've already seen. Jim.henderson (talk) 09:50, 17 May 2012 (UTC)[reply]
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]
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]
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]
@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 improve01:30, 11 May 2012 (UTC)[reply]
Collapsed an exchange regarding the watchlist change, rather than this proposal
The following discussion has been closed. Please do not modify it.
Well, most of this stuff *is* beta tested - how many people who have posted here today on this page have *ever* participated in beta testing of various features? The bolded watchlist has been enabled on quite a few projects for a while, for example; it's not like it's an unknown quantity. The green stars I missed entirely, though. Risker (talk) 02:30, 11 May 2012 (UTC)[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) mabdul12:47, 11 May 2012 (UTC)[reply]
Support Surprising features and changes that break established functionality should be kept to a minimum. Having a beta skin seems like a good way to test many changes (and announce implemented features to the community) without breaking the 'pedia. --PhilosopherLet us reason together.20:14, 13 May 2012 (UTC)[reply]
Support I sometimes like to use betas if they're reasonably stable. When it's something I use regularly, it makes an interesting variation, and I like to see ahead what might be coming--not just as a discussion of it, but the intended implementation. But I also want to know what I'm doing, so if I am doing something important I want to do as quickly and routinely as possible, I can use the regular program and count on everything being the same as usual. DGG ( talk ) 21:57, 13 May 2012 (UTC)[reply]
Strongly support: major changes should not go live without testing. Some major changes require direct user experience in the editing environment before they can truly garner consensus. Fifelfoo (talk) 02:19, 15 May 2012 (UTC)[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]
I have seen this bug before as well. The ACIP tests should probably just be shut down so any permanent enhancements can be worked on. Thanks for bringing this up, Steven Walling • talk23:40, 12 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). SpinningSpark19: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]
And now, for something slightly different… it's down again ! :-)
“Request: POST http://en.wikipedia.org/w/index.php?title=Montreal&action=submit, from 81.57.201.53 via amssq41.esams.wikimedia.org (squid/2.7.STABLE9) to 91.198.174.41 (91.198.174.41)
Error: ERR_READ_TIMEOUT, errno [No Error] at Sun, 13 May 2012 18:21:42 GMT”
Just a suggestion: If I go to Special:Search I have to place the cursor into the search box. It's an extra step, and for someone (me) that doesn't use keyboard shortcuts it means maneuvering a mouse to the box, and clicking, then returning my right hand to the keyboard. Not a web writer, but I know that it's easy to add a line of code so when the page opens the user can just type in the search term. Just a suggestion... — Preceding unsigned comment added by Bennoro (talk • contribs) 17:30, 11 May 2012 (UTC)[reply]
This FAQ answer deals with the main Wikipedia page, where it makes sense not to auto-land the user in the search box, because there are a lot other things to see on the page. [Although personally I would like the auto-landing in the search box on the main page. Can I have it ?] But this FAQ answer does not apply to the page Special:Search ; on this page, there is only one interesting thing : the search box.
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? Brandmeistertalk23:10, 11 May 2012 (UTC)[reply]
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.
Raising issue again: Page exceeded the expansion depth
Category:Pages where expansion depth is exceeded continues to gain entries (310 subcategories and 12,363 pages as of now). All the articles that I've checked don't have obvious expansion depth errors, i.e. all the templates appear to have produced the correct output and not terminated early. Is anyone investigating this situation? Should it be reported elsewhere? Peter coxhead (talk) 08:28, 12 May 2012 (UTC)[reply]
Many templates will only produce something at the deepest expansion levels in certain circumstances, for example some string templates when the strings happen to have certain lengths (not necessarily the longest), so it's hard to tell from the result whether all templates were completely evaluated. Evaluation will only skip the expansion levels which are too deep. Later code of the template with less expansion can still be evaluated. And the red error message "Expansion depth limit exceeded" is only produced in some circumstances. I guess it happens when whatever could not be expanded was supposed to be rendered. If it's elsewhere like in a condition then there may be no indication beyond the category that the expansion depth was exceeded. Unless somebody can produce an example where manual evaluation of the code indicates that the 40 levels should not have been broken, I will assume the category is generated correctly. PrimeHunter (talk) 13:21, 12 May 2012 (UTC)[reply]
Those of us making regular use of {{clade}} have been nesting it to produce trees (cladograms) with leaf nodes up to 20 deep. Leaf nodes at depths of 21 and above don't appear; a red error message may or may not be produced. Testing shows that actually only trees (cladograms) with leaf nodes up to 19 deep don't exceed the expansion depth limit. A cladogram with leaf nodes exactly 20 deep renders the deepest node, but generates an expansion depth limit.
So, if I understand correctly, this means that after outputting the node of depth 20, the software attempts to expand something which would not produce any output (e.g. a #if: expression which would generate an null/empty result). This fails, but doesn't matter as far as the output is concerned.
Does it matter if pages do this? Is there an extra cost to exceeding the expansion depth limit if it is certain that no output has been lost? Peter coxhead (talk) 20:00, 12 May 2012 (UTC)[reply]
The software doesn't evaluate expansions beyond level 40 so it doesn't know what they would have produced if they had been evaluated. See meta:Help:Expansion depth. When the 41st expansion should have been made, the software produces <span class="error">Expansion depth limit exceeded</span> at that place in the wikisource instead of evaluating the expansion. It gives the same result as if the 41st expansion in the wikisource had been replaced by the code <span class="error">Expansion depth limit exceeded</span>. What that result is depends on the context. For example, if the 41st expansion would have been rendered unaltered if it had been text then <span class="error">Expansion depth limit exceeded</span> is rendered. This produces Expansion depth limit exceeded with the way the error class is defined. If the 41st expansion is the condition part in an #if then the #if evaluates to true because the produced <span class="error">Expansion depth limit exceeded</span> is non-empty. PrimeHunter (talk) 22:48, 12 May 2012 (UTC)[reply]
It appears a lot of the articles in Category:Pages where expansion depth is exceeded are caused by analysis of the image_plan/Lageplan parameter in {{Infobox German location}}. If all other parameters are removed then the category is still there. If the parameter is removed and everythning else kept then the category disappears. The infobox code includes:
|<!-- Test whether an imagemap template exists, using the district code in the location map file name (field "image_plan" or "Lageplan")
-->{{#ifexist: Template:Imagemap Germany district {{#ifeq:<!--
The district code is extracted from the file name, with a special case when the district code is only one letter, e.g. "V"
-->{{str find|{{substr_any|{{{image_plan|{{{Lageplan}}}}}}|{{#expr:{{str find|{{{image_plan|{{{Lageplan}}}}}}|.svg}}-4}}|3}}|n}}|1|<!--
The district code has only one letter
-->{{substr_any|{{{image_plan|{{{Lageplan}}}}}}|{{#expr:{{str find|{{{image_plan|{{{Lageplan}}}}}}|.svg}}-2}}|1}}|<!--
The district code has two or three letters
-->{{substr_any|{{{image_plan|{{{Lageplan}}}}}}|{{#expr:{{str find|{{{image_plan|{{{Lageplan}}}}}}|.svg}}-4}}|3}} }}|<!--
The imagemap template exists, and is used
-->{{Imagemap Germany district {{#ifeq:{{str find|{{substr_any|{{{image_plan|{{{Lageplan}}}}}}|{{#expr:{{str find|{{{image_plan|{{{Lageplan}}}}}}|.svg}}-4}}|3}}|n}}|1|{{substr_any|{{{image_plan|{{{Lageplan}}}}}}|{{#expr:{{str find|{{{image_plan|{{{Lageplan}}}}}}|.svg}}-2}}|1}}|{{substr_any|{{{image_plan|{{{Lageplan}}}}}}|{{#expr:{{str find|{{{image_plan|{{{Lageplan}}}}}}|.svg}}-4}}|3}} }}|<!--
No imagemap template exists, a normal location map is used
-->{{{image_plan|{{{Lageplan}}}}}}|240x240px}}|[[Image:{{{image_plan|{{{Lageplan|Dummy flag.png}}} }}}|240x240px]] }}
}}<!--endifeq image_plan=x -->
It uses string templates to make the test mentioned in the opening comment. Something should be modified to use fewer expansion levels but I'm not trying to do it. PrimeHunter (talk) 14:54, 12 May 2012 (UTC)[reply]
Hmm, that's a pretty hardcore piece of code. But the underlying principle is fairly straightforward, and it should be possible to simplify. It's not surprising that there are depth problems; that last {{str_find}} at the end is seven levels deep just in the fragment you've copied. Happy‑melon23:37, 13 May 2012 (UTC)[reply]
Implementing a template that routinely violates such a limitation (by "routinely" I mean, violates the limit when transcluded at or near a depth implied by its intended functionality) is itself a coding error which must be detected and corrected during testing. That is what we have sandbox and testcases pages for. --Mirokado (talk) 22:20, 13 May 2012 (UTC)[reply]
But there's a difference between a template which when used once (i.e. not nested) generates such an error and one like {{clade}} is designed to be used nested, i.e. like this:
We can't re-write {{clade}} to prevent an editor nesting it more than 19 times; the documentation only can advise not doing so and suggest checking the message during preview. Peter coxhead (talk) 22:54, 13 May 2012 (UTC)[reply]
Thanks for the recap. FWIW, the expansion depth problem goes away in the Southwest Chief article I mentioned if I take out the route map, which suggests the problem is in either {{Infobox rdt}} or {{Southwest Chief}}, probably the latter (or perhaps a design issue about the layering of templates). Same problem with Adirondack (train) and {{Adirondack}}. I see no consensus that this matters, but if it does, maybe a template editor active in WP:RR might be interested in tackling it. 68.165.77.170 (talk) 03:26, 14 May 2012 (UTC)[reply]
Random text insertions
I've been active on Wikipedia for quite a while and I've never had this problem before: on two separate occasions, after editing an article, a random piece of text or a reference gets inserted somewhere in the article. I certainly didn't do it myself, I didn't even edit those paragraphs nor did I CTRL-C them; I've also checked my computer for viruses (it's clean) and I've got a firewall in place. Might this be a server-side error? Examples:
[5] (the insertion of the 'kidnapping' item was the intended edit; the insertion of the random reference in the middle of the word "Latakia" wasn't)
[6] (replacing the wrong diacritics with the right ones was the intended edit; copying the article's "language sample", "see also" and "notes" sections and pasting them randomly in the references section wasn't)
Looking at some of the explanations on the WP:Reference desk subpages (esp. mathematics) and feeling they'd at times be more easily understood with a diagram, plus at times me too wanting to sketch things in explanation but not having a suitable tool for generating a PNG/SVG, I find I long for a text-editable TeX-like language supported by WP for putting together quick diagrams, as well as for producing simple diagrams for articles. I guess the best starting point would be some existing language of this nature (as was the case with TeX), but am not personally familiar with such. Is anyone aware of something along these lines that could sensibly be adapted for use on WP? — Quondum☏08:53, 13 May 2012 (UTC)[reply]
In principle, TeX supports drawings with the picture environment. It is, however, fairly horrible - so horrible that I have gladly forgotten all about it. Likewise, SVG can be hand-written, though I've never tried. For tree- and graph-like applications, I found the DOT language to be very useful. --Stephan Schulz (talk) 09:40, 13 May 2012 (UTC)[reply]
SVG is easy to understand, but easily gets complex with all the XML nesting. I suppose any such functionality won't come anytime soon. If it will, be sure that many will complain about its complexity and demand a visual editor, which probably will never come given the delay of the promised WYSIWYG editor. Nageh (talk) 09:48, 13 May 2012 (UTC)[reply]
Thanks for bringing me up to speed on this. I get the impression that the most workable option for WP for some time to come will be SVG. I see that SVG-edit, as a generally available browser-based editor that I had not been aware of, may actually allow one to easily edit pictures created by others; I should perhaps look into this a bit more closely for the intent that I described. — Quondum☏10:40, 13 May 2012 (UTC)[reply]
(ec) It was an extension of <math> that I was thinking of for simple diagrams, graphs etc. beyond the normal formula-expression capability (such as TikZ seems to give). There are times when words become a little clumsy when explaining to someone who is a little scared of or unfamiliar with math. Once one can assume a math-comfortable reader, the utility of diagrams diminishes, but simple diagrams still seem to have a place. — Quondum☏11:09, 13 May 2012 (UTC)[reply]
Thanks for the info -- I tried logging out, and also disabled Adblock Plus which I have installed, but I still didn't see any feedback/encourage thing or the improve link. I guess you're saying it should show up and this must be a client-side browser issue for me. I do see it from time to time though on random articles. Guess I'll tinker with my settings and see. Equazcion(talk)13:36, 14 May 2012 (UTC)[reply]
Looks like it shows up for me in Chrome, whether I'm logged in or not, with adblock enabled -- but not in Firefox (12) at all. Odd. Equazcion(talk)13:45, 14 May 2012 (UTC)[reply]
Can I request that people please not add this to articles? One of the reasons it's deployed so rarely is because we're still testing it, working out issues and (most importantly) doing research. Adding and removing articles from the categories alters the sample, which is not good for data reliability. Okeyes (WMF) (talk) 12:42, 15 May 2012 (UTC)[reply]
Oh, you're just using the additional articles? Yeah, I'll clarify that. That category is basically "really high-profile stuff so we can investigate the worst case scenario". Thanks :). Okeyes (WMF) (talk) 13:08, 15 May 2012 (UTC)[reply]
Another matter, IP's and everybody else get to Wikipedia:Article Feedback Tool/Version 5/Help/Feedback page Editors by clicking "?" and then "Learn more >>" in the "Help improve this article" box at ATFv5 pages, for example at the bottom of Eduardo Saverin. It starts with This is a help page for the willlink|Article Feedback page, aimed at those with the "oversighter" userright. If you are seeing this and do not have that userright, or have any questions about the tool, please email okeyes@wikimedia.org. But everybody can see that text. Later it makes reference to seeing feedback which I don't see but I'm not an oversighter. Also, the whole page assumes there is feedback, but ATFv5 currently has no feedback feature. It only encourages editing. PrimeHunter (talk) 13:18, 15 May 2012 (UTC)[reply]
Good points all; I'll try to get to them in a tick (I'm stuck in the Netherlands datacentre and my laptop is dying. So many machines, none useable!) Okeyes (WMF) (talk) 13:20, 15 May 2012 (UTC)[reply]
Okay, it turns out that the answer to the first point is "Ollie is an idiot"; I misunderstood the restrictions on adding articles to the categories. You're welcome to add things to "additional articles"; so sorry for all the fuss! The other things are on today's to-do list. Okeyes (WMF) (talk) 06:37, 16 May 2012 (UTC)[reply]
I asked this at the help desk and was told to bring it here...
I need to import a template to Wikibooks that will turn a name of a script into its ISO 15924 code. (For example, Latin → Latn). There are many ISO 15924 templates on Wikipedia, but I am not sure which one does what I want. Please advise on the one that will best do what I want. Thanks, Liam987 14:16, 10 May 2012 (UTC)[reply]
I think you will need to modify an exsiting template such as {{ISO 15924 alias}}. Copy the wiki-text to a text file, swap the parameter/value pairs, and save the new template with an edit summary like "Saving new template based on [[:en:Template:ISO 15924 alias]]". Note that the inter-wiki link may need to be modified. – Allen4names16:02, 14 May 2012 (UTC)[reply]
Navigation popups aren't working for me now. Anybody else?
Also, the edit toolbar seems to be on the blink of late. Sometimes it appears, sometimes it doesn't. JN46613:13, 15 May 2012 (UTC)[reply]
Updating numbers of edits on the Home page
Hi
Is there any reason why the numbers of edits on the WP home page (The one with the globe) is stuck and does not update automatically? Just now the English language is showing some 40,000 pages less than it really is! Thanks Apwoolrich (talk) 19:45, 14 May 2012 (UTC)[reply]
I am unable to leave a summary when moving a page. Anyone else having this problem? The form doesn't accept text on my browser. — Martin (MSGJ · talk) 20:48, 14 May 2012 (UTC)[reply]
The move reason field is broken in Opera as of mw1.20wmf2, something about an errant javascript or some such preventing any input. Someone who feels comfortable doing so should submit a bugzilla thingy. -— Isarra༆05:27, 15 May 2012 (UTC)[reply]
Yes, it was opera I was using. Thanks for the information. A bug should certainly be submitted. I'll take a look. — Martin (MSGJ · talk) 14:03, 15 May 2012 (UTC)[reply]
Michelle Paulson, Wikimedia's Legal Counsel has been sent an email about this, so the Legal and Community Advocacy (LCA) team are working on it. Thanks. TheHelpfulOne22:18, 14 May 2012 (UTC)[reply]
Yes, I sent it to her, or maybe one of more than one. However, I was surprised to see the new message banner pop up, something I've never seen on a mirror.--SPhilbrick(Talk)22:25, 14 May 2012 (UTC)[reply]
Makes me want to think that it is a mirror that simply iframes Wikipedia with some modifications (the changes made to the HTML are not that hard to make via scripting). This is the kind of mirror that the WMF hates.--Jasper Deng(talk)22:27, 14 May 2012 (UTC)[reply]
There are web services such as rikai.com or zurukko.jp that add similar functionality to any web sites. I don't see a point for creating a Wikipedia specific service. --Kusunose08:04, 15 May 2012 (UTC)[reply]
Jpgordon: Pass any Japanese text through Google Translate, and the results are likely to be odd (and occasionally hilarious). Jafeluv (talk) 10:38, 15 May 2012 (UTC)[reply]
Problems in categorization of BLPPRODs "by days left", any template magic
But it's never worked correctly or that usefully at that. I kinda get why, but I'm too much of a template newbie to necessarily explain it well--roughly speaking the "number of days left" is only recomputed when the article is actually modified. Cache purge doesn't do it. So there are "expired" articles marked with 8 days left. While there's no hurry, it's a problem for people looking through the BLPPROD pile looking for things to put effort into, an accurate days left count would be a significant benefit to that triage process.
It certainly seems unwise to rely on articles automatically being re-categorised each day.
Maintenance templates are usually sub-categorised according to the month of transclusion, which results in a steady but slow increase in sub-categories.
Some possible workarounds:
You could similarly sub-categorise according to the date of nomination, but that would create numerous sub-categories (a new one every day).
Instead of using the initial digit (in the category sortorder) to indicate the number of days outstanding, perhaps you could extend this to an initial letter to indicate the day of the month that the article was nominated (eg 1 to 9 for the 1st to the 9th, then A to V for the 10th to the 31st).
As a compromise between the above options, you could create 31 sub-categories, and have rolling sub-categories for the day of the month of nomination (but not sub-categorise the month or year).
Thanks for the brainstorming, folks. The thing that concerns me about the bot is the effect on article history. A moderate fraction of articles do survive the BLPPOD processW, it'd be a shame to leave ten null edits clogging the histories there. Perhaps every other day would be a better compromise.
Subcategory by, say, nomination date or expiration date has some real advantages, and the cleanup of empty categories strikes me as easy bot-based maintenance.
Move the "mobile view" link from bottom of page to the top
for the love of god can someone move the "mobile site" link from the bottom of the page to the top. Its a stupid place to put since one has to load entire damn page to get to it, THEN switch to mobile since I'm no longer automatically directed to the mobile wikipedia on my itouch anymore — Preceding unsigned comment added by 24.118.60.18 (talk) 12:27, 15 May 2012 (UTC)[reply]
If your not getting automatically redirected then this is a totally different issue. Clear your cache and then follow this link .. It'll make it permanent — Preceding unsigned comment added by Tfinc (talk • contribs) 19:02, 17 May 2012 (UTC)Tfinc (talk) 19:04, 17 May 2012 (UTC)[reply]
Check out the edit I just made. The class should be "wikitable sortable". I also removed the inline CSS that defines the style for the header row – this overwrote the wikitable sortable styling so the sorting was removed. I've only fixed one section, but feel free to go ahead and do the others. matt (talk) 13:49, 15 May 2012 (UTC)[reply]
And note the exclamation marks used to distinguish header cells in the first row from data cells in subsequent rows. (Also, it's probably best not to specify the widths at all, as different readers will have browsers with very different screen widths.) — Richardguk (talk) 14:00, 15 May 2012 (UTC)[reply]
Thank you both. It would appear the exclamation marks by themselves were the bugger. I've created some tables, but when something doesn't work, I know what I did. It's harder to spot something like this after-the-fact tables-by-committee contributions over the years. Thanks a lot.Maile66 (talk) 14:06, 15 May 2012 (UTC)[reply]
Major problems with new Wikipedia mobile site - Please revert back
Someone posted this in another section and didn't re-post this here, so I am doing it for them. I am also having major problems on the new mobile site on my Android phone that mirror these and make it nearly unusable. It worked fine before!!
The new Wikipedia mobile website is really bad. It has many problems when viewed on Android mobiles:
If you scrolll down while the page is loading, it scrolls back up to the beginning after page loads, unexpectedly. Why does it forcefully scroll the page when the user didn't request it?
The arrow button (in each section for "Show more content") is hard to press, because it's too small. The previous version had a proper "Show" button which was bigger.
Sometimes the full content doesn't appear when you press the arrow button. It might show only the first half of a paragraph, for example.
When you use the arrow button a few times, it's virtually impossible to escape out of the page with the Back button. You have to press it so many times, and it's difficult to tell what's going on.
Using an arrow button is not good for usability anyway, because you can't tell what it's supposed to do.
The link "Jump back a section" usually does nothing.
Please could someone revert it back to the old mobile version ASAP, which didn't have any of these problems.
Adding to this: when you press the arrow or text to expand a section, it takes forever to open. You aren't sure if anything is happening, so often you will press it again, only to have it quickly open and then re-close because the re-close operation registers nearly immediately.
Really, it's terrible. Even my girlfriend, who is not technical, was using it the other day and mentioned it was different and wasn't working correctly. — Preceding unsigned comment added by Georgiabiker (talk • contribs) 14:19, 15 May 2012 (UTC)[reply]
Sorry about the problems with the recent deployment of the mobile site. A lot of unexpected problems crept in. The fixes to most of the problems should be deployed today. --Philinje (talk) 17:52, 15 May 2012 (UTC)[reply]
Yeah I also seem to be having some problems, even though I use an iPod Touch. I'm also probably the only person who browses Mobile Wikipedia on a computer though. Anyway, aside from the fact that sometimes the whole page doesn't load (just a few sections), another problem I have is if I try to open a new tab, when I go back to the old tab, it goes back to the top of the section! Very, very, very annoying. Narutolovehinata5tccsdnew01:28, 16 May 2012 (UTC)[reply]
Problem with the site
Site look weird to anyone else right now? My toolbar's missing and there's a 24 at the top of the screen. The skin just plain isn't loading. Ten Pound Hammer • (What did I screw up now?)01:18, 16 May 2012 (UTC)[reply]
I just got this too, affected here and www.wikipedia.org for sure. Skin sometimes failed to load, but not always. Seems gone now. Looking at the source code for I think it was www.wikipedia.org, there was a 24 appended at the very beginning of the file like so:
The 24 is gone but I am losing navigation bars and javascript. Was kicked out of my AWB as well. Said server connection errors. If it occurs again I will post the specific error. ChrisGualtieri (talk) 01:21, 16 May 2012 (UTC)[reply]
Got beaten to the reverts. Seems like the matter is fixed. I'm not on IRC, but I assume ChrisG knows about it? (We are different people, btw) ChrisGualtieri (talk) 01:32, 16 May 2012 (UTC)[reply]
There's currently an issue with the API servers which Tim Starling is working on. This is intermittently affecting Bots and various scripts and gadgets that use the API like Twinkle, ArticleFeedback, WikiLove, etc. This is completely separate from the '24' issue, which I imagine was accidentally caused by an admin on meta, but I haven't looked into it. Kaldari (talk) 04:21, 16 May 2012 (UTC)[reply]
Sorry if this is in the wrong place. I recently made a request at Wikipedia:Bot requests/Archive 47#Link to a diff when clean-up tags are applied to provide a link to the diff when a cleanup tag was applied. It was suggested the {{REVISIONID}} magic word would accomplish this, but it doesn't seem to work. Maybe someone here knows a bit more about how to do this or can point me in the right direction. There might even be another way to accomplish the same thing. AIRcorn(talk)01:04, 16 May 2012 (UTC)[reply]
I hope you realise that it only works after the page is saved, and updates after the page is edited each time, so you might want to substitute it. Hazard-SJ ✈ 02:02, 16 May 2012 (UTC)[reply]
No I didn't. That won't really work as cleanup templates aren't substituted. Is there another way to link to the diff that added the template? AIRcorn(talk)00:03, 17 May 2012 (UTC)[reply]
Can't one do something like {{tag|1=[urlpart{{subst:REVISIONID}} added in this edit]}}? Something more refined, obviously. But I still think it's doable. Killiondude (talk) 18:56, 17 May 2012 (UTC)[reply]
Find specific edit tool
At some point in the past couple days the miszabot config in WP:ANI was changed -- an "f" was added to the 700K in the maxarchive section. Is there a tool that can find the diff that generated that specific edit? Nobody Ent10:32, 16 May 2012 (UTC)[reply]
and Ucucha's duplinks tool doen't appear in the sidebar. Loading this VP/T page, duplinks also fails to appear, but no error is reported. On many other pages, all is well. These errors are consistent today, not intermittent, but I was having no problem with Pakistan up to 22 April, when I copy edited it, so I guess this must be something recent. Demographics of Croatia, to which the archived problem related, still loads error-free and has duplinks today. Hoping you can help, and thanks. --Stfg (talk) 16:16, 16 May 2012 (UTC)[reply]
Looks like some sort of JavaScript loading problem. My script shouldn't appear on this page, because it adds the link only on mainspace and userspace pages. Ucucha (talk) 17:37, 16 May 2012 (UTC)[reply]
Okay, so I pinged the script's maintainer, Dschwen, and he removed the offending line. Thus, this problem should be officially fixed :) If it's not, then do say, obviously. - Jarry1250[Deliberationneeded]01:52, 17 May 2012 (UTC)[reply]
Many thanks, Jarry1250. Yes, on purging the cache it's fixed; no page loading error, and duplinks is now present on them. --Stfg (talk) 09:26, 17 May 2012 (UTC)[reply]
Wayback/Webcite
Is there a bot or app that will let me trigger Webcites for all of the citations in an article? I just wrote an article and a lot of the citations are to sources that are unlikely to last. I'd like to get archived copies of them, but it's annoying to do one by one. MBisanztalk16:30, 16 May 2012 (UTC)[reply]
I'd be interested in knowing this as well. I doubt it for the Wayback Machine, they don't seem to constantly crawl, but someone might have something for WebCite. --joe deckertalk to me16:32, 16 May 2012 (UTC)[reply]
Using the related changes special page should show articles that are in your watchlist in bold text. It appears to be now displaying all without any bolding. I guess this could be something to do with the watchlist changes but would be good to get it back so you can easily scan the changes not on your watchlist. Keith D (talk) 01:20, 17 May 2012 (UTC)[reply]
Yes, the CSS added to override the bolding on the watchlist is also overriding the bolding on Special:RecentChanges. It's easy enough to target it more specifically, but unfortunately that will also break everyone's overrides for the override. If your override for the override has broken, you will probably be able to fix it by changing your CSS selector from strong.mw-watched a to .mw-special-Watchlist strong.mw-watched a. Anomie⚔02:15, 17 May 2012 (UTC)[reply]
They seem to support it fine. Since the protection template was logged as being added within three seconds of the actual protection, I suspect they were actually submitted at the same time by Twinkle and the template thought the page wasn't protected when the page was parsed. Any edit, even a null edit, probably would have fixed it. Anomie⚔02:40, 17 May 2012 (UTC)[reply]
I have an override in place for the anti-bold override that's currently in place for unwatched changes in my watchlist. What happened to the bold?—cyberpowerChatOffline02:28, 17 May 2012 (UTC)[reply]
Dumps? I tried to look through the database dumps and offline versions, but I couldn't seem to find what I wanted: is there any way to just get a (plain-text) list of the content on en.wp by namespace? It would be nice if it was in the format:
Poke someone who can run a Toolserver query for you (Jarry1250 seems to be helpful!). Or you can run the appropriate API query yourself (search for action=query). That might be more tedious if you aren't familiar with that stuff. Killiondude (talk) 06:09, 17 May 2012 (UTC)[reply]
Thanks. Doesn't seem to be fixed; popups work for me in Firefox 12 now, but not in Chrome. (And the edit toolbar doesn't appear most of the time in either browser.) JN46611:38, 17 May 2012 (UTC)[reply]
Has anyone created a function that can parse wikitext and return a template with its parameters? Alternatively, does an API query exist for that?
{
"Template:X3":
{
"bla{h":"Hello!"
}
}
Something like this, taken from https://en.wikipedia.org/w/index.php?title=Wikipedia:Sandbox&diff=prev&oldid=492475629
You should be able to do that with Regex pretty easily I imagine. Could you give us a little more detailed description of what you are trying to do. It could just be me and my tired 1AM brain but its kinda unclear from the description what your trying to do. Kumioko (talk) 04:27, 17 May 2012 (UTC)[reply]
What I'm trying to do is capture a template from wikitext, that looks something like {{Foo|bar={{baz|b{oo=far}}}} Regex cannot be used for this purpose, because there are nested templates and uneven braces. So that leads to my question, is there already a method of extracting the template? →Στc.05:19, 17 May 2012 (UTC)[reply]
Using regex is horrible, don't do it. It's like drugs; seems like a great idea at the time, but in the long run you end up with more problems than its worth. Even simple things like a link in the template (e.g. {{foo|[[bar|foobar]]}}), can break the regex unless it is very well written. Assuming you're using PHP, here is my hack of a solution to parsing templates:
Collapsed long code snippet, click "show" to the right
<?phpclasstemplateimplementsIterator{private$name;private$params;private$pos;publicfunction__construct($name,$params){$this->name=$name;if(empty($params)){$this->params=array();}else{foreach($paramsas$key=>$value){$this->params[]=array($key,$value);}}$this->pos=0;}publicfunctiongetByKey($key){if(!isset($this->params[$key]))returnfalse;return$this->params[$key];}publicfunction__toString(){return$this->name;}publicfunctioncurrent(){return$this->params[$this->pos][1];}publicfunctionkey(){return$this->params[$this->pos][0];}publicfunctionvalid(){if(isset($this->params[$this->pos]))returntrue;returnfalse;}publicfunctionrewind(){$this->pos=0;}publicfunctionnext(){$this->pos++;}}// Look, don't even bother and read this, just accept that it parses// $text, and returns an array of templates.// Yes, it is horrible in every possible way; but it works.functionparsetemplates($text){$text=str_split($text);$template_level=$args=0;$template=$templates=array();$ignore_next_char=$in_link=false;$arg_name=null;for($i=0;$i<count($text);$i++){$prev=$text[($i-1)];$next=$text[($i+1)];$char=$text[$i];if($char=='['&&$prev=='['){$in_link=true;}elseif($char==']'&&$next==']'){$in_link=false;}if($char=='{'&&$prev=='{'){$template_level++;if($template_level==1){$start=$i;$code='{{';continue;}}elseif($char=='}'&&$next=='}'&&!$ignore_next_char){$template_level--;$ignore_next_char=true;if($template_level==0){$args=0;$code.='}}';$template['name']=trim($template['name']);$tmp_args=array();if(!empty($template['args'])){foreach($template['args']as$tArg){$tmp_args[]=trim($tArg);}}$templates[]=newtemplate($template['name'],$template['args']);$template=array();continue;}}elseif($ignore_next_char){$ignore_next_char=false;}if($template_level==1){$code.=$char;if($char=='|'&&!$in_link){$args++;$arg_name=null;continue;}elseif($char=='='&&$arg_name==null){$arg_name=$template['args'][$args];unset($template['args'][$args]);continue;}if($args==0){$template['name'].=$cont.$char;}elseif($arg_name!=null){$template['args'][$arg_name].=$cont.$char;}else{$template['args'][$args].=$cont.$char;}$cont='';}elseif($template_level>1){$cont.=$char;$code.=$char;}}return$templates;}?>
It runs like so:
<?php$templates=parsetemplates($wikicode);// Returns an array of template objectsforeach($templatesas$template){echo"$template\n";// The name of the templateforeach($templateas$argument=>$value){echo"\t\"$argument\" => \"$value\"\n";}}
I wrote parsetemplates() one night, very late when I was frustated by this exact problem. It's a horrible function, but, it works for all the wikicode i've encountered so far. That said, try not to find anything that breaks it ;) --Chris07:15, 17 May 2012 (UTC)[reply]
That's a fun piece of code. Haven't tested it at all, but it looks like it doesn't handle template parameters ({{{param_name|default}}}, etc), although I guess that's not a common sight on article pages. More generally I think it won't like multiple sets of braces put together; things like {{template|foo={{bar}}}} or especially {{{{WorkOutWhichTemplateToCall}}|foo=bar}} will make it go in or out too many levels. Also image captions can contain links: [[File:Foo.jpg|thumb|This caption [[contains a|link]] which confuses things]]. But a valiant effort nonetheless! :DHappy‑melon14:03, 17 May 2012 (UTC)[reply]
It deliberately doesn't deal with template parameters, it's just way too ugly (and lets face it, if you're trying to parse actual templates, you're going to need something beefier than this, that can handle all the parser functions etc). Image captions with links it can deal with, and {{template|foo={{bar}}}} is also fine (I actually wrote it specifically for that purpose, so that I could parse templates that have templates as arguments). However, you are right {{{{WorkOutWhichTemplateToCall}}|foo=bar}} doesn't work. Damn. --Chris16:30, 17 May 2012 (UTC)[reply]
Actually, strike that about the images with captions. This version can't deal with them (although your example does work, this code [[File:Foo.jpg|thumb|This caption [[contains a|link]] which confuses things|right]] doesn't). I have a different version that does actually deal with that problem, however it breaks with other things, and is not ready for primetime yet. --Chris16:50, 17 May 2012 (UTC)[reply]
[70cc2217] 2012-05-17 08:58:26: Fatal exception of type MWException
I don't know what the deal was, but I had a similar problem. Lasted for a couple minutes. Couldn't save anything. Seems gone now. - jc3709:48, 17 May 2012 (UTC)[reply]
I just activated the unified login option under "My preferences" here on Wikipedia, but cannot seem to login to the Commons site. When I try (using my Wikipedia username and password) I get the following error message:
Login error
<
The user name "My Core Competency is Competency" has been banned from creation as it matches one or more blacklisted character strings.
Your username is 32 characters (excluding the User: prefix), which exceeded Commons' titleblacklist restriction of 30 (including the User: prefix). I've increased it to 40 so you should be fine now. However length restrictions on usernames should really be enforced in Meta's blacklist, not on local projects - and the software should be amended to not included the "User" prefix in the count, as it varies by project language (anyone know if there's a bug for that?). Rd232talk14:51, 17 May 2012 (UTC)[reply]
I like to make a sortable table, but have the sort indicator in the third row, not the first. All the examples in Help:sorting have the top row the sort indicator.
I know how to make it sortable when there is a single header row, see for example, the table in First and second rounds, but I'm not sure how to make it happen if I have two or three header rows.
I know I have to use "!" to indicate header, as opposed to data rows, but I'm not doing well when I try to do formatting such as colspan, in the header rows.
Seems Thomas (activist) keeps defaulting back to a version of the page over 7 days old. Problem comes when viewing as an anon from an external website (see here, for example). I have purged the article numerous times over the last week. Any ideas? Nirvana2013 (talk) 19:05, 17 May 2012 (UTC)[reply]
What exactly is different on your end (as an anon)? I checked it and don't see anything. In general, however, anonymous users use cached versions of pages but it normally isn't more than just a few edits behind the live version. Killiondude (talk) 19:14, 17 May 2012 (UTC)[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.
Note: I'm no longer watching this page because of all the stuff from #Watchlist - bold letter article titles! onwards. --Redrose64 (talk) 08:41, 12 May 2012 (UTC)
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)
Resolved
Liam987 16:26, 14 May 2012 (UTC)
