Wikipedia:Village pump (technical)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

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

The technical section of the village pump is used to discuss technical issues about Wikipedia. Bugs and feature requests should be made at Bugzilla (How to report a bug). Bugs with security implications should be reported to securitywikimedia.org or filed under the "Security" product in Bugzilla.

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

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

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

A Thanks notification.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

MOVE the button

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

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

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

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

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

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

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

Tracked in Phabricator
Task T49658

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

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

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

Time limit for thanks

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

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

Better late than never! GiantSnowman 10:49, 11 June 2013 (UTC)

Suggestion about the icon

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

This is already discussed on Wikipedia talk:Notifications/Thanks#Change the i-love-you heart to something more neutral. A smiley was suggested and received positively. However there were some considerations on copyright. --Patrick87 (talk) 23:35, 12 June 2013 (UTC)

See http://www.unicode.org/charts/PDF/U1F600.pdf.

—Wavelength (talk) 23:59, 12 June 2013 (UTC)

Thanks. I'll comment there. --Tryptofish (talk) 00:25, 13 June 2013 (UTC)

X!'s Edit Counter

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

Further explanation, copied from below and edited a bit for clarity.

Currently, any editor must opt themself in to allow other editors to see additional statistics in X!'s edit counter (for that editor). These additional statistics are (a) top namespace edits and (b) monthly edit statistics. This opt-in was set up because because of a law in Germany, where the toolserver is located. Since we are migrating everything from the toolserver to Wikimedia's labs (in the U.S.), this law isn't relevant anymore.

There are editors who want to see the monthly stats and top namespace edits for everyone, not just for editors who have opted in. The question is should we allow this (by disabling opt-in) or whether we should users to still have control over what can be seen in the edit counter (by keeping opt-in). A third option is to allow users to opt-out; if they don't, then all other editors could see their full statistics.

-- John Broughton (♫♫) 18:33, 14 June 2013 (UTC)

Keep opt-in

1. Opt-out privacy is a joke, and is not privacy at all. While it's certainly not the biggest privacy violation on the Internet, I don't think people have an automatic right to view this kind of data. Oh, and as mentioned below, as long as this is hosted on the toolserver, it can't be changed. There's some German privacy law regarding "profiling of individual user's activity", which requires this kinda thing to be opt-in. --Chris 14:44, 4 June 2013 (UTC)

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

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

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

3. +1 to Chris's statement: "Opt-out privacy is a joke..." Keep this opt-in. If someone wants to use it for themselves, then it's a few clicks away. If they want to use it to peer into someone else's history, it's for that person to open that door to them. --RA (talk) 15:25, 4 June 2013 (UTC)
4. i'm surprised that this is even brought up as an option. an active editor's edit pattern can reveal way too much about them, and the idea that this data should be thrown into the public domain without them actively expressing consent is inconceivable. peace - קיפודנחש (aka kipod) (talk) 17:45, 4 June 2013 (UTC)
5. Our contributions are already public record, but for detailed analysis of our edits, which can be used to hound an editor by those who do not assume good faith of the editors intentions, should IMHO be something that should be primarily available to 'Crats or if an editor chooses to make it publicly available. Hopefully, everyone will want increased transparency of our activities, but IMHO it should be a personal choice, rather than something that one has to opt out from.--RightCowLeftCoast (talk) 17:56, 4 June 2013 (UTC)

   The really crazy/creepy folk, the ones that would engage in off-wiki hounding or outing or real life confrontations, don't need X!s tool. Those people are dedicated enough to sift through a lot more than just some graphs. Sven Manguard Wha? 17:02, 8 June 2013 (UTC)

6. The fact that some data is public but scattered, is one thing, collecting and organizing the data is something quite different, that is (good part of) the work of Intelligence agencies («intelligence gathering, [...] does not necessarily involve espionage, but often collates open-source information.», from Espionage). WP is not a espionage / intelligence agency, I'd say. - Nabla (talk) 23:07, 5 June 2013 (UTC)
7. Per Chris G. It Is Me Here ^{t / c} 17:01, 6 June 2013 (UTC)
8. Yes. This is one of the rare questions I have a gut answer to :-). The data is public, and there is nothing stopping people "rolling their own" analysis, but there is a big difference between that and Wikimedia-supported profiling and publication. Andrew Gray (talk) 19:33, 6 June 2013 (UTC)
9. Yes. The opt-in steps are easy (even I figured it out), and the privacy concerns are compelling. New editors are probably unaware of the feature, and for some this could discourage participation when they become aware. 78.26 (I'm no IP, talk to me!) 15:46, 10 June 2013 (UTC)
10. Very strong support that it should be "opt-in". There are strong privacy concerns. We can expect new users to be unaware that these counters even exist for a substantial period of time before they discover them; that is, if many of them would even discover them at all. I do not think they should be surprised about it when and if they do. This should even be being polled. It's a matter of principle. — Preceding unsigned comment added by Jason Quinn (talk • contribs) 17:39, 11 June 2013 (UTC)
11. I'm aware it's easily available through other means, but it doesn't automatically follow that it should be easily available through this tool as well. wctaiwan (talk) 07:28, 15 June 2013 (UTC)

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)

Remove opt-in completely

