Wikipedia:Village pump (technical): Difference between revisions

Browse history interactively

← Previous edit Next edit →

Content deleted Content added

VisualWikitext

Inline

Revision as of 18:33, 8 July 2013

Table of contents
First discussion
End of page
New post

Shortcuts

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, 213, 214, 215

Universal Language Selector will be enabled on July 2, 2013

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

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

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

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

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

Yes, that is one of the reasons I have JavaScript disabled...

My CSS just hides a link that is rather pointless without the associated JS. – PartTimeGnome (talk | contribs) 22:35, 26 June 2013 (UTC)[reply]

It assists you if you edit in multiple languages, contribute in non-Latin scripts, have problems entering text in your chosen language via a conventional keyboard, and so on. If you only ever write in English on English wikis, it won't be of much use, but you can rest easy knowing that others are helped by it (sometimes very drastically). - Jarry1250 ^{[Vacation needed]} 16:30, 30 June 2013 (UTC)[reply]

Yes, I totally understand this is helpful for others. I'm afraid those who are not using it have to overlook it for the time being, since there is currently no possibility to turn it off. There are two requests in bugzilla though (bugzilla:46306, bugzilla:46744) regarding the issue. --Patrick87 (talk) 17:15, 30 June 2013 (UTC)[reply]

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

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

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

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

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

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

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

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

It wasn't enabled already? πr² (t • c) 13:47, 4 July 2013 (UTC)[reply]

I thought it was deployed on 2 July - which is also what mw:Universal Language Selector/Deployment/Planning says. NtheP (talk) 13:58, 4 July 2013 (UTC)[reply]

Yes, the above message (globally delivered by EdwardsBot) is only meant for the other language Wikipedias, where ULS is not yet active.

Sad part is, that we can't disable ULS in our preferences, even if we don't need it – the same bollocks as with VisualEditor. Although there is notable demand for it (see bugzilla:46306)!

What makes the whole thing much worse is the fact, that in this case WMF did not even have the guts to admit they needed involuntary beta testers as it seems to be the case with VisualEditor. They just gave no reason at all as to why this feature is compulsory and closed the linked bug as "WONTFIX" without a comment. --Patrick87 (talk) 14:07, 4 July 2013 (UTC)[reply]

@Patrick87: Did you really mean bug 50612? πr² (t • c) 14:09, 4 July 2013 (UTC)[reply]

No, sorry. bugzilla:46306 is the correct bug. --Patrick87 (talk) 14:23, 4 July 2013 (UTC)[reply]

Position of templatedata

Please consider joining the feedback request service.

An editor has requested comments from other editors for this discussion. This page has been added to the following list:

Wikipedia technical issues and templates

When discussion has ended, remove this tag and it will be removed from the list. If this page is on additional lists, they will be noted below.

This RfC was prompted by a post on OKeyes's talk page.

There's been a fair bit of discrepancy around the placement of TemplateData, which is necessary for templates to work properly with the VisualEditor. TemplateData is included by adding something that resembles the following text to either the template itself (e.g. the page Template:Foobar) or a page that the template transcludes (e.g. Template:Foobar/doc).

Sample templatedata

<TemplateData>
{
        "description": "The template is used to identify claims in articles, particularly if questionable, that need a citation to a reliable source.",
        "params": {
                "date": {
                        "label": "Month and year",
                        "description": "Provides the month and year of the citation request; e.g., 'January 2013', but not 'jan13'",
                        "type": "string",
                        "required": false
                },
                "reason": {
                        "label": "Alpha-numeric text",
                        "description": "A reason as to why, or for what content, the citation is needed; use single quotes, if any",
                        "type": "string",
                        "required": false
                }
        }
}
</TemplateData>

The example given above, in addition to displaying content in the VisualEditor interface, also prints the content found at Template:Citation_needed/doc#Template_data (minus the section header). However, there is no definitive policy or VisualEditor team "suggestion" as to where it should be placed, save for "Personally I put mine right at the bottom." :) Since eventually all templates should/will have TemplateData, a policy needs to be put in place...otherwise, I can foresee significant confusion and inconsistency--for example, some templates might include TemplateData at the bottom, whereas others would have TemplateData on a separate /doc page, which could result in redundancy, inaccurate information, etc. So, where should the <templatedata> block be placed? There are several options that I can think of, which I've listed below--feel free to add others, voice your support or opposition, or improve my intro statement as you see fit. Theopolisme (talk) 16:48, 1 July 2013 (UTC)[reply]

At the bottom of template itself

...

At the bottom of the template's documentation page

...

In a separate "TemplateData" section on the template itself

...

In a separate "TemplateData" section on the template's documentation page

TemplateData outputs a human-readable format, which provides quite nice documentation on the parameters supported by the template (particularly useful when editing via wikitext), so it is quite fine for this to be on the doc page. Anywhere on the doc page (even under Usage) would be fine by me. — This, that and the other (talk) 09:26, 2 July 2013 (UTC)[reply]

On a subpage of the template titled "/templatedata"

If this would be possible (while still being able to easily include this information in the documentation) this would allow to easily split the TemplateData from the rest of the template/documentation so it keeps clean at all times. This would also aid programmatic access of TemplateData a lot I assume. --Patrick87 (talk) 17:12, 1 July 2013 (UTC)[reply]

Discussion

No preference whatsoever, but if someone can find the time to expand TemplateData with a Lua api, then we could probably auto-generate large parts of the /doc output. —TheDJ (talk • contribs) 21:35, 1 July 2013 (UTC)[reply]
Note that Wikipedia:VisualEditor/TemplateData_tutorial#TemplateData says "The TemplateData is placed after the descriptive information about the template and before the "See also" section." which is what I've been fixing the newest additions to match. So that's the current standard/baseline. –Quiddity (talk) 21:59, 1 July 2013 (UTC)[reply]
That was just added a few hours ago by CaroleHenson. Theopolisme (talk) 22:24, 1 July 2013 (UTC)[reply]
Well, 15 hours ago, and before this RfC, and during my "last night" which is when I first looked. And before that it still contained the detail "after the descriptive information about the template and before the "See also" section." But I won't quibble... ;) –Quiddity (talk) 23:04, 1 July 2013 (UTC)[reply]
Haha, you're quite right. :) But it was only added based upon the discussion that I linked previously, not any specific policy per say. Theopolisme (talk) 00:00, 2 July 2013 (UTC)[reply]
I'd weakly object to placing the templatedata on a new subpage. I agree that it could/would help with organization, but it would also be one more place to watchlist (this is already a problem with documentation subpages..), and it would also further bulk up the results of searches in template-namespace (also a problem with doc subpages) particularly when typing in the VisualEditor template-selection box. [There are potentially ways to fix this (eg. excluding /doc subpages from the autocomplete search results), but they involve development work and/or further complications with subtle edge cases and use cases. Might be more trouble than worth.] –Quiddity (talk) 18:59, 6 July 2013 (UTC)[reply]

