Jump to content

Wikipedia:Village pump (technical)

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Rhamusker (talk | contribs) at 15:54, 2 August 2013 (→Negative Image: new section). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

 Policy Technical Proposals Idea lab WMF Miscellaneous 
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.


Position of templatedata

Tracked in Phabricator
Task T52512
See also: Wikipedia talk:VisualEditor/TemplateData § Move to subpages? To new namespace?, and bugzilla:50512
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
  1. ...
At the bottom of the template's documentation page
  1. ...
In a separate "TemplateData" section on the template itself
  1. ...
In a separate "TemplateData" section on the template's documentation page
  1. 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]
  2. This seems a fairly nice and obvious page. I've been adding it just before the see also section. Documentation of templates is generally quite messy, no consistent style is used, they are often verbose, don't always contain examples or explicit lists of parameters and if they do they use a variety of formats. The template data section does allow a consistent style and in time could be a helpful way to standardise documentation. It does need to a bit richer though: allowing links, wikimarkup, support for explicit options (yes/no), a finer graduality of status: required/recommended/optional/not-recommended. Six months down the line it could become the documentation format; moved up the documentation pages replacing the current ad-hoc standards--Salix (talk): 08:34, 22 July 2013 (UTC)[reply]
On a subpage of the template titled "/templatedata"
  1. 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]
On a new namespace, specific for the JSON of templatedata

(This would be analogous to the new "Gadget definition" namespace used for the JSON of the gadgets 2.0)

  1. Helder 20:44, 29 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]
  • Unarchived by Redrose64 (talk) 08:09, 22 July 2013 (UTC)[reply]
  • All things being equal, i'd like tempaltedata to be on the same page as the template itself. there are several reasons for this, but they are not that important.
    thing is, all things are not equal. many of the templates are protected, and placing templatdata on the template page basically means only sysops/admins will be able to add and amend the templatedata.
    i'm in favor for placing templatedata in (yet another) subpage. i do not think the "doc" subpage is appropriate. we could do some "half and half" approach: put templatedata on the template page if the template is not protected, and on "templatedata" subpage if it is. peace - קיפודנחש (aka kipod) (talk) 01:47, 29 July 2013 (UTC)[reply]
The majority of the template data now seems to be on the /doc subpages. There are some cases where two templates use the same documentation, for example {{larger}} uses Template:Resize/doc for its documentation. This means the TemplateData needs to be in separate subpages, I've used /TemplateData. This discussion might be better at Wikipedia talk:VisualEditor/TemplateData.--Salix (talk): 07:15, 29 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]
      • @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]
              • 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]
      • @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

Note: See bottom of Special:Preferences#mw-prefsection-editing. There is now an option to "Temporarily disable VisualEditor while it is in beta".

Request for reopening: This was a unanimous poll! Adam Cuerden (talk) 14:22, 23 July 2013 (UTC)[reply]

RESOLVED
The request has been answered and a full opt-out is now available through the bottom option at Special:Preferences#mw-prefsection-editing. Red Slash 02:58, 29 July 2013 (UTC) I have a lot of sympathy for this and even voted in support, but WMF's Deputy Director, Erik Möller has said that they will not be offering an integrated option to disable Visual Editor, essentially for the reason that they don't want to make it easy to disable. See his comments: [1]. With more than 50 people offering support here and more than 1300 people already disabling Visual Editor via the gadget, I think the community's point has been plainly made. However, we don't control the Foundation and can't force them to implement this, which unfortunately makes this discussion moot. Dragons flight (talk) 18:06, 22 July 2013 (UTC)[reply]

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

Tracked in Phabricator
Task T52929
Resolved

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]
  • 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]
    • 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. Resolute 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 TalkDone 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 TalkDone 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 TalkDone 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, LindsayHello 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 ChatOnline 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. —Bruce1eetalk 05:08, 4 July 2013 (UTC)[reply]
  • Support I'm another with a slower system who found this imposed upon me with no easy way to disable it and nothing whatsoever on the Editing section of Preferences. Timrollpickering (talk) 15:16, 6 July 2013 (UTC)[reply]
  • Support Why is this a discussion and not common sense? I like the visual editor, I just don't want to ALWAYS use it. -- A Certain White Cat chi? 19:46, 6 July 2013 (UTC)
  • Support - I know it's summer but it's definitely SNOWing here. I haven't seen such clear, overwhelming consensus about anything in a long time - hopefully the WMF will take note for future... GiantSnowman 10:56, 9 July 2013 (UTC)[reply]
Actually I've never seen such clear and overwhelming ignorance as the WMF is currently expressing by not seeing this consensus. I'm sad to say it but I'm deeply disappointed with their work. The atmosphere is freezing here! --Patrick87 (talk) 11:28, 9 July 2013 (UTC)[reply]
  • Support and even strong support as currently VE is more damageable than useful, but still support after bugs are fixed and features redesigned to be useful because every user can choose by himself if he wants the overhead of VE or not. --NicoV (Talk on frwiki) 16:38, 9 July 2013 (UTC)[reply]
  • Support, of course. Opt-out should be provided piece of the software and not something we have to hack together on after the fact. Dragons flight (talk) 16:59, 9 July 2013 (UTC)[reply]
  • Support, I'm shocked at how slowly and poorly this thing works for something being foisted on all editors as ready to use. Nor do I personally have any desire to spend my time learning how to do things with it that I already know how to do in normal editing, as I've found the VE remarkably unintuitive. As commented by many above, turning it off needs to be easy and complete. postdlf (talk) 17:19, 9 July 2013 (UTC)[reply]
  • Support. Obviously, especially when the VE is likely to lose editors rather than gain some. the effect it has on one new editor. I'm wondering how many thousands of others feel like this. Kudpung กุดผึ้ง (talk) 00:46, 10 July 2013 (UTC)[reply]
  • Support - The new JS loads slowly and the extra tabs clutter the appearance of pages; in what world do you add a clunky, bug-ridden 'feature' to the core productivity area of your site and not provide the option to properly disable it? FLHerne (talk) 17:03, 10 July 2013 (UTC)[reply]
  • Support - This would be especially useful for editors with slow internet connections and us WikiNerds who want to edit their plain markup. Furthermore this shouldn't have been ruled out without an option to properly and completely turn it off. -- Toshio Yamaguchi 13:48, 11 July 2013 (UTC)[reply]
  • Support While have have it hidden, I still have the issues where my browser (Firefox and Chrome) freezes or crashes. Bidgee (talk) 13:51, 11 July 2013 (UTC)[reply]
    • There is no way in heaven that that can be related to either the VE init script or the VE hide script. These two scripts are so minimal now, I can't imagine for the life of me that they would cause a crash. (ULS seems more likely). —TheDJ (talk • contribs) 14:56, 11 July 2013 (UTC)[reply]
      • I don't have the problem until I load the English Wikipedia, it didn't have the issue before the VE rollout and I don't have the issue on Commons. It maybe "minimal" but it causes the freezing and crashing of the browser on all of my computers (not just one). Bidgee (talk) 15:46, 11 July 2013 (UTC)[reply]
        • Bidgee, you only seem to be active here, at Meta, and at Commons. Universal Language Selector, which was unfortunately turned on the day after VisualEditor, is configured differently at multilingual projects (e.g., Meta and Commons) than it is at the Wikipedias. It would be very helpful if you would try to see whether you have the same problems at another Wikipedia, like de.wikipedia (where VisualEditor has not been made available to all users yet). If you get the same problems there, it's almost certainly ULS. Additionally, it would be helpful to have browser and OS information if you continue experiencing problems. Whatamidoing (WMF) (talk) 21:33, 11 July 2013 (UTC)[reply]
          • It is clearly a VE issue, I have no issues with de.wikipedia and simple.wikipedia. OS X 10.8.4 running Firefox 22.0 and Chrome 28.0.1500.71, My Windows 7 desktop and laptop both have latest updated browsers (FF 22 and C 28.0.1500.71 m) and have the same issue with English Wikipedia as the OSX. Bidgee (talk) 05:58, 12 July 2013 (UTC)[reply]
  • Support should be able to be turned off and on by the user like many other features. — MrDolomite • Talk 17:57, 12 July 2013 (UTC)[reply]
  • Support I tried it, but it was way too slow for my computer, and I couldn't figure out how to include simple wikitext without having to click at a lot of places, wasting a lot of extra time. I immediately disabled it, but it still takes extra time to load articles. I've considered disabling JavaScript for English Wikipedia, but this would sadly also disable essential tools such as WP:TW. --Stefan2 (talk) 19:48, 15 July 2013 (UTC)[reply]
  • Support; also, make VE better please. It needs to be the way of the future. I made an edit (wikitext) to United States the other day and it was essentially impossible because there are roughly 500 kajillion citations on the page. It was almost impossible to see where the article text was in the editing box because it was so drowned in citations. VE would've made that a LOT easier. Please. Get VE fixed. Red Slash 19:20, 18 July 2013 (UTC)[reply]
  • Support. I'm actually somewhat astonished that the opt-out preference has not been added yet. The arguments seem to boil down to this:
    Core user: "VE is not helpful, I don't want to use it, please let me turn it off."
    WMF: "If we allow core users to disable VE, then we won't get the feedback we need to improve VE."
    Here's the flaw in that reasoning: If people don't want to use VE, they're not going to, and making it harder for them to not use it isn't going to make them want to use it more. If feedback on this feature is so important to you that you're willing to ignore unanimous consensus from the community of core editors to try to get it, shouldn't it also be important enough that you would be willing to, say, hire testers? I really don't understand how you guys came to the conclusion that the only way to get the feedback you need is to deny editors the option of not giving feedback. --Cryptic C62 · Talk 00:42, 19 July 2013 (UTC)[reply]
  • Support. This "we know what's good for you" attitude is disgraceful. Stifle (talk) 15:18, 20 July 2013 (UTC)[reply]
  • Support. WMF/the devs should have used the feedback you received during the voluntary test phase and not made it the default until it was adequate. Making it easy to turn off and stopping it from hobbling those on less than superb machines and connections is the least they can do to make up for what they did instead. Yngvadottir (talk) 18:34, 20 July 2013 (UTC)[reply]
  • Strong support. The option to disable Visual Editor should not be buried under the gadgets tab but should be listed under the "Editing" tab, where all the other options for disabling various aspects of editing exists. As far as discoverability goes, I had to dive into the village pump to find the link to show me the section in the preference pane to disable VE. Agree that it would be ideal if background loading could be disabled, but to me the main issue is that VE disable option is not under the Editing tab. The main reason why I want to disable VE UI, or the straw that broke the camel's back, is the annoyance caused by trying to select an article section text only to have the "[edit]" link morph into "[edit | edit source]" upon mouse hover over. The innocent mouse gesture for selecting text is blocked now by the hover over UI (not friendly to tablets) for a feature that I don't use. But that really shouldn't matter what my particular reason to want to disable VE was. What should matter is there are people out there who want to disable VE and Wikipedia should support those users better. Food for thought. --Makkachin (talk) 13:19, 21 July 2013 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

For what it worth the bug has been reopened, and a discussion is continuing at Wikitech-l.--Salix (talk): 20:00, 22 July 2013 (UTC)[reply]

  • I hate to say that, but what kind of bullshit is this? Sorry Eric, but the day the WMF ignores such crystal clear consent is clearly the day the WMF fails it's job. Do you really want this day to be today? Are you actually realizing you're making all Wikipedia editors to nonvolunteer beta-testers with your actions? How can you take yourself serious with such actions?
For my part VE will never ever be able to replace a markup editor – no matter what you do to tweak it (after endless input of thousands of in volunteer beta-testers). I'm using LaTeX in my day to day work (as does almost every physicist, and they do this for a reason). I'll be happy to consider going into details – as soon as WMF will remember their duties (and not ignoring the community is clearly one of those!). --Patrick87 (talk) 22:26, 22 July 2013 (UTC)[reply]
Unanimous agreement the thing should be turned back on, but the WMF are ignoring it? Eric Möller's views should not be more important than the unanimous agreement of the users. Adam Cuerden (talk) 14:22, 23 July 2013 (UTC)[reply]
You could tell Jimbo - his talk page went from this to this in 24 hours. There's been plenty more since, as people have realised that he's back off hols. --Redrose64 (talk) 18:25, 23 July 2013 (UTC)[reply]
So how does the VE identify an unsupported browser? If it looks at the browser identification string, there are ways to change that. (I typed "change identification string in browser" into Google & found a useful howto that way.) The WMF might have to bow to community dissatisfaction when over 50% of the browsers viewing Wikipedia are, say, "Death to VE". -- llywrch (talk) 23:14, 23 July 2013 (UTC)[reply]
Can we configure browsers to pretend that they are NeXT? --Redrose64 (talk) 23:25, 23 July 2013 (UTC)[reply]
Yebbut, the Foundation is pointedly not listening to clear signs a large number of Wikipedians don't want VE. Maybe providing numbers thru configuring browser ids might make them listen. That--or all active editors stop contributing, which would be the final & extreme response.--llywrch (talk) 04:49, 24 July 2013 (UTC)[reply]
They didn't listen to the strong support for sign-in-to-edit either. The WMF is Mother, the WMF is Father, and we have always been at peace with VisualEditor. - The Bushranger One ping only 08:09, 24 July 2013 (UTC)[reply]

"Opt-out" being re-enabled

James D. Forrester wrote on the mailing list last night:

Because I understand the level of concern that this matter is causing, I

am changing my mind on this. For the duration of VisualEditor's "beta" period, there will be an opt-out user preference. This will be deployed tomorrow morning, San Francisco time. Once VisualEditor is out of 'beta', this preference will be removed.

As others have explained better than I, we think that users will be ill-served by this opt-out, and I hope that as few users as possible will choose this way to degrade their experience and deprive the community of their input. Instead of endlessly arguing the point about this, I'd rather

my team and I spending our time working to make our sites better.

I personally would like to see this option enabled indefinitely, but this is better than the current situation! Zell Faze (talk) 13:02, 24 July 2013 (UTC)[reply]

The mindset behind this message is saddening. VE is, at best, a change. The idea that disabling VE represents choosing to "degrade" the user experience represents an astonishing level of hubris and a severe disconnect with the reality of the situation.—Kww(talk) 16:36, 24 July 2013 (UTC)[reply]
More in meta:Help:Preferences, specifically, the last change in this edit. --Redrose64 (talk) 16:43, 24 July 2013 (UTC)[reply]
on hewiki, i changed the silly message("Temporarily disable VisualEditor while it is in beta") to just "Disable Visual Editor". i had to translate it anyway, and did not see a good reason to carry the "while in beta" part with the translation. if/when the VE team will try to kill this preference again, then we'll have another fight - i do not see good enough reason to start this war now. personally, i write down the "while in beta" part of the phrasing to hurt ego of a developer who finds it too difficult to admit he was wrong. peace - קיפודנחש (aka kipod) (talk) 19:06, 24 July 2013 (UTC)[reply]

Sorry, but this is eye-wash. Do you realize this is only a temporary measure to calm down most of the upset editors? After the "beta" period (whatever means "beta" for WMF – since when "beta" software is enabled by default for everyone?) the setting will be gone and we'll have the exact same discussion again.

