Wikipedia:Village pump (technical)/Archive 113

From Wikipedia, the free encyclopedia
Jump to navigation Jump to search

Contents

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 (talkcontribs) 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://en.wikipedia.org/wiki/Michael_Bubl\xC3\xA9 while the correct percent encoding is http://en.wikipedia.org/wiki/Michael_Bubl%C3%A9. The 12 May list [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?

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)

"Request Feedback" link in toolbox

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://en.wikipedia.org/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 (talkcontribs) 16:57, 2 June 2013 (UTC)
I've actually written some code for removal of the block and rollback interfaces as well, and I would be happy to take some time when I have it (this week is really busy with school, summer semester is always the toughest) to re-work my code and make a script that will re-locate "stuffs" in a more user friendly fashion and upon completion of that I would be happy to make note of it (screenshot or whatever of the output) on Bugzilla and get the layout put directly into the core. To do this, I need community input as to what it "should" look like. Technical 13 (talk) 17:30, 2 June 2013 (UTC)
I don't think we need to move the button - we need to make it so that it's 2 clicks. GiantSnowman 17:34, 2 June 2013 (UTC)
I think that two clicks for something so simple that some users may actually intend to use to thank for 25-40 edits a day is too much... That being said, I'm not opposed (as mentioned on the related bugzilla) to having it so that when you click (thank) instead of it changing to (thanked) that it instead changes to (un-thank) or (de-thank) allowing you to undo it if it wasn't intentional. Technical 13 (talk) 17:57, 2 June 2013 (UTC)
The reason why clicking "edit" when you mean "undo" (or vice versa) is not an issue is because both require you to click another button before anything is saved. If you clicked the wrong one you can click your browser's "Back" button then click the one you meant. – PartTimeGnome (talk | contribs) 00:36, 3 June 2013 (UTC)
  • 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: Face-smile.svg 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

20:05, 11 June 2013 (UTC)

And Notifications and Thanks has been updated: Wikipedia_talk:Notifications#This_week.27s_update. —TheDJ (talkcontribs) 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.

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://en.wikipedia.org/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://en.wikipedia.org/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://en.wikipedia.org/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 (talkcontribs) 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 dependencyTheDJ (talkcontribs) 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

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 (talkcontribs) 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 (talkcontribs) 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 (talkcontribs) 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://en.wikipedia.org/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://en.wikipedia.org/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)