TemplateData: Is it working?

Is TemplateData actually working? Can someone give an example. I was trying to add citation templates that supposedly have this information available, but it didn't seem to be present. Maybe I was doing it wrong? When should I expect to see TemplateData in the Visual Editor? Dragons flight (talk) 02:14, 2 July 2013 (UTC)[reply]

I haven't seen it working yet either. I was under the impression that VE already had the functionality to read TemplateData built in, but I haven't seen any evidence of that - which means adding TemplateData to templates has no benefit whatsoever at the moment. I'm not going on a TemplateData adding spree until I see it working in VE. WaggersTALK 08:38, 3 July 2013 (UTC)[reply]

@Dragons flight: I've just seen this, which kind of answers our question. No timeframe yet though. WaggersTALK 08:44, 3 July 2013 (UTC)[reply]

See bugzilla:50372 for details/tracking. (Latest comment is "You appear to just be seeing the effect of weeks of job queue lag, i.e. a system problem, not a MediaWiki problem.") –Quiddity (talk) 15:34, 3 July 2013 (UTC)[reply]

@Dragons flight and Quiddity: Thanks - definitely working now, both for new and existing templates. There's just a bit of lag between TemplaateData to a template and it being available in VE. WaggersTALK 08:20, 4 July 2013 (UTC)[reply]

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

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)

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]

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): [1][2][3][4]a, extreme one [5]...

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[6]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[7]. 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]

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: [8] -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"[9]:

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]

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: [10]. Fram (talk) 08:46, 5 July 2013 (UTC)[reply]

A rather extreme one: [11]. 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]

Named refs

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

Does VE do this? The diff you gave has no "VE" tag in the es. Also, in a test edit I could not get VE to come up with a ref name like this. -DePiep (talk) 09:48, 5 July 2013 (UTC)[reply]

Tags are not part of the edit summary and are not shown in diffs (bugzilla:25824 and bugzilla:49602 have requests). The tag can for example be seen in the page history.[12] PrimeHunter (talk) 10:16, 5 July 2013 (UTC)[reply]

Indeed. And I'm pretty certain that it is a VE thing, I hadn't seen any of those before, and now they are quite regular appearances in VE edits. No idea what one needs to do to create them, which set of circumstances dictates this, but it is rather obvious that VE does this, just like VE feels that named refs now have to have quotation marks around the ref name, even though that is in reality only needed for multi-word ref names. Sometimes VE behaves like a bad version of AWB, which is ad since we already have a good version of it... Fram (talk) 11:18, 5 July 2013 (UTC)[reply]

Fair enough. I rest my case. -DePiep (talk) 11:31, 5 July 2013 (UTC)[reply]

Another example: [13]

Simple survey of new accounts

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

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

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

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

That's just absurd. It's not the edit window that drives women away - it's the way the guys behave. We're quite capable, and we do have brains, to figure out how to edit. A few of us have actually, swoon, sigh, managed to produce a fair bit of decent content. Complete with pictures and captions and research and all kinds of hard stuff. Victoria (talk) 00:24, 2 July 2013 (UTC)[reply]

Its the way many editors on Wikipedia behave (both male and female) that drive people away. Doc James (talk · contribs · email) (if I write on your page reply on mine) 00:42, 2 July 2013 (UTC)[reply]

Indeed. Honestly, if I was female, I'd likely be quite offended by that suggestion that the editing markup was too complex (and even as a guy I find it staggering that somebody actually suggested that) - because it carries the distinct insinuation that women aren't smart enough to figure it out. - The Bushranger _{One ping only} 00:34, 2 July 2013 (UTC)[reply]

"It's not the edit window that drives women away - it's the way the guys behave." These things are not mutually exclusive. Amazingly, we've never done a reliable survey of the demographics of people who just registered but haven't yet edited. We have no idea if equal numbers of men and women register accounts to begin with, what challenges they might each face when they first try to edit, and so on. Steven Walling (WMF) • talk 01:18, 2 July 2013 (UTC)[reply]

My guess is that women would not like suggestions that females cannot cope with wikitext, and they may not welcome a survey asking if they are female—a bit creepy really. Johnuniq (talk) 00:38, 2 July 2013 (UTC)[reply]

Hi, I wrote the code in question here. I completely understand that there are a lot of women on Wikipedia (and other WMF sites), who not only understand wikitext, but do great work. I also realize there are a lot of other factors at play here. However, we also know editing could be more user-friendly, and Sue Gardner has suggested (in the blog post Steven linked) that may impact female participation. Some other people have agreed. Superm401 - Talk 00:51, 2 July 2013 (UTC)[reply]

Being female, one of the early HTML coders on the newly created internet, and a Wiki editor since 2006, I would say that retention of females has nothing to do with a pink and fluffy style editor and much to do with the simply horrible way that some of the current editors (mostly male) behave to female editors. I have been put down, insulted, and threatened. I've taken time off editing to get my desire to edit back. Putting lipstick on the pig isn't going to get you more female editors without behavior changes of some of the entrenched "power users." Ellin Beltz (talk) 00:52, 2 July 2013 (UTC)[reply]

(edit conflict) The implication is that the 90% of guys who edit here have to put up with a crap rollout as a crutch for the 10% of women who put up with an immense amount of sexism. This implication needs to be retracted immediately. You're hanging it on the women. Great. I'm impressed. Victoria (talk) 00:54, 2 July 2013 (UTC)[reply]

@Ellin Beltz: No one who works in WMF design and engineering thinks women need a "pink and fluffy" editor, and I think you can see that when looking at VisualEditor. That kind of gross stereotyping of what appeals to women simply does not work, and mostly tends to be a complete disaster for somewhat obvious reasons. The point of the survey is not to justify that kind of solution to correcting what gender gap Wikipedia has. The question we're asking is: does a general purpose usability improvement, given to everyone, help make Wikipedia have a gender distribution more like the real world, where half of the world is born female. Maybe it will, maybe it won't. We honestly have no idea, which is why we're running a survey. Steven Walling (WMF) • talk 01:08, 2 July 2013 (UTC)[reply]

