Wikipedia:Village pump (technical): Difference between revisions

Policy

Technical

Proposals

Idea lab

WMF

Miscellaneous

• Table of contents
• First discussion
• End of page
• New post

Shortcuts

• WP:VPT
• WP:VP/T
• WP:TECHPUMP
• WP:PUMPTECH

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 securitywikimedia.org or filed under the "Security" product in Bugzilla.

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

view · edit Frequently asked questions (see also: Wikipedia:Technical FAQ) Click "[show]" next to each point to see more details. If something looks wrong, purge the server's cache, then bypass your browser's cache. This tends to solve most issues, including improper display of images, user-preferences not loading, and old versions of pages being shown. No, we will not use JavaScript to set focus on the search box. This would interfere with usability, accessibility, keyboard navigation and standard forms. See task 3864. There is an accesskey property on it (default to accesskey="f" in English). Logged-in users can enable the "Focus the cursor in the search bar on loading the Main Page" gadget in their preferences. No, we will not add a spell-checker, or spell-checking bot. You can use a web browser such as Firefox, which has a spell checker. If you have problems making your fancy signature work, check Help:How to fix your signature. If you changed to another skin and cannot change back, use this link. Alternatively, you can press Tab until the "Save" button is highlighted, and press Enter. Using Mozilla Firefox also seems to solve the problem. If an image thumbnail is not showing, try purging its image description page. If the image is from Wikimedia Commons, you might have to purge there too. If it doesn't work, try again before doing anything else. Some ad blockers, proxies, or firewalls block URLs containing /ad/ or ending in common executable suffixes. This can cause some images or articles to not appear. For server or network status, please see Wikimedia Status. If you cannot reach Wikipedia services, see Reporting a connectivity issue.

« Archives, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213

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]
            • Whoops, I've already filed the bug yesterday and forgot to link it. Here it is: https://code.google.com/p/chromium/issues/detail?id=291616 (I'm hoping someone will handle this for both Blink and WebKit). Matma Rex talk 12:39, 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]

I put the fix in Common.css in anticipation of the patch being deployed. — Edokter (talk) — 20:04, 24 September 2013 (UTC)[reply]

@Hoo man: Is it safe to assume that since the "status" on the link you provided says "merged" that the patch went through? — -dainomite   22:49, 29 September 2013 (UTC)[reply]

Yes, the patch should be live here now - Hoo man (talk) 16:59, 30 September 2013 (UTC)[reply]

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

Theres a glitch where most pages are not showing the last few edits for me. its showing me an old version. Why is that? How to fix it? Pass a Method talk 09:48, 25 September 2013 (UTC)[reply]

Exactly the same for me above. And it's not clearing over time. I'm seeing pages days old now. Deleting all local cached internet files does not clear it. Purging Wikipedia cache does not clear it. Sometimes it randomly clears itself, and then a little while later goes back to showing the old pages. Something is wrong. 86.160.220.63 (talk) 11:27, 25 September 2013 (UTC)[reply]

If this is still a problem, do you have a link where I could see it? --AKlapper (WMF) (talk) 12:08, 26 September 2013 (UTC)[reply]

Well, you may not see it (depending, I suppose, on which server you connect to??). Also, the suggestion is that you won't see it anyway if you are logged on. Two example pages where I am repeatedly seeing stale content:

http://en.wikipedia.org/wiki/Talk:USS_Skate_(SSN-578) (do not see my edit of 03:37, 24 September 2013)

http://en.wikipedia.org/wiki/Wikipedia:Miscellany_for_deletion/Wikipedia:WikiProject_Containers (do not see JohnCD's edit of 17:36, 25 September 2013‎)

Both these were up to date earlier today when I checked; now they are both back to being stale. This page (VP/T) appears to be up-to-date as I write, but has been very variable over recent days. From time to time I see an up-to-date page; then it goes back to being a random old version. 86.160.222.175 (talk) 17:40, 27 September 2013 (UTC)[reply]

copied this from Wikipedia:Help desk --Frze ^{> talk} 11:31, 25 September 2013 (UTC)[reply]

span class="notranslate" onmouseover="_tipon(this)" onmouseout="_tipoff()

How is it possible to produce such errors? Which button was used?
[1] [2] [3] [4] [5]
Thanks. --Frze ^{> talk} 05:12, 25 September 2013 (UTC)[reply]

Hi Frze. This one is still a mystery to me, perhaps others can comment, but until then I am going to assume that the people that made these edits got their content by doing a copy/paste from a website, capturing everything including the JavaScript and HTML code. I don't think the MediaWiki software produced this by clicking any button on Wikipedia. I'm glad you reverted it. —Prhartcom (talk) 05:56, 25 September 2013 (UTC)[reply]

Hello —Prhartcom - I don't think that this is made by Copy and Paste, because I'm working on categories Pages with incorrect ref-formating/missing reference list, and this error already happened hundreds of times... --Frze ^{> talk} 08:36, 25 September 2013 (UTC)[reply]

Could this be yet another of the Visual Editor malware behaviours? Roger (Dodger67) (talk) 09:18, 25 September 2013 (UTC)[reply]

I think I may have solved the mystery! It looks like these IPs are perhaps copypasting text translated into English from Google Translate. If you take a look at this article discussing Google Translate, at the very end it says that "Upon copying the text ... I noticed that both languages were put onto the clipboard. Intrigued, I had a look at the source code ... both the original texts are included 'side-by-side' in the source code, with the original text enclosed between "google-src-text" <SPAN> tags," which is a lot like what we see in the examples you provided. Sophus Bie ^(talk) 09:19, 25 September 2013 (UTC)[reply]

This appears to happen if you let Google Translate to translate you a Wikipedia page, and then edit the page from the translated text out. Try and error ... --Frze ^{> talk} 09:51, 25 September 2013 (UTC)[reply]

Aha! That's pretty interesting! Do you think perhaps one of us should bring this issue up at WP:Village Pump (technical)? If you've run into it hundreds of times, then it's probably going to keep on happening. The quickest fix I can think of would be for someone to create an WP:Edit filter for edits that turn out like that. Sophus Bie ^(talk) 10:08, 25 September 2013 (UTC)[reply]

Tried and errored: It is impossible to edit the page from the translated text out directly in Google translator. Only by COPY AND PASTE from Google translator.
What I do is clearing up as little "Wiki Janitor" a lot (thousands) of petty minor ref-errors of other editors, pages with missing references list or incorrect ref-formating. I checked such errors and simply reverted (by <undo> or <rollback>), but User:Acalamari told me not to do so. They are good-faith accidents and should have been reverted with a proper explanation.
Now we know the cause of this errors. There is no need for action in my opinion. Is it very difficult to detect such errors automatically?? It's going to keep on happening. But if a filter can be programmed to detect: <span class="notranslate" onmouseover= and stop saving (like website spam filter) instead saying: Do not use Google Translator text. It causes errors. - it would be helpfull. Wikipedially Yours Frze ^{> talk} 11:08, 25 September 2013 (UTC) Sorry for my limited language skills.[reply]

• Cannot prohibit Google Translate as a technical restriction: There are too many acceptable uses of text from Google Translate, such as alternative song titles in other languages, and so we cannot claim a technical reason to forbid it. In some objectionable cases, Google Translate might have been used to improperly generate text from a plagiarized section; however, other users have been translating original text from other-language wikipedias, to have English-language pages added/expanded here. Restrictions might have to be merely voluntary warnings written into various essays, such as "wp:About translating German Wikipedia" or others. I am not seeing a valid use of an edit-filter as a likely method. -Wikid77 14:57, 25 September 2013 (UTC)[reply]

Special:AbuseFilter/345 is the logical place for this. This filter catches a range of strange html added by various browser extensions. I've added "notranslate" to the search clause which should hopefully pick it up. --User:Salix alba (talk): 17:07, 25 September 2013 (UTC)[reply]

That ought to catch it. Thanks, Salix! Sophus Bie ^(talk) 00:45, 26 September 2013 (UTC)[reply]

Thanks too. BW Frze ^{> talk} 04:46, 26 September 2013 (UTC)[reply]

Google translator text detector is working well. --Frze ^{> talk} 13:45, 27 September 2013 (UTC)[reply]

>>>- not working well: see examples

• 14:52, 27 September 2013 https://en.wikipedia.org/w/index.php?title=Grohe&diff=574747274&oldid=568425516
• 02:49, 28 September 2013 https://en.wikipedia.org/w/index.php?title=Savages_(band)&diff=574821568&oldid=574151855

--Frze ^{> talk} 05:44, 28 September 2013 (UTC)[reply]

How do you mean not working? It tagged both those edits which is what it is supposed to do. Do you want it to block the edit? That would need a separate edit filter.--User:Salix alba (talk): 13:18, 28 September 2013 (UTC)[reply]

