Wikipedia:Village pump (technical)/Archive 114

Add links
From Wikipedia, the free encyclopedia
Village pump (technical) archive  

This page contains discussions that have been archived from Village pump (technical). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.

< Older discussions · Archives: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR, AS, AT, AU, AV, AW, AX · 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211

Need a little MATH help

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

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

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

EmilJ gave a link, in that there are some tables which list most of the symbols. The "Unicode codepoint" column has the relevant codes, but to use these in Wikipedia you need to convert them to valid HTML. You do this by altering U+ to &#x and appending a semicolon ; - for example, the leftmost symbol of this (which is the final symbol to be processed) is "Execute", fourth from bottom of the Monadic functions table. It's shown as U+234E, so we would write &#x234E; which displays as ⍎ (this isn't very clear so I'll enlarge it: ⍎).
There are several more listed at Charbase Miscellaneous Technical Block - search for "APL FUNCTIONAL SYMBOL", they're mostly between U+2336 and U+237A. The fourth column gives codes that you can use directly, without conversion. You can also click the link in the left-hand column to see a large version, for example a page like this, the codes that you need are given in the "HTML Escapes" row. When two codes are shown, as with this one, which shows &#9038; &#x234e; you can use either one, they come out identically: ⍎ ⍎ --Redrose64 (talk) 07:49, 5 July 2013 (UTC)
There is no need to convert it to HTML entities. Just copy-and-paste the actual character from the table, that’s far easier.—Emil J. 11:45, 5 July 2013 (UTC)
That's if your browser/OS lets you do that without trashing the character. Anyway, the special characters needed are:
This gives ⍎'⎕',∈N⍴⊂S←'←⎕←(3=T)∨M∧2=T←⊃+/(V⌽¨⊂M),(V⊖¨⊂M),(V,⌽V)⌽¨(V,V ←1 ¯1)⊖¨⊂M'
The symbols '()+,/123=MNSTV are just the normal ones that you type at the keyboard. --Redrose64 (talk) 13:25, 5 July 2013 (UTC)
That’s amazing work, but are you sure about the diaeresis? I don’t know anything about APL, but the character on the picture looks quite different (besides not being a combining character). I’d go with ⍎'⎕',∈N⍴⊂S←'←⎕←(3=T)∨M∧2=T←⊃+/(V⌽"⊂M),(V⊖"⊂M),(V,⌽V)⌽"(V,V ←1¯1)⊖"⊂M'.—Emil J. 13:55, 5 July 2013 (UTC)
In the images [2] [3] [4] (and several others) it certainly looks like a double quote; but the intent is the each operator, as described in the original doc (search for "which is called Each") - the author of that uses two apostrophes at the only point where he uses it in plain text. At APL syntax and symbols#Syntax rules, the each operator is represented using a diaeresis, although that is not explicitly stated as the correct character. Whatever the actual symbol, I couldn't find anything called "each" in the various Unicode lists, but at this page we do have the U+00A8 diaresis, fifth row from bottom. --Redrose64 (talk) 16:24, 5 July 2013 (UTC)

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

nonarticle namespaces main pages

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

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

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

As far as I know, there are no "home" pages for any namespace, with the possible exception of articlespace (and even that's debatable - http://en.wikipedia.org/wiki/ is actually root for all namespaces.
It's not clear that there is any advantage in creating such "home" pages. The error message you got, while perhaps lacking in clarity, does cover your case - you used a URL that had no page title, and the error message begins "The requested page title is invalid. It may be empty ..."). ["empty" = "blank" = "not provided", in programmerese]
More to the point - changing this situation would require programming resources. It's difficult to justify doing so: you put in a bad url, and you got an error message. You were looking for something (a "home page") that doesn't exist, and you found out it didn't exist. -- John Broughton (♫♫) 16:48, 7 July 2013 (UTC)
No such thing as "namespace home page" exists; zero-length titles are invalid, and "Help:" is a zero-length title in the "Help" namespace. On a side note, there is a volunteer's patch in gerrit aiming to improve that error message (https://gerrit.wikimedia.org/r/#/c/43166/, "Show detailed errors for bad titles." by "VitaliyFilippov").
What were you expecting to find under that URL? :) Matma Rex talk 17:04, 7 July 2013 (UTC)
What I wanted to find was something like a directory of relevant pages, in this case pages in the Help namespace, as presumably there wouldn't be a namespace unless there's more than one page (or at least a plan for more than one page), so I could choose the page most relevant to my need.
It's usually more user-friendly to have a home page for any directory (or namespace) that's open to the public. I found out the page was bad but it wasn't clear how to get what I wanted, which is the point of the Bad Page itemization. The root you gave redirects to Main_Page, which is good for that namespace and indirectly for other namespaces. http://en.wikipedia.org/w/ also redirects to the same Main_Page (in the wiki/ directory). As I recall from a non-Wikimedia context, redirects on Apache platforms are one- or two-line text files and, even if there are hundreds of namespaces, the same file can be copied to all of them except the destination (which doesn't need a new one). Editing the Bad Page for clarity doesn't seem like it would take a lot of programming resources, and that page should be clear to nongeeks, to whom a namespace and a colon does not appear to be zero-length. Clarifying may be easier than adding redirects.
Nick Levinson (talk) 18:28, 7 July 2013 (UTC)
The error message is from MediaWiki:Badtitletext. I don't know whether it can be customized to recognise which title it's displayed on but I don't think it would be worth customizing it for a few manually created invalid url's like this. By the way, a search on Help: (and similar for other namespaces) gives the red error message: "An error has occurred while searching: The search backend returned an error:". I consider that slightly more problematic but not worth bugging developers about. PrimeHunter (talk) 22:21, 7 July 2013 (UTC)

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

Special:AllPages is somewhat useful, although it doesn't indicate which page might serve as a main page for the namespace.
Customizing according to a user's request is almost certainly far too much programming. Adding to or clarifying the itemization that's already there would be easier to do and good enough for nongeeks, and offering a partial solution like Special:AllPages could be helpful.
I wanted to check a hit counter for the Bad Page, but since it keeps the URL I had typed I don't know how to check how often the Bad Page is visited from all the URLs that could generate it. Customizing for one URL is wasteful, but clarifying regardless of URL is probably relatively useful.
But if it's still not worth fixing, I'll leave it at that. Thanks for the feedback. Nick Levinson (talk) 15:57, 8 July 2013 (UTC)

Audio thumbnails no longer resize

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

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

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

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

VE: request earlier implementation - partially

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

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

Looks like this has already been proposed with mixed reactions. Theopolisme (talk) 17:35, 7 July 2013 (UTC)
Personally, I support the use of a consistent tab label. If "edit source" is going to be the label we are stuck with for articles, then having the same description applied to all source editing tabs makes sense. Dragons flight (talk) 17:57, 7 July 2013 (UTC)
I was about to strike my request here, but then I read the immature discussion in June (!) (with bug ref bugzilla:50402) you linked to. Because of that immatureness I keep this post open. -DePiep (talk) 18:07, 7 July 2013 (UTC)
I support renaming, FWIW -- it's going to happen eventually (well, not for the talk namespaces, but presumably everywhere else), so why not get editors used to it now? Theopolisme (talk) 23:03, 7 July 2013 (UTC)
For future reference, WP:VE/F is the best place to give feedback for the VisualEditor (or to check for existing threads requesting the same feature/bugfix) so the developers can see it. Hope that helps. --AKlapper (WMF) (talk) 16:14, 8 July 2013 (UTC)

About common.js

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

