Misplaced Pages

This is an old revision of this page, as edited by Ironholds (talk | contribs) at 00:27, 5 June 2013 (→TALK2: Talk-pages with paragraph edit: err). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

• Table of contents
• First discussion
• End of page
• New post

• WP:VPT
• WP:VP/T
• WP:TECHPUMP
• WP:PUMPTECH

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: Misplaced Pages:Technical FAQ) Click "" 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 Misplaced Pages services, see Reporting a connectivity issue.

Village pumps

policy

tech

proposals

idea lab

WMF

misc

• Refining the administrator elections process
• Blocks for promotional activity outside of mainspace

• view
• edit
• history
• watch
• archive
• talk
• purge

Cropping DNB for name variations (redirects)

First let me say I'm not a programmer, so don't beat me for suggesting something infeasible. :) But anyway, he's my thought:

Consider the article Maimonides for instance. At the bottom, via {{Authority control}}, it is connected to this GND/DNB profile (DNB as in Deutsche Nationalbibliothek). As you can see, the DNB profile lists a couple of dozens of alternative spellings of Maimonides' name. So I was thinking how great it would be if the Misplaced Pages software would automatically extract these name variants and create redirects to the actual article (not just to Maimonides, of course, but to all Misplaced Pages articles with GND identifiers). The data is also available in RDF format, so machine readability shouldn't be an issue here (again I'm not a programmer).

Is it possible to do this? Because it would save Misplaced Pages editors a lot of time and energy not having to create all those redirects manually. --bender235 (talk) 16:52, 24 May 2013 (UTC)

• Sourced variant names are interesting but WP overrun by variants: That suggestion, to use the Deutsche Nationalbibliothek profiles (or other) to generate redirect titles is an interesting idea, but there are just too many thousands (over 280 thousand?) of redirects, and we need to restrict (remove) to only have the high-use variants. The best place to list numerous variant spellings is within an article's footnotes, and then a wikisearch (Search:) for those rare spellings would match to whichever articles contained them. Meanwhile, we really need a Bot to sift through over 280 thousand current redirects as "improbable redirects" to delete them. For example, a variant of "New York" might include "Newe Yorke" as a reasonable spelling, as stylized from the archaic word "newe" used in other town names; however, some/many people have gone wild and created zillions of bizarre redirects, in the style of "Nuew Yorkke" or "Nue Yorrk" or "Nu.YoRK." or even "N.w Y.rK" or similar bizarro redirects (the mind boggles, see: 65,500 titles in "Category:Redirects from alternative names"). So, in a sane world, then auto-creating historical variant spellings would make sense, but WP is currently overrun, overwhelmed with "redirect hoarding" of certainly many thousands of useless redirects, often many variations of corporation names. However, long-term, perhaps most redirects would be auto-removed unless listed in profiles of variant spellings, so the initial idea might be used, in the future, to prune away thousands of unsourced spellings. -Wikid77 (talk) 01:58, 25 May 2013 (UTC)

Dude, redirects are cheap. I don't see a problem with the proposal, but if one of the alternative titles was already a blue link or redirected somewhere else, this would obviously require human review. Graham87 03:46, 25 May 2013 (UTC)

And it can all go into WikiData. —TheDJ (talk • contribs) 08:19, 25 May 2013 (UTC)

The existence of silly redirects is not an excuse to avoid creating good ones. Creation of good redirects does not depend on the removal of the silly ones, so both tasks can be done concurrently. Note that Wikid77's examples are hypothetical; none of the redirects they mention have ever existed. – PartTimeGnome (talk | contribs) 15:45, 27 May 2013 (UTC)

The best place to list numerous variant spellings is within an article's footnotes, and then a wikisearch (Search:) for those rare spellings would match to whichever articles contained them.

Maybe. But then again, this would be manual labour, too, wouldn't it? The point of my proposal was to do this automatically. --bender235 (talk) 11:42, 25 May 2013 (UTC)

Getting back to the original proposal, this sounds like a great idea for a bot. – PartTimeGnome (talk | contribs) 15:45, 27 May 2013 (UTC)

And if not redirect, it could at least copy the alternative names in the ALTERNATIVE NAMES parameter in {{Persondata}}. --bender235 (talk) 15:08, 1 June 2013 (UTC)

• Just as a (non-technical) comment on this, the 'alternative name forms' in library records are, or at least are supposed to be, only 'forms' that have been 'sourced' from published works (not just random misspellings). The 'possibility' of someone trying to find a WP article from such a source (like, say, a hebrew translation of an american author) seems 'non-negligible'....i.e, this would IMO be a good thing to do 'somehow' from the perspectives of both 'accessibility' and the possiblity of making 'inter-language wiki' links more 'automatically' creatable (especially in the case of 'personal name' records). Revent (talk) 21:04, 1 June 2013 (UTC)

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)

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)

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)

I noticed it 2+1⁄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)

(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)

(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)

(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)

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)

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)

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)

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)

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)

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)

(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)

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)

