Wikipedia:Village pump (technical)

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 security

wikimedia.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.

view · edit

Frequently asked questions (see also: Wikipedia:Technical FAQ)

Click "[show]" next to each point to see more details.

If something looks wrong, purge the server's cache, then bypass your browser's cache.
This tends to solve most issues, including improper display of images, user-preferences not loading, and old versions of pages being shown.

No, we will not use JavaScript to set focus on the search box.
This would interfere with usability, accessibility, keyboard navigation and standard forms. See task 3864. There is an `accesskey` property on it (default to `accesskey="f"` in English). Logged-in users can enable the "Focus the cursor in the search bar on loading the Main Page" gadget in their preferences.

No, we will not add a spell-checker, or spell-checking bot.
You can use a web browser such as Firefox, which has a spell checker.

If you have problems making your fancy signature work, check Help:How to fix your signature.

If you changed to another skin and cannot change back, use this link.
Alternatively, you can press Tab until the "Save" button is highlighted, and press Enter. Using Mozilla Firefox also seems to solve the problem.

If an image thumbnail is not showing, try purging its image description page.
If the image is from Wikimedia Commons, you might have to purge there too. If it doesn't work, try again before doing anything else. Some ad blockers, proxies, or firewalls block URLs containing /ad/ or ending in common executable suffixes. This can cause some images or articles to not appear.

For server or network status, please see Wikimedia Status. If you cannot reach Wikipedia services, see Reporting a connectivity issue.

« 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

VisualEditor going live

Hey all; the VisualEditor will be going live for all accounts in the next few minutes/hours. Wikimarkup editing will still be available, if you don't want to use it - if you encounter bugs, or have any questions, drop them on the feedback page. Thanks :). Okeyes (WMF) (talk) 20:11, 1 July 2013 (UTC)[reply]

If we get questions about this at OTRS should we just move them to the tech-issues queue or do you want them forwarded somewhere else? Thanks. — Preceding unsigned comment added by Ukexpat (talk • contribs) 20:18, 1 July 2013 (UTC)[reply]

Works for me; I'll monitor it as we go :). Okeyes (WMF) (talk) 20:20, 1 July 2013 (UTC)[reply]

(edit conflict) Hi Okeyes, I've asked at least three times, with no answers, regarding which browsers you're supporting. Since I'm still unable to turn it on in preferences, please post somewhere which browsers will see and which will not - I assume some of us will not. That will cut down potential confusion, imo. Also, the watchlist notice is incredibly small - might want to make that more prominent since not everyone watches the relevant pages. Thanks. Victoria (talk) 20:23, 1 July 2013 (UTC)[reply]

Hi Victoria! The FAQ page at mediawiki.org now has that answer, and I'll tell my team to look into the watchlist notice thing. Thanks for your feedback, --Elitre (WMF) (talk) 20:31, 1 July 2013 (UTC) PS - actually I did not realize it is written here as well :)[reply]

Victoria, what browser are you using? Okeyes (WMF) (talk) 20:35, 1 July 2013 (UTC)[reply]

Okeyes, I've asked here 3 times - the threads have all been archived, the questions ignored. I know, having spoken with Apple, that a subset of users w/ some versions of OSX will not be supported. The browser support is not listed at the page mentioned above. Personally, I don't care, I'll continue to edit as I have, but saying it's available to all logged in users is incorrect. Victoria (talk) 20:41, 1 July 2013 (UTC)[reply]

Afaik: Right now, it supports FF 11+, Iceweasel 10+, Chrome ?16+, and Safari 6+, regards --JEissfeldt (WMF) (talk) 20:43, 1 July 2013 (UTC)[reply]

Hi Victoria, I have at least a user on it.wp happily editing from OSX using Chrome. Perhaps you might want to try as well? Thanks for your reminder about browsers, it is important that that section is clear and complete about it. --Elitre (WMF) (talk) 20:46, 1 July 2013 (UTC)[reply]

Yes, that's right. With a Macbook Pro users have to go to Chrome. They leapfrogged Safari to Snowleopard, loaded an older version to the machines when Lion was released. Go figure. But that's how it is. Victoria (talk) 20:54, 1 July 2013 (UTC)[reply]

Here's a question... I was approached regarding developing a gadget to disable VE buttons. Does that mean that the option to en/disable the VE in Preferences (Editing tab) is going to disappear? — Edokter (talk) — 20:58, 1 July 2013 (UTC)[reply]

Edokter - when we switch to this being the parallel interface - and the one that you get when you hit the "edit" button - yes, that option will go away. If you'd like to disable the thing - we really wish you wouldn't, because both VE & source editors are easily accessible from the interface (both from the tabs and the section edit links), and some features will be really useful to experienced editors as well, like the dialogues to edit complex templates and references. Also, your help in identifying bugs and training new users will be invaluable. That said, if you really can't stand the extra tab, a community member has written a user script that you can use to completely hide VisualEditor from your interface. You can do so by adding importScript('User:Matma Rex/VE killer.js'); to your common.js file. But how about giving it a whirl first? Philippe Beaudette, Wikimedia Foundation (talk) 21:07, 1 July 2013 (UTC)[reply]

No, no, no! You cant be serious! The option is already there – why remove it? If (and only if) I decide to check some compatibility issues I'll activate VE from my preferences. I neither want to see it otherwise nor do I want to load it unnecessarily in background. Wikipedia is a damn slow JavaScript monster by now. Don't you see what you're doing by forcing more an more JavaScript feature on editors? --Patrick87 (talk) 21:21, 1 July 2013 (UTC)[reply]

Yeah, I've coded that up already, because I strongly believe the option should be kept as well. Matma Rex talk 21:17, 1 July 2013 (UTC)[reply]

Thanks Matma Rex, but hiding the VE with the help of CSS or JavaScript is not decreasing loading times. It's only curing the symptoms while a simple checkbox in user setting could cure the disease. --Patrick87 (talk) 21:21, 1 July 2013 (UTC)[reply]

Yes, I realize, using that script is the worst of both worlds. I have no idea why VE team insists on killing the preference when we even can still use the old editing toolbar. Matma Rex talk 21:24, 1 July 2013 (UTC)[reply]

How do I turn it off, entirely, so I don't have to choose between normally editing and VE editing? I don't see anything in Preferences. Beyond My Ken (talk) 21:48, 1 July 2013 (UTC)[reply]

How the hell do I get rid of it? Catfish Jim and the soapdish 21:52, 1 July 2013 (UTC)[reply]

The .js script given above is not working for me. I really would like to turn this off and retain the option of trying it out when I'm ready for it, not when the developers are ready for it. Please restore the turn off switch to Preferences as soon as possible. Beyond My Ken (talk) 21:56, 1 July 2013 (UTC)[reply]

This goes to the question of which browsers support too. If push comes to shove and people don't want, or do want, it's important to know which browser to upgrade to or downgrade to - though that's quite slightly insane, imo. The option to choose should remain. I've had the option for weeks and it's been worthless, hasn't done a thing when I've enabled (and I'm currently a very active editor, know where to post so think of me a cockroach - see one when there are many) - so it would be useful to have the option for those of us who are trying to figure a., if we can use the UI, and 2., whether or not we want it. If you're to emulate google, consider that they always give an option to try a new feature and to return to the older feature. I still have the old compose for instance, though it was introduced quite a long time ago. Victoria (talk) 21:57, 1 July 2013 (UTC)[reply]
One bright point in all this: I don't have to worry about people vandalising music charts or discographies any more: no one will be able to figure out how to edit them. —Kww(talk) 21:58, 1 July 2013 (UTC)[reply]
- Hi all, apologies for not being able to answer everything right now: we're going to explain in a bit more detail but we're a bit overwhelmed at the moment since the real launch happened minutes ago. I will draw the team's attention to this whole discussion, and hopefully they can provide a more complete answer. --Elitre (WMF) (talk) 21:59, 1 July 2013 (UTC)[reply]
  - There are no plans to install or restore a turn off switch to Preferences. I realize that it is a disconcerting change - I am not particularly change-friendly myself, but I'm happy to say that in the time I've been interacting with it it has pleasantly surprised me, even back when the bugs were far more substantial. :) Of course, everyone has the option of using the old interface (and sometimes - such as when working on copyright investigations - it's the only thing that works for me), but it's there if you change your mind. --Maggie Dennis (WMF) (talk) 22:03, 1 July 2013 (UTC)[reply]
    - - Then you seriously need to reconsider those plans immediately. This is not a question about whether the editor is good or bad, it's a question of choice. I've managed to make many thousands of edits with the old editor and I'm quite conversant with it. Your forcing me to make an extra choice each and every time I edit is taking up my time, not yours, and, quote frankly, the choise not to keep the turn-off switch in place is downright rude. Beyond My Ken (talk) 22:19, 1 July 2013 (UTC)[reply]
        The .js script above is also not working for me, I still have two edit tabs, and the section edit tabs are far over to the left and butt ugly as a result. - The Bushranger _{One ping only} 22:27, 1 July 2013 (UTC)[reply]
    - That's strange. I've gone and played with a number of music-related articles and haven't found one yet where it actually worked. Try editing the tables in Akon discography, for example, and watch the tables melt into a pile of misaligned html text being treated as field entries. Try to add or remove a chart from a simple chart list like Bus Stop (song)#Charts. I don't know where to start writing the bugzilla reports because I can't find a working article to compare the broken behaviour to.—Kww(talk) 22:08, 1 July 2013 (UTC)[reply]
      - Hi Kww, just try and describe what happens in the feedback page, don't worry about the rest. Thanks. --Elitre (WMF) (talk) 22:14, 1 July 2013 (UTC)[reply]
      - Your problem may be browser specific. I don't see any obvious errors or malformations when trying to edit the tables in Akon discography. Or maybe you need to explain what action causes the error more precisely? Dragons flight (talk) 22:15, 1 July 2013 (UTC)[reply]
      - When I tried editing the table it worked for me...just very slowly. It went slowly when I reverted myself, too, so it may just be the article. :) --Maggie Dennis (WMF) (talk) 22:17, 1 July 2013 (UTC)[reply]
        Are you saying that when you click http://en.wikipedia.org/wiki/Akon_discography?veaction=edit and scroll through the tables, you don't see snippets of HTML style tags being presented as table data? Check out "Singles->as lead artist" and tell me what album "Oh Africa" is from.—Kww(talk) 22:20, 1 July 2013 (UTC)[reply]
        I see what you're talking about now, Kww. I'll file a bug. You'll be able to track it on the feedback page. Keegan (WMF) (talk) 22:28, 1 July 2013 (UTC)[reply]
  - @Victoriaearle:: As answered to you above, VE currently definitely runs on FF 11+, Iceweasel 10+, Chrome 16+, and Safari 6+. This information is also in the FAQ on mediawiki. Keegan (WMF) (talk) 22:10, 1 July 2013 (UTC)[reply]

@Keegan: - thank you, I read it. What I am trying to say, perhaps unelegantly, is that this has been a rather developer-centric, Silicon Valley-centric rollout without taking into consideration the idiosyncrasies of this particular community of users. I know that I can't use b/c you don't support my browser (said many times now) but somewhere, someplace, would be very useful for you all to post prominently which browsers are supported so as to cut down some of the questions. That's all I meant and will leave you to it now. Victoria (talk) 22:37, 1 July 2013 (UTC)[reply]

No offence, but I find the refusal to provide an off switch to be dissapointing and even a bit arrogant. We like the "old" editing interface and have zero desire to use VisualEditor. And, in my case, that's even assuming it would even work at all in Firefox 5.0. - The Bushranger _{One ping only} 22:18, 1 July 2013 (UTC)[reply]
- - And totally inexplicable, considering that this reaction was entirely predictable. It's also distracting what the developers want, which is feedback, which I'll be more than happy to give when I decide to test the editor. Beyond My Ken (talk) 22:25, 1 July 2013 (UTC)[reply]
  - I completely agree, an opt-out feature is nearly a necessity for a feature of this magnitude. For a lot of the work I do, the VE is incredibly cumbersome and simply does not work, not to mention that it's harder to simply edit anything IMO. StringTheory11 (t • c) 22:29, 1 July 2013 (UTC)[reply]
- Confirmed: VisualEditor will not load in Firefox 5.0. - The Bushranger _{One ping only} 22:22, 1 July 2013 (UTC)[reply]
  - This isn't surprising; Firefox 5.0 was released in mid-2011 and is no longer supported.--Jorm (WMF) (talk) 22:27, 1 July 2013 (UTC)[reply]
    - Then being able to turn off VE, which I cannot use, would be very good, wouldn't it? As I have no interest in changing or upgrading browsers as mine works just fine for everything but VE. - The Bushranger _{One ping only} 22:30, 1 July 2013 (UTC)[reply]
I use version 6.0.5 of Safari and it isnt working.Blethering Scot 22:24, 1 July 2013 (UTC)[reply]
- Please could you provide more information about what operating system you are running? Thehelpfulone 22:26, 1 July 2013 (UTC)[reply]
- (edit conflict)Works like a charm for me with Safari 6.0.5 on Mountain Lion; user agent Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_4) AppleWebKit/536.30.1 (KHTML, like Gecko) Version/6.0.5 Safari/536.30.1. Theopolisme (talk) 22:27, 1 July 2013 (UTC)[reply]

Yes, on Mountain Lion it will work; Safari for Lion is different. I had a 2 hour phone call about this w/ Apple. Reported to Okeyes (WMF) but not interested. Victoria (talk) 22:41, 1 July 2013 (UTC)[reply]

Let's be blunt: I can barely use Wikipedia right now because the section editing tags are knocked so far over to the left they are horrendous. Please install a turnoff button, instead of dismissing editors' concerns with "you'll like it". - The Bushranger _{One ping only} 22:29, 1 July 2013 (UTC)[reply]
- 100% agreed. I fear that WP may lose many editors if a shutoff button ins't installed. StringTheory11 (t • c) 22:30, 1 July 2013 (UTC)[reply]
  - Bushranger, what OS and browser are you using? The opt-out script works fine for me. Ditto Stringtheory11, if you have problems. Okeyes (WMF) (talk) 22:32, 1 July 2013 (UTC)[reply]
    - The editor itself works fine for me, but I can't stand how horrendously complicated it is to do something as simple as adding a template or a ref. StringTheory11 (t • c) 22:34, 1 July 2013 (UTC)[reply]
    - Windows 7 and Firefox 5.0. As noted above, the script isn't working for BMK either. - The Bushranger _{One ping only} 22:34, 1 July 2013 (UTC)[reply]
      - Well, I'm really confused, then. I was given to understand that on something as outdated as 5.0 you simply shouldn't be presented with the option to use the VE. I'm going to follow up on this and try to work out why FF5.0 isn't being effectively blacklisted. Okeyes (WMF) (talk) 22:36, 1 July 2013 (UTC)[reply]
        At the top of articlespace pages (but not userspace or Wikipediaspace) there are 'edit this page' and 'edit source' buttons, and on the sections the 'edit' tab is bonked over left by an 'edit source' that pops up when I mouseover it. (This also does not appear on nonarticlespace pages.) - The Bushranger _{One ping only} 22:37, 1 July 2013 (UTC)[reply]
        And you're not useragent spoofing or anything? Thanks for bringing it up; I'm going to make this highest-priority. We deliberately shouldn't be displaying the VE to you. @Beyond My Ken:, what's your setup in browser and OS terms? Okeyes (WMF) (talk) 22:41, 1 July 2013 (UTC)[reply]

- - - - I'm using FF 22.0 under Windows 7 Home Premium with the Monobook interface, but my problem isn't with making VE work, my problem is that I'm trying to plow my way through a bunch of work and I really don't have time to be your guinea pig at the moment. I need a turn-off switch so I can disable VE now and take a look at it when I'm ready to. The script above did not in any way make a difference. It's good that your collecting data on what systems it works under etc., but I'm afraid your rather missing the point: you need to provide the turn-off switch and allow users who do not want to use it a chance not to. You cannot (or rather, you should not) be forcing this on us. Beyond My Ken (talk) 22:51, 1 July 2013 (UTC)[reply]

- - - - @Beyond My Ken: huh, weird. That's precisely my interface. Did you clear your cache? Okeyes (WMF) (talk) 23:00, 1 July 2013 (UTC)[reply]
        Yes, a number of times. Beyond My Ken (talk) 01:21, 2 July 2013 (UTC)[reply]
        
        Thanks, and AFAIK I'm not, since I've never heard of that or know what it is! - The Bushranger _{One ping only} 22:45, 1 July 2013 (UTC)[reply]
      - Using Mac OSX Lion 10.7.5. Safari 6.0.5. It isn't working is it the os version because its not the latest.22:39, 1 July 2013 (UTC)Blethering Scot
        The VE isn't working, or the opt-out, or both? Okeyes (WMF) (talk) 22:41, 1 July 2013 (UTC)[reply]
        Wasn't getting the option to use it but realised thats maybe because i use the modern skin, so switched to vector got the option but just wouldn't work at all.Blethering Scot 22:44, 1 July 2013 (UTC)[reply]
        What does "not working" look like? (and did you clear your cache? It could be the user script isn't updating things yet). Sorry to be asking silly questions - just trying to pin down the source of the issue here. Okeyes (WMF) (talk) 22:47, 1 July 2013 (UTC)[reply]
        
        In my case, both. Here's what I'm seeing, even with the .js installed (mouse pointer is over the 'Racing career' edit button). - The Bushranger _{One ping only} 22:42, 1 July 2013 (UTC)[reply]
        I meant Blethering Scott; for you, are you useragent spoofing? Okeyes (WMF) (talk) 22:43, 1 July 2013 (UTC)[reply]
        ...since I have no idea what that is, I'm assuming no? - The Bushranger _{One ping only} 22:45, 1 July 2013 (UTC)[reply]
        Oy :(. Okay, throwing this at the developers now. Thanks for bringing it to my attention - I'll give you a poke as soon as I've found out what on earth is going on. Okeyes (WMF) (talk) 22:47, 1 July 2013 (UTC)[reply]
        Now at bugzilla:50534. Okeyes (WMF) (talk) 22:53, 1 July 2013 (UTC)[reply]

Bushranger - fix for your issue coming soon (hours, hopefully). PEarley (WMF) (talk) 23:41, 1 July 2013 (UTC)[reply]

Thank you. - The Bushranger _{One ping only} 23:47, 1 July 2013 (UTC)[reply]

FF5.0 now shows the non-VE as default, thanks very much. - The Bushranger _{One ping only} 01:20, 2 July 2013 (UTC)[reply]

- - @Okeyes: Please don't get into discussions whether the "opt-out script" is working or not. Make sure the opt-out preference is correctly added back to the user preferences. This is the only clean and acceptable solution. Everything else can be considered eyewash to make us more comfortable with the transition. All contents of VisualEditor are still loaded in the background and it only produces compatibility problems as those reported above. --Patrick87 (talk) 22:51, 1 July 2013 (UTC)[reply]
    - At the moment I'm making sure that the VisualEditor isn't loaded for users with blacklisted browsers. Okeyes (WMF) (talk) 22:53, 1 July 2013 (UTC)[reply]
      - So we have to do user agent spoofing to be able to disable visual editor? Pretend to be somebody else who we actually are not just to get the features we need (and only those)? Is this what you want to tell me . What is the reason to not simply add back the pereference to disable VisualEditor? This is already in the code and would be a no-brainer to add back. Probably you even had to remove it prior to the final deployment of VisualEditor. I really do not understad what you are trying by patronizing us and forcing features on us we do not need? --Patrick87 (talk) 23:29, 1 July 2013 (UTC)[reply]

My first impression is that I extremely don't like this. But, I am also a long-time veteran editor who is very comfortable with the classic edit window, so I know VE isn't really aimed at me anyway. VE will just slow me down, but hopefully it does help new/novice editors who would prefer a word processor-like experience. I can get used to clicking "edit source" at the top instead of "edit page", but my one request would be to have the ability to make each section's Edit button default to the classic window (or, as others ask, disable VE entirely). It may seem like a small thing to hover the edit link then move to the edit source button that appears, but I have always found such mouse overs cumbersome and annoying. Resolute 23:36, 1 July 2013 (UTC)[reply]
- Yes, it's totally annoying (as compared to the WMF statement that the old editor would still be able via "edit source" (it is, but it's inconvenient). Additionally this hover functionality breaks MediaWiki:Gadget-righteditlinks.css (which was only needed because the WMF broke the positioning of section edit links before, probably also to be able to add the hover functionality in the first place). --Patrick87 (talk) 23:45, 1 July 2013 (UTC)[reply]
  - As much as I don't like VE being enabled for everyone now, and as much as I don't like it not being disableable (see my killer script above), that was actually done by myself in my capacity as a volunteer developer. I won't repeat the reasoning which was already repeated here at VPT ad nauseamafter it was changed. :) Matma Rex talk 23:48, 1 July 2013 (UTC)[reply]

I've had it enabled for a while, you do get used to it. That said, there's been enough requests for an opt-out that the VE team will be having some discussions on this point ASAP. PEarley (WMF) (talk) 23:50, 1 July 2013 (UTC)[reply]

Thanks! I'm afraid to say, but this is the first WMF statement on this issue that sounds as if some consideration was put into, not trying to convince us that "everything is fine". Regarding the section edit link's position: I'm fine with that, I only wanted to note that those "features" offered by VE easier break already existing things than some might think. Every additional bit of code is prone to errors (that's a fact!). --Patrick87 (talk) 23:59, 1 July 2013 (UTC)[reply]

I should qualify this by saying that I will do my best to bring these concerns forward, and can promise nothing. PEarley (WMF) (talk) 00:13, 2 July 2013 (UTC)[reply]

I'd like to add that the reason the devs didn't provide the built-in prefs switch is because what they wanted to provide (more like a fundamental per-user disabling than Matma Rex's script) was far more complex than expected, and it has serious bugs. (The old prefs switch wouldn't work in the current system; I admit that my eyes glazed over when the explanation started.)

If you've looked through the recent changes, then I'm sure you can understand why the devs believe that fixing the bugs that are resulting in dirty diffs screwing up some articles is more immediately urgent than adding a prefs switch, even though they are aware that an opt-out is important to the old hands (partly because Patrick and I have been pounding on the table and insisting that it's important, which we are planning to continue doing).

As proof that they understand how important this is, you should know that Matma Rex wrote his script in response to a direct request from the devs, when they realized that theirs was too unstable to release. They aren't trying to deprive you of control over your editing environment; they're just trying to work on what's most urgent. I think they were hoping that Matma's script would work well enough that it wouldn't be necessary to go back to "complicated", but if it's not, then Patrick and I know where the table is, and we can pound on it some more. But we need to work within reality: complicated code doesn't sort itself out just because we all want it to be fixed already. It will take time and careful thought. So if y'all can stand down for a few days, we'll see what we can do. Whatamidoing (WMF) (talk) 06:25, 2 July 2013 (UTC)[reply]

While I appreciate that there's hard work going on to try to make everything work, I can't help but feel that, in that case, it would have been better to push back the deployment of VE, and to get it all done (or as close to 'all done' as feasible), and then roll it out, instead of rolling out an incompleted product and touching off a firestorm among the editing base that has, apparently, resulted in editors leaving - quite the opposite of what VE was intended to do. - The Bushranger _{One ping only} 06:32, 2 July 2013 (UTC)[reply]

I'm only aware of one editor leaving (if there are more, I'm happy to talk to them). Actually, I agree, it would be nice if things were much more workable. But it's worth noting that a lot of the bugs and issues we're dealing with here are not bugs we'd encountered before - sometimes the best way to identify them is to follow the "many eyes" principle. We could have perfectly-designed software, and have it rendered buggy and useless by how people use it in practise, which means that finding out how people use it is key to making it function. Okeyes (WMF) (talk) 06:43, 2 July 2013 (UTC)[reply]

True 'nuff - that's why everyone, when something is rolled out, needs to be issued a complimentary can of Raid.

- The Bushranger _{One ping only} 07:43, 2 July 2013 (UTC)[reply]

