Misplaced Pages

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

And what's absolutely and truly STUPID about this is that it showed new edits to this page in green when I pushed history after clicking the diff four minutes earlier (and then checked the rest of my watchlist). So a whole bunch of edits that are new are not shown in green while only a couple are. ♫ Melodia Chaconne ♫ (talk) 01:22, 11 May 2012 (UTC)

And even MORE dumb is that hitting the back button shows only the updates since I posted, not the intervening edits between me clicking on the batch of diffs from the history and reading and then making the above posts, which I of course never actually saw. So how is this supposed to be helpful again? ♫ Melodia Chaconne ♫ (talk) 01:53, 11 May 2012 (UTC)

• This is so ridiculously inane please turn it off. ~~ Lothar von Richthofen (talk) 02:06, 11 May 2012 (UTC)

• Lose the commons-like bold stuff and green highlighting - and see if you can get rid of it at commons also. It's very annoying. ←Baseball Bugs carrots→ 05:22, 11 May 2012 (UTC)

• It certainly is jarring. Seems to me it could be toned down considerably. After all, if we can have diff colors so subtle you practically need to wear special glasses to see them, there's no reason we couldn't have a gentle, low-saturation green here. And perhaps smaller type. Rivertorch (talk) 05:44, 11 May 2012 (UTC)

The green notification might be useful if it was done properly. Currently it displays itself for every revision that I supposedly haven't seen. And on some pages that can mean many copies of the same green box. It is completely taking over the page and makes it look awful IMO.

Perhaps better if the box was be be placed only once at the eldest revision that I haven't seen. And the text can then be changed to something like "Changes above this notification bar are new. Changes below this notification you have already seen". HumphreyW (talk) 07:30, 11 May 2012 (UTC)

• Actually this is great, mine wasn't green so I changed to a green highlight by editing common.css. :D --lTopGunl (talk) 14:36, 11 May 2012 (UTC)

• I have the same opinion as HumphreyW: it's useful to have a line drawn across the revisions, not so useful to label every revision more recent than the last visit, given that there's already a lot of clutter on each line.

• I have the same question: I don't find the green "updated since my last visit" note helpful, and I do find it annoying. Is there some way to opt out of it? I see that this subject has been here for the better part of a week, with questions but no replies; are the tech gods even listening? Update: For some reason someone just reverted my comment, without explanation. If there are instructions somewhere in this thread for opting out (maybe the line of code posted by Yair Rand?), they are not evident or helpful without more detail about what to do with that code or where to put it. --MelanieN (talk) 15:22, 15 May 2012 (UTC)

P.S. Looks like Bbb23 has the same problem. --MelanieN (talk) 15:24, 15 May 2012 (UTC)

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.

Far too complicated. HiLo48 (talk) 17:22, 15 May 2012 (UTC)

I agree a straightforward opt-out feature would be better, but this is better than nothing. --MelanieN (talk) 17:24, 15 May 2012 (UTC)

Only very very slightly. HiLo48 (talk) 10:50, 16 May 2012 (UTC)

Significant comments about why this is absolutely horrid and a horizontal rule would be much better appear in my straw-poll vote above. JJB 20:19, 15 May 2012 (UTC)

"Changes related to" pages all gone wrong

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

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

Use dotted underline instead of stars

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

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

Use italic text instead of stars

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

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

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

Use a check mark instead of stars

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

Change temporarily reverted in search for better consensus

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

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

Oh. So is it currently at bolding? Because the stars really were better than the bold. Bunnies! Leave a message 22:19, 10 May 2012 (UTC)

I have fully reverted, though it was the green stars that I first noticed. In any case, I fully support people proposing radical change to the watchlist. But only in the spirit of Bold, revert, discuss. Update: I am an idiot and didn't see that the bolding is not in Common.css at all. Steven Walling • talk 22:26, 10 May 2012 (UTC)

• Whomever started this process needs a kick in their britches. There are many ways to solicit attention to proposals of forced change in visual design. One way to implement them is to not fuck with the live copy. The annoying bold text is still present, and is still degrading my user experience. Fifelfoo (talk) 22:19, 10 May 2012 (UTC) 22:34, 10 May 2012 (UTC)
• The bolding is back and it's really hard on the eyes - also it induces an instant migraine. Each time I've logged off and logged back in today the watchlist has been different. It's extremely annoying. Truthkeeper (talk) 22:31, 10 May 2012 (UTC)

• Agree with Fifelfoo, all these changes need to be reverted and the proposal(s) needs to go back to the start. I hope the "powers that be" have learnt out of this "epic fail" that we do want projectwide wall-to-wall notification of proposals that have such a drastic effect on all editors' experience of working on the project. Roger (talk) 22:30, 10 May 2012 (UTC)

  The "powers that be" had nothing to do with these changes. --Yair rand (talk) 22:37, 10 May 2012 (UTC)

  Whoever managed this process and implimented these changes are "the powers that be" for the purposes of this discussion, or have the WMF servers achieved self awareness and now write their own code? Roger (talk) 22:51, 10 May 2012 (UTC)

  As you can see from the discussion on the bug request the developers were just fulfilling a community request backed by a consensus. People would be pretty mad if they just refused the change too, so I don't think anyone can lay some blame on their laps here. Steven Walling • talk 23:10, 10 May 2012 (UTC)

The problem was, those who had taken part in the original discussion had said "yes, let's have something, preferably an opt in gadget." There wasn't actually a discussion about how it was going to work, or when it would be done, so when Erwin starts trying to see how it might work, people were surprised, didn't like the first couple of tests, and had in many cases been expecting something else entirely. It was ever thus, but having a space to test out how it might work before changing the interface for everyone might have been really useful, and saved a lot of flak. Elen of the Roads (talk) 23:26, 10 May 2012 (UTC)

• Put an option in userprefs and then leave it alone. My watchlist style changed at least 4 times today between 3 different styles, which is more annoying than either bold or stars. Kilopi (talk) 23:00, 10 May 2012 (UTC)
• There's a misunderstanding I think, the change has not been reverted completely yet, only the stars (!) have been removed. There's a consensus for the status quo, default feature (normal bolding and green text), drastic changes like these (no bolding and different style in histories, besides weird stars) need a vast consensus after a discussion of at least some days at usual, not such hasty decisions and rapid changes, as pointed out also by Kilopi above. Nemo 23:12, 10 May 2012 (UTC)
  • • Where is there consensus on this page for "normal bolding"? The status quo is no bold. ~~ Lothar von Richthofen (talk) 00:08, 11 May 2012 (UTC)
  • Since it appears the CSS hack to remove the bolding on watchlists is breaking bolding elsewhere, I think it may be wise for me to set Commmon.css back to what it was before either Erwin or I edited it. If people want to fight out the configuration change referenced in the bug, then let them have at it. Steven Walling • talk 23:40, 10 May 2012 (UTC)

  A "consensus" of only 20 support !votes to impose a radical user interface change (that has no easy "off switch") on all ninety-odd thousand active editors is not a true consensus. Such proposals should require thousands of support !votes before anyone sane could call it a true consensus. Twenty users is a cabal, not a consensus. (IMHO the threshold should be in the region of ten thousand !votes.) Roger (talk) 23:42, 10 May 2012 (UTC)

  I agree it should probably be discussed more. I cannot do anything about it personally though. Steven Walling • talk 23:44, 10 May 2012 (UTC)

  Surprises seem to bring out the worst in active Wikipedians, but I think, based on the experience of many other websites with visible, function-enhancing changes, that the thing to do would be to leave it in place for a month or two, and only then ask people what they thought. Think about the "Tell Facebook to revert its changes" pages that spring up every time that website changes anything. Tens of thousand of users sign up on these protests, and a month later, most of them can't even remember what the old version looked like. WhatamIdoing (talk) 23:56, 10 May 2012 (UTC)

  No, I'm sorry, that's just plain dumb. Sites like Facebook and Youtube do that because they exploit the fact that they have a "captive audience". Misplaced Pages is very much a user-oriented site, and not giving an option violates that fundamental spirit of the project. ~~ Lothar von Richthofen (talk) 00:06, 11 May 2012 (UTC)

  Facebook also has a beta testing program where they make sure changes are reasonably acceptable to their audience before implementing them, rather than testing new stuff live. Equazcion 00:12, 11 May 2012 (UTC)

  But here you actually have the option of sticking with old settings. I am using MonoBook with green/yellow diff styling. Meanwhile, I am dreading the day when Mark Zuckerberg is going to finally shove that Timeline monstrosity down my throat for good. ~~ Lothar von Richthofen (talk) 00:18, 11 May 2012 (UTC)

  Why so much bold? :( — foxj 07:18, 11 May 2012 (UTC)

  What, you don't like the bold? It doesn't make things easier to notice? What if I throw in some green, does that make it better? ~~ Lothar von Richthofen (talk) 13:52, 11 May 2012 (UTC)

• Can we please get rid of the fucking bold again, already. I don't wake up and shit all over your user-interface and then play hissy-fit games about consensus. Fifelfoo (talk) 00:34, 11 May 2012 (UTC)
  • ^What he said. ~~ Lothar von Richthofen (talk) 00:50, 11 May 2012 (UTC)
    • ^What they said. Kafka Liz (talk) 00:55, 11 May 2012 (UTC)
      • Couldn't have put it more eloquently. MarnetteD | Talk 01:03, 11 May 2012 (UTC)

• I agree that we should revert all these changes until a consensus can be reached for their implementation. We need a wiki-wide surveying for single articles like Muhammad and Pro-life/pro-choice yet technical changes that actually affect us are sandboxed around Facebook-style? I don't appreciate it, and most others here would agree. — FoxCE (talk • contribs) 01:09, 11 May 2012 (UTC)

• GET RID OF THE BOLD!. Constantly having every-fucking-THING on your watchist in bold if you just started the day's editing is EXTREMELY distracting and does NOT make a good work environment. Hopefully this bolded paragraph will be able to aptly demonstrate what I mean! Barts1a / Talk to me / Help me improve 01:16, 11 May 2012 (UTC)
• Revert immediately. Clearly a case of inadequate discussion and hasty implementation. I don't want to look at that eyesore of my watchlist for a second longer. As the net number of complainants now far exceeds the number who participated in the original decision, can someone please revert now and discuss now that we have the undivided attention of "the community"? --Ohconfucius 02:11, 11 May 2012 (UTC)

• GET RID OF THE BOLD! Please!. It makes the page really hard to read and gives me a headache. All that bolding takes its power away as a highlighter while, at the same time, confusing the reader. Bold has to have a reason; there is no logical reason for this use. The titles were perfectly clear. Bielle (talk) 02:10, 11 May 2012 (UTC)

• Bin the Bold I echo the sentiments of the honourable and right honourable members of the project above. doktorb _words 05:21, 11 May 2012 (UTC)

• Don't reset &days= – I don't mind this feature, except that pressing the button "Mark all pages visited" a) does more than that – it also brings up pages which have changed since the list was previously generated and already unbold them, which is confusing; b) forgets what value I had used for the &day= parameter. In short, pressing the button will issue the default Special:Watchlist action, which makes long watchlists much harder on the browser. As it is, the button has more downsides than upsides; I guess I have to learn not to use it. -- Michael Bednarek (talk) 09:39, 11 May 2012 (UTC)

  You're right, I've filed your feature request under bugzilla:36761. Nemo 14:04, 11 May 2012 (UTC)

• The users who are now contesting the consensus for implementing this change clearly didn't participate in the consensus where it was almost unanimously determined to implement this change (and yes, those who didn't participate gave it a silent consensus too). It is right that a notice should have been added or something to inform atleast of what was going on (I was already using a script for the bolding so I got confused too), but I don't think that this was blatantly applied without a consensus. The changes are good, instead of removing them, an opt-in or opt-out feature should be added so that it doesn't hurt those who don't want it. --lTopGunl (talk) 14:44, 11 May 2012 (UTC)
  • Silence does not imply agreement or disagreement. As pointed out by others above, this is an issue that affects thousands upon thousands of users, and for such discussion to have real mandate, the participation rate needed to be a lot higher than the approximately dozen votes that caused this feature to be implemented. --Ohconfucius 00:33, 12 May 2012 (UTC)

    That page doesn't say what you attribute to it: «This page in a nutshell: Consensus is assumed when there's no evidence of disagreement». You need another essay to prove that lack of consensus is proved when there's evidence of disagreement. Thanks, Nemo 07:28, 12 May 2012 (UTC)

• Is there any way we can get this feature back (opt-in) while the arguments continue? --Orlady (talk) 15:20, 12 May 2012 (UTC)
  • See #Watchlist styles below. Equazcion 15:24, 12 May 2012 (UTC)

This actually fixed a bug

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

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

I think I can sum up the opinion above by responding with: boo! Killiondude (talk) 00:03, 11 May 2012 (UTC)

As far as I'm concerned—and I think many others will agree with me—that thread does not in any way constitute a "community consensus", so stop pretending like it is. An RfC is the most transparent way of going about determining consensus here, and that is what is being done above. ~~ Lothar von Richthofen (talk) 00:15, 11 May 2012 (UTC)

"Enabled by community request". bullshit Fifelfoo (talk) 00:40, 11 May 2012

• This is not a "fix." This is simply making the bug 24/7.--Jasper Deng (talk) 01:12, 11 May 2012 (UTC)

  Wasn't the reported bug about an inconsistent behaviour and confusing info? I don't see any of that. Nemo 14:07, 11 May 2012 (UTC)

Agree with Fifelfoo completely. It's really absolutely terrible and needs to become an opt-in option in preferences. Also, can someone please stop Helpful Pixie bot while this his happening to cut down on the watchlist burden. Truthkeeper (talk) 01:23, 11 May 2012 (UTC)

• We had basically the same reaction from Nemo on " Performer's username is shown twice in page move entries on the history": it's not a bug, it's a feature! A poor feature, wanted in principle but very badly implemented. Additionally, the button "Mark all pages visited" sadly does more than that alone; I usually have clicked on "hide my edits" and on "show all bots" to reverse the defaults, but using the "mark" button undoes that preference and sets everything back to its default setting. This is unwanted behaviour. Fram (talk) 11:51, 11 May 2012 (UTC)

  If you consistently change the defaults, it's advised to do so in the preferences. As said above, I've filed this feature request under bugzilla:36761. Nemo 14:07, 11 May 2012 (UTC)

• The manner in which this was implemented made many people irate; and now, no matter how many bugs were fixed, or how effective they were, the implementation debacle totally overshadows the bug fixes. --Ohconfucius 00:38, 12 May 2012 (UTC)

  No. The number of users who like and need the feature totally overshadows the number of complaining users. Moreover, the implementation debacle of hasty and confusing changes to the watchlist style by some admins totally overshadows the (supposed) benefits in terms of (unproven) consensus compliance. Nemo 06:54, 12 May 2012 (UTC)

Community and consensus-focused development

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

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

HOWTO: Subtle marker / no marker

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

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

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

If you'd prefer no marker, use:

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

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

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

VERY much like. Thank you. This should be a gadget, at least. Equazcion 02:08, 11 May 2012 (UTC)

Brilliant idea, I'm in favor (though perhaps as an opt-in to avoid more community rage). — FoxCE (talk • contribs) 02:14, 11 May 2012 (UTC)

see that tiny "mb" to the left of the diff in your image example? That's another pre-existing example of a low-intrusiveness inclusion of one bit of information. Fifelfoo (talk) 02:16, 11 May 2012 (UTC)

A bit of info which you wouldn't be able to customise. ;-) But if you want yet another letter instead of the bold everyone is accustomed to, you can file the request on bugzilla:. Nemo 14:09, 11 May 2012 (UTC)

