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

X!'s Edit Counter

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

---

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

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

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

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

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

Keep opt-in

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

   Urgh. It's on labs now, and the toolserver version will be shutoff soon.—cyberpower ^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)
12. I prefer opt-in. It's not a critical issue, but it seems polite to ask people for permission before collecting and visualizing information about them – even if it's public information. Also, we don't need to turn Wikipedia into some kind of contest or competition. NinjaRobotPirate (talk) 14:40, 16 June 2013 (UTC)
13. Keep opt-in. - Yes, the data is already available. But there is indeed a difference between that and analysis of the data supported by WikiMedia. Plus, people are too interested in this often (but not always) trivial data. See the numerous edit counters. Garion96 (talk) 08:15, 21 June 2013 (UTC)
14. Keep opt-in. --Robby (talk) 05:54, 23 June 2013 (UTC)

Remove opt-in and replace with opt-out

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

   Just as an additional note, I'm fine with the consensus to remove opt-in altogether. Transparency is important; when I first commented here, I just thought some editors might feel more comfortable with the option to not have their editing history so much easier to track. The more I think about it, the more I'm swayed by the comments directly below. Consider this a support for either option. "One is the loneliest number that you'll ever do..." Kurtis ^(talk) 04:33, 16 June 2013 (UTC)

Remove opt-in completely

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

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

   @MZMcBride: Someone just got a new nickname. I kinda like how "Max" rolls off the tongue vs. "MZ". You might also want an avatar, though, to counter that mental image of Max Headroom that springs to mind.... ;-)  —Grollτech (talk) 22:25, 17 June 2013 (UTC)

2. Yeah this. The data is publicly available, that tools shouldn't exist which compile it in a usable form seems silly. --Jayron32 17:49, 4 June 2013 (UTC)
3. The tool doesn't give you any information that isn't already on the user contribs page, seems silly to have an opt-in, or an opt-out. Though I'd support opt-out over opt-in if we must. Prodego ^talk 18:02, 4 June 2013 (UTC)

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

4. It's a helpful tool that uses publicly available information. When unavailable, it just makes finding the information so much harder. I see no real privacy concerns as long as every editors contributions may be browsed. --SmokeyJoe (talk) 21:46, 4 June 2013 (UTC)
5. Going a step further to say that user contributions should be scrutinized carefully and this tool helps enable this. Data on editors' contributions should be widely available to combat POV pushing and similar problematic behaviour. There is no privacy issue as contributions are public record. This falls squarely in line with the foundations's privacy policy which reads: User contributions are also aggregated and publicly available. User contributions are aggregated according to their registration and login status. Data on user contributions, such as the times at which users edited and the number of edits they have made, are publicly available via user contributions lists, and in aggregated forms published by other users. [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)
27. Compiling stats from public information doesn't require anyone's permission. I oppose the ability to opt-out too. Transparency is key. -Nathan Johnson (talk) 01:37, 16 June 2013 (UTC)
28. Support per all above. Fredlyfish4 (talk) 20:30, 16 June 2013 (UTC)
29. Per Tom Morris. -- œ^™ 06:58, 18 June 2013 (UTC)
30. This information can be computed rather quickly from Special:Contributions. Why go through all the trouble if the tool is available? This information is really in no way private. Jguy _Talk^Done 14:08, 18 June 2013 (UTC)
31. I'm for transparency. Let everything be public. —Anne Delong (talk) 14:46, 18 June 2013 (UTC)
32. Support with the reservation that en.wiki does not control a global tool, and this decision needs to apply to en.wiki only or be taken to meta before implementation, as well as explicitly approved by the WMF legal eagles. Tazerdadog (talk) 21:29, 18 June 2013 (UTC)
33. Support removal of opt-in. Most of the "privacy!!!!!!!!!!!!11" people are Snowdenbots who really have no idea about privacy. Just because some information happens to be hidden away in a dark corner of the Internet doesn't mean it's private, it's just not yet been seen by many people. I wouldn't be surprised, though, if the Snowdenbot WMF nuked this proposal from orbit (assuming the "#YOLOswagz2001WMFlolprivacyfreecultureftw" people who make up Wikipedia's high society rejected this as "no consensus".) In the end, this isn't a privacy issue, it's a non-issue, and anyone hacking at the privacy stump is really fooling themselves. Wer900 • talk 04:39, 19 June 2013 (UTC)

    Was the ridiculing really necessary? wctaiwan (talk) 08:58, 21 June 2013 (UTC)

34. Compiling public data (about anonymous user names) and displaying it is easy to read form in no one violates anyone's privacy. --ThaddeusB (talk) 05:19, 20 June 2013 (UTC)
35. Tom has put it very well. There is no sense in which this data is, or should be, private. — Scott • talk 14:55, 20 June 2013 (UTC)
36. Per User:King of Hearts and my comment below. Kudpung กุดผึ้ง (talk) 08:06, 21 June 2013 (UTC)
37. --Andyrom75 (talk) 05:36, 23 June 2013 (UTC)

Discussion

• You need to make your opening statement clearer, explain the situation in greater detail. You say editors "want the detailed edit stats to be visible" - visible to themselves, or visible to the public? GiantSnowman 13:23, 4 June 2013 (UTC)

  I don't see how it can be much clearer. There are users who don't want the opt-in and there are users who want to keep it. So I'm asking the community the simple question. Should the edit counter have the optin?—cyberpower ^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)

  Chris, no offense intended, but I'm not sure that you understand what the word "private" actually means. — Scott • talk 19:26, 20 June 2013 (UTC)

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

  Correct. And I'm very strong on Privacy concerns. Maybe because I'm German too.—cyberpower ^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)

• I'm echoing Snowolf's concerns. The English Wikipedia does not have sole authority over this tool.--Jasper Deng (talk) 04:37, 16 June 2013 (UTC)

  Correct. TParis and I have authority, but unlike Wikipedia devs, we're giving the English and global community the opportunity to decide. — Preceding unsigned comment added by Cyberpower678 (talk • contribs) 14:59, 16 June 2013 (UTC)

  This line of argument is begging the question. — Scott • talk 09:12, 21 June 2013 (UTC)

• There are anomalies in German laws. Germany probably keeps the most detailed personal information over its residents than any other Western country and that is why the populace is largely paranoid about their personal data, which then reflects in such trivia as the use of the ToolServer for quickly compiling data that most of us can gather and collate from other tool server devices, editor contribs, and page histories. The sooner the Edit stats without op-in become available as standard, it will make the work of RfA /RfB/ARCOM/Stewarship, voters, SPI researchers, the granting of minor user rights, and many more meta workers much easier. Kudpung กุดผึ้ง (talk) 08:03, 21 June 2013 (UTC)

  I was aware that the tool was very popular, but wasn't aware that there was such a strong dependency on it. I will begin a meta RfC to determine the remaining fate of the tool.—cyberpower ^Chat_Online 02:20, 22 June 2013 (UTC)

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

Multiple references to the same source

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

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

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

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

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

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

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

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

1. 17. Brown (2000)

3. 6. Schmidt (2003)

4. 7. 14. 15. Smith (2008)

5. Jones (1998)

8. 9. 10. 12. 13. White (2010)

11. Brown (2009)

16. 21. Jackson (2012)

Which is bad and horrible in several ways.

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

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

I use the browser's back feature by clicking its back icon, or pressing Backspace or Alt+←. PrimeHunter (talk) 00:41, 16 June 2013 (UTC)

That's useful as a workaround, but the link issue should still be fixed. Thryduulf (talk) 01:00, 16 June 2013 (UTC)

I think you need to explain why the back button is not a full and complete solution. Dmcq (talk) 08:09, 16 June 2013 (UTC)

