Wikipedia:Village pump (technical)

The technical section of the village pump is used to discuss technical issues about Wikipedia. Bugs and feature requests should be made at Bugzilla (How to report a bug). Bugs with security implications should be reported to security

wikimedia.org or filed under the "Security" product in Bugzilla.

Newcomers to the technical village pump are encouraged to read these guidelines prior to posting here. Questions about MediaWiki in general should be posted at the MediaWiki support desk.

view · edit

Frequently asked questions (see also: Wikipedia:Technical FAQ)

Click "[show]" next to each point to see more details.

If something looks wrong, purge the server's cache, then bypass your browser's cache.
This tends to solve most issues, including improper display of images, user-preferences not loading, and old versions of pages being shown.

No, we will not use JavaScript to set focus on the search box.
This would interfere with usability, accessibility, keyboard navigation and standard forms. See task 3864. There is an `accesskey` property on it (default to `accesskey="f"` in English). Logged-in users can enable the "Focus the cursor in the search bar on loading the Main Page" gadget in their preferences.

No, we will not add a spell-checker, or spell-checking bot.
You can use a web browser such as Firefox, which has a spell checker.

If you have problems making your fancy signature work, check Help:How to fix your signature.

If you changed to another skin and cannot change back, use this link.
Alternatively, you can press Tab until the "Save" button is highlighted, and press Enter. Using Mozilla Firefox also seems to solve the problem.

If an image thumbnail is not showing, try purging its image description page.
If the image is from Wikimedia Commons, you might have to purge there too. If it doesn't work, try again before doing anything else. Some ad blockers, proxies, or firewalls block URLs containing /ad/ or ending in common executable suffixes. This can cause some images or articles to not appear.

For server or network status, please see Wikimedia Status. If you cannot reach Wikipedia services, see Reporting a connectivity issue.

« Archives, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214

Green highlighting of changes since last visit doesn't work anymore

In revision history listings of pages on my watchlist, the highlighting of edits since I last visited the page doesn't work anymore (using Monobook). Thanks for any help... AnonMoos (talk) 19:50, 25 May 2013 (UTC)[reply]

Today, I'm having a similar problem in Vector. For me also, the green highlighting in edit histories is gone, and I would very much like to have a way to get it back. Instead, what I see now is a small bullet point at the beginning of each entry, and the point changes from green (new) to blue (previously visited), with these dots also on my watchlist. For me, it's fairly difficult to see the difference in color of the small dot. --Tryptofish (talk) 20:21, 25 May 2013 (UTC)[reply]

Thanks for mentioning the green dots (I could have gone a looong time without figuring that out for myself). I need to put my face up close to the screen and squint to make use of them, so I agree there definitely needs to be a change... AnonMoos (talk) 21:07, 25 May 2013 (UTC)[reply]

I noticed it 21⁄2 hours ago; I was wondering how long it would take people to complain. This is the edit; there is a link in the edit summary to the relevant discussion. --Redrose64 (talk) 21:11, 25 May 2013 (UTC)[reply]

(edit conflict) Yes, they are indeed difficult to see (in terms of color). I don't mind, however, if the change remains in place, just so long as there is an opt-in workaround for those of us who would like to put something in our preferences that restores the green-font "changed since your last visit" notice on the edit history pages. --Tryptofish (talk) 21:14, 25 May 2013 (UTC)[reply]

(edit conflict) (edit conflict) (edit conflict) it's because of this edit. i did not see it discussed anywhere, and i think it should be reverted, or at least discussed. for now (i.e., until it's reverted), you can undo it for yourself by adding to Special:MyPage/common.css the following line:

span.updatedmarker { display: inline; }

i do not think it's an acceptable solution, though. i think this edit should just be reverted. IMO it is borderline sabotage (although i'm sure this was not the intention). peace - קיפודנחש (aka kipod) (talk) 21:16, 25 May 2013 (UTC)[reply]

(edit conflict)(sorry about all the ecs) Per Redrose's link, there was "discussion" here: WP:Village pump (proposals)#"Updated since last visit" markers, where I'm about to make a cross-notice. --Tryptofish (talk) 21:19, 25 May 2013 (UTC)[reply]

yes, i had so much trouble saving my edit that i did not read carefully the previous addition to the section. i now read the discussion, and i could not find anywhere in the proposal a mention of "oh, and by the way, i am going to hide the updatemarker". all i saw was a discussion of blue vs. green dots, to which i am pretty agnostic. peace - קיפודנחש (aka kipod) (talk) 21:22, 25 May 2013 (UTC)[reply]

to clarify: the actual edit did some things which were not at all discussed in the proposal. only those things (i.e., hiding the green "changed since your last") should be reverted, not necessarily the whole edit. peace - קיפודנחש (aka kipod) (talk) 21:26, 25 May 2013 (UTC)[reply]

Gazillions of ECsTo restore it like it was, add the following to Special:Mypage/common.css:

span.updatedmarker {
    display: inline;
    font-style: italic; /* if desired */
    background-color: transparent; /* this makes the text colored (not highlighted); use if desired */
    color: #006400; /* green, not black */
}

But I agree that User:Edokter didn't really have consensus, and (like with the orange bar and Notifications) it wasn't clear that this new feature would remove the old one. I thought it would only change the color of the dots. Ignatzmice•talk 21:30, 25 May 2013 (UTC)[reply]

Thanks, both of you, very much! For me, the second of these fixes (the one from Ignatzmice) is the one that most exactly restores what I wanted back. ~~Also, if one uses Vector, I think it's the "vector.css" file, rather than "common.css" that needs to be edited.~~ --Tryptofish (talk) 21:37, 25 May 2013 (UTC)[reply]

Thanks, I always like trying to figure out these kinds of things! Common.css changes it for all of your skins; the specific ones change it only for that specific one. So long as you only use one skin, it's six of one, half-dozen of the other. Ignatzmice•talk 21:40, 25 May 2013 (UTC)[reply]

Woops, thanks. I changed both (12?). Anyway, I'm happy again. I'll also point out for future readers here that your instructions include "optional" parts, and I included those to get the same font color and format as before. --Tryptofish (talk) 21:44, 25 May 2013 (UTC)[reply]

(edit conflict) regarding the style, you are correct that "my" snippet does not restore it exactly to the way it was, while Ignatz's snippet does. "mine" actually restores it to the way i see it on other wikis, which i prefer personally. but this is really splitting hair - the main thing is to restore the message itself. as to vector.css vs. common.css: since the sabotage was done on Mediawiki:Common.css, i think it makes more sense to override it in the personal common.css. peace - קיפודנחש (aka kipod) (talk) 21:48, 25 May 2013 (UTC)[reply]

Reset code

Ok, for the non techies like me, what's the code to remove the dots (of any colour), please? NtheP (talk) 22:46, 25 May 2013 (UTC)[reply]

/* Hide reset button */
#mw-watchlist-resetbutton {
    display: none;
}
/* Restore default bullets */
.skin-cologneblue li.mw-changeslist-line-watched,
.skin-cologneblue li.mw-history-line-updated {
    list-style-type: disc;
}
.skin-monobook li.mw-changeslist-line-watched,
.skin-monobook li.mw-history-line-updated,
.skin-modern li.mw-changeslist-line-watched,
.skin-modern li.mw-history-line-updated {
    list-style-image: url(/w/skins/monobook/bullet.gif);
}
.skin-vector li.mw-changeslist-line-watched,
.skin-vector li.mw-history-line-updated {
    list-style-image: url(/w/skins/vector/images/bullet-icon.png);
}

— Edokter (talk) — 22:59, 25 May 2013 (UTC)[reply]

NtheP seemed to be asking how to remove any dots. I would imagine that could be achieved with list-style-image: none;, but that's not working for me.... Ignatzmice•talk 23:05, 25 May 2013 (UTC)[reply]
- That would restore the default HTML bullets. I do think he asked how to restore the original bullets. — Edokter (talk) — 23:11, 25 May 2013 (UTC)[reply]

(edit conflict) (edit conflict) ~~(trying to answer the question: how to remove the dots in history. not sure if it's the same as Ignatz's answer, but if so, i guess it won't work...)~~

try

ul#pagehistory { list-style: none; }

this comes with zero guarantee... : ( peace - קיפודנחש (aka kipod) (talk) 23:08, 25 May 2013 (UTC)[reply]

I'm trying to make the newly appeared neon green dots on the watchlist go away and have tried several pieces of code above but none seems to work. Which script to use to make them disappear on the watchlist only? Victoria (talk) 23:15, 25 May 2013 (UTC)[reply]
- You put the entire code in your User:Victoriaearle/common.css. — Edokter (talk) — 23:19, 25 May 2013 (UTC)[reply]
  - Got it thanks. Victoria (talk) 23:34, 25 May 2013 (UTC)[reply]

Yes thanks for that code to remove those stupid green dots. Lugnuts ^{Dick Laurent is dead} 09:16, 26 May 2013 (UTC)[reply]

Getting rid of any dots would be great but it's enough for me to be able to reset them to black and unchanging. Edoktor, thanks for posting the code. NtheP (talk) 09:23, 26 May 2013 (UTC)[reply]

Edokter, why did you change none; to none none; here? I would have thought that it had no effect. Is this some new syntax for CSS 3, rather like !important? --Redrose64 (talk) 10:42, 26 May 2013 (UTC)[reply]

list-style is a shorthand for list-style-type, list-style-image and list-style-position. In order to disable the bullet completely, the first two need to be set to none. Because there are two properties that accept none as a value, you need to specify it twice in the shorthand notation for both properties to be set. — Edokter (talk) — 11:09, 26 May 2013 (UTC)[reply]

I agree that list-style is a shorthand for the other three, it's in the CSS 2.1 documentation; but that documentation says nothing about the first value applying to the type, the second to the image and the third to the position. The general principle with CSS properties that accept multiple values is that the order that they are specified is unimportant.

That doc page states "A value of 'none' within the 'list-style' property sets whichever of 'list-style-type' and 'list-style-image' are not otherwise specified to 'none'. However, if both are otherwise specified, the declaration is in error (and thus ignored)." very near the bottom of the doc, and then explicitly states "a value of 'none' for the 'list-style' property sets both 'list-style-type' and 'list-style-image' to 'none'", with an example of such use. --Redrose64 (talk) 15:19, 26 May 2013 (UTC)[reply]

Is that the correct version, and is it still current? I've seen this fail in both Chrome and Firefox if only one none is specified. I also think that otherwise means being set to anythinng else the "none". — Edokter (talk) — 15:30, 26 May 2013 (UTC)[reply]

I can't seem to reproduce the bug though; one "none" seems to work (but two isn't an error). — Edokter (talk) — 15:38, 26 May 2013 (UTC)[reply]

It's the latest recommended version. At the W3C All Standards and Drafts list, there is a link Cascading Style Sheets (CSS) Snapshot 2010, which does yield a list of properties, but in there the entry for list-style points straight to the doc that I linked at 15:19, 26 May 2013.

There is CSS Lists and Counters Module Level 3, dated 24 May 2011, but that's described as a "Working Draft", so it's not final. It does give a better explanation of the none value. --Redrose64 (talk) 18:54, 26 May 2013 (UTC)[reply]

Last time I checked, the need for "none none" was because of an IE bug. Anomie ⚔ 00:09, 29 May 2013 (UTC)[reply]

On a related note, is there some code that would get rid of the green highlighted "updated since my last visit" that appears in the history?--十八 10:53, 26 May 2013 (UTC)[reply]

.updatedmarker { display: none; }

— Edokter (talk) — 11:09, 26 May 2013 (UTC)[reply]

Thanks.--十八 20:52, 26 May 2013 (UTC)[reply]

Green bullets - accessibility

Instead of two different-color bullets, it ought to be a bullet vs. no bullet. It'd be much easier to make out the difference. —Designate (talk) 14:33, 26 May 2013 (UTC)[reply]

Can't see any bullets at all!

I'm stealing the thread here, but I can't see any bullets at all. I'm using Firefox 21.0 for Ubuntu Canonical 1.0. --Fama Clamosa (talk) 16:36, 27 May 2013 (UTC)[reply]

I also don't see any bullets but I'm assuming it has more to do with the fact I'm using the gadget that bolds the new entries on my watchlist than it does with the fact that I'm using the Vector skin from Firefox 21 on a Windows Vista laptop. Technical 13 (talk) 16:52, 27 May 2013 (UTC)[reply]

I've given this its own section heading, so you're not stealing the thread any more

. – PartTimeGnome (talk | contribs) 17:01, 27 May 2013 (UTC)[reply]

I'm using the bold watchlist gadget, but I still see the bullets without a problem using both Vector and Monobook. It might be related to some other gadget; can you see the bullets in page histories and Special:RecentChanges when logged out? (Obviously you can't check your watchlist when logged out.) Or it might depend on the browser; which browser do you use? I'm using Opera 12.15 on Linux. – PartTimeGnome (talk | contribs) 17:06, 27 May 2013 (UTC)[reply]

You can't see them on the watchlist if you have enhanced recent changes enabled (aka Group changes by page in recent changes and watchlist), but you should always see them on history pages. — HHHIPPO 17:22, 27 May 2013 (UTC)[reply]

Thanks PartTimeGnome for editorial help. I just logged out and had a look at RC with the same result. I also disabled AdBlock Plus on en.wikipedia.org (just in case) with the same result-- no bullets. I see them on history pages. --Fama Clamosa (talk) 17:24, 27 May 2013 (UTC)[reply]

I don't see them on any pages in any browser on either account. I've checked Watchlist, RC, and page histories in IE7, as well as the latest version of Opera, Chrome, Firefox, and Safari. This T13 account has RC grouping on, but my ShoeMaker account doesn't, and there still are no green bullets. Technical 13 (talk) 17:29, 27 May 2013 (UTC)[reply]

Okay, so I got them to show up on my ShoeMaker account in all of the browsers I tested (IE7, Opera, Safari, and Chrome), but ONLY on my watchlist and histories (which was hard to get, I could only get it from the hist link on the watchlist page) did it work, still no green on RC. Technical 13 (talk) 17:51, 27 May 2013 (UTC)[reply]

Just to double-check: are we really talking about no bullets at all or about no green bullets? I just tried in all 4 skins, looks fine (FF 21.0, Ubuntu 12.4). When logged out, I still see bullets but of course no green ones. Anybody who really sees no bullets at all: could you try the Cologne Blue skin? — HHHIPPO 18:19, 27 May 2013 (UTC)[reply]

No green bullets. The icon used for the green bullet is hard to distinguish without using my magnifying tool. Of course, there are no bullets at all on this account, but I am using enhanced changes (which should remove the text declaring that new should have green bullets since they don't exist for that gadget). Technical 13 (talk) 18:30, 27 May 2013 (UTC)[reply]

Bullet size: agree that they are really hard to see. I changed them to for myself.
Text announcing green bullets: indeed that's wrong, but it's hard to remove it without removing the Mark visited button. Unless... is it possible to add html tags to MediaWiki:Wlheader-showupdated? So we could set display:none in enhanced mode?
What's missing: so the only thing you don't see is green bullets when looking at RC in non-enhanced mode? Are you sure you found an edit that should have a green bullet? — HHHIPPO 18:58, 27 May 2013 (UTC)[reply]

It is possible to add html tags to MediaWiki:Wlheader-showupdated, you can tell because there is already a green in there to change the color of the word green. I'm sure it will be a very rare circumstance to ever see a "new since last" revision in RC. Technical 13 (talk) 22:26, 27 May 2013 (UTC)[reply]

The tags are being worked on, see next sub-thread. To see a green dot in RC, what I did was purposely leave an updated page in the project namespace unvisited, and then filter RC for that namespace. There the traffic is not too much. — HHHIPPO 06:47, 28 May 2013 (UTC)[reply]

I've made an edit request → MediaWiki talk:Wlheader-showupdated#May 2013 Edit Request which should give span#id that can be used to display: none; (and that could probably even be worked into enhanced recent changes to automatically apply something similar). Technical 13 (talk) 10:51, 28 May 2013 (UTC)[reply]

This edit request has been fulfilled and you may now add

span#mw-wlheader-showupdated{display: none;}

to your common.css to hide this extra interface message. Technical 13 (talk) 19:32, 28 May 2013 (UTC)[reply]

Related changes bug

It still tells us that "Changes to pages on your watchlist are shown in bold," but they're actually now shown with the green bullet (even with the green bullets switched off in the watchlist). I'm guessing this is the same in Recent changes. FallingGravity (talk) 20:00, 27 May 2013 (UTC)[reply]

The message is fixed now, except that, like above, there are no bullets in enhanced mode. Plus, watched pages are still supposed to be bold if the corresponding gadget is enabled, but that's broken atm. — HHHIPPO 20:40, 27 May 2013 (UTC)[reply]

That's a different message: MediaWiki:recentchangeslinked-summary. That text has never been hidden. I changed the text, and the gadget to hide the text conditionally. — Edokter (talk) — 20:43, 27 May 2013 (UTC)[reply]

I know. Looks good. Could you set the same span around the watchlist message (but not the reset button)? Technically one should also set display:none for them in enhanced mode, but as long as the span is there people can do that locally. — HHHIPPO 20:50, 27 May 2013 (UTC)[reply]

Will get around to it tomorrow. Too late now. — Edokter (talk) — 21:53, 27 May 2013 (UTC)[reply]

Fixes not working in monobook...

I have tried all of the above codes in my common.css, and none of them have made the stupid green bullets go away. Is there help to be had? - The Bushranger _{One ping only} 04:48, 1 June 2013 (UTC)[reply]

Did you try using the "no green bullets" gadget? It worked when I tried experimenting with the monobook skin. FallingGravity (talk) 19:04, 2 June 2013 (UTC)[reply]

Re: Watchlist notice

Today, I noticed that on my watchlist at the top it now says "Pages that have been changed since you last visited them are shown with a green bullet." Is this only temporary? Or is there a way I can remove it?--十八 20:51, 7 June 2013 (UTC)[reply]

Thanks extension

Hey all. As described on this dedicated page, we've built a system to thank editors for individual edits. As I'm sure you're all aware, it's relatively trivial to deal with bad contributions (undo and rollback are your friend!) but we don't really have any way in MediaWiki to encourage editors who have made good edits. We can send out barnstars, sure, but barnstars are justifiably Kind Of A Big Deal - they're for really substantial contributions or a large number of small ones. There's nothing to thank people for individually helpful, gnome-ish edits except dropping a personal note - which is quite a lot of effort to do every time someone corrects a typo.

The Thanks extension solves for this; with it, you can send an editor a notification about the value of their edit with a couple of button-clicks. If you're not a fan, there will be preference options to turn off (respectively) receiving thanks, and seeing the interface elements of the extension at all. You can read more here :). Okeyes (WMF) (talk) 19:53, 28 May 2013 (UTC)[reply]

We really need other things: Look, these Send-thanks buttons are interesting, but we really need several other things first:

Fix edit-conflicts of 2 replies: We need an edit session to auto-merge two replies, or 2 lines added after the same line.
Allow '#' inside a title: We need to create titles like "C# or Bb" (See sharp or Be flat), the old joke sign on the front of a piano-mover truck, so the page does not insist the title is simply "C" with appendage "# or...".
Raise expansion-depth limit: We have several templates that are just a few levels too deep, and raising the wp:Expansion depth limit, from 40/41 to 50/51, would fix thousands of articles, especially numerous animal species, to reformat better.
Set a parameter value {{set:x|45}}: Many templates run 10x-20x times too slow because they keep re-calculating the values, over and over. Instead, if we could reset or store the calculated parameter values within subtemplates, as {{set:long_calculation|467000.32}}, then many templates could run 10x-20x times faster, with lower expansion depth.

Fixes to those few simple problems, listed above, could help many thousands of users. I understand you want us to thank people, but really, those other problems from 7 years ago, are much more important at this point. Meanwhile, as you are auto-merging 2 replies in edit-conflicts or fixing titles to allow '#' or storing {{set:x|45}}, then we will struggle, for the next several months, to somehow send users the 5 words, "Thank you for your edit". We really need the important things done first, but thank you, in advance, for fixing the important issues first. -Wikid77 (talk) 08:14, 30 May 2013 (UTC)[reply]

For the "parameter value" one, the best way forward there is Lua. That may also help with some expansion-depth cases. There is actually a redirect at both C♯ (C sharp) and B♭ (B flat). You probably mean "#", though, which is very tricky since that inherently has a special meaning both on Wikipedia and the web (bascially a section). There is nothing special about ♭ though. I'm not sure exactly what scenario you mean for the 2 replies, but you should make sure it's in Bugzilla. There are teams (namely Wikimedia Platform Engineering) specifically working on issues like this. They're the ones that helped develop the Lua extension, among other things. So understand that different teams are going to focus on different problems. Superm401 - Talk 05:07, 31 May 2013 (UTC)[reply]

I just went to undo some changes by a POV pusher, but accidently thanked them as this was where I expected the 'undo' option to be - not good design IMO. I've just turned this option off. Nick-D (talk) 02:31, 1 June 2013 (UTC)[reply]

Me too. Wikipedia:Notifications/Thanks#How to turn off this feature for others. Tassedethe (talk) 00:47, 3 June 2013 (UTC)[reply]

I came looking for discussion of this thing as well, had no idea what this dumb thing was til I "thanked" a bad edit, meaning to revert. Tarc (talk) 12:25, 4 June 2013 (UTC)[reply]

Nice to see work, but please go easy

Hi. By all means don't take me too seriously, I am likely *not* your target audience (not a young enthusiast, rather a disheartened old-timer) , but well... I have been mostly out for about a month or so. I get back to a lot of changes, and it is good to see folks are trying to improve WP. The problem is that is getting, for my reading preference, a unreadable mess. There are notifications in coloured boxes that pop up. The notifications themselves look excellent - it is the implementation that looks crappy: the colours and pop-up windows are very not WP-like (maybe that is the start of new WP look?). Not to mention being released apparently without the very minimum of testing (I got a talk message by 1 (one) user and notification about "<username> and 1 other posted on your talk page", while there is no 'other', how can a serious test miss that?) Anyway, get on with it, it looks promising. And the links are weird, with a dotted underline (?) and pop-up hints? Also it looks like I am back 20 years, sometimes pages take 10+ seconds plus to load and they are so full with, I can't be sure, javascript?, that the page keeps on moving around, building up, all the time. It is the back to the 1990s and waiting for those (then) huge pictures to load? To those working hard to improve: thank you for your work, there are some valuable contributions. But please, do not over do it. A Encyclopaedia one can't load nor read comfortably, is useless. - Nabla (talk) 02:24, 29 May 2013 (UTC)[reply]

Nabla, the new notifications aren't for everyone. And Wikipedia has no "target audience." And if you're feeling disheartened, I'd be glad to help you with that. Just drop me a talk message. But, notifications, you can turn them off and go back to the Orange Bar of Doom if you wish. Go to "Gadgets" under Preferences, and select "Display a floating alert when I have new talk page messages." That should do it. And on page weight, that might be a problem with your browser or computer, or maybe a WP bug. The dotted underline etc. I'm not sure about, but I'm sure someone else will know. But drop me a line on my talk page, we'll have a chat. Thanks, TheOneSean ^{[ U | T | C ]} 11:55, 29 May 2013 (UTC)[reply]

10-second delays to format sidebar menus and Insert-menu: I think the 10-second delays, which cause the screen to shift around every few seconds, are related to the auto-collapsed sidebar menus, such as >Interaction or >Toolbox. Perhaps someone knows a way to turn off those collapsed menus, and just show the rapid simple menus from last week, last year. I think many people are learning there is a thin line between "user-interface design" and "user-interfere design". In general, do not move the steering wheel or brake pedal every other day; instead keep navigational controls stable, to avoid even worse user frustration.
Petition to reduce user-interface changes: Many other users have noted severe problems with using the new Wikipedia screens, such as the orange-bar segment for new-messages will lock out some menu options. See petition:

"WP:Petition to the WMF on handling of interface changes"

Numerous comments have been added to the petition, about various issues, and slowdown or browser lockup problems. This isn't Facebook where people come to see their "likes" accumulate in a like-counter. However, the developers are smart enough to stop this, and fix real problems. They recently fixed support for IE8 browsers (world's most popular) to align screen boxes, even to position the map-locator dots to the exact pixel, while adding Wikidata support. -Wikid77 (talk) 08:50, 30 May 2013 (UTC)[reply]

@Nabla: "the colours and pop-up windows are very not WP-like". Just out of curiosity, are you a monobook user ? Why do you think it is not 'Wikipedia-like' Because we never really had a colorscheme that we truly identified with I think. —TheDJ (talk • contribs) 21:51, 31 May 2013 (UTC)[reply]