• Thanks, this is an excellent alternative. I can now use it along with User:Ais523/watchlistnotifier.js without confusion. --lTopGunl (talk) 15:04, 11 May 2012 (UTC)
• Thanks for the workarounds. CaptainScreebo 19:29, 11 May 2012 (UTC)
• That works nice. I don't mind a subtle marker, but the bold was a bit much for me. Offering some options on a gadget that updated your css (you want jazzy, subtle, little green stars, blue fish...?) would be a really nice feature. Elen of the Roads (talk) 22:56, 11 May 2012 (UTC)

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

It seems a very bad idea: as pointed out elsewhere, bold is the standard, other options are very user-unfriendly and would increase confusion. A more of focused discussion on if and how to change the style should happen with less haste when this discussion (and the users' habits) settles down. Nemo 06:04, 12 May 2012 (UTC)

"Standard" really doesn't mean anything. It's the MediaWiki default and can remain that way, but nothing precludes a local community from overriding the default behavior.

I agree that a more focused discussion should take place. That doesn't mean that leaving the bolding on in the meantime is a good idea. For smaller watchlists, it's not so bad. But for active users with a lot of watchlist entries, the bold is simply overwhelming. --MZMcBride (talk) 15:27, 12 May 2012 (UTC)

I've never found it overwhelming even with tens of thousands of items in the watchlist, and I don't see how the number of items in the watchlist matters, it's more about the percentage of visible text which is bolded.

Why isn't holding the default in the meantime a good idea? As written elsewhere, users were already getting used to it, while now only very few users will ever notice this feature and propose something else if needed. Nemo 18:39, 12 May 2012 (UTC)

When you have a larger watchlist, the percentage of bolded items is higher. Usually on a directly proportional basis. That's the overwhelming part. It's very similar to an e-mail inbox that you simply can't ever get ahead of. Not on a project as active as this one, at least. Meta-Wiki is manageable.

The underlining is vastly less awful. It gives a cue without punching the user in the face. I think it would make sense to use the bold for users with smaller watchlists and something less awful for users with larger watchlists. This could be accomplished through a user preference, implicit controls (less than 1,000 items, bold, etc.), or some other means.

That said, this is actively causing a problem for established users, so it should be a fairly high priority to make the site less awful for them. When you have the chief tech guy at Wikimedia posting hacks to make the site less awful, you really question the default, at least as a default for everyone using the site. But obviously Erik's focus is the entire site while my focus is largely people like myself (users with large watchlists). --MZMcBride (talk) 18:50, 12 May 2012 (UTC)

The size of watchlist should be proportional to your interest/ability to follow it; if it isn't, and "unread" items just increase and increase, there's something wrong in yor selection, very similarly to how an inbox as described by you would be plainly broken, and not by its style.

I don't know what Erik's intervention means, I agree that established users should be heled and I think the update markers are very useful for those with a big watchlist (unless they have the memory of Pico della Mirandola). Speaking of the style, I agree of course that it could be changed, although it's difficult to imagine something better than bolding; see for instance the recent comment on #A note about "opt-in". Nemo 18:36, 13 May 2012 (UTC)

• Thanks for that script. It's brought the watchlist back to how it was early yesterday. This should be added to gadgets to allow a choice between a bolded or unbolded watchlist. Truthkeeper (talk) 01:46, 12 May 2012 (UTC)

Move this discussion?

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

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

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

Well, aside from the fact that there's no reason to move the discussion to begin with (this is the correct venue for it and its length doesn't hamper other discussions -- I've seen much worse and people seemed to get along fine), VPT is where people go when they see interface changes, especially unwelcome ones. Moving things off this page just makes the discussion more difficult to find. A header and line kept around doesn't suffice, and while it's true we can link from CENT and we have the RFC listing, those aren't terribly prominent; many if not the majority of people don't know to check those. It makes sense to keep it displayed prominently here; also for the reason that developers etc. need to be reminded of what people's current concerns are, and it's harder for them to ignore a big discussion at VPT than a subpage or some new WP: space page made just for it that no one is watching yet. Prominence here should match the amount of attention an issue has garnered, and this one's got a lot of attention. Equazcion 14:02, 11 May 2012 (UTC)

• Where is the RfC? Do you mean the vote happening at #RFC or is there another page somewhere? Nemo 14:16, 11 May 2012 (UTC)
  • Yeah he means the vote above. An RFC tag was placed at the top of that section, so that makes it listed automatically at WP:RFC. Those listings don't get as much attention as one might hope though. The discussion's presence on this page is actually much more of a draw than the RFC listing (as you've actually demonstrated :) ). Equazcion 14:19, 11 May 2012 (UTC)

It's ironic that the cause of this whole discussion is exactly the fact that things are "hidden" in obscure walled gardens inhabited only by uber-geeks. If an anouncement about the original proposal of six months ago was properly distributed to all user in the first place this "long" topic would not exist. Now you want to sweep this under the rug too! If WP was a commercial organisation the people responsible for this epic fail would have been unemployed today. As for the "crowding out" argument - utter bollocks! This page is not made of paper - it can stretch to accomodate practically any amount of text. Roger (talk) 14:18, 11 May 2012 (UTC)

Now now, let's not be mean to Edokter. The problem is that while there was approval of the theory - "let's have something that allows you to highlight changes you haven't looked at in your watchlist" - nobody really sat down and hammered out the details "how bold? Different colour? Is subtler better? Do we need a css tweakeria? Can we make it a gadget? No? What can we do instead? Would little icons work? Which icons? What colour?" and all the dozens of possible combos. And no-one did the stakeholder communication plan. I know this stuff seems like fantastical bureaucracy when you just want to get in there and tweak code (and the code tweakers are seldom the right folks to do the project plan - everyone has their own set of skills and should be respected for that), but this is what happens if you don't have something. Elen of the Roads (talk) 15:22, 11 May 2012 (UTC)

I can't help but feel that some of this is being done the wrong way round. Is there a problem with the basic skin (of whatever hue)? Not that I can see but there is obviously a demand by a number of users for enhancements to, in this case, the way the watchlist is presented. That is fine and a valid demand but the way forward isn't to make a universal change which is bound to be unsatisfactory to all. With the ability to create user specific custom.css, shouldn't there be an advertising of services available which allow users make changes that suit their needs? On this page since yesterday there have been several options for displaying the watchlist, a shopping list like that, that people can choose from to place on top of the vanilla stylesheet is surely better than enforced changes that few are happy with? NtheP (talk) 16:00, 11 May 2012 (UTC)

Yes. I think there are lessons to be learnt here. Highly-visible changes to functionality need greater sign-off by the community. I don't think needs to be a big-burden process. For example, if a change gets consensus then, before rolling it out, there could be a process to (a) advertise the change on watch lists, (b) link to a page describing the change (with reasoning, descriptions, screen shots, how to opt-out/opt-in/disable the change and, if possible, a staging area), (c) if there is no big fuss after two weeks then deploy the change.

I'm not saying what I described should be the process but some process of this kind may prevent the sudden "WTF!" reaction that this change brought. --RA (talk) 15:51, 11 May 2012 (UTC)

Design by consensus doesn't work. You need someone with vision who understands how the site works at every level and is willing to implement small changes in a way that doesn't upset people. The problem here is that the person or people doing this are going about it in the wrong way. Viriditas (talk) 23:25, 11 May 2012 (UTC)

Not talking about design by consensus. I talking about sign-off and process (i.e. going about it in the right way). --RA (talk) 01:23, 13 May 2012 (UTC)

How does this work, anyways?

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

I think it's stored in the server somewhere. Privacy questions related this have been brought up on meta in this discussion. Killiondude (talk) 21:23, 11 May 2012 (UTC)

It is stored in the server. The watchlist table in the database has a field on each watchlist entry for when an email was last sent (or would have been sent, if you had that preference turned on) about changes to the watched page. Whenever an edit is made to a page, this field in all the watchlist entries pointing to the page is set if it doesn't already have a value. Then when you view the page (or view a diff against the current version of the page), it clears out that field for your watchlist entry. The watchlist-bolding feature uses this same field to determine which entries to mark. Anomie⚔ 22:02, 11 May 2012 (UTC)

I'm just wondering by what order of magnitude this change has increased server load? --Ohconfucius 00:44, 12 May 2012 (UTC)

I'm not a developer, but this has been enabled in careful steps to measure the server load (which was the only reason it wasn't enabled on some Wikimedia wikis, unlike all the other wikis), and the worries seem to have been proven unsubstantiated. I think this is the graph to look at (database master for en.wiki), and there's no noticeable impact to any component, except a peak for a few minutes after the feature was enabled, to set it up in the database. Nemo 06:15, 12 May 2012 (UTC)

Day 2 of this shit

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

1. The discussion implementing this solicited in the range of 20 users' input here on WP:VPP. The discussion did not describe the effects on the user interface
2. The snow grade level above indicating this should be opt-in only is a big clue, as is the depth of outrage at sudden and poorly implemented UI changes
3. Why has the implementer of this not reverted their actions? Fifelfoo (talk) 23:47, 11 May 2012 (UTC)

because they don't have to. There is consensus editing, but not consensus developing; they can do whatever they want. Choyoołʼįįhí:Seb az86556 00:18, 12 May 2012 (UTC)

Yes, I recall that being the status on development. But surely that means they can develop what they want, but we can still ignore it? We did manage to get date autoformatting disabled, eventually ;-) --Ohconfucius 00:50, 12 May 2012 (UTC)

If you read the bug action they relied on a construction of consensus on wikipedia. Fifelfoo (talk) 02:24, 12 May 2012 (UTC)

• The problem is, Steve Walling has tried to revert Edokter, and it hasn't worked as expected. I can have a go at resetting it, but I can't figure out why Steve's reverts didn't work how he expected. Let me see if I can give it a go to turn it off entirely - with apologies for testing in a live system. Elen of the Roads (talk) 01:13, 12 May 2012 (UTC)

Something has worked as all the bolding is gone. Whether it stays this way or not I want to say thanks to you EotR and/or anyone else who gave my eyes a rest - even if it is only temporary. Thanks again. MarnetteD | Talk 01:51, 12 May 2012 (UTC)

It was me. Not sure if this is a permanent fix, but I've given a number of options at the bottom of the page for folks who want the markers back. Elen of the Roads (talk) 02:12, 12 May 2012 (UTC)

Thank you for this action Elen. The concealment of process, and change structure, from the community was disturbing. While the option appears to be fruitful, if needing a lot of UI development, the process so far has not been optimal. It is good to see the Revert section of BRD applied properly to the process at last. Hopefully the discussion will improve the options related to the watchlist greatly. Again thank you. Fifelfoo (talk) 02:24, 12 May 2012 (UTC)

• Thank you for restoring the vanilla watchlist. Now let's talk about the changes item by item. --Ohconfucius 02:32, 12 May 2012 (UTC)
  • Just to say I was happy when I refreshed my watchlist this morning and the dreadful bolding went away :) Thank you for your work on this. Secretlondon (talk) 10:24, 12 May 2012 (UTC)

At least now people have a choice as to how to display their watchlist. Turning on the option wasn't the problem, it was that it by default altered the appearance, which people hadn't anticipated. In the future, I expect someone who is a better script kiddie than I will create a gadget that allows you to choose if you want neon stripes or blue fish. Elen of the Roads (talk) 02:36, 12 May 2012 (UTC)

I probably wouldn't mind some blue fish on my GUI... ;-) --Ohconfucius 02:50, 12 May 2012 (UTC)

Thanks from me too, Elen. I'm much less likely to miss things this way. Now if we can get the colour of links we have visited to be a little more visibly different from that of links we have not visited, I'll be a happy camper. I'm one of those who looks at the colour of the diff link. Yngvadottir (talk) 04:18, 12 May 2012 (UTC)

Great, now how can we get rid of the pointless "Mark all as read" button? No bolding means no need for that. Nikkimaria (talk) 04:37, 12 May 2012 (UTC)

I made a script for the time being if you want. Add importScript('User:Equazcion/RemoveMarkAll.js'); to your skin's .js page. Equazcion 04:54, 12 May 2012 (UTC)

• This is absurd, there's no consensus to disable this feature for everyone. The discussion about this has been opened for a short while and has not reached any conclusion: as was repeated by many, it's a very bad idea to change this back and forth before any stable conclsion, it confuses users a lot. Besides, even if you considered the #RFC above to be a valid consensus (and it isn't), this change does not make is an "opt-in" feature, which as pointed out by the proposers themselves would require some coding; the complete disabling of the feature was supported by a very tiny minority.
  More importantly, as Risker said, it's not hard to see that the vast majority of users like this change, because many said so in this page although users liking something usually don't come here to comment, unlike people wanting to complain. Nemo 06:25, 12 May 2012 (UTC)
  • It's not absurd. The burden of consensus lies in making the change to begin with. There doesn't actually need to be consensus to roll it back when there was no demonstrated consensus to implement it in the first place. Equazcion 08:26, 12 May 2012 (UTC)

    There was consensus to enable the feature, and there's no consensus to disable it (in fact no complete disabling has been asked to the devs). There's no consensus for any particular style other than the default one, which should be restored until a proper consensus has been found on an alternative. --Nemo 13:07, 12 May 2012 (UTC)

    • A good many people would seem to disagree with you that there was adequate consensus, and that said consensus was for the change the way it's actually been implemented. The discussion wasn't very widely advertised nor did it get broad participation. Many of the support !votes it did get were on the condition that a preference be added for it too. Equazcion 13:13, 12 May 2012 (UTC)

      • My bolding seems to be gone, thankfully, but I would like to point out I never heard of this so-called community discussion. This was a hijacking by a minority. In the future, everyone should hear about this sort of discussion...Smarkflea (talk) 17:56, 12 May 2012 (UTC)

