Jump to content

Wikipedia:Village pump (technical)

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Scott (talk | contribs) at 00:10, 24 September 2013 (→‎VisualEditor now opt-in only for all users on English Wikipedia: Disgraceful.). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

 Policy Technical Proposals Idea lab WMF Miscellaneous 
Shortcuts
The technical section of the village pump is used to discuss technical issues about Wikipedia. Bugs and feature requests should be made at Bugzilla (see how to report a bug). Bugs with security implications should be reported to security@wikimedia.org or filed under the "Security" product in Bugzilla.

Newcomers to the technical village pump are encouraged to read these guidelines prior to posting here. Questions about MediaWiki in general should be posted at the MediaWiki support desk.


Misplaced tabs when zoomed in

Dear editors: Because of poor eyesight I often view web page text a little larger than usual by using the "Control +" feature in Firefox. I've been doing this successfully with Wikipedia for months. In the last couple of days, though, when I use this key combination the tabs at the top of each article or talk page display correctly for a moment, and then everything after the "Talk" tab shifts down and completely obscures the title of the article, while the first two tabs remain in the correct locations. I think what previously happened instead was that the search box would be shortened or some of the options would appear as dropdowns, but I can't remember exactly. This seems like a bug. —Anne Delong (talk) 12:55, 12 September 2013 (UTC)[reply]

I have Firefox 23.0.1 and use the View/Zoom In option from the menu bar. What I see on the menu selection is that the Zoom In is the equalivant to "Control ++", and I assume that's what you are referring to. I haven't noticed anything new or different. Generally speaking, the page zoom remains permanent from login to login at all Wikipedia articles unless I decide to change it. — Maile (talk) 13:03, 12 September 2013 (UTC)[reply]
I just tried this out, and it does seem that when the right and left tabs meet due to a high zoom level, the right Vector tabs move under the left tabs. I don't have any way of knowing if this was always the case or what may have occurred in the past, though, and I'm not sure how it could be corrected if unintended. equazcion (talk) 13:06, 12 Sep 2013 (UTC)
I don't get this in either Vector or Modern skin, so maybe there is another contributing factor that makes it happen for you and Anne Delong. It seems to me that a year or so ago, I was getting a phenomenon with article title coordinates dropping down into the text, and somebody fixed that. — Maile (talk) 13:16, 12 September 2013 (UTC)[reply]
It has always been this way, ever since Vector was introduced. I'm positive there is a bug ticket for this, but i can't find it right now. —TheDJ (talk • contribs) 13:43, 12 September 2013 (UTC)[reply]
Well, since it seems that it doesn't happen consistently, perhaps I've been doing something differently. I notice that when I rotate my laptop/tablet to portrait mode, I actually have to zoom out substantially before the page tabs look normal. In any case, it's not a problem for me; if I want to see the article title I can always zoom out temporarily; the title text is certainly large enough even when other text is small. I just thought if it was new it should be reported. —Anne Delong (talk) 15:14, 12 September 2013 (UTC)[reply]
It depends a lot on the available space. So if the tabs or something grew by just 1 pixel, that might perhaps be enough to put it over the edge at your preferred zoom level in combination with your specific screen width. —TheDJ (talk • contribs) 17:15, 12 September 2013 (UTC)[reply]
Actually, no it hasn't always been this way. The right-hand tabs used to slide behind the left-hand tabs. They now shift below the other tabs. This changed when Vector was overhauled to use H3 headers instead of H5 for the portlets, which changed a lot of the metrics of the tabs. — Edokter (talk) — 10:49, 15 September 2013 (UTC)[reply]
Yes,I understand about screen real estate; I have written software myself. However, in the past when there wasn't enough space, more sensible things happened, such as moving some items to a pop-down list, making the search box narrower, etc., rather than covering up the title of the article. Anyway, I was not complaining, just pointing out a possible bug. —Anne Delong (talk) 21:38, 12 September 2013 (UTC)[reply]
  • There's a rather elegant feature in Gadgets which shifts a lot of the tabs and sidebar links to a drop-down; it's under Preferences > Gadgets > section Appearance > "Add page and user options to drop-down menus on the toolbar...". It has the unusual quirk of sometimes adding a blank tab, but otherwise is very useful for condensing these and avoiding the two-line header problem. Andrew Gray (talk) 22:09, 13 September 2013 (UTC)[reply]
  • Thanks, I tried that, and it didn't really help, but I like it anyway; also I found something on the same list that helps on talk pages by shrinking the "new section" tab. —Anne Delong (talk) 20:43, 20 September 2013 (UTC)[reply]

@anyone, Anne Delong, and Maile66: I'm trying to learn exactly how editors use the Wikimedia sites, with accessibility tools like screen magnifiers, and zoom settings. If you could reply to the short list of questions at Wikipedia talk:WikiProject Accessibility#Visual impairment - what settings, software, or other tools are used to compensate, that would be immensely appreciated. Also, if you know of anyone else who might have useful input, please help me get the word out? Much thanks. –Quiddity (talk) 19:24, 20 September 2013 (UTC)[reply]

Scrolling past the bottom of the page...

