Wikipedia:Village pump (technical)

The technical section of the village pump is used to discuss technical issues about Wikipedia. Bugs and feature requests should be made at Bugzilla (see how to report a bug). Bugs with security implications should be reported to security

wikimedia.org or filed under the "Security" product in Bugzilla.

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

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

Invitation to test Hovercards

Hi everyone,

We’d like to invite you to beta test Hovercards. Hovercards is inspired by Navigation Popups, and shows you a card and image which provides a summary of any article link you hover over. Unlike Navigation Popups, Hovercards is aimed at satisfying the needs of readers, so the cards are more minimal and don’t include actions. In a future release we may consider adding an “Advanced” option for editors which exposes actions, but for our first release we are tightly focussed on the reader experience.

To turn Hovercards on, click the “Beta” link at the top right of your screen, scroll down until you find Hovercards, and tick the box!

We’d appreciate any feedback you have. You can leave feedback at mw:Talk:Beta Features/Hovercards. Bug reports can be filed at Bugzilla.

Thanks!

--Dan Garry, Wikimedia Foundation (talk) 21:39, 5 June 2014 (UTC)[reply]

This is just my occasional reminder that if you don't have a Bugzilla account (which not only is completely separate from your Wikipedia account, but which also publishes your e-mail address to the world), and you ever need to get a bug filed, then you can always leave a note on my talk page with the written report that you need filed. There are a lot of volunteer and staff devs who are also willing to help out with these things. Whatamidoing (WMF) (talk) 19:52, 6 June 2014 (UTC)[reply]

I had it enabled for a few weeks before but had to stop using it because of this annoying bug. However, it's fixed now thankfully and I've reenabled Hovercard. Huzzah!, — dain omite 20:11, 6 June 2014 (UTC)[reply]

Indeed. We waited to post this notice until after we got the fix for that bug merged. I'm glad you're enjoying it! --Dan Garry, Wikimedia Foundation (talk) 00:06, 12 June 2014 (UTC)[reply]

Having read "provides the casual reader with a streamlined browsing experience" in the description (and then read the rest too...), my reply to the invitation is "thanks, but no thanks". I hope it will be an opt-in feature, or at least have an easily accessible opt-out. Peridon (talk) 13:26, 11 June 2014 (UTC)[reply]

@DGarry (WMF): I would have left a comment at mw, but I don't appear to have the privilege of editing there. The 'Add new topic' button is greyed out, and there is no 'edit' button that I can see. Yes, I was logged in. If that is how Flow works, you can keep it for me. It looks as bad as this new Media viewer thing in the thread below this one. Peridon (talk) 13:34, 11 June 2014 (UTC)[reply]

BTW I regard 'being focussed on someone's experience' as an indicator of spamming... PR or marketing talk. Peridon (talk) 13:38, 11 June 2014 (UTC)[reply]

High-level design briefs can often sound like that. You'll notice I've kept my messages on this board a lot more precise, as the audience here appreciates more specificity. --Dan Garry, Wikimedia Foundation (talk) 00:02, 12 June 2014 (UTC)[reply]

I've just re-created my user page at mw (someone having deleted my previous one for being 'spam'), but still cannot edit the page linked above, or the Flow talk page. Does this mean that I will be unable to use Flow if it gets rolled out here? Peridon (talk) 10:25, 12 June 2014 (UTC)[reply]

Peridon, what happens with you click in the text box that you described as "grayed out", where it has a + sign and says "Start a new topic"? WhatamIdoing (talk) 18:07, 12 June 2014 (UTC)[reply]

Absolutely nothing. No little hand to show I'm over a link, no action. There's no 'edit' button either. I can view history, or click other little buttons, and even (it seems - I haven't saved) edit the header (there's a little pencil for that). No new topic, though. Just grey. They're welcome to the thing - I don't want to see it brought in here without some sort of opt-out. Probably impossible, as with so much of the technical wizardry that only serves to confuse people. Peridon (talk) 20:06, 12 June 2014 (UTC)[reply]

@Peridon: Thanks for the feedback on the design - the grey text has been mentioned a few times, and is being addressed in the almost-finished redesign - in the current version, it looks even lighter in Firefox, which adds additional opacity to "placeholder" text, which is very annoying.

Regarding the problem with not being able to create a new topic, I'll look into it. Could you let me know what browser/OS you're using, and if there are any non-standard settings, so that I can try to reproduce the problem in order to file a bug? Much thanks. Quiddity (WMF) (talk) 01:08, 13 June 2014 (UTC)[reply]

@Quiddity (WMF): Firefox 20 on XP Pro (classic view) with Monobook. I change settings only when needed, so I couldn't tell you what is standard and what not. So far as I know, the only changes I've made at mw would be to use Monobook as I loathe Vector. I'm not in mw very often, and probably won't be after someone deleting my user page as spam without warning or notice. The grey doesn't look like a deliberate grey - it looks like a something missing (like the link that's supposed to be there) grey. If it IS a deliberate grey, please bin it and use a decent black. Grey is hard to see for a lot of people, as are thin lined fonts (such as New Scientist uses). To hell with fashion - go for clarity. Peridon (talk) 19:38, 13 June 2014 (UTC)[reply]

I wonder if the designers could be convinced to make it exactly the same colors as the Search box. That's "grey", but nobody looks at that and says it's not working or "greyed out". WhatamIdoing (talk) 14:46, 18 June 2014 (UTC)[reply]

Which search box? The one I get in Monobook looks black (or so close to as doesn't matter). I haven't tried searching in Vector or a Flow page. Peridon (talk) 17:49, 22 June 2014 (UTC)[reply]

The search box in Vector: gray lines, gray word, gray icon

The search box in Monobook: gray lines, gray word, gray buttons

Neither the word Search nor the lines forming the search box in these two screenshots look black to me. Does yours look different? WhatamIdoing (talk) 19:46, 23 June 2014 (UTC)[reply]

Tech News: 2014-24

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

Recent software changes

The latest version of MediaWiki (1.24wmf8) was added to test wikis and MediaWiki.org on June 5. It will be added to non-Wikipedia wikis on June 10, and to all Wikipedias on June 12 (calendar).
You can now use guided tours on the Arabic (ar), Bengali (bn) and Norwegian (no) Wikipedias. If you want this tool on your wiki, you need to translate it and ask in Bugzilla. [1] [2]

VisualEditor news

You should no longer be able to add empty references with VisualEditor. [3] [4]
The "use an existing reference" button in the reference tool is now shown as disabled, rather than hidden, when the reference has content. [5] [6] [7]
You will now see category contents again after saving an edit to a category page with VisualEditor. [8] [9]

Future software changes

MediaViewer will be enabled by default on all wikis on June 12. Feedback is welcome. [10]
You will be able to use information from Wikidata directly in Wikiquote pages starting on June 10. [11]
On wikis with the Translate extension enabled, translation administrators will soon be able to use the page migration tool to import existing translations to the new system. [12] [13]
You will soon see metadata on file description pages for Ogg files (example video, example audio). Some metadata with non-English characters may need to be purged or transcoded to UTF-8 before they show correctly. [14] [15]
Templates containing <ref> or <references> tags will no longer need dummy parameters to prevent caching. [16] [17] [18]
You will no longer be able to use Special:Thanks directly. The page will soon show an error message when you visit it. [19] [20]
Hovercards will no longer flicker. [21]

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

07:39, 9 June 2014 (UTC)

Templates containing `<ref>` or `<references>` tags will no longer need dummy parameters to prevent caching.

This means that |close=1 will no longer be needed with {{reflist}} and variants. I performed a quick test on mediawiki.org and it looks good. Once deployed, template documentation will be updated. -- Gadget850^talk 10:41, 9 June 2014 (UTC)[reply]

We are now running 1.24wmf8. This fix is not deployed and is not listed in the 1.24wmf8 change log. -- Gadget850^talk 20:32, 12 June 2014 (UTC)[reply]

That change is coming with 1.24wmf9. Jackmcbarn (talk) 16:02, 13 June 2014 (UTC)[reply]

Not listed in the 1.24wmf9 change log. -- Gadget850^talk 13:38, 15 June 2014 (UTC)[reply]

1.24wmf9 is now deployed, but this fix is not. -- Gadget850^talk 18:37, 20 June 2014 (UTC)[reply]

Yes it is. See Special:Permalink/613719402. Jackmcbarn (talk) 18:39, 20 June 2014 (UTC)[reply]

Yes. Needed a purge. -- Gadget850^talk 18:53, 20 June 2014 (UTC)[reply]

Question re Special: Thanks

Are you telling us that we will no longer be able to "thank" another editor by clicking (thank) on revision diffs under article history ? — Maile (talk) 19:34, 9 June 2014 (UTC)[reply]

@Maile66: No, this will continue to work exactly as it does now. If you've never typed "Special:Thanks" into the search box, this doesn't affect you. :) Matma Rex talk 19:38, 9 June 2014 (UTC)[reply]