@TheDJ: I am using Vector, fully standard except for four CSS line highligting Portuguese and other non-English text. The non-WP looks come from increasing the number of colours: we had black/blue/red text on white/blueish light grey background, now there is white text on a dark gray box prominently on top, plus the silly green "edit saved"... floating window, also a floating window for the notifications. How come pop-up windows suddenly became a good thing (javascript pop-up is good, html pop-up is bad? why?). - Nabla (talk) 00:00, 2 June 2013 (UTC)[reply]

@Nabla: I agree with you that the theme of post edit is somewhat out of place with the rest of site. The 'white on gray' I find a tad less convincing, it's just inversion in order to make it stand out a bit more. The idea of ajax for post edit is clear, you only want to show it very temporarily, and you don't want to affect the flow of the content any more than required. Personally though, I think it's positioning can be improved and so can it's color scheme. For notifications we have a similar problem. The idea is to give the user many more notifications, configurable and live (so not just when navigating pages). Doing that with plain html is almost impossible to do, while not also aggressively taking away realestate from the content.
Also, there is no such thing as html popups. There is html content, ajaxified html content (which can be overlayed on top of other content) and alert dialogs. With the increase in interaction, you will see more ajax based content, simply because it saves you a ton of pageloads. It's only logical. Users who don't want to use ajax, will have to make those many page navigations, but it doesn't make sense for the majority of users if you ask me. Anyway, in terms of design, you will see more Echo, then postedit from what I have seen of projects being discussed. Postedit is the odd man out. —TheDJ (talk • contribs) 17:31, 2 June 2013 (UTC)[reply]

@TheDJ: The problem with the "post edit" is it existence, whatever way you do it it is silly. Having a floating window that does not fit in, actually is a must, otherwise it would be doubly silly: to have a warning that noone can see :-) «The 'white on gray' [...] it's just inversion in order to make it stand out a bit more» Evidently, and it does stand out, and THAT is the problem :-) Why do we want a "0" (i.e., no news) to stand out?

As to «Doing [many notifications] with plain html is almost impossible to do, while not also aggressively taking away realestate from the content.» Why do we need 'many' notifications? And assuming we do, why do they need to be mingled with / on top of the content? Tabbed browsing is perfectly standard nowadays, so we could have a dedicated page, with all the space in the world for notifications (and we already do right?) plus a small warning on the 'main' page (if we really must - which we already do have also). Any editor interested in the notifications would look into the notifications page once in a while, or after getting a warning. The concept of having multiple place-holders (i.e. windows) to differentiate content isn't exactly new :-) I currently have 24 tabs/windows open across 6 workspaces - I bet you do not advise me to try and cram them all in a single window :-) So why exactly do we *need* to a have a loong list of notification on top of content?.

«there is no such thing as html popups» ? I am missing something there. Yes, there are no html pop ups in WP, but there are html pop-ups, right? <a ... target='_top' ...> or something? And they were usually frowned upon. Why is javascript pop-ups a good thing, and html pop-ups a bad thing?

Mostly rhetorical questions, I am fine that we disagree with no need of further explanations. - Nabla (talk) 23:43, 3 June 2013 (UTC)[reply]

PS: You almost completely lost me with the last paragraph... I have some faint idea of what is "ajaxified content", but I "will see more Echo"?? "Postedit is the odd man"?! - Nabla (talk) 08:35, 4 June 2013 (UTC)[reply]

Lua and date/time templates

We have a number of date and time templates, including {{Start date}}, {{End date}}, {{Birth date}}, and many more in the latter series. These could do with being re-written in Lua, which will make them faster, and allow us to both increase their usefulness and to detect and warn about errors (similar to the recent re-write of our referencing templates).

It makes sense to do this in a coordinated manner, rather than individually, and to see whether we can give them a common core.

I'm not a Lua coder (I'm interested in learning, but that's a separate issue), but I do understand the various templates' inputs and outputs, and have worked to develop them for several years,

There is also discussion of similar date coding for the |published= parameters in reference templates.

Would anyone be interested in taking on this project? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:25, 29 May 2013 (UTC)[reply]

I'd be willing to co-op with someone - I don't have enough time to do it all by my lonesome. Anyone? TheOneSean ^{[ U | T | C ]} 15:38, 29 May 2013 (UTC)[reply]

Date templates run 85/second and omit invalid months: I do not see the need to rewrite Template:Start_date (in 113,000 pages) or Template:End_date to use Lua script, because they already run faster than 85 per second (typically used once per article), and if the month number is invalid, then no month name is displayed, clearly indicating the month code was not correct. Meanwhile, as we have found with the Lua-based wp:CS1 cite templates, people either check the results or they don't, and showing Very long red error messages has not stopped people from adding more invalid data into Wikipedia articles, whether minor or major pages. Plus showing the glaring red error messages does not force readers to edit and fix the pages, within a few days or weeks, while it only makes articles look trashy for the vast majority of readers, all for what, to say, "April 31 is invalid" where "April 30" should be the value, or who knows what to put there? ...and how does that really help the readers of 81,000 film articles or others? There is no reason to highlight an error in a date which the reader might not even notice, and even if they do, then the readers will realize "April 31" is invalid, without a red-error message to inform their South Park "warped little minds" as if the readers were clueless about dates. Another issue we learned from using Lua, in the earlier Lua cites, was how every small tweak to alter or restate the red-error messages (which most readers have ignored) had merely triggered the daily reformatting of 2 million pages (for weeks), which made the Toolserver wp:REPLAG delay fall days further behind. Plus, what if the Lua rewrite introduces subtle new date-formatting bugs which do not exist now because of current unknown parameter interactions, and all for what? Sorry, I have done the tedious analysis, and I do not see the need to "re-invent the wheel" of date formatting. This is another YAGNI distraction from high-priority issues. However, thanks for asking, because it sets a clear example for where Lua script is not needed but risks new bugs, plus red-error scarring of some pages, with massive re-reformatting of 110 thousand related articles, for every update of the Lua versions. -Wikid77 (talk) 10:42, 30 May 2013 (UTC)[reply]

Funny, I don't recall asking for "red-error scarring"; your "new bugs" hypothesis is FUD; and your screed ignores the additional functionality which i did propose (and which has been suggested for some time on the talk pages of some of the templates involved). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:49, 30 May 2013 (UTC)[reply]

It is a rule-of-thumb, in computer work, how 10% of bugfixes cause more bugs, and rewrites are even worse. As for enhancements, the markup-based templates run 85/second (used mostly once per page) and could handle new options checked at the rate of 750/second or faster. -Wikid77 15:45, 30 May 2013 (UTC)[reply]

I have an question. Why does not a single one of those three templates (start date, end date and birth date) use the time parser function ?--Snaevar (talk) 11:47, 30 May 2013 (UTC)[reply]

I think those templates were just too rapid, and simple when showing "Month d, YYYY" format, to need #time, while running 85/second, and I could optimize them to run over 100/second, but I will try your suggestion in benchmarking. Thanks. -Wikid77 15:45, 30 May 2013 (UTC)[reply]

Using #time is 2.1x faster as 182/second and checks date errors: I have run more than 15 benchmarking tests, to show how using function #time to show the "Month" name will quicken Template:Start_date/sandbox to run 2.1x times faster, as 182 dates/second. However, #time will issue the red-error scarring "Error: Invalid time." for invalid month/day, which might not meld with prior usage of the template in 113,000 pages (infoboxes), where invalid dates were ignored, showing whatever day "34" or such. -Wikid77 16:26, 30 May 2013 (UTC)[reply]

Converting to Lua would also allow for far better error checking, as recently suggested at Template talk:Death date and age#Math bug. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:20, 4 June 2013 (UTC)[reply]

"Date templates run 85/second and omit invalid months" -- NO, THEY DON'T (omit invalid months); at least this one doesn't, as per the link above Template talk:Death date and age#Math bug Lx 121 (talk) 20:13, 5 June 2013 (UTC)[reply]

Anonymity of WP:Third opinion requests

WP:Third opinion says to include

A five tilde signature (20:34, 30 May 2013 (UTC)) to add the date without your name.

and it includes this note - which I added a while back:

(Note: your name will still be shown in your contributions and edit history.)

Users should be able to request third opinions anonymously. Why can't they? How can editors be empowered to do so?

Note: proposal edited to reflect refinement and offer from Theo.

Blocked users can edit only their own talk pages, so it would presumably be easy to make an account that anyone could use that could only edit WP:Third opinion. Any thoughts on how easy that would be?

Or, we could make it so that users' edits to WP:Third opinion were not logged (in the normal way; we could have logs that oversighters could see and we'd want 3O providers to still be able to know when a 3O had been requested.) Any thoughts on how easy that would be?

We could provide a bot that copied requests received via a web form. ~~Any thoughts on how to do it or how easy that would be?~~

We can and should provide actual 3O requester anonymity as long as we're telling 3O requesters to sign 3Os with ~~~~~ to be anonymous.

Pitfalls? Is this mature enough an idea to file a bug report? --Elvey (talk) 20:34, 30 May 2013 (UTC)[reply]

If there's interest, it could be done through a web portal and a bot, which I'd happy to configure. However, I'm curious--why does this have to be anonymous? If the dispute is between two people, won't the disputants both know who requested it? And even if the third party doesn't know who requested it, does that really matter? If they have a conflict of interest with either of the parties, they probably shouldn't be assisting, period. Theopolisme (talk) 20:41, 30 May 2013 (UTC)[reply]

I'm not familiar with 3O, but a quick search of the 3O talk page archives turned up these two discussions: Wikipedia_talk:Third_opinion/Archive_5#Not_listing_requesting_editor.27s_name and Wikipedia_talk:Third_opinion/Archive_4#Why_no_signatures.3F. Those might shed some light on the subject. jcgoble3 (talk) 23:13, 30 May 2013 (UTC)[reply]

Thanks, Jonathan! @Elvey: I can create a web form (+bot to add them to WP:3O) for submissions if that's what y'all would like. Theopolisme (talk) 01:44, 31 May 2013 (UTC)[reply]

I'm entirely opposed to such anonymity, but am heading to bed and can't type long explanations well on this cell. I'd be happy to do so in the morning though. Technical 13 (talk) 02:18, 31 May 2013 (UTC)[reply]
Okay, good morning! The reason I am opposed to such anonymity is the fact that as a respectable person that respects the process, I do not want to offer a third opinion on a dispute where I'm familiar with either person currently involved. It is a waste of my time to have to go to the location of the dispute to see who is involved before I decide if I want to say anything or remain silent. The normal process for such response is to read the dispute, research both claims to try and see it from both perspectives, and respond one way, the other, or with a compromise that may be satisfactory to both and always in a neutral tone. In the process of leaving a response, it is normal practice to add a reasonable edit summary and check the "Watch this page" checkbox to add it to my watchlist so I can monitor for responses and questions. So, if there was anonymity amongst both of the other parties (they would have to remove all of their signatures from the talk page as no-one goes into a discussion expecting to need to 3O), and request assistance without a signature, then the responder would be going in not knowing who was involved so they could avoid situations where they know one of the people opening them up to claims of favoritism and sneaky emailing and working behind the scenes in a canvassing way to sway a dispute one way or the other. I personally wouldn't want to get caught in that kind of mess and would likely quit offering 3Os if I had to work extra hard to find out who was requesting it so that I could know that I do not know either of them and therefor could not be accused of a COI in the dispute. Technical 13 (talk) 11:40, 31 May 2013 (UTC)[reply]

I understand the concern, "I do not want to offer a third opinion on a dispute where I'm familiar with either person currently involved." But that's easily addressed by requiring that the reporter mention the two people involved. And it's a small issue to begin with; someone beginning to provide a 3) is sure to see the names of the persons involved very quickly, even if we don't add the above requirement. --Elvey (talk) 02:14, 5 June 2013 (UTC)[reply]

I'm one of the most active volunteers at 3O — over 550 edits there and well over a hundred opinions given — and I believe things are fine just the way they are. The project places an ethical obligation on volunteers to be neutral, and the no-sig requirement is really to just help volunteers remain neutral in giving opinions by not knowing who asked for it. In truth, it's usually pretty obvious who made the request, either by the way the request is stated or by the fact that one or the other of the editors says at the article talk page that they're going to ask for a 3O or says that they've done so. The requirement is just a tiny bit of help, nothing more. I'd be opposed to making it more anonymous, however. For one thing, it's probably fruitless for the reasons I've already stated, but more importantly nothing should get posted publicly at Wikipedia which cannot be attributed to the poster. Moreover, 3O is the most "lightweight" of the dispute resolution processes at WP and 3O's are nothing more than just that: opinions. An occasional one which is slightly biased by knowledge of who asked for it isn't going to do much harm, in the grand scheme of things. Regards, TransporterMan (TALK) 18:22, 31 May 2013 (UTC)[reply]

+1 The opportunity for abuse and confusion is too great. It wshould stay as is. We already have at least as much anonymity as is good for the encyclopedia. ~ — Preceding unsigned comment added by DGG (talk • contribs) 23:07, 31 May 2013 (UTC)[reply]

^ says DGG, not signing his message...the irony is appreciated, I assure you :) Theopolisme (talk) 23:07, 31 May 2013 (UTC)[reply]

It's the impact of the irregular, not the most frequent/regular/active 3O suppliers that I'm concerned about. The reason I am proposing better anonymity is not mitigated by the facts TransporterMan mentions, because they address what I see as very minor problems to begin with. Here's a situation where the weak anonymity is a more serious problem: It's common for one person involved in a 2-person dispute to follow the edits of the other. If one of them thereby notices the other requested a 3O, that person could ask an ally or meatpuppet or use a sockpuppet to respond to the 3O. Such a biased 3O goes a long way to supporting a determined POV editor. If Theo implements the feature I'm asking for, then the follower will likely only know of the 3O request once it's been taken on by a regular. If providing such biased 3Os is no longer easy, then 3Os become more trustworthy, and more valuable. Seems like a relatively certain, specific and compelling reason to me.--Elvey (talk) 02:14, 5 June 2013 (UTC)[reply]

I'm not sure that is entirely accurate... Of the disputes that I have followed, it is most often that the person in the wrong, who knows they are wrong uses a SOCK account. The person that is right knows there is something fishy going on and it goes to DRN. The people who help out and volunteer in the DRN, often check the backgrounds of all three people involved and see if there is any potential sockpuppetry or meatpuppetry going on and seem to have a high rate of detecting such things. The sock goes to SPI and the DRN case is closed appropriately. It is my belief that anyone knowledgeable enough to make a sock account to try and prove their point, albeit an extremely stoopid idea, likely has WP:3O on their watchlist and will note the 3O request anyways. So, this doesn't really offer any improvement to the system and like I said above causes an issue with putting reviewers under extra fire for playing favorites despite not knowing who initially involved. Now, if your idea was to make DRN more anonymous by not having the two disputing parties identified and leaving it up to the 3O responder to decide if they want to be anonymous or not, then I would support that proposal. The reason I would support that and not the other is because of where the discussion takes place. In DRN all discussion is localized to the noticeboard and there are often multiple disputes going on at any one time. This means there are multiple DRN volunteers that will skim over each topic and the likelihood of one of the more experienced ones noticing something is exponentially greater than just the one 3O responder on the article talk page. Technical 13 (talk) 12:24, 5 June 2013 (UTC)[reply]

Following a user's contributions and using an ally is relatively quick/easy compared to doing that and following 3O as well; 3O is quite active. The change I'm proposing in no way opens up reviewers to extra fire. Instead of addressing my proposal, you have twice put up straw men of other ideas that are NOT what I've proposed ("they would have to remove all of their signatures" and "...if your idea was..."), and then shot them down. (A straw man did open up reviewers to extra fire.) Congrats, those straw men are dead. So what? If their flaws were present in my proposal, surely you'd shoot at my proposal instead of your straw men. You claim to routinely know when someone "knows they are wrong" in a content dispute and yet you can't see inside their heads, and besides, it's certainly not true that most people in a content dispute who are wrong know they are wrong. There are a fraction (including some paid shills) who don't believe what they're saying, but they're certainly a minority. --Elvey (talk) 17:45, 5 June 2013 (UTC)[reply]

Also, it seems you missed my comment above, which I'll repeat:

I understand the concern, "I do not want to offer a third opinion on a dispute where I'm familiar with either person currently involved." But that's easily addressed by requiring that the reporter mention the two people involved. And it's a small issue to begin with; someone beginning to provide a 3) is sure to see the names of the persons involved very quickly, even if we don't add the above requirement. --Elvey (talk) (repost)

Also, noted that I've EDITED THE PROPOSAL because Theo's offer made it easy to simplify.

I see being OK with telling 3O requesters to sign 3Os with ~~~~~ to be anonymous, and opposed to actual 3O requester anonymity as advocating dishonesty. I see no other way one could have those views. --Elvey (talk) 17:45, 5 June 2013 (UTC)[reply]

New feature: a quick way to say "thanks" for an edit

Hi folks, we wanted to let you know that we just released a new feature today: the Thanks notification offers a new way to give positive feedback on Wikipedia.

This experimental feature lets editors send a private 'Thank you' notification to users who make useful edits -- by clicking a small 'thank' link on their history or diff page, as described on this overview page. The purpose of this Thanks notification is to give quick positive feedback to recognize productive contributions.

We hope that it will make it easier to show appreciation for each other's work -- and it should be particularly helpful for encouraging new users during their first critical steps on Wikipedia. We have intentionally kept this notification as simple as possible, so we can evaluate it and improve it together.

Once you have had a chance to try it out, we welcome your feedback about this feature, and look forward to a healthy discussion on this talk page. (And if you do not want to thank others or be thanked, you can easily disable this notification in your preferences, as described here.)

Many thanks to all the community members who helped us test this feature in recent weeks. We hope the rest of you will find it helpful as well. Enjoy! Fabrice Florin (WMF) (talk) 01:09, 31 May 2013 (UTC)[reply]

I misclicked twice there today, as the last link of that portion has been "undo" so far. I wanted to undo and most probably they have got "thanks"! It seems Wikimedia is working on "implement first and inform later" basis! --Tito Dutta (contact) 01:19, 31 May 2013 (UTC)[reply]

I'm confused; we sent out notifications several days ago about it, one of them here. Okeyes (WMF) (talk) 11:13, 31 May 2013 (UTC)[reply]

Well, If that was the case, at least I overlooked the notification. I was surprised by the new "Thank" functionality. --Patrick87 (talk) 11:35, 31 May 2013 (UTC)[reply]

Yes, I also think the button is placed badly. I left a comment on the talk page. --Patrick87 (talk) 02:19, 31 May 2013 (UTC)[reply]

Not sure if I missed something but I cannot access this feature no do I see any instructions on how to turn it on. Kumioko (talk) 01:57, 31 May 2013 (UTC)[reply]

@Kumioko: Is "Exclude me from feature experiments" checked for you at Special:Preferences#mw-prefsection-rendering? If so, you need to uncheck it to see the "thanks" link. Theopolisme (talk) 03:02, 31 May 2013 (UTC)[reply]

No its not, I thought that too. I also tried IE and Firefox, I tried checking the exclude option and then unchecking it again. Maybe its hiding in the same place as my Green bullet? :-) I don't have that either. Kumioko (talk) 03:06, 31 May 2013 (UTC)[reply]

Are you looking at contribs? It seems it only works when viewing page histories or diffs, not on watchlists or contribs pages. Beeblebrox (talk) 04:17, 31 May 2013 (UTC)[reply]

Alas, I have accidentally thanked someone I wished to 'undo' this morning. Fortunately it was only an experimental edit, but I surely did not mean to thank them. I did my revert afterwards, but there seems to be no way to undo my thanks. They are registered, so perhaps they will be a better editor because of my goof. This seems badly placed (exactly where 'undo used to be). Either that or I can't edit until after I am more caffeinated. Sheesh! (Again I was behind the door when this was passed out...) Fylbecatulous talk 10:10, 31 May 2013 (UTC)[reply]

I too have left a gentle message on their talk page (sigh) Fylbecatulous talk 10:19, 31 May 2013 (UTC)[reply]

I've just done the same, as it was removing a CSD tag it probably looks sarcastic! There should be an 'undo thanks' option that appears to replace the 'thanks' option. Giant Snowman 10:29, 31 May 2013 (UTC)[reply]

A feature like this should require a confirmation step, just like the "undo" button it is unfortunately next to. Hullaballoo Wolfowitz (talk) 10:38, 31 May 2013 (UTC)[reply]

Yes, it should definitely not be a one-click option. Giant Snowman 10:45, 31 May 2013 (UTC)[reply]

Good feature, expect I will use it a lot, but do need some way to handle misclicks though. Personally I'd prefer not to have to confirm each Thanks, since it would be two clicks for one minor job. The ability to undo the Thanks for some seconds afterwards might be enough. Rjwilmsi 11:03, 31 May 2013 (UTC)[reply]

Probably a pain to code, however, but I'll run it past people :). Okeyes (WMF) (talk) 11:13, 31 May 2013 (UTC)[reply]

You sound pretty silly suggesting that two clicks would be a burden. :-) --MZMcBride (talk) 13:49, 31 May 2013 (UTC)[reply]

I don't think it sounds that silly if a person is ambitious about using the feature and is very active in the community... I could see someone thanking a couple dozen people for certain contributions a day so it is not as much two clicks as it is 50 clicks vs 25 clicks... They add up... I think the users was asking for a feature similar to Google calendar that has a little javascript popup (just like the one you use for "your edit has been saved") that would allow them to quickly retract their "thank" if it was a misclick. Technical 13 (talk) 13:55, 31 May 2013 (UTC)[reply]

Good feature- but the icon, a little heart in Barbie Doll pink, I can imagine what the reaction of many of the editors I would like to thank would think of that. Thanks, you are a diamond, thanks for the spadework, thanks for clubbing that ip-editor on the head. Would it take much code to allow me to set an icon in my preferences that matches my malevolent personality? -- Clem Rutter (talk) 11:59, 31 May 2013 (UTC)[reply]

For anyone interested, there's an open bug here regarding the Thanks workflow: bugzilla:47658. --MZMcBride (talk) 13:51, 31 May 2013 (UTC)[reply]

Any way to view a list of the thanks you've gotten? - Amaury (talk) 23:30, 31 May 2013 (UTC)[reply]

@Amaury: Yep, just go here. Theopolisme (talk) 23:31, 31 May 2013 (UTC)[reply]

MOVE the button

Twice(!) today, I accidentally clicked "Thank" instead of "Undo" on a diff page. The button is on the wrong place; it should not be listed after the page action links, but next to the user action link on the next line. — Edokter (talk) — 12:14, 2 June 2013 (UTC)[reply]

I don't see how people never had issues clicking (undo) when they were trying to (edit) or visa-versa... The (thank) is for that edit, but if you want it on the next line and aren't opposed to some js bloat, I could add it into my User:Technical 13/Scripts/NoThanks.js script... It won't be today, but I can probably finish up that script and get it in there by Tuesday. Technical 13 (talk) 12:28, 2 June 2013 (UTC)[reply]

It's because we are used to pressing 'undo' as the button furthest to the right, a place now occupied by the 'thank' button. This entire thing has been very poorly thought out. Giant Snowman 12:37, 2 June 2013 (UTC)[reply]

If that is it, the logical thing would be to put (thank) in the middle so that it isn't the furthest to the right or left... Anyways... If moving it down a line is a wanted feature, I'll add it, otherwise I'm not wasting time on it. Technical 13 (talk) 12:50, 2 June 2013 (UTC)[reply]

This has been an issue for twinkle/friendly users for ages. It's nothing new, we just expanded the group that encounters it a bit further. The central problem here is that our history, contributions, RC, diff etc pages are really poorly thought out in terms of UI. I'd love to see someone do some design work on that. —TheDJ (talk • contribs) 16:57, 2 June 2013 (UTC)[reply]

I've actually written some code for removal of the block and rollback interfaces as well, and I would be happy to take some time when I have it (this week is really busy with school, summer semester is always the toughest) to re-work my code and make a script that will re-locate "stuffs" in a more user friendly fashion and upon completion of that I would be happy to make note of it (screenshot or whatever of the output) on Bugzilla and get the layout put directly into the core. To do this, I need community input as to what it "should" look like. Technical 13 (talk) 17:30, 2 June 2013 (UTC)[reply]

I don't think we need to move the button - we need to make it so that it's 2 clicks. Giant Snowman 17:34, 2 June 2013 (UTC)[reply]