Watchlist styles

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

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

 /* Styling for update markers on watchlist and history pages */
   span.updatedmarker {
   background-color: transparent;
   color: #006400; } strong.mw-watched a {
   font-weight: normal;
   /* @embed */
   background: url(//upload.wikimedia.org/wikipedia/commons/thumb/a/ac/Pentagram_dis.svg/13px-Pentagram_dis.svg.png) no-repeat left;
   /* @noflip */    padding-left: 16px;
}

• If you want a dotted line under the unread ones, add this

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

• If you want the unread in italic , add

 .mw-watched {
font-style: italic !important;
}

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

Je veux ton amour et je veux ta revanche. But seriously, thanks. Killiondude (talk) 02:13, 12 May 2012 (UTC)

Elen, you're a beautiful person. Equazcion 02:17, 12 May 2012 (UTC)

I've grown fond of the bolding. When I add the code snipit into my common.css, the bolding doesn't return. Bgwhite (talk) 02:26, 12 May 2012 (UTC)

I can't get bolding to work either. Looks like any bold attempt is being overridden, I guess by common.css? Other styles do work. I'm not complaining though. Considering the response I think it's better reverted anyway. Equazcion 02:44, 12 May 2012 (UTC)

Most odd. I can get it in italics (see code above) but not bold. I'll see if I can get something that looks similar to the bold. Elen of the Roads (talk) 03:00, 12 May 2012 (UTC)

Everything works fine for me although I placed my own style in before this thread was opened. Goto User:Cyberpower678/vector.css and copy the code from there. It bolds and stars at the same time making it actually look good in my opinion. After every technical change made to .js or .css config files, you need to purge your cache.—cyberpower _Offline 03:17, 12 May 2012 (UTC)

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

• To get the bold back, use

span.updatedmarker {
   background-color: transparent;    color: #006400;
}
strong.mw-watched a {
   font-weight: bold;
}

• And for a really jazzy experience, try

strong.mw-watched a {text-shadow:1px 1px #000080;}

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

Glad I could help.—cyberpower _Offline 03:46, 12 May 2012 (UTC)

Exalt! Most useful. Many, many thanks. doktorb _words 04:02, 12 May 2012 (UTC)

If you want to hide the "Mark all as read" button too, add importScript('User:Equazcion/RemoveMarkAll.js'); to your skin's .js page. Equazcion 05:05, 12 May 2012 (UTC)

Of course, you could also just use plain CSS to remove the button: form#mw-watchlist-resetbutton { display: none }. Nageh (talk) 11:16, 12 May 2012 (UTC)

Thank you Elen and Cyberpower. I hated the bold at first, but now find it extremely useful. Nice to have it back. Equazcion, I could never get your new category script to work, but found your LiveDiffLink.js script to be very convenient and now I get to add your "Mark all" script. Bgwhite (talk) 05:20, 12 May 2012 (UTC)

«I hated the bold at first, but now find it extremely useful» (bold added ;) ). Yeah, such a common and obvious thing. Too bad that the bold has been disabled for everyone and now the vast majority of users who would like it will never discover it, only because a tiny minority complained about it being unable to wait for a day to get used to it (as all MediaWiki users already are). Nemo 06:37, 12 May 2012 (UTC)

Yes, as someone experienced in change management I have to say that the reactions here should have been expected, and not over-reacted to themselves. Very shallow behaviour on both sides. Sad. It was a good change. HiLo48 (talk) 07:02, 12 May 2012 (UTC)

Many of us are experienced there too, as can be especially said for Elen of the Roads. As much as a negative reaction could've been expected, not every negative reaction is merely par for the course and should be brushed off as such. This one was more warranted due to the flawed development cycle it resulted from. Firstly, the change wasn't discussed (or was barely) -- and even though that usually isn't something users of a site are brought in on, it is something that has to happen here; the developers are not supposed to have the power to decide on changes merely due to their technical ability to implement them. The change was also not tested on a pool of this project's audience in beta fashion, and was instead tested live, where it was also rapidly tweaked several times, again with no testing. This rollback isn't a judgment of the feature or a mere reaction to outcry, but I would say in part it's a demonstration of the fact that Misplaced Pages 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 08:10, 12 May 2012 (UTC)

• Now, is there any way to get in the history pages unread from the last visit back on a green background, like it it done on Commons by default?--Ymblanter (talk) 07:22, 12 May 2012 (UTC)
  • I think Elen's CSS code above is supposed to remove those too, but I updated my script to remove them as well: add importScript('User:Equazcion/RemoveMarkAll.js'); to your skin's .js page if you want to try it out. It also removes the "Mark all" button on your watchlist, since that would be useless if you don't have the bolding (or similar) enabled. Equazcion 08:20, 12 May 2012 (UTC)

    Actually, I do not want to remove them (an Ellen's code does not remove them), I want to make them stronger (like it was yeaterday for a couple of hours - black text on green background). I am on the side which likes the new appearance.--Ymblanter (talk) 08:24, 12 May 2012 (UTC)

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

(I meant to reply to this comment originally instead of the one above) You can add importScript('User:Equazcion/RemoveMarkAll.js'); to your skin's .js page. This also removes the "Mark all" button on your watchlist, since that would be useless if you don't have the bolding (or similar) enabled. Equazcion 08:20, 12 May 2012 (UTC)

Yes, I am using that to get of the button (thanks). But what I'm asking about is when I look at the history of a page I am seeing "updated since my last visit" in green next to edits that have occurred since I last looked at the page; how can I get rid of that? Jenks24 (talk) 08:53, 12 May 2012 (UTC)

Yes, I updated my script since I first advertised it here -- it should now be removing those green notices on history pages too. Try hitting Ctrl-F5 to make sure the update is in effect. Let me know on my talk page if it's still not working. Equazcion 08:57, 12 May 2012 (UTC)

Yep, just had to purge my cache, thanks. Jenks24 (talk) 09:27, 12 May 2012 (UTC)

Note that I also just updated the script so that if the bolding is ever re-enabled by default, the script will automatically disable it without any CSS needed. See User:Equazcion/RemoveMarkAll. Equazcion 11:39, 12 May 2012 (UTC)

This will give a light grey background to unread items:

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

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

Cool. We need to update Misplaced Pages:Customizing watchlists with all these options (perhaps not the text shadow one!!) with screenshots, so that people realise they have all these choices. Elen of the Roads (talk) 19:24, 12 May 2012 (UTC)

Actually, that's only one part of the issue. Fact is that many users are not technically comfortable in using all these scripts (and since they're on individual user pages, it is impossible to ensure that they are all updated properly - which is a major problem). As well, even if people are comfortable in using them, they may have technical reasons why they are suboptimal. I've wound up disabling almost every script I ever put into my .css because it did not function properly due to some interaction with (a) other scripts or (b) something in a mandatory hardware or software setting. Gadgets work okay, most of the time. So they should either be gadgets (which are usually maintained and kept compatible with upgrades), or standard.

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

Good point about different skins. Each skin can of course have its own sitewide default. I did suggest over in The Other Place This Discussion Is Also Happening (For No Obvious Reason) that we make a gadget to apply the styling, so everyone can do what they want, and then collect stats on user choices to inform the default. If we did that we should be able to collect data split by skin, so different skins can have different defaults. On the other hand, if we do Elen's survey, that's a lot of screenshots (different options for different skins)... Rd232 16:45, 13 May 2012 (UTC)

Good point. Should add that to the survey. I use modern, and it looked bloody awful - exactly the same as Truthkeeper's description of a migraine attack. So an alternative would be to check in each skin and alter the css to get a toned down effect. I do think there is a style out there that is sufficiently unobtrusive for most people not to be bothered if it is on or off - we just have to find it. Elen of the Roads (talk) 18:38, 13 May 2012 (UTC)

Hey, I have no clue how I ended up here or how I managed to understand any of this, but the green star bolding works now! Thanks cyberpower! — Preceding unsigned comment added by Keraunoscopia (talk • contribs) 04:38, 19 May 2012 (UTC)

So how about those of us who actually want this?

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

• I second that! HiLo48 (talk) 05:13, 12 May 2012 (UTC)
• Me too! Oda Mari (talk) 07:23, 12 May 2012 (UTC)
• Like the new diff display, this took me about a day to adjust to, and now it's gone. I would like it back! Imzadi 1979 → 07:32, 12 May 2012 (UTC)

The ability to highlight the changes is still there. See above, or the page below, for plenty of ways to customise it to suit your eyes and watchlist. If you need a hand, give me a ping. I'm hoping we can get some kind of gadget out of this that just allows people to pick from options, which is what the original discussion actually wanted. --Elen of the Roads (talk) 12:54, 12 May 2012 (UTC)

I don't want to ping anybody. I liked the change. I can never find options and gadgets on this far too complicated site anyway. Don't make this a site for nerds. Make it friendly to newbies. HiLo48 (talk) 08:25, 13 May 2012 (UTC)

The style used seems to have caused a lot of people to have accessibility difficulties. Part of that seems to be that the entries on the watchlist are on a tight linespacing, and part that the colours are very bright. I'm betting there's a style out there that most people would find non-intrusive enough to accept as the default, but it'll be less bright. It's unfortunate that there isn't a simple way to switch it on/off, as this would end all these arguments, but there isn't. It's either on for the whole wiki or off for the whole wiki. --Elen of the Roads (talk) 14:58, 13 May 2012 (UTC)

How about this as a default (for the watchlist part only). Others can remove or adjust. The lime underline is minimally visible in the line spacing and doesn't seem to have any reducing effects on that (even the grey one seems fine to me). I think new users will never know about it if we make it an opt in feature. --lTopGunl (talk) 15:27, 13 May 2012 (UTC)

I'm collecting options. Certainly add that to WP:CUSTOMWATCH Elen of the Roads (talk) 17:44, 13 May 2012 (UTC)

• Me too! Those who actually liked the change will be more likely to by shy and reluctant to go around like you to see what had happened, why it came to their watchlist and why it disappeared again. I want it back, I want it back (without reading through tons and tons of mostly negative comments). It was saving me lot of time (the thing I have the least of) Reo 20:38, 17 May 2012 (UTC)

Misplaced Pages:Customizing watchlists

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

Next steps

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

Communication suggestion now posted at User:Elen_of_the_Roads/Watchlist_survey. Comments, brickbats etc here or at Misplaced Pages:Village_pump_(proposals)#Next_steps. We have to put out something to let users know that the facility is available should they wish to use it. At the same time, some of the folks who took part in the very first discussion are still of the opinion that it should just be switched on as most users either like it or would get used to it, so we need to find out if that is the case as well. --Elen of the Roads (talk) 12:13, 13 May 2012 (UTC)

Final version with images now done. I'll leave it 24hrs for comments (I notice people have started to fill it in), then move it out of userspace and ask for a watchlist notice, unless anyone objects. --Elen of the Roads (talk) 00:30, 14 May 2012 (UTC)

Real life has intruded

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

Fake Edit Summaries

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

You mean the green "changed since your last.." message. I do believe there is a way to make it invisible as a js hack. --Elen of the Roads (talk) 20:16, 13 May 2012 (UTC)

That is what I'm referring to, do you know if anyone has one working? Monty₈₄₅ 01:42, 14 May 2012 (UTC)

Add this to Special:MyPage/common.css (applies to all skins) or Special:MyPage/skin.css (your current skin):

span.updatedmarker{display:none;}

PrimeHunter (talk) 01:43, 14 May 2012 (UTC)

Overriding to plain text

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

I think you need to explain the question better. Bold text where. What links. If you mean watchlist links, the whole (lengthy) explaination is either above or in the archive. --Elen of the Roads (talk) 21:05, 15 May 2012 (UTC)

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

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

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

Fixed it for you (you may need to bypass your cache). See #Special page - related changes below for details on why the old change stopped working. Anomie⚔ 16:14, 17 May 2012 (UTC)

Anomie's latest change to Common.css was here on 17 May. Anomie had previously explained what to do at Misplaced Pages talk:Customizing watchlists#Changes needed. I made the recommended change to my vector.css and it restored the bolding as promised. EdJohnston (talk) 16:28, 17 May 2012 (UTC)

Thank you kindly. Returned tired and sunburnt from pedalling a daylong, 30 mile, umm 50 km photo trip, and felt much better to turn on the home computer and see a friendly face of watchlist. Hope a simple opt-out button in Preferences can soon do such things. And for that matter, in the list of diffs, a similar scheme would be better than words saying a page has been "updated since last visit". Jim.henderson (talk) 23:51, 17 May 2012 (UTC)

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

The bolding itself was de-activated temporarily due to backlash while a more permanent solution is being considered. See Misplaced Pages:Customizing watchlists for instructions on removing the other remnants of this feature for yourself, or re-enabling the bolding, whichever you prefer. Equazcion 08:15, 18 May 2012 (UTC)

Being able to customise stuff is all well and good if that's what you want, and if you know what to do. But the default uncustomised state should at least make sense, without non-functional buttons and irrelevant messages. I shouldn't have to "remove the remnants". The button and message should only appear if they work, whether this be by default or following customisation. Bazonka (talk) 09:43, 18 May 2012 (UTC)

We are in complete agreement. The developers responsible for these changes were either unable or unwilling (it's unclear) to undo them. This temporary override was initiated by Misplaced Pages's administrators, who have more limited access, as a last resort. Equazcion 09:58, 18 May 2012 (UTC)

I've filed a bug for this. I don't think this was tracked otherwise, so there is no chance to get it fixed. — ☠MarkAHershberger☢(talk)☣ 15:29, 18 May 2012 (UTC)

I use this and it works fine with me. With the bolding in the watchlist, no message and no button. Oda Mari (talk) 06:17, 19 May 2012 (UTC)

Good for you Oda, but you're missing my point. Most users won't want or know how to use css code. It should just be correct, without the need to resort to this kind of workaround. Bazonka (talk) 08:18, 19 May 2012 (UTC)

Problems in categorization of BLPPRODs "by days left", any template magic

The WP:BLPPROD template attempts to sort the articles it finds into Category:BLP articles proposed for deletion by days left, which sounds tasty.

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.

The relevant code is at Template:Prod blp/dated via Template:Prod blp for interested parties.

So, clever people, workarounds? Ideas? --joe decker 06:46, 15 May 2012 (UTC)

Meh, maybe the real issue is this --joe decker 07:16, 15 May 2012 (UTC)

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:

1. You could similarly sub-categorise according to the date of nomination, but that would create numerous sub-categories (a new one every day).
2. 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).
3. 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).

— Richardguk (talk) 08:26, 15 May 2012 (UTC)

Or a bot could go through the articles daily and make a null edit if they are not categorized correctly. Null edits update category pages. Purges don't. PrimeHunter (talk) 13:24, 15 May 2012 (UTC)

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.

Anyway, the brainstorming is much appreciated, folks. Thanks! --joe decker 20:57, 15 May 2012 (UTC)

A null edit is not shown in the page history or elsewhere. PrimeHunter (talk) 22:06, 15 May 2012 (UTC)

I did not know that, that pretty much does seem potentially practical. --joe decker 08:51, 17 May 2012 (UTC)

I tihnk I'm going to follow up and attempt a BRFA on the idea. Thanks! --joe decker 19:18, 19 May 2012 (UTC)

Major problems with new Misplaced Pages 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 Misplaced Pages 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)

• Sorry about the problems with the recent deployment of the mobile site. A lot of unexpected problems crept in. The fixes to most of the problems should be deployed today. --Philinje (talk) 17:52, 15 May 2012 (UTC)

• Yeah I also seem to be having some problems, even though I use an iPod Touch. I'm also probably the only person who browses Mobile Misplaced Pages on a computer though. Anyway, aside from the fact that sometimes the whole page doesn't load (just a few sections), another problem I have is if I try to open a new tab, when I go back to the old tab, it goes back to the top of the section! Very, very, very annoying. Narutolovehinata5 01:28, 16 May 2012 (UTC)

We haven't seen any more of these issues creep up after last weeks pushes. Let us know if you see any more. Tfinc (talk) 22:07, 21 May 2012 (UTC)

REVISIONID

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

I hope you realise that it only works after the page is saved, and updates after the page is edited each time, so you might want to substitute it.  Hazard-SJ  ✈  02:02, 16 May 2012 (UTC)

No I didn't. That won't really work as cleanup templates aren't substituted. Is there another way to link to the diff that added the template? AIRcorn (talk) 00:03, 17 May 2012 (UTC)

Can't one do something like {{tag|1=}}? Something more refined, obviously. But I still think it's doable. Killiondude (talk) 18:56, 17 May 2012 (UTC)

Yes this could have been done, unfortunately I am not allowed to do it. Rich Farmbrough, 01:22, 24 May 2012 (UTC).

I was trying to do something similar yesterday: creating a template like this for use like this? But didn't work, because the magic word returned an empty string (although I think in a previous MW version it used to return the id of the revision just saved). Helder 14:56, 24 May 2012 (UTC)

Template parsing

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

{
    "Template:X3":
    {
        "bla{h":"Hello!"
    }
}
Something like this, taken from https://en.wikipedia.org/search/?title=Misplaced Pages:Sandbox&diff=prev&oldid=492475629

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

You should be able to do that with Regex pretty easily I imagine. Could you give us a little more detailed description of what you are trying to do. It could just be me and my tired 1AM brain but its kinda unclear from the description what your trying to do. Kumioko (talk) 04:27, 17 May 2012 (UTC)