Wikipedia should have the mixture of editors that has the best results for maintaining and growing the encyclopedia, whether they're male, female, transsexual, intersex, or green blobby things from Mars. While there does indeed seem to be a somewhat alarming imbalance between male and female editors, the assumption that having that balance pegged to the real world is the ideal end state isn't necessarily the best thing for the encyclopedia - it should be gender-blind, not filling a quota. - The Bushranger _{One ping only} 02:16, 2 July 2013 (UTC)[reply]

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

Yes Wikipedia can get very nasty and I agree that this is probably the greater issue. I am not sure what to do about it other than try to be pleasant myself. I think women are less willing to put up with the nastiness than men and thus why we have more males here. I am not entirely sure which gender is the nicer though since it was a female Wikipedia editor who launched legal attacks against me and required me getting a lawyer for 8 months. Doc James (talk · contribs · email) (if I write on your page reply on mine) 01:04, 2 July 2013 (UTC)[reply]

Probably the first step to curbing nastiness would be to do something about the alarmingly widespread opinon that WP:CIVIL isn't just optional but is for losers, and the mop-hunting lynch mobs that get civility blocks overturned five minutes after the few who dare impose them do so, but that's another kettle of fish... - The Bushranger _{One ping only} 01:27, 2 July 2013 (UTC)[reply]

Comment Nobody is saying anything even remotely close to "women can't edit" or "women can't learn markup." It is simply factually true that women are underrepresented in STEM fields, including software engineering, and thus are less likely to know a markup or coding language. And I think most people here would agree (including you, Ellin!) that knowing some kind of markup/code puts you at a distinct advantage for learning other kinds of markup/coding languages, such as wiki markup. Maybe the latter is not actually an issue for most women, but the point of a survey like this is to actually test the hypothesis instead of making blanket assumptions about women's behavior and interests (and what may or may not offend them, cough). Maryana (WMF) (talk) 01:06, 2 July 2013 (UTC)[reply]
- Whether that is the case or not, I think that the main issue is how new editors are treated. By the way, I have no idea about what software engineering even is. SL93 (talk) 01:11, 2 July 2013 (UTC)[reply]

(edit conflict) Maryana - I am sorry, but I find this to be incredibly insulting. Learning markup is just not hard. Like anything else, there's a learning curve. But the assumption that women might like a Facebook type of experience (I'm not on FB so wouldn't know what that is) is wrong. Wikipedia, first and foremost, is a collaborative writing project and editors, regardless of gender, work for free. They volunteer their time. In my experience the men who don't write much, are a little more difficult to deal with than the so-called content editors. I have made some absolutely great friends here, people are always willing to help, and learning to deal with complicated markup is not an issue. But my biggest problem is the implication that VE was designed solely for women. Ironically, as a woman I can't use it, and Okeyes (WMF) refuses to answer the questions I've put to him repeatedly during the last weeks. That tells me a lot. I think the survey should be shelved for a bit. People are not happy and pointing the finger at technically challenged women isn't helping. Victoria (talk) 01:14, 2 July 2013 (UTC)[reply]

Frankly I've probably just missed them. What does that tell you, exactly? If you have specific questions, drop them on my talkpage where they won't get overwhelmed - I'll try to get to them in the morning. Okeyes (WMF) (talk) 01:20, 2 July 2013 (UTC)[reply]

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

In fact this new VE is more complicated. I have been trying to add a reference for an hour and simply cannot do it. Is there a help page that tells me how to add a properly formatted ref? How are new editors going to figure this out? If refs cannot be added we are way to early to go live on the VE. Doc James (talk · contribs · email) (if I write on your page reply on mine) 01:26, 2 July 2013 (UTC)[reply]

How to edit references. I hope this helps! Keegan (WMF) (talk) 01:40, 2 July 2013 (UTC)[reply]

So what you are saying is everything has to be entered via free text? There is no way to simply add the PMID / ISBN and to have a button that fills in the rest? The is no guidance on what properties a reference should have? Now people need to know reference styles guidelines or our article will simple be a hodgepodge of different ones (which or course means the latter) :-( Doc James (talk · contribs · email) (if I write on your page reply on mine) 01:56, 2 July 2013 (UTC)[reply]

I am not saying that. You asked if there was a page for using references in VisualEditor. There is, I linked you to it. Keegan (WMF) (talk) 02:02, 2 July 2013 (UTC)[reply]

If experienced editors can't use it, then I wonder why it is assumed that new editors can. SL93 (talk) 01:28, 2 July 2013 (UTC)[reply]

Steven, I must say that the theories you point out is pretty sexistic in it's own light. And using those theories as a tool isn't optimal behavior, if you really want to behave gender neutral. _→AzaToth 01:59, 2 July 2013 (UTC)[reply]

I'm also concerned about the implication that this has been done, in part, with women in mind, and that women can't or don't want to learn wiki markup. I also think it's wrong-headed to suppose that the VE will be easier for anyone, as least as it stands. In my own case, I'm as technically incompetent as it's possible to be, and I had no problem learning wikitext, because it's just a question of monkey see, monkey do. But with the VE, you no longer see what other editors have done before you, so it seems to me that it's going to be harder to learn. SlimVirgin ^(talk) 16:01, 2 July 2013 (UTC)[reply]
- I encourage you to read the statements above by Superm401 and Maryana. No one said what you think is being implied. Steven Walling (WMF) • talk 18:53, 2 July 2013 (UTC)[reply]
I agree 100% with SlimVirgin. I can't code for shit, I've tried and tried to learn even easy languages like Python and it just isn't my forte. I learned wikimarkup to a decently high level in a very short time at age 12. Implying that women won't edit because of a wikimarkup barrier is bullshit when a 12-year-old girl who, 6 years later, still can't program at all, can learn wikimarkup in a couple days. My own experience aside, I've worked with many women through the Education Program who have had no trouble at all learning the markup. I find that the people who have the most trouble are non-digital natives. If you're going to "market" an easier way to edit, at least say it's for people who don't have a lot of experience with the Internet. Saying that it'll bring women on board ironically exemplifies the unconscious sexism that makes this community so hostile to women in the first place. Keilana|^{Parlez ici} 17:58, 2 July 2013 (UTC)[reply]
The Visual Editor is probably quite a way from feature parity from the old textbox editor. I think this will compromise the research being conducted. *If* the research finds that women prefer the new VE, does that mean they are 'better' when they dont need to worry about features that are missing from the VE? It is possible that VE edits may be more likely to be reverted because they dont use all the features of the old textbox, and their will walk away feeling unwanted by Wikipedia. i.e. this study, if conducted now, will likely result in a gender catastrophe, or the results will look so bad that the WMF wisely shelves the data to avoid said controversy. How did this research project pass an ethics committee?? John Vandenberg ^(chat) 00:05, 3 July 2013 (UTC)[reply]

i.e. any research that is conducted on a new feature should be gender neutral. Does the feature improve the project? This may be viewed as self-evident by the WMF team, and I am sure VE will eventually be beneficial to the projects, but it might take a while for that to be realised and verified by research. John Vandenberg ^(chat) 00:14, 3 July 2013 (UTC)[reply]

Gender Comment

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

"Please accept my resignation. I dont want to belong to any club that will have me as a member". -Groucho Marx.

I have just tried the visual editor. It is too slow on my machine to be an enjoyable experience but I do think that the interface is a step forwards.

The people discussing this point here are the ones who have successful mastered the markup language. The may come from a background where they can do hex arithmetic in their heads and so appreciate the positioning of the ASCII character set, or from a background where they were already familiar with HTML or they may be someone who likes Wikipedia enough that they just persevered and learnt it.

But anyone commenting here is part of a self-selecting group who not only know how to use the markup language but also put up with the culture here which is far less welcoming today than it was when I started to edit. The major reason for this is that in the early days there were far fewer restrictions on what one could do, so the time before one did something that another "corrected" because of a guideline, and hence the need to lean about the guidelines was much longer than today. Not needing to debate the worth of "corrections" meant that one rarely ended up in a hostile stressful debate.

Some things can not easily be fixed. For example the need for citing sources is important for the credibility of the content -- that debate was done and dusted back in 2006 -- there is no way that we can go back to the way articles were created and maintained prior to that decision. There is no internal desire among enough of the regular editors to fix the uncivil culture that exists, or to stop the politics and social manipulation that are frequently used by some editors (which without a uncivil word being said can leave an editor feeling that they were mugged), all of which can make editing here an unpleasant experience.

But I think that a more friendly editor front end is a good technical fix for one of the problems that Wikipeida has. So I think WYSIWYG front end is a positive step forward and if it encourages people outside the usual demography to start to edit then that must be a positive thing. I think that the phrasing used by Steven Walling at the start of this thread was clumsy -- as there are many other ways to group people who are outside the demographic profile of a typical Wikipedia editor and more of those than just one needs to captured if a survey is to be of greater use. -- PBS (talk) 13:17, 2 July 2013 (UTC)[reply]

The group of editors here is one of the main reasons why Wikipedia exists. They are a key group to keep happy as they are key to making and maintaining the content that raises the funds that keeps the lights on :-) Doc James (talk · contribs · email) (if I write on your page reply on mine) 15:16, 2 July 2013 (UTC)[reply]