1. This information isn't "private". It's just a compilation of public data. Anyone who has access to the Toolserver or to the API can work this out with very little work. Treating public data as if it were private data leads people to believe that by not opting-in or by opting-out, the compilation of these statistics won't be done. It just means it won't be done by this tool. I mean, let's consider the silliness of this: shall we allow users to "opt-out" from Stalker, Max McBride's tool to compare contributions between users in order to help people detect socking? No. The issue isn't actually privacy in any meaningful sense of the term. The reason it is opt-in is to give people a feeling that they are in control of "private" information, even though it isn't private information and they aren't in control. I'd rather not give people the illusion that this information is private when it isn't. —Tom Morris (talk) 15:45, 4 June 2013 (UTC)

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

2. Yeah this. The data is publicly available, that tools shouldn't exist which compile it in a usable form seems silly. --Jayron32 17:49, 4 June 2013 (UTC)
3. The tool doesn't give you any information that isn't already on the user contribs page, seems silly to have an opt-in, or an opt-out. Though I'd support opt-out over opt-in if we must. Prodego ^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. [1] 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 ^Chat_Online 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 ^Chat_Online 15:07, 5 June 2013 (UTC)

    Heh, oops. Ansh666 20:20, 7 June 2013 (UTC)

12. Per all above. ·addshore· ^{talk to me!} 23:11, 5 June 2013 (UTC)
13. You cannot make private what has already been publicized. When each datum has been published, nothing new is revealed by summaries and aggregations that users could always perform on their own computers, if they wished. Opt-in or opt-out attempts to weave garments of mixed fibers. DavidLeighEllis (talk) 02:00, 6 June 2013 (UTC)
14. Because this information is very easy to gather from the API, which is publicly accessible, and with only very minimal coding skills. Any added privacy from an opt-in is illusory. — Carl (CBM · talk) 02:16, 6 June 2013 (UTC)
15. Per supra. Theopolisme (talk) 03:07, 6 June 2013 (UTC)
16. I don't understand how there can be a privacy violation. The pages a person has contributed to is something they should be proud of. -- ^(T) Numbermaniac _(C) 07:24, 6 June 2013 (UTC)
17. A false sense of privacy. Marcus Qwertyus (talk) 19:08, 6 June 2013 (UTC)
18. Per User:Numbermaniac, Not entirely sure how it can be considered a "privacy violation", If you don't want the edit counter being public then don't edit on WP, It's not rocket science!. ........ →Davey2010→→Talk to me!→ 00:15, 7 June 2013 (UTC)
19. This is not a privacy issue. We are all responsible for maintaining the integrity of Wikipedia. Transparency is good. Carrite (talk) 06:43, 7 June 2013 (UTC)
20. The information is already public! The only thing one needs to work a lot to find those! --Tito Dutta  (talk • contributions • email) 00:22, 8 June 2013 (UTC)
21. There isn't a real privacy concern here, and I'm someone that takes digital privacy more serious than they should. I see no reason not to remove opt-in. Sven Manguard Wha? 16:56, 8 June 2013 (UTC)
22. Suggesting an illusion of privacy with an opt-in is worse than being up front with what this data is. older ≠ wiser 17:08, 8 June 2013 (UTC)
23. Useful information, and consistent with the desire for transparency.--SPhilbrick(Talk) 13:08, 10 June 2013 (UTC)
24. Activities performed in a public place aren't private.—Kww(talk) 19:29, 11 June 2013 (UTC)
25. The information stats isn't a privacy issue as its already available and accessible to all. All this does is compile the information that anyone can already view in an easy format.Blethering Scot 19:33, 11 June 2013 (UTC)
26. I fail to see how anybody's editing history is private. On some users I've always wanted to see the detailed stats for some people but they haven't opted in yet. JayJay^{What did I do?} 00:27, 12 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 ^Chat_Online 14:10, 4 June 2013 (UTC)

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

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

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

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

  I agree that you should explain it better and also add that those with x number of edits will always be opt-out. I thought anyone could opt-out by simply deleting the page created during opt-in? Also, the options above are not clear to me. What if I wanted all editors to be automatically opt-in? Mohamed CJ (talk) 14:30, 4 June 2013 (UTC)

  @Mohamed CJ: "What if I wanted all editors to be automatically opt-in?" Then you would support the section "Remove opt-in and replace with Opt-out". That section is for making everyone automatically opted-in and they have the option to opt-out.—cyberpower ^Chat_Online 15:00, 4 June 2013 (UTC)

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

  Let me try this again. Currently, all editor are required to opt themselves in to allow everyone to see additional statistics in X!'s edit counter. These are top namespace edits and monthly edit statistics. This opt-in was setup because because of a law in Germany, which toolserver is located in. Since we are migrating to labs, there are users who wish to see other users monthly stats and top namespace without that said user being looked up to have to opt-in. Therefore all data will be readily available without said users consent. The question is should we allow this or should the user still have control over what can be seen in the edit counter, that is should opt-in be removed, or should it be kept, respectively. I'm sorry if this isn't clear either. I'm trying my best to make it clear.—cyberpower ^Chat_Online 14:57, 4 June 2013 (UTC)

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