@Maile66: At the moment, you can go to Special:Thanks, type in the revision ID for an edit (for example, the revision number for this edit is 612255080), click Submit and you then see "(Example) was notified that you liked their edit". In future, this method will not be available, but the "thank" link on the edit will still work. --Redrose64 (talk) 19:58, 9 June 2014 (UTC)[reply]

Thanks to both of you for this information. — Maile (talk) 21:01, 9 June 2014 (UTC)[reply]

Hmmm, the thank button appears not to be working. Either that, or it is working but the thanker is not being told that the thankee has been thanked, if you get my meaning! Mjroots (talk) 10:01, 24 June 2014 (UTC)[reply]

I've just thanked you; I saw the usual "Are you sure?" popup, and the action was logged. You last thanked someone on 15 June. -- John of Reading (talk) 10:12, 24 June 2014 (UTC)[reply]

@John of Reading: - yes, I got your thanks. Confirms what I said though. Button not working for me. I tried to thank two separate editors today without success. Mjroots (talk) 11:46, 24 June 2014 (UTC)[reply]

Tool for Page →History → Contributors

Tracked in Phabricator
Task T60869

This used to be a tool to give us a list of article contributors by name and by edit count. Then there has been this long time when all that came up was a message that all tools are being migrated to Labs. Has that migration completed? Because What comes up has absolutely nothing to do with individual contributors. — Maile (talk) 19:20, 10 June 2014 (UTC)[reply]

You could use XTools - and if you like it, it's new gadget-helper. Migration from toolserver is done and I'm about to put the finishing touches on it. Hope you like it. --Hedonil (talk) 00:09, 11 June 2014 (UTC)[reply]

XTools is pretty neat . I see what I'm looking for. It's the Page History tool at XTools, which gives a pretty awesome account. And scrolling down to the bottom, I see the information Contributors tool used to give. XTools Page History is way more cool and informative than the old tool was.— Maile (talk) 11:58, 11 June 2014 (UTC)[reply]

Also, I following your instructions on adding this as a Gadget, and now I see the stats showing at the top of my article pages. Thank you so much. — Maile (talk) 12:09, 11 June 2014 (UTC)[reply]

Very nice.--S Philbrick (Talk) 17:40, 11 June 2014 (UTC)[reply]

Yeah, when is the old "Contributors" thing coming back? p b p 04:03, 12 June 2014 (UTC)[reply]

Ditto, this is a useful feature.--♦IanMacM♦ ^{(talk to me)} 06:38, 12 June 2014 (UTC)[reply]

See also Wikipedia:Village pump (technical)/Archive 126#Contributors to a Wikipedia page, and probably a couple of others. As I understand the situation, the actual "problem" is that volunteers can't be forced to port their tools to WMFLabs if they don't want to (and I'm not sure that the independence of volunteers is truly a "problem" in the end, although this particular volunteer's choice is inconvenient for me, too). WhatamIdoing (talk) 18:14, 12 June 2014 (UTC)[reply]

And to add on to what WhatamIdoing said, these topics also don't encourage these volunteers to do it either. Why not go to their page and say "I really love your tool, it's super useful, we appreciate your technical expertise, and value your time on this project. Could you please migrate? We promise Wiki-cookies". That'll do 1 x 10 ^ 6 more towards getting them to actually do it than complaining here and calling them out. From a tool owner perspective, it essentially feels like being called lazy and you come off as unappreciative.--v/r - T P 18:44, 12 June 2014 (UTC)[reply]

I'm not sure which one of us on this thread you are referring to. However, my initial question was because I have no idea who maintains or created a lot of those tools on page history. — Maile (talk) 19:03, 12 June 2014 (UTC)[reply]

It's really directed at anyone who has ever come here for a tool written by a volunteer - ever :). That particular tool is run by meta:User_talk:Duesentrieb.--v/r - T P 19:16, 12 June 2014 (UTC)[reply]

I left a note on Duesentrieb's talk pages - both the English page and the German page. And I found a few notes by other people. Perhaps if enough of us ask, it will eventually be fixed. Dirac66 (talk) 20:01, 13 June 2014 (UTC)[reply]

Article Info is also a good tool.--v/r - T P 22:08, 13 June 2014 (UTC)[reply]

Solution found

Thanks very much to TP for suggesting Article Info! This leads to a form which says "Page history - Get various statistics about the history of a page", so I tried the Revision history statistics link on an article History page, and found an even more direct route to the List of contributors, now called Top Editors.

So my directions would be - choose any article, go to the History page and click on Revision history statistics, then scroll down to Top editors. True, the list doesn't include the least frequent editors with 1 or 2 edits, but one can still check for any single editor's contributions by using Edits by user. Dirac66 (talk) 19:41, 14 June 2014 (UTC)[reply]

That's the XTool that Hedonil mentioned above, which you can add this as a Gadget. There's a draw-back to the XTool, I'm just noticing. It only gives the select "top" editors, not all of them. That's very limiting on many articles. While I like the XTool, I'd really like to have the old one working. Sometimes there is a need to see ALL the contributors of an article, in particular the IPs. — Maile (talk) 22:13, 14 June 2014 (UTC)[reply]

I've added a line to topeditors section which now shows the number & count of all other editors (besides the top 30) - and a link that provides an extra url-parameter editorlimit for more results. This value decuples on each more call (30, 300, 3000 ...), or you can set it by hand. This way, you have free choice on how many rows you want to retrieve. --Hedonil (talk) 15:49, 17 June 2014 (UTC)[reply]

Excellent. I think that with these more calls, Revision history statistics now provides all the information formerly given by List of contributors plus a lot more. The only remaining problem I see is that many people don't know where to look, since List of contributors still leads to the wrong form. Would it be possible to put some sort of redirect on List of contributors, so that it leads to Revision history statistics? Dirac66 (talk) 19:43, 17 June 2014 (UTC)[reply]

Thank you, Hedonil. I just discovered this tool has been substituted for the old one under the Article history "Contributors". And I do see where you added the extra "more" so we can see all the editors. This tool is awesome. Thank you for all the time you spent developing it and deliverng it to us. — Maile (talk) 21:38, 19 June 2014 (UTC)[reply]

Well...Labs now says there's "no service". Let's hope that's temporary, because the little gadget for the XTool is not functioning right now, either. — Maile (talk) 21:43, 19 June 2014 (UTC)[reply]

Labs and the gadget back to normal now. So thanks again for this tool. — Maile (talk) 22:11, 19 June 2014 (UTC)[reply]

IP disruption proposal

I have posted an idea at the ideas lab (User:Spinningspark/IP disruption proposal) but perhaps I can also ask for people here to assess it for technical feasibility just for reassurance that I am not being completely stupid. Well alright, I am completely stupid, but there may still be some merit in the idea. Spinning Spark 16:10, 15 June 2014 (UTC)[reply]

I think it is a marvelous suggestion for lessening disruption by IP-hopping vandals. Binksternet (talk) 16:36, 15 June 2014 (UTC)[reply]

Well first of all, people can choose not to have cookies enabled of course. Plenty folks do that. Second a browser cannot easily return the MAC address in a cookie. If that was possible, advertising agencies would have a field day. Lastly, cookies expire at some point and can be deleted by users, killing your tracker. Also it might conflict with our current privacy policy (not sure). —TheDJ (talk • contribs) 17:11, 15 June 2014 (UTC)[reply]

Cookies may not be the best method of retrieving the MAC address, I don't know, that's why I am asking for technical review. Perhaps I ought just to say what we want to achieve and leave it to the devs to find a method. However, I don't think a user clearing out cookies would be a problem. The history associated with that MAC will still be there on the server and the server will place a new cookie the next time that machine tries to edit. The new edits will still be added to the right history. Spinning Spark 17:26, 15 June 2014 (UTC)[reply]

It is not possible to retrieve the MAC address via the web browser without the use of custom plugins, even if it were possible MAC addresses are modifiable, and even if they weren't this is most likely not going to fly with Wikimedia Foundation's privacy policy. Matma Rex talk 17:33, 15 June 2014 (UTC)[reply]