/* 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)

• 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)
  • 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)

(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)

• 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)
  • You put the entire code in your User:Victoriaearle/common.css. — Edokter (talk) — 23:19, 25 May 2013 (UTC)
    • Got it thanks. Victoria (talk) 23:34, 25 May 2013 (UTC)

Yes thanks for that code to remove those stupid green dots. Lugnuts 09:16, 26 May 2013 (UTC)

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)

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)

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)

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)

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)

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)

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)

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

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)

.updatedmarker { display: none; }

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

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

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

• 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)

• It is possible to add html tags to MediaWiki:Wlheader-showupdated, you can tell because there is already a <Span style=color: darkgreen; font-weight: bold;>green</Span> 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)

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)

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)

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)

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)

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)

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)

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)

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

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)

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)

Regex and Semitic languages

Moved from Misplaced Pages talk:Village pump (technical) -- John of Reading (talk) 07:13, 28 May 2013 (UTC)

Hi,

Is that someone understands why the following regex doesn't work fine with right-to-left languages (I use AWB regex):

Find:

\+)\]\] \+):\1\|\{\{\2\}\}\]\]

Replace:

{{t+|$2|$1}}

Text to search:

] ] 

Result:

{{t+|he|משפחה}} 

While if I puts in "Text to search" ] ] , the result is fine: {{t+|he|gta}} .

Do you understand why?

Thank you in advance to those who will give an explanation for this,

Regards, Automatik (talk) 02:59, 28 May 2013 (UTC)

What exactly are you trying to match? ·Add§hore· 10:18, 28 May 2013 (UTC)

funny enough, the result you get is actually the correct result. unfortunately, because of directionality issues with the browser(s), it just does not display correctly. you can see it by forcing the "pre" element to display with "bidi-override". i do apologize for the readers - for most of you this is just mambo-jumbo - i wish it was mambo-jambo to me also... so here is the "same "pre" section as above, with bidi override:

{{t+|he|משפחה}} 

peace - קיפודנחש (aka kipod) (talk) 20:54, 28 May 2013 (UTC)

Thanks you both! Actually, it's just the preview is bad, but it works correctly. Thank you again :) Automatik (talk) 14:47, 2 June 2013 (UTC)

Just a question, I tried the replacement here, on the page I see what I want (משפחה (he) ), but in the code I see {{t+|he|משפחה}} . It's strange, isn't it? Automatik (talk) 16:03, 2 June 2013 (UTC)

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)

• 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)

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 Misplaced Pages 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)

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)

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

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)

Score block

RESOLVED: Omit "\version" in score-tags. -Wikid77 08:14, 30 May 2013 (UTC)

I still don't understand how to get this, which compiles fine in Lilypond, to display in an article with the <score> markup. Help?

\version "2.16.2"
\new Score {
  \new Staff {
    \relative c' {
      \time 3/4
      \clef treble
      \key g \major
      \partial 4 d4 |
      b'4( c) b | d4( b) a | g( a) e | g fis e |
      d2 d4 | g4( a) b | a2 g4 | fis2 \bar "||"
    }
  }
}

Thanks! --SarekOfVulcan (talk) 20:26, 28 May 2013 (UTC)

just remove the "Version" part, and all will be well. peace - קיפודנחש (aka kipod) (talk) 20:30, 28 May 2013 (UTC)

Argh. I don't know why that didn't happen for me at some point along the way. Thanks! --SarekOfVulcan (talk) 20:39, 28 May 2013 (UTC)

Strange. I could swear this output was working earlier today, and now it's producing an error message. Wikimedia seems to have broken its configuration. Filed as bugzilla:49004. --MZMcBride (talk) 03:39, 31 May 2013 (UTC)

Proposal: mark default gadget as "default"

So the "gadgets" extension (mw:Extension:gadgets) allows defining some of the gadgets as "default". these gadgets are active for anons and new users, though the latter can, of course, turn them off. it is not exrtemely difficult to find out which gadgets are "default" - one has to peek in MediaWiki:Gadgets-definition, and look for "default". however, it is often times very useful to know which gadgets are on by default: e.g., when explaining things to other users (esp. new or inexperienced users), one can assume ("by default") that the default gadgets are active for them. it would also be nice to have some idea which gadgets will be active if one presses the "Restore all default settings".

i propose to mark all the default gadgets in "Preferences => Gadgets" page, by adding a tiny suffix to the lines describing default gadgets, that looks like so (without the quotes): " (default) ". peace - קיפודנחש (aka kipod) (talk) 22:39, 28 May 2013 (UTC)

Support:  Technical 13 (talk) gives his support for this section's subject at 22:57, 28 May 2013 (UTC).

Actually this is already done on Commons. I think it's a good idea, especially for beginners who are not aware of MediaWiki:Gadgets-definition. However we should probably use an unified way to mark Gadgets across projects. What you are proposing is already differing from Commons. I'm not saying Common uses the best solution but at least it looks already quite good to me. --Patrick87 (talk) 23:34, 28 May 2013 (UTC)

actually, commons is where i picked up this idea in the first place, and i should have mentioned it in the proposal.

it's not critical how exactly is the "defaultness" of a gadget is represented visually, as long as it's available.

personally, i'm not so keen about the way this was implemented in commons: i'm not talking about the visual part, but rather about the actual implementation: in commons, there is one template, called commons:Template:Gadget-state, which maintains a list of all default gadgets. when someone changes the "defaultness" of any specific gadget, they need to edit this template also. but regardless of the way this information is presented visually, and regardless of the way this is implemented, i still think it will be good to have this information available _somehow_. peace - קיפודנחש (aka kipod) (talk) 13:05, 29 May 2013 (UTC)

Related: bugzilla:34522. --MZMcBride (talk) 20:52, 30 May 2013 (UTC)

Marking ALL the Special:Preferences defaults, on every tab, would be helpful. There's the "Restore all default settings" button of doom which wipes out all our customizations, but often I'll want to make sure that I'm seeing a page the way most other editors do, eg thumbnail size defaults (What are they currently? 220px?). I know I've changed a few options at Special:Preferences#mw-prefsection-editing, but I'm not sure which...

A few defaults are mentioned in the page itself, and a few are mentioned at Help:Preferences and mw:Help:Preferences, but not all. It would be best if they were all marked within the Special:Preferences page/tabs itself.

As for how to mark the defaults - There's the marker "(default)" as suggested by קיפודנחש above, which is possibly the best method. The only other simple standard I can think of, is that used by in mozilla projects, where user-customized items are marked in bold (but that would probably be a lot more complicated to implement). Any other ways? –Quiddity (talk) 23:44, 3 June 2013 (UTC)

New login and account creation designs being enabled soon

Hi all,

After months of testing, we're finally ready to enable the new designs for account creation and login. We plan on doing this tomorrow (May 29) around 23:00 UTC. If you're intersted in the background, there is documentation about why we did this and how we tested it.

As we announced on the blog a while back, you can try out the new look here before it's launched. (See the blog post for instructions.) If you've logged in or created an account in the last couple weeks, you might have noticed the links we put on the old forms.

Please let me know if you have any questions. We still have some enhancements in the works, but it's long past time these were ready for the primary use cases. Many thanks, Steven Walling (WMF) • talk 01:58, 29 May 2013 (UTC)

This has been  Done now. Steven Walling (WMF) • talk 00:00, 30 May 2013 (UTC)

+1 ·addshore· 11:04, 30 May 2013 (UTC)

• The old login screen was minimalistic and simple to comprehend. It's almost just a simple now, but has a large blue box that looks like it was pirated from Facebook. Necessary? Improvement? Not. -- Ohc _{¿que pasa?} 06:13, 31 May 2013 (UTC)

• Yeah, I don't like the "Facebookification" either. Huge colorful buttons, flashy pop-ups, "Likes" (the new "Thanks" feature) – I don't know where this will be leading.

The simplistic style of Misplaced Pages always added to the seriousness an encyclopedia should exhibit. It's getting lost for me lately. Especially since each and every new feature comes with more CSS styling and JavaScript-ing than the one before instead of adapting the current skins ands styles of Misplaced Pages. --Patrick87 (talk) 08:53, 31 May 2013 (UTC)

I'm gonna start blocking ppl who use the word Facebookification. The only problem here is that people don't want to adjust to change. Be honest about that, don't pretend like the rest of us is trying to imitate Facebook. —TheDJ (talk • contribs) 09:35, 31 May 2013 (UTC)

Change is one thing, but this is something else - and 'Facebookification' is an apt description of what is going on. GiantSnowman 09:43, 31 May 2013 (UTC)

To add to TheDJ: isn't "blocking" a Facebook feature? --Patrick87 (talk) 10:09, 31 May 2013 (UTC)

I wouldn't call it 'Facebookification', perhaps just catching up with what the rest of the web is doing? ·addshore· 13:04, 31 May 2013 (UTC)

It's called Wikiafication, of course. :-) --MZMcBride (talk) 14:00, 31 May 2013 (UTC)

I agree the new login screen is very FaceBookish... Can that be toned down a little... At least pick some different colors or something. As for the Thank feature... Parts of that can be removed with JavaScript (I haven't developed the script to go any further yet)... #A couple technical updates is the discussion for (thank). Technical 13 (talk) 13:29, 31 May 2013 (UTC)

"Facebookification"/"Wikiafication" is not inherently bad. If you want Misplaced Pages to always look like a Web 1.0 site, archive.org may be just the site for you. But eventually this barebones UI is going to prove insufficient, simply because it will diverge too much from what the normal web user (someone who we'd like to covert to an editor) is used to...hence scaring them away from editing. When this wave of Wikipedians dies off, who's going to be left? No one, unless we learn to accept and prosper from changes like this. Theopolisme (talk) 14:19, 31 May 2013 (UTC)

Theo, since your reply is apparently a reply to me based on the indenting (perhaps you miss-indented?), I'm going to reply to it, and to Edokter below here. I'm all for change and improvement and agree that there is much to do on wikipedia in this regard. I agree with both of you that improvements do need to happen. I'm not sure that a big  FaceBook blue  login button offers any improvement there. All I said is pick a different color. Something that can be unique to Misplaced Pages, it's not like there aren't 16+ million colors at least to choose from... As far as recruiting goes, I'm still learning the ways of the Misplaced Pages community despite my adept knowledge when it comes to the actual mechanics of editing. That being said, I'm currently in the process of attempting to put together a "student interest survey" for all of the students of my university (University of Maine System) to see if I can offer a seminar or regular class/meetup or something to inform people more about how Misplaced Pages works and how they can get involved. I'm documenting everything (and will be reporting when I have something significant to do so on a page in my userspace) so that other senior Wikipedians might be encouraged to try something similar (without having to reinvent the wheel). Anyways, before I get TL;DR, my point was, let's pick a different color scheme for wikipedia than what FaceBook and Twitter and all of the social media sites are doing, please... Technical 13 (talk) 14:42, 31 May 2013 (UTC)

Wasn't supposed to be specifically to you, but your reply was still appreciated--looking forward to hearing about how your Misplaced Pages meetup works out, please keep me posted (and check out the WP:USEP, even if it doesn't necessarily exactly conform to what you're trying to do) Theopolisme (talk) 14:56, 31 May 2013 (UTC)

Get with the times already. The majority of Misplaced Pages's user interface is still stuck in the eighties. They're fine for the harcore editors, but a nightmare for new editors. Any change that will take us out of the dark ages is welcome. — Edokter (talk) — 14:23, 31 May 2013 (UTC)

"stuck in the eighties"? isn't this just slightly bit hysteric? can you point to an 80's application similar in any way to wp UI? (it has to be "application" rather than "web site" - there were no web sites in the eighties). personally, i like the recent changes, but we don't have to justify them by declaring the existing system dysfunctional.

the resistance and opposition to the changes is actually somewhat amusing and endearing. we saw similar resistance when "vector" was introduced, and ppl all over the placed declared "monobook" to be the best of god's creations in heaver or on earth, except some digging exposed the fact that (almost identical) opposition, sometime by the same ppl, was shown when monobook was introduced... peace - קיפודנחש (aka kipod) (talk) 14:41, 31 May 2013 (UTC)

Just a thought on that: Books are printed since the 15th century and they look today basically the same as they did back then – because the concept simply works. Transfer of information doesn't need complex styling, actually styling can be detrimental. Misplaced Pages is an Encyclopedia, and an Encyclopedia was always a book historically! Even if it's an on-line Encyclopedia it still hast the same tasks to fulfill, so why do you think we needed to change fundamental concepts of Misplaced Pages? --Patrick87 (talk) 15:06, 31 May 2013 (UTC)

True, funny story on that, we were talking to a hostel guest during the recent dev conference, and she didn't even realize the skin had changed over the past 5 years. We actually had to go back and forth between monobook and Vector before she noticed. Then she said: "Oh, yeah the new one is a bit simpler. And that was controversial ??" Oh, and she dropped of her chair when we showed her Visual Editor. I'm pretty sure that fundamentally, she still thought it was an encyclopedia-like resource though. —TheDJ (talk • contribs) 21:47, 31 May 2013 (UTC)

I don't think the objection is to change, per se. The new login form is simply ugly and out-of-place here. The bright green and blue unnecessarily punch the user in the face. --MZMcBride (talk) 15:37, 31 May 2013 (UTC)

I also read some feedback yesterday that telling the user to "Enter your password here" below a field labeled "Password" could be seen as condescending and insulting to the user's intelligence. I suppose I should file a bug about that. --MZMcBride (talk) 15:41, 31 May 2013 (UTC)

Rather than bury my reply further up, I'll try to address the general "why and how" of the design decisions regarding the new forms.

First up: many sites large and small use blue and green as a primary action button color, and we don't intentionally imitate Facebook, Wikia, or any other site in particular in our design work. We use color and size as tools to emphasize primary and secondary actions on an interface, to make it easier to find and take those actions.

The current log in and sign up pages take the basic functionality of the previous versions and build upon them. To validate our design decisions, we tested this style with thousands of new people on the sign up form, gathered feedback in remote usability tests, responded to literally dozens of bug requests and enhancement ideas on Bugzilla, and iterated on these designs many times.

We didn't do this hastily, just to tickle a designer's random fancy, or to imitate Facebook. We did this because, with the gains we saw during testing, this is going to help thousands of additional people join Misplaced Pages and our other projects every month. Getting new people in the door with minimal pain and confusion is something we owe to those who want to try and improve the encyclopedia by registering. Steven Walling (WMF) • talk 23:15, 31 May 2013 (UTC)

Remember old login-screen was excellent as seen here: I can appreciate all the effort in thinking that the prior login-screen needed work, but it was truly an excellent design, and I need a "thank" button to those who created the old login screen. Before that screen fades from memory, I copied it from Simple Misplaced Pages, shown below, as one for the history book:

Log in Don't have an account? Create an account. You must have cookies enabled to log in to Misplaced Pages. Language: Deutsch | English | Esperanto | français | español | italiano | Nederlands            Username: Password: Remember my login on this browser (for a maximum of 30 days)  Log in   Forgotten your login details?

Sometimes things are not even fully appreciated until they are gone. -Wikid77 (talk) 08:15, 1 June 2013 (UTC)

• One of the things I most enjoy at Misplaced Pages is the stable environment - the "feel" of the place rarely changes. It feels like home, where even when you wake up in the middle of the night, with the lights out, you can still find your way to the bathroom without bumping into things and waking up the whole household.

This last log-in change was a departure from this norm and should have been better adveritised before it happened, in my opinion. I wonder how many editors did not log-in when they saw this unfamiliar log-in page? XOttawahitech (talk) 22:41, 1 June 2013 (UTC)

In addition to announcements here and on the Wikimedia blog more than a month beforehand, I posted links directly on the old login interface to try the new version, which were live from May 6th until the day of launch. Steven Walling (WMF) • talk 01:50, 2 June 2013 (UTC)

A valid complaint in the past about changes has been that the Foundation didn't announce them well. I don't believe that argument can be validly used in this case. Steven did a good job at trying to announce the new login format and I commend him for this. Killiondude (talk) 01:53, 2 June 2013 (UTC)

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)

Nabla, the new notifications aren't for everyone. And Misplaced Pages 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 11:55, 29 May 2013 (UTC)

• 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 Misplaced Pages 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)

@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 'Misplaced Pages-like' Because we never really had a colorscheme that we truly identified with I think. —TheDJ (talk • contribs) 21:51, 31 May 2013 (UTC)

@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)

@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)

@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 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)

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)

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)

I'd be willing to co-op with someone - I don't have enough time to do it all by my lonesome. Anyone? TheOneSean 15:38, 29 May 2013 (UTC)

• 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 Misplaced Pages 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)

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)

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)

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)

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)

• 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)

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)

Spam

I have several hundred thousand edits on wikipedia, my own wikis, and mediawiki sites. I feel the biggest weakness of mediawiki is the spam. Sites like wikipedia and wikia with huge number of technical people stop this spam, but little sites like some of mine are overwhelmed.

A couple of questions:

1. Is there plans to have spam programs like CAPTCHA already installed in future versions of mediawiki?
2. How do I get rid of spambots editing pages on my wiki? I already have Extension:ConfirmEdit with QuestyCaptcha (I was unable to successfully install any others). These spambots are able to create accounts, but they cannot edit.

Thank you! Igottheconch (talk) 14:56, 29 May 2013 (UTC)

See mw:Manual:Combating_spam and mw:Extension:AbuseFilter Werieth (talk) 15:00, 29 May 2013 (UTC)

on my wiki, i had huge spam problem, until i installed mw:Extension:ConfirmEdit. i do not use any visual captcha, but rather "confirmcaptch": users are asked to answer a question in order to register. anons can still post, but if they try to add any link, they are required to answer the question also. so far (~2 years) this have stopped the spam entirely (knock on wood, i hope this won't change). this would not work for large enough or "interesting" enough wikis: spambot operators can, theoretically, teach their bots to answer the question, but if your wiki is small enough/obscure enough, this will never happen in practice. peace - קיפודנחש (aka kipod) (talk) 16:03, 29 May 2013 (UTC)

See also Bayesan spam filter, which is being worked on at Google Summer of Code, for Wikimedia. It will be primarily useful for small wikis.--Snaevar (talk) 01:51, 30 May 2013 (UTC)

thank you so much guys! Your the greatest. Snaevar, Bayesan spam filter sounds promising!

קיפודנחש (aka kipod) As I wrote above (modified to explain what I was trying to say):

I already have Extension:ConfirmEdit with QuestyCaptcha (I was unable to successfully install any others). These spambots are able to create accounts, but they cannot edit.

Here is the section of my localsettings:

require_once( "$IP/extensions/ConfirmEdit/ConfirmEdit.php" ); require_once("$IP/extensions/QuickLink/QuickLink.php"); require_once( "$IP/extensions/ConfirmEdit/QuestyCaptcha.php"); $wgCaptchaClass = 'QuestyCaptcha'; $wgCaptchaQuestions = array( 'question' => "What month did the terrorists attack the world trade center?", 'answer' => "September" ); $wgCaptchaQuestions = array( 'question' => "What country does chinese food come from?", 'answer' => "China" ); $wgCaptchaQuestions = array( 'question' => "What month comes after June?", 'answer' => "July" ); $wgCaptchaTriggers = true; $wgCaptchaTriggers = true; $wgCaptchaTriggers = true; $wgCaptchaTriggers = true; $wgCaptchaTriggers = true; ##$wgGroupPermissions = false; ##$wgGroupPermissions = true; ##$wgGroupPermissions = true; // registered bots ##$wgGroupPermissions = true; ##$wgGroupPermissions = true; ##$ceAllowConfirmedEmail = true; ##captcha settings end

Again, the QuestyCaptcha questions successfully STOP the spambots from editing pages (Every couple of months I have to change the questions), but they still can create user accounts, dozens everyday.

For some reason the spambots are still able to create accounts. I am not sure how or why! Igottheconch 04:52, 30 May 2013 (UTC)

this looks strange: if they can indeed create, why don't they post their junk like they did before? did you try to create a new user account on your wiki yourself, and verified that it's not possible without actually answering the question? peace - קיפודנחש (aka kipod) (talk) 14:29, 30 May 2013 (UTC)

yes it is very strange. I tried creating a new account and I had to enter the captcha, somehow spambots are able to circumvent the captcha.

Screenshot of the 200+ spambots which registered in one day.

Screen shot of failure to create an account without entering question captcha.

Could spambots somehow create an account with Manual:Parameters_to_index.php, circumventing the captcha?

I just added $wgGroupPermissions = false; to localsettings, the new account creation is getting out of hand.

Igottheconch (talk) 03:37, 31 May 2013 (UTC)

Any other suggestions on what I can do to stop spambots from creating new accounts? What does wikipedia do? Igottheconch (talk) 14:41, 3 June 2013 (UTC)

Problems in archiving the discussions

Hello people,

I was looking for my discussion on the Technical Village Pump, but I did not find it.

And now I see that this discussion has been moved to an archive less than 6 days after a message was written in it !

This is crazy.

This is way too soon, and this creates further technical problems.

You may see details and sharings of my point of view in these discussions : this discussion, that discussion.

In this archiving, splitting the page by date instead of by subject is simply stupid. The subjects are important, the dates are meaningless.

A lot of discussions started 5 or 6 days ago or even 2000 years ago and are still relevant and are being hotly discussed today.

This definitely has to be improved.

Cheers,

--Nnemo (talk) 18:10, 29 May 2013 (UTC)

How do you propose that we make improvements, while maintaining manageable page sizes? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:29, 29 May 2013 (UTC)

Well, something like this and that. StackExchange uses its Meta system to receive, discuss and manage bug reports and feature requests. This is not a small idea that could be done in 5 minutes. But this is much more adapted. In the meantime, put the liquid discussions like these here. Thank you. --Nnemo (talk) 19:22, 29 May 2013 (UTC)

WP:LQT? No, thanks. --Redrose64 (talk) 19:57, 29 May 2013 (UTC)

according to the edit summaries of the archiving bot, it seems that it archives any discussion older than 5 days. typical page size seems to hover around 150K. personally i think this can be relaxed: leave discussion longer before archiving, maybe 7 or 10 days. naturally, this will result in larger typical page size. is 250K prohibitively large? personally, i do not think so.

i propose to raise the archiving threshold to 8 days. peace - קיפודנחש (aka kipod) (talk) 16:02, 30 May 2013 (UTC)

It used to be 7 days. It was reduced to 5 days on 29 November 2012. The discussion for this change is at Misplaced Pages talk:Village pump/Archive 8#Lowering the archive time. (There was no announcement of this discussion on VPT itself or its talk page.) – PartTimeGnome (talk | contribs) 21:29, 30 May 2013 (UTC)

Perhaps have long-term 2nd page "technical_longer"

I am thinking that some conversations, or questions, could be placed in a long-term issues page, such as named "(technical longer)" which were still tech issues but likely to run weeks longer (less frequent auto-archiving there), to avoid archiving too soon. That would also allow faster pruning of this page, where some people would realize an issue would need "longer" discussion, and then note a new thread there, as linked from here to allow such threads to be closed here even sooner. Some people have noted my answers seem too detailed, by including analogies or related tangents, and those topics might also be transferred to the tech-longer page, for possible cross-influence between related techniques. In fact, a good reason to open a thread at tech-longer could be auto-archiving before satisfactory answer, so just link the Archive_xx/topic and resume discussion as thread on the tech-longer page. In cases of slow-down there, could post a reminder thread here. I think that is the solution, so I have listed some related questions below, for separated discussions. -Wikid77 15:18, 30 May 2013 (UTC)

What page name to use for the tech-longer page, perhaps tech-extra, as VPTX? -Wikid77 15:18, 30 May 2013 (UTC)

Should we have cross-link templates to wikilink both pages A<-->B by shortcut template names? -Wikid77 15:18, 30 May 2013 (UTC)

Should we use same thread title on both tech-pump pages to simplify cross-links? -Wikid77 15:18, 30 May 2013 (UTC)

Should we note user right to unmove back, as in write-up to note person has right to unmove thread back to here, as when related solutions come faster? -Wikid77 15:18, 30 May 2013 (UTC)

Sounds too complicated...our current system works, so why "fix" it? People are welcome to reopen threads from the archives if they so desire. Theopolisme (talk) 16:34, 30 May 2013 (UTC)

Some people don't reopen the threads by posting to this page though, and instead comment directly to the archive page. This one is, I think, the most recent that went unacknowledged, but there have been several since that where either they weren't expecting a reply (thankyou messages) or somebody else happened to notice and informed them accordingly. --Redrose64 (talk) 16:46, 30 May 2013 (UTC)

What about an editnotice for all archive pages (i.e, prefix "Misplaced Pages:Village_pump_(technical)/Archive")? Theopolisme (talk) 17:12, 30 May 2013 (UTC)

• Wouldn't it be just as easy to prepend any discussion that may need this extra time with {{Bump|days}} which automatically tags the section as do not archive for that duration no matter how stale it gets and skip the extra page and trying to remember and find threads on other pages? Technical 13 (talk) 16:58, 30 May 2013 (UTC)

• A tech-extra forum fixes 5 issues: rushed archiving, staleness, retro-analysis, bloat & fractionating: The problem here is not just rushed archiving to then require a restart of a long-term topic. There is also a major problem of staleness, here already, of topics which experts could see to move to a tech-extra forum (such as tricks to bypass this month's "13" user-interface changes). Plus, having some topics sitting for weeks in a tech-extra page would help the "retro-analysis" of issues, to rethink plans from prior weeks, and perhaps to post links to the specific follow-up templates, help-pages, gadgets (etc.) which now make sense, in retrospect about a topic weeks ago. Next, there is also the opportunity to reduce obvious bloat here, to move some threads to tech-extra sooner, and also append to related long-term threads already in that page. Then the moved topics could be pre-archived, perhaps with a dedicted thread here, "Topics moved to tech-extra May 2013" with one-line links to short titles of the tech-extra topics. Finally, by quickly moving extensive discussions to the tech-extra page, then the archives there would become more comprehensive of full discussions, not fractionated bits and pieces rushed in spurts into the main PUMPTECH archives. The overall concept, for the extra page, would function as a form of "discussable archive" (as people noted above) where the history-log of edits would reflect actual long-term discussions. People could reply, "I'll answer over at tech-extra, with direct links to related issues". Hopefully, a tech-extra page would surpass as a re-arrangeable "wp:Liquid Threads" with methods to restructure long-term discussions of issues which spanned months (plus strike bars in old misleading comments), while streamlining the main VPT page and reducing the rushed archives. Bottomline: we need a "discussable archive" structure, and I think a tech-extra page would help. -Wikid77 (talk) 20:00, 30 May 2013 (UTC)

We could go a long way to sorting the "bloat" problem if some of the posts on this page were a lot shorter. --Redrose64 (talk) 20:36, 30 May 2013 (UTC)

Demand tweets as VPTWEET page! Yet many issues need details to solve. But the real problem is many topics rehashed weeks here, as count of signatures=276. Consider if 15 threads already at tech-extra, reduced to just 22 here. -Wikid77 00:40, 31 May 2013 (UTC)

We can relax the archive limits a bit. It seems to me that compared to 4 years or so ago, this page has a lot fewer topics then it had back then. Back then it hardly dropped under 40 or so topics. These days its usually between 20 and 35. —TheDJ (talk • contribs) 21:27, 30 May 2013 (UTC)

Beware smaller size is due to rushed archiving at "5d" otherwise would be huge 60-70, as people combine threads. See VPT 6 days ago: oldid-330, would be +30 topics now. Wikid77 00:40, 31 May 2013 (UTC)

Watchlist in bold

Unread items in my watchlist have suddenly started going bold, despite the relevant option in Special:Preferences#mw-prefsection-gadgets being unchecked. Is this a bug or somesuch? GiantSnowman 19:08, 29 May 2013 (UTC)

This may be related to #Problem using Twinkle above. If bits.wikimedia.org has some problem, all kinds of weird stuff may happen. — Edokter (talk) — 19:39, 29 May 2013 (UTC)

just tried it (i *do* like this feature, so i had to temporarily disable the gadget in order to test) and it works exactly as advertised for me.

User talk:Edokter may have hit the nail on the head, but my guess is that he didn't, and your problem is that you have some old junk stuck in your browser's cache. try hitting Ctrl+⇧ Shift+Delete (presuming windoze, and one of the "big 3" browsers: i do not know how to drop the cache on mac's browsers, or any windoze browser other than ff/chrome/ie), and select "empty cache" or "drop cache" or "delete temporary files" or whatever your browser use to say "clear the cache". peace - קיפודנחש (aka kipod) (talk) 19:44, 29 May 2013 (UTC)

That didn't work. GiantSnowman 19:58, 29 May 2013 (UTC)

i disabled javascript in my browser, and the gadget still works for me (this gadget is purely CSS - no JS involved). this is why i expressed doubt of the explanation that this is similar problem to the one bugging twinkle users and discussed elsewhere on this page. can you try to see if you have the same problem with a different browser? peace - קיפודנחש (aka kipod) (talk) 14:34, 30 May 2013 (UTC)

The section at the bottom of the editbox that usually holds the <charinsert> links is just solid text for me at the moment so I'm assuming there is something buggy going on with the JavaScript on the site at the moment. mw-edittools I think is the name of the section acting up for me. Technical 13 (talk) 19:52, 29 May 2013 (UTC)

This happened to me once before. I just refreshed the page and it went back to normal. I assume it's the pages you haven't visited on that computer which are going bold; that's what happened to me, which I assumed had something to do with the was the Simple English WP works talk pages, because they do it the same way. Greengreengreenred 14:40, 30 May 2013 (UTC)

actually, no: it's not "pages you haven't visited on that computer", it's "pages you haven't visited while logged in". the information is maintained on the server (rather than, say, in cookies on your computer), and does not depend which computer or which browser you used when reading the page. the system is pretty sophisticated: for instance, if you click "history" and read an old version of the page, this action will not be counted as "visit", but if you compare the latest version to a previous one, this "diff" operation *will* count as "visit" (as it should). peace - קיפודנחש (aka kipod) (talk) 14:50, 30 May 2013 (UTC)

Still not working guys. GiantSnowman 21:39, 30 May 2013 (UTC)

you did not answer my question, so here goes: can you try to see if you have the same problem with a different browser? peace - קיפודנחש (aka kipod) (talk) 22:48, 30 May 2013 (UTC)

It's fine on an older version of the same browser (IE) at a different computer, and it's fine on my iPad - but not on IE10. GiantSnowman 09:44, 31 May 2013 (UTC)

can you do me a favor? from your "watchlist" page, hit F12 and select "console" (it will probably ask you to refresh the page at this point - do it), and post here if you see any errors (typically appear in red) on the console? thanks, peace - קיפודנחש (aka kipod) (talk) 13:49, 31 May 2013 (UTC)

Guys, I think it was because I was in 'compatibility' mode. Seems to be fixed now... GiantSnowman 18:39, 31 May 2013 (UTC)

Extra links for images on Commons

When viewing images on Commons, I notice there are several extra links: included are "Google images" and "Tineye search." Where is the script on Commons located for that? Magog the Ogre (t • c) 04:31, 30 May 2013 (UTC)

They're gadgets, found at commons:Special:Preferences#mw-prefsection-gadgets under the "Maintenance tools" heading. Judging by commons:MediaWiki:Gadgets-definition, the files are: commons:MediaWiki:Gadget-Tineye; commons:MediaWiki:Gadget-Tineye.js; commons:MediaWiki:Gadget-GoogleImages; and commons:MediaWiki:Gadget-GoogleImages.js. --Redrose64 (talk) 09:26, 30 May 2013 (UTC)

User contributions oddity

Not sure if there is something there that needs fixing, but I thought it was pretty strange. See the feedback summary by 176.42.16.120 at Misplaced Pages:Automatic edit summaries. I don't think it's supposed to do that... --Bongwarrior (talk) 17:58, 30 May 2013 (UTC)

Looks like the parser is evaluating the template...Oliver, if you're out there, since AFT is your baby, take a look? Theopolisme (talk) 18:01, 30 May 2013 (UTC)

It's...oh lord. Escaping exists for a reason :/. Okay, I'll let the devs know. Okeyes (WMF) (talk) 20:48, 30 May 2013 (UTC)

They've been poked :). Given his other feedback, of course, it's plausible it's not being evaluated and is being escaped properly, and he's just typing a mess of code in as feedback :). Okeyes (WMF) (talk) 20:50, 30 May 2013 (UTC)

Yeah, that's not really a good idea. Code in feedback posts should be treated exactly as it would be in edit summaries. Graham87 08:13, 31 May 2013 (UTC)

Totally agreed! There's now a patch in gerrit which should fix the problem at our next deployment. Thanks, all :). Okeyes (WMF) (talk) 11:09, 31 May 2013 (UTC)

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?

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?

Or, we could provide a bot that copied requests received via, e.g., email. Any thoughts on how to do it or how easy that would be?

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

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)

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)

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)

• 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)

  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)

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 Misplaced Pages 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)

+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)

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

Problem with flagicon of Switzerland

Proposal: Template_talk:Flag#Fix Swiss/Nepal/Vatican flag height.

Please tell me, which size of Switzerland flag is correct in comparison with the "normal" 2:3 flag. I guess it's the smaller one. But in Misplaced Pages tables is that bigger one as default and it looks ugly (I mean unequal height of lines). 195.91.108.91 (talk) 22:52, 30 May 2013 (UTC)

{{CHE}} uses 17px. -Wikid77 11:48, 3 June 2013 (UTC)

• Perhaps use medium size 17px for Switzerland flag-size problem: Thanks for reminding people about the unresolved flag-size problem for Flag of Switzerland, which has caused line-height trouble for years. After all this time, I would use medium size, x17px, as a compromise between typical x20px width and typical 15px height of the 2:3 ratio flags (re Italy): so Template:J versus Template:J. Although WP has the wp:IAR to ignore rules that prevent improvement, or hinder better typesetting, I suggest to compromise between the common "x20px" Swiss-flag height and the smaller 2:3 ratio x15px height, as the middle ground with x17px. In lists with smaller-font text, then consider x16px, or even x15px, when a better fit. However, you might meet severe resistance from flag advocates, so remind them of the technical advantages with a medium-size compromise, to fit within line height but more visible than a 15px height. Any other questions? -Wikid77 (talk) 03:52, 31 May 2013 (UTC)

In Template:Flagicon is the icon size currently set to 22×20 pixels. Maybe would be enough to set it to 22×15 pix as default, instead of manual editing of every article. 195.91.108.10 (talk) 10:12, 31 May 2013 (UTC)

• See talk-page to reduce Swiss flag icon: I have restarted the discussion from 2 years ago, as: "Template_talk:Country data Switzerland#Reduce default size" and wider discussion:
  "Template_talk:Flag#Fix Swiss/Nepal/Vatican flag height" to fix Nepal/Vatican also -Wikid77 00:46, 1 June, 11:48, 3 June 2013 (UTC)

A couple technical updates

The experimental Thanks extension was deployed to English Misplaced Pages on May 30. Also, as of May 30th, videos are now displayed in a modal viewer when you click on the thumbnail in an article. See Congenital insensitivity to pain for an example. Kaldari (talk) 00:55, 31 May 2013 (UTC)

How do I get rid of the thanks extension?--Bbb23 (talk) 01:02, 31 May 2013 (UTC)

@Bbb23: Misplaced Pages:Notifications/Thanks#How_to_turn_off_this_feature Theopolisme (talk) 01:45, 31 May 2013 (UTC)

Yes, I saw that after I posted, Theopolisme, thanks. I'd like to find a way, though, to turn just this new feature off without necessarily turning off other new features. That check box makes it sound like it turns off all new experiments. My guess is someone has already created a script to do it; I just have to find it.--Bbb23 (talk) 02:00, 31 May 2013 (UTC)

You can add

a.mw-thanks-thank-link {display:none;}

to your Special:MyPage/common.css file to hide the "thanks" link; however, this is not ideal, since it will still leave the vertical pipe next to where the "thanks" link belongs...I'm not a js/css expert, but somebody or other should be able to help with that. Theopolisme (talk) 03:12, 31 May 2013 (UTC)

Yeah, Theo, that was my first thought too—works fine, but like you say, it leaves the () there. I don't think that can be helped, except on the developers' side—the parentheses are hard-coded into the HTML; the only thing they're a part of is <div id="mw-diff-ntitle1">, which is the entire Revision as of ... (thank) line. If the devs would include that set of parens in a span or something, then it could work. Ignatzmice•talk 03:37, 31 May 2013 (UTC)

I'll take a look at it in an hour or so. I'm pretty sure we can get rid of the extras like I did with my script that gets rid of rollback and block buttons... gotta catch a bus to school first. Technical 13 (talk) 10:51, 31 May 2013 (UTC)

Okay, if you are just looking to get rid of the (thank) from diff pages... Adding the following code to your common.js should do it for you: importScript('User:Technical 13/Scripts/NoThanks.js'); // ] — If you want to remove it from other pages (like History pages), that can probably be done too, but I don't want to spend much time on it unless requested. Happy editing! Technical 13 (talk) 12:55, 31 May 2013 (UTC)

UPDATE: The script now removes all "thanks" links from history and differences pages. If there is someplace else you want them gone from (are they anywhere else?) point me to them and I'll add it to the script. Technical 13 (talk) 20:58, 31 May 2013 (UTC)

Wiki mark-ups when editing a page, (MediaWiki:Edittools)

I posted the following problem at the WP help desk (but didn't get an answer and redacted):
"Someone seems to play with the way wiki mark-ups are displayed. They used to be click-able but then suddenly they were not and then were again. Now, again, they're not and one has to copy and paste each symbol. Does someone know what's going on here or at which venue this should be addressed? Thanks, TMCk (talk) 03:20, 30 May 2013 (UTC)"
The problem is still going on as it are coming and going "on their own terms."
Could somebody please indulge me with what is going on and if there is something I can do to keep the mark-ups click-able? When I occur them in a non-click-able way there is no button to change this unlike when they're blue linked. Appreciated for any helpful response, TMCk (talk) 01:00, 31 May 2013 (UTC)

Sorry, but I think you have to describe more precisely what you are talking about (maybe take a screenshot?). I don't understand your question and others might not understand it either (which could be the reason you didn't receive an answer in the first place). --Patrick87 (talk) 02:23, 31 May 2013 (UTC)

Well, here is another problem I encountered before: I can't upload any file to WP for whatever fucked up reason . So here are 2 screenshots taken withing less than a minute of each other from the edit screen of two different pages and uploaded to imageshack: and . Hope this helps pinpoint the problem.
Thanks in front for any helpful response. TMCk (talk) 04:36, 31 May 2013 (UTC)

I'm pretty sure that your original q refers to MediaWiki:Edittools. This depends upon some javascript being retrieved from

Between iii and iv, I'd add "The connection between you and Misplaced Pages is bad". It is quite distinct situation from iii and iv, quite common and probably the hardest to test for normal users, with a lot of possible causes. —TheDJ (talk • contribs) 11:29, 31 May 2013 (UTC)

Thanks for the input so far. Here some facts/info in response:
Indeed, Java script shouldn't be the problem as the named edit tools worked just fine before. I just checked on another faster/newer/better computer (laptop) and get the same problem. for month I used to get a message of a script running slow and recommendation to cancel (the script) as the system might stop responding. I stopped the script and usually something was was not working which was of course logic. Now, for whatever reason, I rarely get this warning even on large pages with lots of templates. I also do not get timeout messages or anything alike and the edit tools might or might not pop up even on small and simple pages that load within seconds. My "real" internet speed is around 3 Mb/s so that shouldn't be the problem either, at least from my side.
Ergo, I can for sure blame it on Wiki and my good guess is that someone screwed up, again. Wikid77 makes a good point below as I had just as many others plenty of problems when they implemented the new notification system full of bugs.
Again, thanks for all the helpful replies so far. They made clear that all I can do is having more-more-and-even-more patience and hope they'll fix the problem at some point.TMCk (talk) 23:31, 31 May 2013 (UTC)

Misplaced Pages is very reliant on caching of pages and scripts (much more than most websites). It might be that your ISP or your home router is using some sort of proxy caching that is operating faulty. I'm not sure where you are located, but in many areas of the world ISPs do a lot of caching to speed up your internet connection and to save bandwidth for themselves. If this caching is a tad lazy (inherently making it broken), it might be serving you 'stale' pages. Pages/scripts that are outdated and really should be fetched from Misplaced Pages again (because they would have different contents), but instead you are getting from a cache somewhere. This should not happen, it's a bug, but not one you (or Misplaced Pages) can do a lot about (the helpdesk will loose you after the first sentence). Usually these pages are cached for about 30 days maximum, and then it's should clear up. If you really want to know, then you need to do problem reduction. Try your computer at someone's house with the same ISP, try at someone with a different ISP, try changing your router brand etc. you need to separate all potential problem areas, and reduce the 'surface' of where the problems occur. That way you could reduce it to a pc, a router, your isp, your region etc. Remember that ISPs often have multiple brands, take that into account as well. Its cumbersome work and not what you want to hear, but there is not much that other editors can do to help you. I've checked your account, and you are not running any custom scripts. There haven't been reports about malfunctioning gadgets (at least none that aren't resolved). However there was a big breakage in the gadgets and scripts last week. If your ISP is caching the broken state of one of those scripts, it might explain why you cannot get it fixed. —TheDJ (talk • contribs) 12:12, 2 June 2013 (UTC)

• English WP website has descended into total chaos of bizarre changes: During May 2013, the MediaWiki software has been changed, every few days, to add new features, and drop others, such as the orange new-messages bar. The typical bottom box of accented letters/symbols is gone at times, but essay wp:PASTE shows those symbols to copy/paste as in foreign languages. Keep a copy of pages saved offline as backup, and expect to get "Cannot find server" at times. There is a recent petition to protest the rampant peculiar changes to the MediaWiki software, as listed above in the VPT infobox (at top):

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

Meanwhile, some edits can be tested by copy/paste into Simple Misplaced Pages or German Misplaced Pages, which have not been fully derailed yet. A few people have called for the firing of WMF personnel, but I ask people to realize the developers are capable people and can be directed to restore the prior website software, and delay future disruptive changes. We have seen no evidence of corrupted page contents, but menus and headers might appear garbled. -Wikid77 (talk) 06:03, 31 May 2013 (UTC)

Wikid77. You pinpointed an ongoing problem. I fully agree and will also sign the petition shortly. I too wouldn't call for "firing of WMF personnel", although when (programming) geniuses are blowing up the barn they need some serious supervision.TMCk (talk) 23:31, 31 May 2013 (UTC)

• The problems are actually supervised: We will need to contact the WMF managers to change directions; for typical software development in U.S. firms, those kinds of changes being made, with wp:Notifications and Thanks-buttons, require budget allocation and approved design plans, directing the efforts of "(programming) geniuses" to perform very disruptive actions, such as re-changing menu navigational controls ("don't keep moving the car's brake pedal") and putting numerous buttons "(thanks)" where they are likely to be accidentally clicked, causing a future psychological aversion to "(thanks)" as marked with unpleasant side-effects. The ergonomics of WP screens need to be re-considered, and contacting supervisors is the fastest method, as with the user-interface petition. I have advised to hold "WP screen-design competitions" to get massive improvements in screen designs rather than disrupting menus for trivial changes. When changing the user-interface buttons, make sure the shifts are worth the shock, and get buy-in from many users. -Wikid77 (talk) 01:27, 1 June 2013 (UTC)

• Do you have any evidence whatsoever that any of the problems reported are due to the projects you're soapboxing about? Ironholds (talk) 04:05, 1 June 2013 (UTC)

You pop up suddenly when there is some constructive criticism about developers but you fail to give a useful response to what this thread is about? If you're involved in the problem described it would be nice to give a useful answer about the issue and how you'll work on a solution rather than just being, apparently, offended (for what reason?) and place a real offensive and useless comment.TMCk (talk) 05:26, 1 June 2013 (UTC)

Wow, apparently ppl aren't allowed to popup anymore. And you wonder why ppl find en.wp such an unkind place that they'd rather avoid. —TheDJ (talk • contribs) 09:22, 1 June 2013 (UTC)

I'm popping up as a volunteer, not a staffer. And, no, I'm not responding to constructive criticism, and I'm not offended; I'm annoyed. Big difference. Here's why I'm annoyed; you have reported that you, as an individual, are struggling to load edit tools and upload images. This is not, to my knowledge, something that has been replicated anywhere else - of our half-billion users and N thousand editors, you are the only one who has come up with the problem, which is something that, as TheDJ has pointed out above, can be explained by many factors that have nothing to do with the servers. And your instinctive response is to blame the developers, based on zero evidence that the problem is at the server end. Iff it is a problem at the server end (and if it was, again, you'd expect other people to notice or report it), the people who would fix it are almost certainly nothing to do with the teams working on Echo or any of the other projects you're also taking issue with. I find this attitude - to instinctively blame the WMF when anything goes wrong - to be problematic, yes. Ironholds (talk) 12:54, 1 June 2013 (UTC)

This is in response to the above and posts you made on related talkpages.
Youre popping up as a "volunter" to comment on an editor's comment accusing him of "soapboxing", yet according to your user page you're working in real live for the Wikimedia Foundation "building new software". You also were involved in the new notification system (ECHO) that was introduced with many bugs and little to no input from regular editors who don't pay much attention to such, (when editors do have problems with changes they might not care enough or simply don't know where to comment, so the number of affected users is of course way higher than can be seen.) The RFC regarding the forced upon change made the change to a small orange bar happen and after several complains of bugs in the system they were fixed after some time. Something that shouldn't have happened as the new feauture should've be inplemented only after making sure there are no (big) bugs left and some short trials, (besides better communication with the community if and what they really want.)
You say you're "annoyed" and "...find attitude - to instinctively blame the WMF when anything goes wrong - to be problematic". Re-read the thread and you'll find that after going to the responses made I pinpointed the problem to WP after checking on and ruling out every other potential problem that was posted. So no, it wasn't anywhere near of "blaming the WMF as default".
I admit that my temper runs higher than usual since the (now solved) ECHO fiasco and I appollogize for it. Maybe you should too, for your post that started IMO to derail this discussion (with me too being to blame.)
Anyhow, since you appear to be an expert according to your user page I gladly would take up your offer (you made somewhere regarding this) and continue our conversation at your talkpage, with concentrating on technical issues you might be able to solve for/with me on way or another. If you'd like to do so please just start posting a thread with infos or questions for info you need from me to get to the grounds of the problem. BTW, while editing this the mark-ups (MediaWiki:Edittools) works again just fine. Thanks in front for further input, TMCk (talk) 22:03, 1 June 2013 (UTC)
Note: Now the mark-ups are again just copy and paste so it still keeps switching.TMCk (talk) 22:07, 1 June 2013 (UTC)

When I say I'm popping up 'as a volunteer' I mean that I'm here in my personal capacity, not in my professional; I'm not denying working for the Foundation. Yes, I help build new software; no, I'm not a developer. Yes, I was involved in Echo; no, I'm not involved in this bug. In regards to Echo's bugs, Echo was extensively tested, but there isn't a prototype instance in the world that compares to actually deploying it and having tens of thousands of editors troop through its workflows. No software is bug free in version 1.0, and no software can be until it's fully exposed to the user base.

In regards to the specific bug; stick a bug in bugzilla. Explain what's happening, give your browser and operating system, and hopefully someone will get to it. If it is a problem at the server end (and that's far from confirmed) it's one effecting a tiny, tiny number of users, so it's no surprise it hasn't been detected until now. Ironholds (talk) 23:05, 1 June 2013 (UTC)

Please forget about all the "other" stuff that is in the past by now. I ask you again: Would you be willing as you offered in another thread to help me out with the weird problem I encounter for a week or so? I'd be much appreciated to engage in a constructive conversation about this at your talk page. If you'd like to take your offer back or I have misinterpreted said offer please just say so. I truly would like to leave non-constructive remarks/comments be bygones and start fresh at either your or my talk page, find out the problem and see if there is a solution. There is really no need for any further defensive posts. You made you point quite clear already. I'm still trying to get some help solving the problem I have, no matter if I'm the only one or not.TMCk (talk) 00:15, 2 June 2013 (UTC)

For the record, I have the same problem with the Edittools only loading the fallback from time to time and it usually corresponds with others noting Wikibits on the fritz or an error in a javascript I am working on or one that I have loaded that someone else is working on... Usually, going to get a drink, coming back, and reloading the page fixes it... Also, can we please try to assume a little more good faith and stop flaming the WMF lackeys so much, it is counter-productive and quite frankly getting annoying. Thanks, I appreciate that so much because I know you just said, "sure, I suppose you're right, it isn't gaining anything". Happy editing! Technical 13 (talk) 12:19, 2 June 2013 (UTC)

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 Misplaced Pages.

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 Misplaced Pages. 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)

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)

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)

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)

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)

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)

@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)

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)

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)

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)

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

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. GiantSnowman 10:29, 31 May 2013 (UTC)

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)

Yes, it should definitely not be a one-click option. GiantSnowman 10:45, 31 May 2013 (UTC)

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)

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

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

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)

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)

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

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

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

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)

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)

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. GiantSnowman 12:37, 2 June 2013 (UTC)

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)

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)

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)

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

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)

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)

urls with square brackets

How do I include a citation that uses the square bracket as part of its url? The address is http://tools.morningstar.co.uk/uk/stockreport/default.aspx?tab=3&vw=story&SecurityToken=0P00007OBL]3]0]E0WWE$$ALL&Id=0P00007OBL&ClientFund=0&CurrencyId=GBP&story=7400228704134. Currently it truncates and doesn't reach the target page. Please see this. Thanks in advance. -- Ohc _{¿que pasa?} 07:15, 31 May 2013 (UTC)

Replace the right brackets with %5D, the equivalent percent-encoding. As mentioned at the relevant help page, you could also use the {{urlencode}} magic word, but the former solution is cleaner IMO because it works everywhere (especially on mirrors/forks and non-MediaWiki sites). At any rate, I've fixed the problem. Graham87 07:42, 31 May 2013 (UTC)

Thanks. -- Ohc _{¿que pasa?} 08:06, 31 May 2013 (UTC)

WP:FRS

RESOLVED: Template fixed so wp:FRS runs 4 seconds. -Wikid77 17:05, 31 May 2013 (UTC)

Per discussion at Misplaced Pages:Administrators' noticeboard#What_is_wrong_with_WP:FRS?, there seems to be a problem in the reliability of the aforementioned page. When I make an edit, it gets through, but gives some a wikimedia error. The error it gives is on the page linked earlier. If anyone knows anything more, that would be great, thanks! -- Numbermaniac _(C) 12:36, 31 May 2013 (UTC)

Just to confirm I also tried editing the page and got a time out. There does seem to be quite a lot of templates on the page and the NewPP report is below.--Salix (talk): 12:45, 31 May 2013 (UTC)

NewPP limit report

Preprocessor visited node count: 253239/1000000

Preprocessor generated node count: 46210/1500000

Post‐expand include size: 1083093/2048000 bytes

Template argument size: 300421/2048000 bytes

Highest expansion depth: 18/40

Expensive parser function count: 1/500

• FIXED: Reformats WP:FRS in 4 sec not 28s as 7x-12x faster: I have rewritten and tested the username-linker Template:Frs_user, to set the username wikilinks 12x times faster than before. So, the wp:FRS page can reformat, or edit-save, within 4 seconds now, rather than the typical 28 seconds which would stretch to 60-sec timeout on busy servers. Thank you both for reporting the performance problem, and I am sorry wp:FRS had been running the slow 28 seconds for over 2 years. If everyone worries about performance, more, then we can fix these major problems years sooner. Are there any related slow pages? -Wikid77 (talk) 17:05, 31 May 2013 (UTC)

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)

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)

"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)

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 Misplaced Pages 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)

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)

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 Misplaced Pages to recruit new people we don't drive away more that are currently here contributing. Kumioko (talk) 17:59, 31 May 2013 (UTC)

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)

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)

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)

• 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)
  • 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)
  • 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)
    • 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... Misplaced Pages might be bigger than you think... Technical 13 (talk) 19:56, 31 May 2013 (UTC)
      • I'm active on English and German Misplaced Pages 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)
        • 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)

Toolserver issues

Why is the Toolserver not loading? For almost two weeks now I have gotten "Connection reset" messages when trying to access it. Is it really this bad off? --Nathan2055 16:32, 31 May 2013 (UTC)

Maybe just your account / browser? It has been working fine for me (minus the occasional and scary 'This user does not exist on en.wikipedia'!) GiantSnowman 16:35, 31 May 2013 (UTC)

The toolserver has not been working properly for months. Please see other threads on this page and in the archives. --Redrose64 (talk) 16:41, 31 May 2013 (UTC)

It's gotten to the point for me that the 20% of the time that toolserver works, it takes pages almost 10 minutes to load for me... It seems to have been abandoned already despite the fact that the memo said 2014... Technical 13 (talk) 16:49, 31 May 2013 (UTC)

The toolserver is a perfect example of exactly the type of problem we should be addressing, not all these stupid facebook facelift changes. We need to put time and effort into areas that will improve things, not in areas were it might, or just because we feel like it. Kumioko (talk) 16:55, 31 May 2013 (UTC)

The Toolserver is being addressed: Labs will replace it by the end of 2013. Already, many tool authors (including myself) have begun migrating their tools to the more stable Labs environment. I don't want to get into the politics behind the migration (the toolserver mailing list archives are quite revealing, if that's your kind of thing). Also, GiantSnowman: X!'s edit counter, btw, is currently being migrated by TParis and cyberpower678. Links on-wiki will be updated when that move is complete...those errors should go away :) Theopolisme (talk) 17:07, 31 May 2013 (UTC)

Thanks, yeah I was aware it was being addressed but my point was that we basically let the toolserver get to a state of collapse before we did anything about it and now we are having to struggle through several months of problems before its fixed. Assuming the replacement isn't delayed. It was just one example anyway. There are long lists of other things that IMO should have taken precedance over these types of changes. With that said, I have advocated for some time that the WMF needs to step up and do some of these things (technical and nontechnical) because the community has shown repeatedly we are incapable of doing them ourselves. So I admit its a bit hypocritical of me to say they need to step up and make the changes we can't but then criticize them when they do. When they do unwanted and unsolicated changes like these lately that also don't work and aren't particularly beneficial, it doesn't really reflect positively on them that their decision making skills are any better than ours. Kumioko (talk) 17:53, 31 May 2013 (UTC)

Migration of the edit counter and the very popular adminstats will need to wait another few weeks unfortunately. There are some tables that are not yet accessible on labs. We are preping the counter for labs though at this time.—cyberpower _Offline 18:17, 31 May 2013 (UTC)

Edit counter now not working? GiantSnowman 19:32, 31 May 2013 (UTC)

Like everything else on Toolserver, you can expect it to come and go at irregular unpredictable intervals. If you try again every hour or so, you might find that it works as it should. --Redrose64 (talk) 22:41, 31 May 2013 (UTC)

I broke all my tools accidently right before the wife shuffled me out the door for a dinner date with friends. So I cant fix them until I get home.--v/r - TP 23:26, 31 May 2013 (UTC)

Like'·addshore·' 08:27, 1 June 2013 (UTC)

↑ Do you do this on purpose? I hate it (as I hate Facebook) and I really hate to see it on Misplaced Pages! And it just accelerates "Facebookification we were talking about above in #New login and account creation designs being enabled soon. --Patrick87 (talk) 14:05, 1 June 2013 (UTC)

Sorry, not on purpose! Maybe we should create our own special wiki symbol to use? :D ·addshore· 20:29, 1 June 2013 (UTC)

 Brilliant idea! Patrick87 WikiloveS this idea! +

Whatever — as long as were not continuing to copy symbols from other communities. I like the Wiki community for not being the same like the others. I hope this will stay this way. --Patrick87 (talk) 22:04, 1 June 2013 (UTC)

Like What Patrick87 said! We should +1 Gogglefy instead! Technical 13 (talk) 16:30, 1 June 2013 (UTC)

Back to the edit count, mine hasn't been working for a full day now. Lova Falk talk 14:53, 1 June 2013 (UTC)

Yes, I’m getting 404 errors from the link at the bottom of Contributions.—Odysseus1479 20:21, 1 June 2013 (UTC)

Last I heard people were working on moving this to tool labs (and I heard this about 30 mins ago). I imagine all of the links will change once it gets set up :) ·addshore· 20:27, 1 June 2013 (UTC)

http://tools.wmflabs.org/xtools/pcount/ now.—cyberpower _Online 21:57, 1 June 2013 (UTC)

I expect you know all about this, but: It's not counting my deleted edits (of which there should be many, due to CSD tagging). Ignatzmice•talk 22:02, 1 June 2013 (UTC)

Same here, deleted edits: 0 - which isn't true. But the edit count is working again, which is good. Lova Falk talk 06:25, 2 June 2013 (UTC)

Yeah, I came here too just to say that my 2,000+ deleted edits has been reset to 0. Cool! Jared Preston (talk) 07:56, 2 June 2013 (UTC)

Ah, what I didn't notice is that the deleted edits have been subtracted from my total number of edits. So just for your information, instead of 43k edits, I now have 41k edits, acc. to the tool. Jared Preston (talk) 08:06, 2 June 2013 (UTC)

• Sorry guys. I forgot to mention that the labs does not yet allow us to access the deleted edits table list. That means it can't count deleted edits at the momemt. Coren has assured us that he's working on it.—cyberpower _Offline 10:36, 2 June 2013 (UTC)

  Oh and I just brought back the articles created counter. http://tools.wmflabs.org/xtools/pages —cyberpower _Offline 10:38, 2 June 2013 (UTC)

  So are these two new links going to be permanent? GiantSnowman 10:42, 2 June 2013 (UTC)

  For me it returned a blank page after about five seconds (Try it). I have made a lot of edits, though. -- John of Reading (talk) 10:46, 2 June 2013 (UTC)

  Edit counter is fine to me, loaded straight away - but the article creator counter took about 5 minutes to bring back a '502 Proxy Error'. GiantSnowman 10:49, 2 June 2013 (UTC)

• Hey guys. I'm most active at #xlabs . That's our official channel for these tools. It helps a lot to report the bugs there. The bug reports link also directs to there now. I will also look into the bugs me tipned here when I get home from work today.—cyberpower _Online 15:12, 2 June 2013 (UTC)
• Edit counter bug fixed. Fatal error: Allowed memory size of 67108864 bytes exhausted (tried to allocate 93 bytes) Since we are on labs, we can of course use more resources so I have enabled top edits for users that have more than 75,000 edits now but less than 500,000. I forgot to expanded the memory limit.—cyberpower _Online 21:04, 2 June 2013 (UTC)

For general information on Toolserver and Labs also see http://www.mediawiki.org/Wikimedia_Labs/Migration_of_Toolserver_tools and http://www.mediawiki.org/Wikimedia_Labs/Toolserver_features_needed_in_Tool_Labs for general information on the plans and status. --AKlapper (WMF) (talk) 09:22, 3 June 2013 (UTC)

• See also Misplaced Pages:Wikimedia Labs which has some helpful information and links. 64.40.54.184 (talk) 02:09, 4 June 2013 (UTC)

Change to the 'new editor getting started' tag

Hi everyone,

If you check RecentChanges often or have articles tagged for issues like copyediting on your watchlist, you might have noticed the "new editor getting started" tag. These edits are made via Misplaced Pages:GettingStarted, which is delivered to new editors after the first sign up. The change that we made yesterday is that, if you're autoconfirmed, your edits won't get tagged, even if you edit via the GettingStarted dashboard. Previously, all of the edits that came via that interface were tagged, even if you weren't really new.

Considering that most of the edits already do come from genuinely new editors, I don't think the volume level will change for the tag significantly. (Right it's about 100-300 edits a day ). However, since admins or patrollers might have noticed this tag, or used it for looking at newbie contributions as a group, I wanted to keep everyone in the loop about what the tag represented. Steven Walling (WMF) • talk 18:50, 31 May 2013 (UTC)

Cologne blue moving categories to bottom

Hi, can somebody provide me some coding to put the categories and interwiki links at the bottom of the page, it looks ridiculous for major topics.♦ Dr. ☠ Blofeld 20:00, 31 May 2013 (UTC)

AWB can do that. If you provide a list of articles and place a request, somebody will run AWB on those pages for you. Bgwhite (talk) 22:28, 31 May 2013 (UTC)

The question is not about the wiki source but about the rendered page in the Cologne Blue skin, for example http://en.wikipedia.org/Wikipedia?useskin=cologneblue. The languages are currently shown at both the top and bottom. At the top they overlap with the sidebar for me in Firefox. The categories are only shown at the top. PrimeHunter (talk) 22:47, 31 May 2013 (UTC)

The following CSS will get rid of the languages from the top, while keeping them at the bottom:

#langlinks { display: none; }

This should reduce the clutter a bit. I'm not sure how to move the categories to the bottom without causing more overlapping, though. – PartTimeGnome (talk | contribs) 01:07, 1 June 2013 (UTC)

It actually looks like a bug, with the links overlapping the sidebar. I submitted a fix —TheDJ (talk • contribs) 09:02, 1 June 2013 (UTC)

Thanks, perhaps the developers would consider changing the format slightly for cologne and placing the language and cats at the bottom? I mean check out United States on Cologne Blue, it just doesn't make sense to have that bloat at the top before an article on what is otherwise probably the nicest looking skin we now have..♦ Dr. ☠ Blofeld 11:10, 1 June 2013 (UTC)

Eh, I think we'd all love to, but there is probably not a single person who would want to burn his fingers on making such a big change to a skin like that, without significant evidence of community support of such a change. We are talking about removing an entire section of the skin, that would be a rare change. —TheDJ (talk • contribs) 19:25, 1 June 2013 (UTC)

this request (i.e., changing it for all cologne users) makes zero sense to me. people who use any skin other than vector usually (though, i would guess, not always) do not want anyone changing anything in the "skin" for them. as to the original question: try and add to Special:MyPage/cologneblue.js the following line:

$( function() { $( '#catlinks' ).appendTo( '#article' ) } );

my minimalistic testing hints that it will do what you want (or at least, what i understood from the request). peace - קיפודנחש (aka kipod) (talk) 01:17, 2 June 2013 (UTC)

"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)

Remove the HTML comment on line 54 – that's probably all. --Patrick87 (talk) 23:25, 31 Masup style="color:olive;font-family:arnprior">Chat]]y 2013 (UTC)

The syntax <!-- comment text --> 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)

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)

Wait, my what? -raylu 21:29, 4 June 2013 (UTC)

Page not displaying properly

There is a problem at 2002 Detroit Tigers season, with some of the text in the lower half of the article not displaying all the way across the screen. AutomaticStrikeout  ?  01:47, 1 June 2013 (UTC)

Fixed. --Patrick87 (talk) 01:58, 1 June 2013 (UTC)

Thank you. AutomaticStrikeout  ?  02:04, 1 June 2013 (UTC)

How to run a query about user contributions - help needed

I am intending to carry out a research following the 2011 Former Contributors Survey Results (WMF is aware and supportive of this project, which we hope will provide WMF and the community with useful information about editor retention; and I am a Misplaced Pages studies scholar with a track record of peer reviewed publications). A major part of this project involves studying the contribution patterns of most active editors; I am in particular interested if there is a correlation between contribution to certain namespaces/pages within them and editors becoming less active and/or leaving our project altogether.

However, doing this using the Special:Contribs is painful, verging on impossible due to being way too time consuming, particularly with the requests timing out 9 times out of 10 (and I am trying to create a dataset for edits of 1,000 or so editors). None of the tools listed at Misplaced Pages:WikiProject edit counters which I have used in the past have the functionality or speed I require.

At the same time I am pretty sure this can be done by individuals who have the voodoo knowledge required to use Misplaced Pages:Database queries; unfortunately I am not capable of doing so. To be honest, I am not even capable of carrying out the instructions at Misplaced Pages:Database_queries#Requesting_that_a_query_be_run; I have created an account on the toolserv but its interface is too unfriendly for non-CS person like myself to even be able to file a request there. Smirk if you will, I am a social scientist, my coding knowledge ends at wiki syntax, and the most technical place I can ask for help is here.

Therefore I am looking for help: I require an assistance from someone who can help me run some queries on the database. To be specific with regards to what I need, I have a sample of editors (based on Misplaced Pages:List of Wikipedians by number of edits) and I'd like to get numbers about their contribution to specific pages, such as WP:AN or WP:AE. As you can see, all the data I am looking for is publicly available; my problem is that I don't know how to make it machine-readable (i.e. create a .csv file or similar, so that I could run some queries of my own in statistical software such as SPSS). Ideally, the results would be distributed by each user on a time scale (monthly or daily), and paired with their total number of edits (so, saying for each editor in the sample that for month X that editor had X edits to AN, Y edits to..., and so on, within Z edits total). I know we have/had edit counters that could do this by namespace, so I am pretty sure this could be doable for individual pages or sets, too.

Please note that I can cover expenses required in obtaining this data from my research budget (in other words, I can pay for your time, or alternatively, I'd be happy to donate $$ from that budget to WMF, or help you get an article to a Good status, or write a DYK on a topic of your choice...).

Even if you cannot help me with all I am asking here, any advice would be appreciated (as in, if someone can point me to a specific downloadable (?) dataset that contains data I need, it may be easier for me t find somebody who can work on it but cannot find it, and so on). --_{Piotr Konieczny aka Prokonsul Piotrus| reply here} 11:47, 1 June 2013 (UTC)

@Piotrus:: You may find the user contribution search tool useful, but even it may not be powerful enough for your purposes. Perhaps it would be worth talking to the maintainer of that tool (and others like it), Scottywong. Graham87 16:39, 2 June 2013 (UTC)

@Piotrus: (Meatsock) User:Betacommand has offered to help. He can be contacted at betacommandtoolserver.org 930913(Congratulate) 17:00, 2 June 2013 (UTC)

Thank you for the pings and offers to help! --_{Piotr Konieczny aka Prokonsul Piotrus| reply here} 02:33, 3 June 2013 (UTC)

Autoblocks

Are autoblocks automatically lifted in the newest version of Mediawiki? I just went to unblock a user, and they automagically disappeared before I had a chance to undo them. Magog the Ogre (t • c) 15:31, 1 June 2013 (UTC)

That is, do they vanish when you unblock the user who was the source of the autoblock? Iirc, yep - User:Coren submitted the necessary patch, actually. Ironholds (talk) 15:35, 1 June 2013 (UTC)

Topics as wp:VPR proposals

To reduce clutter here, while allowing for multi-week discussions, I have submitted some new threads to Village Pump (proposals) wp:VPR:

• wp:VPR#Proposal: Periodically monitor pageview counts
• wp:VPR#Proposal: Move long-term proposals from PUMPTECH to VPR
• wp:VPR#Proposal: Have micro-pages as Micropedia-style articles

There tend to be fewer topics at VPR, so there is less clutter of short-term mixed with long-term issues. I have some other topics to add to that list later. If anyone wants to start a related thread here, that is fine, but I think the topics would be discussed for weeks or months at wp:PROPS. -Wikid77 17:04, 1 June 2013 (UTC)

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)

 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)

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)

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

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)

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

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 Misplaced Pages". 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)

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 Misplaced Pages into something... different. Killiondude (talk) 23:55, 1 June 2013 (UTC)

(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)

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 Misplaced Pages. Kumioko (talk) 23:59, 1 June 2013 (UTC)

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)

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

Wait. So tools like Twinkle and Huggle would stop working? Seriously? --NeilN 00:15, 2 June 2013 (UTC)

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)

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)

From Misplaced Pages:Flow/FAQ#How_will_Flow_handle_spam_and_vandalism.3F: "" *headdesk* Theopolisme (talk) 00:27, 2 June 2013 (UTC)

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 00:28, 2 June 2013 (UTC)

• 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 00:12, 2 June 2013 (UTC)

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)

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)

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)

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 00:23, 2 June 2013 (UTC)

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)

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)

(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)

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)

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)

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)

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

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)

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)

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

I can't remember where I read it, but I thought something said that Misplaced Pages 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)

• 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)

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

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)

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)

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)

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)

• 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)

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)

• • @Okeyes So are you saying Flow will not be implemented before acceptable alternatives for Twinkle, Huggle, Cluebot, etc are rolled out? --NeilN 04:09, 2 June 2013 (UTC)

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)

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)

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)

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

Thank you for your response. May I suggest putting some of it in here? --NeilN 05:56, 2 June 2013 (UTC)

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)

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)

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)

• 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)

@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:

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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.
7. 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.
8. 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)

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

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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)

• 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)

• 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)

• 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)

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)

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)

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)

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)

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)

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)

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)

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)

• 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)

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:Misplaced Pages 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) 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)

• 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)
  • 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)

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)

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)

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)

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)

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 "<span style="background-color: #ccc">This</span>" 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)

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)

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)

GFDL relicensing tag

Can we get a bot to go through and substitute the "migration" flag of images with the {{GFDL}} template? Right now, today, if someone uploads a {{GFDL}} image, it shows the {{License migration}} template. Now that it is four years after the license migration, I think it makes sense to change the default to be not eligible for migration. But in order to change the default, we would need a bot to do a one-time addition of something like migration=not-reviewed to all existing uses of the GFDL template. So if you have {{GFDL}} or {{self|GFDL}}, the template would add "migration=not-reviewed" to the template. After that is done, we can make the default "not-eligible" instead of the default being pending review. --B (talk) 00:16, 2 June 2013 (UTC)

Two problems concerning edit conflicts

Hi all,

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

1. 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.
2. 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

1. Only the section I'm editing visible in both edit windows.
2. 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)

• 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)

That would solve at least part of the problem, although I had hoped for a simpler solution (since I try to keep my Misplaced Pages 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)

@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)

@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: ]

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

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)

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)

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)

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)

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 Misplaced Pages. Fortunately, JQuery comes with excellent API documentation. Writ Keeper ⚇♔ 05:26, 2 June 2013 (UTC)

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)

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)

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)

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)

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)

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)

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

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

(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)

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

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)

(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)

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)

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)

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)

• 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)
  • Yep, looks like Brion had a similar concern to mine in comment 6. Writ Keeper ⚇♔ 16:01, 2 June 2013 (UTC)
    • 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)

"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)

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)

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)

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

• 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)

  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)

• 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)

+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)

• 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)

  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 Misplaced Pages:Notifications/FAQ#What happened to the orange bar for talk page messages on Misplaced Pages? to say that the orange bar requires JavaScript. – PartTimeGnome (talk | contribs) 00:03, 3 June 2013 (UTC)

  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)

  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)

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)

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)

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)

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)

Message for globally-locked

I just now went to block a spammer, but didn't because the system gave me a "The user Tujtatimento is already locked globally" message. Is this a new feature, or I have I just not seen it before? Nyttend (talk) 12:52, 2 June 2013 (UTC)

It's been around since at least October 2008]. You may recall this amusing accident that occurred thanks to that feature. Graham87 15:25, 2 June 2013 (UTC)

No, I'm sorry, I'm not asking about global locks — I was only asking about how Special:Block gives a message talking about the lock. But yes, I remember the incident; I pointed someone to this specific link a few days ago :-) Nyttend (talk) 16:56, 2 June 2013 (UTC)

I think you just missed it, its been around for a while. Most likely its since most of the time we don't bother to block globally locked users. In some cases it can be useful since it will trigger a local autoblock too. Legoktm (talk) 20:55, 3 June 2013 (UTC)

The Athena Skin

Interesting ... Has this been announced anywhere and I've missed it?--Gilderien Chat|List of good deeds 13:20, 2 June 2013 (UTC)

*Shudder*, and also the mediawiki page on it: mw:Athena. Both from a while ago, no idea what the current progress is on it. - Kingpin (talk) 13:40, 2 June 2013 (UTC)

As I commented in the Concerns with Flow discussion above it seems like the WMF is set on changing Misplaced Pages to be prettier and try and attract new users but basically stating the hell with those of us that already edit. The WMF has in multiple occasions said that editor retention is not a priority which, IMO is a large part the problem with why editors don't stay. Is true that some leave because it takes a while to learn the rules of the site but its more of a cultural problem with the community than a technical problem. The reason they leave is because a lot of folks in the community treat new editors like shit and block them or badger them before they have a chance to learn the policies. The policies are what makes the site hard, not learning to indent comments on talk pages with a colon or learning a little Wikimarkup or HTML. If we fix those cultural issues then we will start seeing improvements in editor retention both in longterm editors but new ones as well. Kumioko (talk) 14:34, 2 June 2013 (UTC)

Kumioko, as TheDJ says below, Athena is primarily a thought experiment. There are some elements we're working on, like having consistency in what bits of the UI are coloured what, but it was mostly an exercise in "what might Misplaced Pages need to look like in 5/10/20 years". Most things on MediaWiki.org are not things we plan to deploy, and I'm disappointed to see you launch into a schpiel from what is ultimately a misunderstanding - particularly one that argues we don't think editor retention is a priority. Can you please point me to any Foundation statement to that effect? Okeyes (WMF) (talk) 16:56, 2 June 2013 (UTC)

Okeyes, I think you are taking more offense at my comments than is intended. There just comments in a discussion voicing my concerns about comments that have been made and actions that are being taken. No offense is directed at you or the other individual members of the WMF. I'm not "Launching off" into a discussion. I am commenting in a discussion someone else created. You need to see things from my/our point of view though. There were recently several changes made to the site that were not an improvement, caused a lot of irritation and were generally not worth the time spent. Additionally, the WMF has stated in the past and generally has the attitude that they need not discuss changes to the software with the community nor ask our permission to implement them. If that offends you that I bring that up, then that's fine. I'm not the one that said it. I'm just repeating what the WMF has said in the past. Software development and maintenance of the iste is their domain. Site policy and updates to content for the most part are up to the community. I'm not going to go searching for diffs because its pretty common knowledge. I think you mentioned something like this before yourself. I also agree that there needs to be some design changes. But we are not facebook, we do not need to copy facebook; or twitter; or anything else. Its ok for us to have our own look. We need to design smart chanegs. Not copying and implementing Facebook functionality (and please dear god don't implement a Timeline CSS skin). I also know that Athena ended up as a thought experiment. But that is not how it started. It morphed into a thought experiment because some of us saw flaws in the methodolgy and assumptions being made with its development. Many of which are still applicable to Flow BTW. I would add too that Flow could work for a lot of Wiki's. Particularly those that are not template dependant. It could be one of those options in Mediawiki that doesn't get deployed here. That would be ok too. No one is saying that it can't be. But all evidence points to that it is going to be "forced" on us at some point in the future hell or high water so if that is to happen, I wanted to voice my conerns in the hopes that they are considered. I can't make you or anyone else do anything. But I have offered my comments and voiced my concerns. Its up to you whether you want to take me seriously or just ignore my comments and do whatever you want to do. Kumioko (talk) 15:00, 3 June 2013 (UTC)

Athena was sort of a thought experiment. Some of it's ideas have gone into the mobile skin, some led to echo, some are part of Flow, etc. —TheDJ (talk • contribs) 16:24, 2 June 2013 (UTC)

• Growing support for participatory design: I agree we should move to "Participatory design" but also just here on Misplaced Pages, without trying to talk with WMF employees (re: "You can't fight city hall"). We have enough numerous experienced editors who could create some "recommended" skin variations by resetting either CSS or JavaScript interfaces. This does not require developers, except to the extent that they do not botch the basic support for CSS and JavaScript to function. I have begun to design some new screens for Misplaced Pages, based on how an experienced computer scientist would format the screens, and then we could get many people to suggest other major ideas, not just shift menu options up/down and collapse. -Wikid77 (talk) 14:08, 3 June 2013 (UTC)
  • Heh, I think that most of Misplaced Pages's interface problems derive from being designed the way an experienced computer scientist would design them; all function, no form, everything geared toward the power-user, no thought given to the newbie. Writ Keeper ⚇♔ 14:15, 3 June 2013 (UTC)
  • You should have mentioned redesign for newbies years ago; a good solution is to have a Help-button on the screen, which shows a 2-level menu of 7 options, each tied to 7 sub-options, as 49 basic types of help, some of which would connect to wp:Help_desk personnel who would likely answer most unusual questions within 10 minutes, as indicated by a time-for-response box (but we need to auto-correct the common edit-conflicts which delay Help_desk answers). Most help-menu options would likely lead to common FAQ pages, where perhaps the top 15 questions would answer the concerns for 85% of new users in that situation. Once people start thinking in terms of the "49 most-common help topics" and the "top 25 questions" (or confusions) for each of those 49 sections (1,225 common issues), then numerous problems tend to become very quick to resolve. The more the new users select among the 49 help options, then the more quickly they would remember how to get online help for specific types of issues. Do you see how that would work, and how new users would gain insight, over time, about 1,225 initially unfathomable issues? -Wikid77 (talk) 01:01, 4 June 2013 (UTC)

Constant logoff under Safari

Some time in the last couple of days, my machine will no longer remain logged in to the Wiki. It seems to correspond with the new login form (which is quite nice BTW) appearing. Navigating even a few pages eventually logs me out. Is anyone else on Safari having similar problems? (in fact, it lost my login WHILE typing this message) 108.168.95.104 (talk) 17:29, 2 June 2013 (UTC)

• Almost daily changes to MediaWiki configuration: For 2 weeks I have also experienced end-of-day automatic logoffs for the so-called "30 day" old login screen, but using Firefox, yet never clearing the stored cookies. I can detect when the MediaWiki interface is being fiddled, every day, because my browser cache goes haywire (often several times per day), which indicates some MediaWiki core files are in constant flux, unlike months ago. Here's the deal: if people find how to fix the 30-day login, today, that does not mean it will still work 10 minutes later (sorry, but reality). My favorite adage, "It's not whether you can fit 10,000 angels on the head of a pin, but whether you can keep them there". Always preview before posting a message, to check for auto-logoff as IP address. -Wikid77 14:08/23:57, 3 June 2013 (UTC)

Hey, I've tested this in Safari, and I'm not seeing any unusual behavior. Note that currently the login session is tied to your browser session, and if you don't check the "Keep me logged in" option, it will not remember you by default for 30 days. (For reference, the 30 day maximum is defined by our privacy policy. If you want to be able to stay logged in for longer as an option, I'd encourage you to keep an eye out for an upcoming discussion of a rewrite of the policy, and ask for what you want. There will be a length community consultation before it is finalized.) Steven Walling (WMF) • talk 18:50, 3 June 2013 (UTC)

I am wondering if a login+exit of browser (after +check "30 day") might help to remember the login username. Anyway thanks for running a sanity check of the Safari login, and explaining the dreaded 30-day limit. For users who run monthly update drives, the auto-logoff in mid-edit was a nightmare, causing the save to attribute an IP user to that revision, then exposing a person to wp:SOCKpuppetry claims when editing same page by both username & IP address at same time, leading to wp:Wikihounding at wp:ANI by witchhunt-like atmosphere, which means 3 days of reply-or-else, with potential to torture victim by ANI-dragout as inhuman 7-day torture of unredacted insult-per-minute, followed by 30-day block for wp:Wikilawyering for being "too right" in refuting false claims accurately, followed by lifelong grudges by admins who are afraid to be reviewed (etc.), all because 30-day login expired (oops, so FUBARed) before a 31-day month ended. Anyway never tie software operations to be policeman of policies, but allow each user optional restrictions, where the user is ultimately responsible for exceeding policies of 30-day max logins. -Wikid77 (talk) 23:57, 3 June 2013 (UTC)

@Wikid77: Did the above scenario that you speak of actually happen? Because it sounds like one of the most extreme cases of over-exaggeration I've ever heard, frankly. Theopolisme (talk) 00:10, 4 June 2013 (UTC)

There are posts of mine that are IP posts due to the fact that I've been logged out mid-edit... I use Firefox so I doubt it is Safari specific. Writ Keeper actually revdel one of them to protect my IP, the other times it has happened I said not to worry about it. Tracing my IP will just lead you to my university of which I've disclosed in a few places already anyways... Technical 13 (talk) 01:16, 4 June 2013 (UTC)

Top edited pages

Going from this page, I have decided, out of mere curiosity, to create the page User:Toccata quarta/EditCounterOptIn.js. But when I'm about to do that, I get a warning stating "Code that you insert on this page could contain malicious content capable of compromising your account." My question is: how can I know if what I'm going to enter into the page might compromise my account? And moreover, what kind of content should I place into the page? Pressing "Save page" without doing anything else brings no result. Thank you in advance. Toccata quarta (talk) 17:37, 2 June 2013 (UTC)

• You're totally fine. JavaScript can do some bad things, if you code it right (wrong?), but you don't even have to have any actual JavaScript in that page. See, for example, my opt-in page. Ignatzmice•talk 17:41, 2 June 2013 (UTC)

Does that mean that the list of top edited pages will become available at tools.wmflabs.org if I enter a mere period? Toccata quarta (talk) 17:46, 2 June 2013 (UTC)

Indeed. I'm not the one who wrote it, but it certainly seems that all the tool does is check for the existence of that page (with any content). A period would be fine. Ignatzmice•talk 17:52, 2 June 2013 (UTC)

Thank you for your help—I have created the page now. Toccata quarta (talk) 18:02, 2 June 2013 (UTC)

This is...

...the error I'm getting when trying to use "What links here ==> Redirects only". The article is Maria of Antioch. Thx. José Luiz 00:58, 3 June 2013 (UTC)

Yeah, it's broken everywhere. For some reason, that tool uses screen-scraping to get the list of redirects, a technique which is very prone to breakage. (That seems to be what's happened in this case.) The API would be a better alternative; however, this is up to Dispenser (talk · contribs) to deal with. — This, that and the other (talk) 01:11, 3 June 2013 (UTC)

So, you're actually saying that, up until this "Dispenser" does indeed decides to rethink the technique he used in this particular tool, a hyperlink active in every single enwiki article will be broken to everyone? IMHO, there should be some kind of governance about this s...tuff. Anyway, thank you. Let me see if I can sort those redirs out somehow. José Luiz 02:54, 3 June 2013 (UTC)

We can remove the link in the mean time. —TheDJ (talk • contribs) 06:35, 3 June 2013 (UTC)

Done. Using the "hide links" feature pretty much has the same effect anyway. Graham87 09:55, 3 June 2013 (UTC)

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)

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)

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 <small> or <center> or <font face=Georgia>, 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)

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

Ditto. And <small> is not obsolete in HTML5. --  Gadget850 13:07, 3 June 2013 (UTC)

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

• Fortunately, using "<small>" 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)
  • 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)
    • 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)
      • 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. <font>. — Carl (CBM · talk) 17:28, 3 June 2013 (UTC)
        • 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 17:45, 3 June 2013 (UTC)
          • And there is a bug report requesting that obsolete elements be converted. Have to did around to see the status on that one. --  Gadget850 17:47, 3 June 2013 (UTC)
            • 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 <span style="font-size:larger;"> --Patrick87 (talk) 17:54, 3 June 2013 (UTC)
              • 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 <font>, 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 19:41, 3 June 2013 (UTC)
                • 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)
                  • 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)

UTC Clock Gadget

I noticed something odd while editing with the UTC clock gadget. When I CSDed a page, the UTC clock read exactly 17:50:00, but the page history noted the edit as having occurred at 17:48. Any reason for this discrepancy? It's a minor issue, but it never occurred to me that the UTC Clock might be off. Altamel (talk) 18:10, 3 June 2013 (UTC)

It's probably just that there's a mismatch between your computer's time and the server's time. Misplaced Pages uses its own server time for the revision timestamps (naturally), but the UTC live clock gadget actually uses your computer's internal time, and the two can be out of alignment. You can see this by going into your computer's clock and advancing it a half hour: the UTC live clock will follow the leader and advance a half hour, while the revision timestamps will obviously not change accordingly. Writ Keeper ⚇♔ 18:18, 3 June 2013 (UTC)

• See mw:MediaWiki talk:Gadget-UTCLiveClock.js#Improvment of the clock gadget for more details and discussion on this. Technical 13 (talk) 18:26, 3 June 2013 (UTC)

Yep. My computer was about 90 seconds ahead of the U.S. Government's official time. Which is bad because supposedly, Windows is automatically synchronized with time.gov. Thanks for the help. Altamel (talk) 18:48, 3 June 2013 (UTC)

I had no clue that the gadget was dependent on my computer's clock. Thanks for the details! Nyttend (talk) 03:50, 4 June 2013 (UTC)

Archives

I recently set up one of the MiszaBots to archive my talk page, and it came with a fancy box to display links to old archives. I have two archives set up so far by the bot, but no links to them on my talk page. What's going on and can it be fixed? Thanks, TheOneSean 18:14, 3 June 2013 (UTC)

I've made an edit, and the names are now showing. Unfortunately the {{archives}} template can only display the names automatically if you are using the simplest naming scheme. -- John of Reading (talk) 05:27, 4 June 2013 (UTC)

Other languages

 Done

Hi, the en:WP page Magallanes & the Chilean Antarctica must be linked to the es:WP es:Región de Magallanes y de la Antártica Chilena. I added the link on the old way but I guess that it will be deleted. Can anzone of the admins add the link in the new fashion way?. Thanks a lot. --Best regards, Keysanger (what?) 18:50, 3 June 2013 (UTC)

The proper way to manage language links now is by editing Wikidata. You don't need to be an admin to change language links. In particular, this entry is wikidata:Q2189. As it turned out, the English language link was pointing to a redirect (Magallanes y la Antártica Chilena Region) instead of the main article (Magallanes & the Chilean Antarctica), which was preventing the language links from showing properly. I fixed it and now all seems kosher. Jason Quinn (talk) 19:06, 3 June 2013 (UTC)

Thanks again. --Best regards, Keysanger (what?) 19:24, 3 June 2013 (UTC)

Tech news: 2013-23

Latest tech news from the Wikimedia technical community. Please inform other users about these changes.

Recent software changes

(Not all changes will affect you.)

• The latest version of MediaWiki (1.22/wmf5) was added to non-Misplaced Pages wikis on May 29. It will be enabled on the English Misplaced Pages on June 3, and on all other Wikipedias on June 5.
• The Tamil Misplaced Pages shared a Lua module they created to automate their Main Page.
• There is now a test wiki to test new features in right-to-left languages.
• The Thanks feature was added to the English Misplaced Pages; users can now thank others for individual edits.
• The new interface for account creation and log-in is now the default on 30 wikis, including the English Misplaced Pages, Commons, Meta, and Wikidata. The feature will be added to all wikis after June 5. Users can return to the old look by adding ?useNew=0 to the web address.
• Videos are now played in pop-up windows if their size on the page is smaller than 200 pixels (800 pixels on the English Misplaced Pages).
• Opening your talk page now marks notifications as read, for wikis using the Notifications feature. (bug 47912) .
• All autoconfirmed users can now reset transcoding of video files; previously only administrators could do this.
• The Nearby feature allows people who use mobile devices to see Misplaced Pages articles about objects and places around them.

Future software changes

• The PostEdit feature is now part of MediaWiki, and will work on all wikis. (bug 48726)
• The Narayam and WebFonts extensions will be replaced by the Universal Language Selector extension.
• MediaWiki will now be updated every week, starting on June 6. Thanks to this, bugs will be fixed and features will be added faster than they are now.

Tech news prepared by tech ambassadors and posted by Global message delivery • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

19:15, 3 June 2013 (UTC)

Trademark discussion

Hi, apologies for posting this in English, but I wanted to alert your community to a discussion on Meta about potential changes to the Wikimedia Trademark Policy. Please translate this statement if you can. We hope that you will all participate in the discussion; we also welcome translations of the legal team’s statement into as many languages as possible and encourage you to voice your thoughts there. Please see the Trademark practices discussion (on Meta-Wiki) for more information. Thank you! --Mdennis (WMF) (talk) 01:26, 4 June 2013 (UTC)

It's okay, we forgive your English! :) Theopolisme (talk) 02:02, 4 June 2013 (UTC)

Check For Identical Edits

I started a conversation here: http://en.wikipedia.org/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)

• 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)

  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)

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)

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)

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)

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

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

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

• 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)

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 ""), 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 's down the page, at each paragraph, and perhaps have a Special:Preferences option to put "" at the left-side of talk-page text, rather than as all right-side '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 "" 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 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)

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)

Instead, "micromanagement" is a style of planning, organization and control (POC) which dictates excessive commands at low-level operations. Also, wp:LiquidThreads was 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 ability to redact insults. Instead, listing the paragraph-edit buttons (as "") would simply extend the "" feature at every paragraph and could probably be implemented within a few weeks, based on treating each "" 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)

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)

• 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)

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: Misplaced Pages 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)

Keep opt-in

1. 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)

   Urgh. It's on labs now, and the toolserver version will be shutoff soon.—cyberpower _Online 14:51, 4 June 2013 (UTC)

2. This is a clear privacy issue, I fail to see how anybody can see otherwise. GiantSnowman 15:02, 4 June 2013 (UTC)

   Believe me, a lot of people on IRC tried. I said I'm not doing it without an RfC.—cyberpower _Online 15:24, 4 June 2013 (UTC)

3. +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)
4. 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)
5. 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)

Remove opt-in and replace with opt-out

1. 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 17:46, 4 June 2013 (UTC)

Remove opt-in completely

1. 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)

   Who's Max? --MZMcBride (talk) 22:18, 4 June 2013 (UTC)

2. 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)
3. 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 18:02, 4 June 2013 (UTC)

   Note that if the tool is hosted on a wikimedia de server, then the opt-in must stay. Prodego 18:03, 4 June 2013 (UTC)

4. 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)
5. 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. ThemFromSpace 23:08, 4 June 2013 (UTC)
6. 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)
7. Per Tom Morris. Ironholds (talk) 00:24, 5 June 2013 (UTC)

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? GiantSnowman 13:23, 4 June 2013 (UTC)

  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 _Online 14:10, 4 June 2013 (UTC)

  No, it's still clear as mud. Opt-in to what? GiantSnowman 14:22, 4 June 2013 (UTC)

  Top Namespaces Edits and monthly statistics.—cyberpower _Online 14:23, 4 June 2013 (UTC)

  Slightly clearer - but I'll repeat, "visible to themselves, or visible to the public?" GiantSnowman 14:26, 4 June 2013 (UTC)

  Removing optin means visible to the public.—cyberpower _Online 14:28, 4 June 2013 (UTC)

  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)

  @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 _Online 15:00, 4 June 2013 (UTC)

  I'm still not 100% clear, can somebody else please have a go seeing as cyberpower is unable/unwilling? GiantSnowman 14:40, 4 June 2013 (UTC)

  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 _Online 14:57, 4 June 2013 (UTC)

  No, that's perfect, exactly what I was looking for! Some of us aren't as technically minded as others... ;) GiantSnowman 15:01, 4 June 2013 (UTC)

• 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)

  Some users wish the compilation of public data to be readily accessible. I am well aware that this is public data.—cyberpower _Online 14:10, 4 June 2013 (UTC)

  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)

  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)

• It was an issue on the toolserver due to German privacy laws which are bizarrely strict. Werieth (talk) 14:05, 4 June 2013 (UTC)

  Correct. And I'm very strong on Privacy concerns. Maybe because I'm German too.—cyberpower _Online 14:10, 4 June 2013 (UTC)

• 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 15:40, 4 June 2013 (UTC)

  I also am not sure as to why, if this was a serious proposal, the English Misplaced Pages would get to decide what happens to a global tool. Snowolf 15:41, 4 June 2013 (UTC)

  It's not toolserver anymore. It's labs. Completely different now.—cyberpower _Online 15:51, 4 June 2013 (UTC)

  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)

  It is now completely up to the owner of the tool, as Snowolf says. This vote doesn't really matter. Prodego 18:09, 4 June 2013 (UTC)

  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 _Offline 18:16, 4 June 2013 (UTC)

  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)

• 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/_Talk」 22:06, 4 June 2013 (UTC)

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)

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

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)

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)

See #Toolserver issues above. GiantSnowman 16:01, 4 June 2013 (UTC)

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)

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

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

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)

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

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)

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)

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)

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)

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 20:59, 4 June 2013 (UTC)

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

• Misplaced Pages noticeboards
• Pages automatically checked for accidental language links
• Misplaced Pages requests for comment