Yes if you trust the script you/re loading then you can go ahead. Theoretically someone could replace it with a virus but the only people who can edit that page are TheJJJunk (talk · contribs) and administrators. I would hope that among those people no one would want to deliberately infect other Wikipedia users. —Soap— 05:27, 8 July 2013 (UTC)
A common.js page loads javascript no matter what skin you are currently using. If you know a piece of js code will only work and/or be beneficial for a specific skin, you can name it xx.js where xx is the skin name (vector.js, for example). Help:Javascript might be some good reading. Killiondude (talk) 05:47, 8 July 2013 (UTC)
The message you saw basically means that if you should exercise a bit of caution. Personally, I've never heard of a script that was compromised/malware, but perhaps there are (rare) examples where it happened in the past. More to the point, if I were in your shoes, what I'd do would be (a) think about how I found the script - the more obscure the path, the more to think about (and I certainly would never copy a script from other than a Wikipedia page), and (b) make sure that the page with the script (the one you're importing, or copying from) ends with .js; that prevents anyone but the owner, and admins, from editing it.
If you see something suspicious, asking here is a good idea. Otherwise, just go ahead and add the script, and don't worry about it.
(P.S. "commons.js" is the default location that the software running Wikipedia looks, to see if you have any scripts that you want to use to enhance your reading or editing experience. The browser you use doesn't matter, at least as far as the filename goes.) -- John Broughton (♫♫) 16:14, 8 July 2013 (UTC)
Although the message is a bit hard, and your msg "Personally, I've never heard of a script that was compromised/malware, but perhaps there are (rare) examples where it happened in the past." is correct - loading resources from other servers but WMF servers result in releasing one's IP address, the web browser and operating data and other additional information (e.g. maybe geolocation data). Although this don't have to result in a overtaken computer, it might be against one's privacy. mabdul 21:57, 8 July 2013 (UTC)

File does not render below 15px

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

Youd probably be better off using a PNG or other raster image format, since that particular SVG probably wasnt intended to ever be so small. Im not sure what youre seeing on your screen, but for me the 15px version is just a gray solid star, which although visible, really doesnt look much like the full size image either. For a PNG image, we already have File:Award-star-gold-3d.png which appears as at 13 pixels. —Soap— 05:29, 8 July 2013 (UTC)
Actually, it renders strangely for everything under 100px:
  • Original PNG, SVG:
  • Award-star-gold-3d.svg 100,90,80,70,60,50,40,30,20,10px:
I found one with a slightly different filename (Award star instead of Award-star) that works fine:
  • Award star-gold-3d.svg 100,90,80,70,60,50,40,30,20,10px:
So, there's either something wrong with the SVG or the way that particular file is being handled by the wiki(s). I'll note that the working one is much larger and has a PNG embedded in it. —[AlanM1(talk)]— 10:04, 8 July 2013 (UTC)

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

You could try directly contacting any of the committers of librsvg librsvg gitlog. Might spur a bit of activity. —TheDJ (talk • contribs) 12:29, 8 July 2013 (UTC)
I already posted to the GNOME "desktop-devel-list" (see [7] for the archived discussion) and asked for some hints how to get patches into the code. I was recommended to contact the maintainers who are listed here, but I didn't receive an e-mail response – neither from Hiroyuki Ikezoe nor from Christian Persch. It's an unfortunate situation, especially since it doesn't seem to be much of a priority for the WMF either. --Patrick87 (talk) 12:59, 8 July 2013 (UTC)

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

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

Pool queue is full

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

Problems with links to other languages

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

The source of Sateen contains [[sv:Satin]] and sv:Satin contains [[en:Sateen]], so they are linked directly without being connected in Wikidata. PrimeHunter (talk) 12:41, 8 July 2013 (UTC)
  • Need to crosslink one-to-many articles: The underlying problem is the need to link an article, in one language, as a one-to-many link selecting a set of articles in another language, and vice versa. Because disambig pages have been limited to almost indentical titles, the one-to-many crosslink pages are based on "related concepts" rather than "related spellings" and so an English article about "Stream" could link to a German crosslink page listing several related terms, such as: Fluss, Flysschen, Strom, Bach (or whatever article titles), and then each article would back-link to a crosslink page, so German "Fluss" would link to a page listing: Brook, Creek, Stream, Canal, Channel, or River (etc.), perhaps with explanations that a creek is typically much smaller than a river, and "Flysschen" might be emphasized as the best match to describe a creek. A similar approach could be used to crosslink Satin and Sateen, along with related terms. Currently, many other-language wikis are cross-connected to disambig pages but that has biased the connections to articles with similar titles, rather than to various articles about the same general concepts with the see-also links to related concepts, rather than related spellings. -Wikid77 (talk) 17:41, 8 July 2013 (UTC)
Satin is a warp-faced weave; sateen is weft faced. Other than that, they're essentially the same cloth. An eight-end satin will use eight heald shafts, seven of which are raised while the other one is lowered; an eight-end sateen will also use eight heald shafts, but only one of them is raised while the other seven are lowered. Both raise and lower in a 1-4-7-2-5-8-3-6 sequence. Some looms will partially (or wholly) lower all the heald shafts for the beat-up phase of the cycle, even if some of them need to be raised again for the next pick, so one of these looms, when weaving a warp-faced cloth, will use more power than the same loom weaving a weft-faced cloth. Many weavers, when requested to weave satin, will actually weave sateen and then simply turn the cloth over. Therefore, it's natural to put both weaves on the same article. --Redrose64 (talk) 20:31, 8 July 2013 (UTC)
  • Linked Satin pages to each other: Since the Swedish word for "satin" is also "satin" (as is German "Satin"), I simply connected the Swedish page to the English "Satin" article, until the Swedish WP gets an article named "Sateen". -Wikid77 (talk) 05:23, 9 July 2013 (UTC)

Toggling on/off visibility of reverted edits in article history

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

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

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

Technically, I'd hazard a guess that it is. Hiding revisions like that is theoretically doable (though very annoying to do in practice) by deleting the entire page and then selectively restoring only the worthwhile edits. But is that something we want? Writ Keeper ⚇♔ 17:01, 8 July 2013 (UTC)
No, I'm not talking about deletions at all. Read my second paragraph as how I think it would best work, such that it is entirely reader-enabled and completely temporary even for that reader. postdlf (talk) 17:08, 8 July 2013 (UTC)
(edit conflict) Somewhat related: bugzilla:16619, bugzilla:11664. Do you want to do this server-side or via JS? It certainly is possible, but may be inefficient. πr2 (t • c) 17:04, 8 July 2013 (UTC)
@Postdlf: Did you read the comments at previous discussions, e.g. Wikipedia:Village_pump_(proposals)/Archive_F#An_option_in_preferences_to_hide_reverted_edits.? πr2 (t • c) 17:16, 8 July 2013 (UTC)
I hadn't seen that particular thread. I had started one at a VP page probably a couple years ago, but I think I was proposing the hiding being actually part of the page history rather than just a reader-controlled, impermanent filter, like when you just want to see your Wikipedia-space edits in your contribution history, for example. I think the comments at your VP-proposals thread also assumed that the hiding would actually affect the edit history itself, such that one editor "hides" an edit and it is then hidden for everyone. That would be the wrong way to do it. postdlf (talk) 17:23, 8 July 2013 (UTC)
This one of those features that would be very expensive to do correctly and would leave a false sense of security if done poorly. I find a lot of people leave the "undoing ..." edit summary intact when they start out by reverting the editor and add something (a common case is if I revert an edit as unsourced. I frequently see an "undo" applied and a source added simultaneously). I also frequently revert edits without using the undo button, simply by opening the last good version and saving it with an edit summary explaining why. To handle those cases would require that the tool actually examined each diff in the history. This would make sense as a special tool, but not for the default history view.—Kww(talk) 17:04, 8 July 2013 (UTC)
Yeah, I've thought about that issue when "undo" edits being more than just a straight "undo". How difficult is it though to have the software identify and match up only [change][-change] edits, regardless of how labelled? So if someone adds "poop" to an article, someone else removes it, both would be selectively hidden; if someone adds "poop" to an article, someone else removes it and corrects the spelling of another word, then neither would be captured by this. One way would be just to limit it to uses of the revert tool, which would capture a good portion of the useless edits. postdlf (talk) 17:08, 8 July 2013 (UTC)
Postdlf, how would you expect such a thing to work if there were useful edits in between the vandalism and reversion? I can see it easily working for all of the back to back edit/reverts or the ones that have the revision they are reverting in the edit summary, but what of the others? This would seem to make it a little more tricky to code with a JavaScript userscript. I would doubt this would be considered useful enough for it to be coded into mediawiki itself or even as an extension... Just my thoughts and a question... Technical 13 (talk) 17:24, 8 July 2013 (UTC)
Limiting it to just uses of the revert tool would avoid that problem entirely as you can only use revert on the most recent edits by a single user. However, even if it also applied to undo, undoing an edit identifies which edit is being undone, and then it's just a question of excluding undos that also make other changes at the same time. Given that the revert and undo tools are able to select out what text an edit changed, and then undo just that change, it should be possible to identify when that has happened, both in the original edit and the edit that reverts/undoes it.

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

(edit conflict) The others don't matter. Just hiding back-to-back vandalism/reverts would be enormously helpful on its own; more complex stuff is rare and doesn't necessarily need to be hidden. --NYKevin 17:35, 8 July 2013 (UTC)
Agree - I'd love to see this, especially for reviewing recent traffic to a very busy page. Andrew Gray (talk) 23:32, 8 July 2013 (UTC)

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

google-src-text notranslate

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

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

Tech news: 2013-28

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

Recent software changes (Not all changes will affect you.)

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

Future software changes

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

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

18:33, 8 July 2013 (UTC)

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

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

This is a local change in the English Wikipedia, that is not yet compatible with the Visual Editor feature. Since it is a volunteer developed change, some patience might be required. —TheDJ (talk • contribs) 17:13, 3 July 2013 (UTC)
Thank you.Naraht (talk) 17:15, 3 July 2013 (UTC)
I guess it would be impractical or impossible to change this in the VisualEditor code so it should be handled by the English Wikipedia in MediaWiki:Gadget-edittop.js. There is already a suggestion at MediaWiki talk:Gadget-edittop.js#VisualEditor? PrimeHunter (talk) 19:54, 3 July 2013 (UTC)
edittop is broken. It now goes to VE and unlike other section edit links, there is no option to use the proper editor. More at WP:VE/F#Cannot edit section 0 --Redrose64 (talk) 19:21, 6 July 2013 (UTC)
It is intermittent. Half the time, it does still work and gives a proper plain edit link. Other times, it behaves like a VE edit link. Seems to depend on load order of the VE and the edit-top gadget, which can vary. — Edokter (talk) — 19:33, 6 July 2013 (UTC)
I believe that I have fixed it, see here. It's kinda kludgy: I left the existing .replace() method alone, and put another as a new line above it. I expect that a Javascript expert could probably do the same two actions as a single .replace() method. --Redrose64 (talk) 15:21, 9 July 2013 (UTC)

Visual Editor: Documentation update

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

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

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

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

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

The task is complicated by at least two factors:

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

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

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

This is a very good point...a very good point indeed. Category:Wikipedia_tutorials is a start at least. Theopolisme (talk) 22:40, 5 July 2013 (UTC)
Ugh. Lots of work indeed. Perhaps we can post a heads up to other projects (somehow) to try and be ready for this as well, as we were totally unprepared (I still say WP:IAR but whatever). Jguy TalkDone 03:09, 6 July 2013 (UTC)
The old documentation should not be deleted (or overwritten). More than 90% of edits of articles today are being done using the older (wikitext) edit approach (see section immediately); we need to keep the documentation for that.
I suggest that in many cases parallel pages, with a hatnote, would make the most sense. Thus, Help:Table would remains as is, but a new page, Help:Table (VE), would be added for VE users. At some point, say when a majority of edits are being done using VE, the VE page would become just Help:Table, and the current page would become Help:Table (wikitext).
As for the number of pages that need to be created (where VE editing is totally different from wikitext editing) or modified (where VE editing is only slightly different), there are certainly hundreds, if not thousands. Please take a look at the Editor's Index to Wikipedia. That shows. for example, in the Help pages section, that the following categories are also used for documenting how to do things:
I estimate that the amount of work required to update these (and similar pages not in these categories, nor the tutorials category) is probably in the tens of thousands of hours, since those pages involve more than ten years of cumulative documentation of how the MediaWiki software used to work. -- John Broughton (♫♫) 03:06, 7 July 2013 (UTC)
I wouldn't say that it's an "oversight", because I personally spent some time trying to find people who wanted to work on this. There was no real indication that anybody except me thought that this needed to be done, so I'm glad to hear that I'm not alone.
But this isn't really a technical issue, so perhaps it would make more sense to relocate this conversation to a place like Wikipedia talk:Help Project, Wikipedia talk:New contributors' help page or Wikipedia talk:Editor assistance. As for lists of pages that probably need to be updated, {{tutorials}} lists some more. Whatamidoing (WMF) (talk) 21:47, 8 July 2013 (UTC)
"But this isn't really a technical issue..." It's a deployment task. --RA (✍) 09:41, 9 July 2013 (UTC)

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

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

Even better - the problem now seems intermittent. Purging the page seems to help. VQuakr (talk) 00:44, 8 July 2013 (UTC)
As stated above and at Wikipedia:VisualEditor/Feedback‎, the ability to edit the lead section is a gadget, and the VE development team doesn't support this gadget. GoingBatty (talk) 04:17, 8 July 2013 (UTC)
And I don't support a new gadget not supporting old gadgets. I also do not have VE enabled. When is it going to be fixed? VQuakr (talk) 04:25, 8 July 2013 (UTC)
VisualEditor is being developed by the Wikimedia Foundation, and is not a volunteer-maintained gadget. Per the response I received at Wikipedia:VisualEditor/Feedback/Archive 2013 07#No "edit source" for section 0, "Gadgets are expected to be compatible with MediaWiki rather than the other way around." Looks like a discussion started at MediaWiki_talk:Gadget-edittop.js#VisualEditor? as well. GoingBatty (talk) 04:39, 8 July 2013 (UTC)
  • This is a very annoying bug. I too do not have VisualEditor enabled. A workaround (not that "purging page) is urgently required. --Tito☸Dutta 06:00, 8 July 2013 (UTC)
You can edit source of another section and manually replace the section number at the end of the url with 0. Here is quickly made inelegant code to add an "Edit lead" link to the toolbox: [17]. PrimeHunter (talk) 13:19, 8 July 2013 (UTC)
  • Bad idea. --Tito☸Dutta 16:10, 9 July 2013 (UTC)
This is the same problem that I noted above. --Redrose64 (talk) 17:50, 8 July 2013 (UTC)
  • No update/fix? Is anyone listening here? This needs to fixed soon. I am continuously incorrectly entering to section=1. Tito☸Dutta 16:10, 9 July 2013 (UTC)
  • Stop shouting and be patient. Jeez. GiantSnowman 16:24, 9 July 2013 (UTC)
Please see the last post that I made in #Non-interaction Visual editor and Add an .5Bedit.5D link for the lead section of a page - did my fix not work for you? --Redrose64 (talk) 16:28, 9 July 2013 (UTC)

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

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

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

  • (1) Is it (still) possible, technically, to change "Edit" to read "Edit (VE)", and to change "Edit source" to read "Edit wikitext", or maybe even just "Edit"?
  • (2) Is it possible, technically, to switch the tabs, so that "Edit wikitext" (or perhaps just "Edit") is to the left, and "Edit (VE)" is to the right?

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

(1) Yes, this is possible with admin action alone, (2) Not in any easy way I can see without involving the developers. Dragons flight (talk) 01:55, 8 July 2013 (UTC)
PS. Because of the way the developers use "Edit" to sometimes to mean "source editor" in some namespaces and "visual editor" in other namespaces, a change to the "Edit" label would actually be somewhat complicated too. Far more so than a typical interface change. Dragons flight (talk) 02:02, 8 July 2013 (UTC)
Yes its possible to do both without the developers. Option 2 would require a script but it shouldn't be that hard to craft. There are several of us who could technically do a script like that but it would require an admin to implement and a pretty strong consensus. I would also hold off for a while until they get some of the bugs worked out of the VE program. Right now its too unstable to make a bunch of workarounds IMO. Kumioko (talk) 02:10, 8 July 2013 (UTC)
Thanks; very helpful. What I'm concerned about is the 15 July date for making VE "available" to IP editors; that's when "Edit" appears (for VE) and "Edit wikitext" appears for the older editing interface, for IP editors.
If VE is still problematical by that date - in particular, not being able to see, let alone edit, hidden/invisible text when using VE - then I think it would be desirable to at least nudge IP editors in the direction of continuing to use wikitext editing. I'd prefer, of course, that the availability of VE not be expanded until more problems are fixed (stability, addition of missing features, better UI for features like citations). However, the developers seem to feel strongly that meeting target dates (more or less) has value in and of itself. If they insist on pressing on, we should think about how to mitigate the damage. -- John Broughton (♫♫) 03:23, 8 July 2013 (UTC)
The problem with a button-altering script is that it loads fractionally after everything else, so you'd get the buttons appearing and then switching place (or otherwise jumping around). I think this might get more people annoyed than the alternative! Andrew Gray (talk) 19:05, 8 July 2013 (UTC)

Lua app or edit-filter to spot VisualEditor page glitches

[VE garbled pages are detected by Special:AbuseFilter/550. -Wikid77 04:04, 10 July 2013 (UTC) ]
  • We can write Lua apps which read an article looking for garbled text: It is very scary to imagine allowing 100,000 users per month to edit with a broken VisualEditor which corrupts the text, double-pipes the links, or garbles unmodified image links, but since I first saw Wikipedia, I concluded "Wacko-pedia" with all the peculiar stuff I later came to describe as "wiki-spastick" and quite common, such as parameters coded as dizzy triple-braced "{{{1}}}" rather than simple "#[1]" using the same '#' as a metacharacter in #switch or #ifexpr, as common for 4 decades in computer systems. It was like, hello, didn't anyone learn anything from the horrors in LISP (CAR) and (CDR)? Or "edit-conflict" in a modern(?) computer system designed to support multiple users (imagine going to an automated bank teller and getting "access-conflict" on a bank account with recent debit purchases and told to re-enter the transaction!). However, in the case of predictable bug glitches inserted by VE, we could write some Lua apps which accept a page name and look inside the markup for obvious garbled structures, then list the anomalies, with line numbers, for experienced editors to patch. Otherwise, after all these years of wackofied stuff or peculiar error messages in articles, then most readers would quickly discount any new glitches in pages, as just basically more of the same from the past 12 years. It was just a matter of time before the whole of Wikipedia became wiki-spazzed in every area, but now we know how we are the ones to write debuggers or auto-fixit wizards to circumvent many problems. Decades ago, computer professionals developed "syntax checkers" to help edit markup languages and spot invalid meta-text, and meanwhile WP omitted that step and has gone straight to chalk-board simulation editing, but Lua can be used to create syntax checkers to run after a long edit and remind users to fix glitches in the markup format. -Wikid77 (talk) 17:10, 8 July 2013 (UTC)
This is a 300+ word comment, and I'm sure almost everyone who sees it skims over it regardless of the merits of what you're saying. Could you please try to be more concise in future? Andrew Gray (talk) 19:05, 8 July 2013 (UTC)
  • The 300+ word comment is concise: When considering all the issues covered, in my above comment, then it is very concise. It starts with the concise bolded paragraph header "We can write Lua apps..." and then covers 2 or 3 examples of each issue. Instead, I could have explained, in more detail, how a VisualEditor which corrupts text is typical SOP for WP software, as compared to the design flaw of the triple-tic mark bolding ('''bold''') which could have been coded using the metacharacter '#' as perhaps: #b(bolded), where italic text would be "#i(italicization)" and then both together could have been #ib(italic-bolded) rather than '''''italic-bold''''', and then a literal right parenthesis could be "#)" to show a closing curved bracket inside a bolded or italic string. At any time, a double-hash '##' would show the literal single '#' hashmark. That use of '#b' for bolding would lead to parameter syntax of '#[1]' instead of "{{{1}}}" to access the value of parameter 1. Similarly, I could have explained, in more detail, how most edit-conflicts could be auto-merged, especially in talk-pages where most editing involved adding lines, rather than rewriting of paragraphs. It is truly bizarre how edit-conflicts remain a common part of wiki-editing, when perhaps 95% of them could be auto-merged as multiple insertions stacked, in LIFO (last-in, first-out) order, where a new, erstwhile inserted subsection "==Topic==" would always remain below a 2nd editor's insertion at the same old line number. Those issues are prelude to the unusual fact that a syntax checker would be expected in wiki-editing, such as edit buttons [Show_Preview] [Show_Changes] [Check_Markup], where the Check_Markup option would run a syntax checker to validate use of markup, and then the user is free to ignore warnings or try to adjust the wikitext to avoid syntax warnings. Instead, we get the VisualEditor, long before the button [Check_Markup], and that is truly bizarre in computer systems which use a rigid language structure which has several rules of proper syntax, which could be checked to warn users of potential trouble with the text formatting. Meanwhile, we could write some Lua apps, which accept a page name as input, to run a similar syntax check (on the top-level page), and perhaps even warn that some template names are not valid, or even check the parameters used in major templates which the syntax checker has been directed to proofread for parameter placement. What I hinted at, in the above concise comment, was that we got VisualEditor long before we got the button "[Check_Markup]" but Lua can be used to simulate that capability, and check for typical glitches caused by known bugs in VE, such as links of the form "[[aa|bb|cc]]" as a warning to the editor to check the wikilink format. More later. -Wikid77 (talk) 21:25, 8 July 2013 (UTC)
"Concise" would have been writing: "We could develop a Lua-based tool to check for markup problems caused by known bugs". Rambling on about "wiki-spastick" and ATMs is not, and it's not fair to other users on a busy page to expect them all to take time to read this and try to make sense of it. Andrew Gray (talk) 23:20, 8 July 2013 (UTC)
Wikid, you've talked many many times about creating Lua scripts to check markup. If it's so wonderful, why not mock up a demo rather than posting the same comments over and over. the wub "?!" 08:32, 9 July 2013 (UTC)
I'd be happy to see this too, but a built-in feature to MediaWiki would be preferable. Really, almost any text is "valid" MediaWiki markup, but nobody actually wants to write [[X|Y|Z]] or '''''Foo[[Bar''']]''. See also: bug 21913. πr2 (t • c) 03:26, 10 July 2013 (UTC)
See below, edit-filter 550 working. -Wikid77 04:04, 10 July 2013 (UTC)
Anyway, this is probably a tangential discussion that belongs in its own thread. Regarding the OP's questions, Dragons flight is correct. You could technically switch the tabs using JS or perhaps CSS, but it should probably be done only after a discussion, and in the extension itself (not in Common.js/css) πr2 (t • c) 03:30, 10 July 2013 (UTC)
I have split this portion as subthread "Lua app or edit-filter to spot VisualEditor page glitches". -Wikid77 04:04, 10 July 2013 (UTC)
  • Edit-Filter 550 currently detects pages garbled by VisualEditor: To re-focus on the main concern, of mitigating the damage done by VE, I see now Special:AbuseFilter/550 can detect pages which have bizarre markup garbled when using the VisualEditor, such as unexpected "nowiki" tags or wikilinks with split words. See log entries for filter 550:
http://en.wikipedia.org/w/index.php?title=Special:AbuseLog&wpSearchFilter=550
I guess try to prioritize to fix the most-read articles first, and imagine a world in which the Wikimedia Foundation was the greatest cause of vandalizing pages, and try to enjoy the "cosmic joke" of how some of the worst hack-edits in years are caused by the VisualEditor, rather than by juvenile pranksters! OMG too funny! -Wikid77 04:04, 10 July 2013 (UTC)

detecting visual editor

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

Not exactly at present, but we could add styles to the sitewide CSS pages that would allow content displayed in VE to be different from content displayed to readers or source editors. What did you have in mind? Dragons flight (talk) 21:25, 8 July 2013 (UTC)
It's pretty obvious that WMF is going to continue deploying this thing despite it not being ready. My thought was to be able to add a notice to articles that we know are affected by specific Bugzilla bugs (for example, any template that creates table content displays incorrectly, making VE hard to use on articles that use them) that informs the editor that using the Visual Editor on that particular article is likely to lead to corruption. It would be easy to create a sitewide notice that using VE is likely to lead to article corruption, but I suspect that creating one would be considered a WP:DICK violation. Putting a notice on articles that we actually know are incompatible with VE seems like a reasonable compromise.—Kww(talk) 21:47, 8 July 2013 (UTC)

If the following were added to Mediawiki:Common.css 

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

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

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

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

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

That could even be added to a problematic template itself, couldn't it, rather than in every article that included it?—Kww(talk) 00:07, 9 July 2013 (UTC)
Yes, if you are creating a new template to hold such a warning. Dragons flight (talk) 00:15, 9 July 2013 (UTC)
I was thinking more along the line of being able to add something to {{singlechart}} or {{nom}} that could display a warning on the articles that use them.—Kww(talk) 00:24, 9 July 2013 (UTC)
Sure, if you want. Dragons flight (talk) 00:25, 9 July 2013 (UTC)

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

PS. You need to change the span to a div if you are including table and templates, etc. Also this protection apparently doesn't work on floated elements. Dragons flight (talk) 14:50, 9 July 2013 (UTC)
Can people keep a list or something of when they do this ? Because that's gonna be a lot of cleanup in the long run. —TheDJ (talk • contribs) 21:30, 9 July 2013 (UTC)
Excellent! Let's just do that to every article... ; ) postdlf (talk) 03:39, 9 July 2013 (UTC)
I've already considered making an "article" template that takes the wikitext for an article as its sole input parameter and outputs it. That way you can edit the whole thing as wikitext inside Visual Editor.—Kww(talk) 06:41, 9 July 2013 (UTC)
Maybe a brave soul should create an RfC for enabling the Remove VisualEditor gadget by default. PrimeHunter (talk) 11:08, 9 July 2013 (UTC)
Would be a waste of time. Even if there were a local consensus for that (and I'm not entirely sure there would be), the WMF would just override it. Dragons flight (talk) 14:52, 9 July 2013 (UTC)
They are not even accepting that there is need for a possibility to correctly disable VE (and there clearly is consent on that) instead of only hackily hiding it with a gadget that is prone to break often with a name that could be considered misleading. They will surely not disable anything by default. --Patrick87 (talk) 15:29, 9 July 2013 (UTC)

Notification Bug

Tracked in Phabricator
Task T50568

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

Can't replicate on my end...did you try it with another account? Also, do you get a "clear notifications" link at Special:Notifications? Theopolisme (talk) 00:02, 9 July 2013 (UTC)
(edit conflict) Have you clicked on the "1"? Echo can send notifications other than talk page messages. Other than that, I have no idea, unless the software is simply trying to tell you that "You are #1".  :-) Dragons flight (talk) 00:03, 9 July 2013 (UTC)
I would hope not. That would mean that it is telling the rest of us that we are zeroes.—Kww(talk) 00:09, 9 July 2013 (UTC)
@C678: There was a similar bug reported a few days ago. I've unarchived that thread, and left a mention of this one, at Wikipedia talk:Notifications#Exasperated. If you could give some additional details, such as browser/OS and how long you've had this problem, and what the most-recent notification-type is, that might help. Thanks. –Quiddity (talk) 00:39, 9 July 2013 (UTC)
I just noticed the convenient little link that lets me mark all as viewed. There wasn't a new notification though. It just kept saying 1, with no new notifications. It also said viewing 0 of 1 unviewed notifications at the top. I've had this problem since this morning.—cyberpower ChatLimited Access 00:59, 9 July 2013 (UTC)
Sounds like bugzilla:48568 --AKlapper (WMF) (talk) 08:23, 9 July 2013 (UTC)

Deleted contribs

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

The bot that updates that is now running on Tool Labs rather than the Toolserver. At this time, information about deleted revisions is not available in Tool Labs, although it's on the list of things to somehow be made available at least by special request. Anomie⚔ 11:44, 9 July 2013 (UTC)
So they won't be showing here either then? Currently too slow to load for my crappy PC. GiantSnowman 13:41, 9 July 2013 (UTC)
More regarding adminstats at User talk:Cyberpower678/Archive 12#Admin stats - no deleted edits. If you use X!'s Edit Counter through the old http://toolserver.org/~tparis/pcount/index.php link it will continue to show deleted edits (at least, until Toolserver finally gets pulled), but if you use the new link http://tools.wmflabs.org/xtools/pcount/index.php it won't show deleted edits (at least, for now). --Redrose64 (talk) 14:32, 9 July 2013 (UTC)

Why does the named ref toolbar work intermittently?

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

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

JavaScript changing font family?

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

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

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

Background

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

Goal

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

Method

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

Implementation

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

Progress so far
  1. This was inspired by the Teahouse help community, which uses a similar automatic edit button for their ‘ask a question’ form. That form passes typed user input through the API and posts it at the top of the questions page. MediaWiki:Gadget-teahouse/content.js
  2. Writ Keeper coded a base for the TWA edit button. Right now, it triggers a message whenever an editor is in the Wikipedia:TWA/ namespace. It works, but it needs to be triggered by a user clicking a button or a link, not just whenever the user navigates to a new page. User:Ocaasi/TWAcontents.js
Still to-do (help needed!)
  1. Update Writkeeper’s code so that it is triggered by a user clicking a button or a link.
  2. Allow for customization, so that we can send different messages at different points in the game to different target pages.
Useful Pages

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

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

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

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

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

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

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

== References ==

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

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

As noted on the help page, this can occur whether the undefined reference is invoked in the content or in the reflist. You can update your CSS per H:SHOWCITEERROR and test this on a user subpage. --  Gadget850 talk 00:49, 11 July 2013 (UTC)
But in this case, there is no undefined reference. In a sense, you could say there is a "doubly defined" reference, but the second "definition" isn't a definition at all, just an ineffective attempt to invoke the reference. And that ineffective attempt kills the original definition of the reference. NameIsRon (talk) 00:56, 11 July 2013 (UTC)
You are correct. But only <ref>...</ref> is allowed in the LDR. It appears that Cite gets confused when the singular tag is used in the reflist. This would not be the first spurious error. Need to update the help page. --  Gadget850 talk 02:33, 11 July 2013 (UTC)
This was posted elsewhere— I replied and updated the help page. --  Gadget850 talk 12:25, 16 July 2013 (UTC)
The elsewhere in question was this discussion. A problem with archiving meant only the latter half of this discussion (with Gadget850's original responses) was archived, leaving the original problem report un-archived. Gadget850 subsequently left the above reply on the non-archived part of the discussion. I've merged the two parts together, so this archived discussion is now complete. – PartTimeGnome (talk | contribs) 23:28, 21 July 2013 (UTC)

Amended VisualEditor deployment schedule

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

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

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

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

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

Waist deep in the Big Muddy . . . . Hullaballoo Wolfowitz (talk) 13:24, 6 July 2013 (UTC)
I would rather not be testing this unfinished software. I did not receive a request asking me if I wanted to be a tester. Can't you find a group of users who are willing to be testers, rather than inflicting it on those of us who would rather wait until it is finished? Right now I just want to edit, not test software. Thanks. Nurg (talk) 23:27, 6 July 2013 (UTC)
How do I volunteer to test? I'm a professional software tester. I think that if I had conducted a Test Readiness Review (TRR), the conclusion would have been that the software was not even ready for test. I'm ready to test. Are the developers ready for real testers, who may be former developers? Are they willing to deal with real testers? Robert McClenon (talk) 23:58, 6 July 2013 (UTC)
For the most part there is no need to volunteer, just do it. Use the VisualEditor, stress it, break it, and report your observations. Wikipedia:VisualEditor/Feedback may work well for general feedback. For more specific or technical feedback, Wikimedia relies on Bugzilla (http://bugzilla.wikimedia.org/) where you can file bug reports associated with the "VisualEditor" "product". As to whether anyone is listening, that sometimes can be a bit hard to tell, though developers certainly do look at bug reports. Dragons flight (talk) 01:22, 7 July 2013 (UTC)
James, I don't know what your scheduling constraints may be, but in a perfect world, one shouldn't really worry about when it will be deployed so much as what will be deployed. Specifically, it would make more sense to have a road map of development milestones, and each week your team considers whether or not to deploy in the near future based on whether the associated milestones have been met. For example, a checklist for the wide deployment to logged-in users might have included:
  • Provides functionality for most or all features needed to edit text, links, tables, images, templates, and reference / citations
  • All wiki elements that aren't managable by VE and associated functionality is disabled by default
  • No known bugs that produce corrupted output
  • No known bugs affecting the process of opening / saving / abandoning edits
  • UI is functional and legible across full range of supported browsers
  • Load, edit, and save processes execute in a reasonable run time
  • Visual editor must be easily disabled by users who chose not to use it
Obviously such a list could be elaborated in considerably greater detail (e.g. for example listing which features of template editing are required), but the point is to set specific development goals and identify blockers (personally I'd regard anything that spits out bad wikicode as a blocker when considering future deployments). It is usually okay if the software is not functionally complete, but broadly speaking the features that are provided should be functional. In other words while the list of missing features might be large, the list of known bugs ought to be very short at each phase of deployment. In addition, at each phase of deployment adequate time ought to be given for testing and feedback regarding major changes added since the previous major deployment.
I fully recognize that tons and tons of work must have been undertaken just to get here, where conversations about deployment make sense, and you all should be applauded for that. However, I don't think it is good to rush the final steps. A lot of skilled effort can be undermined by community perceptions that a new product is awkward or buggy. One shouldn't worry too much about when things get deployed as compared to making sure that the set of features that are deployed work well and provide a good experience. Dragons flight (talk) 01:11, 7 July 2013 (UTC)
Apparently they have a schedule, and while they can justify some schedule slippage, it's still the schedule that drives things (apparently). So although expanding the default VE setting to all IP editors has absolutely no value in identifying bugs, it's on the schedule, and (to repeat myself) schedule slippage can only (apparently) be justified to a limited extent. Otherwise, why would a Beta version (which states "it may not let you edit everything yet") be about to be rolled out out to everyone, including (IP) editors who can't turn it off? — Preceding unsigned comment added by John Broughton (talk • contribs) 02:43, 7 July 2013 (UTC)
  • Users are resilient but fatal edit-conflicts in VisualEditor are cruel: For the past 2-3 years, the editor-activity levels have been relatively stable (except for the 30% jump in March 2013 to force Wikidata interwiki links), and editors have survived whatever hardships have been imposed on them. My main concern, predicted months ago, is the demoralizing effect of edit-conflicts on the tedious, keystroke-laden WYSIWYG editing. So, it is important for users to know, based on recent edit-conflict tests, how any interim, erstwhile edit of the same page will completely trash a VisualEditor session. I urge users to please not hit the keyboard, in boundless anger, when the VisualEditor reports an edit-conflict which cannot be fixed; instead, try the browser-back button to return to the VisualEditor and try to copy/paste text into another window, for when the VisualEditor dies, unable to merge even a one-word prior change of the page with the current keystroke updates. Psychologically, one of the fastest ways to get new users to quit Wikipedia is to have the VisualEditor crater on a long edit to a page, and lose all changes, while pretending an edit-conflict preview could salvage the page, but in reality, all keystrokes would be lost. -Wikid77 (talk) 06:20, 7 July 2013 (UTC)
  • When I was pondering whether to turn of VE, I hadn't thought about edit conficts. I routinely copy to the clipboard any long text I write since the conflict resolution process with the old editor is such a pain that it's easier to start over. Since that wouldn't work with VE, I hereby condemn Visual Editor to death. Jc3s5h (talk) 13:48, 7 July 2013 (UTC)

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

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

VE "save" vs "finish edit" button

Tracked in Phabricator
Task T44138

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

Note that the MediaWiki page changed the wording of the first green button one uses to reach the edit summary dialog, not the actual button you click to save the page. Killiondude (talk) 23:11, 9 July 2013 (UTC)
  • I don't have a very strong opinion about the new copy itself, except to note that while the new version was more accurate, I think it should probably be discussed before we change it for everyone. Ideally, it should be changed in VisualEditor proper, not just locally here on English Wikipedia. For new people especially, "Finish editing" is likely to make more sense, but on the other hand it was extremely jarring to see it change, and I'm sure I'm not the only who was wondering why/when it was done. If we do change it, there is a ton of help documentation, extensions, and other things that tell editors to finish by clicking "save page", so there will be lots of updates to take care of beyond just the MediaWiki namespace change. Steven Walling • talk 23:15, 9 July 2013 (UTC)
(edit conflict) The most recent related discussion is here, one of several threads that have complained that the label "Save page" is confusing on a button that doesn't actually save the page. The change was also reported to bugzilla (bugzilla:42138). Oh, and you might be interested that Eloquence (talk · contribs) thanked me for the edit. Not every interface edit needs to be pre-approved by the WMF. That said, if you have a better idea for what the button should say then I'm happy to discuss it. Dragons flight (talk) 23:26, 9 July 2013 (UTC)
I'm confused. You say it is "more accurate" but you still reverted because "it should... be discussed before we change it". This is the essence of bureaucracy.
I agree that it should be changed in VisualEditor proper, but why leave it less accurate in the meantime? How is something that's more accurate "jarring"? I'm perplexed all the way around, Steven. Killiondude (talk) 23:22, 9 July 2013 (UTC)
Accuracy != usability. I could change the login button to "Send account credentials you have entered to the server for verification against the credentials stored in the user table" and that would be more accurate but far less usable. Just as important: most people are used to looking for 'Save page', and it's kind of a big deal to change it, in my opinion. If we're going to make a local decision to change it rather than ask the VisualEditor team to change it, then I think there should be a consensus, even a modicum of one. More practically: I think "Finish editing" is more natural than "Finish edit", which sounds somewhat robotic. Steven Walling • talk 23:32, 9 July 2013 (UTC)
Thank you for your reply. That makes a bit more sense. (Also, James' reply below also gives some perspective). I don't mind "Finish editing" but I don't really see a difference between that and "Finish edit". My goal is to get it to say (nearly) anything other than "Save" since that is not what it does. That having been said, I think the use of the word "jarring" in this thread is a bit hyperbolic. Killiondude (talk) 23:38, 9 July 2013 (UTC)
  • The proposal being discussed was changing it from "Save edit" to "Save edit…" (the ellipsis being commonly used in desktop software to imply that there are steps to come before saving occurs). However, this isn't used normally on the Web; it feels a bit jarring online, even in application-like Web interfaces like VisualEditor's, so might feel a bit incoherent and strange. "Finish edit" feels very wrong to me (pressing the button doesn't "finish" your edit; it's a reversible step, which "finish" implies otherwise). "Continue" is obvious once you know what it's trying to get to, but I don't think it's remotely discoverable. We could revert to "Review and Save", though we switched away from that language once we removed the requirement for every user to view the wikitext diff before saving. It would be nice to actually discuss wording rather than just edit-war on wiki. :-) What are people's thoughts? Jdforrester (WMF) (talk) 23:25, 9 July 2013 (UTC)
    I like "Save edit...". I agree it's not common on the web, but it certainly is in desktop environments. If there is an alternative pattern that's common on the web for this, I would probably support that. Superm401 - Talk 00:18, 10 July 2013 (UTC)
  • I don't think "Finish edit" was a good choice. "Save page" is what one wants to do and "Save page" is what the button was always called in the WikiEditor. If you want to change it all "Save edit" might be an appropriate choice.
Any way I strongly recommend not to remove the word "Save" from the label. "Saving" is a fundamental thing almost every software on every OS supports. "Finishing" is totally unknown and not intuitive.
On side note: I'd rather vote for changing the "Cancel" button to "Discard changes". --Patrick87 (talk) 23:34, 9 July 2013 (UTC)
The button we are talking about doesn't actually save anything. It opens a dialogue that allows people to write an edit summary, generate a diff of their changes, or ultimately push another button to save the page. Multiple people have complained that labeling a button as "save page" is confusing when it doesn't actually save anything. Doubly so for people who are trying to figure out where to add an edit summary. As others have said, just about anything other than "save" would be better. Dragons flight (talk) 23:52, 9 July 2013 (UTC)
Doesn't sound like contradiction to me. If I choose "save" in any desktop application most of the time a window pops up where I have to choose the file the content should be saved to. Still the button is titled "Save" or "Save as", not "Finish Document" or "Choose file" or anything similar confusing. It is called "save", since that's what I want to do and whats commonly recognized.
If your point is that one has to click "save page" two times currently (once to bring up the edit summary dialog and a second time to really save the changes) then just rename the second button to "Submit changes", "Confirm" or just "OK". But I'm sure especially newbies (and those are the users VE is made for after all) will not undersatand a button labeled "Finish". It's just uncommon and unintuitive. --Patrick87 (talk) 00:29, 10 July 2013 (UTC)
  • To add some additional perspective, at least a couple people have complained on VEF that having the same "Save page" label in VE as in the classic editor is jarring for experienced editors. People have had it drummed into their heads for years to make sure you've double-checked everything, entered an edit summary, etc. before clicking "Save page" in the classic editor, as clicking that finishes the edit session and sends everything off to the servers. But in VE it's impossible to enter an edit summary until you click the "Save page" button. --108.38.191.162 (talk) 00:08, 10 July 2013 (UTC)
  • The change was made, it met with several comments of approval and none of disapproval - a pro forma reversion like this doesn't appear to actually achieve anything that anyone at all actually wants. Steven, please reverse yourself - David Gerard (talk) 00:21, 10 July 2013 (UTC)
    • Read my replies to Killion. It's not just for the sake of formality. Steven Walling • talk 00:32, 10 July 2013 (UTC)
  • Killiondude for steward! --MZMcBride (talk) 00:23, 10 July 2013 (UTC)
  • Huh - don't really see that the revert was necessary; we can iterate a bit on these things. But agree that we'll want to solve this in the software itself rather than by means of a local override. Like I said when Dragons flight made the edit and as another couple of users have pointed out, "Finish edit" feels a bit unnatural, but still an improvement over the straightforward "Save" which is a bit confusing since an additional step is required to actually complete the edit. "Review and save" would work for me as well, even if the review step is no longer mandatory.--Eloquence* 00:33, 10 July 2013 (UTC)
  • I urge you all to read John Broughton's comment at WP:VisualEditor/Feedback#edit summary. John is an experienced documentation writer so his perspective carries a lot of weight (for me at least). — This, that and the other (talk) 01:07, 10 July 2013 (UTC)
Since this seems the best place to consolidate the discussion, I'll repeat what I said elsewhere (with a copyedit):
The button labeled "Save page" has the same label as the button, in the old editing interface, that completed the edit session. Lots of effort has been made, over the years, to encourage editors to write an edit summary (and do a preview) before they click "Save page", and now VE has a button with the same label where it's not possible to do a preview or write the edit summary until after clicking the button. The button ought to be labeled "Finish edit" or "Continue" or "Final steps" or just about anything other than "Save page".
The current problem is even worse than just one poorly-labeled button. In VE, after clicking "Save page", a dialog box appears that also has a "Save page" button. So now an editor has to understand that the two "Save page" buttons do not do the same thing. And documentation (when it's written) is going to have to clarify which "Save page" button is being referred to - unless the label on the first occurrence of "Save page" is changed, as it should be.
I don't have any particular attachment to "Finish edit" (in fact, I think "Finish editing" is superior). What I hope everyone can agree is that from a user experience viewpoint, having a new button with the same name but different behavior than an old button is problematical; having two new buttons with the same name that do two different things is simply wrong.
So, where do we go from here? VE is in beta; that means things are going to change. And if only (or mostly) new editors are going to use VE (something I very much hope is wrong, eventually), then there is very little learning to be unlearned. In short, I think we should improve the user interface, by changing the label on the button, and I don't think we should concern ourselves with what WMF thinks, since other language Wikipedias are not going to use the English label anyway. I also note that VE is not being used for anything but articlespace and userspace pages, so that even editors committed to VE are seeing "Save page" in the older wikitext interface when editing other pages - so it would be really good if it did the same thing in both interfaces.
It seems to me that greatest consensus here is that "Save page ... " is better than "Save page", albeit not perfect. I suggest that we go with that, for the moment, and that we then either (a) continue the conversation here to see if we can get consensus on something even better, or (b) someone starts an RfC on the issue. What I would hate to see is the classic "The perfect is the enemy of the good", where we discuss ad infinitum all the permutations of possible labels, while in the meantime something that is clearly wrong (a "Save page" button that does not save the page) remains to confuse editors trying out VE. -- John Broughton (♫♫) 03:10, 10 July 2013 (UTC)
I'm behind you 100%. Something needs to be done now. Chris the speller yack 04:26, 10 July 2013 (UTC)
Something does not need to be "now". This is the interface thousands of people are and will use for a long time. Taking time to deliberate and choose the best option is important. @John Broughton: regarding "I don't think we should concern ourselves with what WMF thinks, since other language Wikipedias are not going to use the English label anyway" -- you couldn't be more wrong. First off, doing something only locally here means that all English wikis will have a save button inconsistent with English Wikipedia. Every day, many new editors try out Commons and other projects, after editing here. Do we want to confuse them with inconsistent interface copy for the same editor? Also, the English text is what is used as the basis for translation for all other languages (they don't make up a version from scratch unless they too override it locally). If we really think that two 'save page' options is bad, the right thing to do is to change it properly in VE, especially before it goes out live as the default to other languages. If the change is needed here, it's certainly needed elsewhere too. Steven Walling • talk 04:51, 10 July 2013 (UTC)
This reminds me of what Ross Perot (not my hero, but he has something here) used to say, that when you see a rattlesnake, you kill it; don't appoint a committee on rattlesnakes to study the problem. Chris the speller yack 15:01, 11 July 2013 (UTC)
@Steven Walling: When you say "change it properly in VE", what exactly do you mean? There is no process, other than through a bug report, already done, to change something in VE. Or to provide feedback to the VE team, already done. Obviously, given the hundreds of more serious bugs, the VE team isn't going to get to this issue for weeks, or probably months. And they haven't responded to the feedback (other than to agree that "Save page" isn't the right label). I'm happy to participate in a process that will result, in a relatively short time, in something positive happening here, but I'm not seeing anything you said as leading to that. Are you suggesting that we just wait, and wait, and wait, for something good to happen? -- John Broughton (♫♫) 16:31, 10 July 2013 (UTC)
I mean changing it in the code. This is just a copy change -- it doesn't involve more than 15 minutes work after we make a decision. It's not going to take VE team weeks to fix it. Steven Walling • talk 17:21, 10 July 2013 (UTC)
Even if implementation is fast, it will presumably take more than 15 minutes to make a decision. After all this issue was flagged in bugzilla for months without any decision being reached. Given the number of outstanding bugs and missing features, I wouldn't necessarily want the VE team to be spending even 15 minutes worrying about what to call the buttons right now. I would suggest that the volunteer community can help by thinking through many of these issues, forming consensus, and implementing changes. The VE team is then free to review our discussions and copy them if they agree with our logic. I agree that having changes implemented within VE itself is ideal, but taking up developer time to think through these issues isn't necessarily the best use of their time. Dragons flight (talk) 17:43, 10 July 2013 (UTC)
  • Relabel 1st "Save page" button as "Submit/Review": The button label should try to summarize its function, so I recommend re-labelling the 1st Save button as "Submit/Review" where the slash punctuation is commonly interpreted as meaning "either/or" unless there are cultural problems with the meaning of the slash. Overall, I definitely object to leaving both buttons as "Save page" (as too confusing with identical labels while different functions), and I already think that, for template-editing, the preview of another page should have button "Run preview" rather than both buttons in the wikitext editor labelled as "Show preview". So, for people who think we are nitpicking just the VisualEditor buttons, remind them to consider button label "Run preview" in the wikitext editor for templates. -Wikid77 (talk) 04:54, 10 July 2013 (UTC)
  • "Save page" is a bad label for the button. It says nothing about 2 next steps coming - the crucial edit summary and then the actual "save." The button should make it clear that there is a next step. The button should say "Write edit summary", or better, just "Next" as almost every webpage in an online multistep process, communicates to users. VE needs to lead users through the process. Jytdog (talk) 12:22, 10 July 2013 (UTC)
  • So, to recap proposed options at this stage, with my totally-POV thoughts on each one:
    Save page
    (Current text) A little confusing to have the same label twice (though they're in different contexts), but very clear as to purpose; doesn't set the user up to expect another step enough.
    Save page…
    Still clear, though I'm not sure that the ellipsis will make obvious to users that there's a next step.
    Save edit
    Perhaps a little clearer than "page" (?), but still the issue with not being clear about there being a next step.
    Save edit…
    As with "Save page…".
    Finish edit
    Pressing the button doesn't "finish" your edit; it's a reversible step, which "finish" implies otherwise.
    Finish editing
    Same problem as "Finish edit", but add the active present tense to the interface for the first time, confusingly.
    Final steps
    Umm. Are they? Worse than "Finish edit", because they're still not irreversible, and "steps" is confusing and unused elsewhere.
    Continue
    Continue what? Browsing? Editing? Changing? I don't think this gives context or sets expectations. Also fails entirely to tell people there's another step.
    Next
    Same problem as "Continue", though slightly better at suggesting there's another step or more to go.
    Review and Save
    You no longer have to review before you save, so this is an optional step, but I think it's a good option.
    Review and Publish
    Underline for users that when they press the next button, it's public for everyone forever; slight preference for this option over Review and Save.
    Submit/Review
    You're not actually submitting, you're publishing straight away (except if Flagged Revisions is switched on… let's not open that can of worms). Feels confusing, especially with the slash - which one is it?
    Review and Submit
    Same issue with "submitting" language in the above, but less confusing (though no less wrong).
  • What do we think? Which one do we like most (or, perhaps, dislike least)? Jdforrester (WMF) (talk) 03:37, 11 July 2013 (UTC)
The current text is actually "Save page" not "Save edit". Dragons flight (talk) 03:48, 11 July 2013 (UTC)
Argh, yes, sorry; updated. Jdforrester (WMF) (talk) 03:56, 11 July 2013 (UTC)
My opinion is summarized below:
Save page - This button doesn't save. It is confusing for people trained to look for editor summaries / diffs before saving, and it also makes documentation hard because two different buttons in the same UI would have the same label. Altogether I consider this the worst option.
Save page... - Adding an ellipsis does not redeem a bad label.
Save edit, Save edit... - Only slightly better than "Save page", still not worth considering in my opinion.
Finish editing - Personally, I like this. For me, "finish editing" actually suggests something like "now, perform the final steps" and is considerably less final and more reversible than "save page". However, it seems that not everyone reads it the same way (I wonder if this is a regional English difference?). I think "Finish editing" is better than "Finish edit".
Final steps - Much better than "Save page" but somewhat worse than "Finish editing".
Continue, Next - I think these are lacking because there is no sense what you are "continuing" towards (the next page?). Though, I would still would prefer them over "Save page".
Review and Save - This may be the best option. It does convey that there is more to do while also being almost done. I might actually prefer Review and Finish, as reserving "Save" only for the button that actually saves seems desirable.
Review and Publish - This is not bad, but given the existence of Flagged Revs (where not all saves are immediately pushed to the public), it is probably not the best language for a Mediawiki-wide default. "Save" or "Finish" seems better than "Publish".
Review and Submit, Submit / Review - Again, not bad, but I consider the previous options to be better. "Submit" tends to suggest a more private submission than is typical of wiki behavior. If we wanted to use a shortening symbol, replacing "and" with "&" would seem a more natural simplification than using "/".
Dragons flight (talk) 04:34, 11 July 2013 (UTC)
I like Finish editing the best out of all of these. Alternatively, someone proposed Next... above and I like that idea. Killiondude (talk) 06:17, 11 July 2013 (UTC)
I think "finish editing" makes sense. It's clear, plain language. I can also confirm this with a quick set of usability tests, if we want. Steven Walling • talk 20:32, 11 July 2013 (UTC)
Although it might be the preferred label of some of you: Don't use anything with "finish" in it. One does not know what to expect. I never read "finish" in any software and it is for a reason. Maybe also from the perspective of someone whose native language is not English: "finish" is hard to understand and not easily recognized as something one would know from other places.
I still prefer keeping the first button "Save page" or something similar. "Saving" is something that every user knows from essentially every software and one doesn't await it to directly submit the information to the server. In this case just change the label of the second button to e.g. submit and the ambiguity would be resolved. The whole thing is perferctly reasonable applying common sense: I want to save my edit (therefore clicking "save"), I then review my changes and enter an edit summary, then I "submit" my information to the server.
Note what I wrote above: The user wants to save the edit (that's the basic workflow), therefore he's searching a button labeled "save". The user isn't searching for a button that allows him to enter an edit summary because he knows, that's the step before actually saving. Buttons should be labeled according to the users workflow and should express what he want's to do. Buttons don't have to exactly say what they are doing.
Therefore let me propose a maybe "dumb" idea: What if we simply rename the button to "OK"! A big red green button labeled "OK" probably can't cause any confusion, especially since we have "Cancel" (which we could color red to perfectly contrast those two) directly next to it. Look at it:
CancelOK Discard ChangesSave Changes
I think this would be perfectly clear to everybody – without the fear of any ambiguities! --Patrick87 (talk) 08:47, 11 July 2013 (UTC)
Patrick's earlier comment about "Discard changes" made me think that "Save changes..." would probably make sense to most people Whatamidoing (WMF) (talk) 22:02, 11 July 2013 (UTC)
Yes, I would like that one, too. It's much better than "finish edit". It would also contrast nicely to "Discard Changes" (see buttons above). --Patrick87 (talk) 22:21, 11 July 2013 (UTC)

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

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

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

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

You can use the adjacent sibling selector, something like .mw-editsection-link-primary + .mw-editsection-bracket, .mw-editsection-divider + .mw-editsection-bracket, to target just the (weirdly multiple) interior brackets. Anomie⚔ 22:46, 10 July 2013 (UTC)
For the records, the related bug report for this request is bugzilla:50540. --AKlapper (WMF) (talk) 10:37, 11 July 2013 (UTC)
I've tried the CSS which is nice but it seems to mess up for section 0. Just to the right of the title I'm getting edit |edit source the first link takes me to source editing of section 0, the second links is to source editing of section 1!--Salix (talk): 12:50, 11 July 2013 (UTC)
Please paste both links, in full, to this section so that I can see what you're being given. --Redrose64 (talk) 12:57, 11 July 2013 (UTC)
First is http://en.wikipedia.org/wiki/Japan%E2%80%93South_Korea_relations?action=edit&section=0 second is http://en.wikipedia.org/w/index.php?title=Japan%E2%80%93South_Korea_relations&action=edit&section=1 .--Salix (talk): 13:45, 11 July 2013 (UTC)
Hmmm, the first one appears to be http://en.wikipedia.org/wiki/Japan%E2%80%93South_Korea_relations?veaction=edit&vesection=1 after processing by MediaWiki:Gadget-edittop.js; the second (which has a different position for the query ? besides a different section number) seems not to have been processed by edittop. At Preferences → Gadgets, what are your settings for:
  • Remove VisualEditor from the user interface
  • Add an [edit] link for the lead section of a page
  • Move section [edit] links to the right side of the screen
I have seen something like this before; yesterday I was getting two edit links for the lead section of Leg before wicket, which was TFA at the time (unfortunately I didn't note them), but today, I have only one - the one processed by edittop; and I also have only one at Japan–South Korea relations (the same one). --Redrose64 (talk) 14:11, 11 July 2013 (UTC)
  • Remove VisualEditor from the user interface off
  • Add an [edit] link for the lead section of a page on
  • Move section [edit] links to the right side of the screen off
I first spotted it with right edit on, but switched it off to see if that cured the problem, it didn't.--Salix (talk): 14:21, 11 July 2013 (UTC)
Ah, these are the same settings as mine. At this stage, I don't know where the second link is coming from, so would welcome input from others. --Redrose64 (talk) 14:54, 11 July 2013 (UTC)

Mention "Remove VisualEditor" under Editing preferences

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

And even better conceal what an ugly hack we have to use because WMF devs don't care about community consensus? This should finally be fixed!
Why shall we put further and further effort into a local workaround on English Wikipedia, with the very limited possibilities we have, prone to break because of errors on every update, being only able to patch it only provisional? If the WMF devs finally insert the much requested turn-off switch this problem will be solved quickly and correctly and on all Wikis at once! --Patrick87 (talk) 22:55, 10 July 2013 (UTC)
Changed the label MediaWiki:Prefs-beta —TheDJ (talk • contribs) 08:51, 11 July 2013 (UTC)
Sorry, but to be honest, this is bullshit! Now we already start to rename headings in the preferences dialog to point to user created Gadgets, because we know we need a pref and know where it should be located but don't get it by WMF? How ridiculous is this? --Patrick87 (talk) 09:05, 11 July 2013 (UTC)
This is where we can exercise some immediate control, so it's not like we have many other options. —TheDJ (talk • contribs) 09:24, 11 July 2013 (UTC)
Do you see the importance that lies in you reply? Don't you think we should have some control on WMF at this point? Shouldn't we have the option to inform WMF of the clear community consensus with the result that it is followed?
I don't know if those guys at WMF are drowning in work right now (after having released a beta-stage software at users) or if they are enjoying the nice weather and I hope they are doing this on purpose. Whatever they do, IMHO they are badly failing their job on this issue. I hope they are aware and will provide a fix soon. --Patrick87 (talk) 09:48, 11 July 2013 (UTC)
Personally I don't have much time to enjoy the nice weather (plus today central Europe is likely getting rainy), and I know that the Visual Editor team has even less time to enjoy it currently as they spend quite some time and weekends on improving VisualEditor. For general reference, WP:VE/F is likely the best place to give feedback for the VisualEditor (or to check for existing threads requesting the same feature/bugfix) so the developers will definitely see it. Hope that helps. --AKlapper (WMF) (talk) 10:41, 11 July 2013 (UTC)
I've filed bugzilla:51179 about restoring the user preference to disable VisualEditor. --MZMcBride (talk) 15:36, 11 July 2013 (UTC)

Always-subst templates

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

Stick it in Category:Wikipedia templates to be automatically substituted, and the AnomieBOT will do it for you. -- John of Reading (talk) 10:34, 11 July 2013 (UTC)
Note {{substituted|auto=yes}} on the template's doc page will both add the category and show a message about it for other users. Anomie⚔ 11:30, 11 July 2013 (UTC)

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

Changing / blocking a bit of Javascript

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

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

The only possible answer to the question as stated is "maybe". You might be able to override the module in ResourceLoader, you might be able to extend it if it was written with extensibility in mind, you might be able to just undo or hide whatever it does. Or maybe not; it depends on what it is you want to do. Matma Rex talk 19:34, 11 July 2013 (UTC)
Let's formulate it in "easy" term: Can I disable VE or ULS using JavaScript? Disable, not hide! --Patrick87 (talk) 19:48, 11 July 2013 (UTC)
VE – possibly, there's an implementation suggestion at MediaWiki talk:Gadget-oldeditor.js which apparently none of the local admins here bothered to test and enable if it works. ULS – not really, because it is entirely loaded in the blocking top queue, before the page even starts rendering. Matma Rex talk 20:34, 11 July 2013 (UTC)
I want to try changing one small piece of behavior in VisualEditor. Assuming I can find the exact Javascript function in GIT, and write a new function that could replace it without breaking anything else, is there way to install it in my personal JS that would ensure that my function gets called and not the stock function. Dragons flight (talk) 20:04, 11 July 2013 (UTC)
Most likely yes. VE exports nearly all of itself inside the ve global variable after it is loaded (user clicks "Edit"); you can access the running VE instance (ve.instances[0]) and its various classes (ve.ce, ve.dm etc.). Modifying those things is not really supported, but should work. A documented and supported API for gadget writers is planned for sometime after the current issues are solved AFAIK, but you should ask James about this. Matma Rex talk 20:38, 11 July 2013 (UTC)
Looks like the off switch is coming. Its a setting in CommonSettings.php so its a local issue.T52929--Salix (talk): 22:09, 11 July 2013 (UTC)

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

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

code gives type of flag
{{flag|Belgium|state}}  Belgium official state flag
{{flag|Niger}}  Niger official state flag used as a default in Wikipedia
{{flag|Belgium}}  Belgium civil flag used as a default in Wikipedia
{{flag|Niger/sandbox}}  Niger/sandbox civil flag (my proposal)

I guess my sandbox version looks better. What do you think?
Maiō T. (talk) 21:12, 11 July 2013 (UTC)

  • Update page "Flag of Niger" with sourced civil flag: It will be easier to back a technical flag size if the flag article documents the size ratio as a common usage. Currently, the page is too nebulous and needs sources to pinpoint a ratio. Perhaps that is why the official ratio (rather than a civil-ensign ratio) is used in the icon. -Wikid77 (talk) 21:30, 11 July 2013 (UTC)

Unresponsive script

Tracked in Phabricator
Task T35018
Tracked in Phabricator
Task T51935
Tracked in Phabricator
Task T53070

I've been getting this message frequently today:

A script on this page may be busy, or it may have stopped responding. You can stop the script now, or you can continue to see if the script will complete.
Script: http://bits.wikimedia.org/en.wikipedia.org/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki%2CSpinner%7Cjquery.triggerQueueCallback%2CloadingSpinner%2CmwEmbedUtil%7Cmw.MwEmbedSupport&only=scripts&skin=monobook&version=20130620T163512Z:106

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

Do you get it while you're editing? After you save? When you're just reading articles? Can you give instructions to reproduce the error, or does it just happen occasionally (at seemingly random times)? πr2 (t • c) 22:58, 2 July 2013 (UTC)
Just when I'm viewing. It mostly seems to happen on larger pages - it has been happening on Pittsburgh Steelers, Barack Obama and Alec Douglas-Home every time I view those pages. The traditional edit window still opens up fine on those articles, and smaller articles seem to be loading normally. It also happens every time I load Special:RecentChanges (which is very irritating, as that's something I use frequently) and sporadically on some project pages, again mostly depending on how large they are. WP:ANI seems to load fine, Wikipedia:VPT and Wikipedia:Articles for deletion/Log/Today seem to load properly about 50% of the time. Today is the first day I've noticed this problem. --Bongwarrior (talk) 23:43, 2 July 2013 (UTC)
That all (happening on non-editable and non-VE-editable pages, happening since today) would indicate that this is an issue with ULS (the cog on language links), not VE. Matma Rex talk 23:47, 2 July 2013 (UTC)
Thanks for the information, that sounds like a pretty good guess. Hopefully there will be some sort of fix. The interface is becoming a bit too bloated for my tastes, and these "features" make editing more of a hassle than it needs to be. --Bongwarrior (talk) 04:39, 3 July 2013 (UTC)
See bugzilla:49935#c5 for the information needed. To what you said above, I suggest to add 1) operating system, 2) recentchanges settings (how many changes are you loading?) and other relevant settings (e.g. if you have gadgets enabled), 3) CPU, total RAM, free RAM, 4) why you've not upgraded Firefox.
Experience shows that there are more chances for your report not to be discarded by devs if you do some JavaScript profiling yourself with firebug and mention the worst offenders, but I don't know easy tutorials for that. Good luck! --Nemo 08:21, 3 July 2013 (UTC)
ping @Bongwarrior:, can you please provide some information as to your browser and browserversion (+OS) —TheDJ (talk • contribs) 17:06, 3 July 2013 (UTC)
The problem seems slightly better today - it's no longer happening on RecentChanges, although it still seems a bit slow to load (and it's still happening on the articles I mentioned). Nemo, the information you requested:
1) Windows Vista SP2
2) The default, 50 changes. Only a few gadgets: popups, reference tooltips, do not show green bullets on watchlist, remove VisualEditor, Yet Another AFC Helper Script, CharInsert, add edit link for lead section, change "new section" tab to "+", display old yellow/green diffs, disable animations, and move section [edit] links to the right side.
3) Intel Celeron 1.60 GHz, 1 GB RAM, 36 MB free RAM
4) If it ain't broke, I don't usually fix it. I have noticed that some of the newer versions of Firefox hog less memory, so I probably will upgrade it at some point. --Bongwarrior (talk) 18:45, 3 July 2013 (UTC)
Bongwarrior, thanks, I've reopened the bug and added your information. --Nemo 07:10, 4 July 2013 (UTC)
I had the same problem and finally managed to fix it using Adblock. I blocked the following 3 items and now it's loading like a charm again:
|http://bits.wikimedia.org/static-1.22wmf8/extensions/UniversalLanguageSelector/*
|http://en.wikipedia.org/w/api.php?action=ulslocalization&language=en
|http://bits.wikimedia.org/en.wikipedia.org/load.php?debug=false&lang=en&modules=ext.centralNotice.bannerController%7Cext.uls.displaysettings*
Of course this just disables the ULS. But if you don't need it, it works. Hopefully this information is useful to you. — Ginsuloft (talk) 13:14, 5 July 2013 (UTC)
Nice, that works perfectly as far as I can tell. Thank you very much. --Bongwarrior (talk) 19:22, 5 July 2013 (UTC)
Oops, I spoke a bit too soon. The pages load nice and fast, but it has the unfortunate side effect of killing or bypassing my monobook.js settings. --Bongwarrior (talk) 19:34, 5 July 2013 (UTC)
I have requested that ULS be disabled. This bug is real, it's reported plenty on wiki, it's time to get it out because it's on every page, it's not like the general user can bypass it like VE. —TheDJ (talk • contribs) 21:14, 9 July 2013 (UTC)

Heavy Javascript load after loading some articles.

Tracked in Phabricator
Task T52836

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

some more pieces of information would be helpful:
  • which articles?
  • which browser (incl. version) do you use?
  • is this behavior consistent and repeatable, or is it intermittent?
  • could you please repeat the same measurements, but add "?debug=true" to the address line? this will help isolate the actual script that causes the issue - without it, the wikipedia script loader (aka "ResourceLoader" or "RL") squashes many scripts together while minifying them, so the information you supplied regarding the actual script that causes the issue is less useful than it would be with "?debug=true".
peace - קיפודנחש (aka kipod) (talk) 14:57, 5 July 2013 (UTC)
Not that guy, but I have the same problem. Which articles? Seems to happen all over Wikipedia at different intensities, but it's the worst at special:recentchanges. Browser=Firefox 12.0, OS=Windows XP SP3. Is this behavior consistent and repeatable, or is it intermittent? Consistent and very annoying. Could you please repeat the same measurements, but add "?debug=true" to the address line? I would if I could. So far I only managed to disable it with AdBlock but as you said it also disables other useful stuff. — Ginsuloft (talk) 15:03, 5 July 2013 (UTC)
Since Firefox 22 you can use "Extras -> Developer tool -> runtime analysis" to exactly measure the time used by each subroutine. For other versions of Firefox there is also Firebug. --Patrick87 (talk) 16:08, 5 July 2013 (UTC)
jQuery.expr.filters.hidden() is the problem, if I did everything correctly. I also found that many articles load fine, it doesn't seem to happen with most short articles, it doesn't happen with Roman Egypt or even some very long pages like List of people of the Three Kingdoms--90.179.235.249 (talk) 16:59, 5 July 2013 (UTC)
For me, the problem seems to be this anonymous function starting at:
curCSS = function( elem, name ) {
var ret, width, minWidth, maxWidth,
computed = window.getComputedStyle( elem, null ),
style = elem.style;
if ( computed ) {
— Ginsuloft (talk) 17:47, 5 July 2013 (UTC)
@Patrick87: I have Firefox 22. Where is this "Extras" to which you refer? --Redrose64 (talk) 18:32, 5 July 2013 (UTC)
@Redrose64: Ah, sorry, I new their messed up new GUI was only producing problems... You have to hit the "Alt" key once (this will bring the classical menu bar up), then it's the second menu from the right. --Patrick87 (talk) 18:37, 5 July 2013 (UTC)
I have had the menu bar switched on for some months (View → Toolbars → Menu bar) ... but the menu bar that I have is File/Edit/View/History/Bookmarks/Tools/Help. I've looked in each one, and there isn't an "Extras". --Redrose64 (talk) 18:43, 5 July 2013 (UTC)
I also don't have an "Extras" menu in Firefox 22, and neither do I have a "Menu bar". View → Toolbars leads to Navigation, Bookmarks, and Add-on. Whatamidoing (WMF) (talk) 19:22, 5 July 2013 (UTC)
Seems I have to apologize again, just pick the "tools" menu (I'm using a German licalized Firefox and since "Extras" is an English word I didn't imagine it could be titled differently in English). However it seems you guys are very bad at searching . --Patrick87 (talk) 19:30, 5 July 2013 (UTC)
I've got Tools → Web developer, but in that submenu, there are 12 items, but no "runtime analysis". Whatamidoing (WMF) (talk) 19:47, 5 July 2013 (UTC)
Try Shift+F5--90.179.235.249 (talk) 19:53, 5 July 2013 (UTC)
Ah, ⇧ Shift+F5 is same as Tools → Web developer → Profiler. --Redrose64 (talk) 19:58, 5 July 2013 (UTC)
Yes exactly this is what I meant. Sorry for the hassle but none of these translations is only close to it's original meaning. --Patrick87 (talk) 20:01, 5 July 2013 (UTC)
i removed the {{tracked}} which pointed to Bugzilla:49935. these are two separate issues: the older bug was about "frozen" browser, that's caused by asinine use of ajax (calling ajax load many times with "async:false"). as a side, one of the developers that responded to the bug demonstrated really bad attitude, criticizing the bug-reporters while behaving as if there is no real problem, instead of making some effort to get to the root of the issue. but as i said, it's not related: this one is about high CPU consumption, and removing the "async:false" which will fix 49935, will do nothing to help here (actually, fixing 49935 will exacerbate this problem). this warrant a separate report. as for the problem itself: as far as i could see, it comes from the new ULS (universal language selector) code. the problem seems to be calling "injectCSS" multiple times (each time with a new style component to load yet-one-more-webfont), instead of collecting all the different CSS pieces this extension wants to ask the browser to load, and loading them all at once. peace -— Preceding unsigned comment added by קיפודנחש (talk • contribs) 20:18, 5 July 2013 (UTC)

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

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

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

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

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

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

Thanks a lot. I've just tried a few different pages, and it seems to be working much, much better. It might be just a tad slower than it was before ULS (or not - that could just be my imagination) but I'm not seeing any freezing or hanging or anything. Muchas gracias. --Bongwarrior (talk) 21:54, 10 July 2013 (UTC)
It's not just your imagination; it is a tiny bit slower. But as I like to say, "Even in Arcadia, there is death." At least pages aren't loading for 4 seconds now, which was absolutely ridiculous. This is to confirm that the patch works. Thank you. Ginsuloft (talk) 14:00, 11 July 2013 (UTC)
Yes, it works much better now.--90.179.235.249 (talk) 14:24, 11 July 2013 (UTC)
just to clarify - it's not "my" patch, and the thanks should go to the developers who solved the problem (specifically, User:Amire80 and the people who code-reviewed his patch, maybe some others, too). peace - קיפודנחש (aka kipod) (talk) 18:03, 11 July 2013 (UTC)
Also to User:Nikerabbit who wrote much of the patch's code and to User:Nemo_bis who tested it before deployment and found an important bug that we resolved.
And thanks also to all the people in this thread that tested and reported things. --Amir E. Aharoni (talk) 13:00, 12 July 2013 (UTC)

Editing protected pages

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

Haha. That's funny. I wonder if that's new or just nobody noticed it before. Is it really that much a problem though? Like do you often copy text from full protected templates to a sandbox to edit it there? Even if not, I suppose it'd be easy to fix by just disabling the toolbar on any page you can't edit. —Soap— 16:57, 12 July 2013 (UTC)

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

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

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

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

  • Various nowiki patterns, some harmless: Numerous editors are afterward using "Edit source" as wikitext editor to remove nowiki-tags. I have noticed the following patterns:
  • all kinds of spurious nowiki-tags, such as someone adds a blank space: <nowiki> here</nowiki>.
  • wikilinks chopped with prefix letters:  "C[[ommandant General]]"
  • wikilink literalized by nowiki-tags: <nowiki>[[Page (person)|Page]]</nowiki>
  • wikilinks with nowiki-tag split as 2 links: "[[Toffee|<nowiki/>]][[toffee]]" to show one link: toffee.
  • wikilinks with no-wiki brackets: "[[Cricket (insect)|[[Cricket<nowiki>]]</nowiki>s]]" to show: [[Cricket (insect)|[[Cricket]]s]]
Those are from live articles, even today (11 July 2013) many bad nowiki tags. -Wikid77 (talk) 20:46, 11 July 2013 (UTC)
  • Support VE edit-warning: Put a system-wide warning how VE edits to wikilinks become garbled. -Wikid77 (talk) 20:46, 11 July 2013 (UTC)
According to Jdforrester, he doesn't see any corruptions at all any more, this is just the fault of the users... So I won't bet on the fix to happen really soon. Yes, why not make Filter 550 blocking to stop the degradation of thousands of articles. --NicoV (Talk on frwiki) 20:50, 11 July 2013 (UTC)
I'd need the make the edit a bit more specific before being comfortable making it actually block, and, on top of that, Visual Editor can't forward the messages from an edit filter block to the user. That's T52472.—Kww(talk) 21:10, 11 July 2013 (UTC)
  • Cannot allow Filter to block entire edits, so just count how many nowiki pages are not fixed yet. Current wikisearch for "nowiki the" reports 2,054 pages contain "nowiki" (beware Norwegian wikipedia is "nowiki"); so this is Thursday, and just count how many more (are not fixed) each day. -Wikid77 (talk) 21:13, 11 July 2013 (UTC)
Edit filter has the ability to warn users about potentially bad edits and require a second push of the save button to confirm that they really want to do that. That seems much more user friendly than blocking the edits. However, I don't think VisualEditor supports that behavior yet. Dragons flight (talk) 21:18, 11 July 2013 (UTC)
Nope. As I posted on one of the many VisualEditor bug report pages, all VisualEditor will do is spit out a cryptic error message. Reaper Eternal (talk) 21:21, 11 July 2013 (UTC)
My experience with the "warning" feature of the edit filter is that it simply becomes one more button to push. Nearly everyone just hits "save" again and doesn't address the warning.—Kww(talk) 21:24, 11 July 2013 (UTC)
I don't know about you interacting with warnings, but in previous studies between 50 and 80% of "test" edits and silly vandalism (e.g. "poop") edits would be abandoned when given an appropriate warning. So at least some people do notice and react to warnings. Of course, the problem probably needs to be easily solvable too. In many cases, I can't really see how people working in VE would easily fix nowiki errors that VE creates. Even for things like using brackets inappropriately, it would be challenging both to understand and to fix the issue. Dragons flight (talk) 21:44, 11 July 2013 (UTC)
My primary experience with warnings is with Filter 526. Nearly everyone plows right through, even after I went to the effort of creating a bilingual edit filter in deference to our Brazilian editors.—Kww(talk) 21:52, 11 July 2013 (UTC)

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

Let me see:
  • all kinds of spurious nowiki-tags, such as someone adds a blank space: <nowiki> here</nowiki>.
These are added in a line-start position, as that line would otherwise be preformatted.
  • wikilinks chopped with prefix letters:  "C[[ommandant General]]"
This is a VE UX issue, but technically correct. Selecting a part of the word for linking will naturally link a part of the word. Also, this often inserts <nowiki/> at the end to avoid unintended link trails.
  • wikilink literalized by nowiki-tags: <nowiki>[[Page (person)|Page]]</nowiki>
This is normally people typing literal wikitext in VE. Same with template braces etc.
  • wikilinks with nowiki-tag split as 2 links: "[[Toffee|<nowiki/>]][[toffee]]" to show one link: toffee.
Was this link created in the VE?
  • wikilinks with no-wiki brackets: "[[Cricket (insect)|[[Cricket<nowiki>]]</nowiki>s]]" to show: [[Cricket (insect)|[[Cricket]]s]]
This sounds odd. Can you describe how or where this happens? --GWicke (talk) 22:16, 11 July 2013 (UTC)
Thanks for analyzing those examples, as we want to know if they are fixed or not caused by VE. Inside "Kneader reactor", see dif258 for dough/toffee wikilinks considered a VE edit, made 10 July 2013. In general, see: Scan of Filter 550. Many "nowiki" are fixed by same users. -Wikid77 02:59, 12 July 2013 (UTC)
From dif258 it is hard to tell if the user just created an empty link followed by a linked word, or if VE created weird HTML. I'm guessing the former as linking generally works fine. Maybe there is an opportunity to improve the UX though to avoid empty links to be created unwittingly. --GWicke (talk) 03:40, 12 July 2013 (UTC)

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

Addendum: apparently the VE tag was gone for a while, but is now back? Thanks for that at least! Fram (talk) 07:55, 12 July 2013 (UTC)
Regarding the tags, see #Revision tags not working correctly, below. Regarding the nowiki tags for editors who are mistakenly adding these in VE (thinking the process for wikilinking is the same in VE as in the old wikitext editor), I agree that the VE editor could be smarter about this. I'm going to post regarding the issue at WP:VE/F, requesting a bug be created for this if one does not already exist. -- John Broughton (♫♫) 20:26, 12 July 2013 (UTC)
Ah, well, not surprisingly, T51820 already exists that addresses this. -- John Broughton (♫♫) 21:00, 12 July 2013 (UTC)

How to circumvent "This file is bigger than the server is configured to allow."

I am trying to upload an NSA video on polygraphy which uses some excerpts from copyrighted TV shows (Meet the Parents and The Simpsons) and so I am uploading it locally on the English Wikipedia instead of on the Commons (I can cut out portions and upload that on the commons).

But when I have it in an OGV format the upload system says "This file is bigger than the server is configured to allow." - How do I circumvent this so I can upload the file?

Also how do I attach SRT files so they can interact with the video on the English Wikipedia?

Thank you WhisperToMe (talk) 07:10, 12 July 2013 (UTC)

You could file a request on Bugzilla to have it uploaded server-side. As for subtitles, see Wikipedia:TimedText. Matma Rex talk 08:53, 12 July 2013 (UTC)
Have you tried chunking the files and uploading them in pieces to be reassembled?—cyberpower ChatOnline 17:05, 12 July 2013 (UTC)
Some help pages to tag on to the above posts are commons:COM:MAXSIZE and commons:Help:Server-side upload. Killiondude (talk) 17:48, 12 July 2013 (UTC)

Revision tags not working correctly

Tracked in Phabricator
Task T53254

Edits made by using VisualEditor get the VisualEditor tag. Or so I thought, as it seems now that some do, and some don't. A typical example of a VisualEditor error was the addition of a substituted persondata template plus the duplication of the defaultsort and all cats plus the addition of Category:Persondata templates without short description parameter (this error should be corrected now, so no new instances of it should happen). I found many of those by looking through changes with the VisualEditor tag, but I have now found many recent edits making the same error, but without the ViualEditor tag. I don't believe that the error also happens in the "old" editing environment (it certainly was a rare one), but now...

Examples: [19][20][21], ... As can be seen, this has been happening since the start of VE, this isn't a recent issue, but I only found out about it just now. It looks as if thousands of VE edits have not been tagged with the VE tag, and thus have not been checked by VE correctors or taken into account in VE editing statistics. Am I missing something here or is something really wrong with this? Fram (talk) 08:29, 12 July 2013 (UTC)

Thanks for the report. We'll investigate ASAP.--Eloquence* 09:01, 12 July 2013 (UTC)
Thanks. Can I just say that so far, the speed and friendliness of replies wrt VE has been refreshing? I don't always agree with the responses or solutions, and VE contained (and contains) some serious flaws, but the post-deployment communication has been as far as I am concerned magnitudes better than with some earlier instances of controversial mediawiki changes. Fram (talk) 09:07, 12 July 2013 (UTC)
Thanks, Fram. We're trying hard to be visible and accessible throughout the deployment. Philippe Beaudette, Wikimedia Foundation (talk) 17:32, 12 July 2013 (UTC)
@Eloquence and Fram: WTF! I can see what appears to have happened. Recently (within the last day, and possibly within the last few hours) the devs altered the VisualEditor tag (including slightly changing its appearance). As what I can only hope was an unexpected side effect of their change, all of the VisualEditor tags added up to that point are now gone. Looking at the history of Asiana Airlines 214 [22], a current event where I know some people were using Visual Editor, there are now no tagged revisions older than four hours ago (despite multiple edit summaries mentioning cleaning up after VE). My own test space, also shows all the tags related to edits from previous days have vanished [23]. Reviewing a selection of articles where Fram was doing cleanup similarly shows all the older VisualEditor Tags seem to have vanished. So it appears we have completely lost the records of how VE was used during that first week. I daresay that if that information still exists in the database then figuring out how to retrieve it should be a priority, as not having those edits flagged will make it considerably harder to identify corruption created by VE and also much harder to measure statistics related to the deployment. Dragons flight (talk) 17:16, 12 July 2013 (UTC)
That is literally impossible. There is precisely no way that change could result in tag's disappearance. Matma Rex talk 17:47, 12 July 2013 (UTC)
Maybe its purely coincidental that the labeling was changed at around the same time the old tags vanished. I certainly wouldn't rule out that more than one software change associated with the tags could have gone live at the same time. That said, I know that both the old tags vanished and the labeling changed after 17:05, 11 July 2013 (UTC). Dragons flight (talk) 17:54, 12 July 2013 (UTC)
And based on Fram's comment, it seems likely that the old revisions lost their tag sometime before 08:29, 12 July 2013 (UTC). Dragons flight (talk) 17:58, 12 July 2013 (UTC)

Just as a note: this is not limited to VisualEditor. All the historical tags for GettingStarted edits are gone as well. Steven Walling (WMF) • talk 17:57, 12 July 2013 (UTC)

This might be helpful [24]. It appears the edit filter tag for blanking is shown on revisions since 01:25, 12 July (UTC); however, recent changes still lists a number of revisions older than that as examples of blanking. Hence, maybe the tag information is intact but the display mechanism was broken? Dragons flight (talk) 18:04, 12 July 2013 (UTC)
Similar behavior appears through the API [25]. Asking for a list of edits having the "blanking" tag returns in 50 results, but the earlier half of those then report they have no tags, which is obviously contradictory. Dragons flight (talk) 18:09, 12 July 2013 (UTC)

Lucky the visualeditor-needcheck ones are working fine. These are the ones where VE is most likely to mess up. From that you can see it was between 23:44 and 00:44 that the tags stopped getting dropped.--Salix (talk): 18:28, 12 July 2013 (UTC)

I have no idea what is happening, but the information about tags is not gone: for example, you can filter eidts with a tag: [26] but funnily it is not shown anyway. It's gotta be something really funky. Matma Rex talk 18:33, 12 July 2013 (UTC)

Bug Report. tag_summary appears to be missing some data. change_tag looks intact. Former could be repopulated from the latter. Awaiting binasher input. — Preceding unsigned comment added by SPringle (WMF) (talk • contribs) 19:26, 12 July 2013 (UTC)

Update, as I understand it: A bug with database schema changes accidentally nuked a table in the database. But (thank gods for backups and redundancy!) no data is actually lost, and WMF's best people are working on it now :) Matma Rex talk 21:00, 12 July 2013 (UTC)

Ah, so easy drop table ... --Redrose64 (talk) 21:32, 12 July 2013 (UTC)
Has Little Bobby come to help edit our project? (oblig. xkcd) –Quiddity (talk) 21:53, 12 July 2013 (UTC)
There's now a writeup by somebody who actually know what they're doing at bug 51254 comment 5 and this is being fixed right now. The tables wasn't nuked, apparently, but merely – as Sean put it – "massively reduced in size" :D Matma Rex talk 22:30, 12 July 2013 (UTC)
Per the bug comments enwiki.tag_summary table has been rebuilt. I'm seeing correct historical tags restored for gettingstarted edits from June. Steven Walling (WMF) • talk 23:39, 12 July 2013 (UTC)
For the record, I reopened this bug due to lingering corruption (see my comments on the bug report). Most of the tags are probably correct at this point, but not all of them. Dragons flight (talk) 01:09, 13 July 2013 (UTC)

Separate page for VE discussion?

Would it be possible to move VE issues to its own page? I like reading VPT, and am not yet dealing with VE, so the increased volume is difficult to deal with. I'm sure I'm not alone. —[AlanM1(talk)]— 17:43, 12 July 2013 (UTC)

I have mentioned WP:VE/F, two or three times, poss more. --Redrose64 (talk) 17:55, 12 July 2013 (UTC)
Yep, VE/F is the place - David Gerard (talk) 18:18, 12 July 2013 (UTC)
  • Other VisualEditor discussions: Also consider the following:
It is an extensive problem, and many highly experienced editors are burning their valuable time re-editing pages garbled in many ways by glitches saved using VisualEditor. People should beware distraction and remember to expand articles or handle other issues. -Wikid77 (talk) 05:09, 13 July 2013 (UTC)

User contributions toolbar

I've noticed that the toolbar at the bottom of User contributions pages has been gone for a while—the one with the edit counter, global contribs, and (for IPs) a geolocator. Is this just a glitch, has it been relocated, or are there actual substantive reasons why it was removed? I'm using MonoBook skin, if it makes any difference. ~~ Lothar von Richthofen (talk) 20:00, 12 July 2013 (UTC)

I still see it with Vector. I suppose one of these revisions could have mythically broken it for monobook, but I think it's much more likely you simply installed some sort of script that's interfering with it. Have you tried WP:BYPASS? Theopolisme (talk) 20:24, 12 July 2013 (UTC)
Assuming that you mean the one at the bottom of Special:Contributions/Lothar von Richthofen,  Works for me in Monobook. --Redrose64 (talk) 20:32, 12 July 2013 (UTC)
It's only there if you have your language preference set to standard English.—Kww(talk) 20:34, 12 July 2013 (UTC)
Ah, that's it. I've had mine set to en-GB. Thanks! ~~ Lothar von Richthofen (talk) 20:42, 12 July 2013 (UTC)
I decided to be more helpful and actually install it on the British interface. Somebody installed a bunch of overrides to force the various alternate definitions to a single "-" character instead of leaving them undefined in the Mediawiki base, which is why a number of messages disappeared.—Kww(talk) 21:10, 12 July 2013 (UTC)

Wikidata after an article move

Wikilinks to others languages are lost after article Direct negotiations between Chile and Argentina in 1977–1978 was moved to Direct negotiations between Chile and Argentina in 1977–78. We can add the links with wikidata but IMO there should be done automatically by every move. --Best regards, Keysanger (what?) 08:26, 12 July 2013 (UTC)

I think there's a bot that does this every hour. But yes, it's a bug, I'm pretty sure it's filed, but can't find it on Bugzilla right now. Matma Rex talk 08:51, 12 July 2013 (UTC)
Y'know, I thought there was a reminder in MediaWiki:Movepage-moved to fix up Wikidata after a move... it seems that there isn't. --Redrose64 (talk) 10:36, 12 July 2013 (UTC)
bugzilla:36729. See quote: "Will be deployed on July 8th or 12th." (quote by User:Denny Vrandečić (WMDE), see #c14). Today is July 12. Is this deployed yet? πr2 (t • c) 13:45, 12 July 2013 (UTC)
Now scheduled for deployment on July 25, per Aude (bugzilla:36729#c15) πr2 (t • c) 21:29, 13 July 2013 (UTC)

Trouble with citation.bot

Is it just me, or is there a problem? When I try to create via {{cite pmid}} (for example, {{cite pmid|12730697}})I get a message about security errors:

<quote>The security certificate presented by this website was not issued by a trusted certificate authority.

The security certificate presented by this website was issued for a different website's address.</quote>

I do have problems on this wifi connection, passing through local public library, which applies filters of its own, bur it has worked before, often. John of Cromer (talk) mytime= Sat 09:00, wikitime= 08:00, 13 July 2013 (UTC)

I added that cite to my sandbox article; it worked fine for me. -- John Broughton (♫♫) 18:42, 13 July 2013 (UTC)

Toolserver down?

Toolserver isn't responding this morning - can somebody please find out what's happening with it? Thanks, PKT(alk) 12:50, 13 July 2013 (UTC)

I get "Unable to connect Firefox can't establish a connection to the server at toolserver.org. The site could be temporarily unavailable or too busy. Try again in a few moments. If you are unable to load any pages, check your computer's network connection. If your computer or network is protected by a firewall or proxy, make sure that Firefox is permitted to access the Web." Anyway, Toolserver has been ropy for months. Try again later; sometimes it takes only a few seconds to come back. --Redrose64 (talk) 13:16, 13 July 2013 (UTC)
Well, it has been an hour and 20 minutes by my count, so far. PKT(alk) 14:10, 13 July 2013 (UTC)
I think this is the same as my report one up from here. It didn't work yesterday either. In the library I get "Network error" John of Cromer (talk) mytime= Sat 16:58, wikitime= 15:58, 13 July 2013 (UTC)
Toolserver is responding off-and-on now, perhaps it was napping. PKT(alk) 16:05, 13 July 2013 (UTC)

Need simple way to add Commons category interwiki links

Ever since wikidata was rolled out to automate the display of language links I have been frustrated by the loss of a way to easily populate Commons categories with interwiki links.

I made the following post at [27]:

Before wikipedia used the wikidata automated tool that displays links to other wikipedia language projects, it was simple to copy the list of interwiki links from any wikipedia article and use it in a Commons category. One would just copy the list, add the source language link and paste to the end of the commons category page.

Well, now I am quite stumped. What is needed is a a simple way to trigger wikidata to show the language interwiki links in
each Commons category.

I tried and failed to do this at [1], but I may have succeeded some months ago only by tedious trial and error.

How about a means for the wikidata page to extract all the links as a single page in copyable plaintext? It appears that functionality has been lost and is sorely needed (by me if noone else). I will back link my posting from the Village pumps at wikipedia and Commons. -~~~~

-84user (talk) 16:37, 13 July 2013 (UTC) (crosslinked at Commons:Village_pump#Need_simple_way_to_add_Commons_category_interwiki_links, feel free to reorganise my postings! -84user (talk) 16:55, 13 July 2013 (UTC))

@84user:, I wrote a CommonsInterwiki tool a while back. There's a more detailed post at commons:Commons:Village_pump/Archive/2013/06#Commons_interwiki_links_generator_tool. Let me know if you can think of any improvements. Legoktm (talk) 00:19, 14 July 2013 (UTC)

Footnotes

I just opened Sorga Ka Toedjoe and the lowercase a, b, c, d etc. which was used for the explanatory footnotes is now showing as [lower-alpha 1], [lower-alpha 2], etc. Yet Sudirman has no issue with the footnotes. Any idea what's happening? — Crisco 1492 (talk) 02:13, 14 July 2013 (UTC)

It is more than that. Something has reset the Cite customizations. Looking at this. --  Gadget850 talk 02:20, 14 July 2013 (UTC)
Purging the page fixed it. That was weird. The English Wikipedia has a lot of customization for Cite, such as replacing the default up arrow backlink labels with carets. --  Gadget850 talk 02:24, 14 July 2013 (UTC)
What is your language set to? --  Gadget850 talk 02:50, 14 July 2013 (UTC)
  • English. It's working now. — Crisco 1492 (talk) 02:53, 14 July 2013 (UTC)

Category:Musical theatre articles missing an image in infobox

Tracked in Phabricator
Task T53163

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

Yes, you can check the namespace. One way to do so is {{Namespace detect}}. Another, specific to the article space, is {{#if:{{NAMESPACE}}||[[Category:Musical theatre articles missing an image in infobox]]}}. However, I would personally recommend {{main other}}, which does exactly what you want (see the second example!). πr2 (t • c) 21:13, 2 July 2013 (UTC)
Thanks, i tried it but to be honest i have no idea what I'm doing so wouldn't work. Im assuming you meant on the infobox rather than the cat.Blethering Scot 21:41, 2 July 2013 (UTC)
The {{main other}} should be wrapped around the category, but placed inside the infobox template code. Here's one I made earlier. --Redrose64 (talk) 22:02, 2 July 2013 (UTC)
Thanks how often does it usually take for them to be removed from the category.Blethering Scot 21:55, 3 July 2013 (UTC)
It depends on the job queue. That's currently showing zero, which occurs so rarely that I suspect that there is some problem with generating the figure. --Redrose64 (talk) 22:22, 3 July 2013 (UTC)
There still showing, have i done it wrong or is the job queue extremely long.Blethering Scot 22:28, 6 July 2013 (UTC)
It's clearly a problem, one that I've noticed elsewhere. I've filed bugzilla:51163. --Redrose64 (talk) 10:05, 11 July 2013 (UTC)
Redrose64, as Nikerabbit says the number in API stats is unreliable. As already documented on Help:Job queue, you can used this graph which uses a maintenance script and should be reliable: [28]. I do see a 5k spike about the time of your edit, may be it. --Nemo 10:13, 11 July 2013 (UTC)
Ignoring that surely 14 days isnt normal at all for it to go through. Is there anything that can be done to make it do so for instance maybe removing and re making the edit.Blethering Scot 16:26, 14 July 2013 (UTC)

Controlling order of reflist

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

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

which yields:

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

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

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

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

Apart from actually making it a bibliography and using templates from the {{sfn}} family, no. Matma Rex talk 21:26, 6 July 2013 (UTC)
I don't understand. It is a bibliography, but I want to label the entries A,B,C or whatever, and refer to them using linked superscripts in the article text, via a <ref>-type syntax. This seems a natural thing to want to do. Are you saying sfn would help with that? EEng (talk) 21:48, 6 July 2013 (UTC)
As an alternative (which would allow a disgusting hack on this), is there some syntax for <ref name=Jones2010/> that would cause only this one callout to Jones2010 to not have a backlink next to the Jones2010 entry in the reflist? (It is recognized I am grasping at straws here.) EEng (talk) 21:52, 6 July 2013 (UTC)
Put a Sources section of titles, then {sfn} each author/year link: Under the References section, put a "===Sources===" subsection with book titles in a bullet list of {cite_book} with ref=harv or such. Then use Template:Sfn in the upper text, to link each book author/year into the Sources list. -Wikid77 (talk) 21:56, 6 July 2013 (UTC)
Look at Today's Featured Article: Dodo. It has numbered short cites (created by template) and then an alphabetized bibliography (called "sources" in this case). That is the way issues like this are usually handled where you want both the links but also a specific layout of sources. Dragons flight (talk) 21:59, 6 July 2013 (UTC)

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

Can you point to an article where that style is already in use? If so, we'll explain how it's done.
Dodo, btw, uses almost-pure Shortened footnotes. I say "almost" because it's throwing about 6 big red errors for me. --Redrose64 (talk) 22:28, 6 July 2013 (UTC)
1. The first part of your questions concerns List-defined references, and as I wrote on that help page: "The references will appear numbered in the order that they are referred to in the content, regardless of how they are ordered within the reference list."
2. There is no way to suppress a footnote backlink. I have a bug report in for that, but it has gone nowhere.
3. The Shortened footnotes help page has examples of articles with good use.
4. As noted at List-defined references, you can use {{r}} to include the in-text citation with a page number. It only supports the default footnote labels, but we could do a variant.
--  Gadget850 talk 02:41, 8 July 2013 (UTC)
None of this answers my question/request. I hope you will forgive my taking the liberty of numbering your points above for reference.
1. Obviously I know that "The references will appear numbered in the order that they are referred to in the content, regardless of how they are ordered within the reference list." -- I said so in my opening post. (I've put that in bold now to make that even more obvious.)
2. In the absence of a useful outcome on point 1., suppressing one backlink would help in a hack in mind for getting something similar to what I really want. But looks like I shouldn't hold my breath.
3. I already explained what I'm trying to do, and it's nothing like sfn.
4. Ditto.
I repeat: I don't need it explained to me how reflists are ordered now, by default -- I know that. My question was whether there's some syntax or trick to change the order; or (implicitly) in the alternative, I was hoping someone would be inspired to add such a function, or tell me where to go to request that this be done. So can someone please answer that question, instead of telling me how to do things other than that which I came here to learn how to do??? In desperation I've implemented a painful hack [29] demonstrating how such a feature might be applied (ignore the entries in the References section -- they're meant to be migrated to other sections).
EEng (talk) 03:44, 10 July 2013 (UTC)
If you use (or wish to use) any form of referencing which involves <ref>...</ref> and <references /> (whether directly or hidden inside templates like {{sfn}} or {{reflist}}) the answer is
No, the order that they are listed is determined by their order in the wikitext, and cannot be changed; it follows that the order that that they are numbered is determined by the order that they are listed.
If you want some other ordering you cannot use <ref>...</ref> and <references /> but must use a custom method - which will be complicated - or one of the older systems from about eight years ago which required every ref to be hand-numbered. See {{ref}}, {{note}}, {{ref label}}, and {{note label}}. --Redrose64 (talk) 07:30, 10 July 2013 (UTC)
Given that it's perfectly natural to want the reflist entries to appear in some useful (instead of haphazard) order, I'm puzzled as to why the possibility of adding such a feature to <ref>...</ref> and <references /> is being ignored. Where would I go to make such a request? EEng (talk) 11:51, 10 July 2013 (UTC)
Which is the Footnote3 system. --  Gadget850 talk 10:46, 10 July 2013 (UTC)
Sounds like that may have to be the interim stopgap. EEng (talk) 11:51, 10 July 2013 (UTC) I spoke to soon. Only an insane person would consider using Footnote3. EEng (talk) 13:33, 10 July 2013 (UTC)

This almost works, except for a spurious backlink:

[1]According to Smith[2] it's true, but Jones[1] says it's false.
  1. ^ a b Jones, J. (2009) The truth
  2. ^ Smith, S. (2010) Jones lies

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

But you've not used {{ref}}/{{note}} at all - you've used almost exactly the same code as EEng did in the original post, with two differences: (i) you've quoted the ref names (which will not make any difference); (ii) you've added <span style="display:none"><ref name="Jones2009"/></span> which is what's causing that "spurious backlink". --Redrose64 (talk) 12:36, 10 July 2013 (UTC)
Who cares whether he used {{ref}}/{{note}}? What does that have to do with anything? The <span style="display:none"><ref name="Jones2009"/></span> he added forces the Jones ref to come first, which is something like what I was looking for. As it happens I had already thought of a similar idea, as seen in the mockup I linked a bit earlier ([30] -- open the source for editing and look at the shamefaced comment at the very beginning). It's why I asked (somewhere above) for a way to suppress a single selected backlink. (Thanks, EmilJ, for trying to help.)
Frankly I'd be willing to live with the spurious backlink if that's the best we can do.
EEng (talk) 13:19, 10 July 2013 (UTC)
If that's your attitude, who cares that you want to use some system that is different from the Wikipedia norm? Three times I responded to a plea for help: but have been rejected once too often. I'm done helping here. Just don't blame me if somebody tidies up that spurious backlink. --Redrose64 (talk) 14:07, 10 July 2013 (UTC)
Look, all I asked is (1) if there's a way to control the order of the reflist and (2) failing that, where I'd go to make a request that such a feature be added. Can you please just answer that? EEng (talk) 15:25, 10 July 2013 (UTC)
you may want to look into mw:Extension:Cite and it's talk page. peace - קיפודנחש (aka kipod) (talk) 16:04, 10 July 2013 (UTC)
Thanks! I'll want to look around there and learn what I can before posting, so it may a while. EEng (talk) 18:01, 10 July 2013 (UTC)
Years back, I offered via WP:Bugzilla a couple of versions of an enhancement to Wikimedia:Extension:Cite which would have supported this. However, the internals of my suggested changes were invalidated by WM:Cite featurization which bypassed WP:Bugzilla before completion of consideration and the suggestions have since been withdrawn. As I recall without digging for details, my changes would have supported the optional placement of the WP:LDR list early in the article, invisibly in the rendered wikitext, and without impacting the footnote numbering. This had the effect of forcing refs in that list to the head of the numbered footnotes and ordering them as they were manually ordered there. Wtmitchell (talk) (earlier Boracay Bill) 23:06, 14 July 2013 (UTC)
It's good to hear from a third editor (EmilJ and kipod being the other two) who takes the time to understand what's being asked. If you look at EmilJ's code above, and my comments at the very start here [31], you'll see that we've all been thinking along the same lines. Nasty hack though this technique I actually feel its advantages outweigh its drawbacks and I'd like to take it live in the article, with the hope that someday a purpose-built facility will become available to make the hack unnecessary. There's only one other editor at Talk:Phineas Gage who's willing to engage this kind of technical issue and I'd be most happy if you'd look over the implementation (in my sandbox) in detail and explore the question with us. I feel that remedying the random order of reflist entries is an important goal for the reader's sake, and well worth any ugliness we editors see in the source. Thanks. EEng (talk) 03:02, 15 July 2013 (UTC)

Recurring problem

Again, I have had two identical edits made, 1 second apart, without double-clicking or anything obvious: [32]. Anyone else experienced this?--Gilderien Chat|List of good deeds 17:59, 13 July 2013 (UTC)

This happened again here and here.--Gilderien Chat|List of good deeds 21:40, 13 July 2013 (UTC)

You made similar reports at [33] (I couldn't make a wikilink to that section) and Wikipedia:Village pump (technical)/Archive 113#Double edit. If you sometimes add a section twice when you use the new section tab, and get an edit conflict with yourself when you make other edits, then it sounds like manifestations of the same problem. I don't recall hearing or seeing this from others so I guess it's something in your account or computer. What is your browser and skin? PrimeHunter (talk) 23:42, 13 July 2013 (UTC)
I don't seem to get the edit-conflict problem anymore, but this has only happened when I use the new section button. I use Chrome, and Windows 7 with a personalised Vector skin on a Dell Inspiron 17R Special edition and I don't recall changing any relevant preferences.--Gilderien Chat|List of good deeds 23:53, 13 July 2013 (UTC)
Again here.--Gilderien Chat|List of good deeds 22:16, 14 July 2013 (UTC)

New Version of the Flow Prototype Released

A new version of the Flow Prototype has been released. Please read the release notes here. This version has many changes, not the least of which is that it approaches full functionality.--Jorm (WMF) (talk) 21:20, 13 July 2013 (UTC)

Again with the liking it rather than lumping it, I'll toss in a cent or two here. Is there any way wikimarkup will be usable in Flow? There's a pretty steep learning curve, but once learned it's definitely quicker to just tap the quote key a couple times than to take my hands off the keyboard and go hunting for the "bold" button. (Speaking of which, if that button works currently it's not in a manner that's obvious to me.) Ignatzmice•talk 21:33, 13 July 2013 (UTC)
Ignatzmice, I think you'll want to read Wikipedia:VisualEditor/Keyboard shortcuts. ⌘ Command+B bolds selected text (on a Mac) and I believe it's Control+B for Windows. Whatamidoing (WMF) (talk) 01:48, 14 July 2013 (UTC)
Tried that, didn't work. It is a pre-alpha version, right Jorm? All will be well in the future, I trust. Ignatzmice•talk 01:55, 14 July 2013 (UTC)
Did you try that in the prototype (which does not have 100% functionality), or in VisualEditor (e.g., in an article)? It's working for me in VE, using Firefox on a Mac. If it's not working for you in VisualEditor, then please let me know so I can file a bug report. Whatamidoing (WMF) (talk) 22:31, 14 July 2013 (UTC)
Flow is currently designed to utilize the VisualEditor and be forwards-compatible with that. Wikimarkup is probably not on the table.--Jorm (WMF) (talk) 21:37, 13 July 2013 (UTC)
I presume it has been considered to have something along the lines of the Wikia visual editor? Also, although personally I think it is a nice touch, the "be nice" may strike people as a little patronising.--Gilderien Chat|List of good deeds 21:42, 13 July 2013 (UTC)
More like our own VisualEditor software. I agree that some people may find "be nice" as patronizing, but at the end of the day I think it will help with our overall problems with civility.--Jorm (WMF) (talk) 22:02, 13 July 2013 (UTC)
Have you used the Wikia editor? It is pretty easy to use and lets you use wikimarkup which it converts when you save.--Gilderien Chat|List of good deeds 22:10, 13 July 2013 (UTC)
I know that we explored the Wikia editor ages ago during our first forays into discovery regarding the VisualEditor and that it was found wanting and buggy in places. Hence our own VisualEditor. I'd expect to receive significant pushback internally were I to suggest the Wikia editor over our own.--Jorm (WMF) (talk) 22:16, 13 July 2013 (UTC)
Ok thanks. The preview is quite formatting heavy, could it be a preference to display more like our current look, which to me is much easier to read than the prototype and other similar things on other sites.--Gilderien Chat|List of good deeds 22:26, 13 July 2013 (UTC)

A few immediate observations:

  • About the cancel buttons, why are they red? To me, they look identical to a wp:redlink, which kind of clashes with the rest of Wikipedia.
  • Are those formatting buttons merely placeholders right now?
  • I can click on multiple "actions" dropdowns, and clicking a new one does not dismiss one already open"
  • When editing the title of a conversation, the input line extends about a 1/4 in past the right edge of the dialog, when it should stop about a 1/4 in from it. (XP, Chrome, independent of zoom or window size)
  • Should deleting a topic prompt for a reason, if it isn't necessary? (Closing a topic requires one)
Chris857 (talk) 21:52, 13 July 2013 (UTC)
In order:
  • Red is the Agora color for a "destructive" action. I agree with you about the "redlink" problem, which is really a bug with "redlinks" in general (they should never have been red in the first place). Your concern is noted, however.
  • Yes, just placeholders.
  • That sounds like a bug. You shouldn't be able to activate multiple modal windows at the same time. What browser/operating system are you using?
  • Bug. I'll look into it.
  • It should, but I didn't code it in. I'll add that to the to-do list.
Hope that helps.--Jorm (WMF) (talk) 22:02, 13 July 2013 (UTC)
Dropdowns
I have a few more details about the "actions" dropdowns, and a screenshot. This is Chrome, on XP.
  • It appears that I can bring up multiple of these menus if they are the same type, ie, multiple conversation-level dropdowns, or multiple "individual-comments-within-conversation" dropdowns, but not a mix of the two. An attempt to mix dismisses all dropdowns except the one just clicked on.
  • If I click outside of the dropdown, all dropdowns are dismissed like I expect. Same with clicking on a action within a dropdown.
  • Entirely unrelated, but Flow is hideously broken on IE8 on XP.
Chris857 (talk) 22:24, 13 July 2013 (UTC)
Let me stress that this is only a prototype, and not the final product. I wrote it using only Chrome and Firefox on a macbook; I should expect that IE will absolutely break with it.
Thank you for the screenshot; this is helpful. I can't guarantee a fix in the next day or so, however. This is funky.--Jorm (WMF) (talk) 22:28, 13 July 2013 (UTC)

It would be nice if it used the screen better - on my main computer (1920 x 1080 monitor), it uses only half the screen - Flow should be able to work well with a whoile range of screen sizes, form phones and tablets to huge wide-screen monitors.Nigel Ish (talk) 22:16, 13 July 2013 (UTC)

Yes, it looks rather silly with 2/3 of the screen being whitespace on my 2560 x 1440 monitor. Dragons flight (talk) 22:31, 13 July 2013 (UTC)

Remind me, is this planned as an option on talk pages or a replacement for them? Dragons flight (talk) 22:32, 13 July 2013 (UTC)

Replacement.--Jorm (WMF) (talk) 22:33, 13 July 2013 (UTC)
Now there is quite a bit of stuff I'd like to have in my talk page. Looking back through my archive there is a section User_talk:Salix_alba/Archive6#Singular with mathematical formula, and computer code. Neither of which can be done by VE and I would suspect maths would be a long time coming. As a mathematical editor being able to do maths on my talk page is vital. I'm very worried you are going to introduce a system which reduces my functionality. Will there be an opt out?--Salix (talk): 22:40, 13 July 2013 (UTC)
See mw:Thread:Talk:Flow Portal/Maths - maths is rapidly on its way, and in a testable state. –Quiddity (talk) 04:35, 15 July 2013 (UTC)
In that case it will need to be very close to feature complete in terms of its representation of wiki code abilities (e.g. math, tables, parser functions, magic words, syntaxhighlight, etc.) since pretty much anything that might be in an article will need to be discussed sooner or later. Otherwise, one risks really antagonizing the experienced users. OR, one could just make options so that the magic edit boxes will also accept wiki code, which is my personal preference though I know the VE people don't like to hear that. Dragons flight (talk) 23:24, 13 July 2013 (UTC)
Possibly simpler is to implement an <wikisrc>...</wikisrc> tag where we can embed wikisource and have it parsed and render by the same system used by actual articles, without being passed through parisod which has round trip problems. You also need to have <pre> implemented so we can see the source which caused the problems. Another recent example of this is on @Okeyes (WMF):'s talk page User talk:Okeyes (WMF)#broken template data where we were trying to debug template data code.--Salix (talk): 00:39, 14 July 2013 (UTC)
Since someone is working on math support for VisualEditor, the use of VisualEditor should not prevent you from using math. The overall plan is "use VisualEditor", not "use a subset of VisualEditor that excludes math". Whatamidoing (WMF) (talk) 01:48, 14 July 2013 (UTC)
Did you realize virtually every mathematician/physicist (e.g. those who use formulas most) uses LaTeX for his/her documents? Wikipedia was always beloved for the possibility to use TeX code. I doubt this will be something VE offers? --Patrick87 (talk) 04:29, 14 July 2013 (UTC)
And how is maths going to be done when the option to enable the mathjax render by default T38496 has been closed as WONTFIX. Its not practical with the default texvc renderer which would have to go off a generate an image for every keystroke.--Salix (talk): 06:18, 14 July 2013 (UTC)
Presumably maths will be done in Flow with VisualEditor exactly like maths will be done in articles with VisualEditor. Whatamidoing (WMF) (talk) 22:31, 14 July 2013 (UTC)
See mw:Thread:Talk:Flow Portal/Maths - maths is rapidly on its way, and in a testable state. –Quiddity (talk) 04:35, 15 July 2013 (UTC)
It looks nice, but my concern at mw:Talk:Flow_Portal#Flow_is_too_tall_27765 still stands. The nature of discussions here is that they tend to consist of many short contributions (unlike, say, Wiktionary, where each contribution to a discussion tends to be longer). Take, for example, this discussion at ANI - how tall would that be in Flow? — This, that and the other (talk) 01:07, 14 July 2013 (UTC)
Ah, I forgot about that thread. Actually I brought up something very similar here sharing your concerns and giving a screenshot comparison how we could easily save huge amounts of space even with the current layout. --Patrick87 (talk) 04:29, 14 July 2013 (UTC)

What technical problem would there be in allowing us to have the equivalent of "edit source" for talk page comments?—Kww(talk) 17:21, 14 July 2013 (UTC)

I think it would be that it would be too slow to parse from stored HTML into wikimarkup and back. Or something like that.--Gilderien Chat|List of good deeds 20:46, 14 July 2013 (UTC)
Not exactly. You're right that Flow discussions will not be saved in form of Wikitext anymore. They'll be rendered to something similar to HTML (not exactly HTML, though) the moment you post a comment. Therefore when displaying a discussion no further parsing is necessary therefore greatly reducing server load.
This does not prevent writing a comment in markup though. It can easily be parsed to the internal Flow representation when you submit it, exactly as if you use VisualEditor (probably even easier). There's no (puplicly known) reason yet why there should not be a markup editor. Except maybe Brandon being a WYSIWYG fetishist, disliking Wikitext, or not caring at all – see also his merely unsatisfying replies he posted to my request regarding the issue in the MediaWiki thread. --Patrick87 (talk) 21:17, 14 July 2013 (UTC)
It's very simple, actually, and I think I've said this multiple times: if we allow raw wiki markup, then it is entirely possible that someone can produce a post that cannot be rendered or edited by the VisualEditor in the future. The only way to guarantee that Flow is "future proof" is to start with the VisualEditor from the beginning.--Jorm (WMF) (talk) 22:01, 14 July 2013 (UTC)
a) Boo-freakin'-hoo, b) so maybe you can make it so we can only do wikimarkup that VE can handle, c) what's the point of VE if it can't do all that markup can do, and d) it's not as critical to be able to edit talk page posts as it is regular articles (still pretty useful, though). Ignatzmice•talk 22:10, 14 July 2013 (UTC)
It's actually simpler than that, Jorm: if you can't handle markup, you haven't produced a useful feature. The use of the Visual Editor is an option. The WMF has stated over and over that it will not mandate its use. To tell us that we cannot discuss things with other editors unless we use Visual Editor is not in keeping with that promise.—Kww(talk) 22:17, 14 July 2013 (UTC)
So Visual Editor may downgrade editors' ability to control form and display? I doubt this has been disclosed before in any sort of simple declarative sentences. Hullaballoo Wolfowitz (talk) 22:22, 14 July 2013 (UTC)
@Jorm (WMF): Yes, you said it multiple times and I supposed we were over this discussion (although it makes a nice excuse to why you "can't" support Wikitext for the clueless user, that i have to admit). Fact is: VE can already do most of the things Wikitext can do (and probably already much more than you will allow in Flow, e.g. templates). Therefore you have to restrict VE to a subset of it's features anyway. And there is no reason why you couldn't do exactly the same for a markup editor in Flow. Remove HTML tags, styles and templates and you would have essentially what you said Flow comments would support. And don't claim VE couldn't support these basic things, that's just not true. Especially when everything is parsed to an internal format in the moment a comment is submitted anyway. --Patrick87 (talk) 22:44, 14 July 2013 (UTC)
Now I'm really confused: are you saying that Flow won't support templates? Did anyone notice that an extremely large percentage of talk page messages consist of a template and a signature?—Kww(talk) 22:48, 14 July 2013 (UTC)
Yes, I believe so, but as Brandon has explained as well, our current method of templating etc. is inefficient and Flow will allow more natural workflows to be developed. Or something like that :p --Gilderien Chat|List of good deeds 23:15, 14 July 2013 (UTC)
It's more complicated than that. An extremely large percentage of user talk page messages consist of what was a template and is now actually wikitext (because they're all subst'd). What you need is an easy way to get a standardized message onto the page. Flow will provide that. It may or may not happen as "a template".
I recommend spending some time with the use cases. mw:Flow Portal/Use cases provides a long list of what you will be able to do. Efficiently leaving messages for other people, whether by humans or by bots, is already on the list.
AFAICT, the only thing that has been definitively ruled out is having a fancy signature, since Flow's "signature" is actually taken from the history page (where fancy signatures don't show up under the current system). WhatamIdoing (talk) 04:25, 15 July 2013 (UTC)


I'm really afraid when I read comments saying that this will replace the current wikitext for talk pages for several reasons:

  • Talk pages are not used only to post messages to each other in a forum, they are also used to work collaboratively between several editors in many cases: for example, writing a list of tasks to do on the article, which can be completed (in the initial post) by others, and when someone has done a task he marks the task (in the initial post) has done. How can it be done with Flow ?
  • Interfaces like Visual Editor are a lot slower to user than simply typing what you want when you have managed the wiki syntax. They can be useful for new editors, or for complex syntax (like tables, ...) but for simple things they are often more cumbersome (requiring to learn shortcuts or to use the mouse).

--NicoV (Talk on frwiki) 22:32, 14 July 2013 (UTC)

The plans for Flow include a header for what's called "metadata" in the mw:Flow Portal/Use cases. This is a place to put things like a {{todo}} list. There are also plans for collaborative editing space. For example, I could create one to post my proposed wording for a page, and then other people could edit that directly. Several different ways of doing this (one per page? one per discussion thread? one per comment? ability to set any given comment to 'anyone can edit'? set all comments to 'anyone can edit'?) have been proposed. If you have ideas or preferences, then feel free to leave a note at WT:Flow. WhatamIdoing (talk) 04:31, 15 July 2013 (UTC)

@Jorm (WMF):. I'm having a bit of trouble figuring out the time line on the various Meta pages. Am I correct in understanding that Flow probably won't be enabled for mainstream use until mid-2014? Or what is the rough schedule? Dragons flight (talk) 22:40, 14 July 2013 (UTC)

My current understanding is that we'll have some version able to be deployed in December of 2013, in an opt-in basis. Mid 2014 seems like a realistic target for mainstream deployment, then.--Jorm (WMF) (talk) 22:49, 14 July 2013 (UTC)
Some info is at WT:FLOW#Roadmap ("December [2013]: Goal date for the full production release of the user-to-user discussion system"). By the way, as is my custom, I prepared this message in a text editor and pasted it into the edit window. Waiting for kitchen-sink-included Javascript before I can do Ctrl-V is irritating. Johnuniq (talk) 01:43, 15 July 2013 (UTC)

Special:Notifications and files

Today, a user thanked me for an edit to a file. For that reason, the file is displayed at Special:Notifications. This makes the notifications page hard to read: I have been thanked for edits to several files, and all of the files are shown at their full size (e.g. 942 × 451 pixels for File:Inaugural Atomic Weights report 1903.png). Some files can be quite big.

Is there a way to see file names as text instead of seeing the images, or at least to see a small thumbnail image instead of a full-size image? Seeing half a million pixels on a small mobile phone screen is inconvenient. WP:IMGSIZE advises people not to force images to be displayed in articles at a too big size for precisely this reason. --Stefan2 (talk) 14:47, 14 July 2013 (UTC)

Fixed by editing MediaWiki:Notification-thanks. Also, gerrit:73615. Anomie⚔ 15:17, 14 July 2013 (UTC)
Thank you! --Stefan2 (talk) 16:44, 14 July 2013 (UTC)

Template displaying different results for different people

I copy the following discussion from Template talk:Sumter County, Florida.

This template is defective. On every article it's attached to, the unincorporated community of Tarrytown, Florida shows up, But on the Sumterville, Florida article Tarrytown won't show up on the template. I thought it was an unintended consequence of one of User:Nyttend's edits, but I was wrong. So why won't Tarrytown show up there? ---------User:DanTD (talk) 17:06, 12 July 2013 (UTC)

Um, it's there when I view the page. Perhaps some sort of weird caching error? I've edited both article and template, so the caching should now be forced to restart. Nyttend (talk) 17:47, 12 July 2013 (UTC)
Sorry. I'm afraid it's still not showing up. It's definitely weird though, because it shows up on every other Sumter County, Florida article. ---------User:DanTD (talk) 21:48, 12 July 2013 (UTC)

Any clue what's going on, or how to fix it? I see no problems myself, so I'm not entirely clear what DanTD's experiencing. Nyttend (talk) 17:18, 14 July 2013 (UTC)

There is a similar report about another navbox (the Sideways link in No Hats Beyond This Point) at Wikipedia:Help desk#Problem with Men Without Hats template? I don't see the problem in any of the pages but I noticed the allegedly missing link is repectively right before and right after the automatically bolded selflink in the navbox. Could there be an issue with such selflinks "eating" a nearby link in certain circumstances? I admit it sounds strange. The disappearing links have been in the templates for years so it doesn't sound like the problem is an old cached page revision. PrimeHunter (talk) 19:06, 14 July 2013 (UTC)
I saw the problem when going through a proxy and now without a proxy I don't. I wonder if the proxy has something to do with it. Doctorx0079 (talk) 23:10, 14 July 2013 (UTC)

Making the double redirect fixing bot smarter.

Recently, the article that was originally at Tom Barry was moved to Tom Barry (soldier), and Tom Barry was then redirected to Thomas Barry. All of this is fine. However, prior to these moves, Guerilla Days in Ireland (written by Thomas Barry (soldier)) was a redirect to Tom Barry. When Tom Barry was redirected to Thomas Barry, Guerilla Days in Ireland became a double redirect, and the double redirect fixing bot came along and made it point directly to Thomas Barry. This is fairly regular scenario. My hope is that the double redirect fixing bot can be made smarter, so that when a page at "A" is moved to "A (foo)", and then the title, "A" is turned into a redirect to disambiguation page "A (bar)", the bot will fix double redirects by pointing them to "A (foo)" instead of "A (bar)". Cheers! bd2412 T 19:34, 14 July 2013 (UTC)

Another option would be to clean up the resulting double-redirects yourself when doing something like that, along with any direct links to the problematic redirect. Anomie⚔ 20:49, 14 July 2013 (UTC)
That would be great - I always do that. However, whoever moved the page in this case didn't do that, and more often than not it seems that people don't do that, leading to a scourge of bad redirects like these. bd2412 T 21:59, 14 July 2013 (UTC)
There really are two choices for the bot: it can redirect to where the redirect points now, or it can redirect to where the redirect pointed. Can you describe, even in vague terms, an algorithm which would let the bot decide which was correct?—Kww(talk) 22:33, 14 July 2013 (UTC)
I propose that the bot or bots should be instructed to see whether the potential double redirect target is a disambiguation page; if yes, then go with the previous target instead of the new one. bd2412 T 00:25, 15 July 2013 (UTC)

Missed wikinavigation with Google Chrome

I've noticed using Chrome Version 28.0.1500.72 m that in attempting navigation via the wikilink WP:SYNC, I am navigated briefly to the target subsection but that I am renavigated back to the head of the article before things settle down. Firevox version 22.0 navigates as expected. Wtmitchell (talk) (earlier Boracay Bill) 22:37, 14 July 2013 (UTC)

It works for me in the same Chrome version on Windows Vista. If a page ends up in the wrong place then try clicking in the browser address bar and press enter. If I'm already somewhere on the page and click the circular reload arrow in Chrome then I first go briefly to the section and then back to wherever I was. I don't know whether this is a normal Chrome feature. PrimeHunter (talk) 23:08, 14 July 2013 (UTC)

Visual Editor uptake: really just 2.9%?

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

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

No IE and Opera support... mabdul 22:55, 5 July 2013 (UTC)
I don't think so. IE only accounts for 18% of hits to the WikiMedia servers. Opera only 2.6%. (stats). Wikipedia may differ, but not that much. Even across all sites in the US, IE only accounts for ~30%.
Is my method right? --RA (✍) 23:09, 5 July 2013 (UTC)
Also, there is no support for back-level browsers. Also, there is no Visual Editor interface for Wikipedia space pages or talk pages. Also, existing users who are familiar with Wiki markup may just continue to use it, especially if they know that Visual Editor has bugs. Robert McClenon (talk) 23:12, 5 July 2013 (UTC)
What do you mean by "back-level browsers"?
I excluded all namespaces except Article. The stats are for edits to the Article namespace only. --RA (✍) 23:15, 5 July 2013 (UTC)
By back-level browsers, I mean versions of supported browsers where the browser version is not supported, such as Firefox 12, where the version is blacklisted because the version doesn't have features that Visual Editor requires. Robert McClenon (talk) 00:04, 6 July 2013 (UTC)
Remember those are not only for all wikimedia projects but they are also stats for page views not for edits so the stats could vary. For starters, it's resonable to expect editors use mobile browsers less. i'm currently using a tablet, an iPad but I can say it's rather annoying at times and there's no way I'd use it for major article edits. And as for a phone? Forgot it. The share is only about 20% in those figures but it still pushes IE up in genera. lI don't particularly know of any reason why IE is likely to be preferred by editors, more likely the opposite but ultimately the figures are fuzzy. And all these (including stuff below like automated edits) add up to the actual usage by editors not being that surprising. And considering the target of the editor, perhaps not bad. Nil Einne (talk) 18:17, 6 July 2013 (UTC)
I make it at 332 out of the last 5000 edits (6.6%). A similar probe a bit more than 24 hours ago had it as 11%, but that difference might have reflected a rush of early testing. As to why your number is different, I don't believe anyone can actually receive 10000 entries from recent changes. Admin and bot accounts can get 5000 entries at a time. It used to be that normal accounts had an even lower limit (though I don't remember what that limit was and haven't tested it recently). However, if you try to generate such a list look at the header, which says "Show last ... changes". If you request more than the limit, the limit value will be placed there. Dragons flight (talk) 23:16, 5 July 2013 (UTC)
Thanks for the tip. Yes, I'm limited to 5,000. But I still only see ~145 (146 now). Which is still just 2.9%
When did you do your test? Are you clicking the link above and searching for "Tag: VisualEditor"? --RA (✍) 23:26, 5 July 2013 (UTC)
I'm writing a script to do this automagically, if y'all can wait just a sec. I'm sure the WMF devs are doing something like this too (and probably in a much more hi-tech way)...right? Theopolisme (talk) 23:39, 5 July 2013 (UTC)
I just did the test and got 375/5000 = 7.1% of edits done with VisualEditor (filter by tag "visualeditor") --Patrick87 (talk) 23:40, 5 July 2013 (UTC)
I got 3.36% out of 10,000 most recent edits using the API (here's how). I'll run it over a larger sample space momentarily. Theopolisme (talk) 23:49, 5 July 2013 (UTC)
Thanks Theopolisme. You'll need to filter by name space (only article), remove anons (not rolled out yet) and bots (don't count). I suspect when you do, the manual figure of 6—7% will be right. Still, wow. That's over 90% of people not using it. . --RA (✍) 23:55, 5 July 2013 (UTC)
Gotcha. About to run with those parameters. Theopolisme (talk) 00:02, 6 July 2013 (UTC)
My post on this topic from July 3rd is here: Wikipedia:VisualEditor/Feedback/Archive 2013 07#Note on usage. It also discusses the fact the new(ish) user accounts are far more likely to use the Visual Editor than experienced accounts. (Whether because they like it or because they don't know any other way is largely impossible to know.) Dragons flight (talk) 00:09, 6 July 2013 (UTC)

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

and here's the source code Theopolisme (talk) 00:17, 6 July 2013 (UTC)
Thanks, Theopolisme. Sorry to be a pain, but does that exclude bots? Thanks for doing this. — Rannpháirtí anaithnid (00:19, 6 July 2013 (UTC)) — (continues after insertion below)
You're not a pain, I just skipped right over what you said...sorry! I've updated the above stats. Theopolisme (talk) 00:32, 6 July 2013 (UTC)
Dragon, very interesting. The pattern is to be expected but the numbers are surprising (to me anyway). Your figures from earlier would also suggest usage is dropping. I wonder if it is dropping in both user groups. IP usage next week will also be very interesting. Given what we are seeing here, I'm not sure what to expect.
"...largely impossible to know..." No it's not. You can contact them and ask. --RA (✍) 00:19, 6 July 2013 (UTC)
Updating for this morning, I see 6.4% of non-anon, non-bot article edits being made with VE. Following up on earlier stats, it appears that the uptake among editors with user pages (i.e. "experienced" editors) is 3.8% of article edits and the uptake for users without user pages (i.e. "newish" editors) is 19% of article edits. So both subgroups have declined by about a third since I first measured this on July 3rd. Regarding why new editors are using it more, I meant that it was impossible to know from the presently observable bulk statistics whether newish editors actively prefer VE or simply didn't know of other options. Of course if you want to go out and conduct a survey of new editors, then be my guest. Dragons flight (talk) 17:33, 6 July 2013 (UTC)
The statistics don't exclude edit made with AWB, Twinkle, Huggle and such like. That could increase the percentage a bit. -- John of Reading (talk) 11:14, 6 July 2013 (UTC)
Yes. Is there a reliable way we can determine those kinds of edit? --RA (✍) 13:50, 6 July 2013 (UTC)
Only by blacklisting, in a sense, edits with edit summaries that contain specific strings of characters (i.e., "HG" or "TW"). Even then it can't perfectly distinguish between automated and manual (because users have the capability to change edit summaries). TParis, doesn't X!'s edit counter tool include a list of these--and if so, could you pass it on to me? Theopolisme (talk) 13:55, 6 July 2013 (UTC)

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

I'm not entirely sure it is fair to exclude some of the semi-auto tools. If the user is making a choice to use a tool that they like better than VE, then personally I'd tend to still count that as a failure to adopt VE. If VE provided automation and tools that were preferred, then (at least in principle) some users would turn away from the other existing tools and switch to VE. (Of course, that argument is largely hypothetical at this point since VE isn't really equipped to replace any of the semi-auto tools yet.) Dragons flight (talk) 17:41, 6 July 2013 (UTC)
A reason it may be fairer to count VE edits against only manual edits is because we would then just be comparing the tool users prefer when making manual edits. i.e. ratio of Edit : EditSource edits. --RA (✍) 10:59, 7 July 2013 (UTC)

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

That makes me wonder how many VE edits were reverted. Is there a way to figure that out? I think it might also be interesting to see how many people disabled it. Last I heard it was over 500 but that was less than 24 hours after release. Its good to know that 8.6% of the edits were done with VE but I think its also important to see if they were immediately reverted due to errors. Kumioko (talk) 23:23, 6 July 2013 (UTC)
AIUI there is a huge problem with the premise that this entire topic is based on. The "Visual editor" tag is not added to the edit summaries of all edits that used VE - it is only added to those edits that the wizard "thinks" may have an errors caused by bugs in VE. Roger (Dodger67) (talk) 11:10, 7 July 2013 (UTC)
No Doger67, you're wrong. The tag you have in mind is called "visualeditor-needcheck" and is applied in addition in this case. --Patrick87 (talk) 12:49, 7 July 2013 (UTC)
Got it, thanks. Roger (Dodger67) (talk) 12:58, 7 July 2013 (UTC)
We'll need to catch that tag too. --RA (✍) 13:29, 7 July 2013 (UTC)
All the edits with visualeditor-needcheck are also tagged with visualeditor.--Salix (talk): 14:33, 7 July 2013 (UTC)

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

Expect a large increase as soon as VE is enabled on IE8, 9 & 10. Roger (Dodger67) (talk) 13:35, 7 July 2013 (UTC)
We could get an estimate from Wikimedia Traffic Analysis Report - Browsers.
Browsers, non mobile All requests Html pages
Chrome 77,011 M 35.23% 6,889 M 30.88%
MSIE 36,362 M 16.64% 3,834 M 17.19%
Firefox 28,901 M 13.22% 2,775 M 12.44%
Mozilla 9,708 M 4.44% 917 M 4.11%
Opera 5,266 M 2.41% 671 M 3.01%
Safari 4,783 M 2.19% 670 M 3.00%
Tablets 11,658 M 5.31% 916 M 4.08%
Phones 36,190 M 16.5% 3,234 M 14.4%
taking the Html pages %, and assuming its really just Chrome and Firefox who currently could use VE thats 43% of posible edits, bring MSIE in adds 17%. So might expect maybe 50% more edits with VE. Its still not going to get that much uptake.--Salix (talk): 14:33, 7 July 2013 (UTC)
Additionally, those figures combine views and edits. I suspect (without evidence) that editors (as opposed to viewers) are skewed towards non-IE browsers (amongst others). There will also be other difference, for example you could effectively knock out phones (14%) from editor stats. --RA (✍) 15:12, 7 July 2013 (UTC)
Although the numbers don't be high, but users who disabled JS for any reasons (e.g. screen-readers, paranoia, etc.) don't get VE, too. mabdul 16:53, 7 July 2013 (UTC)
Updating to now, I see 8.9% of non-anon, non-bot article edits being made with VE (up from 6.4% end of last week). Whether a statistical fluctuation or the start of an actual trend, I don't know, but it is the first time since I started checking this where the fraction of VE edits has showed a sizable increase from a prior measurement. Dragons flight (talk) 20:59, 8 July 2013 (UTC)
I enjoy getting these updates of usage trends. Perhaps there could be a subpage of Wikipedia:VisualEditor that documents this information? Or maybe just somewhere in someone's userspace. Killiondude (talk) 21:08, 8 July 2013 (UTC)
I've created a subpage of Wikipedia:User_Advocacy/VisualEditor with proposed research questions. Maybe there? --RA (✍) 07:32, 9 July 2013 (UTC)
...and I'm getting "VisualEditor was tagged in 979 out of 10000 edits, or 9.79%" when I exclude automated edits as well. Theopolisme (talk)
This morning, I count 8.4% of non-anon, non-bot article edits being made with VE. Still higher than the end of last week. Dragons flight (talk) 14:54, 9 July 2013 (UTC)
Another day later, I count 10.4% of non-anon, non-bot article edits being made with VE. Dragons flight (talk) 16:16, 10 July 2013 (UTC)
11.03% excluding automated edits. Could we store this data in a table somewhere (and ideally graph it)? Theopolisme (talk) 16:20, 10 July 2013 (UTC)
Updating again in order to add numbers by subsample. Right now, I get 9.0% of non-bot, non-anon article edits coming from VE. In addition, "newish" accounts (those without user pages) are making 22% of their article space edits with VE. "Experienced" accounts (those with user pages) are making 4.5% of their article edits with VE. That newish accounts are about 5 times as likely to use VE to edit articles has remained fairly consistent since launch. Dragons flight (talk) 19:17, 10 July 2013 (UTC)
Another day, another stat: 8.3%. Incidentally, these stats seem to bounce around a bit, probably because 5000 non-bot, non-anon edits (representing about 90 minutes of real time) isn't really a long enough baseline to avoid quirky fluctuations (such as the occasional editor who is really excited by VE). At some point I'd like to write a tool to study this more systematically. Dragons flight (talk) 17:05, 11 July 2013 (UTC)
Some stats are at http://ee-dashboard.wmflabs.org/graphs/enwiki_ve_hourly_perc_by_user_type (from File:WMF Monthly Metrics Meeting July 11, 2013.webm). --Nemo 18:20, 15 July 2013 (UTC)
That's awesome, thanks Nemo! (@Dragons flight:) Theopolisme (talk) 19:00, 15 July 2013 (UTC)

Image update not appearing

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

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

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

  • Thumbnail stuck, perhaps display 1px narrower: The previous problems have been fixed by changing the view to display, in a page, as 1-pixer-wider smaller (or taller shorter), until the auto-thumbnailing can re-cache with new image revision. Update: Even smaller custom thumbnails are still showing prior revision. Major, major bug in image display. -Wikid77 (talk) 20:12/20:32, 11 July 2013 (UTC)
I tried a 127px image on the article page, and it seems to have worked. The image page is still a bit screwy though! Periglio (talk) 21:30, 11 July 2013 (UTC)
If this is still an issue then providing the exact link to the exact size of the thumbnail that does not update would be very welcome. Right now I can just guess when it comes to reproduce the problem. :( Also see https://en.wikipedia.org/wiki/Wikipedia:Purge#For_images --AKlapper (WMF) (talk) 14:14, 15 July 2013 (UTC)

"Remove from watchlist" button

Tracked in Phabricator
Task T2424

Often I'm scrolling through my watchlist and find it is overly cluttered with articles that were once upon a time relevant but anymore, and it makes it extremely tedious to locate articles that I'm directly interested at the moment. But to alter my watchlist I have to go to the "edit watchlist" page, and then remember all the articles I wanted to get rid of, rinse and repeat.

I propose that on the Watchlist page, for each of the items, next to the "history" and "undo" "dif" buttons, there's also a "remove from watchlist" button - or something along those lines.--Coin945 (talk) 07:16, 14 July 2013 (UTC)

You could try adding the code from mw:Snippets/Unwatch from watchlist into User:Coin945/vector.js if you are still using vector, or User:Coin945/common.js if not. Personally, I have Wikipedia:Navigation popups turned on, and select "unwatch" from the "actions" menu that pops up whenever I hover my mouse over a link in the watchlist. -- John of Reading (talk) 07:46, 14 July 2013 (UTC)
I use:
// [[user:js/watchlist]]
if (wgCanonicalSpecialPageName == 'Watchlist') 
  importScript('user:js/watchlist.js');
I'm working on building my own script that uses some of the functionality of this script and also adds "add to watchlist" links on Special:Contributions as well... Anyways, happy editing! Technical 13 (talk) 11:30, 14 July 2013 (UTC)
Thankyou very much guys. I'll experiment a bit and see which one I prefer. :)--Coin945 (talk) 14:11, 14 July 2013 (UTC)
users scripts page (WP:JS) contains several scripts that help deal with watchlist. i recommend the one i wrote myself: "Watchlist mark". this script shows pages you watch with boldface in category and contribution pages (just like they already appear in recentchanges page), and also adds a little item called "Show watchlist controls" to the "contentstub" (the little something that appear under page title).
pressing "Show watchlist controls" will add a "[watch]" link after each unwatched page, and "[unwatch]" link after each watched page.
this can be useful when you want to see which pages in some category you are watching, and when you want to add (or remove) many (but not all) the pages in some category to your watchlist. it's also useful if you want to go over your (or someone else's) contributions and start watching some of the pages.
peace - קיפודנחש (aka kipod) (talk) 20:07, 14 July 2013 (UTC)

This is T2424, and it would be cool if someone technically inclined went ahead and fixed it at last. I'm myself planning to do that sometime soonish if nobody else steps up, but that would mean I'd have to get another person with permissions to merge the code to give it a final review. Matma Rex talk 15:42, 15 July 2013 (UTC)

Where is Gadgets ?

It's gone. Where is it now?  Ę-oиė  >>>  ™ 12:15, 14 July 2013 (UTC)

Whatever is happening, took out Twinkle too. --NeilN talk to me 12:19, 14 July 2013 (UTC)
  • Getting same problem, "preferences" keep resetting, and the gadget tab only appears intermittently. -- Hillbillyholiday talk 12:20, 14 July 2013 (UTC)
I am getting this too. I also can't "Rollback Vandal" and "Restore" as these are not appearing as options. I tried updating my Firefox in case this was a compatibility issue but no change **sigh**--5 albert square (talk) 12:24, 14 July 2013 (UTC)
User scripts are failing too, but no errors to track. ?debug=true restores functionality, seems to be ResourceLoader related. — Edokter (talk) — 12:26, 14 July 2013 (UTC)
Same here, I guess something is being "improved". (Hohum @) 12:27, 14 July 2013 (UTC)
Nope, just a bug. Parsoid is DoSing the API cluster, which has implications for gadgets functioning. Mark Bergsma is looking into it now. Okeyes (WMF) (talk) 12:32, 14 July 2013 (UTC)
Thanks for clearing that up Okeyes :)--5 albert square (talk) 12:34, 14 July 2013 (UTC)
  • Looks like it's not a Parsoid problem, actually - some [expletive deleted] decided to DoS the API cluster externally. Okeyes (WMF) (talk) 13:02, 14 July 2013 (UTC)

FYI, it's happened too on many others wiki. But not on my main wiki wp.min. Weird.  Ę-oиė  >>>  ™ —Preceding undated comment added 13:02, 14 July 2013 (UTC)

Someone sort this shit out and fast. Lugnuts Dick Laurent is dead 13:20, 14 July 2013 (UTC)
We are doing so. Okeyes (WMF) (talk) 13:32, 14 July 2013 (UTC)
I hope whoever made that mistake is blocked by an admin. But of course, that wont happen... Lugnuts Dick Laurent is dead 13:54, 14 July 2013 (UTC)
You...want an admin to block an external IP address that is spamming the API? An IP address admins don't have access to, and that has already been blocked from poking said API? Okeyes (WMF) (talk) 13:57, 14 July 2013 (UTC)
  • Well, in theory at least it would be possible, provided it's "just" a DoS attack and not DDoS. (Just joking...) Thomas.W talk to me 14:07, 14 July 2013 (UTC)
  • Totally, but the sysadmins have ways of making them (not) talk ;). Okeyes (WMF) (talk) 14:15, 14 July 2013 (UTC)
Is changing the time stamps to your local time part of the gadgets too because all the time stamps I'm seeing defaulted back to the (what I find annoying) 24 hour UTC format. Even when I go to the "Date and time" section in my preferences and change the time zone, it still doesn't work. Please fix what ever is happening fast!.--Dom497 (talk) 13:59, 14 July 2013 (UTC)
The developers are working as fast as they can (and, yes. In reverse order.) Okeyes (WMF) (talk) 14:02, 14 July 2013 (UTC)

Visual Editor exhumes itself and forces itself on me

Moments ago, while I was editing an article using the editing tool that works properly, the properly-disabled mess misnamed Visual Editor restored itself as my default editing tool. It seems to have been returned to its well-deserved grave after I resaved my "gadget" preferences, but why should any editor have to watch out for this dysfunction to recur? Hullaballoo Wolfowitz (talk) 12:59, 14 July 2013 (UTC)

See the section immediately above this; some [expletive deleted] decided to DoS the API cluster, impacting gadgets. Okeyes (WMF) (talk) 13:01, 14 July 2013 (UTC)
Its because the WMF is too lazy to implement an actual off switch for such a PoS that we are forced to hack a JavaScript off button, which really doesn't turn it off (because you cant) and thus any issues with JavaScript or the resource loader causes issues. Werieth (talk) 13:05, 14 July 2013 (UTC)
And it's restored itself again, and my ability to remove it has been disabled. When I enter the "Gadgets" panel (that is, when it hasn't been disabled without warning), I get a message that individual editors must take responsibility for use of those features. Obviously some people aren't properly taking responsibility for what they're doing. Hullaballoo Wolfowitz (talk) 13:28, 14 July 2013 (UTC)
That's almost always existed. Again, we're working to fix the bug, which is not VE-specific. Okeyes (WMF) (talk) 13:32, 14 July 2013 (UTC)
And when "Gadgets" came back, "Remove VisualEditor from the user interface" had been unchecked"! That's certainly a VE-specific error. Hullaballoo Wolfowitz (talk) 13:45, 14 July 2013 (UTC)
That would be, yes, if it's what's happening - but gadgets are appearing intermittently, unreliably, and I have no idea how much what is loaded can actually be trusted. Could be that the VE box is unticked, in which case you're the only person to report it. Could be the gadgets page isn't displaying a user's personalised settings. Okeyes (WMF) (talk) 13:51, 14 July 2013 (UTC)
No, it is not. The gadget is not related to VisualEditor in any way. It is merely a community-based script to hide the VE buttons. The current DDoS attack also has no relation to VE whatsoever; only gadgets and userscripts are affected as collateral damage from that attack. So hijacking this subject to spew against VE is absolutely pointless. — Edokter (talk) — 13:56, 14 July 2013 (UTC)
  • I had the same issue, which I also noticed after VE reared its ugly head. It hasn't resurfaced though, although I should note that at first Gadgets did not load for me. I had to reload preferences. — Crisco 1492 (talk) 14:05, 14 July 2013 (UTC)
  • Please write any data about the attacker you can disclose. --Синкретик (talk) 13:59, 14 July 2013 (UTC)
    I have zero non-aggregate data, and even if I did I'd disclose none of it. Okeyes (WMF) (talk) 14:01, 14 July 2013 (UTC)
    Why? To divulge an IP address is not libel. --Синкретик (talk) 14:04, 14 July 2013 (UTC)
    No, but divulging an IP address from server logs is a colossal violation of our privacy policy. Okeyes (WMF) (talk) 14:14, 14 July 2013 (UTC)
  • Are you going to sue the attacker? --Синкретик (talk) 14:16, 14 July 2013 (UTC)
    I am not legal counsel for the Foundation and have absolutely no idea. At the moment our focus is on fixing the damage. Okeyes (WMF) (talk) 14:18, 14 July 2013 (UTC)
    May I start a discussion on WP:Village pump (proposals) about actions against the attacker? --Синкретик (talk) 14:33, 14 July 2013 (UTC)
    Strictly speaking, I cannot stop you, but my advice would be that it would be a complete waste of time. Our legal or operations teams are not driven by community consensus, and the chances of us releasing the information are....infinitesimally small. Frankly, nothing's going to happen on that front that is community driven, and I have no idea what will happen at the Foundation end, particularly since a software bug and a DoS look identical in such circumstances. Okeyes (WMF) (talk) 14:35, 14 July 2013 (UTC)
    Okeyes is correct in this isntance. WMF is responsible for the infrastructure, and response to an attack on it will have to come from the Foundation, and I think it unlikely that they won't at least contact the originating ISP(s). There's nothing the Wikipedia community can do except frown at these shenanegans. Resolute 15:09, 14 July 2013 (UTC)

There is actually a proper off switch for VE. It was chosen to disable the off switch for en:wp, and instead have a half-hidden option that breaks every now and then. Enabling the off switch is apparently an "enhancement". The patch is awaiting deployment. Anyone from WMF have an idea if/when this change will go through? - David Gerard (talk) 14:17, 14 July 2013 (UTC)

I do not know; that's a question for those with +2 rights. Okeyes (WMF) (talk) 14:27, 14 July 2013 (UTC)

Question Is the method of disabling the VE broken as of right now? I have checked both the editing preferences and the Gadget "Remove VisualEditor from the user interface", but I still get the edit and edit source links - but only after a delay so that when I clicked what I *thought* was the edit link I was confronted with a long pause and no edit window. Please, provide a means to permanently disable VE for me. Put my username in a "never use VE" list if necessary. -84user (talk) 14:32, 14 July 2013 (UTC)

Could I respectfully request that WMF make it a priority to allow us who do not with to deal with VE at this time to truly place a stake through its heart? I am not opposed to the idea of using it at some future date, I am just too busy with writing and other work to be a guinea pig.--Wehwalt (talk) 14:57, 14 July 2013 (UTC)
84user, it should now be working again. As said, there was a bug around gadgets. If it still doesn't disappear, try clearing your cache. Okeyes (WMF) (talk) 15:07, 14 July 2013 (UTC)
Simple solution — just start using IE like I always do. I'm mildly interested in trying VE, but not so interested that I'd force myself to use Firefox. Nyttend (talk) 17:14, 14 July 2013 (UTC)

What happened?

Okeyes, you seem to be saying that this was caused by a "DOS" of the "API clusters" but you also seem to be saying that there is a bug. Can you clarify if the cause of today's problems was caused by a bug or by the issues with the "API clusters" or by both? Thanks. Delicious carbuncle (talk) 17:22, 14 July 2013 (UTC)

And a possibly more important question - would readers of WP been affected by this? Delicious carbuncle (talk) 17:23, 14 July 2013 (UTC)
It looks like a combination of delayed Parsoid jobs and a poke at the APIs from an external source caused swap death. Readers would not have been affected, to my knowledge, except for those who read logged-in with a gadget-dependent UI (if those exist). Okeyes (WMF) (talk) 13:15, 15 July 2013 (UTC)
For the records, also see patch in https://gerrit.wikimedia.org/r/#/c/73617/ and related https://bugzilla.wikimedia.org/show_bug.cgi?id=51317 --AKlapper (WMF) (talk) 14:23, 15 July 2013 (UTC)
Thanks for the updates. Delicious carbuncle (talk) 15:00, 15 July 2013 (UTC)

User:Cacycle/wikEdDiff

Is anyone else having trouble with the "improved diff" feature (User:Cacycle/wikEdDiff)? I've tried it at Vince Carter and Allen Iverson, and everything is highlighted in red, as if everything on the page had been deleted (though that's not the case). Thanks! Zagalejo^^^ 02:18, 15 July 2013 (UTC)

It worked correctly in my tests. Please post a specific diff where you see the problem. What is your browser and skin? PrimeHunter (talk) 12:09, 15 July 2013 (UTC)
see, e.g., This diff. with chrome 28.0.1500.72, pressing the wikeddiff button shows the whole article in red (maroon?) in the wikeddiff box. with ff 22.0 _and_ IE 10, the "wikeddiff" box has all "normal" text - nothing in red and nothing in green. ie10 in "compatibility mode" shows the wikeddiff box completely empty (except maybe an ellipsis or something). the actual edit removed some superfluous newline characters, i believe. peace - קיפודנחש (aka kipod) (talk) 15:48, 15 July 2013 (UTC)
My tests were in Firefox. I have tried Chrome 28.0.1500.72 now and see the described problem except there is the green text "undefined" after all the red. I examined the page history and it seems to have started in [34]. That and all later tested diffs have the problem. None of the earlier tested diffs have it. I have posted to User talk:Cacycle/wikEdDiff. PrimeHunter (talk) 22:18, 15 July 2013 (UTC)
An example diff is [35]. And yes, I do see the green "undefined". I'm using Chrome. Zagalejo^^^ 04:25, 16 July 2013 (UTC)
note that even though the problem is most noticeable with chrome, none of the other browsers shows the diff i linked to correctly (i.e., none of them indicated the removed whitespaces, as wikeddiff normally does). peace - — Preceding unsigned comment added by קיפודנחש (talk • contribs) 15:36, 17 July 2013 (UTC)

Email throttling

How is the email throttling configured on en Wikipedia? I found Manual:Edit throttling at mediawiki.org, but I can't find the details for en wiki. How many emails can an editor send before this triggers, and how long will he be blocked from emailing one this happens? Is it different among different editor classes, or is it the same for all? --Piotr Konieczny aka Prokonsul Piotrus| reply here 21:57, 15 July 2013 (UTC)

You're looking for InitialiseSettings.php, ctrl+f for "wgRateLimits." ^demon[omg plz] 01:42, 16 July 2013 (UTC)

Article disrupted?

Resolved
 – thanks. -DePiep (talk) 06:19, 16 July 2013 (UTC)

Anyone else seeing a disrupted page Jerusalem, this current version? I see: below the two hatnotes (OK), the infobox starts wide (out of screen), all boxes and images are vertically sequential, and there are a few lines of text unwrapped and very wide. The Edit Source preview does the same, and opening Edit (VE) shows the same, then showing a warning "Unresponsive script" while loading. -DePiep (talk) 05:50, 16 July 2013 (UTC)

I'm seeing the disruption - Firefox 22. -- John of Reading (talk) 05:54, 16 July 2013 (UTC)
Fixed it - there was a </div> missing. -- John of Reading (talk) 05:58, 16 July 2013 (UTC)

Template:Infobox football biography

Hello. I need your help with the Template:Infobox football biography. I use this template in greek wikipedia. I know that wanting help for a foreing wikipedia isn't so appropriate but noone could help me in greek wikipedia.

In the template there is a parameters like {{#ifeq:{{{number|♠}}}|♠||[[Category:Football biography using missing parameters|#]]}}. I want to do the same about the parameters clubs1, clubs2 etc. In this parameters we used a template for teams calling Football teams. I want, if one or more parameters of clubs1, clubs2, clubs3 are using, if they don't have the template Football teams, then will categorize in a certain cateroty.

For example,

  • |clubs1={{Football teams|Arsenal F.C.}}
  • |clubs2={{Football teams|Manchester United F.C.}}
  • |clubs3=Chelsea F.C.

would categorized because in clubs3 the Football teams template in not used. Xaris333 (talk) 22:32, 14 July 2013 (UTC)

Anyone??? Xaris333 (talk) 17:41, 15 July 2013 (UTC)

You may be able to use the {{Str left}} function, if it is available, to check that the first 2 characters of the parameter are {{. Keith D (talk) 23:45, 15 July 2013 (UTC)
That won't work, because templates are processed from inside to outside - the arguments of the {{str left}} will be evaluated before the two characters are determined, by which time they certainly won't be{{ even if they started like that. No, this would have to be a Lua job - you can't do it in Wikicode. --Redrose64 (talk) 07:15, 16 July 2013 (UTC)
I guess you could modify {{Football teams}} to return something specific which doesn't influence rendering at the start, and then test for presense of that. The presense wouldn't guarantee that {{Football teams}} was used but it would be a good indication. PrimeHunter (talk) 11:39, 16 July 2013 (UTC)

Small request for bot/script to replace "language=ru" with "language=Russian"

I don't know where to post this, but the Village Pump seemed like a decent place to start. If this is the wrong place, feel free to move it, and don't thwack me with anything too substantial.

I have been correcting errors in citations, and I have noticed that pretty much every Russia-related article I edit contains an incorrectly formatted parameter, "language=ru", in its citation parameters. (The "language" parameter takes the full language name, not the two-letter code.)

You can see an example of one of these citations here. Note that the rendered reference says "(in ru)" instead of the correct "(in Russian)".

It occurred to me that someone clever with a script or bot or similar creature might be able to do a semi-automated find and replace of "language=ru" in citations with "language=Russian".

Is this a good place to request such a thing? I do not have the time or skills to take on such a project myself. Thanks. Jonesey95 (talk) 00:05, 16 July 2013 (UTC)

I'd try WP:BOTREQ; it's possible that other ISO language names might need to be converted, as well. — Arthur Rubin (talk) 00:43, 16 July 2013 (UTC)
Have you considered letting the parameter be an ISO code or language name? It might help to only have one spelling in cases like Tuvan vs. Tyvan. πr2 (t • c) 02:59, 16 July 2013 (UTC)
Seeing if we can make Citations support ISO codes in addition to Language names has been on my to do list for a while. I think it is possible, though there are a few complexities and I haven't had time to work through it. Dragons flight (talk) 05:59, 16 July 2013 (UTC)
mw:Extension:Scribunto/Lua reference manual#Language library shows a number of language functions. It might be better to create a separate module that would take either the code or full name as inputs and output both the code and full name as separate values that could be read by another module. --  Gadget850 talk 11:25, 16 July 2013 (UTC)
That would be much better, and would allow "lang" and "hreflang" parameters to be set accordingly. It done in Lua, it's possible that either type of value could be accepted. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:26, 16 July 2013 (UTC)
How would you use hreflang? --  Gadget850 talk 10:48, 16 July 2013 (UTC)
AIUI, Bugzilla has a ticket 824245 and a patch to enable that, though not yet deployed here. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:02, 16 July 2013 (UTC)
That bug does not exist. I see T26742 which has an old patch. --  Gadget850 talk 20:46, 16 July 2013 (UTC)

I have reposted this request at WP:BOTREQ. Thanks for the advice. Allowing the citation template to use the two-letter code would be an elegant option; right now the best option that uses the two-letter code is adding the {{Language icon}} template (rendered like this: (in English)) after closing the citation braces but before closing the ref tag. Jonesey95 (talk) 14:20, 16 July 2013 (UTC)

{{Language icon}} does nothing for the citation elements. There is already a feature request to add the proper language markup to titles where 'language' is set. --  Gadget850 talk 16:36, 16 July 2013 (UTC)

Moving "superseded" IfD discussions to its own list?

I have found that many helpful people have converted some of the hoary old GIFs I've uploaded over the years into the shiny new PNG format. When this happens, the older GIF sort of hangs around for a while before being put on the deletion lists. When this happens, I get a scary-looking YOU WILL BE DELETED!!!! message on my talk page (in spite of the no-robots flag?!), when in reality this is a very minor bookkeeping operation.

So is there any reason we shouldn't split off the "images deleted because there's a newer version" to an entirely separate list? It would see this would greatly simplify matters for all involved.

Maury Markowitz (talk) 20:40, 16 July 2013 (UTC)

VE Problems

Magnification

Tracked in Phabricator
Task T52541
Here is what it looks like at 125%

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

I saw this behavior briefly in Chrome but was unable to reproduce it consistently in either Chrome or Firefox Cmcmahon(WMF) (talk) 00:17, 2 July 2013 (UTC)
Maybe you could look at the accompanying image. I am getting this behaviour consistently. -- Diannaa (talk) 00:24, 2 July 2013 (UTC)
Hi Diannaa, I see the problem you're referring to, but I'm also having a problem reproducing the issue on my machine. A few things that would be helpful:
* Version of Chrome you're using
* Which page you're editing
* Exact sequence of events to get to the screen you're looking at
* Any gadgets or user javascript you might have installed
Also, if there are other people here who see the same thing, that would also be helpful information. Thanks! -- RobLa-WMF (talk) 00:31, 2 July 2013 (UTC)
Nevermind, we just figured it out. It's a matter of scrolling down the page a little bit before bringing up a dialog. -- RobLa-WMF (talk) 00:35, 2 July 2013 (UTC)
Thank you for reporting this, I have noted it in our bug tracking system. Cmcmahon(WMF) (talk) 00:44, 2 July 2013 (UTC)
For the record, at my default zoom I see this issue routinely as well. Dragons flight (talk) 02:03, 2 July 2013 (UTC)
The bug has been closed, and appears fixed for me. John Vandenberg (chat) 02:37, 16 July 2013 (UTC)

Adding references

It is amazing how good the old reference tool is. Seconds to teach someone how to use it

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

I've been using the template button (the puzzle piece one) to access the cite templates, which works. There has been some demand for a ref toolbar-like functionality for the reference button in VE - there seems to be some cross-wiki compatibility issues (not all wikis support the cite temps) that make it difficult. It would be a desirable improvement if it's at all possible, I'll check the enhancement requests ... PEarley (WMF) (talk) 00:51, 2 July 2013 (UTC)
It requires many many clicks. It does not fill in all the details based on the PMID (there is no autofill button). Of the 50 or so language of Wikipedia I have looked at only one does not support it and that was Polish. They did this so that people cannot do translation easily, but that is another issue. I have been unable to properly fill out a single reference with the VE based on a PMID. Is there a page of instructions? It is definitely not intuitive, at least not for me. Doc James (talk · contribs · email) (if I write on your page reply on mine) 01:18, 2 July 2013 (UTC)
So does this mean references are free form now? That we no longer have a guiding structure for people to work with? Doc James (talk · contribs · email) (if I write on your page reply on mine) 01:29, 2 July 2013 (UTC)
I'm with ya. The developers know of this concern, and are working on improvements. This is the bug report on the topic. PEarley (WMF) (talk) 01:51, 2 July 2013 (UTC)
But why is this being rolled out before this is fixed? This is essential. A VE that does not make it easy to add references is useless. Doc James (talk · contribs · email) (if I write on your page reply on mine) 10:50, 2 July 2013 (UTC)
Anyway am going to turn VE off. I people could let me know when auto fill of ISBNs and PMIDs is supported again will give it another try.Doc James (talk · contribs · email) (if I write on your page reply on mine) 02:52, 3 July 2013 (UTC)

Using the VE twice in a row

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

I had this problem as well. -- Diannaa (talk) 00:25, 2 July 2013 (UTC)
I've only had the problem when transcluding templates. Under what circumstances did you encounter it? --Maggie Dennis (WMF) (talk) 00:32, 2 July 2013 (UTC)
Just now, I tried to edit Treasure (Bruno Mars song) to correct an error a new person made with the Visual Editor. When I try a second time in a new window, the problem did not recur. -- Diannaa (talk) 00:41, 2 July 2013 (UTC)
I just reproduced it in my sandbox. Word on the street is that it's a caching issue. If it persists, I'll make a bug report (if Maggie hasn't already). PEarley (WMF) (talk) 00:45, 2 July 2013 (UTC)
It's a known issue. →AzaToth 01:54, 2 July 2013 (UTC)
Tracked in Phabricator
Task T52441
This has been fixed. John Vandenberg (chat) 01:50, 16 July 2013 (UTC)

Edit notice

Tracked in Phabricator
Task T52545

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

This is being tracked. PEarley (WMF) (talk) 03:59, 2 July 2013 (UTC)
Bug closed, however this problem is still reproducible with the link editor dialog. John Vandenberg (chat) 02:06, 16 July 2013 (UTC)

Editing fully protected pages

Tracked in Phabricator
Task T52415

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

This too. PEarley (WMF) (talk) 04:03, 2 July 2013 (UTC)
This one has been fixed. John Vandenberg (chat) 01:51, 16 July 2013 (UTC)
However there are two lower priority regressions outstanding: Bugzilla:51215 & Bugzilla:50783. John Vandenberg (chat) 01:54, 16 July 2013 (UTC)

Blacklist + Gadget = Bad Things?

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

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

Add a code editor to the template editor

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

This is related to the TemplateData issue, described here: Wikipedia:VisualEditor/TemplateData. If TemplateData has been added, the parameters are listed on the left of the dialog, making life much more pleasant. PEarley (WMF) (talk) 04:07, 2 July 2013 (UTC)
Clicking on ten different side items is still a slow and annoying way to enter a template (not helped by the fact citation templates support dozens of parameters). More significantly, none of the citation templates I tried actually showed parameter lists even though they already have TemplateData on their pages. So that feature does not appear to be working. Dragons flight (talk) 04:16, 2 July 2013 (UTC)
Hmm, you're right. Just tried "cite book", and no parameter list despite the presence of TemplateData. I'll look into this ... PEarley (WMF) (talk) 04:23, 2 July 2013 (UTC)

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

Tracked in Phabricator
Task T52120

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

Wasn't your fault, see bug above. It added WP:Persondata, which is useful metadata. But it shouldn't be adding it without being asked to. PEarley (WMF) (talk) 04:15, 2 July 2013 (UTC)
This happens quite a lot, e.g. here and other occasions today. Fram (talk) 14:16, 3 July 2013 (UTC)

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

This was a difficult bug to track down, but I'm happy to report that it is now fixed. --GWicke (talk) 03:47, 12 July 2013 (UTC)
Thanks! I haven't found any new ones with this problem anymore, but it's still early days. If it does reappear, I'll drop a note here. Assuming I can find it, that is, as it seems that the VE edittag has been removed, making it a lot harder (or nearly impossible) to track VE bugs of course. Isn't it a bit premature to remove that tag? Or is there another way to find VE edits easily? Fram (talk) 07:42, 12 July 2013 (UTC)
This seems to have indeed been fixed, no new examples are appearing, so thanks. Fram (talk) 12:39, 16 July 2013 (UTC)

Turning a page into a redirect

Tracked in Phabricator
Task T49328

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

Can't be done (yet). Creating and editing redirects is on the list of improvements for "soon" (but I believe that it's on the list to be done after some of the critical improvements to references). Whatamidoing (WMF) (talk) 08:50, 2 July 2013 (UTC)
Editing redirects isn't that urgent, you don't get the option to use VE there so you can't do it wrong. But creating redirects is more urgent, since there the VE option is standard, but it doesn't work for this. But thanks for the swift reply. Fram (talk) 08:54, 2 July 2013 (UTC)
I've added a note to the closest related existing bug, just to make sure this doesn't get overlooked accidentally. Whatamidoing (WMF) (talk) 09:06, 2 July 2013 (UTC)

Get the user interface right

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

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

UI improvements, in terms of both quality and performance, is an important area for us, I know, and there are bugs in place for dealing with things like the slow loading times and the sheer size (as well as UI tweaks). I can't speak for the developers here (and frankly I'm not technical enough to comment directly - I write in R, and that's it), but I remember that with AFT5, when we tried to use PHP to make these kind of UI elements we ended up with one hell of a caching problem. Okeyes (WMF) (talk) 10:22, 2 July 2013 (UTC)
Can you explain what you mean by the wikitext editor not being as usable as it was before? I haven't seen any reports that anything has changed with it, other than the label being "edit source". Whatamidoing (WMF) (talk) 10:30, 2 July 2013 (UTC)
  • I have to first hover over section edit links before being able to reach the same functionality than I did before (see for example bugzilla:50540).
  • On page load it takes significant time until all buttons are available / replaced by Visual editor (see e.g. bugzilla:50542).
  • "Edit" has a different meanings in different namespaces sometimes starting VisualEditor and sometimes the Wikitext editor making it hard to find the link one actually wants (see bugzilla:50402).
  • Incompatibilities caused by the much more complex code needed for all the VisualEditor "features" (e.g. bugzilla:50405). VE might have been coded having usability for new user and style in mind, but not usability for power users and code stability/compatibility.
Those are the things I find most annoying right now (besides the still unusable VisualEditor we're forced to betatest). --Patrick87 (talk) 12:01, 2 July 2013 (UTC)
Thanks for the explanation. It is helpful to know what you meant. Whatamidoing (WMF) (talk) 08:55, 3 July 2013 (UTC)

Nowiki

Tracked in Phabricator
Task T51820
Tracked in Phabricator
Task T51686

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

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

I think someone at the WMF said something like "It's not a bug; it's a feature!" on that. πr2 (t • c) 13:12, 3 July 2013 (UTC)
Probably, but it's a feature that's not only unwanted but actually harmful. Things like this and this actually create errors, and I still haven't seen a single edit where this behaviour was actually wanted (there are bound to be one or two where it works as designed, but that's like having an airbag that deploys every time you brake; sometimes it will be useful, but...). Fram (talk) 13:22, 3 July 2013 (UTC)
I think this is under discussion, but at this point VE assumes that if you put markup directly into it, you are wanting to talk about it rather than use it - from what I understand, developers are being encouraged to add a note or warning so that experienced editors don't make this mistake. (I'll look for the ticket number.) Obviously, newcomers aren't making it because they don't know the markup to begin with. --Maggie Dennis (WMF) (talk) 13:44, 3 July 2013 (UTC)
Found it. :) Tracking number added. --Maggie Dennis (WMF) (talk) 13:47, 3 July 2013 (UTC)
VE is only enabled in mainspace and userspace. It's rare in userspace and very rare in mainspace to talk about wiki markup. I wouldn't be surprised if more than 99% of VE nowiki additions in mainspace are errors. PrimeHunter (talk) 14:01, 3 July 2013 (UTC)
Agreed with PrimeHunter, and disagree with the bugzilla solution: a warning isn't sufficient, this is simply obnoxious behaviour by the software. "Warning: the software isn't going to allow you to do something useful for no good reason at all, please try another method to achieve this" is better than what we have now, but that's about the best I can say about it. It's too soon to tell whether truly new editors will have the same problem, but very recent ones certainly have this problem[42]Fram (talk) 14:27, 3 July 2013 (UTC)
Note: A warning may be easier to implement, but there's also another feature request (bugzilla:49686) about automatically converting such wikitext. guillom 14:32, 3 July 2013 (UTC)

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

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

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

This one as well, so it's not really an exceptional occurrence. Fram (talk) 09:16, 4 July 2013 (UTC)
Hi Fram, thanks for the reports and the links to the diffs which is quite helpful to see what is going on. The <nowiki/> added there is to prevent link-trails since the user only selected part of a word and linked it. This could be addressed by warning the user when a part of a word is being linked, but these kind of nowiki-markups are far fewer in number. The majority of nowikis being added which is the cause of a lot of anguish are the ones added around literal wikimarkup for links (which is being discussed in a couple of different bug reports), and those kind of errors are highly unlikely to be done by newcomers. This is not to indicate that your concerns are not legitimate, but just a clarification about different scenarios where nowikis get inserted. To summarize, these kind of nowikis you point out are not very common. Ssastry (talk) 22:33, 11 July 2013 (UTC)
I'm not convinced that new editors don't have these nowiki problems, e.g. this terrible edit is fulled with nowikis, and is being made by a brand new editor (may have been an IP editor, or a sock, of course). Fram (talk) 08:04, 12 July 2013 (UTC)
To support Fram remark, Filter 550 is rather showing that the nowikis tags are added by many users without a user page, so probably by many new editors. So it's really not a problem limited to experienced users. --NicoV (Talk on frwiki) 08:09, 12 July 2013 (UTC)
Another example of new editor with nowiki problems[44]. Fram (talk) 14:30, 12 July 2013 (UTC)

My two penn'orth. I've lost count of how many pages I've corrected where the error was entirely due to the insertion of some sort of <nowiki></nowiki> tag. This has to be the most absurd "feature" sprung on people. I can't imagine too there being any use for such in a main page, only in meta pages like these which discuss problems with markup. It needs to be removed pdq or sooner. 05:29, 13 July 2013 (UTC) — Preceding unsigned comment added by Johnmperry (talk • contribs)

The devs are working on this right now. It sounds like "have it completely fixed by the next update" is unlikely, but they are hoping to at least reduce the number of nowiki problems soon. Whatamidoing (WMF) (talk) 01:26, 14 July 2013 (UTC)
Actually it looks like we'll have a system in place by/on Monday - before the deployment, certainly. Okeyes (WMF) (talk) 01:33, 14 July 2013 (UTC)
To clarify: I've not been promised that the fix they're working on now will completely solve every single permutation of this problem. But we can expect a significant improvement, even if it might fall short of 100%. Whatamidoing (WMF) (talk) 22:37, 14 July 2013 (UTC)
Typing some wikitext (including '[[', but not ']]') now causes a warning to appear where the save button is. All related bugs closed. Everyone happy now? ;-) John Vandenberg (chat) 03:58, 16 July 2013 (UTC)
Apparently not. But they're working on it. Ignatzmice•talk 04:13, 16 July 2013 (UTC)

The warning clearly isn't sufficient (and even so, very frustrating to get this kind of thing after you have finished editing). New nowiki errors are being created constantly, forcing editors to use the old "edit source" anyway (or giving up in frustration or incomprehension). While a warning is better than no warning, I would like to hear from the devs (or other WMF people) whether they are at least considering disabling the "nowiki" addition for double square brackets; this would solve the vast, vast majority of errors, with very few false positives (the wanted additions of nowiki seem to be nearly always around pipe signs, and occasionally for single square brackets or other markup). Fram (talk) 12:33, 17 July 2013 (UTC)

Template {{tl}} invisible in VE editscreen

Tracked in Phabricator
Task T52704

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

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

Removal before a footnote alters downkey effect

Tracked in Phabricator
Task T52726

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

1. Initial text: Some statement. Bad text.[2].
2. Delete " Bad text." in VE (I used backspace from the period leftwards). Now
When the cursor sits at: Some statement.|[2].
3. Pres ↓. Cursor jumps to bottom of page.

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

Update (silly me): It disfunctions without the deletion. Just place the cursor next to a fotnote. Adding: key ↑ has similar effect (upward). -DePiep (talk) 05:38, 4 July 2013 (UTC)
@DePiep: what browser and version of the browser were you using ? I don't see this problem on Safari 6. —TheDJ (talk • contribs) 08:17, 4 July 2013 (UTC)
Firefox 21.0 atop WinXP. -DePiep (talk) 08:20, 4 July 2013 (UTC)
Confirmed in FF 20 on MountainLion. Reported —TheDJ (talk • contribs) 08:36, 4 July 2013 (UTC)
Just noting, its not fixed yet. John Vandenberg (chat) 05:06, 16 July 2013 (UTC)

Keyboard shortcut fail

Tracked in Phabricator
Task T52725

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

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

One simple typo, nine steps to correct it

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

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

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

I know that complex templates are a pain right now. When the TemplateData gets added (and processed: the system's got a huge stack of these jobs to process), you won't have any need to add them manually at all, which will dramatically reduce the likelihood of anyone introducing typos, non-existent parameters, or similar problems. I think you can expect this problem to be one that essentially solves itself before long. In between now and then, I agree that it's clunky. Whatamidoing (WMF) (talk) 11:53, 4 July 2013 (UTC)
Just checked Wikipedia:VisualEditor/TemplateData, and the example there isn't convincing at all, since the bottom image (the one with TemplateData) is essentially largely what I saw when trying to correct the errors. I'll reserve judgment on whether this will really improve things until the moment that it is supposed to be live. Fram (talk) 12:21, 4 July 2013 (UTC)

Headers inside wikitables

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

Something similar appears to have happened here. —Bruce1eetalk 12:05, 4 July 2013 (UTC)
I'm not convinced that bog-for-bug compatibility is the goal. If you want to display five tables separated by section headings, then I it is reasonable enough for you to create five tables separated by section headings, not one table that uses section headings to break it up. Whatamidoing (WMF) (talk) 13:55, 4 July 2013 (UTC)
But why did VE decide to move them outside the tables? Can you give some examples, some actual edits, where this behaviour has improved the article? I haven't seen any, but despite looking at many VE edits, I haven't seen (or corrected) them all. If there are no reasonable situations where this VE behaviour actually improves the article, then the functionality should be removed (altered), no matter how you think about the way these wikitables are built. It worked, after VE it doesn't work, so at least there has to be a convincing reason why VE does this, i.e. situations (preferably reasonably common situations) where this VE action is truly desirable and an improvement. Fram (talk) 14:12, 4 July 2013 (UTC)
They're working on it. As I understand it, wikicode gets translated into HTML to display the article on your screen when you read it (of course) and when you're using VisualEditor. If the HTML is seriously broken (e.g., in the Criss article), then VisualEditor tries to repair it so that it can display it properly. Usually, this means closing tables that are missing the close-table code. In this instance, it was clearly trying to fix the busted wikicode for the tables, but failed.
Do you know if this "style" used in other articles? It doesn't make sense to code around an improper format used in a single article: the article should just get fixed to use the normal wikicode for displaying five tables. But if this is common, then I could suggest it be considered. Whatamidoing (WMF) (talk) 14:25, 4 July 2013 (UTC)
Considering that it was also used in the article Bruce1ee linked to above in this section, it seems unlikely that the only two articles to use this format have been edited with VE just recently. Fram (talk) 14:35, 4 July 2013 (UTC)
It's not an improper format. A table cell is a td element, which may contain any flow content. A heading element may appear where flow content is expected. Therefore, tables may contain section headings. --Redrose64 (talk) 15:14, 4 July 2013 (UTC)
In Fram's example, they're using section headings to split one table into five. This isn't one table that happens to contain five section headings; it's five separate tables created out of the code for one table. It seems to me that if you want five tables to appear on a page, then you should actually make five tables, i.e., put five {| |} pairs on the page, rather than putting the wikicode for one large table on the page and using section headings to split that table into five separate tables (which is what happens when Mediawiki tries to turn this "one" table into HTML). Whatamidoing (WMF) (talk) 20:36, 4 July 2013 (UTC)
Neither Redrose64's nor Whatamidoing's analysis here is correct. In revision 562814845, and for that matter in revision 560634872, there are clearly five tables, but the headings are not within table cells (they are effectively within the <table> tag). The wikitext is generating improperly nested HTML in that it has the section headings are not within table cells, and Tidy winds up moving them above the tables. But VisualEditor's mangling of the wikitext is in no way appropriate behavior. While round-tripping the badly nested wikitext may not be feasible or desired, at the very least it should have moved rather than duplicated the headers and should have inserted linebreaks between the newly-inserted headers and the "{|" to start the tables. Anomie⚔ 23:58, 4 July 2013 (UTC)
You're right, I wasn't looking carefully. The heading elements were indeed between the {| and the |- and so were interposed between the table element and the first tr element. Most browsers will eject these out of the table: the table element may only directly enclose a small selection of other elements; these include the tr element, which may itself only enclose td and th elements, so the minimum hierarchy to get a heading inside a table and still be valid HTML is <table><tr><td><h3>...</h3></td></tr></table> --Redrose64 (talk) 08:35, 5 July 2013 (UTC)

Adds ./ inside square brackets

Tracked in Phabricator
Task T52720

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

here is another example of the same, again with a piped link with disambiguator. Fram (talk) 08:03, 5 July 2013 (UTC)
Yep, a firefox 13/14 problem; we've temporarily blacklisted those browsers. Okeyes (WMF) (talk) 13:12, 12 July 2013 (UTC)
Thanks. I'll report back if I find any new instances of this problem. Fram (talk) 13:14, 12 July 2013 (UTC)

Random shit with tables

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

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

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

The only thread I see in common with these is that all of them involve tables (including infoboxes that get rendered as tables). Do you think it might be related to T51823? Whatamidoing (WMF) (talk) 19:41, 5 July 2013 (UTC)
Might be, I don't see a pattern yet. I've also noticed more infoboxes being removed than I would consider to be normal, but it is hard to blame this on VE with any certainty, it may be that editors do it on purpose. I'll post more examples when I find them (although I'm getting rather tired of spending my days chasing and reverting VE errors). Fram (talk) 08:06, 8 July 2013 (UTC)

Moving images

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

To be fair, the Wikitext editor allows images to be placed mid-sentence... that is, I can't find evidence of VE being used to make this edit. --Redrose64 (talk) 16:36, 10 July 2013 (UTC)
Yes, it is allowed with the old editor as well, but you had to do it on purpose. Now, you can move images to the middle of words without any intention of doing this, just wanting to move an image between section is very hard. No idea why a manual move is allowed but no means are given to accurately position it. Fram (talk) 07:45, 12 July 2013 (UTC)

Not just moving images, also inserting new ones; [49]. Fram (talk) 12:24, 17 July 2013 (UTC)

Infobox mangling

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

It appears only editing the infobox itself causes this - simply editing the page in VisualEditor seems not to, as evidenced by this VE diff. - The Bushranger One ping only 00:51, 11 July 2013 (UTC)
It could potentially change how the infobox displays, if it contains something where newlines are critical - such as a bulleted list, as used in the |guests= parameter of {{Infobox Doctor Who episode}} - e.g. An Unearthly Child. --Redrose64 (talk) 06:11, 11 July 2013 (UTC)

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

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

Italicizing wikilinks

Tracked in Phabricator
Task T53422

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

I can reproduce that[50], and IMO that is a bug as it is emitting wikitext that is going to annoy the shit out of the wikignomes and page curators, and will result in bots being created to clean up after VE contributors (and the bots will get it wrong and further annoy the crap out of the ... etc etc). John Vandenberg (chat) 04:42, 16 July 2013 (UTC)
Bug filed, thanks. Jalexander--WMF 04:59, 16 July 2013 (UTC)

VE totally screwing up

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

  • [51] turns paragraphs into headers after the removal of an image Fram (talk) 13:56, 12 July 2013 (UTC)
  • [52] added a ton of extraneous HTML markup in a bunch of references. All the user was trying to do was do a minor copyedit, and it added over 1.5K unnecessary spaces and quotes. The Blade of the Northern Lights (話して下さい) 02:50, 16 July 2013 (UTC)
I'll also look into these, of course. --Elitre (WMF) (talk) 13:38, 16 July 2013 (UTC)
The references thing is known and tracked, but has been marked as a duplicate of a supposedly fixed bug... Ignatzmice•talk 14:01, 16 July 2013 (UTC)
Hi there, the first actually seems something an user can trigger (Azatoth made a vid @ Youtube about it, GConsjI9098), so I would not call that a bug. The second looks familiar, will do my best to find out why it still happens. --Elitre (WMF) (talk) 14:07, 16 July 2013 (UTC)
  • here the defaultsort and categories are suddenly moved to the middle of the article, inside a table (VE even adds a curly bracket after the cats). Since this is a VisualEditor edit, I don't think the human editor has the possibility of doing this manually or on purpose, and it looks like a VE error. Never seen this one before though. Fram (talk) 12:59, 17 July 2013 (UTC)
  • Another example of a VE edit totally ruining the article, apparently without the human editor meaning to do this at all; [53]. No idea what happened here, but suddenly adding 21K of unwanted code did rarely happen in the old editor... — Preceding unsigned comment added by Fram (talk • contribs) 13:10, 17 July 2013 (UTC)

Punctuation after wikilinks

When you try to add a comma (or other punctuation) immediately after a wikilink, VE adds the comma inside the wikilink and creates a piped link: [54]. While there are ways around this, it seems that this is the default behaviour on normal editing. Can this be avoided? A comma, semicolon, colon, ... will very rarely be the final part of a wikilink and will usually be intended to be outside the link (this may be less clear for exclamation marks, question marks and points). Fram (talk) 12:39, 16 July 2013 (UTC)

Other example: [55] Fram (talk) 12:50, 16 July 2013 (UTC)

Hi there, I saw this myself today, will definitely look it up later. Thank you! --Elitre (WMF) (talk) 13:33, 16 July 2013 (UTC) PS. I might have missed it, but is there a specific reason for you not writing on VE's feedback page instead? :)
This is more public and seems to have more direct participation. Some of the problems I raised ere (like the missing VE edit tags) turned out not to be VE related after all and got picked up immediately. Fram (talk) 08:08, 17 July 2013 (UTC)

Please explain before I'm 50

Before I reach my 50k'th edit cookie, can someone explain why this VE is pushed so hard upon to me? For example when I spend time on TemplateData (UglyWord#1), it does not respond and I cannot find a communication page. -DePiep (talk) 23:35, 16 July 2013 (UTC)

New essay wp:1EDITMYTH

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

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

See this blog post by Aaron Swartz. Graham87 06:52, 12 July 2013 (UTC)
  • User who neglects to login seems like hundreds of passing strangers: Yes, it makes sense how that blog post, from 4 September 2006, misled people into thinking the "passing strangers" were responsible for most content, but the flaw was:
"few of the contributors (2 out of the top 10) are even registered and
most (6 out of the top 10) have made less than 25 edits to the entire site"
But now we know how the non-registered editors (8 of "top 10" contributors) often use rotating, dynamic IP addresses to continue further edits as another "passing stranger" with a different IP address. If a user rotated among only 255 IP numbers, with 1 per week, it would take nearly 5 years to use all 255 IP numbers in the rotation (as if being 255 passing strangers who each quit within 1 week), plus often login with a separate username to reduce use of those 255 numbers. I had forgotten the issue of "6 out of the top 10 have made less than 25 edits to the entire site" and suddenly "stopped" there, never to edit again during 2001-2006, as if that would be realistic of common human actions. I cannot emphasize enough, as a general rule, to beware thinking of patterns in numbers as contradicting common sense, and instead concentrate on realistic notions about people who write WP pages, plus use large samples of articles (>2,000 pages) to test the ideas. Recent data shows 11,000 users (~10%) edit 25-2500 articles per month, as 92% of edits. Of course, a username who often neglects to login might seem like 256 people, as 255 passing strangers who make a few edits as different IPs and quit. -Wikid77 (talk) 04:13, 16 July, 22:04, 17 July 2013 (UTC)

How often do search results update?

RESOLVED: Daily during 06:00-7:00 UTC; noted in Help:Searching. -Wikid77 16:14, 17 July 2013 (UTC)

Hiya, I was wondering if anyone knows how long it takes for Wikipedia's search page to update with new edits. For example: I've been searching for the exact phrase "passed away" and changing it to "died" (per WP:EUPHEMISM). My ability to do this is dependent on the search results being up to date, and I've noticed that I've gotten hits on articles that no longer have this phrase anymore. Any thoughts? Is there a better way to do this? Thanks! Cyphoidbomb (talk) 20:11, 15 July 2013 (UTC)

See Wikipedia:SEARCH#Delay_in_updating_the_search_index. πr2 (t • c) 20:57, 15 July 2013 (UTC)
Is the whole search index updated at the same time? Can the last update time be seen somewhere? I tried https://wikitech.wikimedia.org/wiki/Server_Admin_Log but don't see it there. If it's the same time for all pages then I guess a search on a frequently edited page like Wikipedia:Sandbox will reveal the approximate time. The search hit on "Wikipedia:Sandbox" currently says "02:40, 15 July 2013" (with UTC time) for me. Based on [56] that indicates a search index update between 02:25 and 02:40 and 05:55. PrimeHunter (talk) 22:41, 15 July 2013 (UTC)
Do you use IRC? You'd probably get a response from the sysadmins on #wikimedia-tech connect. If you find out more, please add it to the H:SEARCH page! πr2 (t • c) 00:37, 16 July 2013 (UTC)
To summarize, they're done about once a day, per wiki (it's done automatically). With the work we're doing on replacing the search backend, the goal is to make search updates near-instantaneous (within seconds at most). ^demon[omg plz] 01:46, 16 July 2013 (UTC)
Awesome, thanks all! Cyphoidbomb (talk) 22:32, 16 July 2013 (UTC)
  • When daily, the new wikisearch index ready circa 06:00-07:00 UTC: Although there have been cases of a "stuck reindex" for days or weeks, I have also checked for daily searches of mispelled words, or counts of combined words, over the past few years and noticed the index seems ready circa 06:00-07:00 (UTC) each night. However, the actual re-indexing might occur hours earlier, possibly 03:00-4:15, with the release of the updated index posted during 06:00-7:00 (UTC). Lately, I have been wikisearching for "nowiki the" to confirm that most insertions of nowiki-tags by the wp:VisualEditor are getting corrected everyday, by someone somewhere, leaving only a few new "nowiki" pages (of 2,065), as re-indexed every day for the past 6 days. BTW: The pageviews in stats.grok.se are often updated circa 01:00-02:00 UTC but counted until 23:00 UTC, each night, which someone noted was midnight in Sweden's time zone. -Wikid77 (talk) 02:04, 16 July 2013 (UTC)
Thanks. I don't use IRC but looking at Wikipedia:Database reports/Pages with the most revisions I suppose Help:Searching could refer to the most recent time in the top-3 results of this search to get an estimate of what time the search index is currently based on. PrimeHunter (talk) 13:46, 16 July 2013 (UTC)
  • WP:Sandbox reindexed 3:30 but articles reindex <04:15 posted >06:00: As expected, the morning's re-indexing is a multi-hour process, running over 4 hours, and although the "WP:Sandbox" reindex timestamp shows re-indexing occurred circa 03:30 each day, the mainspace articles were re-indexed almost 1 hour later, up to 04:15 UTC, with results posted during the hour 06:00-7:00 where some article re-indexes were not ready until nearly 07:00 while "WP:" namespace project-page indexes were posted earlier, near 06:00 UTC. -Wikid77 16:14, 17 July 2013 (UTC)
  • Updated Help:Searching for reindex time and search-options: Thanks to this discussion, I have updated Help:Searching to give the case of the wikisearch re-indexing during 03:00-04:15 (UTC) with results posted during 06:00-7:00. However, I also quickly noted 10 search-options in the top paragraph, with wikilink to the Syntax, because the listing of search-options has been 24 paragraphs below in the page. In this fearful time, of many people thinking Wikipedia has reduced functionality, with fewer browser skins, it is good to note 10 powerful search-options in wikisearch:
NOTE: "Various search options are allowed (see below: Syntax), such as: word1 word2, "find phrase",
-exclusion, respell~, *end, begin*, (red OR white) OR blue, prefix:xx, intitle:xx, and incategory:xx".
I bet few people know the form: respell~ to match various spellings, such as: mariland~. We need to ensure other Help pages have more condensed, concise, top overviews of the technical features and options allowed, rather than far below in a Help page. My hunch is that many power users are unlikely to read down 24 paragraphs to get an overview, especially after several comments on this page, for how even one "300-word paragraph" will be skipped as too long and "unfair" to technical readers. -Wikid77 16:14, 17 July 2013 (UTC)

Is this me or the editor?

Tracked in Phabricator
Task T53521

Every time I try to use the visual editor, I find this at the top of the saved article:

<embed type="application/iodbc" width="0" height="0" />

I'm aware of what iodbc is, and I'm pretty sure I don't have it on my machine… but anything is possible. Is this something my machine is doing, or the editor? Maury Markowitz (talk) 00:39, 17 July 2013 (UTC)

What browser are you using, and can you give steps to reproduce? What page are you trying to edit? Any browser extensions/gadgets that could be interfering? πr2 (t • c) 01:27, 17 July 2013 (UTC)
It's most likely a broken browser extension. Sure you don't have this installed on your browser ? — Preceding unsigned comment added by TheDJ (talk • contribs) 06:47, 17 July 2013 (UTC)
Not that one, but a different one… thanks for the pointer, all fixed! Maury Markowitz (talk) 10:33, 17 July 2013 (UTC)

Wait, one thing… WHY NOW? This didn't happen with the source editor, didn't happen on any other web-based editor, so what is it about the visual editor that kicked it off? Maury Markowitz (talk) 10:34, 17 July 2013 (UTC)

If you want somebody (probably not me) to investigate that then you should say which browser and extension it was. PrimeHunter (talk) 10:47, 17 July 2013 (UTC)
OpenODBC. Already filed in bugzilla. Maury Markowitz (talk) 10:48, 17 July 2013 (UTC)
I have added {{tracked|51521}}. PrimeHunter (talk) 12:23, 17 July 2013 (UTC)

I personally find this similar to a bug with FoxLingo, a Firefox extension: see here. I wonder if they're trying to add HTML to the body, but this happens. I'm really not sure whether this is an extension/browser bug or a bug in VE, but it seems to be a problem with the extensions. πr2 (t • c) 16:30, 17 July 2013 (UTC)

Yes, there are multiple extensions like this (Skype extension also used to cause problems like this) that are just 'dumping' their fragment, wherever they want. If they would carefully wait for the dom to finish loading and append at the end of the document, and avoid using document.write, there wouldn't be a problem. The VE dom elements are at a different position (necessarily) from where our old textarea used to be and this is exposing more of these careless plugins. —TheDJ (talk • contribs) 22:49, 17 July 2013 (UTC)
So these are being progressively worked around in VE? Given it has to work in the messy world of dodgy addons - David Gerard (talk) 22:59, 17 July 2013 (UTC)
I doubt it. There isn't much we can do about this. We bugged Skype for a year to fix their extension. Ppl installed abusefilters. Those are the steps that can be taken. —TheDJ (talk • contribs) 01:19, 18 July 2013 (UTC)
Issues can also be mentioned at Wikipedia:Browser notes#Browser add-ons & proxies (no VisualEditor reports there yet). Relatively few affected people will probably find that page on their own, but it may help others figure out what's wrong. PrimeHunter (talk) 01:30, 18 July 2013 (UTC)

Adding categories

Why can't we added categories to the articles? The category edit feature seems to be missing in all(?) the articles. Categories are listed at the end of the articles but the little plus and minus sign to add and delete them is missing. -- Gwillhickers (talk) 15:51, 17 July 2013 (UTC)

You need to enable the HotCat gadget in your preferences.--ukexpat (talk) 16:41, 17 July 2013 (UTC)
The feature had been enabled for all users, logged-in and IP, for several months. However, misuse by inexperienced users who thought it was a way to add comments on talk pages led to disabling it, returning to the original state of an option for logged-in users. Chris857 (talk) 16:49, 17 July 2013 (UTC)
Well, I've been using HotCat for years and I was just adding some cat's to a couple of pages the other day, but today the plus and minus signs for adding/deleting cat's was missing. In any case, I went into my preferences add (re) added the HotCat feature. Should have checked it out first I guess. Thanks for your help. -- Gwillhickers (talk) —Preceding undated comment added 17:11, 17 July 2013 (UTC)
It sounds like you may think HotCat is the only way to add categories. In case you don't know, the standard way is to manually add the code described at Help:Category#Putting pages in categories. The HotCat gadget is an extra option for logged in users in the English Wikipedia. When HotCat was first enabled by default and then disabled due to problems with confused users, the software couldn't identify users who had originally enabled it manually, so it had to be disabled for everybody. PrimeHunter (talk) 21:18, 17 July 2013 (UTC)

Tech News: 2013-29

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

Recent software changes (Not all changes will affect you.)

Future software changes

  • A new version of the Single User Login system for global accounts will be enabled on July 17. Users will now automatically go back to the previous page instead of seeing the "Login success" page with logos. [60]
  • The software that resizes images on all wikis will change on July 18. Resizing of big images will be faster and more reliable, and the resolution limit for GIF, PNG and TIFF files (currently set at 50 megapixels) will be removed. [61]
  • Edit tags (mostly used by AbuseFilter) will now also be on diff pages. They include a link to Special:Tags before the edit summary. Wikis that use links in tag messages should remove them. [62] [63]
  • Global edit filters are currently in testing and will be added to wikis later. [64]
  • Wikivoyage wikis will start to use Wikidata for interwiki links on July 22. [65]
  • A new image gallery design has been proposed by Brian Wolff; comments and feedback are welcome.
  • An IRC discussion about Bugzilla is planned for July 16, at 16:00 (UTC) on the IRC channel #wikimedia-office on Freenode (time conversion). [66]

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

17:32, 14 July 2013 (UTC)

Null edits

Does anyone understand the changed to null edits made by the fix to T52785? --  Gadget850 talk 20:25, 14 July 2013 (UTC)

Yes. The problem was that people (or their null-editing bots) were null-editing templates with millions of transclusions, which was causing the job queue to be flooded with jobs to reparse every page that transcluded the template. So in an application of WP:PERF#If the sysadmins identify a performance problem, they will fix it, the problem was identified and fixed.
The fix was to make null edits (and the API's action=parse with forcelinkupdate) no longer do that. Now a null edit will reparse the page edited just as it always has (and therefore fix category membership and such), but it will no longer queue every transcluding page for reparse too.
Also, a new "forcerecursivelinkupdate" parameter was added to the API's action=parse to get the old behavior if necessary. Please do not go and change your null-editing bots to make a trivial almost-null edit, and don't change them to blindly use action=parse&forcerecursivelinkupdate=1. If you think your bot needs to do this for some reason, ask (wikitech-l would be a good place) and then be patient for a response. On the other hand, there is no need to be any more paranoid than usual about editing these high-use templates either when the edits are necessary. BJorsch (WMF) (talk) 20:47, 14 July 2013 (UTC)
if your explanation is correct (and if i understood it correctly), then there's a possibility the cure is worse than the disease.
we've been using null edits plenty of times specifically to trigger reparsing of transcluding pages, and this is one of the crucial tools in our toolbox, when pages do not appear the way we expect them to appear. in many cases, we can't use "faux" edits (such as adding or removing some whitepsace from the "noinclude" part of the tempalte) instead of null edits, because these templates are protected and only sysops can edit them (non-sysops can still execute a "purge", supposedly the equivalent of null-edit).
removing this tool from our toolbox seems to me as a very bad idea.
now, if people operate bots that execute null-edits unnecessarily, won't the right solution be to stop the bots from doing so, rather than neutralizing the important function of null edits?
it is also possible, of course, that i did not fully understand what you wrote, and to a leser degree, i guess it is also possible that you didn't fully understand this code change... peace - קיפודנחש (aka kipod) (talk) 22:56, 14 July 2013 (UTC)
You will still be able to null-edit the transcluding page to trigger a reparse of that page, this has not changed. The difference is that if you null-edit the template itself, it will no longer queue every transcluding page for reparse. Also, it's not just bots that are doing this; as mentioned in the bug, individual editors have been known to do this too because they think the job queue isn't working (and doing this can make it not work even more). BJorsch (WMF) (talk) 23:04, 14 July 2013 (UTC)
Correct me if I'm wrong, but wasn't it more that the WMF went out and told people to add TemplateData to all the high use templates. This was of course followed by the discovery that the TemplateData often took a long time to appear in VE, and the advice that null editing the templates would make it appear? Seems like the last two weeks were probably far from routine for the job queue. Dragons flight (talk) 23:10, 14 July 2013 (UTC)
To tell the truth, I don't know much about that—WMF is not all that big, but it's big enough that VE and TemplateData are outside of my "area" (and I haven't had time to look into TemplateData in my volunteer capacity yet). At any rate, this fix will also prevent the job queue from being blown up if people null-edit the templates for that reason, or for future situations like that. BJorsch (WMF) (talk) 23:33, 14 July 2013 (UTC)
Also, in my personal opinion and going off on a bit of a tangent, it would be a good idea to put the TemplateData on the doc page or some other subpage if possible, for the same reasons that we put documentation on a doc page transcluded within <noinclude>: to allow unprotected editing of the documentation and to avoid having to reparse everything transcluding the template itself when only the documentation has changed. Now where was that RFC about that that I forgot to ever comment on... Anomie⚔ 23:35, 14 July 2013 (UTC)
mw:Help:TemplateData says specifically that TemplateData should be on the doc page. I've bolded that statement to increase its visibility; perhaps editors who are placing it directly on template pages could be notified they are making a mistake. -- John Broughton (♫♫) 03:42, 15 July 2013 (UTC)
By general consensus, TemplateData does go on the /doc page, but the software doesn't associate the new data with the template until the template's page itself gets refreshed (via save, null edit, or job queue). And of course once the job queue got thrashed, people started null editing templates to "hurry" the updates along. Dragons flight (talk) 06:57, 15 July 2013 (UTC)
@Dragons flight and Anomie: This change to how templates are enqueued when a null edit was made by Tim specifically to address the chronic difficulties that the JobQueue has (and has apparently had for some months without it being fixed). We're well aware of the advice we've been giving people on how to bypass the problem with the queue that was affecting TemplateData, yes. :-) Jdforrester (WMF) (talk) 23:39, 14 July 2013 (UTC)
  • Some pages (like Category:Rescaled fairuse files more than 7 days old) instruct people to make null edits to certain pages. Are these instructions now obsolete and replaced by things like posting titles=Template:Non-free_reduced&action=purge&forcerecursivelinkupdate=1 to api.php? If so, then the instructions need to be updated. --Stefan2 (talk) 23:25, 18 July 2013 (UTC)

Galleries

The <gallery> tag will support pages for PDF, DjVu and other multi-page files. See T10480. --  Gadget850 talk 20:32, 14 July 2013 (UTC)

Infobox/nav box disputes

I've noticed that infoboxes and nav boxes are subject to a lot of bitter disputes on wikipedia. I was wondering if a good solution to the problem would be a preference option to suppress the showing of infoboxes and nav boxes for those editors who detest them. I think it's a contentious enough topic to warrant an option in preferences.♦ Dr. ☠ Blofeld 09:33, 15 July 2013 (UTC)

I don't think it needs a new option when it can be done in one line of CSS: 
.infobox, .navbox { display: none; }
Just put that in Special:MyPage/common.css. --Redrose64 (talk) 09:52, 15 July 2013 (UTC)
Yes but it doesn't stop disputes happening over info and navboxes. The option should be there in preferences to suppress them. ♦ Dr. ☠ Blofeld 10:23, 15 July 2013 (UTC)
I'm not sure that's going to solve the issue. I like infoboxes because of the consistency and familiarity they bring to pages, but for specific data beyond birth and death dates, the content below the picture might as well say "tl;dr". And when arguments descend into borderline fanboyism, I switch off and lose interest. Ritchie333 (talk) (cont) 12:56, 15 July 2013 (UTC)
In general, I hate info boxes, I make no secret of it. Having said that, I see their usefulness on sports, geographical, film and political articles. Info boxes on biographies are pointless and repeat information which can easily be found within the lead section. They boxes can be so small that they look ridiculous, or too long that they look overwhelming. They can also interfere with the lede image forcing its size, and ruin preceding sections after it if overly long, often sandwiching text between the first image within the body. I think it is high time we found a happy medium in order to appease those who are pro-infobox and those who despise them. -- CassiantoTalk 16:35, 15 July 2013 (UTC)
I'm a serious reader and contributor and I love Infoboxes, both as a reader – to find information quickly, and as an editor with an eye toward wikidata and other automated parsing of information from articles. Computers can't easily extract the information from the prose, and, while humans can, it's harder than looking in the Infobox. In what way is any of that not serious? I suggest trying the code snippet above for a while to hide them. Thanks for that, RR64! —[AlanM1(talk)]— 16:46, 15 July 2013 (UTC)
I retracted that, so no need to get upset. However, that seems to be how they are designed, giving the reader quick information without having to read the entire article" that is a lazy reader in my book. Any important information can be found in the lead section of any article; there is no need to repeat it in an ugly box. The technical "metadata" stuff I have no knowledge of I'm afraid, but surely it can be hidden in some cases? -- CassiantoTalk 16:58, 15 July 2013 (UTC)
And the infobox wars continue to escalate largely because certain editors feel the need to characterize their opponents as, say, "lazy" or "marginally literate". Plenty of careful readers who have no problem swimming through hundreds or thousands of pages hour after day after week still find infoboxes useful. For example, when an unfamiliar term or name comes up in another article, and you just want to click through briefly to get your bearings and then pop immediately back and continue reading before you forget just what it was you were reading. Disinfoboxers fail to recognize the whole world of reading modes in the universe. Plenty of real "bang-bang" wars spring from similar narrowmindedness. Curly Turkey (gobble) 02:10, 19 July 2013 (UTC)

I wonder whether it is going to be true for long that 'Computers can't easily extract the information from the prose' -they seem to be making good headway in doing so - try for example asking about any topic here - (even for topics which don't have WP infoboxes! - although admittedly it doesn't seem strong on operas yet). I suspect we will still be bickering about the importance of infoboxes for metadata when other data-extraction technologies have left the issue behind.--Smerus (talk) 17:50, 15 July 2013 (UTC)

Fine to have better data-extracting devices in a future, but why not have an infobox until then, with dates in templated form and other information structure? Why not give fast access to someone who simply wants to find a date or the name of an opera librettist? And yes, why not hide them for those who despise them? --Gerda Arendt (talk) 17:59, 15 July 2013 (UTC)
Back to Dr. Blofeld's technical request: providing a gadget in preferences to hide all infoboxes for logged-in users is not going to happen because no-one wants that, not even those who dispute the usefulness of such boxes for certain articles. The dispute is not about the sensibilities of those opposing (one can look away) but whether the form and content of infoboxes is appropriate for some articles in delivering information to the average reader. -- Michael Bednarek (talk) 03:03, 16 July 2013 (UTC)
This also hides the lead image, so this is a non-solution. People who oppose infoboxes still want photos. —Designate (talk) 03:20, 16 July 2013 (UTC)

Wiping watchlist clean

For some reason I have 1800 articles on my watchlist. most of which I don't even want to a watch. Can anybody tell me how to wipe the slate clean?Tibetan Prayer ᧾ 10:50, 17 July 2013 (UTC)

Near the top of the watchlist page is a link "Edit raw watchlist". That displays the entire list in an editable text area, which can be cleared with Ctrl-A / Delete. Then click the "Update" button at the bottom and you're done. -- John of Reading (talk) 11:04, 17 July 2013 (UTC)
Note that this is not reversible unless you save the old watchlist offline. There is no history showing the former content. See also Help:Watching pages#Controlling which pages are watched. PrimeHunter (talk) 12:06, 17 July 2013 (UTC)
Nice one John, thanks.Tibetan Prayer ᧾ 11:35, 18 July 2013 (UTC)
You should be able to save the old Watchlist online, as well. — Arthur Rubin (talk) 13:11, 18 July 2013 (UTC)
Of course, but you probably don't want to save it in a publicly visible place (e.g., onwiki) if you don't want others to see what you watched. There's no problem with saving it online, in a private place (or publicly but encrypted). πr2 (t • c) 16:38, 18 July 2013 (UTC)

Cropping svg maps

As the map lab doesn't always seem that responsive I'll ask here. For the Geography of Franz Josef Land article, I think each section needs more localized maps for islands groups. Any chance somebody knows how to crop svg maps of File:Map of Franz Josef Land-en.svg in full scale. I think probably around 4 or 5 crops would suffice. I tried cropping in png from the scaled down version and it produces fuzzy labels because it isn't full scale. Svg won't let me save it full scale.Tibetan Prayer ᧾ 11:35, 18 July 2013 (UTC)

Right click the full resolution link and save it. You can edit this with Inkscape, but I cannot remember how to crop in any sensible way. Graeme Bartlett (talk) 12:08, 18 July 2013 (UTC)
Aymatth2 has kindly produced some.. Thanks anyway!Tibetan Prayer ᧾ 15:29, 18 July 2013 (UTC)
Cropping a SVG is easy. You just adjust the viewBox attribute of the <svg> tag. The first two values offset the origin; the second two define the dimensions of the visible area. --Redrose64 (talk) 15:49, 18 July 2013 (UTC)

Braille in the fall

Link.--Canoe1967 (talk) 12:49, 18 July 2013 (UTC)

It's the only edit by that user. User:Technoquat has trolled the help desk with dozens of socks created for the purpose. I suspect this is another. PrimeHunter (talk) 13:56, 18 July 2013 (UTC)
The user has been blocked by a checkuser. PrimeHunter (talk) 15:48, 18 July 2013 (UTC)

Duplicated text on tags

Since gerrit:72984 is now live, could someone remove the text "[[Special:Tags|Tag]]: " from the content of our tags? Helder 19:52, 18 July 2013 (UTC)

Special:Tags is a better list, not all tags need modifying. Matma Rex talk 20:11, 18 July 2013 (UTC)
By the way, this was announced right here almost a week ago (#Tech News: 2013-29), you guys should start reading those, really. Matma Rex talk 20:19, 18 July 2013 (UTC)
Oh, we would read them, were they not swamped by stuff that belongs elsewhere. Can't see the wood for the trees. --Redrose64 (talk) 21:54, 18 July 2013 (UTC)
 Done. Legoktm (talk) 23:26, 18 July 2013 (UTC)

MediaWiki:Histlegend and the watcher tool

Hi. MediaWiki:Histlegend currently looks something like this:

For any version listed below, click on its date to view it. For more help, see Help:Page history and Help:Edit summary.
External tools: Revision history statistics · Revision history search · Contributors · User edits · Number of watchers · Page view statistics
(cur) = difference from current version, (prev) = difference from preceding version,  m = minor edit, → = section edit, ← = automatic edit summary

I'd like to switch out the "Number of watchers" link with a non-external tool (pointing to <https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)/Archive_114&action=info#mw-pageinfo-watchers> instead). This requires a simple request on the relevant talk page, however this change will mean that the label ("External tools") is no longer completely accurate, as the info action is not an external tool.

Does anyone have thoughts about this? Does anyone care? --MZMcBride (talk) 20:49, 18 July 2013 (UTC)

  • *shrugs* ... but yes, please update the link, given how flaky (and unnecessary, in this case) the toolserver is anyhow. Theopolisme (talk) 20:56, 18 July 2013 (UTC)
  • Maybe just "Tools"? Legoktm (talk) 23:18, 18 July 2013 (UTC)
  • (edit conflict) I've gone ahead and updated the link. If anyone has a better idea for the "external tools" verbiage, we can change that too. Fran Rogers (talk) 23:21, 18 July 2013 (UTC)
  • Yeah I'd rather just call it "Tools" since it's possible that other things will also switch over in the future. —Soap— 01:48, 19 July 2013 (UTC)
  • I like "Tools" too. Theopolisme (talk) 01:54, 19 July 2013 (UTC)

WMF intends for Only VisualEditor to be usable on Talk pages; representative states he would "dearly love to kill off Wikitext".

http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor&diff=prev&oldid=564282164

Was anyone consulted on this? What if you want to quote text from the article on the talk page? Or wanted to use templates?

Not to mention how many bots will need recoded. Goodbye auto-archiving bots. Goodbye the bot that handles Good article promotions.

It gets worse when you start digging:

""You should strive to achieve Zen acceptance that the only editor for Flow will be the VisualEditor. If, by the time Flow is released, the VisualEditor supports a native code editor, it will likely be there. But nothing is promised - nor can it be." - Jorn (WMF)"

He went on to add "It is entirely possible that the data for each post will not be saved as wikitext because there are considerable performance issues that arise when doing so. If this is the case, things like templates will simply be unable to be supported." and further added "I would dearly love to kill off Wikitext."

I apologise if the links are a bit weird - they use LiquidThreads there, and linking to individual threads is buggy.

Is Jorm acting in a rogue manner? Perhaps. But until the WMF denies it, we need to presume this is true. Adam Cuerden (talk) 00:13, 15 July 2013 (UTC)

There's nothing stopping people from creating a user subpage like Special:MyPage/Talk, where both VisualEditor and source editor can be used. And assuming signatures can still be customised, we can even link to it from there. Having two parallel talk systems isn't ideal, but then neither is only allowing VisualEditor – I don't want to be forced to use it. - Evad37 (talk) 01:20, 15 July 2013 (UTC)
If someone posts spam, or vandalism, on your primary user talk page, I'm guessing that you'll choose to use VE to deal with it, if the alternative is that the posting gets left as is. Also, it's not clear how other editors would actually find your parallel user talk page. -- John Broughton (♫♫) 03:33, 15 July 2013 (UTC)
Like Evad said, one could link to the parallel page in one's sig. I was going to also say that you could soft redirect the Flow page to the parallel page, but I don't know if that would work, what with it being a template. One could also hard-redirect it as well. An issue might be Notifications not being integrated with such a workaround (P.S. how will Notifications be integrated with Flow??). Ignatzmice•talk 03:47, 15 July 2013 (UTC)
Looking at the prototype (only a prototype!) there doesn't seem to be a way to edit others' posts, but they are deletable. No VisEd needed. I think. Ignatzmice•talk 03:52, 15 July 2013 (UTC)
Users will not have a signature when Flow arrives in December, and Flow will be some software feature that cannot be replaced with a redirect. The way the developer is talking, only an admin will be able to delete a comment, and that will leave a visible marker (I hope not like "comment by User:OBAMA_IS_GAY removed"). Johnuniq (talk) 03:57, 15 July 2013 (UTC)
See Wikipedia_talk:Flow#Arbitrary_Section_Break_1, particularly Jorm's and Whatamidoing's comments. Editing other people's comments is just a user-right, which will (presumably) be up to us to decide how it is given out (and or changed later on). If it can be restricted to "group-admin", it can be restricted (or unrestricted) in any way. –Quiddity (talk) 04:24, 15 July 2013 (UTC)
This post was duplicated in a variety of places.
If everyone could respond at Wikipedia talk:Flow, rather than in fragmented locations, that would help everyone. (Pointers to discussions are good; fragmenting discussions purposefully is not good.) –Quiddity (talk) 04:24, 15 July 2013 (UTC)
  • How do we enforce policies such as WP:NFCC#9 and WP:BLP if there is no easy way to edit other people's comments on talk pages? How do I tag a comment with {{db-g10}} if I can't edit it? Does it work like LiquidThreads (where you add deletion templates, like {{db-g12}}, to individual posts) or like a normal talk page (where you add revision deletion templates, like {{copyvio-revdel}}, somewhere on the page)? Also, if templates don't work, you might not be able to nominate anything for deletion in the first place as there is no way to add {{delete}}. Sounds like a spammers' paradise... --Stefan2 (talk) 16:02, 15 July 2013 (UTC)
    • You should read the section above fully and note how User:Quiddity explains that editing another user's post will be a user right (so not impossible), same (unmentioned) for deleting. There is nothing set in stone about how that permission will be configured (though giving it to IPs seems unlikely to me). Regarding using templates for deletion... How often do we have such discussions about individual comments ? Not that much I think. Also for entire discussions, we would likely attach either a new comment or add the deletion notification to the page header. If there is more flow control required than that ? If additional workflows are required, I'm sure Brandon would love to hear about them. But please move that discussion to the talk page of the flow portal then. —TheDJ (talk • contribs) 19:23, 15 July 2013 (UTC)

I pointed out at WP:VisualEditor that Flow will force all editors to use VE on talk pages, and I was reverted and accused of making bad-faith false edits. WMF has no idea what they're doing, and we need to make it known to them. Ian.thomson (talk) 21:24, 15 July 2013 (UTC)

Ian - I (and other editors) share your concern, but this isn't an issue for the VE team - it's an issue for Flow. If using VE (plus a degraded VE to handle older browsers and those with disabilities) results in limitations within Flow' that are unacceptable, we need to point that out to the Flow designers. They are the ones who then should turn to the VE team and ask for VE modifications, and/or modify their design so that wikitext editing remains an option. -- John Broughton (♫♫) 05:07, 16 July 2013 (UTC)
Well, in fairness, the closest thing to an "official" comment on this issue is posted on the VisualEditor FAQ. The two are not separate. Risker (talk) 05:14, 16 July 2013 (UTC)

See Wikipedia talk:Flow#Just making sure I have this straight - This seems to be (on its way to being) resolved. I imagine we'll get an even clearer answer in 12+ hours, once more staff have (slept and) woken up and chimed in. Announcing the new prototype over the weekend was just asking for trouble! ;) –Quiddity (talk) 05:47, 16 July 2013 (UTC)

At that link is this, from Jalexander of WMF: "I also, honestly, don't know if we have a Flow FAQ." I believe I saw, somewhere, Jorm saying that there was in fact no FAQ (yet). On my to-do list is to create one (no promises; I hope someone else beats me to it), here at the English Wikipedia, in which we can gather a complete list of issues and answers, including, of course, lots of "to be determined at time X". (If Jorm wants to put up his own, personal FAQ at MediaWiki.org, that's fine.) That way, perhaps we'll avoid getting a beta version of Flow going into full production on our talk pages. Because while it's possible to use multiple editors to edit the same article (WikiEd, for example, has existed for quite a while), it's not possible (or, let's say, at all desirable) to have multiple talk pages for the same article. When we shift to using Flow, it has to be a clean cut-over, even if it's done on a phased, page by page basis. -- John Broughton (♫♫) 22:53, 16 July 2013 (UTC)
I don't know if people have noticed, but we seem to have got what we wanted. Ignatzmice•talk 05:04, 19 July 2013 (UTC)
Well, depends totally on how the "fallback" will look. A fall-back (for me) is mostly something that only supports rudimentary functionality, being used as a last resort to be able to use a product at all if otherwise not possible for some fundamental reason. What I'd like to see is a Wikitext alternative to the VisualEditor.
I'm a little afraid (please Brandon or anybody else involved, feel free to distract my concerns, if you have solid arguments) that we might be mollified with the prospect of an only slightly limited Wikitext editor first, only to recognize later on that it lacks so many functions compared to the VE that it is not an actual alternative but only what it is called – a fall-back. --Patrick87 (talk) 09:31, 19 July 2013 (UTC)

"Some parts of the edit form did not reach the server; double-check that your edits are intact and try again."

Originally posted at WP:HD; this seems a better place, so I'm copying to here. -- John Broughton (♫♫) 01:34, 19 July 2013 (UTC)

Hi there. So I just upgraded from IE9 to IE10, and whenever I'm editing and I click on "Preview", I get the message "Some parts of the edit form did not reach the server; double-check that your edits are intact and try again." I've tried it on three computers and it's the same thing on all of them. I've had a look around online thinking this might be an inherent problem with Wiki and IE10 but I can't find anything. Any help would be very much appreciated. Thanks. Bertaut (talk) 01:16, 19 July 2013 (UTC)

Do you use the classic "Edit source" way to edit the raw wikitext, or do you use the Visual Editor? If the latter: I'd recommend to check the list of open bug reports at https://bugzilla.wikimedia.org/buglist.cgi?f1=cf_browser&o1=equals&resolution=---&v1=Internet%20Explorer&product=VisualEditor and if there is nothing listed that sounds similar, I'd ask on WP:VE/F which is the best place to give feedback for the VisualEditor (or to check for existing threads requesting the same feature/bugfix) so the developers can see it. --AKlapper (WMF) (talk) 11:17, 19 July 2013 (UTC)
Hi. No, I use the "Edit Source" option. As far as I know, Visual Editor isn't available for IE yet. Bertaut (talk) 16:37, 19 July 2013 (UTC)

switch editor.js

I've created a basic prototype for switching from VE to SE mid-edit: User:John Vandenberg/switch editor.js

At the moment it is attached to the real 'Save page' button. After the second 'save page' button is pressed, the unsaved content dialog ("data you have entered may not be saved") appears, but this can be prevented. If the user accepts this, they are taken to the diff with wikitext for additional editing. There are quite a few minor improvements needed, such as transferring the edit summary and save options from VE to SE, and I'll get to those soon, but im throwing it out for code review and alpha testing ;-) John Vandenberg (chat) 11:06, 19 July 2013 (UTC)

It is now has the features I would expect. It doesnt override the save button now. It adds a 'Source' checkbox in the save window, which when checked changes the 'review' button to go to a source editor diff. Only tested in Firefox 22.0 so far. I'll add documentation after breaky. John Vandenberg (chat) 00:39, 20 July 2013 (UTC)
Documentation at User:John Vandenberg/switch editor, and the code is documented now also. Tested in Google Chrome. I don't have IE at home, so would appreciate if someone could test that for me. I'll go up to the office to fix problems if it isnt working on IE. John Vandenberg (chat) 03:14, 20 July 2013 (UTC)
Since VE doesn't run on IE, I don't know what an IE tester would test.—Kww(talk) 03:20, 20 July 2013 (UTC)
I thought VE worked in some versions of IE? John Vandenberg (chat) 03:22, 20 July 2013 (UTC)
It is supposed to eventually be enabled in IE8 and IE9. Support for earlier versions isn't even in the plan. At the current moment, it doesn't support any versions of IE at all.—Kww(talk) 03:34, 20 July 2013 (UTC)

A simplier version, which is bookmarkletable, is at User:John Vandenberg/switch editor 2.js. John Vandenberg (chat) 04:19, 20 July 2013 (UTC)

WikEd invisible and HotCat gone?

Over on wikEd talk it was mentioned that WikEd disappearing was a problem with gadgets in general. I had unchecked WikEd from my gadgets for about a day. I rechecked it in gadgets today. And WikEd isn't there in my editing window. Still problems with the gadgets? — Maile (talk) 18:08, 19 July 2013 (UTC)

Also, what happened to HotCat. I found it unchecked today, which is nothing I would have done. I just re-checked it, but HotCat isn't working for me. — Maile (talk) 18:09, 19 July 2013 (UTC)
Have you bypassed your cache? And for the HotCat issue, see #Adding categories above.--ukexpat (talk) 18:57, 19 July 2013 (UTC)
Well, yes, I bypass my cache regularly in any given day. And just now did it again to make sure. And while I'm typing this, WikEd is not there, even though it's checked under Gadgets. For what it's worth Firefox 22.0, Windows XP, Modern skin. I'm not sure what any of that would have to do with this. But WikEd isn't there. This is going on one more issue I've had with WikEd (and mentioned there) that makes it not a good tool for me. But I was going to run some tests on its latest version today, so I could fill out a Bug report at WikEd. But...no WikEd at all.— Maile (talk) 19:16, 19 July 2013 (UTC)

WP extremely slow

I am experiencing extreme slowness. Anyone else? Nurg (talk) 05:26, 20 July 2013 (UTC)

Yup; about an hour of slowness and random broken-ness. It seems to be fixed now. John Vandenberg (chat) 06:18, 20 July 2013 (UTC)

New Single User Login system, login success page going away

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

Thanks for the heads up, Steven. 64.40.54.109 (talk) 03:58, 10 July 2013 (UTC)
@Steven (WMF): Will this SUL update mean that we get auto-logged into "any public WMF wiki" that aren't currently doing so properly, eg Outreach and Wikimania? I assume so, but am not sure if there are any other meanings for how it relates to users. Thanks. –Quiddity (talk) 00:50, 13 July 2013 (UTC)

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

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

Update: This is now live. Steven Walling (WMF) • talk 21:12, 17 July 2013 (UTC)

*magic* Works like a charm; great work Steven, Greg, and team! :) While perhaps this isn't quite as noticeable as the Visual Editor or Flow, it's still very much appreciated. Theopolisme (talk) 21:17, 17 July 2013 (UTC)
  • Wow, works great! Speeds up login a lot and being quickly and directly brought to the page last shown is what most people probably want after login.
There's one downside: New users might not realize that SUL exists and that they are actually logged in across all Wikimedia projects! Will you provide newbies with the relevant information somewhere so they are aware of unified login? --Patrick87 (talk) 22:22, 17 July 2013 (UTC)
Seems like I spoke a bit too fast. Just came back to see I was not logged in longer on Commons and MediaWiki. Germand and English Wikipedia worked, though. Let's see if this sorts out itself or if there is a real problem somewhere... --Patrick87 (talk) 23:02, 17 July 2013 (UTC)
Tracked in Phabricator
Task T53603
  • This system is buggy. I own the SUL account "Stefan2", but other people own my username locally on Commons and two language editions of Wikipedia, and the accounts on those three projects are not attached to SUL (see sulutil:Stefan2). If I go to Commons, the new SUL system partially logs me in to the local Stefan2 account on Commons: Commons:Special:Preferences tells that I'm not logged in, but the links at the top say that I'm logged in. The user name, Special:Contributions link and "log out" links are all there. Also, the interface is partially in English, partially in German. I'm guessing that the one who set the interface to German was the guy who owns the user name on Commons. I don't know whether I can access any private data other than the language setting, and I don't know whether any edits would be attributed to my IP address or to Commons:User:Stefan2. In any case, things seem to be wrong, and there may be security issues with this. Screenshot: http://i.imgur.com/TvwRbSE.png --Stefan2 (talk) 11:28, 18 July 2013 (UTC)
    • I have notified some folks who will be able to deal with this. This should not happen indeed. Thanks for your restraint. —TheDJ (talk • contribs) 12:10, 18 July 2013 (UTC)
      • Thanks for the report! It turns out there's no security issue here, and only minimal data leakage. There's a script involved with the new SUL that, if you visit a wiki while logged out, checks against login.wikimedia.org to see whether you're logged in centrally. And if so, that script sets the necessary cookies and updates the #p-personal bar to reflect your logged-in status. The bug here is that that script wasn't checking if the local account was unattached, so it was setting the cookies (which would be ignored) and replacing p-personal even in a situation like Stefan2's. As far as everything else is concerned you were still not logged in, so anything you did would be done as an IP, and the only data leakage was that you could see that other Stefan2's p-personal bar (and so guess his language setting and see if he has any unread Echo notifications—you couldn't see those notifications, just the fact of their existence).
        We've now patched the bug, and are in the process of deploying the fix to all WMF wikis as I write this. BJorsch (WMF) (talk) 15:51, 18 July 2013 (UTC)
      • Another thanks for the report. The fix has been deployed, so you shouldn't see this behavior any more. Just to ease anxiety, as BJorsch mentioned, the session cookie you were getting would have been useless to actually authenticate to the site, or impersonate the unattached user. However, that did leak the existence of the unattached account and the number of unread echo notifications. I can understand why that would be upsetting to some people, so I do apologize for the oversight. I'll also get a regression test for this added, so we don't let this slip by again. CSteipp (talk) 16:05, 18 July 2013 (UTC)
  • When logging in, I ticked the box to stay logged in for up to 30 days. About six hours later, I was no longer logged in. I didn't close my browser in the meantime and it's very unlikely my IP address changed. This just happened but the same thing was happening sometimes before the recent changes to the log-in facilities. —rybec 02:16, 21 July 2013 (UTC)

Edit intros not showing if editing entire page normally

Pick any article in Category:Living people. The edit intro (Template:BLP editintro) shows if you either (1) use the VisualEditor to edit the entire page, or (2) edit any section using any editor. It does not show if you edit the entire page using the "traditional" wiki markup editor. Please fix this (requires editing MediaWiki:Common.js). MER-C 04:25, 20 July 2013 (UTC)

This happens because VE plays with the tabs, adding the 'edit source' tab after Commons.js has finished. I believe the solution is to wrap that call in Common.js with 'mw.hook( 've.activationComplete' ).add( function() { .. });' . --John Vandenberg (chat) 06:16, 20 July 2013 (UTC)
If fixed, please update WP:EDITINTRO. --  Gadget850 talk 11:09, 20 July 2013 (UTC)

Math images colors

I would like to bring to the attention of the Wikipedia web technicians community of a particular problem with images representing mathematical symbols, when the user is not using the normal (black on white) colors.

Over here, my system colors are white on navy (like the good old WordPerfect 4 colors) which I find easier to read. In Windows Vista, in Personalization > Window Color and Appearance > Appearance Settings > Color Scheme: Windows Standard > Advanced... > Item: Window, I have set Color 1: navy (background) and Color: White (f9reground).

When in Firefox, in Options > Content > Fonts and Colors > Colors > Text and background, you check Use System Colors and then open a Wikipedia page containing images with images of mathematical symbols, like:

http://en.wikipedia.org/wiki/Cut_locus_%28Riemannian_manifold%29

in the first (Definition) section the "foreground" of the image (a) representing (M,g) appears gray and is difficult to discern. A little later in the same sentence in the image (b)

http://upload.wikimedia.org/math/7/f/5/7f5e50995d711b7b22a3752f74f7a724.png

the text is gray (#777) on white background and it is easier to read.

I do not suppose there is a way to make the image (b) appear with the user's System colors (though I do not see why its text shouldn't be black instead of #777). but certainly it shouldn't be difficult to have image (a) look like image (b).

I do not know how the images are created, but the code of the program that creates the images should not be too difficult to improve. — Preceding unsigned comment added by ΕΜΦ (talk • contribs) 06:38, 20 July 2013 (UTC)

The file http://upload.wikimedia.org/math/7/f/5/7f5e50995d711b7b22a3752f74f7a724.png is an 8-bit greyscale - it has 256 possible "colours": black, white and 254 shades of grey. The PNG file displayed for math markup is generated on the Wikimedia servers. In a PNG file, the colours are hard-coded (either in the pixel data for truecolour images, or a PLTE chunk), they cannot be read from your system. So, to create a PNG using your system colours, your browser would need to send that colour data back to the Wikimedia servers, which would then generate a PNG using those colours - and such a PNG would not be useful to anybody else. --Redrose64 (talk) 07:41, 20 July 2013 (UTC)
Try enabling MathJax in Preferences → Appearance – it will render the math on your browser instead of as an image and I think it will use the system colors correctly. Matma Rex talk 10:26, 20 July 2013 (UTC)
As an other option, you could use a small script like the one I suggested on Wikipedia:Village pump (technical)/Archive 97#Transparent PNGs used for math formulas unreadable on black background, to change the colors of the images. Helder 15:37, 20 July 2013 (UTC)

Tagging module pages for deletion?

See Module:IPAsymbol/sandbox2 and Module:IPAsymbol/sandbox/data2, don't think it works. — Lfdder (talk) 18:12, 20 July 2013 (UTC)

Module pages cannot contain templates. Tag the talk page instead. — Edokter (talk) — 09:52, 21 July 2013 (UTC)
Another way to do it is to place the deletion tag on module's doc page, e.g. as <includeonly>{{db-foo}}></includeonly>. I don't know which would be preferable. Anomie⚔ 10:47, 21 July 2013 (UTC)

Position of templatedata link

There's centralised discussion link pointing to #Position of templatedata on this page; but no such section. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:35, 20 July 2013 (UTC)

Wikipedia:Village pump (technical)/Archive 113#Position of templatedata?
See also bugzilla:50512. Helder 22:54, 20 July 2013 (UTC)
Sigh. Why did not the creators povide a guideline? -DePiep (talk) 23:05, 20 July 2013 (UTC)
Thank you. So why is an archived discussion still being advertised? (or, conversely, why is a still -advertised discussion archived?). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:24, 21 July 2013 (UTC)
It's still being advertised because it's not expired yet. It was archived because nobody posted to it for five days: the timestamps range from 16:48, 1 July 2013 (UTC) to 18:59, 6 July 2013 (UTC) and it was archived at 06:40, 12 July 2013. Many archive bots (including the MiszaBot family) don't care whether a discussion is "open" or "closed": they just go by the latest datestamp. If the person starting the RfC had put a message at the top, explicitly stating something like "This RfC will expire on ...", that would have defeated MiszaBot II. --Redrose64 (talk) 08:03, 22 July 2013 (UTC)

Hard-coded formatting cannot be customised

I expressed a concern at Template talk:Tq#Similarity to example font but it seems no one is listening there. I would like to change the font style/colour for the {{tq}} template (for quoting someone's comment on a talk page: like this) due to its similarity to {{xt}} (for showing an example of correct usage: like this). Alternatively, I have tried to customise the font colour using my style sheet, but the font style and colour seem to be hard coded in the tag used by the template and {{tq}} template and therefore will override any stylesheet settings.

Help? —sroc 💬 11:24, 21 July 2013 (UTC)

Replied there. — Edokter (talk) — 12:08, 21 July 2013 (UTC)

Spelling error in a template

I'm not really sure if this is a template issue or not, but I can't correct it, and it's system wide. Here's an example:

The word "available" is misspelled as "avaliable" (F8: File avaliable on Commons). That should be fixed. -- Brangifer (talk) 15:53, 21 July 2013 (UTC)

That can no longer be corrected (summaries can't be edited), but it should not happen in the future. — Edokter (talk) — 15:58, 21 July 2013 (UTC)
Good. Where is the template located so I can fix that type of thing in the future. I can usually do it, but this time I couldn't locate it. -- Brangifer (talk) 16:24, 21 July 2013 (UTC)
MediaWiki:Filedelete-reason-dropdown (only admins can edit it). Note that the summary could have been entered manually; the system message never had that spelling error. — Edokter (talk) — 16:35, 21 July 2013 (UTC)
It's nice to know that human error might have been the cause, because automated functions should work without flaws. I thought I had found one! Thanks for the info and help. -- Brangifer (talk) 16:47, 21 July 2013 (UTC)

Cite web source fetching the wrong information somehow.

When I use the cite toolbar button to add the page http://movies.nytimes.com/movie/review?res=9C06EFDE1639F936A15752C1A96E958260 as a cited web source, and press the green arrows for it to fetch the information, it seems to grab the info from a completely different NYT movie review page (this one: http://www.nytimes.com/2007/12/26/movies/26alie.html). What is the deal with this? I can work around it by manually getting the correct info, but it's just really weird that it does that. -- Brainy J ~✿~ (talk) 17:42, 21 July 2013 (UTC)

This works for me. Does it happen to any other URL? --  Gadget850 talk 18:06, 21 July 2013 (UTC)

Inappropriate locations for WP:Article feedback questionaires.

Wikipedia:Featured_picture_candidates/Fanous_Ramadan.jpg is currently giving me a "Did you find what you were looking for?" questionnaire.

This is, of course, a completely invalid question on that sort of page. Is there anything we can do? Adam Cuerden (talk) 19:21, 21 July 2013 (UTC)

It can be changed on a per-page basis (I did it for that page), but I'm unaware of a way to do it for all subpages of WP:FPC. Prodego talk 19:38, 21 July 2013 (UTC)
Can a category be added or the like? FPC is set up by way of a template. Adam Cuerden (talk) 20:24, 21 July 2013 (UTC)
It's adjusted as page protection, so there is no way to do it on multiple pages except to have a bot do it. Prodego talk 01:41, 22 July 2013 (UTC)

There's a preference to turn it off (Appearance -> Don't show the Article Feedback widget), though it is concerning that this is popping up more recently. You could ensure it stays off for all future FPC noms by adding the category (Category:Article Feedback Blacklist) to Template:FPCnom. MER-C 03:54, 22 July 2013 (UTC)

Red Links

Hi all

I am user:Elph from ar.wiki. We need a list of red links in our FA articles. we can get red links by below SQL query but we can't separate it by article. Is there some one who has any idea to help us?

SELECT /* SLOW_OK */ DISTINCT pl_title,pl_namespace FROM pagelinks INNER JOIN page ON pl_from = page_id WHERE pl_title NOT IN(SELECT page_title FROM page WHERE page_namespace = 0) AND pl_namespace = 0 AND page_namespace = 0;

Thanks in advance.--عباس‎ ☢ ✉ 15:51, 20 July 2013 (UTC)

I used the query
select p1.page_title as FA, pl_namespace as "link ns", pl_title as "broken link title" from categorylinks inner join pagelinks on cl_from = pl_from inner join page as p1 on p1.page_id = pl_from left outer join page as p2 on p2.page_title = pl_title and p2.page_namespace = pl_namespace where cl_to = "مقالات_مختارة" and p2.page_namespace is null;

It generated the following 11 983 links: http://tools.wmflabs.org/bawolff/arwiki_broken_links_in_FA.txt Bawolff (talk) 22:11, 22 July 2013 (UTC)

New page patrol bar has disappeared

I am unable to patrol new pages all of a sudden. SL93 (talk) 01:01, 21 July 2013 (UTC)

It now says "Mark this page as patrolled". Did something change? SL93 (talk) 01:05, 21 July 2013 (UTC)
Are you using Special:NewPages or Special:NewPagesFeed? The latter works for me. When using the old special page, the "Mark this page as patrolled" link appears briefly and then disappears and the new review sidebar appears. Im not sure if that is normal or not. John Vandenberg (chat) 09:41, 21 July 2013 (UTC)
I was using NewPagesFeed. It still isn't there. SL93 (talk) 02:11, 22 July 2013 (UTC)
Works for me currently, with Firefox 22. Which browser do you use? Is there any output in the JavaScript console of your browser when it fails loading? --AKlapper (WMF) (talk) 07:54, 22 July 2013 (UTC)

Tech News: 2013-30

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

Recent software changes (Not all changes will affect you.)

Future software changes

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

21:03, 21 July 2013 (UTC)

I have created a tracking bug for non-English Wikipedia issues with VisualEditor: bugzilla:51792. (11 problems so far, though some are unconfirmed or may be fixable on those wiki with small changes to templates.). The RTL/bidi/i18n problems are far from resolved too: bugzilla:33126 & bugzilla:33077. John Vandenberg (chat) 08:19, 22 July 2013 (UTC)

Trying to fix Template:Ref Ethiopia

I've been trying to fix what looks like a simple template programming error in Template:Ref Ethiopia. It looks like it should be a simple "if" statement checking some parameters and passing them to {{cite book}}, but it does not seem to be working. I have purged cite book and the Lua module on which it depends, and I've tried a few fixes in my sandbox, but I haven't been able to make it better. If you look at the template, the error message is pretty clear. Passing the "pages" and "chapter" parameter to cite book is not working.

This template is used in about 60 articles (and is generating red text errors in the citations of many of them). Its brother, Template:Ref Stockholm, is used in about a dozen articles.

Anyone want to have a go at fixing it, or suggest what I'm missing? Jonesey95 (talk) 05:21, 22 July 2013 (UTC)

I've edited both templates. Any good? -- John of Reading (talk) 06:50, 22 July 2013 (UTC)
Great work! You fixed red errors in 70+ articles. Thanks. Jonesey95 (talk) 13:45, 22 July 2013 (UTC)
Resolved

Images showing as orphaned when they are not

For example File:FredFrith VHScover StepAcrossTheBorder.jpg and File:Michel Hollard.jpg show no article namespace usage, yet they are used in Step Across the Border and Michel Hollard respectively. This is resulting in orphan-tagging bot false-positives. —Bruce1eetalk 09:53, 22 July 2013 (UTC)

Already raised at Wikipedia:Help_desk#Spurious_Orphaned_non-free_media_emails_? and Bot turned off. Arjayay (talk) 10:04, 22 July 2013 (UTC)
Also discussed at Wikipedia:Administrators' noticeboard/Incidents#Hazard-Bot false positives flood. But considering the error is in Wikipedia's link tables and not the bot, posting the bug here seems sensible. At the moment, neither File:Michel Hollard.jpg#filelinks nor Special:WhatLinksHere/File:Michel_Hollard.jpg shows Michel Hollard although the image has been non-stop in the infobox for years, and the article hasn't been edited since 2 March. A null edit of the file might fix it but others may want to examine the situation first. PrimeHunter (talk) 10:27, 22 July 2013 (UTC)
The image has just now shown up at the linked lists. PrimeHunter (talk) 10:29, 22 July 2013 (UTC)
I've done null edits on Step Across the Border and Michel Hollard and the respective files now show they are used in those articles. —Bruce1eetalk 10:34, 22 July 2013 (UTC)
That's another two fixed, but the bot tagged over 1500 non-free images before it was blocked. And since we don't know the cause yet, it seems safe to assume that the file usage for free files may have been damaged as well. -- John of Reading (talk) 12:11, 22 July 2013 (UTC)
The key is to do a null edit on the article where the file is used. The last time this happened, you had to do a purge on the file description page. Editors have been reverting the notices on the file pages, which is going to make harder to find the falsely orphaned files. --  Gadget850 talk 13:45, 22 July 2013 (UTC)

Mobile version, Main Page

At Talk:Main_Page#Mobile_main_page_lacks_Did_You_Know.2C_On_This_Day.2C_and_the_featured_picture_sections, a new User:Maloof200 has complained that the Main Page on the mobile version has only TFA and ITN and lacks DYK, OTD, FP, FL. User:Crisco 1492 comments there that its likely for conserving bandwidth. Is that the reason? In such case, can we at least have links to these sections so that users can choose and read if they wish to?
Also, is this the right forum; or are mobile version's issues handled somewhere else? §§Dharmadhyaksha§§ {T/C} 07:11, 18 July 2013 (UTC)

Yes to a large degree it was limited to those 2 sections to basically make the main page as fast as possible on mobile (I'm talking 4 years ago now). To a large degree, that still holds. A clean, slim frontpage on your mobile device is simply a good idea, and let's be honest, how often do you read 'below the fold' when you open up Wikipedia to start searching for something ?
As to how it actually selects this content: The MobileFrontend first looks for blocks with the IDs #mp-tfa, #mp-itn and will then append any block with an ID that starts with #mf-. The #mf- logic is explained here and is considered to be the 'official' way to define which blocks you want in your frontpage. —TheDJ (talk • contribs) 09:58, 18 July 2013 (UTC)
Loading speed is a very powerful reason to keep it short & sweet. I don't know what the original proposer had in their mind. But for me; i hardly read TFA. There could be some people like me out there who are more interested in DYKs or others. Can't we at least provide a link to them on the main page itself? §§Dharmadhyaksha§§ {T/C} 10:51, 19 July 2013 (UTC)

I would personally welcome a redesigned homepage that showed all information. loading speed is actually not much of a concern here (I develop the mobile site)...Jdlrobson (talk) 22:43, 23 July 2013 (UTC)

IP editor in ur base killin ur d00dz

Tracked in Phabricator
Task T53862
Resolved

I made an edit and my IP address is showing up as 208.80.154.75 (talk · contribs · WHOIS). A quick check reveals that this IP address is allocated to ... the Wikimedia Foundation in San Francisco. A quick check of my surroundings reveals that I am not located at Wikipedia headquarters. Just curious how this occurs. Thanks, 208.80.154.75 (talk) 08:21, 23 July 2013 (UTC)

You shall be blocked, IP, FOR GREAT JUSTICE as an equivalent to an open proxy. Incnis Mrsi (talk) 08:50, 23 July 2013 (UTC)
Nope, that's software problem, the IP is caching server. There was a similar issue already, see bugzilla:48919. Lazowik (talk) 10:24, 23 July 2013 (UTC)
Well, that was quick: resolved :) Lazowik (talk) 10:51, 23 July 2013 (UTC)
  • See, a title like that is how you draw attention. Not necessarily good attention, but attention. — Crisco 1492 (talk) 10:29, 23 July 2013 (UTC)

Dab solver bug

Dab solver just broke a page on which I used it. I was (not through choice) using IE 8. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:54, 23 July 2013 (UTC)

You can post to WP:dabsolver. Are you sure it was dab solver? If it happened after you clicked Show preview or Show changes then another tool may have interfered with a bad search and replace. PrimeHunter (talk) 12:23, 23 July 2013 (UTC)
I'd go with dab solver; it looks very like this problem. --Redrose64 (talk) 15:54, 23 July 2013 (UTC)

Job queue / Updating links tables when a template changes

I changed a link in a template over 16 hours ago, but the links table doesn't seem to have got updated: Special:WhatLinksHere/Yantra_Mantra still shows all the articles that contained (because of the template transclusion) links to the page before the change. Is the job queue stuck or something? Shreevatsa (talk) 12:34, 23 July 2013 (UTC)

I don't think it's stuck; the job queues were moved from one set of servers to another, and I think they changed the job queue code so that the link tables are only updated if the transcluding pages are themselves edited, which defeats the purpose of the job queue. Not sure if a WP:PURGE is sufficient, or whether it needs to be a full WP:NULLEDIT. --Redrose64 (talk) 13:41, 23 July 2013 (UTC)
I see. That's inconvenient. Thanks for informing me; I've made null edits on those pages and it's fixed now. Both Help:What links here and [74] and Help:Job queue currently have wrong information then... is there some reference to this code changing, so that those pages can be updated? Shreevatsa (talk) 14:10, 23 July 2013 (UTC)
No. An edit to a page will trigger a links update for the job queue for all pages including that page (and all pages including the including page). What changed was that a null edit to a page only triggers a linksupdate on the page being nulledited (where before it did linksupdate on all including pages). This is because people were mass null editing pages just to get the current page updated, and it was overloading the job queue with recursive jobs, so it worked for nobody. To repeat, the behaviour of what happens during a normal edit has not changed. Bawolff (talk) 15:48, 23 July 2013 (UTC)
Is it gerrit:72679? Helder 15:51, 23 July 2013 (UTC)
@Bawolff: Thanks. Unfortunately I null-edited all the mentioned pages already so it's hard to debug now what had gone wrong in this instance. After some 16.5 hours, the set of links had not been updated at all, and I think this is not typical behaviour because in the past (years ago, admittedly) I've seen WhatLinksHere get updated more quickly after a template is edited. Shreevatsa (talk) 16:25, 23 July 2013 (UTC)

Pywikipedia is migrating to git

Hello, Sorry for English but It's very important for bot operators so I hope someone translates this. Pywikipedia is migrating to Git so after July 26, SVN checkouts won't be updated If you're using Pywikipedia you have to switch to git, otherwise you will use out-dated framework and your bot might not work properly. There is a manual for doing that and a blog post explaining about this change in non-technical language. If you have question feel free to ask in mw:Manual talk:Pywikipediabot/Gerrit, mailing list, or in the IRC channel. Best Amir (via Global message delivery). 13:06, 23 July 2013 (UTC)

Prototype for a new referencing tool... what do you think?

Hi, everybody. I've hacked together a working prototype of something that is like an improved WP:Reftoolbar (the dialog thing that allows you to fill out a form to insert citation templates into articles for things like books, journals, newspapers, or websites). At the moment my prototype is completely self-contained and does not "connect" yet to Wikipedia. I've pasted the full HTML file on pastebin if you wish to download and try it out. Just download and load the file into your browser (it seems to work well on up-to-date Firefox, Chrome, and Opera but I haven't tried Internet Explorer yet), there's a mock Wikipedia source editor. You'll have to pretend it's Wikipedia. The demo is only for "cite book". Creating the other three ("cite journal", "cite news", and "cite web") would be fairly easy starting with this code.

I'd be interested what people think about it in general. How they think it compares to the present WP:Reftoolbar. The main feature is that you can dynamically add authors and editors, which is really cool. There's also some error checking on certain fields. I plan on adding more. I have added a lot of references to Wikipedia articles, and I tried to let that experience guide me in designing the form. There's a certain level of complexity to the cite templates that makes a form-based interface difficult to design. I've tried to make the form as self-explanatory as possible, but there are a few potentially confusing aspects, especially for someone not already familiar with the cite templates. The current Reftoolbar has the same issues but I think I've improved the situation.

I plan on continuing to scrutinize, refractor, and encapsulate the code trying to improve the design and so forth. I think I've gotten the usability down as well as I can but so far I've only been using one other person for feedback. Under the hood, I think the code is fairly clean but there's still room for improvement here and there. If after seeing it, you'd like to collaborate on the code, let me know. I'd really be interested in design improvements relating to the CSS. For example, the code of the form uses a lot of <br style="clear:both;" /> that seem like they should be unnecessary but need to be there or they cause layout issues related to floating elements. At some point I'll need to figure out how to "plug it in" to the WikiEditor. I spent a large amount of time trying to do this on an old abandoned prototype but failed. Hopefully I'll be successful next time. Jason Quinn (talk) 07:58, 19 July 2013 (UTC)

Anybody willing to try this and tell me what they think? I think it's got a lot of potential and is really the sort of thing that Wikipedia needs. Perhaps there's a better place to post this but seems like a decent enough spot. Jason Quinn (talk) 14:52, 20 July 2013 (UTC)
This is indeed a nicely-presented dialog for creating a book citation and it generates tidy source. I will keep the html in my directory in case I need to use it. I imagine integrating it into Wikipedia will be a great deal of work, this may be a bit late now given the gradual rollout of a generic template editor for VisualEditor. The date format dropdown gives two non-MOS formats (with leading 0 for the day) which might seduce users to add incorrectly formatted citations and does not provide ISO which would be needed for accessdates etc in some articles, particularly when extending to cite web etc. --Mirokado (talk) 15:59, 20 July 2013 (UTC)
Thanks Mirokado. You are right. I quickly added the date formats and made a mental note that I should put more thought into what formats need to be there. Until now I forgot to return to it. It's now written in my todo list so I don't forget. As for integrating the dialog form into Wikipedia, on the contrary, it should be somewhat easy to add to the default editor or even replace the Reftoolbar. (I say "should" because adding a button is supposed to be easy with Wikieditor; however, I tried to do this already with a previous, now abandoned, form. I couldn't get it to work and got frustrated and gave up. I find it disturbing that such a supposedly user-configurable and crucial item of the interface is badly under-documented. I tried contacting some devs about this but got no response.) Once I get more useful feedback such as yours, I will incorporate any necessary changes. I will then attempt again to integrate this new form again into the Wikieditor for my own account as personal javascript as the next phase. There's one really important feature missing from my form, which is automatic completion of fields based on things like ISBN numbers. This must to be added but I will have to learn a bit more web-fu to do it. There's a chance that I will eventually update the reftoolbar to a new version based on this code base. As for the VisualEditor, no comment lest I get carried away with my emotions. It suffices to say that this little project of mine represents the type of tools that I think the WMF ought to have been developing. Jason Quinn (talk) 16:31, 20 July 2013 (UTC)
How does someone upload something into their browser? I have VE disabled as it does not support a proper reftoolbar. Does your version have auto fill? This is by far the best feature of the old one. Doc James (talk · contribs · email) (if I write on your page reply on mine) 19:17, 24 July 2013 (UTC)
You have to download the file and then use "open file" from your browser. It does not yet support auto-completion. This is a mock-up. It is not intended for current use but just for feedback. There seems to be little interest though. Jason Quinn (talk) 20:28, 24 July 2013 (UTC)
All I see is a screen full of text. Do you have pictures of what it looks like? What are the benefits over the current version? Doc James (talk · contribs · email) (if I write on your page reply on mine) 02:59, 25 July 2013 (UTC)
@Doc James Open a new/blank textfile in notepad. Copy the code portion from the pastebin link, and paste it into your textfile. Save that as test.html and then open it from your browser. :) It looks like this, before clicking the "[Show/hide extra fields]" button.
@Jason Quinn: I'm interested, just quiet! (Us attentive-listeners make a terrible 'net-audience...) Personally I tend to use cite-gen more than reftoolbar, because I'm most frequently referencing articles/papers via URLs, or fixing deadlinks. However, I didn't realize our reftoolbar had ISBN autocomplete now - I'd been using ottobib for years - so that's good to know!
On-topic (In your prototype) -
  • I like the phrasing of the tooltip explanations/reminders - However, you might want to change the display method, perhaps with the further-info links (?) for refname/refgroup, as that's what the current reftoolbar uses for a tooltip-indicator. I understand why you didn't want ? next to every field-title, but I'm not sure the "user discovery needed" is worth the aesthetic improvement.
  • The "either/or" choices, such as "page/pages" and "date/monthyear" could be more clearly indicated. (whether through spacing, or linebreaks/rearrangement, or markers of some sort, or something else.)
  • As you and Doc James say, autocomplete of DOI/ISBN/PMID are must-haves. Autocomplete of WWW might be nice, but cite-gen gives wildly inconsistent results, so that's probably best left separate (maybe a link to it, with tooltip'd disclaimer?).
  • The "preview" and "parsed preview" of the current reftoolbar are also must-haves.
  • The date-wizards are nicely done, especially the "datepicker-format" aspect. Perhaps that could check the article for the existence of a {{Use dmy dates}} or {{Use mdy dates}} and set itself automagically?
Hope that helps. –Quiddity (talk) 05:34, 25 July 2013 (UTC)

Editor for TemplateData

Editor for TemplateData

Hi, I've translated a gadget created on frwiki to visually edit TemplateData. It's available at User:NicoV/TemplateDataEditor.js. To use it, simply add importScript('User:NicoV/TemplateDataEditor.js'); in Special:MyPage/skin.js. --NicoV (Talk on frwiki) 23:04, 19 July 2013 (UTC)

More explanations at User:NicoV/TemplateDataEditor. --NicoV (Talk on frwiki) 05:01, 20 July 2013 (UTC)
This is really useful! @Okeyes (WMF): Worth a look :) Theopolisme (talk) 05:42, 20 July 2013 (UTC)
I've amended the instruction, since Special:MyPage/vector.js won't work for Monobook (etc.) users. The link Special:MyPage/skin.js automatically goes to the relevant .js file for your current skin.
But, it can be simpler. Does it work in all current skins (Cologne Blue, Modern, Monobook, Vector)? If so, the place to put it would be Special:MyPage/common.js; then, if you change skins, the script does not need to be reinstalled for the new skin. --Redrose64 (talk) 07:20, 20 July 2013 (UTC)


Ltrlg has modified TemplateDataEditor in frwiki, including several suggestions and adding a way to easily translate the tool in many languages. So, it can now be used from every wiki. If you want to contribute to translations, I think the best way is to propose translations at fr:Discussion utilisateur:Ltrlg/scripts/TemplateDataEditor.js, the messages to be translated are at the beginning of fr:Utilisateur:Ltrlg/scripts/TemplateDataEditor.js (the "messages"). --NicoV (Talk on frwiki) 11:37, 24 July 2013 (UTC)

Offputting message

Hi, when I go to http://en.m.wikipedia.org/wiki/Main_Page, I see two sections "Today's featured article" and "In the news", both apparently intended to be updated at least daily, and at the bottom is a message "Last modified 1 month ago", which makes it look as if the site is unmaintained. I suggest this is fixed or removed. 86.171.174.107 (talk) 20:37, 20 July 2013 (UTC)

That message only appears on the mobile site, you will see nothing at http://en.wikipedia.org/wiki/Main_Page. Unfortunately, the mobile site is maintained by a separate group from us at English Wikipedia. The main page itself was last modified here (about a month ago), but the content is changed daily. Chris857 (talk) 21:03, 20 July 2013 (UTC)
Oh, thanks. How does one communicate with the people who maintain the mobile site? 86.171.174.107 (talk) 21:50, 20 July 2013 (UTC)
I can't remember, and can't find it for the life of me. Hopefully someone else will come along who knows. Chris857 (talk) 22:13, 20 July 2013 (UTC)
Help:Mobile access#Mobile version of the site has some options ("Report a new bug" doesn't work). The displayed content of Main page is updated daily but the updated parts are stored in templates and transcluded onto the main page. The source code of the main page itself is rarely updated. "Last modified" shows when the source code was updated and not the displayed content in case of transclusions. This is the same for all our millions of pages. The normal (non-mobile) English Wikipedia hides "last modified" for the main page with code in MediaWiki:Vector.css – or MediaWiki:Monobook.css or MediaWiki:Modern.css for registered users with other skins. MediaWiki:cologneblue.css doesn't have the code for some reason so http://en.wikipedia.org/wiki/Main_Page?useskin=cologneblue says "last modified on 17 June 2013". Many foreign language Wikipedias also use our system of rarely updating the main page source code, but don't hide "last modified" for any users. For example, fr: (French) says 9 March 2013, and da: (Danish) says 27. december 2008. PrimeHunter (talk) 22:41, 20 July 2013 (UTC)
Most ordinary readers will not be aware of this subtlety. It isn't such an issue for articles, firstly because the message is not at all prominent and secondly because most article updates affect the page source itself. It is particularly a problem in the case I mentioned, firstly because the message is prominent, and secondly because most main page updates do not affect the page source, and hence the page always appears to be stale even when it has been updated recently. 86.171.174.107 (talk) 22:49, 20 July 2013 (UTC)
I agree. That's why we normally hide it but the mobile main page is controlled by others. I have also suggested to the Danish Wikipedia that they hide it. Last modified in 2008 sounds bad. PrimeHunter (talk) 23:09, 20 July 2013 (UTC)
@Jdlrobson: @Jon (WMF): This discussion might interest you. — This, that and the other (talk) 06:43, 21 July 2013 (UTC)

The block does appear on the non-mobile front page (view the source), however the block "footer-info-lastmod" is hidden with CSS. The same needs to be done for the mobile site, in MediaWiki:Mobile.css. John Vandenberg (chat) 09:47, 21 July 2013 (UTC)

Done. — Edokter (talk) — 09:58, 21 July 2013 (UTC)
Confirmed! Nicely done. And thanks 86.171.174.107 for reporting the problem. John Vandenberg (chat) 11:13, 21 July 2013 (UTC)

Thanks for alerting me to this message. I will make sure a bug gets raised and this fixed. I'd advise not hiding this message on mobile as by doing so you are breaking the license requirements as this is the link to the history page. The problem is that it is not paying attention to changes to the underlying templates... Jdlrobson (talk) 22:40, 23 July 2013 (UTC)

I removed this to avoid legal troubles. I would really value your opinions on what the behaviour should be on the main page. Could we style it differently e.g. use a clock icon, change the text to View history? Any other ideas? https://bugzilla.wikimedia.org/show_bug.cgi?id=51924 Jdlrobson (talk) 18:56, 24 July 2013 (UTC)

Remarkably interesting reading

I think that just about anyone concerned with technical issues will find meta:Research:VisualEditor's effect on newly registered editors/Results to be absolutely fascinating reading, and maybe a little jaw-dropping. --Tryptofish (talk) 17:47, 23 July 2013 (UTC)

Indeed, absolutely fascinating. Theopolisme (talk) 18:08, 23 July 2013 (UTC)

VE seems like wikitext editor except to power users: The wikitext editor is also a "visual editor" of sorts, with similar word-wrapped text, but also markup mixed into the text, plus templates and wikitables. I was also intrigued by the study (Friday-Sunday, June 28-30, 2013), with the massive sample sizes: 9,570 new usernames running wikitext editor, versus 9,575 running VisualEditor. So, even though the edits spanned only 72 hours, it was interesting to see the spread from 1-to-100+ edits, with both VE & wikitext editor at similar usage levels until the large edit-counts. With such large samples, the margin of error at 95% confidence level, gives ~1.00% (0.98/97.826).

As could be expected, beyond a high level of edits, then use of the wikitext editor ran even higher as a tool for power users to run longer edits, once the productivity was recognized. Because only about 12 editors, out of 9,570, continued using the wikitext editor far beyond 5 hours, then the trend is tentative, but even if those 12 new usernames were former IP or other usernames, re-registered, they edited longer than VE users. Anyway, it would be interesting to see if longitudinal studies (longer-term) will show more users are reaching a similar hour of VE edit-burnout, while other editors feel empowered, energized by the wikitext editor, to continue editing more than 7 hours during each 72-hour period, or perhaps people edited less during the two weekend days, as typical.

In some ways, the results of the 72-hour study are very confusing, because "1,502" VE new users exceeded 1 edit, while "2,629" new wikitext-editor users logged more than one edit, but most of the edit-count graphs, with these logarithmic scales, give the impression of both having similar edit-counts per user. Perhaps the edit-counts also count non-Saved edits. Or perhaps if the draft report were to be updated, then revised graphs would reveal the larger differences. When the report noted how 43% fewer VE edits were saved, then I thought, "Well, many new people did not realize to click the SAVE button" but also I wondered, "How many just used VE to experiment and show other text, but had no intention to save those changes?" (less saving of hack edits). -Wikid77 (talk) 06:16/14:51, 24 July 2013 (UTC)

Hours of editing (control = wiktext editor, test = VE).

Count of productive edits, at logarithmic scale: 1, 2, 3, 6, 10, 18, 32, 56, 100 edits. The plotted data seems to show similar activity, but VE usage lower between 18-56 edits (control = wiktext editor, test = VE).

This is for newly registered users; is there anything similar to this research for unregistered (/anonymous) users? The data would be much more noisy of course, but I'm wondering what has been collected. Shreevatsa (talk) 13:04, 24 July 2013 (UTC)

  • Other data confirms IP editors seem "mostly" experienced: It has taken a while, from patching together other data, but the VE-usage patterns of IP editors have been similar to long-term usernames, while different from the average of new usernames. Other data shows IP editors (on average) to exhibit long-term behavior (but often short edit-histories), as would be expected when a username often forgets to log-in, and rotates to perhaps one of 255 dynamic IP addresses during the month/year (of billions of IP numbers). So, the same person could be 10-90 different IP editors all month, and that is a huge distortion compared to a laboratory user running from the same machine IP address all month. One unlogged-in username can skew the IP-editor patterns at that 10x-90x (or more) ratio, versus a new person with a single IP machine who started this week. So, how could the average IP-editor activity look like anything but long-term usernames, when each single, busy non-logged-in user can appear to be hundreds of IP editors in rotation? I think, by "mathematical elimination" the average of IP editors cannot reflect new editors very much, when busy editors are so many different IPs per month. Hence, by deduction, IP-editor averages will be mostly the same as long-term usernames. Make sense? If you want me to derive Pythagorean triples or Fermat's last theorem, it will take longer (just kidding). -Wikid77 14:51, 24 July 2013 (UTC)
  • Looks the the VE is counter productive at worst and no different at best.
    A significant issue that is bizarrely missing from that report is whether editors choose to use the VE or the "old" editor. VE-enabled editors can choose to use either the VE or the "old" editor. From analysis it looks like ~5% of experience user, ~15% of anonymous users, and ~45% of newly registered users use the VE. --RA (✍) 15:18, 24 July 2013 (UTC)
Just thought, the near 50% rate for newly registered users using the VE may indicate a random-selection bias i.e. users are unsure whether to click "Edit" or "Edit source" so they click one at random and so approx. 50% click each. If so, it would appear that as users learn the difference between the two (i.e. experienced users and IPs) they choose the "old" editor over the VE. --RA (✍) 15:31, 24 July 2013 (UTC)
If truly new (inexperienced) users are split on which editor they use, and experienced editors massively favor the old editor, the numbers suggest that about 2 out of 3 anonymous IP users are "experienced". Or possibly just quick learners. It might be interesting so see how long new or anon. users take to develop a preference. ~ J. Johnson (JJ) (talk) 21:12, 24 July 2013 (UTC)
  • Speaking for myself, I shut the Visual Editor off instantly the moment the wave of bug complaints started. Later I signed out and did a couple simple edits as an IP just to see it. Then I signed back in and won't use it again this year at least... Carrite (talk) 02:57, 25 July 2013 (UTC)

I Am Having A Problem With Book Creator

I am experiencing problems with the Book Creator. I just compiled a book: User:Jason Palpatine/Books/History of Israel. My attempts at downloading have failed just like with another article I had you delete earlier. When I try to download it, the system responds:

File not found
From Wikipedia, the free encyclopedia
The file you are trying to download does not exist: Maybe it has been deleted and needs to be regenerated.

Is there anything you can do about this problem? -- Jason Palpatine (talk) 21:19, 23 July 2013 (UTC) This User fails to understand Wikipedia's Systematized Logistical Projection of its Balanced Policy Contingency. (speak your mind | contributions)

I clicked your link and then "Download PDF". It took about 10 minutes to gather and render and then I was presented with "The document file has been generated. Download the file to your computer." Clicking the download link downloaded a 180 MB PDF file. --NeilN talk to me 21:37, 23 July 2013 (UTC)
Thanks. I'll try it again. Jason Palpatine (talk) 15:44, 24 July 2013 (UTC)

Fully protected pages showing semi protected edit notice

If I view source on a fully protected page, such as Template:Column-width, it says "You do not have permission to edit this page, for the following reason: This page is currently semi-protected and can be edited only by established registered users." However, that page is fully protected (and I am logged in), so that notice is misleading and incorrect:Jay8g [V•T•E] 03:59, 24 July 2013 (UTC)

Confirmed. This edit should fix it. --Redrose64 (talk) 08:48, 24 July 2013 (UTC)

Move confirmation confusion

Tracked in Phabricator
Task T47348

After a move a message pops up "the creation of a redirect has been suppressed" or "a redirect has been created". But these are the wrong way round - it says "suppressed" when one has been created and vice versa. — RHaworth (talk · contribs) 16:13, 24 July 2013 (UTC)

This is bugzilla:45348: moving a page with suppressredirect produces misleading message "A redirect has been created". PrimeHunter (talk) 21:23, 24 July 2013 (UTC)

Quantitative data are in for the Visual editor.

According to meta:Research:VisualEditor's effect on newly registered editors/Results, the A/B test showed that new users using wikimarkup made more edits, more "productive edits", spent more time editing, and were far more likely to start editing than those started with the VisualEditor. "Newcomers with the VisualEditor were ~10% less likely to save a single edit than editors with the wikitext editor."

Now, of course, the results are highly biased by the fact that VisualEditor was (and, although some progress has been made, is) feature-poor, buggy, and problematic. Adam Cuerden (talk) 17:01, 19 July 2013 (UTC)

Any data on experienced users? I'm especially curious to see what percentage have disabled it. postdlf (talk) 19:08, 19 July 2013 (UTC)
Wikipedia:VisualEditor/Feedback#Some performance notes shows that roughly 90% of all edits by long-term editors or IPs are made with the source editor. We've seen an 8.6% decline in the number of anonymous edits. The only group that shows any signs of embracing the new editor are newly-created accounts, and they still use the source editor by a 2:1 margin. Wikipedia:Database reports/User preferences shows that 1302 accounts have completely disabled VE, up 30% since last week.
I suspect, but cannot prove, that the reason IP edits are down is that some of our more profilic IP editors have chosen to create accounts in order to disable VE. The most interesting thing about these statistics is that they show that while people with new accounts are a distinct group, IP editors and established editors are acting in extremely similar fashions. This suggests that most IP editors aren't inexperienced at all.—Kww(talk) 19:28, 19 July 2013 (UTC)
The 1302 number might not be complete. For example, you can easily block Visual Editor using Adblock Plus. I'm using that variant as it seems to be a bit faster, although I also have the gadget switched on in case I'm editing from some other computer. Using the gadget, the Visual Editor shows up but quickly hides. On the other hand, using Adblock Plus, the Visual Editor doesn't show up at all (i.e. it's completely blocked). --Stefan2 (talk) 23:26, 19 July 2013 (UTC)
User:Dragons flight assembled some data at Wikipedia:VisualEditor/Feedback#Some_performance_notes. I'll paste it in here. Adam Cuerden (talk) 19:32, 19 July 2013 (UTC)

Data from Dragons flight (copied from Wikipedia:VisualEditor/Feedback#Some_performance_notes) Looking at the last two days (16 and 17 July) we see:

All registered user article edits using source (wikitext) editor 118,380 91.1%
All registered user article edits using VE 11,464 8.9%
New user (registered on or after 1 July) article edits using source 6,610 64.2%
New user article edits using VE 3,678 35.8%
Anon article edits using source 62,101 88.4%
Anon article edits using VE 8,153 11.6%
Older editor (registered prior to 1 July) article edits using source 111,770 93.5%
Older editor (registered prior to 1 July) article edits using VE 7,786 6.5 %
Change in total (daily) article edits since before VE became default on 1 July (comparison: 18-30 June) -4.5%
Change in registered user article edits since before VE became default -2.2%
Change in anon article edits since before VE became default -8.6%

I'd prefer to let others comment on the data at this time. Adam Cuerden (talk) 19:38, 19 July 2013 (UTC)

  • July often has 2% lower activity each year: Along with June each year, the month of July has typically been lower in editor activity than April of the same year. July activity might rise near month end, to offset earlier wikibreaks. If the July-total edits are down -7% or more (for edits-per-month levels), then that would be very unusual, especially since many of us are double-editing numerous pages (400 per day, 12,000 per month?) to remove nowiki tags added during VE confusion. -Wikid77 23:57, 20 July 2013 (UTC) — Preceding unsigned comment added by Wikid77b (talk • contribs)
July is indeed a "trough" month, one needs to compare numbers to the comparable period for the previous year to correct for normal seasonal variation. Carrite (talk) 20:59, 25 July 2013 (UTC)

Is the signing error ever going to be fixed

Tracked in Phabricator
Task T53939

Over the years I have not used the signing tool that many times because I haven't edited or added to Wikipedia that many times but when I have it seems like every single time I have signed it and then right after that the auto-signer says you haven't signed it so I did it for you. This also often causes other problems such as formatting issues such as my latest question on moka pot coffee maker talk was in a gray box that made it all into one line that was longer then the width of the page. In the history you can see the SineBot mark the page yet clearly it is already signed.

http://en.wikipedia.org/w/index.php?title=Talk:Moka_pot&oldid=565522704 — Preceding unsigned comment added by Tumaru (talk • contribs) 20:18, 23 July 2013 (UTC)

The bot is working correctly, it's you who is not signing properly. Your signature needs to have a link to your user page or talk page otherwise it is useless - which is why you need to sign with the sig button or 4 tildes. If you are doing that then you must have edited the default setting in your Special:Preferences--Jac16888 Talk 20:24, 23 July 2013 (UTC)


When I sign something I use the tool at the top of this visual editor to the right of bold and italicize. If that doesn't work then I'm not going to figure out how to "properly" because either the tool should work or shouldn't be there. Also yes I did forget to sign the comment about the autosigner.--tumaru 20:44, 23 July 2013 (UTC)

The easiest way to get a valid signature with a link to your user page is to uncheck "Treat the above as wiki markup" at Special:Preferences. The grey box in [75] is caused by a line with a leading space. Don't use leading spaces unless you want that formatting. You can indent with colons, but we don't indent the first post in a section. PrimeHunter (talk) 20:45, 23 July 2013 (UTC)
@Tumaru: Just to be absolutely clear: (1) You customized your signature, in your Preferences. (2) Your customization violated the requirement that your signature contains an internal link to one of your user pages; (3) Because you did not follow this requirement, what you consider "signing" a post in fact is not acceptable, so a bot is coming along to compensate for your errror; (4) Your clicking on the "Signature and timestamp" icon, in the toolbar, does not (somehow, magically) fix the error you made when you customized your signature; it just posts your (erroneous) code to the page you're on. The tool is working properly - it's just the messenger, and you're blaming it, rather than accepting that you made a mistake and you can fix that mistake. (5) You can deal with this problem by (a) unchecking a preference box, as stated above, and going back to a standard signature, or (b) changing your signature, in your preferences, to comply with WP:SIG. If you want to do customization, you might look at Wikipedia:Smurrayinchester's signature tutorial. -- John Broughton (♫♫) 03:07, 24 July 2013 (UTC)
@John Broughton: I've actually encountered several people with this problem who almost certainly didn't change that preference on their own accord. For example, see this message and especially this one. Graham87 08:42, 24 July 2013 (UTC)
I've filed bug 51939 about this issue. Graham87 09:37, 24 July 2013 (UTC)
Tumaru signs as tumaru with lower case t. That indicates they entered tumaru in the signature field at Special:Preferences, and then it's an easy mistake for an inexperienced user to also checkmark "Treat the above as wiki markup". The explanation about when to check it is a bit technical, and so long that many probably skip it. User talk:SineBot#FAQ describes the error but many users don't find that page when Sinebot complains like at User talk:Tumaru#Your recent edits. User talk:slakr#Suggestions for sine bot has some good suggestions for better Sinebot messages. PrimeHunter (talk) 11:24, 24 July 2013 (UTC)
Aha, I didn't notice the lower-case. The same is true for Boonshofter (linked above) and also (with other customisations) for [Theattackcorgi (linked in the Bugzilla report). (By the way, screen readers don't indicate the case of words unless you ask them to ... which is exactly the way it should be!) You are probably right that it's easy to misclick it by accident – we used to get similar problems with users who had unwittingly clicked the "Use external editor" preference. The problem with the errant signatures will go away when Flow is introduced. I'm so glad it's infinitely more likely to be a usability problem than a database issue! Graham87 13:00, 24 July 2013 (UTC)
@Graham87: - I see. Sorry, my mistake; I'll try to avoid rushing to conclusions in the future. -- John Broughton (♫♫) 15:33, 24 July 2013 (UTC)

@PrimeHunter Thank you I don't have the concentration or patience to read every technical document on Wikipedia since I'm only making very small changes and not very often. Every technical document being an exaggeration because I don't know which ones I should read and which ones I shouldn't bother with. I just read the bit under the signature about treat signature as wiki markup and it didn't say anything about breaking the signature or don't do if your a noob and don't know what your doing. I'm sorry for my inexperience and lack of research but just imagine how many people are just ignoring the error.--tumaru (talk) 17:18, 25 July 2013 (UTC)

Don't worry Tumaru - most "new" users don't change their signature style under preferences until a bit later in their "career". By then, most of the recognize that a "T" and a "t" are two verrrrryyy different characters to the eye of a computer (✉→BWilkins←✎) 17:32, 25 July 2013 (UTC)

Editing coming to mobile site

The WMF mobile features team is happy to announce that editing will be enabled on all Wikimedia mobile sites (e.g., en.m.wikipedia.org) as of today, July 24th at 4 p.m. PST. In this first release, the editing feature is a section-level markup editor available for logged in users only. Just look for the pencil icon near the title of any page and log in with your Wikimedia account to edit. You can also illustrate articles that are missing a lead image by using the image icon to upload a photo from your phone to Commons (only ones you took yourself, please!) and insert it as a thumbnail at the top of the article in one easy step. If you're looking for things to edit, you can access your watchlist or try looking up what's around you by going to Nearby, both of which are in the left navigation menu. If all of these features of the mobile site come as a surprise to you, I strongly encourage you to visit en.m.wikipedia.org and opt into the experimental beta site (you can find the opt-in in Settings in the left navigation menu) – we start building all our features there before releasing them to the full mobile site, so you can have inside access to our development laboratory months before projects go public :)

All of these contributory features work well on iOS, Windows Phone, and latest Android devices/browsers, as well as Firefox. If you're an Android user and experiencing issues with editing in your native browser, try installing Firefox; this is usually more reliable for older Android models. Last but not least, please help us improve these features by giving feedback and/or reporting bugs! We have a mailing list (mobile-l@lists.wikimedia.org) and an IRC channel #wikimedia-mobile connect where we're always around to answer questions. Cheers, and happy mobile editing! Maryana (WMF) (talk) 18:09, 24 July 2013 (UTC)

Why are you only notifying enwiki? πr2 (t • c) 18:21, 24 July 2013 (UTC)
We're a pretty diverse team, so we're each taking on the one or two languages we know and posting localized announcements in those language projects. Here's the French Wikipedia announcement. We're also drafting posts for es, pl, ru, and uk to be posted today. If you speak another language and want to help us spread the word, that would be fantastic :) Maryana (WMF) (talk) 20:05, 24 July 2013 (UTC)
Is this feature available only to autoconfirmed users? I don't fancy wasting time fixing pages where somebody's uploaded a photo of themselves/their friends and stuck it on a random article. We got enough of that last time. --Redrose64 (talk) 19:07, 24 July 2013 (UTC)
Editing is available to all logged in users, as noted now on Help:Mobile access. Photo uploads are a separate matter. The mobile team is working on other ways to make sure quality is high when it comes to mobile photo uploads, such providing a walkthrough education of licensing requirements and so on. (Note that local uploads are not possible on mobile either, only uploads to Commons.) Steven Walling (WMF) • talk 22:42, 24 July 2013 (UTC)
Redrose64, the reason you were seeing so many poor quality images coming from mobile web awhile back was a combination of factors: the size and prominence of the call to action to upload (a big blue button across the whole article) and no educational UI for first-time uploaders. We have a much less prominent upload call to action now (a small gray icon with no text) and a number of first-time user education pieces in place (interstitial screens that explain Commons and make the user confirm that they've understood before they can submit their first upload). We've had uploading enabled on mobile for some time now, and it hasn't caused problems, so I don't anticipate another unmanageable influx of selfies. But if we do start seeing it, we can always gate the feature to more experienced users. Maryana (WMF) (talk) 23:10, 24 July 2013 (UTC)
Yay, cool! And it's nice to see that mobile edits are tagged as such, so they can be tracked in Recent changes. the wub "?!" 10:59, 25 July 2013 (UTC)

Double pasting?

Starting today, some portion of the time when I paste from one edit window to another the content is doubled. I use WikiEd. Has anyone else seen this? a13ean (talk) 18:20, 24 July 2013 (UTC)

Others have reported it at User talk:Cacycle/wikEd#Bug report: Double pasting where it belongs. PrimeHunter (talk) 21:20, 24 July 2013 (UTC)
Thanks! a13ean (talk) 16:15, 25 July 2013 (UTC)

Move log bug?

Sorry folks - you can't get away from that baby, even here. Poor little mite's barely a couple of days old, but his article has already moved at least twice. Yet for some reason, the move log shows no entries. Is this correct? An optimist on the run!   20:35, 24 July 2013 (UTC)

Yes, unfortunately moves are only shown in logs of the former title.[76] The move is in the page history [77] but not the move log. However, transferral of protection settings during a move are logged at the new title, so this move can be seen in a list of all logs.[78] This wouldn't have been the case if the page had been unprotected. PrimeHunter (talk) 21:13, 24 July 2013 (UTC)
Odd - I thought previous names showed up in the log. Maybe they used to. But in general, is there any quick way of tracing the move history of pages without trawling through all the history, if you don't know what the page was called originally? An optimist on the run!   04:49, 25 July 2013 (UTC)
Not really. You could use the "What links here" feature and click on hide links, which would generate a list of pages that redirect to the article (transclusions don't matter here). The original title of the page should be fairly high on that list, because the "what links here" list is sorted by page_id. This isn't a foolproof method, and won't work for pages with complicated move histories or where the relevant redirect has been deleted, because the page ID is reset when a page is deleed and then restored. In the case of Prince George of Cambridge, it's not so useful because of the dizzying array of redirects, but the first entry is the very recentist title The new British royal baby. Its history shows that it was created as a redirect, and then redirected to Child of the Duke and Duchess of Cambridge, which was probably the original title of the page. Graham87 10:56, 25 July 2013 (UTC)
Nope, the original title was Royal baby, per the article's very first edit. Graham87 10:59, 25 July 2013 (UTC)
Yes, quite a move history already, and we probably haven't seen the last: Royal baby → Child of the Duke and Duchess of Cambridge → Prince NN of Cambridge → Son of the Duke and Duchess of Cambridge → Unnamed of the Duke and Duchess of Cambridge → Unnamed son of the Duke and Duchess of Cambridge → Son of the Duke and Duchess of Cambridge → Prince George of Cambridge. PrimeHunter (talk) 15:27, 25 July 2013 (UTC)
(edit conflict) Here's the trail; it's longer than you think. It's more complicated than that, since on at least one occasion, two people were moving the page simultaneously, so one actually moved a redirect to a different name.
I do think that many of those redirects should be deleted, since those like Prince/ss NN of Wales are clearly placeholders (many are inaccurate too: there can only be one Prince of Wales at once, and that's Charles at the mo); those like Prince/ss X could apply to a future child of any royal couple; those like Prince William's baby could apply to any future child that the couple might have; Kate's baby is way too generic; and The new British royal baby could apply to George's own children in 18+ years time. --Redrose64 (talk) 15:50, 25 July 2013 (UTC)

Wikipedia web server infected?

I think it is highly likely that your web server is infected. Are you using Apache? In the past few days, I have received at least 4 (may by 5) warnings from Norton when reading Wikipedia for info - no other pages open

I get this Norton warning
Also see his

Time to check. Tech Info wp (talk) 13:00, 25 July 2013 (UTC)

Probably Norton being overzealous; I'm pretty sure Wikimedia doesn't run Plesk. — Edokter (talk) — 15:41, 25 July 2013 (UTC)

Deletion statistics

Dear tech people:

Now that the stale submissions in the Wikipedia:WikiProject Articles for creation are being deleted with the new db-g13, The total number of Afc submissions can no longer be determined by adding up the pages in the "Accepted AfC submissions" category and the "Declined AfC submissions" category. A third number is needed, "Deleted Afc submissions". Most of these should be picked up by filtering the deletion log by titles starting with "Wikipedia talk:Articles for creation/" and then counting the number of resulting entries. (This misses the submissions which were declined while still in sandboxes and user pages.) However, when I tried to do this manually from the log page it didn't seem to work. Also, there is no counter. I tried the Wikipedia:Statistics article, and the section on deletion says "This section requires expansion. (June 2013)" and is otherwise empty. Is there a method of finding this information that I haven't tried yet? —Anne Delong (talk) 13:08, 25 July 2013 (UTC)

If its helpful:
MariaDB [enwiki_p]> select count(*) from logging where log_title like 'Articles_for_creation/%' and log_namespace = 5 and log_type = 'delete';
+----------+
| count(*) |
+----------+
|    46606 |
+----------+
1 row in set (1 min 1.18 sec)

However that includes pages that were deleted for being pure vandalism and what not. Pages that were deleted, recreated and then deleted again are also counted twice. Bawolff (talk) 18:20, 25 July 2013 (UTC)

Thank you. Pages that are recreated or are just vandalism still have to be kept out of the encyclopedia, so it is fair to include them in the numbers, although some of them don't take much "reviewing". —Anne Delong (talk) 19:09, 25 July 2013 (UTC)

Power users are present and future of WP

This is just FYI to remember how the power users are the ones that keep Wikipedia tolerable and progressive. When checking the stats about who writes WP, the evidence is clear how a core group is doing most work; even 5% of all articles (over 210,000) were created by only about 10 people. Plus the future seems the same: only a relative handful of people are likely to volunteer to write, rewrite or expand so many articles with such precise detail, in tables, charts, images, videos, or sound clips, as well as clarified descriptions. At first I thought the emphasis on newcomers was a courtesy, but now I fear there is a newbie-mania obsession, with a focus to dumb-down the technical tools and help-pages to cater mainly to passing strangers, at the expense of ignoring, bypassing, or even totally insulting the crucial power users. Meanwhile, I hear stories of "doom and gloom" when "three people" quit in one crucial area of WP and "the end is near" (for that area) because Wikipedia is run by skeleton crews of a few users in each area, and so the loss of 3 power users can be a massive reduction in support personnel. In many U.S. businesses, the dedicated employees are given bonuses or extra vacation/holiday time at 3-year, 5-year or 10-year service dates. Anyway, we need to increase efforts to support the power users, as apparently, the newcomers are getting all the attention they could ever need (before they soon leave). Plus, we can develop more technical tools to encourage the power users about future progress, and perhaps attract more power users who realize their clever efforts are keenly appreciated. I am sorry I did not realize the power users had been so severely ignored, or even insulted, in recent years. -Wikid77 (talk) 13:57, 19 July 2013 (UTC)

You have more than five years service so I hereby award you two extra days where you are not obliged to edit, at the same remuneration as those days when you do edit. --Redrose64 (talk) 14:12, 19 July 2013 (UTC)
I agree that power users are very important. Note that at the Meetings and Metrics meeting, the Foundation noted that it isn't even paying any attention to highly-active users. All they are tracking is the number of users with 5+ edits/month. See around 16 minutes into the Youtube video. I commented on the video at the listserv, but nobody responded. II | (t - c) 15:57, 19 July 2013 (UTC)
...the Foundation noted that it isn't even paying any attention to highly-active users. Really? Well that's a big "fark you" if ever I saw one.--ukexpat (talk) 17:07, 19 July 2013 (UTC)
Huh? Please provide an exact quote in context.--Eloquence* 17:54, 19 July 2013 (UTC)
I struck the "any" part. If you start the video at 19:25 (see link above), the discussion gets into editor distribution, which the presenter admits has not been extensively studied in the past year. Using the Youtube transcript with some cleanup:

we haven't done extensive analysis over the past year on edit distributions; when we looked at this is part of the editor trend city what we did find is you know that the typical kind of like power law distribution; um... and i know this is doesn't answer your direct question but when we look at the gate at there was a disproportionate amount of the contributions that were still coming from two thousand seven and before, uh... suggesting that you know that classes in that was one of things that we found in the other two ... was that you know if you've stuck around this long is a pretty good chance that you're going to continue sticking around.

No metrics appear to be available on long-term or highly-active editors that I could find from stats.wikimedia.org - am I missing something? And I'd rather not hear that I should just run the analysis myself. That's the sort of response I've heard a few times before. I'll admit my above statement exaggerates somewhat, but I don't think it is an exaggeration to say that Wikimedia is paying close attention, on a strategic and metric level, to overall editors and other characteristics (gender ratios). No similar attention appears to be paid to long-term and highly-active editors (two additional subgroups). II | (t - c) 20:48, 19 July 2013 (UTC)
What I've been seeing lately is:
  1. VE is working because there is no data saying it isn't.
  2. (presented with data that looks absolutely terrible for VE)
  3. That data is defective for $REASONS!
That is, it's presented in the form of a non-disprovable claim. This is not entirely satisfactory, for fairly obvious reasons. Is there data that (a) shows VE is working (b) doesn't obscure other data that would reasonably be expected to exist if that data had been gathered (c) would stand up to critical analysis? - David Gerard (talk) 21:15, 19 July 2013 (UTC)
"It is difficult to get a man to understand something, when his salary depends upon his not understanding it!" --108.38.191.162 (talk) 04:51, 20 July 2013 (UTC)
@ImperfectlyInformed: I'm probably missing something, but I don't see what that New York Times article has to do with this. πr2 (t • c) 21:20, 19 July 2013 (UTC)
Multitasking accident, thanks. Youtube is now blocked for me, so no precise link. II | (t - c) 21:25, 19 July 2013 (UTC)
I'm glad there's some recognition that this idea of "crowd-sourcing" that is sweeping the online world isn't all it's cracked up to be. Those crowds everyone is chasing don't seem to want to contribute much more than snapping pictures and tagging them with OMG LOL. Perhaps worse, they don't seem to care if anyone else does. Idiocracy was a scary movie. —[AlanM1(talk)]— 13:26, 22 July 2013 (UTC)
  • Yes, crowd-sourcing of text is called a blog, not an encyclopedia. An examination of hundreds of article edit-histories will show a pattern of many hack edits reverted in favor of a relative few edits with meaningful content. The power users are not just assigning categories, and reverting hack edits, but also rewriting the added text, or expanding the contents of many articles, especially adding source references which connect to even more details to add later. -Wikid77 (talk) 21:21, 26 July 2013 (UTC)

Yet Another TemplateData Editor

Hey, I made a TemplateData editor, link. Right now it's in Polish, but I'm going to add i18n soon. Also as for now, the data will be lost on page reload, but I'm working on that. Please write if you find bugs or to request a feature. Hope you dig it :) Lazowik (talk) 21:23, 22 July 2013 (UTC)

Nice! Nothing like Bootstrap for instant good-looking UIs. :) Looking forward to an English version. Theopolisme (talk) 23:12, 22 July 2013 (UTC)
IMO, any templatedata editor worth considering should have the following 2 features:
  1. it should be able to populate all the parameters by analyzing the template itself (fairly easy). it doesn't necessarily have to do it automatically, but it should be able to do it when asked. (automatically is probably also good)
  2. it should be able to populate from existing, partial templatedata record if such already exists
i could not see if your editor has these two features, but if it doesn't please consider adding them.
peace - קיפודנחש (aka kipod) (talk) 23:19, 22 July 2013 (UTC)

Update: added english. You can send me translations, details in the footer :) Lazowik (talk) 23:51, 24 July 2013 (UTC)

It would be nice if the tool could wrap the templatedata tags - <templatedata></templatedata> - around the result. It is counterintuitive to add those manually.--Snaevar (talk) 21:46, 26 July 2013 (UTC)

Finding a users old signature

Ok, this is kind of a weird issue. I suspect that a certain user is actually a sock. One of the similarities between their accounts is a distinctive signature formatting that one of them is using now and the other used several years ago. When I saw this new user using the same format I remembered the other user using it years ago, but when I search their old talk comments it isn't there anymore, even though I was able to find a discussion where it was mentioned. I'm not naming names as I am in the preliminary stages of preparing an SPI on these users. So my questions are:

Why can't I see the old sig formatting anymore?
Is there any way to prove the user used to format their sig differently?
Does it make a difference that the user has been renamed? (more than once I think)

Any help would be very much appreciated. Beeblebrox (talk) 18:00, 24 July 2013 (UTC)

Old signatures aren't cached anywhere, but they are frozen in time at the time a comment is made. If they are different looking now, that means someone went back and edited it. You should be able to find that diff. I can't think of any way that the diffs from the original user's contributions wouldn't show the original signature.—Kww(talk) 18:18, 24 July 2013 (UTC)
If you want to provide a username I can give you a hand digging up sig examples. Werieth (talk) 18:22, 24 July 2013 (UTC)
Via the History tab, you can always look at what was on a talk page at whatever date you want, yes? (Templates aren't locked in place, but that's presumably not relevant, since they are forbidden in signatures per WP:SIG.) -- John Broughton (♫♫) 22:24, 24 July 2013 (UTC)
Thanks all. I found sigs that had the similar name I was expecting, but not the similar formatting. I may have been thinking of someone else. After eight years it all starts to run together a little bit... Beeblebrox (talk) 21:31, 26 July 2013 (UTC)

Commons images dependent on /referencing a local image

http://commons.wikimedia.org/w/index.php?title=File:Flag_of_the_Mongol_Empire_2.svg&oldid=100614944

The image here referenced an existing image which was also moved to Commons.

Is there a way to determine if an image has "Commons dependents" before it's tagged for F8, so that the Commons links can be updated accordingly.

Sfan00 IMG (talk) 22:50, 24 July 2013 (UTC)

This is slightly different from the question you asked at commons:COM:VP. If you have a specific link target in mind you can use iwbacklinks api module - https://commons.wikimedia.org/w/api.php?action=query&list=iwbacklinks&iwbltitle=File:Flag%20of%20the%20Mongol%20Empire%202.gif&iwblprefix=w . Note however, to be sure you get all of them, you have to search with different variations of the File namespace (aka File, file, Image, and image), as well as variations on the prefix (for enwikipedia: w, en, and wikipedia are all prefixes for wikipedia from commons). Bawolff (talk) 18:30, 26 July 2013 (UTC)

I need six-pixel space ...

... but the "nbsp" code gives just four-pixel space. Can someone help me? Is there any template in WP for displaying various spaces?
Maiō T. (talk) 16:30, 25 July 2013 (UTC)

What if you type <small>&nbs​p;</small>&nbs​p;? Does this produce the space you need? Nyttend (talk) 16:43, 25 July 2013 (UTC)
A space is normally measured in em. See Space (typography) for a list of various spaces. --  Gadget850 talk 16:51, 25 July 2013 (UTC)
To Nyttend: I found, the "small &nbsp" produces 3px space, same as the regular "&thinsp". And the "small &thinsp" produces 2px space. That's cool, isn't it? Anyway, thank you.
To Gadget850: That article is interesting, but I miss the HTML code for the hair space (or one-pixel space). We should create a new template for spacing, for example: {{spacepx|1}} creates one-pixel space, or {{spacepx|80}} creates                    this.
Maiō T. (talk) 19:27, 25 July 2013 (UTC)
Let's get down to brass tacks: Why do you need a six pixel space? --Golbez (talk) 19:35, 25 July 2013 (UTC)
So, watch this:
Italy Normal align
Russia Normal align
Switzerland Need 6px to align
United States Normal align
Niger Need 5px to align
France Normal align
Denmark Need 3px to align
Maiō T. (talk) 20:04, 25 July 2013 (UTC)
See Template:Nb5 and Template:Spaces.—Wavelength (talk) 21:31, 25 July 2013 (UTC)
A table would fix this right up. --  Gadget850 talk 22:55, 25 July 2013 (UTC)
To Wavelength: Template {{space|1.5}} is not working. (1.5nbsp=6pixels)
To Gadget850: You mean flag-icons & text in two separate columns? That wouldn't look good.
Maiō T. (talk) 11:00, 26 July 2013 (UTC)
Align to what? --  Gadget850 talk 11:18, 26 July 2013 (UTC)
  • What about something like <span style="margin-left:100px">&8288;</span>? It produces exactly what you want: |⁠|
An whats wrong with a table? Works perfectly in my opinion:
Italy  Normal align
Russia  Normal align
Switzerland  Need 6px to align
United States  Normal align
Niger  Need 5px to align
France  Normal align
Denmark  Need 3px to align
--Patrick87 (talk) 11:47, 26 July 2013 (UTC)

I run across this with ribbons, flags, etc. There are places where a table is impractical, or difficult to get to make work right, like inside stacked templates/tables. {{Pad}} seems to be what's needed:

Italy Normal align
Russia Normal align
Switzerland Need 8px to align
United States Normal align
Niger Need 5px to align
France Normal align
Denmark Need 3px to align

Note that the standard flag icon is 23x15px, so you get different widths when you size the odd-sized ones to be 15px high (e.g. {{flagicon|SUI}}) to get lines the same height. SUI actually needs 8 extra pixels (it's 15x15px). {{Pad|8px}} actually inserts an &nbsp; with left-padding of 8px. So, the lines that don't require extra padding need to be punctuated with an &nbsp; also. The code looks like:

{{flagicon|RUS}}&nbsp;Normal align<br/>
{{flagicon|SUI|size=x15px}}{{Pad|8px}}Need 8px to align<br/>

—[AlanM1(talk)]— 13:22, 26 July 2013 (UTC)

Remember folks, the moral of this story: Before you ask how to do X, also mention why you want to do X. Maybe there are better ideas. :) Also, I might suggest a longer-term goal: That all of the {flagicon} templates eventually equalize their size, containing within them any spacing required to make the flags line up. --Golbez (talk) 13:30, 26 July 2013 (UTC)

Yes; Maiō T. - it would help a great deal if you could give examples of the page(s) on which you need to use this layout. --Redrose64 (talk) 13:38, 26 July 2013 (UTC)

I just created this new template: {{pxsp}}. It creates a space with various width from 1 to X pixels. See:

  • Italy|||||
  • ‍Switzerland‍||||| code: {{pxsp|3}}{{flagicon|SUI}}{{pxsp|4}}
  • Russia|||||
  • ‍Denmark‍||||| code: {{pxsp}}{{flagicon|DEN}}{{pxsp|2}}

All is perfectly aligned. However, I agree with Golbez – the longer-term goal is definitely to equalize all of the flagicons to 23x15 pixels. (The Swiss flag with added transparent color on the sides)
Maiō T. (talk) 22:21, 26 July 2013 (UTC)

But in which articles do you need this behaviour? --Redrose64 (talk) 22:33, 26 July 2013 (UTC)
For example, 2013 Men's World Ice Hockey Championships
Maiō T. (talk) 22:55, 26 July 2013 (UTC)

Blanking filter misfire

Tracked in Phabricator
Task T54077

Hello: does anyone know why this edit triggered the blanking filter? Regards, Orange Suede Sofa (talk) 18:36, 25 July 2013 (UTC)

I don't know why but Special:Contributions/Felix de lima shows it happened for many similar edits by the same user. PrimeHunter (talk) 22:09, 25 July 2013 (UTC)
It's the edit at top of [79]. Clicking diff shows he added a navbox in the external links section. Clicking details shows that the edit filter thinks he also blanked everything before the external links section. It's the same for many other wrong taggings I examined. The edit filter is analyzing a false diff where a lot of the article was allegedly removed. PrimeHunter (talk) 23:26, 25 July 2013 (UTC)
In this edit, they attempted to add the "navbox" {{Los Angeles Film Critics Association Award for Best Supporting Actor 1975-present}} but it doesn't exist (it never existed, so is not even a deleted template); perhaps that's a factor. --Redrose64 (talk) 09:42, 26 July 2013 (UTC)
The same error happens in many other types of edits at [80]. PrimeHunter (talk) 09:51, 26 July 2013 (UTC)
By the way, it appears from that list that the tag "Mobile edit" prevents other tags from being shown, or maybe "Mobile edit" is sometimes shown instead of the right tag? PrimeHunter (talk) 09:54, 26 July 2013 (UTC)

Visual Editor - Will it get faster? When?

I'm an old software developer myself, and can understand some of the challenges faced by developers here so, despite feeling frustrated with the unannounced changes and the little bugs like everyone else, I've up till now made no comment at all about VE anywhere on Wikipedia. I've seen how it works now. It's a move in the right direction for making life easier for newer editors. For me, as an experienced editor, I won't be using it for major changes any time soon, but I would use it for simple things right now if it wasn't so darn slow.

I welcome a lot of new editors, and feel reluctant about recommending it to them because of its slothfulness.

Is it expected to get faster? And I mean a lot faster? When? HiLo48 (talk) 00:19, 26 July 2013 (UTC)

Yes. Maybe. Sooner or later. As I understand (and I'm not part of the VE team, so they can correct me if I'm wrong), improving performance of the editor is a high priority. We should see some improvements in this area soon-ish, though the low hanging fruit may not be very satisfying in terms of what can be accomplished. For example, various forms of caching have already being applied, and large articles remain quite slow. Major performance enhancements probably require reducing the amount of wikitext being converted to and from HTML during each edit session, for example by only processing section(s) that the use is actively editing. Many techniques that might have the largest impact on performance probably require a significant amount of engineering. As a result, it may be long time before we see large improvements in VE performance. You are right though, that making it faster is an important part of the user experience, and I think the devs know that. Dragons flight (talk) 01:57, 26 July 2013 (UTC)
I wouldn't think so. Apart from common sense (what VE is trying to do is extremely difficult and has to take significant time), see this and the reply. Getting a very fast computer with a very fast implementation of Javascript would help, as would adapting one's habits to tolerate the hesitancy. Johnuniq (talk) 02:26, 26 July 2013 (UTC)
If it doesn't get significantly faster, I won't use it, and I don't think it will help new editors much at all. I certainly won't recommend something that performs so poorly. I like my recommendations to have value. The response times involved are far too long for productive editing. HiLo48 (talk) 12:17, 26 July 2013 (UTC)
As a general hint, WP:VE/F is the best place to give feedback for the VisualEditor (or to check for existing threads requesting the same feature/bugfix) so the developers can see it. Hope that helps. --AKlapper (WMF) (talk) 14:41, 26 July 2013 (UTC)
The last thing I heard was "yes" and "months" (meaning not weeks, but not years). I've also heard that it might be really fast "someday". I assume that means "years". Whatamidoing (WMF) (talk) 01:33, 27 July 2013 (UTC)
Well, presumably editors' machines will get faster over time. I have plenty of complaints about VisualEditor, but using a new iMac, speed isn't one of them. :-) --MZMcBride (talk) 05:07, 27 July 2013 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)/Archive_114&oldid=1147960915"