I can't see what the privacy issue is. Hiding the IP address is improving privacy, not breaching it. I also don't understand why access to the MAC address is a security issue, but I expect there is a good answer to that. If it is technically impossible then it is a dead idea anyway, but before I let go of it altogether, this forum suggests that it might be possible with Java or signed Javascript. I appreciate that MAC addresses can be spoofed, but I am not looking for something that is completely unbreakable; we are not guarding nuclear secrets here. Yes, a MAC address can be spoofed, but it is not as easy as getting a new IP from an ISP that dynamically allocates them on each connection. This would be putting one more obstacle in the way of the trolls, most of whom are amateurs and would be stopped by this. Spinning Spark 19:56, 15 June 2014 (UTC)[reply]

This just isn't technically feasible. There's no way that the developers would ever go for running signed JavaScript or a Java applet just to retrieve a user's MAC address. Jackmcbarn (talk) 20:09, 15 June 2014 (UTC)[reply]

Humour me for a moment. What are the difficulties? Spinning Spark 20:29, 15 June 2014 (UTC)[reply]

Using JAVA to achieve this, is like attaching an unreliable Tank to a bike, when you are competing in the Tour de France. You just don't do it. —TheDJ (talk • contribs) 00:42, 16 June 2014 (UTC)[reply]

I'm pretty sure the JavaScript part is untrue, or at least I don't know of any API that would allow this (and the post doesn't mention any either). It might be possible with Java applets (I'm not experienced enough in this to know for sure), but wouldn't be feasible because a) signing applets is apparently non-trivial and unsigned ones pop up huge red warnings in browsers, b) Java security vulnerabilities appear often enough that browsers often automatically disable the plugin even if it's installed, but outdated, and updating it is not straightforward, and c) these days people very often[citation needed] don't even have Java installed (assuming their device can even run it), as it's been largely displaced by Flash and HTML5 for web usage. (The Java applet page is an interesting reading, although it seems outdated by a year or two.) Matma Rex talk 01:18, 16 June 2014 (UTC)[reply]