• How is it a privacy concern? Anyone who has access to the database (any Toolserver user, say) can work out the most-edited-pages of a user by running the query by hand (or going through Special:Contributions). The reason for requiring opt-in is as much to preserve server resources as is it to give users the illusion that the public information is somehow not public. —Tom Morris (talk) 13:53, 4 June 2013 (UTC)

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

  While certainly true, it doesn't mean we should just give up any attempt at privacy. There's a big difference between anyone with access to the Toolserver (or anyone who can code) being able to work something out, and anyone who can use a web browser. --Chris 14:53, 4 June 2013 (UTC)

  Actually, it's not just anyone with access to the Toolserver. It's anyone with access to the API... which is everybody. —Tom Morris (talk) 15:39, 4 June 2013 (UTC)

  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 ^Chat_Offline 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)

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

• I am not sure what this is doing here. I don't see a comment from the user whose account X's tool is on and who would obviously have to agree to these proposed changes, and I don't see a statement from toolserver admins stating that this would be compatible with their ToS, as it was my understanding that it was for ToS purposes that this was impossible. Snowolf ^{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 ^Chat_Online 15:51, 4 June 2013 (UTC)

  I don't think it matters if it is on the Toolserver or Labs. It's still a global tool. Snowolf's point stands. Killiondude (talk) 16:22, 4 June 2013 (UTC)

  It is now completely up to the owner of the tool, as Snowolf says. This vote doesn't really matter. Prodego ^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 ^Chat_Offline 18:16, 4 June 2013 (UTC)

  Your time would be much better spent improving and maintaining tools rather than starting discussions like this. :-) If you have coding skills, I'd strongly recommend focusing on coding. We already have enough process wonkery and meta-process wonkery. --MZMcBride (talk) 22:41, 4 June 2013 (UTC)

  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 ^Chat_Offline 03:49, 6 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)

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)

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 [5] had no entries containing \x so it seems like a recent problem (some of the older lists had a limited number of \x entries). I agree it's too soon to think about creating redirects from the invalid encodings. PrimeHunter (talk) 11:21, 9 June 2013 (UTC)

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

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

Perhaps the referrers and user agents could be logged for a period, aggregated and anonymized (as well as culled of uniques)? That should give some hints as to the origin of the problem. Also, a temporary workaround could be employed using Javascript, similar to the case-sensitive fixer for some Wiktionary projects. If a browser ends up on a red title, and if the name includes some known bad encoding that can be repaired, and if a page with the correct encoding exists (via quick API call check), then (after a short delay) the location could be changed to the correct one. Eg: wikt:Dummy --Splarka (rant) 07:30, 10 June 2013 (UTC)

Passing a location to Special:Nearby?

Tracked in Phabricator
Task T51413

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

If you have Firefox then you could try https://addons.mozilla.org/en-us/firefox/addon/geolocater/ to set a location in the browser. I haven't tried it. PrimeHunter (talk) 00:57, 10 June 2013 (UTC)

i like the idea of allowing passing location to nearby (e.g. "Special:NearBy/44.12,-71.13"), which does not depend on browser at all. we could use such links in portals, on wikivoyage, and more. however, i think it makes more sense to post such a suggestion in mw:Mobile design rather than on enwiki's en:WP:VPT ... peace - קיפודנחש (aka kipod) (talk) 14:54, 10 June 2013 (UTC)

The suggestion was the first response at https://blog.wikimedia.org/2013/05/29/wikipedia-nearby-beta/. The Mobile Software Engineer Jon Robson replied: "Currently there is no option to manually insert a location but it would be trivial to add this functionality. The main complication around doing this is the design Ideally we hope to integrate a map feature in future which would make it easy to drop a pin and see nearby articles. It doesn’t really make sense to allow users to enter a longitude and latitude coordinate as these are not very human friendly :)".

IMHO, that is a poor reason to reject something that would be trivial to add. Allowing users to enter longitude and latitude would be a vast improvement over nothing, especially assuming it can be done with e.g. "Special:NearBy/44.12,-71.13" so various tools can generate a clickable link. PrimeHunter (talk) 15:47, 10 June 2013 (UTC)

I agree with PrimeHunter, especially as Jon said "it would be trivial." Is there a bugzilla? Theopolisme (talk) 15:52, 10 June 2013 (UTC)

esp. since it's not just about users adding the coords manually - this should be done in a way that will allow creating internal links to "nearby"'s, e.g. by using a link in the form "Special:Nearby/coords", which should work even when the device/browser can't/won't allow sending its coordinates. peace - קיפודנחש (aka kipod) (talk) 16:29, 10 June 2013 (UTC)

Raise a bug to make sure this doesn't get lost. I should have been clear. The bit that is trivial is allowing user input. The bit that isn't is how you present that information. It requires a lot of discussion around how it can be queried and what the expected behaviour is when it is queried. For instance if I pass in a geo coordinate what does refresh do? If I pass in a geo coordinate how do I know I'm looking at things near that geo coordinate rather than things nearby? All these design considerations need attention - otherwise we risk the danger of someone thinking they are looking at articles nearby which are actually articles near somewhere completely different and people thinking they are looking at something broken. Jdlrobson (talk) 21:06, 10 June 2013 (UTC)