What I'm trying to do is capture a template from wikitext, that looks something like {{Foo|bar={{baz|b{oo=far}}}} Regex cannot be used for this purpose, because there are nested templates and uneven braces. So that leads to my question, is there already a method of extracting the template? →Στc. 05:19, 17 May 2012 (UTC)

Using regex is horrible, don't do it. It's like drugs; seems like a great idea at the time, but in the long run you end up with more problems than its worth. Even simple things like a link in the template (e.g. {{foo|]}}), 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:

It runs like so:

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

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

That's a fun piece of code. Haven't tested it at all, but it looks like it doesn't handle template parameters ({{{param_name|default}}}, etc), although I guess that's not a common sight on article pages. More generally I think it won't like multiple sets of braces put together; things like {{template|foo={{bar}}}} or especially {{{{WorkOutWhichTemplateToCall}}|foo=bar}} will make it go in or out too many levels. Also image captions can contain links: ] which confuses things]]. But a valiant effort nonetheless! :D Happy‑melon 14:03, 17 May 2012 (UTC)

It deliberately doesn't deal with template parameters, it's just way too ugly (and lets face it, if you're trying to parse actual templates, you're going to need something beefier than this, that can handle all the parser functions etc). Image captions with links it can deal with, and {{template|foo={{bar}}}} is also fine (I actually wrote it specifically for that purpose, so that I could parse templates that have templates as arguments). However, you are right {{{{WorkOutWhichTemplateToCall}}|foo=bar}} doesn't work. Damn. --Chris 16:30, 17 May 2012 (UTC)

Actually, strike that about the images with captions. This version can't deal with them (although your example does work, this code ] which confuses things|right]] doesn't). I have a different version that does actually deal with that problem, however it breaks with other things, and is not ready for primetime yet. --Chris 16:50, 17 May 2012 (UTC)

I have similar code (but in Perl) at User:AnomieBOT/source/d/Templates.pm. My version uses a callback architecture, so giving it {{foo|{{bar}}}} will call the callback for bar and then for foo, and the callback can return new wikitext to directly replace the template if desired. It also tries to handle <nowiki>, <ref>, and so on in a reasonable manner. Anomie⚔ 01:52, 18 May 2012 (UTC)

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

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

Cache of Thomas (activist)

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

What exactly is different on your end (as an anon)? I checked it and don't see anything. In general, however, anonymous users use cached versions of pages but it normally isn't more than just a few edits behind the live version. Killiondude (talk) 19:14, 17 May 2012 (UTC)

This is the page when not signed in and when directed from external site. Nirvana2013 (talk) 21:14, 17 May 2012 (UTC)

The bottom of pages say "This page was last modified on ...". That part is missing in your screenshot but it does look like an old version. If purging doesn't help then it may be your ISP. See Misplaced Pages:Bypass your cache#Internet Service Provider Cache. Try adding a '?' to the url as in http://en.wikipedia.org/Thomas_(activist)? PrimeHunter (talk) 22:15, 17 May 2012 (UTC)

The page says "This page was last modified on 1 May 2012 at 10:22." The article is now 18 days out of date! If you can see the updated page as an anon, then you must be right that it is my ISP (which is BT in the UK). Any ideas on how to rectify for good, rather than adapting the url? Nirvana2013 (talk) 13:40, 18 May 2012 (UTC)

It seems to be only one day outdated for me, as logged in I see 18 May, yet logged out I see 17 May.  Hazard-SJ  ✈  03:03, 19 May 2012 (UTC)

Thanks Hazard-SJ. I do not know what is going on with BT's cache. "BT is the largest ISP in the UK with currently 4,600,000 broadband users." This does not seem very good for a number of potential Misplaced Pages readers. Nirvana2013 (talk) 10:01, 19 May 2012 (UTC)

Hamletbot considered desirable

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

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

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

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

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

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

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

I've started to go through the pages manually - most of them are fairly easy to spot so I haven't had to look at each and every article. But it's a bigger job than I'd anticipated, and it won't get finished immediately. A bot would certainly help, but it could end up introducing new errors, e.g. linking to Hamlet (place) when the correct link would be Hamlet (fish). Bazonka (talk) 12:49, 19 May 2012 (UTC)

I found that there are 122 articles in the Category:Saskatchewan geography stubs that contain links to Hamlet. I think it's pretty safe to assume without hand-checking that all of these should link to hamlet (place) so I'm correcting them. I suspect there may be one or two other cases like this. That category appears to be unique; any remaining errors will have to be detected some other way. --R'n'B (call me Russ) 13:21, 19 May 2012 (UTC)

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

So you'd rather break 4,500 links than fix 200 of them? OK, that was a rhetorical question. Anyway, the question isn't what's "more important"; the question is whether one of these is the primary topic for the ambiguous term "hamlet." --R'n'B (call me Russ) 20:18, 19 May 2012 (UTC)

I've now gone through the entire list of articles that link to Hamlet and fixed about 250 or so. I think that between us R'n'B and I have probably fixed the bulk of this problem, although undoubtedly some will still remain incorrect. There are also quite a few like "X was an actor who played Hamlet" where the link is to the page for the play - arguably it should link to the character, Prince Hamlet. However, I guess that this isn't a real problem because at least they link to something relevant. Bazonka (talk) 16:02, 20 May 2012 (UTC)

I guess we have different views of long-term significance. -— Isarra ༆ 17:02, 20 May 2012 (UTC)

Maybe, but in the end we should both be guided by consensus. If you think the current naming is wrong, feel free to propose moves of the articles about the play and about the community. (I presume we both agree that the fish is not in contention.) However, if there is a consensus favoring such moves, someone will need to take the responsibility of fixing all affected links either before or contemporaneously with the moves. --R'n'B (call me Russ) 17:08, 20 May 2012 (UTC)

Hamlet the character is only notable because of the play. Arguably, the type of place is more important than the play, but I would disagree - at best they are of equal importance. However, we need to take into account the collateral damage of changing the scope of the Hamlet article, and this would be huge if it changed from anything but the play. It's just not worth it. Bazonka (talk) 17:21, 20 May 2012 (UTC)

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

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

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

tested on Firefox 12 and Internet Explorer 10

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

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

I've turned off the extension for now. Kaldari (talk) 18:47, 19 May 2012 (UTC)

Monobook

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

importScript('Misplaced Pages:AutoEd/complete.js');

importScript('User:Timotheus Canens/afchelper4.js'); // Yet another AfC helper script v4.

importScript ('User:Henrik/js/afc-helper.js');

addOnloadHook(function() {

 addPortletLink ('p-tb', wgArticlePath.replace(/\$1/,'User:SGGH/vector.js'), 'My Vector');

}); addOnloadHook(function() {

 addPortletLink ('p-tb', wgArticlePath.replace(/\$1/,'User:SGGH/Useful policy links'), 'Useful policy links');

}); addOnloadHook(function() {

 addPortletLink ('p-tb', wgArticlePath.replace(/\$1/,'Category:Pending AfC submissions'), 'P.AFC');

}); addOnloadHook(function() {

 addPortletLink ('p-tb', wgArticlePath.replace(/\$1/,'WP:UAA'), 'WP:UAA');

}); addOnloadHook(function() {

 addPortletLink ('p-tb', wgArticlePath.replace(/\$1/,'WP:AIV'), 'WP:AIV');

}); addOnloadHook(function() {

 addPortletLink ('p-tb', wgArticlePath.replace(/\$1/,'WP:ANI'), 'WP:ANI');

}); addOnloadHook(function() {

 addPortletLink ('p-tb', wgArticlePath.replace(/\$1/,'CAT:SPEEDY'), 'Speedy Deletion');

}); addOnloadHook(function() {

 addPortletLink ('p-tb', wgArticlePath.replace(/\$1/,'Special:Newpages'), 'New Pages');

}); addOnloadHook(function() {

 addPortletLink ('p-tb', wgArticlePath.replace(/\$1/,'Misplaced Pages:Categories for discussion'), 'Categories for discussion');

});

addOnloadHook(function() {

 addPortletLink ('p-tb', wgArticlePath.replace(/\$1/,'Category:Unassessed Law enforcement articles'), 'Unassessed WPLE Articles');

});

addOnloadHook(function() {

 addPortletLink ('p-tb', wgArticlePath.replace(/\$1/,'Category:Uncategorized pages'), 'Uncategorized Pages');

});

importScript('User:TheDJ/Gadget-HotCat.js');

importScript('User:AzaToth/twinkle.js'); TwinkleConfig = {

       revertMaxRevisions              :       50,
       userTalkPageMode                :       'window',
       showSharedIPNotice              :       true,
       openTalkPage                    :       ,
       openTalkPageOnAutoRevert        :       false,
       summaryAd                       :       " using TW",
       deletionSummaryAd               :       " using TW",
       protectionSummaryAd             :       " using TW",
       watchSpeedyPages                :       ,
       watchProdPages                  :       false,
       openUserTalkPageOnSpeedyDelete  :       ,
       watchRevertedPages              :       ,
       markRevertedPagesAsMinor        :       ,
       deleteTalkPageOnDelete          :       false,
       watchWarnings                   :       false,
       markAIVReportAsMinor            :       true,
       markSpeedyPagesAsMinor          :       true,
       offerReasonOnNormalRevert       :       true,
       orphanBacklinksOnSpeedyDelete   :       {orphan:true, exclude:}

}; importScript('User:Ioeth/friendly.js'); FriendlyConfig = {

       summaryAd                       :       " using Friendly",
       topWelcomes                     :       true,
       watchWelcomes                   :       false,
       markWelcomesAsMinor             :       true,
       insertHeadings                  :       true,
       welcomeHeading                  :       "== Welcome ==",
       insertUsername                  :       true,
       insertSignature                 :       true,
       quickWelcomeMode                :       "auto",
       quickWelcomeTemplate            :       "Welcome",
       markSharedAsMinor               :       true,
       groupByDefault                  :       true,
       watchTaggedPages                :       false,
       markTaggedPagesAsMinor          :       true

};

importScript('User:Mr.Z-man/refToolbar.js');

importScript('User:Smith609/toolbox.js');

RefToolbar is now enabled by default. Remove importScript('User:Mr.Z-man/refToolbar.js'); and reload per the instructions at the top of your JS page. ---— Gadget850 (Ed)  14:16, 20 May 2012 (UTC)

Ah, that's back again - but still not auto-populating? S.G. _ping! 20:38, 20 May 2012 (UTC)

Date sort screwing up

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

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

Thanks for posting this here, Equazcion. I posted a Q over at the Help Desk because I couldn't really figure out the explanations either. Hopefully someone'll know! :) Salvidrim! 15:12, 20 May 2012 (UTC)

Try something like <span style="display:none;">{{#time:Y-m-d|{{{date1}}} }}</span>{{{date1}}} etc. in a template although I note that there are two ambiguous dates listed. Is it d-m-Y (23-01-2025) or m-d-Y (01-23-2025)? – Allen4names 15:31, 20 May 2012 (UTC)

This is copied from the help page, so I'm not sure what the original intent was. If this table is meant to work, it could conceivably take the format of the entries with named months as indication that they're all d-m-y. My main question though is, are the hidden labels always necessary? Is there a way to do this by grouping d-m with wikilinks? The help page seems to indicate something like that, and might even be saying that isn't necessary, but I can't tell because it seems to have been written by someone with some sort of neurological disorder. Equazcion 15:38, 20 May 2012 (UTC)

P.S. The template is {{Dts}}. – Allen4names 15:40, 20 May 2012 (UTC)

I think the moral here is - be consistent with your date formats and it'll be alright on the night. NtheP (talk) 15:42, 20 May 2012 (UTC)

The only all-number date allowed by WP:MOS is yyyy-mm-dd. (Also tweaked the above for full year as there is also an 07 April entry and poor me got confused.) --Mirokado (talk) 15:45, 20 May 2012 (UTC)

Consistency doesn't seem to work on its own, I've tried. The template Allen4names posted is the only thing that seems to have worked so far, so thank you very much for that, Allen. I'd still like to know what's up with this though. I want to clean up that help section so it looks less like a schizophrenic clown's pubic hair (I'm running out of ways to insult this thing, sorry). Equazcion 15:50, 20 May 2012 (UTC)

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

I edited the table above to be consistent as , which according to your interpretation of the help page, should work. It doesn't seem to though. Equazcion 16:03, 20 May 2012 (UTC)

It seems to work if every month is given as three letters. The letters can be first-letter capitalized ("Sep") or all-caps ("SEP"). It does not work if the months are spelled out (September). Jc3s5h (talk) 16:34, 20 May 2012 (UTC)

Sorry I should've said . The table above is currently formatted as you suggest, but the sorting still screws up. Give it a try. Equazcion 16:37, 20 May 2012 (UTC)

OK, so it seems to be translating the month abbreviations to a number, but sorting first on the year, then on the day-of-month, and last on the month, so it is indeed broken. And, in my view, not worth fixing. Jc3s5h (talk) 16:41, 20 May 2012 (UTC)

• Whoa, what? When is any bug not worth fixing? Even the most minor bugs need to be corrected. The whole point of creating and maintaining any kind of system is make it as error-free as possible, and ignoring or dismissing errors certainly runs contrary to that goal. Salvidrim! 16:49, 20 May 2012 (UTC)
  • From Jc3s5h's other comments above, it seems he means that the whole feature should be tossed out since it's in such bad shape -- not quite that it should be ignored. I'd love to demolish that help section myself to make it clear that this feature isn't worth any attempt to use except with the {{dts}} template. Equazcion 16:53, 20 May 2012 (UTC)

Yes, my view is that the feature should be removed; let the table editor either put in date strings that are directly sortable (YYYY-MM-DD) or use the dts template. Any effect in existing tables would be a benefit, since its better to have an obvious error that a subtle one. Jc3s5h (talk) 17:32, 20 May 2012 (UTC)

Ah, I get it. :) Salvidrim! 17:37, 20 May 2012 (UTC)

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

I just took a wrecking ball to Help:Sorting#Dates. Equazcion 18:16, 20 May 2012 (UTC)

(edit conflict) We are using the new tablesorter module, we just can't take advantage of the explicit column tagging feature until HTML5 is enabled. This bug is unrelated: the date sorting of the tablesorter module could easily determine that "1 Apr 2012" is DMY order and "Apr 1 2012" is MDY order, but for some reason it doesn't. It just converts them to "1 4 2012" and "4 1 2012", respectively, and then assumes MDY or DMY order based on the global wiki configuration. Anomie⚔ 18:19, 20 May 2012 (UTC)

My SWAG is that the new tablesorter without HTML5 makes it attached to another object by an inclined plane, wrapped helically around an axis. ---— Gadget850 (Ed)  18:42, 20 May 2012 (UTC)

I should think that would've been obvious. Equazcion 18:50, 20 May 2012 (UTC)

I'm pretty sure the axis referred to by Gadget850 is normal to a toilet bowl rim. Jc3s5h (talk) 19:11, 20 May 2012 (UTC)

I almost fell over laughing when I read "the new tablesorter without HTML5 makes it attached to another object by an inclined plane, wrapped helically around an axis." A while back I spent a few days trying to figure out just a few problems with table formatting for sorting. It nearly drove me nuts. I did manage to add some accurate (at the time) info to Help:Sorting. I did not even attempt to figure out full date sorting though. I did manage to figure out a few permutations of year-only sorting. Also, I figured out some of the numerical sorting problems. --Timeshifter (talk) 10:31, 22 May 2012 (UTC)

A question for CSS specialists

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

You could try the following, assuming we're talking about the Vector skin:

--R'n'B (call me Russ) 17:50, 20 May 2012 (UTC)