Tracked in Phabricator
Task T49658

I think that two clicks for something so simple that some users may actually intend to use to thank for 25-40 edits a day is too much... That being said, I'm not opposed (as mentioned on the related bugzilla) to having it so that when you click (thank) instead of it changing to (thanked) that it instead changes to (un-thank) or (de-thank) allowing you to undo it if it wasn't intentional. Technical 13 (talk) 17:57, 2 June 2013 (UTC)[reply]

The reason why clicking "edit" when you mean "undo" (or vice versa) is not an issue is because both require you to click another button before anything is saved. If you clicked the wrong one you can click your browser's "Back" button then click the one you meant. – PartTimeGnome (talk | contribs) 00:36, 3 June 2013 (UTC)[reply]

Hi everyone, thank you so much for all your helpful feedback about the Thanks feature! We have reviewed all the comments from a variety of channels and have started to discuss and prioritize feature requests, based on your suggestions. Over a dozen people have reported issues with the thanks link, which has caused some to accidentally click "thank" instead of "undo" on history and diff pages. We are now working on this issue as our top priority, as it appears that the current placement next to undo is problematic, as well as the lack of a confirmation or 'unthank' function. To help us solve this issue quickly, we would be grateful if you could answer a few questions, so we can pinpoint the problem more accurately -- and develop an appropriate solution in coming days. To keep our discussion focused in one place, we have posted these questions and a feature update on this Thanks talk page, and encourage you to post your answers on that thread. Thanks again for all your good insights! Fabrice Florin (WMF) (talk) 20:44, 5 June 2013 (UTC)[reply]
- Hi Fabrice. As an intermediate solution, can we at least swap the positions of the "Undo" and "Thank" links? That should dramatically decrease the likelyhood of clicking Thanks by accident, as we all expect the Undo link at the right most position. — Edokter (talk) — 16:05, 8 June 2013 (UTC)[reply]
  - OK, your idea is nice, your workaround put (without any previous discussion) into common.css is just unacceptable. Now the link is green! Not only that links are supposed to be blue with default settings, now it also looks like the "updated since my last visit" messages and messes up my experience with history pages completely! --Patrick87 (talk) 17:18, 8 June 2013 (UTC)[reply]

Time limit for thanks

Just wondering if there should be a time limit on thanks. I just got thanked for an edit I did in 2009. -- WOSlinker (talk) 18:12, 8 June 2013 (UTC)[reply]

I don't see a problem with that. Helder 18:48, 8 June 2013 (UTC)[reply]

Annoying Dev changes

OK devs keep screwing with the UI in monobook without really adding anything. They added #mw-watchlist-resetbutton to the watchlist which does nothing, So I hid it via AdBlock plus, This was recently modified to use a FORM#mw-watchlist-resetbutton which cannot be hidden. PLEASE stop screwing with the UI so that annoying useless "Features" can be killed once and forgotten about. Werieth (talk) 15:04, 31 May 2013 (UTC)[reply]

I agree. It seems too much time is being spent adding useless widgets, gadgets, wingdings and nonesense that doesn't "fix" anything. There are a nearly countless number of problems that could/need to be addressed but we keep wasting time on stuff no one is complaining or cares about. Half the crap doesn't even work or doesn't work right. Even worse most isn't wanted by the community and seems to be tailored n the assumption that if we make WP look more like Facebook more editors will be attracted to editing. Kumioko (talk) 15:10, 31 May 2013 (UTC)[reply]

"If we make WP look more like Facebook more editors will be attracted to editing"...yeah; that's at least part of it. See countless threads above. Theopolisme (talk) 15:16, 31 May 2013 (UTC)[reply]

Yes and its a massively incorrect assumption. I could explain in great detail why by giving some Sociological and technical reasons but its akin to making a car as big as a truck to attract truck buyers. Even f you attract the truck buyers you lose support from the car crowd. It seems like the Scifi channel just did something like this recently, Facebook did it with the hated timeline. We have to remember that the purposes for Facebook and Wikipedia are completely different as are the cast of characters that use and support them. Some features may be appropriate to use between the 2 but many are not. We shouldn't copy them just in the hopes that it "might" attract some new users. Kumioko (talk) 16:52, 31 May 2013 (UTC)[reply]

this has absolutely nothing to do with facebook. the added functionality allowing to distinguish between "read" and "unread" entries in the wathclist is very useful, and vast majority of users just love it. every forum software let me see in a glance which threads have new posts since i last visited them, my email client distinguish between read and unread emails, and it's a very good thing that WP allows this too. for the few and rare people who wish not to use this feature, enwiki added a special gadget that allows one to hide it. this feature comes with a button to "mark all pages visited". if it bothers someone so much, it can be easily hidden by editing Special:MyPage/common.css (just add the line

#mw-watchlist-resetbutton { visibility: hidden; }

peace - קיפודנחש (aka kipod) (talk) 17:24, 31 May 2013 (UTC)[reply]

So how did your description have anything to do with the new login page, the replacement of the OBOD with the number or the other things that bare a striking resemblence to Facebook? I agree that it can be beneficial to see if the aricle has updated since the last time I visited, but many of the other changes are less useful. In the end though it doesn't really matter. They aren't going to remove it once they have implemented it and I am certain there are more insignificant changes coming in the future. My only hope is that in the quest to make all these changes to Facebookize Wikipedia to recruit new people we don't drive away more that are currently here contributing. Kumioko (talk) 17:59, 31 May 2013 (UTC)[reply]

In 2 months, the May/June editor-activity data will reveal how many people gave up trying. Most people (74%) do not post to talk-pages, and they might continue editing as totally oblivious to other concerns. -Wikid77 19:42, 31 May 2013 (UTC)[reply]

my description has nothing to do with all these things. this section is not about them - you might want to go to the top and read what this section is about.

if you wish to hijack this discussion and whine about the login screen and other such things, there is little i can do to stop you, but it seems to me a bit pointless: there are several other sections on this very page that do deal with the login page and the rest of the stuff, so it's not like you have nowhere to whine about the things you want to whine about. peace - קיפודנחש (aka kipod) (talk) 18:23, 31 May 2013 (UTC)[reply]

Your attitude is typical of the problems that plague this site. A user voices conerns about poorly implemented and poorly thought out system changes and there written off as whining. Kumioko (talk) 18:28, 31 May 2013 (UTC)[reply]

Contact WMF product managers such as User:Fabrice_Florin_(WMF): We need to contact people who can change direction, rather than have the "tail wag the dog" and if we can get a discussion scheduled with User:Fabrice_Florin_(WMF), product manager of editor engagement tools (wp:Notifications & Thanks-buttons), then perhaps we can reduce the interface shock, while resetting priority on major issues instead. For example, I would think quickly fixing the 2-reply edit-conflicts could be part of the discussion, such as have an "edit-merge screen" to retro-insert changes into the recent revision for edit-preview, for complex edit-conflicts. Any bugfixes beyond those products might get referred to the specific WMF manager in charge. -Wikid77 (talk) 19:42, 31 May 2013 (UTC)[reply]
- Edit conflicts in discussions will be solved by Flow so you don't need to worry about that much. --Jorm (WMF) (talk) 20:01, 31 May 2013 (UTC)[reply]
- That might help but I'm not going to worry about it. I haven't gotten the impression that they generally care about what we as a community think. And why would they, we can't do anything even close to implementing changes. I have voiced my opinions and will continue to do so. I know that they watch these discussion boards and maybe they'll start adjusting their direction if enough people comment. I doubt it though. Kumioko (talk) 19:48, 31 May 2013 (UTC)[reply]
  - You say "we as a community" like en.wikipedia is the only community they have to listen to and take opinions and ideas into consideration... Wikipedia might be bigger than you think... Technical 13 (talk) 19:56, 31 May 2013 (UTC)[reply]
    - I'm active on English and German Wikipedia as well as on Commons (the three largest projects I assume) and tenor seems to be the same on all of the three projects. So if WMF cares about another part of the community with their actions, they should start to explain themselves better. --Patrick87 (talk) 20:33, 31 May 2013 (UTC)[reply]
      - And even if other projects wanted the changes or didn't care, they could care about us by not installing certain components here that they've installed elsewhere. Technically speaking, there's no reason to require that all Wikipedias use the same software. Nyttend (talk) 12:20, 4 June 2013 (UTC)[reply]

"Missing operand" problem

For quite some time, my monobook.js page hasn't been loading. At present, the editing tools won't load, and ~~Pilaf's Live Preview~~ Lupin's pop-ups won't display either. Even refreshing it (or opening Internet Explorer 10) won't help solve it.

I'm not sure what's happened, but when I go to "Inspect element" from any WP page using Chrome 27 (Windows 7), I get a message which says:

 Uncaught Error: JavaScript parse error: Parse error: Missing operand in file 'User:Slgrandson/monobook.js' on line 54

I managed to trace that 54th line by hand, and it appears to come before Raylu's deletion-sorting tool. I still can't be so sure; which parts aren't working within this code? --Slgrandson (How's my egg-throwing coleslaw?) 23:16, 31 May 2013 (UTC)[reply]

Remove the HTML comment on line 54 – that's probably all. --Patrick87 (talk) 23:25, 31 May 2013 (UTC)[reply]

The syntax  is not valid javascript. Both of these lines should be either removed, or altered to the /* comment text */ form. I also notice four instances of document.write( ... ); which I believe are now forbidden by MediaWiki. --Redrose64 (talk) 23:34, 31 May 2013 (UTC)[reply]

Readjusted with those tips in mind--and what do you know! I've got them back. Thanks! --Slgrandson (How's my egg-throwing coleslaw?) 01:10, 1 June 2013 (UTC)[reply]

Wait, my what? -raylu^T 21:29, 4 June 2013 (UTC)[reply]

Concerns with Flow

Okay, so I've been following the discussion on Flow. There are many things that I am concerned about as it will completely change the way that talks and discussions and what not will have to be handled... The most recent thread of concern is mw:Thread:Talk:Flow/Avatars/reply (25) where it seems that not only will customizable signatures be a thing of the past, but using templates in discussion (even the simple useful ones like {{Done}} and {{Not Done}}) will not be allowed anymore either. Just plain text and a system default signature. It makes me feel like we are all truly being assimilated. Technical 13 (talk) 22:42, 1 June 2013 (UTC)[reply]

Dislike times three or four dozen. Change for change's sake. Do they care about us oldies at all? (What will happen to all those templates already on talk pages when Flow is rolled out?) Ignatzmice•talk 22:53, 1 June 2013 (UTC)[reply]

The biggest concern here might actually be the loss of {{Help me}} and {{Admin help}} making it even harder for new users to get help... Where are those two templates suppose to go? On user talk pages... Where is Flow going to be rolled out to start? On user talk pages... *sigh* Technical 13 (talk) 22:57, 1 June 2013 (UTC)[reply]

How will we discuss the appearance of templates? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:58, 1 June 2013 (UTC)[reply]

We won't be able to use any of the {{Tl|...}} family anymore... That being said, curly brackets should just display as curly brackets from my understanding so we can just type them out (and use square brackets to link the template if we want)... At least that is my guess... Technical 13 (talk) 23:05, 1 June 2013 (UTC)[reply]

Can't even do that, apparently... Ignatzmice•talk 23:09, 1 June 2013 (UTC)[reply]

I also felt that this part of the discussion was very enlightening. It basically says, that the WMF development team made some decisions regarding Flow already knowing it will upset the community, but doesn't care because it thinks those changes are "better for the future of Wikipedia". Everything should simplify the experience for new users, regardless of usability or accustomed ways of doing things, that were accomplished long ago and work perfectly well. --Patrick87 (talk) 23:35, 1 June 2013 (UTC)[reply]

I think "Flow" (see m:Euphemisms) has the potential to be good. However, as I've stated before, the Foundation appears to be doing a lot of work to reshape Wikipedia into something... different. Killiondude (talk) 23:55, 1 June 2013 (UTC)[reply]

(edit conflict) Apparently, Flow will make it impossible to use templates to warn users. This is getting ridiculous.--Gilderien Chat|List of good deeds 23:58, 1 June 2013 (UTC)[reply]

Not to mention WikiProject Banners, the Edit protected template, Article history and a wide variety of others. Like I said in the discussion on Mediawiki. If Flow can't use templates, they may as well stop developing it and move the resources somewhere else. Too much of our system relies on the use of templates, so if they have eliminated the use of templates on talk pages, they just broke Wikipedia. Kumioko (talk) 23:59, 1 June 2013 (UTC)[reply]

The noindex template is important - at least to me. If it can't be used, I hope they consider keeping talk pages from being indexed by default. Victoria (talk) 00:34, 2 June 2013 (UTC)[reply]

I agree wholeheartedly--Kumioko, you've hit the nail on the head here. Theopolisme (talk) 00:10, 2 June 2013 (UTC)[reply]

Wait. So tools like Twinkle and Huggle would stop working? Seriously? --NeilN ^{talk to me} 00:15, 2 June 2013 (UTC)[reply]

Yep, deader than a doornail. In fact a lot of work would need to be done to AWB and a lot of bots as well. Kumioko (talk) 00:17, 2 June 2013 (UTC)[reply]

Well, eventually, I think they will be "replaced" with something called workflow. But in the meantime, usertalk pages will be devoid of custom signatures, templates, and other complicated syntax. Instead of just, I don't know, hiding the syntax, they're prohibiting it.--Gilderien Chat|List of good deeds 00:19, 2 June 2013 (UTC)[reply]

From Wikipedia:Flow/FAQ#How_will_Flow_handle_spam_and_vandalism.3F: "[FIXME]" *headdesk* Theopolisme (talk) 00:27, 2 June 2013 (UTC)[reply]

Cool. So we get a lot of newbies, using the "easier" system to proclaim "I waz here!", while editors who already volunteer their time throw up their hands in frustration and wonder why the Foundation is obsessed with rolling out "Facebook UI" widgets at all costs. --NeilN ^{talk to me} 00:28, 2 June 2013 (UTC)[reply]

As usual, when people who are not active wikimedians design features, they have no clue what is actually required. If this design decision stays in, it obviously cannot be deployed anywhere on Wikimedia, so it would be nice if the WMF would employ their resources to do something actually useful. Snowolf ^{How can I help?} 00:12, 2 June 2013 (UTC)[reply]

Well, it will be deployed on every user talk page. That's already a fixed plan by WMF at this point in time... --Patrick87 (talk) 00:17, 2 June 2013 (UTC)[reply]

If they deploy something (Flow or anything else) that affects the flow of talk pages, they need to do it to all talk pages. Not just users. Otherwise we would now need to learn 2 separate systems for discussions. One for one group of pages and 1 or more for others. That would be about the dumbest way to "Make discussions easier" that I have ever heard. Kumioko (talk) 00:21, 2 June 2013 (UTC)[reply]

Talk about "editor retention"...seems like now everything's just about getting the new ones. It's all or nothing for the WMF... :/ Theopolisme (talk) 00:20, 2 June 2013 (UTC)[reply]

The WMF has made it clear time and time again that editor retention is not a concern of them. Their only concern is to attract new editors, especially ones who seem to be more interested in facebook and shiny graphics than building an encyclopedia. I don't know why you're surprised, it's hardly news. Replying to Patrick, yes, I know it will be deployed regardless of whether it is or isn't fit for purpose. No news there either.Snowolf ^{How can I help?} 00:23, 2 June 2013 (UTC)[reply]

Surprised? No. But I feel like if I say it enough times, maybe someone will listen. Then again, what's he going to do... Theopolisme (talk) 00:25, 2 June 2013 (UTC)[reply]

Well, if the community revolted, with Jimbo, 3 community seats and 2 chapter seat, we would have a majority on the WMF board ... --Gilderien Chat|List of good deeds 00:30, 2 June 2013 (UTC)[reply]

(edit conflict) I wonder how MediaWiki changes are implemented on enwiki, and if there's a way to pause/stop/revert them...

Ignatzmice•talk 00:26, 2 June 2013 (UTC)[reply]

We'd have to fork it or something. Which now doesn't seem like too crappy an idea...well, okay, it's a terrible idea, and we'd lose most of our editors, but it could keep running on MediaWiki 1.20.6 ad inifinitum. ;) Theopolisme (talk) 00:30, 2 June 2013 (UTC)[reply]

Well a lot of people have been trying to get rid of me. Implementing Flow just might do it. Kumioko (talk) 00:28, 2 June 2013 (UTC)[reply]

Admins can change the interface pretty freely; when Wikia implemented their new skin a load of administrators managed to remove it .... of course, they were all desysopped when they tried to fork.--Gilderien Chat|List of good deeds 00:34, 2 June 2013 (UTC)[reply]

That's just a skin, though. Not the underpinnings of MediaWiki itself. Ignatzmice•talk 00:35, 2 June 2013 (UTC)[reply]

Flow is a mediawiki extension, which means it is installed on the server-side. So we'd need a rogue WMF employee or something. Theopolisme (talk) 00:37, 2 June 2013 (UTC)[reply]

There would be a way round it. But (and I would probably do this) this would increase the divide between new and established editors even further.--Gilderien Chat|List of good deeds 00:39, 2 June 2013 (UTC)[reply]

If it came to that, I honestly would advocate a fork. Theopolisme (talk) 00:43, 2 June 2013 (UTC)[reply]

I can't remember where I read it, but I thought something said that Wikipedia was successful in its early days for being simple and not trying to use advanced and complicated technology. Things like Flow and Visual Editor seem to be complicated ways to reinvent the wheel, but only a partial implementation of what we currently have (like all wheels are now semicircles). As an example, this FAQ about Flow says that "A singular package will not and cannot cover these cases. So we have to build our own." But there is a singular package: the thing we currently have.
Also, it is important to gain new users, but alienating the existing editor base is suicide. Retention is as important as attracting newbies. Also, if someone can't overcome the minor barriers that may or may not exist in the current interface, are they someone capable of crafting this encyclopedia? Also, from what I see, these new "features" make some things easier but erect artificial barriers preventing many others.Chris857 (talk) 00:47, 2 June 2013 (UTC)[reply]

I'm glad I Like to because I seem to have opened up a can of worms... I would love to see some WMF response here... Perhaps we are all "just missing something", but I fear we are not... I'm starting to Dislike Flow more and more, and it hasn't even been written yet... Technical 13 (talk) 00:49, 2 June 2013 (UTC)[reply]

Maybe you should try out the interactive prototype? :) --Gilderien Chat|List of good deeds 00:53, 2 June 2013 (UTC)[reply]

I was already going to avoid Flow at all costs. That some users, including myself, "will not be able to edit or add comments" is what ruined it for me. From the above, it seems many others will also be avoiding it, and for good reason.

The WMF is determined to push through changes unfit for purpose regardless of what we say, so we must consider how to workaround such changes when they arrive. Once Flow is required for talk pages, I thought to move my talk page to User:PartTimeGnome/Talk to take it out of talkspace. The scratchspace idea mentioned above is also good. Unfortunately, both ideas would mean losing talk page notifications, though I could ask users to mention me each time they post.

I hope it goes without saying that resisting the organisation controlling the servers is a bad position to be in. Since we can't work with the changes the WMF is forcing through, the WMF needs to change. There is an opportunity for this very soon: the Wikimedia Foundation elections start on 8 June (next week). Use your vote wisely! – PartTimeGnome (talk | contribs) 02:15, 2 June 2013 (UTC)[reply]

Amen. Here is what I think: If Flow is going to cause this much trouble, it is not worth whatever improvements it may bring. AutomaticStrikeout ? 02:52, 2 June 2013 (UTC)[reply]

Before this discussion goes any further, I just want to point out that a lot of what is being said about Flow is nothing but rumour or misinterpretation. It seems that the WMF is asking for community feedback before they develop the tool (as opposed to what happened with, say, AFT), which is something we as a community should welcome. But just grumbling about the supposed "features" of the tool here isn't a very productive use of time. If you are concerned that Flow will not allow the use of templates in discussions, then go and have a friendly chat to the developers, see what their side of the story is, and then explain how you disagree with them. Simple as that. — This, that and the other (talk) 03:48, 2 June 2013 (UTC)[reply]

I may be reading this wrong, but from the discussions linked above it seems Technical already had that conversation, and Jorm said "Nuh-uh." But if they do decide to change that, wonderful. And I might be wrong. Ignatzmice•talk 04:00, 2 June 2013 (UTC)[reply]

Let's be clear here; we're at the discussion stage. The team actively working on Flow consists of Brandon, who is actively talking through things. Now: yes, we may lose templates. The intention is not to lose anything by losing templates. What I mean by that is that, largely, templates aren't the end-goal, they're the method; the goal is being able to signify that a user needs help, or is blocked, or...etc, etc. These are things that can be implemented in other ways. Nobody at the WMF end wants to lose the underlying functionality that makes templates useful. Okeyes (WMF) (talk) 04:05, 2 June 2013 (UTC)[reply]

I'm in the process of writing a response. Today is a non-work day for Foundation folk; I was down in Santa Cruz.--Jorm (WMF) (talk) 04:06, 2 June 2013 (UTC)[reply]

- @Okeyes So are you saying Flow will not be implemented before acceptable alternatives for Twinkle, Huggle, Cluebot, etc are rolled out? --NeilN ^{talk to me} 04:09, 2 June 2013 (UTC)[reply]

Don't panic. Right now, Brandon (Jorm) is actively floating ideas on how Flow could work, including potential alternatives to existing workflows. Nothing has been implemented or set in stone yet, and now is a good time for ideas to be tested, kicked around, prototyped and, in some cases, shot down. The whole point of having this discussion early (with only an interactive prototype in existence) is so that issues can be surfaced early in the development. That's a good thing. Give Brandon a chance to respond in a bit more detail, and then we can see if we can come up with an approach that addresses key concerns.--Eloquence * 04:46, 2 June 2013 (UTC)[reply]

Response from Jorm

Well, hasn't this been fun! I'm just going to comment on everything here, in a subsection, because REASONS.

Here's your bullet points:

Yes, you can still warn users.
Yes, we've made implementation decisions already, based on back-end constraints.
Yes, bots, twinkle, huggle, awb will continue to work. Anyone who says otherwise has been Caught Not Reading.
Yes, you'll still be able to add templates to page boards (though we're not going into Article talk pages yet). There will be a "non-structured" area on every page. Existing templates will likely migrate but again: that's not where we're at right now.
Yes, we're thinking seriously about restricting the ability of allowing anyone to edit other people's comments willy-nilly. This is a complicated topic and we're thinking through several options.

Okay. To the meat.

I wish this discussion would actually have taken place in the multiple places provided for it, and I wish that it had been started on a work day, and I wish that it hadn't had several hours to cook and cycle upon itself without a response from me because it's a Saturday and I was at a cook out with my in-laws. I also wish that there were more assumptions of good faith and trust.

In fact, I think I'm gonna talk about that for a second. Friday was the third year anniversary of my employment at the Foundation. That's a really long time in Silicon Valley years and it's more than enough time, I think, that we should drop the whole schtick about "Foundation designers don't know the community" and "they're trying to turn it into Facebook" and "you don't listen to us" and all the other jazz. I think you'd be disturbed at how well we understand the processes used by the various wikis and I think you might be saddened if you understood how hamstrung we are in making your life better because the complexity of the process is hypnotic. Ask people whether or not Special:NewPagesFeed isn't an improvement and then ask me how many hours were spent studying how page patrollers work and interviewing patrollers and basically absorbing everything about it. Was the final product exactly what any one patroller wanted? Probably not, but it was closer to what they needed.

If you think - even for a moment - that there are not people who are thinking about and discussing every one of the problems or issues that have been brought up above, you're wrong. And if you think that we're working in Bad Faith, there's nothing I or any of us can do for you.

The only thing I can ask you for is your input. I think we've been pretty damned good about trying to communicate and ask for input.

Okay.

Let's start with templates, which I think is what everyone is really freaking out about when it's boiled down.

First, no one has said, ever, "well, we're doing this, and screw you and your processes, you're just out of luck." In fact, we've been pretty solid about saying "we're going to help you in any way you can". In fact, "buried" in the global navigation on every Flow portal is a page describing a "Workflow Description Language". We're planning to give you something to replace your templated workflows and make them better and easier.

Second, no one has said, "well, bots and Twinkle and Huggle and AWB people are screwed." No, they aren't, and I'm frankly finding it hard to jump to that conclusion. How will Twinkle work? Simple: we grab the hook off "create section," take the template that it wants to drop, parse it into html, make sure the Parsoid understands it, and create a new Flow Topic with the html as the post text. That's it! And even better: the conversation is now managed.