I've logged a bug at bugzilla:49413. – PartTimeGnome (talk | contribs) 21:41, 10 June 2013 (UTC)

Yes! It would be great if tools like GeoHack could have links to Special:Nearby.

Regarding concerns that entering a longitude and latitude isn't user friendly, how about allowing entry of any article name where the article has geodata? Users could then enter the name of a town (or nearest notable location) rather than having to look up the coordinates themselves. – PartTimeGnome (talk | contribs) 21:17, 10 June 2013 (UTC)

For articles that have coords registered, another option could be to add a link from the standard left-hand "Toolbox" links-- "What's nearby" or similar. Regards, Orange Suede Sofa (talk) 21:26, 10 June 2013 (UTC)

That's another great idea! – PartTimeGnome (talk | contribs) 21:41, 10 June 2013 (UTC)

Proposed change to the Afc submission process

Dear Technical people:

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

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

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

An implementation note: if we want to give this a trial run (and certainly if it ever goes into production), it needs to be made a default-on gadget, so the code should probably be reviewed with that in mind. I don't think there's anything that's not cross-compatible in it. Writ Keeper ⚇♔ 16:58, 10 June 2013 (UTC)

@Writ Keeper:, no chance to test it, but I'd change at least the url building a bit. like this. —TheDJ (talk • contribs) 18:01, 10 June 2013 (UTC)

Okay, I'll look into that. You changed the typeof thing, but I don't think your version works: it still gives the "not defined" error when I test it in my console, at least, so I'm going to stick with typeof for now. Writ Keeper ⚇♔ 20:11, 10 June 2013 (UTC)

Other than the typeof thing, your suggested changes have been implemented and seem to work. Writ Keeper ⚇♔ 20:23, 10 June 2013 (UTC)

• No promises, but I'll try to set some time aside this week to import the script into my common and test it on all five major browsers (latest version of all except IE which I run v7). I'll let you know what I find. Technical 13 (talk) 18:06, 10 June 2013 (UTC)

Hi Technical 13, have you had time to deal with this yet? Roger (Dodger67) (talk) 20:38, 14 June 2013 (UTC)

I'm sorry, I haven't yet. The only thing higher on my todo list right now is a fix I have in my head for AFCH typeof o = null error. Soon. Technical 13 (talk) 21:38, 14 June 2013 (UTC)

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)

User e-mail sending speed limit

Tracked in Phabricator
Task T51444

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

Yes, 20 per day. MER-C 07:44, 11 June 2013 (UTC)

• Please give a prooflink. I Assume good faith, but err is human. --Синкретик (talk) 08:16, 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  (talk • contributions • email) 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 (talk • contribs) 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)
  • Voted Technical 13 (talk) 17:08, 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)

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)

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)

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)

Tech news: 2013-24

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

Recent software changes

(Not all changes will affect you.)

• The latest version of MediaWiki (1.22/wmf6) was added to test wikis and MediaWiki.org on June 6, and to non-Wikipedia wikis on June 10. It will be enabled on all Wikipedias on June 13. [6]
• An alpha version of the VisualEditor was enabled on all Wikipedias on June 6. Please test it and report problems. [7]
• Several VisualEditor bugs have been fixed; users can now add, edit and remove categories using the editor's "Page settings" menu.
• Wikimedia error messages will no longer link to the #wikipedia IRC channel on Freenode. [8]
• The logo of 16 Wikipedias was changed to version 2.0 in a fourth group of updates. [9]
• A test instance of Wikidata is now available at test.wikidata.org. [10]
• Users can now patrol the first version of a newly created page if they visit it from Special:NewPages or Special:RecentChanges. [11]
• Translation pages will no longer include edit section links (bug #40713). [12]

Future software changes

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

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

20:05, 11 June 2013 (UTC)

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

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)

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, [14] gives the error message you mention above, while [15] works. In fact, searching for � also works if there is more text in the search box [16]. 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)

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)

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 (talk • contribs) 13:52, 13 June 2013 (UTC)

it's absolutely related. in the meantime, until the popup maintainer(s) will add the dependency directly to the script (i don't think this can be done through MediaWiki:Gadgets-definition - currently popup gadget does not use RL, so it can't declare dependencies), you can patch this specific problem for yourself, by adding to Special:MyPage/common.js the following line:

mw.loader.load('mediawiki.user')

there is another bug in mediawiki code that currently only affects IE users: it's in the new "thanks" extension, in this file: [17], line 53: the problem is that this module defines an object with a member named class, which IE considers a reserved word, so it bulks. the fix is very simple - just change class: 'ui-button-green', to 'class': 'ui-button-green',. this probably required opening a bugzilla report, but unfortunately i can't do that ATM. peace - קיפודנחש (aka kipod) (talk) 14:34, 13 June 2013 (UTC)

Thanks. That patch didn't solve it, I'm afraid, but if it's going to be fixed soon, let's not worry too much about the temporary issue. Thanks everyone. --Stfg (talk) 15:56, 13 June 2013 (UTC)

You can use RL modules in non-RL gadgets using code like mw.loader.using('mediawiki.user', function(){ ... }) – the callback function will be executed after the module is loaded. One could just wrap the entire Popups' code in this and it should start working. @kipod – I submitted a patch to the Thanks extension at https://gerrit.wikimedia.org/r/68418, I'll poke someone to get it deployed soon, thanks. Matma Rex talk 16:14, 13 June 2013 (UTC)