This is simply wierd. One of the most competent, helpful, technically proficient and all-round great editors I intersect with quite frequently in the six years I've been an editor is User:WhatamIdoing - yesterday I discovered quite by accident that she is a woman. Just off the top of my head some other great editors I interact with regularly who I know happen to be female are User:SarahStierch, User:LauraHale, User:HelenOnline and User:Anne Delong - does it in any way affect how I interact with them, not in the slightest. However if sexism on WP is actually real may I offer a simple solution: Use a gender-neutral username and unless you tell, nobody will ever know - thus it cannot even become an issue. On the internet nobody knows you're a dog or "Don't ask, don't tell". Roger (Dodger67) (talk) 13:53, 3 July 2013 (UTC)[reply]

WhatamIdoing's gender is not a secret, it's shown in her userboxes. Occasionally, people use gender-specific pronouns in comments about myself, and it's amusing to spot which ones get it wrong. I never correct them. --Redrose64 (talk) 15:16, 3 July 2013 (UTC)[reply]

Those people might look into {{subst:gender}}... --N Y Kevin 16:43, 3 July 2013 (UTC)[reply]

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

I would say that in the case of (a) it's the opposite. Lack of employment gives me more time for editing, not less; and as for economics, it's pretty much free. I already had the PC before I lost my job, and my broadband costs GBP 6.49 per month - but even without those, I'd still be able to use the IT facilities at the public library for no charge (unless I want to print something in colour). --Redrose64 (talk) 16:09, 3 July 2013 (UTC)[reply]

I'm pretty sure it's (b) primarily. Which means the encylopedia is mature and becoming steadily more stable, which means (by extension) that the "drop-off" is a good thing. But the Chicken Littles who declare the sky is falling have gotten "we have to do something about EDITOR RETENTION and RECRUITMENT omg!" established as Holy Writ. - The Bushranger _{One ping only} 23:14, 3 July 2013 (UTC)[reply]

Less than one percent of the articles have passed either GA or FA so still a lot of work to do. Much of the easy work however is done. And we still need editors to review edits and revert vandalism. I guess the really question is "how to we determine the reason for the decline in editor numbers?" One argument against the "easy work is done" hypothesis is that editor numbers have slowed / decreased in many languages which are far from complete. Doc James (talk · contribs · email) (if I write on your page reply on mine) 00:28, 4 July 2013 (UTC)[reply]

Take care about extending this to other namespaces

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

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

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

Adam Cuerden ^(talk) 01:00, 2 July 2013 (UTC)[reply]

Rest assured, there are no plans now or in the immediate future to use VisualEditor outside of the article space and the User space. Keegan (WMF) (talk) 01:36, 2 July 2013 (UTC)[reply]

Yep. The one example I can think of is as part of Flow, and that's an entirely different ballgame (and one where we've plotted out things like GAN problems). Okeyes (WMF) (talk) 06:50, 2 July 2013 (UTC)[reply]

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

I'm slightly confused; Flow will involve the VE, so surely that solves for that problem? And I agree, they're meant to discuss their contributions, but that requires them to make contributions. Having a vector for people to do so and get somewhat hooked is A Good Thing - learning markup can come later in the workflow than it does now. Okeyes (WMF) (talk) 09:11, 2 July 2013 (UTC)[reply]

I think that MER-C means that today newbies will have to learn two systems to participate fully on all pages.

This search suggests that they make about 14 edits to the article space for every 1 edit to an article's Talk: page. If that's distributed evenly, and if we assume that these new accounts don't make many edits, then it might be the case that 10% or so of them actually need to use both systems now. Whatamidoing (WMF) (talk) 10:10, 2 July 2013 (UTC)[reply]

Yep. Add Wikipedia and Wikipedia talk (WP:AFC) to that list as well. MER-C 11:03, 3 July 2013 (UTC)[reply]