"This page is a member of 2 hidden categories" is probably dealt with the preference in the Appearance tab at Special:Preferences labeled "Show hidden categories". --Izno (talk) 00:10, 21 May 2012 (UTC)

Nope, that preference refers to viewing the article normally, not in the edit window. Graham87 02:03, 21 May 2012 (UTC)

Thanks everyone. I've tried these to put in monobook.css but I don't get the desired results. I'm using the vector skin. Please take a look at User:EngineerFromVega/monobook.css. EngineerFromVega 03:56, 21 May 2012 (UTC)

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

Perl call to get search results

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

See mw:API, particularly mw:API:Search. Anomie⚔ 22:37, 20 May 2012 (UTC)

I will take a look. Thank you. History2007 (talk) 04:44, 21 May 2012 (UTC)

File redlink should not lead to godawful upload form

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

As an admin it's also annoying because I might want to track patterns of those deleted images (all I want is the deletion log-entry and associated links). When one follows a redlink to an article (or other text-content) page that has been deleted, there's a pink "A page with this title has previously been deleted." box with log entries, etc. Seems like this same UI feature would be just what we need on the first upload-page one gets when following a redlink to an image. DMacks (talk) 21:10, 20 May 2012 (UTC)

Yes, that makes sense. I think they changed it because it was pointless to encourage edits to "create" file pages, instead of uploading files. Why not create a hybrid? Show the page logs at the top (like a normal redlink), and the upload links at the bottom (instead of an edit field)? Clicking the edit tab should still allow you to create a file page, so everyone would win. ▫ JohnnyMrNinja 21:17, 20 May 2012 (UTC)

Is there any chance of a script/preference workaround for this? Could the navigation popup catch this as a special case and display something about the wpDestFile instead of telling us about the upload wizard? -- John of Reading (talk) 16:17, 21 May 2012 (UTC)

In principle, the WP:FUW page itself could be made to recognize the wpDestFile= parameter and include a message with the deletion log etc if necessary. However, for this to be possible, it would be necessary to make the script globally available through one of the global script files. But the better option is certainly to have the redlinks point somewhere else from the start, see for options below. Fut.Perf. ☼ 06:31, 22 May 2012 (UTC)

Until Future Perfect at Sunrise decided to rename the page three months ago, there was always a link to the deletion log at Misplaced Pages:Upload. I've never seen the benefits of moving the page, but this is a clear downside to having it moved. Nyttend (talk) 01:30, 22 May 2012 (UTC)

I pinged FutPerf. DMacks (talk) 02:19, 22 May 2012 (UTC)

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

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

• Image redlink with colon (]): File:Just an example.jpg (links to https://en.wikipedia.org/search/?title=File:Just_an_example.jpg&action=edit&redlink=1 , i.e. the edit page of the non-existing file page)
• Image redlink without colon: File:Just an example.jpg (links to https://en.wikipedia.org/Wikipedia:Upload?wpDestFile=Just_an_example.jpg)
• Fake link demonstrating what would happen if we reverted Misplaced Pages:Upload to what it was before February: File:Just an example.jpg
• Fake link demonstrating what would happen if redlinks went to Special:Upload per original Mediawiki default behaviour: File:Just an example.jpg
• Fake link demonstrating what would happen if redlinks went to the non-existing file page, without "action=edit": File:Just an example.jpg

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

So, if moving the page back to the previous title wouldn't help, what would? All I know is that it stopped appearing exactly at the same time as when you moved and rearranged the page substantially. Nyttend (talk) 12:13, 22 May 2012 (UTC)

What would help would be to get the MediaWiki variable that governs the behaviour of these redlinks changed to point to one of the url types listed above. I forget what it was called, but there is such a variable. It's something that has to be requested on Bugzilla and done by the devs, but other than that it's fairly easy. We just need to decide which of the above we want. Fut.Perf. ☼ 13:52, 22 May 2012 (UTC)

Images overlapping with table

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

I added a {{clear}} that solved the issue on Safari, and was going to come here to comment that since a) I didn't see the problem with other PC browsers I tried, b) the overlap only appeared with PC Safari with a fairly narrow window sizing, and c) it leaves a hideous amount of whitespace on all browsers at all window sizings, I was going to say it might not be worth it, but now see that my "fix" was immediately reverted as "unacceptable solution", so not sure what to suggest. (Well, I have a theory about breaking the table up alphabetically and having one image/clear per sub-table, but that kinda defeats the purpose of having a sortable wikitable, and again, given the limited number of users affected, probably wouldn't fly, either.) 71.197.246.210 (talk) 01:23, 21 May 2012 (UTC)

Thanks for responding and trying something. I can see how the whitespace was a problem, and yes splitting it up would not work as you would not be able to sort. I'd like to think there is a technical solution, as I've seen pictures on the right on similar articles. Eldumpo (talk) 07:39, 21 May 2012 (UTC)

Pictures on the right of tables is oftentimes a problem. A gallery section would solve the problem. See Misplaced Pages:Gallery tag:

<gallery> </gallery>

You can eek out a little more space for photos on the right by putting the sorting icons above the header text. See the last part of this section: Help:Sorting#Header styling, links, and markup --Timeshifter (talk) 10:42, 22 May 2012 (UTC)

Watching topic

This discussion is brought over from VPI

Before I start, let me say I have no idea how to do this, I just think it is a good idea. But will be willing to help anyone who wants to implement it.

At the moment, we have the option of watching pages. If I want to watch just one topic or discussion on that page, I have to watch the whole page. So when I look at what has changed in my watchlist, even things I am not interested in pop up. I think it would be a good idea to have an option whereby a user can watch a page, but also watch a topic, heading, or sub-heading of a page or article. Kinkreet 20:54, 16 May 2012 (UTC)

It's a good idea. There is the script Catwatch lets you watch a category for changes (I misunderstood)Equazcion 21:14, 16 May 2012 (UTC)

I don't think that's what Kinkreet is after. It sounds more like s/he would like to be able to watch (for example) a single discussion at WP:ANI without having to watch the entire page. WhatamIdoing (talk) 21:19, 16 May 2012 (UTC)

Oops I wasn't paying attention. Yeah this has been brought up before. Actually they were thinking of making all the ANI discussions into transcluded pages, so people could watch them individually and avoid edit conflicts, as is done on some other process pages. It never came to fruition though. The ability to watch a particular header would definitely be awesome. I think it would require some significant new coding and database changes in MediaWiki though. Equazcion 21:29, 16 May 2012 (UTC)

WhatamIdoing caught my idea right on, thanks. I want it (and I think others want it as well) for following a single discussion, as well as following a section of a large article. For example for quantum mechanics, if someone is a historian and only want to keep an eye out for the history of quantum mechanics, I think it would be more efficient for them if they are able to watch just that section, for example. Kinkreet 10:41, 17 May 2012 (UTC)

Yes, a good idea, and may require effort to implement if it requires schema changes as Equazcion said. But as they say leave it to the bot. If the user has patience, a bot could produce such a report without Mediawiki modifications and produce a report once a day. And that would not overload the Mediawiki servers if and when distributed bots fly... but let me not get off topic, for this is unlikely this year. History2007 (talk) 21:57, 18 May 2012 (UTC)

I think we have establish this might be not a simple implementation, but if there is someone who we can talk to about this, who would it be? Kinkreet 12:31, 19 May 2012 (UTC)

It would have to be brought up at bugzilla, that's how we communicate with the developers who make the major changes. It can be tough to get them to do stuff that constitutes major new features, unless a broad consensus is demonstrated first by the community (even then it can be difficult). A !vote at WP:VPT would probably be needed first. I can't predict how that might go. Equazcion 12:47, 19 May 2012 (UTC)

Thanks for the advice, I will move this discussion over there. Kinkreet 08:26, 21 May 2012 (UTC)

It's a good feature request, and one that's been on the table for at least five years (and probably a lot longer). Basically, it's not technically feasible to literally watch the sections on a page; but as has already been mentioned, each section could be a transclusion of some other page, and you could watch that. These sorts of considerations fed into the design of a new extension, LiquidThreads; unfortunately, that project has a rather checkered history, so it's not deployed yet (and may not be for some time). Hence why you still can't watch individual sections of a page, unless you manually transclude them out, unfortunately. - Jarry1250  09:58, 21 May 2012 (UTC)

Interwiki BOTs

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

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

Thanks for taking a look, thought there had to be a simple explanation. Keith D (talk) 17:23, 21 May 2012 (UTC)

New pages bug?

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

Where are you clicking this from? Special:NewPages or somewhere else? This wiki or another wiki? (The problem seems to be with the use of a non-standard & character.) - Jarry1250  15:31, 21 May 2012 (UTC)

When coming to an unpatrolled page from Special:NewPages, a link appears at the bottom that says . See Misplaced Pages:New pages patrol/patrolled pages  Liam987(talk) 19:46, 21 May 2012 (UTC)

Happened on Bostan Khan as well  Liam987(talk) 20:21, 21 May 2012 (UTC)

Has anyone else had this happen?  Liam987(talk) 13:38, 22 May 2012 (UTC)

Special:NewPagesFeed was apparently just deployed, along with MediaWiki 1.20wmf3 (below), so maybe it has something to do with one of those. I just tried patrolling a page and didn't get an error; I don't know if you're getting it every time or just intermittently? Equazcion 13:47, 22 May 2012 (UTC)

It's only happened several times, and not on all pages.  Liam987(talk) 17:50, 22 May 2012 (UTC)

MediaWiki 1.20wmf3 deployment happening shortly complete

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

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

Bug with RevDel

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

The same issue occurs with deleted pages (example). Reaper Eternal (talk) 19:01, 21 May 2012 (UTC)

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

Yet MORE idiocy thrust on us?

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

Meh, I quite like it (why so much hate?). Also it changes the title tag (displayed in your tabs) to make it more obvious which tabs are diffs and which aren't. It's quite clearly a more informative title that what preceded it, anyhow. Ugly, maybe, but certainly more functional (i.e. hardly "stupid", IMHO). It was bug #33928, by the way. - Jarry1250  22:41, 21 May 2012 (UTC)

I think the important thing here is that we continue to oppose every single change that ever happens to the interface with a response that is out-of-proportion with the change itself. Indeed, it is important to keep in mind that the developers are purposely trying to make Mediawiki worse so that people will no longer want to contribute to Misplaced Pages, and we also need to keep in mind that there is no such thing as a good change. Change is always for the worst, and for that reason we must oppose it, and we must also use inflamatory language and act far more personally incensed than we have the right to be. Or maybe we shouldn't do that. --Jayron32 23:06, 21 May 2012 (UTC)

This change was also discussed on commons, and an improvement made as a result. Specifically, Amir is changing it so that the title of the article will precede the explanatory text. That should roll out with 1.20wmf4, which is due in two weeks. -- RobLa-WMF (talk) 00:09, 22 May 2012 (UTC)

Per Jayron32: We must also oppose editors editing articles in a manner that changes something that previously existed, because the prior state will then only exist in the article history. We must not allow editors to edit articles such that the prior intent of an earlier editor is overridden. Previous editors know better than current editors, so established revisions of articles must always be retained. Nothing must ever be lost if someone put it in an article before someone else got there. Assume that previous editors were right and that anyone who makes a change, has made a mistake. See also: Happy-melon and Jorm (below); such technical people should be restricted to code they can develop by carving wood with chisels so that everyone can have a chance of understanding it. Change is bad; usually blockably so. Br'er Rabbit (talk) 09:19, 23 May 2012 (UTC)

What Jayron said. The horrific technological inertia that is developing within the community is only going to lead to two possible outcomes (or some even-less-sustainable combination of the two). Either the developers abandon any hope of satisfying the community and stop bothering to even try to engage with it, or they stop trying to develop beneficial features at all. Either approach has only downsides and (ironically) even less chance of the issues the community genuinely feels strongly about being addressed. Is making such a strong statement about the change of the title of a non-reader-facing page really proportionate? Happy‑melon 00:17, 22 May 2012 (UTC)

^This.--Jorm (WMF) (talk) 00:22, 22 May 2012 (UTC)

Well it was quite a shock, and as it's something I have to look at many times a day it's jarring. Right now I have seven tabs that say "Difference betw..." on them. No idea which is which, so how can I know which are likely to be quick checks and while I want to save until the end to spend more time of them? If the article name will be moved to the front, I guess that solves that issue, at least. But what's the point of it anyway? It's completely redundant driven by the fact that the grey and green is above the article, which means that it's very easy to glance and see it's a diff in the first place. ♫ Melodia Chaconne ♫ (talk) 01:34, 22 May 2012 (UTC)

When editing or moving pages, the page title changes to "Editting (x)" or "Move (x)", similar to the way DIFFs are currently titled. Were there any complaints about it? If you are viewing several editors contributions at once, it has been difficult to distinguish them by tabs alone because they are titled "User contributions of (User name)". Do you wish them to be changed as well? Or new ones (DIFFs) only? --Kusunose 02:41, 22 May 2012 (UTC)

You know, we can easily change this by editing the appropriate MediaWiki-namespace page. I've taken the liberty of changing MediaWiki:history-title, MediaWiki:difference-title, and MediaWiki:difference-title-multipage to match the change linked above by RobLa-WMF (please delete those pages when 1.20wmf4 is live). Also, I agree with Happy-melon above. Anomie⚔ 02:54, 22 May 2012 (UTC)

Thanks, I just noticed that change. It's much better to have the article title first as that is what is important, and it's the only thing visible when have many tabs. Johnuniq (talk) 03:08, 22 May 2012 (UTC)

The point previously made about mistaking "Revision history" for part of the title (in this new version, where the quotes are removed and the page action put after the title, separated by a colon) - is a good point. Which is one of the reasons I very much dislike this re-ordered construction, entirely. To make tabbed browsing easier, We normally use a reversed breadcrumb in the page title (Action < Page name < Site name). Up until now that was the case for all actions and special pages. But this is now broken for Diff and History. For example, right now I see tabs "Editing User:Kr..", "My Watchlist - W..", "Misplaced Pages:Villag..", "Misplaced Pages:Villag.." and "Misplaced Pages:Villag..". I can't tell which of these last three is view, Diff or History. Now one could make a similar point when saying you have tabs "Difference ..", "Difference .." and "Difference ..". So I doubt there is really much of a gain for either. But whatever the case, consistency throughout the interface is most important. And right now these "Diff" and "History" are inconsistent with all other titles, because those titles (Edit, Move, Delete, View source, What links here, ...) all put the action first and quote the page title (which has so far always prevented most confusion about which part the page name is). Krinkle (talk) 03:18, 25 May 2012 (UTC)

How many different types of views are there? I have no clue what type of work it takes to change stuff like this, but do we need 'Difference between revisions' instead of just 'Diff' or even just 'D'? 'Hist' or 'H' instead of 'Revision history'? I'd think we could come up with some system that would allow several tabs to be up at once showing what type of view and for which page at the same time. Do we need such long descriptions? --Onorem♠Dil 04:23, 25 May 2012 (UTC)

Remember that we want the titles to be transparent to new users as well. "D" and "H" certainly don't fit that bill. Anomie⚔ 11:36, 25 May 2012 (UTC)

Beyond all that, it really breaks my brain sometimes. I keep thinking "Difference between revisions" is part of the title. But once again, I ask what the POINT of it is in the first place? It's 100% clear that it's a diff by virtue of the extra stuff at the to

I have the same brain breakage with the diff pages. OTOH, I've long used a small script to remove the "Revision history of" bit on history pages for the same reason the devs changed the default message now: lots of tabs all saying "Revision his..." are useless. There is a way to change both messages: get consensus and we can edit the appropriate MediaWiki-namespace pages to say whatever we want. Or use a script to rewrite the page title and <h1> tags on history and diff pages, if you can't get consensus to change it for everyone. Anomie⚔ 16:31, 25 May 2012 (UTC)