I mostly meant the part about cookies when I mentioned the privacy policy, I vaguely recall that there used to be some rather draconian limits on cookie usage and expiration defined there (IIRC this was the reason why the login cookies used to expire in 30 days), but they seem a bit more lax these days (wmf:Privacy_policy#Information_We_Collect, wmf:Privacy_policy/FAQ#cookieFAQ). If we were to identify users by their MAC addresses (which is probably not possible and definitely not feasible), this would surely have to be incorporated there as well. Disclaimer: I am, obviously, not a lawyer :) Matma Rex talk 01:18, 16 June 2014 (UTC)[reply]

Without some other unique, system-based, non-spoofable identifier it would be inappropriate to hide the IP address for the record of any such edits.

However, the issue of obtaining the MAC address is something of a red herring. While it would be nice to have a non-user-changable method of uniquely identifying the machine from which edits were being made, having a way to uniquely identify the hardware does not appear reasonable. On the other hand, just having the servers assign a unique code to the machine in a cookie, even if the code is only valid for a set period of time (e.g. 30 days), could go a long way toward tracking vandals across IP changes. Alternately, the cookie could just record the IP addresses from which the non-logged-in editor has been editing. These could be checked against being blocked and if the majority are blocked then edits are disallowed. Obviously, the vandal could just disable cookies, or delete the cookie. While it would be possible to require cookies be enabled in order to edit as an IP, that is probably not a good idea. Limiting it to a just a cookie without unique physical machine ID allows for the possibility of multiple user accounts on the same machine (e.g. a family's shared computer).

Basically, there are multiple ways in which it would be possible, although imperfectly, to determine that IP edits are being performed by the same machine/user from different IP addresses. Using just cookies is imperfect, but would probably hinder, or at least make life a bit less convenient for, a significant percentage of vandals. — Makyen (talk) 02:07, 16 June 2014 (UTC)[reply]

I like the idea that a Wikimedia-centric cookie would assign a unique identifier, the cookie lasting 30 days. Such a feature would catch many of our vandals and socks, despite some of them being savvy enough to employ a workaround. Binksternet (talk) 05:03, 20 June 2014 (UTC)[reply]

At a time when the continual decrease in editors, and the lack of new editors, is an increasing problem, is trying to make things less convenient for IP editors and raising barriers to those first few edits really a big priority? Solutions such as "requiring cookies be enabled to edit as an IP" suggest that IP hopping to edit anon is more of a problem than IP hopping to better manage a sock farm without alerting checkuser. Is that really the case? And once you're positing a troll who is deliberately IP-hopping in order to persistently vandalise and disrupt, the idea that a cookie is going to even inconvenience them is silly. 86.129.13.205 (talk) 18:11, 24 June 2014 (UTC)[reply]

Random file tool returns files from Commons

Tracked in Phabricator
Task T68643

Hi. I was using the Special:Random/File tool for a long time on rowiki, in order to fish for unfree images and candidates for Commons. Last days when I accessed the tool, it returned me only Commons files. Tried @ enwiki - same drill. Anyone knows if it's a bug or something has been changed in the Random tool? John of Reading suggested on the Help desk this might be linked to bugzilla:65366. Thanks in advance for assistance. --Gikü (talk) 18:25, 15 June 2014 (UTC)[reply]

Filed as bugzilla:66643. NEverett (WMF) (talk) 19:41, 15 June 2014 (UTC)[reply]

I'm pretty sure you rock :D Thanks! --Gikü (talk) 19:55, 15 June 2014 (UTC)[reply]

Should be fixed in gerrit:139833 by Manybubbles aka NEverett (it now has code to restrict results to the local wiki). It should have also fixed an issue where Special:Random/Talk, /User, etc. did not always forward to the correct namespace, and added Selenium tests for good measure. Thanks NEverett (WMF)! πr² (t • c) 04:08, 17 June 2014 (UTC)[reply]

Just pushed the fix live a few minutes ago. Please let me know if you notice anything funky.NEverett (WMF) (talk) 15:20, 17 June 2014 (UTC)[reply]

Many thanks for fixing Special:Random but mw:Extension:Randomrootpage seems to have been left out of the correction loop - most likely because its more a Wikisource/Wikibooks enabled extension than a Wikipedia one.

Can someone take a stab at updating it so not only are namespaces selectable like in Special:Random but those with sub-pages in use target the only the root again? -- George Orwell III (talk) 05:05, 24 June 2014 (UTC)[reply]

Fixed it already, after Thursday's branch point though. I'll make a note to get this out tomorrow. ^demon^{[omg plz]} 05:43, 24 June 2014 (UTC)[reply]

All fixed. ^demon^{[omg plz]} 15:22, 24 June 2014 (UTC)[reply]

Posting data a diff from an external site

I have a bot which takes the content of a page on Commons, cleans it up, and then posts it as if the user had clicked diff in the edit box so that s/he can view the changes and submit them if desired.

Click here for an example: [22].

Unfortunately, it looks like it's stopped working; the software doesn't accept my post anymore; it blanks the text.

This is what my bot is submitting:

wpTextbox1 = the text
wpSummary = a custom edit summary
wpDiff =" wpDiff"
wpStarttime = the current Mediawiki timestamp
wpEdittime = the Mediawiki timestamp for the previous edit time to the page
wpAntispam = [blank]

What am I doing wrong? Magog the Ogre (t • c) 20:24, 15 June 2014 (UTC)[reply]

Strange. It seems that show changes may be broken. πr² (t • c) 00:59, 16 June 2014 (UTC)[reply]

Try adding wpUltimateParam. πr² (t • c) 01:44, 16 June 2014 (UTC)[reply]

Tried, no dice.

Magog the Ogre (t • c) 21:32, 16 June 2014 (UTC)[reply]

Perhaps you need an edittoken in order to send the diff nowadays. In general I would say, it's either an encoding mistake, or you are just missing too many of the fields. —TheDJ (talk • contribs) 09:24, 17 June 2014 (UTC)[reply]

"Cleanup v2" works for me, but there are character set problems with some files. Note that "cleanup v2" sets wpDiff to "Click me if you have JavaScript disabled", not "wpDiff" as you wrote above. --Stefan2 (talk) 21:18, 19 June 2014 (UTC)[reply]

New mobile site for tablets

Update from the WMF Mobile Web team: Starting today, people accessing Wikimedia projects on a tablet will be sent to a special tablet-optimizied mobile site. Some features and functionality include:

larger fonts and better content formatting for improved readability
a mobile table of contents for page navigation
all sections open by default for long-form reading
improved thumbnail formatting
article actions (edit, add image, watchlist) and notifications
other reading and contribution features (login/create account, random article, upload, watchlist) in the left navigation menu

If you opt into the beta site (visit Settings in the left navigation menu and tap to opt into Beta), you'll also see a talk page feature, and starting June 19 20:00 UTC we will offer Visual Editor editing as an option for beta users, in addition to wikitext editing.

These changes are geared toward improving reading and contribution on a larger touch-screen device. If you prefer to use the old desktop version of the site, you can switch back by scrolling to the bottom of any page and tapping the "Desktop" link; this will return you to the desktop view until you opt back into the mobile view.

Let us know if you have any questions! We're available on IRC #wikimedia-mobile ^connect and via email (mobile-lwikimedia.org). Cheers, Maryana (WMF) (talk) 20:36, 17 June 2014 (UTC)[reply]

If I now visit an en.m. URL in my desktop browser, will I see the tablet or phone version? How may I switch to the other? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:20, 18 June 2014 (UTC)[reply]

Hi Andy – it's based on your browser window screen size. If it's larger than 768px by 768px, you get the tablet view, but if you shrink the window below those dimensions, you get the phone view. You can play around with resizing the window to see the changes between the two :) Maryana (WMF) (talk) 17:23, 18 June 2014 (UTC)[reply]

I am using Wikipedia on an iPad mini. I always want to see the desktop site, never the mobile site. Is there any way to achieve this without having to now scroll down to the bottom of the page and select desktop every single time I visit Wikipedia ? Can I opt out of the mobile version in some way ? Gandalf61 (talk) 06:31, 20 June 2014 (UTC)[reply]

You can opt out by clicking the 'Desktop' link at the bottom; a cookie will remember your preference. If you do get the mobile site again, check if cookies are not blocked, and your bookmark is not set to go to 'en.m.wikipedia.org'. -- [[User:Edokter]] {{talk}} 10:06, 20 June 2014 (UTC)[reply]

Wikipedia Article Traffic Stats: Problems, weird counting, and questions

When clicking the link to Wikipedia traffic statistics, since around 15:00 UTC, I attempted checking statistics for Tour de France, France national football team, Cristiano Ronaldo, United States men's national soccer team, and many more 2014 FIFA World Cup/sports-related articles. Using Firefox, I get "Problem Loading Page". Contacting Henrik, the operator of the traffic stats, does not work as he does not respond.

Plus, I'm seeing unusual pages such as University of East Anglia (not a popular university) and many other weird articles that I don't expect to see up in the top 1,000 list and many more that rank in the next 9,000. What is this issue? Are they Dos attacks? Is some bot doing something?

And, since our technology is advancing, I heard this doesn't count mobile pageviews. Could the pageview statistics count mobile, tablet, and other device pageviews? I think this would be a smart idea. A Great Catholic Person (talk) 05:15, 18 June 2014 (UTC)[reply]

In my professional capacity I'm the person actually rewriting the pageviews definitions, so:

This is a problem. I'm going to kick people internally to send him a note since, given that we bought him a new machine for the service, he should presumably want to reply to us. It could just be a TZ thing, though.
I have been investigating a similar problem reported by User:Gigs and User:PiRSquared17; having gone through the request logs of a page they highlighted, I'm pretty sure it's a bot attack wide disparity in IPs, circular referer chains and a single point of commonality in user agents - that most of them are on Windows XP. We're talking through ways of detecting this in the future.
Yes, it'll absolutely include mobile pageviews, if by that you mean 'pageviews through the mobile site'. Splitting out tablets versus phones on a per-article basis is potentially a pain, but it'll certainly be investigated. We're also looking at distinguishing different types of views: so, you'd have X pageviews, Y history pageviews and Z talkpage page views, or something. We'll see. Ironholds (talk) 05:25, 18 June 2014 (UTC)[reply]

Are hits from search engines crawling Wikipedia still included? Is there any kind of estimate of how many page hits these are likely to contribute? I seem to remember from a previous discussion that search engine hits could be a significant fraction of total hits for low-visited pages. I would like to see a disclaimer, or some information about this, on the page view statistics page. Sometimes people say "look, people do read this article, there are around 50 hits every day", but if 49 of those are non-human then it's misleading. 86.179.4.47 (talk) 13:25, 18 June 2014 (UTC)[reply]
They are, in some form. We have a relatively crude regular expression currently identifying spiders, although what happens to the spider after it's been identified is unknown to me. This is also something we're factoring into the newer version (we have a user agent parser now, which means we can exclude/specially identify and segment hits from spiders). Google, at least, is sensible about their crawling, and pairs crawls of a page with edits to that page. Ironholds (talk) 16:36, 19 June 2014 (UTC)[reply]

I'm puzzled by your last sentence. I wonder if you could explain that a little further? Surely you are not suggesting that Google's search engine edits Wikipedia pages?? 86.179.119.9 (talk) — Preceding undated comment added 17:31, 19 June 2014 (UTC)[reply]

I'm assuming that Ironholds mean Google is accessing the edit page during its crawling of the Web; by "clicking" all the links on the page it will eventually "click" the edit button. It does not edit pages. -- 140.202.10.134 (talk) 19:32, 19 June 2014 (UTC)[reply]

Neither, actually (although we do have edits that claim to be from google bot, because there are a couple of users who (a) spoof their user agent and (b) think they're a lot funnier than they actually are). So, google has a bot built just for crawling Wikimedia sites. We have millions (or billions?) of pages, some of which change very rarely, some of which change very statically; crawling them all, constantly, would be untenable, and crawling them all in one big load once a month would lead to outdated information about things people care the most about. Instead, google's bot crawls the recentchanges feed; when it sees a new entry, it goes to that article, and crawls it, and caches the results. That way things are always pretty much up to date, but google doesn't have to crawl every article - just the ones being updated. Ironholds (talk) 23:12, 19 June 2014 (UTC)[reply]

Thanks, that's interesting to know ... 86.179.119.9 (talk) 01:02, 20 June 2014 (UTC)[reply]

Magic word for Wikidata ID?

Is there a 'magic word' that will return the Wikidata property number of an article? I'd like to include one in a cleanup template. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:15, 18 June 2014 (UTC)[reply]

The nearest thing I could find was {{PAGEID}}, but I'm not sure that's the same thing. It Is Me Here ^{t / c} 12:01, 18 June 2014 (UTC)[reply]

No, the page ID isn't the same thing as the Wikidata item ID. And Andy, I assume that you want the item ID (e.g. "Q142" for France) rather than a property belonging to an item (e.g. Q142's property P36, the capital, is "Paris"). You can get the item ID by using Module:Wikibase:

{{#invoke:Wikibase|id}} → Script error: No such module "Wikibase".

That only works for the current page. Also, it doesn't appear to be documented either on the module page or at mw:Extension:WikibaseClient/Lua. The Lua part of the Wikibase extension is being rewritten, so there is a chance this functionality might be removed at some point (I'd have to ask the developers to find out for certain what's happening to it), but it works for now. — Mr. Stradivarius ^{♪ talk ♪} 12:55, 18 June 2014 (UTC)[reply]

I'll also note that if you have the XTools gadget installed, the link to See full page statistics shows the Wikidata ID (Might not help for a template, but other readers might be interested)--S Philbrick (Talk) 18:48, 18 June 2014 (UTC)[reply]

It is also listed in the "page information" link on the left-hand panel. --Mdann52talk to me! 21:43, 18 June 2014 (UTC) ← Thanks. --User:Ceyockey (talk to me) 23:30, 18 June 2014 (UTC)[reply]

@Mr. Stradivarius:} Thank you, I'll give that a try. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:15, 18 June 2014 (UTC)[reply]

Now working, on {{Gender unclear}}. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:25, 19 June 2014 (UTC)[reply]

Watchlists

Tracked in Phabricator
Task T33881

I have not used the "Watchlist" function until now, and I see that not all edits to an article I have put on my watchlist are being added to it. For example, for 18th June there are no edits listed at all, and yet in the "View history" page there are over 50. I have set the list to go back seven days, but there is nothing listed for 16th and 17th June either, while there have been many edits on those dates as well. Also, how does a watchlist for an article really differ in usefulness from its "View history" pages (apart from its not having the "curr-prev" and "Compare versions" facilities)? --P123ct1 (talk) 08:50, 19 June 2014 (UTC)[reply]

You can have many pages on your watchlist and choose to only see the most recent edit on each. See Help:Watching pages and Special:Preferences#mw-prefsection-watchlist. PrimeHunter (talk) 09:35, 19 June 2014 (UTC)[reply]

AFAIK the default setting is to only show the latest edit to each page on watchlists (but obviously not on page histories). The preference to change this is called "Expand watchlist to show all changes, not just the most recent" in the "Watchlist" tab (direct link in previous comment). The advantage of a watchlist is that you can keep track of many pages in one list; if you are watching only one page it's essentially the same as that page's history. SiBr₄ (talk) 11:08, 19 June 2014 (UTC)[reply]

Thanks. I would have never have guessed from my Watchlist page that I should go to Preferences! --P123ct1 (talk) 11:48, 19 June 2014 (UTC)[reply]

Interesting, a few developers were recently just discussing making the watch list preferences accessible from the watch list. —TheDJ (talk • contribs) 13:00, 19 June 2014 (UTC)[reply]

Size of tables

Is there a function that can return the number of rows in a table? I know that people have asked about automumbering before and the answer is no, but I don't necessarily want to autonumber. I just want to know the total the total number of entries. Spinning Spark 09:44, 19 June 2014 (UTC)[reply]

This might be possible in Lua, but it depends what exactly you want to be done. Can you give us any more details about how you want to use this row-counting function? — Mr. Stradivarius ^{♪ talk ♪} 09:53, 19 June 2014 (UTC)[reply]

I'll give one example: I am working on implementing a COI edit for Manitoba Sports Hall of Fame and Museum, replacing a scattered list of players with a sortable table. I ended up with 12 use cases, and worried that I might have missed someone. I knew there were 216 entries, so it would have been a nice and easy check if I could easily verify that my table had 216 entries. I know the work around, copy and past into Excel and count, but it would have been nice if I could access the number without doing that.--S Philbrick (Talk) 14:54, 19 June 2014 (UTC)[reply]

For things like that, a user script written in JavaScript would be a more natural choice than a Lua module. However, writing such a script might not be easy. You would have to ask someone more knowledgeable about JS than I. Lua would be more suitable for something like taking a list of names and outputting a formatted wikitable of the names, with e.g. a subheading at the top saying "this list contains nn items". — Mr. Stradivarius ^{♪ talk ♪} 15:26, 19 June 2014 (UTC)[reply]

Typing $('.wikitable tbody tr').length; at the console confirms that table has 216 rows. This should work elsewhere, although unfortunately it's going to get confused on pages with more than one table. Unless you're going to be requiring counts like this a lot, I'd suggest just saving that snippet somewhere to copy and paste when needed rather than going to the effort of turning it into a userscript which is loaded on every pageview. the wub "?!" 21:07, 19 June 2014 (UTC)[reply]

Nicely done. --User:Ceyockey (talk to me) 21:17, 19 June 2014 (UTC)[reply]

The article that prompted this was List of surviving veterans of World War II where there is a count of surviving veterans in each section. Every time an entry is added or deleted from the tables the count has to be manually adjusted. These counts rapidly become inaccurate because editors forget to do it, or did not realise in the first place. I wanted to automate this count. The count can be moved to after each table instead of in the headings if that helps (the heading is the wrong place to have this anyway). I have occasionally seen other articles where this would also be a useful feature. Spinning Spark 22:16, 20 June 2014 (UTC)[reply]

That would be a good job for Lua. However, there are two caveats: you would have to change the layout of the page so that the tables are generated by a template, and you would have to move the number of veterans out of the section heading. The problem with having the number of veterans in the section heading is that the heading would have to be generated by the template, and that means that when someone clicked on the section edit link they would be directed to the edit window of the template, rather than the edit window of the article. I'll work up a module to show you what I mean. — Mr. Stradivarius ^{♪ talk ♪} 06:28, 21 June 2014 (UTC)[reply]

@SpinningSpark: I've put together a demonstration in my sandbox. However, thinking about this, using this approach might not be as wise as I first thought. As List of surviving veterans of World War II is very long, converting all of it to use templates might put it over the post-expand include size template limit. That would mean that the end of the page would just display the text {{veteran list}} rather than actually expanding the template. An alternative solution would be to use Lua to grab the wikitext of the entire page and to try and parse that to find the number of table rows. However, such an approach wouldn't work work on page preview, as it uses the latest version of the page stored in the page history, and wouldn't work with things like nested tables, HTML tables, or tables inside templates. I'll see if I can create a module that does this, so that you can compare the approaches. — Mr. Stradivarius ^{♪ talk ♪} 07:40, 21 June 2014 (UTC)[reply]

@SpinningSpark: I've now written {{table row counter}}, which uses the approach I outlined in the latter half of my previous post. For example, {{table row counter|1|ignore=1|page=List of surviving veterans of World War II}} produces "". — Mr. Stradivarius ^{♪ talk ♪} 09:36, 21 June 2014 (UTC)[reply]

Excellent, that's exactly what I wanted. Thanks for doing that. Am I right in thinking that adding or removing a table is going to break this? Would it be possible to work instead from a manually inserted "id=" parameter in the table declaration? Spinning Spark 10:04, 21 June 2014 (UTC)[reply]

@SpinningSpark: That's a good point. I've added the ability to specify tables by ID. Take a look at the updated documentation at {{table row counter}}. — Mr. Stradivarius ^{♪ talk ♪} 05:51, 22 June 2014 (UTC)[reply]

Thanks once again! Spinning Spark 07:23, 22 June 2014 (UTC)[reply]

Poor search suggestions in search box

It's me again, not to report traffic stats (it's back up now), when I type in search suggestions I don't see any relevant topics. Type in "B" without pressing enter, some unpopular topic comes up. When you type in "I" it comes up with Iran Standard Time, and India second. A time zone would not be popular at all. Type in Super Bowl, the Super Bowl article comes first, but then do other old articles XLIII/2009, XLII/2008, and years before, rather than the current ones XLVIII/2014 and the upcoming XLIX/2015. PlayStations 2 and 3 come before PlayStation 4. Can someone fix this issue: Unpopular and outdated suggestions, because I see a glitch. Google and other search engines can put suggestions much, much better than Wikipedia, and Wikipedia needs to be as good as Google in updating search suggestions. A Great Catholic Person (talk) 20:32, 19 June 2014 (UTC)[reply]

I believe the algorithm looks at the "what links here" figures to work out which articles are most popular. Bakhsh and Iran Standard Time are linked from the infobox of just about every Iranian place name article (example). The algoithm isn't clever enough to see that these links are not important. -- John of Reading (talk) 21:23, 19 June 2014 (UTC)[reply]

Hmm...if suggestions are based solely on the popularity of links, I wonder if it'd be worth considering ignoring links that are a result of template transclusions? ~SuperHamster Talk Contribs 21:26, 19 June 2014 (UTC)[reply]

Accurately discounting links arising on transcluded templates from a count of 'what links here' is a rather difficult and expensive operation. However, having generated the most wanted lists for years, I do have a fairly efficient approximation that works well if this is useful - posted at Wikipedia:Most-wanted articles/wantedness.sql in case it it useful. - TB (talk) 21:41, 19 June 2014 (UTC)[reply]

Any changes to the Watchlist?

Since yesterday loading my watchlist makes my Safari 5.1.10 on Mac OS X 10.6.8 run with 100% load on both CPU kernels for about ten seconds, sometimes even longer, freezing the tab... it's the same on all language versions I tried (de, en, fr, es). Expand watchlist to show all changes, not just the most recent is enabled, as are WikEd and Popups. Firefox and Google Chrome behave as normal. I gave it a while, but it seems it doesn't change back for good. Dear developers, did you change anything about the configuration of the watchlist? – Thanks in advance, and good night till tomorrow! :) --Aschmidt (talk) 00:52, 20 June 2014 (UTC)[reply]