Ah, but what if - what if - what if we could make warning a user a real, true workflow? What if, instead of a spray-and-pray template, we can initiate a workflow that actually tracks how many warnings a user has, makes sure the user has seen and acknowledged them, and then also provides them with interactive tools to learn about what they did wrong? Wouldn't that be neat?

Let's now tackle the "devs are making decisions without us" line of thought.

Spoiler: Of course we are. Absolutely we are. You, as a community, cannot individually be expected to understand how our software back end works. Nor can you be expected to understand how to program. Or have studied human interface design, or even know anything about computers at all. I'm not saying that some of you don't: I know many members of the community do.

I am saying that it is our job to know about all of those things. What this means is that we sit and look at our design constraints and look at what our goals are and how the system (e.g., community processes) works, and how the system will be impacted, and so forth. We read tea leaves and we think about The Future - not just as it relates to enwiki, but to all wikis.

Here's the future and I don't think it's a surprise to anyone: The VisualEditor.

That adds a massive constraint to whatever design we come up with. Whatever content gets entered into Flow must be readable, parsable, and editable within the VisualEditor. It is simply a non-starter otherwise.

Currently, the VisualEditor (and Parsoid, which is our real constraint) does not handle templates very well - at least not well enough that we can (at this time) state for a fact that all templates can be parsed by it. The fine developers working the VE are hustling to get these things working but the timeline isn't "next week". Ergo, we can't depend on it, so we have to treat it as a design constraint.

That brings me to the next constraint: scalability and the Parsoid. I walked through the issues with this before and it's a lot of text so I won't repeat it here. The gist is "running every post through the parser on load is not scalable". It's just not possible to do.

We're also not going to be storing the data for Flow posts in the local wikis. The database structure doesn't allow for it (they're built for horizontal scale, not vertical, and Flow requires vertical scaling). That means all Flow posts get saved to a different database system (another constraint).

(There's an interesting side-effect to that, but I'll leave it as an exercise to the reader to figure it out. For now.)

Let's walk back from the ledge, people. This is all good stuff. I'm not going to lie to you: it's going to be change, and it's going to hurt for a bit, but we'll all get through it.

It might be a fun exercise to sit and think about how many things we can fix with Flow, rather than how many things are going to change.

This was long. It's Saturday night. I'm going to spend what remains of it with my wife. I'll try to be available to answer questions tomorrow (Sunday). I'd prefer it if these questions were left at mw:Flow Portal, so they're centralized, but I'll talk here as well.--Jorm (WMF) (talk) 04:52, 2 June 2013 (UTC)[reply]

Thanks for the detailed explanation Jorm. I understand this discussion may have seemed somewhat premature and bad faith but given the recent changes that have been coming out that were, arguably, not helpful, I hope you can understand our concern and reluctance at the potential that this would eliminate the ability of using templates.

Enjoy the rest of your weekend. I have been married a couple times, you have to do the same thing to keep them as you did to get them, it took me a while to figure that out. :-)Kumioko (talk) 05:02, 2 June 2013 (UTC)[reply]

Jorm, my thanks as well. Enjoy your night-- Theopolisme (talk) 05:10, 2 June 2013 (UTC)[reply]

Thank you for your response. May I suggest putting some of it in here? --NeilN ^{talk to me} 05:56, 2 June 2013 (UTC)[reply]

About the exercise to the reader: should we take it as a hint that 'local wikis' is plural while 'different database system' is singular? — HHHIPPO 10:19, 2 June 2013 (UTC)[reply]

Thank you for your response, just one thing though - "Anyone who says otherwise has been Caught Not Reading." ... I have read as much as I can find and I haven't found this said anywhere; Huggle especially relies entirely on templates so presumably it would have to be re-written.--Gilderien Chat|List of good deeds 11:05, 2 June 2013 (UTC)[reply]

WP:FLOW was created too early since the pages describing Flow have insufficient explanation of how common talk page actions would occur. Of course there can be no detail at this stage, but there should be a 20,000 foot overview of fundamental issues like whether Flow will handle standard warnings, and how abusive posts (or spam or trolling) can be removed (hint: asking an admin is not acceptable). The other issues mentioned at WT:Flow should also be addressed. Johnuniq (talk) 11:26, 2 June 2013 (UTC)[reply]

Jorm (WMF), thank you for you taking the time to respond here. Being the one that has opened this discussion here (and a discussion elsewhere questioning the Borgification of signatures (which I'm not saying is entirely bad)), I want you guys to know that I really am assuming good faith on your (the Foundation's) part (I've even gone out of my way to try and stick up for you in some of these threads like here). I'm far from opposed to change. As you know, I've been following this discussion on the MediaWiki liquid threads and I've been following as much of it as I can find on Bugzilla (I'm on the mailing lists as well), and trying to ask important questions and understand it in both places and addressing concerns. I just wanted to make sure that everyone was aware of some of these things and had a chance to offer some more input to the process. No, I'm not saying they don't have the same ability as myself or anyone else to go to MediaWiki and follow all of it like I have, simply that some may not have the kind of time required to read all of the messages if follow it at all or are simply unaware that it exists there. The template thing is a huge concern of mine (and apparently others) because there are so many tools that rely on them from Twinkle, Huggle, Snuggle, AWB (less so because it isn't as often used on talk pages) and critical processes such as warnings, help/edit requests, teahouse invitations, wikiproject banners, afc/dyk/fa/deletion/block notifications, etc... I would love to help in anyway I can to create alternatives or make these functional within Flow before Flow is rolled out... So, do you think that WMF and the community can work together on this instead of the foundation just saying "hey, we researched everything and we know how your systems work better than you do and this is what we devised based on that..."? Technical 13 (talk) 12:12, 2 June 2013 (UTC)[reply]

@Jorm I think there are a lot of flaws with your statements above and with your assumptions in the article about the Athena project linked below. I do think your intentions are pure so I don't want anyone saying I am not assuming good faith but here are a few of my concern which I had last night but saved posting them to let you enjoy your night:

First, not posting on a weekend because you don't work on weekends shows a huge lack of understanding about the dynamic and global nature of how the community works. Or a lock of caring. Either way its not a great thing. The community edits 24 hours a day 7 days a week. We should not need to save our comments and concerns for a WMF work day because the primary developer doesn't edit here off work hours.
Next the comments about posting at the MW site is pretty much silly and again shows a fundamental lack of understanding about how the community works. The vast majority of the community never edits there and wouldn't even know the discussion was there until it was too late. Even on this page there is a limited number of people who comment and most of those are admins and technical folks. If you want to ensure that few comments are made and make the point later that no one commented so everything must be fine, then hiding the discussions in MediaWiki is a good way to do just that.
The technical aspect of the site is much more of a minor problem than the uncivil and toxic nature of how newby's are treated. I agree its a little dated and it could stand some updating but we aren't Facebook and the people who edit here are doing so for different reasons than Facebook or social media so using the mentality that Facebook spent a lot of time and money developing it so it must be good for us as well is fundamentally flawed.
The vast majority don't leave because they have trouble learning how to edit. They leave because the community treats them like crap if they aren't born with the knowledge of our rules and some block happy admin blocks them the first time they don't sign their posts or some other stupid thing. If you want to keep editors, work on culture toxicity, not on implementing a secondary talk page discussion system so they have to learn 2 and eliminate make it so we cannot use templates.
Another big reason we are losing editors is that they aren't leaving, we are diluting our pool of editors with new projects as the come online. With every new project we add (Wikidata, Wikivoyage, Wiktionary, etc.) we lose some editors to this new project. I don't want to sound like these projects are a bad thing because they aren't and that's not what I mean to imply. But it does spread us thinner so our resources don't go as far as far as human capital goes.
You state that no one has said "well, we're doing this, and screw you and your processes, you're just out of luck." Really, isn't that almost exactly what they have said in multiple occasions in the past, including the elimination of the Orange Bar of Doom? Because I distinctly remember at least 2 comments from WMF folks implying exactly that.
You also stated "well, bots and Twinkle and Huggle and AWB people are screwed.". Of course there will be a way to work around the problem but these things will need to have some modifications made to them if this goes through. That modification might need to include just not updating whatever page Flow is displayed on. So although you are correct that no one said they/we are screwed, no one made it clear in any instructions before now that these would not be affected. Additionally, although several of these applications were designed by or supported by people who work at the WMF, none of these applications are actively "supported" by the WMF. So I could easily see the attitude of well we don't support it so its not our problem if it breaks. And it wouldn't be the first time the WMF had this attitude by the way.
There are a lot of improvements that Visual editor will bring I agree but it still has a ways to go. Even when it is released, its likely that we will still need an advanced editor in the form of what we have as the current edit capability.

In summary I'm glad you took the time to post and I very much appreciate that as well as other community members do. But the general tone of your post is that of a general lack of empathy and frankly indicates exactly the problem with the "well, we're doing this, and screw you and your processes, you're just out of luck." comment you made above. Kumioko (talk) 13:58, 2 June 2013 (UTC)[reply]

Wow. That's...certainly something. Let me go through, but by bit.

I don't think it demonstrates a lack of understanding about the community; do you think after three years of heavily engaging with the community, Brandon was ignorant of the fact that we're a global, volunteer-based movement, and that editors can post at any time, from any place? As someone who has worked with him very closely for 2 of those 3 years, Brandon gets it to a degree most staffers don't - to a degree that some community-sourced staffers don't. He wasn't saying he was ignorant of this community trope; he was saying that, weirdly, staffers sometimes need to take time off. As someone who has done the whole work-90-hours-a-week-every-week-for-a-year schtick, I've started trying to take weekends for myself, too (as this demonstrates, I'm not very good at it). I don't think people get the long hours that staffers work, here. It's not Brandon not understanding the community, it's Brandon understanding that working 120 hour weeks would drive him insane. I have absolutely no desire to wander into the office and find him, mind broken, wandering pantsless around the 6th floor chainsmoking Marlboro Lights and singing 'I Will Survive' over and over again. I doubt anyone else wants that mental image either. If you truly think staffers should be active whenever editors are active then you're asking for the WMF to be run by ELIZA, because that's the only way we can keep up.
Nobody has told you to post on MW.org. Please point me to the bit of Brandon's post where he mentioned MW.org as a venue. We are not ignorant of the difficulties around it; if you look at the engagement strategy I wrote for Page Curation, a project Brandon worked heavily on, you'll see it specifically called out as a problem. What Brandon meant is that there are several other perfectly good venues for this kind of discussion, one of which is right here on enwiki.
Citation needed for your third statement? I'll agree that a big chunk of people who register in the data as 'editors who leave' leave because of community toxicity. This is nothing to do with the relative difficulty of overcoming toxicity versus overcoming technology, it's to do with poor science; by definition, everyone who edits and then leaves can handle editing. When we look at surveys of ex-contributors or that sort of data, or just anecdotes, of course we're going to be biased towards people who grok markup and leave for other reasons. People who don't grok markup can't participate in the observations.
No comment on diluting the pool, really, except to say that we're talking about Wikimedia-wide data on editor decline, not enwiki-specific data. We're not losing them, as you note.
We're not talking about the orange bar of death, or any of the other occasions. We're talking about Flow, let's be clear. You may as well tar the development process with the IEP brush, if the approach that you're taking is one where prior actions are complete predictors of future actions taken by a different set of people.
Sure, they'll need some modifications. We know this; I spent about 40 hours writing up use cases for everything we'd need to support in the existing talkpages - not just twinkle or huggle, but the underlying mechanisms, like having a good external API for Flow and making sure that we reach out to the volunteer developer community and provide clear instructions and help with such things.

In summary, I don't see Brandon's post as indicating a lack of empathy; honestly, if he didn't appreciate the feelings the community had do you think we'd be having this conversation, let alone making plans to ensure things like Twinkle support work? If he didn't care - if we didn't care - here's what would happen. We'd keep all the documentation on MediaWiki.org, we'd have built the software already around our utopian community workflows, we would've silently deployed it, and, absent bugzilla reports, not given a brass farthing what anyone said. That's quite clearly not what we've done. I'm sat here at 6pm on a Sunday evening writing out a ludicrously long counter-counter-argument to follow your counter-argument to another staffer's argument because We want to keep people informed about and involved in the process. And that counter-argument I'm responding to is, depressingly, one that alternately argues our culture is toxic and states basically that "well you should be contributing whenever an editor contributes, then. Any alternative just means you don't care about us". I'm disappointed by the cognitive dissonance I'm seeing here.

As I've offered before, Kumioko (and I hope you'll take the offer up, this time); if you want to discuss the factors at play here, or Flow generally, I'm certainly willing to free up an hour for a skype call or a google hangout. The same goes for any other editor who wants to talk through...well, whatever they want, really. Okeyes (WMF) (talk) 16:53, 2 June 2013 (UTC)[reply]

KumiokoCleanStart, I think that while most of your statements are how you personally feel towards the WMF team and may be written based upon good intent, they are mostly unfounded and most of them are completely unfair in my opinion. There really is a big gap in the communications between them and us, and I agree that needs to be addressed. I view a large part of your comment as flaming and bashing of the WMF team and I commend them for their efforts to bite their tongues as well as they have been. Finally, I would really appreciate it if you would do something about your username, I find it disruptive and counter productive... I am barely aware of whatever you had to go through before, but that being said, having the username of "KumiokoCleanStart" and not actually changing your ways implies to me that you really do not wish to have a clean start. Anyways... That is between you and the admins, I just wish you would stop being so disruptive and every comment being to complain or mock or flame someone else. I implore you to look in the mirror and ask yourself how you can improve yourself. Now, since I expect something of a "With all due respect Technical 13" response from you for this comment, I would like to make sure that you know ahead of time, it would be a waste of time... Technical 13 (talk) 17:45, 2 June 2013 (UTC)[reply]

Actually I have met Brandon (although I'm certain he couldn't pick me out in a crowd) and quite a few of the other folks at the WMF and harbor no hard feelings or ill will towards any of them. I found most of them to be very collegial and personable. I also think that some of my statements above are being taken out of context which doesn't really surprise me much either. Clearly I must be the only one who has issue with the comments from Brandon above. I have no doubt that he and the WMF folks mean well but frankly, given the changes that have occurred lately, I wanted to make sure my comments were out there. If they choose to listen and consider my comments or ignore them or if you and others think I am a nut, that's fine. Just remember this discussion a few months from now when Flow comes out because I have enough experience in the IT field as a project manager to see the writing on the wall. So since the comments seem to indicate my input is not wanted or needed I am going to move on and go back to editing. Let them release Flow, break all the templates and cause problems for the admins. Not my problem anymore. I have voiced my concerns and said my piece. There is nothing more I can do since its clear that nothing I say is going to be taken seriously anyway, I'm just wasting my time. Which is IMO not a unique issue with me and a byproduct of the culture here in the project. I'm not an admin nor a member of the WMF so as just an editor, and not a particularly popular one at that, my opinions are of little interest or impact. The reason I keep bringing up the bit about the culture is, strangely, I don't see anything being done about it. Lots of talk about Facebook like pages and making it easier to edit, but the only comments about the culture are directed at me and how your tired of me bringing it up. If your tired of hearing it, then do something about it rather than kick the can down the road. I analyze things, that's what I do and I often offer suggestions to fix it. But I can't make the changes. Hell I can't do a lot of things around here to help out that I would if I could. Because we are more worried about keeping the power in the hands of a few, than enabling editors to edit and buildup the site. That is the problem with our culture. We are driving the editors off with our actions. Not because they can't figure out editing. If you want to retain editors. Look at fixing those issues first. Otherwise your just putting makeup on a pig! No matter how pretty and easy you make the site, if people are still being shitty to one another, they ain't gonna stay because it looks like Facebook.
As for my username this is hardly the place but since you brought it up I'll explain it again. I tried to create a new one and was blocked for socking from an overzealous admin. Then I edited as an IP and once again I had editors crying that I was socking. So I recreated this username and yes I am poking some fun at a lousy policy (clean start) because it doesn't work. Our other policies and culture prevent if from working. If you have to link your old account name to your new one its not a clean start. Frankly if I knew what I now know that I wouldn't be allowed to edit as an IP or create a new name I would have kept the old one with the vast majority of my edits and edit history. But its too late to change it back so now were all stuck with this one. Happy editing and there's no bother replaying to my comments. I'm not going to get involved in the discussion anymore. You all can talk about how wonderful Flow is going to be without my interventions. Kumioko (talk) 22:33, 2 June 2013 (UTC)[reply]

Kumioko, nobody said we didn't want to hear your issues. We said we didn't want to hear complaints about how Brandon doesn't care because he doesn't work 24 hours a day, 7 days a week. There are some very good reasons why the WMF does not get involved in cultural change, and again, for the third time, I am happy to talk to you in more detail about this issue and/or any other. I hope that this time you might either take me up on my offer or at least offer a response. Okeyes (WMF) (talk) 23:20, 2 June 2013 (UTC)[reply]

Okeyes, No one expects Brandon or anyone else to work 24/7/365 and that is not what I meant. What I was referring to was Brandons comment at the start of his post'I wish this discussion would actually have taken place in the multiple places provided for it, and I wish that it had been started on a work day, and I wish that it hadn't had several hours to cook and cycle upon itself without a response from me because it's a Saturday and I was at a cook out with my in-laws. I also wish that there were more assumptions of good faith and trust.'

As I said above, few of us watch the other places so there should be little surprise that no one is commenting there. There is no reason for this to Start or happen on a WMF work day, disussions often cook here and fester and boil. If the WMF is not keeping the members of the community in the loop, things will get blown out of proportion because the WMF isn't relaying that information. If you write a 3 sentance description about Flow and in it say things like Signatures and templates won't work with no explanation of why or how that will be worked around, don't get mad at me or others because we call you out on it. This is an opportunity for growth and development for all of us. We can take everything offensively or take the comments in these discussions as an opportunity for improvement. Lastly certainly I think everyone understands that Brandon and anyone else should get to spend time with their family. No one and certainly not me would have though the less of him if he would have left a comment saying I will comment in detail on Monday I am spending time with the family. I'm glad he left the detailed comment and I am sure he was frustrated at the situation as are we all. But many of his comments raised more conerns and I commnted on them. I got to where I am in my real life because I don't suger coat things and I don't generally hide behind politics. If I see something wrong I work to address fixing it. I am not shy, timid or calculating. I am blunt and often times in text only environments it comes off as abbrasive. Its not meant to be. It doesn't change the problem though. Flow, as advertised, is not an improvement for us here. It could be if the issues are addressed. But not in its current state. Kumioko (talk) 15:17, 3 June 2013 (UTC)[reply]

Per Kumiko's comment a long way above, the VisualEditor can never completely replace the source editor. The VisualEditor is good for convenience and for the less technical among us. However, there are various tasks that would be impossible with a WYSIWYG editor (editing parser functions, CSS, JS, Lua scripts, ...), and other tasks might be harder using WYSIWYG. Furthermore, the VisualEditor cannot work without JavaScript; the source editor provides a fallback for editors unable or unwilling to run scripts. Please do not consider the VisualEditor as the future; the future should be VisualEditor and the source editor. – PartTimeGnome (talk | contribs) 23:24, 2 June 2013 (UTC)[reply]

The VisualEditor always has had a source editor component planned; we're not going to be removing that for just those reasons. Okeyes (WMF) (talk) 23:31, 2 June 2013 (UTC)[reply]

That's basically the opposite of what Brandon told me before. According to him (at least regarding Flow) Wikitext will be abandoned completely and everything will be designed to work properly with VisualEditor. A source editor will only be made available for people without JavaScript enabled and will only offer a very limited set of function (even more limited than the VisualEditor. Can you explain this discrepancy in your statements? --Patrick87 (talk) 00:08, 3 June 2013 (UTC)[reply]

That's not the opposite of what I said. "Source Editor for articles" is not the same as "source editor for discussions". You don't need to edit CSS or Lua scripts to respond to someone in a thread. Ergo, it's not going to be there.--Jorm (WMF) (talk) 00:29, 3 June 2013 (UTC)[reply]

It is impossible to implement the VisualEditor without JavaScript. Therefore the source editor is needed as a fallback for non-JS users. Participating in discussions is core functionality, so it must function without JavaScript. There's nothing wrong with non-JS users having a degraded experience (i.e. no WYSIWYG editing), but they must be able to post in discussions somehow. (Also, because you don't understand the need for something is not an argument to remove it, unless it causes some other problem. Things should be easier for both developers and users if the editor behaviour is broadly similar regardless of where it is used. It should mean fewer code paths to test, and less user confusion due to differences in the available functions.) – PartTimeGnome (talk | contribs) 01:02, 3 June 2013 (UTC)[reply]

OK, I see. So basically the idea is to have all (?) functionality of the current WikiEditor in a future VisualEditor source editing component, but deactivate these functionalities selectively at places where they are not needed? So in the "unstructured" board section everything (?) that is currently possible will be possible in Flow, too, but in comments on the threads only basic text formatting will be offered? --Patrick87 (talk) 01:05, 3 June 2013 (UTC)[reply]

P.S. I've used CSS in talk page comments a few times. I often participate in technical discussions about CSS, and it is useful to be able to show how a given piece of styling will appear. Your assumption that CSS is not used in discussions is incorrect. – PartTimeGnome (talk | contribs) 01:41, 3 June 2013 (UTC)[reply]

I am satisfied with your response, Jorm. It was thoughtful and now that you have given it these concerns I have are fully addressed. Unrelated to the stated problem, it seems that both WMF developers and the WM community are dissatisfied with the communication channels between each other. The existing communication resources - for whatever reason - are not meeting my needs, and other people may feel the same way that I do. This problem may or may not be able to be solved, but if it is not solved then I would expect it to continue. Blue Rasberry (talk) 14:29, 2 June 2013 (UTC)[reply]

I've been thinking about this recently, so this is addressed to the problem you raise (not to you directly) ...

There are 2 aspects to the communication channels problems: Quantity, and Location. (This goes for any example, from ARB/ANI decisions, or MoS changes, to site-code changes.)

Quantity of items: Some people want to know about all the hundreds of plans/changes/decisions. Most people only want to know "What's going to effect me?"
Quantity per item: Some people want ALL the details, and will be upset if core aspects aren't mentioned. Some people just want a brief synopsis in clear non-technical English. Some people want terse bullet-point summaries.
Location: There are a large number of locations that people expect/want/wish their news to be browsable. Some people want it all in one spot and only one spot. Some people want each communication placed in a topic-appropriate location and then mentioned in numerous other places (often leading to fragmented conversations at each external "pointer" eg this one which started as a pointer to Mediawiki). Some people want mass-duplication of anything relevant, pasted to everywhere potentially relevant (eg the 3 Flow portals at mediawiki/meta/here).

Add to which: Some people are reluctant to leave their "home" wiki, for a variety of reasons.

On En.Wp alone, we have all of these: WP:Dashboard and Template:Noticeboard links (compendiums), WP:Wikipedia Signpost, WP:CBB, Site notices, watchlist notices, WP:Update, etc

Then the meta/foundation/mediawiki wikis, and their various structured locations for centralized or separated discussion. Plus all the other languages, and all the sister projects in each language.

Plus all the official blogs, unofficial/personal blogs, IRC, and the voluminous mailing lists.

E.g. If we added all the discussions from http://lists.wikimedia.org/pipermail/wikitech-l/ into this WP:VPT, it would be overwhelming. But that's essentially what some people want (I.e. A say in every matter, and every matter brought to their home-wiki, and every matter discussed in the place they feel is most appropriate).

Back to Flow: Based on mw:Flow Portal/Use cases, and a few other pages I've glanced through: the 1 person working on this, and the people assisting/advising/discussing it with him (i.e. Us, and all other wikimedians), might be aiming to partially improve this flawed situation, with Flow itself (as well as dozens of other primary goals). The only way we'll know if it's an improvement, is if something gets built, and tested. So we have 3 options: (1) Provide feedback/bugreports/code/suggestions to improve whatever Flow turns into, or (2) Invent our own superior solution (and build and test it), or (3) [insert negativity] as some did at the start of this thread.

Helping to build stuff is why we're here, so options 1 and 2 are the only ways forward. –Quiddity (talk) 03:14, 3 June 2013 (UTC)[reply]

General comment Concerning 'good faith' - I assume good faith on the part of the Jehovah's Witnesses or Mormons at my door (never at the same time, unfortunately - could be fun, that...). That doesn't mean that I agree with them in the slightest, or have any desire at all to convert to their faith. (I don't assume good faith on the part of the person trying to sell me a new driveway, or telling me that my roof needs urgent repairs.) Part of the trouble down here on the factory floor is that we rarely seem to see the names of the people perpetrating the changes down here in places like NPP, AfD, AfC and so on. They may have been here long ago, or we might have missed seeing them. I would repeat a comment I made somewhere in the OBOD altercations - progress is change, but change isn't always progress. I don't expect the designer of a new machine that makes veeblefetzers to spend months on the factory floor. I would hope that they know what a veeble is, how one fetzes with it, and to have some acquaintance with the working procedures and safety/comfort of the poor bugger that's going to operate the machine. All of which have more importance than do the scrolled handles, the Ionic supporting columns and the chromed dome over the hopper. Peridon (talk) 18:12, 2 June 2013 (UTC)[reply]
- This reminds me a tad of a great story a colleague recently told me. He was hired by this company to redesign their product language model. When he arrived he was witness to a ton of old technology and already smelled trouble. He then designed a new replacement language, that handled everything the old language did, and added a ton of new functionality in the language. It also included an editor, with autocompletion, syntax highlighting and validation, preview rendering etc. His first draft was reviewed. They loved it, but then came responses like: but how are we going to find the line number of this piece of block ? He answered line number? what would you need that for ? Well, we still need it to run on our 80x40 (column x lines) based storage system (small detail, why would you ever spec that... :D ). Turns out their entire storage reference system was based on their old display and interface formats (old Vax systems). He then gave them the only logical answer; if you want to keep using your 80x40 storage system, you better keep using what you have right now, there is nothing modern that will ever map on it. The real question is, why do you want to keep such a storage format, and not invest into replacing it, so that you can use this great new language that could make your products so much more flexible and your people so much more efficient ? The engineers protested loudly about all the systems that they would need to replace and all instability it would bring. My colleague concluded: there is nothing I can do for you, not a single language I design will help you any further.
  We shouldn't have the problem you describe, but we definitely don't want the problem I just described either. The balance has to be somewhere in between. The company in question is almost bankrupt now btw. In their industry, they were like Nokia and suddenly there was the iPhone. —TheDJ (talk • contribs) 19:00, 2 June 2013 (UTC)[reply]

Hi Jorm. I'd like to clarify a few things: you mention we will be able to use templates on Flow boards, and there will be a non-structured area on each page. Am I correct in my understanding that templates will only be allowed in the non-structured area, and not in regular posts?

You also mention that Flow will still be able to use templates from things like Twinkle (albeit internally expanded into HTML). Why can't the same approach be used for comments from editors? Will the ability to use templates in a discussion only be available using the API?

The expansion of templates into HTML effectively means every template would be subst'd. If this were allowed for editor comments, the automatic substitution might confuse editors who re-edit their comments and find they don't look the same, especially if a template has expanded into something lengthy and complex. This could be solved by storing the original wikitext alongside the expanded HTML; the edit page would show the original wikitext and generate new HTML upon saving.

In many of your comments you appear to say that Flow can replace the functionality of all existing templates. Though this might be true for templates that form part of various workflows (RFCs, warnings, edit requests, etc), what about other templates? Various convenience and formatting templates are frequently used in general discussion, such as {{code}}, {{diff}}, {{small}}, {{smiley}} and {{tracked}}. There's also {{tl}}, which I heavily used in the previous sentence. Another common use of templates is demonstration, either to demonstrate the use of a template, or to give an example of a proposed edit to an article (I'm assuming templates will still be allowed in articles). How will we do these things with Flow? – PartTimeGnome (talk | contribs) 23:03, 2 June 2013 (UTC)[reply]

Templates will be allowed in the non-structured area, yes. Or, at least, that's the current thinking. And no, not in the regular posts.

I'm simplifying what will happen significantly but yes, the principle aligns with "substing" everything that goes in. The reason this works for API edits and not "website" edits is that API edits do not (currently) run through anything that the VisualEditor deals with. If the only way for website edits to happen is through the VE, then only VE-pure code happens.

Now, I'm going to be honest: it's highly likely that many templates left by Twinkle and other applications will break. But, as we've done before with other projects, we will be working with the maintainers of those tools to make sure that things are seamless and will require little or no effort from the editor community to account for the changes.

This is not our first time at this rodeo. As it were.

And yes: technically, we will probably store a "wikitext" version of the page. But that version of the page should be considered "cold storage" and not accessible in the moment to moment use of the software (for the performance issues outlined above).

And regarding the templates you described above: roughly half of those templates either are (or should be) natively supported by the VisualEditor, though in other formats (like linking to diffs, or creating font size changes, or source code). Others (smiley) could be trivially implemented with an emoji generator, and the "tracked" template is an ideal candidate for conversion to a Flow workflow.

In other news, I'd still like it if these questions were moved to WP:FLOW.--Jorm (WMF) (talk) 00:38, 3 June 2013 (UTC)[reply]

Okay, the templates I mentioned are supported by VisualEditor. Can the same be said for the hundreds of other formatting/convenience templates used on talk pages? Templates allow regular editors to define new ways to format text that other editors can easily reuse. With VisualEditor, any new formatting options would need to be added by a developer.

Also, you didn't mention how templates or proposed article edits can be demonstrated in Flow. If I wanted to say "template foo will look like bar when used with parameters baz and qux", I would typically invoke the template in place of bar. How would I say this in Flow?

I think the main problem here is this fixation on the VisualEditor. The VisualEditor is a great idea and I support it, but it can never hope to do all the things we do in wikitext, not even on talk pages. As I read it, the main reason you are saying "no templates" is because the VisualEditor does not support it. Furthermore, its dependence on JavaScript means some editors cannot use it. Relying solely on the VisualEditor introduces too many constraints. We really do need the source editor as an option. – PartTimeGnome (talk | contribs) 01:34, 3 June 2013 (UTC)[reply]

As far as people are concerned about Twinkle, please don't be. Twinkle is actively maintained and can be updated to fit any software changes. It is foolish to try to design new software features around local gadgets, of all things. And, who knows, perhaps some aspects of Twinkle will end up being built into Flow itself? — This, that and the other (talk) 01:06, 3 June 2013 (UTC)[reply]

F.L.O.W. - Frustrating Lots Of Workers

Any radical change is likely to be trouble, but complete upheaval, of day-to-day operations, is guaranteed to be terrifying and demoralizing. Of course, if wp:Flow become unbearable, then people could always resort to using WP essay pages as talk-pages (essay "Talk of RMS Titanic"). Even the mere suggestion that templates used in wp:FLOW pages would be subst'ed to HTML is horrific. Perhaps the first horror would be a long template that generates extensive markup such as {{bg|#ccc|This}} which shows "This" but would insert "This" for every {bg} in a Flow page. Then there is also the pesky trouble of including a calculation adding 20 numbers and reducing the talk-text to only the final result, not easy to modify for adjusted numbers. However, the elephant in the room, for subst'ing templates in Flow pages would be the inability to upgrade system-wide style templates to, retroactively, back-apply the new style into older Flow pages. Templates are not just simple typesetting styles, but rather they are the way to quickly update the population counts of 2,700 towns/cities in Austria, by editing just 10 templates. And they are, also, the way to style wp:WikiProject banners, so all pages could show a similar style, even when enhanced to a new system-wide style in the future. In general, people must understand the concept of a macro scripting language and why the word "macro" is so critically important to easily reading and maintaining data in a word-processing system, and remember that talk-pages are in this same word-processing system. Talk-pages are NOT your grandfather's handheld keypad device to be read by millions of people. No instead, talk-pages are word-processing documents styled and formatted to convey a vast array of information, including data tables and graphical charts calculated by templates and Lua script modules. -Wikid77 (talk) 13:52, 4 June 2013 (UTC)[reply]

Can you stop fear mongering please ? I mean the world can seize to exist tomorrow, but we don't post 300 word essays about that on this page every day either. Still it would significantly impact our capabilities of working on the encyclopedia. —TheDJ (talk • contribs) 15:44, 4 June 2013 (UTC)[reply]

(edit conflict) (false conflict - no other edits)

I am not fear-mongering, and it's not like I said, "FLOW is the secret organization Freakazoid Lunatics Overtake Wikipedia" but I can sense your levels of frustration. I think it would be much more productive to fix the numerous problems with auto-merging of edit-conflicts, both for talk-page replies and for multiple insertions near the same lines in article texts. Some of that work could be called "FLOW" while using the current talk-pages, but with FLOW extensions. Even if the edit-conflicts are not fixed with a formal proof of correctness, yet some heuristic methods could be used to auto-correct most edit-conflicts. I have already noted the need for test-and-set logic, by read-locking the page each time a "new section" is appended, to avoid adding 2 conflicting endings to the same prior revision. Otherwise, wp:FLOW can sound like a scary delusion mistaken about how talk-pages are actually used. The reality is that many talk-pages contain portions of article text, with templates and footnotes, and some cases keep re-revising that text for later use in live articles. Also, people often say, "Edit this talk-page section to see markup" as in

E=mc^{2}

. If you haven't noticed the current fear levels about wp:FLOW, then try rereading those threads. -Wikid77 (talk) 04:38, 5 June 2013 (UTC)[reply]

To correct some of the above:

The expanded HTML won't be visible to users since Flow won't allow you to view or edit the source. Jorm is planning to only allow editing using a cut-down VisualEditor.
Regular users won't be able to use templates at all, so you won't be able to use {{bg}}. HTML expansion of templates only applies to posts by bots and scripts that use the MediaWiki API.
WikiProject banners won't be affected since they will be in the non-Flow "unstructured content" at the top of the page. This behaves like regular wiki pages.

We might end up with essay pages being used for talk (or similar). However, since we can't get rid of Flow, this means we'd have fragmented discussions. Some editors would comment using Flow whilst others would comment on essay pages, causing parallel discussions on the same topic. – PartTimeGnome (talk | contribs) 23:06, 4 June 2013 (UTC)[reply]

Well, it might be more correct to explain how wp:FLOW will not be able to function, realistically, if it worked according to plans suggested in May 2013. So instead, many WP discussions would likely bypass the FLOW-controlled portions of pages, to post talk-pages messages as before in other areas. -Wikid77 04:38, 5 June 2013 (UTC)[reply]

I asked Jorm on IRC and he said that he's not dead-set on disallowing templates – it's just that Flow is going to support whatever VE supports, and it currently doesn't support inserting or modifying templates. But – and this is my own judgment now – it seems to me that the template support will reach useful levels before Flow is anywhere near being fully implemented, so I wouldn't worry about this part too much. Matma Rex talk 19:13, 5 June 2013 (UTC)[reply]

And Brandon achieved what he intended: No one worries anymore up to the day FLOW is due and editors recognize I didn't work as expected. Sorry, Matma Rex, but Brandon mentioned often enough that templates and the like will be most likely gone. I don't believe such excuses that easy. --Patrick87 (talk) 19:53, 5 June 2013 (UTC)[reply]

But is he still planning to disable the source editor for discussion pages? Given that I can't use VisualEditor, that's a bit of a big one for me... – PartTimeGnome (talk | contribs) 20:39, 5 June 2013 (UTC)[reply]

Two problems concerning edit conflicts

Hi all,

besides edit conflicts being always annoying there are two things that bug me most:

When editing a single section of a project page (like this one, with many subsections and mucht text), after an edit conflict I'm confronted with the Wikitext of the whole page. When I edited somewhere in the middle of the page this makes it nearly impossible to locate my own changes in the second edit window and it's as painful to locate the correct section in the first edit window.
Even worse: I have set my preferences to show the "View templates on this page" list below the edit window. In the case of an edit conflict this list is located below the first edit window (therefore between the two edit windows). As it happens that this list grows very long (e.g. on this page) and since it remembers it's state (collapsed or uncollapsed) sometimes I also have to scroll very far to even reach the second edit window, making comparisons impossible (yes, I know, I could just collapse the list first, but I forget that most of the time).

Are there any settings / gadgets / custom CSS / custom JavaScript / whatever which solves these problems (at least partially)? I'd love to have

Only the section I'm editing visible in both edit windows.
The "View templates on this page" section as well as the "View hidden categories on this page" section hidden on edit conflict pages, I don't need them anyway on these pages.(I also thought about custom CSS for this, but it seems an edit conflict page has no special class or anything similar?)

Regards, --Patrick87 (talk) 01:01, 2 June 2013 (UTC)[reply]

I betcha I could cook up a JavaScript (you use JavaScript?) that would search for ec-specific text, and hide the template links if it finds it. (Ever more bloat. Huzzah.) Let's see if WK or Theo or Technical can beat me to it... Ignatzmice•talk 01:30, 2 June 2013 (UTC)[reply]

That would solve at least part of the problem, although I had hoped for a simpler solution (since I try to keep my Wikipedia bloated up to a minimum

). Is there a clean way to do this in JS? If the JavaScript needs to be specific like hell and requires a lot of manual fiddling to select the correct links on the correct pages it would be an unsatisfying solution I'm afraid. --Patrick87 (talk) 01:39, 2 June 2013 (UTC)[reply]

@Ignatzmice: I'd be happy to, but so far I've sufficiently avoided JavaScript proficiency...I'm more of a server-side scripter myself, but I guess it would still be a good learning experience. WK/Technical: code away, I'll work on my own version and then compare it to yours once completed so I can learn something. :p Theopolisme (talk) 02:28, 2 June 2013 (UTC)[reply]

@Patrick87: Whooooooofff. Took me a while, mostly 'cause I didn't realize for a while that just reloading the EC doesn't refresh the scripts, so the changes I was making weren't showing up. But also, Theo, because I have no freakin' clue what I'm doing. Google and StackOverflow, that's how I roll. Anyway:

importScript('User:Ignatzmice/templateEC.js'); // linkback: [[User:Ignatzmice/templateEC.js]]

should do it. Ignatzmice•talk 03:01, 2 June 2013 (UTC)[reply]

That's some beautiful code, my friend. Now just selectively hide part of a textarea and you'll go far ;) Theopolisme (talk) 03:04, 2 June 2013 (UTC)[reply]