Just wanted to add this, too! Especially in long discussions (as on this page) it can become difficult to insert a comment at the right place in a discussion (one has to search twice in the end, once when reading and once in the Wikitext when editing in the comment). Therefore having VE enabled on some Help and Project pages might be very useful, too. However there are many places in Wikipedia namespace were usage of VE is impossible at this time (e.g. WP:GL were <gallery> syntax is heavily used). So we can't blindly activate it or need an opt-out per page (e.g. a magic word like __NOVE__). --Patrick87 (talk) 11:18, 3 July 2013 (UTC)[reply]

Problem is VE as default

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

I agree and I have been telling the developers for weeks it wasn't ready. I think the bigger problem is the WMF doesn't seem to care what we as editors think. They have this mentality and attitude that they know what we want and need and anyone who complains just hates change. That is the true problem. Kumioko (talk) 17:52, 2 July 2013 (UTC)[reply]

Something here needs to change. The WMF cannot be allowed to ram change down our throats. I think the best course of action is for them to immediatly implement an easy opt-out function, via sitewide banner and admit they made a mistake here. ★★Retro Lord ★★ 18:07, 2 July 2013 (UTC)[reply]

Good luck. Kumioko (talk) 18:21, 2 July 2013 (UTC)[reply]

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

Where's the "over 300" number coming from - bugzilla? Okeyes (WMF) (talk) 06:26, 3 July 2013 (UTC)[reply]

I haven't seen any assertions that women are too stupid to learn wikimarkup. I have, however, seen some reasonable evidence in the past that says women are less likely than men to want to spend their limited leisure time learning something that can only be used here, because they have other things to do that are more important to them.

We could make the same claim in other ways: Neurotypical people aren't "too stupid to learn wikimarkup", but our experience indicates that they are less likely to bother learning it than our many productive editors with Asperger's syndrome.

Similarly, many of us have been directly told by various subject-matter experts that they can't be bothered to learn wikimarkup. I expect that most of us won't say that university professors, doctors, and scientists are "too stupid to learn wikimarkup"—but my e-mail inbox still gets messages from people like this, requesting that I fix some error or expand some article, because they don't understand wikimarkup and don't want to waste time learning it.

If we're not offended that many busy people of both genders don't want to waste time learning wikimarkup, then why should we be offended by the idea that many women—the gender whom time-use surveys consistently report as having the least amount of free time—are too busy to bother with it? If we're hopeful that VisualEditor will get more busy doctors and professors improving articles (and we are), then why are we offended at the idea that it might get more busy women improving articles? WhatamIdoing (talk) 09:18, 3 July 2013 (UTC)[reply]

If it makes it any better, I am more offended that this was rolled out with so many problems. Over 300 errors or less. It doesn't matter. SL93 (talk) 15:39, 3 July 2013 (UTC)[reply]

It is true that many busy would-be editors don't want to learn Wiki markup. (Information technology engineers are an exception.) However, a bug-loaded editor that is meant to be easy to use but often does not work should not have been shoved at editors without better testing. New editors are just as likely to abandon the encyclopedia because the visual editor "sucks" as because they don't want to learn to use Wiki markup. Robert McClenon (talk) 00:37, 4 July 2013 (UTC)[reply]

When we get the results of the A/B testing back, we should know the answer to that question, rather than having to speculate about what effect it has on new editors. Whatamidoing (WMF) (talk) 14:13, 4 July 2013 (UTC)[reply]

If you don't have the results of the A/B testing, why is it being rolled out? Logically, you should wait until the test results are in. - Bilby (talk) 15:24, 4 July 2013 (UTC)[reply]

I hear that they are processing the initial results of the A/B test now, and that they will be able to use that as they decide whether to offer VisualEditor to unregistered users next week (as originally planned). If, for example, the test results showed that newbies using VisualEditor were far more likely to get blocked for spamming, then I believe that they intend to postpone the conversion for IP editors. If, on the other hand, it showed that newbies using VisualEditor were far less likely to get blocked for spamming, then that would encourage them to make the change as scheduled (assuming all else is equal; if there are technical reasons to avoid it, then that would obviously matter, too). Whatamidoing (WMF) (talk) 20:42, 4 July 2013 (UTC)[reply]

While it is good that this is being considered before being rolled out to IPs, it has already been rolled out to everyone who creates a new account. - Bilby (talk) 00:27, 5 July 2013 (UTC)[reply]

Category:Musical theatre articles missing an image in infobox

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]

Visual editor - post edit notice

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

There's no way to distinguish this from any other jsMessage notification using CSS. A JavaScript hack would be possible, but it would be a lot easier if the jsMessage call gave a parameter for the id. Any devs? πr² (t • c) 23:33, 2 July 2013 (UTC)[reply]

Per this, it will be hidden by existing CSS when two changes are deployed. πr² (t • c) 00:49, 3 July 2013 (UTC)[reply]

Thanks, have to start watching the deployment schedule. NtheP (talk) 11:29, 3 July 2013 (UTC)[reply]

'Thank' link doesn't appear to work in IE10

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

[14] You appear to be thanking people. It uses js, so make sure that's enabled. I think then you'll see a confirmation. May be related to bugzilla:49161. Killiondude (talk) 21:59, 2 July 2013 (UTC)[reply]

I switched to Chrome. I don't think it's related to bugzilla:49161 as JavaScript is enabled in my IE10. A Quest For Knowledge (talk) 22:02, 2 July 2013 (UTC)[reply]

The problem you are reporting sounds like a potential issue in the code of the "Thanks" software. If the problem is reproducible, it would be nice if somebody who has this issue could send the software bug to the 'Bugzilla' bug tracker by following the instructions How to report a bug, providing potential javascript error feedback and creating a ticket here. This is to make developers of the software aware of the issue. If you have done so, please paste the number of the bug report (or the link) here, so others can also inform themselves about the bug's status. Thanks in advance! --AKlapper (WMF) (talk) 09:58, 3 July 2013 (UTC)[reply]

@A Quest For Knowledge: I was just near an IE10 machine and tested this functionality. It is working just fine for me. —TheDJ (talk • contribs) 17:20, 3 July 2013 (UTC)[reply]

@TheDJ: Weird. I just tried it again, and it did not work for me. Are you using Win7 or Win8? I'm on Win8. I have 2 other Win8 machines I can test this with. A Quest For Knowledge (talk) 19:41, 3 July 2013 (UTC)[reply]

Windows 7, but perhaps I can try on Windows 8 at work tomorrow. —TheDJ (talk • contribs) 20:20, 3 July 2013 (UTC)[reply]

Now tested on Windows 8 with IE10 (vector and monobook) All these combinations work for me. Perhaps you have some broken JS installed in Special:MyPage/myskin.js or a Gadget is malfunctioning ? Other than that I have no explanation. —TheDJ (talk • contribs) 12:29, 4 July 2013 (UTC)[reply]