You're a little out of date. We're at 10.9, 10.10 if you use the beta OS, at this point.—cyberpower ^Chat_Online 00:56, 20 June 2014 (UTC)[reply]

Thanks, C678, there there are good reasons to remain with system 10.6.8 for the time being as a lot of Apple users do because it was the last version with Rosetta. But I did not ask about that. I asked about the changes that have obviously taken place. Any hint?--Aschmidt (talk) 12:52, 20 June 2014 (UTC)[reply]

And those might be good reasons, but that doesn't make it easier to solve your problem. Lots of stuff changes every week, yesterday some 238 changes went live. To find out where something went wrong, it is needed to reduce the footprint significantly. That means disabling all your gadgets etc and see if you still have the problem, trying with a 'clean' account, trying with a different browser etc. The more outdated your browser, the more work you probably have to put into it yourself to keep it somewhat working, because rare browsers are harder to support. New versions of Google Chrome still run on 10.6. If you can't migrate away from 10.6 you at least might consider migrating to a newer browser that is available for the platform. —TheDJ (talk • contribs) 13:24, 20 June 2014 (UTC)[reply]

Removal Of Edit Counter?

Hi. I added an edit counter at my user page, but as I have been informed that it can be dangerous, I have changed my mind. Does anybody know if and how I can remove it? Thank you for any help. David A (talk) 05:56, 20 June 2014 (UTC)[reply]