I've never encountered this before but whenever I go to the PRISM (surveillance program) article I am able to scroll past the bottom of the page. I've closed my browser and opened it back up and manually went back to the article and the problem is persistent so it was not a one time deal. I took a screenshot where you can see that I'm at what should be the bottom of the page but the scrollbar on the far right you can see that I can keep on scrolling but nothing is there but white. Anyone have any clue as to what is going on or if this is a bug or something that can be rectified? Thanks, — -dainomite   03:58, 13 September 2013 (UTC)[reply]

  • The current version of the page works fine for me in Firefox for Mac 23.0.1. As always with reports of this sort, it helps to know what web browser you are using. It also helps to tell us which version of the page you were viewing by pasting in a link from the History page, if you know how to do that (right-click or ctrl-click on the date/time stamp in the View History page and choose Copy Link, then paste it the way I did at the beginning of this response). – Jonesey95 (talk) 04:17, 13 September 2013 (UTC)[reply]
    • This is happening for me too on multiple pages, including that one, with Chrome 29.0.1547.65. Other example pages where it happens: Roy Lichtenstein, Carolina Panthers. I already looked at the wikicode for both of those pages, as well as the nav footers used on them; whatever it is, it's not something obvious. Maralia (talk) 04:32, 13 September 2013 (UTC)[reply]
      • It occurs for me also on those same pages you linked Maralia. — -dainomite   04:40, 13 September 2013 (UTC)[reply]
    • (edit conflict) My browser is SRWare Iron, version 27.0.1500.0 (201000). Actually that version history of the article it does it still, scrolling below the end of the article that is. If I have to provide anything else please let me know. thanks, — -dainomite   04:33, 13 September 2013 (UTC)[reply]
      • I think it has something to do with the {{reflist}} template. Removing those from the page eliminates the issue. PS. Tested in Chrome 29, I do experience it on that page, when the reflists are there. equazcion (talk) 04:51, 13 Sep 2013 (UTC)
      • PS. That particular page (PRISM (surveillance program)) has two reflists, and the main one (not the "notes" group) needs to be removed to fix the issue. Also note you can test this by merely previewing. equazcion (talk) 04:54, 13 Sep 2013 (UTC)
      • PPPPS. (or whichever one I'm up to) This seems to occur on every page with a long reflist -- and the longer the list of refs, the more space shows up below the page. It also does not occur when using the plain <references/> tag, but only when using the {{reflist}} template. equazcion (talk) 05:01, 13 Sep 2013 (UTC)
      • Inspecting the <ol class="references"> element in Chrome shows a height of 11656.015625px in the computed styles, which seems to be the reason for the long space. Not sure exactly what the cause of all that extraneous height is yet though. equazcion (talk) 05:22, 13 Sep 2013 (UTC)
  • (edit conflict) I see this in Chromium 29.0.1547.57. It appears that Chrome has a bug in its handling of -webkit-column-width where it is processing the absolute positioning of the 'cite-accessibility-label' elements before applying the actual wrapping of the references list, which means that these elements wind up well off of what would otherwise be the end of the page. These elements appear to have been added in this change to the Cite extension (as an attempt to fix Template:Bug) which was deployed today along with 1.22wmf16.
    @Graham87 or anyone else who knows a11y: is there a sane way to do this rather than having a span with complicated CSS to try to take it out of the page flow? Anomie⚔ 05:38, 13 September 2013 (UTC)[reply]
    • Yes, by using WAI-ARIA labels, but that behaves inconsistently with screen readers and doesn't work with NVDA. I've been in contact with Marius about these accessibility changes; we first tried the ARIA labels until we found the aforementioned problems, which is why CSS was used. As an aside, do any such problems occur with changes to Template:Sfrac, where I used similar techniques? Graham87 06:53, 13 September 2013 (UTC)[reply]
      • If the template gets used in one of the later references on the page and a multi-column reflist is used, probably. That seems rather unlikely though. But does "1/2" read correctly? And display correctly for other browsers? Anomie⚔ 14:17, 13 September 2013 (UTC)[reply]
        • Yes, it reads correctly with screen readers. Graham87 06:52, 14 September 2013 (UTC)[reply]
    • Setting either widht or height (or both) for .cite-accessibility-label to 0px will clear the problem. Using anything else then 0px may cause any render engine to actually render the element, with the above as a result. — Edokter (talk) — 10:06, 14 September 2013 (UTC)[reply]
      • Which also works in both JAWS and NVDA under the latest release versions of IE and FF, according to tests at User:Graham87/sandbox20. However WebAIM cautions against this approach because screen readers are meant to hide that content. Graham87 11:34, 14 September 2013 (UTC)[reply]
        • We should go what works. And WebAIM's method also works. So we are we using something (clip:) that does not work? — Edokter (talk) — 14:30, 14 September 2013 (UTC)[reply]
          • The clip technique usually works perfectly. However, it appears that the WebKit engine used by the Safari browser, as well as its fork Blink used by Chrome and Opera, have a bug where combining it with absolute positioning with column-based layout with very long columns results in miscalculation and rending the invisible hidden labels offscreen. Other browsers don't seem to have this issue. The change linked by Hoo below is a workaround in the Cite extension, you can apply it to common.css here temporarily to get it fixed right now. I don't think the WebKit/Blink bug was filed yet, I'll see to it. Matma Rex talk 14:43, 14 September 2013 (UTC)[reply]
            • Slight corrections: "clip" has nothing to do with it. It's purely a matter of -webkit-column-width/-webkit-column-count plus absolute positioning of something inside. Also note that the issue still occurs with short columns, it's just that on Wikipedia the effect doesn't lengthen things more than the normal post-References content already does. Thanks for filing the WebKit bug, Matma; please link it from here when you do. Anomie⚔ 11:48, 15 September 2013 (UTC)[reply]

The main cause over here seems to be that the English Wikipedia uses multi-column references while I only tested with single column ones. https://gerrit.wikimedia.org/r/84201 should fix this. - Hoo man (talk) 14:10, 14 September 2013 (UTC)[reply]

Thanks for working on this. I'd just noticed the issue and I'd begun investigating. I'm glad someone else beat me to it. :-) --MZMcBride (talk) 15:00, 19 September 2013 (UTC)[reply]

Wikipedia not remembering me and going into secure logon

For some reason, the "remember me" option isn't working. I keep randomly loading Wikipedia to find myself logged out. Sometimes it remembers me, sometimes it doesn't. And I haven't been clearing my cache or deleting cookies or anything. Ten Pound Hammer • (What did I screw up now?) 03:00, 14 September 2013 (UTC)[reply]

  • Yes, as of today, I have to enter my password every time I log on. I have changed no settings; nor changed any software on my PC except for the usual automatic push-down Windows fixes. Also WP is not recalling any of the texts I have used in my edit summaries which I now have to retype from scratch each time. And I still have 'use a secure logon' turned off which we discovered was the problem creating this loss of memory last week. Hmains (talk) 03:23, 14 September 2013 (UTC)[reply]
My browser remembers edit summaries I've used before, even when I have Javascript disabled. I don't think the site itself has such a function. Many browsers have a configuration option for storing "form history". Turning it off would stop your browser from showing previous entries when filling forms (such as the edit summaries). Using private browsing mode would do the same thing. —rybec 03:38, 14 September 2013 (UTC)[reply]
This is what I was previously told for IE and it worked until today: "to auto fill edit summary: "I haven't found a way to get autocomplete in IE at https with the current setup on Wikipedia's side. If http is acceptable to you then you can disable "Always use a secure connection when logged in" at Special:Preferences, log out, close IE, start IE again and log in at http://en.wikipedia.org. PrimeHunter (talk) 16:50, 31 August 2013 (UTC)" Hmains (talk) 05:02, 14 September 2013 (UTC)[reply]
Are all the people who are having problems using IE? Have all of you disabled HTTPS? Whatamidoing (WMF) (talk) 05:44, 14 September 2013 (UTC)[reply]
I am using IE as always; my WP settings is: (not checked) Always use a secure connection when logged in. I have autocomplete (as always) turned on in IE. Hmains (talk) 06:12, 14 September 2013 (UTC)[reply]
And I also see I have been forced into the https://en.wikipedia regardless of the above noted preference setting Hmains (talk) 06:16, 14 September 2013 (UTC)[reply]
I just found that if I once force my address to be http: , then my password is remembered as well as my edit summary previously used list. I will see how long this works until something else gets screwed up. It would be nice if WP were a stable platform. Hmains (talk) 06:23, 14 September 2013 (UTC)[reply]
  • day 2: I invoke WP from my desktop shortcut. The address shows I am in HTTP:. I am not logged in so WP is not remembering me. I go to the logon panel and notice my address is now HTTPS: . I do not enter any information on the logon screen; I simply back out of it to the WP main page. It now shows I am in HTTP: and I am logged in with my suddenly remembered user id and password. No wonder people have a hard time when experiencing/describing this behavior (see above). Hmains (talk) 15:32, 14 September 2013 (UTC)[reply]
Something very similar happens in Firefox 23.0.1 - until recently, WP:SUL worked fine, and I could switch sites and edit immediately. But now, if I am logged in on English Wikipedia, and then go somewhere else (like commons:, meta: or fr:) it often appears that I am not logged in (links upper right are Create account/Log in, not the normal 6+). Clicking "Log in" allows me to log in; but I have found that logging in is not actually necessary: waiting about five seconds and then going for Ctrl+F5 convinces the site that I am, in fact, logged in. --Redrose64 (talk) 15:40, 14 September 2013 (UTC)[reply]
Note that the "am I centrally logged in?" check isn't run for every page view to prevent overloading the servers. It is run once every 24 hours and every time you visit Special:UserLogin; the 24-hour flag should also be being reset on a successful login (note to self: Template:Bug). Normally the JavaScript involved should be reflecting the successful "am I centrally logged in?" check by replacing the #p-personal bar or by changing the page location, but if you have JS disabled in your browser then the auto-login is by necessity silent. If you do have JS enabled and are still seeing no notice of the login, please do check for and report any JS errors. BJorsch (WMF) (talk) 12:25, 15 September 2013 (UTC)[reply]
As for being logged in here on enwiki and then going to frwiki and being not logged in, that in particular shouldn't be happening with SUL. My first suspicion is that you somehow have a bogus cookie that is hiding one of CentralAuth's cookies; can you reproduce it if you clear all cookies and then close and reopen the browser? BJorsch (WMF) (talk) 12:25, 15 September 2013 (UTC)[reply]
This is almost exactly what I described here more than a week ago, and I am continuing to experience the very same, weirdly random problem. It does remember that I'm logged in - but some pages display as though I'm not. As you say, no need to actually "log in" again, I just go to that page and then straight back to whatever article I was looking at. Most of the time that seems to "work", but not always. And yes, I am using IE. Cgingold (talk) 22:43, 14 September 2013 (UTC)[reply]
FWIW, this sounds like a caching bug of some sort (which could be in your browser, in WMF's caches, or in some cache in between you and WMF's servers) rather than an issue with SUL. BJorsch (WMF) (talk) 12:25, 15 September 2013 (UTC)[reply]
  • Whatever it is, this problem has not been fixed and there seems to be no activity by the people responsible for this mess to fix it. Hmains (talk) 02:13, 19 September 2013 (UTC)[reply]
    • Hmains, I'm sorry that you're still having this frustrating problem. BJorsch named above the three different places where this problem may be caused:
      1. your own computer,
      2. the WMF's servers, or
      3. a server in between you and the WMF's servers.
    • Each user is necessarily responsible for cacheing problems that appear in his own browser. Please follow all the steps at WP:BYPASS and let us know if that (hopefully!) solves the problem for you. If the problem is the WMF's caches, then it will likely be fixed relatively soon. If the problem is at a third-party server in between you and the WMF (e.g., on your corporate or university network or your local ISP), then I'm afraid that there is often nothing that either you or we are able to do about it except wait for the third-party server to update its cache. Whatamidoing (WMF) (talk) 18:53, 19 September 2013 (UTC)[reply]

nowrap vs please-wrap-here option?

We know the "nowrap" option. Is there a way to say to the browser: "within this text string, if you have to break, then break here first?" It has a nesting (level of priority) edge. -DePiep (talk) 17:03, 15 September 2013 (UTC)[reply]

<wbr> (see Wikipedia:Line break handling#wbr). — Edokter (talk) — 17:36, 15 September 2013 (UTC)[reply]
<wbr> is a wikicode thing then (not html)? OK with me if it works...
...but the linked example fails over here (Ff atop WinXP). -DePiep (talk) 18:00, 15 September 2013 (UTC)[reply]
(edit conflict) <wbr> is an optional break position, and it is HTML - it was introduced with HTML5. It has the same "priority" as a normal space; the browser will break the line at whichever of these allows the most text to be displayed across the available width, regardless of whether it's at a space or a <wbr>. I am not aware of any technique that will give one position priority over another. --Redrose64 (talk) 18:03, 15 September 2013 (UTC)[reply]
Linked example works for me (FF 23.0.1 on Win7 SP1) DKqwerty 18:13, 15 September 2013 (UTC)[reply]
re Redrose64: HTML it is then. But as described, <wbr> is the same as an &#x20; space. So I cannot control (set preferences for) this kind of linebreaking. Seems like we are entering "stateless" territory, for which I have no passport. -DePiep (talk) 18:56, 15 September 2013 (UTC)[reply]
It's not the same as a space. If you use it within a word, no extra space appears; if you use it between words, you also need a space otherwise the two words are butted together (and when there is an explicit space between words, a <wbr> is pointless). Consider super<wbr>cali<wbr>fragilistic<wbr>expiali<wbr>docious → supercalifragilisticexpialidocious and vary the width of the browser window, to show the wrapping. --Redrose64 (talk) 19:59, 15 September 2013 (UTC)[reply]
I know these effects. It is space & whitespace behaviour. Also, is has Unicode props (does it diff from zero whitespace really?). My question was, can I steer "nowrap" from within its brackets. I am from structured programming, not streamed (PHP) programming. -DePiep (talk) 21:05, 15 September 2013 (UTC)[reply]
If you are asking if <wbr> works inside {{nowrap}}, then no. You can join strings of words with {{nowrap}} with a simple space where you want the opportunity for a break. Otherwise, please provide an example of what you are trying to do. --  Gadget850 talk 22:01, 15 September 2013 (UTC)[reply]
This answers my question. -DePiep (talk) 22:55, 15 September 2013 (UTC)[reply]
(edit conflict) The {{nowrap}} template is wraps the text string in <span class="nowrap">...</span>, and the nowrap class has been set up to apply the CSS styling white-space:nowrap. This causes any <wbr> tags that may be present in the string to be ignored. It's easily tested:
Let's not disrupt the flow of the rest of the page...

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

where I've added a <wbr> after the fifth letter of any word of ten or more letters. There is no word wrapping for me (Firefox 23). --Redrose64 (talk) 22:09, 15 September 2013 (UTC)[reply]
There is, however, word-wrapping on both Chrome and Opera 12. Some of these browsers must be wrong, but I don't think I am in position to tell which ones :) Matma Rex talk 23:14, 15 September 2013 (UTC)[reply]
Hmmm, it also wraps in IE7 and Safari 5.1.7 --Redrose64 (talk) 23:36, 15 September 2013 (UTC)[reply]
  • Try nowrap of word-joined phrases: I have thought about similar problems, for years, to prioritize one break spot over another, and the best solution I have found is to have several nowrap groups, as word-joined text after the likely break spots. For example, use the joiner template, {{j}} for phrases:
  • "wrap among these words but {{j|not in here}} or these {{j|2 words}}, {{j|nor here}} {{j|nor this}} spot"
With multiple word-joined phrases, set by Template:j, then when users display a line with browser TextSize zoom set larger, the related words will "magically" clump together to avoid awkward splits between closely-related words, and help sight-impaired users view the connected phrases. By word-joining the "{{First 3 words}}" of a paragraph then that can ensure enough width to fit longer words afterward and prevent too-short widow/orphan lines in the related text. I think the use of word-joined groups will solve most cases of awkward wrapping, as long as the groups are kept relatively short. We specifically defined template {j}, 3 years ago, as a short name to typeset these word-joined cases. If we controlled the improvements for MediaWiki, I would define "\_" as "&nbsp" in wikitext markup, as in "join\_these\_words" along with setting parameter 1 as "#[1]" or similar to avoid wiggly syntax "{{{1}}}". -Wikid77 21:45, 15 September 2013 (UTC)[reply]
The "separate nowrap strings" construction. Even then, I can not control them. What with breaks between nowrap-1 and nowrap-2 string? -DePiep (talk) 23:00, 15 September 2013 (UTC)[reply]
It is the solution, but in reverse, because not wrapping between 2 words is the same as allowing to wrap either before-or-after them. The words either wrap, or they don't, and there is no 3rd option to consider. Hence, by deciding where to no-wrap the text, then the problem of clever wrapping is solved, but in reverse. Try it in several cases, and it will make more sense. Now, a related problem is the gapping caused by wrapping long words, and the solution is to either reword a long word as 2-3 words or use a word which can be hyphenated to wrap, such as "worldwide" respelled as "world-wide" as a valid option. Those tactics will provide logical wrapping. -Wikid77 07:48, 19 September 2013 (UTC)[reply]
There is also {{wrap}}, which inserts a breaking space inside a {{nowrap}} block. — Edokter (talk) — 18:44, 16 September 2013 (UTC)[reply]

You may be interested in the work-break property. --MZMcBride (talk) 04:47, 22 September 2013 (UTC)[reply]

search failure / glitch / I'm confused

AN/I archive 799 has the phrase Senators Dodd and Lieberman , yet searching for the phrase [1] returns 0 results. (Last edit to 799 was 10 June.) The search query comes from {{Administrators' noticeboard navbox/Search}} NE Ent 11:36, 16 September 2013 (UTC)[reply]

I have noticed before that the search facility doesn't work correctly with archives over a certain size (can't remember if it's 256 KB or 512 KB). The thread in question is towards the end of the archive page, so it might be past the size limit. --Redrose64 (talk) 13:35, 16 September 2013 (UTC)[reply]
I'm understanding that as a per page limit? -- so the instructions for the both should be adjusted for a smaller limit? NE Ent 21:03, 16 September 2013 (UTC)[reply]

The search backend is changing soon on Wikimedia wikis, by the way. There are notes somewhere... mw:CirrusSearch maybe. --MZMcBride (talk) 04:32, 22 September 2013 (UTC)[reply]

Import URL from Wikidata

Tracked in Phabricator
Task T56312

The {{URL}} template doesn't clean up the syntax when importing the URL from Wikidata. See the infobox of Paniqui, Tarlac, for example. The URL should read www.paniqui.gov.ph when using this template, but instead it shows the entire string (http://www.paniqui.gov.ph/). Can this be corrected? BTW, I haven't seen any bots adding links to Wikidata. Is it too premature to import Wikidata? -- P 1 9 9  ✉ 13:19, 16 September 2013 (UTC)[reply]

{{#property:P856}} used on Paniqui, Tarlac returns http&#58;//www.paniqui.gov.ph/ with an encoded colon, while wikidata:Q56457 says http://www.paniqui.gov.ph/ with a normal colon. {{URL}} uses Module:URL which does not have code to handle an encoded colon. I don't know what causes the colon to be encoded. PrimeHunter (talk) 15:14, 16 September 2013 (UTC)[reply]
Thanks for the report. We're looking into it. Needs to be fixed. --Lydia Pintscher (WMDE) (talk) 10:06, 19 September 2013 (UTC)[reply]

Section editing

I'm curious. Why does the editing software no longer permit simultaneous editing of different sections of the same page? For instance, see this edit where I inadvertently removed another editor's comment in another section. This has never been a problem in the past, so why is this occurring now? Parsecboy (talk) 17:00, 16 September 2013 (UTC)[reply]

Something is currently not right with section editing. bugzilla:53446 was recently opened, but it is likely not limited to high-trafficked articles/pages. You can add a comment there or open up a new bug. Killiondude (talk) 21:41, 16 September 2013 (UTC)[reply]
Do you use VisualEditor or the old classic way to edit wikitext manually? --AKlapper (WMF) (talk) 19:30, 17 September 2013 (UTC)[reply]
I don't think that VE is enabled on talk pages. --Redrose64 (talk) 20:02, 17 September 2013 (UTC)[reply]
  • Overwrite of 1-minute edits has been problem for months or years: Several other users have noted similar problems, sometimes imagining the next editor has deliberately deleted their recent comment, where the prior edit was auto-erased when saving the next edit, within 1 minute after the prior edit. I think it is the "age-old" problem of needing to read-lock the database entry (the page) so that, before an edit can be saved, all other pending edits must wait to only re-read the page after the prior edit has been saved (only 1 session could read the prior revision at a time during the SAVE), then do a diff against the latest read-locked page and auto-merge with the latest prior save, as to not auto-merge by both edits reading the same version of 2 revisions prior as being the revision to merge. Again, unless each SAVE does an exclusive (rapid) read+write lock of the page, then 2 quick edits of a page will both try to merge changes into the same old revision, rather than sequentially readlocking to update once (then unlock), so the 2nd edit is forced to read only after the first edit is saved, to ensure updating the next latest revision in sequence, not merge with 2 revisions back. Note that the exclusive read+write lock would only apply to delay edit-save transactions, and article viewing would not be delayed by the read-lock option. The typical test-and-set logic is needed to control a semaphore to ensure how 2 edits within 1 minute must sequentially wait to read the results of the prior edit-save, before merging new changes, as a 3rd revision applied to the 2nd revision. -Wikid77 (talk) 08:30, 19 September 2013 (UTC)[reply]
Thanks for the explanation. I've never noticed a problem with it in the past, and assumed it was VE-related (though I don't use VE). Parsecboy (talk) 20:33, 23 September 2013 (UTC)[reply]

Login issues

  • Just now, I had to try three times to log in. (FF22, cache always cleared). The first time, it went through the usual login process from the Main Page, but then when it went back to the main page from the login page, it wasn't logged in, even after refreshing. On the second try, I got a login error - but was now logged in - but only on the https version of en.wikipedia, not on the http version. A third try got me logged in 'properly'. - The Bushranger One ping only 18:29, 16 September 2013 (UTC)[reply]
Weird. There are two bug reports in https://bugzilla.wikimedia.org about unintended redirects after logging in, but this sounds different. Wondering if you could reproduce this, but I can understand that's probably nothing you want to try. :) Also note that Firefox 22 became unsupported on August 6, 2013. --AKlapper (WMF) (talk) 16:37, 18 September 2013 (UTC)[reply]

Arabic fonts

Tracked in Phabricator
Task T55957

A few months back (can't remember exactly when), there was a change in the font used for Arabic in Wikimedia projects. The "old" font was a professional-looking, easy-to-read one similar to the ones used in most major Arabic news outlets (e.g. Al-Jazeera). The new one is a more floral, "handwritten" style that greatly slows reading (particularly for non-native readers) and looks exceedingly sloppy (such as when it defies table cells). Arabic Wikipedia used it for a time, but seems to have switched back to the older, cleaner font recently

Why was this change effected and is there a way of turning it off or circumventing it? ~~ Lothar von Richthofen (talk) 18:07, 17 September 2013 (UTC)[reply]

See https://www.mediawiki.org/wiki/Universal_Language_Selector/FAQ#How_do_you_decide_a_default_font_for_a_language_or_script.3F and https://www.mediawiki.org/wiki/Universal_Language_Selector/FAQ#Can_I_disable_the_default_font_that_ULS_has_chosen_for_my_language.3F --AKlapper (WMF) (talk) 19:34, 17 September 2013 (UTC)[reply]
Fixed it, thanks! ~~ Lothar von Richthofen (talk) 21:13, 17 September 2013 (UTC)[reply]
I think it still needs fixing. I don't believe it's reasonable to expect all users to follow the steps AKlapper (WMF) has helpfully suggested. That table looks like crap; it's broken, and needs to be mended. If the old font worked there, why not go back to it? I hadn't noticed the table problem, but have been wondering for a while why I was finding it hard to read Arabic running text, and until reading this had attributed it to worsening eyesight; the old font was definitely more readable. Justlettersandnumbers (talk) 11:53, 18 September 2013 (UTC)[reply]
Please feel free to create a ticket in the 'Bugzilla' bug tracker under product "MediaWiki extensions" and component "UniversalLanguageSelector" by following the instructions How to report a bug. This is to make developers of the software aware of the issue. If you have done so, please paste the number of the bug report (or the link) here, so others can also inform themselves about the bug's status. Thanks in advance! --AKlapper (WMF) (talk) 15:08, 18 September 2013 (UTC)[reply]
Alright, I've added a comment (comment 4) to bugzilla:53957 because it might be the same problem. --AKlapper (WMF) (talk) 11:26, 19 September 2013 (UTC)[reply]
We (the Language engineering team) are considering a change in the Arabic font that is provided with the ULS. Can't promise anything right now, but stuff may change soon, so that local fixes wouldn't be needed. --Amir E. Aharoni (talk) 18:04, 21 September 2013 (UTC)[reply]

Looking for a tool

Is there any toolserver app that could be used to compare two page histories and list the common editors? equazcion (talk) 21:17, 17 Sep 2013 (UTC)

Yes, see Wikipedia:Sockpuppet_investigations/SPI/Administrators_instructions#Useful_SPI_scripts_and_tools. Matma Rex talk 23:09, 17 September 2013 (UTC)[reply]
Thanks -- however those seem to take users and list their common pages, rather than take pages and list the common users. Is there something that does the latter? equazcion (talk) 23:34, 17 Sep 2013 (UTC)
From Betacommand (via IRC): "I am working on a tool for [y'all], should be done within 48 hours." Writ Keeper ⚇♔ 02:23, 18 September 2013 (UTC)[reply]
Awesome, thanks (both of you :)! equazcion (talk) 06:07, 18 Sep 2013 (UTC)
Relaying from IRC - "Betacommand: can you drop a note @https://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28technical%29#Looking_for_a_tool and point them to http://tools.wmflabs.org/betacommand-dev/article_intersection.html" Sfan00 IMG (talk) 16:18, 18 September 2013 (UTC)[reply]
That's great! I'd just suggest adding a total count but it's not detrimental. Thanks for the notification, Sfan00 IMG, and please relay my sincere thanks to Betacommand for making this! equazcion (talk) 16:25, 18 Sep 2013 (UTC)
Relaying: "Betacommand: can you drop another note, have Equazcion take another look, if there are any other features that are wanted (IE ignoring bots or whatever) just let me know."Sfan00 IMG (talk) 16:34, 18 September 2013 (UTC)[reply]
It seems to be just about perfect, as far as I'm concerned :) Thank you once again! equazcion (talk) 20:43, 18 Sep 2013 (UTC)

Forcing Convert into huge Lua modules

This is a major announcement about rewriting Template:Convert.

There is an impending upgrade, expected in October 2013, to switch Template:Convert, from the current collection of small, efficient subtemplates, to use gigantic Lua Module:Convert (tested) and others of several thousand lines each. This will be a drastic new architecture, leaving the dynamic small subtemplates where updates had affected only the related pages, into an old-style software mega-system ("one size fits all") where one Lua change requires reformatting all {convert} articles (nearly 560,000 pages). Consequently, all related Lua modules (Module:Convert/data) will be full-protected, and no new old measurement units can be added, or altered, except by admins, and will require reformatting all pages in Wikipedia which use {convert}. Meanwhile, the old {convert} will be usable for emergency fixes or incompatible parameters, as Template:Convert/old, to allow custom format changes, or instant new units (such as "cuerda" or "US teaspoon") without triggering the 3-day(?) reformatting of all 560,000 pages which use Lua {convert}. During the transition period to Lua, to determine long-term feasibilty, it will be possible to streamline old {convert} into a smaller set of dynamic templates, where perhaps 40 subtemplates would provide all basic conversions for some other-language wikipedias which cover U.S. topics or Imperial units with metres/feet, km/miles, kg/pounds, or ml/pints in cultural descriptions, while most scientific articles would need only give metric units in other languages. If the continual, year-long(?) reformatting of articles, which is triggered by updates to Lua Module:Convert, becomes a performance bottleneck, then a return to the streamlined Template:Convert might be the result, or else split Module:Convert into redundant sub-modules to reformat only fractions of the 560,000 pages whenever the Lua {convert} is updated. We have confirmed, via wp:CS1 Lua cite Module:Citation/CS1, how changing the one module will, absolutely, trigger the cumbersome reformatting of 2.1 million Wikipedia pages for days, every time, for even a tiny change. These problems, of Lua-triggered year-long reformatting of pages, are a new challenge because the prior mega-templates were "too slow" to alter very much, and remained unchanged for months, to not trigger reformatting millions of pages each week. Anyway, we have needed a chance to streamline and reduce Convert's 2,800 subtemplates, and this transition to Lua {convert} can provide a time period for that improvement. -Wikid77 (talk) 23:10, 17 September, 00:29, 20 September 2013 (UTC)[reply]

Maybe this is a dumb question, but why not just merge the second parameter into the module name? convert|123|lb|kg --> convert-lb|123|kg Wnt (talk) 06:56, 18 September 2013 (UTC)[reply]
Yes, separate templates for major units is an excellent way to avoid reformatting all pages, such as a cvt-m (used 45%) or cvt-ft (used 40%) or cvt-km used in 32% of pages, and then all other conversions would then affect less than half of all pages. -Wikid77 21:50, 18 September 2013 (UTC)[reply]
Conversion is tricky! Including aliases, there are over 1000 units (see this master list), and over 4000 templates (see this old list created by Osiris). In principle, there could be a different template and a different module for each of the 42 unit types, but then instead of "convert", the wikitext would have to say "convert-length", so it would be better to see if the servers can cope with a single template and main module.
To handle the addition of new units (such as the "cuerda" and "US teaspoon" templates which Wikid77 recently created), the module provides Module:Convert/extra which is an almost empty list that is checked when the main convert module encounters a unit it does not recognize. I don't see a reason that the extra module should be protected, so anyone could add a new unit there, and the new unit would be instantly available with very little overhead to the servers.
It is highly likely that the convert module will need tweaking, and that will invalidate the cache for many pages, as described above. However, the devs told us to replace templates that do a lot of work, and the module should stabilize after a month or two. We'll have to see how much trouble mega-modules cause. Johnuniq (talk) 10:46, 18 September 2013 (UTC)[reply]
Actually I was proposing to add a unit (it could be either the source or the destination unit, doesn't really matter, whatever people decide they prefer) to the name of the template for each case: convert-lb rather than convert-weight. The idea would be that convert|A|B|C -> convert-B|A|C could be done by bot without any thought involved. That involves a much larger number of templates, some of which could indeed call common modules like a convert-length module, but each overall kind of quantity can have code without dependencies on each of the others, and even within a conversion type the templates would only all be reprocessed if a common module like convert-length itself were changed, rather than when anything affecting convert is changed. Wnt (talk) 14:53, 18 September 2013 (UTC)[reply]
Also, I'm a bit confused by your proposal for Module:Convert/extra. Is there a way to call that without using Module:Convert? Because as I understand it, Lua modules are run when the page is parsed, so a change in Module:Convert/extra should either not affect how convert works at all, or else should trigger it to be rerun wherever it appears. There's no way to build just part of a module/template on Wikipedia without redoing the whole thing, is there? Wnt (talk) 15:00, 18 September 2013 (UTC)[reply]
  • Templates and modules allow dynamic linking only if used: Yes, only a portion of the total 560,000 pages would be affected by using Module:Convert/extra for new units, and only those pages would need to be reformatted when adding yet another new unit. The current markup-based template {convert} works similarly to handle each specific conversion with only a few subtemplates (among 2,800 combinations of options). However, having separate, dedicated templates for cvt-km and cvt-m and cvt-ft (for feet) would almost always limit most feature upgrades to affect only half of total conversions, for years to come (even when WP has 10 million articles), which is how the current Template:Convert/km and Template:Convert/m limit the reformatting to only 45% and 32% of total pages with conversions. Meanwhile, we need to improve the Lua conversions to adjust fraction precisions, such as Template:Convert/old which has the same precision as 3-decimal 7.004. So, in October, there would be fewer changes needed in the Lua version, as being closer to the current precisions of markup-based Convert. -Wikid77 (talk) 21:50, 18 September 2013 (UTC)[reply]

Could I quickly ask what the best options for Simple English Wikipedia would be? Wikid77, you will probably remember that we imported the entire set of subtemplates last year sometime. Should simplewiki continue using those or switch to modules? There are less than 7,000 pages using {convert} anyway -- in case you wanted to do a trial run on a smaller project before implementing it here? Osiris (talk) 02:36, 19 September 2013 (UTC)[reply]

  • Convert works on simplewiki, so if it ain't broke...: There is almost no advantage to switching to a highly complex Lua version of Convert, if following the "80/20 Rule" of fixing problems which hinder 80% of quality. Convert is basically: a ~0% quality problem (never 80%), because any bugs can be fixed within hours/days not months. As noted above, an alternate improvement (long-term) would be dedicated templates for only metres/feet, km/miles, kg/pounds, or ml/pints, and thereby any new features updated in {convert} would affect perhaps reformatting only 25% of all conversion articles. The switch to Lua convert might be a "less-optimal" solution, which incurs numerous complexities for checking precision and derailing the current system of several people who know how to fix many quirks of markup-based Convert. A sideshow arena has been the slow reduction of Convert subtemplates (as a type of "sub-optimization") to remove a mere thousand Convert subtemplates when Wikipedia is drowning in a "zillion" (millions) of trivial templates which could be removed instead. There are over 104,000 types of infobox templates, at that level of detail, and keen reductions among those would simplify more pages than combining rarely-used Convert subtemplates which affect a 2-number phrase. To make major tangible progress instead: analyze quality problems in numerous articles, then count which few quality aspects (if improved) would tend to improve "80%" of article text, for relatively low effort expended. For example, a real improvement for WP would be to create a "list-formatting Bot" which would transform hacked markup lists which contain over-bolding and "<br/>" lines by Bot-editing those lists into typical indented-bullet lists; then run that Bot on thousands of articles where a real benefit could be achieved by rapid wiki-formatting of text. Another major improvement would be a de-redlink Bot which removes "40 redlinks" from all those overlinked pages of garage bands and their 7 non-notable albums or 33 related musicians who never got articles. Focus on major quality problems: over-bolded lists, massive redlinks, or bare-URL cites, and improve the tools which help users to quick-fix those major issues. Rewriting Convert in Lua is just a distraction, of relatively little improvement, in comparison to mass copy-editing of text. -Wikid77 (talk) 04:41, 19 September 2013 (UTC)[reply]

@Wnt: To answer your question at 15:00 above, the plan is a user would always use a template (currently {{convert/sandboxlua}}) to do a convert, and that template always invokes Module:Convert, which in turn always requires two other modules (one for conversion data, and one for text that would be translated for use on another wiki). The main module has logic which says "if the unit I'm looking up is not found, require the extra module and use it to lookup the unit". The result is that the page using a convert template would depend on the extra module if and only if the unit being converted is not in the main data module. Johnuniq (talk) 09:40, 19 September 2013 (UTC)[reply]

If you can actually do this - have a Lua run for a specific page keep track that a module in it was not required, and not rerun based on changes in it - then you should be able to have the main convert template only require the sub-modules it actually uses for any specific unit conversion. Changing the conversion of gallons to ounces shouldn't affect meters to feet, if they are split up properly -- indeed, I'm thinking almost any widely used module should have a way of requiring only the parts it depended on for a particular run. But what I don't understand is --- where is this information kept? It's not in the output of the #invoke, it's not in the module source code - is there some set of wiki global variables that stores the inverse of "what links here" for each page? Wnt (talk) 19:18, 19 September 2013 (UTC)[reply]
The information is stored in the same tables used for "what links here", in this case the templatelinks table that tracks template transclusions. The table is indexed such that it can be used in both directions. This is updated each time you save a page to indicate which templates and modules were used to render it. (The entries for any given page are also updated by job queue tasks when one of the page's transcluded templates or modules is edited.) – PartTimeGnome (talk | contribs) 22:39, 19 September 2013 (UTC)[reply]
A year ago, I was toying with the idea of having separate tables for each type of unit—data for units like meters and feet would be in a "length" table, while grams and pounds would be in a "mass" table. At the back of my mind, I am keeping open the possibility of going back to that idea, but I think that extra complexity would need to be justified by trial-and-error where we find that the enormous single table is unsatisfactory in practice. Johnuniq (talk) 01:58, 20 September 2013 (UTC)[reply]
@Johnuniq: I've looked over your table at User:Johnuniq/Conversion data -> Module:Convert/data. It would indeed be hard to pre-sort an unknown unit according to what kind it is, and of course any table meant to sort out what kind it is in advance would need to be updated quite a bit and affect every usage... however, you should be able to break this down pretty easily by simple alphabetical order. If your script were adjusted to produce several Module:convert/data/x tables according to the alphabetical range of the first letter of the unit, the main Module:convert could require that section specifically. As a result you could update units with far less burden on the server.
It would also be nice to see the logic in Module:convert be more modular where there might be changes, but maybe unit type isn't the right thing there either. There are just a few features like "Mach" conversions which seem to take up a lot of code there, and which might be prone to further tinkering, say, when somebody starts riddling out what the increase in carbon dioxide levels does to the scheme. Maybe a few things like that can be delegated out to a special set of logic functions required only when needed? Wnt (talk) 18:40, 20 September 2013 (UTC)[reply]
Yes, alphabetical sorting would have an advantage, but I don't see why units would need much updating after a month or two. The reason the current templates are continually updated is that people keep finding an option that generally works, but which has not been implemented for a particular unit. The actual unit data almost never changes because Jimp went to a lot of trouble to make the data correct (and I have copied almost all of it). New units can be added to the extra table, and put in the main table once a month, or whenever. One issue regarding alpha order is that I will be maintaining data tables on other wikis—for example, see bn:Module:Convert/data (with sample converts here). Arranging units "by type" means only one table would be needed for a particular convert, although an additional table would be needed to determine which table to use.
When I was still concerned about performance (before it became apparent that speed is not a problem, see my sandbox), I did an ugly hack suggested on wikitech-l, and it turns out that storing a table of data in a single string and doing a binary search on that mega-string is faster than indexing a table (see test2 with background here). However, it is now clear that dirty tricks are not needed. Johnuniq (talk) 23:53, 20 September 2013 (UTC)[reply]

@Osiris: The convert module is in use at the Bengali Wikipedia—some results can be seen here. It's exactly the same as the module proposed for use here, except that the Bengali editors have provided translations for unit names and related text that they use. Johnuniq (talk) 09:40, 19 September 2013 (UTC)[reply]

  • This angle: are there any functional improvements (known, thinkable or should-be made possible) that were postponed because of markup-code complexity? If so, Lua could allow them. I am not talking adding new units. -DePiep (talk) 09:52, 19 September 2013 (UTC)[reply]
There were many requested features for rounding the 1st amount, rounding output to near=5, 25 or 50, and inserting custom text between numbers, but Template:Convert/f was written to allow them. Many of those features are also in the Lua Convert module.
  • So even a tiny changes causes all 560.000 pages to be refreshed. Exactly who declared that a performance issue/problem? Has mw or so requested this rethinking? And we could consider to use an module edit regime that parks minor edits to be introduced once in every x months (or when a bug appears). -DePiep (talk) 10:05, 19 September 2013 (UTC)[reply]
With new units placed in small Module:Convert/extra, then only a small number of pages would reformat to show the new unit in related pages, as compared to waiting for all 560,000 pages to reformat to display the new unit among them.
  • If having 500,000 pages in the job queue worries people, then I might not have made many favours with this edit yesterday. (Pages added to the job queue: 7.8 million.) To a certain extent, having lots of pages in the job queue is inevitable after the switch to Lua: modules that have only just been written are likely to need more tweaking and updating than templates that have been around for years. A lot of this problem should disappear after the really high-use modules stabilise and the focus switches to converting lesser-used templates. Also, it may be a mistake to focus purely on the number of pages that need updating - pages transcluding templates that have been converted to Lua will be processed a lot faster than pages with the old wikicode templates. Although, of course, it is always good to code templates so that they don't use too many resources. Module:Convert/extra seems like a good way to accomplish this to me. After Module:Convert stabilises, the main module will hardly be edited at all, and new updates can be added to Module:Convert/extra with hardly a dent to the job queue. This seems worth it to simplify the current Template:Convert family, which is very hard to comprehend due to the large number of subtemplates and the complex interactions between them. — Mr. Stradivarius ♪ talk ♪ 10:57, 19 September 2013 (UTC)[reply]
If you think the one-line Template:Convert/LoffAoffDbSoff is hard to comprehend for showing number, unit name, and result in "(__)", then imagine a user reading Module:Convert with 3,000 lines of Lua script, and ask them where the "(__)" are displayed by Lua. We know we are creating Lua modules which "no one" else can understand, but perhaps we could write a programmer's guide to Module:Convert, to explain the complexity. Meanwhile Template:Convert/old allows updates to the well-known features. -Wikid77 00:29, 20 September 2013 (UTC)[reply]
Well, Wikid77, we are not forced to do so -- or to do whatever. As you know. Then, about these 560.000 (half a million) pages that are to be changed. Earlier, {{cite book}} was about that same number. It was controlled. -DePiep (talk) 22:24, 19 September 2013 (UTC)[reply]
When I wrote the Lua script for {cite_book}, I tested many parameters and knew the order of the 50 major parameters, plus others reviewed the results long before {cite_book} was transitioned to Lua. There were various discussions to add several more minor parameters, but I noted the impact of updates to continually reformat 1.9 million pages (now 2.1M), and updates were delayed for months. A major problem with mass reformatting (other than WP grinding for days) is how Special:WhatLinksHere is not fully updated for at least 4 days, as oppposed to minimal reformats which can update the backlinks within one hour. -Wikid77 00:29, 20 September 2013 (UTC)[reply]

Seriously funny on the Search feature

I typed Brooks County, Texas in the search bar. There is an existing article by that name. But the one and only search result was the option "containing donnybrook" - and yes, I checked my spelling to make sure I had not caused that. I went to a different tab and again typed in Brooks County, Texas and it brought the article right up. The glitch has come and gone, but it makes me laugh. — Maile (talk) 23:25, 17 September 2013 (UTC)[reply]

Yes. I've seen that sort of thing occur, too. There must me some bug, somewhere. But it only very rarely shows up. DOwenWilliams (talk) 00:11, 18 September 2013 (UTC)[reply]
Please submit a bug to bugzilla: if there is not already one. If you can, get a screenshot or possible steps to reproduce. πr2 (t • c) 00:13, 18 September 2013 (UTC)[reply]
I cannot reproduce the problem with "Brooks County" on English Wikipedia, but I guess that's the problem with intermittent bugs - they are always a bit shy. Also see How to report a bug. --AKlapper (WMF) (talk) 10:17, 18 September 2013 (UTC)[reply]
I have not been able to reproduce it either. Here and there, I've noticed odd search things like that, and I always assumed it was my input that made it happen, some slip on the keyboard. This time, it was definitely the system. Thanks for the information. Existing bug report 27411, and otherwise 155 existing bug reports that come up for "Search suggest". — Maile (talk) 11:22, 18 September 2013 (UTC)[reply]

Changing underscores (_) to hyphens/dashes (-) in URL

Resolved

- No reason to believe Google is having issues, nor any other major search engines. Just because it's not Google's ideal way, they seem to have a handle on it, and as such it's not our problem to optimize their searches if it begins to have problems. ~Charmlet -talk- 21:56, 18 September 2013 (UTC)[reply]

I know that it's the tiniest correction but it can have huge (positive) implications (although it may not be technically possible using wiki software).

Search engines, namely Google, have told many, many times that underscores are not the ideal way to indicate whitespace in a URL because if a URL is phrased .../wiki/Main_Page, "Google will only return that page if the user searches for [Main_Page]". Whereas, if the URL is phrased .../wiki/Main-Page, "that page can be returned for the searches [Main], [Page], and even "[Main Page]".

So, if it is technically feasible, I think to optimize Wikipedia's URLs, this correction should be completed. 184.146.125.96 (talk) 01:23, 18 September 2013 (UTC)[reply]

"-" are valid characters in our page titles iirc, That would break those pages titles without any real benefits. Peachey88 (T · C) 01:29, 18 September 2013 (UTC)[reply]
I just tried it. And "-" works for "Main-Page". But you're right with the "-" character in articles, it breaks the page title. Is there a feasible way to accommodate hyphens/dashes? Or, is it technically impossible? 184.146.125.96 (talk) 01:42, 18 September 2013 (UTC)[reply]
Is this really an actual problem, rathe than a hypothetical one? If one searches, for example, for United States, Google has no problem finding the Wikipedia article of that topic (it's the first search result, at least for me), even though the wikipedia URL includes United_States rather than United-States. -- John Broughton (♫♫) 03:10, 18 September 2013 (UTC)[reply]
I don't entirely follow Google's logic (what about hyphens in normal, non-programmer English? Seems a bit topsy-turvy to me), and besides which, each of our pages should restate the title a few times in the text, and be linked to from other pages using the title, so if it's not indexed properly in the URL, then that doesn't seem too much of a problem (since AFAIK, the other factors are much more impotant to page rank). — Preceding unsigned comment added by MChesterMC (talk • contribs) 10:55, 18 September 2013 (UTC)[reply]
  • Underscores are fine in URLs for search-engine match: Simply search for a quoted phrase, and notice how the matching words are highlighted in URLs with underbars ("_"), in a search-results page (see: Google site-search "main page"). I have been keenly interested in SEO for over nine years and can confirm Google has matched words in URLs with underscores for the past 9 years. As a courtesy to Google, for their company-proprietary PageRank algorithms, I will not say how high a URL match ranks, except to say it does matter. Underscores are not a problem. -Wikid77 13:23, 18 September 2013 (UTC)[reply]
  • Remarked as resolved - no reason to continue this. It's been shown, and I've tested it a bit, that Google and Bing and Yahoo! all do fine with spaces and underscores and finding the articles I search for, even with obscure and/or new ones. ~Charmlet -talk- 21:56, 18 September 2013 (UTC)[reply]

Processing time for WikiProject banner

specifically, {{WikiProject United States}}. Please can anybody assist with this and similar queries in that deletion discussion? --Redrose64 (talk) 12:41, 18 September 2013 (UTC)[reply]

I replied. Please {{ping}} me if there are further question, I am not watching that page. Matma Rex talk 13:35, 18 September 2013 (UTC)[reply]
Wikipedia:Template_limits#How_can_you_find_out.3F Werieth (talk) 15:16, 18 September 2013 (UTC)[reply]
If you follow the link I gave in the original post, you'll see that I already extracted that information. It is another user who is having difficulty interpreting it. If you can assist, please post on the original thread, not here, per WP:MULTI. --Redrose64 (talk) 15:25, 18 September 2013 (UTC)[reply]

Weird text when infobox replaced

See [2] - a vandal removed the infobox, but when it's replaced the lead starts with text about someone named Ethan. Dougweller (talk) 16:29, 18 September 2013 (UTC)[reply]

The Ethan text was a part of the (also vandalized) {{Aztecbox}}. I've reverted. Thanks for the note.—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); September 18, 2013; 16:36 (UTC)
And thanks for fixing it. Dougweller (talk) 17:55, 18 September 2013 (UTC)[reply]
This is where 'Related changes' in the left toolbar comes in handy. --  Gadget850 talk 21:08, 18 September 2013 (UTC)[reply]

Find template with parameter

Hello. 1) Is there a way to find which articles have the parametrer {{flagicon|Cyprus}}? 2) If yes, is there a way to find which articles of a specific category have the parametrer {{flagicon|Cyprus}}? Thx. Xaris333 (talk) 19:41, 18 September 2013 (UTC)[reply]

What is your goal? Werieth (talk) 19:43, 18 September 2013 (UTC)[reply]
  • Use WhatLinksHere of the {Country_data_Cyprus}: The related data-size template is typically a good indicator about using "Cyprus" so just see:
That should be close to what is needed. -Wikid77 (talk) 22:10, 18 September 2013 (UTC)[reply]

Thx. But is not what i want. I want a way to find the articles that had a specific parameter of a template. Xaris333 (talk) 15:02, 19 September 2013 (UTC)[reply]

What are you trying to do? If you explain your goal we can find a solution for you. Werieth (talk) 15:04, 19 September 2013 (UTC)[reply]

Bug in selective undelete of a deleted page

Tracked in Phabricator
Task T45911
  • Because of this bug I could not so something which as an administrator I should have done for someone. Anthony Appleyard (talk) 20:20, 18 September 2013 (UTC)[reply]

Copied from my user talk page

  • Hello, thanks for history merging Disney XD (United Kingdom and Ireland). But could you please delete my two 04:27, 16 September 2013‎ revisions, they don't belong in the history of that page. Thanks, 117Avenue (talk) 18:29, 18 September 2013 (UTC)[reply]
  • Can't do. There is a bug in Wikipedia. I must delete all edits, then undelete the wanted edits. But Disney XD (United Kingdom and Ireland) has 1361 edits, and whenever I tried a selective undelete on it, Wikipedia did not obey, but instead acted as if I had asked for "search deleted edits". So I undeleted everything. Sorry. Anthony Appleyard (talk) 20:14, 18 September 2013 (UTC)[reply]

Continuation

This is bug 43911. Graham87 08:17, 19 September 2013 (UTC)[reply]

Huge blank spaces after the footer on some articles

Is anyone else getting this? I'm getting enormous blank spaces after the footer on some pages, and I've no idea why. Running Chrome and I've tried disabling every extension, hard-refreshing and restarting Chrome -- nothing's working. It's very weird. Happening on Costa Concordia disaster, for example -- the page as it should be shows up, but then there's an enormous blank area about 1/3 the size of the entire article after it. Doesn't happen in Firefox, so it's something in Chrome, but I can't work out what. Anyone have any ideas? As a sidenote, because it might be related, who knows: Wikipedia seems to be forcing SSL on me, and I can't work out why... Again, Firefox doesn't, but using https manually on Firefox doesn't add this enormous whitespace either. Running Chrome 29.0.1547.76 m on Win7. Buttons to Push Buttons (talk | contribs) 23:55, 18 September 2013 (UTC)[reply]

It's a Chrome issue having to do with long {{reflist}} columns. It's being looked into here. equazcion (talk) 23:58, 18 Sep 2013 (UTC)
Aha, thanks very much. Did a ctrl+f for "blank" and "whitespace" but neither hit in that section... Cheers. Buttons to Push Buttons (talk | contribs) 00:04, 19 September 2013 (UTC)[reply]
Regarding SSL, Wikipedia has forced SSL for logged-in users since 28th August. (This can be disabled in preferences.) Were you logged in on Firefox? If you were logged in, did you last log in using Firefox before 28th August? The force-to-HTTPS behaviour only starts happening (for each browser you use) from the next time you log in after the feature was introduced. – PartTimeGnome (talk | contribs) 21:54, 19 September 2013 (UTC)[reply]
Yeah, that's it -- I only use FF when I'm checking if something's wrong with Chrome, and so wasn't logged in. Thanks for the link. Buttons to Push Buttons (talk | contribs) 17:27, 20 September 2013 (UTC)[reply]

I think I'm getting the same thing in that, on some articles, a large number of references are invisible despite being correctly formatted. I first noticed on the Bournemouth which I am currently working on but it the same with other articles so I don't think it's anything I've done. I'm not running Chrome, unless it's been sneaked on while I was updating something. How can I find out and disable it?--Ykraps (talk) 07:08, 20 September 2013 (UTC)[reply]

Chrome is a browser, not something that might be sneaked on you... which browser are you using? --Redrose64 (talk) 16:30, 20 September 2013 (UTC)[reply]
I am afraid that my knowledge of computers is exceptionally limited so I'm not even sure what we're talking about here. I am assuming now that a browser is different to a search engine? If I said Bing was my search engine and Internet Explorer was my browser, would that sound about right?--Ykraps (talk) 17:20, 20 September 2013 (UTC)[reply]
Yeah, that's right, IE is your browser and Bing is your search engine. Chrome is an alternate to IE, from Google. Buttons to Push Buttons (talk | contribs) 17:27, 20 September 2013 (UTC)[reply]
Since you're using Internet Explorer (IE), a web browser which is known to have certain ... er, differences ... from other browsers, it sometimes helps in resolving problems if we know which version of IE that you're using. Press Alt+H, this should open a small menu near the top of the screen. From that, select "About Internet Explorer" (it's usually the last item). You should get a window containing a logo; that logo may include a number, probably between 7 and 10. If it doesn't, there should be a few rows of text, one of which should begin "Version:" followed by a longer number. This is what we're interested in. --Redrose64 (talk) 19:48, 20 September 2013 (UTC)[reply]
It appears to be the latest version of IE, Version 10. I am intrigued by these 'differences'. How does IE differ from other browsers?--Ykraps (talk) 08:25, 21 September 2013 (UTC)[reply]
Oh, where to start? Web pages are written using software that generates code such as HTML and CSS that is computer-readable, and to an extent, also human-readable. There are standards documents that describe what is "good" HTML and "good" CSS, which have appeared in several revisions over more than twenty years. Few browser vendors stick rigidly to one of these revisions (otherwise there would be no progress), but have either chosen to ignore portions of the standards, or have added their own extra features (sometimes both). Similarly, web page authors might not adhere rigidly to the standards. This means that a web page written to take advantage of the features of one browser might not work as expected in another. For example, visit NBR 224 and 420 Classes#Notes. In Internet Explorer versions up to 9, there is a single column, which occupies a little less than a quarter of the page width on a screen 1280 pixels wide. But using certain other browsers, such as Google Chrome or Mozilla Firefox, there are four columns here. To complicate things, Microsoft have chosen to provide recent versions of Internet Explorer with a setting known as "quirks mode", which can be used to configure which features the browser exhibits, so depending on that setting, IE 10 may show one column - or several.
What it comes down to is this. If the web page author has performed a calculation for vertical positioning that the browser doesn't understand, the browser may display certain portions of the page too far up the page - or too far down. --Redrose64 (talk) 15:55, 21 September 2013 (UTC)[reply]
Okay, I think I understand. Some browsers are better at interpreting some codes than others, so changing my browser might solve the problem.NBR 224 and 420 Classes#Notes shows as 3 columns with IE 10 by the way.--Ykraps (talk) 15:34, 22 September 2013 (UTC)[reply]
Have just downloaded Firefox and things seem okay now.--Ykraps (talk) 16:05, 22 September 2013 (UTC)[reply]

how does td style work in wikipedia?

how does td style work in wikipedia?

span works on both wikipedia and on other wikis, but td does not.

Where is td style defined on wikipedia? Is it at Mediawiki:common.css maybe ?

Thank you.

Example:

<td style="background:#a3b1bf">test</td> -- works only on wikipedia, not other wikis
<span style="background:#a3b1bf">test</span> -- works on wikipedia, and all other wikis

Special:Contributions/108.28.6.134 (talk) 05:44, 19 September 2013 (UTC)[reply]

You aren't giving enough context, but this sounds like it could be a case of mixing wikitable and htmltable syntax (which only works with Tidy, which Wikipedia uses and many other wikis do not). Does this work on the other wikis in question?
foo bar
foo bar
--Splarka (rant) 07:15, 19 September 2013 (UTC)[reply]
108.28.6.134 - regarding your test here, it looks peculiar (with the table cell below the span and the signature) because you've used <td>...</td> in isolation. It only displays predictably if it is properly enclosed in <table><tr>...</tr></table>. I've fixed it. --Redrose64 (talk) 15:11, 19 September 2013 (UTC)[reply]
The wiki in question is: http://deadrisingwiki.com
BRILLIANT GUYS! Adding the <table> tags made it work.
Such an easy solution!
User:Splarka - your test works. http://deadrisingwiki.com/wiki/Template_talk:Tab
I will check out Tidy. I thought tidy was for something else, but I will check it out! Thank you!

I get the same thing by adding <table> as I do here.

td style test

Igottheconch (talk) 16:50, 19 September 2013 (UTC)[reply]

SOLVED - and fixed the template:tab too. It was a template error. [3] Igottheconch (talk) 17:59, 19 September 2013 (UTC)[reply]

The problem with that edit is that it assumes that browser vendors have implemented the border-radius: property. This is not yet part of the formal CSS specification - it is still at Candidate Recommendation stage. Browser vendors are unlikely to fully support it unless it reaches at least the Proposed Recommendation stage; some may wait for the final W3C Recommendation. Until that happens, we have used the {{border-radius}} template, which uses several proprietary properties to achieve something similar - -moz-border-radius: for Mozilla browsers and -webkit-border-radius: for Webkit browsers as well as the proposed border-radius: property. --Redrose64 (talk) 18:41, 19 September 2013 (UTC)[reply]
In fairness, whatever its W3C status, virtually all browsers *do* support border-radius these days without need for a proprietary prefix; indeed, most have supported border-radius for yonks (IE9, Firefox 4, Chrome 5) [4] . - Jarry1250 [Vacation needed] 21:55, 22 September 2013 (UTC)[reply]

Redirect status following a pagemove

Tracked in Phabricator
Task T47348

When moving a page, there is an option to specify whether one wishes to leave a redirect. If one checks the appropriate box, a redirect will be created from the old title to the new title; if one unchecks the box, the creation of a redirect will be suppressed.

However, regardless of which option an editor chooses, the Move succeeded screen always notes at the bottom that a redirect was created. The function of creating or suppressing a redirect works just as it should, but the same message is always displayed. How could this be fixed? Thank you, -- Black Falcon (talk) 05:42, 19 September 2013 (UTC)[reply]

It's presumably a MediaWiki page. Copy/paste the text into the search bar and tell the system to search only for MediaWiki pages. You may be able to find it that way, or if there's a link in the message, use WhatLinksHere for the target and restrict the results to MediaWiki pages. Presumably you're an admin, since only admins get the "suppress creation of a redirect" option; if that's so, you'd be able to edit the message yourself. Nyttend (talk) 06:33, 19 September 2013 (UTC)[reply]
Oops, I'm sorry; I'm sleepy, so I had my eyes closed while typing this. Nyttend (talk) 06:34, 19 September 2013 (UTC)[reply]
I've fixed it for you. That's an impressive touch-typing ability you have, by the way. :) — Mr. Stradivarius ♪ talk ♪ 09:01, 19 September 2013 (UTC)[reply]
Thanks, Mr. Stradivarius! It was 1:34 AM, and I didn't feel awake enough to retype it. For some years, I've had a good deal of work doing transcriptions, so I've learned to be able to type while looking at something else or at nothing in particular. However, you'll note that I can easily hit the caps lock while thinking that I've hit the shift! Nyttend (talk) 18:08, 19 September 2013 (UTC)[reply]
This is bug 45348. Graham87 08:07, 19 September 2013 (UTC)[reply]
Thank you. -- Black Falcon (talk) 03:46, 20 September 2013 (UTC)[reply]

Font changed (revisited)

Tracked in Phabricator
Task T55734
Further information: Wikipedia:Village pump (technical)/Archive 116 § Font changed

Harking back to the thread of Sept 7th (Archive 116), has anything been made of this yet? I've looked at the Bugzilla thread, but unfortunately Google Translate doesn't handle that language yet. Peridon (talk) 13:17, 19 September 2013 (UTC)[reply]

I'm guessing you mean Google Translate can't translate technical English to plain English. I'll have a go for you: The most recent activity of interest is on 17 September, when Nikerabbit (Niklas Laxström) submitted a fix for languages that use Latin script (such as British and Canadian English). This is under review and has not yet been merged into the main code. – PartTimeGnome (talk | contribs) 22:23, 19 September 2013 (UTC)[reply]
Thanks. I just wanted to make sure this wasn't forgotten in some burst of other excitement. Peridon (talk) 19:08, 20 September 2013 (UTC)[reply]
Minor note, I followed up my previous query about the rationale for the existence of en-GB and en-CA, created a large synopsis, which resulted in a helpful reply, at mw:Talk:Localisation statistics#en-GB and en-CA - notes. This is just a pointer, for anyone who likes gritty details (or who can give additional details/assistance). –Quiddity (talk) 19:50, 20 September 2013 (UTC)[reply]
When setting up MediaWiki:Gadget-HotCat/de (see below), with my language set to "en - English", I noticed that the edit window was in a proportional-spacing font. After saving, I checked MediaWiki:Gadget-HotCat and found a monospace font; so I re-checked MediaWiki:Gadget-HotCat/de and found that it was still PS. I suspect that the internationalisation suffix (in this case /de) is taken into account. --Redrose64 (talk) 10:00, 21 September 2013 (UTC)[reply]

August page views just got deleted for all of WP

Resolved

At http://stats.grok.se/ all of August pageview statistics have been deleted. They were there yesterday. At Wikipedia:Help_desk#August_page_views_just_got_deleted_for_all_of_WP, I sought answers and remain unsatisfied.--TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 16:54, 19 September 2013 (UTC)[reply]

You may have to contact User:Henrik - that's the link in the FAQ section. It's not an official Wikipedia site, so I don't think anyone else here can do anything about it. There is a big blank, though. Peridon (talk) 17:12, 19 September 2013 (UTC)[reply]
The info might be at http://dumps.wikimedia.org/other/pagecounts-raw/2013/2013-08/ - but don't ask me how to get at it. It seems to be the source for the grok data. Peridon (talk) 17:17, 19 September 2013 (UTC)[reply]
He is inactive and the data that the site uses is from WM isn't it?--TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 17:18, 19 September 2013 (UTC)[reply]
Not been seen since June. And Misza of the bots I, II, and III which is not running, is also missing since May - perhaps there's a conspiracy to kidnap key people. I should be safe, anyway... That dumps link is WM, but what you do with it is beyond me. Peridon (talk) 17:23, 19 September 2013 (UTC)[reply]
(edit conflict)Yes, hence Peridon linking you to the data dumps. Henrik's site hosts a copy of the data rather than anything else - so this doesn't have implications for the actual existence of the information, just how easy it is to get it. If you're interested in obtaining something you can grab it from the link above. Ironholds (talk) 17:25, 19 September 2013 (UTC)[reply]
Can an active user create a new (and updated) tool that accesses the data that exists. This tool needs improvments anyways.--TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) —Preceding undated comment added 17:44, 19 September 2013 (UTC)[reply]
Undoubtedly someone can, but whether they will or not is a different question... Henrik does take fairly long breaks, so he will most likely be back. When, that's another question. Peridon (talk) 17:55, 19 September 2013 (UTC)[reply]
Statistics such as http://stats.grok.se/en/201308/The%20Sound%20of%20Music%20by%20Pizzicato%20Five can be found, was there something else? Peter James (talk) 18:50, 19 September 2013 (UTC)[reply]

Strange issues with image files

Hello, there, I'm having problems with adding image files onto pages. Normally it works just fine, but sometimes, both a while ago and recently, something goes wrong. This happened to me once before, when I was editing the page "Baragon", and it happened to me just now while editing the page "Hoverboard". The image comes in fine, but to the top left corner of the picture, text that reads: "Image:" can be seen. And directly below the image, there is text reading "|250x450px|alt=". I've tried different combinations of spacing in the infobox, I've changed the format from thumbnail to framed to frameless, I've both added and removed the text reading, "File:" from "File:Hoverboard.jpg", but nothing works. Someone has since cleaned up he issue on the Baragon page, but I don't know what I'm supposed to do. --Matthew (talk) 21:10, 19 September 2013 (UTC)[reply]

This edit has fixed Hoverboard. I couldn't see a recent problem in the history of Baragon. The problem is that although some infoboxes expect the full image syntax in the |image= parameter, others expect the filename alone - they fill in the rest themselves. --Redrose64 (talk) 21:31, 19 September 2013 (UTC)[reply]

Loss of session data

I was not signed out and didn't have to sign in again, and yet one of my edits gave me "Sorry! We could not process your edit due to loss of session data". I had to do this edit over.— Vchimpanzee · talk · contributions · 21:18, 19 September 2013 (UTC)[reply]

This happens when you leave the editor open too long, and I suspect when things happen on the server side too. Graeme Bartlett (talk) 21:29, 19 September 2013 (UTC)[reply]
The first problem wasn't likely to have been a factor. My previous edit was five minutes earlier. If it was just me, maybe there's not a serious problem.— Vchimpanzee · talk · contributions · 21:35, 19 September 2013 (UTC)[reply]
Essentially, what happens is that when you click "edit", you're sent a timestamped token and the server keeps a copy. When you click "Save page", you send that token back, and the server compares it against the copy. If they match, the save is processed; but if there is a mismatch (possibly: your browser fails to send the token back; it's been corrupted in some way; or the copy token no longer exists on the server - most probably because it's expired), the save request is refused with the error message that you described. Please note that it has nothing to do with whether you are logged in or not - anonymous editors can experience the same problem. --Redrose64 (talk) 21:42, 19 September 2013 (UTC)[reply]
If you're wondering why these tokens are used, they protect against cross-site request forgery. Without them, some other website could have a button that causes a user to inadvertently submit an edit to Wikipedia just by clicking it. With edit tokens, Wikipedia will reject such an edit as it lacks one. I.e. the edit token ensures someone really visited the edit page before allowing an edit to be saved.
BTW, you don't need to do the edit over from scratch. You are sent a new edit token along with that error message. Just click "Save page" again and your edit should save. – PartTimeGnome (talk | contribs) 22:51, 19 September 2013 (UTC)[reply]
It's not just you, but it's not a substantial problem. I occasionally get this even when making a small change that took just fifteen seconds. I've always assumed that new tokens become effective at stated intervals; the longer your window is open, the more it is that a change will have happened, but it's still possible that you opened the window five seconds before the new token became effective. Just click the "save" button again and repeat several times if necessary; it should always go through eventually. If somehow you try over and over and over again, you still should be able to save the contents in a sandbox. Nyttend (talk) 23:46, 19 September 2013 (UTC)[reply]
It's just done it on me at Wikipedia:Articles for deletion/Grand Duchy of Flandrensis (Grand Duchy of Flandrensis (Second time) nomination). I opened the edit window, typed two sentences and saved. No time gap. It session dataed me three or fory times, so I copied my edit, closed and reopened and pasted. This time, it saved. I can't remember what the session data message I've seen previously looked like, but this little red message doesn't look familiar to me. Peridon (talk) 19:20, 20 September 2013 (UTC)[reply]

green notices

(I don't know if this is best here or at Proposals, so pardon me if it is in the wrong forum.) I really like the idea of green squares to indicate unviewed changes (on my Watchlist page); how-ever, at least on my screen I can hardly see the difference between green and gray-green. I have to look very closely adn even then am not sure which color a square has (depending on the squares above and below it). Is there some way to make the difference easier to see? In addition to color, how about a change in the symbol? Kdammers (talk) 00:54, 20 September 2013 (UTC)[reply]

Wikipedia:Customizing watchlists has a few things you can do. equazcion (talk) 00:58, 20 Sep 2013 (UTC)
You can change the icon for updated entries in you watchlist by adding the following code to your common.css:
/* green bullets for updated entries in watchlist, history and recent/related changes */
li.mw-changeslist-line-watched,
li.mw-history-line-updated {
    list-style-image: url(//upload.wikimedia.org/wikipedia/commons/c/cd/ChangedBulletVector2.png);
}
Note that you have to specify a direct URL to the image, not a Wikilink! In this case, File:ChangedBulletVector2.png was used which yields "". You'll find a list of other matching bullets for vector and monobook skins on the file's description page, but you can also use other images as long as they have the correct dimensions. --Patrick87 (talk) 13:34, 20 September 2013 (UTC)[reply]
@Kdammers: you mention squares, so you're probably using Monobook, not Vector. You should make a change like this to Special:MyPage/monobook.css (not common.css, because it's not the same for all skins). There is related material at Wikipedia:Village pump (technical)/Archive 113#Green bullets in watchlists (also Wikipedia:Village pump (technical)/Archive 112#Green highlighting of changes since last visit doesn't work anymore but that's not so helpful). --Redrose64 (talk) 16:05, 20 September 2013 (UTC)[reply]

visible

Is this edit of mine showing? To me the edit does not appear on the actual page. Pass a Method talk 04:38, 20 September 2013 (UTC)[reply]

Seems to be showing for me. I just purged the page anyway though, check again. equazcion (talk) 04:47, 20 Sep 2013 (UTC)
My comments are not showing on this page either. I was only able to reply/view by going to "difference between revisions" in page history. I think i might have a virus or something. Pass a Method talk 06:01, 20 September 2013 (UTC)[reply]
Oh, its showing now!!. It appears on and off. Pass a Method talk 06:03, 20 September 2013 (UTC)[reply]
  • On rare occasions the old page redisplays after edit: So, please do not panick, and you did the right thing by checking View History to confirm your edit was saved. Whenever the old revision is redisplayed, after an update, then wait 20 seconds and click the browser refresh button, and usually the new revision of the page will appear. The problem is so common I have seen it every few months for years. Perhaps some other users can explain why the re-display of old revisions occurs, and if there are plans to fix it. It might be related to the "need read-lock" problem which allows 2 editors to update the same old revision, and the 2nd editor overwrites the changes of the 1st editor, during the same minute. -Wikid77 (talk) 14:33, 20 September 2013 (UTC)[reply]

Wikipedia talk:File Upload Wizard#Origin of empty stuff

Some help by a technically skilled user is needed there. Thank you in advance. --Leyo 09:01, 20 September 2013

Top 5,000 templates

No hurry on this, but I want to see a list of top 5,000, beyond the typical list of the top 3,000 most-used templates in:

When fixing that list (to correct typo names "Template:Dw" and "Template:Twin_Falls,_Idaho"), which had been redlinked 1-4 months, I noticed how there had been a redlink template sitting outside the list, at rank 3,001, just out of view to be seen for correction, before re-ranked as 2,998. With a larger list of 5,000, then more redlink typo-templates could be fixed before they become listed in the report of the top 3,000. No hurry, just a way to reduce future problems. -Wikid77 10:40, 20 September 2013 (UTC)[reply]

I have no opinion on whether this should be done, but your reason for doing it isn't terribly convincing. You'd just have the same problem with rank 5001. Anomie⚔ 11:22, 20 September 2013 (UTC)[reply]
You should use Special:WantedTemplates for this purpose instead. The special page is currently disabled, but thanks to recent efforts of User:Nemo_bis and WMF's new database engineer Sean Pringle it's going to start being refreshed once again [5]. Matma Rex talk 11:35, 20 September 2013 (UTC)[reply]
The WantedTemplates would be great to have again (and the disabled refresh explains why redlinks have gone uncorrected after January). Perhaps Sean Pringle can also fix the edit-conflict overwrites by setting "read-lock" to the page of each edit-SAVE before using diff3.c to merge edited sections. Remind him its a big problem in busy articles or popular talk-pages. -Wikid77 13:24, 20 September 2013 (UTC)[reply]
Can't you use Wikipedia:Database reports/Templates transcluded on the most pages/Configuration to run your own search? You can modify the limit there (currently set at 1,000). Fram (talk) 11:42, 20 September 2013 (UTC)[reply]
Thanks. I am hoping the re-activated Special:WantedTemplates will be easier for fixing the major redlink templates. -Wikid77 13:24, 20 September 2013 (UTC)[reply]

It could be nice to have one for modules - to see the number of transclusions Christian75 (talk) 13:55, 20 September 2013 (UTC)[reply]

Good idea, and the module namespace=828 (rather than 10 for template namespace), but I was thinking to state "number of invokes" for modules. We know Module:String has 1.417 million and Module:Citation/CS1 has 2.065 million invokes (400 more per day?). -Wikid77 (talk) 14:59, 20 September 2013 (UTC)[reply]
  • Courtesy of Betacommand, here's a list of all templates and modules with at least 1k transclusions: [6], [7]. —  HELLKNOWZ  ▎TALK 15:23, 20 September 2013 (UTC)[reply]
You might find it handy to get a labs account. It only took we a day to get approved. Then you can run your own queries on the replicated database to your heart content.--User:Salix alba (talk): 18:29, 20 September 2013 (UTC)[reply]

Odd access issue

Yesterday and today, my ability to use Wikipedia (both from a searching capability and as an editor) was hampered. I would try to open the site on my browser (IE10) and pages wouldn't load, I'd see that little indicator that a page was loading but it would never load. On other occasions, a page would load only half-way. Then I'd have a page load and in going to another page, the second page would not load--i.e. when I was editing and chose to save, or if I was at one article and navigated to another. Now when I was editing a page, and I saved my work, the next page wouldn't load--I'd get only a white screen--but my emendations to an article would save.

I've never had this problem before. Not once in 10 years of participation.

Now, as far as loading non-Wikipedia pages, I haven't had a single problem in browsing/access all day--everything loaded well, quickly, as it usually does. This is an issue I've experienced in the past 24 hours exclusive only to my use of Wikipedia.

Was this a server problem? a cookie problem? I had no other problems, so I'm leaning to thinking the problem wasn't on my end.

Please advise. BTW, I'm smart, but I'm not computerwonk smart, so despite being semi-literate, explain it to me as if I was an illiterate 3rd grader.--ColonelHenry (talk) 12:09, 20 September 2013 (UTC)[reply]

  • Weekly MediaWiki updates garble browser cache files: For the past several months, there have been weekly changes to the MediaWiki software which displays the Wikipedia pages and edit-mode screens. Also, there are now numerous CSS-class files (hundreds and thousands) which must be downloaded to format the browser skin and page styles. If, during a weekly update to MediaWiki, any of those support files change from the stored cache for your browser, then a lock-up (especially with various IE browsers) can be expected until about Friday each week. The proof of the underlying changes can be shown by re-triggered reformats of prior cached pages in a browser. Of course, Google or other top websites do not rewrite their major software every week, and those websites do not lock-up mid-week. So anyway, the easiest fix, for lock-up with WP screens, is to clear/purge the cache of your browser (Internet Options "Delete Files") between Tuesday-Thursday each week before viewing WP pages. Also plan some extra time for the lock-ups to occur, so don't expect a quick "2-minute edit" to a page on Wednesday, as might be the case on Friday evening when MediaWiki updates are stopped for the weekend. Otherwise, remember we are all coping with these bizarre "user-interfere" changes (every week), but the overall goal is working to expand WP's impressive collection of articles. -Wikid77 (talk) 13:53, 20 September 2013 (UTC)[reply]
    • This is patently false: you're spreading fear, uncertainty and doubt. Please stop. You are wrong, you don't know how the software works, yet you act as if you were the resident expert on everything. When the updates happen they do not behave like you described (ResourceLoader solves these issues), there is not such thing as "CSS-class files", they can not cause the issues described unless someone broke the code completely (the "lock-ups" are your sick invention), and Google does deploy new code continuously. You're wrong on literally everything you wrote other than the fact that there was an update on Thursday. Matma Rex talk 18:38, 20 September 2013 (UTC)[reply]
@Matma Rex: Wow, I am sorry you are so disturbed (please try to read wp:NPA and find a not-so "sick invention" for why civility matters). I have travelled over 500 mi (805 km) to different sites to confirm how Wikipedia locks up on different browsers in different cities. I am sorry you cannot accept that reality. People who complain of lock-ups here are not inventing hallucinations. Perhaps someone has time to explain the CSS class files in the browser cache, and how there are hundreds of CSS classes now. Meanwhile, please calm down, and get some perspective. You have gone from seeming helpful to seeming like ... you do the math.  [...how's that answer for pretending to be shocked...] All joking aside, I don't think the prank to claim there are "no CSS-class files" will fool readers here, and I do think that over-the-top denials of browser lockups are no longer a "cool joke" because too many people come here to earnestly beg for help to get their browsers running again. Perhaps if today were April 1st, then people might see the denial of CSS and lockups as a wry comment, but otherwise, a big joke requires an equally over-the-top response to counter the joke... or not. ;-) Wikid77 (talk) 21:27/23:21, 20 September 2013 (UTC)[reply]
I am sorry, I've run out of patience. Maybe someone else will find enough to talk to you. https://www.youtube.com/watch?v=5hfYJsQAhl0 Matma Rex talk 21:42, 20 September 2013 (UTC)[reply]
And I will walk 500 miles. And I will walk 500 more... ^demon[omg plz] 22:50, 20 September 2013 (UTC)[reply]
Good, and I'll show you the browsers in each city's library, hospital or hotel Internet desk, as they lock-up!! -Wikid77 (talk) 23:21, 20 September 2013 (UTC)[reply]

@Wikid77: - Thank you for your explanation, surprisingly I understood it more than I expected. I did happen to clear my browser cache early on in the process twice and it had no effect. Still a little shocked that I've never seen that happen in 10 years until this week. --ColonelHenry (talk) 03:10, 21 September 2013 (UTC)[reply]

  • Try to stop screens, clear cache + restart browser: I almost forget another part of the problem seems to affect the status of the browser session, so others have noted to also restart the browser. For example, I have found when I have a pending secure-access to another webpage, I have to stop that window, and only then clearing the cache will release the lock-up. Beyond that, then the final step is to restart browser. So in recap, the 3 steps:
1) stop button on pending window, 2) clear cache, 3) restart browser.
The scenario I sense is that the pending, stuck windows are retaining invalid cache files, which cannot be deleted until the pending windows are stopped/closed first, then clear cache, and then restart browser. If that does not work, next time, then return here, and some IE10 experts might know about other issues to watch. Even some of the newest browsers have incompatible features which do not work well with Wikipedia, which surprised me, because I imagined the newer browsers as being "standard reliable" but not so. I guess it's like the warning J.P. Morgan received from his mother-in-law, "Maiden voyages are too uncomfortable... things go wrong" and he did not board Titanic after his luggage went aboard. Instead here, the "penultimate" browsers seem safer, as one version back from the newest browsers, as a general rule. -Wikid77 04:41, 21 September 2013 (UTC)[reply]

New database reports

There are a number of suggestions for new database reports sitting unanswered at the bottom of Wikipedia talk:Database reports. Is anyone able to get any of these up and running? I would be particularly interested in the request to add Lua modules to Wikipedia:Database reports/Templates transcluded on the most pages, and my request to have a new report of fully protected templates and modules that are transcluded on a small number of pages. — Mr. Stradivarius ♪ talk ♪ 15:11, 20 September 2013 (UTC)[reply]

I think that we need to hold off setting up new reports, or adding features to existing reports, until the present Toolserver/WMF Labs situation is resolved. Labs is significantly slower than Toolserver, so any further reports/features on Labs will slow down those that are already there. Labs is also known to have incomplete data: X!'s Edit Counter is still not showing deleted edits, so what else is missing? On the other hand, Labs seems not to suffer from the reliability problems that have plagued Toolserver over the last year. --Redrose64 (talk) 18:58, 20 September 2013 (UTC)[reply]
I'm not sure where you're getting "slower" since the databases are faster by at least an order of magnitude, but the "missing information" you're referring to is information that should have never been made available to begin with on the toolserver. That said, we are in the process of making available a redacted list of deleted edits – but that's an exception. The tool labs isn't intended as a method to get information that isn't already public. — MPelletier (WMF) (talk) 20:10, 20 September 2013 (UTC)[reply]
On behalf of Betacommand, he says he can make these reports for you, but they won't be on the wiki. —  HELLKNOWZ  ▎TALK 19:07, 20 September 2013 (UTC)[reply]
Thanks for the offer Betacommand. :) If you could code up just the report of fully protected templates and modules transcluded on few pages, that would be fantastic. I'm thinking the report should list fully-protected templates and fully-protected modules with a transclusion count of less than 10,000, in order of transclusion count (low to high). Although feel free to tweak those parameters if you think something else would be more sensible. The other reports can wait until they can be added on-wiki, and Legoktm has sorted out the other one I was interested in below. — Mr. Stradivarius ♪ talk ♪ 23:26, 20 September 2013 (UTC)[reply]
Actually, hold that thought - it turns out we already have it. I missed it because it was listed under "protections" and not "templates". It was last run in February though, so it could do with an update. — Mr. Stradivarius ♪ talk ♪ 23:44, 20 September 2013 (UTC)[reply]
@Mr. Stradivarius:: [8] should have enabled it for the module namespace, I've queued another run but it might take up to 2 hours to run... Legoktm (talk) 22:59, 20 September 2013 (UTC)[reply]
Thank you! Don't worry about it taking two hours - I'm used to updates coming every month or so. :) — Mr. Stradivarius ♪ talk ♪ 23:26, 20 September 2013 (UTC)[reply]

Log-in/Log-out, Skins problem

Now somebody has really done it with the dubious animation in the upper right corner. Cologne Blue skin not showing, notice appears "CENTRAL LOGIN. You are centrally logged in as Carrite. Reload the page to apply your user settings." Which doesn't work, of course. Log-out fails. Ridiculous. 24.20.128.148 (talk) 16:22, 20 September 2013 (UTC)[reply]

When I get this message, I wait a few seconds then hard-refresh the page (it's Ctrl+F5 in Firefox). That usually fixes it. --Redrose64 (talk) 18:59, 20 September 2013 (UTC)[reply]
I believe loading any page would apply settings, not just reloading the previous one, but I may be wrong. πr2 (t • c) 02:14, 21 September 2013 (UTC)[reply]
Would like to know what "it doesn't work" exactly means. --AKlapper (WMF) (talk) 17:22, 22 September 2013 (UTC)[reply]
Aklapper, small guess, the JS that does the login redressing only works for Vector and Monobook. And it seems there is a problem that every time you visit a http address while logged in over https, you get the 'central login, you are centrally logged in as' notification for every page view. I'm seeing this as well right now. —TheDJ (talk • contribs) 09:52, 23 September 2013 (UTC)[reply]

Visual Editor Reference Dialog improvement - design mockup for comments

The design team is working on improvements to the VisualEditor Reference Dialog. We would appreciate any feedback! Check it out here on mediawiki.org at VisualEditor Reference Dialog. --KHammerstein (WMF) (talk) 19:30, 20 September 2013 (UTC)[reply]

Gadget descriptions in multiple languages

Occasionally I go through my accounts on "all" the different WM wikis (e.g., Belarusian Wikisource, Vietnamese Wikivoyage...) and update/standardize my preferences. (Just waiting for central preferences to happen.) The hardest part to deal with (for me, as someone who reads only English well) is the Gadgets tab, since the descriptions there are not provided in the user's chosen language but only in the local language of the wiki (example: fr:Special:Gadgets). Two questions about this:

  1. I assume there is currently no easy technical solution to providing gadget descriptions in multiple languages, since it hasn't happened yet. Has there been discussion about this anywhere? (I didn't find anything searching Bugzilla, but then I rarely do.)
  2. Is there any good reason the English Wikipedia is not providing links to MediaWiki:Gadgets-definition and Special:Gadgets from Special:Preferences#mw-prefsection-gadgets, like every other WM wiki seems to? I find these two other pages very useful in wikis in which I don't understand the language at all (MW:G-d shows the gadget names, which are sometimes more understandable than the descriptions; and S:G can be translated at Google Translate, whereas S:P cannot).

- dcljr (talk) 20:53, 20 September 2013 (UTC)[reply]

I think a solution exists and is easy, it's just that no one cares to use it – for each gadget description page such as MediaWiki:Gadget-Navigation popups create subpages with translations for each language – MediaWiki:Gadget-Navigation popups/de, MediaWiki:Gadget-Navigation popups/es, MediaWiki:Gadget-Navigation popups/ru etc. Matma Rex talk 21:50, 20 September 2013 (UTC)[reply]
Commons does this with most gadgets, such as HotCat. AFAIK the only translated gadget on English Wikipedia is MediaWiki:Gadget-popups.js/de. --Redrose64 (talk) 22:19, 20 September 2013 (UTC)[reply]
m:Wikimedia Scripts proposal (or existing translatewiki.net) could solve this by providing a central translation interface for gadgets and gadget-descriptions. πr2 (t • c) 00:57, 21 September 2013 (UTC)[reply]
To demonstrate that gadget descriptions on en.wp are translatable, I've created MediaWiki:Gadget-HotCat/de. To see the effect, go to Preferences and set your language to "de - Deutsch"; save it, and then go to Preferences → Gadgets (which will now be titled "Helferlein"), and have a look at the fifth item under "Editing". --Redrose64 (talk) 09:49, 21 September 2013 (UTC)[reply]
It can be seen with uselang=de without changing preferences. PrimeHunter (talk) 10:55, 21 September 2013 (UTC)[reply]
This is true, but do you want to translate the gadget messages of all WM wikis? That would solve the problem here. πr2 (t • c) 15:35, 21 September 2013 (UTC)[reply]
Personally, I'd be useless as a translator, so no, I don't want to. I didn't even translate MediaWiki:Gadget-HotCat/de - I knew that the HotCat gadget on en.wp is, in most respects, identical to that on Commons, so I merely copied the German description from Commons and altered the second link to a suitable place on en.wp This approach will work for HotCat descriptions in several other languages, but won't work for every gadget, since a lot of en.wp gadgets are not found on commons (compare MediaWiki:Gadgets-definition with commons:MediaWiki:Gadgets-definition); or if they are, they differ in some significant manner. When Commons doesn't have a translation (for example, none of the gadgets on Commons has a Welsh-language description), we could go to the Wikipedia of that other language and see if it has the gadget installed. Wicipedia Cymraeg has no gadgets to copy... --Redrose64 (talk) 17:21, 21 September 2013 (UTC)[reply]
Regarding point 2: The top of Special:Preferences#mw-prefsection-gadgets displays MediaWiki:Gadgets-prefstext. The English Wikipedia has customized the message and made a link to Wikipedia:Gadget but not MediaWiki:Gadgets-definition and Special:Gadgets which are linked from Wikipedia:Gadget. I don't know whether it was a deliberate decision to omit direct links from MediaWiki:Gadgets-prefstext but you can suggest a change. The MediaWiki default for English can currently be seen at MediaWiki:Gadgets-prefstext/en-gb which hasn't been customized. MediaWiki defaults must work at all wikis so they can only link to pages which will always exist. PrimeHunter (talk) 11:18, 21 September 2013 (UTC)[reply]
I've restored the links. I often find myself looking for those, or typing them in manually. This should making maintenance much easier. — Edokter (talk) — 11:56, 21 September 2013 (UTC)[reply]
  • Gadget language files protected against linguists: If we had unprotected language versions, then I think more people might translate "MediaWiki:Gadget-popups.js/de" into:
We have several users who are linguists, and they might help with any troublesome phrases. Perhaps the pages could be created in a gadget-sandbox area, and then installed when ready. -Wikid77 (talk) 21:18, 22 September 2013 (UTC)[reply]
Why change established practice? Pop an {{editprotected}} request at the relevant talk page for the default language - such as MediaWiki talk:Gadget-popups.js - stating the page that is to be created or edited (this would go in the first positional param, e.g {{editprotected|MediaWiki:Gadget-popups.js/de}}), and follow that with the text that is to be added or changed. See for example MediaWiki talk:Gadget-teahouse/content.js#Edit Request 26 Aug 2013. --Redrose64 (talk) 21:48, 22 September 2013 (UTC)[reply]

Huge one day surge in article reads: wikibug or user anomaly?

Can anyone explain why the readership of Mount Hood climbing accidents jumped upward dramatically for a day last week? (See stats) The article's usual level of access is 50–200 per day, but it was 22,639 on Friday September 13. I have asked around and searched in earnest. There appears to be nothing related in the media and as far as the Oregon community knows, there is no known cause. —EncMstr (talk) 21:37, 20 September 2013 (UTC)[reply]

Huge pageview spikes sometimes occur for no obvious reason, and several articles get *insane* levels of pageviews every day, for no obvious reason. Of course, there are cases of pageview spikes of news events broadcast by major news media, such as a blockbuster movie film premiere or a celebrity death. As far as I know, there are no reported cases of wikibugs in the pageview-spike cases, only the drop to low pageview counts when "https" requests were mistakenly omitted from the data logging (see essay: "wp:Google https links"). I guess we need an essay "wp:Pageview spikes" to better explain all the issues, where many people often ask about similar spikes with no obvious explanation. -Wikid77 01:35, 21 September 2013 (UTC)[reply]
I dug some more and grabbed the raw page read statistics. 22,543 reads occurred during one hour, which is the granularity of the raw data. I wouldn't be surprised if they occurred in a shorter timeframe, maybe some kind of bot storm. Is there a log of DoS storms, or maybe some other indication of server load?
date time reads bytes transferred
2013-09-13T00:00:00 1 32109
2013-09-13T02:00:01 1 32097
2013-09-13T03:00:00 3 96330
2013-09-13T04:00:00 3 96302
2013-09-13T05:00:09 2 32476
2013-09-13T06:00:00 3 96324
2013-09-13T07:00:00 2 64216
2013-09-13T10:00:00 1 32250
2013-09-13T11:00:03 22543 726638824
2013-09-13T12:00:02 1 32244
2013-09-13T13:00:00 2 183016
2013-09-13T14:00:00 3 334183
2013-09-13T15:00:00 3 64655
2013-09-13T16:00:01 8 256872
2013-09-13T17:00:01 7 192952
2013-09-13T18:00:07 13 417553
2013-09-13T19:00:00 22 831983
2013-09-13T20:00:00 4 128436
2013-09-13T21:00:01 16 513886
2013-09-13T23:00:11 4 64793
—EncMstr (talk) 17:07, 21 September 2013 (UTC)[reply]

Commons having issues

A heads-up, apparently all of a sudden Commons is having issues where newly uploaded (and some older...) files are throwing up bad-filename, no-thumbnail-for-you errors, even on the main preview image, and refuse to load on en.wiki pages too - I've pinged the village pump there but thought I'd drop a note here. - The Bushranger One ping only 02:11, 21 September 2013 (UTC)[reply]

The thumbnails renderer have been broken on Sep 21 from 1:38am until 3:16am. Was related to some mess with thumb.php and thumb_handler.php. Hashar (talk) 04:49, 22 September 2013 (UTC)[reply]

Image Error

At Battle of Jassini, the image is not being displayed. If the 300px requirement is removed the image displays correctly but is too large. Can anyone fix this? Ryan Vesey 03:04, 21 September 2013 (UTC)[reply]

This issue has been fixed. Ryan Vesey 03:52, 21 September 2013 (UTC)[reply]

Neither Archive bot will archive my user talk page

I had been using MiszaBot to archive my talk page, however around August 6, it just stopped doing so. (That was before the recent problems) Recently, I tried switching to Cluebot, which is now pasting the contents of my talk page into the archive, but is not removing them from the talk page. Can anyone figure out what I have done to anger the Archive Bot Cabal? Monty845 03:56, 21 September 2013 (UTC)[reply]

User:ClueBot seems to be messing up intermittently at several user pages. A cursory look showed these two archive additions were missing accompanying talk page subtractions: [9], [10]. Common to those and your page were User:SuggestBot entries within and surrounding the archived discussions; whether that has something to do with it, I don't exactly know. If you just want to fix it, I would manually archive all your talk page posts from bots. I have a feeling that will get it working again. If you want to get to the bottom of it, perhaps someone smarter than me has an explanation. equazcion (talk) 04:42, 21 Sep 2013 (UTC)
I don't know if ClueBot III uses a similar mechanism as the MiszaBot family, but there have been occasions (see the archives of User talk:Misza13) when the bot has copied sections to the archive, but has not deleted them from the main talk page. Several times, this was associated with an archive page that, prior to copying the thread, was of a size that already exceeded the |maxarchivesize= configuration item. The solution was to remove the duplicated threads, and manually adjust the |counter= configuration item to the next unused number. The next time the bot ran, it created the new archive page, copied the threads, and deleted them from the main talk page. --Redrose64 (talk) 12:08, 21 September 2013 (UTC)[reply]

The bot that checks for bad usernames has stopped running.

Twinkle won't leave delete template

Hello again! I wanted to delete this old Afc draft (housekeeping) using Twinkle because another copy of the article was accepted and is in mainspace, (The histories can't be merged because there is parallel development.) However, there's a comment from another editor which has a deleted template encased in NOWIKI commands. Twinkle picks this up and refuses to leave the delete template. I know that I could just remove the comment, but I thought that I should report this in case it's unintended. —Anne Delong (talk) 13:23, 21 September 2013 (UTC)[reply]

Submit an Edit request link failure.

Resolved

I was looking at the source of {{In the news}} and happened to notice that the "Submit an Edit Request" link was broken. Apparently, something involving redirects and modules broke it. Screenshot to see the error. I'm not sure exactly how to fix this off the top of my head or if it can even be fixed. Technical 13 (talk) 17:37, 21 September 2013 (UTC)[reply]

PS This refers to the link that appears in the interface when viewing the source of a protected template, not a link in the code of {{In the news}} itself. equazcion (talk) 17:47, 21 Sep 2013 (UTC)
The redirect at Template talk:In the news has a colon before the space - "#REDIRECT: [[Wikipedia talk:In the news]]" - which doesn't match what's in the line starting with "local redirect" in Module:Redirect. Peter James (talk) 19:43, 21 September 2013 (UTC)[reply]
I removed it. Legoktm (talk) 21:45, 21 September 2013 (UTC)[reply]
Apparently it was added by Gfoley4 (talk · contribs). --Redrose64 (talk) 13:26, 22 September 2013 (UTC)[reply]
Sorry for any trouble... —GFOLEY FOUR!— 17:19, 22 September 2013 (UTC)[reply]

Pywikipedia broken

About a week after Wikipedia was converted to https-only for login/editing, my pywikipedia installation has refused to run scripts, with the following sort of error messages "WARNING: Token not found on wikipedia:en. You will not be able to edit any page. Received incomplete XML data. Sleeping for 30 seconds..." I have unsuccessfully attempted to resolve the problem by using SVN to update to the latest version of pywikipedia. Any assistance regarding this issue would be appreciated. Thank you. DavidLeighEllis (talk) 20:21, 21 September 2013 (UTC)[reply]

@DavidLeighEllis: Pywikibot moved to git, please see mw:Manual:Pywikibot/Gerrit on how to upgrade. Legoktm (talk) 21:43, 21 September 2013 (UTC)[reply]

Notification on my User & Talk pages -- post personalised messages of thanks as appropriate

I have been receiving messages of "Thanks" recently from various editors following some revisions that I have made to articles of a common interest. How do I activate this feature for my own use?
— | Gareth Griffith-Jones | The Welsh Buzzard | — 21:10, 21 September 2013 (UTC)[reply]

Gareth Griffith-Jones, if you look at a page history (such as the history of this page, you will see that at the end of each line there are links for (undo | thank).
Similarly, if you look at a diff such as one, you will see a "thank" link at the top right of the heading for the newer version.
Just click those links if you want to thank the editor. --BrownHairedGirl (talk) • (contribs) 21:39, 21 September 2013 (UTC)[reply]
I guess you refer to Wikipedia:Notifications/Thanks. PrimeHunter (talk) 21:32, 21 September 2013 (UTC)[reply]
Thanks for the link to Wikipedia:Notifications/Thanks. I followed the reversal of opting-out described there and I can now *thank* other editors. To check that it works, I *thanked* you. Did you receive it? Cheers!
— | Gareth Griffith-Jones | The Welsh Buzzard | — 21:43, 21 September 2013 (UTC)[reply]
Yes, I received it. It's also logged at [11]. PrimeHunter (talk) 23:59, 21 September 2013 (UTC)[reply]
That is kind of you to lead me to that log. It shows the only time I used the function before I "opted-out". Cheers!
— | Gareth Griffith-Jones | The Welsh Buzzard | — 15:55, 22 September 2013 (UTC)[reply]

Analysing category overlap

Resolved

I have been busy diffusing Category:British actors to its sub-categories, and my subjective impression has been that there is huge overlap between the categories for the various media: film, television, stage, radio, video game, and voice.

If that impression is correct, it clashes with the long-standing principle at WP:OC#OVERLAPPING. So I would start an RFC on whether we should reconsider categorisng actors in this way.

However, before doing that, I want to try to measure the extent of the overlap of media in the ~11,000 articles. I think that the figures which would be useful are:

  1. number of articles in only one media category (i.e one of the subcats of Category:British actors by medium)
  2. number of articles in any two media categories
  3. number of articles in any three media categories
  4. number of articles in any four media categories

Any suggestions on how I might go about getting those figures? I had considered trying CatScan2, but can't see any way of making it do this. --BrownHairedGirl (talk) • (contribs) 21:28, 21 September 2013 (UTC)[reply]

Adding the list of categories, one per line, without namespace (copying from the category page doesn't work; maybe it contains hidden formatting characters), setting "depth" to 4 (which seemed to be enough here) and using "at least" going from 1 to 4 results in data that may be what you are looking for - I don't know how accurate it is. I've used the six "media" subcategories of Category:British actors by medium, excluding nationalities and the stub category. If this is correct, the majority are in more than one category:
  • 9969 in at least 1 category
  • 5384 in at least 2
  • 2008 in at least 3
  • 503 in at least 4
Of those, 106 are in at least 5, of which 2 (Brian Blessed and Daniel Craig) are in all 6. Peter James (talk) 12:11, 22 September 2013 (UTC)[reply]
One thing to look out for is categories within more than one parent category (which is usually acceptable overlap, and would probably produce article overlap). There are none within the categories I used, but adding the nationalities finds some. Peter James (talk) 12:50, 22 September 2013 (UTC)[reply]
@Peter James:, thank you very much! That's really useful data. It partly confirms my hunch, tho it doesn't look as bad as I thought.
I would love to be able to try it myself, but I am not quite sure that I would manage to replicate it. Could you be kind enough to post a link to one of the completed search forms you used? The links are on the results page at the bottom of the search box, labelled
Link to a pre-filled form for the query you just ran.
Thanks! --BrownHairedGirl (talk) • (contribs) 01:48, 23 September 2013 (UTC)[reply]
The page has two links: with and without auto-run for articles in at least 1 of the six categories. Peter James (talk) 18:03, 23 September 2013 (UTC)[reply]
Bless you, Peter James. That's great! --BrownHairedGirl (talk) • (contribs) 20:20, 23 September 2013 (UTC)[reply]

File Upload Wizard not working properly

Resolved

After uploading, the final page displayed to users has the following message: 

   Your file has been uploaded successfully and can now be found here:
   File:Example.jpg

Instead of "Example.jpg" there should appear the new file name. This final page has been modified recently and apparently the last programmer introduced this bug. It is serious, as the user may not know how to locate the file they just uploaded. Can someone please look into it? —Prhartcom (talk) 02:59, 22 September 2013 (UTC)[reply]

Fixed, I think. There was something about the server settings that had broken the originally intended notification mechanism for a while, but apparently this is now working again. Fut.Perf. ☼ 23:14, 22 September 2013 (UTC)[reply]
No, I just tried it, and it's still not working. —Prhartcom (talk) 04:11, 23 September 2013 (UTC)[reply]
I took a look at the HTML source, I know that is not the code driving the wizard, but I see something that may help: "Example.jpg" appears throughout, even in places where I saw that it was substituted with the real filename. If it helps, I see:
   Once uploading is completed, you will find your new file at this link::
   <span id="fuwSuccessLink"><b><a href="./wiki.php?slug=File:Example.jpg" title="File:Example.jpg">File:Example.jpg</a></b></span>

and then I see: 

   Your file has been uploaded successfully and can now be found here:
   <span id="fuwSuccessLink2"><b><a href="./wiki.php?slug=File:Example.jpg" title="File:Example.jpg">File:Example.jpg</a></b></span>

For the user experience, he sees the first example above substituted with his real filename but the second example above has failed to substitute. Could it be that the id="fuwSuccessLink" variable is correctly populated but the id="fuwSuccessLink2" is not? —Prhartcom (talk) 12:12, 23 September 2013 (UTC)[reply]

Cleared cache and the fix now works. —Prhartcom (talk) 13:05, 23 September 2013 (UTC)[reply]

What adds the [ ] in collapsible?

Hello! Hope you are having a great weekend!

I am interested in what section of the coding in MediaWiki:Common.js or MediaWiki:Common.css creates the [ ] in Collapsible elements?

If someone wanted to change [ ] to { } for example, or delete it all together, where can that be done?

I notice: 

var collapseCaption = 'hide'

var expandCaption = 'show';

Controls the words "hide" and "show".

THANK YOU! Igottheconch (talk) 11:34, 22 September 2013 (UTC)[reply] 

<span class="collapseButton">
    [
    <a id="collapseButton0" href="#">
        hide
    </a>
    ]
</span>
This means that it wasn't added in any .css using :before or :after. There is some code in MediaWiki:Common.js that creates these links and it looks like:
/* set up the words in your language */
var NavigationBarHide = '[' + collapseCaption + ']';
var NavigationBarShow = '[' + expandCaption + ']';
If you want to change them here on Wikipedia you would have to add something like the following to your common.js:
/* Change collapse links from [ * ] to { * } */
var currCollapseButton = $( '.collapseButton' ).html();
currCollapseButton = currCollapseButton.substring( 1, currCollapseButton.length - 1 );
$( '.collapseButton' ).html( "{" + currCollapseButton + "}" );
Let me know if this works for you (I'm not going to try it myself as it's just too insignificant for me to care about). If it doesn't, then I'll throw it in my sandbox skin.js and tweak it to work for you. Good luck! Technical 13 (talk) 12:56, 22 September 2013 (UTC)[reply]
  • Oh yeah, to make the [ ] just completely go away, you could use:
/* Change collapse links from [ * ] to * */
var currCollapseButton = $( '.collapseButton' ).html();
$( '.collapseButton' ).html( currCollapseButton.substring( 1, currCollapseButton.length - 1 ) );
Almost forgot you asked about that option... Technical 13 (talk) 13:11, 22 September 2013 (UTC)[reply]
According to mw:Manual:Collapsible elements, there are three types of collapsible elements. NavFrame (with div class="NavHead", and the only type with brackets as part of the link) uses:
var navigationBarHide = '[' + collapseCaption + ']';
var navigationBarShow = '[' + expandCaption + ']';
Collapsible tables (with span class="collapseButton" contains:
Button.appendChild( document.createTextNode( '[' ) );
Button.appendChild( ButtonLink );
Button.appendChild( document.createTextNode( ']' ) );
and there's jQuery.makeCollapsible, with span class="mw-collapsible-toggle mw-collapsible-toggle-expanded", but that doesn't appear to be in Common.js - it's part of ResourceLoader - and has "Collapse" and "Expand" buttons. Peter James (talk) 14:35, 22 September 2013 (UTC)[reply]
Thank you Thank you Thank you Technical 13. I appreciate it so much!
User:Igottheconch/Common.js
User:Igottheconch/Common.css
Attempt to try it:
User talk:Igottheconch/Common.js
It doesn't work :(
Any suggestions?
Thanks Peter :) Igottheconch (talk) 14:36, 22 September 2013 (UTC)[reply]
  • Okay, I think I see the issues...
    1. Blank User:Igottheconch/Common.css (edit the page and delete everything)
    2. Move User:Igottheconch/Common.js to User:Igottheconch/common.js (it is case sensitive, and that was my fault).
    3. Use one of the solutions above OR the other (you can comment them out one at a time with /* CODE */ to try each separately).
    4. After saving the page, make sure to WP:BYPASS your cache on User:Igottheconch/common.js then when that is done reloading switch to User talk:Igottheconch/Common.js and WP:BYPASS your cache there too.
  • I've tested both and the code itself is sound. Technical 13 (talk) 15:01, 22 September 2013 (UTC)[reply]
    • It works with NavFrame, by using "NavToggle" in place of "CollapseButton", but not with TOCs (toctoggle) or jQuery.makeCollapsible (mw-collapsible-toggle). Peter James (talk) 15:58, 22 September 2013 (UTC)[reply]
    • I've checked again, and the links are all "hide" and clicking leads to the top of the page instead of hiding anything. The elements and relevant scripts look identical. Peter James (talk) 18:54, 22 September 2013 (UTC)[reply]
    • The problem is that all links have the ID "collapseButton0" instead of "collapseButton1", "collapseButton2" etc. Peter James (talk) 19:06, 22 September 2013 (UTC)[reply]
This is exciting!
Progress!
[Show] becomes either:
{Show}
or
Show
But the collapsible table no longer works.
User talk:Igottheconch/common.js
Thanks Technical 13! Making progress!
Igottheconch (talk) 00:04, 23 September 2013 (UTC)[reply]
Peter James how would I apply what you wrote? I tried to replace CollapseButton with NavToggle and it didn't work :/ Igottheconch (talk) 00:09, 23 September 2013 (UTC)[reply]
I don't know how to make the links work with changed tags. The NavToggle option is only for a different type of collapsing box; the Wikipedia:NavFrame page has examples of both. The collapse still doesn't work, although with NavFrame boxes the IDs appear to stay correct so maybe that's not the cause of the problem. Peter James (talk) 18:12, 23 September 2013 (UTC)[reply]

accessdate= requires |url= (help)

My mistake. Facepalm Facepalm. Good work @Ryan Vesey: Tito☸Dutta 18:29, 22 September 2013 (UTC)[reply]

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

Ref 5 here. I have just read the news in today's The Times of India (hardcopy newspaper, not in web). For some reason, I can not find the web copy of the news — most probably it has not been crawled by Google. Just 1-2 day(s) ago, I cited an offline newspaper source. These accessdate= requires |url= (help) are annoying. Those are not available. The Toi Source here may be available in next 1-2 days (I mean when Google will crawl the page), but, for my other offline sources, URL etc will never will available. --Tito☸Dutta 16:59, 22 September 2013 (UTC)[reply]

Then don't give an accessdate. Accessdate is only relevant if you read an article online, it means that on the Accessdate, the article existed in the form that you read it. Ryan Vesey 17:01, 22 September 2013 (UTC)[reply]
  • I did not add any access date and that's why the error message is coming. --Tito☸Dutta 18:15, 22 September 2013 (UTC)[reply]
  • Yes you did, I removed the accessdate and the error is gone. Ryan Vesey 18:19, 22 September 2013 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

How to search for � (white question mark inside black diamond) in order to fix them?

I sometimes encounter the "�" character when I am cleaning up citations and other text. On my computer (Firefox 23 for Mac), it displays as a white question mark inside of a black diamond. As far as I can tell, it is inserted in place of a character that cannot be rendered and should be replaced by a regular character of some sort.

I would like to search for these characters in order to fix them in articles, but when I paste that character into WP's search, I get an error message that says "An error has occurred while searching: The search backend returned an error:", followed by nothing (i.e. no error text from the search back end).

Does anyone know of a way to search for these characters so that they can be fixed? Or, alternatively, are they indicative of a rendering problem on my computer?

To see an example of one of these, see this diff. – Jonesey95 (talk) 17:16, 22 September 2013 (UTC)[reply]

  • You are referring to the Specials (Unicode block) "U+FFFD � replacement character used to replace an unknown or unrepresentable character" and I am unaware of anyway to currently find these on wiki via a search engine. I suppose, if you were really bored and this "really" bothers you, it would likely be possible to write a bot (would require BAG approval) that will systematically go through all 60,895,882 pages on Wikipedia one at a time and look for the character itself or the associated HTML entity that creates them and adds the pages to a maintenance category that you could then work your way through and fix them. Good luck with that. :) Technical 13 (talk) 17:37, 22 September 2013 (UTC)[reply]
Technical 13 (talk) 18:26, 22 September 2013 (UTC)[reply]
Nice. So far it's found 320+ articles in 1.5 hours. I'll check back in a while to see how many it finds. A maintenance category might be worth the trouble; some of us WikiGnomes do get a desire to fix small things periodically, bored or not. It would take a while to clear out the category initially, but it wouldn't be much trouble to keep it clear after that. I don't know anything about creating bots yet, so I'll leave that to a fellow Gnome. – Jonesey95 (talk) 20:04, 22 September 2013 (UTC)[reply]
It looks like the list topped out at 826 articles. I'm guessing this is a complete scan of the Article namespace; a further scan of the Template namespace would probably turn up a few more. I have fixed about 100 of the articles already. I have pasted the rest of the list as wikilinks at User:Jonesey95/sandbox/diamondcharfix. Until a better list or a category exists, feel free to visit this page, fix the articles in question, and remove items from the list as they are fixed. – Jonesey95 (talk) 04:42, 23 September 2013 (UTC)[reply]
Technical 13, are you not aware that Betacommand/Δ is banned? I don't care if you think he's being "helpful", if you keep posting material from him here I will have you up at ANI for assisting block evasion. — Scott • talk 22:07, 23 September 2013 (UTC)[reply]
You may need to block a couple of others editors too then, including User:Writ Keeper, for this: #Looking for a tool. Just saying. ;) equazcion� | 22:12, 23 Sep 2013 (UTC)
Scott, I was not aware of that until a significant amount of time after the post was made. I thank you for assuming good faith in a civil non-threating way. Happy editing! Technical 13 (talk) 22:18, 23 September 2013 (UTC)[reply]
  • I just had a thought pop into my head, and thought here is as good of a place as any to ask. Would it be possible to create and edit filter that detected this character as added to a page (or article) and offered a warning? I bet most people don't even realize they are adding such a character. If they choose to save anyways, is there any way that an edit filter could add the page to a maintenance category (perhaps Category:Pages with non-standard characters or some such)? Just a couple ideas that popped in my head as a way to deal with characters like this (since they apparently have the ability to break things as evidenced below). Technical 13 (talk) 21:12, 22 September 2013 (UTC)[reply]

Edit history / watchlist side-effect?

Has anyone else noticed that replies to this section in the edit history or the watchlist don't have the little → character at the beginning of the edit summary to allow you to jump right to this section? Happens for me on both IE10 and FF24. Regards, Orange Suede Sofa (talk) 20:21, 22 September 2013 (UTC)[reply]

  • I was going to bring this up as well. I can confirm on FF24, and I can test on O12, O16, S5, IE7, and C29... Post results soon... Technical 13 (talk) 20:39, 22 September 2013 (UTC)[reply]
  • Confirmed on S5, C29, O16, and O12 (which incidentally doesn't show the symbol either, just an empty white box). Waiting for IE7 to load to test it, will report back later (usually takes a good 10-15 minutes to load IE and make it do something). Technical 13 (talk) 20:50, 22 September 2013 (UTC)[reply]
  • IE7 offers is confirmed as well... It also shows it as an empty white box like O12 did. Technical 13 (talk) 20:53, 22 September 2013 (UTC)[reply]
The presence of certain characters in section headings does break section linking. I suspect that � is one such character. --Redrose64 (talk) 20:55, 22 September 2013 (UTC)[reply]
Never noticed it before. But I have it (and it works) with Iceweasel 24.0b3-1 (webbrowser based on Firefox) (so its not completly removedChristian75 (talk) 21:00, 22 September 2013 (UTC)[reply]
  • Confirmed Safari 6. I'd agree with Redrose. Ignatzmice•talk 00:44, 23 September 2013 (UTC)[reply]

Space, the Wikipedia frontier

This topic is not to do with Star Trek. Windows used to end where the text for when the page was last modified. However, I am finding, at least when using Chrome, there is a whole page's worth of space underneath the article end. Is this due to technical limitations? Simply south...... cooking letters for just 7 years 19:03, 22 September 2013 (UTC)[reply]

See "#Scrolling past the bottom of the page..." above. – Jonesey95 (talk) 19:54, 22 September 2013 (UTC)[reply]

Watchlist message

I just noticed when visiting my watchlist, there is a message stating:

1,552 pages on your watchlist, not counting talk pages. Pages that have been changed since you last visited them are shown in bold.

That is obviously not true for people like me who use a watchlist customization and no longer have the default bold for unvisited changes. This is probably not really an issue for those editors who are able to customize their watchlist and know they use a customization, so I don't know whether something should or could be done about it. -- Toshio Yamaguchi 14:56, 23 September 2013 (UTC)[reply]

Interesting. I just visited my watchlist again, and now it says

You have 1,552 pages on your watchlist (excluding talk pages).

Pages that have been changed since you last visited them are shown with a green bullet.

-- Toshio Yamaguchi 15:01, 23 September 2013 (UTC)[reply]

The gadget "Display pages on your watchlist that have changed since your last visit in bold" is consistent. It makes the pages bold, and writes that they are bold. If your watchlist customization is made by adding personal code to User:Toshio Yamaguchi/vector.css and not by selecing a preference or importing a maintained script then it's up to yourself whether to add code which describes your customization. See MediaWiki:Gadget-WatchlistChangesBold.js for the gadget code to say the pages are bold. PrimeHunter (talk) 23:09, 23 September 2013 (UTC)[reply]

Notification of RfC: Should CSD: be an exception to the immunity of pseudo-namespaces to deletion?

There is an ongoing RfC going on at Wikipedia:Requests for comment/CSD pseudo-namespace that anyone visiting this page may be interested in. Technical 13 (talk) 16:39, 23 September 2013 (UTC)[reply]

This isn't a technical issue. -- WOSlinker (talk) 17:17, 23 September 2013 (UTC)[reply]
It is a gigantic waste of people's time, though, technically. — Lfdder (talk) 18:04, 23 September 2013 (UTC)[reply]
It's not ongoing any more; in fact, there is now a MFD to remove the RfC page entirely. -- John Broughton (♫♫) 20:21, 23 September 2013 (UTC)[reply]
  • This RfC is being redrafted, and will be reposted. The technical importance of it is that namespaces are a technical entity and I felt there may be technically inclined people interested in the discussion. Technical 13 (talk) 20:31, 23 September 2013 (UTC)[reply]

VisualEditor now opt-in only for all users on English Wikipedia

All,

This is a quick note to announce that we have reverted the English Wikipedia's configuration of VisualEditor to "opt-in" mode, from the "opt-out" mode that it has been since 1 July. This means that all users on this wiki will now only have access to VisualEditor if they have actively opted-in. We will continue to develop VisualEditor for all wikis, working with those in opt-out mode and users from those opt-in wikis who give their feedback.

Since it is apparent that the English Wikipedia was going to go forward with this plan, as custodians of the site it is our responsibility to find a less damaging and more consistent method for execution of the stated goals. We find it gravely disappointing that known-broken code was enabled for all users despite direct warnings to the participants of the damage it would cause.

Additionally, there is a desperate need to de-escalate this situation. Tempers around VisualEditor have been vitriolic for some time, and we seek a return to a calmer, more collegial working environment.

We continue to believe that this is a mistake: removing site functionality from new users who have expressed that VisualEditor makes their initial edits easier. We believe that the English Wikipedia will, in the long run, be damaged by this decision, but we cannot justify continuing to exhaust staff time (read: donors' funds) to this issue.

Yours,

Jdforrester (WMF), VisualEditor Product Manager 23:21, 23 September 2013 (UTC)[reply]

Hm. You say you want to de-escalate and seek calmer tempers while still maintaining that this is not only a poor decision, but the site will be damaged. While I appreciate the action taken, this notice seems to contain bi-polar sentiments. Killiondude (talk) 23:28, 23 September 2013 (UTC)[reply]
@Killiondude: Sorry if my comment seems confusing; given the extensive comments from us about how the change would break the site, I felt that it was clear what I meant (e.g. an option to opt-in that doesn't work any more if you don't have any edits yet), but for users not involved in the minutiæ it was probably not obvious. My apologies. Jdforrester (WMF) (talk) 23:33, 23 September 2013 (UTC)[reply]
Please retract the accusation that I deployed "known broken code", Jdforrester. I took the feedback from Catrope and implemented it within the limits of what could be done from the client side, repairing all observable defects. I published it for review, and specifically invited Catrope to comment on the changes twice. The only possible remaining characteristic that could be described as "broken" was that it required a new account to make at least one edit with the wikitext editor before the editor could enable VE. No apparent fix for that was forthcoming, and one could argue that demonstrating the competence required to use a talk page was a feature, not a bug.—Kww(talk) 23:34, 23 September 2013 (UTC)[reply]
Replied on Wikipedia:VisualEditor/Feedback.
(edit conflict × 2) @Jdforrester (WMF): You say "known-broken" code when one of your developers actually helped fix it. You were given two options - stubbornly keep it broken and let it go in as broken, or help fix it. You chose the stubborn one, and now are saying it's disappointing? You should be disappointed in yourself - thinking the community would not implement community consensus when it was able to do such. (post EC addition) You were asked for your help to disable it server side. You refused. You were asked, encouraged, to give input and fixes to the code. You refused. Thus, it was implemented as-is. I understand it may not have worked the best it could have, but it got the consensus implemented (one way or another), didn't it? ~Charmlet -talk- 23:36, 23 September 2013 (UTC)[reply]
As far as I understand, all the coding concerns brought by the WMF and its developers were addressed and corrected prior to implementation. I state this merely for the record. I suppose it is comforting to know that there is at least some point where the WMF will choose to respect the consensus of its community despite their disagreement with it, even though they had to essentially be dragged there kicking and screaming. It is also disappointing that their final word on the matter essentially re-enforces their original position, which tells us that although this particular incident is resolved for the time being, nothing has been learned, and we can probably expect more of the same in the future. equazcion� | 23:38, 23 Sep 2013 (UTC)
@Charmlet and Equazcion: It is true that the first round of issues that we highlighted with the hack were fixed, yes - for which we are thankful. It would have been even worse had they not. However, code review doesn't work like this - it's not "one and done". You get reviews until everyone is happy, and do not deploy until it's been tested. Also, "You were asked for your help to disable it server side. You refused." is wrong - I said that I thought this was a very bad idea, gave reasons, and sought a discussion about alternatives. However, my request for partnership and working together was ignored in this case, which is indeed disappointing. And this is not remotely our "final word" on VisualEditor; we're going to be working on this for many years to come. :-) Jdforrester (WMF) (talk) 23:50, 23 September 2013 (UTC)[reply]
This is a contradictory statement. You are essentially saying you did refuse to disable it server-side. The fact that you offered reasons and wanted to discuss alternatives doesn't change that. Further, you appear to think that once the community determines its consensus, the community must then enter into a new consensus discussion with the WMF. I'm unclear on where this belief comes from. equazcion� | 23:59, 23 Sep 2013 (UTC)
I find it gravely disappointing that we got to the point where we had to implement it ourselves because WMF would not despite an overwhelming consensus. I also find it gravely disappointing that this is coming across as "we've been blackmailed into doing but we're still right" rather than accepting what the community wants. I find it gravely disappointing that the WMF has wasted significant amounts of money on VE due to not doing the blatantly obvious thing of engaging the end users at an early stage. I find it gravely disappointing that the WMF is still blaming us for this whole mess while seemingly not even bothering to look at what it did wrong in this implementation. Unfortunately I also find it gravely disappointing that you were appointed to lead this project as it seems to me you're one of these people that are always convinced they're right and so won't listen to other people's views and that's not ideal in someone that's leading a project such as this. Dpmuk (talk) 23:55, 23 September 2013 (UTC)[reply]
@Jdforrester (WMF): You were asked to make the change serverside, yet you didn't. Nitpicking over my wordchoice doesn't help the damage control of the community's trust and opinion of the WMF that should be going on now. An actual apology should be forthcoming immediately, one that does not double back on the comments that got us to having to use the code in the first place. (by the way, I do expect the actual apology, and I expect it soon. Stop digging the hole deeper, and start trying to climb out with what's left of the WMF's dignity) ~Charmlet -talk- 23:58, 23 September 2013 (UTC)[reply]
@Charmlet: Fixing your comment: "You were asked to make the change serverside, yet you didn't yet." I am sorry that our seeking a discussion in a carefully-worded suggestion of ways forward came across as a refusal to engage; that was not my intent, and not my objective. Jdforrester (WMF) (talk) 00:05, 24 September 2013 (UTC)[reply]
You sought a discussion after the discussion had already concluded. That's too late. You should have come forward at the beginning and tried to compromise. Not after the consensus was there. I find it hard to believe you ever would have made the server-side change in absence of this incident. I'm sure the rest of the community would agree. I'm still waiting for an apology that isn't "you're all incompetent, but we'll do your stupid change anyway so we don't look bad"-esque, which this one is (don't even think of trying to weasel your way around that, it's what it amounts to and you all know it). ~Charmlet -talk- 00:09, 24 September 2013 (UTC)[reply]
(edit conflict) LOL at "You get reviews until everyone is happy, and do not deploy until it's been tested" coming from the 'VisualEditor Product Manager'. – iridescent 23:58, 23 September 2013 (UTC)[reply]
Oh, the irony of that. I hadn't spotted that until you pointed it out. So everyone was happy with VE before you deployed it. Who did you ask? Just yourself? Dpmuk (talk) 00:02, 24 September 2013 (UTC)[reply]
Jdforrester:
  • "we have reverted" - by which you mean the community has reverted. This was not a WMF action and it is disgraceful for you to imply otherwise.
  • "gravely disappointing" - the community is gravely disappointed with the way the WMF has handled this situation, from start to finish.
  • "known-broken code" - an adequate description of VisualEditor with its hundreds of bugs spraying errors into the site.
  • "a more collegial working environment" - like one in which you listen to the community that you work for?
  • "We believe that the English Wikipedia will, in the long run, be damaged by this decision" - there's that "we" again; but t:his time it refers to you only.
  • "we cannot justify continuing to exhaust staff time (read: donors' funds) to this issue." - that's your fault, for a months-long saga of lack of adequate testing, bargain-basement change management, mangled rollout procedures, and inadequate and/or inappropriate communication with your major stakeholders. Don't try and recast this as having your time wasted; you have collectively wasted a vast amount of the community's time on this farrago. This is a colossal fuckup on all counts, and now you're going to reap what you've sown.
Your response here is absolutely characteristic of the condescending and dismissive attitude you have displayed towards the community throughout all of this. I for one will not shed a tear if you lose your job over this and are never seen around here again. — Scott • talk 00:02, 24 September 2013 (UTC)[reply]

Article wizard

Was just reading an article in my local free paper about how the Wikipedia:Article wizard top tabs dont work. Not sure if its always been like this but the article mentions how complicated the page is. "Article wizard where to next?" - was the title of the article. -- Moxy (talk) 23:55, 23 September 2013 (UTC)[reply]

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