Jump to content

Wikipedia:Village pump (technical)/Archive 115

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

Complication involving the @ template

I followed "What links here" from Template:@ to the article Sierra Leone, because I was trying to figure out why a template designed to prevent bots from grabbing email addresses on Wikipedia pages was also being used in an article. What I found, searching the wikitext, was this template:

{{@#!*% -Congo-speaking}}

which seems to be malfunctioning - if you go to near the bottom of the page, and, for the "Languages" navigation template, click "show", you'll see "@", which I doubt was the intent of that template.

Could someone more familiar with templates figure out what's going on? And if this is a reason to get rid of Template:@ (see the TFD discussion here), please consider posting at the TFD page. Thanks. -- John Broughton (♫♫) 01:01, 26 July 2013 (UTC)

Your example was just a bit of old vandalism. It should have been {{Niger-Congo-speaking}} but someone messed with it. (A related question is why did that vandalism take over a year to be fixed?) Dragons flight (talk) 01:32, 26 July 2013 (UTC)
Help:Template#Other details says: "If the symbol # (normally used to link to a section of a page) appears in a transclusion, then it and any characters that follow it are ignored." So {{@#!*% -Congo-speaking}} is treated like it only said {{@}}. I guess the reason is that it's not possible to transclude a section. {{foo#bar}} looks like an attempt to transclude the "bar" section of the "foo" template but this is not possible, so the whole "foo" template is transcluded instead. '#' is in Wikipedia:Naming conventions (technical restrictions)#Forbidden characters, so you don't lose the ability to transclude any page by the convention to ignore '#' and what follows it. Since this is nothing special about Template:@, it contributes no argument to delete that template. PrimeHunter (talk) 01:43, 26 July 2013 (UTC)
Thanks for the information, and help. In this case, my sample of one turned out to be non-representative. -- John Broughton (♫♫) 20:26, 26 July 2013 (UTC)
Fascinating. As to Dragons flight's question... could we maybe have a "possible censorship" filter? In this case I'm not sure if the user was just really dumb and didn't know that Niger is a country, not a slur, or if they were trolling, but, either way, a filter could stop stuff like this. (Especially if you consider that some of our most frequent valid false positive reports are cases where someone's trying to revert censorship.) — PublicAmpers&(main account • talk • block) 21:31, 26 July 2013 (UTC)

Talkbacks

Dear tech people: At the Teahouse there is a wonderful feature that makes a tiny "TB" appear next to each user's name when they leave a message. Clicking on the TB lets you leave a talkback message on his or her talk page. It saves a lot of time. Is there a way to make that happen on other talk pages? —Anne Delong (talk) 03:50, 26 July 2013 (UTC)

Sounds like a good idea. I use tb quite often, though with discretion - I usually rely on my watchlist. I use tb mostly in cases where I feel the user may not be using their watchlist (or even know about it), or where my reply on my talk page is rather late. I find the 'Whsperback' template a lot less 'in your face' but it is not a Twinkle feature. All this may change though when Flow gets released, though I haven't been following its development and I don't know exactly what the WMF has up its sleeve. Kudpung กุดผึ้ง (talk) 05:24, 26 July 2013 (UTC)

I actually asked Writ Keeper, the developer of the "Teahouse talkback" script, to do precisely this for me a while ago. Just add 

importScript('User:Writ Keeper/Scripts/talkbackLink.js')

to your Special:MyPage/common.js and you'll see a small "TB" link next to every user talk link. Theopolisme (talk) 06:00, 26 July 2013 (UTC)

Thanks for this. It works. Though I still thing the Whisperback template would be less intrusive and just as effective. Kudpung กุดผึ้ง (talk) 06:14, 26 July 2013 (UTC)

@Kudpung: If you'd prefer to use {{whisperback}}, you can add 

importScript('User:Theopolisme/whisperbackLink.js')

to your common.js instead. Let me know if you encounter any problems with it, Theopolisme (talk) 06:32, 26 July 2013 (UTC)

Thanks again. That works too. Kudpung กุดผึ้ง (talk) 08:53, 26 July 2013 (UTC)

Contents box

Tracked in Phabricator
Task T53766

Is anyone getting a page wide contents box after they make an edit. Whenever I edit a page that has a TOC following the intro section, it ends up going across the entire length of the page rather than a small box. It probably just happened to this page when I clicked "save". Unless no one else sees it that way. --StarcheerspeaksnewslostwarsTalk to me 18:33, 18 July 2013 (UTC)

Nope, not this page. But it is like that at Rose Colored Glasses (Kelly Rowland song), which I recently edited, as well as on my talk page. --StarcheerspeaksnewslostwarsTalk to me 18:35, 18 July 2013 (UTC)
All contents boxes seem to be stretched for me – Connormah (talk) 18:46, 18 July 2013 (UTC)
This might have been a temporary issue related to minor changes in table of content's HTML structure. Is it still happening? Is it still happening after you bypass your browser's cache? Matma Rex talk 18:49, 18 July 2013 (UTC)
(edit conflict)I'm getting stretched content boxes as well - see Zakee Wadood. Insulam Simia (talk/contribs) 18:53, 18 July 2013 (UTC)
I saw the same issue - a cache bypass fixed it.--ukexpat (talk) 18:54, 18 July 2013 (UTC)
The cache bypass worked for me. Thanks. --StarcheerspeaksnewslostwarsTalk to me 19:27, 18 July 2013 (UTC)
using Chrome on W8 and cache bypass doesn't work for me, still having this problem. Peacemaker67 (send... over) 01:57, 20 July 2013 (UTC)

TOC display (trivial, but odd)

(Oops. Redundant to above section. This is what happens when you post a new comment by just clicking on the new section link, without looking at the rest of the page. postdlf (talk) 19:10, 18 July 2013 (UTC))

I can't figure out what's causing the table of contents in this article to display as a box extending the entire width of the article rather than a smaller box just around the section links. I can't find any code in the article regarding the TOC, and TOCs in other articles are displaying normally. postdlf (talk) 19:08, 18 July 2013 (UTC)

I'm having the same thing happen on my user talk page. AutomaticStrikeout  ?  20:10, 18 July 2013 (UTC)
Me too - mediawiki has been upadated to wmf10 today - maybe the reason? Christian75 (talk) 20:49, 18 July 2013 (UTC)
I seem to have this on all articles at the current time. --LukeSurl t c 20:51, 18 July 2013 (UTC)
A cache bypass fixed it. --LukeSurl t c 20:56, 18 July 2013 (UTC)
Same here. Thanks Luke. AutomaticStrikeout  ?  00:22, 19 July 2013 (UTC)
Using Firefox 1.5 (prefer it, don't ask why), neither a browser cache bypass nor a purge works here. However, Firefox 12 displays it correctly. Would really rather use 1.5 to browse WP. -- Tohler (talk) 01:07, 19 July 2013 (UTC)

I came here with the same problem after finding a purge or edit turns the problem on after ticking the 'Add an [edit] link for the lead section of a page' gadget; untick the box, purge or edit the article and it goes away. Using Chrome on Windows 7. Edgepedia (talk) 05:17, 19 July 2013 (UTC)

I'm using Chrome both on an PC and OSX and it's displaying problems across several articles. Mkdwtalk 08:08, 19 July 2013 (UTC)

I'm currently using IE on a PC (blame work) but it was also happening on Chrome on a Mac. Cabe6403 (Talk•Sign) 08:49, 19 July 2013 (UTC)
Bypassing my cache worked; Wikipedia:Bypass your cache. For chrome users: ⇧ Shift + F5 or ⌘ Cmd + F5. Mkdwtalk 08:55, 19 July 2013 (UTC)

Broken "contents"box

Can someone tell me why the "Contents" box at the top of Colt Ford spans the entire width of the page? I can't see anything in the coding that would be messing it up. All other "contents" boxes look fine to me, but the one on Colt Ford is weird. Ten Pound Hammer • (What did I screw up now?) 01:56, 19 July 2013 (UTC)

The same is happening on user talk pages and on some Eurovision and Junior Eurovision articles too. Wesley ☮ Mouse 02:02, 19 July 2013 (UTC)
Perhaps #Contents box is relevant? Chris857 (talk) 02:07, 19 July 2013 (UTC)
  • If and when this gets fixed, has any thought been given to CSS floating the contents box, to avoid the great swathes of vertical whitespace it otherwise tends to generate? Andy Dingley (talk) 09:38, 19 July 2013 (UTC)
    That would create sandwiching, and other layout problems - particularly for people browsing on small monitors, or in small windows. There is {{TOC left}}, for when an article would clearly benefit from a floated TOC. –Quiddity (talk) 02:45, 20 July 2013 (UTC)

Table of Contents internal coding? I have no idea where to ask this but

was something done recently to the TOC coding? Now they stretch across the page from margin to margin (looking out of scale) and have a Hide/Show toggle switch... See Abraham Lincoln and George Washington. I just don't remember the TOC looking like this... Shearonink (talk) 17:13, 19 July 2013 (UTC)

See #Contents box. Chris857 (talk) 17:19, 19 July 2013 (UTC)

Bypassing cache doesn't fix

Hi all - I'm getting the "wide TOC" problem too, but bypassing (and even emptying) the cache, as suggested above, has made no difference. FWIW, I'm using Safari 5.1.7 on a Mac running OS 10.6.8 (and the article in question, not that that will make much difference, probably, is Whitcoulls. Grutness...wha? 11:59, 20 July 2013 (UTC)

Hi all, I'm still seeing this problem when I have the 'Add an [edit] link for the lead section of a page' gadget on. [You have the purge the page so the difference after changing the setting.] Am I the only one? Edgepedia (talk) 16:12, 20 July 2013 (UTC)
I'm seeing this problem in many places, including this page.  I've reloaded the page(s), and used action=purge without success.  I have Firefox/2.0.0.20.  {{toc left}} helps, and is better than nothing.  Unscintillating (talk) 18:27, 20 July 2013 (UTC)
Still getting this on most pages after bypassing cache. This is on Chrome/Win8. --Saddhiyama (talk) 15:32, 22 July 2013 (UTC)

Coping strategies

  • The first time I noticed this problem was at [1].  The approach here is to switch to {{toc left}} and use </br> to force the next line of text below the toc.  This would need manual maintenance should the TOC ever change.  At [2] I combined {{toc left}} with {{clear}}.  The problem with this approach is that it forces text below the box on the right, which is ok in this particular case, but is not a general fix.  A look at Template:Clear shows the {{clear|left}} option.  I have applied this fix at [3].  Here is the improved fix: 
{{toc left}}
{{clear|left}}
Unscintillating (talk) 13:58, 21 July 2013 (UTC)
Please don't use </br>, it's not valid HTML. Use {{clear left}} for positioning purposes, or if you really want a single line break, use <br> or <br />. --Redrose64 (talk) 15:59, 21 July 2013 (UTC)
I don't think that editing pages one-by-one is a sensible solution: we have over 4 million to work through. I have yet to see this "bug" - if bug it is - for myself. I did not see it in Firefox 22 (Windows XP, Monobook); I am not currently seeing it in Firefox 3.6.6 (Windows XP, Monobook). Perhaps a survey could be made tabulating browser/OS/skin against "I see it always/I see it on some pahes/I don't see it anywhere". --Redrose64 (talk) 08:35, 22 July 2013 (UTC)
I see a full-width contents box on some pages (including this one, WP:VPT), but not others (like Helen Thomas), using Win7/FFox20/Vector with some customization in CSS and JS. On WinXP/FFox7/(default, not logged in), the TOC on this page does not start until after the Centralized Discussion box on the right, and does not take up the full width of a ~1000px browser. I'm guessing it occurs on pages with very wide section headers, like "WMF intends for Only VisualEditor..." —[AlanM1(talk)]— 13:44, 22 July 2013 (UTC)
Related: User_talk:Theopolisme#TOC. At least for me, it seems to happen only sporadically for articles/pages using Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.71, but not with Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_4) AppleWebKit/536.30.1 (KHTML, like Gecko) Version/6.0.5 Safari/536.30.1, weirdly enough. Theopolisme (talk) 16:23, 22 July 2013 (UTC)
@Unscintillating:, yes, still seeing the problem: Chrome 27 on OS X 10.8.4. --RA (✍) 22:05, 22 July 2013 (UTC)
Having the same problem. Running Chrome 28 and Windows 7 SP1. Dan653 (talk) 22:18, 22 July 2013 (UTC)
Running the same OS, but using IE 10 the problem disapears... Dan653 (talk) 22:22, 22 July 2013 (UTC)
Running the same OS, but using Firefox 17 ESR the problem disapears. Dan653 (talk) 22:30, 22 July 2013 (UTC)
Maybe it was the chrome 27 to 28 switch from webkit to blink? Dan653 (talk) 22:42, 22 July 2013 (UTC)

Can we remove "thanks" logs from the userlog default display?

I like the new Thank feature and I use it. But I find it annoying that every time someone receives a "thank" notice, it gets listed under their logs. When I click on "view logs" for a person (specifically "view logs for this page" on the revision history of their userpage), I am looking for stuff about them that matters - things like blocks and userrights. Now the first thing I see is a long string of "so-and-so thanked so-and-so". I'm not saying these things shouldn't be logged somehow, but IMO listing them all on a user's log record is clutter; it's unnecessary trivia that gets in the way of what we wanted to see. Would it be possible to make "view thanks log" an optional button (as the Patrol and Review logs already are) instead of including them in the general log by default? I first raised this question at Wikipedia talk:Notifications/Thanks#Must we list every Thank under "View logs"? but was advised to bring it here instead. Thanks for any input. --MelanieN (talk) 13:41, 25 July 2013 (UTC)

Wanting to look at the "Thanks" log is a rare enough case that I agree it shouldn't come up in the default view.—Kww(talk) 00:07, 26 July 2013 (UTC)
I 3rd this request. --User:Ceyockey (talk to me) 00:22, 26 July 2013 (UTC)
I don't like the thanks notifications in the first place and never send them, preferring to write real text, but if someone can make this work I promise to make an exception and send them a thanks. —Anne Delong (talk) 03:46, 26 July 2013 (UTC)
What you are asking for would require developer intervention. Has a bugzilla entry been created? I agree that more configuration is a good thing. Though not what you asked for, it is possible for individual editors to hide thanks log entries using:
.mw-logline-thanks {display: none;}
in your personal CSS. However that just makes the lines invisible (with no option to see them aside from changing your CSS) and you'd still have to load more lines to scroll past them even though you wouldn't see them. So it's a poor hack, but I thought I'd mention it just in case you thought it better than nothing. Obviously, the best solution is to get the devs to add some more configuration options. Dragons flight (talk) 18:00, 26 July 2013 (UTC)
Note the setting already exists - mw:manual:$wgFilterLogTypes. It should be a simple config change. Bawolff (talk) 18:22, 26 July 2013 (UTC)
Thanks for the workarounds; I was actually looking for a system-wide change, as seems to be seconded by others here. I didn't go to Bugzilla because I didn't think of it as a bug; is that where this kind of request is supposed to go? I don't usually frequent these pages so I don't understand the fine distinctions. --MelanieN (talk) 19:54, 26 July 2013 (UTC)
@MelanieN: Bugzilla is where "enhancements" in the MediaWiki software are to be requested, as well as defects reported. This page (VPT) is, of course, a good place to start, since sometimes it's possible for admins to make a change that only affects the English Wikipedia, and sometimes there are gadgets or other workarounds that are satisfactory. -- John Broughton (♫♫) 20:37, 26 July 2013 (UTC)
+1, and I've added bugzilla:52118, hopefully not duplicating anything, and in the right place, and with the right details. (So many products/components, and no "preview" >.< ) –Quiddity (talk) 21:35, 26 July 2013 (UTC)
Thanks, Quiddity. I would not have had a clue how to do that. --MelanieN (talk) 15:00, 27 July 2013 (UTC)

Question on unified login changes

Hi. I already asked this at WT:Unified login/Finalisation (diff), but I realized I might get a quicker response here. My question is: when the unified login changes are made next month, will a SUL account with no edits will be treated any differently from other SULs? I have such an account (named Arc en Ciel); I usurped it some time ago and intend to switch my account to it eventually. I'm asking so that if there are any potential issues, I could switch over before finalization is completed. (The finalization page says "The fate of empty global accounts still remains to be decided" but I'm not sure what precisely "empty" means, e.g. whether the existence of user and talk pages with redirects are considered.) Arc de Ciel (talk) 11:15, 27 July 2013 (UTC)

What's that API error message again? You know, the one where...*trails off* Well, that's just it.

We're trying to build some more sophisticated MediaWiki API error handling (yay, error messages that make sense!) into the Articles for creation helper script. mw:API:Errors_and_warnings shows the standard ones, but does anyone have a copy of what the API will output if something bigger is going on (e.g., an API service disruption)? Here's this github issue. Thanks! Theopolisme (talk) 22:28, 27 July 2013 (UTC)

I imagine it depends on what precisely happens. If thinks are totally overloaded, you would probably get an HTTP status code of either 500 or 503. Bawolff (talk) 23:17, 27 July 2013 (UTC)

VisualEditor going live

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

If we get questions about this at OTRS should we just move them to the tech-issues queue or do you want them forwarded somewhere else? Thanks. — Preceding unsigned comment added by Ukexpat (talk • contribs) 20:18, 1 July 2013 (UTC)
Works for me; I'll monitor it as we go :). Okeyes (WMF) (talk) 20:20, 1 July 2013 (UTC)
(edit conflict) Hi Okeyes, I've asked at least three times, with no answers, regarding which browsers you're supporting. Since I'm still unable to turn it on in preferences, please post somewhere which browsers will see and which will not - I assume some of us will not. That will cut down potential confusion, imo. Also, the watchlist notice is incredibly small - might want to make that more prominent since not everyone watches the relevant pages. Thanks. Victoria (talk) 20:23, 1 July 2013 (UTC)
Hi Victoria! The FAQ page at mediawiki.org now has that answer, and I'll tell my team to look into the watchlist notice thing. Thanks for your feedback, --Elitre (WMF) (talk) 20:31, 1 July 2013 (UTC) PS - actually I did not realize it is written here as well :)
Victoria, what browser are you using? Okeyes (WMF) (talk) 20:35, 1 July 2013 (UTC)
Okeyes, I've asked here 3 times - the threads have all been archived, the questions ignored. I know, having spoken with Apple, that a subset of users w/ some versions of OSX will not be supported. The browser support is not listed at the page mentioned above. Personally, I don't care, I'll continue to edit as I have, but saying it's available to all logged in users is incorrect. Victoria (talk) 20:41, 1 July 2013 (UTC)
Afaik: Right now, it supports FF 11+, Iceweasel 10+, Chrome ?16+, and Safari 6+, regards --JEissfeldt (WMF) (talk) 20:43, 1 July 2013 (UTC)
Hi Victoria, I have at least a user on it.wp happily editing from OSX using Chrome. Perhaps you might want to try as well? Thanks for your reminder about browsers, it is important that that section is clear and complete about it. --Elitre (WMF) (talk) 20:46, 1 July 2013 (UTC)
Yes, that's right. With a Macbook Pro users have to go to Chrome. They leapfrogged Safari to Snowleopard, loaded an older version to the machines when Lion was released. Go figure. But that's how it is. Victoria (talk) 20:54, 1 July 2013 (UTC)
Here's a question... I was approached regarding developing a gadget to disable VE buttons. Does that mean that the option to en/disable the VE in Preferences (Editing tab) is going to disappear? — Edokter (talk) — 20:58, 1 July 2013 (UTC)
Edokter - when we switch to this being the parallel interface - and the one that you get when you hit the "edit" button - yes, that option will go away. If you'd like to disable the thing - we really wish you wouldn't, because both VE & source editors are easily accessible from the interface (both from the tabs and the section edit links), and some features will be really useful to experienced editors as well, like the dialogues to edit complex templates and references. Also, your help in identifying bugs and training new users will be invaluable. That said, if you really can't stand the extra tab, a community member has written a user script that you can use to completely hide VisualEditor from your interface. You can do so by adding importScript('User:Matma Rex/VE killer.js'); to your common.js file. But how about giving it a whirl first? Philippe Beaudette, Wikimedia Foundation (talk) 21:07, 1 July 2013 (UTC)
No, no, no! You cant be serious! The option is already there – why remove it? If (and only if) I decide to check some compatibility issues I'll activate VE from my preferences. I neither want to see it otherwise nor do I want to load it unnecessarily in background. Wikipedia is a damn slow JavaScript monster by now. Don't you see what you're doing by forcing more an more JavaScript feature on editors? --Patrick87 (talk) 21:21, 1 July 2013 (UTC)
Yeah, I've coded that up already, because I strongly believe the option should be kept as well. Matma Rex talk 21:17, 1 July 2013 (UTC)
Thanks Matma Rex, but hiding the VE with the help of CSS or JavaScript is not decreasing loading times. It's only curing the symptoms while a simple checkbox in user setting could cure the disease. --Patrick87 (talk) 21:21, 1 July 2013 (UTC)
Yes, I realize, using that script is the worst of both worlds. I have no idea why VE team insists on killing the preference when we even can still use the old editing toolbar. Matma Rex talk 21:24, 1 July 2013 (UTC)

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

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

The .js script given above is not working for me. I really would like to turn this off and retain the option of trying it out when I'm ready for it, not when the developers are ready for it. Please restore the turn off switch to Preferences as soon as possible. Beyond My Ken (talk) 21:56, 1 July 2013 (UTC)
  • This goes to the question of which browsers support too. If push comes to shove and people don't want, or do want, it's important to know which browser to upgrade to or downgrade to - though that's quite slightly insane, imo. The option to choose should remain. I've had the option for weeks and it's been worthless, hasn't done a thing when I've enabled (and I'm currently a very active editor, know where to post so think of me a cockroach - see one when there are many) - so it would be useful to have the option for those of us who are trying to figure a., if we can use the UI, and 2., whether or not we want it. If you're to emulate google, consider that they always give an option to try a new feature and to return to the older feature. I still have the old compose for instance, though it was introduced quite a long time ago. Victoria (talk) 21:57, 1 July 2013 (UTC)
  • One bright point in all this: I don't have to worry about people vandalising music charts or discographies any more: no one will be able to figure out how to edit them. —Kww(talk) 21:58, 1 July 2013 (UTC)
    • Hi all, apologies for not being able to answer everything right now: we're going to explain in a bit more detail but we're a bit overwhelmed at the moment since the real launch happened minutes ago. I will draw the team's attention to this whole discussion, and hopefully they can provide a more complete answer. --Elitre (WMF) (talk) 21:59, 1 July 2013 (UTC)
      • There are no plans to install or restore a turn off switch to Preferences. I realize that it is a disconcerting change - I am not particularly change-friendly myself, but I'm happy to say that in the time I've been interacting with it it has pleasantly surprised me, even back when the bugs were far more substantial. :) Of course, everyone has the option of using the old interface (and sometimes - such as when working on copyright investigations - it's the only thing that works for me), but it's there if you change your mind. --Maggie Dennis (WMF) (talk) 22:03, 1 July 2013 (UTC)
          • Then you seriously need to reconsider those plans immediately. This is not a question about whether the editor is good or bad, it's a question of choice. I've managed to make many thousands of edits with the old editor and I'm quite conversant with it. Your forcing me to make an extra choice each and every time I edit is taking up my time, not yours, and, quote frankly, the choise not to keep the turn-off switch in place is downright rude. Beyond My Ken (talk) 22:19, 1 July 2013 (UTC)
        • That's strange. I've gone and played with a number of music-related articles and haven't found one yet where it actually worked. Try editing the tables in Akon discography, for example, and watch the tables melt into a pile of misaligned html text being treated as field entries. Try to add or remove a chart from a simple chart list like Bus Stop (song)#Charts. I don't know where to start writing the bugzilla reports because I can't find a working article to compare the broken behaviour to.—Kww(talk) 22:08, 1 July 2013 (UTC)
      • @Victoriaearle:: As answered to you above, VE currently definitely runs on FF 11+, Iceweasel 10+, Chrome 16+, and Safari 6+. This information is also in the FAQ on mediawiki. Keegan (WMF) (talk) 22:10, 1 July 2013 (UTC)
  • @Keegan: - thank you, I read it. What I am trying to say, perhaps unelegantly, is that this has been a rather developer-centric, Silicon Valley-centric rollout without taking into consideration the idiosyncrasies of this particular community of users. I know that I can't use b/c you don't support my browser (said many times now) but somewhere, someplace, would be very useful for you all to post prominently which browsers are supported so as to cut down some of the questions. That's all I meant and will leave you to it now. Victoria (talk) 22:37, 1 July 2013 (UTC)
  • Let's be blunt: I can barely use Wikipedia right now because the section editing tags are knocked so far over to the left they are horrendous. Please install a turnoff button, instead of dismissing editors' concerns with "you'll like it". - The Bushranger One ping only 22:29, 1 July 2013 (UTC)
              • I'm using FF 22.0 under Windows 7 Home Premium with the Monobook interface, but my problem isn't with making VE work, my problem is that I'm trying to plow my way through a bunch of work and I really don't have time to be your guinea pig at the moment. I need a turn-off switch so I can disable VE now and take a look at it when I'm ready to. The script above did not in any way make a difference. It's good that your collecting data on what systems it works under etc., but I'm afraid your rather missing the point: you need to provide the turn-off switch and allow users who do not want to use it a chance not to. You cannot (or rather, you should not) be forcing this on us. Beyond My Ken (talk) 22:51, 1 July 2013 (UTC)
      • @Okeyes: Please don't get into discussions whether the "opt-out script" is working or not. Make sure the opt-out preference is correctly added back to the user preferences. This is the only clean and acceptable solution. Everything else can be considered eyewash to make us more comfortable with the transition. All contents of VisualEditor are still loaded in the background and it only produces compatibility problems as those reported above. --Patrick87 (talk) 22:51, 1 July 2013 (UTC)
        • At the moment I'm making sure that the VisualEditor isn't loaded for users with blacklisted browsers. Okeyes (WMF) (talk) 22:53, 1 July 2013 (UTC)
          • So we have to do user agent spoofing to be able to disable visual editor? Pretend to be somebody else who we actually are not just to get the features we need (and only those)? Is this what you want to tell me . What is the reason to not simply add back the pereference to disable VisualEditor? This is already in the code and would be a no-brainer to add back. Probably you even had to remove it prior to the final deployment of VisualEditor. I really do not understad what you are trying by patronizing us and forcing features on us we do not need? --Patrick87 (talk) 23:29, 1 July 2013 (UTC)


  • My first impression is that I extremely don't like this. But, I am also a long-time veteran editor who is very comfortable with the classic edit window, so I know VE isn't really aimed at me anyway. VE will just slow me down, but hopefully it does help new/novice editors who would prefer a word processor-like experience. I can get used to clicking "edit source" at the top instead of "edit page", but my one request would be to have the ability to make each section's Edit button default to the classic window (or, as others ask, disable VE entirely). It may seem like a small thing to hover the edit link then move to the edit source button that appears, but I have always found such mouse overs cumbersome and annoying. Resolute 23:36, 1 July 2013 (UTC)
    • Yes, it's totally annoying (as compared to the WMF statement that the old editor would still be able via "edit source" (it is, but it's inconvenient). Additionally this hover functionality breaks MediaWiki:Gadget-righteditlinks.css (which was only needed because the WMF broke the positioning of section edit links before, probably also to be able to add the hover functionality in the first place). --Patrick87 (talk) 23:45, 1 July 2013 (UTC)
      • As much as I don't like VE being enabled for everyone now, and as much as I don't like it not being disableable (see my killer script above), that was actually done by myself in my capacity as a volunteer developer. I won't repeat the reasoning which was already repeated here at VPT ad nauseamafter it was changed. :) Matma Rex talk 23:48, 1 July 2013 (UTC)
  • I've had it enabled for a while, you do get used to it. That said, there's been enough requests for an opt-out that the VE team will be having some discussions on this point ASAP. PEarley (WMF) (talk) 23:50, 1 July 2013 (UTC)
  • Thanks! I'm afraid to say, but this is the first WMF statement on this issue that sounds as if some consideration was put into, not trying to convince us that "everything is fine". Regarding the section edit link's position: I'm fine with that, I only wanted to note that those "features" offered by VE easier break already existing things than some might think. Every additional bit of code is prone to errors (that's a fact!). --Patrick87 (talk) 23:59, 1 July 2013 (UTC)