If you're talking about the message MediaWiki:Jswarning, that is a standard message displayed whenever someone edits a page with ".js" at the end of its name. You can ignore it in this case, as the current contents of User:David A/EditCounterOptIn.js won't damage anything.

If you really want to opt out of the edit counter, post again here and someone will delete the opt-in page for you. -- John of Reading (talk) 06:04, 20 June 2014 (UTC)[reply]

You can't opt out of the edit counter anymore. Jackmcbarn (talk) 18:48, 20 June 2014 (UTC)[reply]

Issues using Recent Changes

I have been noticing for a while now that I cannot use the Recent Changes page properly on some browsers. Specifically, Google Chrome will almost always fail to load the full page and will prevent me from clicking on a link normally. I have noticed that if I highlight the name of the article, I can then click on a small line above the article to be directed there. I have noticed that Firefox 29.0.1 does load everything fine, though I was wondering if other users are having the same problem or a similar problem.

Summary:

Problem: Links in Recent Changes can only be clicked on a small line above the article after highlighting the name.
Browser: Google Chrome 37.0.2054.3
Operating system: Mac
Page: Special:RecentChanges

--204.106.251.214 (talk) 06:23, 20 June 2014 (UTC)[reply]

Image position change

{{Ribbon devices}} etc. are a set of templates used to superimpose various devices (stars, letters, numbers, etc.) on award ribbons, like this:

At some point in the last few months, the positions of all of the devices dropped about 6 pixels, such that they hang below the ribbon instead of being vertically centered on it, as you can see in the example above. There have been no changes to the templates or image files. I don't think it was coincident with the skin changes that happened recently, though I could be wrong. I admit to not knowing how it renders in skins other than Vector, before or now. That's on the "to-do" list.

Before just adjusting all the positions in the templates, I wanted to run it by some eyeballs here to see if that is the right solution. Comments? —[AlanM1(talk)]— 11:33, 20 June 2014 (UTC)[reply]

After noticing that the problem did not occur when the ribbon was displayed in an Infobox, I explored the styles that were being used. The relevant difference turned out to be that the devices were positioned correctly if I added "line-height: 16.1833px" to the styles of the div that wraps the whole thing. Without this, the line-height value was 27.2px. Where do these values come from? Is this the correct way to handle the problem? Should I be calculating this value from some other variable(s)? —[AlanM1(talk)]— 13:31, 20 June 2014 (UTC)[reply]

The ribbon above looks fine to me, in Firefox 30 and MonoBook skin. It helps if you link to an article where it's not displaying correctly, also please state which browser and skin that you are using. --Redrose64 (talk) 14:23, 20 June 2014 (UTC)[reply]

I see the devices are too low. It probably is rooted to the Typography refresh which changed the body line-height. I gave the template a fixed line-height, so the issue should be resolved. -- [[User:Edokter]] {{talk}} 17:33, 20 June 2014 (UTC)[reply]

I would say that these kinds of templates should really define their own line-height. The change in the typography shows why. —TheDJ (talk • contribs) 12:12, 21 June 2014 (UTC)[reply]

Agreed. But before the typography refesh, everything was 1.5em, so there wasn't realyl a need. -- [[User:Edokter]] {{talk}} 12:18, 21 June 2014 (UTC)[reply]

...and that is what has now been done to fix the problem. —[AlanM1(talk)]— 02:31, 22 June 2014 (UTC)[reply]

ProveIt glitch

I think this is the right place... ProveIt has a glitch as of yesterday where the default state is "expanded" instead of "collapsed". Well, to fix it, you must "expand" it (even though it already is) and then collapse it again. There are users on User_talk:ProveIt_GT#Broken reporting this problem, but no action on it so I thought it best to come to the experts. If this is the wrong place, please let me know where to direct this. Please use {{replyto}} or {{U}} in reply to ping me. Thank you. EvergreenFir (talk) 19:11, 20 June 2014 (UTC)[reply]

Confirming, I'm experiencing the same problem, in Firefox on Windows 7 machines. It started in just the last week or so. —Largo Plazo (talk) 00:46, 22 June 2014 (UTC)[reply]

Extracting biographical data from Wikipedia

I am thinking about a research project that would try to investigate gender inequality worldwide using Wikipedia biographies through time and space. Simply put, I want to create nice graphs (which we could host at Commons and which could improve numerous Wikipedia articles, up to and including the country-specific series of 100+ articles on gender inequality in country x), as well as tables, about the disparity between our biographies of men and female by year by ethnicity/nationality. As we go back in time, there are fewer and fewer female biographies, compared to male, but to my knowledge nobody has quantified how fewer. With our big dataset, we can fll in this gap. I have already designed a working spreadsheet at [23] to illustrate what can be done. To finish this project, however, I need to extract data from Wikipedia, and I simply lack the skills to do that. Do you know where, or whom I could ask to extract such data for me, preferably in the form of the csv file formatted as in the sample spreadsheet linked? I have already asked about this on Wikidata; they don't have this capacity yet and recommend asking here. I was thinking about asking at dBpedia too, but their website is so unfriendly I couldn't even figure out if they have a discussion forum I could use, sigh. (If you reply here, please echo me - thanks). --_{Piotr Konieczny aka Prokonsul Piotrus| reply here} 18:21, 21 June 2014 (UTC)[reply]

It is most definitely possible to extract this information from individual Wikidata entries, and it is most definitely easier than trying to parse the text of articles (it just doesn't provide an interface to do this, you'd have to process database dumps or something). In fact Googling for "wikidata gender" produces a few results of people already doing this kind of research, e.g. [24] (I haven't read the article in its entirely and I'm not sure how relevant it is to what you want to do, but it looks interesting). Matma Rex talk 18:51, 21 June 2014 (UTC)[reply]

It's indeed close to what I want to do, through it focuses more on the analysis of different language Wikipedias, whereas I am interested in the context of articles themselves (year of birth and ethnicity/citizenship of the subject). So, can anyone help me in obtaining the relevant csv file I could start analyzing? PS. Ah, the linked article is User:Maximilianklein brilliant input, I should've known - I'll ping him and ask for ideas, too, and cross-post this at Wikipedia:WikiProject Countering systemic bias. --_{Piotr Konieczny aka Prokonsul Piotrus| reply here} 09:11, 22 June 2014 (UTC)[reply]

Cross site communication with ToolLabs from Wikimedia

Resolved: Magog the Ogre (t • c) 20:40, 21 June 2014 (UTC)[reply]

Is there a way that I can tell the user's browser communicate from with my tool, hosted on https://tools.wmflabs.org, from a Wikimedia project?

JSONP will not suffice because it works through GET, which limits the amount of data I can post in the request (interesting fact: wmflabs returns a 414 error for requests with more than ~8192 bytes) . Magog the Ogre (t • c) 18:44, 21 June 2014 (UTC)[reply]