Because it's not at all obvious (I didn't know about it for example, and I'm an above average user) and isn't guaranteed to work on all platforms. If the back button was a full solution there would be no point in providing back links at all. Thryduulf (talk) 08:18, 16 June 2013 (UTC)

I'm sorry about that but it is a pretty standard fixture on the major browsers. By not always working I think you're probably referring to some applications where if you press the button something happens like buying a chair, yes pressing the browsers back button then can cause problems because you can't take back an order that way and a transaction environment would have been set up. The back button they provide will take you to before then to something like looking at a picture of a chair instead. However in Wikipedia the only tranasctions of that sort we have are when you press the save page button when editing. Dmcq (talk) 08:34, 16 June 2013 (UTC)

That's not what I'm on about at all. Hardly a major browser these days, but the version of IE on my old phone would take you back to the previous page rather than the previous point in the same page. We should also not just be catering for only the technically literate - if it wasn't obvious to me then it's not going to be obvious to a whole swathe of users less technically adept than I am. I'm sorry, but I don't regard the back button being available as a reason why this problem does not need to be fixed. Thryduulf (talk) 09:25, 16 June 2013 (UTC)

Remembering the letter is something that you have to do here and could be confusing in the text. May be you could highlight the letter in the reference section that you arrived at the particular reference from at the same time as you highlight the reference entry in blue. Keith D (talk) 13:28, 16 June 2013 (UTC)

The blue highlighting is achieved with the target pseudo-class :target - the CSS is

ol.references li:target, sup.reference:target, span.citation:target { background-color: #ddeeff; }

which works for the whole entry in the list. To give one letter some styling in addition to the blue for the whole entry cannot be done with CSS alone, and I'm not enough of a Javascript coder to know whether it's feasible. --Redrose64 (talk) 15:29, 16 June 2013 (UTC)

If feasible (I have no idea) then the highlighting would be good for those who have the bowser support (wider for css than js AIUI). For accessibility reasons we shouldn't rely on something working only with javascript if possible, although I do take the point about the letter potentially being confusing. Would a number (^[6.1] etc) be better than a letter? I'm not sure there is a way around the remembering the letter (or whatever) number though. Thryduulf (talk) 17:22, 16 June 2013 (UTC)

(edit conflict) For "one letter", read "a substring of the list entry" - it doesn't matter whether it's a letter, number or some other characters. The problem is two-fold, and unrelated.

• When you follow links from the article text to the refs section, and you have a superscripted ref link in the article text that occurs more than once, say the ^[1] which occurs three times in NBR 224 and 420 Classes (once in the infobox, twice in the "History" section), each of those links is identical, so the target has no knowledge of where it came from. Therefore, as things stand, it's not possible to have highlighting like

1. Ahrons 1987, p. 195.

assuming that you had clicked the second ^[1] in that article, because the links from the first and third are identical.

• The Cite extension of MediaWiki does not have the means for adding distinguishing marks to the ^[1] which it presently generates via the system message MediaWiki:Cite reference link. The extension would need to be amended so that the third of the three values presently passed into that system message is not a simple number but one of the other methods which you suggest. In other words, it's not that ^[6a] or ^[6(a)] are difficult so ^[6.1] must somehow be "better", but that they're all equally difficult to do.

--Redrose64 (talk) 22:07, 16 June 2013 (UTC)

I understand now the technical issues, thanks. My comment about ^[6.1] being maybe better than ^[6a] was related to Keith D's comment "Remembering the letter is something that you have to do here and could be confusing in the text". I understood that to mean that a suffix letter may be confusing for humans reading the article when it appears in the middle of a section of prose (e.g. source 19 at British National Corpus#Classification errors and misleading titles#Classification errors and misleading titles) - i.e. the letter may get mistaken for lexical information.^[6.1] vs ^[6a] vs ^[6(a)] may be equally easy or difficult for the software, but they aren't necessarily for humans. I don't actually know if this is what Keith meant or whether a reference suffix letter would be an issue, but it is something we should think about before asking for a specific format. Thryduulf (talk) 00:47, 17 June 2013 (UTC)

My comment was related to the fact that normally you take no notice of the actual detail in the brackets, just use it to click on to get to the relevant reference. You have to consciously make a note of the letter in this case to go back. On the further point raised it could be confused as some sort of technical thing such as a page number or item in the reference. Keith D (talk) 08:37, 17 June 2013 (UTC)

I expect it doesn't help at all in Thryduulf's situation, but Preferences, Gadgets, Browsing, Reference Tooltips may avoid you having to go down to the reference list in the first place. Thincat (talk) 21:53, 16 June 2013 (UTC)

MediaWiki:Cite reference link formats the in-text link. The backlink characters are set by MediaWiki:Cite references link many format and the default is ^ ^{1.0 1.1 1.2} etc. This was changed in 2006 to match the {{ref}} template. The actual labels are defined at MediaWiki:Cite references link many format backlink labels and allow for 1065 backlinks. --  Gadget850 ^talk 09:16, 17 June 2013 (UTC)

The basis of this discussion is incorrect. The problem is not multiple uses of a source, but multiple uses of a "named ref" (i.e., "<ref name= ...>"). There is much to be said for using short cites in the text to link to a single full citation of a source. ~ J. Johnson (JJ) (talk) 21:06, 17 June 2013 (UTC)

• Updated the help-page for backspace/Back key: I have updated the help-page, Help:Footnotes, to remind users that the backspace or Back-key can be used (in IE or Firefox browsers) to return to the "footnote marker" superscript "^[1]" after seeing the footnote text. For many users, that will work. -Wikid77 01:55, 18 June 2013 (UTC)
  • For some, definitely. For many, maybe. It doesn't mean that we still shouldn't fix this for everybody though. Thryduulf (talk) 13:37, 21 June 2013 (UTC)

For what users does the "back" button not suffice? Should we be fixing what is possibly a browser deficiency? ~ J. Johnson (JJ) (talk) 22:35, 21 June 2013 (UTC)

i do not think there is a single browser for which the back button will not do exactly what you expect it to do. קיפודנחש (aka kipod) (talk) 00:09, 22 June 2013 (UTC)

I noted above that my old phone browser did not work that way (it went back to the previous page, not the previous point of the current page). In any case it is not that backspace is doing something people don't expect it to do (although many people will not be expecting it do anything), it's that not everybody expects to use the backspace to return to the previous point. Almost everyone will have arrived at the references by click on the link with the mouse or other pointing device. There are links there that allow them to return to where they were using the exact same pointing device - why should we force them to either guess which link they need or let go of the pointing device to press the backspace key (bad ergonomic design)?
Yes, the backspace works but the existing links are still broken and still need fixing. Thryduulf (talk) 22:44, 22 June 2013 (UTC)

The browser's back button is supposed to go back to the previous URL, no matter if that URL points to a different page or not. I doubt there's any browser where that button can't be operated by the same pointing device that's used for following links. Keyboard shortcuts or even dedicated physical keys are only additional ways to call the same function.

It's the browser that knows the previous URL, not the Wiki software and usually not the user, so the natural way to go back is to use a browser function, not a wikilink and not something requiring the user to remember some code. Emulating an existing browser function in the wiki software or in the user's head seems like overkill to me. The former (a 'back' link next to the reference) would require massive software changes and additional page reloads and the latter (additional labels in the reference tags) would disrupt the reading experience for all users. I don't think that's justified. — HHHIPPO 10:58, 23 June 2013 (UTC)

You appear to misunderstand slightly, there is no need for additional links, more page reloads or anything of the sort. The only change needed is to the labelling of the links which already exist. Thryduulf (talk) 12:50, 23 June 2013 (UTC)

I got that. I'm talking about three possible ways to get back, implemented in the wiki engine, the browser, or the user. Leaving the back function to the browser is what we do now, improving the way the user can do it manually is what you suggest. If that change is needed is what we're discussing here, since there are both advantages and disadvantages to it. In my opinion the disadvantages outweigh the advantages. — HHHIPPO 13:44, 23 June 2013 (UTC)

I'm sorry to be so blunt, but the browser's back button is a completely obvious solution to this "problem". If someone is actually using a browser that is so broken that the back button does not work properly, they should probably find a new browser. That's not Wikipedia's problem. NinjaRobotPirate (talk) 12:00, 23 June 2013 (UTC)

The problem is not with the back button, as I keep saying. There are two ways of navigating back to where you were - one is to use the back button/backspace key which works fine on most systems and isn't a problem. The other is to use the links that exist explicitly for this purpose - these work fine when a source is used only once but if they are used more than once it requires you to guess which link to use. It is this requirement to guess that is the problem which needs fixing. If the back button did the entire job then there would be no point in having the links. Thryduulf (talk) 12:50, 23 June 2013 (UTC)

The back button is our current solution to going back, so if that's not a problem then there's no need to fix anything. The links aren't there only for the purpose of emulating a back button. They allow to see easily which statements are supported by (or dependent on) a given reference, no matter how you arrived at that reference. There's a number of use cases for that, and it's particularly handy for sources that are cited more than once. Reading from start to end is not the only thing you can do with an article, there's also writing it and improving it ;-) — HHHIPPO 13:44, 23 June 2013 (UTC)

