Jump to content

Wikipedia:Village pump (technical)/Archive 113

Add links
From Wikipedia, the free encyclopedia
Village pump (technical) archive  

This page contains discussions that have been archived from Village pump (technical). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.

< Older discussions · Archives: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR, AS, AT, AU, AV, AW, AX · 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215, 216, 217

adding thumbnails (namely thumbnails 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}} → India.—Emil J. 15:27, 4 June 2013 (UTC)
Be careful. Use of flags is becoming less popular because of the political issues they raise. See MOS:FLAG. —[AlanM1(talk)]— 01:23, 10 June 2013 (UTC)

kml option has stopped working

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

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

A proposal to solve the problem with unequal height of rows

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

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

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

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

Those seem to be badly encoded URLs, probably originating from malformed links on some website(s). Not much we can do about that. — Edokter (talk) — 10:27, 9 June 2013 (UTC)
I do not think that creating thousands of redirects for cases like this and that is a right way, because they would become expensive to watch and complicated to maintain (especially in the case of a merge–unmerge cycle). If some definite pattern can be detected, such as these URLs with non-standard hexadecimal escapes, and there are substantiated expectation that it will persist, then developers should consider some URL rewrite built into the engine. If it is a glitch caused, say, by some version of a browser or some version of a CMS, which are expected to be fixed soon, then the right way is just ignore. It is not our problem. Incnis Mrsi (talk) 10:38, 9 June 2013 (UTC)
WP:Topred is currently dominated by entries containing \x. In the cases I examined, it was a percent encoding of a real title with each % incorrectly replaced by \x. For example, "Michael Bubl\xC3\xA9" in a url would be the incorrect http://wiki.riteme.site/wiki/Michael_Bubl\xC3\xA9 while the correct percent encoding is http://wiki.riteme.site/wiki/Michael_Bubl%C3%A9. The 12 May list [1] had no entries containing \x so it seems like a recent problem (some of the older lists had a limited number of \x entries). I agree it's too soon to think about creating redirects from the invalid encodings. PrimeHunter (talk) 11:21, 9 June 2013 (UTC)
As Incis hinted, this looks like a bug in code/script to in-line Wikipedia content (and perhaps the high numbers are caused by automatic re-attempts upon failure). What would be really interesting is to see if these redlink cases are being driven by a single or small set of IP addresses. While that would be fun, we shouldn't expect the analytics team to help us with this due to the privacy issues involved. Thanks, West.andrew.g (talk) 13:06, 9 June 2013 (UTC)
I've seen issues like this with Toolserver tools, but I can't reproduce it so far with Firefox 21 or MSIE 10. Maybe someone using an older version of MSIE could try the links with accented letters on http://toolserver.org/~dpl/ch/dab_challenge.php ? GoingBatty (talk) 17:30, 9 June 2013 (UTC)
Perhaps the referrers and user agents could be logged for a period, aggregated and anonymized (as well as culled of uniques)? That should give some hints as to the origin of the problem. Also, a temporary workaround could be employed using Javascript, similar to the case-sensitive fixer for some Wiktionary projects. If a browser ends up on a red title, and if the name includes some known bad encoding that can be repaired, and if a page with the correct encoding exists (via quick API call check), then (after a short delay) the location could be changed to the correct one. Eg: wikt:Dummy --Splarka (rant) 07:30, 10 June 2013 (UTC)

Passing a location to Special:Nearby?

Tracked in Phabricator
Task T51413

At the end of this discussion, an editor suggested the ability to pass an arbitrary location to Special:Nearby. I'd like this as well, because if I'm going to a particular area, I'd like to see if any nearby articles need pictures. I read about some of the workarounds in the previous discussion but they are either cumbersome off-wiki approaches (Marble) or not sufficiently helpful (querying the server directly and getting raw XML back). Regards, Orange Suede Sofa (talk) 00:22, 10 June 2013 (UTC)

If you have Firefox then you could try https://addons.mozilla.org/en-us/firefox/addon/geolocater/ to set a location in the browser. I haven't tried it. PrimeHunter (talk) 00:57, 10 June 2013 (UTC)
i like the idea of allowing passing location to nearby (e.g. "Special:NearBy/44.12,-71.13"), which does not depend on browser at all. we could use such links in portals, on wikivoyage, and more. however, i think it makes more sense to post such a suggestion in mw:Mobile design rather than on enwiki's en:WP:VPT ... peace - קיפודנחש (aka kipod) (talk) 14:54, 10 June 2013 (UTC)
The suggestion was the first response at https://blog.wikimedia.org/2013/05/29/wikipedia-nearby-beta/. The Mobile Software Engineer Jon Robson replied: "Currently there is no option to manually insert a location but it would be trivial to add this functionality. The main complication around doing this is the design Ideally we hope to integrate a map feature in future which would make it easy to drop a pin and see nearby articles. It doesn’t really make sense to allow users to enter a longitude and latitude coordinate as these are not very human friendly :)".
IMHO, that is a poor reason to reject something that would be trivial to add. Allowing users to enter longitude and latitude would be a vast improvement over nothing, especially assuming it can be done with e.g. "Special:NearBy/44.12,-71.13" so various tools can generate a clickable link. PrimeHunter (talk) 15:47, 10 June 2013 (UTC)
I agree with PrimeHunter, especially as Jon said "it would be trivial." Is there a bugzilla? Theopolisme (talk) 15:52, 10 June 2013 (UTC)
esp. since it's not just about users adding the coords manually - this should be done in a way that will allow creating internal links to "nearby"'s, e.g. by using a link in the form "Special:Nearby/coords", which should work even when the device/browser can't/won't allow sending its coordinates. peace - קיפודנחש (aka kipod) (talk) 16:29, 10 June 2013 (UTC)
Raise a bug to make sure this doesn't get lost. I should have been clear. The bit that is trivial is allowing user input. The bit that isn't is how you present that information. It requires a lot of discussion around how it can be queried and what the expected behaviour is when it is queried. For instance if I pass in a geo coordinate what does refresh do? If I pass in a geo coordinate how do I know I'm looking at things near that geo coordinate rather than things nearby? All these design considerations need attention - otherwise we risk the danger of someone thinking they are looking at articles nearby which are actually articles near somewhere completely different and people thinking they are looking at something broken. Jdlrobson (talk) 21:06, 10 June 2013 (UTC)
I've logged a bug at bugzilla:49413. – PartTimeGnome (talk | contribs) 21:41, 10 June 2013 (UTC)
Yes! It would be great if tools like GeoHack could have links to Special:Nearby.
Regarding concerns that entering a longitude and latitude isn't user friendly, how about allowing entry of any article name where the article has geodata? Users could then enter the name of a town (or nearest notable location) rather than having to look up the coordinates themselves. – PartTimeGnome (talk | contribs) 21:17, 10 June 2013 (UTC)
For articles that have coords registered, another option could be to add a link from the standard left-hand "Toolbox" links-- "What's nearby" or similar. Regards, Orange Suede Sofa (talk) 21:26, 10 June 2013 (UTC)
That's another great idea! – PartTimeGnome (talk | contribs) 21:41, 10 June 2013 (UTC)

Watchlist Notifications

Hello, I have left a proposal for a short message to placed on everyone's watchlist next week here which needs approval.--Dom497 (talk) 00:08, 11 June 2013 (UTC)

Tests show "section=new" has edit-conflict

(edit conflict) I have begun discussions about fixing simple edit-conflicts in the several related Bugzilla reports from 2006-2010-2013. Meanwhile, in running tests, I have confirmed that using "section=new" does not reduce edit-conflicts, so if a user intended to reply in a bottom section and also append a new section, then just do both as a bottom-section edit (plus "==Next=="), rather than a separate "section=new". In fact the "section=new" operation also caused an edit-conflict for a later reply in the "penultimate" section, because when adding a "section=new" then the next-to-bottom section also hit edit-conflict, even when separated by a 3-line section between them. From reading the implementation discussions, the software has a function to "append at end of page" (with no comparison of changes), but that still causes the 2nd editor to hit edit-conflict, after a pure append of new text at page bottom. I'll work with Bugzilla to see if the "section=new" operation can be fixed to not edit-conflict against changes to the bottom 2 sections, but in the meantime, beware changing either of the bottom 2 sections of a page could hit edit-conflict after a recent "section=new" addition. If a Show-changes reveals a new "==Header==" at bottom, then beware a conflict. -Wikid77 (talk) 09:14, 11 June 2013 (UTC)

For reference, section editing doesn't really do anything special. We just put it all through GNU diff3, at let that program sort it out. Bawolff (talk) 19:29, 11 June 2013 (UTC)
Thanks for confirming that, as it explains why the edit-conflicts are much the same after all these years, using diff3 as a black box tool and not improving the merge algorithm inside it. I assume it still re-syncs the differences after insert/delete only when the successive entire lines match, rather than resync on lines with the same prefix or suffix text. One possible path forward would be to write a variation of diff3 for talk-page edit-merges, rewritten to allow close-merging of adjacent lines perhaps called "diff3near" which would stack new additions, together, when seeking to resync at the common lines after the merged lines. Currently, diff3 is like a sledge hammer to ensure handling all nail sizes, when a diff3near could be like a tap hammer to easily handle the "small nails" in talk-pages without getting "nail-conflict" to separate small nails near each other. Talk-pages (and many articles) need a more-refined, 3-version merge tool which treats adjacent lines (or phrases) as typical edit-collaborations, not edit-conflicts. Editing is currently just fine, as long as people do not imagine working together, during the same minutes, on revising the same paragraph! -Wikid77 00:04, 12 June 2013 (UTC)

Article feedback on the main page

Is that intentional? If it is, what is the point? -- Toshio Yamaguchi 11:02, 11 June 2013 (UTC)

Feedback on the Main Page?

I just noticed a "reader comments" feedback link on the Main Page; it goes here, and there's just one small comment. Since when is feedback enabled on the Main Page, and why? Nyttend (talk) 21:45, 11 June 2013 (UTC)

I suspect that this edit may be related; but it occurred in between the above two comments. --Redrose64 (talk) 21:59, 11 June 2013 (UTC)

When a bot edits one of my pages,

I don't receive an eMail notification despite having set in my preferences to receive notifications by eMail. I have previously alerted Meno25 to this as it's his bot that placing maintenance templates across my pages and he has brung me here. Any idea what's going on?--Launchballer 17:10, 11 June 2013 (UTC)

Hello Launchballer, is the bot in question listed on MediaWiki:Echo-blacklist? Technical 13 (talk) 17:20, 11 June 2013 (UTC)
No Technical 13, it isn't; it's MenoBot II.--Launchballer 17:24, 11 June 2013 (UTC)
Okay, Launchballer, then next question is if you get any emails at all from anyone. The way that the system currently works is that you only get one email per page no matter how many subsequent edits are done to that page until you go to the history of that page and view the changes. If you read down through the email messages that you get from editors, you should find something like:
There will be no other notifications in case of further activity unless
you visit this page. You could also reset the notification flags for all
your watched pages on your watchlist.

            Your friendly MediaWiki notification system
Unless I am mistaken, it uses the same logic as bolding on your watchlist. If you log in and look at your watchlist you should see a bunch of bold items or items with funky green bullets as opposed to the normal pastel blue ones. You will not receive an email for any of those pages as long as they are noted as being not visited. I'm assuming that this is the trouble you are having. There is no way that I am aware of to get an email for every edit regardless of whether or not you have viewed the differences. It may be worth submitting a bugzilla ticket to have that option. Technical 13 (talk) 17:38, 11 June 2013 (UTC)
That makes some sense, but I have set it to get an eMail for each edit. We are dealing with edits that have occurred by bots immediately after I created the article (see All I See (A+ song) for an example that I did not receive an eMail for).--Launchballer 17:56, 11 June 2013 (UTC)
The new Notifications isn't involved in this.
1) Under Preferenes->User Profile, at the very bottom, there is the option "Email me when a page or file on my watchlist is changed". This has to be checked. You will only get an email when your watchlist has changed.
2) The edit to All I See (A+ song), was done by a bot and was labeled as a minor edit. Under Preferences->Watchlist, you must NOT HAVE "Hide bot edits from the watchlist" and "Hide my edits from the watchlist" checked. If you have one of these checked, your watchlist will not be updated, thus you will not receive an email. Bgwhite (talk) 18:18, 11 June 2013 (UTC)
I think Bgwhite meant "Hide minor edits from the watchlist" must not be checked, rather than "my edits". – PartTimeGnome (talk | contribs) 19:24, 11 June 2013 (UTC)
I kind of guessed that was intended. Neither of them are checked. The top six are unchecked, while the bottom four (below the watchlist token) are checked.--Launchballer 20:00, 11 June 2013 (UTC)

Pywikipedia

I've been trying to download PyWikipediaBot at here, but I'm getting the "Connection has timed out" box. All other sites are working fine. Ypnypn (talk) 20:09, 11 June 2013 (UTC)

Download it here instead. Cheers, Theopolisme (talk) 20:33, 11 June 2013 (UTC)

I just noticed that the toolbox has a "Request feedback" link, but when I click it I'm sent to the protection screen. For example, clicking the link at Sandusky High School sends me to http://wiki.riteme.site/w/index.php?title=Sandusky_High_School&action=protect. (1) If you're a non-admin and click this line in the toolbox, do you get a "permission denied" type of message as if you click my Sandusky link? (2) What's the point of an additional link to the protection screen? (3) Why is this link called "request feedback" when it's not related? I mean, if I start using this link at lots of prominent pages, I'll start getting feedback all right, but not the type that would be expected from a "request feedback" link. Nyttend (talk) 23:46, 11 June 2013 (UTC)

My tests with alternative accounts show it's only a protect link in admin accounts. The admin options in the protection screen include to enable or disable feedback. In autoconfirmed non-admin accounts "Request feedback" leads to a feedback feature. For IP's and non-autoconfirmed accounts there is no "Request feedback". PrimeHunter (talk) 00:26, 12 June 2013 (UTC)

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

A Thanks notification.

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

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

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

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

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

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)
Tracked in Phabricator
Task T49658
I think that two clicks for something so simple that some users may actually intend to use to thank for 25-40 edits a day is too much... That being said, I'm not opposed (as mentioned on the related bugzilla) to having it so that when you click (thank) instead of it changing to (thanked) that it instead changes to (un-thank) or (de-thank) allowing you to undo it if it wasn't intentional. Technical 13 (talk) 17:57, 2 June 2013 (UTC)
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)
  • Hi everyone, thank you so much for all your helpful feedback about the Thanks feature! We have reviewed all the comments from a variety of channels and have started to discuss and prioritize feature requests, based on your suggestions. Over a dozen people have reported issues with the thanks link, which has caused some to accidentally click "thank" instead of "undo" on history and diff pages. We are now working on this issue as our top priority, as it appears that the current placement next to undo is problematic, as well as the lack of a confirmation or 'unthank' function. To help us solve this issue quickly, we would be grateful if you could answer a few questions, so we can pinpoint the problem more accurately -- and develop an appropriate solution in coming days. To keep our discussion focused in one place, we have posted these questions and a feature update on this Thanks talk page, and encourage you to post your answers on that thread. Thanks again for all your good insights! Fabrice Florin (WMF) (talk) 20:44, 5 June 2013 (UTC)
    • Hi Fabrice. As an intermediate solution, can we at least swap the positions of the "Undo" and "Thank" links? That should dramatically decrease the likelyhood of clicking Thanks by accident, as we all expect the Undo link at the right most position. — Edokter (talk) — 16:05, 8 June 2013 (UTC)
      • OK, your idea is nice, your workaround put (without any previous discussion) into common.css is just unacceptable. Now the link is green! Not only that links are supposed to be blue with default settings, now it also looks like the "updated since my last visit" messages and messes up my experience with history pages completely! --Patrick87 (talk) 17:18, 8 June 2013 (UTC)

Time limit for thanks

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

I don't see a problem with that. Helder 18:48, 8 June 2013 (UTC)
Better late than never! GiantSnowman 10:49, 11 June 2013 (UTC)

Suggestion about the icon

I'm ambivalent about the heart icon associated with the thanks notice. To me, it connotes "love" (as in a valentine) more than "thanks". Perhaps something like this: would be better. --Tryptofish (talk) 22:00, 12 June 2013 (UTC)

This is already discussed on Wikipedia talk:Notifications/Thanks#Change the i-love-you heart to something more neutral. A smiley was suggested and received positively. However there were some considerations on copyright. --Patrick87 (talk) 23:35, 12 June 2013 (UTC)
See http://www.unicode.org/charts/PDF/U1F600.pdf.
—Wavelength (talk) 23:59, 12 June 2013 (UTC)
Thanks. I'll comment there. --Tryptofish (talk) 00:25, 13 June 2013 (UTC)

Captcha

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

Don't bother - the latest contributions by Sawwooddoow (talk · contribs) show that this is another troll. -- John of Reading (talk) 20:32, 6 June 2013 (UTC)
Thanks. It looked like a duck, and sounded like a duck, but it was good to hear the quack. - Karenjc 16:57, 7 June 2013 (UTC)
I agree that looks like trolling, but for future reference, it is indeed two completely random English words. I've seen some that could be strange or offensive, and apparently so have other people... [2], [3], [4] Steven Walling (WMF) • talk 17:23, 7 June 2013 (UTC)
Well, gerrit:53124 has kinda been sitting there for a while now... Legoktm (talk) 01:14, 13 June 2013 (UTC)

How does "You have new messages" work?

How exactly does the You have new messages functionality work? Is there some kind of flag like visited since last change=false? I am asking this because I would like to know whether it would be possible to set that flag manually. An example: Say I get a message from another user. I log into my account and get the new messages notification. I then visit my talkpage and find that the issue is too complex to be dealt with at the moment. I would set the flag back to true, which would trigger the You have new messages message again. Is that possible? -- Toshio Yamaguchi 10:44, 11 June 2013 (UTC)

Not currently. It uses timestamps. There is a last viewed timestamp for when you read the page, and one for the last edit. If last edit newer than last viewed you have new messages. Werieth (talk) 12:37, 11 June 2013 (UTC)
:-( Helder 12:16, 12 June 2013 (UTC)

Tech news: 2013-24

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

Recent software changes
(Not all changes will affect you.)
Future software changes
  • A report on mobile upload errors was published, and software changes to reduce their number will come soon. [12]
  • A request for comments on updating MediaWiki to use RDFa version 1.1 was started on MediaWiki.org (Gerrit change #67608).

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

20:05, 11 June 2013 (UTC)

And Notifications and Thanks has been updated: Wikipedia_talk:Notifications#This_week.27s_update. —TheDJ (talk • contribs) 16:10, 12 June 2013 (UTC)

Afc proposal help?

Has anyone had a chance to test out the code listed above at #Proposed change to the Afc submission process? —Anne Delong (talk) 14:09, 12 June 2013 (UTC)

Is daily option working for notification emails?

It took me almost exactly a week to get an email about this revert, even though my notification preferences are set for "A daily summary of notifications" and I saw and clicked on the web-based notification within a couple hours of said revert. I did not change any notification preferences during that time.

Is this something I/we need to worry about? If this is a known issue, is it already documented anywhere? --SoledadKabocha (talk) 17:37, 12 June 2013 (UTC)

WT:Notifications might be a good place to bring this up. Theopolisme (talk) 20:18, 12 June 2013 (UTC)

template cite pmid

Hi, I have a problem with {{cite pmid}}, since yesterday, I saw that it doesn't display correct when it is a redirect to a Template:cite doi/some-id, as it can be seen in Leukoencephalopathy#References.

File:Cite pmid display error.png
screenshot

Any idea about what is happening? --Götz (talk) 21:00, 12 June 2013 (UTC)

A purge fixed Leukoencephalopathy#References. PrimeHunter (talk) 21:08, 12 June 2013 (UTC)
Interesting, now I understand, thanks! Götz (talk) 02:47, 13 June 2013 (UTC)

Wiki signup translation

Sorry for writing here. I'm from another wiki. We have a problem about translation on Special:UserLogin&type=signup. want to translate this line (Wikipedia is made by people like you., 4,255,469 articles, 126,229 recent contributors). but can't find those line in translatewiki.net. How Can i do ? Can anyone help me?--Aftab1995 (talk) 21:46, 12 June 2013 (UTC)

See the bottom of http://wiki.riteme.site/w/index.php?title=Special:UserLogin&type=signup&uselang=qqx for the names of the used MediaWiki namespace pages. The first is MediaWiki:createacct-benefit-heading. PrimeHunter (talk) 22:07, 12 June 2013 (UTC)

Request for import user right

I have asked to be granted the import user right so I can import some long-lost revisions into the Wikipedia database. Please see the discussion on the proposals village pump and add any comments there. Graham87 03:19, 13 June 2013 (UTC)

Status update no longer in contributions?

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

I see your last update in both your contributions and the page history as 5 June at 18:09 (UTC). At present your user page says "Online", which matches what I see in the Status subpage.
It isn't possible for you to update the page when your computer is off. A bot running on another computer could do it if there was some mechanism to remotely check your computer is on (e.g. a program on your computer that stays in contact with the bot). However, this is a somewhat over-engineered solution. – PartTimeGnome (talk | contribs) 21:35, 7 June 2013 (UTC)
Why is my status update not in my contributions, then? And I am offline now after I submit as I have things to do.— Vchimpanzee · talk · contributions · 21:39, 7 June 2013 (UTC)
Wait, I don't show myself updating my status Wednesday. That's it.— Vchimpanzee · talk · contributions · 21:42, 7 June 2013 (UTC)
(edit conflict) When you log in to Wikipedia, a cookie is set on your computer. That cookie is sent back to Wikipedia whenever you request any page, or you send an edit. The only way that Wikipedia knows that you're logged in is if it receives that cookie along with the page request; so technically speaking, you're logged out all the time except for the few milliseconds that it takes to retrieve a page. --Redrose64 (talk) 21:47, 7 June 2013 (UTC)

It does sound like more trouble than it's worth, but I distinctly remember clicking on "offline" before I signed off the computer Monday and it's not in my contributions. Neither is my clicking on "online" today. It wasn't the last thing I did so it's not like I didn't wait long enough before turning off the computer.— Vchimpanzee · talk · contributions · 19:46, 12 June 2013 (UTC)

Whatever I did just now worked ... — Vchimpanzee · talk · contributions · 20:10, 12 June 2013 (UTC)
Those status changes aren't in the page history either. When you tried to go offline on Monday, the edit didn't save at all. When you tried to go online today your status was already online, so it was a null edit. Null edits are not saved in the database, so don't show in the page history or your contributions. I don't know why your "offline" status update didn't save.
Are you aware of losing any other edits, or is it just the status updates? If it's just the status updates, I'd suggest asking the author of the "user online" script you are using if they have any ideas. – PartTimeGnome (talk | contribs) 20:15, 12 June 2013 (UTC)
If you log out before you click on "Status: Online", I'm pretty sure that the status change won't be actioned, because it requires you to be logged in as yourself. It's possible to become logged out even if you didn't use the Log out link upper right, for example by telling your browser to clear cookies. --Redrose64 (talk) 21:19, 12 June 2013 (UTC)
You will need to be logged in for the script to update your status as the javascript dynamically edit the /status subpage based on your username. I've had a look at the script and it seems fine for me so I'd advise purging your cache and if it still doesn't work, try editing the subpage without the script ie. change the subpage to online or offline yourself and see if that works. CJ Drop me a line! • Contribs 09:16, 13 June 2013 (UTC)

Popups not working in page histories

Hi. I use Vector skin on IE8. Recently (I don't know when, but certainly today and yesterday), navigation popups stopped working for me when used in page histories. They still work fine elsewhere, including articles, talk pages and watchlist. Any ideas please? --Stfg (talk) 16:51, 12 June 2013 (UTC)

  • Beware weekly updates to Wikipedia: As you probably know, the current plan is to update the MediaWiki software every Monday/Tuesday, and so beware the next weekly surprise. With a weekly update schedule, it is almost impossible to effectively announce the proposed changes, in a manner where part-time volunteers have time to process the scheduled impacts. It is perhaps not worth taking time to wonder about the latest problems, because next week, they will either break again or be eclipsed by other, more horrifying changes. I have already explained that "moving the brake pedal or steering wheel" on a weekly, daily, or hourly basis is very disruptive to operations. Each person needs to assess how much time to burn, each week, worrying about the rampant questionable changes. However, if you ever wondered how it feels to be a "lab mouse in a maze" where the paths might change every time.... -Wikid77 (talk) 20:16, 12 June 2013 (UTC)
I came here to ask a specific and civil question that may indicate a bug that could be fixed. I think I deserve not to be talked down to about software design management, which I actually do know something about. Now, anyone any ideas about the specific problem, please? --Stfg (talk) 21:14, 12 June 2013 (UTC)
Sorry, I was just checking to see if you wanted to spend much time analyzing this specific problem. -Wikid77 12:38, 13 June 2013 (UTC)
Oh I see. Sorry. Yes, I can spend time on it. Popups are very useful, and other editors may benefit if we can resolve it. --Stfg (talk) 12:58, 13 June 2013 (UTC)
I don't think Wikid77 intended to talk down to anyone. I think he just has a habit of writing tangentially related mini-essays around here. :-)
Does anything show up in your browser's error console when visiting a history page with pop-ups enabled? Can you provide a specific URL that isn't working (for debugging purposes)? It sounds like a selector may have gone missing or something, but it's difficult to say for sure right now. --MZMcBride (talk) 01:10, 13 June 2013 (UTC)
I installed pop-ups and they seem to work fine at <https://wiki.riteme.site/w/index.php?title=User_talk:MZMcBride&action=history&useskin=vector> for me. I'd missed that you're using IE8, though. Can you try another browser? That would help pinpoint this issue. IE8... well, you know. --MZMcBride (talk) 01:16, 13 June 2013 (UTC)
Hi MZMcBride. Thanks for your help. When I load your talk page history from the link above, the IE8 status bar says "Done" until I hover over a "prev" link. After doing that, the status bar says "Error on page" and the details file gives message that's I've copied into User:Stfg/Sandbox1. Does this help? I don't have any other browsers installed, but will do so if you need further info. Cheers, --Stfg (talk) 09:01, 13 June 2013 (UTC)
  • Analyzing messages in User:Stfg/Sandbox1: Some other browsers have no trouble with processing https-protocol for "action=raw", so what happens in IE8 if you open another tab and try running request:
https://wiki.riteme.site/w/index.php?title=MediaWiki:Gadget-popups.js&action=raw&ctype=text/javascript&532528798
Does that request display the JavaScript "main.js" text immediately, or do you get a secure-server warning about the "https:" prefix in the line? -Wikid77 12:38, 13 June 2013 (UTC)
Thanks for looking at this. It asks me if I want to save it or find a program online to open it. --Stfg (talk) 12:55, 13 June 2013 (UTC)
Some other browsers, such as Firefox, simply display the contents of the requested JavaScript text, with no questions about access, and even though IE8 has been the world's most-popular browser for years, some aspects of the MediaWiki software are periodically changed and break the processing with IE8, which differs from IE9 and those other browsers. -Wikid77 (talk) 13:46, 13 June 2013 (UTC)
Popups is using the RL module 'mediawiki.user', without declaring it as a dependency. That might be related... —TheDJ (talk • contribs) 13:52, 13 June 2013 (UTC)
it's absolutely related. in the meantime, until the popup maintainer(s) will add the dependency directly to the script (i don't think this can be done through MediaWiki:Gadgets-definition - currently popup gadget does not use RL, so it can't declare dependencies), you can patch this specific problem for yourself, by adding to Special:MyPage/common.js the following line:
mw.loader.load('mediawiki.user')
there is another bug in mediawiki code that currently only affects IE users: it's in the new "thanks" extension, in this file: [13], line 53: the problem is that this module defines an object with a member named class, which IE considers a reserved word, so it bulks. the fix is very simple - just change class: 'ui-button-green', to 'class': 'ui-button-green',. this probably required opening a bugzilla report, but unfortunately i can't do that ATM. peace - קיפודנחש (aka kipod) (talk) 14:34, 13 June 2013 (UTC)
Thanks. That patch didn't solve it, I'm afraid, but if it's going to be fixed soon, let's not worry too much about the temporary issue. Thanks everyone. --Stfg (talk) 15:56, 13 June 2013 (UTC)
You can use RL modules in non-RL gadgets using code like mw.loader.using('mediawiki.user', function(){ ... }) – the callback function will be executed after the module is loaded. One could just wrap the entire Popups' code in this and it should start working. @kipod – I submitted a patch to the Thanks extension at https://gerrit.wikimedia.org/r/68418, I'll poke someone to get it deployed soon, thanks. Matma Rex talk 16:14, 13 June 2013 (UTC)
As a former popups maintainer :D I added the dependency —TheDJ (talk • contribs) 21:20, 13 June 2013 (UTC)
And bingo! it's working again even in page histories and even with IE8. Many thanks everyone who spent time on this. --Stfg (talk) 22:12, 13 June 2013 (UTC)

VisualEditor breaks BLP warnings

Tracked in Phabricator
Task T51552

Hi. When BLP articles (e.g., Barack Obama) are edited with the normal source editor, a warning about BLP policy appears at the top of the page; this is omitted when the article is edited with the new VisualEditor. I raised this on the VE feedback page and was told that it's not a VE bug per se but a result of the way the warning is generated by the article being in a particular category. Since VE is aimed especially at helping new editors, who probably aren't going to be familiar with our policies about BLPs, it seems important that the warning should be displayed through VE. Is there any way this can be done? Dricherby (talk) 22:39, 12 June 2013 (UTC)

{{BLP editintro}} is added by the editintro code for the English Wikipedia in MediaWiki:Common.js. I don't know whether it can added by the VisualEditor but if you don't get an answer here then you could try asking at MediaWiki talk:Common.js. PrimeHunter (talk) 23:04, 12 June 2013 (UTC)
Thanks for the extra explanation, PrimeHunter. I'll try the page you linked if we don't get it sorted here. Dricherby (talk) 08:55, 13 June 2013 (UTC)
For future reference. the block to add to has class "ve-init-mw-viewPageTarget-toolbar-editNotices". It needs to be wrapped in something with class "ve-init-mw-viewPageTarget-toolbar-editNotices-notice". Now to find a hook to know that the VE is done with setup. —TheDJ (talk • contribs) 22:23, 13 June 2013 (UTC)
Hmm, too easily do this might require adding some events to the VE. I've created a ticket to track this problem. —TheDJ (talk • contribs) 22:35, 13 June 2013 (UTC)

Module:IncrementParams

For any infobox template editors out there, I have just written Module:IncrementParams. This module increments numbered parameters of infoboxes and other similar templates, so that you don't have to renumber all the parameters by hand. Enjoy! — Mr. Stradivarius ♪ talk ♪ 08:40, 13 June 2013 (UTC)

Removal of a deleted page from view

Hi, can a deleted page (ie title, deletion notice and reasons) be completely deleted so that others cannot see it and it does not appear when google searched? Thanks for your help JulieSmith123 (talk) 15:07, 13 June 2013 (UTC)

How is it currently not "completely deleted"? Note that we don't have influence on search results that 3rd parties (e.g. Google) cached (made a copy of) at some point. --AKlapper (WMF) (talk) 15:48, 13 June 2013 (UTC)
And Google will presumably stop indexing it next time they crawl Wikipedia and find the article has gone. (I assume that robots.txt or some other mechanism stops search engines crawling the article creation page you get after clicking on a redlink to an article, which mentions that the article formerly there was deleted.) Dricherby (talk) 15:52, 13 June 2013 (UTC)
Deleted pages return a 404 HTTP status code, aka "Not Found". This tells Google that the page doesn't exist, so Google removes it from its index (eventually). Content such as the deletion log is returned with the status code for display in web browsers, but the 404 causes Google to ignore it. – PartTimeGnome (talk | contribs) 22:01, 13 June 2013 (UTC)
We also have no say over websites such as Deletionpedia. GiantSnowman 15:56, 13 June 2013 (UTC)
AKlapper, Sorry I should have been clearer by "not completely deleted" I mean the title, deletion notice and reasons for its deletion remain (content is gone). Although it is not, I was wondering if there was a deleted article with a libelous or defamatory title would it also remain on wikipedia? I know that you have no influence over 3rd parties, but if a deleted page's title remains, consequentially it still appears on google search pages.Thank you Dricherby - JulieSmith123 (talk) 16:05, 13 June 2013 (UTC)
That information can be wiped, given a valid reason for doing so. Werieth (talk) 16:12, 13 June 2013 (UTC)
Are those valid reasons available anywhere? JulieSmith123 (talk) 16:17, 13 June 2013 (UTC)
You should provide one. GiantSnowman 16:19, 13 June 2013 (UTC)
Who would I send it to and who would deem it valid? JulieSmith123 (talk) 16:27, 13 June 2013 (UTC)
Special:EmailUser/Oversight Contact them and they will review your request. Werieth (talk) 16:31, 13 June 2013 (UTC)
Thank you!!-JulieSmith123 (talk) 16:35, 13 June 2013 (UTC)
Although, if this is related to Clonakylti, I see nothing under RevDel or Oversight policies that would justify its purging (✉→BWilkins←✎) 16:41, 13 June 2013 (UTC)

For the record, there is in fact a list of valid reasons for suppression at Wikipedia:Oversight#Policy. Beeblebrox (talk) 16:40, 13 June 2013 (UTC)

As BWilkins says above, I'm not sure this counts. GiantSnowman 16:44, 13 June 2013 (UTC)
The deletion notice serves as a warning to others not to re-create the page without good reason. In general, the existence of that notice isn't something to worry about: it doesn't reflect badly on you or anyone else, for example (it doesn't even mention anyone by name, apart from the person who deleted the page). Dricherby (talk) 16:52, 13 June 2013 (UTC)
Thanks, no this query doesn't necessarily regard Clonakylti. For the record, I do find deleted for "Unambiguous advertising or promotion" does slightly undermine your credibility- there could be a possible argument for defamation as it could lower your reputation in the eyes of the reasonable-thinking members of society and it mentions the company by name, a person in the eyes of the law- but I do not intend to!! JulieSmith123 (talk) 16:58, 13 June 2013 (UTC)
That's ridiculous, the article was deleted as being promotional, it has no bearing on the company itself, and I must warn you are dancing right up to the line of making a legal threat, which is grounds for immediate blocking. I would suggest you just quietly make whatever request you were going to make to oversight and maybe review the core policies of Wikipedia so that you better understand what is and is not appropriate content. Beeblebrox (talk) 17:09, 13 June 2013 (UTC)
Emphasis: there could be a possible argument and repeated use of the word could but I do not intend to. You will find I did not make any argument. I do not intend to make any request. — Preceding unsigned comment added by JulieSmith123 (talk • contribs) 17:20, 13 June 2013 (UTC)
  • Blanked page with speedy tagbox had cleared Google cache: As typical, when an article for deletion has been blanked and tagged for speedy-delete, then Google resets the indexed cache copy to clear any prior contents. Any use of Google Search, which matches the topic, will link to the deleted page, with no contents to display, and any views of the Google cache will just show the speedy-delete tagbox and none of the prior contents of the deleted page. After a few days, the page-rank typically falls quickly, and within a week, then a direct Google request for the page title might yield zero results, because the prior cache page would be completely hidden from view (as shown when the temporary rename of "Gone with the Wind (film)" caused it to vanish from Google after a few days). Note that an improperly deleted page would remain a few days in Google, to allow time to be discussed and restored without affecting the Google search-results, but a spam page can be blanked/tagged for instant re-caching, and the remaining days of access would just indicate the blanked page was deleted. -Wikid77 (talk) 18:44, 13 June 2013 (UTC)

Thank you Wikid77. - JulieSmith123 (talk) 19:01, 13 June 2013 (UTC)

Special:MyPage plus action=edit ?

Special:MyPage is a magic word that goes to the user's userpage. Is there a way to add/pass an action=edit parameter in the url so that it goes to the editing page of a user's userpage? Cheers! Ocaasi t | c 15:13, 13 June 2013 (UTC)

Well, yeah, it's the same as any other page. Just do https://wiki.riteme.site/w/index.php?title=Special:MyPage&action=edit. (It's not a magic word per se, it's a special page that forwards to one's own userspace, IIRC.) Writ Keeper ⚇♔ 15:17, 13 June 2013 (UTC)
You cannot make a querystring in a wikilink like Special:MyPage?action=edit but as Writ Keeper shows, there is no problem in a url. You can also do it with http://wiki.riteme.site/wiki/Special:MyPage?action=edit. The prettiest and most portable way to do it may be with {{Querylink}} as in {{Querylink|Special:MyPage|qs=action=edit|edit your user page}} to produce edit your user page. PrimeHunter (talk) 18:54, 13 June 2013 (UTC)
You can also use {{edit}}. E.g. {{edit|Special:MyPage|edit your user page}} gives "edit your user page". – PartTimeGnome (talk | contribs) 22:04, 13 June 2013 (UTC)
Thanks all, any of those will work, and the url version is best suited to what I'm working on. Cheers! Ocaasi t | c 03:29, 14 June 2013 (UTC)

This is just FYI. A few of the prior pages with wp:Google https links have resumed the original http-prefix, including: "Gone with the Wind (film)", "Alan Turing" and "American Football". Ironically, the GWTW novel page has shifted to Google https-protocol ("Gone with the Wind") but that allows comparing the recent http/https pageview counts, and many other older pages (such as "Parabola" and "Hyperbola"), still have Google https links as of 13 June 2013. -Wikid77 19:12, 13 June 2013 (UTC)

{{DEFAULTSORT}} behavior on subpages (archived talk pages)

Observe that Category:Closed move reviews has three archived pages listed under A – I assume that they're sorting by A for "Archive". Why don't they sort under B, T, and I? I put a {{DEFAULTSORT:Burma}} tag at the bottom of Talk:Burma/Archive 10 and still it sorts under A rather than B, even though the Page Information shows that the "Default sort key" is Burma. What's up? Thanks, Wbm1058 (talk) 19:41, 13 June 2013 (UTC)

A {{DEFAULTSORT}} is always overridden if a category has an explicit sort key. It's the {{MRVdiscuss}}, which essentially contains a [[Category:Closed move reviews|{{SUBPAGENAME}}]]. --Redrose64 (talk) 20:43, 13 June 2013 (UTC)
Changing the sort key to BASEPAGENAME fixed it. Thanks! Wbm1058 (talk) 21:40, 13 June 2013 (UTC)

Proposed change to the Afc submission process

Dear Technical people:

Writ Keeper has been helping me to implement a proposed addition to the Afc submission process. The proposal is here User:Anne Delong/AfcBox. It has already been through Rfc and been accepted. We would both like a technical assessment to make sure that the javascript is operating properly and not causing interaction problems. If you would like to help check this out, you can find the code at User:Writ Keeper/Scripts/afcDialog.js, and a sample page at User:Writ Keeper/sandbox.

After fixing any technical problems, I will be posting at the Afc talk page for comment on the exact wording of the options, so please hold your comments about that for now so that they'll end up in the right discussion later. Then we'll be working out how to try it with real editors and get feedback from them.

Please let either me or Writ Keeper know if you try this out, whether it works as expected, and whether you forsee any technical problems. (We'll deal with editor interaction problems later at the Afc). Thank you. —Anne Delong (talk) 16:55, 10 June 2013 (UTC)

An implementation note: if we want to give this a trial run (and certainly if it ever goes into production), it needs to be made a default-on gadget, so the code should probably be reviewed with that in mind. I don't think there's anything that's not cross-compatible in it. Writ Keeper ⚇♔ 16:58, 10 June 2013 (UTC)
@Writ Keeper:, no chance to test it, but I'd change at least the url building a bit. like this. —TheDJ (talk • contribs) 18:01, 10 June 2013 (UTC)
Okay, I'll look into that. You changed the typeof thing, but I don't think your version works: it still gives the "not defined" error when I test it in my console, at least, so I'm going to stick with typeof for now. Writ Keeper ⚇♔ 20:11, 10 June 2013 (UTC)
Other than the typeof thing, your suggested changes have been implemented and seem to work. Writ Keeper ⚇♔ 20:23, 10 June 2013 (UTC)
  • No promises, but I'll try to set some time aside this week to import the script into my common and test it on all five major browsers (latest version of all except IE which I run v7). I'll let you know what I find. Technical 13 (talk) 18:06, 10 June 2013 (UTC)
Hi Technical 13, have you had time to deal with this yet? Roger (Dodger67) (talk) 20:38, 14 June 2013 (UTC)
I'm sorry, I haven't yet. The only thing higher on my todo list right now is a fix I have in my head for AFCH typeof o = null error. Soon. Technical 13 (talk) 21:38, 14 June 2013 (UTC)

VisualEditor weekly update - 2013-06-13 (MW 1.22wmf7)

Hey all,

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

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

The most noticeable change for users is that you can now insert images and other media items from the local wiki and Commons - they default to right-floated thumbnailed images with no caption set. Images will also now appear "correctly", positioned in the normal places when editing. We will make it possible to set the caption, as well as convert images from thumbnails to inline or floating on the other side, in the coming week. We also changed the "Save page" workflow to no longer require users to view a wikitext diff before saving (bug 49258), and removed the 'alpha' notice, replacing it with a more subtle beta label (bug 48428). Work continued on ​inserting and editing Templates and References​, ​the other two critical areas ahead of the release ​, which we hope to​ ​​make available in the next week or so.

We fixed some bugs relating to support for multi-byte Unicode characters used by some languages (bug 49246 and 48630) and some tweaks to the category setting interface released last week (bug 48555, bug 48555 and bug 48565). HTML comments and elements that have no contents like some <span>s will now not be silently dropped when editing (bug 48605). You can now use the forwards and back buttons on your browser with VisualEditor as you would expect (bug 43844).

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

Ahead of the regular MediaWiki deployment roadmap, this should be deployed here late today, Thursday 13 June.

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

Jdforrester (WMF) (talk) 17:58, 13 June 2013 (UTC)

Note that section edit links will now take users to the VE, if they have the VE beta enabled. There is a preference switch to have section edit tabs take you to the source, rather than visual, editor - "Use the wikitext editor for editing sections while VisualEditor is in beta " under "Editing". Okeyes (WMF) (talk) 10:42, 14 June 2013 (UTC)
Will there be a preference to do the same when VisualEditor is no longer in beta? In fact, can it be the same preference? Anomie⚔ 11:32, 14 June 2013 (UTC)
Thanks for providing this option. I am basically waiting for template & reference editing to be available before properly looking at visual editor. Rjwilmsi 11:33, 14 June 2013 (UTC)

How to explain simple fixes for edit-conflict

Where can we discuss the ways to fix the simple edit-conflicts, as a page where all concerns can be addressed? Bugzilla is an old, cumbersome forum-style dialogue, where each message is a comment-box which contains the quoted prior comment to reply to "Comment 17" or such. After months of discussions about ways to fix edit-conflicts, I am getting several replies where people think the edit-conflicts are just fine, even saying that an edit of the bottom section should conflict against a new thread "==Topic==" appended at end of page. What is so frustrating is that many of the common edit-conflicts would be "10-minute fixes" to GNU diff3, with no need to rewrite it until auto-correcting the more-intertwined edit-conflicts. Long-term, an auto-correction of edit-conflicts could even merge a prior change to an infobox where all parameters were shifted to align, while a second editor changed the values of some infobox parameters (and those new values would be aligned in the merge), which is completely forbidden today. Should we have an essay "wp:Fixing MediaWiki edit-conflicts" where the talk-page would debate issues to list in the essay? This really upsets me that the edit-conflicts would be so easy to fix (the GNU diff3 utility has been known for over 25 years), but the conflicts are not considered to be a problem. -Wikid77 (talk) 08:25, 14 June 2013 (UTC)

Bugzilla tracks the history of a report, mailinglist wiktech-l is for discussion of the software, #mediawiki IRC channel is for direct discussion with fellow developers and patches go to gerrit. —TheDJ (talk • contribs) 08:50, 14 June 2013 (UTC)
  • Ways to edit with fewer edit-conflicts: Because some people think edit-conflicts are great for warning when other editors are working on adjacent lines, there has been resistance to any fixing of edit-conflicts. Instead, there are some promising tricks which can be used to reduce edit-conflicts in busy pages, such as splitting lines (into 3 or more parts) or putting a thread-footer at the end-of-section. Tests have confirmed that adding text to the bottom thread of a page will avoid conflict with section=new, if the text is added above a footer line, as shown below. Since it has been difficult to get the MediaWiki software improved to auto-correct for edit-conflicts, then perhaps we can explain tricks of conflict-avoidance to more editors, in the manner of "How to drive on a busy highway" (or similar) when there is no other help. -Wikid77 (talk) 00:46, 16 June 2013 (UTC)
(footer - reply above here to avoid conflict with section=new)

Visual editor as default for section editing makes editing task in section impossible

Tracked in Phabricator
Task T50429

I tried to edit the section 2022 FIFA World Cup#Venues because I want to remove a non-free file violating WP:NFCC. However, when editing the section, I edit in the visual editor by default and I don't seem to understand how to remove a file in VE. What do I have to do? -- Toshio Yamaguchi 11:09, 15 June 2013 (UTC)

There are plenty of complaints of a similar nature at Wikipedia:VisualEditor/Feedback. --Redrose64 (talk) 11:17, 15 June 2013 (UTC)
Well, I solved the problem by simply disabling VE in my preferences. -- Toshio Yamaguchi 11:21, 15 June 2013 (UTC)
For the record, handling this in a saner way is discussed at T50429. Matma Rex talk 12:30, 15 June 2013 (UTC)
And I just submitted a patch[14] to show two links side-by-side, in the form of

"[edit] [edit source]", similarly to how the article tabs are done. Hopefully it'll be merged and deployed after the weekend. Matma Rex talk 18:06, 15 June 2013 (UTC)

Why?

Why isn't this feature enabled AFTER all the bugs have been swept out? What is the point of forcing an incomplete feature on us? Why can't this be tested on some test wiki first BEFORE going live on EN Wikipedia? I just don't understand it? -- Toshio Yamaguchi 15:52, 15 June 2013 (UTC)

Because this is opt-in alpha software. Matma Rex talk 17:40, 15 June 2013 (UTC)
Because they need a lot of willing testers, to find and report the bugs, so that it gets rapidly better.
We have the largest userbase; we have and use most of the features that mediawiki offers to the 'pedias; and we (mostly) speak the same language as the devs. Therefor those of us that opt-in, are perfect bug-finders.
I do agree this section-edit feature wasn't a perfect rollout, but it is being discussed. –Quiddity (talk) 17:49, 15 June 2013 (UTC)

Lining

See this: FH+
2.

Or even, better, see how it works in a real text.

Several important inorganic acids contain fluorine. They are generally very strong because of the high electronegativity of fluorine. One such acid, fluoroantimonic acid (HSbF6), is the strongest charge-neutral acid known.[1] The dispersion of the charge on the anion affects the acidity of the solvated proton (in form of FH+
2): The compound has an extremely low pKa of −28 and is 10 quadrillion (1016) times stronger than pure sulfuric acid.[1]Fluoroantimonic acid is so strong that it protonates otherwise inert compounds like hydrocarbons. Hungarian-American chemist George Olah received the 1994 Nobel Prize in chemistry for investigating such reactions.[2]

References

  1. ^ a b Olah, George A. (2005). "Crossing conventional boundaries in half a century of research". Journal of Organic Chemistry. 70 (7): 2413–2429. doi:10.1021/jo040285o. PMID 15787527.
  2. ^ "The Nobel Prize in chemistry 1994". nobelprize.org. Retrieved 22 December 2008.

Is there a way of adding a subscript and a supscript at the same place so they don't mess up the lining of a paragraph?

Thank you very much in advance--R8R Gtrs (talk) 13:46, 15 June 2013 (UTC)

We could force the line-height. FH+
2 —TheDJ (talk • contribs) 14:35, 15 June 2013 (UTC)
Yes, that is a way out, thank you indeed, I'll switch to it if nothing easier comes out. But I'm sure I have seen an easier way, does anybody know it?--R8R Gtrs (talk) 15:10, 15 June 2013 (UTC)
How about this: FH+2 --Redrose64 (talk) 15:58, 15 June 2013 (UTC)
It's nice, I can even type it by heart. Thank you very much!--R8R Gtrs (talk) 16:05, 15 June 2013 (UTC)
{{chem}} uses {{su}}. The su template is made to work on all browsers and to resemble sub/sup height and spacing as closely as possible on all of them, but may as a result have a slightly-off spacing. I would not recommend using any hand-coded solutions, as that will potentially not display correct in all browsers. — Edokter (talk) — 20:55, 15 June 2013 (UTC)

Bolding on watchlist has gone away, please give it back

Please give me the bold marks on the watchlist back, since the update today they have completely gone away – no matter that the pages all haven’t been watched, it tells that they all have which is wrong. I have been told in the meantime that they now only can be seen, when someone has a functionating (newer version of) JavaScript in the browser. But that again is not what unobtrusive JavaScript is about. First no notifications here anymore and no possibility to change interwikis anymore because of Wikidata and so on (new translation feature not editable), now these changes back again, what comes next? WT:Flow#‎Flow without javascript, the VisualEditor, what else should be feared to get live some day?

Shall it not be possible anymore to edit Wikipedia without scripts? Why? Why shall WP editors be forced to new systems, new browsers, new scripts? Does the Foundation want to drive editors away who are not compatible with that what the Foundation wants? If this kind of driving away the editors will continue in the future, then the editors will be away someday, yes. But why do you want this to happen? I thought that there would be a reaching-out for new editors. But it seems to be that theses new editors must meet some technical conditions which are set by the Foundation. That’s really a pity. Everyone should be able to edit WP. Also in the future. Can you please take a look upon Wikipedia:Petition to the WMF on handling of interface changes before changing such things? --Geitost 22:14, 13 June 2013 (UTC)

Please change this back, so that everyone can see the bold marks again: gerrit:65414, CSS file. Or fix it in another way. I don’t have a bugzilla account and don’t want one. --Geitost 22:40, 13 June 2013 (UTC)

This looks like an unintended side effect of a change. You should report it as a bug in bugzilla by following the instructions How to report a bug, in this case under the product 'MediaWiki' and the component 'Interface'. 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!—TheDJ (talk • contribs) 22:58, 13 June 2013 (UTC)
Please read my last sentence, I don’t like to be forced to get a new e-mail address which has to be posted in Bugzilla and there can be seen by everyone, so I won’t make a bugzilla account. I thought that maybe the developers also take a look here, if they update MediaWiki.
I first noticed this change today between 20:00 and 21:00 (CEST) which is between 18:00 and 19:00 (UTC). That is exactly the time when the new version of MediaWiki had been placed to dewiki. And the same happens here on enwiki again, and I think here has also taken place a MW update at this time. So I suppose that this issue here is related to the one above at #Bolding on watchlist despite preference set for no bolding, where users who didn’t want this feature took a script for not seeing it anymore. Now that this feature has been put from css to js (with the update), I can’t see it anymore, and perhaps scripts that should turn this off, don’t function anymore. This isn’t good on both sides and better should be reverted or fixed in another way. I think it would be enough, if anyone just linked to the two threads here on bugzilla. If there ain’t no bug at this time which I just don’t know. --Geitost 23:18, 13 June 2013 (UTC)
Thanks for pointing me to this Geitost. Actually I wondered what was wrong with the bolding on the watchlist today, since bolding was only shown after a noticeable lag. The use of JavaScript explains this unwanted behavior perfectly. I posted a comment to the Gerrit patch mentioned above.
Actually I only created an account for this, since I think we're using by far too much JavaScript already. Instead of even expanding its use, we should strip it out wherever possible. Best example is the new "Thanks" feature that is totally unusable without JavaScript (and seems to even leave some non-working buttons with JavaScript disabled) or the new "Notifications" feature that's also pretty crippled without JavaScript. --Patrick87 (talk) 23:20, 13 June 2013 (UTC)
Yes, that’s why I wrote that also into the petition linked above. See also the Flow discussion. I’m really afraid about the next features that will be put onto the wikis (WP:Flow, WP:VisualEditor). No notifications, no translation extension usable (if there are pages with that new extension, you first have to search for the messages in the namespace Translation: via Special:PrefixIndex instead, that’s quite difficult and takes a lot of time to find the right message to change, you won’t create or change many translations that way, that’s for sure, and: you have to know that, otherwise you won’t edit any translations), no possibility at all to add, change or remove wrong interwikis on Wikidata (cause the pages there are not able to edit directly anymore and interwikis are JS-only on Wikidata). There’s so much now that can’t be done anymore which are really core features and are needed. And it’s getting more and more all the time. I really don’t understand that noone changes this direction back again. It’s the wrong direction to drive away people this way. --Geitost 23:46, 13 June 2013 (UTC)
Perhaps it would be a good idea to put this issue forward at the now-being board elections and other elections. There have to be candidates who care about the users and the communities, as long as the developers and the Foundation don’t care about this (or seem not to do this). --Geitost 00:00, 14 June 2013 (UTC)
I have submitted a change suggestion gerrit:68601, that might be able to address this. —TheDJ (talk • contribs) 00:01, 14 June 2013 (UTC)
Thank you very much! :-) --Geitost 00:03, 14 June 2013 (UTC)
  • Thank you both for working on that problem. The April 2013 editor-activity data has revealed about 10,055 more active editors than expected after the typical 6% decreases in prior years, so even though many veteran editors have gone on break, there are hundreds who have stayed or returned to see these problems. -Wikid77 (talk) 08:25, 14 June 2013 (UTC)

FYI: It is now possible to edit interwiki links in Wikidata without JavaScript. --Lydia Pintscher (WMDE) (talk) 10:05, 14 June 2013 (UTC)

That is most excellent news! I had been giving Wikidata a wide berth after I tried it a while back and found it to be unusable (lots of "edit" links that did nothing when clicked, etc). Your comment prompted me to take another look, and it now works. Thank you! – PartTimeGnome (talk | contribs) 20:51, 14 June 2013 (UTC)
May not be related to this but how do we get the bolding back on the related changes special page for those items that are on our watchlist. Keith D (talk) 17:31, 14 June 2013 (UTC)
If only this totally unwanted feature would go away - I just can't get rid of it. Anyone who wants bold on watchlist, but can't get it, willing to change computers with me, who doesn't want bold on watchlist, but can't get rid of it?
On a serious note, this just re-emphasises my point above, that changes are not tested before they are implemented. Arjayay (talk) 17:46, 14 June 2013 (UTC)
i think you are not 100% fair here. you make the equation "contains bugs === untested". anyone who had even small amount of exposure to software realize immediately that this equation is false, but to emphasize the point, i'll present the same logic in a different form: "tested software === software that contains 0 bugs". practically every person who ever turned on a computer recognizes that the second equation is false.
no "untested" feature go into MW software, and no release to date was 100% free of bugs. putting my prophet cap on, i can see into the future and predict with absolute certainty that the next 50 releases will _all_ be tested, and will _all_ contain bugs.
as to "unwanted features": higher in this very page you complained that "my editing has been severely hampered for months by the toolbars dropping into the edit pane". however, i am somewhat familiar with the bug you referred to, and in know that this problem only occurred when one keep the "advanced" toolbar in the editor open. everything inside this "advanced" toolbar are "features" that at one point or another, someone dubbed as "unwanted". the fact you use these enough to keep the "advanced" toolbar open (and hence encountering the problem you described, which, btw, persisted for little more than a week, not "months") proves that you yourself find at least *some* of those "unwanted features" useful. as to the problem discussed here: this is not a mediawiki problem. it's a problem created when diligent and capable people here at enwiki tried to enhance this feature, in direct response to users' requests. peace - קיפודנחש (aka kipod) (talk) 18:32, 14 June 2013 (UTC)
You state the problem "persisted for little more than a week" - as if it has actually been resolved - which it most certainly hasn't - I am still suffering from it, and my statement of "months" is totally accurate. You claim to be "somewhat familiar with it", so perhaps you could actually resolve it? - Arjayay (talk) 21:22, 14 June 2013 (UTC)
see Bugzilla:27698. i had the honor of reopening this bug report when the problem reincarnated recently, and as far as i knew, the solution really did its job. your report is the first i heard about this issue still persisting. after reading your report, i tried it, and was able to reproduce using "compatibility mode" on IE-10 (i do not usually use IE, and when i do, i do not usually use "compatibility mode"). ttbomk, "compatibility mode" for IE-10 emulates IE-7 behavior. i think this issue should be reported, but may i ask, which browser do you use? peace - קיפודנחש (aka kipod) (talk) 03:57, 15 June 2013 (UTC)
created a new report: Bugzilla:49609. if you use IE 9 or 10, i'll bet that you have "compatibility mode" on, and if you'll turn it off the problem will go away. if you use ie-8, there's still larger than 0 probability that going out of compatibility mode will solve the problem. if you use ie-7 i'm afraid you'll have to wait for the bug to be fixed. peace - קיפודנחש (aka kipod) (talk) 04:32, 15 June 2013 (UTC)
I'm on IE8 (highest I can use in XP) but not in compatibility mode. As I've explained before, there seems to be a common misunderstanding about compatibility mode - it is only backwards compatible - so if I was in it on IE8 I'd end up compatible with earlier versiosn, such as IE7, which you freely admit is not fixed.Arjayay (talk) 17:42, 15 June 2013 (UTC)
first, i apologize for being a bit snappy above. this issue (actually, not exactly this issue, but similar enough that the terse description applied to it) appeared for all browsers a while ago, and was fixed fairly quickly, and hence my comment. i was not aware that it persisted for IE until i read your report. i verified it myself, and opened a new bug report, which was later marked "duplicate" of Bugzilla:4756. as to "compatibility mode": i do not have access to IE-8, and it is close to impossible to switch IE version (except upgrading - but then downgrading back is often no longer an option...). so i only succeded reproducing it with "compatibility mode" for IE-10. as it happens, "compatibility mode" on ie-9 and ie-10 emulates almost (but not quite) exactly IE-7 behavior. i do not know of a good way to test webpage behavior with IE-8 except finding a box with genuine IE-8, which is not a viable option for most developers. regarding insufficient testing with IE and specifically IE in compatibility mode: this is a known deficiency of MW development process, and several people, including myselfth have alerted about it in the past. i am sure MW will be thrilled to have volunteer testers who use genuine IE of any version, and specifically IE-8. peace - קיפודנחש (aka kipod) (talk) 00:30, 17 June 2013 (UTC)
  • Is there any way of de-selecting the bolding on the watchlist? It becomes kind of a watchlist on the watchlist, and I find it disruptive to some degree (sorry to the developers). HandsomeFella (talk) 21:25, 14 June 2013 (UTC)
Thanks, but it doesn't work. I have checked both boxes, the one for the green bullets and reset button, and the one for bold. Should I try manually disabling? HandsomeFella (talk) 10:33, 16 June 2013 (UTC)

VisualEditor disabled

Hey all

As some of you may have noticed, there's a pretty serious issue with the VisualEditor at the moment; it's been tentatively traced to a deployment earlier this morning. We've made fixing it of the highest priority, and in the meantime are about to turn off the VE to prevent people accidentally munging articles. It goes without saying that we're very sorry about this issue, and the disruption it has caused; hopefully it won't be repeated! Okeyes (WMF) (talk) 14:49, 14 June 2013 (UTC)

That's alright Oliver, just beat yourself with a bat and we'll call it even.--v/r - TP 15:02, 14 June 2013 (UTC)
I must have been on another planet, noticed nothing ! ·addshore· talk to me! 15:03, 14 June 2013 (UTC)
TParis; that sounds reasonable, but I'm not sure if my concussion influences my judgment, there ;p. Okeyes (WMF) (talk) 16:37, 14 June 2013 (UTC)
We've already decided to turn off VE for a bit, do we really need your judgement for the next couple hours? ;) <ducks> Jalexander--WMF 17:44, 14 June 2013 (UTC)
gerrit:68667 was merged. Helder 16:39, 14 June 2013 (UTC)
The VE should now be live again :). Okeyes (WMF) (talk) 18:31, 14 June 2013 (UTC)
I activated it on my account just to see it out of curiosity, but I don't see any change. Where's the VisualEditor?—cyberpower ChatOnline 23:58, 14 June 2013 (UTC)
See Wikipedia:VisualEditor#How to enable the VisualEditor. Note you only get the VisualEditor option in some namespaces. PrimeHunter (talk) 00:12, 15 June 2013 (UTC)
Yikes that thing is horrible. It also doesn't seem to want to work right. I can't edit anything with it. All it does is cover the field with green diagonal stripes.—cyberpower ChatOnline 00:22, 15 June 2013 (UTC)
Your using it wrong ;p ·addshore· talk to me! 00:31, 15 June 2013 (UTC)
Template editing is coming next week, or soon thereafter, according to the progress report above, #VisualEditor weekly update - 2013-06-13 (MW 1.22wmf7). –Quiddity (talk) 02:26, 15 June 2013 (UTC)
Yeah I tried it a couple of times in the last week or two about a week ago and only a mother could love it was my feeling about it. Anyway I'll try it out again when it has something about editing template calls. Dmcq (talk) 08:26, 16 June 2013 (UTC)

red Cite Error message precision

The mostly-red message (example) "Cite error: There are <ref> tags on this page, but the references will not show without a {{Reflist|group=lower-alpha}} template or a <references group="lower-alpha"/> tag (see the help page)." is not quite correct on those occasions when we use {{Efn}} templates and not ref elements and a {{Notelist}} template and not a {{Reflist}} template or a <references> element. Parallel situations probably include upper-alpha ({{Efn-ua}}) and romanettes ({{Efn-lr}}). The message does give useful advice but it can easily be misunderstood in these cases, such as by leading editors to add {{Reflist}} templates when they should instead add {{Notelist}} templates. Perhaps the red message should be rephrased (perhaps conditioned on which templates are in use for that page) or, if too many possibilities exist, linked to a page listing the possibilities so editors can pick one relevant to their case. Nick Levinson (talk) 18:08, 15 June 2013 (UTC) (This was posted a few minutes ago without interpreting the sig tildes; now correcting a nowiki tag that truncated the display: 18:08, 15 June 2013 (UTC))

I will update this soon. Unfortunately, there is no way to detect which template triggered the error. --  Gadget850 talk 18:58, 15 June 2013 (UTC)
{{notelist}} is merely a shorthand for {{reflist|group=lower-alpha}}. --Redrose64 (talk) 19:15, 15 June 2013 (UTC)
I guess possibly the code could detect whether an Efn or related template is currently present, if that would help. I'm not a programming expert, so I don't know, and detecting is probably not critical. Thanks. Nick Levinson (talk) 21:03, 15 June 2013 (UTC)
Possibly, but the code is in Cite and only a developer can change it. --  Gadget850 talk 21:38, 15 June 2013 (UTC)
I've added a #ifeq in MediaWiki:Cite error group refs without references to check if $1=lower-alpha -- WOSlinker (talk) 22:15, 15 June 2013 (UTC)
I rolled this back for the moment. There is still a lot of usage of {{reflist|group-lower-alpha}}, and there are also variations of {{notelist}}. We also need to test this carefully as MediaWiki namespace can be tricky. Headed out to the drive in, will look at this later. --  Gadget850 talk 22:41, 15 June 2013 (UTC)
Updated the message to show the group name in the <ref> tag. Added a switch to show the {{efn}} and {{notelist}} templates. Updated the help page to show the three sets of templates. --  Gadget850 talk 13:36, 16 June 2013 (UTC)

Category not displaying

In S. Charles Lee, Category:NRHP architects was added here. However, it isn't displaying in the article for me. But, he does appear in the category here. Can anyone tell what is happening? Chris857 (talk) 03:22, 16 June 2013 (UTC)

@Chris857: - Category:NRHP architects was a hidden category, which do not display unless you change your preferences. I unhid the category in this edit to resolve the issue. GoingBatty (talk) 04:51, 16 June 2013 (UTC)
I've re-hidden that category. It was hidden as the result of this WP:CFD discussion. Read that discussion to understand the reasons why it is hidden. --Orlady (talk) 16:15, 16 June 2013 (UTC)
@Orlady: - Note that the template on Category:NRHP architects states that this category "contains pages that are not articles", which clearly is not the case. You may want to add some additional text in the category to summarize the discussion so people who were not involved in the discussion (such as Chris857) will understand. Thanks! GoingBatty (talk) 18:08, 16 June 2013 (UTC)
I'm not going to change that template or edit the category. Please note that the category is maintained primarily by User:Doncram (not me); if there's a desire to edit it, discuss it with him. As for the template, that's a standard template that is added automatically to hidden categories. One sentence in the template does say that the category "contains pages that are not articles, or it groups articles by status rather than content". Neither one of those statements is exactly true for that category (because it does contain articles grouped on the basis of content). However, the main point is the one that's made in the previous sentence: the category is used for administration of the Wikipedia project and is not part of the encyclopedia. It takes some patience to read through the CFD discussion, but a person who takes the time to read it will find some reasons why this category isn't considered appropriate for inclusion in the encyclopedia. --Orlady (talk) 20:38, 16 June 2013 (UTC)

Problems with a special character

I would like to know more about this character: "�". If I search for it, Wikipedia will return the following message: 

 An error has occurred while searching: The search backend returned an error:

If I try [[�]] or http://wiki.riteme.site/wiki/%EF%BF%BD - it will say "Bad Title".

How can a Wikipedia reader find information about such a character on a Wikipedia article? Thanks. —  Ark25  (talk) 06:17, 12 June 2013 (UTC)

That is the Unicode 'REPLACEMENT CHARACTER' (U+FFFD). See Specials_(Unicode_block)#Replacement_character. --Splarka (rant) 07:29, 12 June 2013 (UTC)
Thank you! I added the character to the list at Wikipedia:Page name#Invalid page names - the reader will be pointed to the list after getting a "Bad Title" error. —  Ark25  (talk) 08:19, 12 June 2013 (UTC)
I fixed the description as only � is invalid in page titles. The other specials are valid, and in fact the respective one-character-titled articles all exist (as redirects): FFF9, FFFA, FFFB, [[ |FFFC]]. However, something is wrong with search: for example, [15] gives the error message you mention above, while [16] works. In fact, searching for � also works if there is more text in the search box [17]. This sounds very much like a bug to me.—Emil J. 18:29, 12 June 2013 (UTC)
I get the same message searching for a pipe character: thus. LeadSongDog come howl! 19:02, 12 June 2013 (UTC)
Apparently the bug is already tracked at bugzilla:47761.—Emil J. 11:00, 13 June 2013 (UTC)

In this case, I think the search engine should a similar message to the one at [http://wiki.riteme.site/� Bad title] when you get a search error. The red error message should be shown alone only when there is an unknown error. —  Ark25  (talk) 00:26, 13 June 2013 (UTC)

There likely is an unknown error. Why would the search engine ever complain about a bad title? It is supposed to search through articles that exist, not those that don’t.—Emil J. 10:36, 13 June 2013 (UTC)
In order to help the users. It can be done by a simple change to the interface of the search engine. Most users have no idea that the search didn't work because of using an illegal character. So it's good to get a similar message to the one at "Bad title". —  Ark25  (talk) 15:10, 14 June 2013 (UTC)
I think you still do not get it. The reason the search engine didn’t work is not related in any way to any illegal characters, this was just a coincidence. It breaks in the same way for quite ordinary characters (or short strings), such as $. As mentioned in bugzilla:47761, it also breaks for lone namespace prefixes, such as Talk:.—Emil J. 16:30, 14 June 2013 (UTC)

I didn't realize there is a bug in the search engine. Sorry for dumb question: the search engine should never return that error? —  Ark25  (talk) 05:52, 17 June 2013 (UTC)

I can’t speak for the devs, but I’d say that since the error message is totally unhelpful, it should never be returned in this form. (I guess the text of the message is just a template used for all search error messages, where the colons are supposed to be followed by a specific error description, but in this case the offending code where the error happened did not supply any specific message due to some anomaly.)—Emil J. 14:52, 17 June 2013 (UTC)

Template:AFC statistics

Thanks to whoever got the Template:AFC statistics page working again. It's so much nicer reviewing pages from there with the additional information provided. —Anne Delong (talk) 23:16, 12 June 2013 (UTC)

I think The Earwig and their bot updates the page, so they deserve the praise. Bgwhite (talk) 07:25, 13 June 2013 (UTC)
It was an AFC group effort. Earwig updated the bot, I lightened the template some, and someone (I don't remember who) replaced part of the template with a Lua component to make it lighter and cleaner. Technical 13 (talk) 11:41, 13 June 2013 (UTC)
The last one is Martijn Hoekstra. — Earwig talk 14:55, 13 June 2013 (UTC)
Well,great. I was using the "Afc submissions sorted by date", but the Template version has some extra information that helps me pick out articles to review. —Anne Delong (talk) 13:00, 17 June 2013 (UTC)
Where as I'm still a fairly new reviewer without a lot of time on my hands, I like to sort them by size and knock off 25-50 small ones at a time. Technical 13 (talk) 13:48, 17 June 2013 (UTC)

Bolding on watchlist despite preference set for no bolding

I noticed that pages I haven't visited since they were last updated just started appearing in bold on my watchlist. I have the preference set under gadgets to not have the bolding, but the bolding is showing up despite the preference. I tried turning the bolding on in the preferences and then back off, but that did not fix the problem. Is there some sort of bug with the bolding/no bolding option? Just before the bolding started showing up, I visited Special:Newpages . . . could that have somehow affected my watchlist? Calathan (talk) 18:18, 13 June 2013 (UTC)

this setting works for me as advertised. try to do a deep-refresh (assuming ff, chrome or ie on windows, press Ctrl+⇧ Shift+Delete, and select whatever your browser use for "drop/forget/delete cache/temporary files". if you use a different browser or os, look in the browser's menu how to completely purge the cache), and see if this solves the problem.
also, if you use a skin other than vector, try it with vector. if you find that the problem is skin or browser related, please report your findings. peace - קיפודנחש (aka kipod) (talk) 18:27, 13 June 2013 (UTC)
Oh, what a headache. Literally...the bold is horrendous. 1. I have checked my preferences under gadgets and indeed have bolding for watchlist unselected. 2. I just performed the "detete temporary internet files" routine (thanks for the neat keypress info...) 3. I temporarily changed my skin from Modern to Vector. None of this mattered one iota. I still have pages bolded. The only way I can keep from getting a migraine is to click "mark all pages visited" each time I check my watchlist; which only works for a moment because I have nearly a thousand pages I watch, some of which are quite active (like this one). This is new, unexpected and unliked. Fylbecatulous talk 18:45, 13 June 2013 (UTC)
I have purged the cache, I'm not on compatibility mode, and the option isn't selected in my preferences. GiantSnowman 18:51, 13 June 2013 (UTC)
I've also tried the suggestions קיפודנחש gave, and they did not fix the problem. I'm using MonoBook, but the bolding was still present when I switched to Vector. I also deleted the cache/temporary Internet files, but that didn't solve the problem. The bolding is still present. Calathan (talk) 18:54, 13 June 2013 (UTC)
It's not working for me either. Roger (Dodger67) (talk) 18:58, 13 June 2013 (UTC)
the problem seems to be real, but it only materialize with IE - for ff and chrome this preference seem to work as advertised. this is the probable cause - i venture a guess that the person who created this gadget use some browser other than IE. i left him a message asking him to take a look at this topic. peace - קיפודנחש (aka kipod) (talk) 19:27, 13 June 2013 (UTC)
It worked perfectly on IE for about a year, why would it suddently change? Roger (Dodger67) (talk) 19:38, 13 June 2013 (UTC)
If it is an IE issue, try toggling "compatibility" mode... Technical 13 (talk) 19:44, 13 June 2013 (UTC)
As I've already said, that doesn't work. GiantSnowman 19:48, 13 June 2013 (UTC)
I have IE10. I see nothing that applies to me on the "Compatability mode" choices...therefore, I too am not in compatability mode and don't intent to tinker, actually. I agree: what has happened? I've been upgraded to IE 10 as long as it has been available. Fylbecatulous talk 20:00, 13 June 2013 (UTC)
This is probably an issue now when it wasn't for the last year because of the recent introduction of green bullets on the watchlist. I believe these use some of the same classes as watchlist bolding; the bolding gadget was probably changed to accommodate this. – PartTimeGnome (talk | contribs) 22:08, 13 June 2013 (UTC)
I think I fixed it. As usual, IE is retarded enough to miss the the finer points of CSS; it does not seem to understand what 'inherit' means. — Edokter (talk) — 20:04, 13 June 2013 (UTC)
I've logged out, re-purged and opened a new browser - still big'n'bold. GiantSnowman 20:08, 13 June 2013 (UTC)
Seems like another, unfortunately increasingly typical, change to the system that has not been properly tested. Why does Wikipedia allow any editor to install any changes without a full test on all browsers? I have complained several times before about such changes and received very arrogant responses along the lines of "it's your fault for using IE" or as described above "IE is retarded"
NO - like it, or hate it, IE is the most used browser in the world, if any change has not been fully tested in all standard browsers it should not be allowed to be implemented. I've made this point before, and it was described as "unrealistic", although no reason or justification was made for this claim. As it is, my editing has been severely hampered for months by the toolbars dropping into the edit pane, due to another so-called "improvement" that caused more damage than good.
Wikipedia has been wondering why experienced editors leave - whilst ignoring repeated requests not to "fix" things that are not bust. We need a simple, basic interface which editors can add to by selecting options in My Preferences, not an increasingly complex interface that requires editors to install complex lines of code to disable them, if they can find this code hidden on some obscure page. Arjayay (talk) 20:31, 13 June 2013 (UTC)
Wikitech-l: Features vs. Internet Explorers. Helder 21:11, 13 June 2013 (UTC)
Since gerrit:65414-change, the CSS for the watchlist is loaded trough javascript. If the user is encountering an error in one of his (other) scripts, then this script may not be able to load and not be able to add the CSS, which would explain the problem that this user is experiencing. See also the report below —TheDJ (talk • contribs) 23:02, 13 June 2013 (UTC)

This is what I have on my common.css - 

strong.mw-watched { font-weight: normal !important; }
span.updatedmarker{display:none;}
#mw-watchlist-resetbutton{display:none}
span.mw-editsection { float:right; }

I also have bolding unselected and green bullets selected on my Preferences > Gadgets menu.

What I get on my Watchlist is green bullets and bolding. I prefer the clearly noticable but not screamingly offensive little green dots without bolding. I'm using IE9 on Win7 - I threw out IE10 because it comprehensively stuffed up the layouts here and on other sites. The bolding happens right at the end of the page loading, almost as an "afterthought", I'm not sure if that is significant. Roger (Dodger67) (talk) 08:59, 14 June 2013 (UTC)

I have to keep the green bullets "selected" (which is ok; they are not too vivid). If I did away with them, then my reset button would be hidden and I woudl have no way to mark all pages visited to allow me a moment with no bold. I am keeping IE10 because I figured out some tweaks that made it work better for me (such as the dastardly "auto-spelll correct" which wrinkly underlined everything here that was in code because it wasn't spaced (such as defaultsort:woodbridge). To me, the bolding is "screamingly offensive". I do not intend to downgrade my browser just for the quirks of Wikipedia. And yes, the bold still lives this morning, btw. Fylbecatulous talk 11:36, 14 June 2013 (UTC)
OK, just to get this clear, this might take at least a week to get this properly fixed. —TheDJ (talk • contribs) 11:40, 14 June 2013 (UTC)
Z'okay. ツ Fylbecatulous talk 12:24, 14 June 2013 (UTC)
  • Its not a javascript error issue for me. I examined the Firefox 19.0.2 error console and there are zero errors but a lot of warnings. For me I used the enhanced RC feed and the timestamps are still bold for me. Werieth (talk) 12:19, 14 June 2013 (UTC)
OK, I downloaded an IE10 virtual machine from http://modern.ie and it seems that IE has a different load order of the styles or something, causing it to follow different specificity rules. I made our overrulling stronger and that seems to have fixed it. —TheDJ (talk • contribs) 15:23, 15 June 2013 (UTC)

This appears to have fixed itself for me i.e. I have done nothing to my computer but it is sorted. GiantSnowman 19:20, 15 June 2013 (UTC)

Did it start behaving soon after 15:14 (UTC) today? --Redrose64 (talk) 19:28, 15 June 2013 (UTC)
No, I think it was working fine this morning. GiantSnowman 19:31, 15 June 2013 (UTC)
For anyone who may care, according to Wikipedia's own Browser statistics, IE is no longer the most used browser. —Anne Delong (talk) 13:18, 17 June 2013 (UTC)

How to include Wikipedia:Book_sources into Special:BookSources?

Because suddenly zh:Special:BookSources can't include zh:template:网络书源,I want to know why the Special:BookSources of other language does nothing happened?Does it need to modify which page?and how to change the default item of the Special:BookSources listing?--Cwek (talk) 11:32, 16 June 2013 (UTC)

The page displayed by zh:Special:BookSources is named by zh:MediaWiki:Booksources. The named page is in the Wikipedia namespace. This is currently set at the Chinese default, "图书来源", so the Special:BookSources page should show zh:Wikipedia:图书来源. However, this was deleted by zh:User:Liangent on 14 June 2013... – PartTimeGnome (talk | contribs) 23:59, 16 June 2013 (UTC)
Do you means that the Special:BookSources will include the Wikipedia:XXXX page which the XXXX defines in MediaWiki:Booksources?Because somesone modify the translation of MediaWiki:Booksources on translatewiki which he changes ″网络书源″ to "图书来源",the mapping lost.But now it seems that it had rolled back and wait for the weekly update.--Cwek (talk) 00:57, 17 June 2013 (UTC)
Yes, that's right. If you don't want to wait for the weekly update, an admin can edit zh:MediaWiki:Booksources to set it back to "网络书源". After the update, an admin can "delete" the page to reset it to its default (which should be the same if the update fixed it). – PartTimeGnome (talk | contribs) 19:44, 17 June 2013 (UTC)

Is it possible to add, site-wide, extra space before the first nav template?

This issue came up at MOS talk. It would probably be best if you answered in that venue, in order to keep the discussion all in one place. 86.121.18.17 (talk) 11:35, 17 June 2013 (UTC)

Redirects in template query

Clicking on 1996 in the following Template:Notre Dame Fighting Irish football navbox initially goes to the correct location within the target article, but then throws you to the bottom; the redirect in 1996 Notre Dame Fighting Irish football team looks OK, any ideas...GrahamHardy (talk) 15:06, 17 June 2013 (UTC)

@GrahamHardy: This is because the 1996 link actually links to a specific section of Notre Dame Fighting Irish football (1990–99); your browser automatically scrolls to that section, see WP:ANCHOR for more details. Cheers, Theopolisme (talk) 15:44, 17 June 2013 (UTC)

@GrahamHardy:, I suggest being patient. Theopolisme, I think I know what Graham is talking about. All of the pages do that to me too where they load the page, go to the right section, go to the bottom, and then bounce back up to the section. It has to do with how the page loads and if it doesn't bounce back up to the section for you, clicking on the URL bar and hitting enter will usually bring you back there. I'm pretty sure that is a browser bug and there is nothing that the Wikipedia (MediaWiki) people can do to fix it. Technical 13 (talk) 16:13, 17 June 2013 (UTC)

Oh, okay, thanks for clarifying. Yeah, not present in Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_4) AppleWebKit/536.30.1 (KHTML, like Gecko) Version/6.0.5 Safari/536.30.1. Theopolisme (talk) 16:57, 17 June 2013 (UTC)
It's due to collapsible sections of infoboxes - there are eight of these before the 1996 heading: three in 1990, one in 1993, three in 1993 and one in 1995. When the page loads, these are initially uncollapsed, but after the page has completed loading, they collapse. If your browser has jumped to the 1996 heading before the boxes collapse, the page content will effectively be pulled upwards, which explains the behaviour you describe. But if your browser jumps to the heading after all the collapsing has occurred, it'll hit the right spot and stay there. --Redrose64 (talk) 18:47, 17 June 2013 (UTC)
I'm sure that may be a contributing factor in some cases Redrose64, but it is doing it on VPT right now for me and there are no collapsed sections on this page currently. I'm using Firefox 21 if it is of any consequence. Technical 13 (talk) 18:55, 17 June 2013 (UTC)

"You cannot overwrite this file"

File:I-might-be-a-cunt-but-im-not-a-fucking-cunt-video-screenshot.jpg
Cannot overwrite this file.... but why? It's not used on anything sensitive and there's nothing in the history or page information noting protection. – JBarta (talk) 21:25, 17 June 2013 (UTC)

My bot got this too when it tried to automatically reduce the file. Take a look at the MediaWiki talk:Titleblacklist...it's being blocked by the regex .*fucking.cunt.*. You'll need to find an admin to upload it for you. Theopolisme (talk) 21:30, 17 June 2013 (UTC)
Ahh. Thanks. – JBarta (talk) 21:47, 17 June 2013 (UTC)

Image deletion

Are some images permanently deleted? Image:WW1-TitlePic-For-Wikipedia.jpg shows no file history and no previous image versions, but it was a working image that was used in the WWI article in early 2006 (at this point, for instance; though it doesn't show up in the infobox, even as a redlink, you can see it if you edit that page version). Why can't I see it in the deleted history? Kafziel Complaint Department: Please take a number 22:49, 17 June 2013 (UTC)

If you look at the diff a few edits later, the file name was vandalized from File:WW1 TitlePicture For Wikipedia Article.jpg, which still exists. So, no image was ever uploaded at that tile, thus no history. Chris857 (talk) 22:53, 17 June 2013 (UTC)
No, there was a file there. It was sneaky vandalism in which a similar file name was used for an image that showed WWI biplanes with swastikas on them, and Bruce Willis from 12 Monkeys inserted into the photo with the Vickers crew. It's mentioned in the talk page history. And I actually saw it at the time. Kafziel Complaint Department: Please take a number 22:57, 17 June 2013 (UTC)
It was on Commons; go to the file there and you'll see the deletion log. Nyttend (talk) 23:18, 17 June 2013 (UTC)
In reference to the original question, some files are permanently deleted: prior to 2006 or so, when an image was deleted, the image data was removed from the server. As a result, very old image deletions can't be undone. --Carnildo (talk) 01:03, 18 June 2013 (UTC)
Indeed; see the relevant Signpost story. Graham87 01:47, 18 June 2013 (UTC)

Thanks, everyone! Kafziel Complaint Department: Please take a number 05:09, 18 June 2013 (UTC)

User e-mail sending speed limit

Tracked in Phabricator
Task T51444

Is there a technical limit on how many e-mails you can send in one peridod (e. g., 1 hour)? --Синкретик (talk) 06:19, 11 June 2013 (UTC)

Yes, 20 per day. MER-C 07:44, 11 June 2013 (UTC)
http://wiki.riteme.site/w/api.php?action=query&meta=userinfo&uiprop=ratelimits MER-C 08:26, 11 June 2013 (UTC)
Thanks. Doesn that mean 20 letters regardless of the receiver? I'm asking because we at Russian Wikipedia had a case of massive e-mail WP:Canvassing at user Pessimist2006's RFA & he failed. --Синкретик (talk) 08:33, 11 June 2013 (UTC)
That link is for the English Wikipedia. As far as I can tell, the throttle limit is set on a per-site basis; http://ru.wikipedia.org/w/api.php?action=query&meta=userinfo&uiprop=ratelimits shows entirely different limits for the Russian Wikipedia. Perhaps this means that global accounts can be spammed by visiting the various Wikimedia projects in turn, sending as many e-mails as possible before reaching the limit, before moving on to the next one. —Psychonaut (talk) 08:41, 11 June 2013 (UTC)

Wow you guys... Tangent much... Let's try to get this back on topic... Has anyone submitted a ticket to bugzilla yet to get a global email limit set once SUL project is done? Jorm (WMF), sorry to bother you, but I'm curious who is lead on the SUL project if you happen to know or can find out. Thanks. Technical 13 (talk) 16:37, 11 June 2013 (UTC)

Deferred revisions: a specific implementation proposal

I have proposed a specific implementation proposal for Wikipedia:Deferred revisions, which does not require massive software changes. I'd like some comments on the technical side (feasibility, stability, etc) before moving to WP:VPR. Cenarium (talk) 19:43, 16 June 2013 (UTC)

It's a clever idea. From a technical perspective, it may require some non-trivial additions to the AbuseFilter extension, and possibly some to FlaggedRevs as well. I agree that it is proposed "in a way that minimizes the amount of technical changes required", but the minimal amount of changes required may not be as small as you think. — This, that and the other (talk) 12:01, 17 June 2013 (UTC)
Personally, I'd file a bugzilla report to see if the software side of things was feasible before going to VPR. I like the idea, though. — Mr. Stradivarius ♪ talk ♪ 12:04, 18 June 2013 (UTC)
I suspect that removing the PC protection after a revision gets accepted may prove challenging technically. Devs may get more motivation if they see an idea has gained support, but since it's likely to be approved and is of general interest (not just for en.wp), I'll file it now and see. Cenarium (talk) 19:23, 18 June 2013 (UTC)
This is T51770. Cenarium (talk) 20:58, 18 June 2013 (UTC)

VisualEditor - A/B test launch on 18 June

Hey all.

As previously announced (via a watchlist notice and static announcements), we'll be enabling the VisualEditor for a percentage of newly-created accounts, starting Tuesday the 18th. Our main goal here is to find out what difference it makes to the number of users who start editing, and who complete an edit, so we can find out what strains a full deployment might put on community workflows - even if it works perfectly as software, we need to know if turning it on will break the teahouse :). Obviously there are some bugs at the moment, a few of them very serious, but I've been assured the big ones will be fixed before the software launches for this test - including things like template and reference editing. If we aren't comfortable with the state of it, we won't hit the on button. If things look fine, we turn it on, and something breaks dramatically, tell us - we retain the ability to just switch the VE off if it starts mangling things, and will be monitoring closely :). Thanks, Okeyes (WMF) (talk) 18:14, 17 June 2013 (UTC)

i thought that according to Declaration of Helsinki, there should be some committee you need to consult before running experiments on humans, no? . peace - קיפודנחש (aka kipod) (talk) 19:59, 17 June 2013 (UTC)
It's not a legally binding instrument, the lead says so! But we'll do our best to make it as non-painful as possible :P. Okeyes (WMF) (talk) 22:26, 17 June 2013 (UTC)
  • VisualEditor got edit-conflict on slighest change and lost all text: The slightest edit-conflict is completely fatal, losing all changes so the page source shows only one word: "undefined". I tried several times to see how the VisualEditor would react to interim changes by another username, and the results were a total disaster, where the slightest changes triggered edit-conflict against the interim revision (but the wikitext editor did auto-correct and merge changes into the interim revision). Plus, when I clicked "manual fix for edit conflict" then the VisualEditor showed the text of the edited page as one word: "undefined" and I was not even able to copy/paste any of the attempted changes for saving elsewhere. I think that amounts to "cruelty to humans" to crater on the slightest change, and then pretend there is a "manual" method for the user to salvage the VisualEditor session, which instead contains the one word "undefined" as the entire result of their keystrokes. I would delay experiments on unaware human subjects (new users) for another month, at least. Instead, give them a welcome message to ask them to "volunteer" to try the WYSIWYG VisualEditor, but not force the Edit-button to send them through the "cattle chute" for subsequent processing. -Wikid77 02:09, 18 June 2013 (UTC)
Tracked in Phabricator
Task T51737
I think this might relate to bugzilla:49737 —TheDJ (talk • contribs) 09:22, 18 June 2013 (UTC)
  • If you're taking bug reports here, I've only made two edits with VisualEditor recently, both yesterday, both disasters: this and this. The random garbling of text (insertion of "ad a private-pilot license and" and "[[File:Audie-Murphy-Monument.jpg|right|thumb|200px|Monument at the site of the plane crash in which Audie Murphy d"), the random insertions and removals of spaces throughout the article, and the random deletion of a hidden comment from an infobox ("<!-- LEAVE THIS ALONE! See Talk page discussion.-->") were all VE. (It's possible someone thought that "fixing" HTML markup by adding or removing a lot of spaces throughout was a feature and not a bug, but they were misinformed ... it takes a lot of time to search through a long diff to check to make sure no additional significant errors were introduced.) I was editing just one section at a time, and the errors introduced were in sections I wasn't editing. - Dank (push to talk) 12:24, 18 June 2013 (UTC)
  • There are plenty of bug reports at WP:VE/F, and these include some that are similar (if not identical) to those of Wikid77 and Dank. Please can we avoid filling up VPT with what are likely to be duplicate threads? --Redrose64 (talk) 14:38, 18 June 2013 (UTC)
    • Yes, thanks. Please give your feedback at Wikipedia:VisualEditor/Feedback. That page is being very closely monitored. :) --Maggie Dennis (WMF) (talk) 14:43, 18 June 2013 (UTC)
      • I gave my feedback at the Visual editor page and I'll summarize here what I said there. I have serious concerns wiht the roll out of VE. The app isn't ready yet so we should not be forcing it to 50% of our new users. They don't know our processes, won't know how to report problems and since many of the problems are subtle, they may not even know its a problem. I'm not going to dwell on it here I just wanted to leave a general note. Kumioko (talk) 19:03, 18 June 2013 (UTC)
  • Hey all. We're going to postpone the A/B test for several days; I'll post more details as I get them, but I understand it's largely down to known bugs with the existing software - bugs that you reported, and bugs that were crucial in making a go/no go decision. Thank you to everyone for all your hard work poking at the VE, and for all your reports thus far; it's much appreciated :). Okeyes (WMF) (talk) 19:25, 18 June 2013 (UTC)

"Ride or Die (Film)" cannot get linked to according articles in the French or German Wiki

FYI: There is a French (RAP Connection) and a German (Ride or Die – Fahr zur Hölle, Baby!) article about Ride or Die. Whenever I try somehow to link them all together, I get the error message this was impossible because the French and the German article were already connected. Please look into this matter. NordhornerII (talk) —Preceding undated comment added 23:19, 17 June 2013 (UTC)

I guess you don't know how interlanguage links work with Wikidata and tried to do something in a wrong way. The French and German articles were indeed already connected and now the English also is.[18] I see Deutsch and Français at Ride or Die (film)#p-lang, and the foreign articles have links to English. PrimeHunter (talk) 00:07, 18 June 2013 (UTC)
Hello, actually I have just rather recently worked with interlanguage links. In case of doubt please check these articles: Camille Claudel 1915 and Body of War. In "Old Europe" we are used to switch between languages. The original error message was (that) I weren't logged in for using Wikidata. I logged in three times (or "thrice" LOL) but the error message kept coming. So I tried to link the articles within Wikidata and that misfired bringing up the aforementioned error message. I deleted my cookies (because I had logged in to the Wikipedia from the film artcle "Ride or Die") and restarted the browser but still no joy. Before this I had no trouble but I noticed that sometimes the interlanguage links only get active after the article in question has been edited again. (I presume this tells you more than me.) However, thank you for your attention. NordhornerII (talk) _The man from Nordhorn 08:35, 18 June 2013 (UTC)

Account Creation Issues

Resolved
Tracked in Phabricator
Task T51727

For everyone's information.—cyberpower ChatOnline 02:57, 18 June 2013 (UTC)

We're on it. Thanks for the swift bug report. Steven Walling (WMF) • talk 02:58, 18 June 2013 (UTC)

Feature brainstorm for Module:WikiProjectBanner

I'm in the early stages of developing a Lua-based replacement for {{WPBannerMeta}}, and I would appreciate peoples ideas for features. If there is anything that you have wanted to do with your WikiProject template, but haven't been able to due to limitations in the meta-template, I would be very interested to hear it. The discussion is over at Template talk:WPBannerMeta. — Mr. Stradivarius ♪ talk ♪ 12:22, 18 June 2013 (UTC)

Gadget-BugStatusUpdate and restricted bugs

Would it be possible to modify MediaWiki:Gadget-BugStatusUpdate.js to display a special label for security-restricted bug reports, such as the one mentioned here? --SoledadKabocha (talk) 17:27, 18 June 2013 (UTC)

Of course it is possible... I'll look into this. I would like to modify the gadget and css and template a little to try and return "Secure Bug" or something if the api can't pull the status for the user and changed the background color of the template to a pastel red color or something to make it clear that the user can't access the bug. I'll play with it in the sandbox in a bit. Technical 13 (talk) 17:47, 18 June 2013 (UTC)
Update: SoledadKabocha, you may want to check out MediaWiki talk:Gadget-BugStatusUpdate.js#Stepping up to the plate... where I've created a list of things that "aren't quite right" with the current {{Tracked}} system. Technical 13 (talk) 19:39, 18 June 2013 (UTC)

Article deleted in 2010 appears in search

{{Tracked|49741}} T51741 If I search for "And was digitally released on June" including the quotation marks, a result for Who's My Bitch (Paradiso Girls song) is returned. But this string has never existed on that page. What's going on? Is this a bug? Thanks! SomeFreakOnTheInternet (talk) 21:55, 17 June 2013 (UTC)

The search page for "And was digitally released on June" says "3 July 2010" for the hit on Who's My Bitch (Paradiso Girls song). Today it's a redirect but on that date it did indeed contain the quoted string. The article was deleted 5 July 2010 [19] so the real question is why results from a page deleted 3 years ago is appearing in searches. I suspect it has something to do with the only edit after the deletion being the creation of a redirect (24 May 2012). PrimeHunter (talk) 22:21, 17 June 2013 (UTC)
I copied the above from Wikipedia:Help desk#Search result returned for something that doesn't exist. The full text currently displayed on the search page: ""Who's My Bitch" was leaked online June 8, 2010, and was digitally released on June 22, 2010. It was featured on MTV's The City . ..." Admin-only link to the deleted revision displayed in the search. It seems harmless in this case but deleted pages can contain nasty stuff and should only be visible to admins for legal reasons.[20] Is this a one-off or a serious bug? PrimeHunter (talk) 23:07, 17 June 2013 (UTC)
Reported this in bugzilla —TheDJ (talk • contribs) 09:15, 18 June 2013 (UTC)
Thanks!! SomeFreakOnTheInternet (talk) 23:36, 19 June 2013 (UTC)

Recover account?

Hi. Is there any way to recover a lost password ~ while one is actually logged into the account? I realise that once not logged in there isn't but, because of a probably unreproducible computer...thing, i am logged into my alternate account, the password of which was glitched out of existence after one edit. Is there any way to change my password or get a new one e-mailed, now that i am in it? I'm sure it's obvious, i'm not a completely new user; the one edit i made was to redirect the user page to mine own main account's page; sure would like to use this account though, as it's named after one of my favourite characters in fiction. Thanks for any help...Kahtar (talk) 08:48, 19 June 2013 (UTC)

If you have forgotten your password but are still logged in, go to Preferences and follow the link "Password: Change password" near the bottom of the first box. Also at Preferences, ensure that an email address has been set (it's in the last box). If you do the second of these, you can get a new password even if you log out, see Help:Reset password. --Redrose64 (talk) 09:06, 19 June 2013 (UTC)
Thanks, Redrose. Unfortunately, both those options require me to know my password before i can change it. I suspect i'm out of luck. Kahtar (talk) 09:42, 19 June 2013 (UTC)
You should still be able to set an email address, and follow the instruction at Help:Reset password#Forgotten password. --Redrose64 (talk) 09:49, 19 June 2013 (UTC)
Curiously, no. Special:ChangeEmail requires a password and, although i enter the one i logged in with a few hours ago, the software tells me "Incorrect password entered." Same thing, of course, on Special:PasswordReset ~ the password that got me here isn't acceptable to change the password. Doesn't make sense to me (like lots of computer things) nor, perhaps, to you; unreproducible i called it above, probably it is, and unrecoverable, too. Kahtar (talk) 11:13, 19 June 2013 (UTC)
Maybe you misremembered a detail in the password. Try variations, for example in capitalization. You can maybe get the username (but not any of its saved settings) from another account. At Wikipedia:Changing username/Simple you can request a rename away from Kahtar, saying you are LindsayH and linking to [21]. Then log in as LindsayH and confirm it. Then log in from a third account with a working password and request a rename to Kahtar. Special:CentralAuth/Kahtar also shows accounts at meta and simple. They would need separate rename requests if you want them in the new account. Don't visit any further wikis while you are logged in as Kahtar. That will create the account at those wikis. PrimeHunter (talk) 11:29, 19 June 2013 (UTC)
I don't see a need for {{User committed identity}} here when the account has no extra user rights, no edits worth attribution, and you have already explained the problem while logged in. PrimeHunter (talk) 13:03, 19 June 2013 (UTC)

Regarding template The Barnstar of Good Humor

There is some problem with The Barnstar of Good Humor! barn star. See the example in the template's documentation. The same problem can be seen here or here too. But the surprising thing is that everything was perfectly right till 5 June 2013. Moreover the template has not been changed since 22 November 2012‎. I am not getting what the actual problem is. Hope that someone here is able to solve it. Regards. - Jayadevp13 12:47, 19 June 2013 (UTC)

@Jayadevp13:I can't see any problems with it... can you be more precise about the issue please? Mdann52 (talk) 12:54, 19 June 2013 (UTC)
(edit conflict) I fixed a problem in the example [22] but I don't see a problem in the uses you link. Please describe the problem you see and say your browser and skin. Depending on the problem, it may help to clear your cache. PrimeHunter (talk) 12:58, 19 June 2013 (UTC)
This may be stupid question, but are you referring to the difference between the original and alternative versions?
The Barnstar of Good Humor
This is just an example!
The Barnstar of Good Humor
This is just an example!
jonkerz ♠talk 13:02, 19 June 2013 (UTC)
@Mdann52 and Jonkerz: The actual issue is this. When I load a page with that barnstar template, this one for example (the barnstar of humour is the middle one), this is what I see - A yellow box, inside it The Barnstar of Good Humor! heading, the text written below it from Hello Jayadevp13 ...to... 2 April 2013 (UTC) and then, just a blue coloured link to the file Barnstar of Humour Hires.png in the left. The 100px image doesn't display. Moreover, I am not able to highlight that blue coloured link with a cursor (as can be usually done, links can be highlighted for copying that text). The same thing is happening with the the second box which Jonkerz has added above. The first one appears perfect wherever I see it. I don't see that problem with any other barnstar boxes.
@PrimeHunter: I use Mozilla Firefox and vector.js skin. I also have Google Chrome installed and when I loaded the page in it, every thing's working fine. Don't know why?
I believe that somewhat the same problem is also being experienced by the person using the IP 117.201.187.14. He/She had told about it here. He/She had earlier edited User talk:Jayadevp13/Archive 1 (maybe coincidence). Regards.
- Jayadevp13 16:42, 19 June 2013 (UTC)
It might sound stupid, but just in case: Have you tried clearing your Firefox's cache (or reloading the page while holding the shift key on your keyboard)? --Patrick87 (talk) 17:09, 19 June 2013 (UTC)
@Patrick87: Your idea is not at all stupid. It works fine now. Everything has turned back to normal. But what was the actual problem and why didn't it happen to any other barnstar box. An explanation of how to do it also needs to be given to 117.201.187.14. Regards. - Jayadevp13 17:15, 19 June 2013 (UTC)
It's not uncommon that an image temporarily fails to display at one or more resolutions for some or all users. It's usually fixed automatically. Commons:Help:Purge has tips which can sometimes help. It can happen to any image and is not related to barnstar coding. PrimeHunter (talk) 20:23, 19 June 2013 (UTC)
@PrimeHunter: Maybe that you are right. I don't know about it.
@Mdann52, PrimeHunter, Jonkerz, and Patrick87: Thank You all for using your time to help me. Regards and keep your good work going. - Jayadevp13 02:57, 20 June 2013 (UTC)

Interaction report

Is there an existing tool that will tell me if, where, and when I have interacted with another user before? VQuakr (talk) 19:23, 19 June 2013 (UTC)

Not that I know of, but there is a tool to tell you which pages you have both edited. WP:EIW is a good resource to find such tools.-gadfium 22:37, 19 June 2013 (UTC)
There are two more listed on Wikipedia:Tools#Page histories, each with somewhat different features. If the other editor has a few thousand edits, the question is not if, but where and when; you (VQuakr) and I have 67 pages in common (omg! sock puppets!) :) jonkerz ♠talk 22:45, 19 June 2013 (UTC)
Perfect, thank you! VQuakr (talk) 04:40, 20 June 2013 (UTC)

Is there an automated way to convert plain text dates to {{Start date}}?

Hi, first time posting to the Village pump, so I apologize in advance for my n00bishness. I posted the following question at the Help Desk and was encouraged to come here:

I was wondering if anyone knows 1) if there is an automated way to convert plain text dates to the {{Start date}} microformat template (ex: January 31, 1999 --> {{Start date|1999|01|31}}) and 2) how to request such a bot to take a pass at an article. This is an example article in need of repair. Thanks y'all! Cyphoidbomb (talk) 20:01, 19 June 2013 (UTC)

Looking for a tool that is the reverse of the Editor Interaction Analyzer

I floated a question by the Help Desk a few weeks ago but the question got sidetracked and was never answered. I'm basically looking for a tool that is a reverse version of the Editor Interaction Analyzer. That is, I want to enter a bunch of articles into the tool, and have it tell me who the common editors are. My feeling is that this would be super-helpful for sockpuppet hunting. Ex: Maybe you've noticed that all articles about Spongebob Squarepants are being vandalized. Maybe you suspect User1234 of sockpuppetry/IP hopping/block evasion. Entering all of these pages into such a tool would tell you who the common editors were, so that you might be able to spot a trend with IP ranges, user names, etc. Does such a thing exist? Thanks! Cyphoidbomb (talk) 05:01, 20 June 2013 (UTC)

Resolved
 – Consider resolved as per CfD as mentioned. It just took some days. -DePiep (talk) 23:25, 20 June 2013 (UTC)

Categories Articles with fooian-language external links (e.g. with Bengali language in Mahatma Gandhi Road, Kolkata) seem to be unhidden or whatever it is. Any progress on that? Brandmeistertalk 14:48, 17 June 2013 (UTC)

Somebody recently decided to alter certain templates, such as {{language icon}} (see this edit), to use a hyphen instead of a space in the category, without first ensuring that the new categories existed. A non-existent category shows as a redlink; and is never hidden. --Redrose64 (talk) 18:30, 17 June 2013 (UTC)
The categories are in the process of being renamed per CFD. I suggest patience: it is a time-consuming process because there are hundreds of such categories. Give us a few days to complete this before anyone freaks out. Good Ol’factory (talk) 21:46, 17 June 2013 (UTC)
The CfD is wp:Categories_for_discussion/Log/2013_June_1#Category:Articles_with_non-English_language_external_links. The todo list is Current nominations as of today: [23] -DePiep (talk) 21:58, 17 June 2013 (UTC)
Due to the mounting concerns (I've had several inquiries), I'm going to just waive through the regular 48-hour waiting period and try to start the bots on the renames today. This should resolve the problem as quickly as possible. Good Ol’factory (talk) 22:01, 17 June 2013 (UTC)
I'd say, don't mount the bot before recovering from the horse's one. But hey, I only know about mountains. And: since it is covered (not forgotten), I don't mind time. -DePiep (talk) 22:05, 17 June 2013 (UTC)
Resolved
 – --- Consider resolved as per CfD as mentioned. It just took some days. -DePiep (talk) 23:25, 20 June 2013 (UTC)

Category:Articles with Russian-language external links does not exist, but redlinks e.g. from Compounds of fluorine. Creating it by [24] shows 200+ (potential) pages. What happened? Similar: page Aziz Duwaik has redlink Category:Articles containing Arabic-language text. -DePiep (talk) 20:53, 17 June 2013 (UTC)

This happened; see #Articles with fooian-language external links, above. -- John of Reading (talk) 21:04, 17 June 2013 (UTC)
I could have thought there was an earlier post on this. And: my section title is off. I keep this one for the example. -DePiep (talk) 21:37, 17 June 2013 (UTC)
The categories are in the process of being renamed per CFD. I suggest patience: it is a time-consuming process because there are hundreds of such categories. Give us a few days to complete this before anyone freaks out. Good Ol’factory (talk) 21:45, 17 June 2013 (UTC)
Fine with me. Have a nice edit. -DePiep (talk) 21:49, 17 June 2013 (UTC)
Bots should be starting the renaming process today, as long as the bots don't decide they are on strike today. Good Ol’factory (talk) 21:59, 17 June 2013 (UTC)

please link en:Juan Gabriel Valdés to es:Juan Gabriel Valdés and to it:Juan Gabriel Valdés. --Best regards, Keysanger (what?) 09:57, 20 June 2013 (UTC)

 In progress right... There are 3 different ones on wikidata, making this impossible atm. There is d:Q6299838, d:Q3810840 and d:Q13512624. I've pinged someone on there to sort the dups out, and I'll clean up later. Mdann52 (talk) 10:11, 20 June 2013 (UTC)
It's cleaned up now, and Mdann has already requested the deletion of redundant entries.  Done Matma Rex talk 12:09, 20 June 2013 (UTC)

Hyderabad, India

Something has happened to all the alt-text on the article Hyderabad, India. I used visual editor and something happened. I am at a loss really. Cas Liber (talk · contribs) 10:06, 20 June 2013 (UTC)

I propose to edit "Country data Niger"

I propose to adjust the template "Country data Niger", following the example of the "Country data Belgium".
Edit from Niger to in Template:Country data Niger and the current default {{flagicon|Niger}} rename to {{flagicon|Niger|state}}
like Belgium has been modified to Belgium as a new default, in Template:Country data Belgium. — Maiō T. (talk) 18:28, 20 June 2013 (UTC)

RFC 2011

I was making a template for pending changes discussions, and unexpectedly, I found out that just typing RFC 2011 gives an external link, as you can see, to a 2011 RFC by the ietf. But why is this... Cenarium (talk) 21:03, 20 June 2013 (UTC)

It's like ISBN, and has been happening for *years*. See WP:RFCAUTO. --Redrose64 (talk) 21:13, 20 June 2013 (UTC)
Thanks, and it's likely going to keep happening for quite some time considering the latest discussion and bugs status. Cenarium (talk) 04:10, 21 June 2013 (UTC)
FUN FACT: ISBN magic auto-linking was introduced in rev:40 (November 2001). I'm not sure when RFC was added. --MZMcBride (talk) 05:04, 21 June 2013 (UTC)

I love how clicking play on the video in Mirror test opens and enlarges the video in the center of the screen, dims the background, and starts playing. It would be great if images also operated in this way. The majority of readers when clicking on an image simply want to see a large version of it.. the user experience would be better if the image opened just like the video example. It would have its caption, a link to the file page, maybe a next/previous button for other images in the same article. Has this been discussed or considered for the English WP? I'm sure the developers are busy but I think it would be a huge improvement. --Mahanga (Talk) 03:54, 15 June 2013 (UTC)

I'm afraid this is not feasible, for legal reasons. For any non-copyright image (such as those licensed CC-BY), we must provide attribution, and displaying the file description page is the means of doing this. --Redrose64 (talk) 07:02, 15 June 2013 (UTC)
I don't understand how we can do it for videos but not for images? The same licensing issues apply. --Mahanga (Talk) 14:42, 15 June 2013 (UTC)
By Centrx. Licensed CC-SA 3.0. Click for full-size image and description.
The video has a 'credits' section, that (although imperfect) is probably the best we can do and at the same time keep presenting video in a usable way. With images we have always been afraid that if we present people with a 'bigger' version, they will download that, instead of downloading it from the 'origin' page. We can definitely create some sort of image mode as well, its just that noone has made it yet. It would be easier if we actually had a database with attribution and licenses for each file, that would make presenting the attribution in different formats a lot easier. —TheDJ (talk • contribs) 13:17, 16 June 2013 (UTC)
Thank you for the reply. I do wish someone steps up to the task because I think everyone would agree that it makes for a much better user experience, especially on mobile. The challenges regarding licensing seem minor and surmountable. I'm not sure how the video extracts the licensing information, but I'm sure the same or similar method could be used for images. The image could also have a link to the Commons page and also links to download original version and/or different resolutions. There are a number of extensions[25] that could be serve as a great starting point. Here's wishing for some image viewing changes by sometime in 2014. --Mahanga (Talk) 15:34, 16 June 2013 (UTC)
Redrose64, "not feasible" is a pretty strong statement. What's wrong with displaying attribution and licensing information in the lightbox frame under the image, just like how you would do it when embedding an image on any other website? The example at right is all I would have to do on my own website to meet license conditions. — Scott • talk 09:20, 21 June 2013 (UTC)

CHECKWIKI and/or AWB removing self-closing XHTML syntax

At here, two <BR /> tags were changed to <BR> tags, in addition to replacing a missing double-bracket later in the article. The edit comment was "(WP:CHECKWIKI error fix #10. Bracket problem. Do general fixes and cleanup if needed. - using AWB (9270))". I understand the slash is needed to make it syntactically correct XHTML. In WP pages, is the <BR /> form incorrect (unlikely), optional (likely), or required (unlikely)? Did AWB/CHECKWIKI do this, or was it the operator (and should it have)? —[AlanM1(talk)]— 07:20, 18 June 2013 (UTC)

I've checked it using 5.5.0.2 SVN 9117, and that version doesn't make this change, so either this is a recent change to the AWB code or it is something that Bgwhite (talk · contribs) did specially. -- John of Reading (talk) 07:50, 18 June 2013 (UTC)
(edit conflict) We used to serve XHTML 1.0, where <br /> was the only permitted form. In 2012 (I think, possibly late 2011) we started serving HTML5 instead, where the documented form is <br> but <br /> is also permitted. In HTML5, either may be upper or lower case - in XHTML, only lowercase is permitted. So we've gone from a single variant to four. Despite that, some people do occasionally use </br> which is meaningless in HTML5, and only meaningful in XHTML if it directly follows a <br> - which was specifically recommended against in the XHTML docs. --Redrose64 (talk) 07:51, 18 June 2013 (UTC)
If you look at the HTML page source of each revision, you will see that HTML Tidy transforms both variants into <br>. Nothing to stress about in that regard. "Optional" would be my answer to the original question. — This, that and the other (talk) 11:02, 18 June 2013 (UTC)
For what it's worth, the syntax highlighter gadget treats only <br /> as correct, for ease of implementation. I'm not sure how popular that gadget is now, though. --SoledadKabocha (talk) 17:30, 18 June 2013 (UTC)

AWB doesn't change <br/> to <br> -- Magioladitis (talk) 14:42, 21 June 2013 (UTC)

Database lag?

What did the devs break this time? :p—cyberpower ChatOffline 19:15, 20 June 2013 (UTC)

You don't expect any neat responses to this, do you? -- Toshio Yamaguchi 19:41, 20 June 2013 (UTC)
It's strange, cause I'm having a lot of issues with other sites too all of a sudden. ViperSnake151  Talk  19:49, 20 June 2013 (UTC)
It's meant to be humorous. But what did happen though?—cyberpower ChatLimited Access 20:13, 20 June 2013 (UTC)
When I was a car mechanic in my imaginary previous life and had customers calling and saying "My car is broken, tell me what's the issue, but I won't provide any details" I sometimes had a tough time. But this is meant to be humorous too. --AKlapper (WMF) (talk) 09:34, 21 June 2013 (UTC)

Database lag

Moved from Wikipedia:Village pump (technical)/Archive 113 § Database lag
 – --Redrose64 (talk) 20:34, 20 June 2013 (UTC)

Due to high database server lag, changes newer than 913 seconds may not appear in this list.

What does this message mean? and how this issue will resolve? I mean, i can't see the newest changes--Jockzain (talk) 19:13, 20 June 2013 (UTC)
Usually things are updated in just a few seconds. The message appears when that time increases dramatically. Wait at least 914 seconds and the changes will probably appear. There have been times when database lag was several hours. - 79.67.252.44 (talk) 08:58, 21 June 2013 (UTC)

A query about bullet-point options

Hello. I'm trying to use bullet points as a way of structuring Infectious_mononucleosis#Signs_and_symptoms by age-groups without interrupting the flow, as subheadings would. My problem is that the second level of bullet points (i.e. a particular set of symptoms) is not a subdivision of the first level (the age groups). For this reason, I'd like to use graphically different (less prominent) bullet points for the second-level. I'm not sure whether the wiki markup allows this. Any suggestions? Thanks in advance, 81.157.7.7 (talk) 10:18, 21 June 2013 (UTC)

You could use {{plainlist}}, that removes the bullets altogether. --Redrose64 (talk) 13:14, 21 June 2013 (UTC)
Thanks Redrose64. Cheers, 81.157.7.7 (talk) 14:48, 21 June 2013 (UTC)

Inputting a collapsible userbox list into infobox

When I see 10, 20 or 30 userboxes side by side or stacked, it hurts my eyes. So I've been attempting to incorporate collapsible lists of userboxes into my info box. I'm very new at Wiki-markup and the associated technical language, thus in attempting to solve my problem I've been using various portions of collapsible list templates that work in their own box/page and using said markup as a guide to creating my own.
My issues are,

  • The collapsible list title and it's associated clickable link, 'show' are scrambled over each other.
I have a minor fix for this, I input a userbox all on it's own, below the hidden/collapsible area, and somehow this formats or changes the list title and show button so they do not overlap.
  • However, regardless, when I expand my lists... lets say I expand list 1..the userboxes in list 1 look fine overall, but the title of list2/list3, etc and their show buttons are then scrambled over my userboxes or in random nearby spots.

You can check out my infobox at my user-page here. Or my sandbox has it loaded as well, where your free to dabble with as you please if it helps fix the issue.
My sandbox has two copies of the infobox, one with the minor fix applied (on top) and one without (on bottom).
In conclusion, I'm not running for help at the first sign of danger. Look at edits to my userpage over the last few days and you'll see I've tried quite a few different things. I want yall to know I've been actually researching this, but to no avail. Thank you for your time,
EzPz (talk) 17:00, 21 June 2013 (UTC)

Hello, ParksTrailer, I'm pretty sure I can help you with this... Do you want it in a collapsible section or do you want it inside of a scrolling section like I have on my user page. Take a look and let me know. :) Technical 13 (talk) 17:37, 21 June 2013 (UTC)
Thank you for checking out my issue! Collapsible, please sir :)EzPz (talk) 18:00, 21 June 2013 (UTC)
Well, I took quite the liberty with how your wiki page was set up, and I've just about solved the problem completely. The only things left are for me to figure out how to align it to the left, add a backgorund color and up the font size, HOPEFULLY I can figure that stuff out :) My sandbox is updated, if you wanna take a look. Thanks man! EzPz (talk) 21:09, 21 June 2013 (UTC)
I suggest reading the documentation for the infobox template... {{Infobox user}} Technical 13 (talk) 01:06, 22 June 2013 (UTC)

X!'s Edit Counter

RfC launched on meta. There is clear support for the removal of the opt-in requirement. Please direct all comments and opinions to that RfC.—cyberpower ChatOffline 03:03, 22 June 2013 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

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)

Further explanation, copied from below and edited a bit for clarity.
Currently, any editor must opt themself in to allow other editors to see additional statistics in X!'s edit counter (for that editor). These additional statistics are (a) top namespace edits and (b) monthly edit statistics. This opt-in was set up because because of a law in Germany, where the toolserver is located. Since we are migrating everything from the toolserver to Wikimedia's labs (in the U.S.), this law isn't relevant anymore.
There are editors who want to see the monthly stats and top namespace edits for everyone, not just for editors who have opted in. The question is should we allow this (by disabling opt-in) or whether we should users to still have control over what can be seen in the edit counter (by keeping opt-in). A third option is to allow users to opt-out; if they don't, then all other editors could see their full statistics.
-- John Broughton (♫♫) 18:33, 14 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 ChatOnline 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 ChatOnline 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)
    The really crazy/creepy folk, the ones that would engage in off-wiki hounding or outing or real life confrontations, don't need X!s tool. Those people are dedicated enough to sift through a lot more than just some graphs. Sven Manguard Wha? 17:02, 8 June 2013 (UTC)
  6. The fact that some data is public but scattered, is one thing, collecting and organizing the data is something quite different, that is (good part of) the work of Intelligence agencies («intelligence gathering, [...] does not necessarily involve espionage, but often collates open-source information.», from Espionage). WP is not a espionage / intelligence agency, I'd say. - Nabla (talk) 23:07, 5 June 2013 (UTC)
  7. Per Chris G. It Is Me Here t / c 17:01, 6 June 2013 (UTC)
  8. Yes. This is one of the rare questions I have a gut answer to :-). The data is public, and there is nothing stopping people "rolling their own" analysis, but there is a big difference between that and Wikimedia-supported profiling and publication. Andrew Gray (talk) 19:33, 6 June 2013 (UTC)
  9. Yes. The opt-in steps are easy (even I figured it out), and the privacy concerns are compelling. New editors are probably unaware of the feature, and for some this could discourage participation when they become aware. 78.26 (I'm no IP, talk to me!) 15:46, 10 June 2013 (UTC)
  10. Very strong support that it should be "opt-in". There are strong privacy concerns. We can expect new users to be unaware that these counters even exist for a substantial period of time before they discover them; that is, if many of them would even discover them at all. I do not think they should be surprised about it when and if they do. This should even be being polled. It's a matter of principle. — Preceding unsigned comment added by Jason Quinn (talk • contribs) 17:39, 11 June 2013 (UTC)
  11. I'm aware it's easily available through other means, but it doesn't automatically follow that it should be easily available through this tool as well. wctaiwan (talk) 07:28, 15 June 2013 (UTC)
  12. I prefer opt-in. It's not a critical issue, but it seems polite to ask people for permission before collecting and visualizing information about them – even if it's public information. Also, we don't need to turn Wikipedia into some kind of contest or competition. NinjaRobotPirate (talk) 14:40, 16 June 2013 (UTC)
  13. Keep opt-in. - Yes, the data is already available. But there is indeed a difference between that and analysis of the data supported by WikiMedia. Plus, people are too interested in this often (but not always) trivial data. See the numerous edit counters. Garion96 (talk) 08:15, 21 June 2013 (UTC)
  14. Keep opt-in. --Robby (talk) 05:54, 23 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 (talk) 17:46, 4 June 2013 (UTC)
    Just as an additional note, I'm fine with the consensus to remove opt-in altogether. Transparency is important; when I first commented here, I just thought some editors might feel more comfortable with the option to not have their editing history so much easier to track. The more I think about it, the more I'm swayed by the comments directly below. Consider this a support for either option. "One is the loneliest number that you'll ever do..." Kurtis (talk) 04:33, 16 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)
    @MZMcBride: Someone just got a new nickname. I kinda like how "Max" rolls off the tongue vs. "MZ". You might also want an avatar, though, to counter that mental image of Max Headroom that springs to mind.... ;-)  —Grollτech (talk) 22:25, 17 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 talk 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 talk 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. [26] 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)
  8. Per Jayron32 -- John of Reading (talk) 04:49, 5 June 2013 (UTC)
  9. Per everyone above. Graham87 04:54, 5 June 2013 (UTC)
  10. I have never understood why this is opt in. It saves a lot of time on various issues, and therefore should be available freely - especially as there are no privacy issues. Mdann52 (talk) 10:05, 5 June 2013 (UTC)
    @Mdann52: It was opt-in because German law required it. Toolserver is located in Germany.—cyberpower ChatOnline 15:07, 5 June 2013 (UTC)
  11. Per above, if it's moved from a server where it's a legal requirement (damn Germans!). It's not actually private information - just number of edits/month and number of edits to individual articles, both of which IIRC can be found on other tools, associated or not. Ansh666 14:39, 5 June 2013 (UTC)
    @Ansh666: You realized you just damned me, right? The guy who is moving the tools to labs. :p—cyberpower ChatOnline 15:07, 5 June 2013 (UTC)
    Heh, oops. Ansh666 20:20, 7 June 2013 (UTC)
  12. Per all above. ·addshore· talk to me! 23:11, 5 June 2013 (UTC)
  13. You cannot make private what has already been publicized. When each datum has been published, nothing new is revealed by summaries and aggregations that users could always perform on their own computers, if they wished. Opt-in or opt-out attempts to weave garments of mixed fibers. DavidLeighEllis (talk) 02:00, 6 June 2013 (UTC)
  14. Because this information is very easy to gather from the API, which is publicly accessible, and with only very minimal coding skills. Any added privacy from an opt-in is illusory. — Carl (CBM · talk) 02:16, 6 June 2013 (UTC)
  15. Per supra. Theopolisme (talk) 03:07, 6 June 2013 (UTC)
  16. I don't understand how there can be a privacy violation. The pages a person has contributed to is something they should be proud of. -- (T) Numbermaniac (C) 07:24, 6 June 2013 (UTC)
  17. A false sense of privacy. Marcus Qwertyus (talk) 19:08, 6 June 2013 (UTC)
  18. Per User:Numbermaniac, Not entirely sure how it can be considered a "privacy violation", If you don't want the edit counter being public then don't edit on WP, It's not rocket science!. ........ →Davey2010→→Talk to me!→ 00:15, 7 June 2013 (UTC)
  19. This is not a privacy issue. We are all responsible for maintaining the integrity of Wikipedia. Transparency is good. Carrite (talk) 06:43, 7 June 2013 (UTC)
  20. The information is already public! The only thing one needs to work a lot to find those! --Tito Dutta  (talk • contributions • email) 00:22, 8 June 2013 (UTC)
  21. There isn't a real privacy concern here, and I'm someone that takes digital privacy more serious than they should. I see no reason not to remove opt-in. Sven Manguard Wha? 16:56, 8 June 2013 (UTC)
  22. Suggesting an illusion of privacy with an opt-in is worse than being up front with what this data is. older ≠ wiser 17:08, 8 June 2013 (UTC)
  23. Useful information, and consistent with the desire for transparency.--SPhilbrick(Talk) 13:08, 10 June 2013 (UTC)
  24. Activities performed in a public place aren't private.—Kww(talk) 19:29, 11 June 2013 (UTC)
  25. The information stats isn't a privacy issue as its already available and accessible to all. All this does is compile the information that anyone can already view in an easy format.Blethering Scot 19:33, 11 June 2013 (UTC)
  26. I fail to see how anybody's editing history is private. On some users I've always wanted to see the detailed stats for some people but they haven't opted in yet. JayJayWhat did I do? 00:27, 12 June 2013 (UTC)
  27. Compiling stats from public information doesn't require anyone's permission. I oppose the ability to opt-out too. Transparency is key. -Nathan Johnson (talk) 01:37, 16 June 2013 (UTC)
  28. Support per all above. Fredlyfish4 (talk) 20:30, 16 June 2013 (UTC)
  29. Per Tom Morris. -- Ϫ 06:58, 18 June 2013 (UTC)
  30. This information can be computed rather quickly from Special:Contributions. Why go through all the trouble if the tool is available? This information is really in no way private. Jguy TalkDone 14:08, 18 June 2013 (UTC)
  31. I'm for transparency. Let everything be public. —Anne Delong (talk) 14:46, 18 June 2013 (UTC)
  32. Support with the reservation that en.wiki does not control a global tool, and this decision needs to apply to en.wiki only or be taken to meta before implementation, as well as explicitly approved by the WMF legal eagles. Tazerdadog (talk) 21:29, 18 June 2013 (UTC)
  33. Support removal of opt-in. Most of the "privacy!!!!!!!!!!!!11" people are Snowdenbots who really have no idea about privacy. Just because some information happens to be hidden away in a dark corner of the Internet doesn't mean it's private, it's just not yet been seen by many people. I wouldn't be surprised, though, if the Snowdenbot WMF nuked this proposal from orbit (assuming the "#YOLOswagz2001WMFlolprivacyfreecultureftw" people who make up Wikipedia's high society rejected this as "no consensus".) In the end, this isn't a privacy issue, it's a non-issue, and anyone hacking at the privacy stump is really fooling themselves. Wer900 • talk 04:39, 19 June 2013 (UTC)
    Was the ridiculing really necessary? wctaiwan (talk) 08:58, 21 June 2013 (UTC)
  34. Compiling public data (about anonymous user names) and displaying it is easy to read form in no one violates anyone's privacy. --ThaddeusB (talk) 05:19, 20 June 2013 (UTC)
  35. Tom has put it very well. There is no sense in which this data is, or should be, private. — Scott • talk 14:55, 20 June 2013 (UTC)
  36. Per User:King of Hearts and my comment below. Kudpung กุดผึ้ง (talk) 08:06, 21 June 2013 (UTC)
  37. --Andyrom75 (talk) 05:36, 23 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 ChatOnline 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 ChatOnline 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 ChatOnline 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 ChatOnline 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 ChatOnline 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 ChatOnline 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)
    Ok then go ahead. Someone who is not a coder, please work out the namespace totals/month counts/etc for my account. --Chris 02:45, 5 June 2013 (UTC)
    It is rather time consuming, but they could do that by going through Special:Contributions and compiling the statistics by hand. Toolserver (or now Tool Labs) or API scripts are just doing what any editor with the time and inclination could do. There's nothing stopping anyone from creating an off-wiki edit counter that uses the API and shows far more detailed information than X's counter - WikiCounter for instance. I might do so on Tool Labs precisely because I'd like to play around with new fancy charting libraries. —Tom Morris (talk) 04:29, 5 June 2013 (UTC)
    That link is broken.—cyberpower ChatOffline 04:33, 5 June 2013 (UTC)
    Thank you for proving my point. Yes the data is public, but who in the right mind would go through 20,000 edits and count them manually? Yes it would be possible for a dedicated person to work out this kind of information, that does not mean we should make their job any easier. --Chris 05:01, 5 June 2013 (UTC)
    Anyone could download a mirror of the database and run a query to get the same results. It's not limit to TS tool devs.--v/r - TP 13:26, 5 June 2013 (UTC)
    Yes, I completely understand that. What I am saying is that there is a big difference between someone being able to use the API, or a database dump and write a script to generate that information, and someone being able to navigate to a web page and access it at the click of a button. No, it's not perfect privacy, but it is better than nothing. --Chris 13:33, 5 June 2013 (UTC)
    Chris, no offense intended, but I'm not sure that you understand what the word "private" actually means. — Scott • talk 19:26, 20 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 ChatOnline 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 How can I help? 15:40, 4 June 2013 (UTC)
    I also am not sure as to why, if this was a serious proposal, the English Wikipedia would get to decide what happens to a global tool. Snowolf How can I help? 15:41, 4 June 2013 (UTC)
    It's not toolserver anymore. It's labs. Completely different now.—cyberpower ChatOnline 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 talk 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 ChatOffline 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)
    To address the issue of the tool's 'owner', I maintain that I inherited the and do not own them and I've taken part in the process, led by Cyberpower, to migrate these tools to labs. I've joined a team, of sorts, that Cyber has termed xlabs and so as these tools move to labs, I am abdicating any sort of psuedo ownership I gained while hosting open source tools that I didn't even design and barely maintained. I'm definitely okay with any changes to the tools as long as it's a team decision and I've address that with Cyber already.--v/r - TP 02:23, 5 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「m/Talk」 22:06, 4 June 2013 (UTC)
  • I'd have to agree with Snowolf, this should be a global discussion and not held on enwiki. Enwiki is not in charge of the other wikis. --Rschen7754 04:53, 5 June 2013 (UTC)
    If this RfC continues to take this course, we will most likely launch a second RfC on meta before any change is applied, after a discussion with the team.
Any chance we could make it opt-out only for en.wp users? I only ask because meta moves slower than a snail with a brain injury when it comes to policy discussions. Beeblebrox (talk) 03:17, 6 June 2013 (UTC)
Based on what I'm looking at right now, it doesn't look there's going to be an opt at all. Besides, the change won't go into effect until at least the tools are migrated, debugged, and fully set up.—cyberpower ChatOffline 03:49, 6 June 2013 (UTC)
  • I'm echoing Snowolf's concerns. The English Wikipedia does not have sole authority over this tool.--Jasper Deng (talk) 04:37, 16 June 2013 (UTC)
    Correct. TParis and I have authority, but unlike Wikipedia devs, we're giving the English and global community the opportunity to decide. — Preceding unsigned comment added by Cyberpower678 (talk • contribs) 14:59, 16 June 2013 (UTC)
    This line of argument is begging the question. — Scott • talk 09:12, 21 June 2013 (UTC)
  • There are anomalies in German laws. Germany probably keeps the most detailed personal information over its residents than any other Western country and that is why the populace is largely paranoid about their personal data, which then reflects in such trivia as the use of the ToolServer for quickly compiling data that most of us can gather and collate from other tool server devices, editor contribs, and page histories. The sooner the Edit stats without op-in become available as standard, it will make the work of RfA /RfB/ARCOM/Stewarship, voters, SPI researchers, the granting of minor user rights, and many more meta workers much easier. Kudpung กุดผึ้ง (talk) 08:03, 21 June 2013 (UTC)
    I was aware that the tool was very popular, but wasn't aware that there was such a strong dependency on it. I will begin a meta RfC to determine the remaining fate of the tool.—cyberpower ChatOnline 02:20, 22 June 2013 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

(edit conflict × 2)

Every edit I have made since tuesday has edit-conflicted, yet they have all gone through apart from the one I just tried to make to post this, and no other users have been involved.--Gilderien Chat|List of good deeds 19:29, 20 June 2013 (UTC)

One issue may be if you are double-clicking the "save page" button - I have run into this issue before. Mdann52 (talk) 12:15, 21 June 2013 (UTC)
I thought about that but it is still happening, but now some (maybe 1/4) of my sessions are lost.--Gilderien Chat|List of good deeds 00:24, 23 June 2013 (UTC)

Wikipedia block in Togo

The Wikipedia website (French, English, German and Swedish) is blocked by Government of Togo (Republic of Togo), all computers cant not access Wikipedia and we do not know why. --Togolaís Díplomátique (talk) 12:37, 22 June 2013 (UTC)

From editing or from viewing? We don't block viewing of wikipedia from anywhere. If it's from editing, you way want to try the unblock ticket request system to try to get your situation sorted out. Sailsbystars (talk) 13:51, 22 June 2013 (UTC)
Both. No one living on Togo can edit or view Wikipedia. I am a correspondant in neigbouring Ghana and we are getting numerous reports from Togo telling us that local ISPs and the Government has blocked the viewing of Wikipedia. --Togolaís Díplomátique (talk) 13:54, 22 June 2013 (UTC)
Ahhh... with that we can't help you directly I'm afraid. The only way to get read (but not write) access is by bypassing your country's filters using open proxies. WE have a project on closed proxies which might be able to get a small number of people editing. One simple way to read wiki articles is to do a google search and click the downward triangle next to the resulting URL and selecting "Cache" which will use google's cache of the page and doesn't require direct access to wikipedia. Sailsbystars (talk) 14:02, 22 June 2013 (UTC)
Okay thanks for your help. The Togolese Ministry of Information has just released a statement saying that the block was due to 'misinformation and blatent lies'. We have had reports of Wikipedia being blocked in parts of Benin aswell. Will keep you guys updated. Thank you.

Pierre Rednóis.

--Togolaís Díplomátique (talk) 14:14, 22 June 2013 (UTC)

Is this statement available online anywhere? Is there discussion of this anywhere else you're aware of? Nil Einne (talk) 17:56, 22 June 2013 (UTC)

The user has been blocked as a sockpuppet of Technoquat. ​—DoRD (talk)​ 19:36, 22 June 2013 (UTC)

X!'s Edit Counter

(Sorry for writing in English. You can translate the proposal.)

Should X!'s edit counter retain the opt-in requirement? Your input is strongly encouraged. Voice your input here.——cyberpower ChatAutomation 04:21, 23 June 2013 (UTC)

Distributed via Global message delivery. (Wrong page? Fix here.)

Google and talk pages

Does Google usually index the Wikipedia talk pages? I don't remember seeing this before, but maybe I didn't happen to do an appropriate search. ( for example, this search) —Anne Delong (talk) 20:16, 20 June 2013 (UTC)

Looks like it does index project talk. Werieth (talk) 20:32, 20 June 2013 (UTC)
Yes, any talk page that is not explicitly marked as {{NOINDEX}} will be indexed by Google. The main exception is "User talk", where you must opt in for each user talk page you want indexed. There are also some exceptions listed in Robots.txt, such as the talk pages of Articles for deletion. – PartTimeGnome (talk | contribs) 21:13, 20 June 2013 (UTC)
Hmmm.... That's an interesting list of noticeboards and discussion pages, most of which I didn't know existed. I'm surprised that Wikipedia talk:WikiProject Articles for creation isn't on the noindex list; there is a lot of frank discussion there about deletions, copyvios, BLP problems, unwanted advertising, etc. —Anne Delong (talk) 23:10, 20 June 2013 (UTC)
WP:NOINDEX is a somewhat good resource. There seems to be some dated info on that page, however. Killiondude (talk) 04:33, 21 June 2013 (UTC)
Thanks again. There seems to be always more to learn about WP! —Anne Delong (talk) 13:52, 23 June 2013 (UTC)

Tracked template stopped working

Please see MediaWiki talk:Gadget-BugStatusUpdate.js#Failure in Chrome/Firefox. — Edokter (talk) — 16:08, 22 June 2013 (UTC)

It only seems broken here. Previewing separate section using them shows them working. — Edokter (talk) — 13:11, 23 June 2013 (UTC)

Image redirects

I'm confused by what I've done. I've uncovered a block evader (blocked on both English Wikipedia and Commons) that is running a good hand/bad hand operation, with the good hand running on Commons and the bad hand running here. His original 75 socks on Commons are blocked, but I expect some resistance to simply deleting all of his contributions, especially since he hasn't been disruptive at Commons in this latest guise.

So, I created a little message file.

.

Then I created a redirect to it: File:Redirect test. Works a treat.

So, went to File:Max Irons 2012.jpg and created the page with the redirect. It continued to show the image, and my redirect wound up in the description. Thinking I had failed to achieve my goal, I then deleted the file I had created (http://wiki.riteme.site/wiki/Special:Undelete/File:Max_Irons_2012.jpg) and now the redirect takes effect and overrides the image.

File:Max Irons 2012.jpg

In some ways good, but I recognize that if I do this to the images, people have the right to bypass it and use the image anyway: I can't put an irreversible block to using the image. Since deleting the file I made caused the effects I had created to take effect, I'm now completely at a loss as to how to undo this cleanly (and ideally without requiring admin rights).—Kww(talk) 19:29, 22 June 2013 (UTC)

Creation/upload protection require admin rights, and so do blacklists and edit filters (well...not really, but still advanced rights).  Hazard-SJ  ✈  02:59, 23 June 2013 (UTC)
At this point I haven't protected anything. What I'm most confused is that when I created the redirect, it did nothing, but now that I've deleted it it takes effect. I'm not precisely certain how to undo what I've done at all, and I'm certain that things aren't supposed to work the way they are.—Kww(talk) 03:43, 23 June 2013 (UTC)
I don't know how to undo it either, but did you check to make sure that the original unexpected behaviour was not the result of a browser caching problem? That can lead to things not showing up when expected, and then showing up later. —Anne Delong (talk) 12:08, 23 June 2013 (UTC)
commons:Help:File redirect#In-depth notes about the operation of file redirects says:
Technically, file redirects are ordinary redirects on File: pages, and they can be created manually. However, this only works where there is no file of that name (if there is a file, any uses of the redirect show the redirect's file, and not the target file - Bugzilla:14928).
Redirects on other projects are not mentioned but it appears from your description that the same holds: If the file exists at Commons then that file is shown and the redirect is ignored. I don't know why the redirect is shown at File:Max Irons 2012.jpg and working as a redirect after it was deleted, but I guess that recreating the file page without a redirect would solve it. PrimeHunter (talk) 13:37, 23 June 2013 (UTC)
  • It's not that the redirect is being ignored, it's some kind of superpowerful redirect that takes effect after deleting it. I've experimented: if I create a local file again, the commons image comes back into view. If I delete the local copy, the redirect comes back into effect, even though all files containing the redirect have been deleted. It's getting stuck somewhere in the MediaWiki software. It's a neat effect, but I think using a bug to manipulate the way we represent several thousand files probably isn't the right answer.—Kww(talk) 16:03, 23 June 2013 (UTC)
You mentioned two issues, one before and one after the deletion of the redirect. I commented on the before situation: When the redirect existed it was being ignored. This is consistent with commons:Help:File redirect#In-depth notes about the operation of file redirects. I have now tested my suggestion to create a file page without a redirect. As expected, this has resolved the issue. The commons file was displayed when the page existed, and is still being displayed after I deleted the page. There is no longer a "phantom redirect" at the deleted English Wikipedia page File:Max Irons 2012.jpg. I agree it's a bug. It should be possible to delete a redirect and be rid of it, without having to remove the redirect code before deleting the page. PrimeHunter (talk) 16:49, 23 June 2013 (UTC)
I think what I'm going to do in these cases is upload the warning message in local namespace above the problematic image in Commons, not getting fancy with a redirect. That way, all that has to be done if some editor decides to incorporated the banned editor's material is to reupload the local copy to match the commons copy or persuade another administrator to delete my blocking image. It would be much simpler if I didn't have to accomodate people that were so desperate to have the lastest and greatest celebrity photos that they were willing to ignore and editors ban status to get them.—Kww(talk) 16:58, 23 June 2013 (UTC)

Script problems

Can someone tell me why User:Nathan2055/afc.js is crashing? It's saying something about extra brackets at the end. --Nathan2055talk - contribs 01:50, 23 June 2013 (UTC)

 Fixed it. Anyone reading this section might also be interested in this. --Nathan2055talk - contribs 15:30, 23 June 2013 (UTC)

Avoiding redirection

Hi, could this template {{ru|FRG}} →  West Germany link here Germany to avoid redirectioning in the same fashion templates like these {{fb|FRG}} or {{bk|FRG}} or {{fh|FRG}} ( West Germany,  West Germany,  West Germany respectively) all link me directly to Germany instead of West Germany? Thank you. Tibullus (talk) 12:59, 23 June 2013 (UTC)

The template to edit to do this is {{Country data West Germany}}. I believe the line to add would be something like this:
| link alias-rugby union = Germany {{{mw|}}} national {{{age|}}} football team
The template is protected, so you'd need to make a protected edit request on the talk page. (I've not tested the above. I'd suggest testing in the template's sandbox first.) – PartTimeGnome (talk | contribs) 14:56, 23 June 2013 (UTC)
  • Rugby-topic decision moved to Template_talk:Ru: Because that issue should get consensus for that other template, I have repeated the question there:
Point to that discussion for other Rugby editors. -Wikid77 15:46, 23 June 2013 (UTC)
I've dropped a note at Template talk:Country data West Germany#Rugby union link change as well. – PartTimeGnome (talk | contribs) 16:31, 23 June 2013 (UTC)

Tech news: 2013-26

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

Recent software changes
(Not all changes will affect you.)
  • The latest version of MediaWiki (1.22wmf8) was added to test wikis and MediaWiki.org on June 20. It will be enabled on non–Wikipedia sites on June 24, and on all Wikipedias on June 27. [27]
  • Universal Language Selector was successfully enabled on the Catalan (ca), Cebuano (ceb), Persian (fa), Finnish (fi), Norwegian Bokmål (no), Portuguese (pt), Ukrainian (uk), Vietnamese (vi), Waray-Waray (war) and Chinese (zh) Wikipedias. [28]
  • The new interface for account creation and log–in is now the default on all Wikimedia wikis. The old look is no longer available (bug #46333). [29]
  • The TimedMediaHandler extension now supports native FLAC files. A discussion to allow this file type is taking place on Commons (bug #49505). [30]
  • After a test period, the Disambiguator extension was enabled on the English Wikipedia on June 18. [31]
  • VisualEditor news:
    • A VisualEditor bug temporarily made all new accounts unusable. The issue is now fixed and account creation works as before (bug #49727).
    • A high importance file insertion bug has been fixed, but the feature does not work perfectly yet. [32]
  • It is now possible to synchronise local CSS and JavaScript files with the beta cluster. This should make it easier to test software features before they are enabled on live wikis. [33]
Future software changes
  • The default link to a help page on editing, visible below the editing window, will change on almost 600 Wikimedia wikis and will now link to MediaWiki.org (bug #45977). [34]
  • Universal Language Selector will be enabled on wikis without language versions (such as Wikisource and Wikispecies) on June 25. [35]
  • The AbuseFilter extension will allow filtering links and HTML code for page creations. [36]
  • The related changes special page will now include upload log entries. [37]
  • It will soon be possible to choose the language of SVG files that contain translations. [38]
  • MediaWiki will now allow converting audio files from one format to another. [39]
  • The Wikidata technical team has started a discussion about how Wikidata can support Wiktionary. [40]
  • The search feature on Wikimedia sites is planned to be modified to use Solr on all wikis by the end of 2013. [41]

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

18:07, 23 June 2013 (UTC)

Note: MediaWiki will now allow converting audio files from one format to another. is actually not what the change in question is about. Its actually a much less interesting change of adding additional stats to Special:TimedMediaHandler about audio files. Bawolff (talk) 22:22, 24 June 2013 (UTC)

Please change "Slovak Republic" to "Slovakia"

I don't know how to change this template:
{{bk|SVK}} produces  Slovakia — it's unnecessarily long form
other templates are in short form:
{{hb|SVK}} produces  Slovakia
{{fb|SVK}} produces  Slovakia
{{ih|SVK}} produces  Slovakia
{{bb|SVK}} produces  Slovakia
195.91.109.79 (talk) 18:33, 23 June 2013 (UTC)

I see the change needed was already requested at Template talk:Country data Slovakia. I added a {{edit protected}} template to get it some attention. GoingBatty (talk) 19:04, 23 June 2013 (UTC)
 Done. Thryduulf (talk) 00:38, 24 June 2013 (UTC)

The Navigational popups gadget doesn't work in Visual Editor. I understand that the creator of Popups is no longer editing. Is there some techie out there looking for a challenge? It would be so helpful if Popups continued to work. While editing an article, it's very useful to be able to see where a link is going, to check whether it's where it ought to be (or a dab page or something else), without having to follow the link to that page.

I've raised this at the VE feedback page and the NAVPOPS talkpage, but thought I'd try for a wider audience here. PamD 13:25, 23 June 2013 (UTC)

This would not be arbitrary to do, simply because of how navigation popups works, combined with the fact that the content in editing mode is dynamic. I think it would require an complete rewrite of the hooks and events system of navigation popups. —TheDJ (talk • contribs) 21:54, 25 June 2013 (UTC)

VisualEditor A/B test back on

Hey all. We're looking to start the A/B test in a couple of hours. My sincere apologies for the short notice :/. If you notice any new bugs, or any substantial problems, please bring them to us as soon as possible so we can resolve them; we'll be monitoring the situation closely and will be able (and willing!) to disable it or put the test off if there's something big that needs resolving. Thanks, Okeyes (WMF) (talk) 15:50, 24 June 2013 (UTC)

This requires a new watchlist notice (possibly even a sitenotice ?). The notice should inform editors about the fact that a group of anons is being fed into this test, and that reviewers and vandal fighters should take extra care when judging the actions of anons, link to page with information about how to perform cleanup of problematic VE edits etc, how to report bugs and how to help fellow editors. Lead the community, don't wait for it to react. —TheDJ (talk • contribs) 13:17, 25 June 2013 (UTC)

Geohack awry as usual

When clicking on acoordinates link, this displays

<quote> Internal Server Error The server encountered an internal error or misconfiguration and was unable to complete your request.

Please contact the server administrator, mpelletier@wikimedia.org and inform them of the time the error occurred, and anything you might have done that may have caused the error.

More information about this error may be available in the server error log.

</quote>

Difficultly north (talk) - Simply south alt. 16:07, 24 June 2013 (UTC)

Is something unclear with the proposed actions in that error message? --AKlapper (WMF) (talk) 07:05, 25 June 2013 (UTC)

Python 3 bots

Are there any Python 3 find and replace bots out there I could fork for a new project? --Nathan2055talk - contribs 20:45, 25 June 2013 (UTC)

WP:BOTREQ seems the perfect place to ask this question. -- John Broughton (♫♫) 02:23, 26 June 2013 (UTC)

uselang=qqx displays message instead of its name

Applying uselang=qqx to Special:RecentChanges gives http://wiki.riteme.site/wiki/Special:RecentChanges?uselang=qqx. Near the top it displays the content of MediaWiki:Recentchangestext instead of displaying the message name "(recentchangestext)". Why? I don't recall seeing this behaviour on other pages. Is there a system to when it's done, or is it a minor bug that it happens here? PrimeHunter (talk) 20:49, 25 June 2013 (UTC)

MediaWiki:Recentchangestext as used on Special:RecentChanges is forced to the wiki's content language, so it is unaffected by uselang. Anomie⚔ 21:04, 25 June 2013 (UTC)
Thanks for the explanation. I guess the documentation for uselang=qqx could use a note about this, and whether there is a good way to find message names when they are forced to the content language. PrimeHunter (talk) 21:25, 25 June 2013 (UTC)
Honestly, there isn't a good way for content messages (beyond grep or source if the message is still the default or search if the message has changed from the default). Bawolff (talk) 00:46, 26 June 2013 (UTC)

Multiple references to the same source

When a particular source is used just once in an article, you are guaranteed to be able to get back to the referenced sentence after viewing the source. When there are multiple uses of the source you have to work out whether the link you followed was from the 1st or 2nd, etc. use of that source.

For example at British National Corpus the first sentence has three supporting sources, [1], [2] and [3], Clicking on the [1] takes you to the references section where you can see it is Burnard and Ashton (1998), you can then follow the ^ link get back to the first sentence. Having clicking the [2] you have to choose from a b c to get back to where you were, in this case it's not rocket science to work out that the first sentence will be link a.

As it gets further down the article though it gets harder to work out. For example in the Spoken discourse under represented section, the first sentence is marked as being verified by source 6. Clicking the [6] you are taken to the references section where you learn the reference is Burnard (2002). After reading that you have to chose from a b c d e f g to get you back to the section you were reading. If you have read the entire article to this point and been noting each source you could possibly work out that it is link f you want. If you haven't read the entire article to this point and/or haven't been noting each source, then you are left with blind guessing. We must be able to do better than that!

TL:DR: When a single source is cited multiple times, getting back from the references section to the right section of pose requires guesswork. This is bad and should be changed.'

The only two solutions I can think of off the top of my head are either to include the usage letter in the inline reference,

"The proportion of written to spoken material in the BNC is 10:1.[6a]", or
"The proportion of written to spoken material in the BNC is 10:1.[6(a)]"

Which might get confusing if people are expecting to find source 6a but end up at source 6. The other alternative is to number the citations not the sources, so the references would either have lots of duplicates (a waste of space, potentially confusing and potentially making it seem like the sourcing is exagerated), or there would be several numbers for some sources, eg.

1. 17. Brown (2000)
3. 6. Schmidt (2003)
4. 7. 14. 15. Smith (2008)
5. Jones (1998)
8. 9. 10. 12. 13. White (2010)
11. Brown (2009)
16. 21. Jackson (2012)

Which is bad and horrible in several ways.

I originally posted the above (minus the TLDR) at help talk:Footnotes#Multiple references to the same source where it was noted that a change from [6] to [6a] or [6(a)] would require developer action following a request at bugzilla. There is no point making a request there until there is consensus here for a change, particularly one of this magnitude. Even if it weren't it's such a significant reader-facing change that it needs to be done right first time. So I'm starting this discussion here to determine what the reaction is to the proposal, what suggestions people have for the format (I'm certain that there must be alternatives other than those I note above), etc. Once there is stability about what people like and don't like, then I guess a prominently advertised RfC followed by a bugzilla request, and then wait for an unknowable amount of time for implementation.

I will link to this discussion from various pages related to citing sources, footnotes and accessibility/usability issues, but more links will be good! Thryduulf (talk) 00:29, 16 June 2013 (UTC)

I use the browser's back feature by clicking its back icon, or pressing Backspace or Alt+←. PrimeHunter (talk) 00:41, 16 June 2013 (UTC)
That's useful as a workaround, but the link issue should still be fixed. Thryduulf (talk) 01:00, 16 June 2013 (UTC)
I think you need to explain why the back button is not a full and complete solution. Dmcq (talk) 08:09, 16 June 2013 (UTC)
Because it's not at all obvious (I didn't know about it for example, and I'm an above average user) and isn't guaranteed to work on all platforms. If the back button was a full solution there would be no point in providing back links at all. Thryduulf (talk) 08:18, 16 June 2013 (UTC)
I'm sorry about that but it is a pretty standard fixture on the major browsers. By not always working I think you're probably referring to some applications where if you press the button something happens like buying a chair, yes pressing the browsers back button then can cause problems because you can't take back an order that way and a transaction environment would have been set up. The back button they provide will take you to before then to something like looking at a picture of a chair instead. However in Wikipedia the only tranasctions of that sort we have are when you press the save page button when editing. Dmcq (talk) 08:34, 16 June 2013 (UTC)
That's not what I'm on about at all. Hardly a major browser these days, but the version of IE on my old phone would take you back to the previous page rather than the previous point in the same page. We should also not just be catering for only the technically literate - if it wasn't obvious to me then it's not going to be obvious to a whole swathe of users less technically adept than I am. I'm sorry, but I don't regard the back button being available as a reason why this problem does not need to be fixed. Thryduulf (talk) 09:25, 16 June 2013 (UTC)
Remembering the letter is something that you have to do here and could be confusing in the text. May be you could highlight the letter in the reference section that you arrived at the particular reference from at the same time as you highlight the reference entry in blue. Keith D (talk) 13:28, 16 June 2013 (UTC)
The blue highlighting is achieved with the target pseudo-class :target - the CSS is 
ol.references li:target, sup.reference:target, span.citation:target { background-color: #ddeeff; }
which works for the whole entry in the list. To give one letter some styling in addition to the blue for the whole entry cannot be done with CSS alone, and I'm not enough of a Javascript coder to know whether it's feasible. --Redrose64 (talk) 15:29, 16 June 2013 (UTC)
If feasible (I have no idea) then the highlighting would be good for those who have the bowser support (wider for css than js AIUI). For accessibility reasons we shouldn't rely on something working only with javascript if possible, although I do take the point about the letter potentially being confusing. Would a number ([6.1] etc) be better than a letter? I'm not sure there is a way around the remembering the letter (or whatever) number though. Thryduulf (talk) 17:22, 16 June 2013 (UTC)
(edit conflict) For "one letter", read "a substring of the list entry" - it doesn't matter whether it's a letter, number or some other characters. The problem is two-fold, and unrelated.
  • When you follow links from the article text to the refs section, and you have a superscripted ref link in the article text that occurs more than once, say the [1] which occurs three times in NBR 224 and 420 Classes (once in the infobox, twice in the "History" section), each of those links is identical, so the target has no knowledge of where it came from. Therefore, as things stand, it's not possible to have highlighting like
  1. ^ a b c Ahrons 1987, p. 195.
assuming that you had clicked the second [1] in that article, because the links from the first and third are identical.
  • The Cite extension of MediaWiki does not have the means for adding distinguishing marks to the [1] which it presently generates via the system message MediaWiki:Cite reference link. The extension would need to be amended so that the third of the three values presently passed into that system message is not a simple number but one of the other methods which you suggest. In other words, it's not that [6a] or [6(a)] are difficult so [6.1] must somehow be "better", but that they're all equally difficult to do.
--Redrose64 (talk) 22:07, 16 June 2013 (UTC)
I understand now the technical issues, thanks. My comment about [6.1] being maybe better than [6a] was related to Keith D's comment "Remembering the letter is something that you have to do here and could be confusing in the text". I understood that to mean that a suffix letter may be confusing for humans reading the article when it appears in the middle of a section of prose (e.g. source 19 at British National Corpus#Classification errors and misleading titles#Classification errors and misleading titles) - i.e. the letter may get mistaken for lexical information.[6.1] vs [6a] vs [6(a)] may be equally easy or difficult for the software, but they aren't necessarily for humans. I don't actually know if this is what Keith meant or whether a reference suffix letter would be an issue, but it is something we should think about before asking for a specific format. Thryduulf (talk) 00:47, 17 June 2013 (UTC)
My comment was related to the fact that normally you take no notice of the actual detail in the brackets, just use it to click on to get to the relevant reference. You have to consciously make a note of the letter in this case to go back. On the further point raised it could be confused as some sort of technical thing such as a page number or item in the reference. Keith D (talk) 08:37, 17 June 2013 (UTC)
I expect it doesn't help at all in Thryduulf's situation, but Preferences, Gadgets, Browsing, Reference Tooltips may avoid you having to go down to the reference list in the first place. Thincat (talk) 21:53, 16 June 2013 (UTC)
MediaWiki:Cite reference link formats the in-text link. The backlink characters are set by MediaWiki:Cite references link many format and the default is ^ 1.0 1.1 1.2 etc. This was changed in 2006 to match the {{ref}} template. The actual labels are defined at MediaWiki:Cite references link many format backlink labels and allow for 1065 backlinks. --  Gadget850 talk 09:16, 17 June 2013 (UTC)
The basis of this discussion is incorrect. The problem is not multiple uses of a source, but multiple uses of a "named ref" (i.e., "<ref name= ...>"). There is much to be said for using short cites in the text to link to a single full citation of a source. ~ J. Johnson (JJ) (talk) 21:06, 17 June 2013 (UTC)
  • Updated the help-page for backspace/Back key: I have updated the help-page, Help:Footnotes, to remind users that the backspace or Back-key can be used (in IE or Firefox browsers) to return to the "footnote marker" superscript "[1]" after seeing the footnote text. For many users, that will work. -Wikid77 01:55, 18 June 2013 (UTC)
For what users does the "back" button not suffice? Should we be fixing what is possibly a browser deficiency? ~ J. Johnson (JJ) (talk) 22:35, 21 June 2013 (UTC)
i do not think there is a single browser for which the back button will not do exactly what you expect it to do. קיפודנחש (aka kipod) (talk) 00:09, 22 June 2013 (UTC)
I noted above that my old phone browser did not work that way (it went back to the previous page, not the previous point of the current page). In any case it is not that backspace is doing something people don't expect it to do (although many people will not be expecting it do anything), it's that not everybody expects to use the backspace to return to the previous point. Almost everyone will have arrived at the references by click on the link with the mouse or other pointing device. There are links there that allow them to return to where they were using the exact same pointing device - why should we force them to either guess which link they need or let go of the pointing device to press the backspace key (bad ergonomic design)?
Yes, the backspace works but the existing links are still broken and still need fixing. Thryduulf (talk) 22:44, 22 June 2013 (UTC)
The browser's back button is supposed to go back to the previous URL, no matter if that URL points to a different page or not. I doubt there's any browser where that button can't be operated by the same pointing device that's used for following links. Keyboard shortcuts or even dedicated physical keys are only additional ways to call the same function.
It's the browser that knows the previous URL, not the Wiki software and usually not the user, so the natural way to go back is to use a browser function, not a wikilink and not something requiring the user to remember some code. Emulating an existing browser function in the wiki software or in the user's head seems like overkill to me. The former (a 'back' link next to the reference) would require massive software changes and additional page reloads and the latter (additional labels in the reference tags) would disrupt the reading experience for all users. I don't think that's justified. — HHHIPPO 10:58, 23 June 2013 (UTC)
You appear to misunderstand slightly, there is no need for additional links, more page reloads or anything of the sort. The only change needed is to the labelling of the links which already exist. Thryduulf (talk) 12:50, 23 June 2013 (UTC)
I got that. I'm talking about three possible ways to get back, implemented in the wiki engine, the browser, or the user. Leaving the back function to the browser is what we do now, improving the way the user can do it manually is what you suggest. If that change is needed is what we're discussing here, since there are both advantages and disadvantages to it. In my opinion the disadvantages outweigh the advantages. — HHHIPPO 13:44, 23 June 2013 (UTC)
I'm sorry to be so blunt, but the browser's back button is a completely obvious solution to this "problem". If someone is actually using a browser that is so broken that the back button does not work properly, they should probably find a new browser. That's not Wikipedia's problem. NinjaRobotPirate (talk) 12:00, 23 June 2013 (UTC)
The problem is not with the back button, as I keep saying. There are two ways of navigating back to where you were - one is to use the back button/backspace key which works fine on most systems and isn't a problem. The other is to use the links that exist explicitly for this purpose - these work fine when a source is used only once but if they are used more than once it requires you to guess which link to use. It is this requirement to guess that is the problem which needs fixing. If the back button did the entire job then there would be no point in having the links. Thryduulf (talk) 12:50, 23 June 2013 (UTC)
The back button is our current solution to going back, so if that's not a problem then there's no need to fix anything. The links aren't there only for the purpose of emulating a back button. They allow to see easily which statements are supported by (or dependent on) a given reference, no matter how you arrived at that reference. There's a number of use cases for that, and it's particularly handy for sources that are cited more than once. Reading from start to end is not the only thing you can do with an article, there's also writing it and improving it ;-) — HHHIPPO 13:44, 23 June 2013 (UTC)
Exactly what I was going to say. The links are there for multiple uses, not explicitly as a replacement for your browser's back button, and they would not be removed in any case. Nobody needs to guess anything; they can just use their back button. The back button does do the entire job. If it doesn't, then it's not a back button, and your software is faulty. I support catering to obsolete and low-end systems, but I do not support catering to faulty software. That's a problem between you and your vendor, not you and Wikipedia. However, if we do implement this feature, I think a better solution would be to bold the link that will take you back, such as 15. ^a b c d e. That way, it doesn't add any other superfluous characters. NinjaRobotPirate (talk) 15:02, 23 June 2013 (UTC) edit: Which seems to have been already suggested. Oops. I must have missed that somehow. NinjaRobotPirate (talk) 15:05, 23 June 2013 (UTC)
Yes, highlighting or bolding would likely be the optimum solution but it isn't presently possible. I suggested suffixes simply because I hadn't thought of bolding when I identified the issue. Thryduulf (talk) 07:50, 26 June 2013 (UTC)

End-of-section blank lines would reduce edit-conflicts

When I was testing edit-conflicts between 2 usernames editing adjacent lines, I confirmed that a blank line will stop edit-conflicts between edits above/below the blank line. Edits to adjacent lines often cause edit-conflicts. Eventually, I realized how an automatic blank line, if appended at end-of-section edits, could stop many edit-conflicts between people who reply after blank lines versus those replying above blank lines, and also avoid edit-conflicts with section=new (because the new "==Topic==" would be separated by the blank line above it). The section '=Header=' lines will format with the same spacing, whether followed by a blank line or not. However, I think the MediaWiki software has been deleting those bottom blank lines which would have avoided many, many recent edit-conflicts. Can anyone think of any trouble which might be caused if the MediaWiki software were to be changed to always leave/insert one blank line at the end of a section-edit (or page)? -Wikid77 05:25, 23 June 2013 (UTC)

When creating this section, you copied one line from the previous thread - the <!-- EdwardsBot 0505 -->. Anyway, the MediaWiki software already does what you ask for: when you edit a section mid-page, any whitespace at the end of the section is stripped and a single newline added to the edit window. When you save a section mid-page, any whitespace at the end of the edit window is stripped and a pair of newlines are inserted between the edited text and the next section heading. --Redrose64 (talk) 08:53, 23 June 2013 (UTC)
So, I see now that the auto-inserted bottom blank line is omitted (in the edit-buffer) when re-editing a section, but saved in the page at end-of-section. Hence, the tactic would be, when in fear of edit-conflict replies, then place a blank line above the reply (2 newlines) and that reply would be treated as below the section's auto-inserted bottom blank line, where any other erstwhile replies would be herded above the auto-omitted bottom blank line. So, at least we know, now, to avoid edit-conflicts in busy threads: put a blank line above the new bottom reply. -Wikid77 14:54, 23 June 2013 (UTC)
Please don't put blank lines within threads. Talk page threads indented using colons (such as this one) yields a dl structure (aka 'definition list' or 'association list'), and a blank line terminates one such structure and starts another, which is undesirable. This is covered at WP:LISTGAP. --Redrose64 (talk) 15:30, 23 June 2013 (UTC)
Wikid77, if you're asking for more blank lines to be added to sections than MediaWiki already adds, this would cause a larger gap between sections. I don't think avoiding edit conflicts is a good justification for changing the appearance of pages. – PartTimeGnome (talk | contribs) 14:26, 23 June 2013 (UTC)
Just recommending to add one blank line (2 newlines) at end of page when creating/editing a page, because as Redrose64 already noted above, the MediaWiki software already auto-inserts a blank line at the bottom of section-edits (but auto-omits it during re-edit). With an auto-inserted blank line at end-of-page then conflicts with section=new would likely become very rare instead of commonplace. Meanwhile to avoid edit-conflicts in non-bottom threads, prepend the new bottom reply with a blank line. -Wikid77 14:54, 23 June 2013 (UTC)
After a few embarrassing situations where I posted exactly the same reply as someone else, I learnt not to put any blank lines in front of my replies (i.e. I want an edit conflict in that case). Also, where ::: or *** are used for indentation or bulleted replies, a blank line causes MediaWiki to end the indent/list and start a new one (i.e. "</dl><dl>" or "</ul><ul>" in the HTML). This causes problems with accessibility. With numbered replies, it also causes the numbering to reset to 1. – PartTimeGnome (talk | contribs) 15:13, 23 June 2013 (UTC)
You can't add one blank line (2 newlines) at end of page when creating/editing a page, because no matter how many you try to add, the last section on a page will be saved with exactly one newline and no trailing space. --Redrose64 (talk) 15:36, 23 June 2013 (UTC)
MOS:HEAD (version of 17:11, 22 June 2013) says: "Include one blank line above the heading, and optionally one blank line below it, for readability in the edit window."
—Wavelength (talk) 14:42, 23 June 2013 (UTC)
  • Avoiding edit-conflicts in non-bottom threads: Consider prepending a blank above the new bottom reply to the thread, unless "Show-changes" reveals another editor has already put a blank line, so then put the bottom reply immediately but with blank line afterward (not before). I guess the issue is to upgrade the MediaWiki software to auto-insert a blank line at end-of-page, just as it does when editing any non-bottom section of the page. However, perhaps when reformatting the page then suppress the display of the bottom blank line, as typical in word-processing softare. -Wikid77 (talk) 15:46, 23 June 2013 (UTC)
No, don't. It's already been explained why not. --Redrose64 (talk) 15:59, 23 June 2013 (UTC)
I was just noting how to avoid edit-conflicts for people who have limited time to edit pages, but not force people to save changes quickly, if they would rather re-edit every time another person modifies a page. -Wikid77 (talk) 00:58, 27 June 2013 (UTC)

essay nutshell collector would help

For an essay finding aid, could the Wikipedia:Essays in a nutshell page and subpages, which require manual entry, be replaced by automation that collects the nutshells? I think essayists often omit this manual step and some may not know about it, especially any who write only one essay; and updates may get missed. This makes it harder to find out if an essay has already been written on a proposed theme. The Category:Essays including subcategories has 698 entries as of a few minutes ago but WP:essays_in_a_nutshell including subpages as of yesterday had only 245 entries. Nearly two thirds seem to be missing

A nice solution would be to run a collection bot once monthly across all essays in the Wikipedia namespace, find the first Nutshell or nutshell template in each (there should be only one anyway), and copy some of the parameters' values into one list (sacrificing the present effort to divide the list topically), sorted by the Defaultsort value (if no Defaultsort template is present, then sorted by the essay title). Then a user could use their browser's search function to find any keywords they wish.

Nick Levinson (talk) 20:43, 23 June 2013 (UTC) (Clarified a destination: 20:48, 23 June 2013 (UTC))

  • The nutshell essay omits most pages, instead see WP:ESSAYSEARCH: The page mainly intended to help find other essays is wp:ESSAYSEARCH, which has noted 800 essay pages in the list, but needs more high-level phrases to describe many of the major essays. However, long-term, we need to improve the "associative retrieval" (or googling by wikisearch, Search [_________] ) to search for essays related to a set of words. The tactic is to have a unique idword (or idphrase), such as "essaypage", inside each essay page so that only those pages would match a wikisearch of "WP:" project pages (namespace: "&ns4=1") with search-word "essaypage", without the need to create an "essay namespace" to limit searches to matching only essays. Perhaps search with the essay phrase "Wikipedia essay" plus the specific words contained in various essays. -Wikid77 (talk) 10:00, 24 June 2013 (UTC)
That sounds too complicated for most users to remember, it's unlikely a controlled vocabulary would be applied with much consistency (consider the problem we now have with undercategorizing, failing to categorize, and miscategorizing articles and people have more practice with that when essayists probably write very few essays each), and Wikipedia:About essay searching does not normally appear on a search results page, so searchers will not usually find the advice. Nick Levinson (talk) 15:26, 24 June 2013 (UTC)
Rather than remember to include "essaypage" and namespace "&ns4=1" in a wikisearch, I am thinking there would be a search-link, and then the user could modify the search-words, after the first search. -Wikid77 (talk) 00:58, 27 June 2013 (UTC)
It's great that there are a number of ways to search through essays. I do hope that that's done primarily by experienced editors - for example, in deciding whether to write a new essay - because for most people, it's better to use the Editor's Index to Wikipedia. That index has, in addition to hundreds of essays, help pages and how-to pages and guidelines and policies and WikiProjects and lots of other entries, nicely organized by topic. (Full disclosure: I built most of it.) -- John Broughton (♫♫) 03:03, 26 June 2013 (UTC)
Same problem. A user has to know it exists. I didn't and I've been editing for years. It's useful, but, in this context, unless it shows up in search results, it's unlikely to be seen. And not all essays are in it, not even ones that are in the {{Wikipedia essays}} template. So editors still would benefit greatly from automation copying nutshells into one place, and, besides that, you might want to propose that the Wikipedia:Editor's index to Wikipedia be complemented by automation for discovering new items to be considered for adding to the index (considered, since the index's design requires thoughtful editing asnd not merely copying). Nick Levinson (talk) 15:35, 26 June 2013 (UTC)

Pool queue is full

In the last 20 hours or so some of my searches have been returning "An error has occurred while searching: Pool queue is full". For example, it happens when I search the Village Pump archives for "pool queue". Using Firefox. Nurg (talk) 06:36, 24 June 2013 (UTC)

Yep, the same just happened to me, "An error has occurred while searching: Pool queue is full", which wsa rather annoying as it was an attempt to create a new page by adding the title in the search box... Also Firefox, for what it's worth. Fram (talk) 06:48, 24 June 2013 (UTC)
Generally this would mean that the search server is overloaded (Pool queue is a queue of people wanting to do something, to prevent too many people from doing it at the same time). Is this still happening? How often does it happen? Bawolff (talk) 22:33, 24 June 2013 (UTC)
I've just received the error message twice in succession. I've not seen it before, but this may be the first time today I hit a title that didn't exist. Thryduulf (talk) 22:39, 24 June 2013 (UTC)
It is still doing it today, quite regularly - I hadn't seen this until 23 June - is this a new "feature"? or the unwanted side effect of some other change? - It certainly slows us WP:WikiGnomes down. - Arjayay (talk) 09:20, 25 June 2013 (UTC)
I first saw this yesterday and now it's happening all the time... Carlossuarez46 (talk) 18:30, 25 June 2013 (UTC)
I've had to suspend spelling corrections etc. which rely on the search facility - my last 25 search attempts have all been met with the "pool queue is full" message. Why has this problem suddenly appeared? and when will it be dealt with? - Arjayay (talk) 18:36, 25 June 2013 (UTC)
I just had it happen to me, not for the first time. It's happened a couple of others times in the last 24 hours. — Maile (talk) 23:09, 25 June 2013 (UTC)
Hi all, this issue should be addressed now. Please do report this issue again if you experience any new symptoms. Thanks! Greg (WMF) (talk) 16:09, 26 June 2013 (UTC)

Green bullets in watchlists

IIRC someone brought this up at the original discussion of the move to green bullets for pages that have changed since the last visit: "Would it be possible to use 2D bullets instead of 3D bullets so that they match the blue bullets?"

The response was something along the lines of "No. We don't have those."

Is it really that hard to come up with a green circle, for consistency's sake? After all, we seem to have managed a blue circle.  — TORTOISEWRATH 18:13, 24 June 2013 (UTC)

On my screen the bullets are small and I can barely tell what colour they are, and anyway the links I haven't visited are bold, and I know that there are a lot of other projects that need work more urgently. —Anne Delong (talk) 18:47, 24 June 2013 (UTC)
Well, this actually sounds like a bad excuse to me. Anyway I'm happily contributing the needed graphics:
Hope they will be used since I don't like the 3D-look either (just didn't care enough about it yet to complain ). --Patrick87 (talk) 19:11, 24 June 2013 (UTC)
Patrick was quicker than me ;) Another way to do it, add:
Extended content
li.mw-changeslist-line-watched, li.mw-history-line-updated {
    list-style-image: url('data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUAAAANAQMAAABb8jbLAAAABlBMVEUAAAAA4AD7GUojAAAAAXRSTlMAQObYZgAAAAFiS0dEAIgFHUgAAAAJcEhZcwAACxMAAAsTAQCanBgAAAAHdElNRQfdBhgSKCF2D+ZrAAAAE0lEQVQI12NgQAEFDD/AsICBAQAakgPJO2sGpQAAAABJRU5ErkJggg==');
}
To your vector.css. jonkerz ♠talk 19:17, 24 June 2013 (UTC)
(edit conflict) Depending on your skin, you should put 
li.mw-changeslist-line-watched, li.mw-history-line-updated { list-style-image: url("//upload.wikimedia.org/wikipedia/commons/c/ce/ChangedBulletMono2.png"); }
(bright version) or 
li.mw-changeslist-line-watched, li.mw-history-line-updated { list-style-image: url("//upload.wikimedia.org/wikipedia/commons/3/3a/ChangedBulletMono2_darker.png"); }
(darker version) into Special:MyPage/monobook.css, or 
li.mw-changeslist-line-watched, li.mw-history-line-updated { list-style-image: url("//upload.wikimedia.org/wikipedia/commons/c/cd/ChangedBulletVector2.png"); }
(bright version) or 
li.mw-changeslist-line-watched, li.mw-history-line-updated { list-style-image: url("//upload.wikimedia.org/wikipedia/commons/3/34/ChangedBulletVector2_darker.png"); }
(darker version) into Special:MyPage/vector.css. Those will give a flat (2d) green bullet instead of a "shiny" 3d green bullet. --Redrose64 (talk) 19:21, 24 June 2013 (UTC) updated Redrose64 (talk) 07:41, 26 June 2013 (UTC)

Yes, so please update the links in MediaWiki:Vector.css and MediaWiki:Monobook.css respectively. That's were we actually need it, not in our user CSS. And that's why I made those graphics. --Patrick87 (talk) 19:27, 24 June 2013 (UTC)

The new bullets fail WP:CONTRAST (and I don't like them). If soneone can't see the original green bullets, these new ones are even harder to see. The point of the green bullets is that they are different then the default bullets, and not be too in-your-face. — Edokter (talk) — 20:28, 24 June 2013 (UTC)
Well, that's why we can't get rid of the "Changed since you last visit" text after all. Every reasonably sized and styled button fails WP:CONTRAST. Carrying this information in only a tiny little bullet is just not possible considering accessibility.
However my proposal reproduces the exact style of the default bullets for those who can see the color difference, therefore providing a consistent UI (which your icons lack). I think anybody that is not able to distinct between the current green and blue bullets won't be able to distinct between my proposal and the blue bullets either (and vice versa!). It just doesn't matter for them! Those who actually can see the difference will wonder why there is an inconsistent style applied to those buttons however. The current bullet just doesn't match the style of the rest of the page. --Patrick87 (talk) 20:43, 24 June 2013 (UTC)
bikeshed or not, I too would prefer a darker green if we would change from 3d to flat. —TheDJ (talk • contribs) 20:15, 25 June 2013 (UTC)
I tried a darker green (I added the links to the bullets above) but I think while it looks good in principle and fits the color scheme it gets really hard to notice the difference (see screenshots below). --Patrick87 (talk) 00:04, 26 June 2013 (UTC)
For those who wish to try the darker version, but are unsure of the CSS (simply altering ChangedBulletVector2.png to ChangedBulletVector2_darker.png won't work), I've added to my post of 19:21, 24 June 2013. --Redrose64 (talk) 07:41, 26 June 2013 (UTC)

The are two apposite gadgets under the "Watchlist" section. --Ricordisamoa 21:07, 24 June 2013 (UTC)

There has been much heated debate on this page over a long period about this feature, which is why I deliberately didn't alter MediaWiki:Vector.css and MediaWiki:Monobook.css but instead suggested that those who wished to should put the change into personal CSS. It may well violate WP:CONTRAST: but when something is opt-in, it doesn't affect those who don't want it. --Redrose64 (talk) 21:33, 24 June 2013 (UTC)
Yes, and I deliberately changed the bullets to be less intrusive and better meld into the page so this much heated debate (that is still boiling below the surface) is cooled down a bit further. As the colored bullets are not opt-in they should look as if they belonged were they are (and bullets that were intentionally designed to look differently than the default ones, with a 3d look that is uncommon for Wikipedia, blatantly fail this task). I hope this is not a "Don't mess with The Doctor" decision and Edokter actually realizes that I want to aid the acceptance of his contribution with the changed icons. --Patrick87 (talk) 22:22, 24 June 2013 (UTC)

bikeshed —TheDJ (talk • contribs) 07:50, 25 June 2013 (UTC)

Screenshots of green bullets in watchlists

Just that everybody knows what we are actually talking about and to allow for a direct visual comparison here are three screenshots of my watchlist (they are using Edokter's current 3d-style bullet, my flat proposal to match the default bullet's style and a darker version of my proposal as suggested by TheDJ which looks quite well but is actually getting hard to notice):

Maybe we should use a different color. Just putting that out there. Red, perhaps? Orange (complement of the blue)?  — TORTOISEWRATH 17:14, 26 June 2013 (UTC)
Thought about that, too. But red doesn't fit into the current color scheme, neither does the complementary color. Accessibility and design do not always go hand in hand . --Patrick87 (talk) 17:53, 26 June 2013 (UTC)
If they're not part of the default setup, but only set via personal CSS, they can be any colour you like, and neither aesthetics nor accessibility will apply. All that's needed is for a file to be created in the desired colour and an appropriate shape - round (for Vector), square (for Monobook and Modern), or round and hollow (for Cologne Blue). --Redrose64 (talk) 18:46, 26 June 2013 (UTC)
There are sooo many ways to have different bullets; color, shape, luminance... you name it. I just went the practical way. I choose green, becuase that color is ususally associated with change (as does the "changed since you last visit" message). Also, I didn't go for "3D", but for a "lit-up" appearance. But it any case... It's a bullet. As theDJ pointed out... why are we discussing the color of the bikeshed's doorknob? — Edokter (talk) — 19:34, 26 June 2013 (UTC)
Because we all come by bike and use it every day . The simplest things are not always the easiest to do after all. User interface changes have to be done with great care or they'll jump into your face.
Personally I wanted to improve Wikipedia with better suiting bullets (why spoil everybody's day already in the morning with an unpleasant doorknob at the bikeshed?). But if you're blocking my improvement there's not much I can do anyway. I had hoped for your insight but it seems you keep using your admin rights to style Wikipedia to your likes instead of lowering your sights, thinking globally and changing it to achieve the best result for the community.
I don't care anymore personally (as you say: its just bullets but I initially thought this would be an uncontroversial and welcomed change). Do what you deem right. I put the bullets I like best into my user CSS. I won't further benefit from a change anyway but the community will! --Patrick87 (talk) 20:02, 26 June 2013 (UTC)

Citation templates not working (Part 2)

I sometimes feel that I don't know exactly what I am talking about when I come here: must use correct jargon so as not to appear as if I don't qualify for the technical level ツ. So I'll just link to this prior discussion: https://wiki.riteme.site/wiki/Wikipedia:Village_pump_(technical)/Archive_111#Editing_Bar:_Citation_Templates_not_working I normally use what is shown in the second screenshot; in which I can click on 'cite' and the template choices drop down, but when I click to choose web (or any), there is a lurch and the box closes. So I switched to the bar in screenshot one. I can get every other icon on the panel to work but when I click 'cite' I get nothing. It is dead... I know how to copy and paste a blank template and fill it in, but I am working my way through Rose Selfridge's references and it took what seemed to be 1/2 hour to repair one. I am operating Windows 7 with IE10, cleared my cache...thanks muchly, Fylbecatulous talk 12:45, 25 June 2013 (UTC)

Perhaps you have compatibility view enabled in IE. There are some tips on controlling compatibility view here. —TheDJ (talk • contribs) 13:07, 25 June 2013 (UTC)
No, sorry. I should have mentioned that. I don't use compatability view. Fylbecatulous talk 13:34, 25 June 2013 (UTC)
This was working until quite recently, and as far as I know I have tinkered with nothing. I did make an edit on June 22: [42] to Keith Moon in which I copied and pasted a template for 'video' because that choice is not in the dropdown box. Could I have possibly sent it to its demise then? Fylbecatulous talk 14:03, 25 June 2013 (UTC)
This will require analyses by a community person (because it is a community tool) with technical knowledge and Internet Explorer. Unfortunately we hardly have any volunteers who have or want to work with explorer, so that constrains my ability to provide you with a solution. Aka, who has IE and wants to help Fylbecatulous ??? —TheDJ (talk • contribs) 18:25, 25 June 2013 (UTC)
In the meantime, I have discovered this feature still works for me on Simple English Wiki (and boy have I perused my settings there to see what might be different - no clue that anything is), so for now, I will just tab over to Simple to create my citations and then copy and paste to my chosen article here. (Desperate times call for desperate measures....) I have even read the page on Wikipedia:RefToolbar to assure myself that my settings are correct. They are, just non-functioning...thanks Fylbecatulous talk 20:49, 25 June 2013 (UTC)
Well, and as an aside, I got booted up to technical level three support with an unnamed large internet provider because there was a glitch in my website whilst paying my bill online (because I, in frustration, told a poor call service agent I was smarter than she and give me someone who knew what they were talking about...) This tech person said they no longer support IE actually. I suppose I am going to need to download another browser. Especially if I am amongst the last remaining holdouts on Wiki...what should I choose? Fylbecatulous talk 20:59, 25 June 2013 (UTC)
There are plenty available, and there is nothing to stop you installing several, and trying out each one. Personally, I use Mozilla Firefox, but I have three other Windows browsers installed: Google Chrome; Opera; and Safari. --Redrose64 (talk) 21:43, 25 June 2013 (UTC)
Thank you, Redrose. When I get home today, I shall experiment. Surely one will be fine. I will just drop this happenstance as a quirk for now, especially since I can still use the template on Simple Wikipedia. A mystery? I promise that the next time I report an incident, it will at least be in a different browser. Happy editing! Fylbecatulous talk 10:49, 26 June 2013 (UTC)

Fix the Toolserver

I'm coming here once again to tell you guys that I STILL can't get the Toolserver to load on my network (yes, I've tried another browser/computer). Labs may be stabler than the TS, but I just looked at it's latest policy revamp and it seems pretty sketchy to me. --Nathan2055talk - contribs 20:47, 25 June 2013 (UTC)

Err, what policy revamp? The only thing that is in the queue at the moment is to tweak the TOS so that the normal Wikimedia-wide privacy policy can apply to Tool Labs, and that hasn't gone to the presses yet that I know of. — MPelletier (WMF) (talk) 21:10, 25 June 2013 (UTC)
If there are specific parts of Labs' policy you have issues with, please let us know. Saying it is sketchy without any details of what the "sketch" is doesn't help us resolve the issues. We intend for our policies to be relatively open, so we'd love to discuss.--Ryan lane (talk) 21:47, 25 June 2013 (UTC)
https://meta.wikimedia.org/wiki/Toolserver#Contact and https://wiki.toolserver.org/view/Main_Page might be good places for the toolserver part of your comment. --AKlapper (WMF) (talk) 09:13, 26 June 2013 (UTC)

All articles

Hi. Any chance somebody could create me a User:Dr. Blofeld/Articles created. I want a list of all articles I've created so I can expand a few from time to time. Obviously the list would have to go on multiple page but I'd like a data dump of articles in order since June 2006.♦ Dr. ☠ Blofeld 15:45, 26 June 2013 (UTC)

@Dr. Blofeld: See the box at the bottom of Special:Contributions/Dr._Blofeld, and the "Articles created" link near the middle. :) –Quiddity (talk) 16:21, 26 June 2013 (UTC)
Hehe, I'm well aware of that of course, and I can never get it to load. SOmebody said it took 36 minutes or something. I need some sort of automated tool to copy and paste a list.♦ Dr. ☠ Blofeld 16:22, 26 June 2013 (UTC)
I'm that "somebody", but as I recall, it took longer: something like 45 mins before I killed the query and restarted it. I posted details, but I can't remember whose talk page this was on though. For those not aware, Dr. Blofeld is one of the most prolific article creators, with several thousand per month --Redrose64 (talk) 18:12, 26 June 2013 (UTC)

Not for a few years, more like 10 a month now, but yeah 2006-2010 was rather extreme I agree!♦ Dr. ☠ Blofeld 20:12, 26 June 2013 (UTC)

  • Perhaps scan categories instead, as Articles-created are reverse order: It might be much easier to just hunt for the articles created in specific older categories, rather than list all thousands of created pages and sift through them. Currently, the default "Articles-created" tool shows the created articles in reverse chronological order:
http://tools.wmflabs.org/xtools/pages/index.php?name=Dr._Blofeld&lang=en&wiki=wikipedia&namespace=0&redirects=noredirects&getall=1
Expect that to run 5 minutes per 40,000 edits, or 1 hour per 480,000. However, to flip the list order, perhaps there would be an option similar to "&dir=prev" but that does not reverse the list. Anyway, it might easier to scan categories of articles created years ago, and then remember the similar article titles of the time. -Wikid77 (talk) 00:58, 27 June 2013 (UTC)

Clicking mouse wheel isn't opening [edit] sections in a new tab

I don't know if this is related to the above question, but I often open section edits in a new tab by clicking on [edit] with my mouse wheel. When I do it now, however, it just opens the section as if I'd left-clicked it. Is there a fix to this? Thanks — Richard BB 15:52, 26 June 2013 (UTC)

Yes, same thing. Matma Rex talk 16:40, 26 June 2013 (UTC)
I'm sure it is related to the above, for which a bug has been filed. —Bruce1eetalk 04:50, 27 June 2013 (UTC)

How easy is it allow something like Google Voice Search for the search box? Apologies if this has been covered before. Thanks. Martinevans123 (talk) 21:34, 26 June 2013 (UTC)

Unified Login Question

I was advised at the Wikipedia Help Desk to ask this question here. I have a unified login. If I am logged in, and click on a link to Meta or Commons, if I look carefully at the upper right corner, it gives me a button to log in, and I am not logged in. If I didn't notice that I wasn't logged in, and edited an article, I would be editing from an IP address beginning with 71. Am I being unreasonable in expecting to stay logged in? (By the way, I am using IE9. I haven't tried with Firefox.) Robert McClenon (talk) 21:56, 23 June 2013 (UTC)

When you log in, a cookie is set, which should be recognised for Wikipedia/Commons/Meta/etc. When I use Firefox, it works as intended. On the (rare) occasions that I need to log in but FF is not available - such as in a public library - I've had problems similar to those that you describe (I don't recall if it was IE8 or IE9), but I'm pretty sure that it's something to do with the browser's settings concerning cookies. --Redrose64 (talk) 22:13, 23 June 2013 (UTC)
Robert McClenon, as Redrose mentions, it is a cookie problem. The answer depends on how tight/loose your privacy settings are. My settings are tight. In my case I don't allow a wikipedia.org site (site you log in) to place a cookie for a (commons|meta).wikimedia.org site as those are two different domains (third-party). So, I have to whitelist some Wikipedia sites to allow cookies regardless of what my privacy settings are. Under IE, goto Internet Options -> Privacy tab -> Sites button. Add wikipedia.org and wikimedia.org as allowed. If you visit any other Wikimedia Foundation domains such as wikidata.org, wikibooks.org or wikivorage.org, you will need to add those sites too. I do the same whitelist option for Firefox and Chrome. Bgwhite (talk) 05:19, 24 June 2013 (UTC)
IE8 does have this problem. I frequently have to re-login to Meta on my work machine, which uses IE8 (work still back in the stone age, we're working on it). Jguy TalkDone 17:02, 27 June 2013 (UTC)

Edits not showing up

I've just saved two edits that didn't take, and haven't shown up in the article history or my contribs. SlimVirgin (talk) 18:52, 24 June 2013 (UTC)

if anything is to come out of this report, i think you should supply some more details. it would help if you list what exactly did you do (e.g., which page were you editing?), whether or not you have the new Visual Editor enabled, and if so, did you use "Edit" or "Edit Source" link, did you press "preview" or "Show Changes" before saving, and did you see the "your edit was saved" message after pressing "Save Page". also, it won't hurt to list which operating system (including version) and which browser (including version) are you using.
peace - קיפודנחש (aka kipod) (talk) 20:35, 24 June 2013 (UTC)
Article info is also welcome. --AKlapper (WMF) (talk) 07:05, 25 June 2013 (UTC)
I'm sorry not to have supplied details when I first reported this, but I assumed others were experiencing the same thing and there would be no need for specifics. It was at Bradley Manning, and I tried to make the edits between 18:43 and 18:53 UTC on 24 June. I saved and was told the edits had been saved. I tried a third time at 18:54 and at that point the edit "took". I referred in that edit summary to "third attempt to save this edit". [43] I didn't have the visual editor enabled, I didn't use preview or show changes, and I did see the "your edit has been saved" message on both occasions. SlimVirgin (talk) 01:16, 26 June 2013 (UTC)
At several points during the last 24 hours I've gotten edit conflicts with myself, which was fairly mysterious. It happened just now with this edit. — Scott • talk 02:24, 26 June 2013 (UTC)
Still happening. (Update: and as of 22:36, 27 June 2013 (UTC).) I'm using the latest Chrome for Windows if that helps. Oh, and when the edit conflict notice appears, the upper version of the text is the version before your changes, even though you've successfully saved them. Pretty confusing if you don't know what's going on. — Scott • talk 13:16, 26 June 2013 (UTC)
Yeah, I've been having some bizarre issues like this, too. Recently, I was in an edit conflict with someone even though we were editing different sections, and after I merged my changes back in, neither of our edits showed up, even after purging the page, though they were still evident in the diffs (but not the source). Very strange.  — TORTOISEWRATH 18:44, 26 June 2013 (UTC)

When will bolding come back onto the watch lists again?

Tracked in Phabricator
Task T51610

Does anybody know how long it will take until the bolding comes back onto the watch lists? It seemed to have been fixed by gerrit:68601 (which I can’t see without JS) 11 days ago, but it hasn’t been fixed yet despite there being MediaWiki updates every week now, so there has been an update since then already. See Wikipedia:Village pump (technical)/Archive 113#Bolding on watchlist has gone away, please give it back. Does anybody know, what’s the problem with that now and how long we have to wait for that fix? It has been more comfortable with the bolding on the watch lists until June 13th. --Geitost 14:26, 25 June 2013 (UTC)

My watchlist is showing the bolding now. —Anne Delong (talk) 16:58, 25 June 2013 (UTC)
You are jusing JavaScript, Geitost is not (as far as I know). That's the difference. The CSS is loaded by JavaScript since a current update, the patch partially reverted that. --Patrick87 (talk) 17:14, 25 June 2013 (UTC)
It works for me too, even with JavaScript disabled, in both Firefox and Chrome. The bolding disappears after disabling the gadget and appears after enabling it (and I'm not using any custom css). jonkerz ♠talk 17:23, 25 June 2013 (UTC)
What you linked to is a submission. The submission has not yet been accepted and merged into the source code. (partly due to me not having the time to do a lot of development over the past 2 weeks). —TheDJ (talk • contribs) 18:19, 25 June 2013 (UTC)
Ok, I thought, if there once is a fix to get merged, then it doesn’t take more than a week that it’s getting live because of the weekly updates. So, with the update today, there will also be no fix then? --Geitost 08:19, 27 June 2013 (UTC)
The changes have just been merged and will go live the next time around, on July 11 (see mw:MediaWiki 1.22/Roadmap). Matma Rex talk 10:03, 27 June 2013 (UTC)
I see, thanks for the info – and for merging (whoever did it) and @TheDJ especially also for fixing. --Geitost 11:16, 27 June 2013 (UTC)

Notifications query

Is there a way for me to get notifications each time someone gives feedback to an article on my watchlist?--Coin945 (talk) 12:32, 27 June 2013 (UTC)

Special:ArticleFeedbackv5Watchlist once used to group feedbacks on watchlisted articles, but now it is just a redirect to Special:ArticleFeedbackv5. Apparently, Incnis Mrsi has notified Okeyes (WMF) about this, a month ago (here).···Vanischenu「m/Talk」 21:17, 27 June 2013 (UTC)

Discussion about spacing between lists (refs/ELs) and navboxes

There seems to be a protracted, site-wide style war between editors who prefer more and those who prefer less vertical space above the first navbox. This mostly involved edit warring by manually adding and removing blank lines and similar devices. Luckily, it seems that a uniform technical solution exists for this issue. Unfortunately, participation in the discussion at WT:MOS has been rather low and took a turn for personalization recently. Perhaps people watching this page have an opinion on how much spacing looks good? If so, please contribute at WT:MOS, for the sake of keeping the discussion in one place. Thanks, Someone not using his real name (talk) 13:44, 27 June 2013 (UTC)

Cite tag & editing issue

Hi. After a break from editing Wikipedia, I came across the following problems while editing on Windows Internet Explorer 8:

  • When attempting to click Cite > Templates > [cite x] on my editing browser (I have the cite tag feature enabled), the desired cite dialog box does not appear, and instead I'm bumped to the top of my browser page. Typically, the named references and error check have their respective logos cut off at the bottom, where the edit window begins. I have tried re-sizing my browser window, to no avail.
  • I also have the edit lede section enabled. However, although the URL indicated by hovering the mouse over [edit] beside the page title indicates "&action=edit&section=0", after clicking it boots me to "&action=edit&section=1"! Correcting the browser URL back to &section=0 solves the problem.

Please fix these problems as they had not appeared previously on my browser, although I am in fact using a new computer system. Thanks. ~AH1 (discuss!) 21:06, 27 June 2013 (UTC)

mw software was updated recently (to 1.22wmf8). after a version update, the first thing you want to try when some scripts give you pain is to do a "deep refresh": from the browser, hit Ctrl+⇧ Shift+Delete, and select "Empty the cache" or "Delete temporary files" or whatever your browser calls it (it's a menu - you probably don't want to delete cookies, or browsing history. you only want to remove the old scripts that may be stuck in the browser's cache). then hit Shift-refresh or Control-refresh (depends on the browser). in 37.73% of the cases, this will cure the issue. if it doesn't, please report again. peace - קיפודנחש (aka kipod) (talk) 23:16, 27 June 2013 (UTC)

Automated way to create lowercase and Lowercase shortcuts? (help to nibble instead of bite)

I've thought for a while now that our "Hey welcome to Wikipedia but you did WP:SOMETHING wrong" approach could be made more welcoming by using more lowercase shortcuts (WP:Something, or wp:something, in this case). Maybe someone knows a way to do this? Is this idea suited for posting at Wikipedia:AutoWikiBrowser/Tasks? Thanks. Biosthmors (talk) 17:17, 23 June 2013 (UTC)

I like the all-caps shortcuts for the policy stuff – it helps identify it as such. I'd guess that most of the people to whom such notes are given do not have the sensitivity to all-caps (i.e. as screaming) that we do, either. —[AlanM1(talk)]— 18:05, 23 June 2013 (UTC)
It's better to write in proper English – that's what piped links are for. Graham87 02:11, 24 June 2013 (UTC)
When dealing with newbies, there is always the chance that they don't recognize what a link is and/or have trouble seeing the only slightly contrasting (from black) blue color of links. Again, the upper-cased abbreviation is a clue that it's something other than just normal text. —[AlanM1(talk)]— 06:19, 29 June 2013 (UTC)

Common editor analyzer

While in the pursuit of sockpuppets, it occurred to me that having a tool similar to Scottywong's Editor Interaction Analyzer that output common editors across articles, would be useful.

Many sockpuppet operators (the children, for example) tend to work in a narrow field of interest. One Costa Rican vandal, for example, loves to butcher articles related to Spongebob Squarepants. Having a tool where I could input a dozen Spongebob-related titles, and that would output a list of IPs and editors common to those articles, might help in revealing other socks.

I'm not a programmer, so I wouldn't know how to get a project like this off the ground, or even if the idea has any merit. It may, after all, be a tool of questionable value. But I thought I'd toss it into the ether, in case any programmers out there were interested, or in case a fellow editor could point me to a more appropriate forum to pitch this idea. (Disclosure: I floated this question by the pump last week, but it was archived, unanswered. I'll drop the issue after this attempt.) Thanks, y'all! Cyphoidbomb (talk) 14:48, 26 June 2013 (UTC)

I too wouldn't know where to start with this, but you may find someone at Wikipedia talk:Tools that could at least point you in the right direction. It doesn't look a heavily watched page, but it's worth a shot! Thryduulf (talk) 13:26, 28 June 2013 (UTC)

CSS/JS issue?

Resolved

I'm on the latest stable version of Chrome, on Win7.

So, every time I click a link on Wikipedia, I get a popup that has an API link which frankly I don't care for. I'm hoping it's just a JS/CSS issue, but for the life of me I can't find which one would do something like that from the comments in them. If anyone could help with that it'd be appreciated :) Charmlet (talk) 03:12, 27 June 2013 (UTC)

Screenshot, please? Matma Rex talk 10:29, 27 June 2013 (UTC)
What is your skin? Does it happen when you are logged out? You have a lot of stuff in User:Charmlet/vector.js. Does it happen if you set a skin other than Vector at Special:Preferences#mw-prefsection-rendering? PrimeHunter (talk) 22:10, 27 June 2013 (UTC)
  • Oh, Charmlet forgot to mention that it cleared itself up. He also had some double script loading between his vector and common which I informed him of and I think he cleaned up. Also, I informed him that some of those scripts are quite old and may experience difficulties in the future. I'm working on condensing some of them, but suggested he eliminate some of the ones he really doesn't need anymore. Technical 13 (talk) 13:32, 28 June 2013 (UTC)

Google Chrome Login for 30 days(not working)

For some reason login with Google chrome is sustaining after closing of the browser (is this a cookie problem?). Steps to reproduce

  • Get to Wikipedia page on google chrome, click login
  • Select remain logged in for 30 days
  • Login successfully
  • Close browser
  • Reopen browser and go to wikipedia page

User is logged out and has to login again

This issue started happening a few days back (around a week probably). Nothing changed on my browser and it works well on IE.  A m i t  ❤  15:01, 27 June 2013 (UTC)

I'm seeing an issue (using Firefox) where logging into the secure servers doesn't log me into the non-secure side. I had to update any bookmark that started with http:// to https:// and that worked. Apparently the secure and non-secure login servers are not talking to each other. Could be related to your issue. (I just noticed that I am not logged in right now. Dang it)...(Ok, now I'm logged into the non-secure side.) --| Uncle Milty | talk | 15:35, 27 June 2013 (UTC)
Er... That's intentional. When you login by HTTPS, you are given a secure login cookie; i.e. it won't be sent over plain HTTP. It is almost as important to secure your login cookie as it to secure your password, since either could be used to impersonate you (though the login cookie can only be used for 30 days). – PartTimeGnome (talk | contribs) 20:04, 27 June 2013 (UTC)
Ah, that makes sense. I guess I need to transition all of my WP bookmarks over to the secure server. Thanks! --| Uncle Milty | talk | 22:07, 27 June 2013 (UTC)
Currently using crome, everything appears to be ok..... you hay just have the http/https issues. Mdann52 (talk) 07:48, 28 June 2013 (UTC)

Pings only sometimes working at the education noticeboard

Is there an explanation or a bug already filed for these types of observations? Thanks. Biosthmors (talk) 17:45, 27 June 2013 (UTC)

Answered in thread. –Quiddity (talk) 02:13, 29 June 2013 (UTC)

No toolbars when editing

I know the site was down for 45 minutes or so. I can edit pages now, but still have no toolbar on any edit page. I have nothing above the edit box and just a long list of symbols below it. But no links, no templates, no menus, nothing, anywhere on the edit pages. So I have no dropdown menu to add a cite, no link to click for my signature, etc... I have to do everything manually. I'm not sure what percentage of other editors are having this problem. Thanks. 76.189.109.155 (talk) 06:51, 28 June 2013 (UTC)

I just tried something and it worked! I cleared my history on my computer (cache, etc.) and that immediately resolved all the problems. Everything's back to normal. :) --76.189.109.155 (talk) 06:58, 28 June 2013 (UTC)
Someone mentioned this in #wikimedia-tech connect a while ago, where the devs said it was probably a side-effect of the rollback to wmf7 (see the above sections). — PinkAmpers&(Je vous invite à me parler) 07:04, 28 June 2013 (UTC)
It's broken again. Clearing my cache, etc. only works for the first Wikipedia edit page I go to, then the same problem returns when I go to the second page. :( I've tested it five times and the exact same thing happens every time. So Wikipedia is putting something on my computer the first time I go to an edit page that's preventing the toolbar and all the other things from appearing on the subsequent edit pages I go to. This is the first time this has ever happened, and started immediately after tonight's site outage. 76.189.109.155 (talk) 07:08, 28 June 2013 (UTC)

The top of this page says bugs should be reported at Bugzilla using the "Report a Bug" option there. You need a registered account to do it, so it would be nice if someone could do that for me (and any other editors having this problem). That will get it on record just in case they're not aware of it. 76.189.109.155 (talk) 07:39, 28 June 2013 (UTC)

I tested again five more times. Same thing happens... when I clear my cache, the first edit page I go to is back to normal (a complete toolbar at the top, and the Insert dropdown menu at the bottom, along with all the linked symbols next to it (– — ° ″ ′ ≈ ≠ ≤ ≥ ± − × ÷ ← → · § Sign your posts on talk pages: ~~~~ Cite your sources: <ref></ref>), but all the edit pages after that remove all of those things. --76.189.109.155 (talk) 07:50, 28 June 2013 (UTC)
  • As above: no editing tools, and none of my scripts are working, and I'm currently logged in. I even have to type out the tildes for my signature. -- Ohc ¡digame!¿que pasa? 08:39, 28 June 2013 (UTC)
    • I always type out tildes for my signature, it's not that much of a hassle, surely? doktorb wordsdeeds 12:50, 28 June 2013 (UTC)
      • LOL. Not a big deal as such, but I just wanted to point out the extent of dysfunctionment across many facets of contributing to WP. -- Ohc ¡digame!¿que pasa? 13:30, 28 June 2013 (UTC)
        • Doktorbuk it is a big deal for users editing from a mobile device that doesn't give them (easy) access to the ~ character. Technical 13 (talk) 15:33, 28 June 2013 (UTC)
          • Doktorb, it's not that much of a hassle to type out four tildes? That's your response? Really? Apparently, you didn't understand the magnitude of the issue. It's not about typing a sig manually, which is among the minor, yet still inconvenient, repurcussions of the problem. When the toolbar and all the other features on the edit page disappear, or when an editor no longer has any editing tools or scripts that work,, it's a big problem. Just ask Wikipedia's IT people. It is the type of problem they always want to know about right away so it can be corrected. Have you ever tried creating citations manually? For the record, I can assure you that relatively few editors manually type their sigs, like you say you do. And as Technical 13 correctly pointed out, it actually is a hassle for editors using a mobile device. So the next time editors come here - to Village Pump technical, where problems like this are supposed to be reported - and say that all their editing features are missing, I hope you'll take it seriously, rather than downplaying their concerns. Having said all that, the problem is now resolved. All of my edit page features are back. --76.189.109.155 (talk) 19:42, 28 June 2013 (UTC)
          • Go to preferences > gadgets > editing and chose "Charinsert". I've had this happen and know other to whom it's happened & that's made it come back. From someone who has never once used the sig thingy & inserts all cites manually - still the toolbar is nice to have. Victoria (talk) 20:19, 28 June 2013 (UTC)
          • I don't have preferences like that because I'm an IP. And, again, manually typing a sig is not the issue. And if you're entering complete/proper cites manually, instead of using the great templates, it's a huge time-waster. You are clearly in the minority if you're doing that. --76.189.109.155 (talk) 21:23, 28 June 2013 (UTC)
            • Sorry, then not much to be done, I suspect. I switched from cite templates to manual b/c it's much faster to write them in, or copy/paste. To each his/her own. I manage to produce some sort of content despite wasting time and being in the minority. Victoria (talk) 21:38, 28 June 2013 (UTC)

Something's badly wrong

Category:Pages with missing references list currently has more than 11000 entries. Something is not right! John of Cromer (talk) mytime= Fri 09:07, wikitime= 08:07, 28 June 2013 (UTC)

It appears to be a software glitch, and the MediaWiki software is currently depopulating that category of all the members that do not belong (~7900 members now). Cheers! Reaper Eternal (talk) 10:35, 28 June 2013 (UTC)
Actually, it's me running the purge, but batch size is limited to 500, so it's taking all morning. Flakey software! John of Cromer (talk) mytime= Fri 12:28, wikitime= 11:28, 28 June 2013 (UTC)

Template:Multiple image not working in several browsers when zoomed

Template:Multiple image is breaking in FF (21.0), MSIE (10.0.9200.16466), Chrome (27.0.1453.110 m) and Safari (5.1.7) when zoomed, but it seems to work in Opera and Netscape Navigator. A sample page where this is not working is Glenn Robinson III. I recently asked for assistance at the Help desk, but they suggested going to the template talk, where I asked at Template_talk:Multiple_image#Zoom_not_working. Some of the browsers had been identified at Template_talk:Multiple_image#Zoom_breaks_Horizontal_layout in 2010. No one seems to be able to figure this out and it has been a problem for 3 years.--TonyTheTiger (T/C/BIO/WP:CHICAGO/WP:FOUR) 02:11, 26 June 2013 (UTC)

Change the "Edit" tab to "Edit source" in all namespaces.

Tracked in Phabricator
Task T52402

I want to propose we change the default wording of the "Edit" tab at page-top, to "Edit source", in order to match wiki-wide the way it currently works in the Main and User namespaces (due to VisualEditor).

This will prevent user-confusion, when the "Edit" button leads to VE in some namespaces, and leads to source-editing in other namespaces.

But I cannot figure out where the text "Edit" is coming from in Vector. Monobook uses Mediawiki:Edit (and I've made the proposal to update that, at MediaWiki talk:Edit#2013 update - change to "Edit source"), but Vector clearly doesn't. I followed some leads, but got nowhere. Halp? –Quiddity (talk) 05:35, 27 June 2013 (UTC)

  • Oppose, and consider "Vedit": This peculiar notion that "Edit source" is editing something different than "Edit" is likely to cause great confusion after a short while, because both the VisualEditor and wikitext editor are editing the source of the page. Instead, name the visual-mode as "Vedit" and people will learn what that word means. Also, find a shorter name for "VisualEditor" such as "Ved" not "VE" or "VD" (although venereal disease might be appropriate warning for new users: "pain in the ___"). Hence, the "Vedit" button would trigger the Ved text editor, with all its limitations, while "Edit" continued to provide the original markup-editor (Medit) to the recent 175,000 active editors each month. There is currently a user-interface petition to protest making the editing of articles about 50x times harder, by pretending that people cannot copy/paste portions of pages into an offline text-editor for faster changes, or cannot copy a similar article with typical infoboxes, footnotes, tables or categories, as the basis of a new or rewritten page. Stop relabelling buttons to derail people's work, or making them fear to learn the simple markup directives. -Wikid77 (talk) 07:51, 27 June 2013 (UTC)
  • I am inclined to support Quiddity's change, as it promotes consistency across all namespaces and eases the transition for all editors. However I worry that it may scare some users from making edits, and also cause inconsistency between wikis. "Vedit" is really nonsensical and means nothing to anyone other than its proposer.

    By the way, Quiddity, you want MediaWiki:vector-view-edit. — This, that and the other (talk) 08:15, 27 June 2013 (UTC)

  • Support something like this. Goes well with "View source" when you can't edit the page - David Gerard (talk) 11:05, 27 June 2013 (UTC)
  • Support - But I want to clarify a couple things. First, Visual editor currently can only edit a couple namespaces but at a point in the future it will be able to edit all or most namespaces. So most people will eventually have it anyway. I don't particularly like "Edit"/"Edit source" terms anyway. Its confusing as to what the difference is so I think we need to change the "Edit" term to something else like "Edit text" or something similar. Kumioko (talk) 11:16, 27 June 2013 (UTC)
  1. In the interim if anybody just wants to do it I created a user script for use User:KumiokoCleanStart/ScriptEdittoEditSource.js. Just add it to your vector.js page. I'll add some better instructions of loading later. Kumioko (talk) 11:40, 27 June 2013 (UTC)
  • Oppose - Concealing the one important feature of Wikipedia – editing pages – behind a label that might only slightly suggest expert knowledge might be needed (editing "source code") is a very bad idea. --Patrick87 (talk) 11:38, 27 June 2013 (UTC)
  • Support something. Oppose "edit source". Something like "edit old" or "edit WikiText" may work better, in addition to making sure the new tab is "VisualEditor" or another thing like that. Charmlet (talk) 14:13, 27 June 2013 (UTC)
  • Support [Wikitext][WYSIWYG] or the like... Technical 13 (talk) 15:05, 27 June 2013 (UTC)
  • Support - we are offering two very different edit interfaces, and there absolutely should be consistency in the labelling of the tabs that lead to them. I am already finding it confusing that "Edit" sometimes gets you VE and sometimes doesn't. I don't see anything wrong with "Edit" and "Edit source", but whatever is chosen should be simple and consistent. JohnCD (talk) 15:14, 27 June 2013 (UTC)
  • (edit conflict) Oppose As Patrick87 pointed out, Edit Source, people think source code, example: HTML markup. <h1><br /><strong> and all that. This could potentially scare people away from editing a page if they think they're editing "source code", as what is suggested with Edit source. Jguy TalkDone 15:22, 27 June 2013 (UTC)
  • Oppose and please get rid of "view source" as well. As stated above the use of "source" is very confusing - it is not the source - and this could cause double confusion when discussing a WP:RS - Arjayay (talk) 15:40, 27 June 2013 (UTC)
  • Support Well, in the old editor they are editing the markup source, as opposed to the new one which hides it. I can't be the only user who spends a lot of time in Talk and Wikipedia space and who is getting mixed up and choosing the wrong option frequently when switching to article space. I am assuming that eventually the visual editor will do everything most people need and they won't use "edit source" much. —Anne Delong (talk) 15:43, 27 June 2013 (UTC)
  • Comment: "Edit wikitext" is more accurate than "Edit source" (and "View source" should be changed to "View wikitext" accordingly) - David Gerard (talk) 21:17, 27 June 2013 (UTC)
  • Support something like this. A tab of a given name ought to take you to the same thing as often as possible. Whether that tab says "Edit source" or "Edit wikitext" or "Old editor" doesn't make any difference to me. (I get almost a million ghits on the quoted phrase "HTML source code". Wikitext is every bit as much source code as HTML is.) WhatamIdoing (talk) 05:15, 29 June 2013 (UTC)
  • Oppose changing "edit" to "edit source". The way Visual Editor and Parsoid work is that Visual Editor passes it´s content over to Parsoid which converts the text into wikitext. Wikicode is the source text. I do understand though that this breaks the habit of some users, which now have to choose "edit source" instead of "edit", but that does not affect my opinion one bit.--Snaevar (talk) 19:33, 29 June 2013 (UTC)
  • Oppose A button that edits the source implies that there is something else that could be edited, if only you could see the button to do it. Anyone who cannot work out that "edit" means edit would not be helped by "edit source"—in fact that would have to be more confusing. It is much better to keep labels short. Johnuniq (talk) 00:30, 30 June 2013 (UTC)

Change "Edit" tab to "Edit source" - Clarification/Proposal

I just realized that I probably "voted" based on wrong assumptions (as others might). The actual problem is, that visual editor adds it's own "edit" tab and renames the current edit tab to "edit source". Therefore the appearance is inconsistent between pages where the Visual editor is active and pages where it is not.

I therefore propose to not change this globally (users not using the visual editor at all don't want to always see "edit source" as the only possibility to edit the page) but to fix it in visual editor. If visual editor is active, it can rename the legacy "edit" tab on every page.

I'd classify this whole issue as a VisualEditor bug, since VE is introducing this inconsistency. We shouldn't fix this by working around the issue by changing well-known translations! --Patrick87 (talk) 16:01, 27 June 2013 (UTC)

Done! I just reported bugzilla:50402. --Patrick87 (talk) 23:17, 28 June 2013 (UTC)
  • Ah. That would make sense. I don't have the VE enabled and don't see the changes right now, so that's probably my reason as well. Thanks for pointing it out Pat! Jguy TalkDone
  • Oppose. The current term "edit" is fine, and causes no confusion. It is clear that you are editing the page, so no need to be technical on whether it is source code/wikitext/whatever. Sjakkalle (Check!) 12:21, 29 June 2013 (UTC)

Fatal exception of type MWException

Tracked in Phabricator
Task T52342

I was getting " Fatal exception of type MWException" a few minutes ago. Any idea what caused it? Ten Pound Hammer • (What did I screw up now?) 05:03, 28 June 2013 (UTC)

All wikimedia sites were down for about 45 minutes. No word on cause yet. --ThaddeusB (talk) 05:08, 28 June 2013 (UTC)
It was probably some techie equivalent of a fly causing the printer to print Tuttle instead of Buttle and things snowballed.--Fuhghettaboutit (talk) 05:18, 28 June 2013 (UTC)
My novice understanding of what the sysadmins are saying is that there were some errors in the most recent Wikidata deployment, which a subsequent deployment caused to come to light. The fix was in the form of Tim reverting to wmf7. — PinkAmpers&(Je vous invite à me parler) 05:16, 28 June 2013 (UTC)
If you are interested in what exactly went wrong with the deployment, you can find some technical background information in https://bugzilla.wikimedia.org/show_bug.cgi?id=50342#c4 --AKlapper (WMF) (talk) 18:33, 29 June 2013 (UTC)

Fatal exception of type MWException and other errors

I've been receiving many of these errors when attempting to view pages. For example, when I tried to post this message I got

[19129209] 2013-06-28 04:43:33: Fatal exception of type MWException

(with different hex codes) many times.

I received:

Internal error

[57123ce3] 2013-06-28 04:35:05: Fatal exception of type MWException

when trying to view my watchlist and received

MediaWiki internal error.

Exception caught inside exception handler.

Set $wgShowExceptionDetails = true; at the bottom of LocalSettings.php to show detailed debugging information.

when trying to view the main page.

—rybec 05:12, 28 June 2013 (UTC)

See above. Legoktm (talk) 05:20, 28 June 2013 (UTC)

Problem with wrapping in Mozilla Firefox

In tables, cells with "Template:Sent off" are always wrapped, but only in Mozilla Firefox:

Yellow card 28' Yellow-red card 82'

(after 28', is the line wrap – you don't see it, if you don't use Firefox)
This template used in a regular text:
Yellow card 28' Yellow-red card 82' is not wrapped
Therefore I propose to replace the comma and space characters in this template with something else, for example / or & or _
28'/82' 28'&82' 28'_82'
or simply remove the space: 28',82'
I solved this problem and edited one of articles with style="white-space:nowrap", but it did not last long. (Some Chrome or MSIE user removed it without thinking.)
Maiō T. (talk) 23:43, 28 June 2013 (UTC)

 Fixed --Patrick87 (talk) 23:58, 28 June 2013 (UTC)
Thank you
Maiō T. (talk) 22:25, 29 June 2013 (UTC)

The lines... a bit too long

I don't know if it should be posted here, but in my opinion, the lines in the pages here, especially when the window is maximized, would be too long to read. They'd contain too many characters (about 140 when the innerWidth is 1366). I think that Wikipedia should set a max-width in its CSS - plus more responsive web design - so that its lines would have a suitable length :) -- Sky6t (talk) 13:35, 26 June 2013 (UTC)

You can set a maximum width in your personal CSS file: 
div#mw-content-text { max-width: 100ex; }
will give approximately 100 characters for the main portion of a page. --Redrose64 (talk) 14:26, 26 June 2013 (UTC)
  • Looks like WP typesetter never found Return key on the typewriter: Several people have kept noting the need for shorter, more readable lines on wide pages, which has been common knowledge among educated typesetters for many decades. It is extremely ironic how the wp:MOS people have spent millions of hours to force state-of-the-art "professional" text styling (even to transform hyphens into a new look), and yet meanwhile, the overwide pages look like they were typeset by a 7-year-old, who found a typewriter and just kept typing words but never found the carriage-return key and just kept putting in more sheets of paper to continue typing the long lines without wrapping. Too funny!! The wp:MOSquito bites them in the rear again! My thanks to User:Sky6t for noting the "elephant in the room" of Typesetting 101, "Hit RETURN at the end of the line" (hello?). Perhaps we should change the tag-line to, "The sum of all knowledge except typesetting". Well, all cosmic jokes aside, I guess setting an upper maximum page width would be a good reminder so people learn to narrow their windows and read so much faster. It really looks like the "cuckoo's nest" to see WP pages with 40-words-per-line, and pretend to be an encyclopedia. Are there any browsers, yet, which display a 2-column mode to show a webpage as two-page panels in a window? Meanwhile, setting a default maximum page width is a good idea. I have already proposed a smart template, as Template:Tracklist/custom, to show a list of album song titles in normal-width tables, rather than as wp:splat tables which stretch to the horizon on wide windows. -Wikid77 (talk) 06:56, 27 June 2013 (UTC)
  • The simple solution to "lines of text are too long when I maximise my browser on a large screen" is "don't maximise your browser on a large screen". I don't think complex software solutions to force a preferred nominal screen-width are the best approach here. Andrew Gray (talk) 17:04, 30 June 2013 (UTC)

Textarea line-height - Are fine adjustments possible?

Illustration added at 01:03, 30 June

I think impossible, but justincase:

Can we get different line-heights (leading / spacing between lines) within the HTML textarea (wikicode editing area), depending upon whether the lines are caused by either:

  1. line-wrap
  2. hard-return ( carriage-return / line-break )

This visual clarity, is the usual reason that editors add blank lines between items in a bulleted list. (and why we/they sometimes add blank lines between indented replies in talkpage discussions). Both of which create semantically incorrect output. (See WP:LISTGAP for details).

A small increase in line-height (25%?) when a carriage-return is involved, would do wonders for the whitespace / legibility. (Similar to the double-spacing we use for paragraph breaks in non-indented text).

<textarea id="wpTextbox1"> is the item in question.

I'm pretty sure this is impossible inside a textarea, but thought I'd confirm. Thanks. –Quiddity (talk) 02:31, 29 June 2013 (UTC)

There 'are' different line heights, but only between paragraphs (as produced by a blank line). This is perfectly reasonable typographically.
A simple line break (as long as not in a list) has no effect at all (e.g. produces no line break in the output) but can be used to improve readability of Wikitext. If you want to force a line-break you have to use <br /> which is deprecated in most cases (but may be useful in discussions). This doesn't produce a new paragraph but only insert a line break and there's no reason why line height should increase. --Patrick87 (talk) 12:23, 29 June 2013 (UTC)
No no! I mean inside the editing-window (HTML textarea) itself. I've added an illustration, at top-right, to clarify. Sorry about my unclear description. (As I said, I think it's impossible to do this, but worth asking justincase. It would make a gigantic impact on general legibility.). –Quiddity (talk) 01:06, 30 June 2013 (UTC)
That is not possible; line heights are fixed throughout a textarea. — Edokter (talk) — 14:30, 30 June 2013 (UTC)
Thanks for the confirmation. (I'm tempted to mention it upstream, but that's one large W3 river...) –Quiddity (talk) 22:15, 30 June 2013 (UTC)
Resolved

Edit counters

I've wondered this for a while, but why do different edit counters give different totals. X!'s edit counter gives me more than 3900 [44], but the one on my preferences is 50 lower. Hot Stop talk-contribs 05:11, 29 June 2013 (UTC)

The X! edit counter includes page moves in the count; see Wikipedia:Edit count#What is an edit count?, paragraph 2. -- John of Reading (talk) 06:17, 29 June 2013 (UTC)
I can't believe I never tried looking that up. Hot Stop talk-contribs 06:32, 29 June 2013 (UTC)
A single move action can bump X!'s edit count by 4. As an example, two days ago you made two page moves, which are recorded in the page move log as four moves (two pairs, each pair being an article and its talk page) but since each one also caused a redirect to be created at the old name, they are recorded as eight entries in your contribs, and so score 8 to X!'s Edit Counter. If you count the entries in your complete move log, and double it (for the redirects that were created), that should account for most of the discrepancy (it won't precisely account for it, because of that redlink). --Redrose64 (talk) 15:51, 29 June 2013 (UTC)
Thanks. I honestly had no idea I'd made that many page moves. Hot Stop talk-contribs 16:27, 29 June 2013 (UTC)
I've been here 7+ years and I did not know that. Neat. EVula // talk // ☯ // 15:38, 30 June 2013 (UTC)

Hidden text via wiki markup?

Several years ago, back before spoiler warnings became deprecated, I seem to remember there was a simple and fairly common way using wiki syntax to create hidden text that had to be highlighted or clicked to be viewable. But Help:Wiki markup has no such information about this, and Help:Hidden text describes hidden comments rather than hidden text intended to be viewed with highlighting or a click. So how was that hidden text done in wiki syntax? (I thought about using styles to setting the color of the text to white, but that would fail for the many users who have customized their user CSS so that their background color is something other than white.) —Lowellian (reply) 22:05, 29 June 2013 (UTC)

I think you're looking for Template:Hidden. --Patrick87 (talk) 23:10, 29 June 2013 (UTC)
Thanks. I could have sworn there was also some method that involved showing hidden text via highlighting rather than clicking, and that worked for all users regardless of their user CSS's background color? —Lowellian (reply) 23:48, 29 June 2013 (UTC)
See "Tooltip" and hover your mouse over displayed text.
—Wavelength (talk) 23:48, 29 June 2013 (UTC)
Hi Lowellian! Will style="color:transparent;" help you? It works for me in Firefox.
  1. asdakfasasdasdasfaafdsgwsaadtgfwaetrrhngfdfdasasdfasdfgdsswaserqw3treuhgfiuosdfasdgfdwswhtrur
  2. asdakfasasdafdsgwsaadtgfwaetrrhngfdswaserqw3treuhgfiuosdfasdgfdwswhtrur
HTH.···Vanischenu「m/Talk」 15:14, 30 June 2013 (UTC)
That will hide the text, but as far as I know there is no way to make it visible on hover (at least as long as there is no custom CSS in e.g. Common.css). --Patrick87 (talk) 15:48, 30 June 2013 (UTC)
Custom CSS is certainly one route. If the text in question is a link, it can be made to change its appearance when hovered over through careful use of the :hover pseudo-class. This is how Wikilinks gain an underline when hovered. AFAIK :hover can only be used with the a element, that is, linked text. You could do something like this: 
a.hidden { color: transparent; } a.hidden:hover { color: blue; }
but that's well into easter-egg territory. --Redrose64 (talk) 17:09, 30 June 2013 (UTC)
Actually this works with every element. I think this is also the way to go if we really want to support something like that. We'd need to add 
.hidden { color:transparent; }
.hidden:hover { color:inherit; }
to Common.css and could then use the feature easily with something like 
<span class="hidden">This text is normally hidden.</span>
--Patrick87 (talk) 21:44, 30 June 2013 (UTC)
Odd, I tried almost exactly that and failed, and then I looked up what W3C's docs on CSS 2.1 said about :hover - so I altered mine to be specific to the <A> tag and it then worked. I now try the above and it also works. Strange --Redrose64 (talk) 22:33, 30 June 2013 (UTC)
You can select them (either by clicking and dragging the mouse, or triple clicking it or using the arrow keys and shift key) or everything (ctrl+a). In Firefox and Chrome, when I select text, the background becomes grey and text becomes black, irrespective of the custom color it carries. In Explorer, black is background and text grey.···Vanischenu「m/Talk」 21:19, 30 June 2013 (UTC)
Yes, but I doubt this is what Lowellian intended. --Patrick87 (talk) 21:44, 30 June 2013 (UTC)

Geobox

The talk page for {{Geobox}} seems under-watched. Could someone with an understanding of that template, or templates in general, please take a look at Template talk:Geobox#Mountains and ranges? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:32, 30 June 2013 (UTC)

Failed to parse (Cannot store math image on filesystem.)

I am seeing the error messgae "Failed to parse (Cannot store math image on filesystem.)" in many articles having math formulas, for example in Positive form. I can also find lot's of these with a Google search [45]. What might be going on? Is this a browser-specific issue? Antilope (talk) 12:35, 30 June 2013 (UTC)

The formulas render for me if under Preferences/Appearance/Math I select MathJax. Selecting Always render PNG produces the error message you describe. I guess it is not a browser issue, but an issue with the Wikipedia servers. -- Toshio Yamaguchi 12:50, 30 June 2013 (UTC)
Or maybe the problem is with MediaWiki, I don't know for sure. Maybe the extension responsible for producing the PNGs is missing some functions only MathJax implements. -- Toshio Yamaguchi 20:37, 30 June 2013 (UTC)
Interestingly, the math code renders correctly when viewing the page in preview mode. Maybe this is caused because MediaWiki always uses MathJax for the preview, even when it is disabled in Preferences, but that is just a guess on my part. -- Toshio Yamaguchi 20:54, 30 June 2013 (UTC)
My guess is definitely incorrect, because what I see in the preview is a PNG rendering and not MathJax. So for some reason, the PNG rendering works in preview, but not on the saved page. The error says something about that the math image cannot be stored on the filesystem. Maybe preview uses some kind of buffer where the image can be stored, but for some reason MediaWiki cannot store that image on the server. Anyway, I am still guessing. -- Toshio Yamaguchi 21:09, 30 June 2013 (UTC)
I'm not attempting to look into this now, but I've opened a bugzilla:50482. Will make sure the WMF QA guys are aware of it to narrow it down then we can look at getting it fixed up. Reedy (talk) 23:56, 30 June 2013 (UTC)

?

Whenever I type http://wiki.riteme.site/wiki/? into my browser, I'm sent to the Main Page instead of to ?, but http://wiki.riteme.site/w/index.php?title=? takes me to the ? redirect just like it should. Any idea what's going on? I requested help at WP:HD, and from that response I know that the same thing happens in IE 8 (my browser), IE 9, and Chrome (don't know what version), so apparently it's a MediaWiki thing. A few other things: (1) Going to http://wiki.riteme.site/w/index.php?title= and putting in a weird character (e.g. http://wiki.riteme.site/w/index.php?title=Ɔ) sends me to http://wiki.riteme.site/w/index.php?title=?. (2) Don't click a link to http://wiki.riteme.site/w/index.php?title=?, because the ? gets left off and you're sent to the Main Page; my problem's something different. (3) Over at WP:HD, someone observed that URL encoding (in this case, http://wiki.riteme.site/wiki/%3F) works without problems. Nyttend (talk) 20:19, 30 June 2013 (UTC)

Stupid me, not including the version of chrome I'm using. 28.0.1500.63 (Official Build 208724) m there it is :) Charmlet (talk) 20:22, 30 June 2013 (UTC)
Well this is not much of a mystery after all. The quotation mark "?" isn't allowed inside URLs (or has another meaning, namely providing URL parameters). Therefore you have to URL encode it to "%3F". If you write [http://wiki.riteme.site/w/index.php?title=?] also the link works correctly: [46] --Patrick87 (talk) 20:30, 30 June 2013 (UTC)
The first instance of a question mark in a URI is defined in rfc:3986 (section 3) as the delimiter between the path (section 3.3) and the query (section 3.4),

The query component is indicated by the first question mark ("?") character and terminated by a number sign ("#") character or by the end of the URI. ... The characters slash ("/") and question mark ("?") may represent data within the query component.

--Redrose64 (talk) 21:55, 30 June 2013 (UTC)

Double edit

What happened here?--Gilderien Chat|List of good deeds 20:33, 30 June 2013 (UTC)

I'm guessing that you accidentally hit "save" twice. I'm going to go to your talk page and attempt the same thing. Nyttend (talk) 20:58, 30 June 2013 (UTC)
I'm pretty sure it was only once, but in the past when I have, it has edit-conflicted with myself rather than double-edit.--Gilderien Chat|List of good deeds 21:04, 30 June 2013 (UTC)
Never mind; my test at your talk page showed that self-edit-conflicting happens when you doubleclick. Nyttend (talk) 21:10, 30 June 2013 (UTC)

Not sure how to explain this, but look at The Afghan Alphabet and you'll see what I mean. I want it to display like This article is about the 2002 documentary. For writing systems used in Afghanistan, see Persian alphabet and Pashto alphabet.-- Brainy J ~✿~ (talk) 20:49, 30 June 2013 (UTC)

Fixed. Go to Template:About and scroll down to read the documentation; we've got an extremely well-written documentation page that's supplied for most of our hatnote templates. I had no clue how to solve your problem until reading the documentation, but it was perfectly easy once I'd read it. Nyttend (talk) 20:57, 30 June 2013 (UTC)
I had read the documentation but it's quite lengthy and I couldn't find the exact situation listed in there. I see it now, but it's not exactly easy to find.-- Brainy J ~✿~ (talk) 21:17, 30 June 2013 (UTC)

Isolated Period in search gives Search backend error.

(Moved from Help Desk) Any search which has an isolated period, for example . abc, a . b, abc . returns "An error has occurred while searching: The search backend returned an error:". Any ideas?Naraht (talk) 01:10, 1 July 2013 (UTC)

Ctrl & click Edit won't open in new tab

Tracked in Phabricator
Task T51993

[Firefox 21.0 on Win 7] When I ctrl & click an Edit tab (at the top of an article, or a section edit), the edit window always used to open in a new browser tab. But for the past week or so it has stopped doing that and insists on opening in the current tab, overwriting the page I want to edit. All other links I ctrl & click open in new browser tabs, including links in the article and the tabs at the top of the page (but not Edit). Shift & clicking an Edit tab has also stopped opening in a new window. Yet right-clicking an Edit tab and selecting "Open Link in New Tab/Window" does open a new tab/window. Is anyone else experiencing this? —Bruce1eetalk 09:35, 26 June 2013 (UTC)

Seems to be caused by the VisualEditor A/B test code. I filed T52221. Matma Rex talk 10:22, 26 June 2013 (UTC)
Thanks for that. BTW I don't have VisualEditor enabled in my Preferences. I don't know if that is relevant. —Bruce1eetalk 10:30, 26 June 2013 (UTC)
I have exactly the same behaviour in Firefox 22.0 on Windows Vista. It happens whether I'm logged in or out, and it doesn't help to clear my entire cache. It doesn't happen in any of Chrome, IE, Safari, Opera. And in Firefox it doesn't happen at any of de:, fr:, es:. At mw: it appears to only happen in namespaces where VisualEditor is enabled, but not on the "Edit source" tab. PrimeHunter (talk) 10:40, 26 June 2013 (UTC)
Me too, and it is highly irritating. In Firefox 21 with scripting disabled, there is no problem. I was just at bn: with scripting enabled, and there is no problem there. However, editing here with scripting prevents ctrl+click_edit from opening a new window/tab. Johnuniq (talk) 11:22, 26 June 2013 (UTC)
[Firefox 22.0 on Win 7] This seems to be working now in the Article namespace, that is ctrl&Edit and ctrl&Edit_source both open in a new tab. But in the Wikipedia namespace ctrl&Edit still doesn't open in a new tab. —Bruce1eetalk 05:00, 2 July 2013 (UTC)

List of places in...

Hi,

How do I get the list of places for the Channel Islands, as most of the Lists of places in... have toolserver links which redirect to Google maps. How do I change the place, to e.g. Sark? I asked on the teahouse freenode, and got sent here...

Matty.007 19:37, 29 June 2013 (UTC)

I'm not sure what you mean. Lists like List of places in Luton are created manually and there doesn't appear to be one for the Channel Islands, apart from more specialised lists in Category:Channel Islands-related lists. Where do you see toolserver redirects to Google Maps? Coordinates often have links like [47] where Google Maps is one of the options but not a redirect. PrimeHunter (talk) 20:49, 29 June 2013 (UTC)
An example: on List of places in Argyll and Bute, there is a linkto toolserver, which, when it loads, is a map on Google maps. Matty.007 10:25, 30 June 2013 (UTC)
Thanks for the example so it's possible to see what you talk about. The lists I examined didn't have such a link. It was added manually in [48]. I currently get a "502 Bad Gateway" message at toolserver for the link and no redirect to Google. I cannot investigate it further today. PrimeHunter (talk) 11:20, 30 June 2013 (UTC)
I think that a direct Toolserver link is a non-standard method (as well as being prone to total failure within the next two years); something like {{GeoGroup}} may be a better choice. --Redrose64 (talk) 13:20, 30 June 2013 (UTC)
The toolserver feature is documented at http://toolserver.org/~para/cgi-bin/kmlexport. The list of places must exist at the English Wikipedia before using the feature. I agree the feature should be used with a template and not with a direct url. PrimeHunter (talk) 01:01, 1 July 2013 (UTC)
OK, thanks. Matty.007 18:17, 1 July 2013 (UTC)

Adding "Feedback" blue box to top of an article

I am seeing at the top of most major city articles a blue box for feedback, I did start the feedback page but how does one code the top blue box to an article, I am specifically asking for Pittsburgh, thanks. Market St.⧏ ⧐ Diamond Way 11:14, 1 July 2013 (UTC)

It has been added to category Category:Article Feedback 5 Additional Articles. Keith D (talk) 12:41, 1 July 2013 (UTC)
Thanks for the response, but I did add the category to the very bottom of Pittsburgh and there is a page wide box with text at the bottom of the article. But I was looking for something like San Francisco where there is a small solid blue box at the top of the article. If I am adding the category wrong let me know. Thanks! Market St.⧏ ⧐ Diamond Way 13:12, 1 July 2013 (UTC)
Specifically the tiny solid blue box up top between From Wikipedia, the free encyclopedia and Coordinates with the blue text outside the box about how many reader comments on such pages like San Francisco. Thanks. Market St.⧏ ⧐ Diamond Way 13:33, 1 July 2013 (UTC)
If you, or anyone else, goes to the bottom of the Pittsburgh article and uses the blue box to leave a comment, then a "reader comments" icon and message will appear at the top. If an article has no reader comments, there is no need to provide a link for viewing them. -- John of Reading (talk) 14:07, 1 July 2013 (UTC)
Ok that makes sense, I did leave a short blurb but marked it "resolved" so after unresolved or 2 or 3 the top box should appear, if its simply waiting for more input then this is resolved for now, I appreciate all the insight! Market St.⧏ ⧐ Diamond Way 14:24, 1 July 2013 (UTC)

IP creation of new article

Resolved

Unless I am missing something an IP is creating new articles, Peter-No-Tail (television series) and Agaton Sax And The Bykoebing Village Festival. Has something changed to allow IPs to create new articles? GB fan 12:43, 1 July 2013 (UTC)

They were created on the talk page and moved by a registered user. IP's can create pages in talk namespaces. PrimeHunter (talk) 13:05, 1 July 2013 (UTC)
Thanks, I knew I must be missing something. I missed the move. I see it now in the article history. GB fan 13:13, 1 July 2013 (UTC)

Image sizing

Some advice on image sizing is needed at Talk:Charles-Valentin Alkan#Lede image. Unfortunately, I'm not going to be able to edit Wikipedia for a week or two, for medical reasons. Can someone else step in, please? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:32, 1 July 2013 (UTC)

Tech news: 2013-27

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

Recent software changes
(Not all changes will affect you.)
  • The latest version of MediaWiki (1.22/wmf9) was added to test wikis on June 27. It will be enabled on non–Wikipedia sites on July 8, and on all Wikipedias on July 11.
  • On Wikisource, the canonical names of the "Index" and "Page" namespaces in the Proofread Page extension are no longer localized (bug #47596). Please check scripts that depend on $wgCanonicalNamespace. [49]
  • A JavaScript problem caused the "View history" and "New section" tabs in the Vector skin to be moved into the drop-down menu on right-to-left wikis. The issue is now fixed and links are visible as before (bug #50196). [50]
  • There was a short site outage on June 28.
  • The automated Category:Pages with missing files now includes broken file links inserted inside the <gallery /> tag (bug #50119). [51]
  • The Nearby feature is now enabled on Commons and shows images in a user's area. [52]
  • There is now a special page listing disambiguation pages for wikis that use the Disambiguator extension (bug #44040). [53]
  • The old version of the Article feedback tool (version 4) was removed from wikis that still used it. [54]
  • VisualEditor news:
    • Many bugs that caused text to be removed or damaged have been fixed, including one related to copy-paste (bug #49816).
    • VisualEditor now offers a visual interface to edit references.
    • In preparation for enabling the VisualEditor on a wider scale, new documentation has been created, including a list of frequently-asked questions and a user guide with many images. Please help with translations.
    • Several problems related to overlapping of elements with the VisualEditor toolbar have been fixed (bug #50096, #50159, #50324).
    • TemplateData information is now displayed for templates that are added to a page (bug #49778).
    • Section edit links now show links to both VisualEditor and the old (source) editor (bug #49666).
    • Images are now loaded securely when using HTTPS (bug #43015). [55]
Future software changes
  • VisualEditor will be enabled for all logged-in English Wikipedia users on July 1, and for all users on July 8.
  • From July 8, it will be possible to upload WAV and native FLAC files to Commons, and use them directly on wiki pages (bug #49505). [56]
  • The Universal Language Selector will be added to the English Wikipedia on July 2, and to remaining wikis on July 9. [57]
Erratum

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

14:22, 1 July 2013 (UTC)

Any ideas as to why I can't print or print preview Boeing 777 or Boeing 737 Next Generation using Windows 7 and Firefox 22? No problems using IE 10 but for these pages in FF the print preview hangs and I have to restart FF. No problems with any other articles on Boeing aircraft, just these two. NtheP (talk) 16:55, 1 July 2013 (UTC)

Thanking for an edit

I've got notifications with editors thanking me for a specific edit. How do they do it? I am assuming there's something in preferences I should play with...? --Piotr Konieczny aka Prokonsul Piotrus| reply here 19:57, 1 July 2013 (UTC)

In the history of a wikipage for each specific edit, you can find a 'thanks' link at the end (after the edit summary). —TheDJ (talk • contribs) 20:04, 1 July 2013 (UTC)
@Piotrus: Wikipedia:Notifications/Thanks is where you can find documentation/discussion. Steven Walling (WMF) • talk 20:21, 1 July 2013 (UTC)
The "thank" link appears at the right-hand end of many (but not all) entries in a page's history. If you don't see any, you probably have "Exclude me from feature experiments" switched on at Preferences. --Redrose64 (talk) 20:36, 1 July 2013 (UTC)
As for the "many (but not all)" bit, it doesn't appear for IP editors, since they aren't covered by the notifications feature. Graham87 03:54, 2 July 2013 (UTC)

DYK check

I'm aiming to install this tool for DYK check. A message appeared that I should ask here for malicious content. Help is welcome.—Prashant 03:59, 2 July 2013 (UTC)

That's a system-generated message that is shown whenever you view or edit a page with a ".js" at the end of its name. The DYKcheck tool is widely used, so you should be fine. -- John of Reading (talk) 06:18, 2 July 2013 (UTC)

Script for edit buttons to banish VE

Since VisualEditor is apparently coming whether we like it or not, is anyone working on a script to make the VE 'edit' button go away and leave only the 'edit script' button, once VE launches? - The Bushranger One ping only 21:04, 27 June 2013 (UTC)

i'm pretty sure you'll be able to use your preferences to disable VE for years to come. we have vector and the "enhanced editing toolbar" for more than 3 years now (iirc), and you can still opt out of it. if the improbable will happen, and someone will remove the preferences choice to opt out of VE, then we can discuss writing silly scripts to hide the "edit" link (or better yet - then we can lobby to return the preference...). as long as the preferences selection is in place, why waste a single iota of brainpower to even think about it? peace - קיפודנחש (aka kipod) (talk) 23:08, 27 June 2013 (UTC)
Because the past history of "upgrades" and "improvements" has left me quite a pessimist about them. - The Bushranger One ping only 23:16, 27 June 2013 (UTC)
i'm willing to put money that the "disable VE" option will still be here 3 years from now, and i'm pretty sure (but not enough to put money on it) that any script i'll write today to banish the "Edit" link whenever "Edit source" link is available will not work by then. there's no point in trying to cross this bridge before we even reached it... peace - קיפודנחש (aka kipod) (talk) 23:20, 27 June 2013 (UTC)
Is it important to you that you not even be able to see VisualEditor's [Edit] button? I think that most people who like the old system will be satisfied with just clicking the tab for the one they want. Whatamidoing (WMF) (talk) 12:12, 1 July 2013 (UTC)
Yes, it is. I could come up with three good reasons to be able to disable VE right now:
  • VE adds new buttons via JavaScript, therefore they are updating with a noticeable delay after the page is initially loaded.
  • The editsection "Edit source" links are only usable after hovering over the "edit" links which is very inconvenient.
  • Page load times will increase if VE's JavaScript has to be loaded, no matter if I use it or not.
--Patrick87 (talk) 14:19, 1 July 2013 (UTC)
  • I'm also interested in having the option to remove the VE button, Since VE was launched for all logged-in accounts, I've lost an irritating amount of time by mistakenly pushing the VE edit button instead of the edit source button. Manxruler (talk) 00:21, 3 July 2013 (UTC)

Just a comment...

...while I agree with the result of the discussion here about removing default HotCat, having some warning before it was turned off would have been nice. I thought something was wrong before I spotted that. - The Bushranger One ping only 00:39, 30 June 2013 (UTC)

I cannot believe that important features such as wp:hotcat get tuned on and off without notification (on a whim?). I suspect this will cost Wikipedia thousands of edits by confused editors by the end of today. XOttawahitech (talk) 13:57, 30 June 2013 (UTC)
I must confess that the problem described as the reason for deactivating its default status - editors mistaking it for a comment feature - is something I have never seen happen, while the second part - admins having to delete accidentally created categories - makes no sense at all, as category creation is completely seperate - invalid categories added through Hotcat are redlinks. - The Bushranger One ping only 00:26, 1 July 2013 (UTC)
Agreed, I was most shocked to come back today from a weekend away to find HotCat had vanished with no notice/warning! GiantSnowman 14:45, 2 July 2013 (UTC)

GeoGroupTemplate still depending on the toolserver

{{GeoGroup}} is used by a lot of pages, but it still links to the nonexistent toolserver instead of relying on the new Labs. As a result, it's completely useless right now. What needs to be done to get it to rely on Labs? Nyttend (talk) 01:20, 2 July 2013 (UTC)

It takes someone to take the code that underlies the toolserver's service and port it over to the Tool Labs. If you know who did the original version, asking them is the best thing to do (since they are the most familiar with their code, obviously). Have you asked them? — MPelletier (WMF) (talk) 13:34, 2 July 2013 (UTC)
Unfortunately, I have no idea whom to ask — I'd never heard of the template until I joined a wikiproject whose articles frequently use it. Will we need to make any changes to the template itself? Nyttend (talk) 16:43, 2 July 2013 (UTC)
According to the template code (and a bit of Googling), you'll need to contact User:Para on Commons. The template will probably need to be edited at some point to fix the link. Graham87 02:38, 3 July 2013 (UTC)

Checking up on VisualEditor edits

Edits made with VisualEditor are all tagged, which means they can be isolated on Recent Changes, see: [59].

Looking at that list, I've found several examples of edits that look like unintentional corruptions (for example by adding random <nowiki> in the middle of a block). I assume such errors are either the result of bugs in VisualEditor or user mistakes caused by unfamiliarity with the new interface. At the moment it seems like most edits are okay, but there are a non-trivial fraction that probably need fixing. While some of these issues get tracked down, it would be good if there were extra eyes reviewing all the changes made via VisualEditor. Dragons flight (talk) 03:02, 2 July 2013 (UTC)

Thanks for that information; it has already helped me quickly fix some goofs. However, it appears that VisualEditor is already being used for the vast majority of edits, so isolating them is not a huge advantage for this purpose, as far as I can see. Chris the speller yack 03:25, 2 July 2013 (UTC)
"Vast majority"? Looking at recent changes, it looks like Visual Editor was used for only a few percent of recent article space edits. Dragons flight (talk) 03:30, 2 July 2013 (UTC)
Forgive my idiotic observation; I now see that your link applies a tag filter, so only VisualEditor changes are shown. Chris the speller yack 03:33, 2 July 2013 (UTC)
There is a special tag applied in cases where VisualEditor believes it may be corrupting the page (in this case it also adds a warning to the save dialog). You can view edits with that tag here. Edits with that tag will almost certainly expose some sort of bug in VE; fortunately, there aren't very many of them.
As for the nowikification that you observed, it looks like that's people typing literal markup into the editor. --Catrope (talk) 03:36, 2 July 2013 (UTC)
There are so many cases of nowikification added with VisualEditor that I think more is going on than just a few editors adding that markup. Chris the speller yack 05:28, 2 July 2013 (UTC)
It's a really hard habit to give up :) If you encounter nowikification in cases where the editor is absolutely positively certain that they didn't add a wikilink in VisualEditor mode, then it should be reported at Wikipedia:VisualEditor/Feedback, but my feeling is that most of these cases can be explained by muscle memory :) guillom 05:40, 2 July 2013 (UTC)
guillom is quite right, it's not a bug as so much a habit. VisualEditor creates wikilinks inserted through it by clicking the link (chains) button, where you then insert the link and it adds the [[]] and {{}} to the code for you. If you type in the braces or brackets, VisualEditor assumes that you are actually trying to use those as writing, and marks it with nowiki tags so that it does not become markup. Moving forward, it should become less and less of an issue until it is no more. If you truly did not add a bracket or brace by hand and VisualEditor thought you did, yes, please report it. Keegan (WMF) (talk) 06:46, 2 July 2013 (UTC)
I have added bug 50527 for solving this problem of cluterring nowiki tags everywhere. TheOriginalSoni (talk) 15:00, 2 July 2013 (UTC)
Tracked in Phabricator
Task T52527

Visual Editor fanclub

Well I like it. And I've been here for EVER. (Chrome running on XP, not sure of the age of either). doktorb wordsdeeds 06:28, 2 July 2013 (UTC)

Thanks! If you spot anything broken or buggy, drop a note on Wikipedia:VisualEditor/Feedback or throw a message-in-a-bottle at my talkpage :). Okeyes (WMF) (talk) 06:45, 2 July 2013 (UTC)
Cheers User:Okeyes (WMF). I know change is feared around here, but I'm in my mid-30s and have been editing since 2004, I'm pretty much over getting out the pitchforks whenever a free service changes something! doktorb wordsdeeds 08:32, 2 July 2013 (UTC)
Since the Anti VE editors already have User:Technical 13/Userboxes/Anti-VE, I went forward with creating this userbox - User:TheOriginalSoni/Userboxes/Pro-VE. TheOriginalSoni (talk) 14:57, 2 July 2013 (UTC)
To VE or not to VE, that is the question. Kumioko (talk) 14:59, 2 July 2013 (UTC)
Or if you like the middle path, you can go neutral VE at User:Zhaofeng Li/Userboxes/Neutral-VE. TheOriginalSoni (talk) 20:12, 2 July 2013 (UTC)

Prevent a particular heading from appearing in the TOC

Is there a way to prevent a particular heading (i.e., not just a whole level of headings) from appearing in the TOC? In particular I'm thinking of the page MediaWiki. In the current version, the section 5.3.1 that appears in the TOC is not actually a section, it's just an example of what formatting looks like, so ideally it should not be in the TOC. It looks like it was created with just <h4> tags, not ====, but it's still showing up in the TOC.

For what it's worth, I know one solution in this case would be to just change the example so it doesn't include a heading. But I just wanted to first check and see if there's a technical solution that doesn't require making content changes.

Thanks, rʨanaɢ (talk) 12:05, 2 July 2013 (UTC)

Fixed using {{fake heading}}. --Redrose64 (talk) 12:58, 2 July 2013 (UTC)
Awesome; thanks! rʨanaɢ (talk) 13:20, 2 July 2013 (UTC)

Visual Editor: site-wide roll out? - angry thread

Moved to Wikipedia talk:VisualEditor § Visual Editor: site-wide roll out.3F - angry thread

— Preceding unsigned comment added by Rannpháirtí anaithnid (talk • contribs) 12:50, 2 July 2013 (UTC)

Language settings cog

See also #Universal Language Selector will be enabled on July 2, 2013

That little cog that's appeared recently above the languages box on the left hand side - is there a way to remove it? Thanks. Lugnuts Dick Laurent is dead 18:08, 2 July 2013 (UTC)

It's called ULS, and sadly no, despite repeated requests (T48306). Matma Rex talk 18:25, 2 July 2013 (UTC)
If you're just concerned about displaying the little cog, then add 
.uls-settings-trigger { display: none }
to your common.css page. It will still load, you just won't see it. πr2 (t • c) 19:25, 2 July 2013 (UTC)

Where have geolocate, Whois etc gone?

I was looking at an article I had created and noticed that most of the recent changes have been by two anon accounts with little contribution history. I was curious to see if there was any evidence of their being connected to the article subject and went to the user contribution pages expecting to find the usual array of tools at the bottom. Where have they gone?

I've not been very active recently so this might be old news, but it's news to me?--Peter cohen (talk) 21:02, 2 July 2013 (UTC)

@Peter cohen: Try setting your user language to "en". The message is MediaWiki:Sp-contributions-footer-anon, but other languages (e.g., en-gb) don't seem to have this. There was a recent change to how MediaWiki handles fallbacks to the content language of the wiki, in this case "en", so that might be related. Set your language in prefs to "English" - not British or Canadian, tho. πr2 (t • c) 21:06, 2 July 2013 (UTC)
That works. Thanks user:area of a circle.--Peter cohen (talk) 21:24, 2 July 2013 (UTC)

Simple survey of new accounts

Hi everyone. This is a quick heads up about a survey my team deployed today, in support of VisualEditor. This doesn't survey isn't delivered to anyone who already had an account before today, but just in case you see it, I wanted to provide a point of reference.

One of the theories about VisualEditor is that it may improve our (dismally unbalanced) gender demographics, by lowering the barrier to participation for everyone who might find markup intimidating, annoying, or otherwise an obstacle. (Sue Gardner has a really good blog post about this.)

Anyway, to establish a more recent and targeted baseline of understanding about how many new accounts/new editors are male or female, we're running an optional one question survey to all accounts that sign up, as of now and continuing for at least a week. We will be able to share the aggregate results publicly, like the annual survey of all editors, but the individual answers will not be shared – unlike the public gender preference.

There's documentation about this "microsurvey" on Meta. Please let me know if you have any questions. Steven Walling (WMF) • talk 23:29, 1 July 2013 (UTC)

That's just absurd. It's not the edit window that drives women away - it's the way the guys behave. We're quite capable, and we do have brains, to figure out how to edit. A few of us have actually, swoon, sigh, managed to produce a fair bit of decent content. Complete with pictures and captions and research and all kinds of hard stuff. Victoria (talk) 00:24, 2 July 2013 (UTC)
Its the way many editors on Wikipedia behave (both male and female) that drive people away. Doc James (talk · contribs · email) (if I write on your page reply on mine) 00:42, 2 July 2013 (UTC)
Indeed. Honestly, if I was female, I'd likely be quite offended by that suggestion that the editing markup was too complex (and even as a guy I find it staggering that somebody actually suggested that) - because it carries the distinct insinuation that women aren't smart enough to figure it out. - The Bushranger One ping only 00:34, 2 July 2013 (UTC)
"It's not the edit window that drives women away - it's the way the guys behave." These things are not mutually exclusive. Amazingly, we've never done a reliable survey of the demographics of people who just registered but haven't yet edited. We have no idea if equal numbers of men and women register accounts to begin with, what challenges they might each face when they first try to edit, and so on. Steven Walling (WMF) • talk 01:18, 2 July 2013 (UTC)
My guess is that women would not like suggestions that females cannot cope with wikitext, and they may not welcome a survey asking if they are female—a bit creepy really. Johnuniq (talk) 00:38, 2 July 2013 (UTC)
Hi, I wrote the code in question here. I completely understand that there are a lot of women on Wikipedia (and other WMF sites), who not only understand wikitext, but do great work. I also realize there are a lot of other factors at play here. However, we also know editing could be more user-friendly, and Sue Gardner has suggested (in the blog post Steven linked) that may impact female participation. Some other people have agreed. Superm401 - Talk 00:51, 2 July 2013 (UTC)
Being female, one of the early HTML coders on the newly created internet, and a Wiki editor since 2006, I would say that retention of females has nothing to do with a pink and fluffy style editor and much to do with the simply horrible way that some of the current editors (mostly male) behave to female editors. I have been put down, insulted, and threatened. I've taken time off editing to get my desire to edit back. Putting lipstick on the pig isn't going to get you more female editors without behavior changes of some of the entrenched "power users." Ellin Beltz (talk) 00:52, 2 July 2013 (UTC)
(edit conflict) The implication is that the 90% of guys who edit here have to put up with a crap rollout as a crutch for the 10% of women who put up with an immense amount of sexism. This implication needs to be retracted immediately. You're hanging it on the women. Great. I'm impressed. Victoria (talk) 00:54, 2 July 2013 (UTC)
@Ellin Beltz: No one who works in WMF design and engineering thinks women need a "pink and fluffy" editor, and I think you can see that when looking at VisualEditor. That kind of gross stereotyping of what appeals to women simply does not work, and mostly tends to be a complete disaster for somewhat obvious reasons. The point of the survey is not to justify that kind of solution to correcting what gender gap Wikipedia has. The question we're asking is: does a general purpose usability improvement, given to everyone, help make Wikipedia have a gender distribution more like the real world, where half of the world is born female. Maybe it will, maybe it won't. We honestly have no idea, which is why we're running a survey. Steven Walling (WMF) • talk 01:08, 2 July 2013 (UTC)
Wikipedia should have the mixture of editors that has the best results for maintaining and growing the encyclopedia, whether they're male, female, transsexual, intersex, or green blobby things from Mars. While there does indeed seem to be a somewhat alarming imbalance between male and female editors, the assumption that having that balance pegged to the real world is the ideal end state isn't necessarily the best thing for the encyclopedia - it should be gender-blind, not filling a quota. - The Bushranger One ping only 02:16, 2 July 2013 (UTC)

This statement sounds like it could offend women. I'm not sure if there is a relation between men and women with editing. Many experienced editors need to tone themselves down when dealing with new editors. Though I wouldn't be surprised if editors are rough with women due to men being the majority. I had that experience when I said that I had Asperger's. SL93 (talk) 00:55, 2 July 2013 (UTC)

Yes Wikipedia can get very nasty and I agree that this is probably the greater issue. I am not sure what to do about it other than try to be pleasant myself. I think women are less willing to put up with the nastiness than men and thus why we have more males here. I am not entirely sure which gender is the nicer though since it was a female Wikipedia editor who launched legal attacks against me and required me getting a lawyer for 8 months. Doc James (talk · contribs · email) (if I write on your page reply on mine) 01:04, 2 July 2013 (UTC)
Probably the first step to curbing nastiness would be to do something about the alarmingly widespread opinon that WP:CIVIL isn't just optional but is for losers, and the mop-hunting lynch mobs that get civility blocks overturned five minutes after the few who dare impose them do so, but that's another kettle of fish... - The Bushranger One ping only 01:27, 2 July 2013 (UTC)
  • Comment Nobody is saying anything even remotely close to "women can't edit" or "women can't learn markup." It is simply factually true that women are underrepresented in STEM fields, including software engineering, and thus are less likely to know a markup or coding language. And I think most people here would agree (including you, Ellin!) that knowing some kind of markup/code puts you at a distinct advantage for learning other kinds of markup/coding languages, such as wiki markup. Maybe the latter is not actually an issue for most women, but the point of a survey like this is to actually test the hypothesis instead of making blanket assumptions about women's behavior and interests (and what may or may not offend them, cough). Maryana (WMF) (talk) 01:06, 2 July 2013 (UTC)
    • Whether that is the case or not, I think that the main issue is how new editors are treated. By the way, I have no idea about what software engineering even is. SL93 (talk) 01:11, 2 July 2013 (UTC)
  • (edit conflict) Maryana - I am sorry, but I find this to be incredibly insulting. Learning markup is just not hard. Like anything else, there's a learning curve. But the assumption that women might like a Facebook type of experience (I'm not on FB so wouldn't know what that is) is wrong. Wikipedia, first and foremost, is a collaborative writing project and editors, regardless of gender, work for free. They volunteer their time. In my experience the men who don't write much, are a little more difficult to deal with than the so-called content editors. I have made some absolutely great friends here, people are always willing to help, and learning to deal with complicated markup is not an issue. But my biggest problem is the implication that VE was designed solely for women. Ironically, as a woman I can't use it, and Okeyes (WMF) refuses to answer the questions I've put to him repeatedly during the last weeks. That tells me a lot. I think the survey should be shelved for a bit. People are not happy and pointing the finger at technically challenged women isn't helping. Victoria (talk) 01:14, 2 July 2013 (UTC)
  • Frankly I've probably just missed them. What does that tell you, exactly? If you have specific questions, drop them on my talkpage where they won't get overwhelmed - I'll try to get to them in the morning. Okeyes (WMF) (talk) 01:20, 2 July 2013 (UTC)

I'm confused by the cough comment. I said that the survey might offend women, not that one woman who isn't offended stands for an entire gender. SL93 (talk) 01:22, 2 July 2013 (UTC)

In fact this new VE is more complicated. I have been trying to add a reference for an hour and simply cannot do it. Is there a help page that tells me how to add a properly formatted ref? How are new editors going to figure this out? If refs cannot be added we are way to early to go live on the VE. Doc James (talk · contribs · email) (if I write on your page reply on mine) 01:26, 2 July 2013 (UTC)
How to edit references. I hope this helps! Keegan (WMF) (talk) 01:40, 2 July 2013 (UTC)
So what you are saying is everything has to be entered via free text? There is no way to simply add the PMID / ISBN and to have a button that fills in the rest? The is no guidance on what properties a reference should have? Now people need to know reference styles guidelines or our article will simple be a hodgepodge of different ones (which or course means the latter) :-( Doc James (talk · contribs · email) (if I write on your page reply on mine) 01:56, 2 July 2013 (UTC)
I am not saying that. You asked if there was a page for using references in VisualEditor. There is, I linked you to it. Keegan (WMF) (talk) 02:02, 2 July 2013 (UTC)
If experienced editors can't use it, then I wonder why it is assumed that new editors can. SL93 (talk) 01:28, 2 July 2013 (UTC)
Steven, I must say that the theories you point out is pretty sexistic in it's own light. And using those theories as a tool isn't optimal behavior, if you really want to behave gender neutral. →AzaToth 01:59, 2 July 2013 (UTC)
  • I'm also concerned about the implication that this has been done, in part, with women in mind, and that women can't or don't want to learn wiki markup. I also think it's wrong-headed to suppose that the VE will be easier for anyone, as least as it stands. In my own case, I'm as technically incompetent as it's possible to be, and I had no problem learning wikitext, because it's just a question of monkey see, monkey do. But with the VE, you no longer see what other editors have done before you, so it seems to me that it's going to be harder to learn. SlimVirgin (talk) 16:01, 2 July 2013 (UTC)
  • I agree 100% with SlimVirgin. I can't code for shit, I've tried and tried to learn even easy languages like Python and it just isn't my forte. I learned wikimarkup to a decently high level in a very short time at age 12. Implying that women won't edit because of a wikimarkup barrier is bullshit when a 12-year-old girl who, 6 years later, still can't program at all, can learn wikimarkup in a couple days. My own experience aside, I've worked with many women through the Education Program who have had no trouble at all learning the markup. I find that the people who have the most trouble are non-digital natives. If you're going to "market" an easier way to edit, at least say it's for people who don't have a lot of experience with the Internet. Saying that it'll bring women on board ironically exemplifies the unconscious sexism that makes this community so hostile to women in the first place. Keilana|Parlez ici 17:58, 2 July 2013 (UTC)
  • The Visual Editor is probably quite a way from feature parity from the old textbox editor. I think this will compromise the research being conducted. *If* the research finds that women prefer the new VE, does that mean they are 'better' when they dont need to worry about features that are missing from the VE? It is possible that VE edits may be more likely to be reverted because they dont use all the features of the old textbox, and their will walk away feeling unwanted by Wikipedia. i.e. this study, if conducted now, will likely result in a gender catastrophe, or the results will look so bad that the WMF wisely shelves the data to avoid said controversy. How did this research project pass an ethics committee?? John Vandenberg (chat) 00:05, 3 July 2013 (UTC)
i.e. any research that is conducted on a new feature should be gender neutral. Does the feature improve the project? This may be viewed as self-evident by the WMF team, and I am sure VE will eventually be beneficial to the projects, but it might take a while for that to be realised and verified by research. John Vandenberg (chat) 00:14, 3 July 2013 (UTC)

Gender Comment

I haven't tried to use Visual Editor. I have read enough comments about it to be willing to wait. However, anyone who suggests that changing the edit interface will help us retain female editors has missed the point. More importantly, anyone who suggests that changing the edit interface will help us retain female editors has no experience with tough-as-nails female engineers. Having worked with female engineers for decades, and having seen that they are every bit as tech-savvy and smart as male engineers, and more tech-savvy and smarter than some males, I know that the idea that changing the edit interface will help us retain female editors is silly. As Ellin and Victoria point out, the real problem is not the edit interface; it is the attitude of some male editors, and, in general, not male engineers, who recognize that female engineers are just engineers who may or may not dress differently. The idea that the edit interface will have anything to do with retaining female editors is silly. Robert McClenon (talk) 12:24, 2 July 2013 (UTC)

"Please accept my resignation. I dont want to belong to any club that will have me as a member". -Groucho Marx.
I have just tried the visual editor. It is too slow on my machine to be an enjoyable experience but I do think that the interface is a step forwards.
The people discussing this point here are the ones who have successful mastered the markup language. The may come from a background where they can do hex arithmetic in their heads and so appreciate the positioning of the ASCII character set, or from a background where they were already familiar with HTML or they may be someone who likes Wikipedia enough that they just persevered and learnt it.
But anyone commenting here is part of a self-selecting group who not only know how to use the markup language but also put up with the culture here which is far less welcoming today than it was when I started to edit. The major reason for this is that in the early days there were far fewer restrictions on what one could do, so the time before one did something that another "corrected" because of a guideline, and hence the need to lean about the guidelines was much longer than today. Not needing to debate the worth of "corrections" meant that one rarely ended up in a hostile stressful debate.
Some things can not easily be fixed. For example the need for citing sources is important for the credibility of the content -- that debate was done and dusted back in 2006 -- there is no way that we can go back to the way articles were created and maintained prior to that decision. There is no internal desire among enough of the regular editors to fix the uncivil culture that exists, or to stop the politics and social manipulation that are frequently used by some editors (which without a uncivil word being said can leave an editor feeling that they were mugged), all of which can make editing here an unpleasant experience.
But I think that a more friendly editor front end is a good technical fix for one of the problems that Wikipeida has. So I think WYSIWYG front end is a positive step forward and if it encourages people outside the usual demography to start to edit then that must be a positive thing. I think that the phrasing used by Steven Walling at the start of this thread was clumsy -- as there are many other ways to group people who are outside the demographic profile of a typical Wikipedia editor and more of those than just one needs to captured if a survey is to be of greater use. -- PBS (talk) 13:17, 2 July 2013 (UTC)
The group of editors here is one of the main reasons why Wikipedia exists. They are a key group to keep happy as they are key to making and maintaining the content that raises the funds that keeps the lights on :-) Doc James (talk · contribs · email) (if I write on your page reply on mine) 15:16, 2 July 2013 (UTC)
This is simply wierd. One of the most competent, helpful, technically proficient and all-round great editors I intersect with quite frequently in the six years I've been an editor is User:WhatamIdoing - yesterday I discovered quite by accident that she is a woman. Just off the top of my head some other great editors I interact with regularly who I know happen to be female are User:SarahStierch, User:LauraHale, User:HelenOnline and User:Anne Delong - does it in any way affect how I interact with them, not in the slightest. However if sexism on WP is actually real may I offer a simple solution: Use a gender-neutral username and unless you tell, nobody will ever know - thus it cannot even become an issue. On the internet nobody knows you're a dog or "Don't ask, don't tell". Roger (Dodger67) (talk) 13:53, 3 July 2013 (UTC)
WhatamIdoing's gender is not a secret, it's shown in her userboxes. Occasionally, people use gender-specific pronouns in comments about myself, and it's amusing to spot which ones get it wrong. I never correct them. --Redrose64 (talk) 15:16, 3 July 2013 (UTC)
Those people might look into {{subst:gender}}... --NYKevin 16:43, 3 July 2013 (UTC)

-- "Don't ask, don't tell" leads to the ghetto and is as bad an idea as "let's make a simple editor for people we consider simple" and then specifying which subsets are being considered simple. Both are controlling statements. However the entire situation may be based on false premises. Has anyone considered that the drop off in new editors and decline in time spent editing is more likely a product of several factors including (a) the current employment and economic problems; (b) the project being more complete with less opportunity for easy contributions; and (c) the speed of reversion of anonymous or new editors' attempts at contribution; than assumptions of ability based on gender? Ellin Beltz (talk) 15:31, 3 July 2013 (UTC)

I would say that in the case of (a) it's the opposite. Lack of employment gives me more time for editing, not less; and as for economics, it's pretty much free. I already had the PC before I lost my job, and my broadband costs GBP 6.49 per month - but even without those, I'd still be able to use the IT facilities at the public library for no charge (unless I want to print something in colour). --Redrose64 (talk) 16:09, 3 July 2013 (UTC)
I'm pretty sure it's (b) primarily. Which means the encylopedia is mature and becoming steadily more stable, which means (by extension) that the "drop-off" is a good thing. But the Chicken Littles who declare the sky is falling have gotten "we have to do something about EDITOR RETENTION and RECRUITMENT omg!" established as Holy Writ. - The Bushranger One ping only 23:14, 3 July 2013 (UTC)
Less than one percent of the articles have passed either GA or FA so still a lot of work to do. Much of the easy work however is done. And we still need editors to review edits and revert vandalism. I guess the really question is "how to we determine the reason for the decline in editor numbers?" One argument against the "easy work is done" hypothesis is that editor numbers have slowed / decreased in many languages which are far from complete. Doc James (talk · contribs · email) (if I write on your page reply on mine) 00:28, 4 July 2013 (UTC)

Take care about extending this to other namespaces

I need to point out that, while I do support the rollout to main space (barring massive bugs), rolling out to any other namespace could be horrifically problematic.

For example, several key processes - AfD, WP:FPC, and so on depend on users filling out templates, and have instructions on how to fill them out, as both comments in the to-be-filled-out template.

All these guides would break horrifically were Visual editor rolled out to the Wikipedia namespace. Talk namespace could potentially screw up WP:GAN, and Template namespace... is just a horrifically bad idea in 99% of cases.

Adam Cuerden (talk) 01:00, 2 July 2013 (UTC)

Rest assured, there are no plans now or in the immediate future to use VisualEditor outside of the article space and the User space. Keegan (WMF) (talk) 01:36, 2 July 2013 (UTC)
Yep. The one example I can think of is as part of Flow, and that's an entirely different ballgame (and one where we've plotted out things like GAN problems). Okeyes (WMF) (talk) 06:50, 2 July 2013 (UTC)

More importantly, we expect newbies to potentially discuss their contributions (made with the VisualEditor) on talk pages... using wiki markup. This is counterproductive, as now they have two editing interfaces to learn. (Same goes with Flow.) MER-C 09:08, 2 July 2013 (UTC)

I'm slightly confused; Flow will involve the VE, so surely that solves for that problem? And I agree, they're meant to discuss their contributions, but that requires them to make contributions. Having a vector for people to do so and get somewhat hooked is A Good Thing - learning markup can come later in the workflow than it does now. Okeyes (WMF) (talk) 09:11, 2 July 2013 (UTC)
I think that MER-C means that today newbies will have to learn two systems to participate fully on all pages.
This search suggests that they make about 14 edits to the article space for every 1 edit to an article's Talk: page. If that's distributed evenly, and if we assume that these new accounts don't make many edits, then it might be the case that 10% or so of them actually need to use both systems now. Whatamidoing (WMF) (talk) 10:10, 2 July 2013 (UTC)
Yep. Add Wikipedia and Wikipedia talk (WP:AFC) to that list as well. MER-C 11:03, 3 July 2013 (UTC)
Just wanted to add this, too! Especially in long discussions (as on this page) it can become difficult to insert a comment at the right place in a discussion (one has to search twice in the end, once when reading and once in the Wikitext when editing in the comment). Therefore having VE enabled on some Help and Project pages might be very useful, too. However there are many places in Wikipedia namespace were usage of VE is impossible at this time (e.g. WP:GL were <gallery> syntax is heavily used). So we can't blindly activate it or need an opt-out per page (e.g. a magic word like __NOVE__). --Patrick87 (talk) 11:18, 3 July 2013 (UTC)

Visual editor - post edit notice

Anyone know the css hack to stop the "Your changes to . . . have been saved" box appear after a VE edit is saved? I already have the .postedit { display: none;} hack for this in source editor in my css file NtheP (talk) 21:51, 2 July 2013 (UTC)

There's no way to distinguish this from any other jsMessage notification using CSS. A JavaScript hack would be possible, but it would be a lot easier if the jsMessage call gave a parameter for the id. Any devs? πr2 (t • c) 23:33, 2 July 2013 (UTC)
Per this, it will be hidden by existing CSS when two changes are deployed. πr2 (t • c) 00:49, 3 July 2013 (UTC)
Thanks, have to start watching the deployment schedule. NtheP (talk) 11:29, 3 July 2013 (UTC)

Hideous new edit crap

Is there any way an editor can disable this ridiculous and abhorrent direct edit rubbish? It is without doubt the single most egregious piece of crap that has ever been foisted upon Wikipedia editors - it won't allow you to link properly, nor to format, and - worst of all - its position makes it seem to be the default (it is certainly in the position that regular editors would automatically click to find a sane form of editing. This is the sort of louse-ridden piece of sodden crud you would expect Zuckerberg to suddenly launch on Facebook - not what would be expected on Wikipedia, whose developers should have known better. Be grateful that I decided to wait a while before posting this query here, it has calmed me down to the point where I can talk mildly about this noxious heap of festering cack. Were it not for that I would let loose with exactly how I feel about it. Surely, surely, there must be some kind of monobook coding that can rid my sight of its putrescence? Grutness...wha? 14:36, 3 July 2013 (UTC)

PS, Please don't take my comments above too literally. I actually think it's far worse than my post above suggests. Grutness...wha? 14:38, 3 July 2013 (UTC)
Having that weird semi-editing mode as the default certainly is a problem. North8000 (talk) 14:42, 3 July 2013 (UTC)
You can select "Remove VisualEditor from the user interface" at Special:Preferences#mw-prefsection-gadgets. It will still load the code with the associated performance issues on slow connections, but at least you shouldn't see it. PrimeHunter (talk) 14:46, 3 July 2013 (UTC)
Aaaahhh. Thank you! I'll again be able to edit Wikipedia without the temptation of hurling my laptop out the nearest window! Grutness...wha? 15:01, 3 July 2013 (UTC)
Or use the most popular browser in the US - Internet Explorer - Wikipedia always deals with it last, if ever - You can't have Visual Editor on IE even if you want it Arjayay (talk) 15:10, 3 July 2013 (UTC)
I believe that the VE devs were really trying to get IE10 support in there, but had to back it out at the last moment due to several heavy content corruption bugs. IE9 and IE10 support are still planned. —TheDJ (talk • contribs) 17:04, 3 July 2013 (UTC)
Or Opera: I have the one that shows "Version 12.15 Build 1748 Platform Win32 System Windows XP Browser identification Opera/9.80 (Windows NT 5.1; Edition IBIS) Presto/2.12.388 Version/12.15", which is apparently the latest version ("Help → Check for Updates" reports "You are using the latest version of Opera") and I don't get VisualEditor on any page - all the [edit] links are for the traditional Wiki editor. --Redrose64 (talk) 15:27, 3 July 2013 (UTC)
There are several major bugs that are currently blocking deployment for Opera browsers. Since Opera usage is extremely low, these issues currently don't have priority. —TheDJ (talk • contribs) 17:04, 3 July 2013 (UTC)
I wasn't complaining - I was pointing out that for those people who don't want the VE experience, using Opera is one way of avoiding it. --Redrose64 (talk) 18:32, 3 July 2013 (UTC)
Regarding: It will still load the code with the associated performance issues on slow connections, but at least you shouldn't see it.
Unless you actually use VisualEditor (by clicking "Edit" with VE enabled), the JavaScript footprint is now about 4KB. So the performance footprint should be negligible if you don't use it.--Eloquence* 05:30, 4 July 2013 (UTC)
Hm. "Visual editor or IE" sounds a bit like "which Hell do you want to spend eternity in?" I'll stick with the simple preference checkbox, thanks. Grutness...wha? 01:26, 4 July 2013 (UTC)

Edit tag on recent changes patrol

A small gripe: is the "tag:visual editor" thing always going to show up with these edits? The only tags that came up before were ones like "possible vandalism" , "changing height and weight" , "possible cut and paste recreation", "repeating characters" etc. These generally served as useful red flags for potential problem edits for patrollers. Now, recent changes patrol is flooded with "tag", most of them visual editor ones, 90% of which are unproblematic, making it much harder to spot genuine problem edits. Is there a purpose or rationale behind that, especially if its use by more editors is being encouraged? Valenciano (talk) 21:48, 3 July 2013 (UTC)

Wikipedia:VisualEditor/Feedback#Tag: visual editor, also Wikipedia:VisualEditor/Feedback#Note on usage --Redrose64 (talk) 22:17, 3 July 2013 (UTC)
I just looked at 500 articlespace edits (via recent changes); there were 13 edits (2.6%) that were tagged as being done by visual editor. That doesn't look like "flooding" to me. And I suspect that as less experienced editors find out how problematical VE (still) is, the percentage will decrease. -- John Broughton (♫♫) 05:13, 4 July 2013 (UTC)

Universal Language Selector will be enabled on July 2, 2013

On July 2, 2013, Universal Language Selector (ULS) will be enabled on this wiki. The ULS provides a flexible way to configure and deliver language settings like interface language, fonts, and input methods (keyboard mappings). Making it available here is Phase 4 of making ULS available in all Wikimedia wikis. Compared to other Wikimedia wikis, on English language Wikipedia input methods will be disabled by default.

Please read the announcement on Meta-Wiki for more information. Siebrand Mazeland 08:15, 26 June 2013 (UTC)

Just a "stupid" question: What are all these settings actually good for? I mean the interface language can be changed from settings, the input language will be disabled if I understand correctly and the "fonts" section is somehow misplaced (how is this a language setting?). Don't want to bug you, but I'm just always wondering on every Wiki that has ULS already activated what I should actually do with it (can one disable it?). --Patrick87 (talk) 09:45, 26 June 2013 (UTC)
Well, I used this CSS in my monobook.css to hide a bit of it (if you use the Vector skin, I think this will also work in vector.css, though I've not checked). I'm not sure what it's for either – I think it does something useful if you use a non-Latin script. – PartTimeGnome (talk | contribs) 21:18, 26 June 2013 (UTC)
Since the whole thing is loaded using JavaScript I'd want to correctly deactivate it (not just hide it) to save resources. When only hiding ULS it still loads in background. And even if it might be fast it accumulates with every bit of JavaScript added. Have you tried lately to load a page, once with JavaScript enabled and once with JavaScript disabled? You'd be surprised by the improvement (and the flickering the things loaded by JavaScript in pieces actually create). --Patrick87 (talk) 21:45, 26 June 2013 (UTC)
Yes, that is one of the reasons I have JavaScript disabled... My CSS just hides a link that is rather pointless without the associated JS. – PartTimeGnome (talk | contribs) 22:35, 26 June 2013 (UTC)
It assists you if you edit in multiple languages, contribute in non-Latin scripts, have problems entering text in your chosen language via a conventional keyboard, and so on. If you only ever write in English on English wikis, it won't be of much use, but you can rest easy knowing that others are helped by it (sometimes very drastically). - Jarry1250 [Vacation needed] 16:30, 30 June 2013 (UTC)
Yes, I totally understand this is helpful for others. I'm afraid those who are not using it have to overlook it for the time being, since there is currently no possibility to turn it off. There are two requests in bugzilla though (bugzilla:46306, bugzilla:46744) regarding the issue. --Patrick87 (talk) 17:15, 30 June 2013 (UTC)

Universal Language Selector will be enabled tomorrow (2013-07-02 08:00-09:00 UTC)

This is a repeat of an earlier announcement here in WP:TVP.

On July 2, 2013, between 08:00 and 09:00 UTC Universal Language Selector (ULS) will be enabled on this wiki. The ULS provides a flexible way to configure and deliver language settings like interface language, fonts, and input methods (keyboard mappings). Making it available here is Phase 4 of making ULS available in all Wikimedia wikis. Compared to other Wikimedia wikis, on English language Wikipedia input methods will be disabled by default.

Please read the announcement on Meta-Wiki for more information. Siebrand (talk) 14:28, 1 July 2013 (UTC)

This just happened in the past few minutes. Siebrand (talk) 08:20, 2 July 2013 (UTC)

Universal Language Selector will be enabled on 2013-07-09 on other wikis

On July 9, 2013, Universal Language Selector (ULS) will be enabled on this other wikis. The ULS provides a flexible way to configure and deliver language settings like interface language, fonts, and input methods (keyboard mappings). Making it available here is the last phase of making ULS available on all Wikimedia wikis.

Please read the announcement on Meta-Wiki for more information. Siebrand 12:21, 4 July 2013 (UTC) (via Global message delivery).

It wasn't enabled already? πr2 (t • c) 13:47, 4 July 2013 (UTC)
I thought it was deployed on 2 July - which is also what mw:Universal Language Selector/Deployment/Planning says. NtheP (talk) 13:58, 4 July 2013 (UTC)
Yes, the above message (globally delivered by EdwardsBot) is only meant for the other language Wikipedias, where ULS is not yet active.
Sad part is, that we can't disable ULS in our preferences, even if we don't need it – the same bollocks as with VisualEditor. Although there is notable demand for it (see bugzilla:46306)!
What makes the whole thing much worse is the fact, that in this case WMF did not even have the guts to admit they needed involuntary beta testers as it seems to be the case with VisualEditor. They just gave no reason at all as to why this feature is compulsory and closed the linked bug as "WONTFIX" without a comment. --Patrick87 (talk) 14:07, 4 July 2013 (UTC)
@Patrick87: Did you really mean bug 50612? πr2 (t • c) 14:09, 4 July 2013 (UTC)
No, sorry. bugzilla:46306 is the correct bug. --Patrick87 (talk) 14:23, 4 July 2013 (UTC)

Problem is VE as default

First off, I pretty much agree with the other women here who have expressed variants on "how condescending it is to assume that women are too stupid to use wiki-markup" I'd also suggest that nastiness in general (not inherently gender-based) is often more of a barrier to women than to men. (My husband and I have often discussed how men talking to men often have a more combative conversational style and stay friends for decades, whereas a lot of women take any conflict with other women as the end of the world and end the friendship). But more to the point, VE is not ready for prime time as far as being able to add references and do a lot of critical formatting tasks without, basically, having to learn a whole new interface that is slower, more mouse clicks, and isn't really any easier than the old one; just different (reminds me of the latest "not-improvement" in Word; I hate replacing keystrokes with buttons, slows me down). My thought is that is should NOT be the "edit this page" default. Instead, I would recommend that the two tabs be labeled something like "easy edit" (for VE) and "edit source" (for what we are already all used to). Perhaps that could be a compromise to avoid test edits clogging our watchlists while the bugs are worked on. Montanabw(talk) 17:45, 2 July 2013 (UTC)

I agree and I have been telling the developers for weeks it wasn't ready. I think the bigger problem is the WMF doesn't seem to care what we as editors think. They have this mentality and attitude that they know what we want and need and anyone who complains just hates change. That is the true problem. Kumioko (talk) 17:52, 2 July 2013 (UTC)
Something here needs to change. The WMF cannot be allowed to ram change down our throats. I think the best course of action is for them to immediatly implement an easy opt-out function, via sitewide banner and admit they made a mistake here. ★★RetroLord★★ 18:07, 2 July 2013 (UTC)
Good luck. Kumioko (talk) 18:21, 2 July 2013 (UTC)

Over 300 errors have been reported so far. That is far from ready. SL93 (talk) 22:24, 2 July 2013 (UTC)

Where's the "over 300" number coming from - bugzilla? Okeyes (WMF) (talk) 06:26, 3 July 2013 (UTC)
I haven't seen any assertions that women are too stupid to learn wikimarkup. I have, however, seen some reasonable evidence in the past that says women are less likely than men to want to spend their limited leisure time learning something that can only be used here, because they have other things to do that are more important to them.
We could make the same claim in other ways: Neurotypical people aren't "too stupid to learn wikimarkup", but our experience indicates that they are less likely to bother learning it than our many productive editors with Asperger's syndrome.
Similarly, many of us have been directly told by various subject-matter experts that they can't be bothered to learn wikimarkup. I expect that most of us won't say that university professors, doctors, and scientists are "too stupid to learn wikimarkup"—but my e-mail inbox still gets messages from people like this, requesting that I fix some error or expand some article, because they don't understand wikimarkup and don't want to waste time learning it.
If we're not offended that many busy people of both genders don't want to waste time learning wikimarkup, then why should we be offended by the idea that many women—the gender whom time-use surveys consistently report as having the least amount of free time—are too busy to bother with it? If we're hopeful that VisualEditor will get more busy doctors and professors improving articles (and we are), then why are we offended at the idea that it might get more busy women improving articles? WhatamIdoing (talk) 09:18, 3 July 2013 (UTC)
If it makes it any better, I am more offended that this was rolled out with so many problems. Over 300 errors or less. It doesn't matter. SL93 (talk) 15:39, 3 July 2013 (UTC)
It is true that many busy would-be editors don't want to learn Wiki markup. (Information technology engineers are an exception.) However, a bug-loaded editor that is meant to be easy to use but often does not work should not have been shoved at editors without better testing. New editors are just as likely to abandon the encyclopedia because the visual editor "sucks" as because they don't want to learn to use Wiki markup. Robert McClenon (talk) 00:37, 4 July 2013 (UTC)
When we get the results of the A/B testing back, we should know the answer to that question, rather than having to speculate about what effect it has on new editors. Whatamidoing (WMF) (talk) 14:13, 4 July 2013 (UTC)
If you don't have the results of the A/B testing, why is it being rolled out? Logically, you should wait until the test results are in. - Bilby (talk) 15:24, 4 July 2013 (UTC)
I hear that they are processing the initial results of the A/B test now, and that they will be able to use that as they decide whether to offer VisualEditor to unregistered users next week (as originally planned). If, for example, the test results showed that newbies using VisualEditor were far more likely to get blocked for spamming, then I believe that they intend to postpone the conversion for IP editors. If, on the other hand, it showed that newbies using VisualEditor were far less likely to get blocked for spamming, then that would encourage them to make the change as scheduled (assuming all else is equal; if there are technical reasons to avoid it, then that would obviously matter, too). Whatamidoing (WMF) (talk) 20:42, 4 July 2013 (UTC)
While it is good that this is being considered before being rolled out to IPs, it has already been rolled out to everyone who creates a new account. - Bilby (talk) 00:27, 5 July 2013 (UTC)

I tried using the new 'Thank' feature for the first time today, and it didn't seem to work in IE10. Is this a known issue? Is this being worked on? IE is one the most popular browsers in the world and should be supported. A Quest For Knowledge (talk) 21:53, 2 July 2013 (UTC)

[60] You appear to be thanking people. It uses js, so make sure that's enabled. I think then you'll see a confirmation. May be related to bugzilla:49161. Killiondude (talk) 21:59, 2 July 2013 (UTC)
I switched to Chrome. I don't think it's related to bugzilla:49161 as JavaScript is enabled in my IE10. A Quest For Knowledge (talk) 22:02, 2 July 2013 (UTC)
The problem you are reporting sounds like a potential issue in the code of the "Thanks" software. If the problem is reproducible, it would be nice if somebody who has this issue could send the software bug to the 'Bugzilla' bug tracker by following the instructions How to report a bug, providing potential javascript error feedback and creating a ticket here. 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:58, 3 July 2013 (UTC)
@A Quest For Knowledge: I was just near an IE10 machine and tested this functionality. It is working just fine for me. —TheDJ (talk • contribs) 17:20, 3 July 2013 (UTC)
@TheDJ: Weird. I just tried it again, and it did not work for me. Are you using Win7 or Win8? I'm on Win8. I have 2 other Win8 machines I can test this with. A Quest For Knowledge (talk) 19:41, 3 July 2013 (UTC)
Windows 7, but perhaps I can try on Windows 8 at work tomorrow. —TheDJ (talk • contribs) 20:20, 3 July 2013 (UTC)
Now tested on Windows 8 with IE10 (vector and monobook) All these combinations work for me. Perhaps you have some broken JS installed in Special:MyPage/myskin.js or a Gadget is malfunctioning ? Other than that I have no explanation. —TheDJ (talk • contribs) 12:29, 4 July 2013 (UTC)

Tool Labs index

So the toolserver has shut down and all my favourite tools have stopped working. How do I discover if there are alternatives available on Tool Labs and how to invoke them? Is there some kind of index or site map? SpinningSpark 09:49, 3 July 2013 (UTC)

There is mw:Toolserver/List_of_Tools linked from mw:Wikimedia_Labs/Tool_Labs/Roadmap_en but that might not be up to date. For general info, see https://blog.wikimedia.org/2013/05/30/preparing-for-the-migration-from-the-wikimedia-toolserver-to-tool-labs/ for the latest state and plans. --AKlapper (WMF) (talk) 10:02, 3 July 2013 (UTC)
That's a pretty useless list from the point of view of a user (and the other links aren't aimed at users at all). Only a tiny fraction of the listed tools has a status of anything besides "unknown" and those that do do not have any information on how the tool might be used. What I need is a list of what is actually available on Tool Labs and links to usage documentation, not a list of exactly how badly the migration from toolserver has been conducted. SpinningSpark 10:31, 3 July 2013 (UTC)
You can open all links in http://tools.wmflabs.org/ in your tabs and go on hunt, or find the most popular tools at http://tools.wmflabs.org/awstats/cgi-bin/awstats.pl
Only a minuscule fraction of the tools has moved so far anyway. Your best option, currently, seems to be to ask individual Toolserver tool authors to add an .htaccess rule to redirect to Tool Labs equivalents if existent. --Nemo 10:44, 3 July 2013 (UTC)
I don't think "minuscule" is accurate since somewhere between a fourth and a third of tools have been moved or so. Part of the problem with trying to find has X been moved is that there has never been an authoritative list of what runs on the toolserver and who maintains them – so it's often not even possible to find out whom to ask. — MPelletier (WMF) (talk) 12:33, 4 July 2013 (UTC)
Ah, probably best to send a note to Jarry1250 (talk · contribs) then. --Redrose64 (talk) 14:43, 3 July 2013 (UTC)
Tool migration is planned when I get some free time :) I'm make sure I do the CIDR tool as well (or at least that someone does; IIRC it is a fork of another tool that went AWOL). The Toolserver itself has a shelf life of slightly less than 18 months, though outages will remain a persistent feature. - Jarry1250 [Vacation needed] 19:31, 3 July 2013 (UTC)

Disappearing edit tab

While an article is loading, there is an "edit this page" tab along the top. When the article finishes loading, it disappears. When I go to history, it reappears while the history loads, then disappears again. This means I can only edit the page by using the section edit links or by quickly hitting the "edit this page" tab on the top while the article is still loading. As far as I can tell, this happens in only in article space and user space (not user talk, or any other namespace that I've noticed). I suspect the wonderful VisualEditor is the culprit, or possibly a bug in the "remove VisualEditor" gadget, which I have enabled. A secondary issue: since when is the tab labeled "edit this page"? As far as I can remember, it has always just been "edit", although it's possible that I am misremembering. My browser is Firefox 6.0 with the Monobook skin. Thanks. --Bongwarrior (talk) 19:21, 3 July 2013 (UTC)

The tab is "Edit" in the default Vector skin but I think it has always been "edit this page" in MonoBook. Other methods to edit the whole page include manually adding ?action=edit to the url (or &action=edit if there already is a ?), or starting a section edit without VisualEditor and then removing the section number from the end of the url. But these workarounds are obviously far from ideal. What happens if you disable the "remove VisualEditor" gadget? There may be compatibility issues with some browser versions. PrimeHunter (talk) 20:19, 3 July 2013 (UTC)
Ah. When I disable the gadget, the problem goes away. Somewhat oddly, still no VisualEditor for me even with the gadget disabled; I'm guessing that my particular browser doesn't support VE, so it doesn't show up? I noticed on the day it was rolled out that my browser was trying to start VisualEditor without success, then a few hours later it didn't even bother; this was before I had enabled the "remove" gadget, I think, so maybe one of the developers had made a tweak shortly after rollout. Thanks for the suggestion. --Bongwarrior (talk) 21:36, 3 July 2013 (UTC)
That's what I had to do; somehow my options had been mucked with to allow the enhanced editor to appear when the VE was turned on, which I didn't like when it was rolled out two years ago (on Opera 12.15) because I'm so used to RefToolbar 1 that I didn't want to change. I was trying to get my edit button back at the same time. Nate • (chatter) 21:57, 3 July 2013 (UTC)
Yeah, when your browser is on the VE blacklist, if you also have the VE-disabling gadget ticked, it'll do that on some pages. Not all, bizzarely. - The Bushranger One ping only 23:02, 3 July 2013 (UTC)
I think I have fixed this problem. —TheDJ (talk • contribs) 09:44, 4 July 2013 (UTC)

I had hidden the VE using the thing in gadgets, but the two tabs (edit and edit source) have just reappeared. SlimVirgin (talk) 23:49, 3 July 2013 (UTC)

Same thing happened to me (Firefox 22 on Windows XP). Nothing (including the killer script) seems to get rid of the thing. Tassedethe (talk) —Preceding undated comment added 00:03, 4 July 2013 (UTC
Same thing has just happened here and slowed things to a crawl. Keith D (talk) 00:04, 4 July 2013 (UTC)
Same here too. *sigh*. Jguy TalkDone 00:06, 4 July 2013 (UTC)
Crosspost from @Okeyes (WMF):
So apparently this is the result of changes to make the loading of VE smaller; on page load, it's gone down from 110kb-ish to 4kb ish, 
but this has resulted in some changes not reflected in MatMaRex's gadget. I understand he was aware of these changes, 
so hopefully they can be fixed. Okeyes (WMF) (talk) 00:12, 4 July 2013 (UTC)
Thanks Jguy. I'd note that I am, obviously, pretty frustrated about this. I'm hoping for a fix soon (early next week? later this one?) - in the meantime, I think people will have to get used to hitting 'edit source' :/. Okeyes (WMF) (talk) 00:23, 4 July 2013 (UTC)
Colour me incorrect - the opt-out gadget should right now be fixed! Credit to User:Jamesofur. Okeyes (WMF) (talk) 00:38, 4 July 2013 (UTC)
Aye! I see the fix now. Thanks! Jguy TalkDone 01:12, 4 July 2013 (UTC)

Named refs

I presume this is a VE result, since I haven't seen this before and now quite regularly: can the ref names be made slightly less uninformative and strange than what is done e.g. here? ref name ":0" and ref name ":1" are not really useful (or good looking), and we have bots that do a better jon of inventing names than this. Perhaps providing an option that people can give the names they want? In the example given, why does ref 41 get a reference name? It is used only once. This seems to be some automated VE thing gone wrong (well, not an actual error like the ones above, but rather annoying busybody work anyway). It would also be very useful if, when you change e.g. ref 1 in VE, that you get a message stating that it is a named ref used in multiple locations, and whether you want your changes to apply to one location of that ref or to all of them. Since VE is seemingly capable of finding identocal refs, it can't be too hard to add such a message surely? Fram (talk) 12:42, 4 July 2013 (UTC)

Does VE do this? The diff you gave has no "VE" tag in the es. Also, in a test edit I could not get VE to come up with a ref name like this. -DePiep (talk) 09:48, 5 July 2013 (UTC)
Tags are not part of the edit summary and are not shown in diffs (bugzilla:25824 and bugzilla:49602 have requests). The tag can for example be seen in the page history.[61] PrimeHunter (talk) 10:16, 5 July 2013 (UTC)
Indeed. And I'm pretty certain that it is a VE thing, I hadn't seen any of those before, and now they are quite regular appearances in VE edits. No idea what one needs to do to create them, which set of circumstances dictates this, but it is rather obvious that VE does this, just like VE feels that named refs now have to have quotation marks around the ref name, even though that is in reality only needed for multi-word ref names. Sometimes VE behaves like a bad version of AWB, which is ad since we already have a good version of it... Fram (talk) 11:18, 5 July 2013 (UTC)
Fair enough. I rest my case. -DePiep (talk) 11:31, 5 July 2013 (UTC)
Another example: [62] — Preceding unsigned comment added by Fram (talk • contribs) 13:47, 5 July 2013 (UTC)

Overlapping icons

Can someone have a look at gene? For me, the padlock and speaker icons (for protection and the spoken version of the article, respectively) are overlapping and look very strange. --NYKevin 15:53, 3 July 2013 (UTC)

I see it too, but it shouldn't happen. From {{pp-meta}}: "This template uses a position that does not collide with icons such as the "Featured Article" star, the "Spoken Wikipedia" icon, or other top-right-hand-corner icons." Seems like a bug of some sort... :/ Theopolisme (talk) 16:14, 3 July 2013 (UTC)
It's because it is using Pending Changes protection and because @Mr. Stradivarius: changed the position of the lock icon in those cases. Which he shouldn't have, since there is only ONE allowed position for lock icons in the current system. I think the intent was to show that two types of protection were in effect for an article, but since we already have the FR dropdown in the top, I don't see why we need a separate lock icon for PC to begin with. —TheDJ (talk • contribs) 16:55, 3 July 2013 (UTC)
I copied the icon location code from the old version of pp-pc1, and didn't give clashes with other icons too much thought. That was obviously an error - my apologies about that. The {{pp-pc1}} template has been discussed at TfD with a result of no consensus, but it would probably be worth nominating it again. In the previous discussion it wasn't made clear that there is no possible location for the icon that would avoid clashes, so that information may change how people vote the second time round. — Mr. Stradivarius ♪ talk ♪ 22:20, 3 July 2013 (UTC)
Are there any pages currently protected under both pending changes and normal protection? Theopolisme (talk) 00:22, 4 July 2013 (UTC)
I haven't checked to see if there are any now, but it is a regular occurrence. I myself have often semi-protected a page for a few days, and at the same time given it pending changes protection for a longer period. I have found that this is a good way to deal with pages which have had a recent vandalism spike but that also have long-term but infrequent vandalism problems. In any case, if we are going to keep the pending changes icons then we should probably disable their being displayed if the page is also under a different form of protection. I'll have a look at the {{pp-meta}} code later on to see if this can be done easily. — Mr. Stradivarius on tour ♪ talk ♪ 04:22, 4 July 2013 (UTC)
It looks like the fix to {{pp-meta}} wouldn't be trivial - it would require at least some restructuring of the main template logic. Probably the whole thing needs rewriting in Lua anyway, so rather than wrestle with that template code I think it would be better just to port it to Lua. I'll add that to my list of things to do... — Mr. Stradivarius ♪ talk ♪ 11:29, 4 July 2013 (UTC)
You are one of our resident Lua ninjas... :) Theopolisme (talk) 07:32, 5 July 2013 (UTC)
Couldn't you just put the {{pp-semi}} on top of the {{pp-pc1}}, so the latter is not visible at all? It seems to me that a page with both will effectively behave like a page that's only semi-protected, so the readers don't actually need to see the white lock. --NYKevin 17:30, 5 July 2013 (UTC)

Inputbox for moving userspace articles straight to articlespace

From this help desk thread, I'd like an inputbox that sends User:Launchballer/{{{1}}} ({{{1}}} being the text I type into it) to {{{1}}}.--Launchballer 09:50, 4 July 2013 (UTC)

Since this involves moving pages, it seems like it'd need to be a separate user script. Theopolisme (talk) 07:30, 5 July 2013 (UTC)

Monobook watchlist css

I find the lines in the watchlist when using Monbook look squeezed together. What css do I need to use to change the row height to say 150%? NtheP (talk) 21:47, 4 July 2013 (UTC)

Strike this, I think I've solved it myself. Might not the be most elegant way but it appears to work. NtheP (talk) 13:32, 5 July 2013 (UTC)

Archive indexing

Is there an alternative to HBC Archive Indexerbot which it seems is no longer running? SpinningSpark 10:47, 6 July 2013 (UTC)

Er, yes. --Redrose64 (talk) 11:08, 6 July 2013 (UTC)
So why has Legobot not indexed the archives at Talk:Printed circuit board, set up on 14 June? SpinningSpark 11:26, 6 July 2013 (UTC)
Legobot hasn't updated any indexes since March 25th. -- John of Reading (talk) 20:59, 6 July 2013 (UTC)
The Indexerbot page claims, as pointed out by Redrose64, that Legobot is now doing the index work, but it isn't, as John of Reading points out. So now you all understand my problem, back to the original question - is there an alternative indexing service? SpinningSpark 22:33, 6 July 2013 (UTC)
Yes, ClueBot III can do indexing along with its archiving feature. Graham87 03:03, 7 July 2013 (UTC)

Lupin anti-vandal tool

Hi,

The User:Lupin/Anti-vandal tool is not showing up here even after following the instructions under User:Lupin/Anti-vandal tool#Installation. Please check if there is an error in my js file, or something of the sort, as I have force-reloaded the page and cleared my browser cache. --JustBerry (talk) 22:41, 6 July 2013 (UTC)

how do I click on links?

How do I click on a link to, say, a footnote in a WP article? Every time I try, I get a pop-up window and so can't actually go to the footnote. — kwami (talk) 00:40, 7 July 2013 (UTC)

It works for me. What does the pop-up say? Can you click the link when you log out? What is your browser and skin? PrimeHunter (talk) 01:05, 7 July 2013 (UTC)
It's the footnote text. I use FF. Looks like it only happens when the fn is big enough to cover up the link when it pops up. Probably a bug. — kwami (talk) 02:40, 7 July 2013 (UTC)
@Kwamikagami: which version of FF ? —TheDJ (talk • contribs) 14:16, 7 July 2013 (UTC)
  • Perhaps disable Reference Tooltips: This past week, I was testing in a major public library which has IE8 browsers, and the reftag pop-ups were getting stuck on the screen. I had to set Special:Preferences, to disable the wp:Reference Tooltips, by unchecking:
[_] Reference Tooltips: Roll over any inline citation to see reference information,
      instead of having to jump away from the article text.
I am not sure why the Tooltips got stuck in IE8, but perhaps there are several other bugs with them. -Wikid77 (talk) 07:03, 7 July 2013 (UTC)
They weren't getting stuck, but the hand cursor would change to an arrow when close to the pop-ups, and as an arrow it wouldn't follow the link. — kwami (talk) 09:23, 7 July 2013 (UTC)
Wow, didn't know that script was so broken on older IE. looking... —TheDJ (talk • contribs) 13:42, 7 July 2013 (UTC)

Infobox images missing from PDFs

Tracked in Phabricator
Task T52948

On the PDF pages of books made from Wikipedia articles, a common bug is that the first image of the infobox does not appear - see [63]. As far as I have seen this is only within Category:Marvel_Comics_superheroes, but it may be more widespread. Sir Rcsprinter, Bt (orate) @ 15:34, 7 July 2013 (UTC)

I think you'll find it has left out the "fair use" images. That's probably a deliberate design choice, though I can't immediately find it documented anywhere. -- John of Reading (talk) 15:50, 7 July 2013 (UTC)

Earwig @ toolserver

Is Earwig, a copyvio checker, being migrated today to Labs? Earwig is imbedded as a tool on the DYK templates. I used it several hours ago, and it was fine. I just tried to run a copyvio on a filmography and got the message below. I've also tried running it on existing Wikipedia pages and get "This pages does not seem to exist", or an indefinite stall that goes nowhere. — Maile (talk) 21:35, 7 July 2013 (UTC) 

Error !

IndexError: list index out of range

<table id="cv-chain-table">                                        <tr>                                            <td class="cv-chain-cell">Article: <div class="cv-chain-detail"><p>${highlight_delta(result.article_chain, result.delta_chain)}</p></div></td>                                                <td class="cv-chain-cell">Source: <div class="cv-chain-detail"><p>${highlight_delta(result.source_chain, result.delta_chain)}</p></div></td>                                            </tr>                                    </table>                                </div>                            </div>                        % endif

./toolserver/copyvios/highlighter.py, line 29:

if highlights[i]:

pages/copyvios.mako, line 136:

<td class="cv-chain-cell">Source: <div class="cv-chain-detail"><p>${highlight_delta(result.source_chain, result.delta_chain)}</p></div></td>

/home/earwig/.local/solaris/lib/python2.7/site-packages/Mako-0.7.2-py2.7.egg/mako/runtime.py, line 817:

callable_(context, *args, **kwargs)
Actually, Earwig is a human being, not a tool (although I make them)! I'm aware of this bug, which seems to happen on various pages, and it's been going on for a while (i.e.nothing's changed in the past several hours). I haven't had a chance to look into it carefully yet. Do note the checker is still in fairly early development, as I've noted on its page, so errors like these are unfortunately going to be common until I have a chance to work on it. As for migration plans, I haven't started yet, since the TS isn't the source of most of my problems, but I plan on looking into it later this month or next. Thanks. — Earwig talk 22:42, 7 July 2013 (UTC)
Ha-hello, human being. Your checker is really good when it isn't doing something like above. Thanks for the info. — Maile (talk) 22:52, 7 July 2013 (UTC)

Visual Editor

Why am I being forced to use the visual editor? Where is the off switch? This thing is responsible for making loading every page insanely slow.—cyberpower ChatOnline 22:41, 2 July 2013 (UTC)

The off switch -> Special:Preferences#mw-prefsection-gadgets under "Editing". It's actually just a workaround: the JS still loads. Please read the FAQ too. More info on how to opt out is available here. In particular, see the discussion above πr2 (t • c) 22:55, 2 July 2013 (UTC)
Thanks. That makes it slightly faster, but load times are still ridiculously high.—cyberpower ChatOnline 23:11, 2 July 2013 (UTC)
@Cyberpower678: then see the discussion above about letting users really disable it, so it doesn't add JS/CSS bloat for users who don't want to use it anyway. And some of the delay might have to do with ULS, which was also enabled today. πr2 (t • c) 00:45, 3 July 2013 (UTC)
Thanks for the pointer on how to turn the wretched thing off.
It's so stinky slow that far from encouraging new editors as the WMF hopes, it will sap their will to live. :(
Did nobody check performance before this slug went live? Or are the testers all using brand new i7 PCs? --BrownHairedGirl (talk) • (contribs) 03:53, 3 July 2013 (UTC)
@BrownHairedGirl: I wish I was! I agree that the slowness is a problem, and one we need to tackle very quickly; the experience has been much improved for me, recently, but is still highly sub-optimal. Hopefully it will get better over the coming weeks as we get a handle on what goes on in a live environment rather than an opt-in deployment. Okeyes (WMF) (talk) 06:23, 3 July 2013 (UTC)
Are you sure that the cause of the slow loading time is VisualEditor and not the Universal Language Selector (which was deployed yesterday)? Whatamidoing (WMF) (talk) 09:22, 3 July 2013 (UTC)
The problem with deploying two new features in a short space of time is that if problems occur and the cause is not obvious, people are more likely to blame the one with which they have had most contact. I'm willing to bet that more people have used VE (whether by design or accident) than have used ULS; therefore, VE will get most blame. --Redrose64 (talk) 09:33, 3 July 2013 (UTC)
It's not better if it was ULS, is it? Another feature we can't disable, despite huge demand (bugzilla:46306)! I can understand why you are forcing VE on us (you need beta testers) but why force ULS on us? I never used any feature of it and I will never use one. --Patrick87 (talk) 09:52, 3 July 2013 (UTC)
It's important to be able to tell the difference, though, because no amount of fixing the VE code is going to solve a problem that's caused by ULS.
Redrose, it should be obvious that neither you nor I were in charge of the schedules.
Cyberpower, is it any better today? (Clear the cache, etc., if you want to be sure.) I believe that the amount of VE loading now when you read (not edit) a page has been reduced by 97%, so if you're still having problems, it's probably not VE. Whatamidoing (WMF) (talk) 14:06, 4 July 2013 (UTC)
It is now.—cyberpower ChatLimited Access 01:10, 9 July 2013 (UTC)

Unsound Testing Approach with Visual Editor

In my opinion as a professional software tester, the decision to roll out the Visual Editor first only in article space was unsound. It both shows a disregard by the developers of the need of the user-editors for a reliable editor, and a developer-centered software culture that discounts the importance of testing. Although the need for the Visual Editor may indeed be greatest in article space, the need for reliability of the Visual Editor is greatest in article space, which is seen by the general public. The Visual Editor should have first been rolled out for testing in user space. Think of the template given for test edits that says that if you want to experiment, use a sandbox. As it is, every edit that is meant to be a constructive edit in article space is also a test edit. The development community ought to reach out to include testers as well as developers. Robert McClenon (talk) 00:44, 4 July 2013 (UTC)

The devs have been spamming everywhere for testers, using giant notices in virtually every place possible, for a really really long time. --Yair rand (talk) 00:49, 4 July 2013 (UTC)
It was rolled out on an opt-in basis since December 2012. Okeyes (WMF) (talk) 00:50, 4 July 2013 (UTC)
I think Robert McClenon suggests it should have been in Userspace (maybe logged in users) first. Since it was available since December 2012, rolling out for Userspace could have been months earlier from now. -DePiep (talk) 01:04, 4 July 2013 (UTC)
Excellent points. On a scale of 1 to 10 regarding mechanisms for accountability to / guidance from the users, (where 0 = no accountability/guidance and 10 = enough to cause complete paralysis) accountability for stuff happening within English Wikipedia it's a "9" and for the IT side it's about a zero. Some fundamental changes in that are needed. North8000 (talk) 01:55, 4 July 2013 (UTC)

IMHO the whole testing and SW development process is biased at its roots: People, who incline to novelties, will join such testing in much greater numbers than more conservative people, who are content with the existing version and are not interested in any changes. In other words - you will never get enough preparatory feedback from editors of the second kind, they will be heard only after the change takes place. So we need to reserve in mind also enough place for those unspoken opinions of editors, who are not attracted by a possibility to test anything new. --Miaow Miaow (talk) 10:43, 4 July 2013 (UTC)

As one of those "conservative" editors, who uses IE, (merely the most used browser in the US and the second most used in the world) I haven't had a chance to comment, and won't for the forseeable future - if ever. There is no point in claiming "The devs have been spamming everywhere for testers" when such a vast number of editors (>50%?), and probably predominantly those, like me, who are less tec-savvy, were totally excluded from the test.
Please stop dismissing IE, and IE users, as a nuisance, and design systems that work with it, from the outset. Arjayay (talk) 11:01, 4 July 2013 (UTC)
Agree. Even though I have gotten IE out of my life, it is arrogance to ignore it. North8000 (talk) 11:05, 4 July 2013 (UTC)
What is the statement based on that Internet Explorer is generally ignored? It is correct that Visual Editor does not support old Internet Explorer versions (see this matrix), but latest versions (9 and 10) are supported, and software bugs are actively being worked on. --AKlapper (WMF) (talk) 11:45, 4 July 2013 (UTC)
They're not supported in the current release, Andre. But yes, IE9 and IE10 will be supported soon. And no, IE is not 50% -- IE8-10 is about 18%. [64] It's been bleeding marketshare pretty badly in the last few years.--Eloquence* 17:00, 4 July 2013 (UTC)
I was really making two related statements, one of them explicit, and one implicit. I will expand. Robert McClenon (talk) 17:42, 4 July 2013 (UTC)
I agree with Robert 100%. The way the WMF went about this rollout was completely irresponsible and frankly just plain stupid. There are too many problems with it yet. To continue to keep this software enabled is the worst possible decision the WMF could do. Whoever is in charge needs to roll it back immediately and allow testing to continue for a few more months to get the problems fixed. Kumioko (talk) 16:33, 5 July 2013 (UTC)

Lack of Formal Testing

What I didn't explicitly say is that, prior to the rollout of software by any well-managed commercial organization (or government agency), it will have been formally tested by a test organization. The test organization interacts with the developers, and is independent of the development organization, and is responsible for testing the software before the end users ever see it. Your bank does not roll out a revised user interface for the ability to pay bills on-line to its users (its depositors and borrowers) based only on the statement by the developers that they are finished development. They roll it out based on the statement by the test organization that it is ready to be deployed. A development organization that hasn't in the past had to deal with a test organization may initially find it to complicate their job, but they will then come to realize that it is better to deal with a test organization writing up bugs off-line than to face the wrath of the users. Wikipedia, partly because it is non-commercial, has not yet adopted commercial best practice, and is still using a 1980's approach of letting the developers do the testing, rather than having a separate test unit within the development organization. Developers do test, but they don't test as well as testers. (For instance, in the case of a bank system, the developers won't systematically enter letters in fields that should be dollars and cents. Testers will, to be sure that the error is handled cleanly with an error message, rather than accepting a weird numeric value, or crashing.) Wikipedia, which has volunteer developers, should also have volunteer testers in a separate branch of the development organization. If there had been a separate test unit, it would have found most of the reported bugs prior to deployment to the users. Robert McClenon (talk) 17:42, 4 July 2013 (UTC)

WMF spent months advertising VE and asking for testers. So they did want volunteer help, and to some degree they did get it, though probably no where near as systematically as a professional test organization might manage. Personally, I think the more telling development problem is that of the 298 Visual Editor bugs that are presently open on Bugzilla, about 200 of them were first reported before Visual Editor was turned on by default here. Yes, turning it on for everyone found 100 new bugs, but if one already had 200 existing bugs to fix, that seems a premature time to be launching it on everyone. Dragons flight (talk) 18:02, 4 July 2013 (UTC)
Dragon, I completely agree with your latter point. I think the number was closer to 300 just a few days before launch. I mentioned the same point you made to #wikimedia-tech and was lightly scoffed at by at least one developer who said something about the number of bugs not relating to the quality of a product. Note that I don't think this developer was on the VE team, but it was still interesting to me. Killiondude (talk) 18:10, 4 July 2013 (UTC)
Your search includes enhancement requests and bugs marked as duplicates, so it was probably somewhat an overestimate. Dragons flight (talk) 18:19, 4 July 2013 (UTC)
Oh, thank you for that pointer. I hadn't realized that. Killiondude (talk) 18:22, 4 July 2013 (UTC)
re Robert McClenon: VE is not a bank account application (especially not wrt error consequences), so your example is a bit extreme. OTOH, as I wrote earlier, the development team could deploy earlier into Userspace (with opt-out), say March, to catch some more plain early bugs. And maybe we should add the argument about the stress for the dev-team once it is out this currently big and major bugs, likely, appear. -DePiep (talk) 20:10, 4 July 2013 (UTC)
It is true that the consequences of errors are not as serious as in a bank account system, to use the example that I provided. That doesn't change the fact that development and testing should be done by separate teams, in this case of volunteers. The point that I was making is that the mindsets of developers and of testers are different. Developers test the obvious test situations, and tend to be optimistic, because they know, correctly, that they have done good work. Testers test the obvious and unobvious situations, such as thinking of mistakes that distracted users might make. Developers can be testers, and testers can be developers, but not on the same effort. My example was of something that could really happen that wasn't right. In a bank, that sort of error could result in financial hardship to customers, and then in litigation. On Wikipedia, it could result in what would be seen, for instance, as page blanking vandalism due to user error, and could cause hard feelings causing editor loss. Robert McClenon (talk) 21:05, 4 July 2013 (UTC)
So, let's get a couple of things clear here. First: we have a QA team. It's a damn good QA team, and it's totally distinct from the VisualEditor team - two completely different subdepartments working from different physical locations. The VE operates out of Features/Product, in SF; QA is led by a dude in Colorado, and is part of the Platform subdepartment. That's as far apart as you can get and still be in Engineering (we're a small org). Second: we've had testing by volunteers. The VisualEditor has been on enwiki since December 2012, on an opt-in basis, with >= 1,000 users taking it for a spin and many of them reporting (later fixed) bugs. Okeyes (WMF) (talk) 12:10, 5 July 2013 (UTC)
Actually the number of bugs related to VE are something around 500 and possibly more. Not only do you need to account for the VE section but also parsers, some under mediawiki and a couple others. All the VE bugs aren't listed under VE. It should also be mentioned that since its release only a couple days ago, more than 500 people have disabled it. Kumioko (talk) 16:36, 5 July 2013 (UTC)
The raw number of open bugs (many of which are duplicates) isn't really a good indication of software's design or implementation. After all, Mediawiki has several thousand open bugs against it, and a couple hundred just against the old editing system, and nobody's suggesting that we turn the whole thing off. We need functional improvements (Monday's update can't come too soon for me), not a particular level of activity in the bug database. Whatamidoing (WMF) (talk) 19:29, 5 July 2013 (UTC)
I appreciate the position you, Maggie, Oliver and others are in with trying to justify the VE debacle but there is a massive difference between the bugs in the Mediawiki software that is pretty well matured and this turd. I also agree that its not the volume of bugs specifically but the significance of some of them. They are major. As much as it sounds like I hate the app, I don't, I think it has a lot of potential and it will be a great asset....someday. But that day ain't today or tomorrow and probably won't be next week or next month. This is like putting an infant in the drivers seat and telling it to drive you home. Kumioko (talk) 22:41, 5 July 2013 (UTC)

Testing in User Space

Visual Editor is currently only available in article space (main space). Although it is true that the need for a more user-friendly editor is greatest in article space, the need for a "nearly bug-free" editor is also greatest in article space, which is the face that Wikipedia shows to its two most important user communities, article building editors, and readers. For that reason, far from deploying it early to that space, its deployment should have been deferred to get it "nearly bug-free". An unfortunate consequence of its initial deployment in article space is that it has been deployed only in a space where test edits are explicitly forbidden, and there is a template warning users for them. Therefore, true test editing is not permitted, and the entire user community is being used as test animals. After testing by a test organization, the Visual Editor should have been deployed to user space as a sandbox, rather than to article space, where its bugs are highly visible rather than visible, and where test edits are not permitted. The sequence of what spaces Visual Editor was deployed to was a blunder. It was a good-faith blunder, but it was a blunder. Robert McClenon (talk) 17:42, 4 July 2013 (UTC)

By way of clarification, VE is presently enabled for both article space and user space. Dragons flight (talk) 17:49, 4 July 2013 (UTC)
It should have been enabled only in user space until it was tested. Robert McClenon (talk) 18:11, 4 July 2013 (UTC)
Any developer philosophy link available? Website development can fundamentally differ from my local server environment development. -DePiep (talk) 20:16, 4 July 2013 (UTC)

Lack of volunteer testers ?

I saw several times in the answers from the VE team that they were looking for testers since last December, and they didn't get enough testing. They use this reasoning for explaining the roll-out to every registered user. But I want to point out a major element that go against this reasoning: major features like template editing and references editing were available only just before the A/B testing at the end of June, so not letting volunteers test them before being rolled out.

Before that, testers couldn't do any real test, being limited to basic wikitext (text, internal links, titles, ...). Even with this limited features several bug reports were opened that showed that VE was producing dirty diffs quite often. As this time, I saw many testers react the same way as I did :

  • Try VE on a few pages
  • See that most edits coudn't be done with VE => report that, but the answer was "it's coming"
  • Try the edits that were supposed to be possible with VE, and see that often you end up with dirty diffs => report that
  • Wait a few days for a new release to come, and start again at the first step

--NicoV (Talk on frwiki) 16:14, 5 July 2013 (UTC)

I agree NicoV, there were more than 1000 users who enabled it and could be considered testers including me. Quite a few of us told them it wasn't ready for release and it had too many problems, but they didn't listen, didn't care and went ahead anyway. So quite a few, including myself, disabled after the WMF showed they didn't care what we had to say. So, the WMF can try and convince us with bullshit excuses and justifications all they want. But the end result was we told them it wasn't ready for release and they did it anyway. So all the hate messages and complaints that are being directed at the WMF about the application are completely deserved. Kumioko (talk) 16:41, 5 July 2013 (UTC)
So, if an organisation does something you disagree with, all the individual people in it deserve abuse? Okeyes (WMF) (talk) 02:37, 6 July 2013 (UTC)
It seems that there were many volunteer editors who tried an early buggy version, didn't like it, and disabled it. As the bugs continue to be fixed, the WMF will have a challenge to educate those editors what's been fixed (and what hasn't) and ask that they retest. GoingBatty (talk) 00:51, 6 July 2013 (UTC)
Just as 9 women can't produce a baby in 1 month, testing with 1,000 volunteers who each have the experience of 100 edits is not the same as using one tester with the experience of 100,000 edits. Chris the speller yack 02:02, 6 July 2013 (UTC)
Chris, I'd invite you to look at the early archives of the feedback page and then come back and tell me that we had "1,000 volunteers with the experience of 100 edits". I'll be back in a sec, only I need to go tell PamD that she's apparently a noob. Okeyes (WMF) (talk) 02:36, 6 July 2013 (UTC)
I agree that part of the problem was inexperienced testers but that is easy to overcome with a good test plan. The bigger problem is the WMF didn't have a test plan. They just threw it out and hoped for the best. That isn't a good way to do testing anymore than the attitude that the WMF has that they know better than we do what we need and want. The sheer volume of negative discussions all over the project are a testemant to that. Kumioko (talk) 02:07, 6 July 2013 (UTC)
  • I'm sorry, Okeyes (WMF), but I'm finding your responses to be lacking information and quite bitey. I think it's pretty clear that it didn't really matter how many experienced volunteers you had in the early going, because many crucial functions of the VE weren't operational until less than 24 hours before the software became the default. Now, if that was part of the plan, then the feedback to be taken in is that it wasn't a particularly good part. If it wasn't part of the plan, then the feedback is "this shouldn't happen". Just think if you'd had a week of testing with half the volunteer testers trying out the referencing and template interfaces, and how many bugs could have been addressed before you had a large number of editors deciding to turn it off almost entirely because of the bugs. Just imagine if this had not gone live at the same time as ULS, which also had significant bugs that wound up rebounding on VE because everyone noticed VE and not ULS. These are things that can be learned and noted for future roll-outs.

    A member of the WMF team recently posted a blog[65] that focused on the opportunity to learn from "non-successes" and plans that did not go well. We need to acknowledge where things can be improved, or we are doomed to continue having the same negative responses over and over. I would have thought that there would have been more learning from the rollout of Echo/Notifications that should have been applied here, for example. People, and projects, are not expected to be perfect - but there is a reasonable expectation that we won't keep seeing the same problems time and again. Risker (talk) 02:55, 6 July 2013 (UTC)

    • @Oliver, I know its hard being the communities punching bag for this but Try not to take it personally. I very much doubt that the majority of us (ok there are probably one or 2:-)) that are directing these negative comments about VE at you, Maggie or the others. Just remember sometimes in order to be effective, truth must penetrate like an arrow...and that is likely to hurt. Kumioko (talk) 03:12, 6 July 2013 (UTC)
      • I'm sorry, but that's simply not true. You'll note we've delayed the next release by a week. This is all to do with the bugs that have been largely surfaced by polite people; it's nothing to do with truth that penetrates like an arrow. We would have come to the same decision without offensive commentary - simply in a more pleasant atmosphere. Okeyes (WMF) (talk) 03:38, 6 July 2013 (UTC)
      • Oliver, its got nothing to do with being rude either. We said weeks ago that VE wasn't ready but the WMF ignored the stupid editors and went ahead anyway. Your talking about us being rude, how do you think that made us feel to know that our opinions didn't matter. And putting it off for a week isn't going to be enough time either. All 1 week will do is allow the WMF to say we listened but really its just trying to make themselves look good for the dumb decision of releasing VE before it was ready and pissing off virtually every editor. It wasn't ready to be released, its not going to be ready in a week and it probably won't be ready in a month either. A lot of problems have been identified and that's good. But keeping it turned on just our of spite doesn't make us look bad, it makes the WMF look bad and just irritates us editors who have to fix the mess. Kumioko (talk) 19:29, 6 July 2013 (UTC)
We've had a lot of user visible changes lately, including Lua, WikiData, Echo, and VisualEditor. That's an unusually large number of user facing changes for only a few months time. Some of these deployments have been handled well, and others not so well. Personally, I'd suggest that Lua was probably the best of the four, while VisualEditor has been the weakest. All of these were deployed in a somewhat incomplete state, which seems to be standard operating procedure for WMF (though personally I'd suggest polishing things a bit more before full-scale deployments). One of the differences is that while Lua and Wikidata were missing key functionality at deployment, they largely avoided bugs that most Wikipedia editors would easily encounter. By comparison, many users will stumble over bugs in VisualEditor. I could go on comparing and contrasting these various deployments, but rather than getting buried in details, let me just acknowledge that innovation is hard. Sometimes we do it reasonably well and sometimes we do it poorly. When it works, it can make a real difference (e.g. Lua now aids most articles on Wikipedia). When it fails, it may be ignored (e.g. #property for Wikidata) or even drive users away. I do hope there are people at WMF who take the time to think about the various deployments and what has gone well vs. poorly. Because Wikipedia depends critically on a volunteer community, getting community involvement and acceptance of innovation is a key step towards ensuring success. Managing that community buy-in can be hard, but it is also an important part of ensuring the successful deployment of new features. Dragons flight (talk) 05:58, 6 July 2013 (UTC)
Yes, Dragons flight. Please keep me updated & informed. Sure VE is the hardest User-experience related of all. Still, my astonishment is about the VE process going for 6 months into trial without true process feedback. Unlike say WikiData, the User-thing was part of the task from the start. Now I'd like to hear what, tomorrow, Mondays WMF weekly meeting will do. Again saying I'ts difficult you know? -DePiep (talk) 18:50, 7 July 2013 (UTC)
Dragons, I'd say that the main theme in your list is not how well the project worked or was handled, but how many users interacted with it. Very few editors dealt with Lua, and therefore very few were bothered by its problems. Many users dealt with Echo, and more people were upset about it. But that doesn't mean that Echo was worse than Lua: IMO Echo worked better than all the others in your list at deployment and was managed much better (with the single notable failure of temporarily removing the Orange Bar of Doom on the weekend). The number of irritated users at the initial deployment speaks more to the visibility of the product than to its quality. Whatamidoing (WMF) (talk) 19:01, 8 July 2013 (UTC)
Retrieved from "https://wiki.riteme.site/w/index.php?title=Wikipedia:Village_pump_(technical)/Archive_113&oldid=1144527155"