Yes, you need to make your tool output some magic HTTP headers to enable cross-origin resource sharing (CORS). This will let you use regular AJAX requests to communicate with the tool. (This won't work on very old browsers, though.) Matma Rex talk 19:34, 21 June 2014 (UTC)[reply]

http://enable-cors.org/ is a useful site on how to do that. Legoktm (talk) 20:11, 21 June 2014 (UTC)[reply]

Yep, that was it; thanks. Magog the Ogre (t • c) 20:40, 21 June 2014 (UTC)[reply]

Sysops stats

Is there a tools wmlabs replacement for Sysops stats? --84.245.230.150 (talk) 08:54, 22 June 2014 (UTC)[reply]

I'm pretty sure that equivalent tools on labs already exist, but I don't know what they're called. I do know that some pages which show adminstats info are generated from data on Labs, so you could ask JamesR (talk · contribs) - operator of AdminStatsBot (talk · contribs) which updates WP:ADMINSTATS, or Cyberpower678 (talk · contribs) - operator of Cyberbot I (talk · contribs) which updates subpages of Template:Adminstats. --Redrose64 (talk) 09:21, 22 June 2014 (UTC)[reply]

I'm not too sure if that user has migrated their scripts to Tool Labs yet. I will sought the license and set up a clone if I am able to obtain the script. I'll get back to you. — JamesR (talk) 10:25, 22 June 2014 (UTC)[reply]

As a quick fix, I've added some AdminStats to XTools. Currently fixed to a period of the past 365 days, but I hope it serves the purpose. --Hedonil (talk) 05:01, 23 June 2014 (UTC)[reply]

@Hedonil: thanks, yes, it is what I wanted to see, but of cource it would be nice, if the all-time stats would be enabled. --84.245.230.150 (talk) 09:06, 24 June 2014 (UTC)[reply]

Javascript warning boxes

Resolved

At MediaWiki:Geonotice.js, there are two boxes above this message. What generates those boxes? The first of the two, that is, the one that begins "Please also see WP:Geonotice" contains some malformed HTML. I've added some newlines for clarity:

<table class="plainlinks fmbox fmbox-editnotice" role="presentation">
<tr>
<td class="mbox-image">
<a href="/wiki/File:Achtung.svg" class="image">
<img alt="Achtung.svg" src="/upwiki/wikipedia/commons/thumb/d/dd/Achtung.svg/80px-Achtung.svg.png" width="80" height="70" srcset="/upwiki/wikipedia/commons/thumb/d/dd/Achtung.svg/120px-Achtung.svg.png 1.5x, /upwiki/wikipedia/commons/thumb/d/dd/Achtung.svg/160px-Achtung.svg.png 2x" data-file-width="628" data-file-height="550" />
</a>
</td>
<td class="mbox-text" style="background-color: #fee;;">
<dl>
<dt style="text-decoration: underline;">Please also see 
<a href="/wiki/Wikipedia:Geonotice" title="Wikipedia:Geonotice">WP:Geonotice</a>
</dt>
</dl>
<p>Please note: some wiki markup will not work within the notices. Instead, you may use HTML formatting.
</p>
<b><div style="font-size: 150%;">This is a JavaScript page! If you don't know how to properly escape strings in that language, don't edit it!<br>Instead, request an edit on the talk page.</div>
</td>
</tr>
</table></b>

- specifically, the last </b> doesn't match with the preceding <b> - it's after the </td></tr></table> instead of before. Additionally, I think that both should be inside the <div>...</div> that they are trying to enclose. --Redrose64 (talk) 15:42, 22 June 2014 (UTC)[reply]

Redrose64: It seems to be from Template:Editnotices/Page/MediaWiki:Geonotice.js, or at least the exact same text is there, and the box has class="plainlinks fmbox fmbox-editnotice". If so, the <b> issue is due to an unclosed ''' in the template:Jay8g [V•T•E] 16:35, 22 June 2014 (UTC)[reply]

Yes it is,

Thank you Fixed, like this. --Redrose64 (talk) 16:47, 22 June 2014 (UTC)[reply]

No way to reverse the "desktop view" operation on mobile devices and it affects inter-language experience

As we know that on a device with mobile UA, links like https://en.wikipedia.org/wiki/Felipe_VI_of_Spain will automatically jump to https://en.m.wikipedia.org/wiki/Felipe_VI_of_Spain

The problem is, if you once wanted to check the desktop version of a certain article and clicked "desktop view" on the bottom, this "auto jump" feature will be disabled. Unless you clear your cookie or something, I haven't find a way to reverse it.

This is most annoying when using "Read in another language". Because unlike other links on mobile version (which are all hard link of .m.'s), the links in "read in another language" are merely normal links like https://zh.wikipedia.org/wiki/費利佩六世 . If you ever clicked a desktop view once, every time you want to change your language version you will be brought to desktop version, and you have to change back to mobile view manually.

I have already reported this bug actually, bugzilla:65047. But later I thought it's a android-chrome only bug and closed it. Now I found it happens on every browsers (at least in Android).

A quick "trick" fix for this particular problem is just using .m. links for interlanguage links as interlinks. I don't know why it's now using normal links, not like others.

In my opinion, if users click "mobile view" again on a desktop version article, this "auto jump" feature should come back automatically.

--fireattack (talk) 23:28, 22 June 2014 (UTC)[reply]

Sounds like you should reopen the bug report and explain why you reopen it? :) --AKlapper (WMF) (talk) 12:47, 23 June 2014 (UTC)[reply]

advanced search?

I want to find all the articles I contributed to, in Wikipedia: namespace, which contained the word "review" in their title. Is there any sort of advanced search page which lets me do that? -- RoySmith (talk) 23:32, 22 June 2014 (UTC)[reply]

I found something at Wikipedia:Tools#User edit counts and analysis that almost does this - results. That's a list of edits, not of pages, so there are some duplicates, but it's close. -- John of Reading (talk) 07:01, 23 June 2014 (UTC)[reply]

@RoySmith: Try searching for Wikipedia:intitle:review. — This, that and the other (talk) 12:12, 23 June 2014 (UTC)[reply]

I keep getting an error when going to edit a page

Our servers are currently experiencing a technical problem. This is probably temporary and should be fixed soon. Please try again in a few minutes.
If you report this error to the Wikimedia System Administrators, please include the details below.
Request: GET http://en.wikipedia.org/enwiki/w/index.php?title=Category:Water_in_Texas&action=edit, from 10.128.0.110 via cp4010 frontend ([10.128.0.110]:80), Varnish XID 83774727
Forwarded for: 67.160.184.158, 10.128.0.110
Error: 503, Service Unavailable at Sun, 22 Jun 2014 23:51:08 GMT

But there is no direction on where it should be reported to. Does anyone know where to report this type of thing? Lestatdelc (talk) 23:53, 22 June 2014 (UTC)[reply]

@Lestatdelc: This sort of thing happens every so often, last reported at Wikipedia:Village pump (technical)/Archive 127#Unstyled and non-loading pages and see WP:WFEM. If you get this error when starting to edit a page, then generally, all you need do is try again a minute or so later; if that fails three times (three minutes), wait a longer period (ten minutes); if you still can't edit after 30 mins or so, file a bugzilla ticket. When doing that, be sure to tell them when the problem started; if it affects all pages, all pages in a given namespace (specify which ones), or just a few pages (specify which ones). --Redrose64 (talk) 09:18, 23 June 2014 (UTC)[reply]

Thanks. It was doing it for over an hour before I posted here about it, but seems to work today. That said, there still doesn't seem to be clear where you are supposed to actually report it. Where is the contact info for Wikimedia System Administrators (if future issues arise that don't get fixed within 30 mins.? Lestatdelc (talk) 01:16, 24 June 2014 (UTC)[reply]

As I say, bugzilla:. --Redrose64 (talk) 08:50, 24 June 2014 (UTC)[reply]

Mobile Browsing Issues

This page [25] doesn't work at all well on a mobile device, you can't follow the alphabetical links (on an iPhone 5). Is there something I can change in the markup or is this just something we will have to put up with for now? GimliDotNet^{(Speak to me,Stuff I've done)} 06:21, 23 June 2014 (UTC)[reply]

@GimliDotNet: This page was totally broken, and the mobile app is a bit more sensitive to broken pages than the plain website. I corrected the article. —TheDJ (talk • contribs) 13:47, 23 June 2014 (UTC)[reply]

Works great now, can fix any more I come across. Thank you GimliDotNet^{(Speak to me,Stuff I've done)} 13:50, 23 June 2014 (UTC)[reply]

Tech News: 2014-26

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

Recent software changes

The latest version of MediaWiki (1.24wmf10) was added to test wikis and MediaWiki.org on June 19. It will be added to non-Wikipedia wikis on June 24, and to all Wikipedias on June 26 (calendar).

VisualEditor news

You can now drag-and-drop selections of content, not just files and templates. [26] [27]
When dragging an item, you will now see a line that helps you to drop it. [28] [29]
You can now only move an image to the start of a paragraph, not to the middle of it, so you don't accidentally split it. [30] [31]
You will now be warned if you add wikitext to file captions and references. [32] [33]

Future software changes

You will no longer be able to upload files on wikis that do not have any copyright tags. [34] [35]
CirrusSearch will be enabled as the primary search method on additional 70 new wikis, including Meta-Wiki and Wikimedia Incubator, during the next week. [36]
CirrusSearch results will soon take into account categories, the first paragraph and the wikitext of a page. You will also be able to use regular expressions to search the wikitext. It will take a few days for the changes to be enabled on all wikis. [37]
You will soon be able to watch translations for e-mail notifications without receiving an e-mail when they are reviewed by another translator. [38] [39]
An IRC meeting to organize old high priority MediaWiki bug reports will take place on June 24 at 17:00 UTC on the channel #wikimedia-office on freenode (time conversion). [40]

Problems

On June 19, all wikis were broken for about 15 minutes due to a high server load.
Between June 13 and June 15 there were problems with the scaling of video files due to a configuration error. [41]

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

07:20, 23 June 2014 (UTC)

Missing piece of wiki table syntax/markup?

In tables, wiki syntax/markup offers...

| ... || ... || ... || (etc)

...as an alternative to...

| ...
| ...
| ...
| (etc)

...but, so far as I'm aware, it doesn't offer something like...

| ... || ... || ... -|
| ... || ... || ... -|
| ... || ... || ... -|
| (etc)

...as an alternative to...

| ... || ... || ...
|-
| ... || ... || ...
|-
| ... || ... || ...
|-
| (etc)

What can work (at least, at present) is...

| ... || ... || ... </tr>
| ... || ... || ... </tr>
| ... || ... || ... </tr>
| (etc)

...i.e. using the HTML "end table row" tag </tr>. I understand, however, that this is improper as it mixes wiki and HTML markup. So, may there be a wiki-style alternative, please? Sardanaphalus (talk) 17:13, 23 June 2014 (UTC)[reply]

The markup |- doesn't mean "end row", it means "begin row", that is, it's equivalent to <tr> not </tr> --Redrose64 (talk) 18:25, 23 June 2014 (UTC)[reply]

Yes. How about a piece of wiki markup that can be added to the end of a row to mark the end of that row? Sardanaphalus (talk) 00:07, 24 June 2014 (UTC)[reply]

It's not necessary to mark the end of a row if the start of the next row is indicated, or the end of the table has been reached. This is because, for any given table row, the <tr> tag (for which the wiki markup is |- at the start of a new line) is mandatory, but the </tr> tag (for which there is no wiki markup) is optional (it's always been optional in HTML, but not in XHTML, which has no optional tags). --Redrose64 (talk) 08:40, 24 June 2014 (UTC)[reply]

It's not a good idea to introduced hacks like detailed in that post and the above posting. It adds very specific behavior that can very easily break because it depends on a slew of side effects of the parser. Long term we are getting rid of many of these side effects, so you are just creating tables that are very likely to break at some point in the future. Use either HTML syntax or wikicode, but don't mess with combinations of the two or using templates to generate something that can also (although a bit more verbose perhaps) be done without a template. It's just a bad idea. We all know that wikicode is ugly, it's ugly in a thousand different ways, but it's what we've got and what we have to live with. —TheDJ (talk • contribs) 19:10, 23 June 2014 (UTC)[reply]

This use of </tr> has been around long before my becoming aware of it – in fact, it's near-certain I came across it here. Mixing markup may be a bad idea, but, in the long-term, isn't the idea that something is "what we've got and what we have to live with" a worse one...? Sardanaphalus (talk) 00:07, 24 June 2014 (UTC)[reply]

Using </tr> without the next tag being either <tr> or </table> relies on browser quirks: assuming that we're not dealing with XHTML (see my post of 08:40, 24 June 2014 (UTC) above), most browsers, on encountering the sequence <table><th>, for which the wiki markup is

{|
!

or <table><td>, for which the wiki markup is

{|
|

will assume that there should be a <tr> (i.e. a |-) in between. Similarly, if they encounter the sequence </tr><th> or </tr><td>, they will also assume that there should be a <tr> in between. Since the <tr> tag at the start of a table row is documented as being mandatory, not all browsers will assume that it should be present if it has been omitted, and so you mustn't rely on such behaviour. --Redrose64 (talk) 08:40, 24 June 2014 (UTC)[reply]

yes, relying on the HTML Tidy module as a hack is a very bad idea, especially since the core HTML Tidy it hasn't been updated since 1998. Frietjes (talk) 21:57, 23 June 2014 (UTC)[reply]

Since 2008 actually. -- [[User:Edokter]] {{talk}} 23:00, 23 June 2014 (UTC)[reply]

Technical input requested

Possibly interesting discussion over at Wikipedia:Village_pump_(proposals)#Signing_posts which could benefit from input from the frequenters of this pump. Peridon (talk) 17:45, 23 June 2014 (UTC)[reply]

It is a technical matter, but after some of the comments there, I am no longer taking part in that discussion. --Redrose64 (talk) 18:27, 23 June 2014 (UTC)[reply]

Yeah we have seen this discussion before. Good luck. —TheDJ (talk • contribs) 18:56, 23 June 2014 (UTC)[reply]

Closed AFDs not displaying on mobile version

AFDs that have been closed using class="boilerplate metadata vfd" in the div are not displaying on the mobile version. Example Wikipedia:Articles_for_deletion/Tube_Bar_prank_calls. The class used in {{Afd top}} is "boilerplate afd vfd xfd-closed" and these display ok. Anybody got any idea what it is about the former class that causes it not to display? Spinning Spark 02:13, 24 June 2014 (UTC)[reply]

probably it's the metadata class. That's stuff that should be hidden in the content namespace, but perhaps mobile has an overly 'active' implementation of it. There are 2 solutions, remove that class, or fix mobile :) —TheDJ (talk • contribs) 05:30, 24 June 2014 (UTC)[reply]

It's the metadata class, and a related matter has come up before, see Wikipedia:Village pump (technical)/Archive 116#CfDs in mobile view - there is much related detail at Wikipedia:Village pump (technical)/Archive 116#'Listen' template not rendering in mobile view. There were one or two related threads, see for example Wikipedia:Village pump (technical)/Archive 119#Wikipedia mobile page have a bug for sister project links. --Redrose64 (talk) 09:25, 24 June 2014 (UTC)[reply]

So is this something that should be raised on bugzilla? I could ask for a bot to change all the templates in the archive, but this does not seem like the right approach. We can never be sure we have found all the entities generating that class. Spinning Spark 15:43, 24 June 2014 (UTC)[reply]

Bugzilla is only for things that we can't fix ourselves. We have two possible approaches here: either remove the metadata class from {{afd top}} or modify the relevant rule in whichever CSS file is setting a rule like

.metadata { display: none; }

I think that altering none to block whilst being the "obvious" thing to do would unhide things that should remain hidden. If we choose the first approach - which has, in fact, already been done - we need to do something about those AfDs closed prior to that modification, perhaps send in a bot to remove the metadata class. --Redrose64 (talk) 16:06, 24 June 2014 (UTC)[reply]

Yeah, I thought that would be the answer on Bugzilla, just checking. Are you sure that my example was created with {{afd top}}? It does not have the template name in hidden text as more recent ones do. If we are sure that there is nothing currently creating this class, then yes, a bot would be the solution. Spinning Spark 17:00, 24 June 2014 (UTC)[reply]

Autofill fills in email address instead of username on the login form

I thought it was a browser glitch until I realized the same issue on a different browser on a different platform. It used to fill in my username and password for me, but now it fills in my email address and password. It's mildly annoying, and was wondering if the login form changed.—cyberpower ^Chat_Online 03:55, 24 June 2014 (UTC)[reply]

html tags in PC error popup

Tracked in Phabricator
Task T69023

I discovered a minor error in an error popup message in the Pending Changes system. Tonight while trying to edit via a mobile connection on my smart phone, I ran afoul of a range block (my workaround is to connect to my ambulance's WiFi, and thus change IP addresses, but that drops me from a 4G to a 3G connection). When I tried to accept revisions, I got the error message popup in the screenshot here. I noticed there's some visible HTML tags in the message. Thought someone might like to clean that up, though I doubt my situation tonight will come up very often. Thanks! —Elipongo (Talk contribs) 07:06, 24 June 2014 (UTC)[reply]

Filed in bugzilla. —TheDJ (talk • contribs) 09:03, 24 June 2014 (UTC)[reply]

@Elipongo: The FAQ box has gone missing from this page (see Template talk:Village pump page header#Missing FAQ at VPT)... but according to Wikipedia:Village pump (technical)/FAQ, your problem might be the StumbleUpon browser extension. --Redrose64 (talk) 09:48, 24 June 2014 (UTC)[reply]

@Redrose64: I'm glad if I'm the catalyst that helped get the FAQ restored, but I do not have StumbleUpon installed on my phone. I use my Droid 4's native browser which I don't even think CAN have extensions installed; I see from the article that StumbleUpon comes as a separate app from the play store. Thanks! —Elipongo (Talk contribs) 15:13, 24 June 2014 (UTC)[reply]

Automating the creation of Wikidata articles

When I create a new article (or see one created by someone else) I like to immediately create a corresponding Wikidata entry. I'm clearly not alone in this.

The process is tiresome, and we need a tool which, when initiated, creates the Wikidata article, with a "click confirm" check, allowing human review and intervention.

The tool could grab data from categories and infoboxes.

I understand this would be a complex process, so it might be best to develop it in manageable chunks: first for people (Infobox person; then Infobox musical artist, then Infobox officeholder...), then buildings (Infobox building, then Infobox church...), then...

Is anyone interested in working on this? I'm not a coder, but am happy to work on specifications and testing. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:06, 24 June 2014 (UTC)[reply]