I should qualify this by saying that I will do my best to bring these concerns forward, and can promise nothing. PEarley (WMF) (talk) 00:13, 2 July 2013 (UTC)
I'd like to add that the reason the devs didn't provide the built-in prefs switch is because what they wanted to provide (more like a fundamental per-user disabling than Matma Rex's script) was far more complex than expected, and it has serious bugs. (The old prefs switch wouldn't work in the current system; I admit that my eyes glazed over when the explanation started.)
If you've looked through the recent changes, then I'm sure you can understand why the devs believe that fixing the bugs that are resulting in dirty diffs screwing up some articles is more immediately urgent than adding a prefs switch, even though they are aware that an opt-out is important to the old hands (partly because Patrick and I have been pounding on the table and insisting that it's important, which we are planning to continue doing).
As proof that they understand how important this is, you should know that Matma Rex wrote his script in response to a direct request from the devs, when they realized that theirs was too unstable to release. They aren't trying to deprive you of control over your editing environment; they're just trying to work on what's most urgent. I think they were hoping that Matma's script would work well enough that it wouldn't be necessary to go back to "complicated", but if it's not, then Patrick and I know where the table is, and we can pound on it some more. But we need to work within reality: complicated code doesn't sort itself out just because we all want it to be fixed already. It will take time and careful thought. So if y'all can stand down for a few days, we'll see what we can do. Whatamidoing (WMF) (talk) 06:25, 2 July 2013 (UTC)
While I appreciate that there's hard work going on to try to make everything work, I can't help but feel that, in that case, it would have been better to push back the deployment of VE, and to get it all done (or as close to 'all done' as feasible), and then roll it out, instead of rolling out an incompleted product and touching off a firestorm among the editing base that has, apparently, resulted in editors leaving - quite the opposite of what VE was intended to do. - The Bushranger One ping only 06:32, 2 July 2013 (UTC)
I'm only aware of one editor leaving (if there are more, I'm happy to talk to them). Actually, I agree, it would be nice if things were much more workable. But it's worth noting that a lot of the bugs and issues we're dealing with here are not bugs we'd encountered before - sometimes the best way to identify them is to follow the "many eyes" principle. We could have perfectly-designed software, and have it rendered buggy and useless by how people use it in practise, which means that finding out how people use it is key to making it function. Okeyes (WMF) (talk) 06:43, 2 July 2013 (UTC)
True 'nuff - that's why everyone, when something is rolled out, needs to be issued a complimentary can of Raid. - The Bushranger One ping only 07:43, 2 July 2013 (UTC)
If only it was that easy! (I note that with this edit we're now having a conversation via edit summary, which is somewhat meta - although not as meta, presumably, as me referring to it in the abstract). Okeyes (WMF) (talk) 07:49, 2 July 2013 (UTC)
Purely personal opinion: you might decide that I'm being excessively cynical, but my experience is that power users (a category that is broad enough to include basically anyone posting to this page) almost never actually leave because of something like this. See meatball:GoodBye, and check the user's contributions in a couple of weeks. WhatamIdoing (talk) 08:55, 2 July 2013 (UTC)

Keyboard shortcut disambiguation needed

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

"Opt out" of VE needed under preferences

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

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

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

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

Tracked in Phabricator
Task T52929
Resolved

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

  • Support We need a way for those who wish to easily opt out of this VE and use the old editing interface just how it was before. Please add. After 80,000 edit I do not need a new editor. I support the VE for those who wish to use it. Doc James (talk · contribs · email) (if I write on your page reply on mine) 23:38, 1 July 2013 (UTC)
  • Support; this shouldn't need to be brought up. StringTheory11 (t • c) 23:46, 1 July 2013 (UTC)
  • Strong support Paternalism by the WMF is not acceptable. There are preferences for things much less important. The Editor is the central component of Wikipedia and therefore needs it's own setting in preferences. I want to be able to configure which editor I'm using. The code for the opt-out preference is already there (it was used in the beta-phase), so implementation (or rather adding back) of the preference is a no-brainer. --Patrick87 (talk) 23:51, 1 July 2013 (UTC)
  • Support, while my browser will shortly be blacklisted from VE making it a non-issue, offering people who don't like it the choice to say no is a good thing. - The Bushranger One ping only 23:56, 1 July 2013 (UTC)
  • Support: I never really did see a response about why this feature is not available. SL93 (talk) 00:04, 2 July 2013 (UTC)
  • Support. This seems like a no-brainer. Everyking (talk) 00:12, 2 July 2013 (UTC)
  • guys, there is a way to get out of it. As explained above, if you add:
    importScript('User:Matma_Rex/VE_killer.js');
  • to your common.js, everything goes back to normal. Okeyes (WMF) (talk) 00:40, 2 July 2013 (UTC)
    We want a simple clean "do not load" option under preferences. I do not think that is too much to ask. When VE works or is better than what we have now people will use it. CUrrently it unfortunately is not. The fact that it does not easily handle referencing is a deal breaker for me. Doc James (talk · contribs · email) (if I write on your page reply on mine) 00:48, 2 July 2013 (UTC)
    • Why would you rather repeatedly inform editors of this? Less editors would need to be informed of that if the option to opt out is in preferences. SL93 (talk) 00:47, 2 July 2013 (UTC)
    No, it doesn't, it only hides VE after it's loaded. So we have it flash in, then flash out, and all of the code is still loaded. It's an awful, crude workaround. Matma Rex talk 00:43, 2 July 2013 (UTC)
    Which is sub-optimal, I appreciate, but mostly out of performance concerns. For those users who simply don't like the interface, we now even have it gadgetised to simplify things. Okeyes (WMF) (talk) 00:46, 2 July 2013 (UTC)
    And performance concerns are negligible or how should I understand your statement? Why don't you just add back the user preference which was there before? The setting would fit into the "Edit" section much better than it fits into the Gadgets section anyway (and it would be a clean solution in contrast to the Gadget-version). Since when is WMF promoting Gadgets anyway? Last time I asked about a Gadget broken by the WMF the response was "we don't support Gadgets so we're afraid we cant help you". --Patrick87 (talk) 01:07, 2 July 2013 (UTC)
  • Support: A request for a preferences click box is not the same as "use this script to kill it." Sorry, I think there should be a check box in preferences to turn off Visual Editor. I never heard about it until last week; today it appeared on my screen and I don't want to use it. I think there should be a way to opt in/out in preferences whether or not there is a script to get rid of it. What if someone wishes to turn it off now, and turn it back on later when the bugs have been ironed out? Ellin Beltz (talk) 00:45, 2 July 2013 (UTC)
    There (strictly speaking) now is one, here (top of "editing"). Okeyes (WMF) (talk) 00:46, 2 July 2013 (UTC)
    Strictly speaking there is no such option to disable Visual Editor. The proposed Gadget only hides it's UI, the Visual Editor is loaded in background nonetheless. --Patrick87 (talk) 01:35, 2 July 2013 (UTC)
  • Support It would be nice to have this choice. Mark Arsten (talk) 00:46, 2 July 2013 (UTC)
    There's now a gadget checkbox here (top of "editing") if you want to hide it. Okeyes (WMF) (talk) 00:46, 2 July 2013 (UTC)
    Thanks Okeyes. That definitely makes it easier to figure out and apply. Doc James (talk · contribs · email) (if I write on your page reply on mine) 00:50, 2 July 2013 (UTC)
    Looks good, thanks. Mark Arsten (talk) 01:11, 2 July 2013 (UTC)
  • Support It's rather ridiculous this was not included at launch. Those of us who have already learned Wikimarkup gain little to no benefit from it, although I do think it'll be great for new users. Adam Cuerden (talk) 00:50, 2 July 2013 (UTC)
  • Support I thought there was going to be one... I remember this being said a month or so ago, what happened? "When it becomes the default, you can go to Special:Preferences#mw-prefsection-editing and turn it off. Of course we can't predict what might happen far in the future, but, at this time, there are absolutely no plans to remove the old editor." I went today to look in my preferences to turn this off because i saved this in my sandbox to opt out when the time came but apparently it's not there. I would like it to be there though instead of having to opt out using JS. — -dainomite   00:57, 2 July 2013 (UTC)
  • Support We want to be able to switch VE off completely, please. Would you bring back the switch in preferences?--Aschmidt (talk) 01:06, 2 July 2013 (UTC)
    As I see now, it's back in the preferences pane. Thanks!--Aschmidt (talk) 01:12, 2 July 2013 (UTC)
    No, sadly it is not. A Gadget was added that hides all UI elements of Visual editor (or rather undoes it's changes to the UI). The Visual Editor itself is still loaded in the background. --Patrick87 (talk) 01:37, 2 July 2013 (UTC)
  • Support There are many of us who hate slow-loading, script-bloated boxes (and thanks for a script gadget to remove it, but no). However, it is clear that a hope is retained that we will learn to like the visual editor, so let's compromise. Mark the preferences option as experimental, with some wording that the setting will be cleared each month. Then, everyone gets to try the new system at least once a month. I see the report above that it's back, but I thought I would post what I had written anyway. Johnuniq (talk) 01:16, 2 July 2013 (UTC)
    • Your writing is still valid. The Gadget provided only hides the VisualEditor's UI elements, the setting to correctly disable it is not back yet. The VisualEditor itself and all of it's JavaScript is still loaded in the background. Therefore this setting solves none of the "slow-loading, script-bloated boxes" but only hides them. --Patrick87 (talk) 01:42, 2 July 2013 (UTC)
  • Preferences → Gadgets → Remove VisualEditor from the user interface --  Gadget850 talk 01:15, 2 July 2013 (UTC)
    • I realize this, but I noted above that having section edit links default to VE was a nuisance, even if the mouseover brings up a parallel link. I viewed this as a minor nuisance, but still one that I am happy to eliminate by turning VE off. I'm not dismissing the work you guys put in to setting this up, but the classic interface is better for me and the option to disable simplifies things. Resolute 14:53, 2 July 2013 (UTC)
  • Support as expressed above; a total no-brainer. Beyond My Ken (talk) 01:18, 2 July 2013 (UTC)
  • Support Firstly because we were being promised repeatedly that this option would always exist- not providing it discredits all the editors who made the promise. Support because editing is 40% text and 60% references, and training a group of new editors to hop over the edit button to the edit source, so they can add a reference blows their confidence immediately. Support because VE is so unstable it can only be used by experienced editors who can navigate around its shortcomings- it is not suitable for new editors. We need a quick way to help new editors to blank it out.-- Clem Rutter (talk) 01:31, 2 July 2013 (UTC)
  • Support. The Gadgets version is not sufficient; for best performance the VE code simply should not be loaded. -- King of ♥ ♦ ♣ ♠ 01:55, 2 July 2013 (UTC)
  • Support. The VE should NOT be forced on people. Many people have spent many years learning and perfecting wiki markup and code. If you want VE enabled by default on new accounts sure, but it should NOT be forced on existing editors. Jguy TalkDone 03:20, 2 July 2013 (UTC)
  • sigh* just logged into my work machine (which is sadly IE8 (it's still supported as long as XP is supported)) and the interface is completely broken for me, even with the 'gadget' checked. The javascript being loaded is way too much. And wiki.riteme.site is in my list of trusted Intranet safe sites. This is where I do a majority of my editing, so I suppose I'm done with Wikipedia until such a time where the old editor is brought back and/or the option to disable VE completely is brought forward. It is quite sad to see all of these editors bow out because of this forced change, many of whom have been here for many years. I've witnessed 5 so far myself. This should not be forced, it should be an opt-in. We should also not be told to 'deal with it'. Jguy TalkDone 03:47, 2 July 2013 (UTC)
...according to what I can see, you shouldn't be getting anything VE-related on IE8, as anything from IE10 or before is blacklisted for it? - The Bushranger One ping only 03:59, 2 July 2013 (UTC)
@Jguy:: Bushranger is, as usual, correct; you shouldn't be getting this. Can you send me a screenshot or something when you have time? Okeyes (WMF) (talk) 06:41, 2 July 2013 (UTC)
Perhaps my browser was having an episode, as the site works correctly this AM (it was previously completely unbrowsable due to the amount of Javascript, e.g. would not load). My opinion still stands. While you might think the VE is the next big thing I do not support it being forced onto people and enabled in their preferences automatically. While it might not be broken and might include all the features to make editing easier, its quite apparent that most editors do not like it because they're used to what they know. This obviously is the exact opposite of 'easy' to them. This action by the WMF is almost like them playing 'big brother' and forcing things and ideals on people. What happened to concensus on this? Was it decided in a RfC that all editors will have it enabled by default come July 1st? I can't wait until it gets enabled on other language wiki's. We're going to have a very bad storm on our hands before too long. Jguy TalkDone 13:15, 2 July 2013 (UTC)
  • Support. Logged on this morning to find it enabled by default - spent a couple of minutes finding out how to disable it which I've now, thankfully, done. In an ideal world, experienced editors should be seeing a big red button on their screen saying "VE is here - here is a demonstration of how it works, and here is how to disable it if you don't like it." I may use it in time, but that will be in my own time, not yours, thank you very much. Ghmyrtle (talk) 07:48, 2 July 2013 (UTC)
    That's fair enough. The VE should actually be showing a help interstitial; is that not occurring? We advertised it fairly prominently beforehand (blog posts, signpost coverage, village pump notices dating back a year, a watchlistnotice for weeks, a centralnotice for a week); if you can come up with any ideas for us to do better next time, I'd be most appreciative. Okeyes (WMF) (talk) 08:00, 2 July 2013 (UTC)
    Small, unbolded messages at the top of the screen are what everyone - new users, old users, everyone - completely ignores. I knew it was coming in, but expected more warning (message on talk page, perhaps?), and some more explanation. Geeky explanations using words like "interstitial" and "javascript" are, for some of us, utterly meaningless and useless. But thanks for responding! Ghmyrtle (talk) 08:08, 2 July 2013 (UTC)
    Here's the problem: people ignore it because it's the communications method we use. If we start bolding them, six months later people will say "oh, I don't read those". If we make them blink, then we'll discover blink-blindness sets in.
    Meanwhile, if we notified everyone by more agressive means (talkpages, email), I fear we'd get more people yelling about the notifications than would yell about not being notified! Andrew Gray (talk) 22:40, 2 July 2013 (UTC)
  • Support Exactly what User:Ghmyrtle said. Cheers, LindsayHello 08:11, 2 July 2013 (UTC)
  • Support. This is yet another botched new feature deployment by the WMF. I've made it perfectly clear that I don't want to be screwed around with and the WMF have made it clear that it will be actually disableable (not fake disableable via gadgets). What is going on? MER-C 08:55, 2 July 2013 (UTC)
    I can't see any comment in that FAQ that says that. It was, I think, in a previous version, when the FAQ was volunteer maintained and written. Okeyes (WMF) (talk) 09:00, 2 July 2013 (UTC)
    Re "botched"; if you want to talk through what you think we could have done better, I'm happy to do that. Okeyes (WMF) (talk) 09:02, 2 July 2013 (UTC)
    Isn't it obvious? How about fixing all known bugs and making it reasonably feature complete (redirecting a page?) before wide-scale deployment? How about not foisting said buggy software on clueless newbies? How about not deploying a mess of slow-loading JavaScript with no means of getting rid of it? (Whatever happened to the bit about increasing participation in the Global South, where internet is crap?) We are here to build an encyclopedia, not test bloated, buggy software! Oh, and fire Eloquence, as him not giving a rat's arse (on multiple occasions) is fully incompatible with his role at the WMF. MER-C 10:55, 3 July 2013 (UTC)
    If we followed that standard, we'd have to shut down Wikipedia entirely. There are "known bugs" for the old system, too. Whatamidoing (WMF) (talk) 11:45, 4 July 2013 (UTC)
    Hi everyone recently I used the visual editor while trying to edit a page. It definitely falls way short in terms of replacing the wikimarkup editing if you want my opinion. I immediately disabled it. ---$o#aM ❊  আড্ডা  09:15, 2 July 2013 (UTC)
    Okay; can you explain anything specific it needs to improve at handling? Okeyes (WMF) (talk) 09:20, 2 July 2013 (UTC)
  • I'm not even going to TRY to figure out if I'm posting in the right spot. I said last night that I was gone, and that's just how I feel/felt. And I thank Doc James for pointing me to this thread - and at least when I clicked edit I got a window I could work in. Anyway .. changes like this VE thing should be either "for new editors" or they should be an "opt-IN" thing. I knew what was when I signed up for wiki .. and this VE thing wasn't it. I'm not even tempted to go looking for any "opt-OUT". If it's progress, that's fine ... but I'm not interested. No offense Okeyes, I'm glad you trying to recruit NEW editors - but I really do despair for the "OLD" ones. Press 1 for English? ... BS .. press 1 for some foreign language. — Ched :  ?  13:12, 2 July 2013 (UTC)
  • Support. I thought the purpose of the Visual Editor was to engage new editors, not to scare away the established ones. Even if the VE had all the features available in the regular editing window (which it doesn't) and worked flawlessly (ditto), I much prefer to spend my limited Wikipedia time on actual editing, instead of on re-learning every editing habit I have.—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); July 2, 2013; 14:27 (UTC)
  • Support. I've clicked on the new "edit" button by mistake a few times, and the articles have been slow to load (one took 15 seconds), but when I hit the back button or stop, my browser briefly froze, so having these two tabs next to each other is not ideal. An opt-out would be very helpful. An opt-in would be better still, because I think the VE (as currently presented) is going to make things harder for editors, new and old. At the very least, so long as the two tabs are next to each other, the new VE tab should be called Visual Editor, or "new editor" or something, rather than "edit," which would reduce mistaken clicks. SlimVirgin (talk) 17:10, 2 July 2013 (UTC)
  • Support. There's almost never a good reason to force things on us, and this is definitely no exception; we need to make it disableable instead of just hideable. Nyttend (talk) 17:35, 2 July 2013 (UTC)
  • Support. I agree with pretty much everything that's been said here. It would be nice to able to choose Visual Editor on occasion, but it's been really annoying to hit "edit" and find myself in a situation where I can't edit categories, can't easily edit old coding, etc. Furthermore, because VE is somewhat handicapped, it seems to me that newbies who originally get involved via VE should have an easy way to opt out of the default -- and adding a string to JavaScript isn't an easy opt-out. --Orlady (talk) 17:39, 2 July 2013 (UTC)
  • Support - I think the concept of VE is great but the implementation is thus far terrible. I agree with the comments here as well. Kumioko (talk) 17:43, 2 July 2013 (UTC)
  • Support North8000 (talk) 17:46, 2 July 2013 (UTC)
  • Support What a croc o' shite. Lugnuts Dick Laurent is dead 18:20, 2 July 2013 (UTC)
  • Support VE is great for new editors and I even support turing it on by default, but it's laborious and clunky for old hands. Please just turn the existing checkbox option into one that completely disables it when selected. Pol430 talk to me 22:31, 2 July 2013 (UTC)
  • Support I was told, back when the tests and all started, that I would have the choice to opt-out (to be exact, I was referred to the FAQ, which back then said I could turn this infernal gadget off). Now, when this thing is launched, I don't have such an option after all. I feel conned. Plus, having this thing load in the background is a real issue for my terribly slow internet connection. All of which, I've already told you, repeatedly. But, hey, I'm just an old hand, and I'll "never actually leave because of something like this". Right? Manxruler (talk) 01:02, 3 July 2013 (UTC)
  • Support Why? Why make this difficult for users, who prefer not to have it and are now forced to wait three times as long for a page to load, and even longer in some cases to suppress it?—cyberpower ChatOnline 01:50, 3 July 2013 (UTC)
  • Support My system is not the newest or fastest in the world, and I don't see why I should have slower load times and fidgety edit links when I will never use this feature. I tried it, I hated it, I'm done with it. -Rrius (talk) 03:26, 3 July 2013 (UTC)
  • Support The Crab Who Played With The Sea (talk) 08:13, 3 July 2013 (UTC)
  • Support. I got rid of it, it has returned. There needs to be a better way. Tassedethe (talk) 00:05, 4 July 2013 (UTC)
  • Support. The gadget only hides it, it doesn't stop it from loading. IMO VE is still too buggy and clumsy to use. —Bruce1eetalk 05:08, 4 July 2013 (UTC)
  • Support I'm another with a slower system who found this imposed upon me with no easy way to disable it and nothing whatsoever on the Editing section of Preferences. Timrollpickering (talk) 15:16, 6 July 2013 (UTC)
  • Support Why is this a discussion and not common sense? I like the visual editor, I just don't want to ALWAYS use it. -- A Certain White Cat chi? 19:46, 6 July 2013 (UTC)
  • Support - I know it's summer but it's definitely SNOWing here. I haven't seen such clear, overwhelming consensus about anything in a long time - hopefully the WMF will take note for future... GiantSnowman 10:56, 9 July 2013 (UTC)
Actually I've never seen such clear and overwhelming ignorance as the WMF is currently expressing by not seeing this consensus. I'm sad to say it but I'm deeply disappointed with their work. The atmosphere is freezing here! --Patrick87 (talk) 11:28, 9 July 2013 (UTC)
  • Support and even strong support as currently VE is more damageable than useful, but still support after bugs are fixed and features redesigned to be useful because every user can choose by himself if he wants the overhead of VE or not. --NicoV (Talk on frwiki) 16:38, 9 July 2013 (UTC)
  • Support, of course. Opt-out should be provided piece of the software and not something we have to hack together on after the fact. Dragons flight (talk) 16:59, 9 July 2013 (UTC)
  • Support, I'm shocked at how slowly and poorly this thing works for something being foisted on all editors as ready to use. Nor do I personally have any desire to spend my time learning how to do things with it that I already know how to do in normal editing, as I've found the VE remarkably unintuitive. As commented by many above, turning it off needs to be easy and complete. postdlf (talk) 17:19, 9 July 2013 (UTC)
  • Support. Obviously, especially when the VE is likely to lose editors rather than gain some. the effect it has on one new editor. I'm wondering how many thousands of others feel like this. Kudpung กุดผึ้ง (talk) 00:46, 10 July 2013 (UTC)
  • Support - The new JS loads slowly and the extra tabs clutter the appearance of pages; in what world do you add a clunky, bug-ridden 'feature' to the core productivity area of your site and not provide the option to properly disable it? FLHerne (talk) 17:03, 10 July 2013 (UTC)
  • Support - This would be especially useful for editors with slow internet connections and us WikiNerds who want to edit their plain markup. Furthermore this shouldn't have been ruled out without an option to properly and completely turn it off. -- Toshio Yamaguchi 13:48, 11 July 2013 (UTC)
  • Support While have have it hidden, I still have the issues where my browser (Firefox and Chrome) freezes or crashes. Bidgee (talk) 13:51, 11 July 2013 (UTC)
    • There is no way in heaven that that can be related to either the VE init script or the VE hide script. These two scripts are so minimal now, I can't imagine for the life of me that they would cause a crash. (ULS seems more likely). —TheDJ (talk • contribs) 14:56, 11 July 2013 (UTC)
      • I don't have the problem until I load the English Wikipedia, it didn't have the issue before the VE rollout and I don't have the issue on Commons. It maybe "minimal" but it causes the freezing and crashing of the browser on all of my computers (not just one). Bidgee (talk) 15:46, 11 July 2013 (UTC)
        • Bidgee, you only seem to be active here, at Meta, and at Commons. Universal Language Selector, which was unfortunately turned on the day after VisualEditor, is configured differently at multilingual projects (e.g., Meta and Commons) than it is at the Wikipedias. It would be very helpful if you would try to see whether you have the same problems at another Wikipedia, like de.wikipedia (where VisualEditor has not been made available to all users yet). If you get the same problems there, it's almost certainly ULS. Additionally, it would be helpful to have browser and OS information if you continue experiencing problems. Whatamidoing (WMF) (talk) 21:33, 11 July 2013 (UTC)
          • It is clearly a VE issue, I have no issues with de.wikipedia and simple.wikipedia. OS X 10.8.4 running Firefox 22.0 and Chrome 28.0.1500.71, My Windows 7 desktop and laptop both have latest updated browsers (FF 22 and C 28.0.1500.71 m) and have the same issue with English Wikipedia as the OSX. Bidgee (talk) 05:58, 12 July 2013 (UTC)
  • Support should be able to be turned off and on by the user like many other features. — MrDolomite • Talk 17:57, 12 July 2013 (UTC)
  • Support I tried it, but it was way too slow for my computer, and I couldn't figure out how to include simple wikitext without having to click at a lot of places, wasting a lot of extra time. I immediately disabled it, but it still takes extra time to load articles. I've considered disabling JavaScript for English Wikipedia, but this would sadly also disable essential tools such as WP:TW. --Stefan2 (talk) 19:48, 15 July 2013 (UTC)
  • Support; also, make VE better please. It needs to be the way of the future. I made an edit (wikitext) to United States the other day and it was essentially impossible because there are roughly 500 kajillion citations on the page. It was almost impossible to see where the article text was in the editing box because it was so drowned in citations. VE would've made that a LOT easier. Please. Get VE fixed. Red Slash 19:20, 18 July 2013 (UTC)
  • Support. I'm actually somewhat astonished that the opt-out preference has not been added yet. The arguments seem to boil down to this:
    Core user: "VE is not helpful, I don't want to use it, please let me turn it off."
    WMF: "If we allow core users to disable VE, then we won't get the feedback we need to improve VE."
    Here's the flaw in that reasoning: If people don't want to use VE, they're not going to, and making it harder for them to not use it isn't going to make them want to use it more. If feedback on this feature is so important to you that you're willing to ignore unanimous consensus from the community of core editors to try to get it, shouldn't it also be important enough that you would be willing to, say, hire testers? I really don't understand how you guys came to the conclusion that the only way to get the feedback you need is to deny editors the option of not giving feedback. --Cryptic C62 · Talk 00:42, 19 July 2013 (UTC)
  • Support. This "we know what's good for you" attitude is disgraceful. Stifle (talk) 15:18, 20 July 2013 (UTC)
  • Support. WMF/the devs should have used the feedback you received during the voluntary test phase and not made it the default until it was adequate. Making it easy to turn off and stopping it from hobbling those on less than superb machines and connections is the least they can do to make up for what they did instead. Yngvadottir (talk) 18:34, 20 July 2013 (UTC)
  • Strong support. The option to disable Visual Editor should not be buried under the gadgets tab but should be listed under the "Editing" tab, where all the other options for disabling various aspects of editing exists. As far as discoverability goes, I had to dive into the village pump to find the link to show me the section in the preference pane to disable VE. Agree that it would be ideal if background loading could be disabled, but to me the main issue is that VE disable option is not under the Editing tab. The main reason why I want to disable VE UI, or the straw that broke the camel's back, is the annoyance caused by trying to select an article section text only to have the "[edit]" link morph into "[edit | edit source]" upon mouse hover over. The innocent mouse gesture for selecting text is blocked now by the hover over UI (not friendly to tablets) for a feature that I don't use. But that really shouldn't matter what my particular reason to want to disable VE was. What should matter is there are people out there who want to disable VE and Wikipedia should support those users better. Food for thought. --Makkachin (talk) 13:19, 21 July 2013 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

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

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

"Opt-out" being re-enabled

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

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

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

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

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

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

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

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

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

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

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

When will it be enabled?

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

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

Login glitch?

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

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


Toolbox


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

Please see #New Single User Login system, login success page going away above. --Redrose64 (talk) 14:57, 22 July 2013 (UTC)
Yes, I assumed that. Doesn't explain why on two occassions it decided not to redirect me to the Main Page and instead stopped on some foundation page (which appears to be connected to the login process). Brambleclawx 15:16, 22 July 2013 (UTC)
The problem you are reporting sounds like a potential issue in the code of the MediaWiki software or the server configuration. If the problem is reproducible, it would be nice if somebody who has this issue could send the software bug to the 'Bugzilla' bug tracker (under product "MediaWiki extensions" and component "CentralAuth") by following the instructions How to report a bug and providing additional information (used browser and version, etc). This is to make developers of the software aware of the issue. If you have done so, please paste the number of the bug report (or the link) here, so others can also inform themselves about the bug's status. Thanks in advance! --AKlapper (WMF) (talk) 08:18, 23 July 2013 (UTC)
I can't reproduce reliably. It just happens once in a while. Brambleclawx 14:42, 23 July 2013 (UTC)

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

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

Hypothetical vandalism - how to reverse?

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

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

Tech News: 2013-31

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

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

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

20:44, 28 July 2013 (UTC)

Special:Search and special character

Tracked in Phabricator
Task T49770

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

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

Updates on VE data analysis

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

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

Blanking of default text in ACIP-created user pages

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

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

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

Notification number error

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

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

Did something just change with redirects?

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

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

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

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

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

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

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

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

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

Comment

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

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

You can turn it off?!

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

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

No Page View Statistics

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

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

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

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

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

Austria-Hungary|| here I want France

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

Austria-Hungary|| here I want Russia

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

Austria-Hungary|| this is OK

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

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

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

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

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

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

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

urn:nbn:de:1111-200606299

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

urn:nbn:de:1111-200606299

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

List of Redirects

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

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

Creating user sub-pages - should permissions be restricted?

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

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

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

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

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

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

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

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

OK, how about this:

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

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

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

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

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

Difficulty creating new username

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

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

My Sig arrow got "boxed"?!?

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

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

New VisualEditor RFC

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

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

Staying Logged on

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

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

Bizarre vandalism reversion edit

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

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

Position of templatedata

Tracked in Phabricator
Task T52512
See also: Wikipedia talk:VisualEditor/TemplateData § Move to subpages? To new namespace?, and bugzilla:50512
This RfC was prompted by a post on OKeyes's talk page.

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

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

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

At the bottom of template itself
  1. ...
At the bottom of the template's documentation page
  1. ...
In a separate "TemplateData" section on the template itself
  1. ...
In a separate "TemplateData" section on the template's documentation page
  1. TemplateData outputs a human-readable format, which provides quite nice documentation on the parameters supported by the template (particularly useful when editing via wikitext), so it is quite fine for this to be on the doc page. Anywhere on the doc page (even under Usage) would be fine by me. — This, that and the other (talk) 09:26, 2 July 2013 (UTC)
  2. This seems a fairly nice and obvious page. I've been adding it just before the see also section. Documentation of templates is generally quite messy, no consistent style is used, they are often verbose, don't always contain examples or explicit lists of parameters and if they do they use a variety of formats. The template data section does allow a consistent style and in time could be a helpful way to standardise documentation. It does need to a bit richer though: allowing links, wikimarkup, support for explicit options (yes/no), a finer graduality of status: required/recommended/optional/not-recommended. Six months down the line it could become the documentation format; moved up the documentation pages replacing the current ad-hoc standards--Salix (talk): 08:34, 22 July 2013 (UTC)
On a subpage of the template titled "/templatedata"
  1. If this would be possible (while still being able to easily include this information in the documentation) this would allow to easily split the TemplateData from the rest of the template/documentation so it keeps clean at all times. This would also aid programmatic access of TemplateData a lot I assume. --Patrick87 (talk) 17:12, 1 July 2013 (UTC)
On a new namespace, specific for the JSON of templatedata

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

  1. Helder 20:44, 29 July 2013 (UTC)
Discussion
  • No preference whatsoever, but if someone can find the time to expand TemplateData with a Lua api, then we could probably auto-generate large parts of the /doc output. —TheDJ (talk • contribs) 21:35, 1 July 2013 (UTC)
  • Note that Wikipedia:VisualEditor/TemplateData_tutorial#TemplateData says "The TemplateData is placed after the descriptive information about the template and before the "See also" section." which is what I've been fixing the newest additions to match. So that's the current standard/baseline. –Quiddity (talk) 21:59, 1 July 2013 (UTC)
    That was just added a few hours ago by CaroleHenson. Theopolisme (talk) 22:24, 1 July 2013 (UTC)
    Well, 15 hours ago, and before this RfC, and during my "last night" which is when I first looked. And before that it still contained the detail "after the descriptive information about the template and before the "See also" section." But I won't quibble... ;) –Quiddity (talk) 23:04, 1 July 2013 (UTC)
    Haha, you're quite right. :) But it was only added based upon the discussion that I linked previously, not any specific policy per say. Theopolisme (talk) 00:00, 2 July 2013 (UTC)
  • I'd weakly object to placing the templatedata on a new subpage. I agree that it could/would help with organization, but it would also be one more place to watchlist (this is already a problem with documentation subpages..), and it would also further bulk up the results of searches in template-namespace (also a problem with doc subpages) particularly when typing in the VisualEditor template-selection box. [There are potentially ways to fix this (eg. excluding /doc subpages from the autocomplete search results), but they involve development work and/or further complications with subtle edge cases and use cases. Might be more trouble than worth.] –Quiddity (talk) 18:59, 6 July 2013 (UTC)
  • Unarchived by Redrose64 (talk) 08:09, 22 July 2013 (UTC)
  • All things being equal, i'd like tempaltedata to be on the same page as the template itself. there are several reasons for this, but they are not that important.
    thing is, all things are not equal. many of the templates are protected, and placing templatdata on the template page basically means only sysops/admins will be able to add and amend the templatedata.
    i'm in favor for placing templatedata in (yet another) subpage. i do not think the "doc" subpage is appropriate. we could do some "half and half" approach: put templatedata on the template page if the template is not protected, and on "templatedata" subpage if it is. peace - קיפודנחש (aka kipod) (talk) 01:47, 29 July 2013 (UTC)
The majority of the template data now seems to be on the /doc subpages. There are some cases where two templates use the same documentation, for example {{larger}} uses Template:Resize/doc for its documentation. This means the TemplateData needs to be in separate subpages, I've used /TemplateData. This discussion might be better at Wikipedia talk:VisualEditor/TemplateData.--Salix (talk): 07:15, 29 July 2013 (UTC)

TemplateData: Is it working?

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

I haven't seen it working yet either. I was under the impression that VE already had the functionality to read TemplateData built in, but I haven't seen any evidence of that - which means adding TemplateData to templates has no benefit whatsoever at the moment. I'm not going on a TemplateData adding spree until I see it working in VE. WaggersTALK 08:38, 3 July 2013 (UTC)
@Dragons flight: I've just seen this, which kind of answers our question. No timeframe yet though. WaggersTALK 08:44, 3 July 2013 (UTC)
See bugzilla:50372 for details/tracking. (Latest comment is "You appear to just be seeing the effect of weeks of job queue lag, i.e. a system problem, not a MediaWiki problem.") –Quiddity (talk) 15:34, 3 July 2013 (UTC)
@Dragons flight and Quiddity: Thanks - definitely working now, both for new and existing templates. There's just a bit of lag between TemplaateData to a template and it being available in VE. WaggersTALK 08:20, 4 July 2013 (UTC)

Random "Talk: you have new messages" messages?

Tracked in Phabricator
Task T54301

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

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

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

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

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

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

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

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

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

  • I've also been getting these messages even though I have no new message. It started for probably well over an hour ago. Then it went away for a while, and now it's back again. —Kri (talk) 22:14, 30 July 2013 (UTC)
  • This just happened to me. Inanygivenhole (talk) 22:20, 30 July 2013 (UTC)
  • Nyttend just left me a message saying that after he received a legitimate message on his talk page, the fakes stopped. However, I just got another fake when viewing my user page. CtP (t • c) 22:21, 30 July 2013 (UTC)
  • I've been having the same problem for the past hour or so. Glad to see it's not on my end. Friginator (talk) 22:23, 30 July 2013 (UTC)
  • Ditto to getting a fake message. I went to talk page, nothing new. Checked history, nothing new, but the bar remained. Not really sure how many of these ditto messages we need. Apteva (talk) 22:25, 30 July 2013 (UTC)
  • Nyttend left me a test message at my talk too, but that didn't make the notice go away. --Tryptofish (talk) 22:27, 30 July 2013 (UTC)
  • I got a real message by Nyttend at my talk page that he/she believed could maybe stop the fake notification, but the notification didn't go away even after I had visited my talk page and read what he/she wrote. It didn't seem to have any effect at all. —Kri (talk) 22:35, 30 July 2013 (UTC)
  • I'm a he, for future reference :-) I spammed seven people who'd come here to report this problem. Not sure why it stopped the problem for me but didn't for Tryptofish and Kri; perhaps it's a browser thing? Nyttend (talk) 22:40, 30 July 2013 (UTC)
Well, I use Firefox, and I also use the secure server here, but my guess is it's something within the Wiki system, and probably going on and off. --Tryptofish (talk) 23:05, 30 July 2013 (UTC)
Oh, I'm using FireFox 22.0, which is the latest I guess. And I don't get the notification when I'm logged out but it returns immediately again when I log in. —Kri (talk) 23:10, 30 July 2013 (UTC)
  • One thing I forgot to mention earlier is that, when I saw this happening, the top bar usually did not show "talk: you have new messages" until the page completed loading, showing the normal uncolored "talk" until then. Something in the CSS? - The Bushranger One ping only 23:36, 30 July 2013 (UTC)
I was lead to Visual Editor Issues/Complaints/Feedback. The Data sink. -DePiep (talk) 23:43, 30 July 2013 (UTC)
  • I had the same problem. The orange message indicator was there and wouldn't go away even though there were no new messages. North8000 (talk) 00:12, 31 July 2013 (UTC)
Do you still see the problem now? Dowjohn (talk) 00:43, 31 July 2013 (UTC)
  • @Nyttend: thanks for the message, it's gone now, but it's also many hours later. Maybe one of the Echo devs could comment on what this was and if it's solved, or if we should continue speculating and experimenting. It seems it started at the same time when html-emails were activated. — HHHIPPO 08:36, 31 July 2013 (UTC)
  • Hi all, sorry for this problem, which we believe should now be fixed. If you are still experiencing this issue, try refreshing your cache. This appears to be due to an older version of our Javascript code remaining in some of your browser caches and conflicting with our new version. We are still investigating why and how this caching bug crept in to impact the Notifications code, as we are not aware of anything we did on our end to cause it. Please keep us posted on this issue and thanks so much for reporting it! Fabrice Florin (WMF) (talk) 08:50, 31 July 2013 (UTC)

Blacklist help with ?????

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

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

Screenshots of Wikipedia

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

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

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

Ghost category

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

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

Alt-shift-p keyboard shortcut not working

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

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

Logo image in infobox

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

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

Google indexing sandboxes?

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

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

You asked a question; I tried to help; I might not have asked for thanks, but I certainly didn't ask for my advice to be stuffed right back in my face. But it seems that you have some problem with me. --Redrose64 (talk) 11:20, 26 July 2013 (UTC)

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

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

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

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

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

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

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

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

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

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

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

Overwriting sections

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

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

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

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

Change to VisualEditor integration on the English Wikipedia

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

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

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

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

Edit source vs. Edit

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

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

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

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

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

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

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

Whoo-eee, that's fine! Works splendidly on Safari 6/Mac OS 10.8. Seems to have the side benefit of restoring the "right-click on the header line to edit" gadget to edit source, not VE. I think I'll keep it around! One not-really-a-coding suggestion: You could put the script in your userspace (to make it easy to import/more official) and then stick a line in to import the CSS (as part of the JS), so people don't have to edit two separate pages.
 Done - the script (with some coding changes based on Reaper Eternal's method below) now has a home at User:Evad37/rename editors - Evad37 (talk) 17:16, 2 August 2013 (UTC)

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

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

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

I've always had Visual Editor disabled under Preferences/Gadgets. It still says "Edit Source" on my browser, as of today. I guess that takes some getting used to. I first noticed it on my Talk Page this morning, and my reaction was that somebody must have protected my page. Then I noticed that it's on all pages. It's a little disconcerting. — Maile (talk) 12:30, 2 August 2013 (UTC)
The setting at Preferences → Gadgets → Remove VisualEditor from the user interface just hides the VisualEditor, it doesn't actually remove it, so tabs and edit links may still behave strangely. However, the setting at Preferences → Editing → MediaWiki:Visualeditor-preference-betatempdisable prevents VE from loading, so tabs etc. should behave properly. To replicate the pre-VE behaviour, switch on the Editing one, and switch off the Gadgets one. --Redrose64 (talk) 12:52, 2 August 2013 (UTC)
Disabling it thru the Preferences/Editing worked for me. Thanks. — Maile (talk) 14:16, 2 August 2013 (UTC)
The gadget doesn't work currently due to a change in VE. It would be great if somebody with the proper knowledge could update MediaWiki:Gadget-oldeditor.js so users who have enabled the gadget and are satisfied with it don't have to find where to disable VE now. The gadget is not made by the VE team and they don't maintain it or keep VE compatible with it. PrimeHunter (talk) 13:49, 2 August 2013 (UTC)
PrimeHunter, what's wrong for you with the "official" gadget in Special:Preferences#mw-prefsection-editing --> Usability features? Thanks, --Elitre (WMF) (talk) 14:04, 2 August 2013 (UTC)
That one works. I only say "gadget" about the Gadgets tab. I was replying to Redrose64 who wrote: "The setting at Preferences → Gadgets → Remove VisualEditor from the user interface just hides the VisualEditor". I know that gadget isn't made by the VE team and they have never said they would keep it compatible with VE. But there are many users who have the gadget enabled and will be annoyed when they see VE has reappeared and they don't know the Editing preference that works. See Wikipedia:VisualEditor/Default State RFC#Was this just turned on for all users? for examples of angry users. PrimeHunter (talk) 14:15, 2 August 2013 (UTC)
(edit conflict)I agree 100% with User:PrimeHunter. I thought I had disabled this (expletive) thing on the preferences page, and today the bloody thing pops up again with editsource editbeta allover the place. I'm annoyed that I had to waste 10 minutes of my time trying to figure out how to kill it again. Then I see an option to "temporarily" disable it!? I don't want temporary... I don't want to see this thing ever again. A very clear consensus is forming at the RfC that this POS be opt-in only, to cause this thing to turn on again when it's been turned off is spitting in the face of the community.–Wine Guy~Talk 14:23, 2 August 2013 (UTC)
Yeah, I had to say option, sorry for that. If people want to fix the "unofficial" gadget, that's fine: but if this does not happen, I just wanted to make sure everybody realize there is no real need for that anymore since the "official" option does work. WineGuy, can you please see my second comment in this thread? Seeing VE again today was not planned or intended, again, I'm sorry for the trouble. --Elitre (WMF) (talk) 14:43, 2 August 2013 (UTC)
The unofficial gadget isn't needed currently for users who know the Editing preference, but this may change. The preference displays MediaWiki:Visualeditor-preference-betatempdisable. As strongly hinted by both the message name and text, the Wikimedia Foundation may remove this option when VE is officially no longer in beta. I think we should keep the gadget. If the gadget can be changed to toggle the Editing preference as suggested by Matma Rex then great, but if we delete the gadget and restore it later then I don't know whether its new state can be restored from the old state for those users who had enabled the old version and will be annoyed if they have to enable it again. PrimeHunter (talk) 15:20, 2 August 2013 (UTC)
In reply to User:Elitre (WMF) above: I appreciate your reply, and also the fact that the developers have once again put you, as the Community Liaison, in the awkward position of having to apologize for their misdeeds. The fact that this problem was "not planned or intended" is yet another indication that this roll-out has been, and continues to be, mishandled. As VE has been forced on people who don't want it, the dev team needs to be more careful about testing before going live with updates. –Wine Guy~Talk 16:36, 2 August 2013 (UTC)
Wine Guy, there is no way devs can actually know or prevent changes to something (be it VE, MediaWiki or whatever) from damaging something else - unless you don't really think that devs know all of the volunteer-written tools&gadgets everywhere in the wikiverse? :) - which is why things need, well, their maintainers, and caring people who mind letting them notice when their intervention is required. --Elitre (WMF) (talk) 16:48, 2 August 2013 (UTC)
In this case, I'll have to side with the devs. You can't account for every custom hack people implement. When updates happen, it becomes incumbent on the owners of said hacks to adapt if something breaks. Resolute 16:52, 2 August 2013 (UTC)
I don't really expect them to account for every custom hack, I do try to be reasonable. It would have been nice if they had anticipated this problem, though. –Wine Guy~Talk 17:39, 2 August 2013 (UTC)
"Anticipated" can cover a lot of territory, from foreknowledge to delaying these much-requested changes until a volunteer has time to update his code. The first probably happened, and I suspect that the last would have been unacceptable to the people who strongly advocated for these changes. Whatamidoing (WMF) (talk) 21:01, 2 August 2013 (UTC)

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

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

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

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

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

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

Negative Image

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

It looks fine to me (in Firefox 22 under Windows XP): black and gold on a white background. However, different browsers and operating systems can do funny things to JPEGs. Which browser and OS are you using? --Redrose64 (talk) 16:13, 2 August 2013 (UTC)
I just looked on a windows xp using chrome and you right it looks fine, however when using safari 5.1 and OX 10.6, it does look black.
Thank you --Rhamusker (talk) 16:17, 2 August 2013 (UTC)
The problem is that that image uses the CYMK colorspace rather than RGB. Firefox can render CYMK properly, other browsers not so much.--ukexpat (talk) 20:26, 2 August 2013 (UTC)

Template coding help needed

Template:Celestial events by month links has the v-d-e links and the hide button in a largish font. They should not be IMO. Can someone change it? I got a bit lost in the wikicode. Cheers -- Alan Liefting (talk - contribs) 01:14, 3 August 2013 (UTC)

Just remove font-size:1.5em;. PrimeHunter (talk) 01:25, 3 August 2013 (UTC)
Ta. Thought it might be something like that. -- Alan Liefting (talk - contribs) 01:34, 3 August 2013 (UTC)

Block showing in one place, but not another

Special:Contributions/71.156.18.97 does not show an active block for 71.156.18.97 (talk · contribs). But his block log shows a block I placed on him yesterday that has yet to expire. Then again, when I go to Special:Block/71.156.18.97, it does not warn me that the IP is already blocked, as I believe it should. Weird! Anyone know what's wrong? Someguy1221 (talk) 04:53, 3 August 2013 (UTC)

Revision history - Number of watchers

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

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

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

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

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

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

Email notifications

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

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

I've just turned it off; as I cautioned when this was first discussed, the email was full of unnecessary bloat. For example, for a nine-words-plus-links mail, before the first character of thoss words, was:

<html><head></head><body> <table cellspacing=3D"0" cellpadding=3D"0" border=3D"0" width=3D"100%" alig= n=3D"center"> <tr> <td bgcolor=3D"#E6E7E8"><center> <br /><br /> <table cellspacing=3D"0" cellpadding=3D"0" border=3D"0" width=3D"600"> <tr> <td bgcolor=3D"#FFFFFF" width=3D"35"> </td> <td bgcolor=3D"#FFFFFF" width=3D"61"> </td> <td bgcolor=3D"#FFFFFF" width=3D"469" style=3D"line-height:40px;">&nbsp= ;</td> <td bgcolor=3D"#FFFFFF" width=3D"35"> </td> </tr><tr> <td bgcolor=3D"#FFFFFF" width=3D"35" rowspan=3D"2"> </td> <td bgcolor=3D"#FFFFFF" width=3D"61" align=3D"center" valign=3D"top" ro= wspan=3D"2"><img src=3D"http://bits.wikimedia.org/static-1.22wmf12/extensio= ns/Echo/modules/icons/Talk.png" alt=3D"" height=3D"30" width=3D"30"></td> <td bgcolor=3D"#FFFFFF" width=3D"469" align=3D"left" style=3D"font-fami= ly:arial; font-size:13px; line-height:20px; color:#6D6E70;">

Note the inclusion of http://bits.wikimedia.org/static-1.22wmf12/extensio= ns/Echo/modules/icons/Talk.png which means calls back to the server when I open my mail.

I fail to see why forcing this on people is thought acceptable. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:46, 2 August 2013 (UTC)

This is not being "forced" on anyone. There is a very simply plain text or HTML preference under Notifications preferences, and it's even mentioned in the emails themselves. This is the default because it's far more readable. Most humans on the Web are just fine with having HTML email, considering they use modern web, mobile, and desktop clients that are easily able to handle calling a single image. Not to mention the fact that most users are not technical enough to know or care whether things like the Talk icon are called from the server or embedded etc. Steven Walling (WMF) • talk 20:48, 2 August 2013 (UTC)
And that preference was set to HTML, not by me. Ergo, the above email was forced on me. You have the ability to force that that on users, and apparently the authority to force that on users; and you clearly believe that you have the justification to force it on users. But please do not pretend that you did not do so. We were also told a while ago that the option would not persist. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:05, 2 August 2013 (UTC)
As it's a binary preference that (as I understand it) has only come into existence, the alternative was forcing all users to receive plain-text emails; either way you're going to have to "force" a decision on their behalf. Most people are happy with HTML mail; I don't think the preferences of a small group (including you and I) should be able to block a change that is uncontentious for the vast majority. Andrew Gray (talk) 11:00, 3 August 2013 (UTC)

Template data for citation

Template data was added for {{citation}}. The problem is that this template has two modes: patent and citation. Patent mode is switched by recognizing the inventor parameters. With a fully populated template data, editors are going to be presented with both sets of parameters, with resulting confusion. Thoughts? --  Gadget850 talk 01:21, 3 August 2013 (UTC)

I see that there is a notice that TD needs improvement there, but still: I'd consider using labels and/or descriptions in a "creative" way in order to distinguish among the two sets, at least temporarily. For example, patent-related parameters could include something like (P), while (C) would mean citation, so that you can recognize more easily the ones you are looking for. --Elitre (WMF) (talk) 07:48, 3 August 2013 (UTC)

Is it possible to pipe a link through an image? I.e. have a picture link to a page? I tried File:Wikipedia-logo-v2.svg|15px but it doesn't work. (Yeah, I know it is not good per MoS, and so it is something I want to add to a W namespace page, not main, so no worries here). --Piotr Konieczny aka Prokonsul Piotrus| reply here 09:30, 3 August 2013 (UTC)

{{click}}, though I notice that page now says you can do it with an attribute in the image code itself. Andrew Gray (talk) 09:43, 3 August 2013 (UTC)
. See Wikipedia:Picture tutorial#Links. PrimeHunter (talk) 09:43, 3 August 2013 (UTC)
The |link= method means that there is no longer a direct link to the file description page, which is required for all copyrighted images. --Redrose64 (talk) 10:22, 3 August 2013 (UTC)
Wrong. If |link= and a caption are both used then the funny little double-rectangle icon at upper right of the caption is still a link to the image description page, even though clicking on the image itself follows the |link= link. An example is seen in the first image in this section. (There's some odd stuff going on in the caption which isn't related to this question, but with which I'm hoping some technical wizard will assist -- if you're interested see Talk:Phineas_Gage#technical_stuff.) EEng (talk) 12:19, 3 August 2013 (UTC)
The icon with the file page link is caused by thumb whether or not there is a caption. It looks bad for small images. PrimeHunter (talk) 12:38, 3 August 2013 (UTC)
You're right -- thumb alone will do it. And you're also right it looks awful for small (and presumably captionless) images) but in practice such images may correspond to cases where the "link-to-image-description" may not be necessary anyway. (I'm sure someone can step in here and explain the requirements, but certainly many images e.g. WP logo linking to main page don't link to their descriptions.) In the case I linked to above, the object behind the image is a multipage djvu document. Unfortunately the cover page had been scanned crooked, and I didn't want that showing in the article. So I created a separate image of the title page with the crookedness corrected; that's what shows in the thumbnail, but if the reader clicks that image he's taken to the original multipage djvu so he can read whole thing. If for some reason he wants to see the description page for the what's thumbnailed in the article they can click on the little double-rectangle thingamajig (which turns out to be http://bits.wikimedia.org/static-1.22wmf12/skins/common/images/magnify-clip.png). EEng (talk) 13:33, 3 August 2013 (UTC)
A link to the file description page is not required if the license on the file does not require credit to the author, notification that the file is under the license, or other metadata of that sort to be included when the file is reused. Of the licenses commonly used here, only "public domain" and CC0 qualify (other licenses, such as WTFPL, do qualify but aren't commonly used). I note that your djvu example is an uncommon case; most of the time |link= is used on icons, without thumb. Also, is it not possible to fix the djvu? Anomie⚔ 14:12, 3 August 2013 (UTC)
In addition to correcting the crookedness I also wanted to present a version with most of the margins cropped out, so as to present the printing as large as possible -- but of course I didn't want to crop the original. Anyway, I couldn't figure out what sw to use with djvu. EEng (talk) 18:49, 3 August 2013 (UTC) P.S. I want to put a plug in here for a neat, underutilized feature I discovered during this discussion: WP:Picture_tutorial#Image_maps
The puzzle globe at the upper left of all pages is added by the Wikimedia Foundation to their own website. They own the image and don't have to give attribution to themselves. It's not in the wiki source so it's not copied by mirrors (at least not legally). However, I improperly displayed a small version of it in an earlier post without linking the file page File:Wikipedia-logo-v2.svg. I have changed the example to . This uses the public domain File:Flag of Poland.svg. PrimeHunter (talk) 14:14, 3 August 2013 (UTC)

Mysterious data override

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

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

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

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

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

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

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

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

Seven nations with population-data templates

Sorry for the confusion, but for years, we have been adding automatic population templates (some copied from German Wikipedia) to keep town-population lists which display each population count in any of thousands of towns, by #switch on town-code numbers in the various templates. Already, thousands of town/region articles of 7 nations use those templates: Germany, Austria, South Africa, Switzerland, Belgium, Turkey, and New Zealand (France not yet, only on dewiki, see: "Category:Template:Metadata Population"). Here's the deal, people at German WP update the population templates, each year, and then we copy each template's #switch data into enwiki, and within an hour, thousands of enwiki articles get the latest population counts+source, as input by editors in German WP. I estimate over 21,000 articles use those templates. That is how we accomplish so much with just 10-15 edits per nation each year. -Wikid77 19:08, 4 August 2013 (UTC)

Has SUL finalization started?

The process of finalizing Single User Login was to start this August. Nearly 2,5 days have passed and there doesn't seem to be any activity or news. --Синкретик (talk) 11:27, 3 August 2013 (UTC)

The link should be meta:Single User Login finalisation announcement. I don't know the current schedule. PrimeHunter (talk) 12:14, 3 August 2013 (UTC)
On 12 May the time was changed from 27 May 2013 to August 2013.[42] With no news since then it seems unlikely to happen anytime soon. [43] also shows nothing since 12 May, except unanswered questions about the time. PrimeHunter (talk) 12:25, 3 August 2013 (UTC)
See the mailing list announcement from 12 May where it says that it will take place in August, but not until after Wikimania. It seems that Wikimania will be held around next weekend. --Stefan2 (talk) 15:41, 3 August 2013 (UTC)
It looks like the SUL renaming is likely to be held up; see this mailing list comment. The tools aren't there yet, and VE is using a lot of developer time. Andrew Gray (talk) 17:39, 3 August 2013 (UTC)
I think https://login.wikimedia.org/, where all the logins and unifications go through, was specifically created for this. There has been some changes in the logins. Sometimes the user is automatically logged out when visiting another wiki. However, when the page is reloaded, the user will be logged in again. Plus, the preferences (language settings, etc.) are automatically set when visiting another project for the first time. --Glaisher [talk] 16:45, 4 August 2013 (UTC)
login.wikimedia.org was created because of Safari (and soon Firefox, it would be already except they've postponed making it the default) "breaking" how the old version of SUL was logging you into the other wikis; this article has some details on that. To work around that, we created login.wikimedia.org so that all the various wikis could have a central location to ask "am I logged in?".
While loginwiki might wind up being used for global profiles or the like in the future, it wasn't created for the final SUL unification, nor is the final SUL unification actually dependent on loginwiki. The unification is finally being pushed so that long-requested cross-wiki features (like watchlists and notifications) can have some chance of being done sanely. Nor does loginwiki have anything to do (yet) with preferences being automatically set, and when I tried it just now by going to abwiki (which I had never happened to visit before now) it didn't set my language to English. BJorsch (WMF) (talk) 00:19, 5 August 2013 (UTC)

Date template improvemt requested

Could someone with a high level of template expertise please take a look at Template talk:Start date#Time display? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:18, 3 August 2013 (UTC)

Another place to post, if no response here, is Wikipedia:Requested templates, though that page does seem to have some tumbleweeds going though it. Still, little harm done in trying, if necessary. -- John Broughton (♫♫) 17:06, 4 August 2013 (UTC)

Notice for RFC on VE

Two things on the sitenotice about the RFC on Visual Editor:

  1. I disabled the notice soon after reading it for the first time, a few days ago, but whenever I load any page (even Mediawiki:Sitenotice!), the notice displays for at least a second (sometimes more) before automatically disappearing. I can't remember this ever happening before, since notices normally don't appear at all once I've closed them; what's the difference here?
  2. Sometimes the [hide] link appears to the far right side, and sometimes it's centered above the notice. This was the case before I closed the notice; it's not just been over the past couple of days. Why wouldn't it always go in the same place?

I've been using Wikipedia from several different IP addresses since the notice first appeared, including one more than 400 miles (640 km) away from another, but it happens on all of them. Right now, I'm on the same address as I was when I made this edit, but things haven't changed in two days. Running IE8/Monobook/Windows 7. Nyttend (talk) 12:29, 4 August 2013 (UTC)

Same on IE8 on Windows XP. I would assume they would tell you to update your browser, as IE10 is the latest supported browser for Windows 7. I can't, however, and it is quite annoying. Jguy TalkDone 13:24, 4 August 2013 (UTC)
  • Support for IE changes daily, with CSS settings: Perhaps the IE browsers do not fully process all the *hundreds* of CSS classes which are downloaded now to display almost any WP page. The wp:Data hoarding of thousands and thousands of CSS classes might not inherent all the attribute values, or there might even be a transmission error in some dozen CSS classes, among all the thousands and thousands and thousands (plus thousands more) sent to your browser (it is freaking unbelievable when counting the CSS classes). Hence, the recent WP trash-the-interface actions include: the [hide] button shifts from right to center, the top page title disappears (often), the redlinks turn "blue" (neat feature), some bordered tables get double-thick lines, the wp:Tooltips pop-ups get stuck overlayed onscreen (IE8), the image-boxes lose the outer border, the town map locator-dots shift a few pixels out to sea, or the whole page loses the box style and scrolls down the page, and the page locks up. Thankfully, IE8 has been the world's most popular browser, or it would be difficult to show for years how Wikipedia looks like twisted crap in almost every building visited. -Wikid77 (talk) 18:38, 4 August 2013 (UTC)

I have been experiencing intermittent errors when trying to get a list of contributors of various pages on Wikipedia. It is now to a point where I am getting ready to throw the towel in and stop clicking the dreaded Contributors link (View history).

Here are a couple of different error messages I have been getting:

  • Database Error: Can't connect to MySQL server on 'sql-s1' (4) on sql-s1/enwiki_p
  • Database Error: User 'daniel_www' has exceeded the 'max_user_connections'

I hope someone here can explain why this continues happening - is this all tied to the mystical toolserver? Thanks in advance, XOttawahitech (talk) 16:41, 4 August 2013 (UTC)

Yes; the fact that the URL begins http://toolserver.org/ is a bit of a giveaway --Redrose64 (talk) 19:13, 4 August 2013 (UTC)

Interlanguage automoronism

Sorry, I dont use that kind of lingo that I'm using now very often, but really annoyed.

Not sure this is entirely tech, but if it isn't, it's darn close. Please move if so required.

To be brief, Broom_(shrub) lacks a de: link. That used to be piece of cake in the past.

Now see what really happens here, as of today.

For one thing, I know that a Broom_(shrub) is a "Besenginster" in de:. (I found out by its latin name). So the thing to do is to add [[de:Besenginster]] to the page source, and be done. Simple and straightforward. Well, that it used to be.

Interlanguage links are not accessible for edit in the source. Not any more.

Instead some table-ish stuff presents itself to not much avail as it won't let me do what (I figure) should be done. Taking away my editor's freedom to do good, to say the least. Add to that, what it does do is give me a hassle.

Instead of letting me do the proper edit, some automatism behind the scenes insists that the de: link was already taken - that must be, for the opposite direction as there is no de: link in Broom_(shrub). Or anything the like.

The link in question supposedly involves Cytisus_scoparius.

Now while it's true that there is some (real-life) connection between Cytisus_scoparius and Broom_(shrub), some automatism behind the scenes shouldn't be keeping editors from doing what they see fit, this being just an example, after all.

Steps-to-repro again, for the sake of accuracy:

  1. Read Broom_(shrub). Edit. Look for (old-style) language links. Nope. Back to Read mode.
  2. Click "Edit links" in the toolbar, at "Languages". "Wikipedia pages linked to this item" shows up.
  3. Click "add" right under that table to add the de: link.
    Which has become a lot more complicated in handling now. WTF. If that's mandatory to use that's pure, bloating, imposed, self-imposing, obnoxious overengineering.
  4. type "de" for site. Resolves to decoded text in a pulldown. At least that works smoothly.
  5. type TAB. Well, somebody did their homework, for that matter.
  6. type Besenginster. Resolves to the present article in de:. So far, so good - or so I thought.
  7. click "Save" (and I find this does not work by hitting SPACE. That's in violation of a UI design rule, or used to be.) Watch the blurb bubble that's been sitting there and was blue, turn red and complain: "An error occurred while trying to perform save and because of this, your changes could not be completed." Well done.
  8. click "Details" on the blurb. Details are: "Site link Besenginster already used by item Q145781." Could have been told earlier in the first place, if it has to.
  9. "Besenginster" and "Q145781" turn out to be links in the Details. "Besenginster" is fine (links to the de: article). "Q145781" evaluates (links) to wikidata:Cytisus scoparius. Painstakingly copying the caption and inserting it into a (de? en?) WP search field... is not required, but only by reading the whole page and finding "Wikipedia pages linked to this item" (heading). Fair enough, but barely, considering all the hassle that I've listed to this point. Well...
  10. Seemingly, "Cytisus scoparius" as a Wikidata item links to "Besenginster" in de: and to "Cytisus scoparius" in en:. And that seems to be an 1:1 relation for each language.
    As Cytisus_scoparius eclectically points out that this is the precise name for a family of brooms, and Broom_(shrub) is a common Broom in some parts of the world but a Scotch Broom otherwise, blah, blah... oh, very well.
    But it's still perfectly rational, as "Besenginster" (in de:) is a common name and Broom_(shrub) is a common name (and there's no Scotch_Broom article, for that matter, apart from the occasional redirect) - so it's perfectly rational to interlink Broom_(shrub) with [[de:Besenginster]] and leave the eclectic stuff for the reader to click on where it says "Cytisus scoparius" in either article's text.
    That's precisely what the automagicalism won't let me do, short of painstakingly restructuring it all (if I so dared). WTF.

Bottom line: I want interwiki language links back. As an option, if it has to be, but definitely. Period. Or anybody else has a better solution to come up with? That I'll appreciate. If you can tell me I just have to click this and that and be done, fine. But I still doubt it. Thanks in advance if you care.

In considering whether to reply, please keep in mind that it's not you I'm being angry at. I'll try to cool it. I'm just being really annoyed.

--217.81.139.17 (talk) 22:19, 4 August 2013 (UTC)

  • Interwiki links still work during this transition period: I inserted "[[de:Besenginster]]" at bottom of page, to reduce frustration. Please note because there are 4.2 million articles, in enwiki alone among 30 million, the interwiki links still work during this transition period, until more millions of articles can be cross-connected, and Wikidata achieves its goal: "Nothing less than total world domination". Meanwhile, you might think you have discovered the Foundation's true secret mission: to destroy the profession of software development so that many educated people no longer think "computer science" was ever a real science, with logic and tested theories of how to develop reliable software capable of guiding airplanes or spacecraft trajectories. However, in reality there is no secret cabal named "Destroying Users Morale and Sabotaging Software" (D.U.M.A.S.S.), but instead it is just the way they implement peculiar plans in the Foundation. A typical ageing bureaucracy is likely to have multiple bureau departments which fight each other over control of data storage, or have two different menu options to edit the same page, with a menu branch for each part of the bureaucracy. That is normal bureaucratic activity, so do not worry unless you start seeing two menu options on every section of pages, as then you would know the goals of the bureaucracy have superceded the functionality of the system. -Wikid77 (talk) 02:13, 5 August 2013 (UTC)

"automatically accepted"

It seems that the article history is once again being cluttered up with stuff that appears to me to be of little or no use. This time, its the mention that a given edit is "[automatically accepted]" is tagged onto each line for each article in mainspace. The link just leads back to the article. I'm unaware of any recent discussion on why this needs to make a comeback. I think it should be removed unless there is strong consensus for it. -- Ohc ¡digame!¿que pasa? 03:07, 5 August 2013 (UTC)

This is part of the Pending changes feature, which was re-enabled after a 2012 RfC. Graham87 06:12, 5 August 2013 (UTC)

Re-focus on power users, as VE usage plummets

This is a reminder how the power users, with the computer power tools, are still the future of WP, so create more tools. I know I should avoid talk of VisualEditor (VE) here, but I just wanted to reassure the technical users how the mainstream users have re-awakened and returned to using the wikitext editor: edits by new/old usernames are 96% wikitext (up from 91% last week), and IP edits are 80% by wikitext editor (up from 70%, 30% were VE) in a sample of 3,000 edits on 3 August 2013. The overall IP edits are still 27% of total (799 of 3,000) as during last month, so no major effects on IP editing (other than many people have been counting the IP edits versus the 73% username-based edits). Be assured: people who write encyclopedia articles tend to be quick-learners and not long distracted by fads, but focus on how to accomplish more. The power users, who make 92% of monthly edits, will likely appreciate the better gadgets or tools. To comment on VE, see: WP:VisualEditor/Default_State_RFC. -Wikid77 (talk) 21:19, 3 August 2013 (UTC)

Edits by user type dashboard. The August 2013 changes were intended to reduce VE usage by making VisualEditor's beta status clearer, both in the labeling and position of the edit links, and by giving a first-time informational message to new users. As I wrote in the Signpost, during the beta phase of VisualEditor, we need to ensure that we have reasonably representative usage of VisualEditor so it's not developed in isolation from real user concerns (both new and experienced users), but we're looking for a reasonable compromise which achieves that while minimally disrupting the experience of users who have no interest in the beta.--Eloquence* 22:45, 3 August 2013 (UTC)
You're constantly getting this wrong for many of us Erik, which is sad since it neither helps the community nor your efforts to improve VE: There are users (let's call them "power users") who are more efficient with the Wikitext editor. Since this is clear (already today) those users know the'll eventually continue to use the Wikitext editor and would want to disable the VE. This does not mean those users are not willing to help in development of VE during the beta phase! Actually it's the other way round!
If you'd say "VE is enabled by default during the beta phase for registered users, so we get as much useful input as possible, but we'll offer an option to disable it in the long term for those who do not want to use VE in day-to-day work" you would make many editors and also yourself much happier than we're now with the unsuccessful launch of VE. --Patrick87 (talk) 23:53, 3 August 2013 (UTC)
I agree, if the WMF actually relayed the attitude they wanted our help they would have it but when they repeatedly ignore our feedback and insist that hundreds of users across multiple wiki's are just being resistant to change, that doesn't instill an environment of mutual cooperation. I have been here a long time and I have never seen the community in as much of a consensus about anything as they currently are about how negatively the VE application is impacting things here. The problem here is that the WMF wants to push this broken and grossly unfinished app to the masses at all cost knowing its broken. Kumioko (talk) 00:42, 4 August 2013 (UTC)
This article from the Register pretty much sums things up. Kumioko (talk) 01:18, 4 August 2013 (UTC)
Wikid, I don't think your sample shows what you're claiming. If people are individually choosing to use VisualEditor less, then you should see a steady downward trend. The fact that it declined on the day after it was deliberately made less prominent does not prove that people are rejecting it. That instead proves that the UI changes (location, label, etc.) had the intended effect. If people are deliberately choosing to use it less, rather than being influenced by the UI, then you ought to see fewer edits on the days before these changes than you did in the first week of July. Whatamidoing (WMF) (talk) 20:24, 5 August 2013 (UTC)

Wikidata creep?

See: Wikidata:Project_chat#Many-to-one pygmy elephant. -Wikid77 15:18, 5 August 2013 (UTC)

Before interwiki language links passed over to Wikidata I had no difficulty in editing them. But now I've given up trying. For example, the en.wp equivalent of it:clacson should be Vehicle horn, not Horn (acoustic), but I have been unable to make the change. When I tried some time ago I got an error message telling me that Vehicle horn was already spoken for (and now I seem to get a message telling me that Vehicle horn was not found...).

Help:Interlanguage links sends me to Wikipedia:Wikidata, which is... erm... tl;dr (I'm tempted to say gobbledegook).

My understanding is that any given WP page can now only link to only one counterpart in any other given language. As anyone with even a basic knowledge of translation (or semantics) will know, this is a naive restriction.

To take a topical [44] example from it.WP: it:Grazia (diritto), a page with no interwiki language link... This Italian legal term is commonly translated into English as "pardon". However, en:Pardon is already taken by it:Indulto—a different [45] concept (the lead of it:Grazia (diritto) distinguishes the Italian legal concepts of grazia and indulto).

While acknowledging that it may be early days, I'm concerned that this is technical WP:CREEP, where the interests of Wikidata are effectively trumping the interests of Wikipedia's global readership. 86.140.51.65 (talk) 22:19, 3 August 2013 (UTC)

Were we discussing this matter at Oxford Meetup three weeks ago? If so, I'll see you tomorrow! --Redrose64 (talk) 22:36, 3 August 2013 (UTC)
  • Wikidata stores the links at each item's page. Editing links is very easy from the graphical user interface, but yes, only one link per language per site per item is permitted.--Jasper Deng (talk) 22:40, 3 August 2013 (UTC)
The restriction of one link per language seems to me to be at odds with the global character of the Wikipedia project. Fwiw, I feel that this is an issue that deserves discussion online. (The graphical user interface doesn't seem [46] to help redirect it:Clacson to en:Vehicle horn.) 86.140.51.65 (talk) 22:52, 3 August 2013 (UTC)
In this particular case, it would have to be moved to the vehicle horn item. Yes, this requirement is debatable and something you can bring up at d:Wikidata:Project chat.--Jasper Deng (talk) 00:17, 4 August 2013 (UTC)
Thank you for your replies, Jasper Deng. I'm not sure I feel altogether prepared to enter the Wikidata habitat. Remaining on en:WP for the moment, WP:Wikidata#Interlanguage links (Phase 1) seems to me cryptic (WP:CREEP) and worrying... For instance, the largely unexplained star network illustration of "Links to all languages from one central point" rings alarm bells of WP:SYSTEMIC: viz. not only creating a conceptual straightjacket of the interlinks, but an "en-centric" one to boot. I hope I am wrong! 86.140.51.65 (talk) 08:01, 4 August 2013 (UTC)
  • Some pages need to interwiki link to a crosslink page: They are many rare cases where an interwiki needs a one-to-many link, and I suggested for years to use wp:crosslink pages (Template:Crosslink), which each would link to multiple other pages based on similar topics being cross-linked, rather than similar page titles. The issue is a one-to-many link by similar semantic content, rather than similar syntax in spelling the page titles. An example was the page "River" which might be better linked to a crosslink page of several related terms in German language, such as de:Bach, de:Fluss, de:Strom, etc. This is a general issue in information science, and I welcome others to expand this concept. -Wikid77 (talk) 19:36, 4 August 2013 (UTC)
  • Put in-page interwiki and discussion at WD:Wikidata:Project_chat: I just fixed the page by using the old in-page interwiki links, which have more capability, then opened a thread at Wikidata:
The need for many-to-one page links has been an issue for years, and hopefully the discussion will lead to an early fix. -Wikid77 (talk) 15:18, 5 August 2013 (UTC)
Thank you, Wikid77. 86.140.51.65 (talk) 21:50, 5 August 2013 (UTC)

Naughty ref template?

On the Maltase article I changed {reflist} to {reflist|2} it now superimposes some of the reference text over an image. It could be fixed by revering my edit but it is a glitch that should be sorted out. Cheers. -- Alan Liefting (talk - contribs) 04:13, 4 August 2013 (UTC)

It looks OK to me, under Firefox 22. Which browser are you using? --Redrose64 (talk) 08:47, 4 August 2013 (UTC)
FF22. Might be related to screen resolution. Am running 1280x800. -- Alan Liefting (talk - contribs) 09:14, 4 August 2013 (UTC)
Mine's 1280x1024 but the height shouldn't affect it; the skin might, so I've tried both Monobook and Vector skins, but it looks fine in both. --Redrose64 (talk) 09:24, 4 August 2013 (UTC)
Hmmm. The plot thickens. Am running Monobook. -- Alan Liefting (talk - contribs) 09:47, 4 August 2013 (UTC)
OK, just so we've covered every aspect, try a WP:BYPASS just in case your browser has something cached that mine hasn't. --Redrose64 (talk) 09:51, 4 August 2013 (UTC)
Still no change! -- Alan Liefting (talk - contribs) 05:08, 5 August 2013 (UTC)
It's working for me in Safari 6 on Mac OS 10.7.5. Can someone else give it a try? It would be helpful if we could find someone else with this problem. Whatamidoing (WMF) (talk) 20:27, 5 August 2013 (UTC)

Erroneous message on Watchlist

At the top of my Watchlist is a message that states, "Pages that have been changed since you last visited them are shown in bold." This is just wrong. Pages that have changed are shown with a green bullet point. The message needs to be fixed to match reality (I'm sure it used to mention the green bullets...) Thanks, Bazonka (talk) 08:44, 4 August 2013 (UTC)

The message hasn't changed in about eight weeks... what is your language setting? --Redrose64 (talk) 09:03, 4 August 2013 (UTC)
It was set to British English. Changing it to just English fixes the problem. I'm aware that the BrE setting isn't always right, and so I'm sure I'd already changed to English a couple of years ago, but maybe not. In any case, the BrE message does need to be fixed because I can't be the only person using it. Bazonka (talk) 09:29, 4 August 2013 (UTC)
I've copied MediaWiki:Wlheader-showupdated to MediaWiki:Wlheader-showupdated/en-gb verbatim. --Redrose64 (talk) 09:46, 4 August 2013 (UTC)
Users with British or Canadian English often miss important customizations of interface messages, for example links to English Wikipedia help and policy pages. I have restored [47] a warning at Help:Preferences but I suggest we also warn the users more directly. Users with en-gb or en-ca see MediaWiki:Preferences-summary/en-gb or MediaWiki:Preferences-summary/en-ca (both are currently blank) at top of Special:Preferences. Users with the default en see MediaWiki:Preferences-summary. I suggest we set MediaWiki:Preferences-summary/en-gb to something like: "For information about the settings on this page, see Help:Preferences. Your language setting British English is not recommended." Similarly for en-ca. PrimeHunter (talk) 20:28, 4 August 2013 (UTC)
British is the third most selected language, after Spanish. Then French, Brazilian Portuguese, Russian, Indonesian, German, Arabic, Chinese, Dutch. Only 277 users have Canadian selected. See Wikipedia:Database_reports/User_preferences. --  Gadget850 talk 20:43, 4 August 2013 (UTC)
Thanks for the stats. Is there ever any good reason to choose British English, for example American words a British user may misunderstand? Does anybody know stats on how many MediaWiki defaults are different for en and en-gb, and what those differences are? PrimeHunter (talk) 21:06, 4 August 2013 (UTC)
Only way I know is to go to Special:AllMessages, select the desired language, and Go. Custom messages are highlighted in light blue. --  Gadget850 talk 21:11, 4 August 2013 (UTC)
Here are some I made earlier: en; en-gb; en-ca. --Redrose64 (talk) 21:43, 4 August 2013 (UTC)
Thanks. I was thinking particularly of the default messages in the MediaWiki software and not customizations at the English Wikipedia. It appears from mw:Localisation statistics that only 51 of 2979 messages have an en-gb variant. I found https://doc.wikimedia.org/mediawiki-core/master/php/html/MessagesEn_8php_source.html and https://doc.wikimedia.org/mediawiki-core/master/php/html/MessagesEn__gb_8php_source.html. The latter appears to show all en-gb variants. Here is a possibly complete summary of differences between en and en-gb: uncategorized/uncategorised, "Add pages and files I [something] to my watchlist"/"Add pages I [something] to my watchlist" (don't know why files are omitted in en-gb but en/en-gb confirms the difference), "$1"/‘$1’ (different quote characters in many messages), color/colour, canceled/cancelled, vandalized/vandalised, Kilometers/Kilometres, meters/metres, digitize/digitise, program/programme, License/License. So for a few British spellings and different quotation marks, users with en-gb lose hundreds of customized messages at the English Wikipedia. That seems like a bad deal unless you are fanatical about British spelling, but then you would still have to live with lots of American spellings in articles. PrimeHunter (talk) 23:18, 4 August 2013 (UTC)
Personally I've found that feelings can run very strong on the License/License issue. EEng (talk) 01:57, 5 August 2013 (UTC)
I accidentally wrote "License" both times and you copied that. The Licence/License issue probably causes more feelings ;-) PrimeHunter (talk) 13:16, 5 August 2013 (UTC)
Oh, you accidentally wrote "License" twice, did you? I hadn't understood that. I naturally thought you were referring to the License/License issue, about which we periodically see such violent agreement. EEng (talk) 19:40, 5 August 2013 (UTC)
20 of those custom messages are for cite errors. I tried redirects, which don't work at all, and transclusion, which does not work on all pages. --  Gadget850 talk 00:02, 5 August 2013 (UTC)

Side discussion

As a side issue, as my updated watchlist entries are neither bold nor green what's the css to hide the line altogether? NtheP (talk) 09:19, 5 August 2013 (UTC)

It doesn't have a class so I don't know whether CSS can hide it but this JavaScript in Special:MyPage/common.js uses its span id:
document.getElementById("mw-wlheader-showupdated").style.visibility = "hidden";
PrimeHunter (talk) 10:05, 5 August 2013 (UTC)
Of course you can do that using CSS, it would be 
#mw-wlheader-showupdated { display: none; }
—TheDJ (talk • contribs) 12:29, 5 August 2013 (UTC)
Thanks, both. Had got most of it just hadn't sussed the # NtheP (talk) 18:24, 5 August 2013 (UTC)

Strange behaviour of Parser Functions

Tracked in Phabricator
Task T14974

Hi there,

cannot find out the reason of strange behaviour.

I suppose that the construction: 

[http://dlib.rsl.ru/viewer/01002921717{{#if:5|#?page={{#expr:5+2}}|}} test]

should give me: test.

Instead, I got: [http://dlib.rsl.ru/viewer/01002921717

  1. ?page=7 test].

Cannot find out why it adds a new line and thinks that the sharp sign starts it and how to workaround it... I need working URL-links with sharps!

Hinote (talk) 00:04, 5 August 2013 (UTC)

The parser interprets the sharp character as a list point of an numbered list at this point. Can you rewrite the code to not contain it inside the parser function? E.g. 
[http://dlib.rsl.ru/viewer/01002921717#?page={{#if:5|{{#expr:5+2}}|}} test].
--Patrick87 (talk) 00:33, 5 August 2013 (UTC)
(edit conflict) It's T14974. Long ago, people complained that templates containing wikimarkup that's supposed to come at the start of the line (such as * or #) were rendering wrong when the template wasn't itself placed at the beginning of the line (that was T2529). Despite there being a workaround ("put a newline before the template!"), this was fixed by automatically injecting a newline before any transclusion of text beginning with those characters, which caused T14974, which unfortunately has no workaround in many cases. Anomie⚔ 00:40, 5 August 2013 (UTC)
Thanks guys for quick response!!!... Dammit!... So strange bugfixes and so strange behaviour in the parser code... Of course, I will rewrite the template and the link it contains, so that I have #if outside of the link, but it will require repeating the whole part of the URL which stands before the sharp... Hmmm... Hinote (talk) 00:49, 5 August 2013 (UTC)
I don't know exactly in which situations this workaround works but in your example you can encode the number sign as &#35;: test PrimeHunter (talk) 00:54, 5 August 2013 (UTC)
Should also work. Could not quickly find this html substitution code for the sharp sign... Thanks! Hinote (talk) 01:08, 5 August 2013 (UTC)
Quickly see wp:CODES for HTML entity character codes (with accented letters), where I have repeated &#35;= # (hashmark). -Wikid77 12:17, 5 August 2013 (UTC)


Weird redirect behavior

File:Code of Honor.jpg displays like a redirect to File:ROH Code of Honor.jpg, but actually it is a redirect to (the deleted) File:ST-TNG Code of Honor.jpg, as can be seen by editing the source. Apparently the explanation is that the behavior is trumped by Commons:File:Code of Honor.jpg which redirects to Commons:File:ROH Code of Honor.jpg. This behavior is a problem because the local redirect is tagged for speedy deletion as a redirect to a deleted page, but the page is almost inaccessible. (Try accessing it with this ordinary link: File:Code of Honor.jpg.)

Perhaps the local redirect should just be deleted. (I bring it here because it is difficult to access it from Category:Candidates for speedy deletion.) Or maybe the difficulty should be explored first. —teb728 t c 07:36, 5 August 2013 (UTC)

Deleted the redirect. — Edokter (talk) — 08:18, 5 August 2013 (UTC)

{{CatAZ}}

I made it myself very difficult creating [[Category:Vessels by ENI number]] in Commons by using Category:ENI XXXXXXXX for each individual vessel. Mentioned template deviates by number. Is it possible to modify the template so that it does not use the term ENI and goes to a combination of numbers, like [[Category:Ships by name]] in Commons? --Stunteltje (talk) 08:17, 5 August 2013 (UTC)

The unlinked items in your post are commons:Template:CatAZ, commons:Category:Vessels by ENI number, commons:Category:Ships by name. Are you looking for something like this:
Preview the code at commons:Category:Vessels by ENI number to see how it works. 00 to 10 looks appropriate with the current category members but I don't know whether 11 to 99 will get far more members later. PrimeHunter (talk) 10:48, 5 August 2013 (UTC)

Sandbox ???

Hi, I was referred to you by Hillbillyholiday81 for helping with my sandbox. I'm having trouble formatting my categories correctly and trying to add this reference but keep getting errors. Here's my sandbox: http://wiki.riteme.site/wiki/User:GulfamUlRehman/sandbox Here's my new reference: http://heartbreakerrecords.com/artists/wem/index.html Really, thanks for your help! GulfamUlRehman (talk) 15:46, 5 August 2013 (UTC)

I don't see an attempt to add that reference in the page history [48] so I cannot say what the problem is. If you save an edit then we can see what is wrong. The categorization of the page was deliberately inactivated by others (with two different methods [49][50]) because those categories are only for real articles. Your user sandbox shouldn't show up in Category:Hip hop and the other categories for readers of the encyclopedia. Category:Entertainment occupations and Category:Hip hop would also have been far too general for an article like that. It might have belonged in Category:East Coast hip hop musicians. PrimeHunter (talk) 18:31, 5 August 2013 (UTC)

redirect cat listed as subcat but shouldn't

I created a redirect from a category to another category, with {{R from alternative name}}. The redirecting category is showing and counting as an empty subcategory of the destination category. This is useless. It should only redirect. While it being listed makes it appear available, clicking the subcategory name recursively brings the visitor back to the parent category. How do I keep the redirect but stop the redirecting category from appearing as a subcategory? Nick Levinson (talk) 16:04, 5 August 2013 (UTC)

I think I fixed it. Chris857 (talk) 16:09, 5 August 2013 (UTC)
So you did, and, even though I was amidst correcting my post above the same way when you did that, I probably wouldn't have thought of adding the colon to the redirect. Thank you. Nick Levinson (talk) 16:21, 5 August 2013 (UTC)

"Mark all pages visited" button is disappearing

I have the feature where my watchlist marks for me any pages I have not visited that have edits. There's a button marked "Mark all pages visited" to remove the notations beside any unvisited pages. The button is appearing really briefly, and then is vanishing. This problem started when I logged on this morning. I am using a Toshiba laptop and running Vector skin on a Chrome browser. Any comments or advice would be welcome. Thanks, -- Diannaa (talk) 17:53, 5 August 2013 (UTC)

I have it in Vector on Chrome. Did it happen before or after [51]? Do you see the button in MonoBook at [52]? PrimeHunter (talk) 18:16, 5 August 2013 (UTC)
@Diannaa: Lemme guess, you are using Enhanced Recent Changes and you have made changes (enabled bolding gadget ?) to make the feature appear (Because the feature is disabled on en.wp when users use Enhanced Recent changes by default). For consistencies sake, this morning I also hid the button in Enhanced recent changes mode. That means I probably need to fix the "bolding" gadget to as well. —TheDJ (talk • contribs) 18:40, 5 August 2013 (UTC)
Ah, you use custom CSS I see. Well I now changed the method to use CSS, so I think it should work for you now... —TheDJ (talk • contribs) 18:51, 5 August 2013 (UTC)
@TheDJ: Sorry for the delay in replying; I had to go into town for a while. Everything seems to be functioning normally again. Thank you for your help :) -- Diannaa (talk) 21:13, 5 August 2013 (UTC)

Something Visual Editor didn't do...

Does anyone know why this page is properly formatted, yet the links don't work? There is no hidden code in there, so any help would be great. Thanks! Kevin Rutherford (talk) 17:59, 5 August 2013 (UTC)

Need some template guru help

Can someone remove the deletion notice from Template:Infobox_rail for me? I looked at the deletion discussion and it was clearly a fail, but it seems no one closed it and the template still has the delete header on it. I would do this myself, but there was scary red text, so I back paged. Thanks! Maury Markowitz (talk) 18:28, 5 August 2013 (UTC)

You could simply undo the most recent edit, which added the TfD notice. -- John of Reading (talk) 18:34, 5 August 2013 (UTC)
Ohhh, duh… Maury Markowitz (talk) 18:36, 5 August 2013 (UTC)
TfD's are normally open for at least 7 days and sometimes a little longer depending when somebody comes by to close them. Just wait. Most of the other discussions at Wikipedia:Templates for discussion/Log/2013 July 27 haven't been closed either. PrimeHunter (talk) 18:39, 5 August 2013 (UTC)

How can an user without a Wikipedia account get the benefits of Mathjax rendering?

Having switched to Mathjax several months ago, I am now shocked at how awful the default math rendering is. So

  1. How about making Mathjax the default renderer?
  2. Alternatively how about providing some way for users who are not logged in to use Mathjax?

cffk (talk) 00:25, 6 August 2013 (UTC)

See bugzilla:36496, bugzilla:48036 and mailarchive:wikitech-l/2013-July/070454.html. Helder 02:18, 6 August 2013 (UTC)

User namespace shortcut

We have the "WP:" namespace set up so that WP:NPA redirects to Wikipedia:NPA. Is there any reason we don't do the same for "U:" to "User:"? — Preceding unsigned comment added by Pigsonthewing (talk • contribs)

It was suggested a few years ago but not much discussion happened. Killiondude (talk) 22:33, 6 August 2013 (UTC)
See also User talk:Wavelength/Archive 4#U: (June 2012) and Wikipedia:Village pump (miscellaneous)/Archive 38#U: (June 2012).
—Wavelength (talk) 02:33, 7 August 2013 (UTC)
Things like "User:" and "Talk:" are already rather short, so there's not much of a case on that front but "UT:" for user talk, and "Cat:" for the category namespace would all be pretty useful. "T:" for the template namespace would also be justified, except that most other users (I'm a bit of a templates gnome) would have little cause to ever use it. "CT:" for category talk is probably an edge case, although supporting "Cat talk:" would probably help a lot. VanIsaacWS Vexcontribs 03:05, 7 August 2013 (UTC)
Also see Wikipedia:Perennial_proposals#Create_shortcut_namespace_aliases_for_various_namespaces. πr2 (t • c) 03:05, 7 August 2013 (UTC)

Template:Country geography

I'm trying to understand a template. It looks to me as if it should output something, so I'm wondering why it doesn't. In this article, the {{Country geography}} infobox includes parameter "km coastline = landlocked" (where "landlocked" would sometimes be a number like 123 to mean 123 km). It looks to me as if the infobox should generate (omitting the html table stuff):

Coastline {{convert|landlocked|km|mi|abbr=on}}

If {{convert}} gets "landlocked" as its first parameter, it correctly complains loudly. I've tried the infobox wikitext in a sandbox, and "Coastline" never appears, even if "landlocked" is replaced with 123. Why not?

If anyone is curious, I'm investigating a similar template in a similar article which does output the erroneous "landlocked" text, with bad results. The article is bn:ম্যাসেডোনিয়ার ভূগোল, and the error message reads (according to Google Translate): 'Conversion error: Value "land-locked" must be a number'. Johnuniq (talk) 04:00, 7 August 2013 (UTC)

It didn't even work with valid inputs before! I have fixed it, but there may be other errors in the template. And, since you're interested, it was fixed on bnwiki already. ;) πr2 (t • c) 04:14, 7 August 2013 (UTC)
Does anyone else think that this template should maybe be implemented through the infobox framework? It seems like it's reinventing the wheel.VanIsaacWS Vexcontribs 04:40, 7 August 2013 (UTC)
@πr²: Amazing, thanks. Hilariously, I noticed that strange syntax but because of some magic I was recently shown above, I imagined it was more of the same. You edited the article to replace "landlocked" with "0", but I believe the parameter should be blank (or probably just omit the "km coastline" setting as it's unlikely to be needed). With "0", the article shows "Coastline 0 km (0 mi)" (after purging). Johnuniq (talk) 06:03, 7 August 2013 (UTC)

want a notice on a redirect page

A category has an unusual purpose that is not obvious unless explained, the category is already populated, and it simultaneously serves as a redirect to another category. All of this is within its purpose. It is a hard redirect; a soft redirect using the {{Category redirect}} template would add a notice for emptiness that is not appropriate to this particular redirect. A notice has been added to explain the purpose to visitors who click the link to the redirect, but it's not appearing even there. It should not appear at the redirect destination (and it doesn't) but if someone clicks the link to the redirect then they should see it. Right now, only a diff provides the notice, and it's unlikely that most admins or other editors would ever open and read the diff. Is there a way to make the notice visible to editors who read the redirect page? If not, should something be reprogrammed? Or do we need to add a parameter to the {{Category redirect}} template to make disappear its pro-emptiness notice, a parameter probably only for one-time use, and then add or keep the desired notice of the unusual purpose appear not just in the diff but on the redirect page? Nick Levinson (talk) 17:24, 5 August 2013 (UTC)

You cannot make text appear on a redirect page, and apart from "(Redirected from ...)" the target page cannot display different text depending whether you got there via a redirect. If you don't want users having to edit the redirect page or examine the page history to find its purpose then the only option I see is giving it a special name like Category:This is a test of category redirects. PrimeHunter (talk) 18:48, 5 August 2013 (UTC)
Please don't use hard redirects for categories, more at WP:R#CATEGORY. --Redrose64 (talk) 22:26, 5 August 2013 (UTC)
Did you read the diff explaining the purpose? I think Wikipedia can live with one hard category redirect for testing. I already learned something from it: Category redirects are shown in italics.[53] PrimeHunter (talk) 23:17, 5 August 2013 (UTC)
In fact, Category:X2 is the only category in Wikipedia that is a hard redirect without a {{category redirect}} soft redirect template, and it is that way solely for testing. I know it is the only one because my bot fixes any others that it finds. This category is the canary in the coal mine so that we are aware if something changes in the underlying software, such as the italics for redirected categories (which is a fairly recent development). --R'n'B (call me Russ) 09:33, 6 August 2013 (UTC)
Text can be added to a soft-redirect page if it's done via a template, at least {{R from alternative name}}. Compare a page with unformatted text (scroll down) with its revision from deletion of the R template. Would there be a problem with using {{Cmbox}} to do nothing but add custom text? Nick Levinson (talk) 15:42, 7 August 2013 (UTC)

WikiMiniAtlas

Some time ago I added {{coord}} to Martin Gusinde Anthropological Museum but the wikilink is still not shown in the WikiMiniAtlas. What must I do to show the article link on the map?. --Best regards, Keysanger (what?) 11:04, 6 August 2013 (UTC)

The coordinates are parsed into a separate database so that they can be used for WikiMiniAtlas. I'm not sure how often this database gets updated. I think it used to be once every 3 to 6 months, but that was years ago. You should ask the maintainer of the tool. That would be Dschwen. —TheDJ (talk • contribs) 09:03, 7 August 2013 (UTC)
Thanks, DJ. --Best regards, Keysanger (what?) 19:05, 7 August 2013 (UTC)
Hi all, updates are currently triggered manually by me. Last update was about a month ago. Due to low toolserver performance it cannot be much more often as the update is quite time consuming. I'll trigger an update now. --Dschwen 02:22, 8 August 2013 (UTC)

"could not load twinkleoptions.js"

Hello all. I'm not sure if this is the right place to ask for help about this but I have been getting the message "could not load twinkleoptions.js" every time any WP page loads. It's getting a little annoying and I haven't been able to figure out why on my own. Does anybody know anything about this or what to do about it? I first noticed it after I disabled Visual Editor in my preferences yesterday, maybe it's a coincidence but it might help to figure it out. Thanks in advance for any help/suggestions.--William Thweatt TalkContribs 07:14, 7 August 2013 (UTC)

Problem with wysiwyg redactor

Problem with wysiwyg redactor ( http://ckeditor.com/download или http://www.mediawiki.org/wiki/Extension:WYSIWYG ). Everything is working perfect! But recently i have found a bug when using tags, for example i place a tag on the page <categorytree mode=pages>123</categorytree> after saving i open the redactor and instead of line <categorytree mode=pages>123</categorytree> i see <parsererror style="display: block; white-space: pre; border: 2px solid #c77; padding: 0 1em 0 1em; margin: 1em; background-color: #fdd; color: black"> === This page contains the following errors: === <div style="font-family:monospace;font-size:12px">error on line 1 at column 67: attributes construct error </div> === Below is a rendering of the page up to the first error. === </parsererror>

What should i do so the redactor does not do such replace. Thank you. — Preceding unsigned comment added by 93.72.183.188 (talk • contribs) 15:59, 7 August 2013‎ (UTC)

no warrantee and no guarantee - you may want to try and add the "categorytree tag manually to the list of "kosher" tags. as far as i could see, you prolly want to edit a line that looks like so
wgImgWikitags = ['source', 'ref', 'nowiki', 'html',
                        'includeonly', 'gallery', 'noinclude', 'onlyinclude'
                    ],
in a file named "special.js" (in some subdirectory under the extension tree), and add to the list of "kosher" tags also 'categorytree' (dont forget the comma, and i don't think "html" really belongs there...). peace - קיפודנחש (aka kipod) (talk) 20:53, 7 August 2013 (UTC)

Filter 30 malfunctioning

Tracked in Phabricator
Task T54077
Resolved

Hi, edit filter 30 currently seems to be malfunctioning, as there are a lot of edits that are not blanking being tagged/warned on the abuse log. Could someone disable and/or take a look at the filter? Thanks. Insulam Simia (talk) 18:29, 7 August 2013 (UTC)

T54077, already fixed; the fix will be deployed after Wikimania. Matma Rex talk 18:56, 7 August 2013 (UTC)
Okay, thank you for the info. Insulam Simia (talk) 19:27, 7 August 2013 (UTC)

Hello!

Sorry if this is the wrong page to ask on, but I'm a new user to Wikipedia and I was wondering if someone would care to direct me to the right tutorial links and/or help me get used to editing and the such. Thank you! — Preceding unsigned comment added by Bob the Billder (talk • contribs) 23:11, 7 August 2013 (UTC)

Answered at User talk:Bob the Billder. VanIsaacWS Vexcontribs 23:28, 7 August 2013 (UTC)

New section tab

Dear tech people: Today when I tried to add a new section to the forum at Wikipedia talk:WikiProject Articles for creation, the new section tab was missing. I therefore clicked on the edit source button of the last existing section, intending to add a header manually, and then a new section heading came up. Is this a bug? I notice that the new section tab seems to be working fine on this page. —Anne Delong (talk) 11:40, 7 August 2013 (UTC)

Confirmed. That is somewhat strange. πr2 (t • c) 12:00, 7 August 2013 (UTC)
Fixed by commenting out __NONEWSECTIONLINK__.[54] PrimeHunter (talk) 12:09, 7 August 2013 (UTC)
Thanks. I just love creating new sections... —Anne Delong (talk) 17:48, 8 August 2013 (UTC)

A couple of questions

I keep getting the message "Only secure content is displayed" when I visit a page in Wikipedia. Is there any security risk if I accept to show all the content? Second; when visiting articles about authors, the infobox often mentioned who influenced the writers, and who they in turned influenced. For some reason, this information now seems to be invisible in all these articles. Is there a reason for this? 2A02:FE0:C900:1:ADC4:D2C2:F604:A44D (talk) 02:39, 8 August 2013 (UTC)

Template:Infobox writer#Parameters says about influences and influenced: "No longer supported. Please move cited/citable instances into prose." It was decided recently at Template talk:Infobox writer#"Influences" and "Influenced", influenced by Template talk:Infobox person#RfC: Should the "influences" & "influenced" parameters be removed? PrimeHunter (talk) 03:11, 8 August 2013 (UTC)
To q1: which browser are you using? When you first enter Wikipedia, do you do so by clicking a link from another website; from a bookmark in your browser; or by entering a URL into the address bar of your browser?
To q2: it was me. --Redrose64 (talk) 09:35, 8 August 2013 (UTC)

New page feed repetition

Tracked in Phabricator
Task T49645

This was posted on Wikipedia talk:Page Curation#Repetition but I'm cross-posting it here for visibilty.

The new page feed seems to be loading the same set of entries when scrolling down. The first 19/20 entries load up like normal. When the scrolling triggers the next batch to load it is the same set which is appended to the end. I can keep scrolling for ages and end up with the same group repeated over and over again. Refeshing the page totally seems to clear it and give fresh new pages but the same issue exists when trying to scroll deeper into the new page list. For reference, I'm on a Windows 7 computer using IE9 (not by choice). Cabe6403(Talk•Sign) 09:26, 8 August 2013 (UTC)

Fixing XLinkBot

Hi everybody, I think somebody should fix XLinkBot because, as can be seen from its discussion page, sometimes it makes mistakes.

--Vitalij zad (talk) 19:59, 8 August 2013 (UTC)

Usually youtube is not a reliable source/good external link for Wikipedia articles. So the bot reverts additions of youtube. In this case, youtube is really no worse than the existing Google videos link, however. πr2 (t • c) 20:14, 8 August 2013 (UTC)

Text in article but not in edit window

How can we remove the line of text (about iTunes) from the top of this version of "8888 Uprising"?
—Wavelength (talk) 20:51, 8 August 2013 (UTC)

The bot already reverted it... πr2 (t • c) 20:58, 8 August 2013 (UTC)
Thank you. Now I see that it has been removed, but those same links (including the permanent link) both showed it still present a few minutes ago. Maybe my computer was not refreshing its version of the article.
—Wavelength (talk) 21:03, 8 August 2013 (UTC)
Actually, I was seeing the link too. Strange because the bot already reverted it. So I purged the page. That seemed to fix it. You can do that by adding ?action=purge to the end of the URL (& instead of ? if there's already a ? in the URL). πr2 (t • c) 21:18, 8 August 2013 (UTC)
Thank you for that advice.
—Wavelength (talk) 21:31, 8 August 2013 (UTC)

DEFAULTSORT and something else

Hi! I was wondering if there is some tool, which could help fing articles in some category, that don't have DEFAULTSORT? That was the first thing. The other is connected with templates. How to enable two ways of writing the parameter for images (to be ok, if it is written in form "File:Filename.jpg" and "Filename.jpg"), can't figure it out (for example this doesn't work: [[{{ucfirst:{{{image}}}|File:{{{image}}}}}|{{#if:{{{image_size|}}}|{{{image_size}}}px|200px}}|]]). Thanks! --91.200.65.244 (talk) 14:33, 6 August 2013 (UTC)

  • Question number one, I'm not exactly sure what you are asking. Question number two, the only way to do that logically is with string functions. These string functions only exist on the English Wikipedia in the form of the Module:String Lua module. It would make your template unduly heavy and I advise against it. Simply include instructions/documentation telling the user to just use the filename.img and leave the namespace off. [[File:{{{image|Example.png}}}|{{#ifeq:{{{image_size|}}}||200|{{{image_size}}}}}px]] should likely be your code... Technical 13 (talk) 14:50, 6 August 2013 (UTC)
1) for example there is category "American actors" and i want to know in which articles there isn't the defaultsort (to see each page would take a lot of time). 2) PrimeHunter, yes module is good, but it is actually not for en wiki. --91.200.65.244 (talk) 15:06, 6 August 2013 (UTC)
Then which wiki? We need to know which features it has. This page is mainly for the English Wikipedia. PrimeHunter (talk) 15:26, 6 August 2013 (UTC)
Does it happen to be the Latvian Wikipedia? (just guessing) πr2 (t • c) 04:20, 7 August 2013 (UTC)
  • Auto-insert "File:" by checking padleft of image-name: The other issue, about allowing people to omit "File:" can be solved by checking {padleft:|n|} of the image-name, against prefix "File:" or "Image:" as:
[[{{#ifeq:{{padleft:|5|{{ucfirst:{{{image}}} }}|File:
| {{{image}}}
| {{#ifeq:{{padleft:|6|{{ucfirst:{{{image}}} }}|Image:
| {{{image}}}
| File:{{{image}}}
}}<!--endif prefix "Image:"-->
}}<!--endif-->|{{#if:{{{image_size|}}}|{{{image_size}}}px|200px}}|]]
To check the middle of a name, then use Template:Substring to extract central text, or Template:Str_find to scan within the name. -Wikid77 (talk) 04:32, 7 August 2013 (UTC)
All characters of namespaces are case insensitive, you can have spaces between namespace and ":", and in foreign language wikis you can choose between English and local names of namespaces. {{NAMESPACENUMBER:}} from 2012 can be used to not worry about all that: {{#ifeq:{{NAMESPACENUMBER:{{{image}}}}}|6||File:}}{{{image}}}. PrimeHunter (talk) 10:39, 7 August 2013 (UTC)
Thanks. I re-confirmed {{NAMESPACENUMBER:x}} will work at Latvian Wikipedia (":lv"). -Wikid77 04:58, 8 August 2013 (UTC)
It could be argued what is the best way to treat "file names" starting with a namespace. They are technically allowed to do that so File:Media:example.png could have been a file (I don't recommend naming your file that), while the code [[Media:example.png]] wouldn't display File:example.png but instead make a direct link to the actual file: Media:example.png. The original question included px so it's presumably for a situation where you want to display a file. PrimeHunter (talk) 13:07, 7 August 2013 (UTC)
Thanks. I had forgotten about "Media:" prefix. -Wikid77 04:58, 8 August 2013 (UTC)

In regards to question 1. It would be possible to make a toolserver/wikimedia labs tool to do that, but I'm not aware of any currently existing. You can kind of sort of get similar info using the api: [55]. However, if you're using defaultsort rather constantly, perhaps there is a better solution. If its simply because the default mediawiki sorting order sorts č, ģ, ķ, etc in the wrong order (I'm assuming Latvian is the language here), you can request at bugzilla that the default order be changed to [56] for your wiki. Bawolff (talk) 19:48, 9 August 2013 (UTC)

a good idea or a template misuse ?

I edit especially the sport competition articles. I would like to edit {{flaglink}}. My idea is: if the flaglink-template is used without country parameter, then display TO BE DECIDED
Please join us and post your opinion to Template talk:Flaglink/core.
Maiō T. (talk) 11:14, 9 August 2013 (UTC)

Wikipedia:VisualEditor/Feedback#Visual_Editor

I apologise for this, but I wish to retract a lot of comments I made, and, as I said them widely, I want to make people widely aware of my retraction. Thank you for your time. Adam Cuerden (talk) 15:31, 9 August 2013 (UTC)

According to Wikipedia:Database reports/Articles containing links to the user space, our article on the 2012–13 Colchester United F.C. season had a link to userspace as of 12:00 yesterday. However, I can't find any userspace links right now, the page hasn't been edited in a week, and if someone had put a signature into one of the article's templates, I would expect numerous related pages to appear on the report as well — but this is the only one. What's happening? I've never seen this report before; I only discovered it today because it listed a page I'd edited, Rohan Mishra, which had nothing except a message from me, due to very unusual circumstances that I'll explain if you're desperately curious :-) Nyttend (talk) 01:44, 10 August 2013 (UTC)

Quick 1 minute look: it uses {{goa}} instead of something else (probably {{goal}} or similar was intended). πr2 (t • c) 02:00, 10 August 2013 (UTC)
At least it did until I fixed it. πr2 (t • c) 02:03, 10 August 2013 (UTC)
And I tried to load the page and look for the error after you fixed it. Took me a little bit of confusion before I thought to refresh the page history...Nyttend (talk) 02:05, 10 August 2013 (UTC)

Aren't article talk pages meant to be no indexed?

See [57] Dougweller (talk) 00:32, 6 August 2013 (UTC)

Nope. IIRC Google used to ignore talk pages on its own volition, but it obviously doesn't now. Graham87 01:15, 6 August 2013 (UTC)
FYI [58] EEng (talk) 03:13, 6 August 2013 (UTC)
I have often wondered why Google ignores talk pages when we don't request it with noindex or our robots.txt at http://wiki.riteme.site/robots.txt. I notice that all talk pages they index now appear to have url's of form wiki.riteme.site/wiki/Talk%3A and not wiki.riteme.site/wiki/Talk:. I haven't found a way to specify the difference in a search but compare the green url's in site:wiki.riteme.site/wiki/Talk and site:wiki.riteme.site/wiki/Category. The former says "Talk%3A" in all examples I examined while the latter says "Category:". I wonder whether Google has on their own added "Talk:" to a blacklist, have indexed a site which says "Talk%3a" instead, and have then followed the links without realizing that it bypasses the blacklist. PrimeHunter (talk) 03:40, 6 August 2013 (UTC)
maybe then we should NOINDEX them - I know I see a lot of BLP violations on them. — Preceding unsigned comment added by Dougweller (talk • contribs) 13:35, 6 August 2013 (UTC)
I agree it's quite strange that Google used to ignore article talk pages but not userspace pages. The last community discussion on what should and should not be no-indexed was some time ago and probably needs to be updated; I'm not sure where is the proper venue for such discussion.
Also on the subject of no-indexing, does anyone have any insight regarding the question I asked here? Thanks, Newyorkbrad (talk) 13:38, 6 August 2013 (UTC)
There is a small difference between them. robots.txt means "don't crawl trough this part of my website". The no indexing part is a side effect of the not crawling. Robots.txt is useful to avoid excessive usage by Google of our resources, where it is of no use to them anyways. NOINDEX means just that "you are free to look at this page, as long as you don't make it part of your public index". It might be that information on such pages is still used for instance for pagerank algorithm scores of indexed pages (not sure about that, but I wouldn't be surprised). Since pages are often available with multiple urls these days, I think that is why google is advising the NOINDEX as the 'go to' technique. Plus they still get to analyze your page as a bonus :D —TheDJ (talk • contribs) 09:32, 7 August 2013 (UTC)
  • I would support adding talk pages to robots.txt but not forcing a NOINDEX on each and every one of them. I would also support adding anything in certain project spaces such as WP:AFC drafts (although "most" should be covered by a full scale inclusion of all talk pages, there are a few that get misplaced in Wikipedia:Articles for creation/ (starting on page three)). Technical 13 (talk) 14:30, 6 August 2013 (UTC)
Talk pages for biographies of living persons are already noindexed, provided they have {{WPBiography|living=yes}} or {{BLP}} template at the top. Personally I don't support indiscriminate noindexing of discussion pages; NOINDEX should be confined to pages where there is good reason for it. Should there be consensus for this, I'd advise asking the devs to enable the MediaWiki option for this rather than using robots.txt. As I explained elsewhere, robots.txt does not prevent indexing of a page; it just makes it less likely. Robots.txt will stop Googlebot from seeing a NOINDEX instruction on a page, potentially allowing an explicitly noindexed page to be indexed. – PartTimeGnome (talk | contribs) 16:18, 11 August 2013 (UTC)

Subst with a template that invokes a module

I wanted to "freeze" some results from Module:Convert by using subst:, but as the table below shows, it does not work. In this table, {{convert}} is a standard template, and {{convert/sandboxlua}} is a template that invokes the module.

Template Result
{{convert|2|m}} 2 metres (6 ft 7 in)
{{subst:convert|2|m}} {{#ifeq:|on|{{ntsh|{{FORMATNUM:2|R}}}}}}{{#ifeq:{{{format}}}|off|{{formatnum:{{convert/{{#if:1|m}}|{{FORMATNUM:2|R}}|{{#ifeq:{{#expr:0*0}}|0|0}}|||||||r={{#ifeq:{{{sp}}}|us|er|re}}|d=LoffA{{#switch:{{{abbr}}}|off=none|def=off|off}}DbSoff|s=}}|R}}|{{convert/{{#if:1|m}}|{{FORMATNUM:2|R}}|{{#ifeq:{{#expr:0*0}}|0|0}}|||||||r={{#ifeq:{{{sp}}}|us|er|re}}|d=LoffA{{#switch:{{{abbr}}}|off=none|def=off|off}}DbSoff|s=}}}}{{convert/track/abbr/}}{{convert/track/disp/}}{{#if:|{{convert/track/sing}}|{{convert/track/adj/}}}}
{{convert/sandboxlua|2|m}} 2 metres (6 ft 7 in)
{{subst:convert/sandboxlua|2|m}} Conversion error: Need value

I can work around this (I'll use Special:ExpandTemplates), so I'm just wondering whether this is documented somewhere, or if I've missed something. mw:Extension:Scribunto/Lua reference manual#Returning text mentions subst, but I would need a couple more lines of explanation. Johnuniq (talk) 07:43, 6 August 2013 (UTC)

Hmmm. Now that I've saved the above, an edit shows the last item in the table is:
{{#invoke:convert|convert}}
So the subst applied to the template, but there was no attempt to call the module, and the bare #invoke:convert is causing the above error message. That's understandable, but not quite what I had hoped for. Johnuniq (talk) 07:48, 6 August 2013 (UTC)
I've added safesubst to {{convert/sandboxlua}} so it works now. -- WOSlinker (talk) 11:16, 6 August 2013 (UTC)
Template Result
{{subst:convert/sandboxlua|2|m}} 2 metres (6 ft 7 in)
Good grief, what magic is that!? When I've got a spare week I will study some docs, thanks. Johnuniq (talk) 11:48, 6 August 2013 (UTC)
  • {|safesubst:} is very confusing even though it works, and yet another reason people dislike wikitext, similar to parameter syntax "{{{1}}}" when instead "#[1]" would have been easier to read when mixed with other double-braced parser functions "{{__}}". I have not thought how to redesign {subst:}, but perhaps re-read "Help:Subst#The_safesubst:_modifier" and then spend 2 weeks meditating in a Buddhist temple. When I meditated, I realized it could have been called "{|insanesubst:}" and made as much sense yet also warn the reader not to be expect obvious sanity. I suspect there should have been a live template-processing option, such as mythical {{MODE:subst=yes}} which would treat every embedded template as if prefixed with {{{{{|safesubst:}}}__}}" so that the end result would replace the template call with the processed results. While we are on the subject of peculiar template actions, I want to confirm that some markup inside templates will run differently than when copied into the same page (surprise!), but fortunately those cases are rare. Also remember that {subst:} does not work inside reftags "<ref>..</ref>" as parsed differently (unless temporarily renamed "<xxref>"), and people wonder what would be instant valuable improvements to WP instead of diverting resources to a VE used by 10% of people. Let's see: fix edit-conflicts, allow subst in reftags, create a "sanesubst" mode, etc. I guess military leaders learned how "division of command" can send the cavalry in the wrong direction when major help is needed elsewhere. -Wikid77 04:01, 7 August 2013 (UTC)
For a (slightly) simpler explanation: "subst:" is not recursive. It expands the template it is used on, but not the #invoke call inside that template. The safesubst trick is one way to mark templates and parser functions used inside a template to also be expanded if the outer template is subst'd. Instead of {{{|safesubst:}}}, one can use <includeonly>subst:</includeonly> for the same effect. You just need to know one of these tricks to use it; it isn't essential to understand how they work. The help link Wikid77 gave you explains in more depth if you are interested. – PartTimeGnome (talk | contribs) 16:35, 11 August 2013 (UTC)

[edit source]

I don't like the new [edit source] links because of their additional length and because they make me think that I'm attempting to edit a protected page without the rights to do it. Is there any gadget or other method that I could use to cause these links to display as [edit] when I'm logged in? Nyttend (talk) 21:31, 6 August 2013 (UTC)

Preferences → Editing → MediaWiki:Visualeditor-preference-betatempdisable worked for me. — Maile (talk) 21:36, 6 August 2013 (UTC)
And for me too; thanks. Nyttend (talk) 21:39, 6 August 2013 (UTC)
@Nyttend: Also check out User:Evad37/rename editors for a script you can import (that disable switch won't be around forever, unless we can convince the WMF otherwise). If you don't want the entire script, just the CSS at User:Evad37/noVEsections.css will do what you want will restore the simple [edit] for sections. Ignatzmice•talk 13:26, 7 August 2013 (UTC)
As there is an alternative method to reduce the trouble caused by relabelling the links, please notice that completely disabling VE will cause instead that you will not be able to use it and that devs, VE itself and the whole community won't benefit from your experience. It's ok if one does not want to use it, but this is not really what was asked here (and ways to disable it are already linked everywhere) :) --Elitre (WMF) (talk) 14:59, 7 August 2013 (UTC)
I use IE, so there's literally no way in which this preference affects me aside from the changed header name. I was completely unaware that I'd previously checked the box in the first place. Nyttend (talk) 17:49, 7 August 2013 (UTC)
Which means I'll need to ping you as soon as support for IE arrives to make sure you don't miss VE then ;) --Elitre (WMF) (talk) 17:53, 7 August 2013 (UTC)
Why does Nyttend get the changed labels in the first place? If he uses IE (which is not supported), VE shouldn't be active at all, and certainly it should not mess with labels then! --Patrick87 (talk) 19:18, 7 August 2013 (UTC)
Nyttend, if you're interested in finding out a bit more about this, you could temporarily re-enable VisualEditor and then click this link: https://wiki.riteme.site/w/index.php?title=Water&uselang=qqx and tell us what the tabs say across the top of the page. It should begin with something like (nstab-main). The main question is whether any of them say "visualeditor-ca-editsource". Whatamidoing (WMF) (talk) 22:07, 7 August 2013 (UTC)
@Whatamidoing (WMF): I thought I'd pitch in here for you. I'm on a fully updated Windows XP Pro machine and IE8, fully updated to Build 8.0.6001.18702. From left to right, at the top of the page as they appear: (nstab-main)(nstab-talk)(vector-view-view)(visualeditor-ca-editsource)(vector-view-history)
However, if I select the entire heading and copy it to clipboard, then I end up with:
(namespaces)(nstab-main)(nstab-talk)(variants)(views)(vector-view-view)(visualeditor-ca-editsource)(vector-view-edit)(vector-view-history)
I just did a quick looksie and refreshed that page several times. All the information that's present in the clipboard copy actually loads when the page is refreshed, but disappears after (I assume) all the javascript is done loading and then I see visually what I shared above.
Additionally, all of the 'Edit Section' links are indeed 'Edit Source' within any article, even outside main and user spaces, with VisualEditor disabled within my preferences, those are just 'Edit'. Jguy TalkDone 16:43, 9 August 2013 (UTC)
Thanks. It's the presence of (visualeditor-ca-editsource) on a browser that can't use VisualEditor that causes it. Now I can go talk to the tech folks and see what they have to say. They're all (or nearly all, at any rate) off at Wikimania now, so it may take a bit to get an answer. It's possible that this is deliberate, because having all edit-with-wikitext links match regardless of namespace, etc., has been requested, but hopefully I can at least find out whether it's intentional or accidental. Whatamidoing (WMF) (talk) 17:49, 9 August 2013 (UTC)
Along similar lines I see the [edit source] links when logged out, despite using a browser VE doesn't support (Opera) and having JavaScript disabled. I don't see them when logged in because I have VE disabled in preferences. To my mind, using an unsupported browser or browsing without JS should have a similar effect to disabling VE; I find it strange that this one aspect of VE shows in browsers that cannot run VE. – PartTimeGnome (talk | contribs) 21:51, 11 August 2013 (UTC)
Opera 12 and higher is no longer on the browser blacklist. Whatamidoing (WMF) (talk) 05:26, 12 August 2013 (UTC)

RdCheck

The issue discused here appears to be resolved as the tool RdCheck seems to be working again. I've tried it out on a few pages and the results came out normally. So, could the link to the tool in "What Links Here" be re-instated? Or better yet, could a link to RdCheck be added to the Toolbox so we don't have to waste (significant) time going though What Links Here to get to it? — Cbbkr (talk) 20:46, 9 August 2013 (UTC)

What would be the point of that? As I said in that discussion, using the "hide links" feature (along with the "hide transclusions" feature for templates) pretty much has the same effect anyway. Graham87 02:41, 10 August 2013 (UTC)
"pretty much" being the key phrase:
1. What Links Here takes significantly longer in terms of clock time to bring up than RdCheck, and that's just for the initial page. More "significantly longer" times are required to remove the links and transclusions (and possibly to select a pagesize larger than 50 entries, which is less painless than going back and forth between multiple pages of randomly listed entries). The wasted time required to bring up that initial What Links Here page is why I'd like to invoke RdCheck directly from the Toolbox.
2. RdCheck arranges the links alphabetically by the name of the section/anchor they point to and makes obvious which ones point to an invalid section name/anchor. When a conscientious editor is considering renaming a section or anchor in an article RdCheck makes it very easy to predetermine what might become broken as a result of the change. Doing this from What Links Here (even with Popups, and more so without it) is much more laborious. A minor detail, RdCheck sub-sorts each section/anchor group.
The only advantage What Links Here gives me is that I can use Popups with it to directly edit the redirect or bring up or edit its talk page, etc. instead of first bringing up the redirect before selecting these possibilities. But the benefits of #1 & #2 more than compensate for this.
— Cbbkr (talk) 20:42, 10 August 2013 (UTC)

Friday pageview stats

According to the dump pages the data is out there for yesterday's page views. Why isn't the pageview statistic page updating?--TonyTheTiger (T/C/WP:FOUR/WP:CHICAGO/WP:WAWARD) 23:07, 10 August 2013 (UTC)

You sure? [59] I see 383 views on August 9th for VPT—it may have just taken some time to update, unless I'm misunderstanding you. Theopolisme (talk) 13:25, 11 August 2013 (UTC)

resurrecting file history

Could s.o. restore file:Andamanese languages--map.JPG or merge its history w the copy on Commons? I'd like to see what its sources were. — kwami (talk) 09:02, 11 August 2013 (UTC)

The only content was:
{{NowCommons|Image:Andamanese languages-map.jpg}}
== Licensing ==
{{PD-self}}
PrimeHunter (talk) 09:49, 11 August 2013 (UTC)
Okay, thanks. I take it the author was Ko'oy? — kwami (talk) 10:30, 11 August 2013 (UTC)
Yes. It was also uploaded to File:Andamanese languages map.jpg the same day. The user contributions at the time [60] includes [61] which says "It was loosely adapted from similar maps used by sources such as the Andaman Association." PrimeHunter (talk) 10:45, 11 August 2013 (UTC)
Thank you! That's what I needed. We have a new map, and are wondering which is better sourced. Sorry I didn't notice that on my own. — kwami (talk) 20:18, 11 August 2013 (UTC)

Odd behavior in preview mode

Procedure: Edit any page in legacy mode. Click "show preview". Scroll down so that the the text box is visible. Press "alt". Then click on the browser's scroll bar. The text in the text box becomes invisible. Sometimes it regains visibility upon moving the mouse. Other times it reappears only when the scroll bar is moved. Can anyone reproduce? (Monobook, Firefox 22, Windows Vista) --Cryptic C62 · Talk 22:45, 11 August 2013 (UTC)

Vulnerability of CheckUsers

I have been wondering lately if we should think about protecting our CheckUsers. If an editor angers the wrong people on Wikipedia wouldn't they be the first link in the chain to out that user for off-wiki retaliation? I am thinking more of criminal organizations, foreign governments, and big corporations than the run of the mill editor squabbles. Safeguards like CheckUser requests at the sock board to activate tools or two needed to perform a check. I don't know what would be involved or how the sys works. Someone may wish to [link that article here] about the French government strong arming an admin to delete a page.--Canoe1967 (talk) 23:10, 10 August 2013 (UTC)

Why are checkusers so special? Normal editors (not even admins) already get phonecalls to their employer alleging that they're implicit in pedophilia and hiding pedophiles, and ArbCom won't even open the case. Andy Dingley (talk) 23:15, 10 August 2013 (UTC)
This isn't so much about protecting checkusers themselves, but protecting others who would be affected by their actions. Whereas most admin actions can be undone (as happened in the French incident), a checkuser revealing personal information cannot be undone. If a government or corporation puts a checkuser under duress to reveal personal information, it is likely the consequences for the person concerned would be very serious. – PartTimeGnome (talk | contribs) 22:19, 11 August 2013 (UTC)
The Foundation made a statement about the French event here at meta. -84user (talk) 01:20, 11 August 2013 (UTC)
See also this program that provides some specific assistance. As well, the WMF has been helpful in addressing "problematic" requests and pressure on various individuals including checkusers. Risker (talk) 01:52, 11 August 2013 (UTC)
I was thinking of the non-legal pressure. An editor writes something bad about the KGB. The KGB pressures a checkuser to get the editor's IP. The KGB then pressures the ISP to get the editor's name and address. The checkuser is the first, and probably easiest, link in the chain of events. They are all listed and some probably have either talk page information or email turned on to access them. The KGB could go through the same route with ISP email to identify a checkuser first. I think even Google and Yahoo emails need a local ISP email to create. More steps but still possible in theory. I was just wondering if there are any thoughts about adding steps to the CheckUser process to help with this. Even a non-transparent method that the public isn't aware of. The checkuser could click a wrongly labeled box that would alert authorities. At the same time it would generate an IP to the Vatican or Grand Central Station Wi-Fi. Something like-> Accelerated process: y/n?--Canoe1967 (talk) 12:42, 11 August 2013 (UTC)
One idea I've had: Provide a way for checkusers to quickly resign their checkuser rights without needing to ask anyone else. If a checkuser were under duress they could resign their rights in two or three clicks, then no longer be in a position to reveal personal information. To get their rights back again they'd need to re-apply to ArbCom and convince them they were no longer under duress.
Also, I think the considerations here apply just as much to oversighters. A lot of oversighted information is private information of one sort or another, and oversighters can see that material. – PartTimeGnome (talk | contribs) 22:32, 11 August 2013 (UTC)
Those are very good ideas, both of them. I'd support that. Ignatzmice•talk 22:39, 11 August 2013 (UTC)
None of the above proposed solutions solve the problem as they can all be gamed by a sufficiently determined attacker. First, the a checkuser approval system, do you need to go back and ask for approval for each leg of a chain? What about multiple accounts linked by behavioral evidence? Get approval to run a checkuser on A, based on a regular case, but actually run it on B who those applying the Duress are after. Or maybe the security forces pick up 2 checkusers so one can approve the tool use of the other. Not to mention this all would make checkuser a bureaucratic nightmare. Add a quick resign CU option, make it very clear to the CU you picked up that resignation will be treated as non-compliance and will trigger what ever is being threatened for duress. There is quite simply no way to prospectively guard against the compromise of the person behind the account that could not be overcome by an the one applying the duress. At best we could make it easier for the CU to force the issue, calling "bluff" of the one applying the duress, but there is always a risk its not a bluff... Monty845 04:22, 12 August 2013 (UTC)
You are quite right. I can't think of anything we could do that would stop someone powerful, competent and determined from getting what they want; but we can make it harder for them. However, competency is not a given, especially when considering governments. Look at the French incident – they went to a lot of trouble to get a page deleted, but didn't know another admin could easily restore it. It subsequently became the most visited page on the French Wikipedia, which was most likely the last thing they wanted. – PartTimeGnome (talk | contribs) 21:02, 12 August 2013 (UTC)
  • Please Note authority figures (or whoever) should never contact Wikipedia volunteers, They should always contact the Wikimedia Foundation directly. The incident in France was bad and should not have happened. If a volunteer is contacted by an authority figure (or whoever), the volunteer should always refer them to the Foundation. Most people already know this, but I think it's worth repeating. 64.40.54.44 (talk) 04:03, 12 August 2013 (UTC)
    Volunteers are an easier target to intimidate so they're the ones the bad guys will go after, no matter how much we and the WMF say they shouldn't. Saying "go talk to the WMF" probably won't do a volunteer much good when they are being threatened with jail or worse. – PartTimeGnome (talk | contribs) 21:02, 12 August 2013 (UTC)
What would be involved in having a fake button generate a specific IP instead of the users real IP? This IP address could be set to trigger all sorts of alarms at the ISP when anyone tries to find out customer information on it.--Canoe1967 (talk) 22:53, 12 August 2013 (UTC)

Template:IE

Could someone please have a look at this template? Firstly, it has some loose code hanging around at the top, and secondly, when I tried to add {{Uncat}} to it, this messed the template page up even more. Thanks! It Is Me Here t / c 06:15, 12 August 2013 (UTC)

 Done see here. Of particular note is that if you put {{uncat}} on a template, it must be inside a <noinclude>...</noinclude>. --Redrose64 (talk) 07:51, 12 August 2013 (UTC)
Thank you! It Is Me Here t / c 10:13, 12 August 2013 (UTC)

and, & and me

I recently created Lindsay, Pontypool & Bobcaygeon Railway by clicking a link I found on the Bobcaygeon page. Now the article has an & in the title, rather than "and". I saw this and attempted to fix it with a move, but it said that you can't do that - that it already has an "and" in the title!

What's the story here? Is there some background magic going on? And since most railway articles do say "and", is there a way to get that into the article name now?

Maury Markowitz (talk) 16:09, 12 August 2013 (UTC)

I just moved it to 'and' instead of '&'. No issue. Weird. Fiddle Faddle 16:13, 12 August 2013 (UTC)

Playing audio files is inconvenient

Playing audio files is inconvenient. Audio files cannot be played in-page. One has to be redirected to a new page to play the file. Example: C_major

To be precise I am talking about the simpler file insert method. The above link contains two different methods. The simpler insert method is frequently used because it do not destroy the layout. The other method takes large space but it can be played in-page.

So I propose a re-design. — Preceding unsigned comment added by Golopotw (talk • contribs) 22:36, 12 August 2013 (UTC)

\relative c' { f d f a d f e d cis a cis e a g f e }
does this work better for you?
recently the "score" extension was introduced. it allows in-page playing of notes. see also Help:Score.
HTH. peace - קיפודנחש (aka kipod) (talk) 22:59, 12 August 2013 (UTC)

Slow

Is it just me, or is the site kinda sluggish right now? It's taking me upwards of 10 seconds to save edits. Ten Pound Hammer • (What did I screw up now?) 10:50, 11 August 2013 (UTC)

Sluggish since I signed in 1.5hr ago ES&L 11:07, 11 August 2013 (UTC)
Yup - in UK.  —SMALLJIM  11:12, 11 August 2013 (UTC)
Slow in NL as well. — Edokter (talk) — 12:00, 11 August 2013 (UTC)
Yes in San Antonio, TX. — 16:09, 11 August 2013 (UTC)
Might be related to some work by the Operations team that can be seen in the Server Admin Log. Are there still issues? --AKlapper (WMF) (talk) 13:59, 13 August 2013 (UTC)

Cite Templates in dropdown don't work

The four convenient cite templates in the drop-down box have ceased working for me. Perhaps I need to change browser settings or something. Working with latest IE on Windows 8 desktop. Grateful for any hints or redirect. Davidships (talk) 01:16, 13 August 2013 (UTC)

Maybe you could be more specific. I use Firefox 23.0 with Windows XP. Things have been quirkier than usual the last month or two. Sometimes my toolbar doesn't show, and I have to do "Preview" as a kind of "Refresh" to bring it back. Sometimes the Templates drop-down box isn't there, and I have to go over to the upper right hand side and click on "Cite" to bring it back. Does any of this sound like what is happening to you, or is it something else? — Maile (talk) 01:25, 13 August 2013 (UTC)
Difficult to say more. I can open and close the cite toolbar with Templates, Named References, Error Check but none of the templates open and neither of the other two apparently live links do anything. It is the same in Edit Source and Preview. The only thing that happens in Preview is that the page scrolls to the top when trying to open a template from the menu. Davidships (talk) 10:31, 13 August 2013 (UTC)
Since I don't use IE or Windows 8, hopefully someone else can answer this. Maybe it would be helpful for others reading this if you could list which skin you're using (Preferences/Appearance), and also what gadgets you have checked under Preferences/Gadgets. — Maile (talk) 14:01, 13 August 2013 (UTC)
It appears you are using IE10— try compatibility view. --  Gadget850 talk 14:11, 13 August 2013 (UTC)
Well, thanks Gadget. I played with CV a bit - when I applied it, it was even worse - the edit tool bar disappeared altogether. So I reverted it, I think, but now the templates seem to work OK, even after a reboot. So.... thanks Davidships (talk) 16:26, 13 August 2013 (UTC)

page showing cat when cat does not show page

This cat does not show this page.

A userspace subpage showed a category at the bottom but the category page stopped listing the subpage. (Because of editing, this may not be apparent any more but it was yesterday and again just a moment ago.) Most likely, it resulted from my bad programming of a new template I'm developing on a different subpage, the results of which are displayed on my sandbox page; the template assigns the category to the page it's used on. If my bad programming is why the cat discrepancy happened, there's no need to fix it, because I'll probably solve the problem anyway when I get the template to work properly in other ways. But this seems to be about how Wikipedia works, which could be useful to understand. Even if I misprogrammed the template in an grossly stupid way, I don't think I should have been able to achieve that discrepancy. Is it a Wikipedia/Wikimedia/MediaWiki feature/bug? If it's a feature, what should we know about when one shows but the other doesn't? Thanks. Nick Levinson (talk) 15:19, 12 August 2013 (UTC)

The issue that you see is common to all categories and is part of the MediaWiki set of fun foibles. Your user page was 'in' the category, but was not visible because of the thing I know of as the queuing mechanism. I performed a null edit o your user sub page and it was then rendered visible in the category. Some categories have an excellent explanation of this, I just cant remember which ones. It fools many people quite often. Fiddle Faddle 15:50, 12 August 2013 (UTC)
See Help:Job queue and WP:NULL. PrimeHunter (talk) 15:54, 12 August 2013 (UTC)
The job queue is counter intuitive. When the server is really busy the queue gets serviced faster! It seems, though that some pages depend on being edited before they will ever appear in categories. IT seems to be to do with the order the category is created and the page has the category element included on it. IIRC if you add the category to the page prior to the creation of the category, hell may have to freeze over before you see the page inside the category. Whichever way round it is, it is most definitely a pain the fundament until one remembers about it. Fiddle Faddle 16:01, 12 August 2013 (UTC)
For fun look at mw:Manual:Job queue and the talk page, especially this part Fiddle Faddle 16:07, 12 August 2013 (UTC)
Resolved. I'm relieved it was not my bad programming, which is only bad for other reasons. I've done dummy edits occasionally but thought they were null edits and didn't realize null edits were different and useful, so thanks for doing one. The links helped and so did the humor. In this case, the pages were created years after the category was. Thank you all. Nick Levinson (talk) 16:33, 12 August 2013 (UTC)
Maybe the cat's not alive. Martinevans123 (talk) 17:35, 12 August 2013 (UTC)
This is pure disinformation. "That part" only applies to the default way of running the queue, only applicable when you do not have shell access (that is, only on free hostings). Every single large and wiki, including Wikimedia ones, obviously use better methods; I believe Wikimedia wikis don't even store the queue items in the database, but in a specialized system designer for job queues (but I'm not sure which one right now). Matma Rex talk 21:05, 12 August 2013 (UTC)
FWIW yes, the WMF now uses Redis, which should increase performance. Legoktm (talk) 20:49, 14 August 2013 (UTC)
Whatever the actual behind-the-scenes method, the job queue software did change a few weeks ago, not long after the general deployment of VisualEditor. In the past, if you altered a template, the template change would (eventually) propagate through to the articles which transcluded it, and for each article, the entry on the category page, the categories at the page bottom, and the what-links-here would all be updated together. But now it seems that one or two of these can become updated whilst the others are not - so an article might be visible on a cat page yet not show the same cat at the bottom, or vice versa. It's worse for a hidden cat - recently I've come across several cases where, when editing an article, it's shown (at the very bottom) "This page is a member of 1 hidden category:" yet when I check that cat page, the article isn't listed, and nor is the hidden cat shown at the bottom of the article when not in edit mode.
The only sure way of fixing the links for a given article seems to be a WP:NULLEDIT, which seems to defeat the whole point of the job queue. --Redrose64 (talk) 21:48, 12 August 2013 (UTC)
@Redrose64: File a bug? The change has little to do with actual job queue itself and is not really related to VisualEditor – it was prompted by issues with templatedata tags on doc subpages not applying to the main template page due to a bug in metadata cache invalidation, or something like that. Matma Rex talk 11:48, 14 August 2013 (UTC)
@Matma Rex: Well, you may be right, but I have shell access on all the wikis I run, and I have an expert, and I have the responses in the mediawiki manual, so I suspect the correctness of this part. I am aghast that it does work that way, but that is the way it is stated there that it works. Or did until the job queue software change, presumably. Fiddle Faddle 11:37, 14 August 2013 (UTC)
@Timtrent: How else would you expect this to work when one can't do anything but upload the files to the server via FTP and access a database? As I said, it's easy to set up a proper way when you have the necessary access. Also, patches are always accepted if you have a better lowest-common-denominator solution :) Matma Rex talk 11:45, 14 August 2013 (UTC)
Is someone keeping score? Fiddle Faddle 13:45, 14 August 2013 (UTC)

Layout works in strange ways

Hello, ysterday I made changes to the article on an old town in Germany named Steinfurt and everything looked proper on my own PC (even with different browsers and resolutions) but today I checked the page again while I was in the public library of Münster and there it was totally different. All of a sudden neither the pics on the left side nor the ones on the right side were any longer embedded. Instead there were pics on the left and on the right (right so) but there was no text at all in between the pics but a kind of huge gap. The text only continued underneth the pics. Check it out: previous version What is that all about? What escaped me? Nordhorner II (talk) I am not a number! I am a Nordhorner. 11:57, 13 August 2013 (UTC)

What browser and version. I'm guessing Internet Explorer in the library. That sounded like a game of Clue --  Gadget850 talk 14:13, 13 August 2013 (UTC)
Hello Gadget, here is the requested information on the PC I used in the library:
  • Microsoft Windows XP Professional Version 5.1 2600 Service Pack 3 (32 Bit)
  • Resolution 1920 x 1020
  • MS IE 8.0.6001.1870.2CO

I expanded the article on the aforementioned town in order to express a certain appreciation for the good people there who supported my mother when she had to recover from a most severe physical challenge and so I was embarassed when it looked as if my effort had backfired (and messed up the page) ... Well, a lot of institutions and companies in Germany stick to Windows XP but don't miss IE updates.Nordhorner II (talk) I am not a number! I am a Nordhorner. 08:26, 14 August 2013 (UTC)

This is caused by the alternating use of right and left floating elements. IE6 and IE7 don't really support this. IE > 8 in IE7 compatibility mode also might cause trouble. In the past we used to avoid doing this I think, but it is hard to keep that up now. Most people use better browsers these days and since it doesn't really affect people's ability to actually read the page, it's not a critical problem. —TheDJ (talk • contribs) 09:52, 14 August 2013 (UTC)
Thank you. Let me repeat that at home I do use another browser than IE. Moreover the library offers to use Firefox too. Nordhorner II (talk)I am not a number! I am a Nordhorner. 12:19, 14 August 2013 (UTC)

Mapping

I'm in the midst of writing a series of articles on abandoned railways. These tend to be easy to see on satellite imagery as lines through forests or similar features. My particular task is helped by a Google Earth map that I found that is semi-accurate, but needs some cleanup. So...

1) can someone recommend a tool for editing the existing map file I have, so I can correct the minor mis-locations? 2) Once I finish (1) I'd like some way to present these in the Wiki articles. I'm open to any suggestions here.

Thanks!

Maury Markowitz (talk) 13:50, 14 August 2013 (UTC)

You might possibly find some help in Wikipedia:WikiProject Maps. Jim.henderson (talk) 01:14, 15 August 2013 (UTC)

Table rulings

Can someone tell me what has gone wrong at Lemonade (Alexandra Stan song)#Charts? The rulings on the table have disappeared, and I cannot see why. The lack of | characters before the {{singlechart}} calls is normal, and works at all other articles (see Category:Singlechart usages for UK for examples).—Kww(talk) 16:21, 14 August 2013 (UTC)

Don't ask me why, but it appears to be caused by the {{col-begin}} template in the section above. Monty845 16:30, 14 August 2013 (UTC)
That's odd: the table is included inside of columns in a lot of places. I'll dig into that later.—Kww(talk) 16:34, 14 August 2013 (UTC)

Section heading numbers

I would like to suggest that section heading numbers should be followed by a fullstop. My reason is that, in headings that also contain numbers, the result often appears confusing at first glance. (To me, at least.)
For example, a heading like "Class 4" or "Class 4 locomotive" may display as, for example, "4 Class 4" or "4 Class 4 locomotive". I believe "4. Class 4" or "4. Class 4 locomotive" would be less confusing on the eye.

4 Class 4
4. Class 4

4 Class 4 locomotive
4. Class 4 locomotive

André Kritzinger 01:25, 9 August 2013 (UTC)

You can do this for your own browser by either using a CSS2 compatible browser and adding 
.tocnumber:after { content: "." }
to Special:MyPage/common.css or by adding 
$('.tocnumber').append('.');
to common.js. If the JS doesn't work, then try wrapping it in "$(function(){" ... "});". But, anyway, this is a small change, but it might disturb many people. I'll look for an old discussion about this. πr2 (t • c) 01:46, 9 August 2013 (UTC)
That's a handy fix, but only works for the Table of Contents of each page. Use this to do the numbers in the headings themselves as well:
.tocnumber:after, .mw-headline-number:after { content: "." }
—sroc 💬 02:09, 9 August 2013 (UTC)
Ah, you're right. Thanks! I didn't notice because I have the "Auto-number headings" pref disabled, so I just assumed it was referring to the TOC. Anyway, these issues are obviously related, and the code is basically the same. :) Maybe this is a good proposal. πr2 (t • c) 02:24, 9 August 2013 (UTC)
I've also added the following to my CSS to reduce the size of the numbers to further help distinguish them:
.tocnumber, .mw-headline-number { font-size: 80% !important; }
Each to their own, but I think André's suggestion is a good one. —sroc 💬 02:34, 9 August 2013 (UTC)
Comment: The "section heading numbering" has caused issues with other gadgets and userscripts before. I don't think there should be any change to it without a full scale RfC to ask the community what they want to see happen. My first concern with changing this is how the change is going to effect the "Ask a question" gadget for the Teahouse. I just recently got that script fixed to not show a messy <span class="mw-headline-number">###</span> when it pulls the section title and posts it to the edit summary making the section link unusable. You can see the details of that at MediaWiki talk:Gadget-teahouse/content.js. Thanks for taking these other issues into mind before making any changes. Technical 13 (talk) 11:29, 9 August 2013 (UTC)
Providing Technical 13's valid concerns are addressed, this seems like a sensible change, But isn't it a MediaWiki issue? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:16, 9 August 2013 (UTC)
Thank you for the comments. A "personal fix" for my own browser is not the solution, though. Since it will affect virtually ALL pages, I'd rather see the boffins look into this to see whether it is doable. If it is, fine, if not, so be it. Should I refer the suggestion to someplace else or can I consider the seed as being planted and wait for it to sprout? André Kritzinger (talk) 13:56, 9 August 2013 (UTC)
Andy, if there were consensus for this change an admin could make it in our site-wide common.css without any changes to MediaWiki. Of course, the devs might want to make this the default for MediaWiki, but that's up to them. I tried it in my personal CSS, but found I preferred it without the full stops. (This is a personal preference thing. It might be because I've gotten used to the full stops not being there.) – PartTimeGnome (talk | contribs) 22:01, 11 August 2013 (UTC)
OK, so where do you okes suggest I take this suggestion now to get a community discussion going? André Kritzinger (talk) 20:03, 16 August 2013 (UTC)
Well, this is a community discussion... If you're looking to get a better idea of community support with support/oppose !votes, there's WP:Village pump (proposals). – PartTimeGnome (talk | contribs) 20:56, 16 August 2013 (UTC)
Thanks. That's what I was looking for. André Kritzinger (talk) 23:59, 16 August 2013 (UTC)

Konrad Zuse

There is vandalism on this page ("Hello konrads") that appears just above the table of contents, but doesn't appear to be part of the page's own code. Maybe it's in a template, but I can't figure out which one. Help, please. Thanks, NawlinWiki (talk) 14:37, 13 August 2013 (UTC)

It's already been reverted. Try a WP:BYPASS. --Redrose64 (talk) 15:10, 13 August 2013 (UTC)
Related observation but in the last couple of days I've dealt with about 5 OTRS tickets about vandalism and in each case cluebot had already reverted the vandalism when I looked, but the cache hadn't cleared and in 2 cases it required a null edit before the cache cleared. NtheP (talk) 10:48, 16 August 2013 (UTC)

Counting infoboxes

You may be interested to know that we have we have over 2.4 million infoboxes in article-space. Please see Wikipedia:WikiProject Infoboxes/Statistics, and feel free to make additions or fixes there. Would it be possible to automate the transclusion counts? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:22, 15 August 2013 (UTC)

Yet another Articles for Creation Helper Script

I am absolutely baffled by installing this script. I've checked the box on my Preferences and cleared my browser cache, yet the script doesn't show up when I open an article in the pending-AfCs category. Any ideas on what I'm doing wrong? —Theodore! (talk) (contribs) 04:14, 16 August 2013 (UTC)

What is your browser and skin? Do you have a "Review" tab at Wikipedia talk:Articles for creation/Kapow Pictures, or a triangle tab which reveals a "Review" link when clicked? PrimeHunter (talk) 09:44, 16 August 2013 (UTC)

Recent changes?

Not sure if I've just been unobservant for several years: has there always been a line right under the level 1 heading for Special:RecentChanges that says "Track the most recent changes to the wiki on this page."? Also, I thought calling Wikipedia "the wiki" was generally frowned upon. Brambleclawx 14:24, 16 August 2013 (UTC)

Indeed, Wikipedia is a wiki, not the wiki. The message would read better as "this wiki", which I think is what is meant. – PartTimeGnome (talk | contribs) 20:17, 16 August 2013 (UTC)
The message is from MediaWiki:Recentchanges-summary. It hasn't been customized so the MediaWiki default is shown. "the wiki" refers to whichever wiki the message is displayed at. I'm not sure it's a good idea to create custom messages for minor changes. If the MediaWiki default is changed later then we wouldn't get the change. PrimeHunter (talk) 21:45, 16 August 2013 (UTC)

VisualEditor weekly update - 2013-08-15 (MW 1.22wmf13)

Hey all,

Here is a copy of the weekly update for the VisualEditor project. This is so that you all know what is happening, and make sure you have as much opportunity to tell us when we're wrong and help guide the priorities for development and improvement:

VisualEditor was updated as part of the wider MediaWiki 1.22wmf13 branch deployment on Thursday 15 August. In the three weeks since 1.22wmf12, as well as presenting their work at Wikimania, discussing and planning improvements and new featurees, the team worked on some changes to how VisualEditor integrates with MediaWiki, a few minor feature improvements and improving the performance of the system, and fixing bugs and stability improvements.

Firstly, on the integration, the "edit" and "edit source" tabs and section edit links can now be configured more flexibly (which has been taken advantage of on the English Wikipedia). The labels for these "edit" and "edit source" tabs and section edit links (however they have been configured for a given wiki) will be consistent on all pages, even those that cannot yet be edited with VisualEditor like templates (bug 50402). These labels are applied before the page is sent to the user, so they no longer "flash in" for some users (bugs 50542 and 50692). Further, the section edit links both appear at once, rather than only one appearing until a user hovers over the heading (bug 50540). We also made a more prominent welcome notice that appears the first time a user opens VisualEditor (or every 30 days for logged-out users), warning them about VisualEditor being in beta (bug 52366).

In terms of new features, you can now edit references that are defined inside a <references> block (bug 51741), references defined in templates and image captions will also display (bug 51289 and bug 52427), and nested references now display correctly (bug 50749). We also made some changes to the link inspector to make it faster and simpler to use - you no longer need to press enter twice to set a link (bug 51065) or click as many times (bug 51523), and you are warned more clearly that the title you've entered is invalid (e.g. "Foo{}bar") and so won't let you set it (bug 33094). We made some major performance improvements to deleting text (bug 52013) and scrolling pages (bug 52014), which should be visible on long pages.

You can now add and edit <code> (code) and <s> (strikethrough) annotations in experimental mode on MediaWiki.org - coming to production wikis soon (bugs 51590 and bug 51610), as well as <tt> annotations with the same code (bug 52352), and a more general solution for use with similar pairs of annotations built out too (bug 52477). We added a keyboard shortcut for the "Clear formatting" tool: Ctrl+\ or ⌘ Cmd+\ (bug 51507). VisualEditor now uses the same kind of post-edit feedback message that the wikitext editor uses, for increased consistency between the different editors (bug 39632). Finally, we fixed the last known issues with Opera and so un-blacklisted it (bugs 37861, 47793 and 50813; tracked by bug 36000).

On the bug front, we fixed a number of issues. Firstly, we correct a problem where an ugly error was shown to the user on changing a template if there was an API issue (bug 52483). We now strip leading whitespace from paragraphs, so as to avoid users creating accidental <nowiki>s (bug 51462). A bug that made it impossible to save multiple consecutive references is now corrected (bug 52228), as is one that sometimes didn't get you a new edit token if your current one had expired (bug 51915). We also quickly fixed an issue where VisualEditor would crash on loading a page with a <nowiki> in it (bug 51948), and a corruption issue which led to categories getting duplicated (bug 52238).

Adding a link on an empty selection no longer crashes (bug 51404); if you press enter too quickly it still works (bug 51415); and the link inspector no longer aggressively picks a link for you in cases where there's only one suggestion (bug 52420). The save dialog briefly attached to whichever dialog you had most recently opened, rather than the main toolbar; this is now fixed (bug 52317), as has the toolbar floated to the top of the screen over the user's personal tools if a dialog had been opened (bug 52441). The link describing wikitext in the warning notice about not inserting it now opens in its own window (bug 52093), as does the link to the user guide (bug 52475). Embedded buttons' inspectors now display correctly, used in the forthcoming equation editor on large equations (bug 52845). Further, once you save the page, we re-enable the wikipage content handlers, so gadgets like those that make tables sortable will work again (bug 51565).

Finally, the Google Summer of Code work progressed well; early versions of the Math extension editor and tool for setting text language details are now available for testing on MediaWiki.org, and that for the SyntaxHighlight extension will be soon.

A complete list of individual code commits is available in the 1.22/wmf13 changelog, and all Bugzilla bugs closed in this period are on Bugzilla's list.

Ahead of the regular MediaWiki deployment roadmap, this should be deployed here two days early, on Tuesday 20 August.

Hope this is helpful! As always, feedback gratefully received, either here or on the enwiki-specific feedback page.

Jdforrester (WMF) (talk) 23:16, 16 August 2013 (UTC)

Search and nonexistent pages

Go to http://wiki.riteme.site/wiki/User:DoesntExist and click the "Search for ..." link. You get back to the same place. Doesn't seem very useful: can someone see if a fix to MediaWiki:Noarticletext will break anything? — This, that and the other (talk) 11:47, 16 August 2013 (UTC)

That's odd. The search link is Special:Search/User:DoesntExist which redirects to User:DoesntExist. Normally search will only redirect when there is a matching title like Special:Search/Exist which redirects to Exist. Other namespaces give a search results page and not a redirect when there is no matching title, for example: Special:Search/User talk:DoesntExist, Special:Search/Wikipedia:DoesntExist, Special:Search/DoesntExist, Special:Search/Talk:DoesntExist. Is it deliberate or a bug for search to redirect Special:Search/User:DoesntExist? I suppose it's useful to go to a page saying the account is not registered when you enter "User:DoesntExist" in the search box. It may be less useful for a search link to do it, but consistency between the search box and search links is probably good. PrimeHunter (talk) 22:49, 16 August 2013 (UTC)
It's not just for "DoesntExist"...try User:Rfkhdj, for example. It seems that searching for a user page (Special:Search/User:Rfkhdj) will always take you to the userpage, regardless of whether or not the user exists. Theopolisme (talk) 19:33, 17 August 2013 (UTC)

how to delete excess space by a template draft

A template displays two spaces where the programming has only one nonbreaking space (one ampersand nbsp semicolon) after the pipe in an "#if" template inside the main template that I'm drafting. (I assume that if I use a breaking space it will be stripped and there'll be no space at all.) The double-space is visible in my Wikipedia sandbox. How do I prevent the extra space from displaying? Nick Levinson (talk) 17:05, 16 August 2013 (UTC)

Only the second space comes from User:Nick Levinson/Subscription or libraries. The first space is in User:Nick Levinson/sandbox, in the code Display: {{User: If you remove either one, only one space will be displayed. --Redrose64 (talk) 17:41, 16 August 2013 (UTC)
Oops. That wasn't quite it because I erred above in not pointing to a more specific example in a large sandbox, but even where I had typical antecedent text (as with "Oblast" in the sandbox) I spaced before the template thus causing the error you found. So I'll add to documentation that no space should precede the template. Thanks for figuring out what I should have figured out all by myself. Nick Levinson (talk) 18:56, 17 August 2013 (UTC)

trouble viewing messages in Special:AbuseLog

Tracked in Phabricator
Task T54977

An administrator mentioned to me [62] something he did with edit filter 575, and I wanted to look at the log messages from it. This link correctly shows me the messages from filter 550. I changed "550" to "575" in the URL: [63]. The changed URL shows me a jumble of messages from various edit filters. —rybec 17:37, 17 August 2013 (UTC)

I see only messages from 575 filter. Ruslik_Zero 18:06, 17 August 2013 (UTC)
Same here - 575 only. --Redrose64 (talk) 18:17, 17 August 2013 (UTC)
Filter 575 is hidden from public view. Admins like Ruslik, Redrose and I see messages from filter 575 there. Others don't. Maybe the idea is that a determined vandal could guess how to circumvent a hidden filter by comparing a list of edits that triggered it. PrimeHunter (talk) 18:31, 17 August 2013 (UTC)
It appears non-admins see the same list of all filter messages as when the Filter ID field is blank. This seems confusing. PrimeHunter (talk) 18:38, 17 August 2013 (UTC)
Yes, it is definitely confusing, especially as the software gives no indication of an error. Seems Bugzilla worthy. Theopolisme (talk) 19:29, 17 August 2013 (UTC)
Administrative rights aren't in the same package as filter editing and viewing — that's the Edit filter manager right. Edit filter managers who aren't admins can see private filters, while admins who aren't edit filters can't see them. That being said, there are very few EFMs who aren't admins, while admins can give themselves the right. Nyttend (talk) 00:52, 18 August 2013 (UTC)
Thanks, everyone. bugzilla:52977 —rybec 16:57, 18 August 2013 (UTC)

Current time lagged

A few mins ago on Time in Cambodia (before I purged the page), the page reported "Now is 10:13:09 in Cambodia (03:13 in UTC)", which was about 45 mins out of sync.

Time in Indonesia is currently saying "Now:11:32", which is 30 mins out of sync.

Im guessing this 'the time is now ....' data exists in other similarly titled article, but it isnt in Thailand, Singapore and Malaysia.

Is this a known problem? If it has been happening frequently, perhaps we need to remove unnecessary current time info from articles. John Vandenberg (chat) 04:07, 18 August 2013 (UTC)

A purge to each article "bumps" the times to their correct values; this is just the job queue being... a job queue. (I'm not really clear as to why this information is included in articles, by the way...wasn't that what timeanddate.com was for? ;) ) Theopolisme (talk) 04:23, 18 August 2013 (UTC)
It's not a job queue issue. The article uses the {{CURRENTHOUR}} {{CURRENTMINUTE}} {{CURRENTSECOND}} {{CURRENTTIME}} variables which are not updated in real time, but only when a page is edited or purged. It would seriously overload the servers to update in real time those pages which use these variables, which is why we have bots like Joe's Null Bot (talk · contribs) for those cases where knowing the current date and time is critical (for example, certain types of deletion processes require a certain time to elapse between nomination and delete). --Redrose64 (talk) 08:14, 18 August 2013 (UTC)
If we try to show current time in articles then we need to make a purge link, for example with {{Time}}. By the way, Time in Cambodia currently uses naive code which will display the time as 07:00 to 31:00. PrimeHunter (talk) 10:28, 18 August 2013 (UTC)
That's easily fixed. --Redrose64 (talk) 11:44, 18 August 2013 (UTC)
IMO, rather than having these "purge" links it would be better to replace these not-so-current times with some JS (in MediaWiki:common.js or a default-enabled gadget) that could do it more correctly, and omit the not-really-current time entirely for non-JS pageviews. Maybe I'll try to throw something together later. Anomie⚔ 12:14, 18 August 2013 (UTC)
IMO, the right thing to do is not to replace it with some JS, but rather to completely remove this silliness, and add to WP:NOT one more line: "wikipedia is not a clock, nor a world clock. קיפודנחש (aka kipod) (talk) 12:37, 18 August 2013 (UTC)
I'm totally with kipod on that one. —TheDJ (talk • contribs) 13:31, 18 August 2013 (UTC)
Ditto.--SPhilbrick(Talk) 19:14, 18 August 2013 (UTC)
Well, I don't see the point in having an article on some country state that "the current time there is ...." On the other hand: in that times on WP are reported as UTC, and an editor can reasonably want to be aware of current UTC time, but might not have his user-side time zone set correctly, it does seem reasonable to have some place for checking current UTC time. Is that available anywhere? ~ J. Johnson (JJ) (talk) 21:08, 18 August 2013 (UTC)
Preferences → Gadgets → (S) Add a clock to the personal toolbar that displays the current time in UTC and provides a link to purge the current page (documentation) --Redrose64 (talk) 21:25, 18 August 2013 (UTC)

visited/unvisited pages

My personal general take on that aside and talking plainly on a technical issue that seems not to work as it should and taking the latest page I checked as an example, no matter if I check the most recent page or get the latest diff [only one revision since my last visit], it still shows up in green as "updated since my last visit". I'm using now chrome b/c IE is not supported anymore and still get "shit". This is not a one time issue so please fix it w/o excuses like telling me it's my fault. I got that crap before and it never was the case as told. Thanks, TMCk (talk) 01:21, 17 August 2013 (UTC)Yeah, I'm pissed b/c I've lost my patience after one screw-up after another. Sorry, but that's the way it is.TMCk (talk) 01:21, 17 August 2013 (UTC)

The "usual suspects"? Taken it personal when there is a problem and therefore critique?I really don't expect much nor am I asking for such.TMCk (talk) 01:49, 19 August 2013 (UTC)
The same system is used for email notifications and your talkpage notice, so it can't be totally crazy.... I couldn't find anything obvious while glossing over the code. The only thing i wonder about if it is perhaps a page vs talkpage issue. The source is a bit difficult to decode when it comes to that part of the logic. —TheDJ (talk • contribs) 23:13, 19 August 2013 (UTC)
BTW, the most common reasons for this problem is that people accidentally visit a page not-logged in on http (don't notice this) and then go on to read their watchlist logged in on https. The system can't know what you read when you weren't logged in when you read. —TheDJ (talk • contribs) 23:16, 19 August 2013 (UTC)
Nope, I clearly was logged in. And I didn't check if the same happens with talk pages but it sure does happen with articles as my example makes clear.TMCk (talk) 01:27, 20 August 2013 (UTC)

Search cache updating frequency

I was answering an OTRS ticket from a person who, for privacy reasons, removed unnecessary references to his own name from an article about an associate of his. I have verified that his name is completely expunged from the article, and I purged the cache for that page.

However, when his name is entered in the Search box, the article still appears in the search result. That was the reason for his complaint to OTRS.

How long does it take for the search cache to reflect this change? ~Amatulić (talk) 13:58, 18 August 2013 (UTC)

Normally once a day - very early in the morning UTC, or late evening American time. --Redrose64 (talk) 14:12, 18 August 2013 (UTC)
I've seen problems with Commons' search cache sometimes taking two days or so recently. Whatamidoing (WMF) (talk) 16:29, 19 August 2013 (UTC)

Edit issues

I bring these here because they just started a few days ago, and I cannot relate them particularly to VE, although maybe they are:

  • Even though I have the option checked in Prefs, I can no longer right click on a section header to edit. I had to go back to Prefs and enable links.
  • None of the symbol links on the edit page below the edit screen are working. They are visible as text, but there are no links.
  • The WP search field no longer shows a dropdown box that changes with each letter I type to yield possible clickable options. Instead, this has changed to a dropdown box only when the options are pages I've searched for and have clicked on in the past.
  • Although I still have the option checked in Prefs, I no longer see reference tooltips when I mouseover inline citations.

I checked my scripts and they're all okay; javascript is still enabled. I completely disabled everything Visual Editor, but the problems are still there. I use Win8 and IE10. Please leave cracks about IE at home. Any enlightenments? – Paine Ellsworth CLIMAX! 15:29, 18 August 2013 (UTC)

This may be related to recent troubles with HotCat. Have you tried a WP:BYPASS (to persuade your browser to forget all old versions of Wikipedia's scripts)? --Redrose64 (talk) 16:09, 18 August 2013 (UTC)
Hi, Redrose64! I purged it all with no joy, but as usual your words led me to check something I'd almost forgotten about. For a long time I've had WP on "compatiblilty view". I just turned it off and it's all back to normal. Something's been fixed. – Paine Ellsworth CLIMAX! 16:41, 18 August 2013 (UTC)
Did this, by any chance, start on Thursday afternoon, California time? I believe that's when a Mediawiki (not VisualEditor: that was delayed here until tomorrow) update was made. It's possible that something was changed that made compatibility view become incompatible. Whatamidoing (WMF) (talk) 16:33, 19 August 2013 (UTC)

mashing 2 lines together for unintended confusion

The layout of a box with a message, probably a template, sometimes inserts one text string into another, likely confusing some less geeky readers. Here's one as of a few minutes ago: "To list a page in this category, do not edit this category page. Instead, edit the page you want to list, adding [[Category:X2]] at the Hide this message bottom. See FAQ/Categorization for details." I can't reach this box and don't know how to fix it if I could. It probably afflicts a lot of different boxes. I don't know if this varies according to the display platform; I'm seeing it on a laptop, not on a cell phone. But simply changing the browser's width changed the display to "To list a page in this category, do not edit this category page. Instead, edit Hide this message the page you want to list, adding [[Category:X2]] at the bottom. See FAQ/Categorization for details." (Here, I added nowiki tags into each quotation.) The variation may create a challenge in editing a template. Nick Levinson (talk) 18:01, 18 August 2013 (UTC)

In my browser the "Hide this message" is in a smaller font and linked to Template:Editnotices/Namespace/Category, a page which instructs how to add a code to your .css page to hide that message from your view. Perhaps in some browsers the font is larger and more confusing? – Paine Ellsworth CLIMAX! 18:26, 18 August 2013 (UTC)
We could put a faint border around the "Hide this message" link (see example above) to make it clearer that the text is separate from the link. --Redrose64 (talk) 18:53, 18 August 2013 (UTC)
That would help; and I don't know that it needs to be very faint. Maybe a little stronger border?
My browser is Firefox 9.0.1 and the font sizes appear to be the same. I'm not concerned with hiding it from view and I'm used to the mashing, but I think it would confuse exactly the people who don't realize they have an option to hide it.
I like the idea of the redesign.
Nick Levinson (talk) 21:31, 18 August 2013 (UTC)
Hmm, if your browser doesn't show any difference in font size, that suggests that it doesn't recognise font-size:xx-small; - which is odd, because that's one of the original styles from CSS 1.0, which predates HTML 4.0 by about three years and therefore also predates all versions of Firefox by at least five years. Anyway, the border doesn't have to be faint - plenty of other styles are available: Hide Hide Hide Hide Hide Hide Hide Hide Hide Hide Hide Hide --Redrose64 (talk) 22:22, 18 August 2013 (UTC)
I like the border; would it be possible to make the margin on the top and right consistent? Right now there is more space on the right than on the top, which looks odd. Theopolisme (talk) 00:29, 19 August 2013 (UTC)
I sugest margin-left of 5em. Added it to the example. —TheDJ (talk • contribs) 08:47, 19 August 2013 (UTC)
BTW, I find this whole 'hide this message' thing a terrible approach. It seems highly oriented at active editors and inserted without consideration for casual editors. I'd vote for removing it all together. —TheDJ (talk • contribs) 09:01, 19 August 2013 (UTC)

Oversized pictures in mobile view

This has been raised in Wikipedia talk:Route diagram template#Oversized icons in mobile view.
Some randomly selected icons were blown up to double size, at WP:RDT

I noticed, around a week earlier, that in mobile view, pictures can be enlarged to twice the size when using displays with high device pixel ratio, like a retina display. For example, in Wikipedia:Today's featured article/August 19, 2013, the photo might get enlarged after the higher version is loaded. I suspect this is due to the following CSS rules: 

img.tex, .image img, .thumb img {
max-width:100% !important;
width: auto !important;
height: auto !important
}

It seems that, after a higher resolution photo is loaded, the browser would try to resize that photo to its native size. However, I believe this is against the idea of providing a higher resolution photo to those mobile devices with 2x device pixels.

This might not be a serious problem for photos on TFA, but for the WP:Route diagram templates, this behaviour is undesirable and there is no way to override this behaviour, unless one remove file links (and icons would not be selected by .image img).

I saw this problem on an iOS 6.1.3 device with Retina display, in both Safari and Chrome. Can someone familiar with mobile view take a look on this? — Peterwhy 21:08, 18 August 2013 (UTC)

Ping Jon and Brion.--Jorm (WMF) (talk) 22:35, 18 August 2013 (UTC)
Try pinging Jon properly. :-) Graham87 03:32, 19 August 2013 (UTC)
Sorry! Ping User:jdlrobson in future for quicker replies. There's various problems at play here - namely 36936, 49440 and 35704. Jon (WMF) (talk) 23:42, 27 August 2013 (UTC)

It is more likely to be the use of srcset which allows the MediaWiki software to render alternate images based on the device capabilities. This was added a few revs ago. See HTML Living Standard. --  Gadget850 talk 23:15, 18 August 2013 (UTC)

Curiously, the W3C don't describe the srcset= attribute - it's not mentioned at all in the HTML 5.0 Candidate Recommendation 6 August 2013, but it is mentioned (twice each) in the HTML 5.1 Working Draft 28 May 2013 and Nightly Editor's Draft - but is not actually described there.
Don't rely on this attribute being retained: I have noticed before that attributes or elements are added and then later dropped, such as the <command> element which was listed in the CR of 17 December 2012 but not that of 6 August 2013. An attribute or element should only be considered (semi-)permanent once the W3C doc has reached W3C Recommendation stage. --Redrose64 (talk) 07:38, 19 August 2013 (UTC)
It's in an html5 extension with draft status. —TheDJ (talk • contribs) 08:41, 19 August 2013 (UTC)
FYI... srcset is not currently supported by Safari. It was added just last week to webkit's code. You can download a nightly build to try it out. Bgwhite (talk) 09:06, 19 August 2013 (UTC)
General note: Browser and hardware information is always welcome to help reproducing it. For example I cannot reproduce this problem on a Nokia N950. --AKlapper (WMF) (talk) 09:11, 19 August 2013 (UTC)
"iOS 6.1.3 device with Retina display, in both Safari and Chrome." he did :D —TheDJ (talk • contribs) 09:23, 19 August 2013 (UTC)
Oops, I'm sorry. My reading skills on a Monday morning obviously aren't the best. :-/ --AKlapper (WMF) (talk) 10:27, 19 August 2013 (UTC)

Debugging the problem

Tracked in Phabricator
Task T55026

It seems to me that this issue only affects PNGs of SVG images. Perhaps there is a bug in the polyfill script. mediawiki:HiDPI_display_support. —TheDJ (talk • contribs) 09:50, 19 August 2013 (UTC)

mw:HiDPI display support. — Peterwhy 10:12, 19 August 2013 (UTC)

Confirming my earlier belief, this problem seems to be caused by the quoted CSS rules together with a higher device pixel display. I encountered the same enlarging problem in my Firefox after setting device pixel ratio to 2.0x and 1.5x respectively (Config here), and the problematic images shrank back after disabling auto image width or auto image height. My guess is that these CSS rules overwrite the width and height set by img tag. — Peterwhy 10:00, 19 August 2013 (UTC)

Another hint is, if you check the mobile Main Page [64] (as of now) using a high device-pixel ratio display, the image in TFA (battleship) gets enlarged but the image ITN (sports ground) does not. I guess this is because the first image has a link to its own file page, but the second image does not. Instead, the second image has a link to the file page of its uncropped version. This keeps the second image unselected by .image img. — Peterwhy 10:09, 19 August 2013 (UTC)
(e/c) Actually, I was mistaken. It seems that the problem is twofold
  1. The "img.tex, .image img, .thumb img" is conflicting with the polyfill requirement of a fixed width and height.
  2. Some icon templates seem to use a different transclusion logic, where the image is not linked. This avoids them falling into this "img.tex, .image img, .thumb img", but causes a cluttered display of the assembled bsicon template.
Reported the problem —TheDJ (talk • contribs) 10:24, 19 August 2013 (UTC)
The second problem can easily be solved, and modifications to de-link all icons has already been coded, only waiting to be pushed from sandboxes. And so, the example in Bugzilla might get outdated soon. — Peterwhy 11:12, 19 August 2013 (UTC)
I hope you've made sure all the icons being delinked are public domain, CC0, or another license that doesn't require attribution or notice of the license on each use? Anomie⚔ 11:27, 19 August 2013 (UTC)
No, although in my opinion most icons should be in {{PD-shape}}. And there certainly are some really simple shapes that were originally marked CC (e.g.   (STRq)). And there can't be many mechanisms that prevent people from adding icons requiring attributes afterwards. This is one of the obstacles that prevented this to be rolled out, since April.
More discussions: Wikipedia talk:Route diagram template/Archive 7#Route maps 3x faster by BS-overlap update but lack pictogram links. — Peterwhy 12:20, 19 August 2013 (UTC)
The linking of icons in the WP:RDT system was already contrary to guidelines, in that it is possible to overlay several icons on top of each other - but only the topmost icon would be linked, even if the top one was PD but a lower one was CC-BY-SA. --Redrose64 (talk) 18:17, 19 August 2013 (UTC)
Alternatively, keep formatting images like [[File:placeholder.png|Placeholder|20px|link=File:placeholder.png]]. Quite a dumb way though. — Peterwhy 13:27, 19 August 2013 (UTC)

CSS on mobile site

Meta: I often encounter issues with article display (some but not all CSS related) in mobile view, but it's not clear where to raise them. There is a mailing list, and bugzilla, but there should really be an en.WP page as a first and central location for such discussions. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:37, 19 August 2013 (UTC)

@Andy, this is because the mobile view ignores and overwrites most of the inline CSS. This is part of the mobile teams efforts to design a more responsive website. They are even pondering disallowing all inline CSS at some point in the future. In that scheme Templates would likely have their own css block/page, and all styling should be done using classes. It's not decided yet, but the mobile platform features as a testing ground for some of those ideas. They don't really care about properly displaying templates like these that use elaborate CSS hacks. They want to find 'better' ways. —TheDJ (talk • contribs) 09:50, 19 August 2013 (UTC)
I understand this is the future styling way; repeating inline style definitions for hundreds of times (even with the use of templates) is bad. I agree this would be convenient for the mass "content editors", who might not care about the exact presentation in different views. But for "template editors", this poses a headache to make things work in mobile view. Either mobile users are ignored (hence the notice box on top of WP:Route diagram template), or extra inline styles are added to overwrite what mobile teams want, sometimes even using !important to overwrite their !important. I know that is bad, and inline !important means no custom CSS can overwrites it; but what the project requests are just some simple borderless tables floating in the center. Unless there are some simple, well-accessible and secure way to define a CSS block for individual template series, or some way to opt-out the general styles, I believe such glitches will still occur. Or, meanwhile this "edit war" will still continue. — Peterwhy 10:58, 19 August 2013 (UTC)
(ec) I do hope they 'find' it before they implement it. Killing all inline CSS will kill the majority of all templates. Is there a bug requesting per-page-CSS? Without that, mobile is doomed, because I doubt editors are prepared to tailor for mobile view if it means that the only way to do so it by severely restricting desktop view. — Edokter (talk) — 11:03, 19 August 2013 (UTC)
That would be bugzilla:35704. Again, it's a long term goal that is under consideration. It wouldn't be realistic right now. —TheDJ (talk • contribs) 11:43, 19 August 2013 (UTC)
I'm not talking about only inline styles; but my point was about the need for a clearly signposted, on-wiki place to discuss such issues; rather than a desire to do so here. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:47, 19 August 2013 (UTC)

Template:Category TOC not clearing left

I was looking at this category page and the Category TOC template is floating to the right of the Template:Category class, instead of below it. I looked at the page in 3 different browsers, IE10, Mozilla 23.0, and Chrome 28.0.1500.95 m and it is doing the same thing. What's up? --Funandtrvl (talk) 17:54, 19 August 2013 (UTC)

The layout of ToCs has changed recently. I corrected most of the 'custom' ones that we have here on en.wp, but forgot about the small detail of clearing floating content with these custom ones. Will fix. —TheDJ (talk • contribs) 21:06, 19 August 2013 (UTC)
I strongly suspect that this edit may be relevant. --Redrose64 (talk) 21:25, 19 August 2013 (UTC)
h2 might do automatic clearing. Would explain why it's only now visible. Still, the place to fix this was on the right floated div. —TheDJ (talk • contribs) 22:21, 19 August 2013 (UTC)
Actually, this is an even more specific problem. Here, the new toc is preceded by a Table, and a table behaves like an inline-block itself... Hmm. Gonna have to sleep on this one, that's a difficult issue. —TheDJ (talk • contribs) 22:25, 19 August 2013 (UTC)
Thank you for looking into it, I wish I knew more about programming so that I could help you out! --Funandtrvl (talk) 23:08, 19 August 2013 (UTC)

Wikipedia:Wikipedia_Signpost/2013-08-21/Technology_report

Hey, all! I was wondering if I could get a few eyes on this, to make sure my explanations of the new features are clear, and to check I haven't misunderstood anything. I'm afraid Gerrit, Bugzilla, and the Tech Report are all pretty bad at giving context for a lot of things, so I've had to do a lot of research to try and get things right.

It's my first time doing the tech report, so, well, wouldn't mind an expert review. Adam Cuerden (talk) 18:51, 19 August 2013 (UTC)

Completed article in user space

Hi,

I have an article I've completed in my sandbox and I want to publish it. How do I do that? — Preceding unsigned comment added by Eirefrance (talk • contribs) 19:04, 19 August 2013 (UTC)

You would move the page into article space. See also WP:YFA. --Redrose64 (talk) 21:28, 19 August 2013 (UTC)

Placement of images

I'm trying to figure out how to add another image to a specific spot on the Leavenworth, Washington, page. I want it to go below the climate table and to left of the climate chart. While editing, I placed the code for this photo between the {{Weather box}} and the {{Climate chart}}, but a preview of the reading interface wasn't laid out how I wanted. Any help would be much appreciated. Jsayre64 (talk) 20:38, 19 August 2013 (UTC)

Bear in mind that +/- half our readers view the mobile version of the site, and not everyone has the same browser, screen-size, window-size, image preferences and text-size settings as you. Where you use the image isn't where other people will see it. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:33, 19 August 2013 (UTC)
(edit conflict) This edit should do it. You may like to adjust the caption. I think you should also make sure that the dates in the climate chart don't fall foul of WP:DATESNO, the bit about "do not use year-final numerical date formats (DD/MM/YYYY or MM/DD/YYYY)". --Redrose64 (talk) 21:36, 19 August 2013 (UTC)
Thanks. I know there are many different screen sizes these days; I was just trying to lay it out best for a laptop. Something will always look errant on some screen. I also took care of the dates and caption. Jsayre64 (talk) 04:28, 20 August 2013 (UTC)

Hi, just wanted to spread the word about a change in session cookie names:

Please note that the session cookie name on WMF wikis has changed from wiki_session to wikiSession. That is, for example, enwiki_session to enwikiSession.
This was done in response to a security issue -- we had to find some way to rapidly cause all session IDs to be regenerated. Changing the cookie name was the simplest way to achieve that. More details should become available once we are sure that the security issue is fixed.

Hope this doesn't cause anyone trouble. Sumana Harihareswara, Wikimedia Foundation Engineering Community Manager (talk) 21:09, 19 August 2013 (UTC)

I can't help but imagine this is going to affect a good quantity of tool/bot authors; at least those whose tools do login actions for the purpose of editing. For my tool, this change meant the cookie was mis-parsed, leading to invalid edit tokens being generated, and the rejection of every edit attempt (see Wikipedia_talk:STiki#Errors). I understand the need for the change, but a broad(er)(?) announcement might aid those being affected by the change. I don't know what has currently been done, but my earlier attempts to root out this issue found little documentation change across the API and other sources I use for such news. West.andrew.g (talk) 23:20, 19 August 2013 (UTC)

Special:MIMESearch

This page says, in bold text, "This page is disabled".

It actually works perfectly fine. What's up with that? Adam Cuerden (talk) 21:53, 19 August 2013 (UTC)

This was recently fixed in gerrit:67468. We have locally overridden labels that we need to correct. Taking care of it. —TheDJ (talk • contribs) 22:09, 19 August 2013 (UTC)

updating categories

Is there any way to speed up articles being added to tracking categories? WP says that it could take days to weeks, but based on how slowly a cat I created a month ago is filling up, it looks like it might be months to years, at least for articles that aren't edited. I used to add tracking categories to templates in order to find problems in our articles, and they would fill up in a few hours or at most a couple days, but this time it's been so slow that it's impractical to do this. — kwami (talk) 22:25, 19 August 2013 (UTC)

The job queue, which handles this, was changed a few weeks ago and since then, template mods which alter categorisation have, as you say, taken weeks to go through. This template mod, for example, took at least three weeks to shake out all relevant pages. --Redrose64 (talk) 23:36, 19 August 2013 (UTC)
Well, that explains it. But after 3 weeks, a mod of the language infobox was only maybe 10% categorized. Is this change going to be relatively permanent? — kwami (talk) 02:29, 20 August 2013 (UTC)
Wow, another cat triggered by the same template shows 1,300 articles in less than a week, so maybe there was s.t. odd about how the other one was coded. — kwami (talk) 08:52, 20 August 2013 (UTC)

Article in sandbox

I have an article completed in my sandbox that I would like to publish. I can't figure out to do that, however, and I can't find any guidance in the help link. Can someone help me out?

Thanks. — Preceding unsigned comment added by Eirefrance (talk • contribs) 13:19, 20 August 2013 (UTC)

See Wikipedia:Moving a page. If you have problems, post a message on my talk page, and I'll do it for you. AndyTheGrump (talk) 13:29, 20 August 2013 (UTC)
Hello Eirefrance. One could also simply copy and paste the content into Palmetto Education Association, I would imagine. Thanks for your contributions! Biosthmors (talk) 13:30, 20 August 2013 (UTC)
Please see also the reply I left above. --Redrose64 (talk) 15:27, 20 August 2013 (UTC)

Need help with "ifexist"

I asked this earlier at Wikipedia:Help_desk/Archives/2013_June_18#Need_help_with_.22ifexist.22

Hello, I'm asking this question here, because I didn't get any answer on fi-wiki, and I guess that here is more users who knows about this kind of things.

So, we have a template fi:Malline:GrandSlamKaaviot which is the same as Template:Infobox Tennis Grand Slam events. Problem with the fi-wiki template is that we have to make always redirect pages to get this work.

This is how it's in en-wiki:
{{ #ifexist: {{{1}}} {{{2}}} – Men's Singles |[[{{{1}}} {{{2}}} – Men's Singles|men]] | ''men'' }}
This is how it's in fi-wiki:
{{ #ifexist: {{{1}}} {{{2}}} – Miesten kaksinpeli |[[{{{1}}} {{{2}}} – Miesten kaksinpeli|miehet]] | ''miehet'' }}

But in fi-wiki we have articles like "Miesten kaksinpeli Australian avoimessa tennisturnauksessa 2013" so we have to make a redirect page from Australian avoin tennisturnaus 2013 – Miesten kaksinpeli to the link above to get this link showing in the template.

So, now the function {{ #ifexist: {{{1}}} {{{2}}} – Miesten kaksinpeli |[[{{{1}}} {{{2}}} – Miesten kaksinpeli|miehet]] | ''miehet'' }} should someway to get print the following way: {{ #ifexist: Miesten kaksinpeli [[here should be some function which uses one of the following lines (I think so):

  • Australian avoimessa tennisturnauksessa
  • Ranskan avoimessa tennisturnauksessa
  • Wimbledonin tennisturnauksessa
  • Yhdysvaltain avoimessa tennisturnauksessa {{{2}}}|miehet]] | ''miehet'' }}

Thanks! --Stryn (talk) 18:55, 20 August 2013 (UTC)

The problem isn't ifexist but differences between English and Finnish. In English the tournament is 2013 Australian Open and the Men's Singles event is 2013 Australian Open – Men's Singles. Both say "Australian Open". I don't know Finnish but it appears to use different words where English uses the same words. 2013 Australian Open is fi:Australian avoin tennisturnaus 2013, while 2013 Australian Open – Men's Singles is fi:Miesten kaksinpeli Australian avoimessa tennisturnauksessa 2013. So the stand-alone tournament name is "Australian avoin tennisturnaus" while the tournament name part of the event says "Australian avoimessa tennisturnauksessa". Something similar for the three other Grand Slam tournaments. That name conversion must be coded somewhere. I suggest the main template fi:Malline:GrandSlamKaaviot makes the conversion and calls a core subtemplate fi:Malline:GrandSlamKaaviot/core with both names plus all the other parameters. The core then does all the other work and places the parameters in the right Finnish order (not the same order as English). For example, if the converted name is passed in {{{x}}} then
{{ #ifexist: {{{1}}} {{{2}}} – Miesten kaksinpeli |[[{{{1}}} {{{2}}} – Miesten kaksinpeli|miehet]] | ''miehet'' }}
should become
{{ #ifexist: Miesten kaksinpeli {{{x}}} {{{2}}} |[[Miesten kaksinpeli {{{x}}} {{{2}}}|miehet]] | ''miehet'' }}
as far as I can tell. If this sounds meaningful but you don't know how to code the whole thing then I can try although it's a little tricky without knowing the language. Here is a way to make the name conversion in the main template if I got the Finnish right:
| x = {{#switch: {{{1}}} | Australian avoin tennisturnaus = Australian avoimessa tennisturnauksessa | Ranskan avoin tennisturnaus = Ranskan avoimessa tennisturnauksessa | Wimbledonin tennisturnaus = Wimbledonin tennisturnauksessa | Yhdysvaltain avoin tennisturnaus = Yhdysvaltain avoimessa tennisturnauksessa }}
PrimeHunter (talk) 20:45, 20 August 2013 (UTC)

List of categories with over 200 articles

Hi, is there any tool or other easy way to get list of all categories where is over 200 articles? I'm not asking anyone to do this here, but in fi-wiki we have a request to put {{CategoryTOC}} in such categories. Thanks. --Stryn (talk) 19:00, 20 August 2013 (UTC)

Infobox in opera mini

Tracked in Phabricator
Task T38936

Hi.

I sometimes use a nokia s40 phone with opera mini browser to read wikipedia (view only, not edit). In any article containing an infobox, I find the problem that the infobox data (i.e the right column in the table) gets cut (i.e its not visible on screen) due to the infobox width being greater than the screen width. This happens with the images in the infobox too, but not with article text (which renders fine with text width equal to screen width).

I have just tested and can see the problems at the articles Meerut (a place) and Amitabh Bachchan (a person), so the problem is not limited to a particular type of infobox.

Now the question is, is this a problem with the {{Infobox}} template or with wikimedia mobile (and can anyone else confirm this)?

NOTE: The phone used does not have an accelerometer, i.e no exchanging screen width with screen height.

Thanks.--Siddhartha Ghai (talk) 21:44, 20 August 2013 (UTC)

This is a well known problem of the mobile site, and not one that can be easily solved. It is a very complicated problem, simply because much of the Wikipedia content was never designed to function on such small screens. It is being tracked as bugzilla:36936. —TheDJ (talk • contribs) 22:08, 20 August 2013 (UTC)

Edit count

Being completely obsessive in too many ways, i keep a daily count of how many edits i have done. It has always been in step with X!'s counter on Toolserver, until today. I know Toolserver's going away, but has something happened to it that it managed not to count the edits i made two days ago? It's about forty shy of mine actual total, both total total and for this month. A quirk; not really important, i suppose, but an anomaly, all the same. Cheers, LindsayHello 06:36, 14 August 2013 (UTC)

I believe toolserver uses a replication (copy) of the main database, it might just be that they have been slow updating the copy.--Salix (talk): 06:56, 14 August 2013 (UTC)
Mine's 144 too low. There haven't been any days recently where I've made 144 edits between 00:00 and 23:59 (UTC), so more than one day has been lost. --Redrose64 (talk) 19:39, 14 August 2013 (UTC)
Thanks, Salix; usually when there is a replication lag the tool shows it, and there hasn't been any showing for the past couple of days, that's why i assumed there might be something else. And, Redrose, it's good to know that i'm clearly not the only person tracking daily. I calculate two days' worth lost, in my case. Cheers, LindsayHello 02:08, 15 August 2013 (UTC)
I've determined that the missing edits are primarily from 15:00 (UTC) on 10 August to 19:00 on 11 August (UTC) but there are others missing from outside this range, possibly as broad as 21:00 (UTC) 9 August to 06:00 (UTC) 12 August. I can't determine exact limits. --Redrose64 (talk) 11:25, 21 August 2013 (UTC)
  • I just noticed another issue today, not sure how long it's been going on. But when I go to that same edit counter tool by X!, the monthly edit numbers can no longer be expanded to show the breakdown by page space. I have my user opt-in file that I thought was supposed to facilitate that process, so something appears to have stopped functioning. Any information? --Tryptofish (talk) 20:04, 16 August 2013 (UTC)
If you mean hovering over the monthly number, Tryptofish, that seems to be working today ~ it's showing a breakdown in a little floating box, right? Perhaps this behaviour is part and parcel of Toolserver going away? Gradually. Cheers, LindsayHello 18:46, 19 August 2013 (UTC)
Yes, that's what I meant. I just checked again, and it's not working for me. I'm traveling recently and using someone else's computer, which apparently is missing something in the software. When I get back to my usual computer in a couple of days, I'll check again. Thanks. --Tryptofish (talk) 18:55, 19 August 2013 (UTC)
  • I'm now back on my "usual" computer. I'm still seeing the same issue. When I go to the Edit Counter tool, and go to the part under the header "Month counts", I see a list of year-month-number values in plain text, but when I hover the cursor over them, or try to click on them, nothing happens. I don't get that floating box or any other further information, even though I used to a couple of weeks ago, and I take it that it works currently for LindsayH. I'm using the current version of Mozilla Firefox (v 23.0.1). Any help? --Tryptofish (talk) 22:58, 21 August 2013 (UTC)

Recreation of renamed accounts via cross-wiki – possible bug?

User Unixgallery was renamed to Vvwang on July 12, but recreated automatically on July 15 and made some edits on July 29. Bug or feature? I don't see why this would be desirable, but correct me if I'm wrong. Ginsuloft (talk) 15:27, 18 August 2013 (UTC)

Since global account Unixgallery still exists, the user can login using it. When he goes to any page of enwiki, the local account is created automatically. Ruslik_Zero 15:58, 18 August 2013 (UTC)
Thanks, but you explained the "how" part, which I was already aware of, when my question was more "why". Is this a desirable effect, when the reason the user was renamed in the first place was because his username was promotional (and reported to UAA)? I mean, why (not how) can the user log in to another language Wikipedia, then log again back in here and continue with the original username? Ginsuloft (talk) 16:34, 18 August 2013 (UTC)
The proper way to prevent a user with a given name from being created, whether automatically or manually, is to list it at Mediawiki:Titleblacklist with the "User:" prefix. The standard renaming process does not do this. Perhaps it should, in cases of promotional or otherwise proscribed usernames. However, this problem will no longer exist once SUL is finalized, so maybe we shouldn't bother trying to solve it. --NYKevin 23:31, 20 August 2013 (UTC)
Ok, thanks. I didn't know about the SUL update; that seems to solve everything. I did know of Mediawiki:Titleblacklist but that seemed like an unnecessary jump through a flaming hoop just to block a spammer. Again, I was blissfully unaware of SUL. Also, probably just another simple thing and I'm an idiot for asking this, but why doesn't your username have a creation date on the list of users? Ginsuloft (talk) 16:47, 21 August 2013 (UTC)
User account creation wasn't logged the way it is now until sometime in 2005 (?). As a result, older accounts don't have a "created" timestamp. Andrew Gray (talk) 17:07, 21 August 2013 (UTC)

Login issue

Moved from Wikipedia talk:Village pump (technical) § Login issue
 – Redrose64 (talk) 21:40, 19 August 2013 (UTC)

Hello.

I seem unable to login in WP. After a seemingly successful login, it still says "Create account" and "Log in" at the top.

Has anything happened, or is this a caching issue?

46.194.141.253 (talk) 17:41, 19 August 2013 (UTC)

Maybe your browser rejects cookies, check that fist and about caching you can try to reload Wikipeidia with Ctrl+F5 in most browsers......
My1 21:08, 19 August 2013 (UTC)
It may actually be logging you in, but caching issues show you the site as if you're logged out. A hard refresh after logging in would fix this. Steven Walling (WMF) • talk 21:36, 19 August 2013 (UTC)
Do you allow cookies from login.wikimedia.org? --AKlapper (WMF) (talk) 11:48, 21 August 2013 (UTC)
Another possibility is that you logged into the HTTP server, but are now accessing a page on the HTTPS server (or vice versa). -- Ypnypn (talk) 17:37, 21 August 2013 (UTC)

Should an account security option be developed?

Moved from WP:Village pump (idea lab) § Should an account security option be developed?
Tracked in Phabricator
Task T55156

A recent RfA has highlighted a community concern that I believe could be alleviated by the technical development of a doable, I would think, security option. The angst surrounds people who are editing from an environment where an IP is shared, exacerbated when other people routinely have access to the computer an admin uses when editing. I believe we should have an option that causes the software to log the user out after a defined period of inactivity; similar to what all online banking accounts I've ever used do as a security norm.

We have an option to remain logged in for an extended period; shouldn't we also have an option to automatically log off as well? How difficult would such an option be to develop? Would anyone considering this idea be willing to help develop a proposal if it is shown to have merit? Thank you for considering this and perhaps helping to develop the idea. :) John Cline (talk) 20:19, 19 August 2013 (UTC)

This seems more like a question for WP:VPT. Ironholds (talk) 23:26, 19 August 2013 (UTC)
I agree as indicated by the move. Thanks Ironholds! :) John Cline (talk) 00:53, 20 August 2013 (UTC)
So you want 'active' serverside expiry of a session after a time that is shorter than the default (I think) 24 minute session expiry ? All assuming people don't press the Remember me button. —TheDJ (talk • contribs) 19:26, 20 August 2013 (UTC)
I am not technically as computer literate as you appear to be, though it sounds as if you have restated my desire correctly. I was not aware that such an option may already be in place, logging an account off as you suggest in perhaps 24 minutes. It may be better if such information was more widely disseminated. I might still suggest an option in preferences that could allow those interested to adjust the time frame of inactivity down to a smaller setting than 24 minutes and I find it surreal to imagine in my tenure on Wikipedia that I've never been logged off by the system or seen a dialog box suggest I am about to be logged off for inactivity. I never use a remember me option as well, and never will. :) John Cline (talk) 20:31, 20 August 2013 (UTC)
Session expiry is not the same as being logged out. If you start to edit a page, and take a long time about it, then when you eventually try to save the edit you will get a message like
Sorry! We could not process your edit due to a loss of session data. Please try again. If it still doesn't work, try logging out and logging back in.
This is an expired session; if you were logged in to begin with, you will still be logged in after that message appears. --Redrose64 (talk) 22:25, 20 August 2013 (UTC)
I have encounter the kind of interruption you just described. Therefor, no, it is not related to my initial comment. I am specifically interested in knowing that the account would log off after measured inactivity, reducing exposure if for example an administrator fell asleep in a college dorm while logged in to his or her account; or any other perceived manner where a breech could result. The RfA I mentioned has taken some oppose !votes because the candidate is unable to inspire confidence that it will not happen and I assign some of that inability to the lack of a mitigating option. :) John Cline (talk) 22:43, 20 August 2013 (UTC)
Although I am not personally in need of such a feature, it seems like a good idea to me. Since Wikipedia already keeps track of the required data in order to log one out after 30 days, It shouldn't be hard to develop an option to let the person choose the time period before logout. However, I have been logged out unexpectedly in the middle of an edit and it can cause problems if you are not expecting it. I often take quite a while to compose a paragraph or to read a long discussion before posting. If the period is too short, it could be a real source of frustration, and if it's not short, it won't have much security impact. It would only be useful if the person could choose the time delay that was personally optimal. —Anne Delong (talk) 14:06, 21 August 2013 (UTC)
I think you have highlighted two valid points. I agree that an option allowing the user to select the duration of inactivity before a log off is triggered would be ideal. To recognize the impact a loss of data might have on a users morale if logged out prior to saving, it seems like it would be great if a special cache was in use to allow the user logging back in, who had been logged out for inactivity, to restore the session as it was upon logging off. Perhaps one who is proficient at this level of programming could comment on the technical difficulties involved; as this is the greatest unknown factor in my ability to draft a proposal. :) John Cline (talk) 14:28, 21 August 2013 (UTC)

I have filed a request for this —TheDJ (talk • contribs) 15:20, 21 August 2013 (UTC)

HTTPS for logged in users on Wednesday August 28th

— Preceding unsigned comment added by Glaisher (talk • contribs) 06:19, 20 August 2013‎ (UTC)

I can't use https on one of my browsers. Will there be an "opt-out" for this? An optimist on the run!   08:24, 21 August 2013 (UTC)
OK, it have been complicated discussions, so i'm not sure if I have this 100% right, but as far as I understand: You will always need to login using secure, but you can disable secure in your preferences for requests that follow you having logged in. Basically, the WMF doesn't want passwords send over non-https lines anymore. There might be some geo holes that will be created in this restriction for countries where https is blocked, but how exactly that works is pending engineering and development today and tomorrow. There likely will also be some follow up steps to better help users from those kinds of regions to secure their account. Basically, if your browser doesn't support HTTPS, you shouldn't use it to login to services anymore (be it Wikipedia or anything else). It was never safe but it's starting to get outright dangerous even for 'normal' users. —TheDJ (talk • contribs) 08:50, 21 August 2013 (UTC)
I'm curious, which one? --Golbez (talk) 17:21, 22 August 2013 (UTC)
As I just updated on the meta page, we've delayed this rollout by one week. The change will now take place on August 28 at 1pm Pacific Time. Please take a look at gadgets or bots you maintain to make sure they'll continue to work; more information at meta. Hope I didn't mess stuff up too much by updating the section header. Sumana Harihareswara, Wikimedia Foundation Engineering Community Manager (talk) 19:02, 21 August 2013 (UTC)
I think the message we're showing as a CentralNotice should be a bit more specific; instead of saying "Technical maintenance will be performed soon", why not "On August 28, Wikimedia will perform changes to make its services more secure. Read more" ViperSnake151  Talk  21:45, 21 August 2013 (UTC)
See the section #Technical maintenance banner. --Glaisher [talk] 17:04, 22 August 2013 (UTC)

HTTPS for users with an account

Greetings. Starting on August 21 (tomorrow), all users with an account will be using HTTPS to access Wikimedia sites. HTTPS brings better security and improves your privacy. More information is available at m:HTTPS.

If HTTPS causes problems for you, tell us on bugzilla, on IRC (in the #wikimedia-operations channel) or on meta. If you can't use the other methods, you can also send an e-mail to https@wikimedia.org.

Greg Grossmeier (via the Global message delivery system). 18:58, 20 August 2013 (UTC) (wrong page? You can fix it.)

Anyone have any idea where this was discussed with users or is this another case of the technical people forcing stuff down our throat without discussion? I see no reason why wikipedia needs https - we're not doing anything that needs security (with the possible exception of checkuser and the like). (I should add that I'm not necessarily against many of these changes, just the way they're being implemented without discussion with users). Dpmuk (talk) 21:36, 20 August 2013 (UTC)
For more information try reading m:HTTPS, as linked above and the official wmf weblog. This is to protect your reading privacy. This has always been at the top of the foundations priorities and the recent revelations about NSA analytics have shown how far our community has been compromised on that front. —TheDJ (talk • contribs) 22:04, 20 August 2013 (UTC)
Why is it that every time the WMF so much as sneezes, the entire WP community jumps down their collective throat? Even without the NSA concerns, HTTPS is still very necessary for anyone on public Wi-Fi, and we all know that typical users aren't knowledgeable enough to manually add the "https:" when needed. --NYKevin 23:45, 20 August 2013 (UTC)
I read m:HTTPS. Personally I don't think that makes the case for why everyone has to use it. It makes the case, and does it well, for it being an option, probably even the default option, but not, in my opinion, for making people use it. But that's not really my point. My point is where has it been discussed. Even if I completely agreed with reasoning I'd still be asking that. So far just about every major rollout has had unintended consequences, many of which could have been avoided if users had been engaged. One such possible example is listed below. I don't think a post to VPT with one weeks notice is how something that may break tools should be announced on Wikipeida - I'm aware it's probably been announced elsewhere but I expect announcing it in those places doesn't even come close to informing everyone that wants to know - I suspect many editors don't even know where these announcements are made. As a further example of the complete lack of communication with users we're now told it's been delayed a week with no reason given, yes it's there if you follow two links, but it's hardly transparent. As I say my concern isn't so much with what's being rolled out but how things are being communicated with the community. Dpmuk (talk) 19:16, 21 August 2013 (UTC)
As I just updated on the meta page, we've delayed this rollout by one week. The change will now take place on August 28 at 1pm Pacific Time. Please take a look at gadgets or bots you maintain to make sure they'll continue to work; more information at meta. Sumana Harihareswara, Wikimedia Foundation Engineering Community Manager (talk) 19:01, 21 August 2013 (UTC)
For the benefit of the rest of the world, that's 20:00 UTC. An optimist on the run!   11:09, 22 August 2013 (UTC)
Alternative: [65]. Darkdadaah (talk) 14:04, 22 August 2013 (UTC)
Retrieved from "https://wiki.riteme.site/w/index.php?title=Wikipedia:Village_pump_(technical)/Archive_115&oldid=1252107069"