I currently have my preferences set to use http rather than https but now when ever I try to load a page it starts off showing me as not logged in and so not using my settings (I use monobook rather than vector so it's pretty obvious), then as logged in and showing the message "Central login You are centrally logged in as Dpmuk. Reload the page to apply your user settings." Reloading does not apply instead we just repeat the whole process over again. It appears to me that I'm having to be re-logged in every time I load a page using http. I'm using Firefox 23.0.1. Any ideas? Dpmuk (talk) 18:39, 25 September 2013 (UTC)[reply]

This sounds like #Cookie not being baked (log in annoyance). --Redrose64 (talk) 23:05, 25 September 2013 (UTC)[reply]

I'm not so sure they're the same thing. Anyway, this sounds exactly like the issue that should have been fixed in gerrit:85776. Not sure if that's deployed yet. --Jeremyb (talk) 05:02, 26 September 2013 (UTC)[reply]

gerrit:85776 appears to be deployed. However, see Template:Bug: there may be a caching issue going on where the new Varnish caches aren't properly varying on the presence of the forceHTTPS cookie. BJorsch (WMF) (talk) 13:52, 26 September 2013 (UTC)[reply]

I'm having a similar issue over the last few days. It only involves Commons. Every time I shut down my computer, Commons logs me out. No matter even if it's just a quick "Restart" of my computer. Commons is reading that as logging off them. I've checked my Cookies, and I'm not deleting any that are for Commons. But I've been seeing a couple of new cookies incubator.wikimedia.org and login.wikimedia.org; however, I never delete those. My Preferences say I'm logged in on 37 active sites. — Maile (talk) 00:07, 27 September 2013 (UTC)[reply]

• It's worse than I thought. It's not when I reboot my system that makes it happen. I just logged in to Commons. Looked at English Wikipedia in another window. When I came back to Commons, it had booted me out again. But only Commons. And my Preferences still say I'm logged in on 37 active sites. — Maile (talk) 00:58, 27 September 2013 (UTC)[reply]
• Buggers! I just tested it again. Logged in to Commons. Clicked on a Wikipedia page. Came back to Commons, and it had booted me out. I'm not feeling the love from Commons anymore.— Maile (talk) 01:02, 27 September 2013 (UTC)[reply]

If you've ever felt an emotion besides "genocidal rage" when dealing with commons, consider yourself lucky. VanIsaac_{WS Vex}^contribs 01:08, 27 September 2013 (UTC)[reply]

The "37 active sites" thing in Preferences is a count of the number of sites that have had your details (login ID, password, email address and a small number of other things) copied from your original Wikimedia site, see WP:SUL. It has no knowledge of the state of cookies on your machine. You'll find that "37 active sites" periodically increases, but almost never gets reduced. I suspect that if you click the Manage your global account link, and then refresh your prefs, the figure will jump. Mine currently shows "Your account is active on 152 project sites.", although I've edited on no more than 60 - I don't think I've visited more than about 10-15 others. --Redrose64 (talk) 10:19, 27 September 2013 (UTC)[reply]

Understood. But I did, upon your suggestion, click on Manage your global account link, and refreshed my prefs-nothing changed. It still says 37 active sites. Like you, that number does not reflect sites I've visited, which in my entire edit history is a mere tiny fraction of that number. I don't believe this is about my cookies, either. Including the two I added yesterday, my "allowed" list of cookies for Wikimedia include incubator.wikimedia.org, login.wikimedia.org, commons.wikimedia.org, meta.wikimedia.org, wikimedia. What am I missing, and why would this kick up in the last few days? Even with all those cookies, Commons logs me out everytime I look at another page. — Maile (talk) 11:54, 27 September 2013 (UTC)[reply]

At commons:Special:Preferences, make sure you have "Remember my login on this browser (for a maximum of 30 days)" checked, also make sure that the "Always use a secure connection when logged in" setting matches that on Wikipedia. If you need to change the latter, log out afterwards and log in again. --Redrose64 (talk) 14:12, 27 September 2013 (UTC)[reply]

Yeah, they were both checked in Commons preferences, so that isn't the issue. And when I login on Commons, "Keep me logged in" is always checked. This is very odd. — Maile (talk) 15:03, 27 September 2013 (UTC)[reply]

• In regards to Commons, they must be working on something over there. There's a hiccup of sorts over there. If I go to that page, it loads as not logged in. After a few seconds, it automatically logs me in right in front of my eyes, and tells me "You are centrally logged in as Maile 66. Reload the page page to apply your user settings." I reloaded the page, and it shows me logged out, repeats the identical process of logging me in with the same message about being centrally logged in and needing to reload the page. It showed my skin preference as Monobook, but what I was seeing was Vector. I changed it to Modern skin and it showed it as saved. But it's still appearing in Vector. They must be jiggling the system over there.. — Maile (talk) 21:19, 27 September 2013 (UTC)[reply]

I've hesitated to post this until now -- it seems such an obvious idea that it seems like it must have come up before, but there's nothing I can find in the archives.

Why do I have to choose between Show Preview and Show Changes? Why can't I push one button and get both at once? EEng (talk) 03:12, 26 September 2013 (UTC)[reply]

Hmmm... those are reasonable questions. I'm not sure. I guess as the individual actions were implemented, developers thought one action per button would be clearest/cleanest.

Special:Preferences#mw-prefsection-editing has some preview-related options, but none that probably do what you want. I searched around Bugzilla for a relevant bug, but didn't see anything. You should consider filing a bug there. I'm not sure a single button is the right answer, but re-thinking the overall workflow might be nice. (Arguably this is what VisualEditor is doing, but we can continue to improve the source/wikitext editor, of course.) --MZMcBride (talk) 06:59, 26 September 2013 (UTC)[reply]

At least for me when I do show changes, I get the diff at the top and the rendered page below it. Werieth (talk) 13:10, 26 September 2013 (UTC)[reply]

Are you sure you're not looking at a diff (off your watchlist etc.)? Those do show diff + rendered page (though of course no edit box). Otherwise, I sure would like to know how you get that to happen! EEng (talk) 13:59, 26 September 2013 (UTC)[reply]

Werieth, are you sure you're not using a gadget like wikiEd or something else? πr² (t • c) 15:29, 26 September 2013 (UTC)[reply]

So is there, or is there not, some whatchamajigger thing I can install to get such functionality? Or should I make a request somewhere? I'm not foolish enough to predict no one will find fault with such an idea, but I venture to say it can't be too controversial. EEng (talk) 16:08, 28 September 2013 (UTC)[reply]

You can file a bug in Bugzilla, if there isn't one already. It's possible that a JavaScript gadget or MediaWiki extension can already do this. This could also possibly go into MediaWiki core. A Bugzilla bug will properly track the idea, regardless of resolution. --MZMcBride (talk) 03:24, 30 September 2013 (UTC)[reply]

This one has made me scratch my head for months.

In the edit toolbar on the .js page, how do you add {{subst:PAGENAME}} to multiple sections of the same button?

Because when you add {{subst:PAGENAME}} to the .js edit toolbar page, then click the edit toolbar, the .js page shows up, not the name of the page...

Thanks! Igottheconch (talk) 15:30, 26 September 2013 (UTC)[reply]

I'm not completely sure what you're asking, but try replacing

{{subst:PAGENAME}}

by

{{" + "subst:PAGENAME}}

...or by

" + mw.config.get('wgTitle').replace(/_/g, ' ') + "

(use wgPageName instead of wgTitle if you want the namespace, like FULLPAGENAME. The .replace(...) part is not needed with wgTitle, but is with wgPageName)

πr² (t • c) 15:39, 26 September 2013 (UTC)[reply]

The easiest option may actually be to just add // <nowiki> in the first line of the JS, if that's what you mean. πr² (t • c) 16:39, 26 September 2013 (UTC)[reply]

hi pir! looks like we are following each other from wikiproject to wikiproject.

I found: https://meta.wikimedia.org/wiki/Help:Recursive_conversion_of_wikitext

thank you for your help! Igottheconch (talk) 16:48, 26 September 2013 (UTC)[reply]

DAMN. every time I edit my .js page, the "subst" disappears. Igottheconch (talk) 16:58, 26 September 2013 (UTC)[reply]

@Igottheconch: try adding a separate line to the beginning like this: // <nowiki>. Does that fix it? πr² (t • c) 17:08, 26 September 2013 (UTC)[reply]

Looks very promising pir. :) Igottheconch (talk) 12:59, 28 September 2013 (UTC)[reply]

Hey all,

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

Following the regular MediaWiki deployment roadmap, this should be deployed here (for opted-in users) on Thursday 3 October.

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

Jdforrester (WMF) (talk) 18:25, 26 September 2013 (UTC)[reply]

So, let's see, currently the dragging-and-dropping of images totally sucks in many major ways, so you are now going to enable it for infoboxes, references, and reference lists too? Seems rather ass-backwards to me... (by the way, since this isn't rolled out to here yet, I tried it on [6], which to my immense amusement contains tons of visible wikitext in the VE. Hypocrisy muych? Anyway, as expected, it sucks.)

I've set you (WMF) a challenge at [7]. It's solvable if you are creative, but it's hardly user-friendly... Fram (talk) 07:31, 27 September 2013 (UTC)[reply]

I have posted more feedback at WP:VEF, I'll repeat my most recent post here:

I finally found a MediaWiki page with references, and as could be expected but contrary to what was announced, reflists can not be moved.[8] Probably a good thing, but if even the official wmf announcements can't be trusted anymore as to what is includd and what isn't, then one wonders how much these things have been tested (assuming they have been tested at all).

Proposal: the WMF doesn't issue any updates, new versions, new rollouts, ... for the next 3 months, and then comes back with some seriously tested actual progress. Please don't bother us with weekly unreliable announcements of very dubious improvements, it will not create any goodwill at all. Fram (talk) 10:35, 27 September 2013 (UTC)[reply]

Hi Fram, there is no way for the VisualEditor dev team to hide.  :) VE is an open source project: any progress happens publicly in the MediaWiki / Wikimedia Tech context anyway. Release soon & release often + document your releases are just good OSS practices - why change them? I personally think that getting here all releases and the related documentation that all the rest are getting is a good thing. You can always ignore them. Meanwhile, others may want to keep using, testing and contributing to a better VE.--Qgil (talk) 19:11, 27 September 2013 (UTC)[reply]

... On the other hand it is very good that you put so much time testing. I tried to map the problems you describe with Bugzilla reports:

• Template:Bug - Translate extension's <translate> and <tvar> fail to appear in extensiontags (PATCH_TO_REVIEW)
• About dragging, looking at your challenge I believe you mean Template:Bug - Visual Editor: editing window does not scroll when dragging (ASSIGNED)
• About reflists, probably Template:Bug - VisualEditor: Drag-and-drop of content (text, transclusions, references, …) to move it (ASSIGNED)

I'm going to mention your feedback there. Sorry for my ignorance: do you have have a username in Bugzilla? Thank you again for your feedback.--Qgil (talk) 23:18, 27 September 2013 (UTC)[reply]

"You can always ignore them". No, we can't. VE created thousands of problems on pages, without the editors wanting or even noticing those. Many manhours have been spent tracking these down and correcting them, but only some of them have since been prevented by the WMF VE updates. Now, they are introducing new ones (or expanding old ones). Furthermore, "document your releases"? They don't update the documentation, and the things they claim this release will solve are not correct, as a very short test proved. As for my "challenge", the dragging doesn't scroll is also a problem, the challenge though was to get a template like "languages" at the very bottom of the page. You can't do this by normal editing in VE (it's of course no problem in wikitext), you have to use tricks or workarounds.

Usually, in Open Source (or anywhere), new releases are made available, and users choose whether they want them or not. Not so here, the developers (the WMF) force them upon us, whether we want them or not, whether we let them now before that they are much too buggy and that they create more errors than they solve (like e.g. with this release). Thorough testing before you release is also a good practice, but one the WMF hasn't heard of, it seems. These aren't exceptional things I tested, these are normal editing practices. Why can I find them so soon on my own when the WMF apparently can't but feel that this is ready for release?

Have you people at the WMF (and please include WMF in your signature, it indicates your COI status as a "paid editor" more clearly) not learned anything from the last few months? Apparently not... And no, I'm not interested in Bugzilla, the treatment I have received there (and have seen others receive) from WMF people has thoroughly disgusted me. If you force releases upon us here, against our wishes, and with known bugs in them, then I'll complain about them here as well, until sometime finally changes at the WMF (the general culture, the interaction with the Wikipedia versions, the priorities, and perhaps some of the personnel as well). For the moment, you are not helping us at all, you are just a big nuisance. Fram (talk) 15:30, 28 September 2013 (UTC)[reply]

Fram, I can help with problems in Bugzilla (just like many others do). Please CC me in any report you feel you haven't been treated properly. Nobody is perfect in Bugzilla, just like nobody is perfect in wiki discussion pages. But still, Bugzilla is an efficient tool when it comes to handle (discuss, push, triage...) software bugs and feature requests. I can also help forwarding feedback originated here in Bugzilla (just like many others do). I cannot help discussing how new features are deployed to English Wikipedia since I'm just a humble "technical contributor coordinator" at mediawiki.org and surroundings, with no opinion and even less decision on this topic. Still, hopefully we can work together. :) I came here after seeing your edits at mw:Groups and I do appreciate the time you take testing. Thank you again.--Qgil (talk) 04:47, 29 September 2013 (UTC)[reply]

I hate the English "you" :-) Often, when I'm criticizing "you", I mean you at the WMF plural, not you personally. So e.g. "you are a big nuisance" wasn't meant to read "Qgil is a big nuisance", but "the WMF is a big nuisance" (wrt to VE, their releases, their interactions with us here), despite people from the WMF trying to interact positively. I don't know whether it makes my message more palatable, but rest assured that I am fed up with the WMF as an institution, and one or two people in it, not with all people there. Fram (talk) 06:59, 30 September 2013 (UTC)[reply]

This is now being discussed at Wikipedia:VisualEditor/Feedback#Visual Editor/Status. Apparently no one at WMF / MediaWiki believes it important that these status reports are factually correct. Fram (talk) 15:51, 30 September 2013 (UTC)[reply]

I really don't see how a personal consideration that "people who wrote the reports should be the ones correcting them - except if they ask someone else to" can be read the way you read it, but anyway I'm here only to update a status of a bug mentioned above :) --Elitre (talk) 17:18, 30 September 2013 (UTC)[reply]

Well, what if the "people who wrote the reports" are not inclined to? Do they WP:OWN that page? Apparently they do, and no one else is allowed to alter these pages. Or does everyone at MediaWiki simply agree that these "press releases" are just that, PR, and shouldn't be correct. If so, then please don't bother posting them here anymore, we don't use VE anyway and don't trust the WMF anymore, so... 18:25, 30 September 2013 (UTC)

This is the technical village pump on the English Wikipedia. There are few better places to post such questions. We generally take the view that more information and transparency is better and that security through obscurity in design and development decisions should be minimized. I won't un-archive this discussion, but I've started a new one at User talk:BikeRider95. --MZMcBride (talk) 04:32, 27 September 2013 (UTC)[reply]

I don't know enough about the MediaWiki codebase to comment on specific security issues, but I do know that the WP:BEANS metaphor does not extend well to software security practices. Unless someone decides to post an open MediaWiki exploit (instead of reporting it to security@wikimedia.org), I can't see any harm in having this discussion here. — Mr. Stradivarius ^{♪ talk ♪} 11:08, 27 September 2013 (UTC)[reply]

Just a quick heads up that there's a known issue where cached special pages, such as Special:DoubleRedirects (used by bots to fix double redirects), are not being updated. The relevant bug on Bugzilla is at https://bugzilla.wikimedia.org/show_bug.cgi?id=53227. wctaiwan (talk) 20:28, 26 September 2013 (UTC)[reply]

Aha, that likely explains the reason for the issue #Are double redirects still being fixed by bots? raised earlier here. Wbm1058 (talk) 20:53, 26 September 2013 (UTC)[reply]