Unresponsive script

Tracked in Phabricator
Task T35018

Tracked in Phabricator
Task T51935

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]

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]

Tool Labs index

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

There is mw:Toolserver/List_of_Tools linked from mw:Wikimedia_Labs/Tool_Labs/Roadmap_en but that might not be up to date. For general info, see https://blog.wikimedia.org/2013/05/30/preparing-for-the-migration-from-the-wikimedia-toolserver-to-tool-labs/ for the latest state and plans. --AKlapper (WMF) (talk) 10:02, 3 July 2013 (UTC)[reply]

That's a pretty useless list from the point of view of a user (and the other links aren't aimed at users at all). Only a tiny fraction of the listed tools has a status of anything besides "unknown" and those that do do not have any information on how the tool might be used. What I need is a list of what is actually available on Tool Labs and links to usage documentation, not a list of exactly how badly the migration from toolserver has been conducted. Spinning Spark 10:31, 3 July 2013 (UTC)[reply]

You can open all links in http://tools.wmflabs.org/ in your tabs and go on hunt, or find the most popular tools at http://tools.wmflabs.org/awstats/cgi-bin/awstats.pl

Only a minuscule fraction of the tools has moved so far anyway. Your best option, currently, seems to be to ask individual Toolserver tool authors to add an .htaccess rule to redirect to Tool Labs equivalents if existent. --Nemo 10:44, 3 July 2013 (UTC)[reply]

I don't think "minuscule" is accurate since somewhere between a fourth and a third of tools have been moved or so. Part of the problem with trying to find has X been moved is that there has never been an authoritative list of what runs on the toolserver and who maintains them – so it's often not even possible to find out whom to ask. — MPelletier (WMF)^(talk) 12:33, 4 July 2013 (UTC)[reply]

I should point out that toolserver is still running. What tools are you looking for?—cyberpower ^Chat_Offline 11:43, 3 July 2013 (UTC)[reply]
It wasn't running at the time I made the post (or at least was not contactable), but it seems that this was just another example of the increasing flakiness of the toolserver. As for what tools I need, there is a long list, but the one I needed when I asked the question was http://toolserver.org/~jarry/cidr/index.php a CIDR range contribution tool. Spinning Spark 13:17, 3 July 2013 (UTC)[reply]

Ah, probably best to send a note to Jarry1250 (talk · contribs) then. --Redrose64 (talk) 14:43, 3 July 2013 (UTC)[reply]

Tool migration is planned when I get some free time :) I'm make sure I do the CIDR tool as well (or at least that someone does; IIRC it is a fork of another tool that went AWOL). The Toolserver itself has a shelf life of slightly less than 18 months, though outages will remain a persistent feature. - Jarry1250 ^{[Vacation needed]} 19:31, 3 July 2013 (UTC)[reply]

Hideous new edit crap

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

PS, Please don't take my comments above too literally. I actually think it's far worse than my post above suggests. Grutness...wha? 14:38, 3 July 2013 (UTC)[reply]

Having that weird semi-editing mode as the default certainly is a problem. North8000 (talk) 14:42, 3 July 2013 (UTC)[reply]

You can select "Remove VisualEditor from the user interface" at Special:Preferences#mw-prefsection-gadgets. It will still load the code with the associated performance issues on slow connections, but at least you shouldn't see it. PrimeHunter (talk) 14:46, 3 July 2013 (UTC)[reply]

Aaaahhh. Thank you! I'll again be able to edit Wikipedia without the temptation of hurling my laptop out the nearest window! Grutness...wha? 15:01, 3 July 2013 (UTC)[reply]

Or use the most popular browser in the US - Internet Explorer - Wikipedia always deals with it last, if ever - You can't have Visual Editor on IE even if you want it Arjayay (talk) 15:10, 3 July 2013 (UTC)[reply]

I believe that the VE devs were really trying to get IE10 support in there, but had to back it out at the last moment due to several heavy content corruption bugs. IE9 and IE10 support are still planned. —TheDJ (talk • contribs) 17:04, 3 July 2013 (UTC)[reply]

Or Opera: I have the one that shows "Version 12.15 Build 1748 Platform Win32 System Windows XP Browser identification Opera/9.80 (Windows NT 5.1; Edition IBIS) Presto/2.12.388 Version/12.15", which is apparently the latest version ("Help → Check for Updates" reports "You are using the latest version of Opera") and I don't get VisualEditor on any page - all the [edit] links are for the traditional Wiki editor. --Redrose64 (talk) 15:27, 3 July 2013 (UTC)[reply]

There are several major bugs that are currently blocking deployment for Opera browsers. Since Opera usage is extremely low, these issues currently don't have priority. —TheDJ (talk • contribs) 17:04, 3 July 2013 (UTC)[reply]

I wasn't complaining - I was pointing out that for those people who don't want the VE experience, using Opera is one way of avoiding it. --Redrose64 (talk) 18:32, 3 July 2013 (UTC)[reply]

Regarding: It will still load the code with the associated performance issues on slow connections, but at least you shouldn't see it.

Unless you actually use VisualEditor (by clicking "Edit" with VE enabled), the JavaScript footprint is now about 4KB. So the performance footprint should be negligible if you don't use it.--Eloquence * 05:30, 4 July 2013 (UTC)[reply]

Hm. "Visual editor or IE" sounds a bit like "which Hell do you want to spend eternity in?" I'll stick with the simple preference checkbox, thanks. Grutness...wha? 01:26, 4 July 2013 (UTC)[reply]

Overlapping icons

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

I see it too, but it shouldn't happen. From {{pp-meta}}: "This template uses a position that does not collide with icons such as the "Featured Article" star, the "Spoken Wikipedia" icon, or other top-right-hand-corner icons." Seems like a bug of some sort... :/ Theopolisme (talk) 16:14, 3 July 2013 (UTC)[reply]

It's because it is using Pending Changes protection and because @Mr. Stradivarius: changed the position of the lock icon in those cases. Which he shouldn't have, since there is only ONE allowed position for lock icons in the current system. I think the intent was to show that two types of protection were in effect for an article, but since we already have the FR dropdown in the top, I don't see why we need a separate lock icon for PC to begin with. —TheDJ (talk • contribs) 16:55, 3 July 2013 (UTC)[reply]

I copied the icon location code from the old version of pp-pc1, and didn't give clashes with other icons too much thought. That was obviously an error - my apologies about that. The {{pp-pc1}} template has been discussed at TfD with a result of no consensus, but it would probably be worth nominating it again. In the previous discussion it wasn't made clear that there is no possible location for the icon that would avoid clashes, so that information may change how people vote the second time round. — Mr. Stradivarius ^{♪ talk ♪} 22:20, 3 July 2013 (UTC)[reply]