I wanted to respond to Happy-Melon's remarks. I don't really see anything wrong with this particular change FYI. However, as someone who participates at VP Proposals and basically always has, I'd just like to point out that the developers would probably find themselves getting better responses if they worked on changes the community has been requesting. Realizing full-well that they're mostly volunteers and can spend their time the way they like, I think a better job could be done in encouraging development of what the community wants, rather than their own whims regarding what is best for the community. They've become a little too comfortable with the latter over the years for my taste, and it would appear I'm not alone in feeling that. Most rights-wielding users have been more-or-less trained to be sensitive to the fact that their privileges are only there to serve the community's decisions. I feel this much less from developers. Perhaps it's a disconnect that started with the use of bugzilla, a forum outside of Misplaced Pages, where development business is discussed outside the purview of the average user (even most non-average users). The argument could be made that that's a good thing, and certainly that bugzilla's features are more conducive to development talk. I just don't know if keeping things status-quo is worth risking the kind of breakdown Happy-Melon describes, which does seem plausible. Equazcion 04:35, 22 May 2012 (UTC)

Huh? This was a community requested change, not a developer "whim" about what's best for the community. In fact pretty much all of the development projects that are going on right now are community requested (visual editor, new templating system, PageTriage, etc.), mostly from the English Misplaced Pages community. In fact, we do so much development specifically for the English Misplaced Pages community that the other languages and projects are often upset at being neglected. I agree that Bugzilla isn't ideal, but it's much more efficient than hanging out on the Village Pump all day ;) Kaldari (talk) 05:42, 22 May 2012 (UTC)

I was speaking more in general terms, but if you could point me to the discussion on this change, that might help. Surprised you'd bring up triage though, considering that was hardly the community's first choice. I wasn't prescribing any particular solution, least of which handing development discussions entirely over to VP. But if you want idea seeds: Some sort of automated cross-posting of promising bugs to a page that doesn't require a separate login from Misplaced Pages; or some sort of "transclusion" of them here, as it were (have a page here read their database). More communication, more visibility, more accountability. Creation-of and adherence-to a policy on Misplaced Pages for proposing, discussing, and implementing interface changes that affect Misplaced Pages's defaults. That's just off the top of my head. Equazcion 06:00, 22 May 2012 (UTC)

Except from en.wikipedia isn't the only MediaWiki wiki, so having MediaWiki development discussions here isn't really the best option. Having an external forum from any particular implementation of MediaWiki is actually quite important, in my opinion. And there is no reason why the MediaWiki developers should have to follow some policy the community on Misplaced Pages make up for them. - Kingpin (talk) 07:34, 22 May 2012 (UTC)

As far as I'm concerned, the developers can feel free to make whatever MediaWiki changes they want, with the notable caveat that anything default is disabled on Misplaced Pages until the community agrees to it via a process. Equazcion 07:36, 22 May 2012 (UTC)

Addendum: I'm not claiming to have all the answers. Nevertheless, Happy-Melon brought up a valid point. Whether or not you agree that people's reactions are justified in these situations, we can't change the way people react just by telling them they should be reacting differently. Why not attempt to address this issue in a way that has a chance of improving it? I'm open to suggestions, but considering there is an incongruence between MediaWiki's development as standalone software vs. its effects on a website purported to be run by a very large community whose interests may differ, I think discussing a policy governing the way MediaWiki changes affects Misplaced Pages could be a good start. Equazcion 07:50, 22 May 2012 (UTC)

"And there is no reason why the MediaWiki developers should have to follow some policy the community on Misplaced Pages make" is exactly the sort of attitude which is giving rise to the frequent and voluminous complaints about changes to the MW software, interface etc. The general feeling is that someone suggests a change, a small coterie of editors agree with the principle without adequately thrashing out the practical, implementation and other issues, and it appears the developers then go ahead on exactly the same basis, and as if "the community" has given carte blanche. Then they recoil in horror when "the community" rejects the change loudly the moment such change 'goes live'. I'm not suggesting the everything needs to have the same degree of community approval, nor that I am unhappy about the subject of this particular discussion. Crux is that editors feel the developers are acting without accountability. The best recent example is the bolding applied to the Watchlist. Of course, it makes little sense to discuss these solely on en.wp as development changes affect other wikis. but the current process (cycle of request–development–trial–roll-out) is not working properly right now, because there is currently no such procedure. --Ohconfucius 08:11, 22 May 2012 (UTC)

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

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

1. The green stars were not a change in MediaWiki, but on English Misplaced Pages itself.
2. Anyone can bookmark a bugzilla query which generates a list of recently fixed (or opened) bugs (check e.g. 130 created during the last week or these 33 bugs fixed during the last month). Then, it is easy to check periodically and mention here on VP any request which seems controversial for the English wikipedia (e.g.: in case it was a request of one of the many other WMF wikis, which may happen to have different needs from enwiki), in order to have more discussion prior to "fixing" the bug.
3. I think it is even possible for someone which the appropriate knowledge to write a bot to check bugzilla periodically and list the recent bugs in a Misplaced Pages page, so that people can watch it without leaving the wiki (there is also a MW extension for this: mw:Extension:Bugzilla Reports). Helder 12:55, 22 May 2012 (UTC)

1. The preceding change that resulted in the backlash that preceded the rash move to green stars was the result of a developer move to change a MediaWiki config option for Misplaced Pages. It makes little difference either way. That that change could occur the way it did, and the backlash, were the result of a lack of governance of interface changes.
2. You're saying users here can keep an eye on bugzilla if they want. That incurs the same problem. The ones who would take that upon themselves aren't the ones whose reactions we're looking to deal with here.
3. This one sounds like a good start. But only a start. Equazcion 13:10, 22 May 2012 (UTC)

I think this really boils down to giving users a choice whether they want certain changes to apply or not, at least initially. In most cases it would be relatively easily to allow the user to check a box or uncheck a box for a given function to apply. If the user wants it great and if not thats ok too. Changes are notoriously hard to implement in WP for Anything but generally better accepted if its opt in or out based on the user. Lets remember that Users are different and I mean this in no derogetory way but some can see better than others, some see colors different, some have trouble reading certain fonts and some of us like things a certain way and once we are used to it get rather irritated when it changes. Same applies here. Kumioko (talk) 14:00, 22 May 2012 (UTC)

Surely the standard option should be the basic, with users able to add whatever embellishments they choose, whereas currently I, and many other users, have to use code to turn things off. This gives longer refresh times and annoying jumps - e.g when the "Mark all pages visited" button initially appears, and then disappears. This is particularly pronounced and frustrating with a poor connection. Presumably this "provide then hide" also adds to the server load, slowing the system down for everyone. The developers seem to have forgotten the KISS principle. Arjayay (talk) 14:26, 22 May 2012 (UTC)

The "KISS principle" apparently does not mean what you think it means, if you think adding a user preference and much conditional code is somehow simpler than just enabling the feature and allowing people to override it with styling. Also note that this "provide then hide" probably adds less to the server load than would "don't provide then issue extra requests to load it extra" would. Anomie⚔ 15:34, 22 May 2012 (UTC)

@Kumioko: Had people not jumped the gun and disabled the bolding for everyone, we'd certainly have a gadget by now that disabled it with a single checkbox click, and then people who wanted different styling could start from either state in their personal CSS. But as it is, we've got the incomplete hiding in the site-wide CSS and massive arguments over whether it should be shown again and how exactly it should look that we'd now need 7 or 8 checkboxes to turn on each of the different style options to satisfy people. Anomie⚔ 15:34, 22 May 2012 (UTC)

@Equazcion: Recall that the enabling of this feature was overwhelmingly requested at VPR among people who bothered to comment. What "governance" do you imagine that would avoid the "Oh noes! I can't abide change!" comments from people who didn't bother with the original discussion? Anomie⚔ 15:34, 22 May 2012 (UTC)

It would appear "overwhelmingly" is a subjective term. The response following the change was noticeably more "overwhelming" than the proposal discussion, which got 20 support votes -- some of which included the condition that a preference setting for toggling the feature accompany its implementation, which was ignored. I've outlined above some ideas for "governance". Equazcion 15:47, 22 May 2012 (UTC)

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

Where on history pages do you see this? Equazcion 14:14, 22 May 2012 (UTC)

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

It is ironic:

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

Helder 18:28, 22 May 2012 (UTC)

break 1

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

The whole idea that every user and wiki should be able to opt out of every single change to MediaWiki is why doing any sort of development takes ages. Not only do we have to make sure that our software works in 200+ languages (including right-to-left), but we also have to make sure that it works in all the ancient MediaWiki skins, that it supports all 3 versions of the editing interface (old, older, and oldest), that if the user disables any dependencies or JavaScript it degrades gracefully, and we even have community members demanding that all features work in text-only browsers. Frankly, it's a miracle that any changes to MediaWiki ever actually get deployed. And for the record, we try really hard to get community feedback before changes are deployed (with some notable failures). Most of the development teams do weekly IRC office hours, and spend a huge amount of time responding to bugzilla threads, listserv threads, and on-wiki threads discussing ideas for features. And we devote special attention to English Misplaced Pages in particular: frequently advertising projects on the Signpost and Village pumps. And that's just what we do publicly. We spend inordinate amounts of time discussing community feedback and potential community reaction to features in development meetings, often skyping or IRCing with community members for real-time feedback on ideas. And for all our efforts, we still get chewed out for every single change without fail. I'm not saying the community isn't entitled to griping about the process, but you should realize it's a 2-way street, and both sides should work towards better collaboration. Demanding that all changes be opt-in or that all MediaWiki-related discussions happen on en.wiki isn't realistic or helpful. And calling our work "idiocy" isn't going to make developers take community input more seriously. Kaldari (talk) 19:27, 22 May 2012 (UTC)

I feel your pain and my heart bleeds for you. I'm only being partially sarcastic. Nevertheless, if you think telling people about this here is going to solve the problem, you're being very optimistic. This thread did become the recent developments complaint discussion, though my comment that more or less began it was to address something more fundamental. The issue you and DJ outline is the problem. Evidently, if you're trying really hard to get community feedback, the current system apparently limits your ability to do that, to the point that your changes still don't reflect the community's wishes -- or they hate them because they still didn't know they were coming, but either way it makes no difference. We have a problem, whether or not your intentions and efforts are noble. Maybe we should look for ways to address it. Equazcion 19:40, 22 May 2012 (UTC)

I'm all for that. Right now, there are so many different venues for discussion it's rather unmanagable. I also think one of the big problems is that we have a very hard time getting people to beta test things for us. We usually have working prototypes of new features up on test.wiki or one of the prototype wikis weeks before they are deployed to en.wiki, but it seems no matter where we advertise it, we generally only get significant community feedback after the features are deployed. When I was first hired, I pushed for getting more of our work covered in the Signpost, which I think has had some positive impact, but not a lot. We've also started using "community liasons" for projects, which I also think has had some success. Of course part of the problem is none of these solutions scale well to 800+ projects. I'm interested in more ideas though. Kaldari (talk) 20:04, 22 May 2012 (UTC)