If only it was that easy! (I note that with this edit we're now having a conversation via edit summary, which is somewhat meta - although not as meta, presumably, as me referring to it in the abstract). Okeyes (WMF) (talk) 07:49, 2 July 2013 (UTC)[reply]

Purely personal opinion: you might decide that I'm being excessively cynical, but my experience is that power users (a category that is broad enough to include basically anyone posting to this page) almost never actually leave because of something like this. See meatball:GoodBye, and check the user's contributions in a couple of weeks. WhatamIdoing (talk) 08:55, 2 July 2013 (UTC)[reply]

Keyboard shortcut disambiguation needed

Previously, during editing, Alt-Shift-V activated Show Changes; now it is also assigned to the new (Visual) Edit shortcut. That means neither action is automatically activated, causing extra keystrokes to show-changes or new-edit. [disambiguation needed] Dl2000 (talk) 23:35, 1 July 2013 (UTC)[reply]

"Opt out" of VE needed under preferences

Tracked in Phabricator
Task T52929

A Gadget to hide all UI elements of VisualEditor using JavaScript is selectable here (section "Editing"). Note, however, that it is still loaded in background. Please consider testing the VisualEditor for some time first and report any issues you might be facing on the feedback page.

Support We need a way for those who wish to easily opt out of this VE and use the old editing interface just how it was before. Please add. After 80,000 edit I do not need a new editor. I support the VE for those who wish to use it. Doc James (talk · contribs · email) (if I write on your page reply on mine) 23:38, 1 July 2013 (UTC)[reply]
Support; this shouldn't need to be brought up. StringTheory11 (t • c) 23:46, 1 July 2013 (UTC)[reply]
Strong support Paternalism by the WMF is not acceptable. There are preferences for things much less important. The Editor is the central component of Wikipedia and therefore needs it's own setting in preferences. I want to be able to configure which editor I'm using. The code for the opt-out preference is already there (it was used in the beta-phase), so implementation (or rather adding back) of the preference is a no-brainer. --Patrick87 (talk) 23:51, 1 July 2013 (UTC)[reply]
Support, while my browser will shortly be blacklisted from VE making it a non-issue, offering people who don't like it the choice to say no is a good thing. - The Bushranger _{One ping only} 23:56, 1 July 2013 (UTC)[reply]
Support: I never really did see a response about why this feature is not available. SL93 (talk) 00:04, 2 July 2013 (UTC)[reply]
Support. This seems like a no-brainer. Everyking (talk) 00:12, 2 July 2013 (UTC)[reply]
guys, there is a way to get out of it. As explained above, if you add:
importScript('User:Matma_Rex/VE_killer.js');
to your common.js, everything goes back to normal. Okeyes (WMF) (talk) 00:40, 2 July 2013 (UTC)[reply]
We want a simple clean "do not load" option under preferences. I do not think that is too much to ask. When VE works or is better than what we have now people will use it. CUrrently it unfortunately is not. The fact that it does not easily handle referencing is a deal breaker for me. Doc James (talk · contribs · email) (if I write on your page reply on mine) 00:48, 2 July 2013 (UTC)[reply]
- Why would you rather repeatedly inform editors of this? Less editors would need to be informed of that if the option to opt out is in preferences. SL93 (talk) 00:47, 2 July 2013 (UTC)[reply]
No, it doesn't, it only hides VE after it's loaded. So we have it flash in, then flash out, and all of the code is still loaded. It's an awful, crude workaround. Matma Rex talk 00:43, 2 July 2013 (UTC)[reply]
Which is sub-optimal, I appreciate, but mostly out of performance concerns. For those users who simply don't like the interface, we now even have it gadgetised to simplify things. Okeyes (WMF) (talk) 00:46, 2 July 2013 (UTC)[reply]
And performance concerns are negligible or how should I understand your statement? Why don't you just add back the user preference which was there before? The setting would fit into the "Edit" section much better than it fits into the Gadgets section anyway (and it would be a clean solution in contrast to the Gadget-version). Since when is WMF promoting Gadgets anyway? Last time I asked about a Gadget broken by the WMF the response was "we don't support Gadgets so we're afraid we cant help you". --Patrick87 (talk) 01:07, 2 July 2013 (UTC)[reply]
Support: A request for a preferences click box is not the same as "use this script to kill it." Sorry, I think there should be a check box in preferences to turn off Visual Editor. I never heard about it until last week; today it appeared on my screen and I don't want to use it. I think there should be a way to opt in/out in preferences whether or not there is a script to get rid of it. What if someone wishes to turn it off now, and turn it back on later when the bugs have been ironed out? Ellin Beltz (talk) 00:45, 2 July 2013 (UTC)[reply]
There (strictly speaking) now is one, here (top of "editing"). Okeyes (WMF) (talk) 00:46, 2 July 2013 (UTC)[reply]
Strictly speaking there is no such option to disable Visual Editor. The proposed Gadget only hides it's UI, the Visual Editor is loaded in background nonetheless. --Patrick87 (talk) 01:35, 2 July 2013 (UTC)[reply]
Support It would be nice to have this choice. Mark Arsten (talk) 00:46, 2 July 2013 (UTC)[reply]
There's now a gadget checkbox here (top of "editing") if you want to hide it. Okeyes (WMF) (talk) 00:46, 2 July 2013 (UTC)[reply]
Thanks Okeyes. That definitely makes it easier to figure out and apply. Doc James (talk · contribs · email) (if I write on your page reply on mine) 00:50, 2 July 2013 (UTC)[reply]

Looks good, thanks. Mark Arsten (talk) 01:11, 2 July 2013 (UTC)[reply]
Support It's rather ridiculous this was not included at launch. Those of us who have already learned Wikimarkup gain little to no benefit from it, although I do think it'll be great for new users. Adam Cuerden ^(talk) 00:50, 2 July 2013 (UTC)[reply]
Support I thought there was going to be one... I remember this being said a month or so ago, what happened? "When it becomes the default, you can go to Special:Preferences#mw-prefsection-editing and turn it off. Of course we can't predict what might happen far in the future, but, at this time, there are absolutely no plans to remove the old editor." I went today to look in my preferences to turn this off because i saved this in my sandbox to opt out when the time came but apparently it's not there. I would like it to be there though instead of having to opt out using JS. — -dainomite 00:57, 2 July 2013 (UTC)[reply]
- It was planned, but the code turned out to be seriously buggy at the last minute. Getting it really, truly off (rather than just covered up) is more complicated than expected. Whatamidoing (WMF) (talk) 06:32, 2 July 2013 (UTC)[reply]
Support We want to be able to switch VE off completely, please. Would you bring back the switch in preferences?--Aschmidt (talk) 01:06, 2 July 2013 (UTC)[reply]
As I see now, it's back in the preferences pane. Thanks!--Aschmidt (talk) 01:12, 2 July 2013 (UTC)[reply]
No, sadly it is not. A Gadget was added that hides all UI elements of Visual editor (or rather undoes it's changes to the UI). The Visual Editor itself is still loaded in the background. --Patrick87 (talk) 01:37, 2 July 2013 (UTC)[reply]
Support There are many of us who hate slow-loading, script-bloated boxes (and thanks for a script gadget to remove it, but no). However, it is clear that a hope is retained that we will learn to like the visual editor, so let's compromise. Mark the preferences option as experimental, with some wording that the setting will be cleared each month. Then, everyone gets to try the new system at least once a month. I see the report above that it's back, but I thought I would post what I had written anyway. Johnuniq (talk) 01:16, 2 July 2013 (UTC)[reply]
- Your writing is still valid. The Gadget provided only hides the VisualEditor's UI elements, the setting to correctly disable it is not back yet. The VisualEditor itself and all of it's JavaScript is still loaded in the background. Therefore this setting solves none of the "slow-loading, script-bloated boxes" but only hides them. --Patrick87 (talk) 01:42, 2 July 2013 (UTC)[reply]
Preferences → Gadgets → Remove VisualEditor from the user interface -- Gadget850^talk 01:15, 2 July 2013 (UTC)[reply]

Excellent, thanks! I hope visual editor does what the devs hope, but I like my kludgy wikisyntax and edit box. ;) Resolute 01:20, 2 July 2013 (UTC)[reply]
- You can use the old editor even with VisualEditor turned on next to it. Whatamidoing (WMF) (talk) 06:32, 2 July 2013 (UTC)[reply]

- I realize this, but I noted above that having section edit links default to VE was a nuisance, even if the mouseover brings up a parallel link. I viewed this as a minor nuisance, but still one that I am happy to eliminate by turning VE off. I'm not dismissing the work you guys put in to setting this up, but the classic interface is better for me and the option to disable simplifies things. Reso lute 14:53, 2 July 2013 (UTC)[reply]

Support as expressed above; a total no-brainer. Beyond My Ken (talk) 01:18, 2 July 2013 (UTC)[reply]
Support Firstly because we were being promised repeatedly that this option would always exist- not providing it discredits all the editors who made the promise. Support because editing is 40% text and 60% references, and training a group of new editors to hop over the edit button to the edit source, so they can add a reference blows their confidence immediately. Support because VE is so unstable it can only be used by experienced editors who can navigate around its shortcomings- it is not suitable for new editors. We need a quick way to help new editors to blank it out.-- Clem Rutter (talk) 01:31, 2 July 2013 (UTC)[reply]
Support. The Gadgets version is not sufficient; for best performance the VE code simply should not be loaded. -- King of ♥ ♦ ♣ ♠ 01:55, 2 July 2013 (UTC)[reply]
Support. The VE should NOT be forced on people. Many people have spent many years learning and perfecting wiki markup and code. If you want VE enabled by default on new accounts sure, but it should NOT be forced on existing editors. Jguy _Talk^Done 03:20, 2 July 2013 (UTC)[reply]

sigh* just logged into my work machine (which is sadly IE8 (it's still supported as long as XP is supported)) and the interface is completely broken for me, even with the 'gadget' checked. The javascript being loaded is way too much. And en.wikipedia.org is in my list of trusted Intranet safe sites. This is where I do a majority of my editing, so I suppose I'm done with Wikipedia until such a time where the old editor is brought back and/or the option to disable VE completely is brought forward. It is quite sad to see all of these editors bow out because of this forced change, many of whom have been here for many years. I've witnessed 5 so far myself. This should not be forced, it should be an opt-in. We should also not be told to 'deal with it'. Jguy _Talk^Done 03:47, 2 July 2013 (UTC)[reply]

...according to what I can see, you shouldn't be getting anything VE-related on IE8, as anything from IE10 or before is blacklisted for it? - The Bushranger _{One ping only} 03:59, 2 July 2013 (UTC)[reply]

@Jguy:: Bushranger is, as usual, correct; you shouldn't be getting this. Can you send me a screenshot or something when you have time? Okeyes (WMF) (talk) 06:41, 2 July 2013 (UTC)[reply]

Perhaps my browser was having an episode, as the site works correctly this AM (it was previously completely unbrowsable due to the amount of Javascript, e.g. would not load). My opinion still stands. While you might think the VE is the next big thing I do not support it being forced onto people and enabled in their preferences automatically. While it might not be broken and might include all the features to make editing easier, its quite apparent that most editors do not like it because they're used to what they know. This obviously is the exact opposite of 'easy' to them. This action by the WMF is almost like them playing 'big brother' and forcing things and ideals on people. What happened to concensus on this? Was it decided in a RfC that all editors will have it enabled by default come July 1st? I can't wait until it gets enabled on other language wiki's. We're going to have a very bad storm on our hands before too long. Jguy _Talk^Done 13:15, 2 July 2013 (UTC)[reply]

Support. Logged on this morning to find it enabled by default - spent a couple of minutes finding out how to disable it which I've now, thankfully, done. In an ideal world, experienced editors should be seeing a big red button on their screen saying "VE is here - here is a demonstration of how it works, and here is how to disable it if you don't like it." I may use it in time, but that will be in my own time, not yours, thank you very much. Ghmyrtle (talk) 07:48, 2 July 2013 (UTC)[reply]
That's fair enough. The VE should actually be showing a help interstitial; is that not occurring? We advertised it fairly prominently beforehand (blog posts, signpost coverage, village pump notices dating back a year, a watchlistnotice for weeks, a centralnotice for a week); if you can come up with any ideas for us to do better next time, I'd be most appreciative. Okeyes (WMF) (talk) 08:00, 2 July 2013 (UTC)[reply]
Small, unbolded messages at the top of the screen are what everyone - new users, old users, everyone - completely ignores. I knew it was coming in, but expected more warning (message on talk page, perhaps?), and some more explanation. Geeky explanations using words like "interstitial" and "javascript" are, for some of us, utterly meaningless and useless. But thanks for responding! Ghmyrtle (talk) 08:08, 2 July 2013 (UTC)[reply]
Here's the problem: people ignore it because it's the communications method we use. If we start bolding them, six months later people will say "oh, I don't read those". If we make them blink, then we'll discover blink-blindness sets in.

Meanwhile, if we notified everyone by more agressive means (talkpages, email), I fear we'd get more people yelling about the notifications than would yell about not being notified! Andrew Gray (talk) 22:40, 2 July 2013 (UTC)[reply]
Support Exactly what User:Ghmyrtle said. Cheers, Lindsay^Hello 08:11, 2 July 2013 (UTC)[reply]
Support. This is yet another botched new feature deployment by the WMF. I've made it perfectly clear that I don't want to be screwed around with and the WMF have made it clear that it will be actually disableable (not fake disableable via gadgets). What is going on? MER-C 08:55, 2 July 2013 (UTC)[reply]
I can't see any comment in that FAQ that says that. It was, I think, in a previous version, when the FAQ was volunteer maintained and written. Okeyes (WMF) (talk) 09:00, 2 July 2013 (UTC)[reply]
Re "botched"; if you want to talk through what you think we could have done better, I'm happy to do that. Okeyes (WMF) (talk) 09:02, 2 July 2013 (UTC)[reply]
Isn't it obvious? How about fixing all known bugs and making it reasonably feature complete (redirecting a page?) before wide-scale deployment? How about not foisting said buggy software on clueless newbies? How about not deploying a mess of slow-loading JavaScript with no means of getting rid of it? (Whatever happened to the bit about increasing participation in the Global South, where internet is crap?) We are here to build an encyclopedia, not test bloated, buggy software! Oh, and fire Eloquence, as him not giving a rat's arse (on multiple occasions) is fully incompatible with his role at the WMF. MER-C 10:55, 3 July 2013 (UTC)[reply]
If we followed that standard, we'd have to shut down Wikipedia entirely. There are "known bugs" for the old system, too. Whatamidoing (WMF) (talk) 11:45, 4 July 2013 (UTC)[reply]

Hi everyone recently I used the visual editor while trying to edit a page. It definitely falls way short in terms of replacing the wikimarkup editing if you want my opinion. I immediately disabled it. ---$o#aM ❊ আড্ডা 09:15, 2 July 2013 (UTC)[reply]
Okay; can you explain anything specific it needs to improve at handling? Okeyes (WMF) (talk) 09:20, 2 July 2013 (UTC)[reply]

I'm not even going to TRY to figure out if I'm posting in the right spot. I said last night that I was gone, and that's just how I feel/felt. And I thank Doc James for pointing me to this thread - and at least when I clicked edit I got a window I could work in. Anyway .. changes like this VE thing should be either "for new editors" or they should be an "opt-IN" thing. I knew what was when I signed up for wiki .. and this VE thing wasn't it. I'm not even tempted to go looking for any "opt-OUT". If it's progress, that's fine ... but I'm not interested. No offense Okeyes, I'm glad you trying to recruit NEW editors - but I really do despair for the "OLD" ones. Press 1 for English? ... BS .. press 1 for some foreign language. — Ched : ? 13:12, 2 July 2013 (UTC)[reply]
Support. I thought the purpose of the Visual Editor was to engage new editors, not to scare away the established ones. Even if the VE had all the features available in the regular editing window (which it doesn't) and worked flawlessly (ditto), I much prefer to spend my limited Wikipedia time on actual editing, instead of on re-learning every editing habit I have.—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); July 2, 2013; 14:27 (UTC)
Support. I've clicked on the new "edit" button by mistake a few times, and the articles have been slow to load (one took 15 seconds), but when I hit the back button or stop, my browser briefly froze, so having these two tabs next to each other is not ideal. An opt-out would be very helpful. An opt-in would be better still, because I think the VE (as currently presented) is going to make things harder for editors, new and old. At the very least, so long as the two tabs are next to each other, the new VE tab should be called Visual Editor, or "new editor" or something, rather than "edit," which would reduce mistaken clicks. SlimVirgin ^(talk) 17:10, 2 July 2013 (UTC)[reply]
Support. There's almost never a good reason to force things on us, and this is definitely no exception; we need to make it disableable instead of just hideable. Nyttend (talk) 17:35, 2 July 2013 (UTC)[reply]
Support. I agree with pretty much everything that's been said here. It would be nice to able to choose Visual Editor on occasion, but it's been really annoying to hit "edit" and find myself in a situation where I can't edit categories, can't easily edit old coding, etc. Furthermore, because VE is somewhat handicapped, it seems to me that newbies who originally get involved via VE should have an easy way to opt out of the default -- and adding a string to JavaScript isn't an easy opt-out. --Orlady (talk) 17:39, 2 July 2013 (UTC)[reply]
Support - I think the concept of VE is great but the implementation is thus far terrible. I agree with the comments here as well. Kumioko (talk) 17:43, 2 July 2013 (UTC)[reply]
Support North8000 (talk) 17:46, 2 July 2013 (UTC)[reply]
Support What a croc o' shite. Lugnuts ^{Dick Laurent is dead} 18:20, 2 July 2013 (UTC)[reply]
Support VE is great for new editors and I even support turing it on by default, but it's laborious and clunky for old hands. Please just turn the existing checkbox option into one that completely disables it when selected. Pol430 talk to me 22:31, 2 July 2013 (UTC)[reply]
Support I was told, back when the tests and all started, that I would have the choice to opt-out (to be exact, I was referred to the FAQ, which back then said I could turn this infernal gadget off). Now, when this thing is launched, I don't have such an option after all. I feel conned. Plus, having this thing load in the background is a real issue for my terribly slow internet connection. All of which, I've already told you, repeatedly. But, hey, I'm just an old hand, and I'll "never actually leave because of something like this". Right? Manxruler (talk) 01:02, 3 July 2013 (UTC)[reply]
Support Why? Why make this difficult for users, who prefer not to have it and are now forced to wait three times as long for a page to load, and even longer in some cases to suppress it?—cyberpower ^Chat_Online 01:50, 3 July 2013 (UTC)[reply]
Support My system is not the newest or fastest in the world, and I don't see why I should have slower load times and fidgety edit links when I will never use this feature. I tried it, I hated it, I'm done with it. -Rrius (talk) 03:26, 3 July 2013 (UTC)[reply]
Support The Crab Who Played With The Sea (talk) 08:13, 3 July 2013 (UTC)[reply]
Support. I got rid of it, it has returned. There needs to be a better way. Tassedethe (talk) 00:05, 4 July 2013 (UTC)[reply]
Support. The gadget only hides it, it doesn't stop it from loading. IMO VE is still too buggy and clumsy to use. —Bruce1ee^talk 05:08, 4 July 2013 (UTC)[reply]
Support I'm another with a slower system who found this imposed upon me with no easy way to disable it and nothing whatsoever on the Editing section of Preferences. Timrollpickering (talk) 15:16, 6 July 2013 (UTC)[reply]
Support Why is this a discussion and not common sense? I like the visual editor, I just don't want to ALWAYS use it. -- A Certain White Cat ^chi? 19:46, 6 July 2013 (UTC)
Support - I know it's summer but it's definitely SNOWing here. I haven't seen such clear, overwhelming consensus about anything in a long time - hopefully the WMF will take note for future... Giant Snowman 10:56, 9 July 2013 (UTC)[reply]

Actually I've never seen such clear and overwhelming ignorance as the WMF is currently expressing by not seeing this consensus. I'm sad to say it but I'm deeply disappointed with their work. The atmosphere is freezing here! --Patrick87 (talk) 11:28, 9 July 2013 (UTC)[reply]

Support and even strong support as currently VE is more damageable than useful, but still support after bugs are fixed and features redesigned to be useful because every user can choose by himself if he wants the overhead of VE or not. --NicoV ^{(Talk on frwiki)} 16:38, 9 July 2013 (UTC)[reply]
Support, of course. Opt-out should be provided piece of the software and not something we have to hack together on after the fact. Dragons flight (talk) 16:59, 9 July 2013 (UTC)[reply]
Support, I'm shocked at how slowly and poorly this thing works for something being foisted on all editors as ready to use. Nor do I personally have any desire to spend my time learning how to do things with it that I already know how to do in normal editing, as I've found the VE remarkably unintuitive. As commented by many above, turning it off needs to be easy and complete. postdlf (talk) 17:19, 9 July 2013 (UTC)[reply]
Support. Obviously, especially when the VE is likely to lose editors rather than gain some. the effect it has on one new editor. I'm wondering how many thousands of others feel like this. Kudpung กุดผึ้ง (talk) 00:46, 10 July 2013 (UTC)[reply]
Support - The new JS loads slowly and the extra tabs clutter the appearance of pages; in what world do you add a clunky, bug-ridden 'feature' to the core productivity area of your site and not provide the option to properly disable it? FLHerne (talk) 17:03, 10 July 2013 (UTC)[reply]
Support - This would be especially useful for editors with slow internet connections and us WikiNerds who want to edit their plain markup. Furthermore this shouldn't have been ruled out without an option to properly and completely turn it off. -- Toshio Yamaguchi 13:48, 11 July 2013 (UTC)[reply]
Support While have have it hidden, I still have the issues where my browser (Firefox and Chrome) freezes or crashes. Bidgee (talk) 13:51, 11 July 2013 (UTC)[reply]
- There is no way in heaven that that can be related to either the VE init script or the VE hide script. These two scripts are so minimal now, I can't imagine for the life of me that they would cause a crash. (ULS seems more likely). —TheDJ (talk • contribs) 14:56, 11 July 2013 (UTC)[reply]
  - I don't have the problem until I load the English Wikipedia, it didn't have the issue before the VE rollout and I don't have the issue on Commons. It maybe "minimal" but it causes the freezing and crashing of the browser on all of my computers (not just one). Bidgee (talk) 15:46, 11 July 2013 (UTC)[reply]
    - Bidgee, you only seem to be active here, at Meta, and at Commons. Universal Language Selector, which was unfortunately turned on the day after VisualEditor, is configured differently at multilingual projects (e.g., Meta and Commons) than it is at the Wikipedias. It would be very helpful if you would try to see whether you have the same problems at another Wikipedia, like de.wikipedia (where VisualEditor has not been made available to all users yet). If you get the same problems there, it's almost certainly ULS. Additionally, it would be helpful to have browser and OS information if you continue experiencing problems. Whatamidoing (WMF) (talk) 21:33, 11 July 2013 (UTC)[reply]
      - It is clearly a VE issue, I have no issues with de.wikipedia and simple.wikipedia. OS X 10.8.4 running Firefox 22.0 and Chrome 28.0.1500.71, My Windows 7 desktop and laptop both have latest updated browsers (FF 22 and C 28.0.1500.71 m) and have the same issue with English Wikipedia as the OSX. Bidgee (talk) 05:58, 12 July 2013 (UTC)[reply]

When will it be enabled?

I have been waiting for the launch of VisualEditor, but it still hasn't been enabled for me yet. Specs: I use the English Wikipedia, run Firefox Portable 22.0 (by PortableApps.com) and am using it on an HP Pavilion P6 running Windows 8. George8211 20:25, 6 July 2013 (UTC)[reply]

It is out. If you try to edit an article and don't see both and "Edit" and "Edit source" tab at the top of the page, then your browser is not recognized as supported. (Note that VisualEditor is only present on article and user pages right now.) Firefox 22 should be supported, but possibly PortableApps changed the identification string in a way that Mediawiki doesn't recognize. I'd suggest asking at Wikipedia:VisualEditor/Feedback. Dragons flight (talk) 20:37, 6 July 2013 (UTC)[reply]

A bit of waiting, and it is now working. Thanks for the help. George8211 14:52, 8 July 2013 (UTC)[reply]

Problems

Magnification

Tracked in Phabricator
Task T52541

I use a 125% screen magnification, so when I try to edit a table or template or what have you there's overlapping dialogue boxes. They must not have tested it at different zoom settings. Please see File:Overlapping dialogue boxes with visual editor.JPG. I use a Toshiba laptop and run Chrome. -- Diannaa (talk) 23:49, 1 July 2013 (UTC)[reply]

I saw this behavior briefly in Chrome but was unable to reproduce it consistently in either Chrome or Firefox Cmcmahon(WMF) (talk) 00:17, 2 July 2013 (UTC)[reply]

Maybe you could look at the accompanying image. I am getting this behaviour consistently. -- Diannaa (talk) 00:24, 2 July 2013 (UTC)[reply]

Hi Diannaa, I see the problem you're referring to, but I'm also having a problem reproducing the issue on my machine. ~~A few things that would be helpful~~:

* Version of Chrome you're using

* Which page you're editing

* Exact sequence of events to get to the screen you're looking at

* Any gadgets or user javascript you might have installed

~~Also, if there are other people here who see the same thing, that would also be helpful information. Thanks! -- RobLa-WMF (talk) 00:31, 2 July 2013 (UTC)~~[reply]

Nevermind, we just figured it out. It's a matter of scrolling down the page a little bit before bringing up a dialog. -- RobLa-WMF (talk) 00:35, 2 July 2013 (UTC)[reply]

Thank you for reporting this, I have noted it in our bug tracking system. Cmcmahon(WMF) (talk) 00:44, 2 July 2013 (UTC)[reply]

For the record, at my default zoom I see this issue routinely as well. Dragons flight (talk) 02:03, 2 July 2013 (UTC)[reply]

Adding references

Every sentence I add to Wikipedia is accompanied by a high quality reference. We have an amazing tool in the WP:Edit box that formats and fills in the reference based on the PMID or ISBN. Can this new VE do this? I have fiddled with it and am unable to figure out how. Here is instructions on how we use the toolbar Wikipedia:MEDHOW#Steps_for_editing and a few instructions on other options when it is not working (which is unfortunately too much of the time) Doc James (talk · contribs · email) (if I write on your page reply on mine) 00:12, 2 July 2013 (UTC)[reply]

I've been using the template button (the puzzle piece one) to access the cite templates, which works. There has been some demand for a ref toolbar-like functionality for the reference button in VE - there seems to be some cross-wiki compatibility issues (not all wikis support the cite temps) that make it difficult. It would be a desirable improvement if it's at all possible, I'll check the enhancement requests ... PEarley (WMF) (talk) 00:51, 2 July 2013 (UTC)[reply]

It requires many many clicks. It does not fill in all the details based on the PMID (there is no autofill button). Of the 50 or so language of Wikipedia I have looked at only one does not support it and that was Polish. They did this so that people cannot do translation easily, but that is another issue. I have been unable to properly fill out a single reference with the VE based on a PMID. Is there a page of instructions? It is definitely not intuitive, at least not for me. Doc James (talk · contribs · email) (if I write on your page reply on mine) 01:18, 2 July 2013 (UTC)[reply]

So does this mean references are free form now? That we no longer have a guiding structure for people to work with? Doc James (talk · contribs · email) (if I write on your page reply on mine) 01:29, 2 July 2013 (UTC)[reply]

I'm with ya. The developers know of this concern, and are working on improvements. This is the bug report on the topic. PEarley (WMF) (talk) 01:51, 2 July 2013 (UTC)[reply]

But why is this being rolled out before this is fixed? This is essential. A VE that does not make it easy to add references is useless. Doc James (talk · contribs · email) (if I write on your page reply on mine) 10:50, 2 July 2013 (UTC)[reply]

Anyway am going to turn VE off. I people could let me know when auto fill of ISBNs and PMIDs is supported again will give it another try.Doc James (talk · contribs · email) (if I write on your page reply on mine) 02:52, 3 July 2013 (UTC)[reply]

Using the VE twice in a row

When I make two VE edits back to back the second edit states "You are editing an old revision of this page" Doc James (talk · contribs · email) (if I write on your page reply on mine) 00:12, 2 July 2013 (UTC)[reply]

I had this problem as well. -- Diannaa (talk) 00:25, 2 July 2013 (UTC)[reply]

I've only had the problem when transcluding templates. Under what circumstances did you encounter it? --Maggie Dennis (WMF) (talk) 00:32, 2 July 2013 (UTC)[reply]

Just now, I tried to edit Treasure (Bruno Mars song) to correct an error a new person made with the Visual Editor. When I try a second time in a new window, the problem did not recur. -- Diannaa (talk) 00:41, 2 July 2013 (UTC)[reply]

I just reproduced it in my sandbox. Word on the street is that it's a caching issue. If it persists, I'll make a bug report (if Maggie hasn't already). PEarley (WMF) (talk) 00:45, 2 July 2013 (UTC)[reply]

It's a known issue. _→AzaToth 01:54, 2 July 2013 (UTC)[reply]

Tracked in Phabricator
Task T52441

Edit notice

Tracked in Phabricator
Task T52545

Unless the edit notice is removed before opening a dialogue box, it lays there on top of the box, making it impossible to edit the content, or in the case of a bigger edit notice, to even see the content. It's not very intuitive as to how to make the edit notice go away, either. -- Diannaa (talk) 00:56, 2 July 2013 (UTC)[reply]

This is being tracked. PEarley (WMF) (talk) 03:59, 2 July 2013 (UTC)[reply]

Editing fully protected pages

Tracked in Phabricator
Task T52415

Using Visual Editor, an administrator is not warned that they are editing a fully-protected page. Tested on Mahathir Mohamad -- Diannaa (talk) 01:25, 2 July 2013 (UTC)[reply]

This too. PEarley (WMF) (talk) 04:03, 2 July 2013 (UTC)[reply]

Blacklist + Gadget = Bad Things?

As a note, apparently the gadget to turn off VE interacts poorly with the browser blacklist (which my FF5.0 is on). I ticked the gadget box regardless of the blacklist, and after I removed the .js VE-killer which had made the edit button vanish completely, everything was fine...until I got to Bird species described in the 2000s (decade), which had the 'edit this page' button vanish when the page finished loading. Unticking the gadget fixed this. - The Bushranger _{One ping only} 01:46, 2 July 2013 (UTC)[reply]

Thanks, Bushranger. I'll pass this on. PEarley (WMF) (talk) 04:16, 2 July 2013 (UTC)[reply]

Add a code editor to the template editor

It is a HUGE pain to enter templates with many parameters (such as citations) using the workflow of Add Parameter -> Enter Parameter Value -> Repeat. Many extra mouse clicks and other interruptions. In terms of making small edits to the values, the visual layout is probably okay, but having to enter a lot of new values is tedious. An option that could be very useful is to show an equivalent wikicode block at the bottom of the template editor (or provide a similar mechanism) that allows one to quickly make a raw edit to the template inputs without having to fully back out of the visual editor. Dragons flight (talk) 02:10, 2 July 2013 (UTC)[reply]

This is related to the TemplateData issue, described here: Wikipedia:VisualEditor/TemplateData. If TemplateData has been added, the parameters are listed on the left of the dialog, making life much more pleasant. PEarley (WMF) (talk) 04:07, 2 July 2013 (UTC)[reply]

Clicking on ten different side items is still a slow and annoying way to enter a template (not helped by the fact citation templates support dozens of parameters). More significantly, none of the citation templates I tried actually showed parameter lists even though they already have TemplateData on their pages. So that feature does not appear to be working. Dragons flight (talk) 04:16, 2 July 2013 (UTC)[reply]

Hmm, you're right. Just tried "cite book", and no parameter list despite the presence of TemplateData. I'll look into this ... PEarley (WMF) (talk) 04:23, 2 July 2013 (UTC)[reply]

Categories duplicated, strange invisible table added at the bottom of a page

Tracked in Phabricator
Task T52120

I used Vedit to add a comma and some italics to Michala Petri, and got more changes than I expected (I subsequently undid the extra changes). Check the edit that brought it to size 6,152 bytes. Did I click something I shouldn't have, or did this add something valuable to the page that I just don't understand? Chris the speller ^yack 02:42, 2 July 2013 (UTC)[reply]

Wasn't your fault, see bug above. It added WP:Persondata, which is useful metadata. But it shouldn't be adding it without being asked to. PEarley (WMF) (talk) 04:15, 2 July 2013 (UTC)[reply]

This happens quite a lot, e.g. here and other occasions today. Fram (talk) 14:16, 3 July 2013 (UTC)[reply]

This duplication (in an ugly format) of Persondata happens quite a lot, I just corrected this error in 42 articles[1], which is way too much for the short time VE has been life, the limited number of people using it, and the fact that many of these errors had already been reverted (and more may still be unnoticed). A few things I remarked and which may help in solving the issue; most (but sadly not all) of the articles were about musicians, many of them with the infobox musical artist; and (if I checked correctly) all of them are in the (large) Category:Persondata templates without short description parameter category. Could this be given some priority: together with the nowiki problems, it's the single most often occurring error (of the errors that make it into the articles), and even though it has no direct influence on the article, it may affect later changes to cats or persondata negatively. The nowiki errors, and the problems with infoboxes and other templates are more urgent than this, but it still is something that should get tackled pretty soon if possible... Fram (talk) 10:01, 9 July 2013 (UTC)[reply]

This was a difficult bug to track down, but I'm happy to report that it is now fixed. --GWicke (talk) 03:47, 12 July 2013 (UTC)[reply]

Thanks! I haven't found any new ones with this problem anymore, but it's still early days. If it does reappear, I'll drop a note here. Assuming I can find it, that is, as it seems that the VE edittag has been removed, making it a lot harder (or nearly impossible) to track VE bugs of course. Isn't it a bit premature to remove that tag? Or is there another way to find VE edits easily? Fram (talk) 07:42, 12 July 2013 (UTC)[reply]

Turning a page into a redirect

Tracked in Phabricator
Task T49328

First attempt at the Visual Editor, first mistake or bug. I tried to turn Huddleston Elementary School into a redirect. Adding the #REDIRECT, but that was turned into "nowiki" automatically. Fine so far, but how are we supposed to add the "redirect" magic word without the nowiki markup in Visual Editor? I have checked all buttons, and can't seem to find it. It's not really useful to have an editor that doesn't let you make all changes, since this means that prior to editing, you have to think about whether the type of change you want to make is supported by VE or not... Mind you, apparently I'm lucky that I got that far, further attempts at other pages only gave gibberish, with the software adding a second # when I put #, and other related problems. Fram (talk) 08:17, 2 July 2013 (UTC)[reply]

Can't be done (yet). Creating and editing redirects is on the list of improvements for "soon" (but I believe that it's on the list to be done after some of the critical improvements to references). Whatamidoing (WMF) (talk) 08:50, 2 July 2013 (UTC)[reply]

Editing redirects isn't that urgent, you don't get the option to use VE there so you can't do it wrong. But creating redirects is more urgent, since there the VE option is standard, but it doesn't work for this. But thanks for the swift reply. Fram (talk) 08:54, 2 July 2013 (UTC)[reply]

I've added a note to the closest related existing bug, just to make sure this doesn't get overlooked accidentally. Whatamidoing (WMF) (talk) 09:06, 2 July 2013 (UTC)[reply]

Get the user interface right

Currently the UI is loaded via JavaScript. This makes the edit buttons "flicker" in after page load (see e.g. bugzilla:50542). Additionally the section edit links for the Wikitext editor are hidden behind links that need to be hovered first needing time and being inconvenient.

I see WMF's wish to have both editors coexisting but this is only possible if VisualEditor adds itself seamlessly into the UI (which it currently does not!) and the Wikitext editors keeps exactly as usable as it was before (which it currently is not!). I'm therefore strongly requesting that you fix those UI bugs. Do it correctly (maybe at the PHP level on the server instead of at the JavaScript level on the user's machine) and much of the controversy might be resolved! --Patrick87 (talk) 10:18, 2 July 2013 (UTC)[reply]

UI improvements, in terms of both quality and performance, is an important area for us, I know, and there are bugs in place for dealing with things like the slow loading times and the sheer size (as well as UI tweaks). I can't speak for the developers here (and frankly I'm not technical enough to comment directly - I write in R, and that's it), but I remember that with AFT5, when we tried to use PHP to make these kind of UI elements we ended up with one hell of a caching problem. Okeyes (WMF) (talk) 10:22, 2 July 2013 (UTC)[reply]

Can you explain what you mean by the wikitext editor not being as usable as it was before? I haven't seen any reports that anything has changed with it, other than the label being "edit source". Whatamidoing (WMF) (talk) 10:30, 2 July 2013 (UTC)[reply]

I have to first hover over section edit links before being able to reach the same functionality than I did before (see for example bugzilla:50540).
On page load it takes significant time until all buttons are available / replaced by Visual editor (see e.g. bugzilla:50542).
"Edit" has a different meanings in different namespaces sometimes starting VisualEditor and sometimes the Wikitext editor making it hard to find the link one actually wants (see bugzilla:50402).
Incompatibilities caused by the much more complex code needed for all the VisualEditor "features" (e.g. bugzilla:50405). VE might have been coded having usability for new user and style in mind, but not usability for power users and code stability/compatibility.

Those are the things I find most annoying right now (besides the still unusable VisualEditor we're forced to betatest). --Patrick87 (talk) 12:01, 2 July 2013 (UTC)[reply]

Thanks for the explanation. It is helpful to know what you meant. Whatamidoing (WMF) (talk) 08:55, 3 July 2013 (UTC)[reply]

Nowiki

Tracked in Phabricator
Task T51820

Tracked in Phabricator
Task T51686

Looking over actual VisualEditor edits (coupled with my own experience with it), the one thing that IMO simply has to change is the automatic addition of "nowiki" tags when people e.g. play with square brackets. The vast majority of errors introduced by VisualEditor are unwanted nowiki tags, while the amount of "wanted" nowiki tags is extremely small (in my sample of some 100 edits, none, against some 15 nowiki errors). Examples which I corrected (many others were corrected by the original editor, but required thus a second edit for no good reason): [2][3][4][5]a, extreme one [6]...

By sheer number of errors, and ratio of errors vs. benefit of this, this has to be the most prominent problem in VisualEditor as of now. Any idea if and when this will be corrected? Fram (talk) 10:23, 3 July 2013 (UTC)[reply]

I think someone at the WMF said something like "It's not a bug; it's a feature!" on that. πr² (t • c) 13:12, 3 July 2013 (UTC)[reply]

Probably, but it's a feature that's not only unwanted but actually harmful. Things like this and this actually create errors, and I still haven't seen a single edit where this behaviour was actually wanted (there are bound to be one or two where it works as designed, but that's like having an airbag that deploys every time you brake; sometimes it will be useful, but...). Fram (talk) 13:22, 3 July 2013 (UTC)[reply]

I think this is under discussion, but at this point VE assumes that if you put markup directly into it, you are wanting to talk about it rather than use it - from what I understand, developers are being encouraged to add a note or warning so that experienced editors don't make this mistake. (I'll look for the ticket number.) Obviously, newcomers aren't making it because they don't know the markup to begin with. --Maggie Dennis (WMF) (talk) 13:44, 3 July 2013 (UTC)[reply]

Found it. :) Tracking number added. --Maggie Dennis (WMF) (talk) 13:47, 3 July 2013 (UTC)[reply]

VE is only enabled in mainspace and userspace. It's rare in userspace and very rare in mainspace to talk about wiki markup. I wouldn't be surprised if more than 99% of VE nowiki additions in mainspace are errors. PrimeHunter (talk) 14:01, 3 July 2013 (UTC)[reply]

Agreed with PrimeHunter, and disagree with the bugzilla solution: a warning isn't sufficient, this is simply obnoxious behaviour by the software. "Warning: the software isn't going to allow you to do something useful for no good reason at all, please try another method to achieve this" is better than what we have now, but that's about the best I can say about it. It's too soon to tell whether truly new editors will have the same problem, but very recent ones certainly have this problem[7]Fram (talk) 14:27, 3 July 2013 (UTC)[reply]

Note: A warning may be easier to implement, but there's also another feature request (bugzilla:49686) about automatically converting such wikitext. guillom 14:32, 3 July 2013 (UTC)[reply]

If you can, please add your thoughts to the bug. It's really helpful for the developers to hear directly from community about what works and what doesn't. If not, I can certainly post there with some of your comments. --Maggie Dennis (WMF) (talk) 14:30, 3 July 2013 (UTC)[reply]

I don't like Bugzilla, neither the interface not the followup time nor the reactions I sometimes get there from developers. It doesn't give the impression that it is taken seriously. Back to the problem at hand: for some reason, sometimes only the closing nowiki tag is added, e.g. here, with editors struggling to correct this in VisualEditor[8]. Fram (talk) 08:02, 4 July 2013 (UTC)[reply]

Update: apparently new editors get "nowiki" errors as well, so the justification that "Obviously, newcomers aren't making it because they don't know the markup to begin with." is invalid as well: new editor whose first edit yesterday was with VisualEditor. Fram (talk) 09:13, 4 July 2013 (UTC)[reply]

This one as well, so it's not really an exceptional occurrence. Fram (talk) 09:16, 4 July 2013 (UTC)[reply]

Hi Fram, thanks for the reports and the links to the diffs which is quite helpful to see what is going on. The <nowiki/> added there is to prevent link-trails since the user only selected part of a word and linked it. This could be addressed by warning the user when a part of a word is being linked, but these kind of nowiki-markups are far fewer in number. The majority of nowikis being added which is the cause of a lot of anguish are the ones added around literal wikimarkup for links (which is being discussed in a couple of different bug reports), and those kind of errors are highly unlikely to be done by newcomers. This is not to indicate that your concerns are not legitimate, but just a clarification about different scenarios where nowikis get inserted. To summarize, these kind of nowikis you point out are not very common. Ssastry (talk) 22:33, 11 July 2013 (UTC)[reply]

I'm not convinced that new editors don't have these nowiki problems, e.g. this terrible edit is fulled with nowikis, and is being made by a brand new editor (may have been an IP editor, or a sock, of course). Fram (talk) 08:04, 12 July 2013 (UTC)[reply]

To support Fram remark, Filter 550 is rather showing that the nowikis tags are added by many users without a user page, so probably by many new editors. So it's really not a problem limited to experienced users. --NicoV ^{(Talk on frwiki)} 08:09, 12 July 2013 (UTC)[reply]

Another example of new editor with nowiki problems[9]. Fram (talk) 14:30, 12 July 2013 (UTC)[reply]

Template `{{tl}}` invisible in VE editscreen

Tracked in Phabricator
Task T52704

When template {{tl}} is used, it does not show in the VE edit screen (or possibly whitespace?). Its sister template {{tlx}} shows correct. Demo: User:DePiep/VEdemo VE: [10] -DePiep (talk) 21:22, 3 July 2013 (UTC)[reply]

Reported. —TheDJ (talk • contribs) 23:18, 3 July 2013 (UTC)[reply]

Removal before a footnote alters downkey effect

Tracked in Phabricator
Task T52726

In VE, when I remove any text before (to the left of) a reference footnote, and then press ↓, the cursor jumps to the bottom of the page. Expected behaviour is: cursor moves to the line below. Example scheme (not working here):

~~1. Initial text: Some statement. Bad text.^[2].~~

2. ~~Delete " Bad text." in VE (I used backspace from the period leftwards). Now~~

When the cursor sits at: Some statement.|^[2].

3. Pres ↓. Cursor jumps to bottom of page.

(Try page: Hydrogen has many footnotes -- just don't save of course). -DePiep (talk) 00:56, 4 July 2013 (UTC)[reply]

Update (silly me): It disfunctions without the deletion. Just place the cursor next to a fotnote. Adding: key ↑ has similar effect (upward). -DePiep (talk) 05:38, 4 July 2013 (UTC)[reply]

@DePiep: what browser and version of the browser were you using ? I don't see this problem on Safari 6. —TheDJ (talk • contribs) 08:17, 4 July 2013 (UTC)[reply]

Firefox 21.0 atop WinXP. -DePiep (talk) 08:20, 4 July 2013 (UTC)[reply]

Confirmed in FF 20 on MountainLion. Reported —TheDJ (talk • contribs) 08:36, 4 July 2013 (UTC)[reply]

Keyboard shortcut fail

Tracked in Phabricator
Task T52725

The keyboard shortcut for the old Edit was Alt-Shift-E. That seemed to have been assigned for Edit Source, to maintain the same key shortcut as the old Edit, but that now seems changed out. The hint over the Edit Source link indicates "<accesskey-ca-editsource>", whatever sort of keyboard shortcut combination that is supposed to represent. This is causing a problem by reducing efficiency of editing. Dl2000 (talk) 04:07, 4 July 2013 (UTC)[reply]

tracked —TheDJ (talk • contribs) 08:26, 4 July 2013 (UTC)[reply]

One simple typo, nine steps to correct it

To correct one simple typo (change "lable" to "label"), it took me nine steps in "Edit Source" instead of one in "Edit"[11]:

Click on the infobox
Click on the "transclusion" icon
Click on "Lable"
Ctrl-C the text in the parameter
Click "remove parameter"
Type "Label"
Enter
Ctrl-V to readd the parameter text
Apply changes

How is this an improvement? Why isn't there at least a "change parameter name" option to eliminate a few of those steps? There are (at least) three other parameters with a typo in that same infobox, which would take me another 18 steps to correct (the first two and last one only need to be done once, hurrah). Fram (talk) 08:12, 4 July 2013 (UTC)[reply]

I know that complex templates are a pain right now. When the TemplateData gets added (and processed: the system's got a huge stack of these jobs to process), you won't have any need to add them manually at all, which will dramatically reduce the likelihood of anyone introducing typos, non-existent parameters, or similar problems. I think you can expect this problem to be one that essentially solves itself before long. In between now and then, I agree that it's clunky. Whatamidoing (WMF) (talk) 11:53, 4 July 2013 (UTC)[reply]

Just checked Wikipedia:VisualEditor/TemplateData, and the example there isn't convincing at all, since the bottom image (the one with TemplateData) is essentially largely what I saw when trying to correct the errors. I'll reserve judgment on whether this will really improve things until the moment that it is supposed to be live. Fram (talk) 12:21, 4 July 2013 (UTC)[reply]

Headers inside wikitables

I've recreated a problem another editor had here, to be sure that it's VE related. While I wasn't editing the wikitables at all, the VE decided that the headers that were inside the wikitables should be duplicated, turning something that worked allright into a mess. Fram (talk) 11:19, 4 July 2013 (UTC)[reply]

Something similar appears to have happened here. —Bruce1ee^talk 12:05, 4 July 2013 (UTC)[reply]

I'm not convinced that bog-for-bug compatibility is the goal. If you want to display five tables separated by section headings, then I it is reasonable enough for you to create five tables separated by section headings, not one table that uses section headings to break it up. Whatamidoing (WMF) (talk) 13:55, 4 July 2013 (UTC)[reply]

But why did VE decide to move them outside the tables? Can you give some examples, some actual edits, where this behaviour has improved the article? I haven't seen any, but despite looking at many VE edits, I haven't seen (or corrected) them all. If there are no reasonable situations where this VE behaviour actually improves the article, then the functionality should be removed (altered), no matter how you think about the way these wikitables are built. It worked, after VE it doesn't work, so at least there has to be a convincing reason why VE does this, i.e. situations (preferably reasonably common situations) where this VE action is truly desirable and an improvement. Fram (talk) 14:12, 4 July 2013 (UTC)[reply]

They're working on it. As I understand it, wikicode gets translated into HTML to display the article on your screen when you read it (of course) and when you're using VisualEditor. If the HTML is seriously broken (e.g., in the Criss article), then VisualEditor tries to repair it so that it can display it properly. Usually, this means closing tables that are missing the close-table code. In this instance, it was clearly trying to fix the busted wikicode for the tables, but failed.

Do you know if this "style" used in other articles? It doesn't make sense to code around an improper format used in a single article: the article should just get fixed to use the normal wikicode for displaying five tables. But if this is common, then I could suggest it be considered. Whatamidoing (WMF) (talk) 14:25, 4 July 2013 (UTC)[reply]

Considering that it was also used in the article Bruce1ee linked to above in this section, it seems unlikely that the only two articles to use this format have been edited with VE just recently. Fram (talk) 14:35, 4 July 2013 (UTC)[reply]

It's not an improper format. A table cell is a td element, which may contain any flow content. A heading element may appear where flow content is expected. Therefore, tables may contain section headings. --Redrose64 (talk) 15:14, 4 July 2013 (UTC)[reply]

In Fram's example, they're using section headings to split one table into five. This isn't one table that happens to contain five section headings; it's five separate tables created out of the code for one table. It seems to me that if you want five tables to appear on a page, then you should actually make five tables, i.e., put five {| |} pairs on the page, rather than putting the wikicode for one large table on the page and using section headings to split that table into five separate tables (which is what happens when Mediawiki tries to turn this "one" table into HTML). Whatamidoing (WMF) (talk) 20:36, 4 July 2013 (UTC)[reply]

Neither Redrose64's nor Whatamidoing's analysis here is correct. In revision 562814845, and for that matter in revision 560634872, there are clearly five tables, but the headings are not within table cells (they are effectively within the <table> tag). The wikitext is generating improperly nested HTML in that it has the section headings are not within table cells, and Tidy winds up moving them above the tables. But VisualEditor's mangling of the wikitext is in no way appropriate behavior. While round-tripping the badly nested wikitext may not be feasible or desired, at the very least it should have moved rather than duplicated the headers and should have inserted linebreaks between the newly-inserted headers and the "{|" to start the tables. Anomie ⚔ 23:58, 4 July 2013 (UTC)[reply]

You're right, I wasn't looking carefully. The heading elements were indeed between the {| and the |- and so were interposed between the table element and the first tr element. Most browsers will eject these out of the table: the table element may only directly enclose a small selection of other elements; these include the tr element, which may itself only enclose td and th elements, so the minimum hierarchy to get a heading inside a table and still be valid HTML is <table><tr><td><h3>...</h3></td></tr></table> --Redrose64 (talk) 08:35, 5 July 2013 (UTC)[reply]

Adds ./ inside square brackets

Tracked in Phabricator
Task T52720

I have seen this once or twice on other edits as well, so it seems to be a VE error: here in four cases "./" is added at the front of a wikilink, which then no longer works. In each case, it is a link with a disambiguator and a pipe in (note that VE also adds an underscore, which is not an error but unnecessary anyway). Fram (talk) 07:59, 5 July 2013 (UTC)[reply]

here is another example of the same, again with a piped link with disambiguator. Fram (talk) 08:03, 5 July 2013 (UTC)[reply]

Yep, a firefox 13/14 problem; we've temporarily blacklisted those browsers. Okeyes (WMF) (talk) 13:12, 12 July 2013 (UTC)[reply]

Thanks. I'll report back if I find any new instances of this problem. Fram (talk) 13:14, 12 July 2013 (UTC)[reply]

Random shit with tables

This may be related to the persondata duplication error, and/or the section headers in tables errors, or not, but I've seen too often that VE adds blocks of code that are clearly not wanted and not added by the editor, like here. No idea what causes it yet, but worth being investigated. Fram (talk) 08:00, 5 July 2013 (UTC)[reply]

Another example: [12]. Fram (talk) 08:46, 5 July 2013 (UTC)[reply]

A rather extreme one: [13]. Fram (talk) 12:06, 5 July 2013 (UTC)[reply]

The only thread I see in common with these is that all of them involve tables (including infoboxes that get rendered as tables). Do you think it might be related to Template:Bugzilla? Whatamidoing (WMF) (talk) 19:41, 5 July 2013 (UTC)[reply]

Might be, I don't see a pattern yet. I've also noticed more infoboxes being removed than I would consider to be normal, but it is hard to blame this on VE with any certainty, it may be that editors do it on purpose. I'll post more examples when I find them (although I'm getting rather tired of spending my days chasing and reverting VE errors). Fram (talk) 08:06, 8 July 2013 (UTC)[reply]

Moving images

In VE, you can easily move images. You don't have much control of where you place it though, which results in the placement of images in the middle of headers, words, ... E.g. things like this should be avoided by the software. Fram (talk) 13:39, 10 July 2013 (UTC)[reply]

To be fair, the Wikitext editor allows images to be placed mid-sentence... that is, I can't find evidence of VE being used to make this edit. --Redrose64 (talk) 16:36, 10 July 2013 (UTC)[reply]

Yes, it is allowed with the old editor as well, but you had to do it on purpose. Now, you can move images to the middle of words without any intention of doing this, just wanting to move an image between section is very hard. No idea why a manual move is allowed but no means are given to accurately position it. Fram (talk) 07:45, 12 July 2013 (UTC)[reply]

Infobox mangling

It appears that VisualEditor "scrunches" the template code in infoboxes so that instead of being one line per paramater, it puts everything on one line; see here for an example. While this doesn't change how the infobox displays (fortunatly), it makes it very ugly and hard to edit in the source and really shouldn't be doing this. - The Bushranger _{One ping only} 00:27, 11 July 2013 (UTC)[reply]

It appears only editing the infobox itself causes this - simply editing the page in VisualEditor seems not to, as evidenced by this VE diff. - The Bushranger _{One ping only} 00:51, 11 July 2013 (UTC)[reply]

It could potentially change how the infobox displays, if it contains something where newlines are critical - such as a bulleted list, as used in the |guests= parameter of {{Infobox Doctor Who episode}} - e.g. An Unearthly Child. --Redrose64 (talk) 06:11, 11 July 2013 (UTC)[reply]

Is this something that you'd like to have reported as a bug, requested enhancement, or whatever you want to call it? If so, I think you might want to copy this to WP:VisualEditor/Feedback (the more common place for bug reports). Whatamidoing (WMF) (talk) 21:42, 11 July 2013 (UTC)[reply]

This was a temporary regression (See Template:Bug). The most common case has already been fixed and deployed. In any case, as The Bushranger noted, this should only affect tempaltes that are edited. Ssastry (talk) 22:55, 11 July 2013 (UTC)[reply]

Italicizing wikilinks

I noticed this a lot recently, but somehow didn't realize that it was VE-related as well. Not really a bug, but suboptimal editing nevertheless: when people select wikilinked text and italicize it, VE doesn't put quotes around the square brackets but creates a piped link where the part after the pipe is the same as the part before the pipe, but with added double quotes. This works, but it seems to be suboptimal use of the possibilities of wiki-markup, and creating many unnecessary piped links. Examples of the result of this can be seen here. Fram (talk) 13:52, 12 July 2013 (UTC)[reply]

VE totally screwing up

A section for things that go rather clearly wrong, but which don't match a clear pattern or existing section :-)

[14] turns paragraphs into headers after the removal of an image Fram (talk) 13:56, 12 July 2013 (UTC)[reply]

Category:Musical theatre articles missing an image in infobox

Tracked in Phabricator
Task T53163

When Template:Infobox musical is present the above category is automatically added. This is ok for article space but its also adding the cat to user space and Article for creations pages. Is there a technical way to make it only appear in article space.Blethering Scot 20:13, 2 July 2013 (UTC)[reply]

Yes, you can check the namespace. One way to do so is {{Namespace detect}}. Another, specific to the article space, is {{#if:{{NAMESPACE}}||[[Category:Musical theatre articles missing an image in infobox]]}}. However, I would personally recommend {{main other}}, which does exactly what you want (see the second example!). πr² (t • c) 21:13, 2 July 2013 (UTC)[reply]

Thanks, i tried it but to be honest i have no idea what I'm doing so wouldn't work. Im assuming you meant on the infobox rather than the cat.Blethering Scot 21:41, 2 July 2013 (UTC)[reply]

The {{main other}} should be wrapped around the category, but placed inside the infobox template code. Here's one I made earlier. --Redrose64 (talk) 22:02, 2 July 2013 (UTC)[reply]

Thanks how often does it usually take for them to be removed from the category.Blethering Scot 21:55, 3 July 2013 (UTC)[reply]

It depends on the job queue. That's currently showing zero, which occurs so rarely that I suspect that there is some problem with generating the figure. --Redrose64 (talk) 22:22, 3 July 2013 (UTC)[reply]

There still showing, have i done it wrong or is the job queue extremely long.Blethering Scot 22:28, 6 July 2013 (UTC)[reply]

It's clearly a problem, one that I've noticed elsewhere. I've filed bugzilla:51163. --Redrose64 (talk) 10:05, 11 July 2013 (UTC)[reply]

Redrose64, as Nikerabbit says the number in API stats is unreliable. As already documented on Help:Job queue, you can used this graph which uses a maintenance script and should be reliable: [15]. I do see a 5k spike about the time of your edit, may be it. --Nemo 10:13, 11 July 2013 (UTC)[reply]

Unresponsive script

Tracked in Phabricator
Task T35018

Tracked in Phabricator
Task T51935

Tracked in Phabricator
Task T53070

I've been getting this message frequently today:

A script on this page may be busy, or it may have stopped responding. You can stop the script now, or you can continue to see if the script will complete.

Script: http://bits.wikimedia.org/en.wikipedia.org/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki%2CSpinner%7Cjquery.triggerQueueCallback%2CloadingSpinner%2CmwEmbedUtil%7Cmw.MwEmbedSupport&only=scripts&skin=monobook&version=20130620T163512Z:106

I'm using Monobook and Firefox 6.0, and I'm guessing that this might be related to the VisualEditor, though I can't be certain of that. I disabled VE, but I still get the message. Is it trying to load anything important, and is there an easy way to preemptively kill it without getting this message every five minutes? Thanks. --Bongwarrior (talk) 22:05, 2 July 2013 (UTC)[reply]

Do you get it while you're editing? After you save? When you're just reading articles? Can you give instructions to reproduce the error, or does it just happen occasionally (at seemingly random times)? πr² (t • c) 22:58, 2 July 2013 (UTC)[reply]

Just when I'm viewing. It mostly seems to happen on larger pages - it has been happening on Pittsburgh Steelers, Barack Obama and Alec Douglas-Home every time I view those pages. The traditional edit window still opens up fine on those articles, and smaller articles seem to be loading normally. It also happens every time I load Special:RecentChanges (which is very irritating, as that's something I use frequently) and sporadically on some project pages, again mostly depending on how large they are. WP:ANI seems to load fine, Wikipedia:VPT and Wikipedia:Articles for deletion/Log/Today seem to load properly about 50% of the time. Today is the first day I've noticed this problem. --Bongwarrior (talk) 23:43, 2 July 2013 (UTC)[reply]

That all (happening on non-editable and non-VE-editable pages, happening since today) would indicate that this is an issue with ULS (the cog on language links), not VE. Matma Rex talk 23:47, 2 July 2013 (UTC)[reply]

Thanks for the information, that sounds like a pretty good guess. Hopefully there will be some sort of fix. The interface is becoming a bit too bloated for my tastes, and these "features" make editing more of a hassle than it needs to be. --Bongwarrior (talk) 04:39, 3 July 2013 (UTC)[reply]

See bugzilla:49935#c5 for the information needed. To what you said above, I suggest to add 1) operating system, 2) recentchanges settings (how many changes are you loading?) and other relevant settings (e.g. if you have gadgets enabled), 3) CPU, total RAM, free RAM, 4) why you've not upgraded Firefox.

Experience shows that there are more chances for your report not to be discarded by devs if you do some JavaScript profiling yourself with firebug and mention the worst offenders, but I don't know easy tutorials for that. Good luck! --Nemo 08:21, 3 July 2013 (UTC)[reply]

ping @Bongwarrior:, can you please provide some information as to your browser and browserversion (+OS) —TheDJ (talk • contribs) 17:06, 3 July 2013 (UTC)[reply]

The problem seems slightly better today - it's no longer happening on RecentChanges, although it still seems a bit slow to load (and it's still happening on the articles I mentioned). Nemo, the information you requested:

1) Windows Vista SP2

2) The default, 50 changes. Only a few gadgets: popups, reference tooltips, do not show green bullets on watchlist, remove VisualEditor, Yet Another AFC Helper Script, CharInsert, add edit link for lead section, change "new section" tab to "+", display old yellow/green diffs, disable animations, and move section [edit] links to the right side.

3) Intel Celeron 1.60 GHz, 1 GB RAM, 36 MB free RAM

4) If it ain't broke, I don't usually fix it. I have noticed that some of the newer versions of Firefox hog less memory, so I probably will upgrade it at some point. --Bongwarrior (talk) 18:45, 3 July 2013 (UTC)[reply]

Bongwarrior, thanks, I've reopened the bug and added your information. --Nemo 07:10, 4 July 2013 (UTC)[reply]

I had the same problem and finally managed to fix it using Adblock. I blocked the following 3 items and now it's loading like a charm again:

|http://bits.wikimedia.org/static-1.22wmf8/extensions/UniversalLanguageSelector/*


|http://en.wikipedia.org/w/api.php?action=ulslocalization&language=en

|http://bits.wikimedia.org/en.wikipedia.org/load.php?debug=false&lang=en&modules=ext.centralNotice.bannerController%7Cext.uls.displaysettings*

Of course this just disables the ULS. But if you don't need it, it works. Hopefully this information is useful to you. — Ginsuloft (talk) 13:14, 5 July 2013 (UTC)[reply]

Nice, that works perfectly as far as I can tell. Thank you very much. --Bongwarrior (talk) 19:22, 5 July 2013 (UTC)[reply]

Oops, I spoke a bit too soon. The pages load nice and fast, but it has the unfortunate side effect of killing or bypassing my monobook.js settings. --Bongwarrior (talk) 19:34, 5 July 2013 (UTC)[reply]

I have requested that ULS be disabled. This bug is real, it's reported plenty on wiki, it's time to get it out because it's on every page, it's not like the general user can bypass it like VE. —TheDJ (talk • contribs) 21:14, 9 July 2013 (UTC)[reply]

Heavy Javascript load after loading some articles.

Tracked in Phabricator
Task T52836

I'm getting spikes of CPU usage/browser getting stuck after loading some articles. The script causing the problem seems to be http://bits.wikimedia.org/en.wikipedia.org/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki%2CSpinner%7Cjquery.triggerQueueCallback%2CloadingSpinner%2CmwEmbedUtil%7Cmw.MwEmbedSupport&only=scripts&skin=vector&version=20130620T163512Z:106 --90.179.235.249 (talk) 13:50, 5 July 2013 (UTC)[reply]

some more pieces of information would be helpful:

which articles?
which browser (incl. version) do you use?
is this behavior consistent and repeatable, or is it intermittent?
could you please repeat the same measurements, but add "?debug=true" to the address line? this will help isolate the actual script that causes the issue - without it, the wikipedia script loader (aka "ResourceLoader" or "RL") squashes many scripts together while minifying them, so the information you supplied regarding the actual script that causes the issue is less useful than it would be with "?debug=true".

peace - קיפודנחש (aka kipod) (talk) 14:57, 5 July 2013 (UTC)[reply]

Not that guy, but I have the same problem. Which articles? Seems to happen all over Wikipedia at different intensities, but it's the worst at special:recentchanges. Browser=Firefox 12.0, OS=Windows XP SP3. Is this behavior consistent and repeatable, or is it intermittent? Consistent and very annoying. Could you please repeat the same measurements, but add "?debug=true" to the address line? I would if I could. So far I only managed to disable it with AdBlock but as you said it also disables other useful stuff. — Ginsuloft (talk) 15:03, 5 July 2013 (UTC)[reply]

Most articles are affected, some seem to be worse than other. (Austria, Japan or Birds are some of particularly affected ones) Talk pages are fine.
Firefox 22.0
It seems to be consistent
With "?debug=true" the offending script is http://bits.wikimedia.org/en.wikipedia.org/load.php?debug=true&lang=en&modules=jquery%2Cmediawiki%2CSpinner%7Cjquery.triggerQueueCallback%2CloadingSpinner%2CmwEmbedUtil%7Cmw.MwEmbedSupport&only=scripts&skin=vector&version=20130620T163512Z:6841 but it seems to be the same script, just not minified. --90.179.235.249 (talk) 15:49, 5 July 2013 (UTC)[reply]

Since Firefox 22 you can use "Extras -> Developer tool -> runtime analysis" to exactly measure the time used by each subroutine. For other versions of Firefox there is also Firebug. --Patrick87 (talk) 16:08, 5 July 2013 (UTC)[reply]

jQuery.expr.filters.hidden() is the problem, if I did everything correctly. I also found that many articles load fine, it doesn't seem to happen with most short articles, it doesn't happen with Roman Egypt or even some very long pages like List of people of the Three Kingdoms--90.179.235.249 (talk) 16:59, 5 July 2013 (UTC)[reply]

For me, the problem seems to be this anonymous function starting at:

curCSS = function( elem, name ) {


var ret, width, minWidth, maxWidth,
computed = window.getComputedStyle( elem, null ),
style = elem.style;

if ( computed ) {

— Ginsuloft (talk) 17:47, 5 July 2013 (UTC)[reply]

@Patrick87: I have Firefox 22. Where is this "Extras" to which you refer? --Redrose64 (talk) 18:32, 5 July 2013 (UTC)[reply]

@Redrose64: Ah, sorry, I new their messed up new GUI was only producing problems... You have to hit the "Alt" key once (this will bring the classical menu bar up), then it's the second menu from the right. --Patrick87 (talk) 18:37, 5 July 2013 (UTC)[reply]

I have had the menu bar switched on for some months (View → Toolbars → Menu bar) ... but the menu bar that I have is File/Edit/View/History/Bookmarks/Tools/Help. I've looked in each one, and there isn't an "Extras". --Redrose64 (talk) 18:43, 5 July 2013 (UTC)[reply]

I also don't have an "Extras" menu in Firefox 22, and neither do I have a "Menu bar". View → Toolbars leads to Navigation, Bookmarks, and Add-on. Whatamidoing (WMF) (talk) 19:22, 5 July 2013 (UTC)[reply]

Seems I have to apologize again, just pick the "tools" menu (I'm using a German licalized Firefox and since "Extras" is an English word I didn't imagine it could be titled differently in English). However it seems you guys are very bad at searching

. --Patrick87 (talk) 19:30, 5 July 2013 (UTC)[reply]

I've got Tools → Web developer, but in that submenu, there are 12 items, but no "runtime analysis". Whatamidoing (WMF) (talk) 19:47, 5 July 2013 (UTC)[reply]

Try Shift+F5--90.179.235.249 (talk) 19:53, 5 July 2013 (UTC)[reply]

Ah, ⇧ Shift+F5 is same as Tools → Web developer → Profiler. --Redrose64 (talk) 19:58, 5 July 2013 (UTC)[reply]

Yes exactly this is what I meant. Sorry for the hassle but none of these translations is only close to it's original meaning. --Patrick87 (talk) 20:01, 5 July 2013 (UTC)[reply]

i removed the {{tracked}} which pointed to Bugzilla:49935. these are two separate issues: the older bug was about "frozen" browser, that's caused by asinine use of ajax (calling ajax load many times with "async:false"). as a side, one of the developers that responded to the bug demonstrated really bad attitude, criticizing the bug-reporters while behaving as if there is no real problem, instead of making some effort to get to the root of the issue. but as i said, it's not related: this one is about high CPU consumption, and removing the "async:false" which will fix 49935, will do nothing to help here (actually, fixing 49935 will exacerbate this problem). this warrant a separate report. as for the problem itself: as far as i could see, it comes from the new ULS (universal language selector) code. the problem seems to be calling "injectCSS" multiple times (each time with a new style component to load yet-one-more-webfont), instead of collecting all the different CSS pieces this extension wants to ask the browser to load, and loading them all at once. peace -— Preceding unsigned comment added by קיפודנחש (talk • contribs) 20:18, 5 July 2013 (UTC)[reply]

After further tries - it seems to be always addEmbeddedCSS(), but with different subroutine for different articles. For some (Austria, Japan it's jQuery.expr.filters.hidden(), for others (Jupiter, Birds, special:recentchanges) it's curCSS(). I hope it helps.--90.179.235.249 (talk) 20:39, 5 July 2013 (UTC)[reply]

i created a new bug report - bugzilla:50836. i think the main issue here is calling injectCSS() multiple times (e.g., in Japan this function is called 20 times), but the whole ULS thing contains some seriously pessimized code. peace - קיפודנחש (aka kipod) (talk) 21:27, 5 July 2013 (UTC)[reply]

קיפודנחש, thanks for your investigation and report. --Nemo 08:52, 8 July 2013 (UTC)[reply]

Just a note that the Language Engineering team responsible for ULS will be holding an office hour later today, at 17:00 UTC on #wikimedia-office (on Freenode): http://www.mail-archive.com/wikitech-l@lists.wikimedia.org/msg69718.html Matma Rex talk 11:28, 10 July 2013 (UTC)[reply]

patch deployed, call for people who experienced the problem to retest

so a patch was deployed on enwiki (specifically, this is the patch, if you care about this kind of things). the patch is supposed to improve the heavy javascript CPU load issue, and may or may not solve the "browser freeze" issue. can the people who reported the original problem verify that it's fixed now?

peace - קיפודנחש (aka kipod) (talk) 21:24, 10 July 2013 (UTC)[reply]

Thanks a lot. I've just tried a few different pages, and it seems to be working much, much better. It might be just a tad slower than it was before ULS (or not - that could just be my imagination) but I'm not seeing any freezing or hanging or anything. Muchas gracias. --Bongwarrior (talk) 21:54, 10 July 2013 (UTC)[reply]

It's not just your imagination; it is a tiny bit slower. But as I like to say, "Even in Arcadia, there is death." At least pages aren't loading for 4 seconds now, which was absolutely ridiculous. This is to confirm that the patch works. Thank you. Ginsuloft (talk) 14:00, 11 July 2013 (UTC)[reply]

Yes, it works much better now.--90.179.235.249 (talk) 14:24, 11 July 2013 (UTC)[reply]

just to clarify - it's not "my" patch, and the thanks should go to the developers who solved the problem (specifically, User:Amire80 and the people who code-reviewed his patch, maybe some others, too). peace - קיפודנחש (aka kipod) (talk) 18:03, 11 July 2013 (UTC)[reply]

Also to User:Nikerabbit who wrote much of the patch's code and to User:Nemo_bis who tested it before deployment and found an important bug that we resolved.

And thanks also to all the people in this thread that tested and reported things. --Amir E. Aharoni (talk) 13:00, 12 July 2013 (UTC)[reply]

Visual Editor

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

The off switch -> Special:Preferences#mw-prefsection-gadgets under "Editing". It's actually just a workaround: the JS still loads. Please read the FAQ too. More info on how to opt out is available here. In particular, see the discussion above πr² (t • c) 22:55, 2 July 2013 (UTC)[reply]

Thanks. That makes it slightly faster, but load times are still ridiculously high.—cyberpower ^Chat_Online 23:11, 2 July 2013 (UTC)[reply]

@Cyberpower678: then see the discussion above about letting users really disable it, so it doesn't add JS/CSS bloat for users who don't want to use it anyway. And some of the delay might have to do with ULS, which was also enabled today. πr² (t • c) 00:45, 3 July 2013 (UTC)[reply]

Thanks for the pointer on how to turn the wretched thing off.

It's so stinky slow that far from encouraging new editors as the WMF hopes, it will sap their will to live. :(

Did nobody check performance before this slug went live? Or are the testers all using brand new i7 PCs? --BrownHairedGirl (talk) • (contribs) 03:53, 3 July 2013 (UTC)[reply]

@BrownHairedGirl: I wish I was! I agree that the slowness is a problem, and one we need to tackle very quickly; the experience has been much improved for me, recently, but is still highly sub-optimal. Hopefully it will get better over the coming weeks as we get a handle on what goes on in a live environment rather than an opt-in deployment. Okeyes (WMF) (talk) 06:23, 3 July 2013 (UTC)[reply]

Are you sure that the cause of the slow loading time is VisualEditor and not the Universal Language Selector (which was deployed yesterday)? Whatamidoing (WMF) (talk) 09:22, 3 July 2013 (UTC)[reply]

The problem with deploying two new features in a short space of time is that if problems occur and the cause is not obvious, people are more likely to blame the one with which they have had most contact. I'm willing to bet that more people have used VE (whether by design or accident) than have used ULS; therefore, VE will get most blame. --Redrose64 (talk) 09:33, 3 July 2013 (UTC)[reply]

It's not better if it was ULS, is it? Another feature we can't disable, despite huge demand (bugzilla:46306)! I can understand why you are forcing VE on us (you need beta testers) but why force ULS on us? I never used any feature of it and I will never use one. --Patrick87 (talk) 09:52, 3 July 2013 (UTC)[reply]

It's important to be able to tell the difference, though, because no amount of fixing the VE code is going to solve a problem that's caused by ULS.

Redrose, it should be obvious that neither you nor I were in charge of the schedules.

Cyberpower, is it any better today? (Clear the cache, etc., if you want to be sure.) I believe that the amount of VE loading now when you read (not edit) a page has been reduced by 97%, so if you're still having problems, it's probably not VE. Whatamidoing (WMF) (talk) 14:06, 4 July 2013 (UTC)[reply]

It is now.—cyberpower ^Chat_{Limited Access} 01:10, 9 July 2013 (UTC)[reply]

Non-interaction Visual editor and Add an [edit] link for the lead section of a page

Even though I have the Add an [edit] link for the lead section of the page turned on, the "edit" does not expand to give me the choice of editing using the visual editor and the standard wiki editor (edit source) which every other section has. Any ideas on how to change that? — Preceding unsigned comment added by Naraht (talk • contribs) 17:12, 3 July 2013 (UTC)[reply]

This is a local change in the English Wikipedia, that is not yet compatible with the Visual Editor feature. Since it is a volunteer developed change, some patience might be required. —TheDJ (talk • contribs) 17:13, 3 July 2013 (UTC)[reply]

Thank you.Naraht (talk) 17:15, 3 July 2013 (UTC)[reply]

I guess it would be impractical or impossible to change this in the VisualEditor code so it should be handled by the English Wikipedia in MediaWiki:Gadget-edittop.js. There is already a suggestion at MediaWiki talk:Gadget-edittop.js#VisualEditor? PrimeHunter (talk) 19:54, 3 July 2013 (UTC)[reply]

edittop is broken. It now goes to VE and unlike other section edit links, there is no option to use the proper editor. More at WP:VE/F#Cannot edit section 0 --Redrose64 (talk) 19:21, 6 July 2013 (UTC)[reply]

It is intermittent. Half the time, it does still work and gives a proper plain edit link. Other times, it behaves like a VE edit link. Seems to depend on load order of the VE and the edit-top gadget, which can vary. — Edokter (talk) — 19:33, 6 July 2013 (UTC)[reply]

I believe that I have fixed it, see here. It's kinda kludgy: I left the existing .replace() method alone, and put another as a new line above it. I expect that a Javascript expert could probably do the same two actions as a single .replace() method. --Redrose64 (talk) 15:21, 9 July 2013 (UTC)[reply]

Unsound Testing Approach with Visual Editor

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

The devs have been spamming everywhere for testers, using giant notices in virtually every place possible, for a really really long time. --Yair rand (talk) 00:49, 4 July 2013 (UTC)[reply]

It was rolled out on an opt-in basis since December 2012. Okeyes (WMF) (talk) 00:50, 4 July 2013 (UTC)[reply]

I think Robert McClenon suggests it should have been in Userspace (maybe logged in users) first. Since it was available since December 2012, rolling out for Userspace could have been months earlier from now. -DePiep (talk) 01:04, 4 July 2013 (UTC)[reply]

Excellent points. On a scale of 1 to 10 regarding mechanisms for accountability to / guidance from the users, (where 0 = no accountability/guidance and 10 = enough to cause complete paralysis) accountability for stuff happening within English Wikipedia it's a "9" and for the IT side it's about a zero. Some fundamental changes in that are needed. North8000 (talk) 01:55, 4 July 2013 (UTC)[reply]

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

As one of those "conservative" editors, who uses IE, (merely the most used browser in the US and the second most used in the world) I haven't had a chance to comment, and won't for the forseeable future - if ever. There is no point in claiming "The devs have been spamming everywhere for testers" when such a vast number of editors (>50%?), and probably predominantly those, like me, who are less tec-savvy, were totally excluded from the test.
Please stop dismissing IE, and IE users, as a nuisance, and design systems that work with it, from the outset. Arjayay (talk) 11:01, 4 July 2013 (UTC)[reply]

Agree. Even though I have gotten IE out of my life, it is arrogance to ignore it. North8000 (talk) 11:05, 4 July 2013 (UTC)[reply]

What is the statement based on that Internet Explorer is generally ignored? It is correct that Visual Editor does not support old Internet Explorer versions (see this matrix), but latest versions (9 and 10) are supported, and software bugs are actively being worked on. --AKlapper (WMF) (talk) 11:45, 4 July 2013 (UTC)[reply]

They're not supported in the current release, Andre. But yes, IE9 and IE10 will be supported soon. And no, IE is not 50% -- IE8-10 is about 18%. [16] It's been bleeding marketshare pretty badly in the last few years.--Eloquence * 17:00, 4 July 2013 (UTC)[reply]

I was really making two related statements, one of them explicit, and one implicit. I will expand. Robert McClenon (talk) 17:42, 4 July 2013 (UTC)[reply]

I agree with Robert 100%. The way the WMF went about this rollout was completely irresponsible and frankly just plain stupid. There are too many problems with it yet. To continue to keep this software enabled is the worst possible decision the WMF could do. Whoever is in charge needs to roll it back immediately and allow testing to continue for a few more months to get the problems fixed. Kumioko (talk) 16:33, 5 July 2013 (UTC)[reply]

Lack of Formal Testing

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

WMF spent months advertising VE and asking for testers. So they did want volunteer help, and to some degree they did get it, though probably no where near as systematically as a professional test organization might manage. Personally, I think the more telling development problem is that of the 298 Visual Editor bugs that are presently open on Bugzilla, about 200 of them were first reported before Visual Editor was turned on by default here. Yes, turning it on for everyone found 100 new bugs, but if one already had 200 existing bugs to fix, that seems a premature time to be launching it on everyone. Dragons flight (talk) 18:02, 4 July 2013 (UTC)[reply]

Dragon, I completely agree with your latter point. I think the number was closer to 300 just a few days before launch. I mentioned the same point you made to #wikimedia-tech and was lightly scoffed at by at least one developer who said something about the number of bugs not relating to the quality of a product. Note that I don't think this developer was on the VE team, but it was still interesting to me. Killiondude (talk) 18:10, 4 July 2013 (UTC)[reply]

Your search includes enhancement requests and bugs marked as duplicates, so it was probably somewhat an overestimate. Dragons flight (talk) 18:19, 4 July 2013 (UTC)[reply]

Oh, thank you for that pointer. I hadn't realized that. Killiondude (talk) 18:22, 4 July 2013 (UTC)[reply]

re Robert McClenon: VE is not a bank account application (especially not wrt error consequences), so your example is a bit extreme. OTOH, as I wrote earlier, the development team could deploy earlier into Userspace (with opt-out), say March, to catch some more plain early bugs. And maybe we should add the argument about the stress for the dev-team once it is out this currently big and major bugs, likely, appear. -DePiep (talk) 20:10, 4 July 2013 (UTC)[reply]

It is true that the consequences of errors are not as serious as in a bank account system, to use the example that I provided. That doesn't change the fact that development and testing should be done by separate teams, in this case of volunteers. The point that I was making is that the mindsets of developers and of testers are different. Developers test the obvious test situations, and tend to be optimistic, because they know, correctly, that they have done good work. Testers test the obvious and unobvious situations, such as thinking of mistakes that distracted users might make. Developers can be testers, and testers can be developers, but not on the same effort. My example was of something that could really happen that wasn't right. In a bank, that sort of error could result in financial hardship to customers, and then in litigation. On Wikipedia, it could result in what would be seen, for instance, as page blanking vandalism due to user error, and could cause hard feelings causing editor loss. Robert McClenon (talk) 21:05, 4 July 2013 (UTC)[reply]

So, let's get a couple of things clear here. First: we have a QA team. It's a damn good QA team, and it's totally distinct from the VisualEditor team - two completely different subdepartments working from different physical locations. The VE operates out of Features/Product, in SF; QA is led by a dude in Colorado, and is part of the Platform subdepartment. That's as far apart as you can get and still be in Engineering (we're a small org). Second: we've had testing by volunteers. The VisualEditor has been on enwiki since December 2012, on an opt-in basis, with >= 1,000 users taking it for a spin and many of them reporting (later fixed) bugs. Okeyes (WMF) (talk) 12:10, 5 July 2013 (UTC)[reply]

Actually the number of bugs related to VE are something around 500 and possibly more. Not only do you need to account for the VE section but also parsers, some under mediawiki and a couple others. All the VE bugs aren't listed under VE. It should also be mentioned that since its release only a couple days ago, more than 500 people have disabled it. Kumioko (talk) 16:36, 5 July 2013 (UTC)[reply]

The raw number of open bugs (many of which are duplicates) isn't really a good indication of software's design or implementation. After all, Mediawiki has several thousand open bugs against it, and a couple hundred just against the old editing system, and nobody's suggesting that we turn the whole thing off. We need functional improvements (Monday's update can't come too soon for me), not a particular level of activity in the bug database. Whatamidoing (WMF) (talk) 19:29, 5 July 2013 (UTC)[reply]

I appreciate the position you, Maggie, Oliver and others are in with trying to justify the VE debacle but there is a massive difference between the bugs in the Mediawiki software that is pretty well matured and this turd. I also agree that its not the volume of bugs specifically but the significance of some of them. They are major. As much as it sounds like I hate the app, I don't, I think it has a lot of potential and it will be a great asset....someday. But that day ain't today or tomorrow and probably won't be next week or next month. This is like putting an infant in the drivers seat and telling it to drive you home. Kumioko (talk) 22:41, 5 July 2013 (UTC)[reply]

Testing in User Space

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

By way of clarification, VE is presently enabled for both article space and user space. Dragons flight (talk) 17:49, 4 July 2013 (UTC)[reply]

It should have been enabled only in user space until it was tested. Robert McClenon (talk) 18:11, 4 July 2013 (UTC)[reply]

Any developer philosophy link available? Website development can fundamentally differ from my local server environment development. -DePiep (talk) 20:16, 4 July 2013 (UTC)[reply]

Lack of volunteer testers ?

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

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

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

--NicoV ^{(Talk on frwiki)} 16:14, 5 July 2013 (UTC)[reply]

I agree NicoV, there were more than 1000 users who enabled it and could be considered testers including me. Quite a few of us told them it wasn't ready for release and it had too many problems, but they didn't listen, didn't care and went ahead anyway. So quite a few, including myself, disabled after the WMF showed they didn't care what we had to say. So, the WMF can try and convince us with bullshit excuses and justifications all they want. But the end result was we told them it wasn't ready for release and they did it anyway. So all the hate messages and complaints that are being directed at the WMF about the application are completely deserved. Kumioko (talk) 16:41, 5 July 2013 (UTC)[reply]

So, if an organisation does something you disagree with, all the individual people in it deserve abuse? Okeyes (WMF) (talk) 02:37, 6 July 2013 (UTC)[reply]

It seems that there were many volunteer editors who tried an early buggy version, didn't like it, and disabled it. As the bugs continue to be fixed, the WMF will have a challenge to educate those editors what's been fixed (and what hasn't) and ask that they retest. GoingBatty (talk) 00:51, 6 July 2013 (UTC)[reply]

Just as 9 women can't produce a baby in 1 month, testing with 1,000 volunteers who each have the experience of 100 edits is not the same as using one tester with the experience of 100,000 edits. Chris the speller ^yack 02:02, 6 July 2013 (UTC)[reply]

Chris, I'd invite you to look at the early archives of the feedback page and then come back and tell me that we had "1,000 volunteers with the experience of 100 edits". I'll be back in a sec, only I need to go tell PamD that she's apparently a noob. Okeyes (WMF) (talk) 02:36, 6 July 2013 (UTC)[reply]

I agree that part of the problem was inexperienced testers but that is easy to overcome with a good test plan. The bigger problem is the WMF didn't have a test plan. They just threw it out and hoped for the best. That isn't a good way to do testing anymore than the attitude that the WMF has that they know better than we do what we need and want. The sheer volume of negative discussions all over the project are a testemant to that. Kumioko (talk) 02:07, 6 July 2013 (UTC)[reply]

I'm sorry, Okeyes (WMF), but I'm finding your responses to be lacking information and quite bitey. I think it's pretty clear that it didn't really matter how many experienced volunteers you had in the early going, because many crucial functions of the VE weren't operational until less than 24 hours before the software became the default. Now, if that was part of the plan, then the feedback to be taken in is that it wasn't a particularly good part. If it wasn't part of the plan, then the feedback is "this shouldn't happen". Just think if you'd had a week of testing with half the volunteer testers trying out the referencing and template interfaces, and how many bugs could have been addressed before you had a large number of editors deciding to turn it off almost entirely because of the bugs. Just imagine if this had not gone live at the same time as ULS, which also had significant bugs that wound up rebounding on VE because everyone noticed VE and not ULS. These are things that can be learned and noted for future roll-outs.
A member of the WMF team recently posted a blog[17] that focused on the opportunity to learn from "non-successes" and plans that did not go well. We need to acknowledge where things can be improved, or we are doomed to continue having the same negative responses over and over. I would have thought that there would have been more learning from the rollout of Echo/Notifications that should have been applied here, for example. People, and projects, are not expected to be perfect - but there is a reasonable expectation that we won't keep seeing the same problems time and again. Risker (talk) 02:55, 6 July 2013 (UTC)[reply]
- @Oliver, I know its hard being the communities punching bag for this but Try not to take it personally. I very much doubt that the majority of us (ok there are probably one or 2:-)) that are directing these negative comments about VE at you, Maggie or the others. Just remember sometimes in order to be effective, truth must penetrate like an arrow...and that is likely to hurt. Kumioko (talk) 03:12, 6 July 2013 (UTC)[reply]
  - I'm sorry, but that's simply not true. You'll note we've delayed the next release by a week. This is all to do with the bugs that have been largely surfaced by polite people; it's nothing to do with truth that penetrates like an arrow. We would have come to the same decision without offensive commentary - simply in a more pleasant atmosphere. Okeyes (WMF) (talk) 03:38, 6 July 2013 (UTC)[reply]
  - Oliver, its got nothing to do with being rude either. We said weeks ago that VE wasn't ready but the WMF ignored the stupid editors and went ahead anyway. Your talking about us being rude, how do you think that made us feel to know that our opinions didn't matter. And putting it off for a week isn't going to be enough time either. All 1 week will do is allow the WMF to say we listened but really its just trying to make themselves look good for the dumb decision of releasing VE before it was ready and pissing off virtually every editor. It wasn't ready to be released, its not going to be ready in a week and it probably won't be ready in a month either. A lot of problems have been identified and that's good. But keeping it turned on just our of spite doesn't make us look bad, it makes the WMF look bad and just irritates us editors who have to fix the mess. Kumioko (talk) 19:29, 6 July 2013 (UTC)[reply]

We've had a lot of user visible changes lately, including Lua, WikiData, Echo, and VisualEditor. That's an unusually large number of user facing changes for only a few months time. Some of these deployments have been handled well, and others not so well. Personally, I'd suggest that Lua was probably the best of the four, while VisualEditor has been the weakest. All of these were deployed in a somewhat incomplete state, which seems to be standard operating procedure for WMF (though personally I'd suggest polishing things a bit more before full-scale deployments). One of the differences is that while Lua and Wikidata were missing key functionality at deployment, they largely avoided bugs that most Wikipedia editors would easily encounter. By comparison, many users will stumble over bugs in VisualEditor. I could go on comparing and contrasting these various deployments, but rather than getting buried in details, let me just acknowledge that innovation is hard. Sometimes we do it reasonably well and sometimes we do it poorly. When it works, it can make a real difference (e.g. Lua now aids most articles on Wikipedia). When it fails, it may be ignored (e.g. #property for Wikidata) or even drive users away. I do hope there are people at WMF who take the time to think about the various deployments and what has gone well vs. poorly. Because Wikipedia depends critically on a volunteer community, getting community involvement and acceptance of innovation is a key step towards ensuring success. Managing that community buy-in can be hard, but it is also an important part of ensuring the successful deployment of new features. Dragons flight (talk) 05:58, 6 July 2013 (UTC)[reply]

Yes, Dragons flight. Please keep me updated & informed. Sure VE is the hardest User-experience related of all. Still, my astonishment is about the VE process going for 6 months into trial without true process feedback. Unlike say WikiData, the User-thing was part of the task from the start. Now I'd like to hear what, tomorrow, Mondays WMF weekly meeting will do. Again saying I'ts difficult you know? -DePiep (talk) 18:50, 7 July 2013 (UTC)[reply]

Dragons, I'd say that the main theme in your list is not how well the project worked or was handled, but how many users interacted with it. Very few editors dealt with Lua, and therefore very few were bothered by its problems. Many users dealt with Echo, and more people were upset about it. But that doesn't mean that Echo was worse than Lua: IMO Echo worked better than all the others in your list at deployment and was managed much better (with the single notable failure of temporarily removing the Orange Bar of Doom on the weekend). The number of irritated users at the initial deployment speaks more to the visibility of the product than to its quality. Whatamidoing (WMF) (talk) 19:01, 8 July 2013 (UTC)[reply]

Need a little MATH help

Any math markup gurus out there with 5 free minutes? Could someone take a look at this page and try to convert the string of APL into markup? The string is about half way down the page, search on "and here it is". Thanks! Maury Markowitz (talk) 18:22, 4 July 2013 (UTC)[reply]

I guess you mean this --Redrose64 (talk) 19:04, 4 July 2013 (UTC)[reply]

Weird APL characters like ⍎ are included in Unicode, but not in TeX, so it is more feasible to convert it into regular text. BTW, the same (?) program also appears at the very beginning of the page.—Emil J. 19:35, 4 July 2013 (UTC)[reply]

So to convert to regular text... is there a table of chars or something I can use? Most of these do not appear in my editor's cheat sheets. Maury Markowitz (talk) 22:27, 4 July 2013 (UTC)[reply]

EmilJ gave a link, in that there are some tables which list most of the symbols. The "Unicode codepoint" column has the relevant codes, but to use these in Wikipedia you need to convert them to valid HTML. You do this by altering U+ to &#x and appending a semicolon ; - for example, the leftmost symbol of this (which is the final symbol to be processed) is "Execute", fourth from bottom of the Monadic functions table. It's shown as U+234E, so we would write ⍎ which displays as ⍎ (this isn't very clear so I'll enlarge it: ⍎).

There are several more listed at Charbase Miscellaneous Technical Block - search for "APL FUNCTIONAL SYMBOL", they're mostly between U+2336 and U+237A. The fourth column gives codes that you can use directly, without conversion. You can also click the link in the left-hand column to see a large version, for example a page like this, the codes that you need are given in the "HTML Escapes" row. When two codes are shown, as with this one, which shows ⍎ ⍎ you can use either one, they come out identically: ⍎ ⍎ --Redrose64 (talk) 07:49, 5 July 2013 (UTC)[reply]

There is no need to convert it to HTML entities. Just copy-and-paste the actual character from the table, that’s far easier.—Emil J. 11:45, 5 July 2013 (UTC)[reply]

That's if your browser/OS lets you do that without trashing the character. Anyway, the special characters needed are:

This gives ⍎'⎕',∈N⍴⊂S←'←⎕←(3=T)∨M∧2=T←⊃+/(V⌽¨⊂M),(V⊖¨⊂M),(V,⌽V)⌽¨(V,V ←1 ¯1)⊖¨⊂M'

The symbols '()+,/123=MNSTV are just the normal ones that you type at the keyboard. --Redrose64 (talk) 13:25, 5 July 2013 (UTC)[reply]

That’s amazing work, but are you sure about the diaeresis? I don’t know anything about APL, but the character on the picture looks quite different (besides not being a combining character). I’d go with ⍎'⎕',∈N⍴⊂S←'←⎕←(3=T)∨M∧2=T←⊃+/(V⌽"⊂M),(V⊖"⊂M),(V,⌽V)⌽"(V,V ←1¯1)⊖"⊂M'.—Emil J. 13:55, 5 July 2013 (UTC)[reply]

In the images [18] [19] [20] (and several others) it certainly looks like a double quote; but the intent is the each operator, as described in the original doc (search for "which is called Each") - the author of that uses two apostrophes at the only point where he uses it in plain text. At APL syntax and symbols#Syntax rules, the each operator is represented using a diaeresis, although that is not explicitly stated as the correct character. Whatever the actual symbol, I couldn't find anything called "each" in the various Unicode lists, but at this page we do have the U+00A8 diaresis, fifth row from bottom. --Redrose64 (talk) 16:24, 5 July 2013 (UTC)[reply]

Thanks guys! Maury Markowitz (talk) 12:27, 8 July 2013 (UTC)[reply]

Visual Editor: Documentation update

An oversight of the Visual Editor roll out appears to have been documentation. Currently, our help documentation describes the "old" way of doing things. I've asked Okeyes about the possibility of a roll back of the Visual Editor and the word is that that is not going to happen. Consequently, we need to update our documentation.

As the first step in the effort to update our documentation, I'd like to colate a list of affected pages, invite suggestions and ask others for help.

From a cursory view, an intial list of areas to be updated includes:

Wikipedia:Tutorial
Help: Wikipedia: The Missing Manual
Help:Starting editing
Wikipedia:Picture tutorial
Wikipedia:FAQ/Editing

However, lots of pages make passing reference to the "old" way (e.g. Wikipedia:Plain and simple) or will need to be updated to refer to the Visual Editor (e.g. Help:Table). In all, this is a big task.

The task is complicated by at least two factors:

Uptake of the visual editor looks paltry, so we will need to continue to reference to the "old" editor.
Not everything can be done in the visual editor, so we will need to educate users about when the will have to use the "old" editor.
The visual editor is only rolled out to Article and User namespaces. There does not appear to be any plan at present to include any other namespaces. We will need to educate users of this fact.
There are bugs in the visual editor. We will need to educate users of this fact.

What other pages need to be updated? What other considerations can people think of? What is the best way to go about this task?

--RA (✍) 22:31, 5 July 2013 (UTC)[reply]

This is a very good point...a very good point indeed. Category:Wikipedia_tutorials is a start at least. Theopolisme (talk) 22:40, 5 July 2013 (UTC)[reply]

Ugh. Lots of work indeed. Perhaps we can post a heads up to other projects (somehow) to try and be ready for this as well, as we were totally unprepared (I still say WP:IAR but whatever). Jguy _Talk^Done 03:09, 6 July 2013 (UTC)[reply]

The old documentation should not be deleted (or overwritten). More than 90% of edits of articles today are being done using the older (wikitext) edit approach (see section immediately); we need to keep the documentation for that.

I suggest that in many cases parallel pages, with a hatnote, would make the most sense. Thus, Help:Table would remains as is, but a new page, Help:Table (VE), would be added for VE users. At some point, say when a majority of edits are being done using VE, the VE page would become just Help:Table, and the current page would become Help:Table (wikitext).

As for the number of pages that need to be created (where VE editing is totally different from wikitext editing) or modified (where VE editing is only slightly different), there are certainly hundreds, if not thousands. Please take a look at the Editor's Index to Wikipedia. That shows. for example, in the Help pages section, that the following categories are also used for documenting how to do things:

I estimate that the amount of work required to update these (and similar pages not in these categories, nor the tutorials category) is probably in the tens of thousands of hours, since those pages involve more than ten years of cumulative documentation of how the MediaWiki software used to work. -- John Broughton (♫♫) 03:06, 7 July 2013 (UTC)[reply]

I wouldn't say that it's an "oversight", because I personally spent some time trying to find people who wanted to work on this. There was no real indication that anybody except me thought that this needed to be done, so I'm glad to hear that I'm not alone.

But this isn't really a technical issue, so perhaps it would make more sense to relocate this conversation to a place like Wikipedia talk:Help Project, Wikipedia talk:New contributors' help page or Wikipedia talk:Editor assistance. As for lists of pages that probably need to be updated, {{tutorials}} lists some more. Whatamidoing (WMF) (talk) 21:47, 8 July 2013 (UTC)[reply]

"But this isn't really a technical issue..." It's a deployment task. --RA (✍) 09:41, 9 July 2013 (UTC)[reply]

Visual Editor uptake: really just 2.9%?

I've just taken a look at the the last ~~10,000~~5,000 edits to the Article namespace, excluding bots and anons. Only 145 (~~1.45%~~2.9%) were made using the Visual Editor. My way of calculating this was to look for the string "Tag: VisualEditor" in the listings.

Is my method wrong? My maths? Or is uptake really so low? I'm flabbergasted because, if this is correct, this amounts to a near total rejection of the Visual Editor. --RA (✍) 22:45, 5 July 2013 (UTC)[reply]

No IE and Opera support... mabdul 22:55, 5 July 2013 (UTC)[reply]

I don't think so. IE only accounts for 18% of hits to the WikiMedia servers. Opera only 2.6%. (stats). Wikipedia may differ, but not that much. Even across all sites in the US, IE only accounts for ~30%.

Is my method right? --RA (✍) 23:09, 5 July 2013 (UTC)[reply]

Also, there is no support for back-level browsers. Also, there is no Visual Editor interface for Wikipedia space pages or talk pages. Also, existing users who are familiar with Wiki markup may just continue to use it, especially if they know that Visual Editor has bugs. Robert McClenon (talk) 23:12, 5 July 2013 (UTC)[reply]

What do you mean by "back-level browsers"?

I excluded all namespaces except Article. The stats are for edits to the Article namespace only. --RA (✍) 23:15, 5 July 2013 (UTC)[reply]

By back-level browsers, I mean versions of supported browsers where the browser version is not supported, such as Firefox 12, where the version is blacklisted because the version doesn't have features that Visual Editor requires. Robert McClenon (talk) 00:04, 6 July 2013 (UTC)[reply]

Remember those are not only for all wikimedia projects but they are also stats for page views not for edits so the stats could vary. For starters, it's resonable to expect editors use mobile browsers less. i'm currently using a tablet, an iPad but I can say it's rather annoying at times and there's no way I'd use it for major article edits. And as for a phone? Forgot it. The share is only about 20% in those figures but it still pushes IE up in genera. lI don't particularly know of any reason why IE is likely to be preferred by editors, more likely the opposite but ultimately the figures are fuzzy. And all these (including stuff below like automated edits) add up to the actual usage by editors not being that surprising. And considering the target of the editor, perhaps not bad. Nil Einne (talk) 18:17, 6 July 2013 (UTC)[reply]

I make it at 332 out of the last 5000 edits (6.6%). A similar probe a bit more than 24 hours ago had it as 11%, but that difference might have reflected a rush of early testing. As to why your number is different, I don't believe anyone can actually receive 10000 entries from recent changes. Admin and bot accounts can get 5000 entries at a time. It used to be that normal accounts had an even lower limit (though I don't remember what that limit was and haven't tested it recently). However, if you try to generate such a list look at the header, which says "Show last ... changes". If you request more than the limit, the limit value will be placed there. Dragons flight (talk) 23:16, 5 July 2013 (UTC)[reply]

Thanks for the tip. Yes, I'm limited to 5,000. But I still only see ~145 (146 now). Which is still just 2.9%

When did you do your test? Are you clicking the link above and searching for "Tag: VisualEditor"? --RA (✍) 23:26, 5 July 2013 (UTC)[reply]

I'm writing a script to do this automagically, if y'all can wait just a sec. I'm sure the WMF devs are doing something like this too (and probably in a much more hi-tech way)...right? Theopolisme (talk) 23:39, 5 July 2013 (UTC)[reply]

I just did the test and got 375/5000 = 7.1% of edits done with VisualEditor (filter by tag "visualeditor") --Patrick87 (talk) 23:40, 5 July 2013 (UTC)[reply]

I got 3.36% out of 10,000 most recent edits using the API (here's how). I'll run it over a larger sample space momentarily. Theopolisme (talk) 23:49, 5 July 2013 (UTC)[reply]

Thanks Theopolisme. You'll need to filter by name space (only article), remove anons (not rolled out yet) and bots (don't count). I suspect when you do, the manual figure of 6—7% will be right. Still, wow. That's over 90% of people not using it. . --RA (✍) 23:55, 5 July 2013 (UTC)[reply]

Gotcha. About to run with those parameters. Theopolisme (talk) 00:02, 6 July 2013 (UTC)[reply]

My post on this topic from July 3rd is here: Wikipedia:VisualEditor/Feedback/Archive 2013 07#Note on usage. It also discusses the fact the new(ish) user accounts are far more likely to use the Visual Editor than experienced accounts. (Whether because they like it or because they don't know any other way is largely impossible to know.) Dragons flight (talk) 00:09, 6 July 2013 (UTC)[reply]

"VisualEditor was used in 671 out of 10,000 most recent mainspace non-anon, non-bot edits, or 6.71%." Theopolisme (talk) 00:16, 6 July 2013 (UTC)[reply]

and here's the source code Theopolisme (talk) 00:17, 6 July 2013 (UTC)[reply]

Thanks, Theopolisme. Sorry to be a pain, but does that exclude bots? Thanks for doing this.

You're not a pain, I just skipped right over what you said...sorry! I've updated the above stats. Theopolisme (talk) 00:32, 6 July 2013 (UTC)[reply]

Dragon, very interesting. The pattern is to be expected but the numbers are surprising (to me anyway). Your figures from earlier would also suggest usage is dropping. I wonder if it is dropping in both user groups. IP usage next week will also be very interesting. Given what we are seeing here, I'm not sure what to expect.

"...largely impossible to know..." No it's not. You can contact them and ask. --RA (✍) 00:19, 6 July 2013 (UTC)[reply]

Updating for this morning, I see 6.4% of non-anon, non-bot article edits being made with VE. Following up on earlier stats, it appears that the uptake among editors with user pages (i.e. "experienced" editors) is 3.8% of article edits and the uptake for users without user pages (i.e. "newish" editors) is 19% of article edits. So both subgroups have declined by about a third since I first measured this on July 3rd. Regarding why new editors are using it more, I meant that it was impossible to know from the presently observable bulk statistics whether newish editors actively prefer VE or simply didn't know of other options. Of course if you want to go out and conduct a survey of new editors, then be my guest. Dragons flight (talk) 17:33, 6 July 2013 (UTC)[reply]

The statistics don't exclude edit made with AWB, Twinkle, Huggle and such like. That could increase the percentage a bit. -- John of Reading (talk) 11:14, 6 July 2013 (UTC)[reply]

Yes. Is there a reliable way we can determine those kinds of edit? --RA (✍) 13:50, 6 July 2013 (UTC)[reply]

Only by blacklisting, in a sense, edits with edit summaries that contain specific strings of characters (i.e., "HG" or "TW"). Even then it can't perfectly distinguish between automated and manual (because users have the capability to change edit summaries). TParis, doesn't X!'s edit counter tool include a list of these--and if so, could you pass it on to me? Theopolisme (talk) 13:55, 6 July 2013 (UTC)[reply]

I ran it while blacklisting ['AWB', 'TW', 'HG', 'STiki', 'Undid'], and got "VisualEditor was tagged in 864 out of 10000 edits, or 8.64%". Not perfect, but more accurate. Theopolisme (talk) 14:08, 6 July 2013 (UTC)[reply]

I'm not entirely sure it is fair to exclude some of the semi-auto tools. If the user is making a choice to use a tool that they like better than VE, then personally I'd tend to still count that as a failure to adopt VE. If VE provided automation and tools that were preferred, then (at least in principle) some users would turn away from the other existing tools and switch to VE. (Of course, that argument is largely hypothetical at this point since VE isn't really equipped to replace any of the semi-auto tools yet.) Dragons flight (talk) 17:41, 6 July 2013 (UTC)[reply]

A reason it may be fairer to count VE edits against only manual edits is because we would then just be comparing the tool users prefer when making manual edits. i.e. ratio of Edit : EditSource edits. --RA (✍) 10:59, 7 July 2013 (UTC)[reply]

When do you measure, after everyone has had experience and can judge, or while everyone is experimenting and then maybe giving up? I've tried twice now to correct links using the 'vise'. Depending on how you are counting, you'll see two unsuccessful tries at correcting 'Böotes' to 'Boötes'. I then gave up and used the direct method, when reviewing showed the vise's result of 'Böotes|Boötes|Boötes'. I would worry that attempts to make something unready work will be counted as 'enthusiasm' - "hey, they use the vise twice as much as direct editing!" Shenme (talk) 18:32, 6 July 2013 (UTC)[reply]

That makes me wonder how many VE edits were reverted. Is there a way to figure that out? I think it might also be interesting to see how many people disabled it. Last I heard it was over 500 but that was less than 24 hours after release. Its good to know that 8.6% of the edits were done with VE but I think its also important to see if they were immediately reverted due to errors. Kumioko (talk) 23:23, 6 July 2013 (UTC)[reply]

AIUI there is a huge problem with the premise that this entire topic is based on. The "Visual editor" tag is not added to the edit summaries of all edits that used VE - it is only added to those edits that the wizard "thinks" may have an errors caused by bugs in VE. Roger (Dodger67) (talk) 11:10, 7 July 2013 (UTC)[reply]

No Doger67, you're wrong. The tag you have in mind is called "visualeditor-needcheck" and is applied in addition in this case. --Patrick87 (talk) 12:49, 7 July 2013 (UTC)[reply]

Got it, thanks. Roger (Dodger67) (talk) 12:58, 7 July 2013 (UTC)[reply]

We'll need to catch that tag too. --RA (✍) 13:29, 7 July 2013 (UTC)[reply]

All the edits with visualeditor-needcheck are also tagged with visualeditor.--Salix (talk): 14:33, 7 July 2013 (UTC)[reply]

On the back of this thread, I've been bold and added some research/monitoring tasks around the Visual Editor to the Wikipedia:User Advocacy effort page. Please comment on these, if you can. If folk here would be willing to add their skills to the group, please add your name here. There is also an invitation to contribute to a brainstorming discussion on the effort. Thanks, --RA (✍) 13:29, 7 July 2013 (UTC)[reply]

Expect a large increase as soon as VE is enabled on IE8, 9 & 10. Roger (Dodger67) (talk) 13:35, 7 July 2013 (UTC)[reply]

We could get an estimate from Wikimedia Traffic Analysis Report - Browsers.

Browsers, non mobile	All requests		Html pages
Chrome	77,011 M	35.23%	6,889 M	30.88%
MSIE	36,362 M	16.64%	3,834 M	17.19%
Firefox	28,901 M	13.22%	2,775 M	12.44%
Mozilla	9,708 M	4.44%	917 M	4.11%
Opera	5,266 M	2.41%	671 M	3.01%
Safari	4,783 M	2.19%	670 M	3.00%
Tablets	11,658 M	5.31%	916 M	4.08%
Phones	36,190 M	16.5%	3,234 M	14.4%

taking the Html pages %, and assuming its really just Chrome and Firefox who currently could use VE thats 43% of posible edits, bring MSIE in adds 17%. So might expect maybe 50% more edits with VE. Its still not going to get that much uptake.--Salix (talk): 14:33, 7 July 2013 (UTC)[reply]

Additionally, those figures combine views and edits. I suspect (without evidence) that editors (as opposed to viewers) are skewed towards non-IE browsers (amongst others). There will also be other difference, for example you could effectively knock out phones (14%) from editor stats. --RA (✍) 15:12, 7 July 2013 (UTC)[reply]

Although the numbers don't be high, but users who disabled JS for any reasons (e.g. screen-readers, paranoia, etc.) don't get VE, too. mabdul 16:53, 7 July 2013 (UTC)[reply]

Updating to now, I see 8.9% of non-anon, non-bot article edits being made with VE (up from 6.4% end of last week). Whether a statistical fluctuation or the start of an actual trend, I don't know, but it is the first time since I started checking this where the fraction of VE edits has showed a sizable increase from a prior measurement. Dragons flight (talk) 20:59, 8 July 2013 (UTC)[reply]

I enjoy getting these updates of usage trends. Perhaps there could be a subpage of Wikipedia:VisualEditor that documents this information? Or maybe just somewhere in someone's userspace. Killiondude (talk) 21:08, 8 July 2013 (UTC)[reply]

I've created a subpage of Wikipedia:User_Advocacy/VisualEditor with proposed research questions. Maybe there? --RA (✍) 07:32, 9 July 2013 (UTC)[reply]

...and I'm getting "VisualEditor was tagged in 979 out of 10000 edits, or 9.79%" when I exclude automated edits as well. Theopolisme (talk)

This morning, I count 8.4% of non-anon, non-bot article edits being made with VE. Still higher than the end of last week. Dragons flight (talk) 14:54, 9 July 2013 (UTC)[reply]

Another day later, I count 10.4% of non-anon, non-bot article edits being made with VE. Dragons flight (talk) 16:16, 10 July 2013 (UTC)[reply]

11.03% excluding automated edits. Could we store this data in a table somewhere (and ideally graph it)? Theopolisme (talk) 16:20, 10 July 2013 (UTC)[reply]

Updating again in order to add numbers by subsample. Right now, I get 9.0% of non-bot, non-anon article edits coming from VE. In addition, "newish" accounts (those without user pages) are making 22% of their article space edits with VE. "Experienced" accounts (those with user pages) are making 4.5% of their article edits with VE. That newish accounts are about 5 times as likely to use VE to edit articles has remained fairly consistent since launch. Dragons flight (talk) 19:17, 10 July 2013 (UTC)[reply]

Another day, another stat: 8.3%. Incidentally, these stats seem to bounce around a bit, probably because 5000 non-bot, non-anon edits (representing about 90 minutes of real time) isn't really a long enough baseline to avoid quirky fluctuations (such as the occasional editor who is really excited by VE). At some point I'd like to write a tool to study this more systematically. Dragons flight (talk) 17:05, 11 July 2013 (UTC)[reply]

Amended VisualEditor deployment schedule

For your information, we are amending the deployment schedule of the VisualEditor and pushing the rollout to IP editors by a week. This will give us more time to squash bugs especially in the areas of dirty diffs, as well as the notorious Template:Bugzilla.

Following the deployment to the English Wikipedia last Monday, many more users have taken the time to test VisualEditor and provide feedback. You and others have reported many bugs and issues previously unnoticed, and we're very grateful for our community to have provided so much detailed feedback. We also appreciate that the launch of this beta has been disruptive. Extensive testing notwithstanding, the process of cleanly generating wikitext from a rich-text interface is very complex and somewhat fragile, which is what causes VisualEditor to sometimes insert "dirty diffs". Caching and infrastructure issues can make issues arise in a production context that weren't previously seen. We're thankful for your patience, understanding and support.

We appreciate continued reports in Bugzilla as well as on the feedback page. As we work to squash bugs, we are prioritizing bugs that impact content and stability. We are also looking for ways to educate users that they're in the VisualEditor, and don't need to use wikitext - and in fact, will create problems if they do. (See Template:Bugzilla.)

We are planning to deploy the VisualEditor beta to anonymous users on English Wikipedia on 15 July. We will follow, with a multi-language test rollout to a selected language set on 22 July, with a target date for full deployment to all Wikipedias on 29 July. Of course, the farther we get down that schedule, the more likely it is that things may change, so it is possible that the full deployment will need to be pushed into August. Because of Wikimania and staff availability, that would mean we'd be looking at full deployment somewhere around 19 August.

We hope that you'll continue to test VisualEditor as we improve it, and provide us with more feedback. Our goal is for VisualEditor to not only become as bug-free as possible but to eventually become the best collaborative authoring tool on the planet. The only way we can get there is through continued iteration and continued feedback along the way. Jdforrester (WMF) (talk) 00:20, 6 July 2013 (UTC)[reply]

Waist deep in the Big Muddy . . . . Hullaballoo Wolfowitz (talk) 13:24, 6 July 2013 (UTC)[reply]

I would rather not be testing this unfinished software. I did not receive a request asking me if I wanted to be a tester. Can't you find a group of users who are willing to be testers, rather than inflicting it on those of us who would rather wait until it is finished? Right now I just want to edit, not test software. Thanks. Nurg (talk) 23:27, 6 July 2013 (UTC)[reply]

How do I volunteer to test? I'm a professional software tester. I think that if I had conducted a Test Readiness Review (TRR), the conclusion would have been that the software was not even ready for test. I'm ready to test. Are the developers ready for real testers, who may be former developers? Are they willing to deal with real testers? Robert McClenon (talk) 23:58, 6 July 2013 (UTC)[reply]

For the most part there is no need to volunteer, just do it. Use the VisualEditor, stress it, break it, and report your observations. Wikipedia:VisualEditor/Feedback may work well for general feedback. For more specific or technical feedback, Wikimedia relies on Bugzilla (http://bugzilla.wikimedia.org/) where you can file bug reports associated with the "VisualEditor" "product". As to whether anyone is listening, that sometimes can be a bit hard to tell, though developers certainly do look at bug reports. Dragons flight (talk) 01:22, 7 July 2013 (UTC)[reply]

James, I don't know what your scheduling constraints may be, but in a perfect world, one shouldn't really worry about when it will be deployed so much as what will be deployed. Specifically, it would make more sense to have a road map of development milestones, and each week your team considers whether or not to deploy in the near future based on whether the associated milestones have been met. For example, a checklist for the wide deployment to logged-in users might have included:

Provides functionality for most or all features needed to edit text, links, tables, images, templates, and reference / citations
All wiki elements that aren't managable by VE and associated functionality is disabled by default
No known bugs that produce corrupted output
No known bugs affecting the process of opening / saving / abandoning edits
UI is functional and legible across full range of supported browsers
Load, edit, and save processes execute in a reasonable run time
Visual editor must be easily disabled by users who chose not to use it

Obviously such a list could be elaborated in considerably greater detail (e.g. for example listing which features of template editing are required), but the point is to set specific development goals and identify blockers (personally I'd regard anything that spits out bad wikicode as a blocker when considering future deployments). It is usually okay if the software is not functionally complete, but broadly speaking the features that are provided should be functional. In other words while the list of missing features might be large, the list of known bugs ought to be very short at each phase of deployment. In addition, at each phase of deployment adequate time ought to be given for testing and feedback regarding major changes added since the previous major deployment.

I fully recognize that tons and tons of work must have been undertaken just to get here, where conversations about deployment make sense, and you all should be applauded for that. However, I don't think it is good to rush the final steps. A lot of skilled effort can be undermined by community perceptions that a new product is awkward or buggy. One shouldn't worry too much about when things get deployed as compared to making sure that the set of features that are deployed work well and provide a good experience. Dragons flight (talk) 01:11, 7 July 2013 (UTC)[reply]

Apparently they have a schedule, and while they can justify some schedule slippage, it's still the schedule that drives things (apparently). So although expanding the default VE setting to all IP editors has absolutely no value in identifying bugs, it's on the schedule, and (to repeat myself) schedule slippage can only (apparently) be justified to a limited extent. Otherwise, why would a Beta version (which states "it may not let you edit everything yet") be about to be rolled out out to everyone, including (IP) editors who can't turn it off? — Preceding unsigned comment added by John Broughton (talk • contribs) 02:43, 7 July 2013 (UTC)[reply]

Users are resilient but fatal edit-conflicts in VisualEditor are cruel: For the past 2-3 years, the editor-activity levels have been relatively stable (except for the 30% jump in March 2013 to force Wikidata interwiki links), and editors have survived whatever hardships have been imposed on them. My main concern, predicted months ago, is the demoralizing effect of edit-conflicts on the tedious, keystroke-laden WYSIWYG editing. So, it is important for users to know, based on recent edit-conflict tests, how any interim, erstwhile edit of the same page will completely trash a VisualEditor session. I urge users to please not hit the keyboard, in boundless anger, when the VisualEditor reports an edit-conflict which cannot be fixed; instead, try the browser-back button to return to the VisualEditor and try to copy/paste text into another window, for when the VisualEditor dies, unable to merge even a one-word prior change of the page with the current keystroke updates. Psychologically, one of the fastest ways to get new users to quit Wikipedia is to have the VisualEditor crater on a long edit to a page, and lose all changes, while pretending an edit-conflict preview could salvage the page, but in reality, all keystrokes would be lost. -Wikid77 (talk) 06:20, 7 July 2013 (UTC)[reply]

When I was pondering whether to turn of VE, I hadn't thought about edit conficts. I routinely copy to the clipboard any long text I write since the conflict resolution process with the old editor is such a pain that it's easier to start over. Since that wouldn't work with VE, I hereby condemn Visual Editor to death. Jc3s5h (talk) 13:48, 7 July 2013 (UTC)[reply]

Just been reading bugzilla 50601, and I strongly oppose this solution on general grounds; checking hundreds of VE edits, the amount where the "nowiki" was wanted/needed was minimal (close to non-existent), while the cases where nowiki was added incorrectly or unwanted was significant. Certainly with square brackets, not having the nowiki should be default. It doesn't make any sense to tell people that in VE, the wikimarkup doesn't work and shouldn't be used, when they still need the wikimarkup inside VE when editing templates (linking parameters and so on). Please, please, re-enable the square brackets inside VE. Of course, keep the possibility to create links the VE way, but don't include all square brackets inside nowiki, certainly when on the other side people still need to use this inside infoboxes and the like. Fram (talk) 07:11, 9 July 2013 (UTC)[reply]

I wonder if "[[" could be used as a keyboard shortcut to open VisualEditor's link tool. Whatamidoing (WMF) (talk) 21:49, 11 July 2013 (UTC)[reply]

Controlling order of reflist

Don't see where else to post this. Consider this:

According to Smith<ref name=Smith2010/> it's true, but Jones<ref name=Jones2009/> says it's false. {{Reflist|refs= {{refn|name=Jones2009|Jones, J. (2009) ''The truth'' }} {{refn|name=Smith2010|Smith, S. (2010) ''Jones lies''}} }}

which yields:

According to Smith^[1] it's true, but Jones^[2] says it's false.

^ Smith, S. (2010) Jones lies
^ Jones, J. (2009) The truth

As usual, entries in the reflist appear in the order first cited in the text. [bolding added later -- see below] But I want them in the order in which I listed them in the {{Reflist|refs = section (in this case, alphabetical order, because the Reflist is really going to be a bibliography). Is there some way of doing that (perhaps some special syntax to Reflist)?

Thanks! EEng (talk) 21:24, 6 July 2013 (UTC)[reply]

Apart from actually making it a bibliography and using templates from the {{sfn}} family, no. Matma Rex talk 21:26, 6 July 2013 (UTC)[reply]

I don't understand. It is a bibliography, but I want to label the entries A,B,C or whatever, and refer to them using linked superscripts in the article text, via a <ref>-type syntax. This seems a natural thing to want to do. Are you saying sfn would help with that? EEng (talk) 21:48, 6 July 2013 (UTC)[reply]

As an alternative (which would allow a disgusting hack on this), is there some syntax for <ref name=Jones2010/> that would cause only this one callout to Jones2010 to not have a backlink next to the Jones2010 entry in the reflist? (It is recognized I am grasping at straws here.) EEng (talk) 21:52, 6 July 2013 (UTC)[reply]

Put a Sources section of titles, then {sfn} each author/year link: Under the References section, put a "===Sources===" subsection with book titles in a bullet list of {cite_book} with ref=harv or such. Then use Template:Sfn in the upper text, to link each book author/year into the Sources list. -Wikid77 (talk) 21:56, 6 July 2013 (UTC)[reply]

Look at Today's Featured Article: Dodo. It has numbered short cites (created by template) and then an alphabetized bibliography (called "sources" in this case). That is the way issues like this are usually handled where you want both the links but also a specific layout of sources. Dragons flight (talk) 21:59, 6 July 2013 (UTC)[reply]

I'm familiar with these techniques, but as mentioned I want the article text to refer to the sources using e.g. ^[A]:20 (and here I'm using the </nowiki>^: 20</nowiki> syntax too) not e.g. (Jones 2010). So the entries in the Sources list need to be assigned A,B,C etc. codes (I'd be happy to do that manually, but it's a nightmare if something's added to or dropped from the list -- everything shifts), and I'd like backlinks from the sources entries to the callouts in the main text. The ref machinery is perfect for this, except for the order in which the reflist comes out. See now? EEng (talk) —Preceding undated comment added 22:26, 6 July 2013 (UTC)[reply]

Can you point to an article where that style is already in use? If so, we'll explain how it's done.

Dodo, btw, uses almost-pure Shortened footnotes. I say "almost" because it's throwing about 6 big red errors for me. --Redrose64 (talk) 22:28, 6 July 2013 (UTC)[reply]

1. The first part of your questions concerns List-defined references, and as I wrote on that help page: "The references will appear numbered in the order that they are referred to in the content, regardless of how they are ordered within the reference list."

2. There is no way to suppress a footnote backlink. I have a bug report in for that, but it has gone nowhere.

3. The Shortened footnotes help page has examples of articles with good use.

4. As noted at List-defined references, you can use {{r}} to include the in-text citation with a page number. It only supports the default footnote labels, but we could do a variant.

-- Gadget850^talk 02:41, 8 July 2013 (UTC)[reply]

None of this answers my question/request. I hope you will forgive my taking the liberty of numbering your points above for reference.

1. Obviously I know that "The references will appear numbered in the order that they are referred to in the content, regardless of how they are ordered within the reference list." -- I said so in my opening post. (I've put that in bold now to make that even more obvious.)

2. In the absence of a useful outcome on point 1., suppressing one backlink would help in a hack in mind for getting something similar to what I really want. But looks like I shouldn't hold my breath.

3. I already explained what I'm trying to do, and it's nothing like sfn.

4. Ditto.

I repeat: I don't need it explained to me how reflists are ordered now, by default -- I know that. My question was whether there's some syntax or trick to change the order; or (implicitly) in the alternative, I was hoping someone would be inspired to add such a function, or tell me where to go to request that this be done. So can someone please answer that question, instead of telling me how to do things other than that which I came here to learn how to do??? In desperation I've implemented a painful hack [21] demonstrating how such a feature might be applied (ignore the entries in the References section -- they're meant to be migrated to other sections).

EEng (talk) 03:44, 10 July 2013 (UTC)[reply]

If you use (or wish to use) any form of referencing which involves <ref>...</ref> and <references /> (whether directly or hidden inside templates like {{sfn}} or {{reflist}}) the answer is

No, the order that they are listed is determined by their order in the wikitext, and cannot be changed; it follows that the order that that they are numbered is determined by the order that they are listed.

If you want some other ordering you cannot use <ref>...</ref> and <references /> but must use a custom method - which will be complicated - or one of the older systems from about eight years ago which required every ref to be hand-numbered. See {{ref}}, {{note}}, {{ref label}}, and {{note label}}. --Redrose64 (talk) 07:30, 10 July 2013 (UTC)[reply]

Given that it's perfectly natural to want the reflist entries to appear in some useful (instead of haphazard) order, I'm puzzled as to why the possibility of adding such a feature to <ref>...</ref> and <references /> is being ignored. Where would I go to make such a request? EEng (talk) 11:51, 10 July 2013 (UTC)[reply]

Which is the Template:Fnote3 system. -- Gadget850^talk 10:46, 10 July 2013 (UTC)[reply]

~~Sounds like that may have to be the interim stopgap. EEng (talk) 11:51, 10 July 2013 (UTC)~~ I spoke to soon. Only an insane person would consider using Template:Fnote3. EEng (talk) 13:33, 10 July 2013 (UTC)[reply]

This almost works, except for a spurious backlink:

According to Smith^[2] it's true, but Jones^[1] says it's false.

^ ^a ^b Jones, J. (2009) The truth
^ Smith, S. (2010) Jones lies

—Emil J. 12:13, 10 July 2013 (UTC)[reply]

But you've not used {{ref}}/{{note}} at all - you've used almost exactly the same code as EEng did in the original post, with two differences: (i) you've quoted the ref names (which will not make any difference); (ii) you've added <span style="display:none"><ref name="Jones2009"/></span> which is what's causing that "spurious backlink". --Redrose64 (talk) 12:36, 10 July 2013 (UTC)[reply]

Who cares whether he used {{ref}}/{{note}}? What does that have to do with anything? The <span style="display:none"><ref name="Jones2009"/></span> he added forces the Jones ref to come first, which is something like what I was looking for. As it happens I had already thought of a similar idea, as seen in the mockup I linked a bit earlier ([22] -- open the source for editing and look at the shamefaced comment at the very beginning). It's why I asked (somewhere above) for a way to suppress a single selected backlink. (Thanks, EmilJ, for trying to help.)

Frankly I'd be willing to live with the spurious backlink if that's the best we can do.

EEng (talk) 13:19, 10 July 2013 (UTC)[reply]

If that's your attitude, who cares that you want to use some system that is different from the Wikipedia norm? Three times I responded to a plea for help: but have been rejected once too often. I'm done helping here. Just don't blame me if somebody tidies up that spurious backlink. --Redrose64 (talk) 14:07, 10 July 2013 (UTC)[reply]

Look, all I asked is (1) if there's a way to control the order of the reflist and (2) failing that, where I'd go to make a request that such a feature be added. Can you please just answer that? EEng (talk) 15:25, 10 July 2013 (UTC)[reply]

you may want to look into mw:Extension:Cite and it's talk page. peace - קיפודנחש (aka kipod) (talk) 16:04, 10 July 2013 (UTC)[reply]

Thanks! I'll want to look around there and learn what I can before posting, so it may a while. EEng (talk) 18:01, 10 July 2013 (UTC)[reply]

how do I click on links?

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

It works for me. What does the pop-up say? Can you click the link when you log out? What is your browser and skin? PrimeHunter (talk) 01:05, 7 July 2013 (UTC)[reply]

It's the footnote text. I use FF. Looks like it only happens when the fn is big enough to cover up the link when it pops up. Probably a bug. — kwami (talk) 02:40, 7 July 2013 (UTC)[reply]

@Kwamikagami: which version of FF ? —TheDJ (talk • contribs) 14:16, 7 July 2013 (UTC)[reply]

Perhaps disable Reference Tooltips: This past week, I was testing in a major public library which has IE8 browsers, and the reftag pop-ups were getting stuck on the screen. I had to set Special:Preferences, to disable the wp:Reference Tooltips, by unchecking:

[_] Reference Tooltips: Roll over any inline citation to see reference information,
instead of having to jump away from the article text.

I am not sure why the Tooltips got stuck in IE8, but perhaps there are several other bugs with them. -Wikid77 (talk) 07:03, 7 July 2013 (UTC)[reply]

They weren't getting stuck, but the hand cursor would change to an arrow when close to the pop-ups, and as an arrow it wouldn't follow the link. — kwami (talk) 09:23, 7 July 2013 (UTC)[reply]

Wow, didn't know that script was so broken on older IE. looking... —TheDJ (talk • contribs) 13:42, 7 July 2013 (UTC)[reply]

Infobox images missing from PDFs

Tracked in Phabricator
Task T52948

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

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

nonarticle namespaces main pages

When I tried to go to http://en.wikipedia.org/wiki/Help:[24] (including the trailing colon) maybe 10 minutes ago because I wanted the home page for the namespace, I got a page titled Bad Title, which itemizes errors I may have made but the type of URL I supplied is not one of them. Two solutions:

Edit Bad Page to add this case. The page does not have an "Edit" tab link, so apparently I can't edit it.
Create redirects for this case (one for each namespace). If you tell me how, maybe I can do it, but usually I'd do it by typing the bad address and being invited to create the desired page and that invitation didn't appear this time, so either please tell me how or maybe someone else has the authority to do it.

Thanks. Nick Levinson (talk) 16:05, 7 July 2013 (UTC) (Corrected confusing display of URL: 16:08, 7 July 2013 (UTC)) (Clarified on colon: 16:12, 7 July 2013 (UTC))[reply]

As far as I know, there are no "home" pages for any namespace, with the possible exception of articlespace (and even that's debatable - http://en.wikipedia.org/wiki/ is actually root for all namespaces.

It's not clear that there is any advantage in creating such "home" pages. The error message you got, while perhaps lacking in clarity, does cover your case - you used a URL that had no page title, and the error message begins "The requested page title is invalid. It may be empty ..."). ["empty" = "blank" = "not provided", in programmerese]

More to the point - changing this situation would require programming resources. It's difficult to justify doing so: you put in a bad url, and you got an error message. You were looking for something (a "home page") that doesn't exist, and you found out it didn't exist. -- John Broughton (♫♫) 16:48, 7 July 2013 (UTC)[reply]

No such thing as "namespace home page" exists; zero-length titles are invalid, and "Help:" is a zero-length title in the "Help" namespace. On a side note, there is a volunteer's patch in gerrit aiming to improve that error message (https://gerrit.wikimedia.org/r/#/c/43166/, "Show detailed errors for bad titles." by "VitaliyFilippov").

What were you expecting to find under that URL? :) Matma Rex talk 17:04, 7 July 2013 (UTC)[reply]

What I wanted to find was something like a directory of relevant pages, in this case pages in the Help namespace, as presumably there wouldn't be a namespace unless there's more than one page (or at least a plan for more than one page), so I could choose the page most relevant to my need.

It's usually more user-friendly to have a home page for any directory (or namespace) that's open to the public. I found out the page was bad but it wasn't clear how to get what I wanted, which is the point of the Bad Page itemization. The root you gave redirects to Main_Page, which is good for that namespace and indirectly for other namespaces. http://en.wikipedia.org/w/ also redirects to the same Main_Page (in the wiki/ directory). As I recall from a non-Wikimedia context, redirects on Apache platforms are one- or two-line text files and, even if there are hundreds of namespaces, the same file can be copied to all of them except the destination (which doesn't need a new one). Editing the Bad Page for clarity doesn't seem like it would take a lot of programming resources, and that page should be clear to nongeeks, to whom a namespace and a colon does not appear to be zero-length. Clarifying may be easier than adding redirects.

Nick Levinson (talk) 18:28, 7 July 2013 (UTC)[reply]

The error message is from MediaWiki:Badtitletext. I don't know whether it can be customized to recognise which title it's displayed on but I don't think it would be worth customizing it for a few manually created invalid url's like this. By the way, a search on Help: (and similar for other namespaces) gives the red error message: "An error has occurred while searching: The search backend returned an error:". I consider that slightly more problematic but not worth bugging developers about. PrimeHunter (talk) 22:21, 7 July 2013 (UTC)[reply]

For an index of pages, you can go to Special:AllPages and select a namespace. -- John Broughton (♫♫) 03:41, 8 July 2013 (UTC)[reply]

Special:AllPages is somewhat useful, although it doesn't indicate which page might serve as a main page for the namespace.

Customizing according to a user's request is almost certainly far too much programming. Adding to or clarifying the itemization that's already there would be easier to do and good enough for nongeeks, and offering a partial solution like Special:AllPages could be helpful.

I wanted to check a hit counter for the Bad Page, but since it keeps the URL I had typed I don't know how to check how often the Bad Page is visited from all the URLs that could generate it. Customizing for one URL is wasteful, but clarifying regardless of URL is probably relatively useful.

But if it's still not worth fixing, I'll leave it at that. Thanks for the feedback. Nick Levinson (talk) 15:57, 8 July 2013 (UTC)[reply]

Audio thumbnails no longer resize

I have Diamond Trust of London at FAC; a small thing that's niggling me, and only recently appeared - is that the audio file thumbnail no longer responds to size parameters. As the audio thumbnail is directly below an image thumbnail, I'd like them to be the same width so that the text is neatly aligned to the side.

This thumbnail no longer responds to the "upright" parameter. It did when I originally wrote the article in May.

I have tested this in the latest versions of Firefox and Chrome. Is this change by design? When did this occur? - hahnch e n 16:25, 7 July 2013 (UTC)[reply]

I cannot find any existing ticket listed in the bugtracker yet. If the problem is reproducible, it would be nice if somebody who has this issue could send the software bug to the 'Bugzilla' bug tracker under product "MediaWiki extensions" and component "TimedMediaHandler" by following the instructions How to report a bug. This is to make developers of the software aware of the issue. If you have done so, please paste the number of the bug report (or the link) here, so others can also inform themselves about the bug's status. Thanks in advance! --AKlapper (WMF) (talk) 16:10, 8 July 2013 (UTC)[reply]

VE: request earlier implementation - partially

May sound funny, but I'm serious. I suggest a specific part of Visual Editor is rolled out ASAP.

That is: in every namespace, change the old "edit" tab label (text) into "edit source" tab label without changing the behaviour (same as it was done is in Article and User space already). That way everyone can get used to that change, for example in Template space (my home town). While there is no distracting/changed effect "edit" tab label in view, I get the difference even before VE arrives there. -DePiep (talk) 17:27, 7 July 2013 (UTC)[reply]

Looks like this has already been proposed with mixed reactions. Theopolisme (talk) 17:35, 7 July 2013 (UTC)[reply]

Personally, I support the use of a consistent tab label. If "edit source" is going to be the label we are stuck with for articles, then having the same description applied to all source editing tabs makes sense. Dragons flight (talk) 17:57, 7 July 2013 (UTC)[reply]

I was about to strike my request here, but then I read the immature discussion in June (!) (with bug ref bugzilla:50402) you linked to. Because of that immatureness I keep this post open. -DePiep (talk) 18:07, 7 July 2013 (UTC)[reply]

I support renaming, FWIW -- it's going to happen eventually (well, not for the talk namespaces, but presumably everywhere else), so why not get editors used to it now? Theopolisme (talk) 23:03, 7 July 2013 (UTC)[reply]

For future reference, WP:VE/F is the best place to give feedback for the VisualEditor (or to check for existing threads requesting the same feature/bugfix) so the developers can see it. Hope that helps. --AKlapper (WMF) (talk) 16:14, 8 July 2013 (UTC)[reply]

Earwig @ toolserver

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

Error !

IndexError: list index out of range

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

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

if highlights[i]:

pages/copyvios.mako, line 136:

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

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

callable_(context, *args, **kwargs)

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

Ha-hello, human being. Your checker is really good when it isn't doing something like above. Thanks for the info. — Maile (talk) 22:52, 7 July 2013 (UTC)[reply]

1st section "edit" button links to 2nd section

I just noticed this today; not sure how long it has been in effect. When I click the lede section edit link near the article title, it links me to an editing window with the 2nd section text. The 2nd section edit link also links to the 2nd section. I am editing in Firefox with the "visual editor" disabled (of course). VQuakr (talk) 00:25, 8 July 2013 (UTC)[reply]

Even better - the problem now seems intermittent. Purging the page seems to help. VQuakr (talk) 00:44, 8 July 2013 (UTC)[reply]

As stated above and at Wikipedia:VisualEditor/Feedback‎, the ability to edit the lead section is a gadget, and the VE development team doesn't support this gadget. GoingBatty (talk) 04:17, 8 July 2013 (UTC)[reply]

And I don't support a new gadget not supporting old gadgets. I also do not have VE enabled. When is it going to be fixed? VQuakr (talk) 04:25, 8 July 2013 (UTC)[reply]

VisualEditor is being developed by the Wikimedia Foundation, and is not a volunteer-maintained gadget. Per the response I received at Wikipedia:VisualEditor/Feedback/Archive 2013 07#No "edit source" for section 0, "Gadgets are expected to be compatible with MediaWiki rather than the other way around." Looks like a discussion started at MediaWiki_talk:Gadget-edittop.js#VisualEditor? as well. GoingBatty (talk) 04:39, 8 July 2013 (UTC)[reply]

This is a very annoying bug. I too do not have VisualEditor enabled. A workaround (not that "purging page) is urgently required. --Tito☸Dutta 06:00, 8 July 2013 (UTC)[reply]

You can edit source of another section and manually replace the section number at the end of the url with 0. Here is quickly made inelegant code to add an "Edit lead" link to the toolbox: [25]. PrimeHunter (talk) 13:19, 8 July 2013 (UTC)[reply]

Bad idea. --Tito☸Dutta 16:10, 9 July 2013 (UTC)[reply]

This is the same problem that I noted above. --Redrose64 (talk) 17:50, 8 July 2013 (UTC)[reply]

No update/fix? Is anyone listening here? This needs to fixed soon. I am continuously incorrectly entering to section=1. Tito☸Dutta 16:10, 9 July 2013 (UTC)[reply]

Stop shouting and be patient. Jeez. Giant Snowman 16:24, 9 July 2013 (UTC)[reply]

Please see the last post that I made in #Non-interaction Visual editor and Add an .5Bedit.5D link for the lead section of a page - did my fix not work for you? --Redrose64 (talk) 16:28, 9 July 2013 (UTC)[reply]

Changing the labels on the "Edit" (VE) and "Edit source" tabs

Many moons ago, the "New section" tab was had a much shorter label: "+". After much discussion (and a new gadget to maintain this label if desired), "New section" became the default label. As I recall, this didn't require programmer sign-off, just admin action (and consensus).

So, I want to assess the options for doing something similar with regard to the new "Edit" tab for VisualEditor.

(1) Is it (still) possible, technically, to change "Edit" to read "Edit (VE)", and to change "Edit source" to read "Edit wikitext", or maybe even just "Edit"?

(2) Is it possible, technically, to switch the tabs, so that "Edit wikitext" (or perhaps just "Edit") is to the left, and "Edit (VE)" is to the right?

-- John Broughton (♫♫) 01:24, 8 July 2013 (UTC)[reply]

(1) Yes, this is possible with admin action alone, (2) Not in any easy way I can see without involving the developers. Dragons flight (talk) 01:55, 8 July 2013 (UTC)[reply]

PS. Because of the way the developers use "Edit" to sometimes to mean "source editor" in some namespaces and "visual editor" in other namespaces, a change to the "Edit" label would actually be somewhat complicated too. Far more so than a typical interface change. Dragons flight (talk) 02:02, 8 July 2013 (UTC)[reply]

Yes its possible to do both without the developers. Option 2 would require a script but it shouldn't be that hard to craft. There are several of us who could technically do a script like that but it would require an admin to implement and a pretty strong consensus. I would also hold off for a while until they get some of the bugs worked out of the VE program. Right now its too unstable to make a bunch of workarounds IMO. Kumioko (talk) 02:10, 8 July 2013 (UTC)[reply]

Thanks; very helpful. What I'm concerned about is the 15 July date for making VE "available" to IP editors; that's when "Edit" appears (for VE) and "Edit wikitext" appears for the older editing interface, for IP editors.

If VE is still problematical by that date - in particular, not being able to see, let alone edit, hidden/invisible text when using VE - then I think it would be desirable to at least nudge IP editors in the direction of continuing to use wikitext editing. I'd prefer, of course, that the availability of VE not be expanded until more problems are fixed (stability, addition of missing features, better UI for features like citations). However, the developers seem to feel strongly that meeting target dates (more or less) has value in and of itself. If they insist on pressing on, we should think about how to mitigate the damage. -- John Broughton (♫♫) 03:23, 8 July 2013 (UTC)[reply]

The problem with a button-altering script is that it loads fractionally after everything else, so you'd get the buttons appearing and then switching place (or otherwise jumping around). I think this might get more people annoyed than the alternative! Andrew Gray (talk) 19:05, 8 July 2013 (UTC)[reply]

Lua app or edit-filter to spot VisualEditor page glitches

[VE garbled pages are detected by Special:AbuseFilter/550. -Wikid77 04:04, 10 July 2013 (UTC) ][reply]

We can write Lua apps which read an article looking for garbled text: It is very scary to imagine allowing 100,000 users per month to edit with a broken VisualEditor which corrupts the text, double-pipes the links, or garbles unmodified image links, but since I first saw Wikipedia, I concluded "Wacko-pedia" with all the peculiar stuff I later came to describe as "wiki-spastick" and quite common, such as parameters coded as dizzy triple-braced "{{{1}}}" rather than simple Template:J using the same '#' as a metacharacter in #switch or #ifexpr, as common for 4 decades in computer systems. It was like, hello, didn't anyone learn anything from the horrors in LISP (CAR) and (CDR)? Or "edit-conflict" in a modern(?) computer system designed to support multiple users (imagine going to an automated bank teller and getting "access-conflict" on a bank account with recent debit purchases and told to re-enter the transaction!). However, in the case of predictable bug glitches inserted by VE, we could write some Lua apps which accept a page name and look inside the markup for obvious garbled structures, then list the anomalies, with line numbers, for experienced editors to patch. Otherwise, after all these years of wackofied stuff or peculiar error messages in articles, then most readers would quickly discount any new glitches in pages, as just basically more of the same from the past 12 years. It was just a matter of time before the whole of Wikipedia became wiki-spazzed in every area, but now we know how we are the ones to write debuggers or auto-fixit wizards to circumvent many problems. Decades ago, computer professionals developed "syntax checkers" to help edit markup languages and spot invalid meta-text, and meanwhile WP omitted that step and has gone straight to chalk-board simulation editing, but Lua can be used to create syntax checkers to run after a long edit and remind users to fix glitches in the markup format. -Wikid77 (talk) 17:10, 8 July 2013 (UTC)[reply]

This is a 300+ word comment, and I'm sure almost everyone who sees it skims over it regardless of the merits of what you're saying. Could you please try to be more concise in future? Andrew Gray (talk) 19:05, 8 July 2013 (UTC)[reply]

The 300+ word comment is concise: When considering all the issues covered, in my above comment, then it is very concise. It starts with the concise bolded paragraph header "We can write Lua apps..." and then covers 2 or 3 examples of each issue. Instead, I could have explained, in more detail, how a VisualEditor which corrupts text is typical SOP for WP software, as compared to the design flaw of the triple-tic mark bolding ('''bold''') which could have been coded using the metacharacter '#' as perhaps: #b(bolded), where italic text would be "#i(italicization)" and then both together could have been #ib(italic-bolded) rather than '''''italic-bold''''', and then a literal right parenthesis could be "#)" to show a closing curved bracket inside a bolded or italic string. At any time, a double-hash '##' would show the literal single '#' hashmark. That use of '#b' for bolding would lead to parameter syntax of '#[1]' instead of "{{{1}}}" to access the value of parameter 1. Similarly, I could have explained, in more detail, how most edit-conflicts could be auto-merged, especially in talk-pages where most editing involved adding lines, rather than rewriting of paragraphs. It is truly bizarre how edit-conflicts remain a common part of wiki-editing, when perhaps 95% of them could be auto-merged as multiple insertions stacked, in LIFO (last-in, first-out) order, where a new, erstwhile inserted subsection "==Topic==" would always remain below a 2nd editor's insertion at the same old line number. Those issues are prelude to the unusual fact that a syntax checker would be expected in wiki-editing, such as edit buttons [Show_Preview] [Show_Changes] [Check_Markup], where the Check_Markup option would run a syntax checker to validate use of markup, and then the user is free to ignore warnings or try to adjust the wikitext to avoid syntax warnings. Instead, we get the VisualEditor, long before the button [Check_Markup], and that is truly bizarre in computer systems which use a rigid language structure which has several rules of proper syntax, which could be checked to warn users of potential trouble with the text formatting. Meanwhile, we could write some Lua apps, which accept a page name as input, to run a similar syntax check (on the top-level page), and perhaps even warn that some template names are not valid, or even check the parameters used in major templates which the syntax checker has been directed to proofread for parameter placement. What I hinted at, in the above concise comment, was that we got VisualEditor long before we got the button "[Check_Markup]" but Lua can be used to simulate that capability, and check for typical glitches caused by known bugs in VE, such as links of the form "[[aa|bb|cc]]" as a warning to the editor to check the wikilink format. More later. -Wikid77 (talk) 21:25, 8 July 2013 (UTC)[reply]

"Concise" would have been writing: "We could develop a Lua-based tool to check for markup problems caused by known bugs". Rambling on about "wiki-spastick" and ATMs is not, and it's not fair to other users on a busy page to expect them all to take time to read this and try to make sense of it. Andrew Gray (talk) 23:20, 8 July 2013 (UTC)[reply]

Wikid, you've talked many many times about creating Lua scripts to check markup. If it's so wonderful, why not mock up a demo rather than posting the same comments over and over. the wub "?!" 08:32, 9 July 2013 (UTC)[reply]

I'd be happy to see this too, but a built-in feature to MediaWiki would be preferable. Really, almost any text is "valid" MediaWiki markup, but nobody actually wants to write [[X|Y|Z]] or '''''Foo[[Bar''']]''. See also: bug 21913. πr² (t • c) 03:26, 10 July 2013 (UTC)[reply]

See below, edit-filter 550 working. -Wikid77 04:04, 10 July 2013 (UTC)[reply]

Anyway, this is probably a tangential discussion that belongs in its own thread. Regarding the OP's questions, Dragons flight is correct. You could technically switch the tabs using JS or perhaps CSS, but it should probably be done only after a discussion, and in the extension itself (not in Common.js/css) πr² (t • c) 03:30, 10 July 2013 (UTC)[reply]

I have split this portion as subthread "Lua app or edit-filter to spot VisualEditor page glitches". -Wikid77 04:04, 10 July 2013 (UTC)[reply]

Edit-Filter 550 currently detects pages garbled by VisualEditor: To re-focus on the main concern, of mitigating the damage done by VE, I see now Special:AbuseFilter/550 can detect pages which have bizarre markup garbled when using the VisualEditor, such as unexpected "nowiki" tags or wikilinks with split words. See log entries for filter 550:

http://en.wikipedia.org/w/index.php?title=Special:AbuseLog&wpSearchFilter=550

I guess try to prioritize to fix the most-read articles first, and imagine a world in which the Wikimedia Foundation was the greatest cause of vandalizing pages, and try to enjoy the "cosmic joke" of how some of the worst hack-edits in years are caused by the VisualEditor, rather than by juvenile pranksters! OMG too funny! -Wikid77 04:04, 10 July 2013 (UTC)[reply]

About common.js

When I was creating the page "User:AsceticRose/common.js" for using the importScript('User:TheJJJunk/ARA.js'); code (Automatic Referencing Assistant tool found at User:TheJJJunk/Automatic Referencing Assistant page), I was shown the message "Code that you insert on this page could contain malicious content capable of compromising your account. If you are unsure whether code you are adding to this page is safe, you can ask at the appropriate village pump" at preview page. Then I abandoned creating the page. Will anyone please tell me if this code is malicious. And what actually "common.js" page is? I use Opera 12.15 --AsceticRosé 02:42, 8 July 2013 (UTC)[reply]

Yes if you trust the script you/re loading then you can go ahead. Theoretically someone could replace it with a virus but the only people who can edit that page are TheJJJunk (talk · contribs) and administrators. I would hope that among those people no one would want to deliberately infect other Wikipedia users. —Soap— 05:27, 8 July 2013 (UTC)[reply]

A common.js page loads javascript no matter what skin you are currently using. If you know a piece of js code will only work and/or be beneficial for a specific skin, you can name it xx.js where xx is the skin name (vector.js, for example). Help:Javascript might be some good reading. Killiondude (talk) 05:47, 8 July 2013 (UTC)[reply]

The message you saw basically means that if you should exercise a bit of caution. Personally, I've never heard of a script that was compromised/malware, but perhaps there are (rare) examples where it happened in the past. More to the point, if I were in your shoes, what I'd do would be (a) think about how I found the script - the more obscure the path, the more to think about (and I certainly would never copy a script from other than a Wikipedia page), and (b) make sure that the page with the script (the one you're importing, or copying from) ends with .js; that prevents anyone but the owner, and admins, from editing it.

If you see something suspicious, asking here is a good idea. Otherwise, just go ahead and add the script, and don't worry about it.

(P.S. "commons.js" is the default location that the software running Wikipedia looks, to see if you have any scripts that you want to use to enhance your reading or editing experience. The browser you use doesn't matter, at least as far as the filename goes.) -- John Broughton (♫♫) 16:14, 8 July 2013 (UTC)[reply]

Although the message is a bit hard, and your msg "Personally, I've never heard of a script that was compromised/malware, but perhaps there are (rare) examples where it happened in the past." is correct - loading resources from other servers but WMF servers result in releasing one's IP address, the web browser and operating data and other additional information (e.g. maybe geolocation data). Although this don't have to result in a overtaken computer, it might be against one's privacy. mabdul 21:57, 8 July 2013 (UTC)[reply]

File does not render below 15px

This file renders as a blank white square (), as does any size of it smaller than 15px. At 15px and above (e.g. [26]), it renders correctly (). Depending on ribbon size, display size and resolution, etc., the smaller image sizes are used by en:Template:Ribbon devices. How can I fix this? (originally posted at Commons:Help desk) —[AlanM1(talk)]— 03:38, 8 July 2013 (UTC)[reply]

Youd probably be better off using a PNG or other raster image format, since that particular SVG probably wasnt intended to ever be so small. Im not sure what youre seeing on your screen, but for me the 15px version is just a gray solid star, which although visible, really doesnt look much like the full size image either. For a PNG image, we already have File:Award-star-gold-3d.png which appears as

at 13 pixels. —Soap— 05:29, 8 July 2013 (UTC)[reply]

Actually, it renders strangely for everything under 100px:

Original PNG, SVG:

Award-star-gold-3d.svg 100,90,80,70,60,50,40,30,20,10px:

I found one with a slightly different filename (Award star instead of Award-star) that works fine:

Award star-gold-3d.svg 100,90,80,70,60,50,40,30,20,10px:

So, there's either something wrong with the SVG or the way that particular file is being handled by the wiki(s). I'll note that the working one is much larger and has a PNG embedded in it. —[AlanM1(talk)]— 10:04, 8 July 2013 (UTC)[reply]

This is a known bug in librsvg (we have a bug at bugzilla:42090, as well as upstream at bugzilla.gnome.org/show_bug.cgi?id=605875) and occurs when the radius of the Gaussian blur filter effect drops below one pixel. Even before the object disappears completely, the effect is not rendered in the correct position anymore (you can see this easily in the renderings above.
Sad part about this is, that I already submitted a patch for this exact issue last year. But since no one seems to be actively maintaining librsvg this has not even been committed to the source repository yet. --Patrick87 (talk) 11:06, 8 July 2013 (UTC)[reply]

You could try directly contacting any of the committers of librsvg librsvg gitlog. Might spur a bit of activity. —TheDJ (talk • contribs) 12:29, 8 July 2013 (UTC)[reply]

I already posted to the GNOME "desktop-devel-list" (see [27] for the archived discussion) and asked for some hints how to get patches into the code. I was recommended to contact the maintainers who are listed here, but I didn't receive an e-mail response – neither from Hiroyuki Ikezoe nor from Christian Persch. It's an unfortunate situation, especially since it doesn't seem to be much of a priority for the WMF either. --Patrick87 (talk) 12:59, 8 July 2013 (UTC)[reply]

I would just recommend using PNG's. SVG isnt really a good idea for anything like this. Using an SVG with a PNG in it basically combines the disadvantages of both formats. —Soap— 00:40, 9 July 2013 (UTC)[reply]

Seems like you confounded something here... The SVG with PNG contained is actually the version that is rendering "correctly" (although you are completely right that there should never be any raster graphics inside an SVG). The correct SVG without PNG included is rendering wrongly due to the librsvg bug. A pre-rendered PNG is surely a workaround but not a real solution (free scalability is what SVG is all about in the end). --Patrick87 (talk) 00:51, 9 July 2013 (UTC)[reply]

Pool queue is full

I previously reported the error "Pool queue is full" occurring when searching. The problem did seem to go away for about 10 days but I received the same error when attempting a search a few minutes ago. User:Greg_(WMF) requested notification if it occurred again. Nurg (talk) 07:54, 8 July 2013 (UTC)[reply]

Problems with links to other languages

Why are there two articles on the English Wikipedia, satin and sateen, linking to the Swedish article satin? Why can I edit the language links for the English satin article but not for the sateen article? When in the Swedish satin article, one will end up on the sateen article when clicking the English-link under Languages ("På andra språk"), but when trying to edit the links, it seems like it is the satin article that is the corresponding English article and not sateen. —Kri (talk) 09:05, 8 July 2013 (UTC)[reply]

The source of Sateen contains [[sv:Satin]] and sv:Satin contains [[en:Sateen]], so they are linked directly without being connected in Wikidata. PrimeHunter (talk) 12:41, 8 July 2013 (UTC)[reply]

Need to crosslink one-to-many articles: The underlying problem is the need to link an article, in one language, as a one-to-many link selecting a set of articles in another language, and vice versa. Because disambig pages have been limited to almost indentical titles, the one-to-many crosslink pages are based on "related concepts" rather than "related spellings" and so an English article about "Stream" could link to a German crosslink page listing several related terms, such as: Fluss, Flysschen, Strom, Bach (or whatever article titles), and then each article would back-link to a crosslink page, so German "Fluss" would link to a page listing: Brook, Creek, Stream, Canal, Channel, or River (etc.), perhaps with explanations that a creek is typically much smaller than a river, and "Flysschen" might be emphasized as the best match to describe a creek. A similar approach could be used to crosslink Satin and Sateen, along with related terms. Currently, many other-language wikis are cross-connected to disambig pages but that has biased the connections to articles with similar titles, rather than to various articles about the same general concepts with the see-also links to related concepts, rather than related spellings. -Wikid77 (talk) 17:41, 8 July 2013 (UTC)[reply]

Satin is a warp-faced weave; sateen is weft faced. Other than that, they're essentially the same cloth. An eight-end satin will use eight heald shafts, seven of which are raised while the other one is lowered; an eight-end sateen will also use eight heald shafts, but only one of them is raised while the other seven are lowered. Both raise and lower in a 1-4-7-2-5-8-3-6 sequence. Some looms will partially (or wholly) lower all the heald shafts for the beat-up phase of the cycle, even if some of them need to be raised again for the next pick, so one of these looms, when weaving a warp-faced cloth, will use more power than the same loom weaving a weft-faced cloth. Many weavers, when requested to weave satin, will actually weave sateen and then simply turn the cloth over. Therefore, it's natural to put both weaves on the same article. --Redrose64 (talk) 20:31, 8 July 2013 (UTC)[reply]

Linked Satin pages to each other: Since the Swedish word for "satin" is also "satin" (as is German "Satin"), I simply connected the Swedish page to the English "Satin" article, until the Swedish WP gets an article named "Sateen". -Wikid77 (talk) 05:23, 9 July 2013 (UTC)[reply]

Toggling on/off visibility of reverted edits in article history

I've thought about this issue for awhile after seeing how many articles have histories that are mostly vandalism and the reversions of vandalism. This makes it very time-consuming and difficult to sift through when you're looking for constructive contributions to see how a higher-traffic article has developed, or even just to look for unreverted vandalism.

The default of course would be for all edits to be visible. A link would then say "hide reverted or undone edits", and clicking it would hide edits that have left no net change in the article's text (at least those expressly marked as reverted or undone and the edits that reverted/undid them). This could function just like the current option of selecting how many edits to view on the screen at a time: it would only affect that reader's current view of the article's history, and would not be permanent as the full view would be restored for that reader when they reload the history page.

So is this feasible? Any other concerns or questions? postdlf (talk) 16:57, 8 July 2013 (UTC)[reply]

Technically, I'd hazard a guess that it is. Hiding revisions like that is theoretically doable (though very annoying to do in practice) by deleting the entire page and then selectively restoring only the worthwhile edits. But is that something we want? Writ Keeper ⚇♔ 17:01, 8 July 2013 (UTC)[reply]

No, I'm not talking about deletions at all. Read my second paragraph as how I think it would best work, such that it is entirely reader-enabled and completely temporary even for that reader. postdlf (talk) 17:08, 8 July 2013 (UTC)[reply]

(edit conflict) Somewhat related: bugzilla:16619, bugzilla:11664. Do you want to do this server-side or via JS? It certainly is possible, but may be inefficient. πr² (t • c) 17:04, 8 July 2013 (UTC)[reply]

@Postdlf: Did you read the comments at previous discussions, e.g. Wikipedia:Village_pump_(proposals)/Archive_F#An_option_in_preferences_to_hide_reverted_edits.? πr² (t • c) 17:16, 8 July 2013 (UTC)[reply]

I hadn't seen that particular thread. I had started one at a VP page probably a couple years ago, but I think I was proposing the hiding being actually part of the page history rather than just a reader-controlled, impermanent filter, like when you just want to see your Wikipedia-space edits in your contribution history, for example. I think the comments at your VP-proposals thread also assumed that the hiding would actually affect the edit history itself, such that one editor "hides" an edit and it is then hidden for everyone. That would be the wrong way to do it. postdlf (talk) 17:23, 8 July 2013 (UTC)[reply]

This one of those features that would be very expensive to do correctly and would leave a false sense of security if done poorly. I find a lot of people leave the "undoing ..." edit summary intact when they start out by reverting the editor and add something (a common case is if I revert an edit as unsourced. I frequently see an "undo" applied and a source added simultaneously). I also frequently revert edits without using the undo button, simply by opening the last good version and saving it with an edit summary explaining why. To handle those cases would require that the tool actually examined each diff in the history. This would make sense as a special tool, but not for the default history view.—Kww(talk) 17:04, 8 July 2013 (UTC)[reply]

Yeah, I've thought about that issue when "undo" edits being more than just a straight "undo". How difficult is it though to have the software identify and match up only [change][-change] edits, regardless of how labelled? So if someone adds "poop" to an article, someone else removes it, both would be selectively hidden; if someone adds "poop" to an article, someone else removes it and corrects the spelling of another word, then neither would be captured by this. One way would be just to limit it to uses of the revert tool, which would capture a good portion of the useless edits. postdlf (talk) 17:08, 8 July 2013 (UTC)[reply]

Postdlf, how would you expect such a thing to work if there were useful edits in between the vandalism and reversion? I can see it easily working for all of the back to back edit/reverts or the ones that have the revision they are reverting in the edit summary, but what of the others? This would seem to make it a little more tricky to code with a JavaScript userscript. I would doubt this would be considered useful enough for it to be coded into mediawiki itself or even as an extension... Just my thoughts and a question... Technical 13 (talk) 17:24, 8 July 2013 (UTC)[reply]

Limiting it to just uses of the revert tool would avoid that problem entirely as you can only use revert on the most recent edits by a single user. However, even if it also applied to undo, undoing an edit identifies which edit is being undone, and then it's just a question of excluding undos that also make other changes at the same time. Given that the revert and undo tools are able to select out what text an edit changed, and then undo just that change, it should be possible to identify when that has happened, both in the original edit and the edit that reverts/undoes it.

Judging from the bugzilla links posted by PirSquared17 above, many editors would like to be able to selectively ignore the clutter in an article's edit history to make it easier to find edits that actually made lasting changes. postdlf (talk) 17:32, 8 July 2013 (UTC)[reply]

(edit conflict) The others don't matter. Just hiding back-to-back vandalism/reverts would be enormously helpful on its own; more complex stuff is rare and doesn't necessarily need to be hidden. --N Y Kevin 17:35, 8 July 2013 (UTC)[reply]

Agree - I'd love to see this, especially for reviewing recent traffic to a very busy page. Andrew Gray (talk) 23:32, 8 July 2013 (UTC)[reply]

I may work on this as a hobby project, because the right answer would be a lot of fun to see. What you need to do is represent the article history as a graph, and, for every pair of identical versions in the history, identify the paths that would take you between them. You could even work the sub-problem of individual paragraphs or sentences with virtually the same code.—Kww(talk) 18:38, 8 July 2013 (UTC)[reply]

google-src-text notranslate

Johnmperry (talk · contribs) has drawn my attention to two edits (one, two) adding vast amounts of HTML tags mentioning, among other things, "google-src-text notranslate". Does anyone recognise this? -- John of Reading (talk) 18:20, 8 July 2013 (UTC)[reply]

It's a cut-and-paste of applying Google Translate to wikitext.—Kww(talk) 19:08, 8 July 2013 (UTC)[reply]

Tech news: 2013-28

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

VisualEditor news:
- VisualEditor deployment has been delayed by a week. It is now planned to enable the editor for logged–in editors on chosen Wikipedias on July 22, and on all Wikipedias on July 29.
- A bug that made it impossible to save VisualEditor edits that triggered a CAPTCHA has been fixed. [28]
- Several bugs that occurred on right–to–left wikis have been fixed last week (bug #49416, bug #49613, bug #50543).
Uploading files has been restricted on Meta Wiki to administrators and the newly created uploader group. An exemption doctrine policy is being developed (bug #50287). [29]
Emergency priority CentralNotice banners will always be shown unless users have hidden them, ignoring cookies set for lower priority banners. [30]

Future software changes

MediaWiki will allow choosing a specific page of a PDF document or a thumbnail of a video file to show up inside the <gallery /> tag (bug #8480). [31]
It will now be possible to create empty MediaWiki: messages, for instance in order to disable them (bug #50124). [32]
The Nearby feature will soon be enabled on Wikivoyage wikis again. [33]
The Notifications extension messages will now include a direct link to diffs on wiki as well as in notification e-mails (bug #48183). [34]
Table of contents will now use the HTML <div /> element instead of <table />, fixing a nine–year–old bug #658. [35]
First mock–ups of a mobile Wikidata application have been published by Pragun Bhutani as part of his Google Summer of Code project. [36]
A discussion on minimum documentation practices in MediaWiki code has been started and awaits comments from the community.

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

18:33, 8 July 2013 (UTC)

detecting visual editor

Is it possible for an edit notice to detect whether the article is being edited with Visual Editor?—Kww(talk) 21:12, 8 July 2013 (UTC)[reply]

Not exactly at present, but we could add styles to the sitewide CSS pages that would allow content displayed in VE to be different from content displayed to readers or source editors. What did you have in mind? Dragons flight (talk) 21:25, 8 July 2013 (UTC)[reply]

It's pretty obvious that WMF is going to continue deploying this thing despite it not being ready. My thought was to be able to add a notice to articles that we know are affected by specific Bugzilla bugs (for example, any template that creates table content displays incorrectly, making VE hard to use on articles that use them) that informs the editor that using the Visual Editor on that particular article is likely to lead to corruption. It would be easy to create a sitewide notice that using VE is likely to lead to article corruption, but I suspect that creating one would be considered a WP:DICK violation. Putting a notice on articles that we actually know are incompatible with VE seems like a reasonable compromise.—Kww(talk) 21:47, 8 July 2013 (UTC)[reply]

If the following were added to Mediawiki:Common.css

.visual-editor-show { display: none; }
.visual-editor-show .ve-ce-branchNode-blockSlug { display: none; }
.ve-ce-surface .visual-editor-show { display: inline; }
.ve-init-mw-viewPageTarget-toolbar-editNotices .visual-editor-show { display: inline; }

Then one could create elements that are visible in the Visual Editor edit window but are not shown to readers by using:

<div class="visual-editor-show"> My hidden content </div>

The hidden content could be anything, but message boxes like {{warning}} might be particularly appropriate, if the goal is to warn people about the limitations of the visual editor on a particular page. Tested in my user space and it seems to work as intended.

Dragons flight (talk) 00:00, 9 July 2013 (UTC)[reply]

That could even be added to a problematic template itself, couldn't it, rather than in every article that included it?—Kww(talk) 00:07, 9 July 2013 (UTC)[reply]

Yes, if you are creating a new template to hold such a warning. Dragons flight (talk) 00:15, 9 July 2013 (UTC)[reply]

I was thinking more along the line of being able to add something to {{singlechart}} or {{nom}} that could display a warning on the articles that use them.—Kww(talk) 00:24, 9 July 2013 (UTC)[reply]

Sure, if you want. Dragons flight (talk) 00:25, 9 July 2013 (UTC)[reply]

As another tip, if you wrap an element in <span class="ve-ce-protectedNode"> ... </span> it appears that VE will refuse to edit it (or even select it) even if it would otherwise think it should. This could be used to protect content if there are cases where we know that edits will create problems. It is a rather hacky solution though as it doesn't give the user any insight into why they can't select the item. Dragons flight (talk) 03:35, 9 July 2013 (UTC)[reply]

PS. You need to change the span to a div if you are including table and templates, etc. Also this protection apparently doesn't work on floated elements. Dragons flight (talk) 14:50, 9 July 2013 (UTC)[reply]

Can people keep a list or something of when they do this ? Because that's gonna be a lot of cleanup in the long run. —TheDJ (talk • contribs) 21:30, 9 July 2013 (UTC)[reply]

Excellent! Let's just do that to every article... ; ) postdlf (talk) 03:39, 9 July 2013 (UTC)[reply]

I've already considered making an "article" template that takes the wikitext for an article as its sole input parameter and outputs it. That way you can edit the whole thing as wikitext inside Visual Editor.—Kww(talk) 06:41, 9 July 2013 (UTC)[reply]

Maybe a brave soul should create an RfC for enabling the Remove VisualEditor gadget by default. PrimeHunter (talk) 11:08, 9 July 2013 (UTC)[reply]

Would be a waste of time. Even if there were a local consensus for that (and I'm not entirely sure there would be), the WMF would just override it. Dragons flight (talk) 14:52, 9 July 2013 (UTC)[reply]

They are not even accepting that there is need for a possibility to correctly disable VE (and there clearly is consent on that) instead of only hackily hiding it with a gadget that is prone to break often with a name that could be considered misleading. They will surely not disable anything by default. --Patrick87 (talk) 15:29, 9 July 2013 (UTC)[reply]

Notification Bug

Tracked in Phabricator
Task T50568

My little red badge keeps displaying 1 instead of zero despite there being no new notifications. What's going on? I confirmed this on my iPhone as well.—cyberpower ^Chat_{Limited Access} 21:57, 8 July 2013 (UTC)[reply]

Can't replicate on my end...did you try it with another account? Also, do you get a "clear notifications" link at Special:Notifications? Theopolisme (talk) 00:02, 9 July 2013 (UTC)[reply]

(edit conflict) Have you clicked on the "1"? Echo can send notifications other than talk page messages. Other than that, I have no idea, unless the software is simply trying to tell you that "You are #1". :-) Dragons flight (talk) 00:03, 9 July 2013 (UTC)[reply]

I would hope not. That would mean that it is telling the rest of us that we are zeroes.—Kww(talk) 00:09, 9 July 2013 (UTC)[reply]

@C678: There was a similar bug reported a few days ago. I've unarchived that thread, and left a mention of this one, at Wikipedia talk:Notifications#Exasperated. If you could give some additional details, such as browser/OS and how long you've had this problem, and what the most-recent notification-type is, that might help. Thanks. –Quiddity (talk) 00:39, 9 July 2013 (UTC)[reply]

I just noticed the convenient little link that lets me mark all as viewed. There wasn't a new notification though. It just kept saying 1, with no new notifications. It also said viewing 0 of 1 unviewed notifications at the top. I've had this problem since this morning.—cyberpower ^Chat_{Limited Access} 00:59, 9 July 2013 (UTC)[reply]

Sounds like bugzilla:48568 --AKlapper (WMF) (talk) 08:23, 9 July 2013 (UTC)[reply]

Deleted contribs

...appear to have been deleted, per my Adminstats bar? I've lost about 4k... Giant Snowman 10:52, 9 July 2013 (UTC)[reply]

The bot that updates that is now running on Tool Labs rather than the Toolserver. At this time, information about deleted revisions is not available in Tool Labs, although it's on the list of things to somehow be made available at least by special request. Anomie ⚔ 11:44, 9 July 2013 (UTC)[reply]

So they won't be showing here either then? Currently too slow to load for my crappy PC. Giant Snowman 13:41, 9 July 2013 (UTC)[reply]

More regarding adminstats at User talk:Cyberpower678#Admin stats - no deleted edits. If you use X!'s Edit Counter through the old http://toolserver.org/~tparis/pcount/index.php link it will continue to show deleted edits (at least, until Toolserver finally gets pulled), but if you use the new link http://tools.wmflabs.org/xtools/pcount/index.php it won't show deleted edits (at least, for now). --Redrose64 (talk) 14:32, 9 July 2013 (UTC)[reply]

New Single User Login system, login success page going away

This info will go out with the latest edition of Tech News, but I wanted to drop a special notice that platform engineering is deploying a revamped version of the unified login system. The current goal is to deploy this Thursday, July 11th, barring any last minute hiccups. This will vastly improve the long term stability and security of our cross-wiki authentication system, in addition to heading off impending breakage when the next version of Firefox is released. Among other things, the most visible change will be that you will no longer see a special "Login successful" landing page, and instead you will be automatically redirected back to where you were before login (if the system doesn't know where you were, you'll just go to the Main Page). There is more detail in this mailing list announcement. Thanks, Steven Walling (WMF) • talk 22:48, 9 July 2013‎ (UTC)[reply]

Thanks for the heads up, Steven. 64.40.54.109 (talk) 03:58, 10 July 2013 (UTC)[reply]

Hi all. Due to us wanting to iron out some last minute things with the experience (especially regarding the GettingStarted extension) we're going to delay the rollout until Monday July 15th (this coming Monday). We really want to make everyone's first experience with the new login go smoothly, so we think the delay is worth it. Thanks for your understanding! Greg (WMF) (talk) 16:32, 10 July 2013 (UTC)[reply]

Thanks for the update. And we like hesitations/delays in roll-outs! ;) Slow and steady wins the race. –Quiddity (talk) 22:24, 10 July 2013 (UTC)[reply]

VE "save" vs "finish edit" button

Tracked in Phabricator
Task T44138

Hi. I rather enjoyed User:Dragons flight's slight change to the interface of VE. User:Steven Walling recently reverted, saying that there should be a discussion about this. This is the discussion. Please comment. Killiondude (talk) 23:10, 9 July 2013 (UTC)[reply]

Note that the MediaWiki page changed the wording of the first green button one uses to reach the edit summary dialog, not the actual button you click to save the page. Killiondude (talk) 23:11, 9 July 2013 (UTC)[reply]

I don't have a very strong opinion about the new copy itself, except to note that while the new version was more accurate, I think it should probably be discussed before we change it for everyone. Ideally, it should be changed in VisualEditor proper, not just locally here on English Wikipedia. For new people especially, "Finish editing" is likely to make more sense, but on the other hand it was extremely jarring to see it change, and I'm sure I'm not the only who was wondering why/when it was done. If we do change it, there is a ton of help documentation, extensions, and other things that tell editors to finish by clicking "save page", so there will be lots of updates to take care of beyond just the MediaWiki namespace change. Steven Walling • talk 23:15, 9 July 2013 (UTC)[reply]

(edit conflict) The most recent related discussion is here, one of several threads that have complained that the label "Save page" is confusing on a button that doesn't actually save the page. The change was also reported to bugzilla (bugzilla:42138). Oh, and you might be interested that Eloquence (talk · contribs) thanked me for the edit. Not every interface edit needs to be pre-approved by the WMF. That said, if you have a better idea for what the button should say then I'm happy to discuss it. Dragons flight (talk) 23:26, 9 July 2013 (UTC)[reply]

I'm confused. You say it is "more accurate" but you still reverted because "it should... be discussed before we change it". This is the essence of bureaucracy.
I agree that it should be changed in VisualEditor proper, but why leave it less accurate in the meantime? How is something that's more accurate "jarring"? I'm perplexed all the way around, Steven. Killiondude (talk) 23:22, 9 July 2013 (UTC)[reply]

Accuracy != usability. I could change the login button to "Send account credentials you have entered to the server for verification against the credentials stored in the user table" and that would be more accurate but far less usable. Just as important: most people are used to looking for 'Save page', and it's kind of a big deal to change it, in my opinion. If we're going to make a local decision to change it rather than ask the VisualEditor team to change it, then I think there should be a consensus, even a modicum of one. More practically: I think "Finish editing" is more natural than "Finish edit", which sounds somewhat robotic. Steven Walling • talk 23:32, 9 July 2013 (UTC)[reply]

Thank you for your reply. That makes a bit more sense. (Also, James' reply below also gives some perspective). I don't mind "Finish editing" but I don't really see a difference between that and "Finish edit". My goal is to get it to say (nearly) anything other than "Save" since that is not what it does. That having been said, I think the use of the word "jarring" in this thread is a bit hyperbolic. Killiondude (talk) 23:38, 9 July 2013 (UTC)[reply]

The proposal being discussed was changing it from "Save edit" to "Save edit…" (the ellipsis being commonly used in desktop software to imply that there are steps to come before saving occurs). However, this isn't used normally on the Web; it feels a bit jarring online, even in application-like Web interfaces like VisualEditor's, so might feel a bit incoherent and strange. "Finish edit" feels very wrong to me (pressing the button doesn't "finish" your edit; it's a reversible step, which "finish" implies otherwise). "Continue" is obvious once you know what it's trying to get to, but I don't think it's remotely discoverable. We could revert to "Review and Save", though we switched away from that language once we removed the requirement for every user to view the wikitext diff before saving. It would be nice to actually discuss wording rather than just edit-war on wiki. :-) What are people's thoughts? Jdforrester (WMF) (talk) 23:25, 9 July 2013 (UTC)[reply]
I like "Save edit...". I agree it's not common on the web, but it certainly is in desktop environments. If there is an alternative pattern that's common on the web for this, I would probably support that. Superm401 - Talk 00:18, 10 July 2013 (UTC)[reply]
I don't think "Finish edit" was a good choice. "Save page" is what one wants to do and "Save page" is what the button was always called in the WikiEditor. If you want to change it all "Save edit" might be an appropriate choice.

Any way I strongly recommend not to remove the word "Save" from the label. "Saving" is a fundamental thing almost every software on every OS supports. "Finishing" is totally unknown and not intuitive.

On side note: I'd rather vote for changing the "Cancel" button to "Discard changes". --Patrick87 (talk) 23:34, 9 July 2013 (UTC)[reply]

The button we are talking about doesn't actually save anything. It opens a dialogue that allows people to write an edit summary, generate a diff of their changes, or ultimately push another button to save the page. Multiple people have complained that labeling a button as "save page" is confusing when it doesn't actually save anything. Doubly so for people who are trying to figure out where to add an edit summary. As others have said, just about anything other than "save" would be better. Dragons flight (talk) 23:52, 9 July 2013 (UTC)[reply]

Doesn't sound like contradiction to me. If I choose "save" in any desktop application most of the time a window pops up where I have to choose the file the content should be saved to. Still the button is titled "Save" or "Save as", not "Finish Document" or "Choose file" or anything similar confusing. It is called "save", since that's what I want to do and whats commonly recognized.

If your point is that one has to click "save page" two times currently (once to bring up the edit summary dialog and a second time to really save the changes) then just rename the second button to "Submit changes", "Confirm" or just "OK". But I'm sure especially newbies (and those are the users VE is made for after all) will not undersatand a button labeled "Finish". It's just uncommon and unintuitive. --Patrick87 (talk) 00:29, 10 July 2013 (UTC)[reply]

To add some additional perspective, at least a couple people have complained on VEF that having the same "Save page" label in VE as in the classic editor is jarring for experienced editors. People have had it drummed into their heads for years to make sure you've double-checked everything, entered an edit summary, etc. before clicking "Save page" in the classic editor, as clicking that finishes the edit session and sends everything off to the servers. But in VE it's impossible to enter an edit summary until you click the "Save page" button. --108.38.191.162 (talk) 00:08, 10 July 2013 (UTC)[reply]
The change was made, it met with several comments of approval and none of disapproval - a pro forma reversion like this doesn't appear to actually achieve anything that anyone at all actually wants. Steven, please reverse yourself - David Gerard (talk) 00:21, 10 July 2013 (UTC)[reply]
- Read my replies to Killion. It's not just for the sake of formality. Steven Walling • talk 00:32, 10 July 2013 (UTC)[reply]
Killiondude for steward! --MZMcBride (talk) 00:23, 10 July 2013 (UTC)[reply]

Huh - don't really see that the revert was necessary; we can iterate a bit on these things. But agree that we'll want to solve this in the software itself rather than by means of a local override. Like I said when Dragons flight made the edit and as another couple of users have pointed out, "Finish edit" feels a bit unnatural, but still an improvement over the straightforward "Save" which is a bit confusing since an additional step is required to actually complete the edit. "Review and save" would work for me as well, even if the review step is no longer mandatory.--Eloquence * 00:33, 10 July 2013 (UTC)[reply]
I urge you all to read John Broughton's comment at WP:VisualEditor/Feedback#edit summary. John is an experienced documentation writer so his perspective carries a lot of weight (for me at least). — This, that and the other (talk) 01:07, 10 July 2013 (UTC)[reply]

Since this seems the best place to consolidate the discussion, I'll repeat what I said elsewhere (with a copyedit):

The button labeled "Save page" has the same label as the button, in the old editing interface, that completed the edit session. Lots of effort has been made, over the years, to encourage editors to write an edit summary (and do a preview) before they click "Save page", and now VE has a button with the same label where it's not possible to do a preview or write the edit summary until after clicking the button. The button ought to be labeled "Finish edit" or "Continue" or "Final steps" or just about anything other than "Save page".

The current problem is even worse than just one poorly-labeled button. In VE, after clicking "Save page", a dialog box appears that also has a "Save page" button. So now an editor has to understand that the two "Save page" buttons do not do the same thing. And documentation (when it's written) is going to have to clarify which "Save page" button is being referred to - unless the label on the first occurrence of "Save page" is changed, as it should be.

I don't have any particular attachment to "Finish edit" (in fact, I think "Finish editing" is superior). What I hope everyone can agree is that from a user experience viewpoint, having a new button with the same name but different behavior than an old button is problematical; having two new buttons with the same name that do two different things is simply wrong.

So, where do we go from here? VE is in beta; that means things are going to change. And if only (or mostly) new editors are going to use VE (something I very much hope is wrong, eventually), then there is very little learning to be unlearned. In short, I think we should improve the user interface, by changing the label on the button, and I don't think we should concern ourselves with what WMF thinks, since other language Wikipedias are not going to use the English label anyway. I also note that VE is not being used for anything but articlespace and userspace pages, so that even editors committed to VE are seeing "Save page" in the older wikitext interface when editing other pages - so it would be really good if it did the same thing in both interfaces.

It seems to me that greatest consensus here is that "Save page ... " is better than "Save page", albeit not perfect. I suggest that we go with that, for the moment, and that we then either (a) continue the conversation here to see if we can get consensus on something even better, or (b) someone starts an RfC on the issue. What I would hate to see is the classic "The perfect is the enemy of the good", where we discuss ad infinitum all the permutations of possible labels, while in the meantime something that is clearly wrong (a "Save page" button that does not save the page) remains to confuse editors trying out VE. -- John Broughton (♫♫) 03:10, 10 July 2013 (UTC)[reply]

I'm behind you 100%. Something needs to be done now. Chris the speller ^yack 04:26, 10 July 2013 (UTC)[reply]

Something does not need to be "now". This is the interface thousands of people are and will use for a long time. Taking time to deliberate and choose the best option is important. @John Broughton: regarding "I don't think we should concern ourselves with what WMF thinks, since other language Wikipedias are not going to use the English label anyway" -- you couldn't be more wrong. First off, doing something only locally here means that all English wikis will have a save button inconsistent with English Wikipedia. Every day, many new editors try out Commons and other projects, after editing here. Do we want to confuse them with inconsistent interface copy for the same editor? Also, the English text is what is used as the basis for translation for all other languages (they don't make up a version from scratch unless they too override it locally). If we really think that two 'save page' options is bad, the right thing to do is to change it properly in VE, especially before it goes out live as the default to other languages. If the change is needed here, it's certainly needed elsewhere too. Steven Walling • talk 04:51, 10 July 2013 (UTC)[reply]

This reminds me of what Ross Perot (not my hero, but he has something here) used to say, that when you see a rattlesnake, you kill it; don't appoint a committee on rattlesnakes to study the problem. Chris the speller ^yack 15:01, 11 July 2013 (UTC)[reply]

@Steven Walling: When you say "change it properly in VE", what exactly do you mean? There is no process, other than through a bug report, already done, to change something in VE. Or to provide feedback to the VE team, already done. Obviously, given the hundreds of more serious bugs, the VE team isn't going to get to this issue for weeks, or probably months. And they haven't responded to the feedback (other than to agree that "Save page" isn't the right label). I'm happy to participate in a process that will result, in a relatively short time, in something positive happening here, but I'm not seeing anything you said as leading to that. Are you suggesting that we just wait, and wait, and wait, for something good to happen? -- John Broughton (♫♫) 16:31, 10 July 2013 (UTC)[reply]

I mean changing it in the code. This is just a copy change -- it doesn't involve more than 15 minutes work after we make a decision. It's not going to take VE team weeks to fix it. Steven Walling • talk 17:21, 10 July 2013 (UTC)[reply]

Even if implementation is fast, it will presumably take more than 15 minutes to make a decision. After all this issue was flagged in bugzilla for months without any decision being reached. Given the number of outstanding bugs and missing features, I wouldn't necessarily want the VE team to be spending even 15 minutes worrying about what to call the buttons right now. I would suggest that the volunteer community can help by thinking through many of these issues, forming consensus, and implementing changes. The VE team is then free to review our discussions and copy them if they agree with our logic. I agree that having changes implemented within VE itself is ideal, but taking up developer time to think through these issues isn't necessarily the best use of their time. Dragons flight (talk) 17:43, 10 July 2013 (UTC)[reply]

Relabel 1st "Save page" button as "Submit/Review": The button label should try to summarize its function, so I recommend re-labelling the 1st Save button as "Submit/Review" where the slash punctuation is commonly interpreted as meaning "either/or" unless there are cultural problems with the meaning of the slash. Overall, I definitely object to leaving both buttons as "Save page" (as too confusing with identical labels while different functions), and I already think that, for template-editing, the preview of another page should have button "Run preview" rather than both buttons in the wikitext editor labelled as "Show preview". So, for people who think we are nitpicking just the VisualEditor buttons, remind them to consider button label "Run preview" in the wikitext editor for templates. -Wikid77 (talk) 04:54, 10 July 2013 (UTC)[reply]

"Save page" is a bad label for the button. It says nothing about 2 next steps coming - the crucial edit summary and then the actual "save." The button should make it clear that there is a next step. The button should say "Write edit summary", or better, just "Next" as almost every webpage in an online multistep process, communicates to users. VE needs to lead users through the process. Jytdog (talk) 12:22, 10 July 2013 (UTC)[reply]

So, to recap proposed options at this stage, with my totally-POV thoughts on each one:
Save page

(Current text) A little confusing to have the same label twice (though they're in different contexts), but very clear as to purpose; doesn't set the user up to expect another step enough.

Save page…

Still clear, though I'm not sure that the ellipsis will make obvious to users that there's a next step.

Save edit

Perhaps a little clearer than "page" (?), but still the issue with not being clear about there being a next step.

Save edit…

As with "Save page…".

Finish edit

Pressing the button doesn't "finish" your edit; it's a reversible step, which "finish" implies otherwise.

Finish editing

Same problem as "Finish edit", but add the active present tense to the interface for the first time, confusingly.

Final steps

Umm. Are they? Worse than "Finish edit", because they're still not irreversible, and "steps" is confusing and unused elsewhere.

Continue

Continue what? Browsing? Editing? Changing? I don't think this gives context or sets expectations. Also fails entirely to tell people there's another step.

Next

Same problem as "Continue", though slightly better at suggesting there's another step or more to go.

Review and Save

You no longer have to review before you save, so this is an optional step, but I think it's a good option.

Review and Publish

Underline for users that when they press the next button, it's public for everyone forever; slight preference for this option over Review and Save.

Submit/Review

You're not actually submitting, you're publishing straight away (except if Flagged Revisions is switched on… let's not open that can of worms). Feels confusing, especially with the slash - which one is it?

Review and Submit

Same issue with "submitting" language in the above, but less confusing (though no less wrong).
What do we think? Which one do we like most (or, perhaps, dislike least)? Jdforrester (WMF) (talk) 03:37, 11 July 2013 (UTC)[reply]

The current text is actually "Save page" not "Save edit". Dragons flight (talk) 03:48, 11 July 2013 (UTC)[reply]

Argh, yes, sorry; updated. Jdforrester (WMF) (talk) 03:56, 11 July 2013 (UTC)[reply]

My opinion is summarized below:

Save page - This button doesn't save. It is confusing for people trained to look for editor summaries / diffs before saving, and it also makes documentation hard because two different buttons in the same UI would have the same label. Altogether I consider this the worst option.

Save page... - Adding an ellipsis does not redeem a bad label.

Save edit, Save edit... - Only slightly better than "Save page", still not worth considering in my opinion.

Finish editing - Personally, I like this. For me, "finish editing" actually suggests something like "now, perform the final steps" and is considerably less final and more reversible than "save page". However, it seems that not everyone reads it the same way (I wonder if this is a regional English difference?). I think "Finish editing" is better than "Finish edit".

Final steps - Much better than "Save page" but somewhat worse than "Finish editing".

Continue, Next - I think these are lacking because there is no sense what you are "continuing" towards (the next page?). Though, I would still would prefer them over "Save page".

Review and Save - This may be the best option. It does convey that there is more to do while also being almost done. I might actually prefer Review and Finish, as reserving "Save" only for the button that actually saves seems desirable.

Review and Publish - This is not bad, but given the existence of Flagged Revs (where not all saves are immediately pushed to the public), it is probably not the best language for a Mediawiki-wide default. "Save" or "Finish" seems better than "Publish".

Review and Submit, Submit / Review - Again, not bad, but I consider the previous options to be better. "Submit" tends to suggest a more private submission than is typical of wiki behavior. If we wanted to use a shortening symbol, replacing "and" with "&" would seem a more natural simplification than using "/".

Dragons flight (talk) 04:34, 11 July 2013 (UTC)[reply]

I like Finish editing the best out of all of these. Alternatively, someone proposed Next... above and I like that idea. Killiondude (talk) 06:17, 11 July 2013 (UTC)[reply]

I think "finish editing" makes sense. It's clear, plain language. I can also confirm this with a quick set of usability tests, if we want. Steven Walling • talk 20:32, 11 July 2013 (UTC)[reply]

Although it might be the preferred label of some of you: Don't use anything with "finish" in it. One does not know what to expect. I never read "finish" in any software and it is for a reason. Maybe also from the perspective of someone whose native language is not English: "finish" is hard to understand and not easily recognized as something one would know from other places.

I still prefer keeping the first button "Save page" or something similar. "Saving" is something that every user knows from essentially every software and one doesn't await it to directly submit the information to the server. In this case just change the label of the second button to e.g. submit and the ambiguity would be resolved. The whole thing is perferctly reasonable applying common sense: I want to save my edit (therefore clicking "save"), I then review my changes and enter an edit summary, then I "submit" my information to the server.

Note what I wrote above: The user wants to save the edit (that's the basic workflow), therefore he's searching a button labeled "save". The user isn't searching for a button that allows him to enter an edit summary because he knows, that's the step before actually saving. Buttons should be labeled according to the users workflow and should express what he want's to do. Buttons don't have to exactly say what they are doing.

Therefore let me propose a maybe "dumb" idea: What if we simply rename the button to "OK"! A big red green button labeled "OK" probably can't cause any confusion, especially since we have "Cancel" (which we could color red to perfectly contrast those two) directly next to it. Look at it:

CancelOK Discard ChangesSave Changes

I think this would be perfectly clear to everybody – without the fear of any ambiguities! --Patrick87 (talk) 08:47, 11 July 2013 (UTC)[reply]

Patrick's earlier comment about "Discard changes" made me think that "Save changes..." would probably make sense to most people Whatamidoing (WMF) (talk) 22:02, 11 July 2013 (UTC)[reply]

Yes, I would like that one, too. It's much better than "finish edit". It would also contrast nicely to "Discard Changes" (see buttons above). --Patrick87 (talk) 22:21, 11 July 2013 (UTC)[reply]

Why does the named ref toolbar work intermittently?

It seems like it has been this way for years. I have a normal red-blooded American load (Dell laptop, Windows 7, IE 9 or 10).TCO (talk) 02:42, 10 July 2013 (UTC)[reply]

Random toolbar functions have been linked to slow timeouts: It might sound nutty, but others have noted that when response time gets too slow, then the structure of the displayed page can change, and omit some buttons while showing other faster options. In such cases, perhaps just refresh the browser screen, and the page might redisplay faster with all the buttons connected properly next time. The days are long gone when expensive computers were reliable and quick, with every transaction running within 7 seconds, with the same results every time. Think of today's computers as "compu-mush" or "compu-sewage" run by "crapware" where the worst are compu-trash. That is the reason many intelligent people seem to be inept at developing quality software; they are still quite smart but are facing the old "garbage in, garbage out" (GIGO) problems, where the whole computer system is the garbage now. -Wikid77 (talk) 05:31, 10 July 2013 (UTC)[reply]

I'll try the refresh. I hate computers... TCO (talk) 11:25, 10 July 2013 (UTC)[reply]

JavaScript changing font family?

I haven't edited seriously for a couple months and now after coming back I discovered that in templates where we had serif fonts, the font appears briefly and then turns into a sans-serif font after ~half a second. You can see an example at {{Script/Hebrew}} (refresh the page to see the serif font briefly appearing on the {{{1}}}). The font issue is important in this template (its raison d'être), and I'm trying really hard to find it but can't find where or why this is being done. Can anyone please help? Thanks, Ynhockey ^(Talk) 10:47, 10 July 2013 (UTC)[reply]

I can't reproduce this problem right now, but I assume that this is caused by mw:Universal Language Selector, a< new extension which was enabled recently (see the gear right to "Languages" on the left) which changes the font used from the system font to a webfont for some languages. --Patrick87 (talk) 11:15, 10 July 2013 (UTC)[reply]

Thanks, that appears to have been the cause. —Ynhockey ^(Talk) 13:57, 10 July 2013 (UTC)[reply]

Removing the animation from "edit source" section links on Visual Editor

For people choosing to keep VisualEditor enabled, adding the following to your personal CSS page will disable the section link animation so that both the "edit" and "edit source" links are permanently visible.

.mw-editsection-link-secondary { visibility: visible !important; }
.mw-editsection-divider { visibility: visible !important; }
.mw-editsection-bracket { visibility: hidden !important; }

It has the side effect that the bounding brackets, i.e. [ ], no longer appear around the links on pages editable with the Visual Editor, but personally, I regard that as an acceptable loss in order to remove the annoying animation. If someone else can figure out how to keep the brackets, then that might be even better. Dragons flight (talk) 18:19, 10 July 2013 (UTC)[reply]

You can use the adjacent sibling selector, something like .mw-editsection-link-primary + .mw-editsection-bracket, .mw-editsection-divider + .mw-editsection-bracket, to target just the (weirdly multiple) interior brackets. Anomie ⚔ 22:46, 10 July 2013 (UTC)[reply]

For the records, the related bug report for this request is bugzilla:50540. --AKlapper (WMF) (talk) 10:37, 11 July 2013 (UTC)[reply]

I've tried the CSS which is nice but it seems to mess up for section 0. Just to the right of the title I'm getting edit |edit source the first link takes me to source editing of section 0, the second links is to source editing of section 1!--Salix (talk): 12:50, 11 July 2013 (UTC)[reply]

Please paste both links, in full, to this section so that I can see what you're being given. --Redrose64 (talk) 12:57, 11 July 2013 (UTC)[reply]

First is http://en.wikipedia.org/wiki/Japan%E2%80%93South_Korea_relations?action=edit&section=0 second is http://en.wikipedia.org/w/index.php?title=Japan%E2%80%93South_Korea_relations&action=edit&section=1 .--Salix (talk): 13:45, 11 July 2013 (UTC)[reply]

Hmmm, the first one appears to be http://en.wikipedia.org/wiki/Japan%E2%80%93South_Korea_relations?veaction=edit&vesection=1 after processing by MediaWiki:Gadget-edittop.js; the second (which has a different position for the query ? besides a different section number) seems not to have been processed by edittop. At Preferences → Gadgets, what are your settings for:

Remove VisualEditor from the user interface
Add an [edit] link for the lead section of a page
Move section [edit] links to the right side of the screen

I have seen something like this before; yesterday I was getting two edit links for the lead section of Leg before wicket, which was TFA at the time (unfortunately I didn't note them), but today, I have only one - the one processed by edittop; and I also have only one at Japan–South Korea relations (the same one). --Redrose64 (talk) 14:11, 11 July 2013 (UTC)[reply]

Remove VisualEditor from the user interface off
Add an [edit] link for the lead section of a page on
Move section [edit] links to the right side of the screen off

I first spotted it with right edit on, but switched it off to see if that cured the problem, it didn't.--Salix (talk): 14:21, 11 July 2013 (UTC)[reply]

Ah, these are the same settings as mine. At this stage, I don't know where the second link is coming from, so would welcome input from others. --Redrose64 (talk) 14:54, 11 July 2013 (UTC)[reply]

The Wikipedia Adventure, Help Wanted: an automatic edit button script

Background

The Wikipedia Adventure (TWA) is an onboarding game--a guided tour to teach new editors how to contribute to Wikipedia. In the game players are invited to help out at a hypothetical article (Earth), and along the way they learn skills while interacting with simulated peers.

Goal

Make TWA players feel like they are actually receiving messages from other editors, when in fact they are just sending messages to themselves.

Method

Use the Mediawiki Edit API. Have a button (or a link) on a Wikipedia subpage of Wikipedia:TWA/ use the API to add target text to a target page. Because different messages are received at different points in the game, the ability to customize the target text and target page is critical.

Implementation

Build a javascript userscript stored in the user’s common.js page. The beta-version of the game will later deliver this script as a gadget (set in user preferences, turned on by default, and only active from the Wikipedia:TWA/ subspace).

Progress so far

This was inspired by the Teahouse help community, which uses a similar automatic edit button for their ‘ask a question’ form. That form passes typed user input through the API and posts it at the top of the questions page. MediaWiki:Gadget-teahouse/content.js
Writ Keeper coded a base for the TWA edit button. Right now, it triggers a message whenever an editor is in the Wikipedia:TWA/ namespace. It works, but it needs to be triggered by a user clicking a button or a link, not just whenever the user navigates to a new page. User:Ocaasi/TWAcontents.js

Still to-do (help needed!)

Update Writkeeper’s code so that it is triggered by a user clicking a button or a link.
Allow for customization, so that we can send different messages at different points in the game to different target pages.

Useful Pages

Mediawiki API:EDIT: https://www.mediawiki.org/wiki/API:Edit, help page
Mediawiki API: https://en.wikipedia.org/w/api.php, API
Parsed page example: https://en.wikipedia.org/w/api.php?action=parse&page=User_talk:Ocaasi&format=jsonfm

Can you help realize a neat project? I'd love to have you join the team working on this...

Barnstars and Bounties: To help make this happen in July, I am offering special... rewards.

Please ping me if you're interested. Cheers, Ocaasi^{t | c} 21:47, 10 July 2013 (UTC)[reply]

Mention "Remove VisualEditor" under Editing preferences

Many editors looked under the Editing tab in preferences to disable VisualEditor. It was there earlier but now we only have the gadget "Remove VisualEditor from the user interface". As far as I know we cannot make an option under Editing without the developers, but we can mention the gadget in an interface message. Looking at the message locations in [37], I suggest changing MediaWiki:Prefs-beta from "Usability features" to "Usability features (Remove VisualEditor is under Gadgets)". PrimeHunter (talk) 22:27, 10 July 2013 (UTC)[reply]

And even better conceal what an ugly hack we have to use because WMF devs don't care about community consensus? This should finally be fixed!

Why shall we put further and further effort into a local workaround on English Wikipedia, with the very limited possibilities we have, prone to break because of errors on every update, being only able to patch it only provisional? If the WMF devs finally insert the much requested turn-off switch this problem will be solved quickly and correctly and on all Wikis at once! --Patrick87 (talk) 22:55, 10 July 2013 (UTC)[reply]

Changed the label MediaWiki:Prefs-beta —TheDJ (talk • contribs) 08:51, 11 July 2013 (UTC)[reply]

Sorry, but to be honest, this is bullshit! Now we already start to rename headings in the preferences dialog to point to user created Gadgets, because we know we need a pref and know where it should be located but don't get it by WMF? How ridiculous is this? --Patrick87 (talk) 09:05, 11 July 2013 (UTC)[reply]

This is where we can exercise some immediate control, so it's not like we have many other options. —TheDJ (talk • contribs) 09:24, 11 July 2013 (UTC)[reply]

Do you see the importance that lies in you reply? Don't you think we should have some control on WMF at this point? Shouldn't we have the option to inform WMF of the clear community consensus with the result that it is followed?

I don't know if those guys at WMF are drowning in work right now (after having released a beta-stage software at users) or if they are enjoying the nice weather and I hope they are doing this on purpose. Whatever they do, IMHO they are badly failing their job on this issue. I hope they are aware and will provide a fix soon. --Patrick87 (talk) 09:48, 11 July 2013 (UTC)[reply]

Personally I don't have much time to enjoy the nice weather (plus today central Europe is likely getting rainy), and I know that the Visual Editor team has even less time to enjoy it currently as they spend quite some time and weekends on improving VisualEditor. For general reference, WP:VE/F is likely the best place to give feedback for the VisualEditor (or to check for existing threads requesting the same feature/bugfix) so the developers will definitely see it. Hope that helps. --AKlapper (WMF) (talk) 10:41, 11 July 2013 (UTC)[reply]

I've filed bugzilla:51179 about restoring the user preference to disable VisualEditor. --MZMcBride (talk) 15:36, 11 July 2013 (UTC)[reply]

problem with references: either an unusual (undocumented?) rule, or perhaps a bug

I have run across a minor problem that confounded me until I figured out my blunder. The error message that resulted was not very helpful. I wasn't sure where to write up the problem, and settled on the VP.

Here is a way to demonstrate the problem. Just include a named reference, such as ipsum, improperly coded the way you would code an attempt to invoke a named reference: e.g., <ref name=ipsum/>, but instead of having that code appear within the body of the article itself (where it would be valid), place it in the set of list-defined references. This causes all the valid references to ipsum to fail to be recognized, and furthermore it causes an error to appear within the References section:
Cite error: The named reference ipsum was invoked but never defined (see the help page).
Note that this error occurs whether the particular named reference is defined within the main body of the article or down in the reflist as in my illustration below.

Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.<ref name=ipsum/> Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.<ref name=minim/> Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur.<ref name=duis/> Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.<ref name=excepteur/> Curabitur pretium tincidunt lacus.

== References ==

{{reflist|refs=
<ref name=duis>duis</ref>
<ref name=excepteur>excepteur<ref>
<ref name=ipsum>ipsum</ref>
<ref name=minim>minim</ref>
<ref name=ipsum/>
}}

This is like the "Doctor, it hurts when I do this!" story; the answer would be, "Don't do that!" In other words, the rule I had (accidentally) violated is evidently: Do not attempt to invoke a named reference within a set of list-defined references. Once I figured out what was causing the error to appear when I had edited an article, I originally thought about updating the Help page to explain the "rule". When someone violates the rule, they can be confused because they can see that the named reference is, indeed, defined. It seems like it would be best to just ignore the <ref name=ipsum/> code when it is meaningless, and/or generate a warning message, or a new error message, but allow all the valid references to that item to be processed. I'm hoping someone who knows how references are processed, and in particular how the error messages are generated, will recognize what's triggering the error and can figure out what to do about it. I know we're supposed to "be bold", but I'm out of my element in dealing with a problem like this (obviously). NameIsRon (talk) 22:29, 10 July 2013 (UTC)[reply]

As noted on the help page, this can occur whether the undefined reference is invoked in the content or in the reflist. You can update your CSS per H:SHOWCITEERROR and test this on a user subpage. -- Gadget850^talk 00:49, 11 July 2013 (UTC)[reply]

But in this case, there is no undefined reference. In a sense, you could say there is a "doubly defined" reference, but the second "definition" isn't a definition at all, just an ineffective attempt to invoke the reference. And that ineffective attempt kills the original definition of the reference. NameIsRon (talk) 00:56, 11 July 2013 (UTC)[reply]

You are correct. But only <ref>...</ref> is allowed in the LDR. It appears that Cite gets confused when the singular tag is used in the reflist. This would not be the first spurious error. Need to update the help page. -- Gadget850^talk 02:33, 11 July 2013 (UTC)[reply]

Always-subst templates

Changes have been made to {{Infobox Unternehmen}}, such that it should always be Subst:, and never kept in article-space. Do one or more of the cleanup bots have a facility to watch for and fix transclusions in articles? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:26, 11 July 2013 (UTC)[reply]

Stick it in Category:Wikipedia templates to be automatically substituted, and the AnomieBOT will do it for you. -- John of Reading (talk) 10:34, 11 July 2013 (UTC)[reply]

Note {{substituted|auto=yes}} on the template's doc page will both add the category and show a message about it for other users. Anomie ⚔ 11:30, 11 July 2013 (UTC)[reply]

Thank you, both. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:42, 11 July 2013 (UTC)[reply]

Editing protected pages

After clicking "View source" on a protected page, it is of course impossible to edit the box containing the wikitext. However, the icons above the wikitext (such as B, I, etc. do work. Therefore, if I accidentally click one of these buttons, messing up the wikitext I'm looking at, there is no way to undo my mistake (aside from reloading the page). -- Ypnypn (talk) 19:10, 11 July 2013 (UTC)[reply]

New essay wp:1EDITMYTH

Finally, after years of frustration of people claiming Wikipedia was mainly written by swarms of newcomers, each adding 1 paragraph and "never" returning, I have written an indepth essay wp:1EDITMYTH:

WP:Beware myth of WP written by passing strangers - mythbusters needed

I had tried to imagine, in a twisted world, how total strangers could each contribute valuable facts to an encyclopedia, at one point in time, but never have any curiosity to return, and it just didn't make any sense, in any form. The concept was this "Newbietopia" where incoming strangers add most content to WP then mainly leave (not really), while the rest of us veteran editors simply "change category links" year after year, almost never adding content nor creating new major articles (huh?). Then, I learned, some time ago, how Jimbo formerly gave speeches on "Wikipedia written by handful of people" as perhaps 550 editors because "he talked with them daily" as the articles were expanded. So, I carefully examined the editor-activity stats (for various years), and concluded "Jimbo was right" (again) in the sense that the vast majority of edits are made, each month, by a relative handful of editors (~10%). As noted in the essay wp:1EDITMYTH, the ratio is a "90/10 Rule" where 90% of edits are made by only 10% of editors (much higher than the 80/20 Rule), and the May 2013 editor-activity stats confirm the 90/10 pattern still applies, even years later. Plus, random checks of IP contributions will reveal similar "veteran IP" editors updating numerous articles. Does anyone know how the "strangers-wrote-WP" myth got started, and why all people do not know that 10% of editors make 90% of all edits (2.8 million per month)? The core power-users make more than just the crucial edits which rewrite long sections of text, add templates, match intricate styles and correct source references; no, instead 90% of all edits each month are made by about 10,500 editors who each change over 20-2500 articles per month, not by passing strangers. Here's the deal: technical improvements to WP software and gadgets, for power users (not newcomers), can help them continue to make the 90% of all edits each month. -Wikid77 (talk) 19:27, 11 July 2013 (UTC)[reply]

See this blog post by Aaron Swartz. Graham87 06:52, 12 July 2013 (UTC)[reply]

Changing / blocking a bit of Javascript

I'm not a Javascript expert, by any means, so maybe there is a simple answer to this.

I would like to write a user Javascript function that either blocks or replaces an existing function installed by Wikimedia. Is there a natural way to do that? It is not practical to prevent the Wikimedia function from loading (as it is part of a large package, and I want to keep most of the package intact), but is it possible to surgically override one small piece of their large package? Dragons flight (talk) 19:29, 11 July 2013 (UTC)[reply]

The only possible answer to the question as stated is "maybe". You might be able to override the module in ResourceLoader, you might be able to extend it if it was written with extensibility in mind, you might be able to just undo or hide whatever it does. Or maybe not; it depends on what it is you want to do. Matma Rex talk 19:34, 11 July 2013 (UTC)[reply]

Let's formulate it in "easy" term: Can I disable VE or ULS using JavaScript? Disable, not hide! --Patrick87 (talk) 19:48, 11 July 2013 (UTC)[reply]

VE – possibly, there's an implementation suggestion at MediaWiki talk:Gadget-oldeditor.js which apparently none of the local admins here bothered to test and enable if it works. ULS – not really, because it is entirely loaded in the blocking top queue, before the page even starts rendering. Matma Rex talk 20:34, 11 July 2013 (UTC)[reply]

I want to try changing one small piece of behavior in VisualEditor. Assuming I can find the exact Javascript function in GIT, and write a new function that could replace it without breaking anything else, is there way to install it in my personal JS that would ensure that my function gets called and not the stock function. Dragons flight (talk) 20:04, 11 July 2013 (UTC)[reply]

Most likely yes. VE exports nearly all of itself inside the ve global variable after it is loaded (user clicks "Edit"); you can access the running VE instance (ve.instances[0]) and its various classes (ve.ce, ve.dm etc.). Modifying those things is not really supported, but should work. A documented and supported API for gadget writers is planned for sometime after the current issues are solved AFAIK, but you should ask James about this. Matma Rex talk 20:38, 11 July 2013 (UTC)[reply]

Looks like the off switch is coming. Its a setting in CommonSettings.php so its a local issue.Template:Bug--Salix (talk): 22:09, 11 July 2013 (UTC)[reply]

Image update not appearing

I uploaded a replacement logo at File:Blue cross logo.png but the previous image still shows (although it now has the size of my new image). The original image is the blue cross with the text to the right.

I found this phenomena mentioned many times before, with the answer being purging the page and refreshing the browser. I have tried that a few times, but I still see the old image.

Is it just me that cannot see the new logo? Periglio (talk) 19:39, 11 July 2013 (UTC)[reply]

Thumbnail stuck, perhaps display 1px narrower: The previous problems have been fixed by changing the view to display, in a page, as 1-pixer-~~wider~~ smaller (or ~~taller~~ shorter), until the auto-thumbnailing can re-cache with new image revision. Update: Even smaller custom thumbnails are still showing prior revision. Major, major bug in image display. -Wikid77 (talk) 20:12/20:32, 11 July 2013 (UTC)[reply]

I tried a 127px image on the article page, and it seems to have worked. The image page is still a bit screwy though! Periglio (talk) 21:30, 11 July 2013 (UTC)[reply]

What shall we do about all VE's "nowiki" tags?

Edit filter 550 is being tripped over 30 times an hour. This happens when a VE user inputs wiki markup such as a [[ ]] link, and VE wraps the edit in "nowiki" tags. That is a lot of spurious "nowiki" tags that VE is throwing into the encyclopedia, and a lot of confused users.

I think it is URGENT to implement a warning for users who try to insert Wiki markup with VE, so that they can revert to source edit and clean up the mess (and find out how to add links in VE)
If that is going to take time, how about setting Filter 550 to block such edits in the meantime?
By now there must be thousands of spurious nowikis scattered around. What can be done to clean up? Is there any possibility of a script targetting edits that tripped Filter 550? In most cases, I guess that stripping out the nowikis would achieve what the users intended, but others may already have done that.

JohnCD (talk) 20:25, 11 July 2013 (UTC)[reply]

Various nowiki patterns, some harmless: Numerous editors are afterward using "Edit source" as wikitext editor to remove nowiki-tags. I have noticed the following patterns:

all kinds of spurious nowiki-tags, such as someone adds a blank space: <nowiki> here</nowiki>.
wikilinks chopped with prefix letters: "C[[ommandant General]]"
wikilink literalized by nowiki-tags: <nowiki>[[Page (person)|Page]]</nowiki>
wikilinks with nowiki-tag split as 2 links: "[[Toffee|<nowiki/>]][[toffee]]" to show one link: toffee.
wikilinks with no-wiki brackets: "[[Cricket (insect)|[[Cricket<nowiki>]]</nowiki>s]]" to show: [[Cricket (insect)|[[Cricket]]s]]

Those are from live articles, even today (11 July 2013) many bad nowiki tags. -Wikid77 (talk) 20:46, 11 July 2013 (UTC)[reply]

Support VE edit-warning: Put a system-wide warning how VE edits to wikilinks become garbled. -Wikid77 (talk) 20:46, 11 July 2013 (UTC)[reply]

According to Jdforrester, he doesn't see any corruptions at all any more, this is just the fault of the users... So I won't bet on the fix to happen really soon. Yes, why not make Filter 550 blocking to stop the degradation of thousands of articles. --NicoV ^{(Talk on frwiki)} 20:50, 11 July 2013 (UTC)[reply]

I'd need the make the edit a bit more specific before being comfortable making it actually block, and, on top of that, Visual Editor can't forward the messages from an edit filter block to the user. That's Template:Bugzilla.—Kww(talk) 21:10, 11 July 2013 (UTC)[reply]

Cannot allow Filter to block entire edits, so just count how many nowiki pages are not fixed yet. Current wikisearch for "nowiki the" reports 2,054 pages contain "nowiki" (beware Norwegian wikipedia is "nowiki"); so this is Thursday, and just count how many more (are not fixed) each day. -Wikid77 (talk) 21:13, 11 July 2013 (UTC)[reply]

Edit filter has the ability to warn users about potentially bad edits and require a second push of the save button to confirm that they really want to do that. That seems much more user friendly than blocking the edits. However, I don't think VisualEditor supports that behavior yet. Dragons flight (talk) 21:18, 11 July 2013 (UTC)[reply]

Nope. As I posted on one of the many VisualEditor bug report pages, all VisualEditor will do is spit out a cryptic error message. Reaper Eternal (talk) 21:21, 11 July 2013 (UTC)[reply]

My experience with the "warning" feature of the edit filter is that it simply becomes one more button to push. Nearly everyone just hits "save" again and doesn't address the warning.—Kww(talk) 21:24, 11 July 2013 (UTC)[reply]

I don't know about you interacting with warnings, but in previous studies between 50 and 80% of "test" edits and silly vandalism (e.g. "poop") edits would be abandoned when given an appropriate warning. So at least some people do notice and react to warnings. Of course, the problem probably needs to be easily solvable too. In many cases, I can't really see how people working in VE would easily fix nowiki errors that VE creates. Even for things like using brackets inappropriately, it would be challenging both to understand and to fix the issue. Dragons flight (talk) 21:44, 11 July 2013 (UTC)[reply]

My primary experience with warnings is with Filter 526. Nearly everyone plows right through, even after I went to the effort of creating a bilingual edit filter in deference to our Brazilian editors.—Kww(talk) 21:52, 11 July 2013 (UTC)[reply]

See also: #Nowiki, bugzilla:49820, bugzilla:50527 (solved by filter 550), bugzilla:49686. πr² (t • c) 22:07, 11 July 2013 (UTC)[reply]

Let me see:

all kinds of spurious nowiki-tags, such as someone adds a blank space: <nowiki> here</nowiki>.

These are added in a line-start position, as that line would otherwise be preformatted.

wikilinks chopped with prefix letters: "C[[ommandant General]]"

This is a VE UX issue, but technically correct. Selecting a part of the word for linking will naturally link a part of the word. Also, this often inserts <nowiki/> at the end to avoid unintended link trails.

wikilink literalized by nowiki-tags: <nowiki>[[Page (person)|Page]]</nowiki>

This is normally people typing literal wikitext in VE. Same with template braces etc.

wikilinks with nowiki-tag split as 2 links: "[[Toffee|<nowiki/>]][[toffee]]" to show one link: toffee.

Was this link created in the VE?

wikilinks with no-wiki brackets: "[[Cricket (insect)|[[Cricket<nowiki>]]</nowiki>s]]" to show: [[Cricket (insect)|[[Cricket]]s]]

This sounds odd. Can you describe how or where this happens? --GWicke (talk) 22:16, 11 July 2013 (UTC)[reply]

Thanks for analyzing those examples, as we want to know if they are fixed or not caused by VE. Inside "Kneader reactor", see dif258 for dough/toffee wikilinks considered a VE edit, made 10 July 2013. In general, see: Scan of Filter 550. Many "nowiki" are fixed by same users. -Wikid77 02:59, 12 July 2013 (UTC)[reply]

From dif258 it is hard to tell if the user just created an empty link followed by a linked word, or if VE created weird HTML. I'm guessing the former as linking generally works fine. Maybe there is an opportunity to improve the UX though to avoid empty links to be created unwittingly. --GWicke (talk) 03:40, 12 July 2013 (UTC)[reply]

The "nowiki" for square brackets should be disabled asap, this was a mistake by the VE developers. Nowiki for other code (like the ampersand) seems to be more useful and mless problematic, but the number of incorrect nowikis for square brackets is way too high, for very few correct nowikis. I have been correcting them wherever I found them, but now that the VisualEditor tag seems to have been disabled, I can't filter the recent changes any longer, and I'm not going to look through ten times the number of edits to find the same number of errors. VE error reporting and fixing has already distracted me enough from all other things I like to do around here. Please, disable automatic "nowiki" for square brackets, and bring back the VE tag for the foreseeable future, until all repeated errors and problems are solved. Fram (talk) 07:52, 12 July 2013 (UTC)[reply]

Addendum: apparently the VE tag was gone for a while, but is now back? Thanks for that at least! Fram (talk) 07:55, 12 July 2013 (UTC)[reply]

Edit request of the fully protected "Template:Country data Niger" according to the example of Belgium

I created Template:Country data Niger/sandbox for how the official Template:Country data Niger should look like. In the bottom row of this table is my proposal for a new Niger default.

code	gives	type of flag
{{flag\|Belgium\|state}}	Belgium	official state flag
{{flag\|Niger}}	Niger	official state flag used as a default in Wikipedia
{{flag\|Belgium}}	Belgium	civil flag used as a default in Wikipedia
{{flag\|Niger/sandbox}}	Niger/sandbox	civil flag (my proposal)

I guess my sandbox version looks better. What do you think?
Maiō T. (talk) 21:12, 11 July 2013 (UTC)[reply]

Update page "Flag of Niger" with sourced civil flag: It will be easier to back a technical flag size if the flag article documents the size ratio as a common usage. Currently, the page is too nebulous and needs sources to pinpoint a ratio. Perhaps that is why the official ratio (rather than a civil-ensign ratio) is used in the icon. -Wikid77 (talk) 21:30, 11 July 2013 (UTC)[reply]

How to circumvent "This file is bigger than the server is configured to allow."

I am trying to upload an NSA video on polygraphy which uses some excerpts from copyrighted TV shows (Meet the Parents and The Simpsons) and so I am uploading it locally on the English Wikipedia instead of on the Commons (I can cut out portions and upload that on the commons).

But when I have it in an OGV format the upload system says "This file is bigger than the server is configured to allow." - How do I circumvent this so I can upload the file?

Also how do I attach SRT files so they can interact with the video on the English Wikipedia?

Thank you WhisperToMe (talk) 07:10, 12 July 2013 (UTC)[reply]

You could file a request on Bugzilla to have it uploaded server-side. As for subtitles, see Wikipedia:TimedText. Matma Rex talk 08:53, 12 July 2013 (UTC)[reply]

Wikidata after an article move

Wikilinks to others languages are lost after article Direct negotiations between Chile and Argentina in 1977–1978 was moved to Direct negotiations between Chile and Argentina in 1977–78. We can add the links with wikidata but IMO there should be done automatically by every move. --Best regards, Keysanger (what?) 08:26, 12 July 2013 (UTC)[reply]

I think there's a bot that does this every hour. But yes, it's a bug, I'm pretty sure it's filed, but can't find it on Bugzilla right now. Matma Rex talk 08:51, 12 July 2013 (UTC)[reply]

Y'know, I thought there was a reminder in MediaWiki:Movepage-moved to fix up Wikidata after a move... it seems that there isn't. --Redrose64 (talk) 10:36, 12 July 2013 (UTC)[reply]

bugzilla:36729. See quote: "Will be deployed on July 8th or 12th." (quote by User:Denny Vrandečić (WMDE), see #c14). Today is July 12. Is this deployed yet? πr² (t • c) 13:45, 12 July 2013 (UTC)[reply]

VisualEditor tag not working correctly

Edits made by using VisualEditor get the VisualEditor tag. Or so I thought, as it seems now that some do, and some don't. A typical example of a VisualEditor error was the addition of a substituted persondata template plus the duplication of the defaultsort and all cats plus the addition of Category:Persondata templates without short description parameter (this error should be corrected now, so no new instances of it should happen). I found many of those by looking through changes with the VisualEditor tag, but I have now found many recent edits making the same error, but without the ViualEditor tag. I don't believe that the error also happens in the "old" editing environment (it certainly was a rare one), but now...

Examples: [38][39][40], ... As can be seen, this has been happening since the start of VE, this isn't a recent issue, but I only found out about it just now. It looks as if thousands of VE edits have not been tagged with the VE tag, and thus have not been checked by VE correctors or taken into account in VE editing statistics. Am I missing something here or is something really wrong with this? Fram (talk) 08:29, 12 July 2013 (UTC)[reply]

Thanks for the report. We'll investigate ASAP.--Eloquence * 09:01, 12 July 2013 (UTC)[reply]

Thanks. Can I just say that so far, the speed and friendliness of replies wrt VE has been refreshing? I don't always agree with the responses or solutions, and VE contained (and contains) some serious flaws, but the post-deployment communication has been as far as I am concerned magnitudes better than with some earlier instances of controversial mediawiki changes. Fram (talk) 09:07, 12 July 2013 (UTC)[reply]

[Smith2010-1] Smith, S. (2010) Jones lies

[Jones2009-2] Jones, J. (2009) The truth

[Jones2009-3] Jones, J. (2009) The truth

[Smith2010-4] Smith, S. (2010) Jones lies

[1]

[2]

[1]

[2]