Are there any pages currently protected under both pending changes and normal protection? Theopolisme (talk) 00:22, 4 July 2013 (UTC)[reply]

I haven't checked to see if there are any now, but it is a regular occurrence. I myself have often semi-protected a page for a few days, and at the same time given it pending changes protection for a longer period. I have found that this is a good way to deal with pages which have had a recent vandalism spike but that also have long-term but infrequent vandalism problems. In any case, if we are going to keep the pending changes icons then we should probably disable their being displayed if the page is also under a different form of protection. I'll have a look at the {{pp-meta}} code later on to see if this can be done easily. — Mr. Stradivarius on tour ^{♪ talk ♪} 04:22, 4 July 2013 (UTC)[reply]

It looks like the fix to {{pp-meta}} wouldn't be trivial - it would require at least some restructuring of the main template logic. Probably the whole thing needs rewriting in Lua anyway, so rather than wrestle with that template code I think it would be better just to port it to Lua. I'll add that to my list of things to do... — Mr. Stradivarius ^{♪ talk ♪} 11:29, 4 July 2013 (UTC)[reply]

_{You are one of our resident Lua ninjas... :) Theopolisme (talk) 07:32, 5 July 2013 (UTC)}[reply]

Couldn't you just put the {{pp-semi}} on top of the {{pp-pc1}}, so the latter is not visible at all? It seems to me that a page with both will effectively behave like a page that's only semi-protected, so the readers don't actually need to see the white lock. --N Y Kevin 17:30, 5 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]

Disappearing edit tab

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

The tab is "Edit" in the default Vector skin but I think it has always been "edit this page" in MonoBook. Other methods to edit the whole page include manually adding ?action=edit to the url (or &action=edit if there already is a ?), or starting a section edit without VisualEditor and then removing the section number from the end of the url. But these workarounds are obviously far from ideal. What happens if you disable the "remove VisualEditor" gadget? There may be compatibility issues with some browser versions. PrimeHunter (talk) 20:19, 3 July 2013 (UTC)[reply]

Ah. When I disable the gadget, the problem goes away. Somewhat oddly, still no VisualEditor for me even with the gadget disabled; I'm guessing that my particular browser doesn't support VE, so it doesn't show up? I noticed on the day it was rolled out that my browser was trying to start VisualEditor without success, then a few hours later it didn't even bother; this was before I had enabled the "remove" gadget, I think, so maybe one of the developers had made a tweak shortly after rollout. Thanks for the suggestion. --Bongwarrior (talk) 21:36, 3 July 2013 (UTC)[reply]

That's what I had to do; somehow my options had been mucked with to allow the enhanced editor to appear when the VE was turned on, which I didn't like when it was rolled out two years ago (on Opera 12.15) because I'm so used to RefToolbar 1 that I didn't want to change. I was trying to get my edit button back at the same time. Nate • (chatter) 21:57, 3 July 2013 (UTC)[reply]

Yeah, when your browser is on the VE blacklist, if you also have the VE-disabling gadget ticked, it'll do that on some pages. Not all, bizzarely. - The Bushranger _{One ping only} 23:02, 3 July 2013 (UTC)[reply]

I think I have fixed this problem. —TheDJ (talk • contribs) 09:44, 4 July 2013 (UTC)[reply]

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

Same thing happened to me (Firefox 22 on Windows XP). Nothing (including the killer script) seems to get rid of the thing. Tassedethe (talk) —Preceding undated comment added 00:03, 4 July 2013 (UTC

Same thing has just happened here and slowed things to a crawl. Keith D (talk) 00:04, 4 July 2013 (UTC)[reply]

Same here too. *sigh*. Jguy _Talk^Done 00:06, 4 July 2013 (UTC)[reply]

Crosspost from @Okeyes (WMF):

So apparently this is the result of changes to make the loading of VE smaller; on page load, it's gone down from 110kb-ish to 4kb ish, 
but this has resulted in some changes not reflected in MatMaRex's gadget. I understand he was aware of these changes, 
so hopefully they can be fixed. Okeyes (WMF) (talk) 00:12, 4 July 2013 (UTC)

Thanks Jguy. I'd note that I am, obviously, pretty frustrated about this. I'm hoping for a fix soon (early next week? later this one?) - in the meantime, I think people will have to get used to hitting 'edit source' :/. Okeyes (WMF) (talk) 00:23, 4 July 2013 (UTC)[reply]

Colour me incorrect - the opt-out gadget should right now be fixed! Credit to User:Jamesofur. Okeyes (WMF) (talk) 00:38, 4 July 2013 (UTC)[reply]

Aye! I see the fix now. Thanks! Jguy _Talk^Done 01:12, 4 July 2013 (UTC)[reply]

Edit tag on recent changes patrol

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

Wikipedia:VisualEditor/Feedback#Tag: visual editor, also Wikipedia:VisualEditor/Feedback#Note on usage --Redrose64 (talk) 22:17, 3 July 2013 (UTC)[reply]

I just looked at 500 articlespace edits (via recent changes); there were 13 edits (2.6%) that were tagged as being done by visual editor. That doesn't look like "flooding" to me. And I suspect that as less experienced editors find out how problematical VE (still) is, the percentage will decrease. -- John Broughton (♫♫) 05:13, 4 July 2013 (UTC)[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%. [15] 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[16] 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]

Inputbox for moving userspace articles straight to articlespace

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

Since this involves moving pages, it seems like it'd need to be a separate user script. Theopolisme (talk) 07:30, 5 July 2013 (UTC)[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 [17] [18] [19] (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]

Monobook watchlist css

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

Strike this, I think I've solved it myself. Might not the be most elegant way but it appears to work. NtheP (talk) 13:32, 5 July 2013 (UTC)[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]

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]

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]

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]

Archive indexing

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

Er, yes. --Redrose64 (talk) 11:08, 6 July 2013 (UTC)[reply]

So why has Legobot not indexed the archives at Talk:Printed circuit board, set up on 14 June? Spinning Spark 11:26, 6 July 2013 (UTC)[reply]

Legobot hasn't updated any indexes since March 25th. -- John of Reading (talk) 20:59, 6 July 2013 (UTC)[reply]

The Indexerbot page claims, as pointed out by Redrose64, that Legobot is now doing the index work, but it isn't, as John of Reading points out. So now you all understand my problem, back to the original question - is there an alternative indexing service? Spinning Spark 22:33, 6 July 2013 (UTC)[reply]