As a former popups maintainer :D I added the dependency —TheDJ (talk • contribs) 21:20, 13 June 2013 (UTC)

And bingo! it's working again even in page histories and even with IE8. Many thanks everyone who spent time on this. --Stfg (talk) 22:12, 13 June 2013 (UTC)

Is daily option working for notification emails?

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

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

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

template cite pmid

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

File:Cite pmid display error.png

screenshot

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

A purge fixed Leukoencephalopathy#References. PrimeHunter (talk) 21:08, 12 June 2013 (UTC)

Interesting, now I understand, thanks! Götz (talk) 02:47, 13 June 2013 (UTC)

Wiki signup translation

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

See the bottom of http://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)

VisualEditor breaks BLP warnings

Tracked in Phabricator
Task T51552

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

{{BLP editintro}} is added by the editintro code for the English Wikipedia in MediaWiki:Common.js. I don't know whether it can added by the VisualEditor but if you don't get an answer here then you could try asking at MediaWiki talk:Common.js. PrimeHunter (talk) 23:04, 12 June 2013 (UTC)

Thanks for the extra explanation, PrimeHunter. I'll try the page you linked if we don't get it sorted here. Dricherby (talk) 08:55, 13 June 2013 (UTC)

For future reference. the block to add to has class "ve-init-mw-viewPageTarget-toolbar-editNotices". It needs to be wrapped in something with class "ve-init-mw-viewPageTarget-toolbar-editNotices-notice". Now to find a hook to know that the VE is done with setup. —TheDJ (talk • contribs) 22:23, 13 June 2013 (UTC)

Hmm, too easily do this might require adding some events to the VE. I've created a ticket to track this problem. —TheDJ (talk • contribs) 22:35, 13 June 2013 (UTC)

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)

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)

Module:IncrementParams

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

Removal of a deleted page from view

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

How is it currently not "completely deleted"? Note that we don't have influence on search results that 3rd parties (e.g. Google) cached (made a copy of) at some point. --AKlapper (WMF) (talk) 15:48, 13 June 2013 (UTC)

And Google will presumably stop indexing it next time they crawl Wikipedia and find the article has gone. (I assume that robots.txt or some other mechanism stops search engines crawling the article creation page you get after clicking on a redlink to an article, which mentions that the article formerly there was deleted.) Dricherby (talk) 15:52, 13 June 2013 (UTC)

Deleted pages return a 404 HTTP status code, aka "Not Found". This tells Google that the page doesn't exist, so Google removes it from its index (eventually). Content such as the deletion log is returned with the status code for display in web browsers, but the 404 causes Google to ignore it. – PartTimeGnome (talk | contribs) 22:01, 13 June 2013 (UTC)

We also have no say over websites such as Deletionpedia. GiantSnowman 15:56, 13 June 2013 (UTC)

AKlapper, Sorry I should have been clearer by "not completely deleted" I mean the title, deletion notice and reasons for its deletion remain (content is gone). Although it is not, I was wondering if there was a deleted article with a libelous or defamatory title would it also remain on wikipedia? I know that you have no influence over 3rd parties, but if a deleted page's title remains, consequentially it still appears on google search pages.Thank you Dricherby - JulieSmith123 (talk) 16:05, 13 June 2013 (UTC)

That information can be wiped, given a valid reason for doing so. Werieth (talk) 16:12, 13 June 2013 (UTC)

Are those valid reasons available anywhere? JulieSmith123 (talk) 16:17, 13 June 2013 (UTC)

You should provide one. GiantSnowman 16:19, 13 June 2013 (UTC)

Who would I send it to and who would deem it valid? JulieSmith123 (talk) 16:27, 13 June 2013 (UTC)

Special:EmailUser/Oversight Contact them and they will review your request. Werieth (talk) 16:31, 13 June 2013 (UTC)

Thank you!!-JulieSmith123 (talk) 16:35, 13 June 2013 (UTC)

Although, if this is related to Clonakylti, I see nothing under RevDel or Oversight policies that would justify its purging (✉→BWilkins←✎) 16:41, 13 June 2013 (UTC)

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

As BWilkins says above, I'm not sure this counts. GiantSnowman 16:44, 13 June 2013 (UTC)