Exactly what I was going to say. The links are there for multiple uses, not explicitly as a replacement for your browser's back button, and they would not be removed in any case. Nobody needs to guess anything; they can just use their back button. The back button does do the entire job. If it doesn't, then it's not a back button, and your software is faulty. I support catering to obsolete and low-end systems, but I do not support catering to faulty software. That's a problem between you and your vendor, not you and Wikipedia. However, if we do implement this feature, I think a better solution would be to bold the link that will take you back, such as 15. ^a b c d e. That way, it doesn't add any other superfluous characters. NinjaRobotPirate (talk) 15:02, 23 June 2013 (UTC) edit: Which seems to have been already suggested. Oops. I must have missed that somehow. NinjaRobotPirate (talk) 15:05, 23 June 2013 (UTC)

Yes, highlighting or bolding would likely be the optimum solution but it isn't presently possible. I suggested suffixes simply because I hadn't thought of bolding when I identified the issue. Thryduulf (talk) 07:50, 26 June 2013 (UTC)

(edit conflict × 2)

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

One issue may be if you are double-clicking the "save page" button - I have run into this issue before. Mdann52 (talk) 12:15, 21 June 2013 (UTC)

I thought about that but it is still happening, but now some (maybe 1/4) of my sessions are lost.--Gilderien Chat|List of good deeds 00:24, 23 June 2013 (UTC)

Google and talk pages

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

Looks like it does index project talk. Werieth (talk) 20:32, 20 June 2013 (UTC)

Yes, any talk page that is not explicitly marked as {{NOINDEX}} will be indexed by Google. The main exception is "User talk", where you must opt in for each user talk page you want indexed. There are also some exceptions listed in Robots.txt, such as the talk pages of Articles for deletion. – PartTimeGnome (talk | contribs) 21:13, 20 June 2013 (UTC)

Hmmm.... That's an interesting list of noticeboards and discussion pages, most of which I didn't know existed. I'm surprised that Wikipedia talk:WikiProject Articles for creation isn't on the noindex list; there is a lot of frank discussion there about deletions, copyvios, BLP problems, unwanted advertising, etc. —Anne Delong (talk) 23:10, 20 June 2013 (UTC)

WP:NOINDEX is a somewhat good resource. There seems to be some dated info on that page, however. Killiondude (talk) 04:33, 21 June 2013 (UTC)

Thanks again. There seems to be always more to learn about WP! —Anne Delong (talk) 13:52, 23 June 2013 (UTC)

Wikipedia block in Togo

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

From editing or from viewing? We don't block viewing of wikipedia from anywhere. If it's from editing, you way want to try the unblock ticket request system to try to get your situation sorted out. Sailsbystars (talk) 13:51, 22 June 2013 (UTC)

Both. No one living on Togo can edit or view Wikipedia. I am a correspondant in neigbouring Ghana and we are getting numerous reports from Togo telling us that local ISPs and the Government has blocked the viewing of Wikipedia. --Togolaís Díplomátique (talk) 13:54, 22 June 2013 (UTC)

Ahhh... with that we can't help you directly I'm afraid. The only way to get read (but not write) access is by bypassing your country's filters using open proxies. WE have a project on closed proxies which might be able to get a small number of people editing. One simple way to read wiki articles is to do a google search and click the downward triangle next to the resulting URL and selecting "Cache" which will use google's cache of the page and doesn't require direct access to wikipedia. Sailsbystars (talk) 14:02, 22 June 2013 (UTC)

Okay thanks for your help. The Togolese Ministry of Information has just released a statement saying that the block was due to 'misinformation and blatent lies'. We have had reports of Wikipedia being blocked in parts of Benin aswell. Will keep you guys updated. Thank you.

Pierre Rednóis.

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

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

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

Tracked template stopped working

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

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

Image redirects

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

So, I created a little message file.

.

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

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

File:Max Irons 2012.jpg

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

Creation/upload protection require admin rights, and so do blacklists and edit filters (well...not really, but still advanced rights).  Hazard-SJ  ✈  02:59, 23 June 2013 (UTC)

At this point I haven't protected anything. What I'm most confused is that when I created the redirect, it did nothing, but now that I've deleted it it takes effect. I'm not precisely certain how to undo what I've done at all, and I'm certain that things aren't supposed to work the way they are.—Kww(talk) 03:43, 23 June 2013 (UTC)

I don't know how to undo it either, but did you check to make sure that the original unexpected behaviour was not the result of a browser caching problem? That can lead to things not showing up when expected, and then showing up later. —Anne Delong (talk) 12:08, 23 June 2013 (UTC)

commons:Help:File redirect#In-depth notes about the operation of file redirects says:

Technically, file redirects are ordinary redirects on File: pages, and they can be created manually. However, this only works where there is no file of that name (if there is a file, any uses of the redirect show the redirect's file, and not the target file - Bugzilla:14928).

Redirects on other projects are not mentioned but it appears from your description that the same holds: If the file exists at Commons then that file is shown and the redirect is ignored. I don't know why the redirect is shown at File:Max Irons 2012.jpg and working as a redirect after it was deleted, but I guess that recreating the file page without a redirect would solve it. PrimeHunter (talk) 13:37, 23 June 2013 (UTC)

• It's not that the redirect is being ignored, it's some kind of superpowerful redirect that takes effect after deleting it. I've experimented: if I create a local file again, the commons image comes back into view. If I delete the local copy, the redirect comes back into effect, even though all files containing the redirect have been deleted. It's getting stuck somewhere in the MediaWiki software. It's a neat effect, but I think using a bug to manipulate the way we represent several thousand files probably isn't the right answer.—Kww(talk) 16:03, 23 June 2013 (UTC)

You mentioned two issues, one before and one after the deletion of the redirect. I commented on the before situation: When the redirect existed it was being ignored. This is consistent with commons:Help:File redirect#In-depth notes about the operation of file redirects. I have now tested my suggestion to create a file page without a redirect. As expected, this has resolved the issue. The commons file was displayed when the page existed, and is still being displayed after I deleted the page. There is no longer a "phantom redirect" at the deleted English Wikipedia page File:Max Irons 2012.jpg. I agree it's a bug. It should be possible to delete a redirect and be rid of it, without having to remove the redirect code before deleting the page. PrimeHunter (talk) 16:49, 23 June 2013 (UTC)

I think what I'm going to do in these cases is upload the warning message in local namespace above the problematic image in Commons, not getting fancy with a redirect. That way, all that has to be done if some editor decides to incorporated the banned editor's material is to reupload the local copy to match the commons copy or persuade another administrator to delete my blocking image. It would be much simpler if I didn't have to accomodate people that were so desperate to have the lastest and greatest celebrity photos that they were willing to ignore and editors ban status to get them.—Kww(talk) 16:58, 23 June 2013 (UTC)

Script problems

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

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

X!'s Edit Counter

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

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

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

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

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

When creating this section, you copied one line from the previous thread - the <!-- EdwardsBot 0505 -->. Anyway, the MediaWiki software already does what you ask for: when you edit a section mid-page, any whitespace at the end of the section is stripped and a single newline added to the edit window. When you save a section mid-page, any whitespace at the end of the edit window is stripped and a pair of newlines are inserted between the edited text and the next section heading. --Redrose64 (talk) 08:53, 23 June 2013 (UTC)

So, I see now that the auto-inserted bottom blank line is omitted (in the edit-buffer) when re-editing a section, but saved in the page at end-of-section. Hence, the tactic would be, when in fear of edit-conflict replies, then place a blank line above the reply (2 newlines) and that reply would be treated as below the section's auto-inserted bottom blank line, where any other erstwhile replies would be herded above the auto-omitted bottom blank line. So, at least we know, now, to avoid edit-conflicts in busy threads: put a blank line above the new bottom reply. -Wikid77 14:54, 23 June 2013 (UTC)

Please don't put blank lines within threads. Talk page threads indented using colons (such as this one) yields a dl structure (aka 'definition list' or 'association list'), and a blank line terminates one such structure and starts another, which is undesirable. This is covered at WP:LISTGAP. --Redrose64 (talk) 15:30, 23 June 2013 (UTC)

Wikid77, if you're asking for more blank lines to be added to sections than MediaWiki already adds, this would cause a larger gap between sections. I don't think avoiding edit conflicts is a good justification for changing the appearance of pages. – PartTimeGnome (talk | contribs) 14:26, 23 June 2013 (UTC)

Just recommending to add one blank line (2 newlines) at end of page when creating/editing a page, because as Redrose64 already noted above, the MediaWiki software already auto-inserts a blank line at the bottom of section-edits (but auto-omits it during re-edit). With an auto-inserted blank line at end-of-page then conflicts with section=new would likely become very rare instead of commonplace. Meanwhile to avoid edit-conflicts in non-bottom threads, prepend the new bottom reply with a blank line. -Wikid77 14:54, 23 June 2013 (UTC)

After a few embarrassing situations where I posted exactly the same reply as someone else, I learnt not to put any blank lines in front of my replies (i.e. I want an edit conflict in that case). Also, where ::: or *** are used for indentation or bulleted replies, a blank line causes MediaWiki to end the indent/list and start a new one (i.e. "</dl><dl>" or "</ul><ul>" in the HTML). This causes problems with accessibility. With numbered replies, it also causes the numbering to reset to 1. – PartTimeGnome (talk | contribs) 15:13, 23 June 2013 (UTC)

You can't add one blank line (2 newlines) at end of page when creating/editing a page, because no matter how many you try to add, the last section on a page will be saved with exactly one newline and no trailing space. --Redrose64 (talk) 15:36, 23 June 2013 (UTC)

MOS:HEAD (version of 17:11, 22 June 2013) says: "Include one blank line above the heading, and optionally one blank line below it, for readability in the edit window."

—Wavelength (talk) 14:42, 23 June 2013 (UTC)

• Avoiding edit-conflicts in non-bottom threads: Consider prepending a blank above the new bottom reply to the thread, unless "Show-changes" reveals another editor has already put a blank line, so then put the bottom reply immediately but with blank line afterward (not before). I guess the issue is to upgrade the MediaWiki software to auto-insert a blank line at end-of-page, just as it does when editing any non-bottom section of the page. However, perhaps when reformatting the page then suppress the display of the bottom blank line, as typical in word-processing softare. -Wikid77 (talk) 15:46, 23 June 2013 (UTC)

No, don't. It's already been explained why not. --Redrose64 (talk) 15:59, 23 June 2013 (UTC)

I was just noting how to avoid edit-conflicts for people who have limited time to edit pages, but not force people to save changes quickly, if they would rather re-edit every time another person modifies a page. -Wikid77 (talk) 00:58, 27 June 2013 (UTC)

Avoiding redirection

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

The template to edit to do this is {{Country data West Germany}}. I believe the line to add would be something like this:

| link alias-rugby union = Germany {{{mw|}}} national {{{age|}}} football team

The template is protected, so you'd need to make a protected edit request on the talk page. (I've not tested the above. I'd suggest testing in the template's sandbox first.) – PartTimeGnome (talk | contribs) 14:56, 23 June 2013 (UTC)

• Rugby-topic decision moved to Template_talk:Ru: Because that issue should get consensus for that other template, I have repeated the question there:

• Template_talk:Ru#Handling_of_FRG - how to process option "FRG"

Point to that discussion for other Rugby editors. -Wikid77 15:46, 23 June 2013 (UTC)

I've dropped a note at Template talk:Country data West Germany#Rugby union link change as well. – PartTimeGnome (talk | contribs) 16:31, 23 June 2013 (UTC)

Navigation popups and Visual Editor

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

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

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

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

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

I like the all-caps shortcuts for the policy stuff – it helps identify it as such. I'd guess that most of the people to whom such notes are given do not have the sensitivity to all-caps (i.e. as screaming) that we do, either. —[AlanM1(talk)]— 18:05, 23 June 2013 (UTC)

It's better to write in proper English – that's what piped links are for. Graham87 02:11, 24 June 2013 (UTC)

Tech news: 2013-26

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

Recent software changes

(Not all changes will affect you.)