Yes, ClueBot III can do indexing along with its archiving feature. Graham87 03:03, 7 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. 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]

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."
There is no way to suppress a footnote backlink. I have a bug report in for that, but it has gone nowhere.
The Shortened footnotes help page has examples of articles with good use.
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]

Lupin anti-vandal tool

Hi,

The User:Lupin/Anti-vandal tool is not showing up here even after following the instructions under User:Lupin/Anti-vandal tool#Installation. Please check if there is an error in my js file, or something of the sort, as I have force-reloaded the page and cleared my browser cache. --JustBerry (talk) 22:41, 6 July 2013 (UTC)[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 [20]. 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:[21] (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: [22]. PrimeHunter (talk) 13:19, 8 July 2013 (UTC)[reply]

This is the same problem that I noted above. --Redrose64 (talk) 17:50, 8 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]

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]

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]

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. [23]), 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 [24] 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]

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]

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]

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]

Tech news: 2013-28

Latest [[<tvar|technews>m:Special:MyLanguage/Tech/News</>|tech news]] from the Wikimedia technical community. Please inform other users about these changes. [[<tvar|more-transl>m:Special:MyLanguage/Tech/News/2013/28</>|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. [25]
- 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). [26]
Emergency priority CentralNotice banners will always be shown unless users have hidden them, ignoring cookies set for lower priority banners. [27]

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

tag (bug #8480). [28]

It will now be possible to create empty MediaWiki: messages, for instance in order to disable them (bug #50124). [29]
The Nearby feature will soon be enabled on Wikivoyage wikis again. [30]
The Notifications extension messages will now include a direct link to diffs on wiki as well as in notification e-mails (bug #48183). [31]
Table of contents will now use the HTML
element instead of , fixing a nine–year–old bug #658. [32]
First mock–ups of a mobile Wikidata application have been published by Pragun Bhutani as part of his Google Summer of Code project. [33]
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)

[Smith2010-1] Smith, S. (2010) Jones lies

[Jones2009-2] Jones, J. (2009) The truth

[1]

[2]

@@ Line 1,311: / Line 1,311: @@
 {{User|Johnmperry}} has drawn my attention to two edits ([http://en.wikipedia.org/w/index.php?title=The_Matrix_%28production_team%29&diff=563375836&oldid=550331146 one], [http://en.wikipedia.org/w/index.php?title=Baby_Princess&diff=563275148&oldid=562226977 two]) adding vast amounts of HTML tags mentioning, among other things, "google-src-text notranslate". Does anyone recognise this? -- [[User:John of Reading|John of Reading]] ([[User talk:John of Reading|talk]]) 18:20, 8 July 2013 (UTC)
+== [[m:Special:MyLanguage/Tech/News/2013/28|Tech news: 2013-28]] ==
+<div class="plainlinks mw-content-ltr" lang="en" dir="ltr">
+<div class="plainlinks mw-content-ltr" lang="en" dir="ltr">
+Latest '''[[<tvar|technews>m:Special:MyLanguage/Tech/News</>|tech news]]''' from the Wikimedia technical community. Please inform other users about these changes. ''[[<tvar|more-transl>m:Special:MyLanguage/Tech/News/2013/28</>|Translations]] are available.''
+'''Recent software changes''' ''(Not all changes will affect you.)''
+* [[mw:VisualEditor/Portal|VisualEditor]] news:
+** VisualEditor deployment [//en.wikipedia.org/w/index.php?title=Wikipedia%3AVisualEditor%2FFeedback&diff=563042612&oldid=563038914 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.
+** [[bugzilla:50356|A bug]] that made it impossible to save VisualEditor edits that triggered a CAPTCHA has been fixed. [https://gerrit.wikimedia.org/r/#/c/71160/]
+** Several bugs that occurred on right–to–left wikis have been fixed last week ([[bugzilla:49416|bug #49416]], [[bugzilla:49613|bug #49613]], [[bugzilla:50543|bug #50543]]).
+* Uploading files has been restricted on Meta Wiki to administrators and the newly created ''uploader'' group. An [[m:Meta:Exemption doctrine policy|exemption doctrine policy]] is being developed ([[bugzilla:50287|bug #50287]]). [https://gerrit.wikimedia.org/r/#/c/71252/]
+* Emergency priority [[mw:Extension:CentralNotice|CentralNotice]] banners will always be shown unless users have hidden them, ignoring cookies set for lower priority banners. [https://gerrit.wikimedia.org/r/#/c/71751/]
+'''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 <code><gallery /></code> tag ([[bugzilla:8480|bug #8480]]). [https://gerrit.wikimedia.org/r/#/c/60858/]
+* It will now be possible to create empty <code>MediaWiki:</code> messages, for instance in order to disable them ([[bugzilla:50124|bug #50124]]). [https://gerrit.wikimedia.org/r/#/c/71332/]
+* The Nearby feature will soon be enabled on Wikivoyage wikis again. [https://gerrit.wikimedia.org/r/#/c/71375/]
+* The [[mw:Echo (Notifications)|Notifications]] extension messages will now include a direct link to diffs on wiki as well as in notification e-mails ([[bugzilla:48183|bug #48183]]). [https://gerrit.wikimedia.org/r/#/c/64876/]
+* Table of contents will now use the HTML <code><div /></code> element instead of <code><table /></code>, fixing a nine–year–old [[bugzilla:658|bug #658]]. [https://gerrit.wikimedia.org/r/#/c/39792/]
+* First mock–ups of a [[mw:User:Pragunbhutani/GSoC 2013 Implementation Approaches|mobile Wikidata application]] have been published by Pragun Bhutani as part of his Google Summer of Code project. [http://lists.wikimedia.org/pipermail/design/2013-July/000729.html]
+* A discussion on [[mw:Manual talk:Coding conventions/PHP#Recommending some minimum documentation practices|minimum documentation practices]] in MediaWiki code has been started and awaits comments from the community.
+'''''[[m:Special:MyLanguage/Tech/News|Tech news]]''' prepared by [[m:Special:MyLanguage/Tech/Ambassadors|tech ambassadors]] and posted by [[m:Global message delivery|Global message delivery]] • [[m:Special:MyLanguage/Tech/News#contribute|Contribute]] • [[m:Special:MyLanguage/Tech/News/2013/28|Translate]] • [[m:Tech|Get help]] • [[m:Talk:Tech/News|Give feedback]] • [[m:Global message delivery/Targets/Tech ambassadors|Subscribe or unsubscribe]].''
+</div>
+</div> 18:33, 8 July 2013 (UTC)
+<!-- EdwardsBot 0519 -->