Reply - Does anyone know when this might be fixed? --Jax 0677 (talk) 14:13, 27 September 2013 (UTC)[reply]

In Internet Explorer 10 the AutoComplete function can be set by use of Tools → Internet options → Content → AutoComplete, click on Settings. Then you check/uncheck those items you want to AutoComplete. My "Forms" box is checked, which governs a dropdown box for the Edit summary field. I have found that this does not work when I login to Wikipedia on a secure server. There may be other forms that don't auto-complete, as well. Since I make many edits that require the same edit summary, the absence of the AutoComplete functionality is a dramatic slowdown for me. I don't mind having to login securely...

• I do mind having to type the same edit summary over and over and over!!!

Any ideas that might help fix this? Please remember that this is not an HTTP vs. HTTPS issue so much as it is a...

• "Why does it work in HTTP, but not in HTTPS?" issue. – Paine Ellsworth ^CLIMAX! 21:10, 26 September 2013 (UTC)[reply]
  • Because that is how Microsoft build it. —TheDJ (talk • contribs) 09:13, 27 September 2013 (UTC)[reply]
  • Paine: It looks like this won't be fixed, as it is the result of a Microsoft coding decision, and the WMF probably won't go back to allowing HTTP for logged-in users. Perhaps you could try a new browser? Both Firefox and Chrome should handle this with no problems. — Mr. Stradivarius ^{♪ talk ♪} 10:36, 27 September 2013 (UTC)[reply]

    This is a little confusing. Put aside that Microsoft has another coding boner. The Template:Bug, if I read it correctly, has been fixed and we should once again enjoy logged-in HTTP, soon. So Mr. S, what is it do you mean by the WMF probably won't go back to allowing HTTP for logged-in users? – Paine Ellsworth ^CLIMAX! 17:07, 27 September 2013 (UTC)[reply]

    • Oh, ok, ignore what I said then - it was just a guess. I would still recommend switching browsers though. :) — Mr. Stradivarius ^{♪ talk ♪} 22:28, 27 September 2013 (UTC)[reply]

You and so many others, but for me the Internet Explorer buries its competition, even with all its idiotic-syncrasies. I use Firefox and Chrome to check my edits, so it's not as if I don't know how to use them. IE lets me do so much more! Joys! – Paine Ellsworth ^CLIMAX! 14:13, 28 September 2013 (UTC)[reply]

I was wondering whether a user at the help desk's problem might be because they had turned off the preferences setting for "Show edit toolbar (requires JavaScript)". Anyway, I don't think that's the issue, but when I was playing around and set it to off to see what they might be seeing, I learned that turning it off does nothing; that the edit toolbar remains working regardless of whether the setting for it is ticked on or not. Am I seeing what everyone else is? If so, should we remove this from preferences since it does nothing and miselads people into thinking turning it off is an option?--Fuhghettaboutit (talk) 23:36, 26 September 2013 (UTC)[reply]

Did you purge your browser's cache after saving the setting? —EncMstr (talk) 23:42, 26 September 2013 (UTC)[reply]

Oops! It looks like the browser caching problem is described at WP:BYPASS. —EncMstr (talk) 23:45, 26 September 2013 (UTC)[reply]

Do you have "Enable enhanced editing toolbar" checked? I think it overrides that option. Matma Rex talk 23:43, 26 September 2013 (UTC)[reply]

Yes, I bypass my cache whenever I make any preference change as a matter of course. But also yes, you've found the issue, thanks. If you untick "enable enhanced..." then it does go away. So (in the voice of Emily Litella), never mind.--Fuhghettaboutit (talk) 23:48, 26 September 2013 (UTC)[reply]

This ticket is related. —TheDJ (talk • contribs) 09:06, 27 September 2013 (UTC)[reply]

This refers to the tiny color icon that displays next to your user page link when logged in. I see those are delivered with CSS base64 codes. Would it be possible for someone to point me to the base64 code for the female version of the icon? I can't seem to find it through the usual search means. Thanks :) (PS. I could obviously register a dummy account under a female persona and get it that way, but would rather not). equazcion� | 02:21, 27 Sep 2013 (UTC)

• @Equazcion: You can change this in Special:Preferences#mw-prefsection-personal. I don't see any obvious visual differences when I do that, but I don't know how one finds this "base64" thing so I can't say for sure. Ignatzmice•talk 02:47, 27 September 2013 (UTC)[reply]
  • I feel stupid now, I could've just switched it temporarily in preferences. Heh. Thanks. It looks like you're right, it's the same icon for male and female. I had always assumed they were different. Thanks Ignatzmice :) equazcion� | 02:51, 27 Sep 2013 (UTC)

Anyway, I didn't realize there were any females on Wikipedia, what with all the arguing and posturing and huffing and puffing and thumping of chests all the time. EEng (talk) 02:54, 27 September 2013 (UTC)[reply]

Recent studies have shown that there actually aren't any females on Wikipedia. Probably why the icon depicts a middle-aged bald white guy for everyone. It could probably use some glasses too. equazcion� | 02:59, 27 Sep 2013 (UTC)

Oi. I may be middle aged and white, but I am neither male nor balding. But I'll be darned if I'm gonna put an icon anywhere. The female versions always have terrible hairstyles. Risker (talk) 03:06, 27 September 2013 (UTC)[reply]

Since we're on the subject of sex, I'm gonna use that as an excuse to link to a bit of whimsy I'm somewhat please with, if I do say so myself. [9] In case it's not immediately apparent, the inspiration was the novelty of a bot leaving a Talk message for another bot. EEng (talk) 03:18, 27 September 2013 (UTC)[reply]

That's nothing; bots have edit-warred against each other - and even against themselves! - The Bushranger _{One ping only} 07:46, 27 September 2013 (UTC)[reply]

 Done There are a number of Korean subway stations articles in Category:Candidates_for_speedy_deletion#Pages_in_category

Such as Jongno 3-ga Station but it is not clear to me why they are there. Anyone know?--SPhilbrick(Talk) 10:43, 27 September 2013 (UTC)[reply]

Was Template:Seoul Metropolitan Subway stations tagged for speedy? Werieth (talk) 10:45, 27 September 2013 (UTC)[reply]

There was a maintenance move involving Template:Seoul Metropolitan Subway (now a redirect). That may be the issue, Is this something that will go away with a little time, or do I need to do something to clean up?--SPhilbrick(Talk) 11:05, 27 September 2013 (UTC)[reply]

You can make null edits to the pages to force the categories to update. I just did that for all of the likely-looking pages in CAT:CSD, and the list has now shrunk quite a lot. If you don't make null edits, you have to wait for the job queue to process them, and that can sometimes take days or even weeks. — Mr. Stradivarius ^{♪ talk ♪} 11:19, 27 September 2013 (UTC)[reply]

OK, thanks. That looks like it cleaned it up --SPhilbrick(Talk) 11:23, 27 September 2013 (UTC)[reply]

(edit conflict) Also, yes, that is the issue. :) If a category is updated by a template, rather than directly by an edit to an article, the category page doesn't change straight away but has to wait for the job queue. This is to stop the site freezing when some editor just decides that he wants to make a change that requires 7.6 million pages to be updated. — Mr. Stradivarius ^{♪ talk ♪} 11:27, 27 September 2013 (UTC)[reply]

OK makes sense.--SPhilbrick(Talk) 12:00, 27 September 2013 (UTC)[reply]

I was going to ask what a null edit was, but I found a left over station at CSD. Now I know what a null edit is. :-) Peridon (talk) 16:38, 27 September 2013 (UTC)[reply]

Can someone who is familiar with how bots tend to implement {{bots}} and {{nobots}} directives (especially those that use "mwparserfromhell") please check out my question at Template talk:Bots#Whether this needs to be a "real" template call? Thanks. - dcljr (talk) 14:29, 27 September 2013 (UTC)[reply]

Is there a way to change the settings so that no upper right corner notification appears when a bot posts on my user talk page? I want my notifications to be things that require my attention, not the new issue of the signpost. There may not be a way to do that, but I figured I'd ask anyway. Howicus (Did I mess up?) 15:04, 27 September 2013 (UTC)[reply]

• Which bot is it that is triggering a notification that you don't want? It may be possible to request the bot added to MediaWiki:Echo-blacklist. Technical 13 (talk) 15:18, 27 September 2013 (UTC)[reply]

Instead of asking for the signpost to be copied to your talk page, you could add Wikipedia:Wikipedia Signpost/Issue to your watchlist. That might be less obtrusive. -- John of Reading (talk) 16:50, 27 September 2013 (UTC)[reply]

Signpost is delivered by EdwardsBot (talk · contribs). Echo-blacklisting it would be unpopular, I'm sure. I use a technique similar to that suggested by John of Reading - I have several user talk pages on my watchlist, nine or ten of which happen to be subscribers to Signpost. I just read one of those - it's a bit like reading somebody else's newspaper over their shoulder when you're on the train. --Redrose64 (talk) 19:55, 27 September 2013 (UTC)[reply]

I'm sure it would have to be something discussed by the community. Those that still wanted the notification would still have that option via Special:MyPage/Echo-whitelist but adding it to the site blacklist would prevent those that do not want it from having to deal with it. I think this is definitely something that should be considered since the operator of EdwardsBot refuses to make it exclusion compliant. Technical 13 (talk) 20:10, 27 September 2013 (UTC)[reply]

Regarding "exclusion compliance," if you don't want to receive The Signpost, unsubscribe from receiving it. It's an opt-in newsletter. If you do receive it, you're going to get a notification about it, as the bot will edit your talk page. This is completely expected behavior. --MZMcBride (talk) 20:23, 27 September 2013 (UTC)[reply]

MZMcBride, I was saying that the rest of the system should adapt to accommodate EdwardsBot, and I apologize if it seemed otherwise. Making the bot compliant would not prevent them from getting notifications specifically, it would prevent them from getting and posts from the bot what-so-ever, and I am not promoting that. I'm just saying that the community should have to opportunity to determine if they should get double notifications (the actual post and the notification there was a post) for such things. Technical 13 (talk) 20:33, 27 September 2013 (UTC)[reply]

• I've bumped the thread at MediaWiki talk:Echo-blacklist#EdwardsBot suggesting again that this bot be added to the list. Technical 13 (talk) 00:45, 28 September 2013 (UTC)[reply]

Well, I was looking to disable the notifications for every bot (Edwardsbot was just an example), so that the notification would only show up when a non-bot editor posted...looks like the answer is no, but thanks anyway. Howicus (Did I mess up?) 15:58, 28 September 2013 (UTC)[reply]

WP:GAC appears to have crashed. Once we get to Natural sciences, the list display "Template:GANentry". Could be bot-related, further discussion also here. CR4ZE (t) 15:12, 27 September 2013 (UTC)[reply]

• Sounds like you have hit the template transclusion limit. I'll take a look at it in a moment and see if I can make some suggestions. Technical 13 (talk) 15:15, 27 September 2013 (UTC)[reply]

I can confirm this now as it is listed on Category:Pages where template include size is exceeded as is Wikipedia:Good article reassessment/Archive 38 and Wikipedia:Good article reassessment/Archive 51. Looking to see what templates you are using and if we can make you a new one to cut down on meta template dependencies which should reduce or eliminate this issue. Technical 13 (talk) 15:21, 27 September 2013 (UTC)[reply]

Okay, so I created {{GANentry/sandbox}} in which I ran through a series of substitutions which resulted in this change to {{GANentry}} which has fixed the immediate problem. The pages is now at about 64% of the template include size limit. That being said, there is now a larger concern that the page is at 98% of the Expensive parser function count limit. Technical 13 (talk) 15:38, 27 September 2013 (UTC)[reply]

Okay, the reason for this is because of the '''({{#ifexist:Talk:{{{1|Example}}}/GA{{{2}}}|[[Talk:{{{1|Example}}}/GA{{{2}}}|discuss review]]|<span class="plainlinks">[//en.wikipedia.org/w/index.php?title=Talk:{{urlencode:{{{1|Example}}}/GA{{{2}}}}}&action=edit&editintro=Template:GAN/editintro&preload=Template:GAN/preload start review]</span>}})''' in {{GANentry}} which creates the (discuss review) or (start review) links on every entry. The members of the project should discuss an alternative to those links as #ifexist: is an expensive parser function. Technical 13 (talk) 15:49, 27 September 2013 (UTC)[reply]