Furthermore this step is complete nonsense in my opinion. WMF argued, that they want us to use the VE so we give feedback and it is possible to improve the product for everyone. Now the option to diable the VE is given in the "beta" phase (where input would be needed most) but will be gone when VE gets "stable" (when input shouldn't be that necessary anymore).

The whole thing looks like a confusion and obfuscation tactics to me... --Patrick87 (talk) 20:05, 25 July 2013 (UTC)[reply]

If I am 'degrading' the experience by removing a buggy piece of software and allowing full editing of wiki markup then so be it. Has WMF been taken over by EA or something? PantherLeapord (talk) 02:32, 26 July 2013 (UTC)[reply]
Why I'm sceptical about this "opt-out": "This option is recommended, as it will automatically give you a chance to try VisualEditor again when it's more developed and fully-featured." Manxruler (talk) 08:58, 26 July 2013 (UTC)[reply]

When will it be enabled?

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

It is out. If you try to edit an article and don't see both and "Edit" and "Edit source" tab at the top of the page, then your browser is not recognized as supported. (Note that VisualEditor is only present on article and user pages right now.) Firefox 22 should be supported, but possibly PortableApps changed the identification string in a way that Mediawiki doesn't recognize. I'd suggest asking at Wikipedia:VisualEditor/Feedback. Dragons flight (talk) 20:37, 6 July 2013 (UTC)[reply]
A bit of waiting, and it is now working. Thanks for the help. George8211 14:52, 8 July 2013 (UTC)[reply]
I'm using chrome and there isn't any differences?--Gilderien Chat|List of good deeds 13:47, 21 July 2013 (UTC)[reply]
I've just spent three days using Firefox 3.6.6, which doesn't offer me the chance to use VE: it's so much easier when every "edit this page" tab or "[edit]" link behaves the same regardless of namespace. Now I'm back on Firefox 22.0 and I've already hit the wrong link three times. How do I downgrade FF from 22.0 to a version that doesn't support VE? --Redrose64 (talk) 13:30, 23 July 2013 (UTC)[reply]
@Redrose64: You don't need to change browsers - just go to your Preferences, then the Gadgets tab, and then the Editing section - you'll see an option to hide VE regardless of what browser you're using. (Remember to save your change.) -- John Broughton (♫♫) 03:27, 24 July 2013 (UTC)[reply]
Oh yes, I've done that, but it still loads - I can tell because when I go to a page, the tabs flick about as the various Javascript components kick in and then countermand each other. Occasionally my PC complains that Firefox is using excessive memory. I would like to reduce the number of times that this happens by dumping Javascript that I don't need. --Redrose64 (talk) 07:55, 24 July 2013 (UTC)[reply]
Then you should really look elsewhere for ways to improve your system's performance. The "load" from VE is 4KiB, or about 0.5% of what you get when you read one Wikipedia article, and it only loads about once a week (unless you clear your cache sooner). I run NoScript on Firefox, and that makes a much, much bigger difference than any change to VE ever could. Whatamidoing (WMF) (talk) 18:16, 24 July 2013 (UTC)[reply]

Login glitch?

This doesn't happen consistently, but twice, including today, when I logged in, I got some sort of weird screen. Both times, it has happened when logging in from the Main Page (not sure if it's related). I think it's the same thing because it looks similar, but I didn't record it last time. Anyway, after inputting my password, I hit enter; I then see a screen with the url http://wikimediafoundation.org/wiki/Special:CentralLogin/start?token= (I have left out the token string in case this is sensitive information about my account I shouldn't be revealing; suffice it to say it was a 32 character string consisting of both numbers and letters), which displays as a white screen which looks somewhat like this (the links appeared to be Wikilinks, not EL):

in the wiki [r]" accesskey="r">Recent changes


Toolbox


I notice that I no longer am directed to a page that says "you are now logged in" (or whatever it used to say). I'm using IE8. Add Forgot to say that regardless of this error, I am still logged in, if I navigate to any Wikipedia page after this, or even press the back button. Just logged out and back in and did not encounter issue. Brambleclawx 14:32, 22 July 2013 (UTC)[reply]

Please see #New Single User Login system, login success page going away above. --Redrose64 (talk) 14:57, 22 July 2013 (UTC)[reply]
Yes, I assumed that. Doesn't explain why on two occassions it decided not to redirect me to the Main Page and instead stopped on some foundation page (which appears to be connected to the login process). Brambleclawx 15:16, 22 July 2013 (UTC)[reply]
The problem you are reporting sounds like a potential issue in the code of the MediaWiki software or the server configuration. 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 "CentralAuth") by following the instructions How to report a bug and providing additional information (used browser and version, etc). 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) 08:18, 23 July 2013 (UTC)[reply]
I can't reproduce reliably. It just happens once in a while. Brambleclawx 14:42, 23 July 2013 (UTC)[reply]

I also saw it, I was taken to https://login.wikimedia.org/wiki/Special:CentralLogin/start?token=token code···Vanischenu「m/Talk」

More info, but might be useless
Just a few minutes ago, I was taken to https://login.wikimedia.org/wiki/Special:CentralLogin/start?token=code. When I tried to type CentralLogin on the address bar of browser, https://en.wikipedia.org/wiki/Special:CentralLogin/complete?token=token code also came up along with the above. (these token numbers are different each time, but 32 characters long, and both the pages showed the message "The provided authentication token is either expired or invalid." in red). Since login.wikimedia.org was already mentioned in that thread, it might be associated with the new central log in system. (and account creation started there only after 8 May 2013) (Special:CentralLogin is not new, and it can be used for completing my logging in to sister projects eg, if I went offline before the logging in is complete) A search on google took me to mw:Auth_systems/SUL2 and [2], but I can't understand anything from it···Vanischenu「m/Talk」 09:40, 28 July 2013 (UTC)[reply]
"The provided authentication token is either expired or invalid" when you revisit the page is expected: the token is only valid for a short time, and is removed as soon as it's used. BJorsch (WMF) (talk) 11:47, 28 July 2013 (UTC)[reply]

Google indexing sandboxes?

I was astonished to discover that Google is indexing my sandbox. I'm sure there's been controversy about whether user page and user talk pages should be indexed, but it seems to me that there should be no controversy here, given what the sandbox is for. (I actually don't believe that. Of course there will be controversy.) So, should sandboxes (and their subpages) be by default not indexed, without the user having to do anything to make it that way? EEng (talk) 22:47, 24 July 2013 (UTC)[reply]

By default User: pages are indexed; it's opt-out. Personally I use {{userpage|noindex=yes}} on my main user page and {{User Sandbox}} on my sandboxes; but a simple __NOINDEX__ will also work. --Redrose64 (talk) 23:01, 24 July 2013 (UTC)[reply]
Look, I know all that. I didn't ask how to make my sandbox unindexed. What I said is that perhaps sandboxes (which are specifically for drafts, experiments, and other stuff clearly not for public consumption) should be unindexed by default. As an alternative maybe an edit notice on sandboxes should remind the user that the content is indexed by default and explain (as above) how to block indexing; in fact maybe such an editnotice should pop up for all userspace pages -- sandboxes for sure. Just a thought. EEng (talk) —Preceding undated comment added 23:47, 24 July 2013 (UTC)[reply]
Is it currently possible to noindex user sandboxes which don't have __NOINDEX__ on them, and without noindexing all of userspace? It doesn't appear from http://www.robotstxt.org/robotstxt.html that our robots.txt at http://en.wikipedia.org/robots.txt can say something like "For all *, noindex en.wikipedia.org/User:*/sandbox". Does MediaWiki have a feature to automatically add a noindex tag to each such page? Not that I'm aware of. PrimeHunter (talk) 00:11, 25 July 2013 (UTC)[reply]
One other point (just to give a specific motivation): that "temporary" BLP violations are tolerated in userspace drafts, and that userspace is generally below the radar for patrolling and whatnot, are both additional reasons such stuff shouldn't be indexed. But putting it that way, almost everything in userspace shouldn't be indexed since it's hard to tell what's an article draft and what's something else. Dunno. Just pointing out a potential problem. EEng (talk) 04:35, 25 July 2013 (UTC)[reply]
The problem here is there is not entity called 'sandbox'. It's simply a subpage of a userpage. These are indexed by default. Getting them non-indexed (by default) from the English wikipedia setup is indeed rather difficult I think. I can't find any interface messages that are included an such a page that we could abuse for it. And wildcarding is also not possible. —TheDJ (talk • contribs) 08:35, 25 July 2013 (UTC)[reply]
"Temporary" BLP violations are not tolerated in userspace drafts: the BLP policy also applies to user and user talk pages. That some slip under the radar indicates either that recent changes patrollers are not aware of the policy, or that they are not patrolling everything they should: by default, Special:RecentChanges lists all namespaces, so it takes a conscious effort to patrol only, say, articles in mainspace. --Redrose64 (talk) 14:37, 25 July 2013 (UTC)[reply]
You're nuts if you think a userspace subpage tagged "under construction" is going to be held to the same standard as live articles. But forget BLP -- it was just one specific consideration. Anyway, I was making a suggesting that I thought would improve things. If it's not technically feasible, that's that. But pretending that the status quo is just fine might be called looking at things through redrose-colored glasses. EEng (talk) 21:03, 25 July 2013 (UTC)[reply]
I don't 'think a userspace subpage tagged "under construction" is going to be held to the same standard as live articles'; but that's not what I said. My point was that WP:BLP applies everywhere - it's not selective. This is because some people just don't appreciate that once something has been posted on the internet, it's there for all the world to see, and there's nothing that can be done to turn back the clock. An internet page is a published work, even if it's still in draft; libel is libel, regardless of where or how it's published. --Redrose64 (talk) 22:24, 25 July 2013 (UTC)[reply]
Oh, for heaven's sake! (a) if you really think it doesn't matter where and how something potentially libelous is published, you really don't know what you're talking about; (b) not that it matters, because BLP was just a side point, as already mentioned. I'm sorry I bothered to make the suggestion. EEng (talk) 03:15, 26 July 2013 (UTC)[reply]
You asked a question; I tried to help; I might not have asked for thanks, but I certainly didn't ask for my advice to be stuffed right back in my face. But it seems that you have some problem with me. --Redrose64 (talk) 11:20, 26 July 2013 (UTC)[reply]

Since you bring it up I'll explain. There have been three times, to my memory, that I've made posts outlining (a) the way things are; and (b) why I think it would be an improvement to change that in some way. All three times you've appeared to recapitulate the way things are, ignoring the change I suggested.

  • Example above: I said that sandboxes are indexed by default, and should be unindexed by default. You responded by explaining that Sandboxes are indexed by default (which is what I had just said in my original post, and was clearly the reason I made that post) and how I could make my sandbox unindexed, which completely missed the suggestion I was making, which is that they should be unindexed by default.
  • In the earlier discussion you linked [3], I pointed out that < reflist > outputs its entries in essentially random order, and that it would useful to be able to control that order, but still get the automatic numbering etc of the < ref > machinery. You responded by explaining that < reflist > outputs in essentially random order (which I obviously already knew, because I said so in my original post) and pointed me to a help page describing a completely unworkable, fragile approach requiring manual numbering of everything, so that if any cite is inserted or deleted all the other numbers have to be manually adjusted throughout the article -- as if somehow that answered the proposal of my post
  • In yet another discussion [4], I asked how, when using a citation template, one might include multiple ISBNs (as when there are paperback and hardcover editions with identical pagination, which is very common). Instead of just explaining how to do it (which eventually turned out to be very simple) you and others put a lot of effort into explaining why I shouldn't want multiple ISBNs in one citation. It's infuriating for some research-naive macro-expert technocrats to withhold details on how to do something because their erroneous ideas convince them I should "only supply the ISBN of the volume I actually consulted".

In sum you have an annoying habit of trying to explain why people shouldn't want to do what they want to do, or should get along with current painful and inadequate facilities, instead of addressing the request being made. EEng (talk) 23:42, 28 July 2013 (UTC)[reply]

Sandboxes are noindexed by default. A page that doesn't have {{user sandbox}} isn't a sandbox, it's a subpage; the software can't magically know what you intend to use a subpage for. (As for the rest, could the two of you please take it to WP:DR or something?) --NYKevin 13:21, 2 August 2013 (UTC)[reply]
Defining the problem away doesn't solve the underlying problem. I was aware of the definitional problems from the beginning. At this point my recommendation would be that User: and User Talk: spaces simply be unindexed, period (or at least by default) -- not sure what purpose is served by indexing user page and user talk pages anyway, and this solves the sandbox problem too. If something is ready for public consumption, it ought to be in article space. But I've put much more effort into this minor issue than I care to. BTW there's no dispute between me and RedRose -- he sensed I'm annoyed with him so I explained why. EEng (talk) 15:05, 2 August 2013 (UTC)[reply]

Did something just change with redirects?

I had just finished doing the edit request at Template talk:R unprintworthy#editprotected which changed the wording under the redirect. However when I went to check at Alfred C. Kinsey no wording appeared. Just the redirect. I'm sure there was something written the moment before. Theres also no wording for templates using other redirect templates like Alumna.

Should the text appear after the redirects? Or are my eyes deceiving me.--Salix (talk): 08:11, 25 July 2013 (UTC)[reply]

From Help:Redirect, "Any text appearing after the redirect link will be ignored in the display". I think this is standard. -- John of Reading (talk) 08:25, 25 July 2013 (UTC)[reply]
Yeah, when I want to be sure I've added the right templates to a redirect I add a space after the hash (#) before REDIRECT and preview the page. (And just like my !ref> test I'd like a personal edit filter that would stop me from forgetting to remove that space before submitting :-) ) Mark Hurd (talk) 15:05, 30 July 2013 (UTC)[reply]

Proposal: English Wikipedia should set up a sitenotice explaining how to turn VisualEditor off.

Summary: Per the poll a bit above, the Editing preference to disable VisualEditor has been reenabled. We should have a sitenotice letting people know of this change.