The deletion notice serves as a warning to others not to re-create the page without good reason. In general, the existence of that notice isn't something to worry about: it doesn't reflect badly on you or anyone else, for example (it doesn't even mention anyone by name, apart from the person who deleted the page). Dricherby (talk) 16:52, 13 June 2013 (UTC)

Thanks, no this query doesn't necessarily regard Clonakylti. For the record, I do find deleted for "Unambiguous advertising or promotion" does slightly undermine your credibility- there could be a possible argument for defamation as it could lower your reputation in the eyes of the reasonable-thinking members of society and it mentions the company by name, a person in the eyes of the law- but I do not intend to!! JulieSmith123 (talk) 16:58, 13 June 2013 (UTC)

That's ridiculous, the article was deleted as being promotional, it has no bearing on the company itself, and I must warn you are dancing right up to the line of making a legal threat, which is grounds for immediate blocking. I would suggest you just quietly make whatever request you were going to make to oversight and maybe review the core policies of Wikipedia so that you better understand what is and is not appropriate content. Beeblebrox (talk) 17:09, 13 June 2013 (UTC)

Emphasis: there could be a possible argument and repeated use of the word could but I do not intend to. You will find I did not make any argument. I do not intend to make any request. — Preceding unsigned comment added by JulieSmith123 (talk • contribs) 17:20, 13 June 2013 (UTC)

• Blanked page with speedy tagbox had cleared Google cache: As typical, when an article for deletion has been blanked and tagged for speedy-delete, then Google resets the indexed cache copy to clear any prior contents. Any use of Google Search, which matches the topic, will link to the deleted page, with no contents to display, and any views of the Google cache will just show the speedy-delete tagbox and none of the prior contents of the deleted page. After a few days, the page-rank typically falls quickly, and within a week, then a direct Google request for the page title might yield zero results, because the prior cache page would be completely hidden from view (as shown when the temporary rename of "Gone with the Wind (film)" caused it to vanish from Google after a few days). Note that an improperly deleted page would remain a few days in Google, to allow time to be discussed and restored without affecting the Google search-results, but a spam page can be blanked/tagged for instant re-caching, and the remaining days of access would just indicate the blanked page was deleted. -Wikid77 (talk) 18:44, 13 June 2013 (UTC)

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

Special:MyPage plus action=edit ?

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

Well, yeah, it's the same as any other page. Just do https://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 "". – 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)

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)

Bolding on watchlist despite preference set for no bolding

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