• The latest version of MediaWiki (1.22wmf8) was added to test wikis and MediaWiki.org on June 20. It will be enabled on non–Wikipedia sites on June 24, and on all Wikipedias on June 27. [2]
• Universal Language Selector was successfully enabled on the Catalan (ca), Cebuano (ceb), Persian (fa), Finnish (fi), Norwegian Bokmål (no), Portuguese (pt), Ukrainian (uk), Vietnamese (vi), Waray-Waray (war) and Chinese (zh) Wikipedias. [3]
• The new interface for account creation and log–in is now the default on all Wikimedia wikis. The old look is no longer available (bug #46333). [4]
• The TimedMediaHandler extension now supports native FLAC files. A discussion to allow this file type is taking place on Commons (bug #49505). [5]
• After a test period, the Disambiguator extension was enabled on the English Wikipedia on June 18. [6]
• VisualEditor news:
  • A VisualEditor bug temporarily made all new accounts unusable. The issue is now fixed and account creation works as before (bug #49727).
  • A high importance file insertion bug has been fixed, but the feature does not work perfectly yet. [7]
• It is now possible to synchronise local CSS and JavaScript files with the beta cluster. This should make it easier to test software features before they are enabled on live wikis. [8]

Future software changes

• The default link to a help page on editing, visible below the editing window, will change on almost 600 Wikimedia wikis and will now link to MediaWiki.org (bug #45977). [9]
• Universal Language Selector will be enabled on wikis without language versions (such as Wikisource and Wikispecies) on June 25. [10]
• The AbuseFilter extension will allow filtering links and HTML code for page creations. [11]
• The related changes special page will now include upload log entries. [12]
• It will soon be possible to choose the language of SVG files that contain translations. [13]
• MediaWiki will now allow converting audio files from one format to another. [14]
• The Wikidata technical team has started a discussion about how Wikidata can support Wiktionary. [15]
• The search feature on Wikimedia sites is planned to be modified to use Solr on all wikis by the end of 2013. [16]

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

18:07, 23 June 2013 (UTC)

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

Please change "Slovak Republic" to "Slovakia"

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

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

 Done. Thryduulf (talk) 00:38, 24 June 2013 (UTC)

essay nutshell collector would help

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

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

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

• The nutshell essay omits most pages, instead see WP:ESSAYSEARCH: The page mainly intended to help find other essays is wp:ESSAYSEARCH, which has noted 800 essay pages in the list, but needs more high-level phrases to describe many of the major essays. However, long-term, we need to improve the "associative retrieval" (or googling by wikisearch, Search [_________] ) to search for essays related to a set of words. The tactic is to have a unique idword (or idphrase), such as "essaypage", inside each essay page so that only those pages would match a wikisearch of "WP:" project pages (namespace: "&ns4=1") with search-word "essaypage", without the need to create an "essay namespace" to limit searches to matching only essays. Perhaps search with the essay phrase "Wikipedia essay" plus the specific words contained in various essays. -Wikid77 (talk) 10:00, 24 June 2013 (UTC)

That sounds too complicated for most users to remember, it's unlikely a controlled vocabulary would be applied with much consistency (consider the problem we now have with undercategorizing, failing to categorize, and miscategorizing articles and people have more practice with that when essayists probably write very few essays each), and Wikipedia:About essay searching does not normally appear on a search results page, so searchers will not usually find the advice. Nick Levinson (talk) 15:26, 24 June 2013 (UTC)

Rather than remember to include "essaypage" and namespace "&ns4=1" in a wikisearch, I am thinking there would be a search-link, and then the user could modify the search-words, after the first search. -Wikid77 (talk) 00:58, 27 June 2013 (UTC)

It's great that there are a number of ways to search through essays. I do hope that that's done primarily by experienced editors - for example, in deciding whether to write a new essay - because for most people, it's better to use the Editor's Index to Wikipedia. That index has, in addition to hundreds of essays, help pages and how-to pages and guidelines and policies and WikiProjects and lots of other entries, nicely organized by topic. (Full disclosure: I built most of it.) -- John Broughton (♫♫) 03:03, 26 June 2013 (UTC)

Same problem. A user has to know it exists. I didn't and I've been editing for years. It's useful, but, in this context, unless it shows up in search results, it's unlikely to be seen. And not all essays are in it, not even ones that are in the {{Wikipedia essays}} template. So editors still would benefit greatly from automation copying nutshells into one place, and, besides that, you might want to propose that the Wikipedia:Editor's index to Wikipedia be complemented by automation for discovering new items to be considered for adding to the index (considered, since the index's design requires thoughtful editing asnd not merely copying). Nick Levinson (talk) 15:35, 26 June 2013 (UTC)

Unified Login Question

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

When you log in, a cookie is set, which should be recognised for Wikipedia/Commons/Meta/etc. When I use Firefox, it works as intended. On the (rare) occasions that I need to log in but FF is not available - such as in a public library - I've had problems similar to those that you describe (I don't recall if it was IE8 or IE9), but I'm pretty sure that it's something to do with the browser's settings concerning cookies. --Redrose64 (talk) 22:13, 23 June 2013 (UTC)

Robert McClenon, as Redrose mentions, it is a cookie problem. The answer depends on how tight/loose your privacy settings are. My settings are tight. In my case I don't allow a wikipedia.org site (site you log in) to place a cookie for a (commons|meta).wikimedia.org site as those are two different domains (third-party). So, I have to whitelist some Wikipedia sites to allow cookies regardless of what my privacy settings are. Under IE, goto Internet Options -> Privacy tab -> Sites button. Add wikipedia.org and wikimedia.org as allowed. If you visit any other Wikimedia Foundation domains such as wikidata.org, wikibooks.org or wikivorage.org, you will need to add those sites too. I do the same whitelist option for Firefox and Chrome. Bgwhite (talk) 05:19, 24 June 2013 (UTC)

IE8 does have this problem. I frequently have to re-login to Meta on my work machine, which uses IE8 (work still back in the stone age, we're working on it). Jguy _Talk^Done 17:02, 27 June 2013 (UTC)

Pool queue is full

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

Yep, the same just happened to me, "An error has occurred while searching: Pool queue is full", which wsa rather annoying as it was an attempt to create a new page by adding the title in the search box... Also Firefox, for what it's worth. Fram (talk) 06:48, 24 June 2013 (UTC)

Generally this would mean that the search server is overloaded (Pool queue is a queue of people wanting to do something, to prevent too many people from doing it at the same time). Is this still happening? How often does it happen? Bawolff (talk) 22:33, 24 June 2013 (UTC)

I've just received the error message twice in succession. I've not seen it before, but this may be the first time today I hit a title that didn't exist. Thryduulf (talk) 22:39, 24 June 2013 (UTC)

It is still doing it today, quite regularly - I hadn't seen this until 23 June - is this a new "feature"? or the unwanted side effect of some other change? - It certainly slows us WP:WikiGnomes down. - Arjayay (talk) 09:20, 25 June 2013 (UTC)

I first saw this yesterday and now it's happening all the time... Carlossuarez46 (talk) 18:30, 25 June 2013 (UTC)

I've had to suspend spelling corrections etc. which rely on the search facility - my last 25 search attempts have all been met with the "pool queue is full" message. Why has this problem suddenly appeared? and when will it be dealt with? - Arjayay (talk) 18:36, 25 June 2013 (UTC)

I just had it happen to me, not for the first time. It's happened a couple of others times in the last 24 hours. — Maile (talk) 23:09, 25 June 2013 (UTC)

Hi all, this issue should be addressed now. Please do report this issue again if you experience any new symptoms. Thanks! Greg (WMF) (talk) 16:09, 26 June 2013 (UTC)

VisualEditor A/B test back on

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

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

Geohack awry as usual

When clicking on acoordinates link, this displays

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

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

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

</quote>

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

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

Green bullets in watchlists

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

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

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

On my screen the bullets are small and I can barely tell what colour they are, and anyway the links I haven't visited are bold, and I know that there are a lot of other projects that need work more urgently. —Anne Delong (talk) 18:47, 24 June 2013 (UTC)

Well, this actually sounds like a bad excuse to me. Anyway I'm happily contributing the needed graphics:

• File:ChangedBulletVector2.png –
• File:ChangedBulletMono2.png –
• File:ChangedBulletVector2 darker.png –
• File:ChangedBulletMono2 darker.png –

Hope they will be used since I don't like the 3D-look either (just didn't care enough about it yet to complain ). --Patrick87 (talk) 19:11, 24 June 2013 (UTC)

Patrick was quicker than me ;) Another way to do it, add:

Extended content
li.mw-changeslist-line-watched, li.mw-history-line-updated { list-style-image: url('data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUAAAANAQMAAABb8jbLAAAABlBMVEUAAAAA4AD7GUojAAAAAXRSTlMAQObYZgAAAAFiS0dEAIgFHUgAAAAJcEhZcwAACxMAAAsTAQCanBgAAAAHdElNRQfdBhgSKCF2D+ZrAAAAE0lEQVQI12NgQAEFDD/AsICBAQAakgPJO2sGpQAAAABJRU5ErkJggg=='); }

To your vector.css. jonkerz ♠talk 19:17, 24 June 2013 (UTC)

(edit conflict) Depending on your skin, you should put

li.mw-changeslist-line-watched, li.mw-history-line-updated { list-style-image: url("//upload.wikimedia.org/wikipedia/commons/c/ce/ChangedBulletMono2.png"); }

(bright version) or

li.mw-changeslist-line-watched, li.mw-history-line-updated { list-style-image: url("//upload.wikimedia.org/wikipedia/commons/3/3a/ChangedBulletMono2_darker.png"); }

(darker version) into Special:MyPage/monobook.css, or

li.mw-changeslist-line-watched, li.mw-history-line-updated { list-style-image: url("//upload.wikimedia.org/wikipedia/commons/c/cd/ChangedBulletVector2.png"); }

(bright version) or

li.mw-changeslist-line-watched, li.mw-history-line-updated { list-style-image: url("//upload.wikimedia.org/wikipedia/commons/3/34/ChangedBulletVector2_darker.png"); }

(darker version) into Special:MyPage/vector.css. Those will give a flat (2d) green bullet instead of a "shiny" 3d green bullet. --Redrose64 (talk) 19:21, 24 June 2013 (UTC) updated Redrose64 (talk) 07:41, 26 June 2013 (UTC)

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

The new bullets fail WP:CONTRAST (and I don't like them). If soneone can't see the original green bullets, these new ones are even harder to see. The point of the green bullets is that they are different then the default bullets, and not be too in-your-face. — Edokter (talk) — 20:28, 24 June 2013 (UTC)

Well, that's why we can't get rid of the "Changed since you last visit" text after all. Every reasonably sized and styled button fails WP:CONTRAST. Carrying this information in only a tiny little bullet is just not possible considering accessibility.

However my proposal reproduces the exact style of the default bullets for those who can see the color difference, therefore providing a consistent UI (which your icons lack). I think anybody that is not able to distinct between the current green and blue bullets won't be able to distinct between my proposal and the blue bullets either (and vice versa!). It just doesn't matter for them! Those who actually can see the difference will wonder why there is an inconsistent style applied to those buttons however. The current bullet just doesn't match the style of the rest of the page. --Patrick87 (talk) 20:43, 24 June 2013 (UTC)

bikeshed or not, I too would prefer a darker green if we would change from 3d to flat. —TheDJ (talk • contribs) 20:15, 25 June 2013 (UTC)

I tried a darker green (I added the links to the bullets above) but I think while it looks good in principle and fits the color scheme it gets really hard to notice the difference (see screenshots below). --Patrick87 (talk) 00:04, 26 June 2013 (UTC)

For those who wish to try the darker version, but are unsure of the CSS (simply altering ChangedBulletVector2.png to ChangedBulletVector2_darker.png won't work), I've added to my post of 19:21, 24 June 2013. --Redrose64 (talk) 07:41, 26 June 2013 (UTC)

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

There has been much heated debate on this page over a long period about this feature, which is why I deliberately didn't alter MediaWiki:Vector.css and MediaWiki:Monobook.css but instead suggested that those who wished to should put the change into personal CSS. It may well violate WP:CONTRAST: but when something is opt-in, it doesn't affect those who don't want it. --Redrose64 (talk) 21:33, 24 June 2013 (UTC)

Yes, and I deliberately changed the bullets to be less intrusive and better meld into the page so this much heated debate (that is still boiling below the surface) is cooled down a bit further. As the colored bullets are not opt-in they should look as if they belonged were they are (and bullets that were intentionally designed to look differently than the default ones, with a 3d look that is uncommon for Wikipedia, blatantly fail this task). I hope this is not a "Don't mess with The Doctor" decision and Edokter actually realizes that I want to aid the acceptance of his contribution with the changed icons. --Patrick87 (talk) 22:22, 24 June 2013 (UTC)

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

Screenshots of green bullets in watchlists

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

Maybe we should use a different color. Just putting that out there. Red, perhaps? Orange (complement of the blue)?  — TORTOISEWRATH 17:14, 26 June 2013 (UTC)

Thought about that, too. But red doesn't fit into the current color scheme, neither does the complementary color. Accessibility and design do not always go hand in hand . --Patrick87 (talk) 17:53, 26 June 2013 (UTC)

If they're not part of the default setup, but only set via personal CSS, they can be any colour you like, and neither aesthetics nor accessibility will apply. All that's needed is for a file to be created in the desired colour and an appropriate shape - round (for Vector), square (for Monobook and Modern), or round and hollow (for Cologne Blue). --Redrose64 (talk) 18:46, 26 June 2013 (UTC)

There are sooo many ways to have different bullets; color, shape, luminance... you name it. I just went the practical way. I choose green, becuase that color is ususally associated with change (as does the "changed since you last visit" message). Also, I didn't go for "3D", but for a "lit-up" appearance. But it any case... It's a bullet. As theDJ pointed out... why are we discussing the color of the bikeshed's doorknob? — Edokter (talk) — 19:34, 26 June 2013 (UTC)

Because we all come by bike and use it every day . The simplest things are not always the easiest to do after all. User interface changes have to be done with great care or they'll jump into your face.

Personally I wanted to improve Wikipedia with better suiting bullets (why spoil everybody's day already in the morning with an unpleasant doorknob at the bikeshed?). But if you're blocking my improvement there's not much I can do anyway. I had hoped for your insight but it seems you keep using your admin rights to style Wikipedia to your likes instead of lowering your sights, thinking globally and changing it to achieve the best result for the community.

I don't care anymore personally (as you say: its just bullets but I initially thought this would be an uncontroversial and welcomed change). Do what you deem right. I put the bullets I like best into my user CSS. I won't further benefit from a change anyway but the community will! --Patrick87 (talk) 20:02, 26 June 2013 (UTC)

Edits not showing up

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

if anything is to come out of this report, i think you should supply some more details. it would help if you list what exactly did you do (e.g., which page were you editing?), whether or not you have the new Visual Editor enabled, and if so, did you use "Edit" or "Edit Source" link, did you press "preview" or "Show Changes" before saving, and did you see the "your edit was saved" message after pressing "Save Page". also, it won't hurt to list which operating system (including version) and which browser (including version) are you using.

peace - קיפודנחש (aka kipod) (talk) 20:35, 24 June 2013 (UTC)

Article info is also welcome. --AKlapper (WMF) (talk) 07:05, 25 June 2013 (UTC)

I'm sorry not to have supplied details when I first reported this, but I assumed others were experiencing the same thing and there would be no need for specifics. It was at Bradley Manning, and I tried to make the edits between 18:43 and 18:53 UTC on 24 June. I saved and was told the edits had been saved. I tried a third time at 18:54 and at that point the edit "took". I referred in that edit summary to "third attempt to save this edit". [17] I didn't have the visual editor enabled, I didn't use preview or show changes, and I did see the "your edit has been saved" message on both occasions. SlimVirgin ^(talk) 01:16, 26 June 2013 (UTC)

At several points during the last 24 hours I've gotten edit conflicts with myself, which was fairly mysterious. It happened just now with this edit. — Scott • talk 02:24, 26 June 2013 (UTC)

Still happening. I'm using the latest Chrome for Windows if that helps. Oh, and when the edit conflict notice appears, the upper version of the text is the version before your changes, even though you've successfully saved them. Pretty confusing if you don't know what's going on. — Scott • talk 13:16, 26 June 2013 (UTC)

Yeah, I've been having some bizarre issues like this, too. Recently, I was in an edit conflict with someone even though we were editing different sections, and after I merged my changes back in, neither of our edits showed up, even after purging the page, though they were still evident in the diffs (but not the source). Very strange.  — TORTOISEWRATH 18:44, 26 June 2013 (UTC)

Citation templates not working (Part 2)

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

Perhaps you have compatibility view enabled in IE. There are some tips on controlling compatibility view here. —TheDJ (talk • contribs) 13:07, 25 June 2013 (UTC)

No, sorry. I should have mentioned that. I don't use compatability view. Fylbecatulous talk 13:34, 25 June 2013 (UTC)

This was working until quite recently, and as far as I know I have tinkered with nothing. I did make an edit on June 22: [18] to Keith Moon in which I copied and pasted a template for 'video' because that choice is not in the dropdown box. Could I have possibly sent it to its demise then? Fylbecatulous talk 14:03, 25 June 2013 (UTC)

This will require analyses by a community person (because it is a community tool) with technical knowledge and Internet Explorer. Unfortunately we hardly have any volunteers who have or want to work with explorer, so that constrains my ability to provide you with a solution. Aka, who has IE and wants to help Fylbecatulous ??? —TheDJ (talk • contribs) 18:25, 25 June 2013 (UTC)

In the meantime, I have discovered this feature still works for me on Simple English Wiki (and boy have I perused my settings there to see what might be different - no clue that anything is), so for now, I will just tab over to Simple to create my citations and then copy and paste to my chosen article here. (Desperate times call for desperate measures....) I have even read the page on Wikipedia:RefToolbar to assure myself that my settings are correct. They are, just non-functioning...thanks Fylbecatulous talk 20:49, 25 June 2013 (UTC)

Well, and as an aside, I got booted up to technical level three support with an unnamed large internet provider because there was a glitch in my website whilst paying my bill online (because I, in frustration, told a poor call service agent I was smarter than she and give me someone who knew what they were talking about...) This tech person said they no longer support IE actually. I suppose I am going to need to download another browser. Especially if I am amongst the last remaining holdouts on Wiki...what should I choose? Fylbecatulous talk 20:59, 25 June 2013 (UTC)

There are plenty available, and there is nothing to stop you installing several, and trying out each one. Personally, I use Mozilla Firefox, but I have three other Windows browsers installed: Google Chrome; Opera; and Safari. --Redrose64 (talk) 21:43, 25 June 2013 (UTC)

Thank you, Redrose. When I get home today, I shall experiment. Surely one will be fine. I will just drop this happenstance as a quirk for now, especially since I can still use the template on Simple Wikipedia. A mystery? I promise that the next time I report an incident, it will at least be in a different browser. Happy editing! Fylbecatulous talk 10:49, 26 June 2013 (UTC)

When will bolding come back onto the watch lists again?

Tracked in Phabricator
Task T51610

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

My watchlist is showing the bolding now. —Anne Delong (talk) 16:58, 25 June 2013 (UTC)

You are jusing JavaScript, Geitost is not (as far as I know). That's the difference. The CSS is loaded by JavaScript since a current update, the patch partially reverted that. --Patrick87 (talk) 17:14, 25 June 2013 (UTC)

It works for me too, even with JavaScript disabled, in both Firefox and Chrome. The bolding disappears after disabling the gadget and appears after enabling it (and I'm not using any custom css). jonkerz ♠talk 17:23, 25 June 2013 (UTC)

What you linked to is a submission. The submission has not yet been accepted and merged into the source code. (partly due to me not having the time to do a lot of development over the past 2 weeks). —TheDJ (talk • contribs) 18:19, 25 June 2013 (UTC)

Ok, I thought, if there once is a fix to get merged, then it doesn’t take more than a week that it’s getting live because of the weekly updates. So, with the update today, there will also be no fix then? --Geitost 08:19, 27 June 2013 (UTC)

The changes have just been merged and will go live the next time around, on July 11 (see mw:MediaWiki 1.22/Roadmap). Matma Rex talk 10:03, 27 June 2013 (UTC)

I see, thanks for the info – and for merging (whoever did it) and @TheDJ especially also for fixing. --Geitost 11:16, 27 June 2013 (UTC)

Python 3 bots

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

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

Fix the Toolserver

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

Err, what policy revamp? The only thing that is in the queue at the moment is to tweak the TOS so that the normal Wikimedia-wide privacy policy can apply to Tool Labs, and that hasn't gone to the presses yet that I know of. — MPelletier (WMF) ^(talk) 21:10, 25 June 2013 (UTC)

If there are specific parts of Labs' policy you have issues with, please let us know. Saying it is sketchy without any details of what the "sketch" is doesn't help us resolve the issues. We intend for our policies to be relatively open, so we'd love to discuss.--Ryan lane (talk) 21:47, 25 June 2013 (UTC)

https://meta.wikimedia.org/wiki/Toolserver#Contact and https://wiki.toolserver.org/view/Main_Page might be good places for the toolserver part of your comment. --AKlapper (WMF) (talk) 09:13, 26 June 2013 (UTC)

uselang=qqx displays message instead of its name

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

MediaWiki:Recentchangestext as used on Special:RecentChanges is forced to the wiki's content language, so it is unaffected by uselang. Anomie⚔ 21:04, 25 June 2013 (UTC)

Thanks for the explanation. I guess the documentation for uselang=qqx could use a note about this, and whether there is a good way to find message names when they are forced to the content language. PrimeHunter (talk) 21:25, 25 June 2013 (UTC)

Honestly, there isn't a good way for content messages (beyond grep or source if the message is still the default or search if the message has changed from the default). Bawolff (talk) 00:46, 26 June 2013 (UTC)

Template:Multiple image not working in several browsers when zoomed

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

Universal Language Selector will be enabled on July 2, 2013

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

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

Just a "stupid" question: What are all these settings actually good for? I mean the interface language can be changed from settings, the input language will be disabled if I understand correctly and the "fonts" section is somehow misplaced (how is this a language setting?). Don't want to bug you, but I'm just always wondering on every Wiki that has ULS already activated what I should actually do with it (can one disable it?). --Patrick87 (talk) 09:45, 26 June 2013 (UTC)

Well, I used this CSS in my monobook.css to hide a bit of it (if you use the Vector skin, I think this will also work in vector.css, though I've not checked). I'm not sure what it's for either – I think it does something useful if you use a non-Latin script. – PartTimeGnome (talk | contribs) 21:18, 26 June 2013 (UTC)

Since the whole thing is loaded using JavaScript I'd want to correctly deactivate it (not just hide it) to save resources. When only hiding ULS it still loads in background. And even if it might be fast it accumulates with every bit of JavaScript added. Have you tried lately to load a page, once with JavaScript enabled and once with JavaScript disabled? You'd be surprised by the improvement (and the flickering the things loaded by JavaScript in pieces actually create). --Patrick87 (talk) 21:45, 26 June 2013 (UTC)

Yes, that is one of the reasons I have JavaScript disabled... My CSS just hides a link that is rather pointless without the associated JS. – PartTimeGnome (talk | contribs) 22:35, 26 June 2013 (UTC)

Ctrl & click Edit won't open in new tab

Tracked in Phabricator
Task T51993

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

Seems to be caused by the VisualEditor A/B test code. I filed Template:Bug. Matma Rex talk 10:22, 26 June 2013 (UTC)

Thanks for that. BTW I don't have VisualEditor enabled in my Preferences. I don't know if that is relevant. —Bruce1ee^talk 10:30, 26 June 2013 (UTC)

I have exactly the same behaviour in Firefox 22.0 on Windows Vista. It happens whether I'm logged in or out, and it doesn't help to clear my entire cache. It doesn't happen in any of Chrome, IE, Safari, Opera. And in Firefox it doesn't happen at any of de:, fr:, es:. At mw: it appears to only happen in namespaces where VisualEditor is enabled, but not on the "Edit source" tab. PrimeHunter (talk) 10:40, 26 June 2013 (UTC)

Me too, and it is highly irritating. In Firefox 21 with scripting disabled, there is no problem. I was just at bn: with scripting enabled, and there is no problem there. However, editing here with scripting prevents ctrl+click_edit from opening a new window/tab. Johnuniq (talk) 11:22, 26 June 2013 (UTC)

The lines... a bit too long

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

You can set a maximum width in your personal CSS file:

div#mw-content-text { max-width: 100ex; }

will give approximately 100 characters for the main portion of a page. --Redrose64 (talk) 14:26, 26 June 2013 (UTC)

• Looks like WP typesetter never found Return key on the typewriter: Several people have kept noting the need for shorter, more readable lines on wide pages, which has been common knowledge among educated typesetters for many decades. It is extremely ironic how the wp:MOS people have spent millions of hours to force state-of-the-art "professional" text styling (even to transform hyphens into a new look), and yet meanwhile, the overwide pages look like they were typeset by a 7-year-old, who found a typewriter and just kept typing words but never found the carriage-return key and just kept putting in more sheets of paper to continue typing the long lines without wrapping. Too funny!! The wp:MOSquito bites them in the rear again! My thanks to User:Sky6t for noting the "elephant in the room" of Typesetting 101, "Hit RETURN at the end of the line" (hello?). Perhaps we should change the tag-line to, "The sum of all knowledge except typesetting". Well, all cosmic jokes aside, I guess setting an upper maximum page width would be a good reminder so people learn to narrow their windows and read so much faster. It really looks like the "cuckoo's nest" to see WP pages with 40-words-per-line, and pretend to be an encyclopedia. Are there any browsers, yet, which display a 2-column mode to show a webpage as two-page panels in a window? Meanwhile, setting a default maximum page width is a good idea. I have already proposed a smart template, as Template:Tracklist/custom, to show a list of album song titles in normal-width tables, rather than as wp:splat tables which stretch to the horizon on wide windows. -Wikid77 (talk) 06:56, 27 June 2013 (UTC)

Common editor analyzer

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

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

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

All articles

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

@Dr. Blofeld: See the box at the bottom of Special:Contributions/Dr._Blofeld, and the "Articles created" link near the middle. :) –Quiddity (talk) 16:21, 26 June 2013 (UTC)

Hehe, I'm well aware of that of course, and I can never get it to load. SOmebody said it took 36 minutes or something. I need some sort of automated tool to copy and paste a list.♦ Dr. ☠ Blofeld 16:22, 26 June 2013 (UTC)

I'm that "somebody", but as I recall, it took longer: something like 45 mins before I killed the query and restarted it. I posted details, but I can't remember whose talk page this was on though. For those not aware, Dr. Blofeld is one of the most prolific article creators, with several thousand per month --Redrose64 (talk) 18:12, 26 June 2013 (UTC)

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

• Perhaps scan categories instead, as Articles-created are reverse order: It might be much easier to just hunt for the articles created in specific older categories, rather than list all thousands of created pages and sift through them. Currently, the default "Articles-created" tool shows the created articles in reverse chronological order:

http://tools.wmflabs.org/xtools/pages/index.php?name=Dr._Blofeld&lang=en&wiki=wikipedia&namespace=0&redirects=noredirects&getall=1

Expect that to run 5 minutes per 40,000 edits, or 1 hour per 480,000. However, to flip the list order, perhaps there would be an option similar to "&dir=prev" but that does not reverse the list. Anyway, it might easier to scan categories of articles created years ago, and then remember the similar article titles of the time. -Wikid77 (talk) 00:58, 27 June 2013 (UTC)

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

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

Yes, same thing. Matma Rex talk 16:40, 26 June 2013 (UTC)

I'm sure it is related to the above, for which a bug has been filed. —Bruce1ee^talk 04:50, 27 June 2013 (UTC)

Voice search

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

CSS/JS issue?

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

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

Screenshot, please? Matma Rex talk 10:29, 27 June 2013 (UTC)

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

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

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

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

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

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

• Support something like this. Goes well with "View source" when you can't edit the page - David Gerard (talk) 11:05, 27 June 2013 (UTC)
• Support - But I want to clarify a couple things. First, Visual editor currently can only edit a couple namespaces but at a point in the future it will be able to edit all or most namespaces. So most people will eventually have it anyway. I don't particularly like "Edit"/"Edit source" terms anyway. Its confusing as to what the difference is so I think we need to change the "Edit" term to something else like "Edit text" or something similar. Kumioko (talk) 11:16, 27 June 2013 (UTC)

1. In the interim if anybody just wants to do it I created a user script for use User:KumiokoCleanStart/ScriptEdittoEditSource.js. Just add it to your vector.js page. I'll add some better instructions of loading later. Kumioko (talk) 11:40, 27 June 2013 (UTC)

• Oppose - Concealing the one important feature of Wikipedia – editing pages – behind a label that might only slightly suggest expert knowledge might be needed (editing "source code") is a very bad idea. --Patrick87 (talk) 11:38, 27 June 2013 (UTC)
• Support something. Oppose "edit source". Something like "edit old" or "edit WikiText" may work better, in addition to making sure the new tab is "VisualEditor" or another thing like that. Charmlet (talk) 14:13, 27 June 2013 (UTC)
• Support [Wikitext][WYSIWYG] or the like... Technical 13 (talk) 15:05, 27 June 2013 (UTC)
• Support - we are offering two very different edit interfaces, and there absolutely should be consistency in the labelling of the tabs that lead to them. I am already finding it confusing that "Edit" sometimes gets you VE and sometimes doesn't. I don't see anything wrong with "Edit" and "Edit source", but whatever is chosen should be simple and consistent. JohnCD (talk) 15:14, 27 June 2013 (UTC)
• (edit conflict) Oppose As Patrick87 pointed out, Edit Source, people think source code, example: HTML markup. <h1><br /><strong> and all that. This could potentially scare people away from editing a page if they think they're editing "source code", as what is suggested with Edit source. Jguy _Talk^Done 15:22, 27 June 2013 (UTC)
• Oppose and please get rid of "view source" as well. As stated above the use of "source" is very confusing - it is not the source - and this could cause double confusion when discussing a WP:RS - Arjayay (talk) 15:40, 27 June 2013 (UTC)
• Support Well, in the old editor they are editing the markup source, as opposed to the new one which hides it. I can't be the only user who spends a lot of time in Talk and Wikipedia space and who is getting mixed up and choosing the wrong option frequently when switching to article space. I am assuming that eventually the visual editor will do everything most people need and they won't use "edit source" much. —Anne Delong (talk) 15:43, 27 June 2013 (UTC)

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

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

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

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

• That is correct Pat. This is a VE bug, would you please submit a ticket for it on Bugzilla? Thanks. Technical 13 (talk) 16:36, 27 June 2013 (UTC)

Ah. That would make sense. I don't have the VE enabled and don't see the changes right now, so that's probably my reason as well. Thanks for pointing it out Pat! Jguy _Talk^Done 16:57, 27 June 2013 (UTC)

Notifications query

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

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

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

Google Chrome Login for 30 days(not working)

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

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

User is logged out and has to login again

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

I'm seeing an issue (using Firefox) where logging into the secure servers doesn't log me into the non-secure side. I had to update any bookmark that started with http:// to https:// and that worked. Apparently the secure and non-secure login servers are not talking to each other. Could be related to your issue. (I just noticed that I am not logged in right now. Dang it)...(Ok, now I'm logged into the non-secure side.) --| Uncle Milty | talk | 15:35, 27 June 2013 (UTC)

Er... That's intentional. When you login by HTTPS, you are given a secure login cookie; i.e. it won't be sent over plain HTTP. It is almost as important to secure your login cookie as it to secure your password, since either could be used to impersonate you (though the login cookie can only be used for 30 days). – PartTimeGnome (talk | contribs) 20:04, 27 June 2013 (UTC)

Pings only sometimes working at the education noticeboard

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

Script for edit buttons to banish VE

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

Cite tag & editing issue

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

• When attempting to click Cite > Templates > [cite x] on my editing browser (I have the cite tag feature enabled), the desired cite dialog box does not appear, and instead I'm bumped to the top of my browser page. Typically, the named references and error check have their respective logos cut off at the bottom, where the edit window begins. I have tried re-sizing my browser window, to no avail.

• I also have the edit lede section enabled. However, although the URL indicated by hovering the mouse over [edit] beside the page title indicates "&action=edit&section=0", after clicking it boots me to "&action=edit&section=1"! Correcting the browser URL back to &section=0 solves the problem.

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