Visual Editor is a controversial new WYSIWYG editor being produced by the WMF. However, despite greatly changing the site interface, most notably making it much more difficult to edit sections in wikitext (whilst VisualEditor is unable to edit a single sections itself, no less! See WP:VE#Limitations), no preference to allow it to be used at launch was available. According to a statement by User:Romaine on the Dutch Wikipedia, the WMF had promised an opt-out option, and, indeed, our own FAQ (which was not written by the WMF, as they like to point out) promised the ability to turn it off until 10 June ([5]).

Further, the developers have announced that bugfixing is expected to slow immensely over the month of August, due to Wikimania.

Since the community gave unanimous support to a preference, and this is now available, but likely is not widely known, I think we have a duty to our users to explain how to turn Visual Editor off in preferences, and a sitenotice is warranted. Adam Cuerden (talk) 14:03, 25 July 2013 (UTC)[reply]

  • Support Adam Cuerden (talk) 13:59, 25 July 2013 (UTC)[reply]
  • Support. Sitenotices are appropriate only for emergencies and announcements that are significant for everyone, and this really is an announcement that affects everyone. Some things that affect everyone don't need Sitenotice announcement, e.g. when we switched from Monobook to Vector: it was a (major) cosmetic change, but not something that required action or offered the possibility of action for everyone. Nyttend (talk) 15:11, 25 July 2013 (UTC)[reply]
  • Support: I should imagine a lot of editors would be more comfortable continuing to use the old system, and so would welcome instructions on how to return to it. It Is Me Here t / c 15:13, 25 July 2013 (UTC)[reply]
  • Support this is a major issue which is likely to be of interest to even very casual editors. Hut 8.5 15:25, 25 July 2013 (UTC)[reply]
  • Support Yngvadottir (talk) 15:29, 25 July 2013 (UTC)[reply]
  • Comment I'm neutral on the need for this, but any notice must be neutrally worded and note that the preference is likely to be disabled in the future. Thryduulf (talk) 15:40, 25 July 2013 (UTC)[reply]
    The name of the preference should be enough to make it clear it may be disabled in future. I agree the wording will need to be very neutral, and should basically state what VE is, and then say something like "We hope you've been enjoying the VisualEditor experience, but if you prefer to opt-out, it may be turned off by etc" Adam Cuerden (talk) 16:18, 25 July 2013 (UTC)[reply]
  • Support. I don't think I need to say much. Insulam Simia (talk) 15:51, 25 July 2013 (UTC)[reply]
  • Support - Participation in WMF's ill-considered software debugging endeavor should be voluntary. It was a grave misstep to have forced Not Ready For Primetime software on En-WP; this is insufficient damage mitigation, but a good first step. Carrite (talk) 15:52, 25 July 2013 (UTC)[reply]
  • Support - I managed to turn VE off on day 1 so have avoided the problems others have had, but it would be good to make things easier for everyone by explaining how to do it. Ghmyrtle (talk) 15:55, 25 July 2013 (UTC)[reply]
  • Support , obviously. -- cyclopiaspeak! 16:09, 25 July 2013 (UTC)[reply]
  • Support; this affects everyone. — Scott • talk 16:12, 25 July 2013 (UTC)[reply]
  • Oppose. both the introduction of this proposal (VE is not "controversial") and the idea of creating sitenotice telling people to turn off VE. instructions for turning it off should definitely be in all the appropriate Help pages, but i do not think this is an appropriate item for sitenotice. peace - קיפודנחש (aka kipod) (talk) 16:15, 25 July 2013 (UTC)[reply]
  • Comment I agree we need to let users know, but a sitenotice is likely to be more disruptive than is necessary. Why not just include it in the help documentation that is linked to from the VisualEditor? That way we avoid bothering users who are comfortable with it, or who have learnt to simply ignore it. At the same time, the preference is temporary - only for the length of the beta period. In some ways driving everyone towards it would be a bad thing because it will lead to heightened disruption when it is removed. Okeyes (WMF) (talk) 16:43, 25 July 2013 (UTC)[reply]
    • Simply put, the word "VisualEditor" appears nowhere on the editing interface, and, therefore, the help is essentially invisible. One would need to luck onto the right name, and know that it updated 25 days after VE's launch. Adam Cuerden (talk) 18:27, 25 July 2013 (UTC)[reply]
      • That doesn't parse for me, I'm afraid :/. You don't need to know that it's called the VisualEditor to see the universal symbol for "help" in it. In fact, I'd argue this is far superior to knowing its name given the number of casual users we have who aren't necessarily interested in metapedian spaces. Okeyes (WMF) (talk) 18:36, 25 July 2013 (UTC)[reply]
        • I went into VE and looked. two problems: First of all, it froze Firefox for a few seconds, and second, the circled questionmark does not scream help to me. I've never seen that used as a help icon before. I mean, knowing there was a help icon, I could find it, but if I didn't know that, I'd probably presume it was the referencing tool (VE does have a referencing tool now, right? As hinted above, I really can't use it). But, any, back to the point. If VE doesn't work for you - you're on a screenreader, it freezes your browser on load, or the like, you're not going to be looking around in the VE interface for a way to turn it off. Adam Cuerden (talk) 18:45, 25 July 2013 (UTC)[reply]
    • That presumes that the Visual Editor will ever leave beta, and that the community will accept having the preference taken away. I assumed that the temporary nature of this change was just posturing. There's no reason to ever force people to enable VE if the WMF truly intends to keep its promises in regard to not disabling wikitext.—Kww(talk) 18:48, 25 July 2013 (UTC)[reply]
  • Oppose per kipod above. Seriously guys, give it a break, the preference is now available precisely where all other preferences are and should be and anyone with half a brain will be able to find it. Matma Rex talk 18:40, 25 July 2013 (UTC)[reply]
  • Oppose not needed; "preferences" is a reasonable place to look by default. VQuakr (talk) 18:45, 25 July 2013 (UTC)[reply]
  • Support The instruction sheet needs to include instructions to IP editors on how to disable it as well. I've found that AdBlock will do it using a filter rule of "modules=ext.visualEditor". There must be similar techniques that IP editors can use with different browsers and ad-blocking software.—Kww(talk) 18:47, 25 July 2013 (UTC)[reply]
  • Oppose nobody needs to switch this off, you can as easily click on edit source to enter the wikiedit interface. If, and it's a very large if, there is a need for a site notice, it should be neutral and point out that there are two tools for editing and how you can edit using either at the editor's choice. NtheP (talk) 18:55, 25 July 2013 (UTC)[reply]
    • "Easily"? Hovering over edit and waiting to be able to click "edit source" is easy? When accidentally clicking on the VE option freezes up your computer? If you have a good computer, great for you, but please think of those of us who don't. Adam Cuerden (talk) 19:08, 25 July 2013 (UTC)[reply]
  • Oppose. Sitenotices becomes less useful as they are used more often, as overuse simply leads to viewers ignoring the notices. The core users who really care about the issue already know about the preference by now, and everyone else who wants to turn it off later will find out how through the documentation pages or by asking someone. Not enough users would really benefit from a sitenotice for it to be worth using in this case. --Cryptic C62 · Talk 19:00, 25 July 2013 (UTC)[reply]
  • Not really seeing the point. Might be worth sending through a bot to notify those who enabled the gadget that the preference is now available again (although that may be considered private information and thus not a list that can be made public), or to modify the wording associated with the gadget directing people to the preference. Risker (talk) 19:05, 25 July 2013 (UTC)[reply]
  • How else would you reach IP editors that require the use of alternate techniques to disable it?—Kww(talk) 19:10, 25 July 2013 (UTC)[reply]
    • Why on Earth would you require reaching IP editors to disable it? "Edit source" is available to all users, and VE adds 2.6KB JavaScript footprint when not used.--Eloquence* 19:37, 25 July 2013 (UTC)[reply]
      • I keep VE on solely to work with reported bugs, Eloquence. If I didn't, I would disable it in a flash (and I keep the AdBlock setting handy so that I can disable it when I want to work without it getting in the way). To have the "edit" control for a section lead me to VE unless I remember "don't move your mouse to where the control is, move your mouse to 3 centimeters to the right of where the control is, and the control you actually want will magically appear" is abominable. New IP editors would also be genuinely surprised to learn that the default editing button takes them to a beta tool that can't successfully edit many Wikipedia articles. That WMF decided to roll this tool out to new editors is a problem I do not have the power or influence to solve. I can at least try to get the information out to help them deal with the problem that WMF has created. Better yet, WMF could simply make beta software an opt-in experience, which is what should be done for betas.—Kww(talk) 20:00, 25 July 2013 (UTC)[reply]
  • Oppose. Completely inappropriate use of the sitenotice. Use a watchlist notice at the very most. --Yair rand (talk) 19:18, 25 July 2013 (UTC)[reply]
  • Oppose I see no reason why we need a sitenotice. The metapedians who are angry about this have already turned it off or know where to look and it has long been held that IP editors get the standard version of everything. If and IP editor wants to change the interface we have a app for that. --In actu (Guerillero) | My Talk 19:27, 25 July 2013 (UTC)[reply]
    • "Metapedians"? That's dismissive, divisive, and an inaccurate characterization of what is very widespread dissatisfaction and concern over VE and how it has been implemented. My article space rate is nearly twice yours (as is Kww's, Carrite's...); should our !votes count for more than yours then? Or we could all whip out our edit counts like schoolboys. postdlf (talk) 21:38, 25 July 2013 (UTC)[reply]
      • Metapedians are people who know about Wikipedia's internal processes: if a person has over 1k edits to the projct space, over 100 posts to ANI, uses our internal three letter acronyms, is an admin, can name half of the people on arbcom, knows what NEWT is, reads the signpost, or knows where to look on the toolserver to look up the edit count breakdown they are a metapedian. Content creators, in the buzzword sense, are a subset of the group. The opposite of a medapedian is someone who chips away at a few articles in a small section of the encyclopedia and never to very rarely gets involved with the internal processes of the community. --Guerillero | My Talk 23:34, 25 July 2013 (UTC)[reply]
  • Oppose Inappropriate use of sitenotice. Per Matma Rex as well. Legoktm (talk) 19:46, 25 July 2013 (UTC)[reply]
  • Oppose sitenotice; Though a watchlist notice could be ok. →AzaToth 19:51, 25 July 2013 (UTC)[reply]
  • Oppose sitenotice. Watchlist notice might be nice. —TheDJ (talk • contribs) 21:27, 25 July 2013 (UTC)[reply]
  • Support. The more we can empower contributors by giving them information and choices about which tools they can use the better. It should never be a higher priority to push a particular tool. postdlf (talk) 21:38, 25 July 2013 (UTC)[reply]
  • Oppose. As others have said, a site notice is the wrong mechanism for this. I agree though that it should be widely advertised (e.g. watchlist notice and other tools / documentation). Dragons flight (talk) 21:57, 25 July 2013 (UTC)[reply]
  • Support Absolutely. Manxruler (talk) 23:07, 25 July 2013 (UTC)[reply]
  • Comment: Not sure what good it would do, given the apparent invisibility of the BIG RED EDIT NOTICE at the top of this page redirecting VE stuff to WP:VE/F. —[AlanM1(talk)]— 23:14, 25 July 2013 (UTC)[reply]
  • Oppose. Absolutely pointless!, There's plenty of info here telling you how to turn it off!. -
    →Davey2010→→Talk to me!→ 23:44, 25 July 2013 (UTC)[reply]
  • Oppose. There were some issues with the way the WMF rolled out VE, that much is obvious. Whatever, they got overly enthusiastic, and were slow to react to consensus. Water under the bridge; let's hope they've learned their lesson for next time. As someone said above, anyone who cares enough to turn off the VE has presumably already done so. I'd venture that if we had a sitenotice saying "Hey, you can turn off this feature now", the overwhelming response from newbies would be "Why on Earth would I want to do that?" At this point, the only thing I could see myself supporting is some topic-bans for the users who are constantly whining about the fact that they have to move their mouses one inch to the right to edit the old-fashioned way. (To be clear, I make use of source editing quite often myself, and I personally think that the VE is buggy enough that I'd just as well avoid it for the time being, except for little edits. But I've had months of experience {{{[[#<small>[<u>editing wikitext</>~~~'''''----*:#; . Most people who read Wikipedia have not.) — PinkAmpers&(Je vous invite à me parler) 01:58, 26 July 2013 (UTC)[reply]

Comment

Is there recruiting going on here? People keep talking about "metapedians", when this is nothing to do with Meta. Adam Cuerden (talk) 19:52, 25 July 2013 (UTC)[reply]

A metapedian is someone who spends a lot of time on work in the project space, such as writing guidelines or talking to editors. You might say that the opposite of metapedian is content creator. With merely 13% of your edits being in the mainspace and 57% in WP and WT, you are a metapedian. If you would like to read more about it, see meta:Metapedianism. Whatamidoing (WMF) (talk) 20:27, 25 July 2013 (UTC)[reply]
I'm a content creator/improver, as will be blatantly obvious from both my userpage and my edit stats, and I was concerned about the extra load and slowness from VE being there in the background when I used the gadget. It's because in its present form it impairs editing that it's so important for editors to know how to avoid it. Doubly so for those for whom its being there but merely concealed by the gadget has a more appreciable effect than it does for me (supported browser, relatively good connection on both machines I use). Please don't let's divert this into a discussion of how we should spend our time here, especially since it's not editing talk pages that VE makes hard. Yngvadottir (talk) 21:16, 25 July 2013 (UTC)[reply]
Neither I nor WhatamIdoing, at least, were suggesting how users should or should not spend their time. I would say you are a metapedian; it's not about proportion, it's about familiarity with the bureaucracy of Wikipedia, the discussions about users or discussions about discussions, that sort of thing. Like you, I am a consistent content creator: I'm still a metapedian, and don't shrink from that description. Okeyes (WMF) (talk) 22:26, 25 July 2013 (UTC)[reply]
See my reply to In actu above; this is an extremely inappropriate and irrelevant characterization to bring up in this discussion, not to mention inaccurate. postdlf (talk) 21:38, 25 July 2013 (UTC)[reply]
I replied to you above --Guerillero | My Talk 23:34, 25 July 2013 (UTC)[reply]
I'm a metapedian and proud of it. There is nothing dismissive about the term or the class of users. The English Wikipedia would be a complete mess without our metapedians. Whatamidoing (WMF) (talk) 00:52, 27 July 2013 (UTC)[reply]
Sorry, I've never seen the term before, and it was weird seeing a lot of people using it at once. Adam Cuerden (talk) 22:35, 25 July 2013 (UTC)[reply]
A link to the page would have been helpful, but it probably didn't occur to anyone that it would be unknown to many people reading this page. It's definitely not a name that you'll encounter every day. Whatamidoing (WMF) (talk) 00:52, 27 July 2013 (UTC)[reply]
  • I suppose I'm a metapedian. But I wasn't 7 or 8 years ago when I first started before I became involved in meta stuff a few years later. I never found the standard editing interface to be any more complicated than using the tool bar of the editing window of any common or garden forum or blog, even if I now code my content and messages on-the-fly in Wiki markup. Natuarally I've turned off Visual editor which I found to be a great distraction and not very helpful at all for the kind of work I do nowadays. I have noticed some comments recently on articles I work on to the effect of 'I would have done this, but I've been away for a while and don't know how to use this new thing - can someone make the edit for me?' . I think the method for turning it off should be more visible. Kudpung กุดผึ้ง (talk) 05:46, 26 July 2013 (UTC)[reply]

You can turn it off?!

I had no idea this was a thing and I wouldn't have known if I hadn't come to this Village Pump page. I had assumed we couldn't turn it off, since WMF staff said earlier this month that they weren't going to be giving us the ability to turn it off. Well, i'll go do that now. Thanks for not letting me know earlier. SilverserenC 10:35, 28 July 2013 (UTC)[reply]

Yes, something needs to be done. WP has become like Microsoft: You need to know the terminology in order to find help, but you need to go to help to find the terminology. How is anyone supposed to know that this is called "VisualEditor"? It used to be that the edit window linked to the discussion page, but now that it takes 20 minutes for the edit window to open, who's going to be able to find it? VE should be an opt-in option as long as it's impractical to use for actual editing. — kwami (talk) 00:18, 31 July 2013 (UTC)[reply]

Migrate the "Remove VisualEditor from the user interface" gadget to the "Temporarily disable VisualEditor while it is in beta" preference

Let's migrate the "Remove VisualEditor from the user interface" gadget to the "Temporarily disable VisualEditor while it is in beta" preference. This is possible by making the gadget toggle that preference and disable itself via the action=options API and would be trivial to implement (or you could ask ops to make that change directly in the database, but that might not be feasible).

The rationale is obvious – that gadget only fires after VE is loaded (so it's a performance issue) and is not supported by the developers (so it could break surprisingly again, as it already has a few times).

Thoughts? Matma Rex talk 19:19, 25 July 2013 (UTC)[reply]

Oh, by the way, this isn't a strawpoll, but a technical question to the technical people, since this is the technical section of the village pump. Matma Rex talk 19:20, 25 July 2013 (UTC)[reply]

Sounds good to me. --MZMcBride (talk) 16:14, 26 July 2013 (UTC)[reply]
Why not simply remove it? — Edokter (talk) — 12:22, 27 July 2013 (UTC)[reply]
The downside is that the WMF have stated the intent of removing their preference for VE at any time. The gadget will be needed later, I suspect. Adam Cuerden (talk) 17:57, 28 July 2013 (UTC)[reply]

MediaWiki_talk:Gadget-oldeditor.js#Edit_request. Matma Rex talk 14:24, 2 August 2013 (UTC)[reply]

Special:Search and special character

Tracked in Phabricator
Task T49770

I tried using Special:Search to search for documents with "™" (trademark symbol) in their titles. I put "intitle:™" in the search form, and received "An error has occurred while searching: The search backend returned an error: " without any visible error message after that: [6]. When I leave out "intitle:" and just search for "™", the result is the same [7]. When I put "™" into the search box that's on every page, it took me to Trademark symbol as it should have. —rybec 20:07, 26 July 2013 (UTC)[reply]

"Ways to enter a non-ASCII character into the wikitext": Use an HTML named character entity reference like à or HTML numeric character reference like ¡, and copy the character from preview. In the past the code itself had to be stored in the wikitext. Such codes may still be present on some pages. Results of the internal search function may be affected by this. On the other hand, this search function cannot find some characters, including "→", while if it is coded as "→", it can be found by searching for "rarr". See also Help:Searching. (From meta:Help:Special_characters#Editing.) Relevant? Theopolisme (talk) 23:03, 26 July 2013 (UTC)[reply]
Thank you; I confess I hadn't read those help texts. A search for intitle:™ [8] shows the articles with trade in the title; searching for ™ [9] brings up a suggestion There is a page named "™" on Wikipedia then results for the word trade. Searching for other single non-alphanumeric characters, such as $ [10] or %, gives the same inscrutable error message. —rybec 02:22, 27 July 2013 (UTC)[reply]
Definitely annoying, and yes, the error message is utterly unhelpful. Perhaps someone more familiar with the search functionality of MediaWiki could chime in? Theopolisme (talk) 02:42, 27 July 2013 (UTC)[reply]
This may be a case where it's easier not to use MediaWiki's built-in search interface, as these things often break down on fancy characters. If what you're after is a list of all page titles (or all non-redirect page titles?) with a TM in them, then asking someone to run a database query on toolserver/labs might be faster, or you could pull enwiki-latest-all-titles-in-ns0.gz from dumps.wikimedia.org and search it locally. (it's only a 55mb zipped file). This is what I did a while back when looking for articles with smartquotes in the title, IIRC - I was able to generate some lists like this. Andrew Gray (talk) 13:02, 27 July 2013 (UTC)[reply]
In fact, I just ran it :-). There's about 180 of them, many of which are garbled Unicode and don't really have "TM" in at all, like Antonín DvoÅ™ak. User:Andrew Gray/TM has the list - feel free to do with it as you will. Note that this list includes redirects, but IIRC there's some user-scripts you can use to highlight those. The dump is also from 8th July, so is not completely up-to-date - there's at least one redlink. Andrew Gray (talk) 13:12, 27 July 2013 (UTC)[reply]
Help:Searching#Special searches has two grep links to tools which can make the search for titles by simply entering the symbol ™. With "Include redirects" unchecked, the first tool http://toolserver.org/~vvv/grep.php?wiki=enwiki_p&ns=0 only returns Synthespians™ and Hi™ How Are You Today? (the latter link fails at the tool because '?' is not encoded). The second tool http://toolserver.org/~jarry/grep/?lang=en&wiki=wikipedia&ns=0 includes redirects even though "Include redirects" is unchecked. It gives 125 results including the two already mentioned (with the same encoding error for '?'). PrimeHunter (talk) 13:55, 27 July 2013 (UTC)[reply]
This problem is tracked in bugzilla:47770. --AKlapper (WMF) (talk) 12:30, 29 July 2013 (UTC)[reply]

Updates on VE data analysis

I posted an update on VE data analysis and created a top-level page linking to various reports and dashboards.--DarTar (talk) 00:29, 27 July 2013 (UTC)[reply]

I've added that link to the navigation template on all the VE pages. -- John Broughton (♫♫) 01:15, 28 July 2013 (UTC)[reply]
Does the analysis exclude edits made via another tool (e.g. AWB, Dabsolver, Reflinks), or does those get lumped in with the wikitext edits? GoingBatty (talk) 04:08, 28 July 2013 (UTC)[reply]
@GoingBatty: I'm sure the logic is that if an edit does not have a VE tag added to it, it's considered to be done by the wikitext editor. But maybe "wikitext editors" would be a better label, since the tools you mention, or something like wikEd, have a different UI. -- John Broughton (♫♫) 20:17, 28 July 2013 (UTC)[reply]
I think we're trying to measure is the two primary editors that new users would use: VE and the standard editor (i.e. what you get when you click "Edit source"). If so, I suggest that edits from all other tools be excluded from the statistics. However, if excluding the edits from other tools is too challenging, then maybe "wikitext editors" (or "all other editors") would be more clear. Thanks! GoingBatty (talk) 21:34, 28 July 2013 (UTC)[reply]
I understand what you're saying, but tools like AWB actually use wikitext to edit and people should theoretically be checking the code for each edit they are making (using the "source" view as we now call it). Killiondude (talk) 18:20, 29 July 2013 (UTC)[reply]
Good point about AWB being another wikitext editor. Therefore, I support John's suggestion to use "wikitext editors". GoingBatty (talk) 22:54, 29 July 2013 (UTC)[reply]

Revision history - Number of watchers

Want to say the changes made to the Revision history specifically the "Number of watchers" link is a great and wonderful idea - I see only positive from the decision. Not sure who to thank ... so posting here. I do have a question...would it not be a good idea to change the name of the link at the top " Revision history" pages to say "page information" as this is what they now contain. This would then also negate the need to redirect and highlight to the section "Number of page watchers" as i believe most will find it in the end. Changing the title will also inform editors and readers alike that much more info can be found through the link then just the number of watchers as it now implies.-- Moxy (talk) 01:59, 27 July 2013 (UTC)[reply]

You're welcome. :-)
The relevant discussion about changing the page history link is here: Wikipedia:Village pump (technical)/Archive 114#MediaWiki:Histlegend and the watcher tool.
The "Page information" link is always available in the sidebar. The only reason we're keeping the watchers link on the page history is for historical reasons, really. It's no longer an external tool and it's already available from the sidebar (via the "Page information" link), but users have been trained to find the number of page watchers from the page history, so a link has been retained there. Unlike the sidebar "Page information" link, the "Number of watchers" link now highlights the specific table row and anchors the browser window if possible. --MZMcBride (talk) 05:14, 27 July 2013 (UTC)[reply]
I would like to see that updated to the number of active watchers. At this page, there are more than 35 inactive users "watching" it for every active user. WhatamIdoing (talk) 16:58, 27 July 2013 (UTC)[reply]
I get an error at this page that WhatamIdoing linked. Is it correct because I would love to see what WhatamIdoing is trying to show us?Moxy (talk) 01:34, 28 July 2013 (UTC)[reply]
The link works for me. Can you describe what error you are getting? Anyway, here is the data she was trying to show:
Page Watchers Active
Wikipedia:WikiProject Contents (talk) 1986 55
πr2 (t • c) 03:05, 28 July 2013 (UTC)[reply]
The problem with WhatamIdoing's link is that it's on Toolserver - you need to throw a six to start. --Redrose64 (talk) 11:15, 28 July 2013 (UTC)[reply]

The error I get is "A problem occurred in a Python script. Here is the sequence of function calls leading up to the error, in the order they occurred." 

/home/dispenser/public_html/cgi-bin/cursor.pyx in oursql.Cursor.execute (oursqlx/oursql.c:15932)()
/home/dispenser/public_html/cgi-bin/cursor.pyx in oursql.Cursor.execute (oursqlx/oursql.c:15801)()
/home/dispenser/public_html/cgi-bin/statement.pyx in oursql._Statement.prepare (oursqlx/oursql.c:7818)()
/home/dispenser/public_html/cgi-bin/statement.pyx in oursql._Statement._raise_error (oursqlx/oursql.c:7425)()

-- Moxy (talk) 15:45, 28 July 2013 (UTC)[reply]

I've gotten the same error before; just try again.
I'm not certain of the definition of 'inactive user', but I believe that it's anyone with no edit or other action during that previous 30 days (might be 60 or 90, but I'm pretty sure that only one action during that timespan is required). WhatamIdoing (talk) 20:59, 31 July 2013 (UTC)[reply]
I assume that an "inactive user" is one that isn't listed at Special:ActiveUsers, in which case it's 30 days. See also Special:Statistics. --Redrose64 (talk) 09:26, 2 August 2013 (UTC)[reply]

No Page View Statistics

( Previous discussion at: User talk:Henrik and Wikipedia:Help desk ) -- 79.67.244.91 (talk) 16:04, 29 July 2013 (UTC)[reply]

It is DAY FOUR with no Page view statistics on Wikipedia. I believe this has been reported at bugzilla a couple of days ago. Just wondering what’s next? XOttawahitech (talk) 15:34, 27 July 2013 (UTC)[reply]

Pay the hamster food bill at Toolserver? --Redrose64 (talk) 15:52, 27 July 2013 (UTC)[reply]
"Page View" count on this app seems to be down system wide for 4 days now, are the other stats also affected or being dropped? 99.140.182.228 (talk) 17:09, 27 July 2013 (UTC)[reply]
 Works for me at this URL anyway. --Redrose64 (talk) 19:12, 27 July 2013 (UTC)[reply]
Those statistics stop 22 July. They usually go up to the current or previous day. User talk:Henrik#No stats for July 23? has a link to http://lists.wikimedia.org/pipermail/wikitech-l/2013-July/070740.html. If you post the same issue in a new place then please link to the old place, especially when it has relevant information you don't mention. PrimeHunter (talk) 20:52, 27 July 2013 (UTC)[reply]
Yes, the web site itself works - in as much as it shows a graph. The problem is that there were no figures shown for July 23, July 24 or July 25 on that graph. Some of the figures have since appeared (part of June 24, and most or all of June 25), but the rest are missing, presumed lost, forever (all of June 23 and most of June 24). The June 26 figures look normal, but were very late in appearing. The June 27 and June 28 figures look slightly reduced, but that may be the actual traffic level. Data loss of some sort or another happens several times every year for whatever reason (seemingly a different reason every time). -- 79.67.244.91 (talk) 16:04, 29 July 2013 (UTC)[reply]
This was more feedback on the problem: WP:Help desk#Page view stats down. I created a new article 7-24-2013, but 0 view hits since then, even though I know there are some. Ihardlythinkso (talk) 21:00, 27 July 2013 (UTC)[reply]
Ha, this is very unfortunate. The day my featured article Paul Kagame was on the main page is the day the stats don't work. Now I'll never know how much of a spike it got! Or perhaps the two are connected: the article was so wildly popular that day, that it broke the view counter completely :)  — Amakuru (talk) 13:40, 30 July 2013 (UTC)[reply]

Please tell me what I'm doing wrong in my sandbox effort

code current result desired result
{{Flagicon|France}} France ——————
{{Flagicon/sandbox|France}} France

Austria-Hungary|| here I want France

{{Flagicon|Russia}} Russia ——————
{{Flagicon/sandbox|Russia}} Russia

Austria-Hungary|| here I want Russia

{{Flagicon|}} ——————
{{Flagicon/sandbox|}}

Austria-Hungary|| this is OK

I'm trying to add #if into the Template:Flagicon/core/sandbox, but it's not working. My idea is: If the country-parameter is empty or wrong, then display File:Flag of None.svg with dimensions of 25x17px. Please fix it, thanks. Maiō T. (talk) 16:49, 27 July 2013 (UTC)[reply]

@Maiō T.: I've fixed it so if no "flag-alias" is specified it prints the "Flag of None." Is this what you wanted? How do you plan to determine if a parameter is "wrong"? Theopolisme (talk) 05:29, 28 July 2013 (UTC)[reply]
@Theopolisme: No. It was even worse, so I reverted your edit. And the "wrong parameter"? I don't know, the "#ifexist" might be the right solution. Maiō T. (talk) 11:56, 28 July 2013 (UTC)[reply]
{{{1}}} is the first unnamed parameter but Template:Flagicon/core/sandbox doesn't appear to be called with unnamed parameters at all. Maybe you want {{{alias|}}} instead of {{{1|}}}, but changing {{Flagicon}} would probably be controversial. Currently it displays nothing if it doesn't have parameters. Many articles, for example for sports events, use it without parameters until a person/team becomes known. I'm not sure the editors want it to display File:Flag of None.svg instead of nothing. I think File:Flag of None.svg is currently mainly used for entities without a known flag like Mondariz, and not for entities still to be determined. PrimeHunter (talk) 12:25, 28 July 2013 (UTC)[reply]
Note that ifexist is an expensive parser function, and flagicons are often used lot's of times on pages. It would probably be better to convert flagicons into two lua modules, one data table, and one script. —TheDJ (talk • contribs) 12:49, 28 July 2013 (UTC)[reply]
Yes, PrimeHunter, you're right. I meant the sport articles, see this. There is a lot of ugly [[ {{{altlink}}}|]] codes and I would like to change them to or some other icon, e.g. "TBD". Let's close this discussion about {{Flagicon}}, I'll leave it as is. However, please propose something about those [[ {{{altlink}}}|]]'s. Thanks, Maiō T. (talk) 15:21, 28 July 2013 (UTC)[reply]
Your example 2013 FIBA Europe Under-16 Championship#Second Round doesn't use {{Flagicon}} or {{Flagicon/core}}. It uses {{Flaglink/core}} and {{Flagright/core}}. The bottom of the source edit window shows the used templates. For a section edit, click Show preview to see the templates used in the section. The ugly code displayed in the article could for example be removed by editing {{Bk}} and {{Bk-rt}} to place their current content inside {{#if:{{{1|}}}|...|&nbsp;}}. PrimeHunter (talk) 09:57, 29 July 2013 (UTC)[reply]
 Done O.K. Maiō T. (talk) 15:54, 30 July 2013 (UTC)[reply]

Hypothetical vandalism - how to reverse?

Consider the following: Page A is an important page, such as a featured article. Page B is any page with a long history and lots of edits. An admin deletes Page A, moves Page B to where Page A was, then deletes and restores Page A. Page B history is still where Page B was, but Page A now has a scrambled history. How would one undo the damage and restore the history of Page A to its original state? I tried this on my own installation of MediaWiki, but can't seem to figure out (can't say I really tried hard, but I just thought of this when thinking if there's any way for a vandal to cause irreversible damage). Ginsuloft (talk) 12:44, 28 July 2013 (UTC)[reply]

Delete all the revisions of A, move B back, and undelete A.--Gilderien Chat|List of good deeds 12:52, 28 July 2013 (UTC)[reply]
Oh, so when you delete a revision, they disappear from the history when the page is deleted and restored? Did I understand correctly? Ginsuloft (talk) 12:55, 28 July 2013 (UTC)[reply]
Never mind, I just realized that you can select which revisions to restore. So, it seems like there's no way to irreversibly vandalize Wikipedia. Ginsuloft (talk) 12:59, 28 July 2013 (UTC)[reply]
Well, it can be a pain to do that, as there is little trace left as to which edits came from "A" and which from "B". But it's not completely irreversible. (I think WP:BEANS has already been violated, so, if there is a good way to distinguish which revisions came from which articles, please let me know.) — Arthur Rubin (talk) 16:50, 28 July 2013 (UTC)[reply]
Unless the two pages are extremely similar, it should be clear by looking at each revision which page it came from. But it's going to be a very tedious job, for sure. --Fran Rogers (talk) 17:04, 28 July 2013 (UTC)[reply]
A similar thing happens when you import a page from another wiki to an already existing title. πr2 (t • c) 17:40, 28 July 2013 (UTC)[reply]
Don't forget that you could do this with multiple pages, merging lots of histories into one. Personally I disagree with WP:BEANS. Due to Murphy's law (or the second law of thermodynamics), we should be ready for what could happen, because if it isn't fixed, eventually it will happen. As for the solutions, one could write a bot that compares the histories with the redirected/deleted pages and restores revisions based on that. This becomes more complex if the malicious admin were to merge histories with the leftover pages as well, but eventually the chain of page-moves must end, so the clean histories of the pages that were used to disrupt page A will always remain somewhere, which is why it will never be 100% irreversible (still hard to clean up, as was said). Ginsuloft (talk) 18:09, 28 July 2013 (UTC)[reply]

Blanking of default text in ACIP-created user pages

A while back there was a project called Outreach:Account Creation Improvement Project (ACIP), which aimed to get more users registering an account. It never really got anywhere and was shut down in 2012. However, it left a legacy of, by Google's count, well over 60,000 abandoned user pages containing the same example text: Hello, my background is in biology, with a main interest in snakes. I speak English and French. In my off-time, I listen to a lot of music, and I have discovered that Wikipedia is a very good source for information in that department. Hopefully I can help make it even better.

It strikes me that it's pretty weird for us to be claiming that we have over 60,000 bilingual herpetologists as editors, and I propose that we get someone to code up a bot to remove these fairly embarrassing artifacts of a dead project. They're trivial to find; all of them are on pages transcluding {{New user bar}}. — Scott • talk 16:01, 28 July 2013 (UTC)[reply]

It appears there are 52031 base user pages transcluding that template with only one revision in the history. Of those, 7900 have exactly the ACIP default text, 8239 have the text you quote with possible modifications elsewhere in the page, and 8288 contain the three words "snakes", "English", and "French" in that order. I could easily see deleting the 7900 (and I'll write the bot if there's consensus, or at least WP:SILENCE), but the rest I'd rather see MFDs for. Anomie⚔ 04:11, 29 July 2013 (UTC)[reply]
Although perhaps the process outlined at Wikipedia:Bots/Requests for approval/The Anomebot2 2 would be better; I wonder why @The Anome: never followed up on that bot request. Anomie⚔ 04:16, 29 July 2013 (UTC)[reply]
Thanks for the investigation, Anomie. I agree with your suggestions. — Scott • talk 13:09, 29 July 2013 (UTC)[reply]

Tech News: 2013-31

Latest tech news from the Wikimedia technical community. Please inform other users about these changes; not all changes will affect you. Translations are available.

  • The latest version of MediaWiki (1.22/wmf12) was added to test wikis and MediaWiki.org on July 25. It will be enabled on non–Wikipedia sites on July 29, and on all Wikipedias on August 1. [11]
  • Wikivoyage was offline for around 40 minutes on July 24. [12]
  • Pywikipediabot moved their code from SVN to git; bot owners need to update their tools. [13]
  • The Notifications and Thanks extensions were added to Meta-Wiki on July 26; other wikis will get them soon. [14]
  • It is now possible to add edit summaries on Wikidata using the API; the feature will be added to user interface soon. [15]
  • The software that resizes large PNG images on all wikis was changed on July 25. Resizing of PNG files bigger than 35 megapixels should be faster and more reliable now. [16]
  • Three new webfonts (Gentium, Old Persian and Shapour) will be added to Universal Language Selector. [17], [18], [19]
  • Special:MIMESearch, which gives a list of files by type, will be enabled on all Wikimedia wikis with MediaWiki version 1.22/wmf12 (bug #13438). [20]
  • A mailing list to discuss multimedia features was started; users are encouraged to sign up.
  • VisualEditor news:
    • On July 24, VisualEditor was added for logged-in users on the German (de), Spanish (es), French (fr), Hebrew (he), Italian (it), Polish (pl), Russian (ru) and Swedish (sv) Wikipedias; it will be added for all users on those wikis on July 29. [21]
    • A preference to completely disable VisualEditor while it is in beta phase was added on July 24. [22]
    • Many bugs were fixed in right-to-left languages. [23] [24] [25] [26] [27] [28]
    • It is possible again to scroll down in the template editing window (bug #51739).
    • VisualEditor now works with the FlaggedRevisions extension. (bug #49699)
    • If the user opens VisualEditor using a section edit link, the title of the section is added to the edit summary (bug #50872).
    • Invisible templates now can't be deleted by accident or on purpose (bug #51322).

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

20:44, 28 July 2013 (UTC)

1.22/wmf4 added support for new URI schemes, but they were disabled until 1.11:

  • ftps:
  • ssh:
  • sftp:
  • xmpp:
  • sip:
  • sips:
  • tel:
  • sms:
  • bitcoin:
  • magnet:
  • urn:
  • geo:

--  Gadget850 talk 21:20, 28 July 2013 (UTC)[reply]

I'm confused. I tried searching for "URI" and "xmpp" in the 1.22/wmf4 page without results. I did the same in the 1.22/wmf5 and 1.22/wmf11 pages (is that what you meant by "1.11"?), but no results. Could you clarify? Thanks :) –Quiddity (talk) 02:52, 29 July 2013 (UTC)[reply]
The Tech Report announced this for wmf4, but it ws not released until 1.22/wmf5, where it is described as "Whitelist a bunch of url protocols." --  Gadget850 talk 11:41, 29 July 2013 (UTC)[reply]
This then means that error checking in Module:Citation/CS1 needs to be updated? —Trappist the monk (talk) 12:19, 29 July 2013 (UTC)[reply]
@Trappist the monk: no, per the code and Help:CS1_errors#bad_url, it only checks if the url param somewhat resembles a URI. These new URI schemes should work just fine. —TheDJ (talk • contribs) 19:09, 29 July 2013 (UTC)[reply]
Exactly. It does mean I have to do a bit of documentation updates. --  Gadget850 talk 22:59, 29 July 2013 (UTC)[reply]

Looking at these, usefulness is limited. Most will require some sort of browser add on to resolve the URL. For example:

urn:nbn:de:1111-200606299

Links properly, but without a URN resolver it gives an error message. We do have {{URN}} that links to a resolver site:

urn:nbn:de:1111-200606299

--  Gadget850 talk 00:58, 31 July 2013 (UTC)[reply]

Notification number error

I've noticed there is a problem with the notification number next to the username. Formally you could click on it but today I've received a notification but when I click on the number, the drop down box doesn't appear. I'm using windows and IE7. The C of E God Save the Queen! (talk) 11:24, 29 July 2013 (UTC)[reply]

Would be good to hear if other users can reproduce the problem with this browser (I don't have a machine with IE7 around), and if possible also get some Javascript error output (if IE has something similar. Probably not). --AKlapper (WMF) (talk) 12:29, 29 July 2013 (UTC)[reply]
OK I don't see the problem with the click action (possible caching issue, since i started fresh ?). I did however see a major problem with the Preferences link bugzilla:52225 —TheDJ (talk • contribs) 15:35, 29 July 2013 (UTC)[reply]

List of Redirects

Special:ListRedirects lists only the first 1000 redirects. Is there a way to get it to display more? Or to start from a particular character? Or is there perhaps a tool that would do the same thing? older ≠ wiser 15:43, 29 July 2013 (UTC)[reply]

You can use the API, with the query for list=allpages restricted to redirects, example. You can iterate with the apcontinue parameter given in return. --NicoV (Talk on frwiki) 15:56, 29 July 2013 (UTC)[reply]
Depending on what you need it for, have someone run a database query for you. Werieth (talk) 16:00, 29 July 2013 (UTC)[reply]
Well, I'm mostly interested in browsing at the moment. I'm in a discussion about the appropriateness of using redirects on disambiguation pages (Wikipedia talk:Manual of Style/Disambiguation pages#Clarification regarding WP:DABREDIR and subsections). I was looking for redirects that had a parenthetical qualifier attached and that redirected to an article (not to a disambiguation page). And from that, I was hoping to find cases where there is a redirect of the form Foo (disambiguating term) that are not used on the corresponding Foo disambiguation page. For a tangible example, Pawpaw (genus) used to be a redirect to Asimina article on the N.Am genus of paw paw trees. There had been a dispute over whether that redirect, Pawpaw (genus), should be used as an entry on the Paw Paw disambiguation page, since it was not actually the name of the genus, but a colloquial use. As a compromise Pawpaw (genus) was later redirected back to the disambiguation page. That disagreement has been resurrected and I was hoping to be able to look for other similar situations where the redirect with a parenthetical disambiguator might not be appropriate for use on the disambiguation. older ≠ wiser 16:44, 29 July 2013 (UTC)[reply]
Any suggestions on how I might find someone willing and able to write a query to do the following?
  1. List all redirects with the form basename (parenthetical term). The "basename" and "parenthetical term" could be anything.
  2. A nice to have bonus, filter the list such that it excludes redirects to disambiguation pages and includes only redirects to articles.
I'd be happy with #1 alone, but 1 with 2 would be exactly what I'm looking for. older ≠ wiser 13:06, 30 July 2013 (UTC)[reply]
In the past I've just poked a Toolserver users to run a database query for things like this. Due to the prolonged demise of the TS, I'm not sure that's an option but you could try. I'm not sure there's an exhaustive list anywhere of who has a TS account, but there's a good idea here: tswiki:Category:Tools by authors. Killiondude (talk) 17:48, 30 July 2013 (UTC)[reply]

Creating user sub-pages - should permissions be restricted?

Should creation of user-sub-pages in other user's space be allowed by users (vs admins)? If someone creates a new user subpage under my name, do I get notified (since it's not on my watchlist)? --Obi-Wan Kenobi (talk) 23:47, 29 July 2013 (UTC)[reply]

I don't think it should be restricted (I create pages under my bot's username, for example), but I agree that notifications would be very useful... perhaps the Echo team could look into this? Theopolisme (talk) 00:11, 30 July 2013 (UTC)[reply]
I haven't tested it; if you have another username, perhaps you could test and see if there are any notifications. If not, then yes, we should be notified when a new page is created in our userspace, otherwise someone could create an attack page, redirect people to it, and they may believe it was created by the user in question (esp if done with a similar-looking username).--Obi-Wan Kenobi (talk) 00:21, 30 July 2013 (UTC)[reply]
Tested just to verify; I didn't receive any notification (User:Theopolisme^2/test). Theopolisme (talk) 00:39, 30 July 2013 (UTC)[reply]
Can someone please give an example of when it would be appropriate for a user to create a user subpage in the space of another person (not a bot or another id of the same person) without their permission? —Anne Delong (talk) 00:49, 30 July 2013 (UTC)[reply]
"Without their permission" is the key part of your question; I can't see when that would ever be appropriate. "With their permission," though, is a different story—and why it shouldn't be disallowed outright (for example, I seem to recall a user creating a list about the Visual Editor or something like that in Okeyes's userspace a week or so ago). I think notifications would be a nice in-between. Theopolisme (talk) 00:59, 30 July 2013 (UTC)[reply]
This is a classic example of a solution in search of a problem. Should someone hatch such an idiotic scheme to "frame" someone the page's history would show who the schemer was, and exonerate the victim. See WP:IFITAINTBROKE. There is no problem to be solved here. EEng (talk) 01:17, 30 July 2013 (UTC)[reply]
What about notifying a user that a subpage under their username has been created is a bad idea? I agree that restricting permission to edit user subpages is a bad idea, but what's wrong with notifications? Theopolisme (talk) 01:26, 30 July 2013 (UTC)[reply]
Repeating myself (see below): What's wrong with it is it's one more piece of software to be developed and maintained with only an imaginary benefit. These threat scenarios are imaginary. EEng (talk) 04:07, 30 July 2013 (UTC)[reply]
@Anne Delong: When Writ Keeper created his orange-bar replacement script and lots of people started using it, I created the documentation page for it. Perhaps not a wonderful example, as he had to go in and fix the errors I'd made, but he hadn't done it yet.... Ignatzmice•talk 01:13, 30 July 2013 (UTC)[reply]

Creating a talk page seems like something that should be allowed. Editing someone's common.js seems like something that should be prohibited. —rybec 01:39, 30 July 2013 (UTC)[reply]

Editing another user's common.js/.css is already prohibited for regular users (admins can do so, which is useful for, say, helping someone install a script). Theopolisme (talk) 01:55, 30 July 2013 (UTC)[reply]
I tend to concur that it should not be restricted. However, since there are very few justifiable cases, it would be better to give notification to the user in question. I know that the page history can be searched etc but not everyone checks the page history of any given page before going there, and if someone created a doppleganger name they could write slanderous material and attribute it to the user. the reason this came up is b/c a vandal recently edited a sub-page of a user I know (I wasn't Watching the subpage) and then transcluded this sub page in the main page. The transclusion was subtle and I didn't notice it and the vandalism was buried in the middle of the larger sub-page. The notification wouldn't have helped here, but a determined vandal could do the same thing and create/edit their own sub-page w/o anyone seeing it, then transclude it with a sneaky edit that people might not notice. (Eg mark as minor, claim to fix. Typo, transclude a page with innocuous title, etc)
so, are there any reasons to _not_ notify here? --Obi-Wan Kenobi (talk) 02:21, 30 July 2013 (UTC)[reply]
Yes. It's one more piece of software machinery to be created and maintained in order to solve a problem that isn't a problem. No matter how similar the phony username was or whatever, your friend the victim would have had zero trouble proving he didn't do it, because edit histories are unambiguous as to who did what. People can make all kinds of disruptive edits all kinds of places (possibly with a sly username resembling someone else's) and doing that in a user's subpage is just one very specific place it could happen. There's no point in specially guarding against this one particular case. EEng (talk) 04:07, 30 July 2013 (UTC)[reply]
The reason I liked this idea wasn't because of "sneaky userspace madness." I simply think it would be informative to know when someone adds a page to your userspace, be it a misplaced sandbox/draft or something completely different. I don't think it's life or death, and I don't think Obi-Wan's rationale for requesting this is the main benefit—rather, I just think notifications about what goes on in your userspace would be beneficial. Theopolisme (talk) 04:45, 30 July 2013 (UTC)[reply]

An example I'm surprised no one has mentioned is userfying articles, drafts, or other content into another editor's userspace. Perhaps I'm surprised because this is the only reason I have ever created a page in someone else's userspace, and it is typically done with their prior knowledge. Someguy1221 (talk) 03:39, 30 July 2013 (UTC)[reply]

an excellent point. I've userfied many misplaced user sandboxes or user drafts in the course of new-pages patrolling (and then left note on the users' talks, of course). Ignatzmice•talk 03:50, 30 July 2013 (UTC)[reply]

This has been brought up a number of times over the years, and the answer is always the same: MediaWiki has no concept of ownership of pages, in the User or any other namespace Perhaps it's worth adding to WP:PEREN at this point. There are valid reasons to do things in another's space without admin rights (the userfying example is a good one). This is the absolute definition of a solution in search of a problem. Now, the proposal below isn't a terrible idea on the surface (being able to watchlist creations of subpages), but at first glance it sounds inefficient so it'd have to be implemented intelligently. ^demon[omg plz] 06:23, 30 July 2013 (UTC)[reply]

Actually, I might have spoken too soon, the existing indices seem to cover the table pretty well. A naïve (like 15 seconds to think up) query isn't as bad as I thought it would be:
mysql> explain select * from watchlist where wl_namespace = 2 and wl_title like 'Foo/%';
  +----+-------------+-----------+-------+-----------------+-----------------+---------+------+------+-------------+
  | id | select_type | table     | type  | possible_keys   | key             | key_len | ref  | rows | Extra       |
  +----+-------------+-----------+-------+-----------------+-----------------+---------+------+------+-------------+
  |  1 | SIMPLE      | watchlist | range | namespace_title | namespace_title | 261     | NULL |    1 | Using where |
  +----+-------------+-----------+-------+-----------------+-----------------+---------+------+------+-------------+
I may not be thinking this out well as it's late, YMMV. The UX would need some cleanup to support this sort of watching though (not my thing :)) ^demon[omg plz] 06:39, 30 July 2013 (UTC)[reply]
Thought about it a third time, and I think I over-simplified what would need doing. We'd probably need something like a new column watchlist.wl_subpages or somesuch to indicate you're watching subpages of a page, rather than some /% magic on wl_title. So yeah, non-trivial but not a bad idea. I should go to bed and stop trying to figure out things like this ;-) ^demon[omg plz] 06:54, 30 July 2013 (UTC)[reply]
Just want to point out, for the sake of my own reputation, that if you look elsewhere you'll see I completely agree that this is, as you say, a solution in search of a problem. It's amazing how quickly, deeply, and unknowingly people can go down the rabbit hole. I made the proposal below only in a desperate attempt to redirect the discussion away from something based on "userspace ownership". EEng (talk) 02:09, 31 July 2013 (UTC)[reply]
A proposal

OK, how about this:

  • If page X is on your watchlist, then creation of any new subpage X/whatever shows up in your watchlist "report"
    • ...but only creation of X/whatever -- at that point it's your choice whether to add X/whatever to your watchlist to monitor future changes to it
    • Some thought needs to be given to what happens when a sub-sub (grandchild) page is created with no sub (child) page already created in between (I don't even know if that's possible -- indeed I don't know if there are sub-sub pages, but programmer types know what I'm talking about).
  • On initial creation of account ImAnEditor, then instead of ImAnEditor's watchlist being initially empty (as it is now) it should initially contain two things: Talk:ImAnEditor and User:ImAnEditor.

This way you're also picking up creation of subpages of e.g. a policy page you're watching, so it has some generalized meaning projectwide instead of being special for protecting "my" subpages. "Should" be straightforward to implement -- little tweak to the semantics of watchlists, plus a change to initialization of new user accounts. EEng (talk) 05:26, 30 July 2013 (UTC)[reply]

I think it would be completely reasonable to have all subpages of one's own user and user talk page automatically watchlisted upon creation, and upon creation only (so you can unwatchlist it if you like, and it won't revert back to that state). If anyone fusses there could be a preference to disable this. Someguy1221 (talk) 07:43, 30 July 2013 (UTC)[reply]
Either watchlisted, or use the notification system to ping someone. Again, the case of someone else creating a page in your userspace, while it happens, is relatively rare, and the chance for abuse is there, so I think we should find some way, any way, to notify the user. I don't know if a completely generic solution (e.g. watching arbitrary pages lets you hear about creation of arbitrary sub-pages) is needed, this could just be a one-off for user-space pages. --Obi-Wan Kenobi (talk) 14:31, 30 July 2013 (UTC)[reply]

User:Theopolisme, I create user subpages sometimes for professors (in their userspace) to help develop WP:Course pages. Biosthmors (talk) 09:49, 30 July 2013 (UTC)[reply]

For some background, this thread sprang from this one. Two observations on comments above:
Example of other users creating subpages: UBX (talk · contribs) has no contributions (but is registered); however the user page has over 6000 subpages.
MediaWiki does have the concept of ownership of user pages - see Special:ListGroupRights which has entries described as
  • Edit your own user CSS files (editmyusercss)
  • Edit your own user JavaScript files (editmyuserjs)
  • Edit other users' CSS files (editusercss)
  • Edit other users' JavaScript files (edituserjs)
Besides these, Special:MyPage/Editnotice and Special:MyTalk/Editnotice are "owned" in the same way as the CSS/Javascript subpages. --Redrose64 (talk) 10:32, 30 July 2013 (UTC)[reply]

Difficulty creating new username

I joined wikipedia today, and it took me a number of attempts to create a user name. Every one I entered came back as unavailable. I had to try another name, and enter all the other fields again (along with the Security check). It got very frustrating. Why can't you include a button to check the user name to see if it is available? Many other websites to this, and it would save a great deal of time and frustration. thanks Nalcomis (talk) 02:52, 30 July 2013 (UTC)[reply]

@Nalcomis: Sorry about all the difficulty! If you go to Special:Listusers there's a list of all the usernames that have already been taken and you can search them. Or, if you just type in the search bar "User:Example username" (replace Example Username with the username you want) you can see if the user page has been created or if a user exists. — kikichugirl inquire 03:29, 30 July 2013 (UTC)[reply]
And this is actually coming at some point. The JS field validation was postponed from the new "login and account" creation project, due to higher priority issues, but I think it is still in the long term planning, exactly for the reasons stated by USer:Nalcomis. —TheDJ (talk • contribs) 07:06, 30 July 2013 (UTC)[reply]

My Sig arrow got "boxed"?!?

Hi all, kudos for all the great help you give to all of us technically challenged. I have notice that my signature used to have little green arrows like street signs but have now been replaced with little squares and I have tested this on several web browsers. This has happened a few times before and the arrows came back after a few hours. It was one of the special characters that one editor showed me a list of months ago. If the arrow image is gone for good are there replacement images or a certain page that lists those? Thanks in advance. Market St.⧏ ⧐ Diamond Way 04:48, 30 July 2013 (UTC)[reply]

They aren't images, they are Unicode characters, rendered in green by your signature. And they aren't really arrows. The two characters are ⧏ U+29CF LEFT TRIANGLE BESIDE VERTICAL BAR, and ⧐ U+29D0 VERTICAL BAR BESIDE RIGHT TRIANGLE. [29] can display Unicode characters as images. How they display as Unicode characters at Wikipedia or any other website is determined by your browser. Wikipedia just passes on the number of the Unicode character. If a character isn't supported then a browser may display a standard placeholder symbol, for example a square. I see the right characters in Firefox 22.0 and Opera 12.12 on Windows Vista, but squares in Google Chrome and IE. Arrow (symbol) has a lot of Unicode arrows, and List of Unicode characters#Geometric Shapes has many triangles. Some of them may have wider support. At http://shapecatcher.com/ you can make a drawing and get a list of similar Unicode characters. PrimeHunter (talk) 10:31, 30 July 2013 (UTC)[reply]
Not sure if this helps, but maybe you can try replacing the raw arrow characters with the HTML code for them, which Wikipedia translates for you. For example, &#8592; generates ←. See [30] for a list of codes. Ginsuloft (talk) 12:39, 30 July 2013 (UTC)[reply]
Thanks for the assistance with this, PrimeHunter & Ginsuloft! Cleared some things up for me! Market St.⧏ ⧐ Diamond Way 04:45, 31 July 2013 (UTC)[reply]

Random "Talk: you have new messages" messages?

Tracked in Phabricator
Task T54301

All of a sudden I'm getting the thing at the top of the page displaying "talk: you have new messages" occasionally and randomly, even though I don't have any. I didn't notice this before I selected the VE opt-out and disabled the gadget disabling, however reversing that didn't make it stop. What's causing this? - The Bushranger One ping only 19:01, 30 July 2013 (UTC)[reply]

Ive been getting the same for about ten minutes. Really annoying.Blethering Scot 19:04, 30 July 2013 (UTC)[reply]
It'll be a cache issue. Just give it a few minutes. Adam Cuerden (talk) 19:05, 30 July 2013 (UTC)[reply]
A Wikipedia cache issue, then? I emptied my web browser cache and I still get the orange bar message at the top of the page even though I don't have any new messages. Heymid (contribs) 19:08, 30 July 2013 (UTC)[reply]
That'd be my guess. If it persists more than an hour or two, though, then's the time to start bug-checking. Adam Cuerden (talk) 19:13, 30 July 2013 (UTC)[reply]
I'm getting the same thing. The notifications number/box doesn't light up, just the "you have new messages" orange bar. SchreiberBike talk 19:06, 30 July 2013 (UTC)[reply]
For what it's worth, I came here to mention the same thing. New message indicator, but no messages less than a month old. APL (talk) 19:08, 30 July 2013 (UTC)[reply]

I am getting a yellow box next to the notification counter telling me "Talk: You have new messages". but the notification counter is zero, and a check of my talk page (and confirmed with a history check) shows that I don't have any new messages on my talk page. The yellow notification will disappear sometimes, and then reappear. I'm using the Chrome browser with Win 7. -- Whpq (talk) 19:03, 30 July 2013 (UTC)[reply]

As a note (this is happening to me too, see just above), FF22 with Win7 64bit here. - The Bushranger One ping only 19:05, 30 July 2013 (UTC)[reply]
I'm seeing this too. Firefox 22 on Xubuntu Linux. Thryduulf (talk) 19:12, 30 July 2013 (UTC)[reply]
Also to me on Safari 5.06, Mac OS X 5.8, Dual 2.5 GHz PowerPC G5. Ian Spackman (talk) 19:15, 30 July 2013 (UTC)[reply]

It seems to appear on page histories and diff links, but only diffs and histories that have not been visited before on that browser. Navigating to a different diff and back again clears the yellow bar. It is completely phantom, the notification area has no message and there is nothing on the talk page. It also appears when Twinkle opens a page. I am using Monobook, Firefox 22.0, Windows 7. SpinningSpark 19:20, 30 July 2013 (UTC)[reply]

Me too, it began some time after 18:30 UTC. Monobook, Firefox 22, Windows XP. I've not worked out a pattern, but it certainly does appear on previously-visited pages. --Redrose64 (talk) 19:32, 30 July 2013 (UTC)[reply]
Also happened randomly on Special:Watchlist. - The Bushranger One ping only 19:32, 30 July 2013 (UTC)[reply]
Redrose64, I think it's dependent on whether the link you click to get to the page is marked as visited or not. For instance, the diff links on a history page are blue, even if one has visited that diff before by, for instance, clicking through the diffs on an old version page. It only changes colour when one clicks through the diff link on the history page. SpinningSpark 19:41, 30 July 2013 (UTC)[reply]
I was getting it by clicking on the watchlist button at the top of the page, from any page, and sometimes it would persist for several refreshes of Special:Watchlist. - The Bushranger One ping only 19:52, 30 July 2013 (UTC)[reply]
Works as usual for me (FF22.0, Ubuntu 12.04, Monobook, Europe). I have browsing history disabled though, maybe that's the point. — HHHIPPO 19:49, 30 July 2013 (UTC)[reply]
It appears to have cleared up as I haven't noticed it happening in 20+ minutes. - The Bushranger One ping only 19:52, 30 July 2013 (UTC)[reply]
It's stopped happening for me s well. -- Whpq (talk) 19:54, 30 July 2013 (UTC)[reply]
It's currently happening for me (Chrome on Windows 7). Even when viewing previously-visited pages. bobrayner (talk) 21:28, 30 July 2013 (UTC)[reply]
It just started happening for me a minute ago. MarnetteD | Talk 21:29, 30 July 2013 (UTC)[reply]
On the top of /this/ page after refreshing after an edit conflict now. - The Bushranger One ping only 21:30, 30 July 2013 (UTC)[reply]
  • Just happened to me when I opened up the Main Page in a new tab - wasn't on Wikipedia before it started and noticed it when I first came to the site this evening Oddbodz (talk) 21:34, 30 July 2013 (UTC)[reply]

I have this problem as well, I think its a bug in server side code, I'm using chrome on windows 7 CombatWombat42 (talk) 21:34, 30 July 2013 (UTC)[reply]

[ec with Oddbodz and CW42] Reported by me at the Help Desk (final section), same problem. IE8, Windows 7, Monobook, USA. I use the orange bar, which noticeably didn't appear; I was getting the highlighted "new messages" (it looked orange to me, not yellow, but I'm not a good judge of that) next to notifications, but the orange bar didn't appear until someone left me a note pointing me to this page. Nyttend (talk) 21:37, 30 July 2013 (UTC)[reply]
I'm very zen, but the orange color really is a bit annoying. --Tryptofish (talk) 22:27, 30 July 2013 (UTC)[reply]
  • I didn't see it until I activated browsing history. Took a while until it went away after de-activating that again, but it seems related. Let's see what happens, time to sleep anyway... — HHHIPPO 22:06, 30 July 2013 (UTC)[reply]
  • I can confirm that this is happening to me too, even though my talk page hasn't been edited in about two weeks. CtP (t • c) 22:09, 30 July 2013 (UTC)[reply]

OMG! OMG OMG! OMG MOMG OMG! What is this? Can I stop freaking out? (Thanks.) μηδείς (talk) 22:11, 30 July 2013 (UTC)[reply]

Well, I use Firefox, and I also use the secure server here, but my guess is it's something within the Wiki system, and probably going on and off. --Tryptofish (talk) 23:05, 30 July 2013 (UTC)[reply]
Oh, I'm using FireFox 22.0, which is the latest I guess. And I don't get the notification when I'm logged out but it returns immediately again when I log in. —Kri (talk) 23:10, 30 July 2013 (UTC)[reply]
  • One thing I forgot to mention earlier is that, when I saw this happening, the top bar usually did not show "talk: you have new messages" until the page completed loading, showing the normal uncolored "talk" until then. Something in the CSS? - The Bushranger One ping only 23:36, 30 July 2013 (UTC)[reply]
I was lead to Visual Editor Issues/Complaints/Feedback. The Data sink. -DePiep (talk) 23:43, 30 July 2013 (UTC)[reply]
  • I had the same problem. The orange message indicator was there and wouldn't go away even though there were no new messages. North8000 (talk) 00:12, 31 July 2013 (UTC)[reply]
Do you still see the problem now? Dowjohn (talk) 00:43, 31 July 2013 (UTC)[reply]
  • @Nyttend: thanks for the message, it's gone now, but it's also many hours later. Maybe one of the Echo devs could comment on what this was and if it's solved, or if we should continue speculating and experimenting. It seems it started at the same time when html-emails were activated. — HHHIPPO 08:36, 31 July 2013 (UTC)[reply]
  • Hi all, sorry for this problem, which we believe should now be fixed. If you are still experiencing this issue, try refreshing your cache. This appears to be due to an older version of our Javascript code remaining in some of your browser caches and conflicting with our new version. We are still investigating why and how this caching bug crept in to impact the Notifications code, as we are not aware of anything we did on our end to cause it. Please keep us posted on this issue and thanks so much for reporting it! Fabrice Florin (WMF) (talk) 08:50, 31 July 2013 (UTC)[reply]

New VisualEditor RFC

If interested, see Wikipedia:VisualEditor/Default State RFC‎. Adam Cuerden (talk) 19:29, 30 July 2013 (UTC)[reply]

Nice! Market St.⧏ ⧐ Diamond Way 04:43, 31 July 2013 (UTC)[reply]

Staying Logged on

For some reason, only starting tonight, Wikipedia (and Commons) are ignoring my "Keep me logged in (for up to 30 days)" option and log me out every time the browser is closed. Is this just me or everyone?  Ronhjones  (Talk) 19:44, 30 July 2013 (UTC)[reply]

I found the problem - my bookmark was "http://en.wikipedia.org/" for some reason it now needs to be "https://en.wikipedia.org/" to stay logged in. C'ést la vie...  Ronhjones  (Talk) 19:53, 30 July 2013 (UTC)[reply]
Note this may be fixed when gerrit:76738 is merged and deployed. There's no timeframe on that happening, though. BJorsch (WMF) (talk) 20:01, 30 July 2013 (UTC)[reply]

Bizarre vandalism reversion edit

I came across this on 57567 Crikey. What is going on here? A lag? Simply south...... fighting ovens for just 7 years 22:08, 30 July 2013 (UTC)[reply]

What is so special with this edit? It's vandalism and ClueBot NG immediately cleans it up the same minute it is written, there's no lag here. —Kri (talk) 22:18, 30 July 2013 (UTC)[reply]
Nevermind. The vandalism appeared to be still there at the same time it was reverted. I did double check it earlier and I have not visited this page before today. It seemed to be some sort of visual error that has corrected itself. Simply south...... fighting ovens for just 7 years 22:43, 30 July 2013 (UTC)[reply]
Another example of this was reported at Wikipedia:Help desk#I am very sorry. The history says the edit was reverted after four seconds, but I saw the bad text in the article hours later. A purge fixed it, but that's not how it is supposed to work. -- John of Reading (talk) 06:35, 31 July 2013 (UTC)[reply]

Blacklist help with ?????

Earlier today, I created (and promptly G7-deleted) a page at ????????????; I was trying to create a pagetitle with characters my computer doesn't understand, and somehow I got sent to the question marks. ?, ??, and ??? are all valid entries, but almost everything from ???? to ???????????? (I didn't check with more question marks) has deleted edit history and nothing useful. Any chance that we could edit MediaWiki:Titleblacklist so that any title consisting solely of four or more question marks is disallowed? Some of the creations are clearly pagecreation vandalism, but I'm guessing that a bunch of them are mistakes like mine; a blacklist entry would prevent mistakes like this. Asking for someone else to supply the code, which I would happily add to the Mediawiki page; I'd add it myself, but I know nothing of regex, so attempting to do it myself would likely make this mess seem like nothing. Nyttend (talk) 22:36, 30 July 2013 (UTC)[reply]

New page titles with as three or more consecutive question marks are already blocked by the blacklist entry .*[!?‽¿]{3}(?<!!!!).*", but Administrators, Bureaucrats and Account creators are unaffected by the blacklist according to WP:UAL. Does a message about this appear when creating a page with a title such as that? Peter James (talk) 23:17, 30 July 2013 (UTC)[reply]
If no message is currently displayed, then maybe an AbuseFilter should be set up to warn admins; however, I'm not sure that would work, as admins might be able to override edit filters (even ones that are good for them!). πr2 (t • c) 04:11, 31 July 2013 (UTC)[reply]
No message is displayed. It's been a good while since I performed an action that I knew to override the blacklist, so I'd forgotten; I had thought there was a quick "Are you sure?" notice. I'd advise against an edit filter, since we don't need to impair performance for every single edit, just for the sake of preventing something so rare as this. Instead, I'd suggest that we add (or ask the developers to add) an "Are you sure?" notice for actions that override the blacklist. Nyttend backup (talk) 13:15, 31 July 2013 (UTC)[reply]
Maybe you thought of MediaWiki:Titleprotectedwarning which is displayed to admins at [31], but that's a create-protected title and not merely matching a blacklist entry. Looking at [32] from an admin account, I don't see anything we could do to warn admins that the title is blacklisted. Non-admins get MediaWiki:Titleblacklist-forbidden-edit at [33], but admins get nothing helpful. I think we would have to ask the developers to add a new MediaWiki message, but problems may be too rare to be worth the trouble. PrimeHunter (talk) 13:54, 31 July 2013 (UTC)[reply]
By the way, I didn't know it was possible to see which blacklist entry is matched. The English Wikipedia has overwitten the default MediaWiki:Titleblacklist-forbidden-edit without using the $1 parameter seen in for example MediaWiki:Titleblacklist-forbidden-edit/en-gb, so we hide the matching blacklist entry to users with the default en language. Compare [34] and [35] in non-admin accounts to see the difference. I guess there are both ups and downs of displaying the entry, considering it would make it easier for abusive editors to circumvent the blacklist by modifying the title a little. PrimeHunter (talk) 14:09, 31 July 2013 (UTC)[reply]

Screenshots of Wikipedia

I have written a guide about how to upload screenshots of Wikipedia at User:Thryduulf/How to upload screenshots of Wikipedia. It is primarily aimed at non-technical users who want to add a screenshot to illustrate bug reports and for other project uses.

I would welcome improvements to the guide and comments on its talk page. Once it is free of bugs I will move it to somewhere in Help: or Wikipedia: space if people want that. It doesn't fit with Wikipedia:Software screenshots which is about screenshots for use in articles, so I wont be merging it with that although a hatnote and maybe a see also from that page would be appropriate. Thryduulf (talk) 15:09, 31 July 2013 (UTC)[reply]

Good idea. There may or may not be content from commons:Commons:Screenshots#To create a free screenshot that you'd like to include. Killiondude (talk) 17:38, 31 July 2013 (UTC)[reply]
This section too. But I think Thryduulf's has enough for most users to figure it out. πr2 (t • c) 18:46, 31 July 2013 (UTC)[reply]
Thanks for the suggestions, I've included them as a see also section. Thryduulf (talk) 20:16, 31 July 2013 (UTC)[reply]
I've done a bit more copyediting. I think you're good to go; editors are still free to improve pages in the Help: and Wikipedia: namespaces. -- John Broughton (♫♫) 03:59, 2 August 2013 (UTC)[reply]

Email notifications

I don't know if this is a temporary glitch (the same preferences problem we had a while back?) but my notification emails have set themselves to HTML, not plain text. This seems to have happened sometime in the past 24h. Andrew Gray (talk) 23:19, 31 July 2013 (UTC)[reply]

I'm not aware of any preference to get HTML mails. They are always plain text as far as I know. What makes you identify them as HTML? If you see clickable links then it's probably your mail software which adds this to a plain text url. If you use a mail forwarding service then I suppose it might reformat the mails. PrimeHunter (talk) 00:38, 1 August 2013 (UTC)[reply]
mw:Echo (Notifications)/Feature requirements#HTML single email notifications does say: "We are planning to use HTML Email as the default format for all notifications, as soon as that feature is ready." mw:Echo (Notifications)/Feature requirements#HTML email digests says: "There will not be any email format preferences unless we hear a strong user demand for this". What type of notification mails is it? PrimeHunter (talk) 00:48, 1 August 2013 (UTC)[reply]
Oh, I now see there actually is an email format preference at Special:Preferences#mw-prefsection-echo. PrimeHunter (talk) 00:53, 1 August 2013 (UTC)[reply]
These were enabled as of about 24 hours ago. Risker (talk) 00:55, 1 August 2013 (UTC)[reply]
AFAIK the first I heard of it was at m:Meta:Babel#HTML Email Notifications are live --Redrose64 (talk) 06:29, 1 August 2013 (UTC)[reply]
Thanks for the pointer; I'll leave a note there. When I saw the preferences button I assumed it had always been there :-) Andrew Gray (talk) 11:39, 1 August 2013 (UTC)[reply]

Ghost category

Can someone figure out why Tales from the Aniverse is appearing in Category:Comics publications when the category name is nowhere to be found in the article, nor in anything transcluded on it? Hotcat won't remove the category, and it doesn't appear in the coding anywhere. Ten Pound Hammer • (What did I screw up now?) 01:42, 1 August 2013 (UTC)[reply]

See Template:Infobox comic book title#Categories. PrimeHunter (talk) 01:56, 1 August 2013 (UTC)[reply]
I did follow the instructions, but that category is still showing up. Ten Pound Hammer • (What did I screw up now?) 02:51, 1 August 2013 (UTC)[reply]
If you don't want Category:Comics publications then you need to set "subcat" or "altcat". -- John of Reading (talk) 06:30, 1 August 2013 (UTC)[reply]
(edit conflict) |subcat= and |altcat= are both empty, therefore, "the article will be placed into Category:Comics publications by default". --Redrose64 (talk) 06:33, 1 August 2013 (UTC)[reply]
altcat = Science fiction comics would work, and then the category isn't needed at the bottom (having it in two places can cause confusion if somebody tries to change it). PrimeHunter (talk) 10:21, 1 August 2013 (UTC)[reply]
That still didn't work, and neither did subcat = Science fiction comics. Help? Ten Pound Hammer • (What did I screw up now?) 10:34, 1 August 2013 (UTC)[reply]
In [36] you added altcat = Science fiction comics, but there already was an empty altcat = later (not visible in the diff). The last assignment overrides the first. I have fixed it. PrimeHunter (talk) 10:39, 1 August 2013 (UTC)[reply]

Alt-shift-p keyboard shortcut not working

I have been away for a while. There have been a few changes in the interim, including this new fangled visual editor. Not sure if this is related to VE but the alt-shift-p as both print page and as a 'show preview' no longer works for me. Am running WinXP and Firefox Ver 22. Be good to get it sorted. Cheers. -- Alan Liefting (talk - contribs) 07:59, 1 August 2013 (UTC)[reply]

I'm on a Mac with Firefox 22, and ctrl-option-p is working for preview. Would you mind trying again? I think that they updated some of the software yesterday, and things sometimes go a little strange for a bit when that's happening. (For me, when an access key doesn't work, it usually means that my cursor is once again sitting in the Find box rather than on the Wikipedia page, but I don't think I've ever heard of anyone having that problem—or, at least, not having that problem as often as I do.) Also, are the other access keys working for you? Whatamidoing (WMF) (talk) 17:04, 1 August 2013 (UTC)[reply]
Turns out it is not a Mediawiki issue and I now recall having this problem in the past. Window Media Player uses alt-shift-p unless the minimise to toolbar option is disabled. Problem fixed by disabling the minimise to toolbar. Cheers. -- Alan Liefting (talk - contribs) 21:32, 1 August 2013 (UTC)[reply]
Resolved

Logo image in infobox

At Pittsburgh Parks Conservancy . . . I tried every possible configuration but it still isn't going through. The image appears in yesterdays history of the article, and is still loaded on wikipedia. Thanks in advance. Market St.⧏ ⧐ Diamond Way 12:35, 1 August 2013 (UTC)[reply]

Fixed in [37]. Image parameters are not standardized across infoboxes. Look at the documentation for the specific infobox, in this case {{Infobox non-profit}}. PrimeHunter (talk) 12:42, 1 August 2013 (UTC)[reply]
Big thanks PrimeHunter!
Resolved
Market St.⧏ ⧐ Diamond Way 12:45, 1 August 2013 (UTC)[reply]
That can be fixed by using Module:InfoboxImage to support various types of markup. See {{Infobox WorldScouting}} for instance. --  Gadget850 talk 18:24, 1 August 2013 (UTC)[reply]

Overwriting sections

I now know of two cases where I have accidentally overwritten sections, thus removing information. The first one I found was at Joan Armatrading where I overwrote a section in October 2012 and then put it back in February 2013. Just today (UTC) I discovered that I did something similar to the Blindness article in March 2008! As I'm obsessive (some would say paranoid) about article integrity, the fact that I, an experienced admin, have managed to make this mistake *twice* without it being detected frankly scares the heebie-jeebies out of me. I'd like to find out:

  • Am I the only one who's done this? Is the fact that I've managed to do this so easily an artifact of my screen reader use (because I don't actually see a physical model of the screen)?
  • Is there any way to detect other instances like the ones I've described above (either by me or others)? I personally haven't done much article expansion (except last year with Paralympic-related articles, where this problem almost certainly didn't occur. But I wonder if we've lost any other article text this way?

I don't really expect concrete, definite answers (especially to the second question). I'm also not too sure if this is the right place for such a query, but this seems to be the best fit. I just had to get this quandary off my chest. Graham87 16:30, 1 August 2013 (UTC)[reply]

It looks like, in October 2012, you realized that you'd made a mistake - created the same section twice - but not that you'd overwritten a section - so you deleted your duplicate section.
I think it's fairly difficult to do what you did. You have to (a) open up the wrong section; (b) not realize that you are in the wrong section; and (c) paste the text you've composed outside of Wikipedia (I assume) on top of the existing text, rather than editing it. The last of these isn't done very often, I think; if it is, it's certainly an argument against the new VisualEditor approach to editing.
The two edits you point to resulted in significant deletions of text, though in the first case it was a two-edit process, and in the second, just a single edit. So one way to detect this would be to look at one's contributions list, for such significant negative figures. Of course, for someone with a lot of contributions (that would be you), this is more difficult. I don't know of any tool to select edits based on characters added or deleted, but I suppose a database extract would be quite easy to sort contributions in that way.
Also, some context: someone with a good reputation (that would be you) is more likely to not be questioned (or reverted) when he/she makes a mistake, particularly - as I said above - one that seems to me to be quite rare. So your situation is even rarer in that less experienced editors might well be asked "Did you want to overwrite that other section"? -- John Broughton (♫♫) 03:38, 2 August 2013 (UTC)[reply]
@John Broughton: Thanks very much for your response. Yes, in both those examples, I had pasted the section in from a text editor. I do this fairly often when making non-trivial edits to articles because I find it more comfortable and more consistent than an HTML textarea with JAWS. (For an example of one of the ridiculous problems I had, I once had my zoom level set to 400% for a few months without realizing it ... that might have explained my issues with very short lines in the edit window!)
I imagine it would be easier for me to edit the wrong section without my knowledge because I can quite easily cut off speech (I can press enter to go into forms mode then delete a whole section without hearing any of the text that I've just deleted). I doubt I've remove text in this way too often ... most of my section-level edits are copyediting, where it's quite easy to figure out if I'm editing the wrong section! I'll go through my own article expansions and check for similar issues. Graham87 07:22, 2 August 2013 (UTC)[reply]
Oh, another reason why I use a text editor to edit Wikipedia more than most people probably do is that the in-browser find feature is fairly useless for me no matter which browser I'm using. I can search for text in a browser window, but if I want to edit it, I have to go into forms mode in JAWS and navigate to it again from scratch – thus defeating the purpose of the find feature entirely. With an external editor, finding and replacing text is much easier for me. Graham87 07:56, 2 August 2013 (UTC)[reply]
@Graham87: I find it amazing that you are so fluent in editing wikipedia to begin with. It is good to have you Graham87 ! P.S. Matmarex and I have been adding some keyboard navigation features to mw-collapsibles (our third, but core form of collapsing elements) and sortable tables. I hope they are useful to you as well and at the very least not obtrusive ! —TheDJ (talk • contribs) 09:35, 2 August 2013 (UTC)[reply]
I have occasionally found that I am editing the wrong section. This happens only on discussion pages, and the "wrong" section is one from later on in the page. The scenario is that I read through a thread, consider my reply, and then go for [edit], only to find that the edit window is not the section that I intended. Checking the editing history, I find that in between me going to the page and going for [edit], an archiving bot has been along and deleted some sections from earlier in the page. --Redrose64 (talk) 09:44, 2 August 2013 (UTC)[reply]
@TheDJ: Thanks very much! I've just tested the new sorting code at List of countries by population. I think the idea of making the sort toggles into actual buttons is a good idea for accessibility, but unfortunately, for some bizarre reason, JAWS 14 (the latest version) now doesn't recognize the table headers in both Internet Explorer 10 and Firefox 22 (i.e. it thinks the first entry in the list is the column header and acts accordingly). This is not a good thing.
@Redrose64: Yeah, I've occasionally encountered that problem as well. And I'll never forget this bug (long since fixed, thank goodness) that caused a similar problem. Graham87 10:07, 2 August 2013 (UTC)[reply]
@Graham87: Eh.. stupid JAWS... Why does it 'make up' table headers. Well perhaps we should remove the "role=button" from the header then. I guess it conflicts with the 'other' definition of it being a header. The tabindex probably will still be enough. This also has implications of other uses of role=button I guess. —TheDJ (talk • contribs) 11:56, 2 August 2013 (UTC)[reply]

Change to VisualEditor integration on the English Wikipedia

As discussed as part of (one of the two) current RFCs about VisualEditor, we have made some changes to how VisualEditor appears here. The most noticable change is that the wikitext editor ("edit source") is now the primary (first) link, the section edit links' animation is gone (finally!), and VisualEditor is now explicitly called "beta" on its tabs. You can read more details in the update.

My thanks again for those who gave feedback on the proposals, and I'd love to hear thoughts on what further tweaks or changes we can make.

Jdforrester (WMF) (talk) 05:37, 2 August 2013 (UTC)[reply]

The change that has just been done completely overlooks the fact that the vast majority of visitor to WP are readers. Instead of a small link showing [edit] off to the right we now have in your face, intrusive links next to the header. Readers need not see the visual editor link and they do not need to know it is in beta. If readers are going to be subjected to the plethora of edit links at all they should be unobtrusive, i.e. small and to the right and NOT two of them. -- Alan Liefting (talk - contribs) 06:53, 2 August 2013 (UTC)[reply]
@Alan Liefting: To clarify, this change has not changed the position of the section edit links (they've been on the left for some months now, in a change entirely unrelated to VisualEditor), and neither has it changed the provision of the links to readers who are logged-out (it's been that way for years). We've done our best to down-play them now there are two (I, too have concerns about showing both of them at once as being too "heavy"). I don't think that this is perfect, but I would disagree that we have over-looked readers. Jdforrester (WMF) (talk) 07:07, 2 August 2013 (UTC)[reply]
This change makes reading Wikipedia more annoying for screen reader users, due to bug 11555. The word "edit" (now "edit source[editbeta]" appears as part of the heading title, which is read out in full whenever a screen reader user navigates between headings. I wrote it like "editbeta" because that's how my screen reader JAWS pronounces it – it's read as one word and sounds like "edit betta" in the default American English synthesiser, which kinda reminds me of the Macintosh Performa. The hover links that were previously there were inaccessible, but I never noticed them because I use IE as my primary browser; it's the one that works best with JAWS. Graham87 07:35, 2 August 2013 (UTC)[reply]
Hi Graham, I am going to add this to the bug you mentioned. Thanks for your feedback, hope this gets fixed soon. --Elitre (WMF) (talk) 08:32, 2 August 2013 (UTC)[reply]
Thanks for that, Elitre. Graham87 09:46, 2 August 2013 (UTC)[reply]
Strangely, "Beta" does not appear on page .tl, and clicking 'Edit' on a section does not bring up either editor. Chris the speller yack 15:14, 2 August 2013 (UTC)[reply]

Edit source vs. Edit

Can this be switched back so it just says "Edit", esp. on the section headings on an article. Or to have an option in your preferences along the lines of "Change the "new section" tab text to instead display the much narrower "+"." Thanks. Lugnuts Dick Laurent is dead 07:04, 2 August 2013 (UTC)[reply]

See the thread directly above and the corresponding link to Wikipedia:VisualEditor/August 2013 update. Killiondude (talk) 07:12, 2 August 2013 (UTC)[reply]
I've read the update, but I want to change the display to show simply "Edit". Can this be done? Lugnuts Dick Laurent is dead 07:16, 2 August 2013 (UTC)[reply]
If you go to the bottom of Special:Preferences#mw-prefsection-editing, and check the option for "Temporarily disable VisualEditor while it is in beta", that will do it. Canuck89 (converse with me) 08:52, August 2, 2013 (UTC)
This is going to disable VE, which is not really what is being asked here. (This said, I am not aware of ways to override the default labels, while Lugnuts can certainly propose a rename here or in similar venues). --Elitre (WMF) (talk) 09:20, 2 August 2013 (UTC)[reply]
Has the previous setting of that been lost? I'm pretty sure I disabled the VE the other day, and now my setting seems to have disappeared. Sigh. —Tom Morris (talk) 11:36, 2 August 2013 (UTC)[reply]
I'm fairly certain this can be accomplished with a personal JavaScript. There was a thread a while back about removing the brackets from around the edit link; try searching for that. Pinging User:Writ Keeper and User:Theopolisme because I'm rather busy (and don't know JavaScript that well). Ignatzmice•talk 11:42, 2 August 2013 (UTC)[reply]
@Tom, no, it hasn't. (copy/pasting the rest I posted elsewhere: What you experienced was not intended at all (see Wikipedia:VisualEditor/August_2013_update). It is my understanding that the recent changes happened to somehow "break" the unofficial, community-developed gadget that you were using. You can still use the official one which you can find in your Preferences, as noted. Sorry if this caused trouble.) --Elitre (WMF) (talk) 11:48, 2 August 2013 (UTC)[reply]
Here is some JS that renames edit source to edit, and below is some CSS that hides "| edit beta" from section links. WARNING: I have only tested this code on Chrome v28 on Windows 7 - use at your own risk.

Add the following to Special:MyPage/common.js (or a skin-specific file) 

// Change "[Edit][Edit source]" to "[VE][Edit]" --top tabs
jQuery( function( $ ) {
    if (document.getElementById('ca-ve-edit'))
        {
        var vetab = document.getElementById('ca-ve-edit');
        vetab.getElementsByTagName("a")[0].innerHTML="VE";        
        var setab = document.getElementById('ca-edit');
        setab.getElementsByTagName("a")[0].innerHTML="Edit";
        // Change "edit source" to "edit" --section links
        sections = new Array();
        sections = document.getElementsByClassName("mw-editsection mw-editsection-expanded");
        if (sections.length == 0)
            { sections = document.getElementsByClassName("mw-editsection"); }
        var i=0;
        while (sections[i])
            {
            sections[i].getElementsByTagName("a")[0].innerHTML="edit"
            i++;
            }
        }
} );

Add the following to Special:MyPage/common.css (or a skin-specific file) 

/* == HIDE VE SECTION EDIT LINKS == */
.mw-editsection-divider,
.mw-editsection-visualeditor { display:none !important; }

Any improvements from advanced coders would also be appreciated. - Evad37 (talk) 12:07, 2 August 2013 (UTC)[reply]

Whoo-eee, that's fine! Works splendidly on Safari 6/Mac OS 10.8. Seems to have the side benefit of restoring the "right-click on the header line to edit" gadget to edit source, not VE. I think I'll keep it around! One not-really-a-coding suggestion: You could put the script in your userspace (to make it easy to import/more official) and then stick a line in to import the CSS (as part of the JS), so people don't have to edit two separate pages.

I renamed my tabs using the following code in my personal javascript file: 

$( document ).ready( function() {
  $( 'a', '#ca-addsection' ).text( '+' );
  $( 'a', '#ca-history' ).text( 'Hist' );
  $( 'a', '#ca-viewsource' ).text( 'Source' );
  $( 'a', '#ca-talk' ).text( 'Talk' );
  $( 'a', '#ca-edit' ).text( 'Source' );
  $( 'a', '#ca-view' ).text( 'Read' );
  $( 'a', '#ca-nstab-user' ).text( 'User' );
  $( 'a', '#ca-nstab-project' ).text( 'Project' );
  $( 'a', '#ca-nstab-mediawiki' ).text( 'Interface' );
  $( 'a', '#ca-nstab-help' ).text( 'Help' );
  $( 'a', '#pt-mytalk' ).text( 'Talk' );
  $( 'a', '#pt-preferences' ).text( 'Prefs' );
  $( 'a', '#pt-watchlist' ).text( 'Watchlist' );
  $( 'a', '#pt-mycontris' ).text( 'Contribs' );
  $( 'a', '#pt-logout' ).text( 'Logout' );
});

Reaper Eternal (talk) 12:24, 2 August 2013 (UTC)[reply]

I've always had Visual Editor disabled under Preferences/Gadgets. It still says "Edit Source" on my browser, as of today. I guess that takes some getting used to. I first noticed it on my Talk Page this morning, and my reaction was that somebody must have protected my page. Then I noticed that it's on all pages. It's a little disconcerting. — Maile (talk) 12:30, 2 August 2013 (UTC)[reply]
The setting at Preferences → Gadgets → Remove VisualEditor from the user interface just hides the VisualEditor, it doesn't actually remove it, so tabs and edit links may still behave strangely. However, the setting at Preferences → Editing → MediaWiki:Visualeditor-preference-betatempdisable prevents VE from loading, so tabs etc. should behave properly. To replicate the pre-VE behaviour, switch on the Editing one, and switch off the Gadgets one. --Redrose64 (talk) 12:52, 2 August 2013 (UTC)[reply]
Disabling it thru the Preferences/Editing worked for me. Thanks. — Maile (talk) 14:16, 2 August 2013 (UTC)[reply]
The gadget doesn't work currently due to a change in VE. It would be great if somebody with the proper knowledge could update MediaWiki:Gadget-oldeditor.js so users who have enabled the gadget and are satisfied with it don't have to find where to disable VE now. The gadget is not made by the VE team and they don't maintain it or keep VE compatible with it. PrimeHunter (talk) 13:49, 2 August 2013 (UTC)[reply]
PrimeHunter, what's wrong for you with the "official" gadget in Special:Preferences#mw-prefsection-editing --> Usability features? Thanks, --Elitre (WMF) (talk) 14:04, 2 August 2013 (UTC)[reply]
That one works. I only say "gadget" about the Gadgets tab. I was replying to Redrose64 who wrote: "The setting at Preferences → Gadgets → Remove VisualEditor from the user interface just hides the VisualEditor". I know that gadget isn't made by the VE team and they have never said they would keep it compatible with VE. But there are many users who have the gadget enabled and will be annoyed when they see VE has reappeared and they don't know the Editing preference that works. See Wikipedia:VisualEditor/Default State RFC#Was this just turned on for all users? for examples of angry users. PrimeHunter (talk) 14:15, 2 August 2013 (UTC)[reply]
(edit conflict)I agree 100% with User:PrimeHunter. I thought I had disabled this (expletive) thing on the preferences page, and today the bloody thing pops up again with editsource editbeta allover the place. I'm annoyed that I had to waste 10 minutes of my time trying to figure out how to kill it again. Then I see an option to "temporarily" disable it!? I don't want temporary... I don't want to see this thing ever again. A very clear consensus is forming at the RfC that this POS be opt-in only, to cause this thing to turn on again when it's been turned off is spitting in the face of the community.–Wine Guy~Talk 14:23, 2 August 2013 (UTC)[reply]
Yeah, I had to say option, sorry for that. If people want to fix the "unofficial" gadget, that's fine: but if this does not happen, I just wanted to make sure everybody realize there is no real need for that anymore since the "official" option does work. WineGuy, can you please see my second comment in this thread? Seeing VE again today was not planned or intended, again, I'm sorry for the trouble. --Elitre (WMF) (talk) 14:43, 2 August 2013 (UTC)[reply]
The unofficial gadget isn't needed currently for users who know the Editing preference, but this may change. The preference displays MediaWiki:Visualeditor-preference-betatempdisable. As strongly hinted by both the message name and text, the Wikimedia Foundation may remove this option when VE is officially no longer in beta. I think we should keep the gadget. If the gadget can be changed to toggle the Editing preference as suggested by Matma Rex then great, but if we delete the gadget and restore it later then I don't know whether its new state can be restored from the old state for those users who had enabled the old version and will be annoyed if they have to enable it again. PrimeHunter (talk) 15:20, 2 August 2013 (UTC)[reply]

Mysterious data override

Someone please have a look at this and comment on what's causing the issue?

Might be Wikidata but I'm as yet totally unfamiliar with that, especially any silent overrides. (Sorry in case I should be apologizing for that.)

TIA, --217.81.163.66 (talk) 12:48, 2 August 2013 (UTC)[reply]

The figure comes from Template:Metadata Population DE-BB. --Redrose64 (talk) 12:58, 2 August 2013 (UTC) (moved from Talk:Steinhöfel#What technical "miracle" is overriding the figures from the info box to avoid having a split discussion) --Redrose64 (talk) 13:39, 2 August 2013 (UTC)[reply]
Thanks again Redrose. Just learned (or re-learned;) that WP:MULTI thing from you. Great! — Preceding unsigned comment added by 217.81.185.254 (talk) 14:02, 2 August 2013 (UTC)[reply]
Thanks Redrose. How do I clean up the source so there will be no inconsistent data issue?
This looks something like nested implicit template transclusion, that's a little over my level of WP template intricacies at the moment.
How much of what can I take out without doing damage to what's there?
As this has broadened into the more general question of "How to resolve data override by (nested/cascading) Data Template Transclusion",
please find that below and answer there. TIA
P.S.: Special thanks for cleaning up the TOC issue on the go. Oh yep, I accidentally used braces instead of underscore.
--217.81.163.66 (talk) 13:12, 2 August 2013 (UTC)[reply]

How to resolve data override by (nested/cascading) Data Template Transclusion

please see "Mysterious data override" above and answer here as this has broadened into a new question

TIA, --217.81.163.66 (talk) 13:21, 2 August 2013 (UTC)[reply]

In your example it's done by templates at the English Wikipedia and not by Wikidata. Any template can be coded to ignore parameters and use data from elsewhere, but the behaviour has to be coded into the specific template. The details vary. Steinhöfel uses Template:Infobox German location. The documentation says "Population data automatically transcluded from {{Population Germany}}." PrimeHunter (talk) 13:37, 2 August 2013 (UTC)[reply]

Search: When something is in a WikiProject:'s talk page, what search namespace would that be in?

I made a post on WikiProject:Psychology Talk and, searchwise, it seems to be gone. How?

Could I have missed the right checkmark in Advanced Search or is this really a glitch in the tech?

Case is this: (Psychology), with brief cross-posts at (Anthropology) and Sociology.

TIA, --217.81.163.66 (talk) 13:09, 2 August 2013 (UTC)[reply]

It's in the Wikipedia talk namespace, but those posts are from today and haven't been indexed by the search feature yet. See Help:Searching#Delay in updating the search index. PrimeHunter (talk) 13:26, 2 August 2013 (UTC)[reply]

Negative Image

Hi, I recently updated this image http://en.wikipedia.org/wiki/File:Angels_Den_Main_Logo.jpg. Unfortunately, the image came back in a sort of negative fashion; changing the original colours. Thanks. Rhâmusker Rhamusker (talk) 15:54, 2 August 2013 (UTC)[reply]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&oldid=566869150"