this setting works for me as advertised. try to do a deep-refresh (assuming ff, chrome or ie on windows, press Ctrl+⇧ Shift+Delete, and select whatever your browser use for "drop/forget/delete cache/temporary files". if you use a different browser or os, look in the browser's menu how to completely purge the cache), and see if this solves the problem.

also, if you use a skin other than vector, try it with vector. if you find that the problem is skin or browser related, please report your findings. peace - קיפודנחש (aka kipod) (talk) 18:27, 13 June 2013 (UTC)

Oh, what a headache. Literally...the bold is horrendous. 1. I have checked my preferences under gadgets and indeed have bolding for watchlist unselected. 2. I just performed the "detete temporary internet files" routine (thanks for the neat keypress info...) 3. I temporarily changed my skin from Modern to Vector. None of this mattered one iota. I still have pages bolded. The only way I can keep from getting a migraine is to click "mark all pages visited" each time I check my watchlist; which only works for a moment because I have nearly a thousand pages I watch, some of which are quite active (like this one). This is new, unexpected and unliked. Fylbecatulous talk 18:45, 13 June 2013 (UTC)

I have purged the cache, I'm not on compatibility mode, and the option isn't selected in my preferences. GiantSnowman 18:51, 13 June 2013 (UTC)

I've also tried the suggestions קיפודנחש gave, and they did not fix the problem. I'm using MonoBook, but the bolding was still present when I switched to Vector. I also deleted the cache/temporary Internet files, but that didn't solve the problem. The bolding is still present. Calathan (talk) 18:54, 13 June 2013 (UTC)

It's not working for me either. Roger (Dodger67) (talk) 18:58, 13 June 2013 (UTC)

the problem seems to be real, but it only materialize with IE - for ff and chrome this preference seem to work as advertised. this is the probable cause - i venture a guess that the person who created this gadget use some browser other than IE. i left him a message asking him to take a look at this topic. peace - קיפודנחש (aka kipod) (talk) 19:27, 13 June 2013 (UTC)

It worked perfectly on IE for about a year, why would it suddently change? Roger (Dodger67) (talk) 19:38, 13 June 2013 (UTC)

If it is an IE issue, try toggling "compatibility" mode... Technical 13 (talk) 19:44, 13 June 2013 (UTC)

As I've already said, that doesn't work. GiantSnowman 19:48, 13 June 2013 (UTC)

I have IE10. I see nothing that applies to me on the "Compatability mode" choices...therefore, I too am not in compatability mode and don't intent to tinker, actually. I agree: what has happened? I've been upgraded to IE 10 as long as it has been available. Fylbecatulous talk 20:00, 13 June 2013 (UTC)

This is probably an issue now when it wasn't for the last year because of the recent introduction of green bullets on the watchlist. I believe these use some of the same classes as watchlist bolding; the bolding gadget was probably changed to accommodate this. – PartTimeGnome (talk | contribs) 22:08, 13 June 2013 (UTC)

I think I fixed it. As usual, IE is retarded enough to miss the the finer points of CSS; it does not seem to understand what 'inherit' means. — Edokter (talk) — 20:04, 13 June 2013 (UTC)

I've logged out, re-purged and opened a new browser - still big'n'bold. GiantSnowman 20:08, 13 June 2013 (UTC)

Seems like another, unfortunately increasingly typical, change to the system that has not been properly tested. Why does Wikipedia allow any editor to install any changes without a full test on all browsers? I have complained several times before about such changes and received very arrogant responses along the lines of "it's your fault for using IE" or as described above "IE is retarded"

NO - like it, or hate it, IE is the most used browser in the world, if any change has not been fully tested in all standard browsers it should not be allowed to be implemented. I've made this point before, and it was described as "unrealistic", although no reason or justification was made for this claim. As it is, my editing has been severely hampered for months by the toolbars dropping into the edit pane, due to another so-called "improvement" that caused more damage than good.

Wikipedia has been wondering why experienced editors leave - whilst ignoring repeated requests not to "fix" things that are not bust. We need a simple, basic interface which editors can add to by selecting options in My Preferences, not an increasingly complex interface that requires editors to install complex lines of code to disable them, if they can find this code hidden on some obscure page. Arjayay (talk) 20:31, 13 June 2013 (UTC)

Wikitech-l: Features vs. Internet Explorers. Helder 21:11, 13 June 2013 (UTC)

Since gerrit:65414-change, the CSS for the watchlist is loaded trough javascript. If the user is encountering an error in one of his (other) scripts, then this script may not be able to load and not be able to add the CSS, which would explain the problem that this user is experiencing. See also the report below —TheDJ (talk • contribs) 23:02, 13 June 2013 (UTC)

This is what I have on my common.css -

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

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

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

I have to keep the green bullets "selected" (which is ok; they are not too vivid). If I did away with them, then my reset button would be hidden and I woudl have no way to mark all pages visited to allow me a moment with no bold. I am keeping IE10 because I figured out some tweaks that made it work better for me (such as the dastardly "auto-spelll correct" which wrinkly underlined everything here that was in code because it wasn't spaced (such as defaultsort:woodbridge). To me, the bolding is "screamingly offensive". I do not intend to downgrade my browser just for the quirks of Wikipedia. And yes, the bold still lives this morning, btw. Fylbecatulous talk 11:36, 14 June 2013 (UTC)

OK, just to get this clear, this might take at least a week to get this properly fixed. —TheDJ (talk • contribs) 11:40, 14 June 2013 (UTC)

Z'okay. ツ Fylbecatulous talk 12:24, 14 June 2013 (UTC)

• Its not a javascript error issue for me. I examined the Firefox 19.0.2 error console and there are zero errors but a lot of warnings. For me I used the enhanced RC feed and the timestamps are still bold for me. Werieth (talk) 12:19, 14 June 2013 (UTC)

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)

Bolding on watchlist has gone away, please give it back

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

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

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

This looks like an unintended side effect of a change. You should report it as a bug in bugzilla by following the instructions How to report a bug, in this case under the product 'MediaWiki' and the component 'Interface'. This is to make developers of the software aware of the issue. If you have done so, please paste the number of the bug report (or the link) here, so others can also inform themselves about the bug's status. Thanks in advance!—TheDJ (talk • contribs) 22:58, 13 June 2013 (UTC)

Please read my last sentence, I don’t like to be forced to get a new e-mail address which has to be posted in Bugzilla and there can be seen by everyone, so I won’t make a bugzilla account. I thought that maybe the developers also take a look here, if they update MediaWiki.

I first noticed this change today between 20:00 and 21:00 (CEST) which is between 18:00 and 19:00 (UTC). That is exactly the time when the new version of MediaWiki had been placed to dewiki. And the same happens here on enwiki again, and I think here has also taken place a MW update at this time. So I suppose that this issue here is related to the one above at #Bolding on watchlist despite preference set for no bolding, where users who didn’t want this feature took a script for not seeing it anymore. Now that this feature has been put from css to js (with the update), I can’t see it anymore, and perhaps scripts that should turn this off, don’t function anymore. This isn’t good on both sides and better should be reverted or fixed in another way. I think it would be enough, if anyone just linked to the two threads here on bugzilla. If there ain’t no bug at this time which I just don’t know. --Geitost 23:18, 13 June 2013 (UTC)

Thanks for pointing me to this Geitost. Actually I wondered what was wrong with the bolding on the watchlist today, since bolding was only shown after a noticeable lag. The use of JavaScript explains this unwanted behavior perfectly. I posted a comment to the Gerrit patch mentioned above.

Actually I only created an account for this, since I think we're using by far too much JavaScript already. Instead of even expanding its use, we should strip it out wherever possible. Best example is the new "Thanks" feature that is totally unusable without JavaScript (and seems to even leave some non-working buttons with JavaScript disabled) or the new "Notifications" feature that's also pretty crippled without JavaScript. --Patrick87 (talk) 23:20, 13 June 2013 (UTC)

Yes, that’s why I wrote that also into the petition linked above. See also the Flow discussion. I’m really afraid about the next features that will be put onto the wikis (WP:Flow, WP:VisualEditor). No notifications, no translation extension usable (if there are pages with that new extension, you first have to search for the messages in the namespace Translation: via Special:PrefixIndex instead, that’s quite difficult and takes a lot of time to find the right message to change, you won’t create or change many translations that way, that’s for sure, and: you have to know that, otherwise you won’t edit any translations), no possibility at all to add, change or remove wrong interwikis on Wikidata (cause the pages there are not able to edit directly anymore and interwikis are JS-only on Wikidata). There’s so much now that can’t be done anymore which are really core features and are needed. And it’s getting more and more all the time. I really don’t understand that noone changes this direction back again. It’s the wrong direction to drive away people this way. --Geitost 23:46, 13 June 2013 (UTC)

Perhaps it would be a good idea to put this issue forward at the now-being board elections and other elections. There have to be candidates who care about the users and the communities, as long as the developers and the Foundation don’t care about this (or seem not to do this). --Geitost 00:00, 14 June 2013 (UTC)

I have submitted a change suggestion gerrit:68601, that might be able to address this. —TheDJ (talk • contribs) 00:01, 14 June 2013 (UTC)

Thank you very much! :-) --Geitost 00:03, 14 June 2013 (UTC)