Some Google https links now http

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

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 (talkcontribs) 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 (talkcontribs) 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 (talkcontribs) 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)
  • How to change your watchlist look/behaviour, see: Wikipedia:Customizing watchlists. This assumes things are working correctly. I personally love the bolding, so you must be related to my evil in-laws :) Bgwhite (talk) 23:29, 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://en.wikipedia.org/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://en.wikipedia.org/� 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 belowTheDJ (talkcontribs) 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 (talkcontribs) 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 (talkcontribs) 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

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://en.wikipedia.org/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)
  • That should be changed email limit globally! --Tito Dutta  (talkcontributionsemail) 09:01, 11 June 2013 (UTC)
    • That's probably not easily doable until we actually finish the whole global account migration (SUL). But we should make a bugzilla for it. —TheDJ (talkcontribs) 09:16, 11 June 2013 (UTC)
      • Support making a bugzilla if that's easy enough to do now. --Синкретик (talk) 11:25, 11 June 2013 (UTC)
        • There's no need to start an entire Bugzilla just for this one issue. A single report to the existing Bugzilla will suffice. And there's no need to vote for that; just head on over to https://bugzilla.wikimedia.org/ and file the report. —Psychonaut (talk) 13:14, 11 June 2013 (UTC)
          • Yes, but they may not fulfill it due to absence of consensus. --Синкретик (talk) 13:28, 11 June 2013 (UTC)
            • I've never known the developers to check for consensus here before implementing a very reasonable feature request. If they want to gauge the demand for a feature they'll sooner look at the Bugzilla votes. —Psychonaut (talk) 15:10, 11 June 2013 (UTC)
              • Yes, that is a problem, isn't it. Users should not have to out themselves to report or vote for a bug. LeadSongDog come howl! 16:08, 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)

  • I have. --Синкретик (talk) 17:00, 11 June 2013 (UTC)
  • For the record, developers do not look at votes on bugzilla, like ever (Seriously. The vote feature is used like a watchlist for bugzilla for folks who don't like adding themselves as cc on a bug). It is preferred to gather consensus on a wiki page (and usually consensus is required for config changes. Reasonable requests get denied all the time due to lack of consensus [Usually that happens for non-english wikis though]). In regards to Синкретик's question, according to mw:Auth_systems, that would be Chris. Bawolff (talk)
    • Noted: Bawolff, In2thats12, RobLa-WMF can one of you ping/echo Chris to this discussion, I can't seem to see a link to his profile on mw: or here on w: Thanks Technical 13 (talk) 19:32, 11 June 2013 (UTC) 19:25, 11 June 2013 (UTC)
      • btw, I should clarify one thing about my previous comment. Consensus is needed for config changes generally, it is not needed for bug fixes usually (if the bug could reasonably considered to be obviously unwanted behaviour). This request may fall more in the bug fix category than the config change category. Chris's user page is mw:User:CSteipp. Bawolff (talk) 19:47, 11 June 2013 (UTC)
    • I left Chris a message on mw:User talk:CSteipp and now we just wait for a reply. Technical 13 (talk) 11:06, 12 June 2013 (UTC)
      • He's left a comment on the bug page. He doesn't oppose it. --Синкретик (talk) 13:40, 12 June 2013 (UTC)
      • [14:00] <Technical_13> Would you mind if I quote your Bugzilla reply on VPT csteipp ?
        [14:01] <csteipp> Technical_13: not at all

        For some background, the limit is currently 20 emails/user for all wikis (that
        was changed from 100 a few months back). That counter is per wiki, so a user
        could send out emails from multiple wikis to the same user, and the target
        would receive more than 20/day.

        To move this to a global throttle isn't trivial, but we could do it. It would
        fall into the general Admin Tools work.


        Technical 13 (talk) 18:25, 12 June 2013 (UTC)
        • The email system only lets me send about 1 every other day. I gave up trying to use the Email system. Kumioko (talk) 17:16, 12 June 2013 (UTC)
          • It's a bug than can be fixed if you report it in details with a new thread here. My restriction request is hardly connected to your problem. --Синкретик (talk) 06:48, 13 June 2013 (UTC)
  • No replies to the bug have been made on bugzilla last week. The developers must be very busy, maybe with SUL finalization… --Синкретик (talk) 18:47, 18 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? Face-wink.svg. 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)
I think this might relate to bugzilla:49737TheDJ (talkcontribs) 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)
    • Thanks as always, Oliver and Maggie, I'll make my bug report over there. - Dank (push to talk) 20: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

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)
  • You're very welcome Steven (WMF). That is what we do, find broken stuffs and make sure it gets documented... Technical 13 (talk) 11:13, 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 (talkcontribs) 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)
  • The only thing I can offer to suggest is to follow the instructions for {{User committed identity}} and then proceed as if your account was compromised. Just my suggestion. Technical 13 (talk) 12:03, 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?
Barnstar of Humour3.png The Barnstar of Good Humor
This is just an example!
Barnstar of Humour.svg 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)

Articles with fooian-language external links

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)

Articles with Russian-language external links

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)

wikilinks to es-it:WP:

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)

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

  • Please report all problems with Visual Editor at WP:VE/F. --Redrose64 (talk) 14:07, 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 Flag of Niger (3-2).svg 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)

Click image opens image in gallery mode?

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

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 (talkcontribs) 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 (talkcontribs) 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. Face-tongue.svg 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  (talkcontributionsemail) 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. olderwiser 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. Wer900talk 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 (talkcontribs) 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

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.

Blocked upload.jpg

.

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://en.wikipedia.org/wiki/Special:Undelete/File:Max_Irons_2012.jpg) and now the redirect takes effect and overrides the image.

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

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)

Navigation popups and Visual Editor

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 (talkcontribs) 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 (talkcontribs) 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://en.wikipedia.org/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 some, definitely. For many, maybe. It doesn't mean that we still shouldn't fix this for everybody though. Thryduulf (talk) 13:37, 21 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 Face-wink.svg). --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 (talkcontribs) 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 (talkcontribs) 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):

Colored bullets in watchlist 1.png

Colored bullets in watchlist 2.png

Colored bullets in watchlist 3.png

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 Face-wink.svg. --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 Face-wink.svg. 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://en.wikipedia.org/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 (talkcontribs) 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 (talkcontribs) 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)

Voice search

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?

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 (