It isn't so much something that's effecting me, I haven't opened any GANs recently. There looks to be a cumbersome backlog of GANs, not that that ever changes. I'd suggest that we split the GAN page into multiple pages, which I'm sure would require revamping Legobot but it would eliminate future problems where the backlog exceeds the technical limit. CR4ZE (t) 15:48, 27 September 2013 (UTC)[reply]

Part of the problem was this edit, which made {{la}} much more complicated than it had been before yesterday, and thus {{GANentry}} also became more complicated. If that edit were reverted, this change could be reverted too. --Redrose64 (talk) 20:05, 27 September 2013 (UTC)[reply]

Yes, Redrose64, that is likely the straw that broke the camel's back. However, if their system was on that fine of a line that such a change broke their entire system, then it was time for their system to be updated anyways. Also, that doesn't change the fact that they are less than a dozen entries away from exceeding the expensive parser function limit, which is about to break their system again. I've found the section on the projects talk page and offered my assistance to help them with that issue. Technical 13 (talk) 20:20, 27 September 2013 (UTC)[reply]

I suddenly cannot access the WP insecure site - neither by typing a http address, instead of an https, nor by clicking on my dozens of favourites - all of which start http - they automatically insert the s before loading.
Is this at the WP end? or have those "lovely" people in Seattle enforced another change, part way through a browsing session, without asking users if they want it, or telling users how to overcome it (W7 IE10)?
Why don't I use the secure site? Because I use dozens of pre-saved edit summaries, which do not work in https. Arjayay (talk) 16:06, 27 September 2013 (UTC)[reply]

Hi.

HTTP and HTTPS access should both work. There is an HTTP cookie in place that auto-redirects you from HTTP to HTTPS if you're logged in and have the "secure my session" user preference set in Special:Preferences.

Broadly, you should being using the secure site (HTTPS) unless you absolutely cannot. It should be possible to write a small JavaScript script that adds a drop-down menu (or autocomplete menu) to the edit summary field. Would that be sufficient? --MZMcBride (talk) 18:16, 27 September 2013 (UTC)[reply]

My "Preferences" are not set for "Always use a secure connection when logged in", but any HTTP address, as shown when hovering over a link in "favorites", becomes an HTTPS address as soon as it appears in the URL box.
A JavaScript script to add a drop down or autocomplete menu would be ideal, provided it remembers my previous edit summaries. As I understand it, part of the "security", is not to remember previous entries.
Arjayay (talk) 18:51, 27 September 2013 (UTC)[reply]

see above. According to Bugzilla this should be fixed in the next MediaWiki patch, scheduled for October 10. - The Bushranger _{One ping only} 22:01, 27 September 2013 (UTC)[reply]

SO, it appears that, yet again, some half-tested (I am being generous) change has been made to the software, that disables a standard, and very important, preference, and we have to wait weeks for the damage to be undone? - No wonder we are losing experienced editors. Arjayay (talk) 19:01, 29 September 2013 (UTC)[reply]

Excluding template links from "Special:WhatLinksHere" has never been possible, and this limitation has been brought up before. But I seem to have done it for one page and I'm not sure how it happened.

• All of my script documentation pages include User:Equazcion/ScriptNav, a navigation template that links to all my scripts. So for example, Special:WhatLinksHere/User:Equazcion/LiveDiffLink lists all my script doc pages, because they all have the navigation template transcluded, and that template links to User:Equazcion/LiveDiffLink.

• User:Equazcion/Floater, however, includes the same navigation template, but Special:WhatLinksHere/User:Equazcion/Floater does not list any of my other script doc pages.

I'm wondering if this is a glitch or what, because I'd like to be able to make it happen in the future :) equazcion� | 19:32, 27 Sep 2013 (UTC)

It's just that the jobqueue hadn't caught up with the change you made to User:Equazcion/ScriptNav. A few null edits will fix it. -- WOSlinker (talk) 19:47, 27 September 2013 (UTC)[reply]

Aw. Oh well. Thanks for the explanation :) equazcion� | 19:51, 27 Sep 2013 (UTC)

Recently I've noticed that when I'm editing Wikipedia, it automatic "corrects" my spelling. That is fine if I've made a typo, but it keeps correcting non-US English to US English spelling. Is this a Wiki function or a browser tool? It clearly contravenes WP:ENGVAR. And it's very subtle - initially I didn't even notice it to start with. --Bermicourt (talk) 20:18, 27 September 2013 (UTC)[reply]

Pretty sure it's your browser - most new browsers have built-in spellcheck. In Firefox, Options>Advanced will let you uncheck 'check my spelling as I type'. - The Bushranger _{One ping only} 21:59, 27 September 2013 (UTC)[reply]

I've got "check my spelling as I type" switched on, but it doesn't alter any actual typed content - it puts wiggly red lines under words that it doesn't recognise, à la Microsoft Word. --Redrose64 (talk) 22:43, 27 September 2013 (UTC)[reply]

Bermicourt, If you're using Firefox, simply right-click in the edit box and select "Languages", then click on "English (United Kingdom)"; if it doesn't show in the list, select "Add Dictionaries" to download it (and any other languages you might want). I get squiggly red lines under misspelled words, but it doesn't actually change them (which would be very annoying, since it would change almost all wikicode) - (I also have "check my spelling as I type" turned on, like Redrose). Hope this helps. --NSH001 (talk) 23:43, 27 September 2013 (UTC)[reply]

Thanks folks. I'll look at that. I'm not against US spelling, but I like to choose it when I want it! --Bermicourt (talk) 08:03, 28 September 2013 (UTC)[reply]

Please see Help_talk:CS1_errors#Q for technical details. I'm bothered by the fact that a standard Google Books URL, which works without the "http://" part, produces an irritating error message (see here, for instance). My browser can read this just fine, so while another editor referred to this as "URL errors" they are clearly not errors. Can someone fix this please? Again, technical details are explained on the CS1 errors talk page; I could not possibly paraphrase that. Drmies (talk) 20:28, 27 September 2013 (UTC)[reply]

Relevant problematic code:

<ref>{{cite book|last1=Abdullaev|first1=Kamoludin|last2=Akbarzaheh|first2=Shahram|title=Historical Dictionary of Tajikistan|url=books.google.com/books?id=mC9RsIYy8m8C&pg=PA153&lpg=PA153|year=2010|publisher=Scarecrow|isbn=9780810860612|pages=153–54|chapter=Gurughli}}</ref>

I'm not sure it's unreasonable to say that the "url" template parameter be a full URL (i.e., include the protocol). Your Web browser automatically guesses which protocol you meant, but the protocol is still required. Perhaps the template should try to guess as well, but I'm not sure that's a great idea. --MZMcBride (talk) 21:02, 27 September 2013 (UTC)[reply]

Please can we keep discussion in one place? It started at Help talk:CS1 errors#Q. --Redrose64 (talk) 22:45, 27 September 2013 (UTC)[reply]

Yeah, well, I was told to take it here. I don't understand most of what these technical people are telling me and I'm not really sure I care. I just want those ugly notifications gone. Or, better yet, I want someone to fix the f***ing Citation expander for me! Drmies (talk) 23:07, 27 September 2013 (UTC)[reply]

I suggested that the discussion be moved here, since the poster's question is a technical one about how WP works, not a question about citations. I hope that someone here can explain the reason why WP does not or cannot guess at the protocol for a URL. If someone knows a good way to move the original discussion to this page, and that's the right thing to do, please do so. – Jonesey95 (talk) 02:25, 28 September 2013 (UTC)[reply]

I didn't mean that VPT should not have been informed: in fact, the first post above by Drmies was entirely in accordance with WP:MULTI. But once you get people discussing exactly the same problem in two different places, you get some people who read only the replies in one place, and so don't get the whole picture. --Redrose64 (talk) 08:01, 28 September 2013 (UTC)[reply]

   These don't make sense together. Should the last should be changed?
-- FROM TOPIC

The above rcat template should only be used to categorize redirects that are in the main namespace.

-- FROM TERM

-- TO TOPIC

The above rcat template should only be used to categorize redirects that are in the main namespace.

-- TO TERM

In fact, should three of the template-pages contain Rdrs to one template? I only noticed bcz i previewed {{R from related term}} and {{R to related term}} before saving.
--Jerzy•t 22:21, 27 September 2013 (UTC)[reply]

This isn't really a technical issue, but one for Wikipedia talk:Template messages/Redirect pages. --Redrose64 (talk) 22:50, 27 September 2013 (UTC)[reply]

I didn't mind seeing a few, what was it, weeks ago? But how can the community disable this godforsakenly annonying banner crap posted at the top of Wikipedia articles? What is the difference between this and advertisements? It has the same annoyance effect. Who determines when banners go up? Are we going to have to have an RfC with hundreds of people to disable this stuff? Or can someone just be bold? Are people without accounts seeing this stuff as well? Yikes. Our viewership has declined since the beginning of the year despite us adding about 900 pages a day. We shouldn't be chasing people away with these annoying advertising-like banners. Who determines the value of such advertisments? Biosthmors (talk) pls notify me (i.e. {{U}}) while signing a reply, thx 08:20, 28 September 2013 (UTC)[reply]

I'm not getting it. In Preferences - Gadgets I've got 'Suppress fund raiser banner' ticked - have you? May not be the thing, but worth looking until someone who really knows gets here. Peridon (talk) 18:21, 28 September 2013 (UTC)[reply]

I don't have it ticked. But who decides when to run these things? Where is the community input in this? Sorry to bug you again today User:Mdennis (WMF). Biosthmors (talk) pls notify me (i.e. {{U}}) while signing a reply, thx 19:53, 1 October 2013 (UTC)[reply]

See m:CentralNotice, User:Biosthmors. :) --Maggie Dennis (WMF) (talk) 22:47, 1 October 2013 (UTC)[reply]

• Today I found that File:Frogmendvd.jpg had been deleted as "orphan fair-use", i.e. "not linked to". But it is (and probably always was) linked to from Frogman#Aqualungs, not as a displayed image but with a plain wikilink starting in a colon. (I have undeleted the image.) Anthony Appleyard (talk) 08:53, 28 September 2013 (UTC)[reply]

Yes, my understanding is that files merely linked (rather than embedded) are not counted under "file usage".[10] So, in particular, sound files are not included. This leads to incorrect tagging and deletion. To add insult to injury, once such a file has been deleted a bot comes round and removes the link from the article on grounds that the file does not exist.[11] Thincat (talk) 09:29, 28 September 2013 (UTC)[reply]

PS "What links here" does show the usage.[12] I see the WP:CSD#F5 submission was made using Twinkle.[13] Does Twinkle detect orphaned files itself and could its methodology be improved? Do deleting admins take proper account of the matter? Thincat (talk) 09:40, 28 September 2013 (UTC)[reply]

The file is in fact orphaned, and its usage on that article fails WP:NFC. Ill be nominating it for deletion shortly. Werieth (talk) 14:56, 30 September 2013 (UTC)[reply]

Discovered a problem with the format price template:

• {{Format price|8.1}} gives 8.10 (i.e 2 d.p.)
• {{Format price|8.2}} gives 8.20 (i.e. with 1 d.p.)

Looking at the template logic, this is because