• Thank you both for working on that problem. The April 2013 editor-activity data has revealed about 10,055 more active editors than expected after the typical 6% decreases in prior years, so even though many veteran editors have gone on break, there are hundreds who have stayed or returned to see these problems. -Wikid77 (talk) 08:25, 14 June 2013 (UTC)

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

That is most excellent news! I had been giving Wikidata a wide berth after I tried it a while back and found it to be unusable (lots of "edit" links that did nothing when clicked, etc). Your comment prompted me to take another look, and it now works. Thank you! – PartTimeGnome (talk | contribs) 20:51, 14 June 2013 (UTC)

May not be related to this but how do we get the bolding back on the related changes special page for those items that are on our watchlist. Keith D (talk) 17:31, 14 June 2013 (UTC)

If only this totally unwanted feature would go away - I just can't get rid of it. Anyone who wants bold on watchlist, but can't get it, willing to change computers with me, who doesn't want bold on watchlist, but can't get rid of it?
On a serious note, this just re-emphasises my point above, that changes are not tested before they are implemented. Arjayay (talk) 17:46, 14 June 2013 (UTC)

i think you are not 100% fair here. you make the equation "contains bugs === untested". anyone who had even small amount of exposure to software realize immediately that this equation is false, but to emphasize the point, i'll present the same logic in a different form: "tested software === software that contains 0 bugs". practically every person who ever turned on a computer recognizes that the second equation is false.

no "untested" feature go into MW software, and no release to date was 100% free of bugs. putting my prophet cap on, i can see into the future and predict with absolute certainty that the next 50 releases will _all_ be tested, and will _all_ contain bugs.

as to "unwanted features": higher in this very page you complained that "my editing has been severely hampered for months by the toolbars dropping into the edit pane". however, i am somewhat familiar with the bug you referred to, and in know that this problem only occurred when one keep the "advanced" toolbar in the editor open. everything inside this "advanced" toolbar are "features" that at one point or another, someone dubbed as "unwanted". the fact you use these enough to keep the "advanced" toolbar open (and hence encountering the problem you described, which, btw, persisted for little more than a week, not "months") proves that you yourself find at least *some* of those "unwanted features" useful. as to the problem discussed here: this is not a mediawiki problem. it's a problem created when diligent and capable people here at enwiki tried to enhance this feature, in direct response to users' requests. peace - קיפודנחש (aka kipod) (talk) 18:32, 14 June 2013 (UTC)

You state the problem "persisted for little more than a week" - as if it has actually been resolved - which it most certainly hasn't - I am still suffering from it, and my statement of "months" is totally accurate. You claim to be "somewhat familiar with it", so perhaps you could actually resolve it? - Arjayay (talk) 21:22, 14 June 2013 (UTC)

see Bugzilla:27698. i had the honor of reopening this bug report when the problem reincarnated recently, and as far as i knew, the solution really did its job. your report is the first i heard about this issue still persisting. after reading your report, i tried it, and was able to reproduce using "compatibility mode" on IE-10 (i do not usually use IE, and when i do, i do not usually use "compatibility mode"). ttbomk, "compatibility mode" for IE-10 emulates IE-7 behavior. i think this issue should be reported, but may i ask, which browser do you use? peace - קיפודנחש (aka kipod) (talk) 03:57, 15 June 2013 (UTC)

created a new report: Bugzilla:49609. if you use IE 9 or 10, i'll bet that you have "compatibility mode" on, and if you'll turn it off the problem will go away. if you use ie-8, there's still larger than 0 probability that going out of compatibility mode will solve the problem. if you use ie-7 i'm afraid you'll have to wait for the bug to be fixed. peace - קיפודנחש (aka kipod) (talk) 04:32, 15 June 2013 (UTC)

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

How to explain simple fixes for edit-conflict

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

Bugzilla tracks the history of a report, mailinglist wiktech-l is for discussion of the software, #mediawiki IRC channel is for direct discussion with fellow developers and patches go to gerrit. —TheDJ (talk • contribs) 08:50, 14 June 2013 (UTC)

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 ^Chat_Online 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 ^Chat_Online 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)

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)

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

Resolved

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 Template:Bug. Matma Rex talk 12:30, 15 June 2013 (UTC)

Lining

See this: FH⁺
₂.

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 (HSbF₆), is the strongest charge-neutral acid known. The dispersion of the charge on the anion affects the acidity of the solvated proton (in form of FH⁺
₂): The compound has an extremely low pK_a of −28 and is 10 quadrillion (10¹⁶) times stronger than pure sulfuric acid.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.

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

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

We could force the line-height. FH+
2 —TheDJ (talk • contribs) 14:35, 15 June 2013 (UTC)