Wow, thanks! Looks easy in principle. Do you have any idea how well this works performance-wise? I could imagine scanning the whole body-content could be quite demanding? Will test it soon (but probably not until tomorrow). --Patrick87 (talk) 03:08, 2 June 2013 (UTC)[reply]

It works, performance-wise. No idea about detailed milliseconds—might depend on the size of the page, might not. (The notice is at the top.) Maybe WK might have access to fancy-pants tools. I agree it's slightly worrisome that it scans the whole page, but like I said, it might quit after finding the notice—and can you think of an way it wouldn't?
Re: selectively hiding—I suppose I could look for the auto section summary, find that section, hide all above, find the next double-equals, hide all below—but that's just very pseudo pseudocode, and I need to get to bed. Someone else can try it, if they want. Ignatzmice•talk 03:16, 2 June 2013 (UTC)[reply]

Quick note: I tried to get it to only load on action=submit pages; that didn't work. I tried doing it without variables; that didn't work (though I don't mind that so much as the selective loading, just in case it does make a difference). If someone wants to take a peek at the history and let me know what I did wrong, go for it. But it doesn't matter that much. Ignatzmice•talk 04:03, 2 June 2013 (UTC)[reply]

Yo all. You don't have to search the whole damn page to find the template: just use a JQuery selector. $("div.mw-explainconflict") should do the trick. You'll want to read up about JQuery selectors (which are based on native CSS selectors, so they're extremely fast) in general; they're basically necessary to do any kind of user scripts on Wikipedia. Fortunately, JQuery comes with excellent API documentation. Writ Keeper ⚇♔ 05:26, 2 June 2013 (UTC)[reply]

Of course, if the contents of that script are all you're trying to do, you should be doing it through CSS directly, which would obviate any performance problems. I'll take a look. Writ Keeper ⚇♔ 05:29, 2 June 2013 (UTC)[reply]

Yo yourself. From what I can tell from the above thread, the other goal is to selectively "hide" some text in a text area. I have no idea if that's possible, but I imagine it would be a matter of editing the text area--storing its contents to a variable--using some sort of regex to "edit" the contents and make a capture group of the section the user was editing (via the diff tab?)--print only that text back out into the textarea--then letting the user edit it (just that section, in other words)--and then, once they press save, use some more capture-groupy magic to reinsert their updated text. I'm sweating and all I did was outline the functionality in a way that didn't even make much sense. Theopolisme (talk) 05:33, 2 June 2013 (UTC)[reply]

Also, I don't think that code will work, Ignatz: "templatesUsed" is a class, not an ID, so the correct selector would be $(".templatesUsed"). Writ Keeper ⚇♔ 05:39, 2 June 2013 (UTC)[reply]

You'd think, wouldn't you? But I found that #templatesUsed worked, and .templatesUsed didn't. It is also the ID of one of the divs or spans or something within the larger one. Who knows. Ignatzmice•talk 12:16, 2 June 2013 (UTC)[reply]

Okay, I think the CSS for hiding the templates used should be:

.mw-explainconflict ~ #editform .templatesUsed{display:none;}

. Put that in your common.css page and it'll get rid of that with no performance issues. Writ Keeper ⚇♔ 05:44, 2 June 2013 (UTC)[reply]

Ah, the sibling selector! Now I was searching for any class or ID of a parent I could use, but I didn't think of this CSS selector I never used before. --Patrick87 (talk) 05:59, 2 June 2013 (UTC)[reply]

Yeah, I knew that a sibling selector existed, but I had to look up its syntax. :) Writ Keeper ⚇♔ 06:03, 2 June 2013 (UTC)[reply]

Just put it into my de:User:Patrick87/global.css, works perfectly. Thanks again! --Patrick87 (talk) 16:27, 2 June 2013 (UTC)[reply]

(late to the party) In the above example, ~ is more correctly described as the general sibling combinator - it's a combinator, not selector, because it combines two selectors; and "general", since there is also +, the adjacent sibling combinator, which is better known, since it was introduced with CSS 2. --Redrose64 (talk) 20:10, 4 June 2013 (UTC)[reply]

Goddammit, you're right. Seems to load much faster, too. Ignatzmice•talk 12:16, 2 June 2013 (UTC)[reply]

S'why Jimbo pays me the big bucks, man. Generally speaking, any time you can do something through CSS directly, you should, since the CSS will load instantly and the equivalent Javascript will nearly always have a noticeable delay. the very barebones tools that CSS provides are also great for programmer discipline. Writ Keeper ⚇♔ 15:51, 2 June 2013 (UTC)[reply]

(Ironically, I just got an edit conflict.) And just hiding part of the text isn't a solution, since the way it works now your edit conflict is far more likely to cause other edit conflicts, since you are forced to edit the entire page, rather than the section, greatly increasing the risk of a conflict. I personally just hit the back button, cut my text, reload the page, and try the section edit again (with the text I paste back in). Is there any reason the code can't be changed to no longer escalate edit conflicts to the page level ? StuRat (talk) 05:46, 2 June 2013 (UTC)[reply]

Yes, and it's a problem that faces any user script, too: how do we programmatically know what section you were editing? I'm not sure there's a way to figure that out. (Well, that shouldn't be insurmountable on the server side, but it might be insurmountable for us user script plebs.)Writ Keeper ⚇♔ 05:48, 2 June 2013 (UTC)[reply]

Some edit-conflicts are caused by deleting/shifting text, or inserting subheaders, and the full-page display can help reveal when the section headers have changed, as when a re-edit accesses a different topic ==header==. -Wikid77 06:43, 5 June 2013 (UTC)[reply]

Couldn't you just look at the diff (that is shown when you edit conflict), grab some of the "+" text, and re.find (or whatever the javascript equivalent) in the text area? Then just match the == before and after it to get section boundaries. Not going to work *all* the time, but seems like it would cover a majority of the cases. Theopolisme (talk) 06:20, 2 June 2013 (UTC)[reply]