• {{#expr:(8.1*100 mod 10)}} is 0 (i.e. 0)
• {{#expr:(8.2*100 mod 10)}} is 9 (i.e. 9)
• NB {{#expr:(820 mod 10)}} is 0 (i.e. 0)

It looks like there's some sort of bizarre rounding error going on in the multiply. Is there a way round this? Edgepedia (talk) 10:06, 28 September 2013 (UTC)[reply]

• • got it! ->

• {{#expr:((8.2*100 round 0) mod 10)}} is 0 (i.e. 0)

Edgepedia (talk) 10:09, 28 September 2013 (UTC)[reply]

The engineering department is hosting two office hours this week to discuss VisualEditor. The first of these will be held on Monday, 30 September, at 1900 UTC. The second will be held on Wednesday, 2 October, at 0000 UTC. Please join as Product Manager James Forrester discusses VisualEditor and upcoming plans. Thanks! --Maggie Dennis (WMF) (talk) 14:04, 28 September 2013 (UTC)[reply]

The link was correct, but the time for the first meeting should have read 1900. Sorry for any confusion! 24 hour time conversion threw me, I'm afraid. :/ --Maggie Dennis (WMF) (talk) 10:17, 30 September 2013 (UTC)[reply]

I have a problem with logging in with a bot account using the MediaWiki API where it always gives the "NeedToken" result even if I pass the correct sessionID cookie and login token. The code used for login worked on 30 May 2013 when it was last used. Could the problem be because of any changes in the API login procedure since then? If yes, please mention the changes. If you need the code, the one currently used is at User:CLT20RecordsUpdateBot/Source/update.php and the code used for the 30 May edit is at User:IPLRecordsUpdateBot/Source/update.php. (both are similar except for a few changes such as user name, page title etc.) jfd34 (talk) 14:49, 28 September 2013 (UTC)[reply]

The name of the session cookie has changed, see this wikitech-l post. If at all possible, you really should redo your code to handle the cookies automatically from the Set-Cookie headers in the HTTP response instead of trying to construct them manually. Anomie⚔ 15:17, 28 September 2013 (UTC)[reply]

On Forest Lawn Memorial Park (Hollywood Hills), the official website template isn't working. Why? It's just displaying the "Official Website" text as plain text, not a link. -- Zanimum (talk) 18:06, 28 September 2013 (UTC)[reply]

The URL contained = thus you needed to have 1= at the start. Werieth (talk) 18:09, 28 September 2013 (UTC)[reply]

Is this new? I've used the template for years without needing 1=! -- Zanimum (talk) 21:01, 28 September 2013 (UTC)[reply]

Two conditions must be met for 1= to be needed. These are fairly rare to both occur at the same time. The template must not be using a named parameter (IE url=, title=, name= ) and the value being passed must also contain a =. It has always been like this, PARAMETER = VALUE in this case PARAMETER = http://www.forestlawn.com/MainPark.aspx?park_id and VALUE = 4. Since the parameter is unknown in this case, its ignored. `Werieth (talk) 21:08, 28 September 2013 (UTC)[reply]

PS few official websites include = in the address. Werieth (talk) 21:10, 28 September 2013 (UTC)[reply]

(edit conflict) Or to put it another way, if a parameter's value contains an equals sign, you need to give the parameter name explicitly (even if that is a number). This behaviour goes right back to the introduction of named parameters in templates many years ago. See H:T#Usage hints and workarounds, first bullet.

If the actual URL had been http://www.forestlawn.com/MainPark.aspx, which does not contain an equals, {{official website|http://www.forestlawn.com/MainPark.aspx}} would have been perfectly valid. --Redrose64 (talk) 22:08, 28 September 2013 (UTC)[reply]

I always just use the 1= by default, I'm pretty sure on some older browsers it's needed, as I had problems without it without having those parameters both met. (Also, as an aside, people should be sure to use {{official website}} and not {{official}}, I see the latter used a lot but it just redirects to the former.) - The Bushranger _{One ping only} 00:03, 29 September 2013 (UTC)[reply]

It's not browser-specific - or at least, it shouldn't be, because template parameter processing is done entirely on the Wikimedia servers - what your browser sees is pure HTML. With the 1= before the template parameter, the browser is served

<span class="official website"><span class="url"><a rel="nofollow" class="external text" href="http://www.forestlawn.com/MainPark.aspx?park_id=4">Official website</a></span></span>

which contains a link (it's the <a>...</a> element), but without the 1= the browser is merely served

<span class="official website">Official website</span>

which has no link, and is little better than plain text. Browser/HTML compatibility should not be an issue: the <a>...</a> element works in all browsers (it's one of the original elements of circa 1990), and whilst the <span>...</span> element is not original (it was introduced with HTML 4.0), you'd need to still be using a browser about as old as IE 3 for that not to be recognised. --Redrose64 (talk) 10:06, 29 September 2013 (UTC)[reply]

• It's always been like that. You have options (and = isn't the only "naughty" character, | is just as bad). The options for = are to use the named parameter (ie. url=), use the exclusive numbered parameter (ie. 1=), or use the "escaped" = sign in the url itself (ie {{=}}). For pipe, the only options I'm aware of are escaped methods including {{!}} and &#124;. Happy editing! Technical 13 (talk) 22:04, 28 September 2013 (UTC)[reply]

  For the pipe character, you can (almost always) percent encode it as "%7C". This option isn't available for the equals sign (which would be "%3D"), because that removes its status as key-value separator for the target web server (i.e. www.forestlawn.com would see a parameter named "park_id=4" with no value). Anomie⚔ 11:36, 29 September 2013 (UTC)[reply]

Can anyone figure out why {{tracked}} is not working here (on this page)? I can find no apparent error. — Edokter (talk) — 22:35, 28 September 2013 (UTC)[reply]

Works for me. Theopolisme (talk) 22:56, 28 September 2013 (UTC)[reply]

I guess Edokter isn't thinking of the template itself but of the JavaScript actions it should cause for users with the gadget "Enable tracking bugs on Bugzilla using the {{tracked}} template." PrimeHunter (talk) 23:05, 28 September 2013 (UTC)[reply]

See User:PrimeHunter/sandbox2 for an example where it works for me. With the gadget enabled, the box made by {{tracked|54626}} displays the name and status of bugzilla:54626: "forceHTTPS session cookie placed even with HTTPS opt-out set RESOLVED". This text is made by MediaWiki:Gadget-BugStatusUpdate.js and not by the template itself. Above in #Is WPs unsecure site still working? I only see the same as your image: A box saying "Tracked in Bugzilla Bug 54626". PrimeHunter (talk) 23:20, 28 September 2013 (UTC)[reply]

It is the script that fails. I found some duplicate bugs that may cause the script to fail, but removing those did not fix it. Regardless, I found that the template (and script) uses ID attributes, which must be unique. I changed those into classes. See what happens. — Edokter (talk) — 10:31, 29 September 2013 (UTC)[reply]

The problem is the link to Template:Bug in the section #Blacklist not functioning correctly. That bug was changed to be a hidden bug, which means Bugzilla's API throws a permissions error when asked to return it. It would be better if Bugzilla's API would do more like ours, and return the remaining results while indicating a permissions error for just that one bug, but I haven't looked to see if it's possible to tell it to do that. Anomie⚔ 11:31, 29 September 2013 (UTC)[reply]

Just found out myself... I've unlinked the bug. — Edokter (talk) — 11:45, 29 September 2013 (UTC)[reply]

• This is something that I've been sitting on for awhile. I'll add the "security bug" fix I came up with in the next week to my sandbox script (which has had the id/class thing fixed for months now as I mentioned on MediaWiki talk:Gadget-BugStatusUpdate.js#List of things to fix or improve). I'll mention there when I complete the fix for security bugs and I'll take another poke at adding resolutions to the template as well. Technical 13 (talk) 12:43, 29 September 2013 (UTC)[reply]

I have just noticed that the editor on .js pages has changed when I tried to edit my monobook.js page. Sorry if this has already been covered, I don't edit js pages often. It's all very well having semantically meaningful colours in the edit window, but I am now having a problem finding things on the page. My browser search seems to be ignoring the edit window (FF23). It only finds text on the page that is not in the edit window. Is there some kind of built-in search facility in the editor? Or failing that, how do I get the old editor back? SpinningSpark 23:19, 28 September 2013 (UTC)[reply]

While in the new editor (when the editor box has focus, ie. there's a blinking cursor in it), the Ctrl-F keystroke brings up a custom search that will find things throughout the code. You can get the old editor back by clicking the leftmost button in the upper toolbar (the /* graphic). equazcion� | 06:05, 29 Sep 2013 (UTC)

Am I the only one having trouble to load Wikipedia pages? Revision histories, undo, Previews, Saves etc are impossibly slow and reminiscent of when I had a dial up. I don't think it's me. I don't have problems with other sites that I know are big to load. SlightSmile 23:49, 28 September 2013 (UTC)[reply]

Could be a combination of HTTPS (instead of HTTP), and that the current scripting doesn't seem to allow the browser to display a partially-loaded page (as many of the older versions of scripting did)... AnonMoos (talk) 07:39, 2 October 2013 (UTC)[reply]

There once was a bot maintained by Rich Farmborough that fed recent changes to medical articles (articles with Wikiproject Medicine's template on their talk page) into a page like a watchlist. Since Rich was blocked from bot work, it has fallen into disrepair (it now just lists changes to articles beginning with "A"). Is there an alternative way for me and others to monitor recent changes to medical articles? --Anthonyhcole (talk · contribs · email) 01:10, 29 September 2013 (UTC)[reply]

There's the WikiProject Changes tool at Toolserver.org.[14] Peter James (talk) 01:55, 29 September 2013 (UTC)[reply]

Yay! That's perfect. Thank you, Peter. --Anthonyhcole (talk · contribs · email) 02:27, 29 September 2013 (UTC)[reply]

Is it possible to see how many indefinite blocks are out there currently, and/or have been given if the past? How about blocks in general? Is there any tool/list that tells how many blocks of various length are/have been given out? --_{Piotr Konieczny aka Prokonsul Piotrus| reply here} 05:59, 29 September 2013 (UTC)[reply]

Special:BlockList shows all blocked users. It has an option to hide temporarily blocked users, which would only show indefinites. I'm not sure if there's a way to get total counts automatically. equazcion� | 06:23, 29 Sep 2013 (UTC)

Yep, I was looking at it, but without total counts, it's a major pain to try to use it. I also looked at Category:Blocked_Wikipedia_users which gives about 150k, but I don't think it's accurate - many editors get blocked indef but don't end up in that category (I just compared some random indefs from block log and they are not in that category, for example User talk:Peterfedor or User talk:Josh miller135. --_{Piotr Konieczny aka Prokonsul Piotrus| reply here} 06:31, 29 September 2013 (UTC)[reply]

Posting on behalf of Betacommand via IRC, the current count is 586809 accounts. Legoktm (talk) 22:54, 29 September 2013 (UTC)[reply]

Aggregate block statistics would make for a good database report. --MZMcBride (talk) 03:26, 30 September 2013 (UTC)[reply]

On the left side of this (and I think every) page under "Statistics" is a bullet point "Edit history stats" that no longer works. If it can't be revived could someone please delete it? --Anthonyhcole (talk · contribs · email) 06:40, 29 September 2013 (UTC)[reply]

You're likely seeing that cause you have my User:Equazcion/SidebarHistoryTools script installed. I just removed the link to the now-defunct tool. You may need to bypass your cache to see the change. equazcion� | 06:46, 29 Sep 2013 (UTC)

I realized after removing the link that there's a replacement for the defunct tool, so I added the link back pointing to the correct URL. Again, bypass your cache to see the change. equazcion� | 06:50, 29 Sep 2013 (UTC)

...although I just checked your .js pages and don't see my script in them. I think the link you're seeing is coming from User:Smith609/toolbox.js, so you'd have to contact him to fix the script. But thanks for helping me update my script anyway :) equazcion� | 06:55, 29 Sep 2013 (UTC)

OK. Thanks. If it's only happening to people who've optedd in, I guess it's not a problem. --Anthonyhcole (talk · contribs · email) 07:30, 29 September 2013 (UTC)[reply]

I notice someone accidentally enabled article feedback on this Village Pump page. That should probably be removed, and all Village Pumps should probably have the enable feeback link disabled. I'm not sure how that's done, but WP:ANI doesn't show the link, so I'm assuming it's possible. equazcion� | 07:23, 29 Sep 2013 (UTC)

That was me. Sorry. I couldn't immediately see how to disable it. --Anthonyhcole (talk · contribs · email) 07:27, 29 September 2013 (UTC)[reply]

No problem, I think it was bound to happen sooner or later with the link showing up here. I'm not sure how to disable it either, but I'm assuming an admin can. equazcion� | 07:37, 29 Sep 2013 (UTC)

 Disabled through the "change protection" tab, see here. --Redrose64 (talk) 09:27, 29 September 2013 (UTC)[reply]

Thanks Redrose64. If possible it should probably be disabled preemptively for the other Village Pumps as well. equazcion� | 09:29, 29 Sep 2013 (UTC)

Could a kind admin who knows JavaScript take a look at the edit request over at User talk:Js/urldecoder.js#Support for LiquidThreads? It's been sitting in CAT:EP since September 25 and needs someone who knows what they're doing to take a look at it. — Mr. Stradivarius ^{♪ talk ♪} 14:37, 29 September 2013 (UTC)[reply]

I am trying to fix the original upload log at File:Herzliyya skyline.jpg. I am trying to insert a right-to-left mark. I have failed. Can someone assist me with this? If we are successful, I may try to fix all the RTL errors in original upload logs by bot. Magog the Ogre (t • c) 17:26, 29 September 2013 (UTC)[reply]

I added in a LRM and that fixed the username, dimensions, and file size from the original upload fixed. I don't actually read Hebrew, so I don't know if the rest of the description is correct, but the meta-data is legible at least. VanIsaac_{WS Vex}^contribs 18:02, 29 September 2013 (UTC)[reply]

This style is present on my userpage, where it causes a hatnote to become red (hopefully it's not just me). I can't seem to find where it's coming from or why (it's not present in anything else that I've found); my element inspector suggests it's coming from index.php:4, which is the line that declares the character set and title, and contains no CSS, nor do any of the lines near it.  — TORTOISEWRATH 21:56, 29 September 2013 (UTC)[reply]

Which hatnote? --Redrose64 (talk) 22:09, 29 September 2013 (UTC)[reply]

• TW, are you using the AFCH helper script perchance? I ask because that code comes from MediaWiki:Gadget-afchelper.css (which I'll put in a request to fix for you that should take effect in a few days (once AFCH dev team (Legoktm—Theopolisme—APerson241—mabdul) can come up with a suitable script wide replacement for)). Technical 13 (talk) 22:11, 29 September 2013 (UTC)[reply]
  •  Done in source here. Theopolisme (talk) 22:18, 29 September 2013 (UTC)[reply]
    • Alas, nary alleviation be done.  — TORTOISEWRATH 02:43, 1 October 2013 (UTC)[reply]
  • Nope... but it only occurs when I'm logged in, so I don't really care that much. Could that be coming from Twinkle?  — TORTOISEWRATH 02:43, 1 October 2013 (UTC)[reply]
    • Hrrmm... Interesting. TW, in order to troubleshoot this more for you, it would be helpful if you could list which gadgets you are using on your preferences page. Also, as a test, edit the page and see if it is still red. Knowing that will help isolate the problem as well. :) Technical 13 (talk) 11:56, 1 October 2013 (UTC)[reply]
• Nope, this is nothing other than AFC Helper... see line 4 of MediaWiki:Gadget-afchelper.css. Presumably this will be fixed by the AFCH team. — This, that and the other (talk) 12:02, 1 October 2013 (UTC)[reply]
  • Oii... it was coming from AFCH :/ ... I had no idea I had it enabled! It's been fixed in git, so the problem'll be solved soon.  — TORTOISEWRATH 23:06, 1 October 2013 (UTC)[reply]

I would need a tool or script or whatever that lists all the articles linked in a given article, and how many times is each one linked. I would need to locate the pages linked several times, and reduce the excessive links. I know that such a tool exists, I had once used it, but I don't remember the name or where to find it. Cambalachero (talk) 23:12, 29 September 2013 (UTC)[reply]

User:Ucucha/duplinks? PrimeHunter (talk) 23:18, 29 September 2013 (UTC)[reply]

It wasn't that one, but it was also useful. Thanks! Cambalachero (talk) 01:54, 30 September 2013 (UTC)[reply]

WP:AWB lists multiple links on pages as well. VanIsaac_{WS Vex}^contribs 02:35, 30 September 2013 (UTC)[reply]

I just saw a "Due to high database server lag, changes newer than 40,654 seconds may not appear in this list" notification when I clicked my watchlist. Biosthmors (talk) pls notify me (i.e. {{U}}) while signing a reply, thx 23:35, 29 September 2013 (UTC)[reply]

Same here. Looks to be slowly coming down, but its like a bomb went off with that ~40,000 second loss of edits. Special:RecentChanges looks to be going okay. Chris857 (talk) 23:37, 29 September 2013 (UTC)[reply]

I'm seeing the same thing. I assume they are doing some kind of work on the servers. --Tryptofish (talk) 23:40, 29 September 2013 (UTC)[reply]

Down to 35,875 seconds now. Holy database server lag, Batman. - The Bushranger _{One ping only} 23:44, 29 September 2013 (UTC)[reply]

Looks to have cleared out fully for me, now. Chris857 (talk) 23:58, 29 September 2013 (UTC)[reply]

Seems to be gone for me as well, at least for now, but man that was one crazy database lag. Let's see if it continues.... Narutolovehinata5 ^tccsdnew 00:03, 30 September 2013 (UTC)[reply]

• The watchlist and contribution server locked up and needed to be restarted, it should be fine now. Technical 13 (talk) 00:15, 30 September 2013 (UTC)[reply]
• From wikitech:SAL:
  • 23:56 logmsgbot: springle synchronized wmf-config/db-eqiad.php 'depool db1049'
  • 23:20 springle: powercycling db1049, soft lockup, unresponsive
• db1049 is enwiki's watchlist slave. Legoktm (talk) 01:50, 30 September 2013 (UTC)[reply]

Template:Annotated_image : Will it be possible to modify the template input, such as using percentage rather then amount of pixels? e.g. crop 9% from the top rather then "-22" pixels?. I have used this template recently and the experience was rather inconvenient. thanks. Ykantor (talk) 01:13, 30 September 2013 (UTC)[reply]

After testing the new release of VE, announced here in #VisualEditor weekly update - 2013-09-26 (MW 1.22wmf19), it became quite obvious that I am apparently the first one to test these changes before they are implemented live, since the predictable bugs were very easy to find and will create loads more problems (luckily, with the opt-in, the amount of VE edits has dropped dramatically).

I have posted these problems in the above thread (where one developer responded) and at Wikipedia:VisualEditor/Feedback#Error reports before they even happen!, where no one from the WMF could be bothered to reply.

I then filed Bugzilla 54737, which was closed as invalid. Apparently, we first need to get consensus that theior product and new release sucks before they can act upon it, instead of using their brains and testing it for themselves. Furthermore, even if we get a consensus, "on average, they take a month or two to process"[15]. But anyway, here we are.

I would like to see whether people agree that, considering the current state of VE and the quality of the weekly releases (buggy, badly and incorrectly described, ...), it would be a lot better if we didn't get any VE updates or releases until most of the major bugs are solved and we get an actually working product. The WMF is still trying to use the Wikipedia's as their forced "community testing ground" (see nice older pages like [16]: "The VisualEditor project aims to create a reliable rich-text editor for MediaWiki. It is a top priority for the Wikimedia Foundation and it is available for testing on the English Wikipedia."), whether we want this or not.

This has to stop. They can test it on their own pages if they want to, or on testwiki, or on Wiki-versions that explicitly agree to be a testing ground; but they shouldn't bother us with it, and they should stop pushing new, untested, faulty releases to us. Fram (talk) 07:37, 30 September 2013 (UTC)[reply]

Do these updates affect the opt-in nature? equazcion� | 07:44, 30 Sep 2013 (UTC)

... you told them to not push any updates for 3 months in the bug! 1) You're not even giving them a chance to fix the bugs that exist, 2) that is not what Bugzilla is for. --Rschen7754 07:45, 30 September 2013 (UTC)[reply]

As long as it's opt-in only and being used by people that are using it with an eye to evaluating the results and the interface, I can't get too excited about releases, Fram. Even well-run projects have the occasional regression. If I see evidence that people testing Visual Editor are damaging Wikipedia and not cleaning up after themselves, my excitement level will quickly rise.

Conceptually, I agree with you that until they get tables, complex templates that include styles and table formatting, and tables themselves working, there's no actual reason for anyone but themselves to test the code.—Kww(talk) 07:52, 30 September 2013 (UTC)[reply]

Don't you think you're getting a little bit extremist? You want them to fix VE's problems by... doing nothing. Sure. Adam Cuerden ^(talk) 07:58, 30 September 2013 (UTC)[reply]

No, he wants them to fix VE's problems by fixing VE's problems. As Fram notes, they don't need the live English Wikipedia community in order to find problems, since many problems are already apparent. A beta software release for live testing should really only be done once obvious inadequacies are taken care of and further bugs aren't becoming readily apparent via genuine efforts at non-live testing. That said, personally, I don't much care if they want to continue plodding down this half-assed path, as long as VE remains opt-in and doesn't cause problems for non-testers. equazcion� | 08:09, 30 Sep 2013 (UTC)

Like Equaczion said, I want them to fix bugs at Testwiki, and at every Wiki that actively welcomes VE and its updates, be it Mediawiki or another language version or Wikisource or whatever. I don't want them to push clearly untested updates to here and everywhere. I have left feedback at Mediawiki as well, but no one seems to care that their release notes are utterly wrong. I seriously doubt that anyone had tested any of the VE "improvements" of the version 19 before they implemented it at Mediawiki and announced the rollout here for this week, and I doubt as well that anyone but me has independently tested it but me (WMF developer Qgil has tested my bug reports and confirmed them, thanks for that). Why would we allow them to push their releases when their quality is way sub-par? Whether it will affect the opt-in, I don't know, since I'm unable to test that (and I doubt they have done). I don't see the value in rushing a new release every week when there are so many major bugs left and so little enthusiams here to test or use it, or to clean up after those that still use it. Fram (talk) 08:30, 30 September 2013 (UTC)[reply]

I'm afraid I don't see the point in this request. I think, although WMF should have withdrawn VE entirely after it was determined that there were serious encyclopedia-damaging bugs, that there's no point in withholding updates. There is no indication that WMF is likely to restore previously existing serious bugs, and I consider the possibility that an update adds new serious bugs likely, but unlikely to be detected without using a live Wiki. I could be wrong, — Arthur Rubin (talk) 09:57, 30 September 2013 (UTC)[reply]

Well, I tested the new release V19. There are, at the moment, a number of serious bugs in file handling (someone should really tell the WMF that it is about "files", not "images", since quite a few years), e.g. with the moving of files. Moving files works very poorly and causes more problems than it solves. So when this new version doesn't address this bug, but instead opens up this "functionality" for templates and other things, then yes, the WMF is actually expanding known bugs to new possibilities, and testing in their own pages at Mediawiki were more than sufficient to find these problems (and a few others to boot). Pushing these changes (with the accompanying incorrect description, which no one is allowed to correct apparently) to all wikipedia instead of testing them locally (at Mediawiki and Testwiki) is irresponsible behaviour and only makes Wikipedia worse. It isn't too bad for us, now that we have opt-in, but we could at least send the message that theit approach is totally wrong. Fram (talk) 10:05, 30 September 2013 (UTC)[reply]

Woah, woah, you want developers to spend their precious time testing software before releasing it? This is Web 2.0/"agile"/"waterfall"/insert buzzword here! Your users are your testers! Regression testing, test suites, fuzzing, what are those, some new websites or somethin? To be fair to the WMF, this problem is hardly limited to them. The trendy thing in software development these days seems to be letting your end users find the mistakes you made, and then bitching at them for not providing a ready-to-go patch to fix your errors, or if you're a large corporation potentially calling the police on them for finding bugs with security implications. After all "open source" means "other people do my work for me," right? I mean, who's got time to test software anymore? That's what they do when they write actually important software, right, like software that can kill people if it screws up (medical devices, military hardware, etc.), just throw the latest HEAD revision onto the device and ship it when the deadline comes. --108.38.191.162 (talk) 16:49, 30 September 2013 (UTC)[reply]

Cute, but even open-source developers only recommend live use after major issues are dealt with. The difference between the old and new-age open-source ways is that works in progress aren't "closed" quite as often, so instead of limiting them to a hired or even select group, they're often made available for all to test, should they wish to and be able to find the test release. Things still aren't generally implemented live or even put in plain sight until they're pretty reliable. By even the most relaxed industry standard, VE is in the alpha stage, and in order to participate in testing, users should need to have the requisite knowledge to navigate to a non-live testing ground. equazcion� | 18:12, 30 Sep 2013 (UTC)

Oh I'm aware of that. I'm a programmer myself. My point was mainly in regards to the belief some people have that "open source" is magic pixie dust that will fix all the bugs in your software. This is more common in the corporate world, where some suits seem to think a legion of programmers will materialize to fix all your bugs for free. As for testing, if the WMF wants to learn how to do things right, they should look at projects like the Linux kernel, Perl, and distributions like Debian and Gentoo, all of which have automated test suites, groups of dedicated testers, and in fact require testers to sign off on code before it's marked for release. --108.38.191.162 (talk) 19:33, 30 September 2013 (UTC)[reply]

• Fram, I get that you dislike VE and the way it's been deployed. That's great; it's certainly not a rare opinion! But this suggestion seems to be deliberately pointed - everyone else has to not be told about ongoing work because you dislike the project?

Given one of the major community complaints about VE, and every other major technical project, is a lack of communication, demanding less communication is going to be massively counterproductive and serve to make things just that bit less pleasant for everyone involved further down the line. Andrew Gray (talk) 19:45, 30 September 2013 (UTC)[reply]

• • No, that's not what I am suggesting. It's not that I don't want to hear about ongoing work (assuming that their reports are actually correct, the current one isn't), but that I don't want them to deploy the actual updates until a few months have passed, most of the major bugs have been fixed, and things have thoroughly been tested at testwiki and at any wiki that agrees to be used for that purpose (e.g. Mediawiki). It seems that I haven't explained my proposal very well, or that my current disagreement about the latest release notes have been mixed up with this proposal. But I repeat: I call here for a moratorium on deployments, further VE code updates, not for silent deployments. apologies for the misunderstanding! Fram (talk) 19:58, 30 September 2013 (UTC)[reply]
    • Aha - that makes a bit more sense (though personally I don't agree!). I've updated the heading. Andrew Gray (talk) 20:17, 30 September 2013 (UTC)[reply]

• Fram, this is one of those cases of watching an inevitable result. Now that WMF has lost English Wikipedia as an involuntary testbed, their first few releases will inevitably represent quality degradations to the point that many of the projects that have it marked as "opt-out" will move to "opt-in". They will then get even less feedback, so their quality will degrade further. WMF will either have to learn to test code on their own, or the project will collapse. I'm hoping for the former. One way or the other, us raising a bigger fuss about it probably won't help.

I'm personally hoping that the VE development team starts to use WMF's QA team to evaluate releases (right now, my understanding is that they don't, something which doesn't surprise me but does sadden me). It probably is reasonable to ping Mr. Forrester and ask him what QA stages VE goes through. The last quote I have from him on the topic is "<+James_F> Elitre1: We test the fixes, yes, but clearly not enough. :-( We've spoken with the QA team about working with them, but currently we don't do any significant work with them, no."—Kww(talk) 20:05, 30 September 2013 (UTC)Pinging Mr. Forrester—Kww(talk) 22:49, 2 October 2013 (UTC)[reply]

Note that they are currently hiring a full-time VE tester. Andrew Gray (talk) 20:17, 30 September 2013 (UTC)[reply]

Shouldn't they have filled that position six months ago?—Kww(talk) 20:22, 30 September 2013 (UTC)[reply]

(ec)Any reason to believe whatever Jdforrester tells us? His track record isn't exactly spotless over the last couple of weeks... He asked for feedback about the status report, but can apparently not be bothered to read it or act on it. He has replied to my request about where he got the "edit summary" figures from, but his response (on his talk page) is seriously unconvincing. Fram (talk) 20:23, 30 September 2013 (UTC)[reply]

It's always good to at least know what the official statement is, regardless of whether you personally find it credible.—Kww(talk) 20:35, 30 September 2013 (UTC)[reply]

Resolved

Somehow this edit broke all math formulas in Lucas sequence. This revision for me comes up as a red mess with a lot of error messages like the following:

Failed to parse (Cannot store math image on filesystem.): U_0(P,Q)=0, \,

Any ideas what's wrong here? -- Toshio Yamaguchi 11:19, 30 September 2013 (UTC)[reply]

The linked revision looks fine to me, for some reason. I don't see any red errors. equazcion� | 11:25, 30 Sep 2013 (UTC)

Toshio, can you get us a screenshot and upload it to commons? I can't see any red or error messages either. Thanks. Technical 13 (talk) 11:33, 30 September 2013 (UTC)[reply]

Actually it was a server caching issue. A null edit fixed it. Thanks. -- Toshio Yamaguchi 11:35, 30 September 2013 (UTC)[reply]

Help!

1. I seem to have lost the 'edit history' tab at top right of the edit page. I think it happened when I was on my 'Preferences' page, (possibly using the 'Gadgets' tab); but I can't remember what I unchecked.
2. When I come across a link that I don't know, e.g. WP ETA; I hover the cursor/arrow over said link - and all I get is 'Wikipedia ETA'. I know that 'WP' is 'Wikipedia' !! (As the old saying goes: 'As much use as a chocolate fireguard'), but what does 'ETA' stand for? (I do know what it means, in this instance, I'm just using it as an example). Is there some way that this system could be changed to be of some use, because at the moment, it's of no use whatsoever.
3. Why, when going through the edit history page (when I can, see '1' above), do the 'radio buttons' for different versions of an article always revert to the most recent effort, even though I might be looking at a version of the page from many editions ago ? It didn't always 'function' in this silly way.

I use Internet Explorer 10.

Thanks in advance

RASAM (talk) 13:22, 30 September 2013 (UTC)[reply]

• Some answers to the 3 issues: The MediaWiki software has been updated on a weekly cycle in recent months, and some functionality has been changed for various versions of various browsers. Specifically, your issue number (1): the missing "View history" tab has been noted by other users, so try widening the screen when the search-box ("[Search________]") seems to overlay and eclipse the history-tab or overflow-menu arrow underneath, or else overlays atop the page title; apparently, there is an extra, variable-size gap (auto-widens with screen width) between the "Talk" and "Read" tabs which has been pushing the other top tabs further to the right (and eclipsing tabs on some browsers). For issue (2), the hover text for some terms could be improved. However, for issue (3), about history-page radio buttons, I suggest viewing more entries per page, such as option "&limit=500" in the URL address line, and then the radio buttons to compare selected versions would not reset back to the top entries on the page, as often. Other users have suggested the developers create a stable version of the MediaWiki interface (as in "Classic Coke") for users who tire of the shifting, unpredictable screen appearance after weekly updates to the MediaWiki software. It gives the feel of the automobile's steering wheel and brake pedal being shifted each week. I guess it could be said the screen updates are "straightening the deck chairs on the Titanic" rather than fixing important problems, such as wp:edit-conflicts, or providing new features such as a footer box to display at the end of a page regardless of bottom edits to a page. Anyway, I am sorry the problems have annoyed you, but thank you for noting these concerns, as a reminder for what upsets users. -Wikid77 (talk) 11:46, 1 October 2013 (UTC)[reply]

I usually forget my password and have to reset it. I notice that it takes a tiny amount of login attempts (1 or 2) to trigger a red flag, forcing me to decipher capchas and wait five minutes, etc. It hits me every few weeks. Most people have more than 1 or 2 passwords which they try before remembering what they used. 4-5 attempts would be much more convenient. Notice that google and other "giants" are more lenient, so it surely would not make accounts noticeably less secure.J1812 (talk) 15:58, 30 September 2013 (UTC)[reply]

Dear editors: While checking out the above page in order to give advice to a new user, I clicked on the "Ask" button, but it doesn't appear to do anything. Since I came to the page from the default banner at the top of my talk page which says "Ask questions, get answers", this is surprising. —Anne Delong (talk) 17:16, 30 September 2013 (UTC)[reply]

Those buttons at the top of Wikipedia:Questions are actually more like navigation tabs. The "ask" button just navigates to Wikipedia:Questions in case you're at one of the other help pages -- so if you're already at that page, it indeed doesn't do anything. Might be kinda confusing. I may rename that button to something more intuitive, like "questions". equazcion� | 17:25, 30 Sep 2013 (UTC)

Done -- made it "Where to ask questions". Hopefully that helps. equazcion� | 17:30, 30 Sep 2013 (UTC)

Thanks. It was a little embarrassing to be saying to the user, "Look how easy it is to get help", and then the "Ask" button didn't do anything. —Anne Delong (talk) 21:36, 30 September 2013 (UTC)[reply]

This morning, I added a redirect while on a Mozilla Firefox computer. When I tried to go back to what I was doing before, I kept being sent to the redirect target. I even clicked on the back button very quickly, which normally works in that situation. Nothing worked, so I had to retype the search term. I don't know whether this is something Wikimedia would consider a bug.— Vchimpanzee · talk · contributions · 20:32, 30 September 2013 (UTC)[reply]

I use Firefox. I've noticed for some time (over two years, I think) that if a redirect has a fragment identifier (i.e. it points to a section heading), I normally need to use "back" twice. --Redrose64 (talk) 20:53, 30 September 2013 (UTC)[reply]

But in this case it "redirects" no matter what I do. No amount of pressing the back button changes this.— Vchimpanzee · talk · contributions · 21:27, 30 September 2013 (UTC)[reply]

Which version of Firefox are you using? I'm still on 23.0.1, but I know that 24 has been released recently. --Redrose64 (talk) 21:44, 30 September 2013 (UTC)[reply]

If you hold down the Back button in Firefox, it should show you the last 10 or so pages in that tab's history. You can jump back two or three steps at once by clicking on the title of the page you want. – Jonesey95 (talk) 21:47, 30 September 2013 (UTC)[reply]

Yes, or you can right-click the back button for the same effect. --Redrose64 (talk) 22:07, 30 September 2013 (UTC)[reply]

I haven't asked what version. I should try these ideas if it happens again. But no one seems to be saying this is a bug.— Vchimpanzee · talk · contributions · 17:19, 2 October 2013 (UTC)[reply]

For some reason my HotCat, despite being enabled in preferences, is not working and the bottom of articles is displayed as if HotCat weren't enabled. I tried resetting my preferences back to default and enabling HotCat by itself and that still didn't work. When I made this edit to my common js page didn't make any difference either but that was more my wondering "I wonder if this will do anything" more than anything else. My browser is SRWare Iron, version 27.0.1500.0 (201000). I don't think browser compatability is an issue since hotcat lists Google Chrome as "tested and working" and SRWare Iron is chromium based. Thanks, — -dainomite   22:18, 30 September 2013 (UTC)[reply]

Dainomite In your User:Dainomite/vector.js file, delete the first 3 lines (including the */). That should fix it. equazcion� | 01:48, 1 Oct 2013 (UTC)

Awesome, thank you! I had no idea... — -dainomite   02:57, 1 October 2013 (UTC)[reply]

No problem :) equazcion� | 03:31, 1 Oct 2013 (UTC)

I put together the Absurd overhead report at Commons after finding a GIF with PHP exploit code. Many of these files are uncompressible (lacking redundant data), but the optimizers discard 70+% of the size. We deleted the RAR archives and have a crude check for ICC profiles. So what else could the extra data be? — Dispenser 03:01, 1 October 2013 (UTC)[reply]

Probably depends on the image. For example, File:M734 Parts.png has a huge private chunk named "cpIp". Extracting the data from that chunk, it's identified as "Composite Document File V2 Document, No summary info". It wouldn't surprise me if that turns out to be some proprietary program's native format, embedded in the PNG so that program can still edit the text and vector bits of the image. Anomie⚔ 11:39, 1 October 2013 (UTC)[reply]

And File:Bearing Suspense Taboo.JPG has an appended 7z archive, which is password protected. So almost certainly some sort of warez or other crap we don't want. The jpg itself is only 103199 bytes long. Anomie⚔ 12:16, 1 October 2013 (UTC)[reply]

Adobe Fireworks saves to a proprietary PNG format as its native source format, with all object and layer data etc, plus a flattened raster for general display. Those could be uploads where people neglected to export and just uploaded their Fireworks source files. equazcion� | 12:26, 1 Oct 2013 (UTC)

The sample Fireworks files from Adobe's website all match the 7z 6-byte magic number. All the files (including the JPEGs) match 7z magic number too, but fewer contain the string "Fireworks". I'll have to add this to the report. — Dispenser 15:02, 1 October 2013 (UTC) Mistaken, apparently grep ignores binary characters. Using bgrep now. — Dispenser 19:51, 1 October 2013 (UTC)[reply]

For those who are interested, embedded password-protected archives were previously discussed at Commons:Commons talk:Criteria for speedy deletion#password protected embedded files. --Stefan2 (talk) 17:31, 1 October 2013 (UTC)[reply]

I took a look at a few more of these now. File:Logo MdV 2012web.jpg and File:Revanlogo.jpg have insanely huge embedded ICC profiles, I don't know if it's stupidity or embedded data of some sort. I see a bunch of the PNGs have large "mkTS" and numerous large "mkBT" chunks, which are probably those Fireworks files that were mentioned. Anomie⚔ 21:19, 1 October 2013 (UTC)[reply]

Those two files have been nominated for speedy deletion as copyright violations (non-free logos). That way, we should also get rid of any embedded data. --Stefan2 (talk) 21:41, 1 October 2013 (UTC)[reply]

Fireworks files typically have many non-standard PNG chunks interspersed between smallish IDAT chunks. The PNG I examined with a "cpIp" chunk did not have this structure. The "Pngcheck" command line program can show exactly what chunks are present in a PNG, and whether there's additional bytes after the end of PNG data... AnonMoos (talk) 07:30, 2 October 2013 (UTC)[reply]

• Does anyone know why File:SGD Quad FINAL.jpg is so large? 1.75 MB sounds very much for 300x224 pixels... --Stefan2 (talk) 22:14, 2 October 2013 (UTC)[reply]
  • It has a great deal of junk (mostly what seems to be text, some binary) that all says "photoshop" all over the place. Anomie⚔ 01:20, 3 October 2013 (UTC)[reply]
    • Photoshop thumbnail, but mostly the ICC profile. I'd be more interested in why File:Basket of Fruit (after Carravagio) Sand Painting by Brian Pike.JPG and File:HJcurrentFF.png seem to be 99% junk. — Dispenser 01:56, 3 October 2013 (UTC)[reply]

wikidata seems not to send the wikilinks for the left column if I am not logged in as en:wi editor. --Best regards, KS (wat?) 10:44, 1 October 2013 (UTC)[reply]

It works for me. Try clearing your entire cache. What is your browser? Please give an example article. Are the links and language names not displayed at all? PrimeHunter (talk) 10:50, 1 October 2013 (UTC)[reply]

The ">languages ¤" link (at the left side) was sometimes closed when I logged out and reloaded the page I was viewing. But now I can't reproduce the failure. It is all right now. --Best regards, KS (wat?) 20:55, 1 October 2013 (UTC)[reply]

The languages list depends on javascript, and a typical Wikipedia page uses several .js files; like the CSS files, these don't come from the main Wikipedia servers at the domain "en.wikipedia.org", but a separate server at "bits.wikimedia.org". If a crucial one of these files fails to make it through from the bits server, the languages list may fail to display correctly - or at all. --Redrose64 (talk) 21:34, 1 October 2013 (UTC)[reply]

I am trying to developing a webapp for Wikipedia using its API.

To get the content of the title 'Poole', I am using the following API.

Wiki API Call for Poole

But I do not get the section data for References and Notes. It only contains empty h3 tags as follows;

<h2>References and notes</h2> <h3>Notes</h3> <h3>Bibliography</h3>

If I see the same article in the mobile view of Wikipedia then I can see the entire data for the entire section.

URL for the same - https://en.m.wikipedia.org/wiki/Poole

Can you please let me know what I am doing wrong ? or is there any issue with the Wiki API ? — Preceding unsigned comment added by Harin4wiki (talk • contribs) 11:06, 1 October 2013 (UTC)[reply]

Pages don't actually contain references in those sections. References and notes sections are mostly generated on-the-fly by templates, usually the {{reflist}} template, using code found throughout the rest of the article text in <ref> tags. That's why the API doesn't deliver references in those sections -- they aren't actually there in the saved page code. equazcion� | 11:34, 1 Oct 2013 (UTC)

You should probably disregard what I just said, on second thought. I notice you're getting html coded output from the API, rather than wikicode, which I guess should contain the references (I'm not entirely sure). Perhaps someone else can explain. equazcion� | 11:45, 1 Oct 2013 (UTC)

Okay, first, let's offer others responding an easier to read api link: https://en.wikipedia.org/w/api.php?action=query&prop=extracts%7Cpageimages%7Clinks&piprop=thumbnail%7Cname&pithumbsize=240&plnamespace=0&pllimit=500&format=jsonfm&redirects=&titles=Poole

Next, what do you mean by "section data"? Do you mean the content of what is in those sections? If that is the case, then you want the full page content using: https://en.wikipedia.org/w/api.php?action=query&prop=revisions%7Cpageimages%7Clinks&rvprop=content&piprop=thumbnail%7Cname&pithumbsize=240&plnamespace=0&pllimit=500&format=json&redirects=&titles=Poole (human friendly version) replacing "extracts|" with "|revisions&rvprop=content" of which will give you the wikitext of the page that you will have to parse the page data yourself to get the list of references. Or... You could just do an HTML scrape on the page itself if you are doing this from outside Wikipedia instead of a userscript that runs on the page itself. If you are doing on the userpage itself, then just use jQuery to find the information you want.

I'll need more details to help you further. Technical 13 (talk) 12:21, 1 October 2013 (UTC)[reply]

Hi I was wondering if somebody knew how to get the title of the article to be in the centre rather than the left?♦ Dr. Blofeld 11:17, 1 October 2013 (UTC)[reply]

If you mean making a particular title display that way for all users, I don't think we can currently do that. If you want to have all article titles display that way just for you, you can add this to your common.js file:

• $('.firstHeading').css('text-align','center');

equazcion� | 11:23, 1 Oct 2013 (UTC)

Why make it that complicated?

.firstHeading { text-align: center; }

in Special:MyPage/common.css will do it. --Redrose64 (talk) 11:32, 1 October 2013 (UTC)[reply]

As a js coder my brain defaults to js solutions. But yeah the CSS method is basically the same thing, and is probably more "appropriate". equazcion� | 11:48, 1 Oct 2013 (UTC)

Thanks for the quick response!♦ Dr. Blofeld 12:34, 1 October 2013 (UTC)[reply]

• Also DISPLAYTITLE allows span alignments: An individual title can be shifted by using a span-tag when styling the page title:

• {{DISPLAYTITLE:<span style="margin-left:4em">Xxxx</span>}}

However, the same style would apply when editing the page, to display extra spacing at the top: "Editing Xxxx". Anyway, there might be cases where the span-styling of the title would be more appropriate, such as for a rock band name with multiple fonts.

• {{DISPLAYTITLE:RockBand<span style="font-family:Georgia">789</span>}} → RockBand789

Things to ponder. -Wikid77 12:41, 1 October 2013 (UTC)[reply]

So what would be the full coding for a centrally aligned slightly boldened/largened Georgia font for article titles?♦ Dr. Blofeld 13:44, 1 October 2013 (UTC)[reply]

In order that the font size can be relative to the normal size for a first-level heading, you need to do it as two rules instead of one:

.firstHeading {
  font-family: Georgia, sans-serif;
  font-weight: bolder;
  text-align: center;
}
.firstHeading span {
  font-size: larger;
}

I've put each declaration onto a separate line for clarity - you can run them together onto one line if you like; the only mandatory space is the one before span Again, this goes in Special:MyPage/common.css. --Redrose64 (talk) 16:34, 1 October 2013 (UTC)[reply]

I think I had a gadget allowing to see the number of rights, edits, etc. of a contributor and the content of a diff when hovering over the watchlist, but it's gone. I am also looking for a gadget allowing to see the references when editing a section. Thanks, — Racconish^Tk 13:33, 1 October 2013 (UTC)[reply]

I'm pretty sure that you're thinking of Wikipedia:Tools/Navigation popups, which is the seventh gadget in the list on the preferences page. ​—DoRD (talk)​ 13:42, 1 October 2013 (UTC)[reply]

Right on, thanks ! Does the one on references ring a bell ? — Racconish^Tk 15:02, 1 October 2013 (UTC)[reply]

There is a popup for references, it is at Preferences → Gadgets - last item in the "Browsing" section, "^(D) Reference Tooltips: hover over inline citations to see reference information without moving away from the article text (does not work if "Navigation popups" is enabled above)". However, it's only active in the page view, not in the edit window.

Viewing the refs when editing a section has been a wishlist item for years. What some people do is to put a dummy <references /> at the bottom of the section, and preview it. Make sure that you remove it before saving. --Redrose64 (talk) 16:47, 1 October 2013 (UTC)[reply]

Thanks Redrose. I was looking for an equivalent of this gadget. Cheers, — Racconish^Tk 17:26, 1 October 2013 (UTC)[reply]

Twice this morning I've had 'invalid token' errors while trying to use Twinkle to apply templates to usertalkpages, and just now I got a 'Grabbing data of earlier revisions: Exception Caught: DB connection error: Can't connect to MySQL server on '10.64.16.10' (111) (10.64.16.10)' error while trying to do a revert. - The Bushranger _{One ping only} 14:22, 1 October 2013 (UTC)[reply]

I have noticed this problem before and I wonder if here is something I can put in the wikicode that will fix it. Here's an example of an article where this is happening: Wikipedia talk:Articles for creation/Tony Grey. In the edit window, as soon as the line break code is entered in the infobox, all subsequent text is pink, making it hard to pick out embedded items in the text. —Anne Delong (talk) 15:03, 1 October 2013 (UTC)[reply]

By "line break code", do you mean a newline, or the <br> tag? Does the text show pink in the edit window, or on the page when viewed? Is this when using the VisualEditor, WikEd, or the traditional editor? --Redrose64 (talk) 16:51, 1 October 2013 (UTC)[reply]

Yes, as you can see in the edit window, after the <br> tag, using "Edit Source". The colours are added for visual context while editing, and don't appear on the saved page. —Anne Delong (talk) 17:44, 1 October 2013 (UTC)[reply]

I have been able to replicate this - but only if I go to Preferences → Gadgets, and enable "^(S) Syntax highlighter: Alternative to the default coloring of wiki syntax in the edit box (works best in Firefox and works almost all of the time in Chrome and Opera)". If you alter those <br> to <br /> the pink background ends immediately after the > as you would expect. Both <br> and <br /> are valid in HTML5, which is what Wikipedia serves at present. --Redrose64 (talk) 19:04, 1 October 2013 (UTC)[reply]

Thank you for taking the time to help me out. I'm sorry that I forgot that long ago I had enabled the colours with a gadget. I regularly see articles with <br> in the infoboxes. If they have been deprecated, is there a better way to force an "/n" in an infobox? —Anne Delong (talk) 20:29, 1 October 2013 (UTC)[reply]

The <br> tag isn't deprecated; the problem is that the syntax highlight gadget doesn't handle it correctly, although it copes fine with <br />. Changing <br> to <br /> will not alter either the validity or appearance of the rendered page. However, they are not recommended for use as separators in a list. If the various items that they are being used to separate is semantically a list, it's probably better to use one of the templates that mark up the items as a list, which (I am told) will enable screen-reader software to announce them in a more suitable manner. For example, instead of

| associated_acts     = [[Hiromi]] <br> [[John McLaughlin]] <br>

you could use the {{plainlist}} template, like this:

| associated_acts     = {{plainlist|
*[[Hiromi]]
*[[John McLaughlin]]
}}

BTW: that six-string bass that he's playing in the photo is an unusual instrument (even Dave Pegg doesn't go above five), and could do with a mention. Do you happen to know if the tuning is B0 E1 A1 D2 G2 C3; B0 E1 A1 D2 G2 B2; or G0 B0 E1 A1 D2 G2. --Redrose64 (talk) 21:13, 1 October 2013 (UTC)[reply]

I'm sorry, I don't know; it's not my article. It's in the Afc and I was just trying to straighten up the citations and having trouble spotting them. My bass looks like this, and has only the usual four strings. But back on topic, I can see that the beginning editors I am working with would be flummoxed if I inserted one templated item inside another in their articles, so I'll try out your backslash suggestion instead, and save the plainlist information for the future when I may need it in one of my own articles. And I'm sorry that I didn't read your first answer carefully enough, mistakenly thinking you said that the tags were no longer valid. Thanks again. —Anne Delong (talk) 21:45, 1 October 2013 (UTC)[reply]

SO, I went to login to Wikipedia and I saw this after I entered my username (but not my password )

File:Wikierror10012013.jpg

I realize anyone can read any messasge on my talkpage, but it's acting like I already logged in. Anyone else seeing that, if so, that looks to me like it would be a security issue  KoshVorlon. We are all Kosh   16:58, 1 October 2013 (UTC) [reply]

20:00, 2 October 2013 (UTC)

Traceback (most recent call last):
  File "C:\core\pywikibot\login.py", line 15, in <module>
    import pywikibot
ImportError: No module named pywikibot

Please consider joining the feedback request service. An editor has requested comments from other editors for this discussion. This page has been added to the following list: Wikipedia technical issues and templates When discussion has ended, remove this tag and it will be removed from the list. If this page is on additional lists, they will be noted below.