I suggested a Vector Beta skin somewhere above (if it hasn't been archived yet) where changes could be tested by the community simply by switching skins. Advertising of changes could be done via watchlist notices. Feedback could be handled via a newly-created forum here. Equazcion 20:09, 22 May 2012 (UTC)

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

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

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

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

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

MediaWiki deployments to the WMF cluster go through about four generations of testing before they are deployed to enwiki, usually consisting of , , then deployment to , then one or two tranches of other WMF wikis (for 1.20wmf3, all 121 wikibooks wikis), before finally hitting enwiki. I don't think it's a generalisation to say that most enwiki editors missed that entire process, simply because they do not generally have cause to look outside enwiki (and of course there's no reason why they should).

In terms of your first comment, remember that context and ask why enwiki is more deserving of notifications than any of those 124 other sites. Of course it is, and as Ryan says above, substantially more effort is put in to engaging with enwiki than other communities. The WMF sysadmins, and MediaWiki developers, are certainly happy to work to make that engagement more efficient and effective; but enwiki is far from the sole community deserving of their time, and the extent to which many enwiki users think it should be, is stretching many developers' patience. Happy‑melon 20:54, 22 May 2012 (UTC)

I think a single notification page that could be watched would already be a huge step forward. Some way to provide feedback would be needed as well. Nageh (talk) 21:04, 22 May 2012 (UTC)

I think so too, because although such notifications are already made, they are made to VPT and it's clear that that is not being effective at spreading the word to those that want to know. But it is important that whereever such notifications are made, that venue is clearly laid out and well-publicised, which is where the discussion Equazcion exhorts above is needed. A comprehensive discussion amongst the enwiki community about how it wants to best organise its interaction with the MediaWiki community, would certainly have the full support of said MediaWiki community. Happy‑melon 21:09, 22 May 2012 (UTC)

"I think a single notification page that could be watched would already be a huge step forward."

Like -- Toshio Yamaguchi (tlk−ctb) 10:25, 23 May 2012 (UTC)

break 2

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

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

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

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

And how often are the small wiki communities requesting new features for MW? Where do all the ideas for new features come from? From the developers? From editors on the English Misplaced Pages? If the fraction of the latter is significant I think it is just fair to at least have a way to comment on the MW progress. Thank you. Nageh (talk) 20:47, 22 May 2012 (UTC)

Certainly not nearly as vocally, or regularly, as enwiki; and of course the majority of features are positive developments for all wikis. But it was disappointing to see the 1.18 release criticised for being light on frontend changes, when it was merely that the majority of said frontend changes (improved text-directionality and gender support, for instance) were merely targeted at languages other than English.

It is absolutely appropriate for enwiki editors to be involved in the MediaWiki development process, to propose changes and even to oppose them. What needs to change is the attitude in the community when participating in that interaction, which needs to have more of an embassadorial feel and less of the Divine Right of Kings. Happy‑melon 21:04, 22 May 2012 (UTC)

I tend to agree with your last sentence. Let's hope that better ways for intercommunication and a better attitude go hand-in-hand. Nageh (talk) 21:10, 22 May 2012 (UTC)

The first part of your comment is clearly a resource problem (it's impossible to deliver everything everyone wants within a short timeframe with the people we have), not a problem of ideas or input and where they come from. The second part... well you got to comment on the process right ? It's just that your comments weren't picked up in a timely and expedient manner, giving you the feeling that you were not heard.... So that is where any focus of the discussion should be (visibility of the process).

How do developers convince people they are listening and that they are giving priority to issues, without continuously being in debate. And is achieving this goal more important than the actual process of developing the software (Are we gonna allow the pace of the development pace to drop in order to give this visibility) ? The only thing that I can come up with is coupling a much more advanced and usable system than bugzilla (such as the commercial Jira for instance) and significantly integrating it with wiki communities. If the developers can then force themselves to do any actual time accounting and planning in this tooling and that makes the development prices more visible to the community. Such a change would go a long way to making the process more visible. But that is gonna require a huge investment in customizing and switching tooling for the development process and probably still won't work very well for the volunteer developers. —TheDJ (talk • contribs) 21:15, 22 May 2012 (UTC)

Better visibility doesn't necessarily imply a slowed down software development pace. I'm not requesting that all activities are accounted for in detail. A tighter integration of the bug tracking system with Misplaced Pages certainly will help, but even interim solutions such as the extension mentioned above and a rough but up-to-date progress plan pushed to en.wiki will possibly already improve things quite a bit. Nageh (talk) 21:27, 22 May 2012 (UTC)

So basically the "this month in tech" blog post, but then integrated into every WMF wiki and with more detail and planning, with a 'direct feedback' option for a wiki reader (that does not overload the developers) and without overwhelming the reader. Would likely also require separating the volunteer effort from the WMF effort (which is hardly plannable) and making that a WMF decision on when to include certain sets of volunteer work (roadmap that inclusion process separately for WMF). I don't see a way to do that without significantly diverting resources to that plan for at least the next 2 year to enable this, because otherwise we will be having the same conversation again in 3 more months. —TheDJ (talk • contribs) 21:39, 22 May 2012 (UTC)

I cannot see any intent for efforts in this post. What would be so painful to assemble a list of features the developers are planning to implement for their next (major) MW release, with a possibility to comment on these ideas??? I'm at loss. Other than that, it would already be a step forward if editor-requested bugzilla feature requests would be disseminated to the community via above-mentioned extension. Nageh (talk) 22:25, 22 May 2012 (UTC)

Since all major projects take time to develop, it's usually quite easy to track their progress. For example WMF sponsored projects on such a scale are all referenced extensively in the (aforementioned in other people's comments) monthly engineering reports on the WMF blog (if you're not happy with commenting there, there is also a MediaWiki talkpage you can use). If there are non-WMF-sponsored large projects on the go (these are rarer), generally you're reliant on en.planet.wikimedia.org or on posts to the wikitech-l mailing list (though this isn't the case with Wikidata, for example, which gets included in the WMF's monthly reports. For more imminent upcoming deployments, see Software deployments (no way to comment there, admittedly); for more distant upcoming deployments, see Roadmap (which has a talkpage). For small (in coding time) tweaks, you can consult commit logs, or the easiest way is to wait for mw:MediaWiki_1.20/wmf4 to be created, like wmf3 has already been - this usually happens well before deployment to enwiki. There's a talkpage attached wherre you can comment. Finally, if that all sounds like a bit too much, I try to summarise upcoming projects of all sizes in the Signpost'ss weekly Technology Report, and people are quick to comment on articles there with their thoughts, which have a surprisingly high developer response rate. I'm also open to suggestions on how to improve the report. - Jarry1250  22:51, 22 May 2012 (UTC) Apologies if you personally knew some of the above Nageh -- I just wanted to be complete(ish) so people reading this could get a feel for the difference avenues available. - Jarry1250  22:56, 22 May 2012 (UTC)

There's nothing painful about assembling release notes; indeed the developers do it all the time (see mw:MediaWiki 1.20/wmf3, for instance). The question is how to bring that information to enwiki, and the 45,999 other wiki communities, without the very process of notification taking up huge chunks of developers' time. And even whether it's reasonable of enwiki to expect that information to be brought to them, as opposed to 'merely' placed on a neighbouring wiki which shares user accounts and logins with enwiki. Happy‑melon 22:57, 22 May 2012 (UTC)

I think these are some very useful ideas. Clearly we need a higher-profile and more stream-lined venue of communication between the community and developers. In the meantime, if you want to get detailed information on what's coming down the pipe, probably the best place to look is http://www.mediawiki.org/MediaWiki_1.20 and related subpages. Specifically you can see what new changes are in the latest release (for example, http://www.mediawiki.org/MediaWiki_1.20/wmf3#What.27s_new), and when they are going to be deployed to en.wiki (for example, http://www.mediawiki.org/MediaWiki_1.20/Roadmap). These pages are updated every two weeks. Maybe there's some way this could be set up as a feed that gets picked up by other wikis. Kaldari (talk) 23:15, 22 May 2012 (UTC)

Global watchlists would be invaluable for this. Happy‑melon 23:55, 22 May 2012 (UTC)

Take a look at Project Echo --Jorm (WMF) (talk) 01:01, 23 May 2012 (UTC)

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

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

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

As long as we're on the subject, you may want to take a look at what WMF developers are going to be working on for the next year Kaldari (talk) 22:49, 24 May 2012 (UTC)

Template talk:NDB

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

German Misplaced Pages already updated theirs, so I copied their code over here. Let me know if there are any problems, I'm still checking through some transclusions. Equazcion 09:01, 22 May 2012 (UTC)

Some links don't appear to be working this way. I don't know enough about this to fix it (or to tell if the invocations are wrong). Could someone else have a look? {{NDB}}, German version is here: http://de.wikipedia.org/Vorlage:NDB. Equazcion 09:14, 22 May 2012 (UTC)

I reverted and tried just changing the URL prefix but that doesn't seem to be working either. See Andreas Schlüter, Daniel Gabriel Fahrenheit. Equazcion 09:31, 22 May 2012 (UTC)

I also tried it in the sandbox but I could not get it to work, this is why I turned here.--Stone (talk) 12:21, 22 May 2012 (UTC)

Fix a url in a template

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

I've looked at Template talk:NDB and I see no problem. What is wrong with it? --Redrose64 (talk) 09:25, 24 May 2012 (UTC)

I don't know why Stone mentions the unused talk page. The post refers to an issue with Template:NDB, mentioned above in #Template talk:NDB. PrimeHunter (talk) 11:26, 24 May 2012 (UTC)

The problem is not necessarily with Template:NDB (the German template being de:Vorlage:NDB) - it might lie in the subtemplates. There are two which are used to build portions of the URL, these are Template:ADB/MDZ-ID and Template:ADB/Nativeno - the German equivalents are de:Vorlage:NDB/MDZ-ID and de:Vorlage:NDB/Seite. Even if we ignore the fact that the string 0001/bsb000 is in the main template at en.wp but a subtemplate at de.wp, we see that the numbers generated by the subtemplates are very different. --Redrose64 (talk) 14:07, 24 May 2012 (UTC)

Possible red herring, but I notice that the German template de:Vorlage:NDB uses subtemplates de:Vorlage:NDB/MDZ-ID and de:Vorlage:NDB/Seite, whereas the English template Template:NDB uses subtemplates Template:ADB/MDZ-ID and Template:ADB/Nativeno even though Template:NDB/MDZ-ID and Template:NDB/Nativeno exist. DH85868993 (talk) 16:36, 24 May 2012 (UTC)

I think I got it now. I copied the German code again, but only copied the code within the link this time. For some reason this seems to have worked -- and on checking the resulting diff, Redrose and DH's observation seems to have been the issue. Post back if there are still problems. Equazcion 17:02, 24 May 2012 (UTC)

Massive vertical break in Signpost News and notes display mode

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

Thanks Tony. I'm running IE 7.0 (though I wish I wasn't) if that's any help. --Dweller (talk) 14:48, 22 May 2012 (UTC)

Big gaps before files or section breaks are something I've often noticed when using IE7 recently - I don't remember it from a couple of years back, so it may be due to a recent change, but it's certainly not just you! No idea for a solution, sadly... Andrew Gray (talk) 22:21, 22 May 2012 (UTC)

Database lag

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

Someone had been pegging our API servers with requests, causing a replication lag on db12 (contributions). The offender has been blocked now, replag seems to be dropping. Max Semenik (talk) 15:59, 22 May 2012 (UTC)

I see it is indeed dropping now. Thanks for the quick info :) Equazcion 16:03, 22 May 2012 (UTC)

Ummm, didn't stay dropping for long, continuing to poke up: , 12806s. --joe decker 05:28, 23 May 2012 (UTC)

• Now 309 seconds and rising... - The Bushranger _{One ping only} 21:37, 23 May 2012 (UTC)

• The problem seems to be continuing, and not getting any better, at least for me. It's really difficult to pull up my watchlist or any edit histories. --Tryptofish (talk) 21:45, 23 May 2012 (UTC)
  • and now it seems clear... - The Bushranger _{One ping only} 21:48, 23 May 2012 (UTC)
    • My theory is that we fixed it, by making our comments here. Works like magic, every time! --Tryptofish (talk) 22:36, 23 May 2012 (UTC)

According to #wikimedia-tech, it was apparently the same server today that was causing the problem yesterday. It's an older machine that just isn't up to serving en.wp, so it has been removed from duty until it is replaced in a few weeks. ​—DoRD (talk)​ 22:47, 23 May 2012 (UTC)

Thanks. It's much better now. --Tryptofish (talk) 23:08, 23 May 2012 (UTC)

Yep, it's hell getting old...even for computers, I suppose ;) ​—DoRD (talk)​ 13:07, 24 May 2012 (UTC)

Template:Playmate: rework or delete?

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

Talk pages messed up for IE 7

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

Why haven't you tried another browser then, instead of leaving us to guess what your problem is? --Aspro (talk) 20:50, 22 May 2012 (UTC)

I'm at work, where we are limited to only IE 7. — Loadmaster (talk) 15:58, 23 May 2012 (UTC)

I gave IE7 a quick spin; can't reproduce. Any specific pages you're seeing this on? Does it happen when you're logged out? Any errors reported by the browser? Any other odd behavior on other sites? Any suspicious-looking purple gorillas nearby?--Eloquence* 21:30, 22 May 2012 (UTC)

The problems seem to be gone now, so I'll guess that it was my browser and/or configuration. None of the article pages was affected, and only about half of the Talk pages seemed to be affected. The primary effects were: 1) the first box below the title line appeared to overlay text underneath; 2) the entire page contents did not load, stoppping somewhere at 50%–80% of the page; 3) only the section titles, tables, and images were visible, while none of the normal text was; 4) in the editing pages, most things were visible but some things like the symbol selection div were not. Like I said, the problem appears to be gone now (another day, another reboot), I suspect a local caching problem here on my company's side, but perhaps my experience can be useful to others in the future(?). — Loadmaster (talk) 15:58, 23 May 2012 (UTC)

Wikilinking to a subsection?

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

As long as the subsection name's is unique, you can append the section name after a "#" symbol in the name. For example, this section, I can wikilink as ] Alternatively, or if the title's not unique, you can use the template {{anchor}} right after the section header, which you can assign any name, and then link to that anchor name instead. So for example if you put {{anchor|this spot}} in the section you want to link to, you can then link to it via ]. --MASEM (t) 19:23, 22 May 2012 (UTC)

And just adding that this is irregardless of how deep the header is; it is based on the textual content not the level of outline. --MASEM (t) 19:24, 22 May 2012 (UTC)

Thank you, the 'anchor' was exactly what I was looking for. :) Buddy23Lee (talk) 19:35, 22 May 2012 (UTC)

I think these days you have to encode punctuation, that test link of yours doesn't seem to work in my browser. - Jarry1250  21:03, 22 May 2012 (UTC)

Reviewing link bug

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

Turning Sharebox into a gadget

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

Headers

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

If you have Misplaced Pages:refToolbar 2.0 with a right pointing triangle at "Advanced" then click Advanced to see Heading and other options. PrimeHunter (talk) 03:44, 23 May 2012 (UTC)

THanks, that's what I was looking for. --Ohconfucius 04:46, 23 May 2012 (UTC)

Make it possible to show different content to different users

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

I don't know if it's easy to detect if the current user is an admin, but conditionals exist in MediaWiki, we make a fair use of this set of conditions, for example. --joe decker 18:25, 23 May 2012 (UTC)

Do you mean the class="sysop-show" from MediaWiki:Group-sysop.css and MediaWiki:Common.css? Helder 19:17, 23 May 2012 (UTC)

Fixing redirected pages

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

You should probably consider whether the changes you want to make are in accord with WP:NOTBROKEN, first. Happy‑melon 19:43, 23 May 2012 (UTC)

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

Template:Split media

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

Not sure exactly what you mean, but I think you might be looking for {{Orphaned non-free revisions}}. →Στc. 00:33, 24 May 2012 (UTC)

That's exactly it. I wouldn't have expected it would serve that function based on the name. Thank you. ▫ JohnnyMrNinja 01:39, 24 May 2012 (UTC)

Watchlist gremlins

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

At the top of my watchlist, I have "Hide minor edits | Show bots | Hide anonymous users | Hide logged-in users | Hide my edits | Hide patrolled edits". What do you have there? - Jarry1250  23:10, 23 May 2012 (UTC)

Hide minor edits | Show bots | Hide anonymous users | Hide logged-in users | Hide my edits | Hide patrolled edits --Bbb23 (talk) 23:19, 23 May 2012 (UTC)

Your question raised a question for me. I have Show bots above. That means it hides any edits by bots. Does that also mean that if the last edit was by a bot, it won't show the edit just before the bot edit, i.e., it shows nothing?--Bbb23 (talk) 23:25, 23 May 2012 (UTC)

Exactly. That's why I posted this to your original question at Misplaced Pages:Help desk#Watchlist: "Make sure you are not hiding some entries at Special:Preferences#mw-prefsection-watchlist". It appears you ignored that and instead came here claiming you didn't get help at the help desk. PrimeHunter (talk) 00:03, 24 May 2012 (UTC)

My apologies. I didn't "ignore" it, though, I failed to look before I came here and mistakenly thought the last edit to the topic was the one before yours. Still, my fault for not checking. That explains it perfectly because I recently changed that setting. I don't suppose there's a way to hide bot edits but still see the latest non-bot edit? And to expand on my apology at the risk of sounding fawning, I almost always get the help I need at the help desk. It is hands down my favorite place on Misplaced Pages.--Bbb23 (talk) 00:09, 24 May 2012 (UTC)

Sorry if I sounded harsh. I don't think you can hide some types of edits and still see the latest edit not of those types. bugzilla:9790 is about it. Hiding works better if you choose "Expand watchlist to show all changes, not just the most recent" at Special:Preferences#mw-prefsection-watchlist. See Help:Watching pages#Options. PrimeHunter (talk) 00:31, 24 May 2012 (UTC)

Yes you can. There is a kickass script that does this - and more - courtesy of User:Uncle Douggie. WP:HIDEBOTS for details. Rich Farmbrough, 15:55, 24 May 2012 (UTC).

Pipe separator problems

Please see Template_talk:User#Pipe_separators and Template_talk:Toolbar#Symmetry_and_beauty. There is a problem for some editors (not all, though) viewing templates with pipe separators such that they appear with missing spacing – "talk| contribs" rather than "talk | contribs". Could someone please have a look? Thanks. It Is Me Here 22:48, 23 May 2012 (UTC)

Do you have your language preference set to en-gb (or something else) instead of en? I note that MediaWiki:pipe-separator has been fixed to not screw up when used in parser functions, while MediaWiki:pipe-separator/en-gb does not have any such fix. Anomie⚔ 04:03, 24 May 2012 (UTC)

Yes, I have en-gb. It Is Me Here 09:52, 24 May 2012 (UTC)

Help:Preferences says (I wrote it): It is not recommended to select "en-GB - British English" or "en-CA - Canadian English" at the language option in preferences. Many interface messages have been customized at the English Misplaced Pages but only for the default selection "en - English". The language option only affects interface messages and not article text. PrimeHunter (talk) 11:17, 24 May 2012 (UTC)

Actually, this applies to all language options— Misplaced Pages:Database reports/User preferences shows the top language setting is es. I have a bit more on this at User:Gadget850/FAQ/Language. I made a proposal some time back about the possibility of redirecting messages where the default version has been modified, but there was no participation. ---— Gadget850 (Ed)  11:29, 24 May 2012 (UTC)

The problem applies to all languages but if a user chooses a foreign language then the advantage of knowing the language better is often larger than the disadvantage of losing customized messages. Therefore I only disrecommended English variants. See Help talk:Preferences#What about Canadian English? PrimeHunter (talk) 12:01, 24 May 2012 (UTC)

This should now be fixed - MediaWiki:Pipe-separator/en-gb has been created as a clone of MediaWiki:Pipe-separator. --Redrose64 (talk) 15:03, 24 May 2012 (UTC)