Not really, because we have no guarantee that your post is uniquely yours (in other words, that the text the method finds is the text you added, rather than someone else's). Think of any place on ANI or a village pump where !votes happen: new postst that are an exact duplicate could easily happen there, if one is just saying "'''Support.'''" or something. (Yes, signatures will usually resolve that, but that's still not a guarantee, and since it will weird the hapless use out to a significant degree, I don't think that's a good thing to ignore.) Moreover, that still doesn't help with SuRat's point, since that still doesn't let us submit a new API query with only the edited section; we still have to submit the entire page. Plus, that's just a shitty way of doing things, aesthetically speaking. Writ Keeper ⚇♔ 06:50, 2 June 2013 (UTC)[reply]

Resolution of edit-conflicts is a 3-revision merge: And so a condensed edit-conflict preview would require comparing your changes to your prior revision, then comparing the newer revision against your prior revision, and then excluding the common sections, even if out-of-sync by one line all the way down the page. Instead consider how simplistic the full-page preview is: it shows the full latest revision versus your update to the full prior revision, with no attempt to merge the two at all. The auto-correction is not hard to do, but it can be confusing at a human level, of side-by-side comparisons better done by machine algorithms, as merging revision-C after revision-A with revision-D after revision-A, while allowing for other intermediate revisions called "revision-B" after revision-A. Unless all 3 revisions (A/C/D) are compared, then the edit-conflict cannot be accurately reduced to a few sections, because even small changes intended for the prior revision might seem very different against the latest revision. However, there could be a special-case counter, as for less than 5 changes, to show those limited sections, but auto-merge to submit the full page after edit-conflict. -Wikid77 (talk) 06:43, 5 June 2013 (UTC)[reply]

Tracked in Phabricator
Task T6745

Regarding problem number 1: Just checked Bugzilla and found that it was already reported back in 2006. I hope we can catch the attention of a developer, since changing this directly in MediaWiki would be the best solution after all. --Patrick87 (talk) 15:53, 2 June 2013 (UTC)[reply]
- Yep, looks like Brion had a similar concern to mine in comment 6. Writ Keeper ⚇♔ 16:01, 2 June 2013 (UTC)[reply]
  - I guess the question is, "Is this really necessary?" Flow will make edit conflicts things of the past--so why waste time building fixes to handle them in a system that will soon be unused on Wikimedia sites? Theopolisme (talk) 16:12, 2 June 2013 (UTC)[reply]

"Flow will make edit conflicts things of the past"? i thought flow only pertains to talk pages, no? conflicts happen in article space also... peace - קיפודנחש (aka kipod) (talk) 16:23, 2 June 2013 (UTC)[reply]

Mainspace edit conflicts are already handled quite well, all things considered--while they could be improved, that wasn't what this thread was specifically about. Theopolisme (talk) 16:31, 2 June 2013 (UTC)[reply]

Mainspace conflicts can be horrific, as when trying to edit a hot-topic article, such as latest disaster or notable criminal case or such. Again, people should section-edit, then preview, copy new text, and then re-edit quickly to paste/save text (see essay: wp:Avoiding edit conflicts). -Wikid77 06:43, 5 June 2013 (UTC)[reply]

New notifications don't get attention of new users like the Orange Bar of Doom did

Recent experience indicates that the new notifications system doesn't get new users' attention nearly as well as the Orange Bar of Doom did. I found that a newly registered user had replaced most of the content of a stub article with a copyvio, so I removed the content and wrote a little "welcome" essay on the user's talk page. The user came back and recreated their earlier content with an edit summary ("did not save the first time for some reason tried it again") that indicates that they didn't see my user-talk message and have no idea what happened. I have to assume that this newbie hasn't noticed the rather subtle notification of a talk-page message, and they haven't enabled email. I've posted a warning on the talk page, but warnings and other messages to newbies are useless if the users (who presumably don't even know they have talk pages) never see them. --Orlady (talk) 03:55, 2 June 2013 (UTC)[reply]

No shit, really? sighs... Ignatzmice•talk 03:59, 2 June 2013 (UTC)[reply]
- Yep I have noticed that too. Kumioko (talk) 04:07, 2 June 2013 (UTC)[reply]

Need top maintenance-tag to alert editors: The failure(s) of the user-talk system have been a problem for years, and we should not rely on MediaWiki software upgrades this year to fix it (after further user-talk downgrades), but instead, create a useful tag-box at the top of the article, especially if multiple editors were updating the page. I suggest a "{Concerned}" tag-box which would state, "Recent edits to this page have raised concerns; see Talk:Xxxx#Concerns" and have that link to header "#Concerns" or a header named by parameter {{{1}}}. Hence, even a new editor could redisplay the page, then see the top Concerned tag-box, and read the talk-page link to "==Concerns==" about adding the recent copyvio text. A {Concerned} tag-box should have been developed years ago, as a general notice which even new editors, or editors whose user-talk has been re-MediaWikified, could read as an alert to their edits. -Wikid77 (talk) 12:06, 2 June 2013 (UTC)[reply]
Urgh, not more maintenance tags... . However, what you propose are really communication tags, not maintenance tags. What maintenance does such an article need? Since the edits that raised concern have already been undone, the only thing a wikignome finding the tag needs to do is remove the tag! I'm not keen on littering articles with little messages to get the attention of just one or two people editing it. If there are many editors making the same "bad" edits, the page needs an editnotice. Editnotices get the attention of editors without disturbing readers. There's also a strong risk of such tags being left on the article for years (the template could be coded to cause it to disappear from the rendered page after a week or two, though it would still be in the wikitext). – PartTimeGnome (talk | contribs) 00:21, 3 June 2013 (UTC)[reply]

The "maintenance" needed would be to remove the copyvio text if re-added (as explained at the related talk-page link). However, an edit-notice warning of copyvio would also help to deter the active editor(s), but unfortunately, give no alert to readers who might think the copyvio text could be copied, or was approved by "wiki-management". A tag-box template, as {Concerned}, would cover more options, formally logging the copyvio event, and also catch the attention of the editor who had noticed the "old revision" was still there "unchanged" but a {Concerned} tag-box would instead get the attention of the editor, as most definitely a change in the article's appearance after the copyvio text had been removed. Many people would be alerted to the issue. In a sense, working on Wikipedia is like a massive multiplayer chess game, where the strategy involves making moves in combination with all users, including new editors, old editors who fix copyvio problems, people who read an article wondering about copyvio, and people who want to copy an article (unaware copyvio text has been added). Adding a tag-box template is a move to make advances with numerous users, where many users also know how to easily remove the tag-box when outdated. -Wikid77 22:29, 5 June 2013 (UTC)[reply]

Recent experience is not quantitative data, or even reliable qualitative data; it's the plural of 'anecdote' ;p. I'd note that clickthrough rates with the OBOD were pretty weak too. However: as far as I know there is some work being done to A/B test clickthrough rates and find out exactly how many people it grabs or misses, and hopefully iterate on the design from there. Ironholds (talk) 13:05, 2 June 2013 (UTC)[reply]

+1. as my teacher used to say: " 'anecdote' is not the singular form of 'data' ". we had plenty of cases of new users missing or ignoring the old "you have a message" bar. it is possible that the new notification is less visible, and it's also conceivable that it's more visible, or just equally as visible. pointing to one (or 5) case(s) where the new notification was ignored proves very little, considering the aforementioned fact that the old notification was also ignored occasionally. it's hard to think of a good way to produce reliable data for this question. peace - קיפודנחש (aka kipod) (talk) 16:00, 2 June 2013 (UTC)[reply]

The user could have had javascript turned off. If I understand correctly, all the user would see was the (0) at the top of the screen turn into a (1) as the little orange bar is not fully integrated into Echo to make it HTML, which I've heard the developers are working on. In the mean time, I think a better way to notify the non-javascript users by turning from a (0) to a bolded (1) or (2). FallingGravity (talk) 23:34, 2 June 2013 (UTC)[reply]
The "1" already appears in bold with a red background without the use of JavaScript. The developers fixed that a little while back. However, I still don't see the "You have new messages" orange bar that users with JavaScript see. I suspect many users without JS don't realise what the red number signifies and ignore it. (Or perhaps they try clicking it once, see just a trivial notification, then never look again, not realising it can tell them something more important.) We definitely need the orange bar available to non-JS users since it is a much clearer indication that the user has messages. I'm glad to hear the developers are working on this, or was what you heard only about highlighting the "1", which has already happened?

I've added a note to Wikipedia:Notifications/FAQ#What happened to the orange bar for talk page messages on Wikipedia? to say that the orange bar requires JavaScript. – PartTimeGnome (talk | contribs) 00:03, 3 June 2013 (UTC)[reply]
Ah yes, I had experimented with the disabling of the javascript a while back. Making the small orange bar HTML was mentioned by User:Edokter, over here. FallingGravity (talk) 20:32, 3 June 2013 (UTC)[reply]
I saw that comment (it was a reply to me!). That was when the new message indicator was just a gadget. The developers have now integrated it into Echo, but it still requires JavaScript. I'm guessing they think no one needs to talk to non-JS users... – PartTimeGnome (talk | contribs) 21:38, 3 June 2013 (UTC)[reply]

Notifications error in calculation of yesterday

I've just noticed that when Notifications shows "Yesterday", that's not always true. From top to bottom, I have notices which give dates/times as follows:

06:41
Yesterday at 05:14
Yesterday at 22:54
Yesterday at 21:21
Yesterday at 19:25
Yesterday at 17:45
Yesterday at 13:43
Thursday at 16:58

Notice in particular that the second seems to be earlier than the 3rd-7th. The true dates/times of the relevant edits were as follows:

06:41, 2 June 2013 (UTC)
(see below)
22:54, 31 May 2013 (UTC)
21:21, 31 May 2013 (UTC)
19:25, 31 May 2013 (UTC)
17:45, 31 May 2013 (UTC)
13:43, 31 May 2013 (UTC)
16:58, 30 May 2013 (UTC)

There are two problems here. The first is that edits which were on Friday 31 May are shown as "yesterday" - today is Sunday 2 June. The other is that this new "... thanked you for your edit on ..." doesn't show in the relevant user's contributions, but I'm certain that it was 05:14 1 June, because that user made no edits on 31 May, but they did make an edit to the page named in the "thanked you" message at around the same time on 1 June. --Redrose64 (talk) 08:38, 2 June 2013 (UTC)[reply]

I suspect they used a very crude algorithm to decide what constitutes as 'yesterday', namely between 24-48 hours. — Edokter (talk) — 12:55, 2 June 2013 (UTC)[reply]

Redrose64, you are right about the date of that thanks. CSB radio thanked you at 05:14 on 1 June. See Special:Log/thanks. – PartTimeGnome (talk | contribs) 00:30, 3 June 2013 (UTC)[reply]

Might be worth to send a software bug report to the 'Bugzilla' bug tracker by following the instructions How to report a bug, in this case under the product 'MediaWiki Extensions' and the component 'Echo' (You can use this direct link if you have a Bugzilla account). This is to make developers of the software aware of the issue. If you have done so, please paste the number of the bug report (or the link) here, so others can also inform themselves about the bug's status. Thanks in advance! --AKlapper (WMF) (talk) 09:29, 3 June 2013 (UTC)[reply]

adding thumnails (namely thumnails of flags) to a section

Hi, I am trying to add a thumbnail flag to a section for which the text is already written.

I have browsed the help section "adding images", but could not find anything relevant to my problem.

Does someone knows where I can find it?

Thanks for your help.

Regards. — Preceding unsigned comment added by Kimuzukashiineko (talk • contribs) 07:28, 3 June 2013 (UTC)[reply]

You can write {{flag|India}} to get

India. If you want the flag only, you can use {{flagicon|India}} →

.—Emil J. 15:27, 4 June 2013 (UTC)[reply]

Forcing HTML 5

In the announced plans to force use of HTML 5, I am wondering how will the outdated HTML tags be handled, such as ~~~~ or <center> or , and table attributes: border=1 or cellspacing=2 or cellpadding=3 or valign=top. Up to now, the MediaWiki parser has been using pseudo-HTML as "text formatting directives" as if it were part of the macro scripting language, where marking a column for vertical alignment (valign=top) would convert the pseudo-HTML into: valign="top". But now, after the massive fiasco of dropping the orange new-messages bar, to confuse 50,000 active registered editors, I am "slightly concerned" that the next MediaWiki shock will be bizarre rejection of "valign=top" rather than merely continue support by translating pseudo-HTML into the longer HTML-5 equivalents. Any word on how disasterous the forcing of HTML 5 will be in the next MediaWiki upgrade/downgrade, as perhaps handled by a different WMF department than the new-messages bar? -Wikid77 (talk) 11:17, 3 June 2013 (UTC)[reply]

Er. What announced plans? Okeyes (WMF) (talk) 12:33, 3 June 2013 (UTC)[reply]

Ditto. And  is not obsolete in HTML5.[1] -- Gadget850^talk 13:07, 3 June 2013 (UTC)[reply]

But it did undergo a semantics change ("was for smaller text, now used for side comments and small print").[2] Jason Quinn (talk) 18:52, 3 June 2013 (UTC)[reply]

Fortunately, using "" is still safe, but as stated in the archive page (/Archive_112#Tech_news:_2013-22): "MediaWiki will stop supporting XHTML 1.0 and HTML versions lower than version 5. HTML5 will now be the default language for pages created by the software." And so, I am wondering what will happen to "valign=top" in table columns. -Wikid77 (talk) 14:46, 3 June 2013 (UTC)[reply]
- All Wikimedia sites have been using HTML5 output for many months, when the configuration was finally changed to $wgHtml5 = true. The upcoming change simply removes the legacy code supporting $wgHtml5 = false from the MediaWiki software. As far as I can make out it should have no effect on Wikimedia sites. the wub "?!" 16:21, 3 June 2013 (UTC)[reply]
 - And why can I still use non-conforming features like teletype text, ~~striked text~~, big text and the like? Shouldn't tey be prevented if we already produced standard conforming HTML5? --Patrick87 (talk) 17:27, 3 June 2013 (UTC)[reply]
 - Mediawiki does run its output through HTML tidy, but they do not clean up such things. Browsers have no problems handling them, as you can see. But if you look at the source of this page, it says <!DOCTYPE html> ,which means HTML5. The main issue in changing to HTML5 is that Mediawiki no longer guarantees the source is well-formed XML. The usual formatting commands still work fine, e.g. . — Carl (CBM · talk) 17:28, 3 June 2013 (UTC)[reply]
 - HTML elements and attributes are whitelisted by Sanitizer.php. Help:HTML in wikitext#Obsolete elements notes the obsolete elements. Even though obsolete, browsers will probably support them forever. -- Gadget850^talk 17:45, 3 June 2013 (UTC)[reply]
 And there is a bug report requesting that obsolete elements be converted. Have to did around to see the status on that one. -- Gadget850^talk 17:47, 3 June 2013 (UTC)[reply]
 So we're producing nonconforming code on purpose? I hope I don't have to understand this. The correct way would be to either deprecate those HTML tags completely and offer something similar through Wikitext or substitute them automatically (e.g. replace <big> with  --Patrick87 (talk) 17:54, 3 June 2013 (UTC)[reply]
 Template:Bug Replace deprecated HTML tags in HTML5. Each of the obsolete tags has a matching template, except for <tt>, which has other replacements. And if you want to just turn off , then please have a plan in place to update signatures. In the scheme of things, this is a minor issue. Rather irritating when validating a page. -- Gadget850^talk 19:41, 3 June 2013 (UTC)[reply]
 On the other hand, see Template:Bug where code doing this sort of thing was removed after it proved more trouble than it was worth. Anomie ⚔ 02:02, 4 June 2013 (UTC)[reply]
 Exactly. The latest ideas on this are that some 'transformations' will be added to parsoid to actually move away from all deprecated HTML elements. But this is not definitive. For now, we will potentially output non-compliant HTML5 for some of the user generated content. There is nothing wrong with this, compliancy with specific versions of HTML has sort of become obsolete with the concept of a living HTML standard as professed by HTML5 and the browser vendors. All browsers will recognize these elements into infinity most likely, and if they don't we can do some things at the server side, before users are bothered with it. So no panic needed, users won't notice a thing about this change. —TheDJ (talk • contribs) 11:36, 4 June 2013 (UTC)[reply]

Check For Identical Edits

I started a conversation here: http://en.wikipedia.org/wiki/Help_talk:Edit_conflict#Check_for_identical_edits.3F . I am moving it here. — Preceding unsigned comment added by TheUnknownNinjaNN2 (talk • contribs) 05:26, 4 June 2013 (UTC)[reply]

Also rare bug says edit-conflict when none: Although it might seem an edit-conflict was caused by hitting "Save page" twice, there have been cases where a single Save would trigger an edit-conflict preview, but "Show changes" would confirm no other edits to that section, and in fact no other edits to the entire page, but still refuse to save the changes. We are not sure if the false edit-conflicts are perhaps caused by logic errors in the page-submit, such as thinking an extra paragraph which was added at the end of a page is perhaps sometimes an edit-conflict. -Wikid77 (talk) 11:34, 4 June 2013 (UTC)[reply]
I've seen this phenomena myself and usually can find where it thinks that a blank line was added or removed somewhere else. I usually look over to see what the conflict is, and if there is no other person's comment, I scroll to the bottom, click on the "Your text' box, hit ctrl+a then ctrl+c scroll back up to the active edit box and press ctrl+a then ctrl+v then Save. I'll try a little harder to take exact notes about the placement and +/- of the blank line conflict. Technical 13 (talk) 12:14, 4 June 2013 (UTC)[reply]

I have occasionally bumped it twice though. It is not responding so I click again. Sometimes, I missed it on this tiny screen. Sometimes, it was slow internet.

TheUnknownNinjaNN2(Talk,Always willing to discuss this subject) 23:25, 4 June 2013 (UTC)[reply]

Problems with watchlist green bullet

A week or two ago, a new line appeared near the top of my watchlist noting that "Pages that have been changed since you last visited them are shown with a green bullet." I have yet to see any green bullets so I assumed that this was yet another buggy feature forced on us without adequate announcements or testing. That's disappointing but I found the gadget in my user preferences that purports to turn this feature off entirely. However, the line still appears at the top of my watchlist. Is this a bug in the gadget that can be fixed? Or is there some other way to remove this broken feature from my watchlist? ElKevbo (talk) 06:16, 4 June 2013 (UTC)[reply]

I would hope that the gadget can be fixed, but until then you can add this line to User:ElKevbo/common.css -

#mw-wlheader-showupdated { display: none; }

-- John of Reading (talk) 06:22, 4 June 2013 (UTC)[reply]

I fixed the gadget. —TheDJ (talk • contribs) 10:19, 4 June 2013 (UTC)[reply]

Can you fix it to disable the bolding too? Werieth (talk) 10:28, 4 June 2013 (UTC)[reply]

Awesome. Thanks so much to both of you! ElKevbo (talk) 16:00, 4 June 2013 (UTC)[reply]

Yeah, I didn't see them at first either. They firstly do not show up if you are using enhancedRC. Secondly, if you are not using enhancedRC, the difference in the colors is near indistinguishable with certain color blindnesses or even if you have a dull screen (I had to use a tool called Instant EyeDropper that tells you the hex code of colors on the page). So, if any of those situations apply to you (I use enhancedRC myself) then the css John of Reading suggests is the way to go to make that annoying inaccurate statement go away. Happy editing! Technical 13 (talk) 12:05, 4 June 2013 (UTC)[reply]

TALK2: Talk-pages with paragraph edit

Although wp:FLOW has its own plans, what we have wanted, for years, is to simply go to a long talk-page, and edit by paragraph (each marked "[e]"), just one at time in those cases, to either change the paragraph or reply. Note this is just one mode of access, where also, the original ability to edit the whole talk-page and reply to several topics, during one edit, would still be supported. However, note that paragraph-level edits would still require automatic-merge for edit-conflict of 2 replies, such as FIFO (first-in, first-out), where the 2nd reply after a paragraph would get inserted after the 1st reply, and in fact, a 3-person edit-conflict would insert reply3 after reply2 (after reply1).
So, imagine a talk-page with numerous [e]'s down the page, at each paragraph, and perhaps have a Special:Preferences option to put "[e]" at the left-side of talk-page text, rather than as all right-side [e]'s. Now, paragraphs would be any ":" or "*" or "#" indent-mark or blank-line break, or perhaps a Special:Preferences to also mark any text break (newline) as a point to show "[e]" to edit that separate line. I understand the paragraph-level talk-page is not the same as WYSIWYG-edit, and paragraphs generated by templates (or Lua script modules) would limit access to the top of the template call, but it would be a format that even many new users could handle, by keeping the edit focused on one paragraph at a time (until users were more comfortable with the current section-level [edit] of "==Header==" or whole page). I think that would be fantastic, and solve the new-user frustration about long talk-page texts. Also, by inviting edits to just one paragraph at a time, then edit-conflicts would be limited to just one small portion of a talk-page, as much easier to auto-merge and resolve. After talk-pages, then perhaps introduce paragraph-edits to articles, with an option to just edit the whole page but position initial cursor at that paragraph. Does that sound useful? If so, we can move this thread to a wp:VPR proposal thread. -Wikid77 (talk) 11:07, 4 June 2013 (UTC)[reply]

This looks like micromanagement. Although that is not necessarily bad, I think that this would add a new level of complexity in a system that borders on being too complex already. What you are suggesting is the same concept of Liquid Threads, which although I wasn't around for the discussion on that, apparently didn't get consensus. Technical 13 (talk) 12:10, 4 June 2013 (UTC)[reply]

Instead, "micromanagement" is a style of planning, organization and control (POC) which dictates excessive commands at low-level operations. Also, wp:LiquidThreads is a limited message-box system, which could spread a 30-line conversation, with 12 replies, into four screens of scrolled message-boxes, where replies could only be appended onto one box at a time, with no limited ability to redact insults. Instead, listing the paragraph-edit buttons (as "[e]") would simply extend the "[edit]" feature at every paragraph and could probably be implemented within a few weeks, based on treating each "[e]" segment as if it were a "==header==" with all segments numbered in order. Sometimes the largest feature improvements can be made, quickly, with the simplest of software changes. -Wikid77 (talk) 14:23, 4 June 2013 (UTC)[reply]

I've just checked at MediaWiki.org (where LiquidThreads is installed), and I can edit other users' comments to redact personal attacks without a problem. You might be confused with the proposed Flow discussion system, for which Jorm is planning to restrict the ability to edit others' comments to administrators only. – PartTimeGnome (talk | contribs) 23:14, 4 June 2013 (UTC)[reply]

I guess others imposed limits on wp:LiquidThreads, where the edits to redact or append text into a message box were reverted as "improper style". -Wikid77 04:43, 7 June 2013 (UTC)[reply]

No, what you have wanted is that. I've got no particular interest in being able to edit paragraph-by-paragraph exclusively, I think it would be excessively disruptive, and I think it would be a total waste of our time to discuss a feature that will be overwritten by Flow anyway. What you're asking is for the community and the foundation to play chicken...over paragraph editing. Ironholds (talk) 00:27, 5 June 2013 (UTC)[reply]

The paragraph-edit buttons (as "[e]") would simply extend the "[edit]" feature at every paragraph, for use with the current sophisticated talk-page structure, rather than the narrow, limited wp:Flow edits. Also, it could be extended to apply to paragraph-level editing of article texts, while using the full macro scripting language with markup for text styling, and templates for sortable tables, infoboxes, wp:charts, and Lua script modules to allow smart templates to help proofread text during edit-preview. -Wikid77 (talk) 04:43, 7 June 2013 (UTC)[reply]

X!'s Edit Counter

Please consider joining the feedback request service.

An editor has requested comments from other editors for this discussion. This page has been added to the following list:

Wikipedia technical issues and templates

When discussion has ended, remove this tag and it will be removed from the list. If this page is on additional lists, they will be noted below.

Several users have expressed that they want the detailed edit stats to be visible without having to optin. I see this as a Privacy concern and I feel the community should answer this question before taking any intiative on this. Should the detailed edit counter remain as an opt-in or should it be an opt-out or not opt-able at all? — Preceding unsigned comment added by Cyberpower678 (talk • contribs) 12:58, 4 June 2013 (UTC)[reply]

Keep opt-in

Opt-out privacy is a joke, and is not privacy at all. While it's certainly not the biggest privacy violation on the Internet, I don't think people have an automatic right to view this kind of data. Oh, and as mentioned below, as long as this is hosted on the toolserver, it can't be changed. There's some German privacy law regarding "profiling of individual user's activity", which requires this kinda thing to be opt-in. --Chris 14:44, 4 June 2013 (UTC)[reply]
Urgh. It's on labs now, and the toolserver version will be shutoff soon.—cyberpower ^Chat_Online 14:51, 4 June 2013 (UTC)[reply]
This is a clear privacy issue, I fail to see how anybody can see otherwise. Giant Snowman 15:02, 4 June 2013 (UTC)[reply]
Believe me, a lot of people on IRC tried. I said I'm not doing it without an RfC.—cyberpower ^Chat_Online 15:24, 4 June 2013 (UTC)[reply]
+1 to Chris's statement: "Opt-out privacy is a joke..." Keep this opt-in. If someone wants to use it for themselves, then it's a few clicks away. If they want to use it to peer into someone else's history, it's for that person to open that door to them. --RA (talk) 15:25, 4 June 2013 (UTC)[reply]
i'm surprised that this is even brought up as an option. an active editor's edit pattern can reveal way too much about them, and the idea that this data should be thrown into the public domain without them actively expressing consent is inconceivable. peace - קיפודנחש (aka kipod) (talk) 17:45, 4 June 2013 (UTC)[reply]
Our contributions are already public record, but for detailed analysis of our edits, which can be used to hound an editor by those who do not assume good faith of the editors intentions, should IMHO be something that should be primarily available to 'Crats or if an editor chooses to make it publicly available. Hopefully, everyone will want increased transparency of our activities, but IMHO it should be a personal choice, rather than something that one has to opt out from.--RightCowLeftCoast (talk) 17:56, 4 June 2013 (UTC)[reply]
The really crazy/creepy folk, the ones that would engage in off-wiki hounding or outing or real life confrontations, don't need X!s tool. Those people are dedicated enough to sift through a lot more than just some graphs. Sven Manguard Wha? 17:02, 8 June 2013 (UTC)[reply]
The fact that some data is public but scattered, is one thing, collecting and organizing the data is something quite different, that is (good part of) the work of Intelligence agencies («intelligence gathering, [...] does not necessarily involve espionage, but often collates open-source information.», from Espionage). WP is not a espionage / intelligence agency, I'd say. - Nabla (talk) 23:07, 5 June 2013 (UTC)[reply]
Per Chris G. It Is Me Here ^{t / c} 17:01, 6 June 2013 (UTC)[reply]
Yes. This is one of the rare questions I have a gut answer to :-). The data is public, and there is nothing stopping people "rolling their own" analysis, but there is a big difference between that and Wikimedia-supported profiling and publication. Andrew Gray (talk) 19:33, 6 June 2013 (UTC)[reply]

Remove opt-in and replace with opt-out

As per Tom Morris, this information is not actually private. X!'s edit counter is a quick and efficient way to gauge an editor's contribution history. I think that switching to an opt-out system would help to improve transparency. Some people would feel uncomfortable with their editing patterns being so exposed, so they should still be permitted to opt-out at their discretion. Kurtis ^(talk) 17:46, 4 June 2013 (UTC)[reply]

Remove opt-in completely

This information isn't "private". It's just a compilation of public data. Anyone who has access to the Toolserver or to the API can work this out with very little work. Treating public data as if it were private data leads people to believe that by not opting-in or by opting-out, the compilation of these statistics won't be done. It just means it won't be done by this tool. I mean, let's consider the silliness of this: shall we allow users to "opt-out" from Stalker, Max McBride's tool to compare contributions between users in order to help people detect socking? No. The issue isn't actually privacy in any meaningful sense of the term. The reason it is opt-in is to give people a feeling that they are in control of "private" information, even though it isn't private information and they aren't in control. I'd rather not give people the illusion that this information is private when it isn't. —Tom Morris (talk) 15:45, 4 June 2013 (UTC)[reply]
Who's Max? --MZMcBride (talk) 22:18, 4 June 2013 (UTC)[reply]
Yeah this. The data is publicly available, that tools shouldn't exist which compile it in a usable form seems silly. --Jayron32 17:49, 4 June 2013 (UTC)[reply]
The tool doesn't give you any information that isn't already on the user contribs page, seems silly to have an opt-in, or an opt-out. Though I'd support opt-out over opt-in if we must. Prodego ^talk 18:02, 4 June 2013 (UTC)[reply]
Note that if the tool is hosted on a wikimedia de server, then the opt-in must stay. Prodego ^talk 18:03, 4 June 2013 (UTC)[reply]
It's a helpful tool that uses publicly available information. When unavailable, it just makes finding the information so much harder. I see no real privacy concerns as long as every editors contributions may be browsed. --SmokeyJoe (talk) 21:46, 4 June 2013 (UTC)[reply]
Going a step further to say that user contributions should be scrutinized carefully and this tool helps enable this. Data on editors' contributions should be widely available to combat POV pushing and similar problematic behaviour. There is no privacy issue as contributions are public record. This falls squarely in line with the foundations's privacy policy which reads: User contributions are also aggregated and publicly available. User contributions are aggregated according to their registration and login status. Data on user contributions, such as the times at which users edited and the number of edits they have made, are publicly available via user contributions lists, and in aggregated forms published by other users. [3] Them From Space 23:08, 4 June 2013 (UTC)[reply]
It's simply a tool that takes public data and aggregates it using standard methods. Without the tool, all the information could still be found, but it would just take more work. I see no privacy violation here. -- King of ♥ ♦ ♣ ♠ 23:52, 4 June 2013 (UTC)[reply]
Per Tom Morris. Ironholds (talk) 00:24, 5 June 2013 (UTC)[reply]
Per Jayron32 -- John of Reading (talk) 04:49, 5 June 2013 (UTC)[reply]
Per everyone above. Graham87 04:54, 5 June 2013 (UTC)[reply]
I have never understood why this is opt in. It saves a lot of time on various issues, and therefore should be available freely - especially as there are no privacy issues. Mdann52 (talk) 10:05, 5 June 2013 (UTC)[reply]
@Mdann52: It was opt-in because German law required it. Toolserver is located in Germany.—cyberpower ^Chat_Online 15:07, 5 June 2013 (UTC)[reply]
Per above, if it's moved from a server where it's a legal requirement (damn Germans!). It's not actually private information - just number of edits/month and number of edits to individual articles, both of which IIRC can be found on other tools, associated or not. Ansh666 14:39, 5 June 2013 (UTC)[reply]
@Ansh666: You realized you just damned me, right? The guy who is moving the tools to labs. :p—cyberpower ^Chat_Online 15:07, 5 June 2013 (UTC)[reply]
Heh, oops. Ansh666 20:20, 7 June 2013 (UTC)[reply]
Per all above. ·addshore· ^{talk to me!} 23:11, 5 June 2013 (UTC)[reply]
You cannot make private what has already been publicized. When each datum has been published, nothing new is revealed by summaries and aggregations that users could always perform on their own computers, if they wished. Opt-in or opt-out attempts to weave garments of mixed fibers. DavidLeighEllis (talk) 02:00, 6 June 2013 (UTC)[reply]
Because this information is very easy to gather from the API, which is publicly accessible, and with only very minimal coding skills. Any added privacy from an opt-in is illusory. — Carl (CBM · talk) 02:16, 6 June 2013 (UTC)[reply]
Per supra. Theopolisme (talk) 03:07, 6 June 2013 (UTC)[reply]
I don't understand how there can be a privacy violation. The pages a person has contributed to is something they should be proud of. -- ^(T)Numbermaniac_(C) 07:24, 6 June 2013 (UTC)[reply]
A false sense of privacy. Marcus Qwertyus (talk) 19:08, 6 June 2013 (UTC)[reply]
Per User:Numbermaniac, Not entirely sure how it can be considered a "privacy violation", If you don't want the edit counter being public then don't edit on WP, It's not rocket science!. ........ →Davey2010→→Talk to me!→ 00:15, 7 June 2013 (UTC)[reply]
This is not a privacy issue. We are all responsible for maintaining the integrity of Wikipedia. Transparency is good. Carrite (talk) 06:43, 7 June 2013 (UTC)[reply]
The information is already public! The only thing one needs to work a lot to find those! --Tito Dutta (talk • contributions • email) 00:22, 8 June 2013 (UTC)[reply]
There isn't a real privacy concern here, and I'm someone that takes digital privacy more serious than they should. I see no reason not to remove opt-in. Sven Manguard Wha? 16:56, 8 June 2013 (UTC)[reply]
Suggesting an illusion of privacy with an opt-in is worse than being up front with what this data is. older ≠ wiser 17:08, 8 June 2013 (UTC)[reply]

Discussion

You need to make your opening statement clearer, explain the situation in greater detail. You say editors "want the detailed edit stats to be visible" - visible to themselves, or visible to the public? Giant Snowman 13:23, 4 June 2013 (UTC)[reply]
I don't see how it can be much clearer. There are users who don't want the opt-in and there are users who want to keep it. So I'm asking the community the simple question. Should the edit counter have the optin?—cyberpower ^Chat_Online 14:10, 4 June 2013 (UTC)[reply]
No, it's still clear as mud. Opt-in to what? Giant Snowman 14:22, 4 June 2013 (UTC)[reply]
Top Namespaces Edits and monthly statistics.—cyberpower ^Chat_Online 14:23, 4 June 2013 (UTC)[reply]
Slightly clearer - but I'll repeat, "visible to themselves, or visible to the public?" Giant Snowman 14:26, 4 June 2013 (UTC)[reply]
Removing optin means visible to the public.—cyberpower ^Chat_Online 14:28, 4 June 2013 (UTC)[reply]
I agree that you should explain it better and also add that those with x number of edits will always be opt-out. I thought anyone could opt-out by simply deleting the page created during opt-in? Also, the options above are not clear to me. What if I wanted all editors to be automatically opt-in? Mohamed CJ (talk) 14:30, 4 June 2013 (UTC)[reply]
@Mohamed CJ: "What if I wanted all editors to be automatically opt-in?" Then you would support the section "Remove opt-in and replace with Opt-out". That section is for making everyone automatically opted-in and they have the option to opt-out.—cyberpower ^Chat_Online 15:00, 4 June 2013 (UTC)[reply]

I'm still not 100% clear, can somebody else please have a go seeing as cyberpower is unable/unwilling? Giant Snowman 14:40, 4 June 2013 (UTC)[reply]
Let me try this again. Currently, all editor are required to opt themselves in to allow everyone to see additional statistics in X!'s edit counter. These are top namespace edits and monthly edit statistics. This opt-in was setup because because of a law in Germany, which toolserver is located in. Since we are migrating to labs, there are users who wish to see other users monthly stats and top namespace without that said user being looked up to have to opt-in. Therefore all data will be readily available without said users consent. The question is should we allow this or should the user still have control over what can be seen in the edit counter, that is should opt-in be removed, or should it be kept, respectively. I'm sorry if this isn't clear either. I'm trying my best to make it clear.—cyberpower ^Chat_Online 14:57, 4 June 2013 (UTC)[reply]
No, that's perfect, exactly what I was looking for! Some of us aren't as technically minded as others... ;) Giant Snowman 15:01, 4 June 2013 (UTC)[reply]
How is it a privacy concern? Anyone who has access to the database (any Toolserver user, say) can work out the most-edited-pages of a user by running the query by hand (or going through Special:Contributions). The reason for requiring opt-in is as much to preserve server resources as is it to give users the illusion that the public information is somehow not public. —Tom Morris (talk) 13:53, 4 June 2013 (UTC)[reply]
Some users wish the compilation of public data to be readily accessible. I am well aware that this is public data.—cyberpower ^Chat_Online 14:10, 4 June 2013 (UTC)[reply]

While certainly true, it doesn't mean we should just give up any attempt at privacy. There's a big difference between anyone with access to the Toolserver (or anyone who can code) being able to work something out, and anyone who can use a web browser. --Chris 14:53, 4 June 2013 (UTC)[reply]
Actually, it's not just anyone with access to the Toolserver. It's anyone with access to the API... which is everybody. —Tom Morris (talk) 15:39, 4 June 2013 (UTC)[reply]
Ok then go ahead. Someone who is not a coder, please work out the namespace totals/month counts/etc for my account. --Chris 02:45, 5 June 2013 (UTC)[reply]
It is rather time consuming, but they could do that by going through Special:Contributions and compiling the statistics by hand. Toolserver (or now Tool Labs) or API scripts are just doing what any editor with the time and inclination could do. There's nothing stopping anyone from creating an off-wiki edit counter that uses the API and shows far more detailed information than X's counter - WikiCounter for instance. I might do so on Tool Labs precisely because I'd like to play around with new fancy charting libraries. —Tom Morris (talk) 04:29, 5 June 2013 (UTC)[reply]
That link is broken.—cyberpower ^Chat_Offline 04:33, 5 June 2013 (UTC)[reply]

Thank you for proving my point. Yes the data is public, but who in the right mind would go through 20,000 edits and count them manually? Yes it would be possible for a dedicated person to work out this kind of information, that does not mean we should make their job any easier. --Chris 05:01, 5 June 2013 (UTC)[reply]
Anyone could download a mirror of the database and run a query to get the same results. It's not limit to TS tool devs.--v/r - T P 13:26, 5 June 2013 (UTC)[reply]
Yes, I completely understand that. What I am saying is that there is a big difference between someone being able to use the API, or a database dump and write a script to generate that information, and someone being able to navigate to a web page and access it at the click of a button. No, it's not perfect privacy, but it is better than nothing. --Chris 13:33, 5 June 2013 (UTC)[reply]
It was an issue on the toolserver due to German privacy laws which are bizarrely strict. Werieth (talk) 14:05, 4 June 2013 (UTC)[reply]
Correct. And I'm very strong on Privacy concerns. Maybe because I'm German too.—cyberpower ^Chat_Online 14:10, 4 June 2013 (UTC)[reply]
I am not sure what this is doing here. I don't see a comment from the user whose account X's tool is on and who would obviously have to agree to these proposed changes, and I don't see a statement from toolserver admins stating that this would be compatible with their ToS, as it was my understanding that it was for ToS purposes that this was impossible. Snowolf ^{How can I help?} 15:40, 4 June 2013 (UTC)[reply]
I also am not sure as to why, if this was a serious proposal, the English Wikipedia would get to decide what happens to a global tool. Snowolf ^{How can I help?} 15:41, 4 June 2013 (UTC)[reply]

It's not toolserver anymore. It's labs. Completely different now.—cyberpower ^Chat_Online 15:51, 4 June 2013 (UTC)[reply]
I don't think it matters if it is on the Toolserver or Labs. It's still a global tool. Snowolf's point stands. Killiondude (talk) 16:22, 4 June 2013 (UTC)[reply]
It is now completely up to the owner of the tool, as Snowolf says. This vote doesn't really matter. Prodego ^talk 18:09, 4 June 2013 (UTC)[reply]
I maintain it too. Right now I have taken up the project if moving it to labs. So it does matter. And I probably will be launching a proposal on meta or redirect a thread to here for more input globally.—cyberpower ^Chat_Offline 18:16, 4 June 2013 (UTC)[reply]
Your time would be much better spent improving and maintaining tools rather than starting discussions like this. :-) If you have coding skills, I'd strongly recommend focusing on coding. We already have enough process wonkery and meta-process wonkery. --MZMcBride (talk) 22:41, 4 June 2013 (UTC)[reply]
To address the issue of the tool's 'owner', I maintain that I inherited the and do not own them and I've taken part in the process, led by Cyberpower, to migrate these tools to labs. I've joined a team, of sorts, that Cyber has termed xlabs and so as these tools move to labs, I am abdicating any sort of psuedo ownership I gained while hosting open source tools that I didn't even design and barely maintained. I'm definitely okay with any changes to the tools as long as it's a team decision and I've address that with Cyber already.--v/r - T P 02:23, 5 June 2013 (UTC)[reply]
toolserver.org/~tparis/topedits/ lists 100 top edited pages of each namespace publicly. wikichecker.com even shows edit counts by hour of day and day of week. So the data is already public.···Vanischenu^「m/_Talk」 22:06, 4 June 2013 (UTC)[reply]
I'd have to agree with Snowolf, this should be a global discussion and not held on enwiki. Enwiki is not in charge of the other wikis. --Rs chen 7754 04:53, 5 June 2013 (UTC)[reply]
If this RfC continues to take this course, we will most likely launch a second RfC on meta before any change is applied, after a discussion with the team.

Any chance we could make it opt-out only for en.wp users? I only ask because meta moves slower than a snail with a brain injury when it comes to policy discussions. Beeblebrox (talk) 03:17, 6 June 2013 (UTC)[reply]

Based on what I'm looking at right now, it doesn't look there's going to be an opt at all. Besides, the change won't go into effect until at least the tools are migrated, debugged, and fully set up.—cyberpower ^Chat_Offline 03:49, 6 June 2013 (UTC)[reply]

Preferences-Browsing-Navigation popups

I just disabled my popups. I think someone is diddling with them, as of within the last hour, and it wasn't working for me. Instead of the popup happening where my pointer was, the popup started appearing as a narrow vertical sidebar on the far right of the screen. It was less intrusive. However, what the change did was make it impossible to go on the popup to disable it. I could get to "popup", but when I moved the pointer to click on "disable", it totally flipped and ran lengthwise and I never figured out where "disable" went to. Somewhat annoying. — Maile (talk) 15:52, 4 June 2013 (UTC)[reply]

The gadget hasn't been changed since 11 january. —TheDJ (talk • contribs) 16:06, 4 June 2013 (UTC)[reply]

Interesting. Well, whatever caused it, I think I can live without the gadget. Thanks for your quick reply. — Maile (talk) 16:25, 4 June 2013 (UTC)[reply]

Edit counter problem

When I go to X!'s Edit Counter for myself here, it shows that I have no deleted edits, which I most certainly do. (Not that I'm bragging about having deleted edits.) I use IE10 to edit, but I also have Google Chrome. When I put the URL into Google Chrome, the exact same thing happened. öBrambleberry of RiverClan 15:55, 4 June 2013 (UTC)[reply]

See #Toolserver issues above. Giant Snowman 16:01, 4 June 2013 (UTC)[reply]

Need help at Template:Commons and category-inline

I've noticed that Template:Commons and category-inline does not allow two parameters to list the Commons Page and Category, when they are not the same, such as Commons:Automobile and Commons:Category:Automobiles. The companion template, Template:Commons and category, does allow the two parameters. Since I have yet to figure out how to modify the template to make it work, would someone who is really good with templates be able to add this functionality to this template? Thanks much in advance! --Funandtrvl (talk) 18:21, 4 June 2013 (UTC)[reply]

I've made the change. It should now work as expected. — Edokter (talk) — 18:44, 4 June 2013 (UTC)[reply]

Wonderful!! --Funandtrvl (talk) 19:28, 4 June 2013 (UTC)[reply]

One problem, I updated the /doc page, because the 2nd parameter (Commons category) does need to be specified, if it is not the same as the default, which is the PAGENAME. Both templates seem to work this way, maybe the default for the second parameter should be the 1st parameter, if nothing else is specified, instead of PAGENAME. --Funandtrvl (talk) 19:57, 4 June 2013 (UTC)[reply]

I thought the first sentence summed that up pretty well. — Edokter (talk) — 20:36, 4 June 2013 (UTC)[reply]

Permanent reflist

Hi.

Is it possible to add a permanent {{Reflist}} below my main edit box, so that even when I edit a section, I can see how references look like?

Best regards,
Codename Lisa (talk) 18:36, 4 June 2013 (UTC)[reply]

The way that you can do that now is just add in a {{Reflist}} to the article section you are editing, preview it to see how the refs look, and then remove it before you save your edit. postdlf (talk) 18:41, 4 June 2013 (UTC)[reply]

Yeah, it just needs a round of add and previewing, and a round of removing which can be forgotten, with catastrophic results. Thanks for the hack, which I knew by the way. Can we please stay on topic? Best regards, Codename Lisa (talk) 20:18, 4 June 2013 (UTC)[reply]

Yes, that should be possible, although it might be better to require a mouseclick to do it (more like an in-line page preview with a built-in reflist). Writ Keeper ⚇♔ 20:34, 4 June 2013 (UTC)[reply]

You will still not be able to see named references which were defined in other sections. A better solution is User:Anomie/ajaxpreview.js. -- Gadget850^talk 20:59, 4 June 2013 (UTC)[reply]

Thanks. Best regards, Codename Lisa (talk) 21:15, 4 June 2013 (UTC)[reply]

What I would like is not a permanent reflist, but a "Preview w/ reflist" button. I am constantly adding a {{reflist}} to check refs, then have to remove it, and once in a while forget to, which in more highly trafficed articles splats some number of users with a big red error. ~ J. Johnson (JJ) (talk) 20:52, 7 June 2013 (UTC)[reply]

Module:Infobox is now live

I have just now put Module:Infobox up live on the English Wikipedia. Please keep an eye out for any bugs, and report them to Template talk:Infobox. And a big thanks to Toohool for writing the code, and for WOSlinker for helping me to test it. — Mr. Stradivarius ^{♪ talk ♪} 09:35, 5 June 2013 (UTC)[reply]

It's clear from Template talk:Infobox that this has worked very well. Congratulations to all involved! -- John of Reading (talk) 07:00, 7 June 2013 (UTC)[reply]

Interesting Edit conflict failure.

I removed a comment of J with this edit. I got an edit conflict, but it only showed a blank line added a paragraph or so above my post but it did not show J's post. AutomaticStrikeout restored the comment with this edit a short while later. So, somehow I got what I thought was a "fake" edit conflict, but it wasn't and removed the previous editor's comment. Technical 13 (talk) 12:34, 5 June 2013 (UTC)[reply]

(edit conflict) (conflict against new thread added below during edit-preview)

Some edit-conflicts are false, so re-run a Show-changes diff: Some edit-conflicts are correctly noted, but others are not, and re-running a "Show changes" can pinpoint the differences, plus check the recent history, such as with "limit=5" to list the prior 5 revision entries. I wish the "fake edit-conflicts" were just pilot error, but unfortunately, we have massive evidence that Wikipedia's edit-screen interface is broken, and needs to be fixed not abandoned, like having a bus where the doors do not open at some bus stops, and just buying a new bus with a simple door, rather than fix the original bus. I am hoping people can see that changing Wikipedia into a WYSIWYG "chalkboard simulator" is not the way forward, because pages, including talk-pages, are word-processing documents which use a macro scripting language where what-you-see ("WYS") is the template call or function call or calculation, and what-you-get ("WYG") is the computed result of calculating/typesetting the template's output. The WYSIWYG interface is better for young children, who want to scrawl on a chalkboard and edit at that level, whereas Wikipedia can support adults who use transformations of macros into text which does not appear in the original language, such as {{convert|45|ly|km mi}} yielding "45 light-years (4.3×10¹⁴ km; 2.6×10¹⁴ mi)" where the word "light-years" does not even appear in the input data. Anyway, the path forward is to fix edit-conflict, to fix the bus doors to open at every stop for every passenger, not get a new bus with a simple, small door which does not allow passengers to carry packages (or babies) onto the bus. -Wikid77 (talk) 13:40, 5 June 2013 (UTC)[reply]

Screenshots in talkpage discussion

With the usual apologies-with-humble-request-to-be-directed-elsewhere-if-this-isn't-the-right-place: I am involved in a discussion of how certain markup affects line breaks and text justification in the final, formatted version of articles seen at various zoom levels and so on. How would I insert screenshots into the discussion? It seems weird to upload images to the Wikipedia-never-forgets image repository (alongside the Mona Lisa and so on) for this self-referential purpose -- or would that be that OK? EEng (talk) 13:27, 5 June 2013 (UTC)[reply]

I've found uploading them to commons is the norm. I believe there is a category to tag them with if you upload them to enwiki and am not sure if there is such a thing on commons. Technical 13 (talk) 14:27, 5 June 2013 (UTC)[reply]

Uploading such images to commons makes no sense at all, as there is no way they could be useful to another project where the talk page discussion is not taking place. Just upload them locally.—Emil J. 14:59, 5 June 2013 (UTC)[reply]

I've actually used one to describe extension/core problems to devs on mw: before, so saying there is no way they could be useful elsewhere is stretching the box pretty thin... Technical 13 (talk) 15:29, 5 June 2013 (UTC)[reply]

Commons is, as T13 says, the norm--from Wikipedia:Software screenshots, if the screenshots are of free software (which wikipedia is, sans logo), they should be uploaded to Commons. When you upload them to Commons, be sure to tag them with commons:Template:Wikipedia-screenshot, which includes the Wikimedia logo caveat. Theopolisme (talk) 15:50, 5 June 2013 (UTC)[reply]

The page you linked to (which, anyway, is not even a guideline) is irrelevant. It discusses screenshots of software to be used as illustrations in articles on said software. Of course these belong to commons, just like most other media used in articles, barring legal issues. The OP is talking about something completely different: screenshots of a Wikipedia article used in a discussion on its talk page related to formatting changes in the article.—Emil J. 17:11, 5 June 2013 (UTC)[reply]

Precisely. While in principle article Talk discussions are filed away along with everything else in the Giant Grand Complete History of How Wikipedia Got This Way, a screenshot that's part of a minor side discussion on one article will be of no lasting use (especially the one I will be needing in the present situation -- I assure you) and since images are way larger than text one just wonders if there's somewhere to put such a screenshot such that it will silently evaporate sometime in the middle future. Otherwise, Emilj, by "locally" do you mean to en-wikipedia, or do you mean something else? EEng (talk) 18:20, 5 June 2013 (UTC)[reply]

I meant to English Wikipedia, yes.—Emil J. 20:06, 5 June 2013 (UTC)[reply]

Just use a third-party service like imgur, then. Theopolisme (talk) 23:53, 5 June 2013 (UTC)[reply]

What's wrong with me? Of course. Thanks. EEng (talk) 00:11, 6 June 2013 (UTC)[reply]

On concern regarding external hosters: Sooner or later they delete graphics and while it might seem some simple screenshots will never ever be needed again, nothing is more frustrating than finding an archived discussion (that seems relevant to a problem oneself might have one day) with all images unavailable and therefore being not understandable anymore. --Patrick87 (talk) 08:05, 6 June 2013 (UTC)[reply]

"Sign your posts on talk pages"

Considering that many new users get confused by this, I think it would be worthwhile to no longer display it in mainspace, as I've suggested here. I'd like to know how this can be done in js, along with linking. Thanks, Cenarium (talk) 17:09, 5 June 2013 (UTC)[reply]

Suppressing rulespam for everyone or user option: In general, the wp:rulespam has grown like kudzu, and the whole system needs to reduce the rulespam to a few lines and instead start wikilinking to rule-blurb pages, such as see: "wp:Explain PUMPTECH rules" rather than fill the screen with the same tired "rants" of issues to consider before replying. However, meanwhile, we need to help users suppress the messages, such as "Sign your posts on talk pages" etc. I also wonder how to suppress the View-Source diatribe ("You do not have permission to edit this page..."), which spans almost 2 screens of text, when trying to edit a protected page. -Wikid77 (talk) 21:18, 5 June 2013 (UTC)[reply]

the above rant seems somewhat disconnected from reality. i include the subject of this discussion, i.e. the standard talk page editnotice here, to aid the discussion:

This is a talk page. Please respect the talk page guidelines.

where exactly do you see rulspam? in reality, this does exactly what you preach: it provides a link to a more elaborated policy page explaining talkpage guidelines, and very little else. i do not have strong opinion regarding the comment about the signature myself: if signbot is active on main talk space, i think it can be probably dropped without too many repercussions. however, using this lean and mean editnotice as an excuse for this long sermon seems slightly out of place. peace - קיפודנחש (aka kipod) (talk) 23:05, 5 June 2013 (UTC)[reply]

The proposal is about dropping the "Sign your posts on talk pages" bit when editing articles rather than article talk pages. – PartTimeGnome (talk | contribs) 23:24, 5 June 2013 (UTC)[reply]

I think the original poster is referring to the item in "edittools", i.e. the business that appears below the edit box:

– — ° ″ ′ ≈ ≠ ≤ ≥ ± − × ÷ ← → · § Sign your posts on talk pages: ~~~~ Cite your sources: <ref></ref>

There is already a discussion on this at MediaWiki talk:Edittools. — This, that and the other (talk) 09:41, 6 June 2013 (UTC)[reply]

this, of course, makes perfect sense. there may be other markups which should be namespace dependent: e.g., "ref" and "reflist" on article space only, "noinclude" and "includeonly" on template space only, and maybe a couple others. i do not think edittools is currently clever enough to take the namespace into account, but it's pretty straightforward thing to teach it to do so. קיפודנחש (aka kipod) (talk) 18:58, 6 June 2013 (UTC)[reply]

<ref> and {{reflist}} are often used on talk pages. <includeonly> is used in Fetured Lists to trancslude the lead onto Wikipedia:Today's featured list. Gadget850^talk 20:37, 6 June 2013 (UTC)[reply]

{{shrug}}. did not try to say that these wikicodes are never used outside their "natural habitat". i still think that "ref" and "reflist" are more likely to be used by mistake than intentionally outside article space, and "includeonly" and "noinclude" are more likely to be used mistakenly outside of template namespace. removing them from the charinsert box will not prevent anyone from using them - it will just remove a probably-not-what-you-meant button from the box. i can continue to live peacefully with them there on all spaces (just as i lived with the signature button in article space...) - i merely commented that teaching edittools to display a namespace-dependent list may have more uses, in addition to removing the sig button. peace - קיפודנחש (aka kipod) (talk) 21:24, 6 June 2013 (UTC)[reply]

Could a JS-savvy person or two please take a look at my post? — This, that and the other (talk) 08:12, 7 June 2013 (UTC)[reply]

Citations button not working

There is a "Citations" button next to the "Show changes" button when editing. It invokes a bot and I presume it is supposed to help with completing citations. At present it is adding an "f" character to the beginning of the edit buffer... Mirokado (talk) 22:16, 5 June 2013 (UTC)[reply]

The "Citations" button you refer to is enabled at Special:Preferences#mw-prefsection-gadgets with "Citation expander: Automatically expand and format citations (uses "Citation bot")." The added "f" is discussed at User talk:Citation bot#The bot is trying to add an f word with every edit. PrimeHunter (talk) 22:39, 5 June 2013 (UTC)[reply]

Thanks! I'd forgotten all about that option. --Mirokado (talk) 22:44, 5 June 2013 (UTC)[reply]

Did some major glitch just happen?

My skin was changed, all my preferences are different and my giganto watchlist has disappeared. Before My Ken (talk) 23:25, 5 June 2013 (UTC)[reply]

Also, the latest edit shown in my contributions is from 2009. It looks like we're working from a back-up? Before My Ken (talk) 23:30, 5 June 2013 (UTC)[reply]

I haven't noticed anything. Your account hasn't edited since 2011 and its user page redirects to User:Beyond My Ken. Did you log in to the wrong account? PrimeHunter (talk) 23:31, 5 June 2013 (UTC)[reply]

Yes, I did, and I just discovered it seconds ago. I think that I got logged out on Commons and logged back in there using the wrong account. So sorry for bothering everyone. Beyond My Ken (talk) 23:34, 5 June 2013 (UTC)[reply]

kml option has stopped working

The {kml} option, which normally shows a number of pins representing geographical features overlaid on google maps, appears to have stopped working. I have tried the ones on River Welland, Huddersfield Broad Canal and River Don Navigation and all now report "No geocoded items found", and show a google map of the whole world. Is this the right place to report this. I cannot find anywhere else to do so. Regards. Bob1960evens (talk) 14:46, 6 June 2013 (UTC)[reply]

It now appears to be working again. Bob1960evens (talk) 22:01, 9 June 2013 (UTC)[reply]

stats.grok.se /en server issue

On all pages, I've been getting "internal server error" on stats. Only on stats. I have Firefox 21.0, so when I go to Tools/Web Developer/Page Source, that also flips to "internal server error" — Maile (talk) 15:38, 6 June 2013 (UTC)[reply]

Fixed - Henrik has resolved this. — Maile (talk) 21:44, 6 June 2013 (UTC)[reply]

Modern skin-Preferences-Gadgets tab is gone

~~My WikiEd disappeared between edits, so I went to find Gadgets...gadzooks!, it's gone, too~~. — Maile (talk) 17:06, 6 June 2013 (UTC)[reply]

And now it's all back. — Maile (talk) 17:08, 6 June 2013 (UTC)[reply]

Captcha

There's been an outbreak of trolling at the Reference desk lately, and this post on the Help desk made me suspect it's spreading. A quick archive search revealed at least one previous similar complaint here back in 2008; however, the problem then was caused by an unfortunate conjunction of two innocuous words. If two proper dictionary words are still required, I can't see how the current reported captcha could possibly have been produced, but I don't know for sure. Before I stop assuming good faith with our questioner, can anyone here look at the alleged captcha wording and tell me categorically whether or not the system could have generated it? - Ka renjc 20:25, 6 June 2013 (UTC)[reply]

Don't bother - the latest contributions by Sawwooddoow (talk · contribs) show that this is another troll. -- John of Reading (talk) 20:32, 6 June 2013 (UTC)[reply]

Thanks. It looked like a duck, and sounded like a duck, but it was good to hear the quack. - Ka renjc 16:57, 7 June 2013 (UTC)[reply]

I agree that looks like trolling, but for future reference, it is indeed two completely random English words. I've seen some that could be strange or offensive, and apparently so have other people... [4], [5], [6] Steven Walling (WMF) • talk 17:23, 7 June 2013 (UTC)[reply]

VisualEditor weekly update - 2013-06-06 (MW 1.22wmf6)

Hey all,

Here is a copy of the regular (now every week) update for the VisualEditor project. This is so that you all know what is happening, and make sure you have as much opportunity to tell us when we're wrong and help guide the priorities for development and improvement:

VisualEditor was updated as part of the wider MediaWiki 1.22wmf6 branch deployment on Thursday 6 June. In the ten days weeks since 1.22wmf5, the team worked on new features ahead of VisualEditor's launch as the default way users will edit our wikis in beta.

The most noticeable change for users is that it is now possible to set, edit and remove the categories that a page belongs to and it's "default sort" key, as part of the new "page settings" dialog that can be opened from the button on the toolbar. For now, this dialog covers categories and a simple listing of language links, but will be expanded to cover other "meta-data" like a page having the table of contents disabled, and integration with Wikidata's language links system. Work also continued on the other three critical areas ahead of the release - Templates, References and Images - and we hope to release these in the next week or two.

The way that known browsers are supported changed slightly; browsers are now only blacklisted if we know that they cause significant problems, like Internet Explorer version 8 and below. If your browser is not known, you will get a notice alerting you to this issue (38128). We have added further support in our back-end for multi-character "grapheme clusters", which means that wikis that use extended ("non-BMP") Unicode characters can now work (48975). The left and right arrow keys now move in the correct direction in RTL environments (38546).

A complete list of individual code commits is available in the 1.22/wmf6 changelog, and all Bugzilla bugs closed in this period on Bugzilla's list

Per the MediaWiki deployment roadmap, this should be deployed here on Thursday 13 June.

Hope this is helpful! As always, feedback gratefully received, either here or on the enwiki-specific feedback page.

Jdforrester (WMF) (talk) 22:07, 6 June 2013 (UTC)[reply]

Why is there a difference I cannot see?

See this edit. The diff demonstrates a real difference that I cannot see. Is there a hidden character, or another character that looks identical but is not so in fact? I've just requested some category moves and I want to make sure these all end up in the right place. -- Ohc ^¡digame!_{¿que pasa?} 03:23, 7 June 2013 (UTC)[reply]

Which browser where you using? I can't see a difference either, and I'm in Chrome 27 on Windows XP. -- ^(T)Numbermaniac_(C) 03:26, 7 June 2013 (UTC)[reply]

It's probably a different character format. Differences of any kind will ring up as a diff. Even of its the format.—cyberpower ^Chat_Offline 03:32, 7 June 2013 (UTC)[reply]

I find a hidden character at the end of the old version. The program I'm using calls it ASCII 26 (substitute character), but that may just be my program's way of saying "I don't know". Dragons flight (talk) 03:40, 7 June 2013 (UTC)[reply]

Thanks. I had a suspicion about this, and tried replacing the characters one after another. Only by changing the last character did my regex tester react. I baffled as to how that "I don't know" got there. Humpf! :-( -- Ohc ^¡digame!_{¿que pasa?} 03:48, 7 June 2013 (UTC)[reply]

It's a Unicode Left-to-right mark (U+200E). It occurs where the * is in "(Bundesliga*|Liga)/gi, '$1$2')". Johnuniq (talk) 03:50, 7 June 2013 (UTC)[reply]

Thanks for the pointers. What enables you to see it? Just curious to know if there are any more such characters in my scripts – I occasionally get surprising 'failures' but with no apparent errors. -- Ohc ^¡digame!_{¿que pasa?} 05:56, 7 June 2013 (UTC)[reply]

Each row of a watchlist starts like this: (diff | hist) . . Example title*; 06:51 . .

The LTR (left-to-right mark) is just after the title (where * is shown). There are a total of four LTRs on each watchlist row—I don't know the details, but they are used to say "what follows is left-to-right text", and are presumably used because in some cases the preceding text might have been right-to-left. If you highlight and copy "Example title" you might accidentally also copy the LTR. That's often how it ends up in places where it should not be. I can see it because I use one of the many text editors that can show stuff like that (and I have a simple script that uses wget to get a particular revision of a page which I can use to perform a diff locally).

If you put a list of page titles here or on my talk, I will check them for non-printable characters. Johnuniq (talk) 07:19, 7 June 2013 (UTC)[reply]

On the test Wikipedia I once made a gadget (pretty outdated, don't use it) to expose evil hidden Unicode characters in the editing window, by temporarily converting them to HTML entities. It was pretty easy to copy/paste existing functions from it and other stuff to make a similar script at User:Splarka/diffreveal.js to show invisible Unicode in diffs (via history or "Show changes" button). The diff above shows as Bundesliga[U+200E] with it, for example. It could be adapted pretty easily to various needs. --Splarka (rant) 09:18, 7 June 2013 (UTC)[reply]

if you use chrome, i found the "Unicode Analyzer" extension 100% unobtrusive, and occasionally useful. it allowed me to see the problem in the very first diff (in first post) almost immediately. peace - קיפודנחש (aka kipod) (talk) 14:58, 7 June 2013 (UTC)[reply]

Here's my technique. In the Wikipedia diff, copy the mystery text to your copypaste buffer, making sure that you also get a few extra characters at the start and end - this is to ensure that you get all the invisibles. Then go to Unicode Code Converter v7.05, and paste your text into the "Mixed input" green box. Then click the "Convert" button immediately above - all the grey boxes will then get filled in, in different ways. If I do this, the "HTML/XML" second grey box shows ll-(Bundesliga‎|Li - I then append that Unicode hex value to http://www.charbase.com/ giving http://www.charbase.com/200E for information about the character. For some reason, this technique doesn't work for diffs containing a   - they get decoded as regular spaces. --Redrose64 (talk) 19:18, 7 June 2013 (UTC)[reply]
I guess you're using Firefox... Converting NBSP into a regular space in form fields is a very long-standing bug in Firefox (over 10 years old). It's why you sometimes see users make edits that change NBSPs into regular spaces if they're not ampersand-encoded. See bugs 194498 and 359303. – PartTimeGnome (talk | contribs) 21:21, 7 June 2013 (UTC)[reply]

Firefox and NBSP have an interesting inconsistent relationship. In FF20.0, I can currently edit forms containing them, paste them in, input them manually, and submit/save them. But, I can not copy them from Firefox's markup, forms, or javascript windows (prompt('nbsp','\u00a0');). This makes sense for most use cases, but is inconsistent with how other browsers work. --Splarka (rant) 22:46, 7 June 2013 (UTC)[reply]

HotCat / CatScan / AWB

I have used CatScan to find X number of articles that I want to add a new category to. Is there an easy way to add the category to all of the relevant articles usind HotCat or AWB? Or do I have to manually add to each and every article, which may be 100 or so and will obviously be a boring and time-consuming task. Giant Snowman 09:27, 7 June 2013 (UTC)[reply]

You can probably do it with AWB... It has the ability to pull all of the members of a category, save that list to a file, pull the members of a second category, compare the two and only keep the ones in both categories. It would be helpful if I knew what your CatScan query was... Technical 13 (talk) 11:35, 7 June 2013 (UTC)[reply]

I did it quickly late last night, but it was searching through Category:English football managers for all articles that are also in the subcategories of Category:Expatriate association football managers by country of residence. All relevant articles are therefore eligible for inclusion in Category:English expatriate football managers - and I intend to repeat it for all relevant nationalities. Giant Snowman 11:42, 7 June 2013 (UTC)[reply]

Yeah, you can do that with AWB... If you need someone to do it for you... Wikipedia:AutoWikiBrowser/Tasks is the place to ask. :) Happy editing! Technical 13 (talk) 13:15, 7 June 2013 (UTC)[reply]

Thanks, I'm not super-savvy with AWB (i.e. I keep to the basics!) but I'll have a play around. Thanks. Giant Snowman 13:18, 7 June 2013 (UTC)[reply]

To get your list for the subcategories of Category:Expatriate association football managers by country of residence you'll have to use a "recursive category" search. When I did it, I found that there are about 2550 pages in those sub-categories. When I cross referenced it with the Category:English football managers there was about 1250 articles in both... Technical 13 (talk) 13:23, 7 June 2013 (UTC)[reply]

Hmm, I'm sure my CatScan brought back just under 100 articles. One of us must be wrong! Giant Snowman 13:25, 7 June 2013 (UTC)[reply]

I'm not convinced that CatScan is accurate. I've never had any luck using it. Anyways, yes, one of our methods is wrong. :) Technical 13 (talk) 13:41, 7 June 2013 (UTC)[reply]

i am not 100% sure i understand what you are trying to do, but from what i saw, cat-a-lot is the ideal tool for the job. you might want to look at it (see Wikipedia:WikiProject User scripts/Scripts). it's a very powerful category-manipulation tool that was developed in commons. initially it operated on files only, but now it can handle any page. be warned - i did not test it in a while, and it's possible that one of the recent version upgrades broke it. if you do try it and find problems, please report (and, actually, i would also appreciate a report if you use it and find it useful). peace - קיפודנחש (aka kipod) (talk) 14:50, 7 June 2013 (UTC)[reply]

Module:String technical help requested

Hello all, I've posted a question at Module talk:String#Help needed and am hoping to get some help... If you know anything about the Module or Lua in general, please check it out. Thanks. Technical 13 (talk) 18:15, 7 June 2013 (UTC)[reply]

A question about notifications

I have a question about the new notification system. When I receive a notifcation saying that a certain article has been linked, who actually gets that notification? Everyone who ever edited the article? A certain number of editors with the largest number of edits to the article? Editors who expanded the article a certain amount? A certain number of recent editors? What's the criteria? Beyond My Ken (talk) 18:25, 7 June 2013 (UTC)[reply]

Hello Beyond My Ken. If you go to Preferences → Notifications and mouse-over the little question-mark icon it will tell you "Notify me when someone links to a page I created from an article page." Technical 13 (talk) 18:31, 7 June 2013 (UTC)[reply]

Ah, thank you. I somehow didn't recognize some of the articles as ones that I had created. Beyond My Ken (talk) 20:33, 7 June 2013 (UTC)[reply]

Redirects you create that someone else expands into articles also count as articles you created. – PartTimeGnome (talk | contribs) 21:37, 7 June 2013 (UTC)[reply]

Ah! That helps too!

And speaking of redirects, is there anyway to redirect notifications from my old IDs to my current one? Beyond My Ken (talk) 21:55, 7 June 2013 (UTC)[reply]

Hmm. Not that I know of, but it would be an interesting form of wikistalking if I were able to, say, see anytime User:Beyond My Ken is linked. Perhaps that's why following other usernames beside the one you're logged in to is not supported Killiondude (talk) 21:02, 8 June 2013 (UTC)[reply]

Good point. I've solved the problem by setting notifications on the old account to got to e-mail, so I'll see them that way (if there are any). Beyond My Ken (talk) 22:49, 8 June 2013 (UTC)[reply]

Status update no longer in contributions?

I used to see User:Vchimpanzee/Status in my contributions, and still do for earlier "edits", but today it's not there. That scared me but I checked my profile page and it's properly updated. Some days I forget to do it. Some days I turn off my computer and I'm still "online" for days. While I'm here, Is there a possible way to change that to "offline" just by the mere fact I'm no longer "signed in" once my computer is off? Or vice versa?— Vchimpanzee · talk · contributions · 20:32, 7 June 2013 (UTC)[reply]

I see your last update in both your contributions and the page history as 5 June at 18:09 (UTC). At present your user page says "Online", which matches what I see in the Status subpage.

It isn't possible for you to update the page when your computer is off. A bot running on another computer could do it if there was some mechanism to remotely check your computer is on (e.g. a program on your computer that stays in contact with the bot). However, this is a somewhat over-engineered solution. – PartTimeGnome (talk | contribs) 21:35, 7 June 2013 (UTC)[reply]

Why is my status update not in my contributions, then? And I am offline now after I submit as I have things to do.— Vchimpanzee · talk · contributions · 21:39, 7 June 2013 (UTC)[reply]

Wait, I don't show myself updating my status Wednesday. That's it.— Vchimpanzee · talk · contributions · 21:42, 7 June 2013 (UTC)[reply]

(edit conflict) When you log in to Wikipedia, a cookie is set on your computer. That cookie is sent back to Wikipedia whenever you request any page, or you send an edit. The only way that Wikipedia knows that you're logged in is if it receives that cookie along with the page request; so technically speaking, you're logged out all the time except for the few milliseconds that it takes to retrieve a page. --Redrose64 (talk) 21:47, 7 June 2013 (UTC)[reply]

Image?

Why is the image in this DYK nom showing up as a picture of Charlieissocoollike?--Gilderien Chat|List of good deeds 22:08, 7 June 2013 (UTC)[reply]

I see File:ZhangZiyi Amfar.jpg with a woman in a black dress. Are you saying you see an image of the man Charlieissocoollike instead? PrimeHunter (talk) 00:43, 8 June 2013 (UTC)[reply]

Yes. However, it is squashed in from the sides and also not in the article.--Gilderien Chat|List of good deeds 16:54, 8 June 2013 (UTC)[reply]

I suspect that your browser is stubbornly ignoring the true file content and is displaying a locally-cached copy which has the same filename. Try a WP:BYPASS. --Redrose64 (talk) 19:19, 8 June 2013 (UTC)[reply]

Thank you, it is now showing the correct image.--Gilderien Chat|List of good deeds 22:55, 8 June 2013 (UTC)[reply]

Regex

Hi I would like to replace every parameter containing specific word with something else. However I can't mange to build my Search string. For example I want to pick all those parameters:

{{{abcNAMEasd|}}}
{{{NAMEefg|}}}
{{{hijNAME|}}}

I obviously start with \{\{\{ and end with \}\}\}, but I can't figure out the look up. Please help. 79.176.217.170 (talk) 03:48, 8 June 2013 (UTC)[reply]

It sounds like you want this: {{{.*?NAME.*?}}}. And you don't need to escape curly braces in regex. Best — Mr. Stradivarius ^{♪ talk ♪} 05:14, 8 June 2013 (UTC)[reply]

Thanks, it works but still too inclusive, for example it will catch this as well:

{{{SomeOtherCarp|}}}
{{{abcNAMEasd|}}}

also I do need escape curly braces, at least in the variant used in notepad++ ;) --79.176.217.170 (talk) 05:42, 8 June 2013 (UTC)[reply]

Actually your variant works, I just changed the first any character to char, which fits my needs. Thanks. (btw have fun in mediations ;) ) 79.176.217.170 (talk) 05:52, 8 June 2013 (UTC)[reply]

Ah yes, you need to disallow brackets from the match, like this: {{{[^{}]*?NAME[^{}]*?}}}. You can play around with disallowing different characters to suit your situation as well. And thank you. :) — Mr. Stradivarius ^{♪ talk ♪} 06:05, 8 June 2013 (UTC)[reply]

Elections banner is buggy

We're bound to get complaints about the latest WMF banner "Votes are now being accepted for the Board of Trustees and Funds Dissemination Committee election. Click here to read about the candidates and vote. [ Help with translations! ]" (it's elections, not fundraising, but people will still complain) so I'll kick it off. It's buggy: the cross-in-circle icon closes it as expected; but then it then immediately takes you to meta:Wikimedia Foundation elections 2013. It's not a problem specific to en.wp, since it happens at commons: and fr: too. I'm willing to bet it's not a something to bother bugzilla with, so does anybody know where the relevant file-a-bug page is? --Redrose64 (talk) 09:17, 8 June 2013 (UTC)[reply]

Not sure about the bug-filing page, but the notice is using m:Special:CentralNotice, so some place on Meta would be a good start. Maybe m:Meta:Requests for help from a sysop or bureaucrat? — Mr. Stradivarius ^{♪ talk ♪} 09:47, 8 June 2013 (UTC)[reply]

OK, thanks; from that first link I found Elections_voting_open in which was m:Special:CentralNoticeBanners/edit/Election2013 voting starts and looking at the logs I saw who last modified it, so I posted to their talk page. --Redrose64 (talk) 10:27, 8 June 2013 (UTC)[reply]

Thanks Redrose, I'm looking into this. It may be that the 'box' around that circle isn't big enough and so it thinks you're clicking both the circle and the link at the same time. Jalexander--WMF 22:03, 8 June 2013 (UTC)[reply]

That should be better now, I expanded the invisible 'box' that is the close link and tested on a couple browsers. If anyone has other issues let me know. Jalexander--WMF 22:29, 8 June 2013 (UTC)[reply]

Hidden audio file links

Can someone take a look at Template talk:Infobox IPA#Hiding the linkage. I'm worried that templates are once again managing to hide links to info about audio files.

The importance of additional linkage for audio file templates has been discussed several times before.

"Clean" audio templates with nothing but a play button and no other links shouldn't even be contemplated since they violate our own conditions concerning licensing and information about the creators.

Peter ^Isotalo 15:59, 8 June 2013 (UTC)[reply]

Are thousands of people a day not finding the articles they want?

Over at WP:Topred, which lists the most popular weekly redlinks, there are a lot of entries with complicated and repeated codes. For example, the current #13 is Michael Bubl\xC3\xA9, with 19,135 hits. Is this a likely result of 19,000+ attempted but failed human views of the article Michael Bublé? If so, is anyone aware of a technical solution, so that all articles with complicated characters, such as "é", can have redirects created for them? Thanks. Biosthmors (talk) 10:22, 9 June 2013 (UTC)[reply]

Those seem to be badly encoded URLs, probably originating from malformed links on some website(s). Not much we can do about that. — Edokter (talk) — 10:27, 9 June 2013 (UTC)[reply]

I do not think that creating thousands of redirects for cases like this and that is a right way, because they would become expensive to watch and complicated to maintain (especially in the case of a merge–unmerge cycle). If some definite pattern can be detected, such as these URLs with non-standard hexadecimal escapes, and there are substantiated expectation that it will persist, then developers should consider some URL rewrite built into the engine. If it is a glitch caused, say, by some version of a browser or some version of a CMS, which are expected to be fixed soon, then the right way is just ignore. It is not our problem. Incnis Mrsi (talk) 10:38, 9 June 2013 (UTC)[reply]

WP:Topred is currently dominated by entries containing \x. In the cases I examined, it was a percent encoding of a real title with each % incorrectly replaced by \x. For example, "Michael Bubl\xC3\xA9" in a url would be the incorrect http://en.wikipedia.org/wiki/Michael_Bubl\xC3\xA9 while the correct percent encoding is http://en.wikipedia.org/wiki/Michael_Bubl%C3%A9. The 12 May list [7] had no entries containing \x so it seems like a recent problem (some of the older lists had a limited number of \x entries). I agree it's too soon to think about creating redirects from the invalid encodings. PrimeHunter (talk) 11:21, 9 June 2013 (UTC)[reply]

As Incis hinted, this looks like a bug in code/script to in-line Wikipedia content (and perhaps the high numbers are caused by automatic re-attempts upon failure). What would be really interesting is to see if these redlink cases are being driven by a single or small set of IP addresses. While that would be fun, we shouldn't expect the analytics team to help us with this due to the privacy issues involved. Thanks, West.andrew.g (talk) 13:06, 9 June 2013 (UTC)[reply]

I've seen issues like this with Toolserver tools, but I can't reproduce it so far with Firefox 21 or MSIE 10. Maybe someone using an older version of MSIE could try the links with accented letters on http://toolserver.org/~dpl/ch/dab_challenge.php ? GoingBatty (talk) 17:30, 9 June 2013 (UTC)[reply]

A proposal to solve the problem with unequal height of rows

I propose to change the flagicon size from default 22x20 pixels to 24x15 pixels in the fully protected Template:Flagicon/core.

Default flagicon size 22x20 pix maximum

Italy	22x15
Spain	22x15
Switzerland	20x20
France	22x15
Belgium	22x15
Nepal	20x20
China	22x15
Vatican City	20x20
United Kingdom	22x11
Australia	22x11
Canada	22x11
Cuba	22x11

Flagicons with proposed size 24x15 pix maximum

Italy	23x15
Spain	23x15
Switzerland	15x15
France	23x15
Belgium	23x15
Nepal	15x15
China	23x15
Vatican City	15x15
United Kingdom	24x12
Australia	24x12
Canada	24x12
Cuba	24x12

So, as you can see on this example, the first table looks ugly because of oversized flags of Switzerland, Nepal and Vatican. Please post your remarks on the talk page Wikipedia talk:WikiProject Flag Template. Thanks. Maiō T. (talk) 13:50, 9 June 2013 (UTC)[reply]