Fixed in en-gb and en-ca but not any foreign language. It seems impractical to create hundreds of identical language pages at Special:PrefixIndex/MediaWiki:Pipe-separator. It would be nice if MediaWiki gave an option for MediaWiki:Pipe-separator to say "Use this for any language without a customized message". PrimeHunter (talk) 19:14, 24 May 2012 (UTC)

Black background on Misplaced Pages?

Is it possible to view Misplaced Pages with a black (or dark) background? Axl ¤ 23:03, 23 May 2012 (UTC)

Yes, although the green-on-black gadget hasn't yet been updated to work with Vector properly, so you either have to switch to Monobook or put up with the logo in the wrong place. - Jarry1250  23:09, 23 May 2012 (UTC)

How do I view it like that? I am a relative novice in this area. Axl ¤ 23:24, 23 May 2012 (UTC)

Ah, I figured it out, thanks. It's pretty garish! Axl ¤ 23:30, 23 May 2012 (UTC)

Very much so. I mean, you can also try and "build your own", but it's a bit more complicated, especially if it takes you a while to work out what actually looks best. - Jarry1250  13:14, 24 May 2012 (UTC)

I am now using the green-on-black format. I find that some users' signatures are not visible. Here are some examples:-

mabdul

Leaky

I presume that this is because the users have specified black as the text colour. Can this be adjusted for my viewing? Axl ¤ 09:20, 26 May 2012 (UTC)

You should inform each of these users that their signature fails Misplaced Pages:Signatures#Appearance and color and WP:CONTRAST, because by explicitly setting a text colour without also setting a background colour, they have made incorrect assumptions about the background colour. If you examine my own signature, you'll see that those portions which explicitly set a text colour also set a background colour - the markup is <span style="color:#a80000; background:#ffeeee; text-decoration:inherit">Red</span>, which this contrast calculator shows as having a contrast of 7:1, and this one shows 7.02:1 - either way, it's WCAG 2 AAA Compliant. --Redrose64 (talk) 12:41, 26 May 2012 (UTC)

TOC

Suddenly ToC is collapsed by default on articles - at least for me. What's happening? Rich Farmbrough, 01:25, 24 May 2012 (UTC).

It should remember the last state. If you expand one then are the following still collapsed? It works for me. PrimeHunter (talk) 02:14, 24 May 2012 (UTC)

Thanks, yes it does - maybe collapsed is the default? Is this another "bugfix"? Pages are crafted to work with their ToC... Rich Farmbrough, 14:36, 24 May 2012 (UTC).

I'm not sure what you say yes to. If you still have problems then try clearing your entire cache. For as long as I know, it has worked so if you collapse one TOC then all following TOC's are collapsed in that browser until you expand one, and then they are all expanded until you collapse one. That is sensible to me and it also works for unregistered users who cannot set preferences. Maybe you accidentally hit a hide link in a TOC. PrimeHunter (talk) 17:44, 24 May 2012 (UTC)

files in[REDACTED] and commons with same name

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

No, there isn't: the same syntax is used whether the image is on the local[REDACTED] or on commons - the MediaWiki parser looks locally first, and then on commons.

Generally, where there is a filename clash, it's best to rename the local image, not the one on commons, because there is likely to be much less work involved. --Redrose64 (talk) 09:21, 24 May 2012 (UTC)

Thanks for the info. I'll take your advice next time. --Bachrach44 (talk) 10:01, 24 May 2012 (UTC)

Image and Cache Issue

Hi,

I was directed here from Misplaced Pages's Cache page; I have recently uploaded a new version of this file. This new version is currently active on this article. However, there appears to be a caching issue. The image is not being presented correctly on Wikis such as this one. I have tried purging and, to a certain extent, that has worked. However, if I want to add this image to an article and I press the 'preview' button, the image is shown to be out-of-date and warped. Is there a way to fix this? Is it only a matter of time until the image will be shown properly? Thanks for the help. Poppersocks (talk) 20:58, 24 May 2012 (UTC)

What WMF developers are going to be working on for the next year

In the interests of keeping the community more in the loop, here is a draft of the WMF engineering goals for the next fiscal year:

• http://www.mediawiki.org/Wikimedia_Engineering/2012-13_Goals

And here are the projects that the Features Engineering Team is working on specifically:

• http://www.mediawiki.org/Wikimedia_Features_engineering

Feedback regarding any of these projects is welcome on the talk pages of the specific projects on mediawiki.org. Kaldari (talk) 22:45, 24 May 2012 (UTC)

Thank you! I see a some amazingly cool stuff there. --joe decker 20:49, 25 May 2012 (UTC)

Proxy error

I am getting these messages frequently:

The proxy server received an invalid response from an upstream server.
The proxy server could not handle the request POST /wikipedia/en/search/.

Reason: Error reading from remote server

Apache/2.2.14 (Ubuntu) Server at secure.wikimedia.org Port 443

I am assuming this is because some server is overloaded. I use the secure login—does that affect which servers are used? Can I do anything other than keep re-sending edited pages? Would I be better off using the non-secure login? --Greenmaven (talk) 01:46, 25 May 2012 (UTC)

Are you using https://en.wikipedia.org/ or https://secure.wikimedia.org/wikipedia/en/? If the latter, try changing to the former. Anomie⚔ 02:29, 25 May 2012 (UTC)

I will try the former, as I am using the latter. But I would appreciate getting a tech answer to my initial questions. Tks --Greenmaven (talk) 07:50, 25 May 2012 (UTC)

secure.wikimedia.org is deprecated. See Misplaced Pages:Secure server. PrimeHunter (talk) 12:56, 25 May 2012 (UTC)

Category sortkey problem

This problem is stumping me, and I have to leave for the airport in 50 minutes so I don't have much time to work on it. Why does Category:1949 operas sort under the wrong place in Category:1949 works? It should be under "Operas" but it's the first entry in the list. Graham87 02:13, 25 May 2012 (UTC)

Well, it was sorting as the first entry in the list because Template:Year by category had an extra space when it was constructing the category link. But fixing that makes it be under "1" instead of "o" in the category, so something in Template:OperasByYear still isn't quite right. Perhaps it should be redone along the lines of one of the templates for the other categories. Anomie⚔ 02:27, 25 May 2012 (UTC)

Fixed in after reading the documentation of {{Year by category}}. PrimeHunter (talk) 11:00, 25 May 2012 (UTC)

Nifty! Anomie⚔ 11:34, 25 May 2012 (UTC)

Indeed! Thanks, guys. Graham87 01:19, 26 May 2012 (UTC)

A prime example of why content categories should not be in templates. Rich Farmbrough, 12:18, 26 May 2012 (UTC).

Access to Article Feedback Tool Data

Hi, I am interested to know whether it is possible to get access to Article Rating Data. I have found data on the earlier version, which covers the period of 2011march-september, but I would like to use the latest data. In case that is not public yet, is there any chance it also will be accessible in the future; and if so when approximately? Thank you in advance! — Preceding unsigned comment added by MkkLR (talk • contribs) 19:20, 25 May 2012 (UTC)

Historical data dumps collected via previous AFT versions as well as weekly data dumps from the current AFT version are available for download, but only for English Misplaced Pages. All dumps are available as compressed CSV files and are released under a CC-BY-SA license. Real-time anonymized AFT data is also available via the toolserver. Version 5 of the Article Feedback Tool is now under development by the Wikimedia Foundation. This will be a huge improvement compared to older versions of the AFT because WP:AFT5 will actually be useful. Arcandam (talk) 12:58, 26 May 2012 (UTC) p.s. If you have any questions about the AFT its probably best to ask people like User:Okeyes (WMF) or User:Jorm (WMF).

replacing references temporarily

Using Perl, I've slurped an article.

I need to match the first sentence of the article, but intervening references with a period in them create an ambiguity so the script does not find the period at end of the sentence (it finds the period in the embedded reference instead).

So, I'd like to be able to save references off and put them back again into the first sentence after I've extracted and processed it.

How can this be done? The Transhumanist 21:41, 25 May 2012 (UTC)

Assuming you have the entire article in a scalar, I'd use a regex something like this (you'll need to add in other weird reference type coding, but you get the idea): if ($article =~ m$^(.+?)(<ref>.+</ref>)?(.*?)?\.$){$first_sentence = "$1" . "$3"}. In case you don't know, the ? following + makes it non-greedy, which is probably important for what you're trying to do. Shadowjams (talk) 23:06, 25 May 2012 (UTC)

That won't work if there's more than one <ref> element in the document and the first sentence ends between them. Something like this should work: m$^(<ref>.*?</ref>|.)*?\.$ (the sentence ends up in $&). You need to replace the <ref> part with something that will actually match all ref open tags (perhaps just <ref would work) and you will have to deal with empty tags as well. And I'm sure there are other bugs. I wish MediaWiki syntax wasn't such a mess. -- BenRG (talk) 23:44, 25 May 2012 (UTC)

Did you test that? I don't think it will catch the refs at all, because it should treat the entire OR as a single token... I'll test it in a minute. Shadowjams (talk) 00:22, 26 May 2012 (UTC)

Ok that works. I learned something new (could you tell me where I went wrong? I'm surprised the () group allows alternate versions like that). As an aside, you're gonna have practical problems with this script with things like infoboxes, and other templates, the IPA template, for example, has lots of periods in it that will cause you problems. You might do something like ensure a space after the period, which would cut down on some of these. Shadowjams (talk) 00:27, 26 May 2012 (UTC)

In your code, the initial .+? means that <ref> will match the first occurrence in the file, but the following .+ means that </ref> will match the last occurrence, which may be too late. If that .+ is replaced with .+?, it will match the first occurrence of </ref>, but in that case it will fail if there's a second <ref>...</ref> in the first sentence which has a period in it.

| is an infix operator that has lower precedence than concatenation (which is the only other infix operator, I think), and you can override that with any kind of parentheses. In older regular expression syntaxes parentheses were only used for grouping (as in mathematical expressions), but Perl uses them for capturing groups and has the ugly (?:...) syntax for pure grouping parentheses. I should have used (?:...), but I wanted the expression to be slightly more readable.

Since Perl tries the leftmost alternative first, it will match <ref>.*?</ref> (a single reference) if it can. Otherwise it will advance by one character (matching .) and try again. Actually, this is buggy: if there's no period in the whole article outside of <ref>...</ref> pairs, it will backtrack and find a period inside a ref, which is probably not what you want. To fix that you would need to control backtracking somehow. I think that m$^(<ref>.*?</ref>(*PRUNE)|.)*?\.$ will work, but I've never actually used (*PRUNE) before. This expression still has a lot of problems, and Misplaced Pages being what it is I bet there are a lot of pages that will trigger those problems. -- BenRG (talk) 06:09, 26 May 2012 (UTC)

Using ?: has two main advantages, reducing processing time and readability. The first (as I understand it - later versions of perl may be smarter) only applies if it is used for all groups, and is negligible in most cases, the second is somewhat subjective. I tend to use it where branching selections would give different numbers, this is relatively rare and I have not looked for better solutions. Rich Farmbrough, 12:53, 26 May 2012 (UTC).

The big extra thing these regexes need to match is something like <ref*/> for named refs - and indeed the valid but meaningless &ltref />.Rich Farmbrough, 13:02, 26 May 2012 (UTC).

Further to the extra comments you made on my talk page about replacing the refs temporarily with XXXXX:

This process is called "strip marking" and is used by a number of processes including the MediaWiki software, AWB and the perl code for Helpful Pixie Bot and Pixie. There are several issues to account for:

1. Assumptions. Depending on what you can assume you can make the process more or less simple. The following items can be ignored if simplifying assumptions can be made.
2. No mis-matches. Sufficiently bad mis-matches means you have to throw the idea away (at least partly), and find another strategy. Sufficiently bad means:

   p(mis-match)* damage > threshold

3. Nesting - code should deal with arbitrary levels of nesting if needed
4. Removal - if the stuff surrounding thing you are stripping is removed, should it stay?
5. Matching the strip marker. This has tripped me up using AWB (and indeed the coder's response to the bug I logged is how I know AWB uses strip markers).
6. Conversely no aliases for strip markers. "Strip marker" would be a bad strip marker (in general), as would anything you might find on a WP page. I might suggest for generality using a bunch of Unicode characters form obscure planes (or even illegal Unicode characters if perl will let you get away with them - these should provide extra belt-and-braces if you check for legality before you write the page). But for this case even your "XXXXX" might well suffice.
7. Replacement - if you can be sure the whole thing is simple you can push the items onto a stack (array) and pop them back afterwards. This is effectively an atomicity argument - and the way Pixie does it (though recursively in some cases - which is rather elegant in its way). If, however, you might re-arrange paragraphs you need to use something smarter - a hash for example. Strip-mark with a unique strip mark for each item (remembering how this affects the above point) and replace by iterating through the hash or strip markers - removing the items from the has h as you go. If the hash deos not end up empty, flag an exception.

Rich Farmbrough, 12:53, 26 May 2012 (UTC).

Try User:PleaseStand/References segregator. ---— Gadget850 (Ed)  13:25, 26 May 2012 (UTC)

Issue with College Baseball Template - But Only Once

In the 2012 Big 12 Baseball Tournament article, the {{cbsb link}} template is used frequently. It works for the most part, but for some reason displays "Missouri Tigers baseball" in the first round of the "Bracket" section. It works fine in the standings. Manually changing and unchanging the display field failed to resolve the problem. Smartyllama (talk) 21:55, 25 May 2012 (UTC)

Fixed by removing a wrong capitalization. PrimeHunter (talk) 23:10, 25 May 2012 (UTC)

Rollback now displays "(warn using TW)" when complete

After completing a rollback, the diff page used to say:

Reverted edits by Username (talk | contribs | block) to last revision by Bongwarrior (talk | contribs | block).

But today it says:

Reverted edits by Username (talk (warn using TW) | contribs | block) to last revision by Bongwarrior (talk | contribs | block).

What is the "(warn using TW)" addition all about? I haven't noticed any extra functionality, and it looks kind of ugly and unnecessary to me. I'm not sure if it was a Twinkle change, a MediaWiki namespace change, or something related to the MediaWiki 1.20wmf3 deployment, but I felt that, for the good of the project, it was important to make my displeasure known. --Bongwarrior (talk) 04:01, 26 May 2012 (UTC)

It was a Twinkle change. Prior to this, the link to the talk page was bold. →Στc. 05:58, 26 May 2012 (UTC)

Special:ApiSandbox does more than a sandbox should

I made this edit when playing with the action=edit. Does anyone know how one reports this sort of issue? →Στc. 06:14, 26 May 2012 (UTC)

I'm not clear what the issue is. But the answer is probably Bugzilla. Rich Farmbrough, 12:27, 26 May 2012 (UTC).

Is there any technical reasons to keep Category:Hidden Categories a hidden category?

I don't think Category:Hidden categories should be hidden... and now it contains itself... Ibicdlcod (talk) 07:23, 26 May 2012 (UTC)

No there is no reason for this. Rich Farmbrough, 12:09, 26 May 2012 (UTC).

 Fixed Rich Farmbrough, 12:17, 26 May 2012 (UTC).

Featurerequest for Reflinks

I have a featurerequest for an expert programmer; WP:REFLINKS sometimes mistakes the text in the commentbox as the name of the author which results in this kind of stuff. "Meld je aan of registreer je om een reactie te plaatsen!" is Dutch and means "Login or register to comment".. It may be possible to get it to fetch the author's name correctly but if not the easiest hack would be to simply disallow a couple of strings. Unfortunately User:Dispenser does not communicate anymore. Arcandam (talk) 13:29, 26 May 2012 (UTC)