Wikipedia:Village pump (technical)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

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

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.

« 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

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)

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)

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!, —  dainomite   20:11, 6 June 2014 (UTC)

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)

• 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)

@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)

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)

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)

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)

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)

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)

@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)

@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)

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)

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)

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)

The text is in fact the same color as the search box's. Both text fields use the "placeholder" attribute to have default text that is replaced as soon as the user starts to fill in the field. On most (but not all) browsers this is some shade of gray. The borders of the flow boxes are rather lighter than those of the search box, though. --Yair rand (talk) 22:17, 25 June 2014 (UTC)

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)

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)

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

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

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

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

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

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)

@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)

@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)

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

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)

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)

@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)

If memory serves, User:Steven (WMF) is the contact for Thanks. He'll probably need to know things like what web browser and computer system you're using, Mjroots. Also, do you have JavaScript disabled? Whatamidoing (WMF) (talk) 05:08, 25 June 2014 (UTC)

I'll keep this in one place as it may benefit others.

@Steven (WMF): - I'm using Firefox (not sure what version, but it's the latest one) and Windows XP. JavaScript is enabled as far as I know. Mjroots (talk) 06:04, 25 June 2014 (UTC)

@Mjroots: To find out your Firefox version: in the menu bar at the top, select Help → About Mozilla Firefox. --Redrose64 (talk) 21:46, 25 June 2014 (UTC)

I've got Firefox 30.0 installed. Mjroots (talk) 04:30, 26 June 2014 (UTC)

Seems to be working again now. Mjroots (talk) 15:15, 27 June 2014 (UTC)

• I'm not at all impressed by the decision to do away with Special:Thanks. This decision forces those people that want to occasionally thank people for an edit here or there to have to put up with the horrible in-line thank process (poorly placed link, required confirmation for a simple process because of the poorly placed link, additional page history clutter). I vaguely remember that it may be possible to thank a user via the API, and I suppose I should finish my NoThanks script to be able to make use of this and better customize the thanking process. It won't be this week or next though as I'm cramming to complete the equivalent of four biology finals in the next week or so, but I'll get to it... — {{U|Technical 13}} ^{(e • t • c)} 15:24, 27 June 2014 (UTC)

I like the confirmation required bit, saved me from thanking the wrong person once. Dougweller (talk) 15:39, 27 June 2014 (UTC)

• When I'm done with NoThanks, it will have an option to undo the thank instead of having to confirm which will reduce the "normal operation" of thanking someone to one click... — {{U|Technical 13}} ^{(e • t • c)} 15:52, 27 June 2014 (UTC)

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. SpinningSpark 16:10, 15 June 2014 (UTC)

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

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)

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. SpinningSpark 17:26, 15 June 2014 (UTC)

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)

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. SpinningSpark 19:56, 15 June 2014 (UTC)

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)

Humour me for a moment. What are the difficulties? SpinningSpark 20:29, 15 June 2014 (UTC)

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)

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)

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)

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)

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)

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)

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)

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

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

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)

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)

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)

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)

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

Sysops stats

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

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)

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)

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)

@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)

See also no:Spesial:Prefiksindeks/MediaWiki:Gadget-show-sysop-activity. Helder.wiki 13:31, 23 June 2014 (UTC)

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/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)

@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)

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)

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

Missing piece of wiki table syntax/markup?

Prompted by this.

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)

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)

• 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)

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)

• I'm considering this from user-to-syntax, so to speak, rather than vice versa. Because it can be useful visually, I – user – ("I, User"!) would like to be able to mark the end of a row (and so, if one follows, the beginning of the next row on the next line) on the same line as the code for that row, just as the syntax already allows for each cell in a row. So how about a piece of markup – syntax – that facilitates this (whether "-|" or something else)...? Sardanaphalus (talk) 21:11, 24 June 2014 (UTC)

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)

• 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)

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)

• That's what's motivating my request/proposal, especially as there's already provision for more than one cell per line of code. Sardanaphalus (talk) 21:11, 24 June 2014 (UTC)
• I'll note that in the above instances, the parser will add the 'missing' <tr> automatically. So this is valid wiki markup resulting in valid HTML. -- [[User:Edokter]] {{talk}} 11:11, 27 June 2014 (UTC)

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)

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

correct, thank you, the 1998 was a typo (still very old). Frietjes (talk) 23:56, 24 June 2014 (UTC)

Moved from User talk:Redrose64 § Wiki-style table markup

Any further thoughts / advice re Wikipedia:Village pump (technical)#Missing piece of wiki table syntax/markup?...? (Maybe I should enquire at mediawiki.org...?)

I imagine you might have quite a backlog – you seem to dispense advice and information everywhere! Very valuable. Hope you don't find it too exhausting.

Regards, Sardanaphalus (talk) 09:46, 27 June 2014 (UTC)

(end of moved text) Please don't split discussions across multiple pages, it makes them harder to follow.

It's not possible to configure the English Wikipedia to accept MediaWiki-style markup additional to what MediaWiki provides itself. That would need a feature request at bugzilla:. But aside from that, it is bad HTML to use end-of-row markers without corresponding start-of-row markers; it is also bad practice to expect a browser to make assumptions about where missing markup should have been placed, unless the documentation (which for tables may be found at: HTML 3.0; HTML 3.2; HTML 4.01; HTML 5.0; HTML 5.1) explicitly shows it to be optional markup. For a table row, the <tr> tag has always been mandatory; the </tr> tag has always been optional, except in XHTML 1.0 where it is mandatory (because there are no optional tags in XHTML). --Redrose64 (talk) 10:04, 27 June 2014 (UTC)

HTML Tidy is disabled by default in MediaWiki,[22] thus pages using this hack will break when ported to a wiki with the defaults. Tidy is required to mix wiki table and html table markup. --  Gadget850 ^talk 11:01, 27 June 2014 (UTC)

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? SpinningSpark 02:13, 24 June 2014 (UTC)

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)

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)

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. SpinningSpark 15:43, 24 June 2014 (UTC)

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)

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. SpinningSpark 17:00, 24 June 2014 (UTC)

• If you can get me a list of pages, I can run through once with AWB and remove the "metadata" classes. — {{U|Technical 13}} ^{(e • t • c)} 20:01, 24 June 2014 (UTC)
• @Technical 13: The pages that need checking should all be in the following searches:

• Special:prefixIndex/Wikipedia:Templates for deletion
• Special:prefixIndex/Wikipedia:Templates for discussion
• Special:prefixIndex/Wikipedia:Files for deletion
• Special:prefixIndex/Wikipedia:Possibly unfree files
• Special:prefixIndex/Wikipedia:Categories for discussion
• Special:prefixIndex/Wikipedia:Redirects for discussion
• Special:prefixIndex/Wikipedia:Miscellany for deletion

• SpinningSpark 23:27, 24 June 2014 (UTC)

• There's only about 32K pages in the resulting list. I've made 25 test edits using my find/replace with AWB. In order to complete this process, it only makes sense to request the bot flag. I'm on my way to BRFA for that now. — {{U|Technical 13}} ^{(e • t • c)} 00:12, 25 June 2014 (UTC)

Update: My request for T13bot has been Approved for trial (175 edits or 10 days). Please provide a link to the relevant contributions and/or diffs when the trial is complete. by Xaosflux. I'll complete his request for 25 trials in each prefix tomorrow. (bed time for me here). — {{U|Technical 13}} ^{(e • t • c)} 01:34, 25 June 2014 (UTC)

Initial trial run has completed, if anyone has any comments, please bring them to Wikipedia:Bots/Requests for approval/T13bot. Thank you, — xaosflux ^Talk 00:20, 26 June 2014 (UTC)

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)

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)

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

@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)

@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)

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)

What about topics that already have a Wikidata item (for example, because an article exists on another WP)? πr² (t • c) 01:23, 28 June 2014 (UTC)

VisualEditor global newsletter—June 2014

Did you know?

The character formatting menu, or "Style text" menu lets you set bold, italic, and other text styles. "Clear formatting" removes all text styles and removes links to other pages.

Do you think that clear formatting should remove links? Are there changes you would like to see for this menu? Share your opinion at MediaWiki.org.

The user guide has information about how to use VisualEditor.

The VisualEditor team is mostly working to fix bugs, improve performance, reduce technical debt, and other infrastructure needs. You can find on Mediawiki.org weekly updates detailing recent work.

• They have moved the "Keyboard shortcuts" link out of the "Page options" menu, into the "Help" menu. Within dialog boxes, buttons are now more accessible (via the Tab key) from the keyboard.
• You can now see the target of the link when you click on it, without having to open the inspector.
• The team also expanded TemplateData: You can now add a parameter type  "date" for dates and times in the ISO 8601 format, and  "boolean" for values which are true or false. Also, templates that redirect to other templates (like {{citeweb}} → {{cite web}}) now get the TemplateData of their target (bug 50964). You can test TemplateData by editing mw:Template:Sandbox/doc.
• Category: and File: pages now display their contents correctly after saving an edit (bug 65349, bug 64239)
• They have also improved reference editing: You should no longer be able to add empty citations with VisualEditor (bug 64715), as with references. When you edit a reference, you can now empty it and click the "use an existing reference" button to replace it with another reference instead. 
• It is now possible to edit inline images with VisualEditor. Remember that inline images cannot display captions, so existing captions get removed. Many other bugs related to images were also fixed.
• You can now add and edit {{DISPLAYTITLE}} and __DISAMBIG__ in the "Page options" menu, rounding out the full set of page options currently planned.
• The tool to insert special characters is now wider and simpler.

Looking ahead

The VisualEditor team has posted a draft of their goals for the next fiscal year. You can read them and suggest changes on MediaWiki.org.

The team posts details about planned work on VisualEditor's roadmap. You will soon be able to drag-and-drop text as well as images. If you drag an image to a new place, it won't let you place it in the middle of a paragraph. All dialog boxes and windows will be simplified based on user testing and feedback. The VisualEditor team plans to add autofill features for citations. Your ideas about making referencing quick and easy are still wanted. Support for upright image sizes is being developed. The designers are also working on support for viewing and editing hidden HTML comments and adding rows and columns to tables.

Supporting your wiki

Please read VisualEditor/Citation tool for information on configuring the new citation template menu, labeled "⧼visualeditor-toolbar-cite-label⧽". This menu will not appear unless it has been configured on your wiki.

If you speak a language other than English, we need your help with translating the user guide. The guide is out of date or incomplete for many languages, and what's on your wiki may not be the most recent translation. Please contact me if you need help getting started with translation work on MediaWiki.org.

VisualEditor can be made available to most non-Wikipedia projects. If your community would like to test VisualEditor, please contact product manager James Forrester or file an enhancement request in Bugzilla.

Please share your questions, suggestions, or problems by posting a note at mw:VisualEditor/Feedback or by joining the office hours on Saturday, 19 July 2014 at 21:00 UTC (daytime for the Americas and Pacific Islands) or on Thursday, 14 August 2014 at 9:00 UTC (daytime for Europe, Middle East, Asia).

To change your subscription to this newsletter, please see the subscription pages on Meta or the English Wikipedia. Thank you! Whatamidoing (WMF) (talk) 04:59, 25 June 2014 (UTC)

Twinkle

Twinkle isn't working for me on Firefox, I'm logged in, it's checked in preferences and I've done a restart, any ideas? It's OK on Chrome Jimfbleak - talk to me? 06:40, 25 June 2014 (UTC)

Same here on Chrome. I can't fully open "New pages feed", I get only one (the most recent) article in the results and can't use Twinkle. --BiH (talk) 11:15, 25 June 2014 (UTC)

Same here. I am seeing further error messages, and my JS has been a bit hit-or-miss for the past few days. Also using the latest version. --Mdann52talk to me! 15:03, 25 June 2014 (UTC)

Same here.(Chrome35)--Freshman404^Talk 17:44, 25 June 2014 (UTC)

Ditto--☾Loriendrew☽ ☏(talk) 02:58, 26 June 2014 (UTC)

It has happened before. From my end all seems fine. --Fauzan^{✆ talk}_{✉ mail} 13:21, 26 June 2014 (UTC)

Move stopped because of blacklist

I tried to boldly move article 2010 FIFA World Cup qualification (CONCACAF – CONMEBOL play-off), because I believe that the endash should not be spaced. But the move failed:

"2010 FIFA World Cup qualification (CONCACAF – CONMEBOL play-off)" cannot be moved to "2010 FIFA World Cup qualification (CONCACAF–CONMEBOL play-off)", because the title "2010 FIFA World Cup qualification (CONCACAF–CONMEBOL play-off)" is on the title blacklist. If you feel that this move is valid, please consider requesting the move first."

The blacklist explains that user account names must not exceed 40 characters, so I guess there is a similar cause here.

What to do? There are several pages in the same category that should be moved (there shouldn't be spaces, right?): Category:FIFA World Cup qualification inter-confederation play-offs.

HandsomeFella (talk) 13:58, 25 June 2014 (UTC)

It's not about the total length but this:

.*\p{Lu}(\P{L}*\p{Lu}){9}.* <casesensitive | moveonly> # Disallows moves with more than nine consecutive capital letters

Admins can make the moves but considering the number of articles, I think you should seek consensus first and notify at Wikipedia talk:WikiProject Football. PrimeHunter (talk) 14:20, 25 June 2014 (UTC)

Great. I'll do that. Thanks. HandsomeFella (talk) 14:51, 25 June 2014 (UTC)

I need some good devs

This isn't exactly a technical question, but could you all find me an engineer or three? We are looking for frontend focused developers for the editing team. This team's primary focus is on the ongoing development of the VisualEditor and is recently also responsible for the wikitext editor.

If you or someone you know has been hacking around on the VisualEditor or MediaWiki, even if it's just been for fun, then please look at the job description and consider clicking the "apply" button at the bottom of the page. We are looking for engineers at multiple levels of experience with the primary focus being on frontend development; javascript, HTML/CSS, MediaWiki, contenteditable, etc.. The Engineers on the team are interested in what you can and have been doing vis a vis your skills and experience combined with a good team and culture fit. Feel free to send me e-mail if you have questions; alternatively, you can talk to User:Jdforrester (WMF) (the product manager, who is also keen to find a good dev for this team) or Emily Blanchard (Engineering Team Recruiter).

In addition to more general frontend Developers to work on the VisualEditor and MediaWiki projects we are also looking for someone with solid ContentEditable experience. If you are an interested engineer or know someone that might be please share this with them and refer them our way!

If you've never done development work on MediaWiki projects but would like to start, see mw: How to become a MediaWiki hacker. Volunteer devs do a huge amount of work. Some volunteer developers here at WMF were hired because they were awesome volunteers (including User:Catrope, User:Krinkle, and User:Krenair on this team). Whatamidoing (WMF) (talk) 20:47, 25 June 2014 (UTC)

Upload a file through the API

I've looked around for an answer to this question, but I can't find any suitable discussion. The closest I got was talk:Upload this mw discussion page that shows some actual JavaScript code, but it isn't quite what I'm looking for. My question is, is it possible to not just upload a file using the API but to build a file out of text and then upload that text in the form of a file using JavaScript. The reason I ask is because I have a script that extracts data from WP:NRHPPROGRESS (big page.. may take a second to load) and outputs it to a subpage, from which I copy it into an SVG file and upload it. The thing is, though, the rest of the SVG file never changes (it's a map), so I feel like I should be able to simply copy it somewhere here as wikitext, query it, then add in the script generated code and have the entire text of the file on-wiki instead of on my hard drive. I would like to then take that total text and somehow make JS think it's the contents of a file and upload it directly to Commons. The only reason I think this should be possible is because of the SVG format, which is text-based instead of like JPG or PNG or something. Is there anyone out there that can think of a way to do this? I've never used the API to even upload a file, but I use it all the time to query categories, wikitext, edit, etc., so talk to me like I'm 5 if it's something upload-specific haha. Thanks!--Dudemanfellabra (talk) 14:17, 26 June 2014 (UTC)

Have a look at the code of the SVGEdit extension. (+ FormMulitpart), it just does what you want: Upload an SVG created by script. And of course it is possible to upload other formats as well, though a bit more complicated. (You would have to use the native FormData object, and get the binary data from somewhere, e.g. a canvas element.) --132.230.1.28 (talk) 09:54, 27 June 2014 (UTC)

Thank you for that response. I haven't tried anything yet, but from what I can gather from the code, it seems as if I can copy the code from both of these sources into a JS page on-wiki, call saveSVG("FILENAME", {...., data:SVGTEXT, ...}, "EDITSUMMARY", CALLBACKFUNCTION) where the ellipses would have all the other file data like encoding, etc., and it should work? Do I need to format SVGTEXT in any certain way, or can it just be regular text?--Dudemanfellabra (talk) 13:03, 27 June 2014 (UTC)

Classic Wikipedia article traffic stats not working. What!?

The classic Wikipedia article traffic statistics does not show older data for any article before December 2010. A Great Catholic Person (talk) 19:20, 27 June 2014 (UTC)

Try "View history" | "external tools: Revision history statistics" | scroll down to the traffic history |scroll down to other items like user edits

--Ancheta Wis   (talk | contribs) 22:21, 27 June 2014 (UTC)

This message was a replacement for an older one (see this diff) and that's why it's out of chronological order. Graham87 08:14, 28 June 2014 (UTC)

Requested new citation template feature: Hover the mouse over a footnote marker and the supported text is highlighted

Tracked in Phabricator
Task T20231

Sorry for the long title. That's what I'm looking for. Often I'll use three different sources to support three different facts in a sentence. The reader, just looking at the three footnote markers^[1][2][3] won't know which ref's support which assertions. Would someone please make a citation system - template, VE, I don't care - that highlights the supported text when you hover over the footnote marker?

So, in this example:

At any given time, about half of all patients with malignant cancer are experiencing pain, and more than a third of those (and two thirds of all patients with advanced cancer) experience pain of such intensity that it adversely affects their sleep, mood, social relations and activities of daily living.^[1][2][3]

hovering the mouse over ^[1] produces:

At any given time, about half of all patients with malignant cancer are experiencing pain, and more than a third of those (and two thirds of all patients with advanced cancer) experience pain of such intensity that it adversely affects their sleep, mood, social relations and activities of daily living.^[1][2][3]

hovering the mouse over: ^[2] produces

At any given time, about half of all patients with malignant cancer are experiencing pain and more than a third of those (and two thirds of all patients with advanced cancer) experience pain of such intensity that it adversely affects their sleep, mood, social relations and activities of daily living.^[1][2][3]

hovering the mouse over ^[3] produces:

At any given time, about half of all patients with malignant cancer are experiencing pain, and more than a third of those (and two thirds of all patients with advanced cancer) experience pain of such intensity that it adversely affects their sleep, mood, social relations and activities of daily living.^[1][2][3]

I'll pay US$1000 to the first person or team who, in the next 6 months, presents a useable citation template, visual editor fix, or anything else that incorporates this option in article citations. --Anthonyhcole (talk · contribs · email) 12:07, 27 June 2014 (UTC)

I built this (one of several systems) for such markup back around 2000. It's a nightmare. The extra markup you have to place into the body text to indicate just what and where is being sourced quickly becomes onerous. It's especially bad when there are multiple citations and they overlap, but not in a nested fashion. No-one bothers with it these days. Take a look at TEI for what's probably the lead in this sort of system.

Better approaches seem to take it the other way. Annotate the citations to indicate the scope to which they apply. This can use techniques like XPointer or even the old Purple Numbers. Most of these systems for practical use then need auto-coalescence of the cited regions, such that citation markers only appear once per joined block, not repeated for every region.

The systems that mostly work for such needs are legalistic and work by formalising the structure of the text. Everything breaks down to statements or clauses, none of which can be compounds. It's easy (and usually verbose) to number each of these. The addressing becomes a simple matter of listing numbered paragraphs. It works, it's specific and it's also horribly unreadable. Not what we want at all. Andy Dingley (talk) 12:21, 27 June 2014 (UTC)

Well, that doesn't sound very useful! :o) (I didn't understand most of what you said.) I'm not too bothered - at least in this prototype stage - how much effort it takes on the editor's part, but if it's really very onerous others will object to me putting it on articles. And it would need to appear to the reader like any other en.WP citation, except for the extra feature. If it can't effectively be done, no worries.

I was thinking the editor could just copy and paste the relevant article text against a template parameter

|supports="Blah blah blah" "Alpha beta gamma"

and any text on the page exactly matching the text within quotation marks would be automatically highlighted. From this user-point-of-view that would be the simplest, but if that's not doable, then the simple feature I'm looking for is probably unattainable. --Anthonyhcole (talk · contribs · email) 12:40, 27 June 2014 (UTC)

@Anthonyhcole: What you described is doable, of course, but I'm not sure if it would be practical:

• I can't think of a way to do this without forcing the user to adjust technicalities about such tags when new content is added (in your example, the texts would have to be updated in both places; some numbering approach like what Andy described would require updating the numbers). This could be avoided by implementing this in VisualEditor, but then VisualEditor is hated around here for some inexplicable reason and doing that would surely get someone hanged.
• Allowing one <ref> tag to provide a citation for several text fragments instead of just one also feels problematic (if you think you need this, it means you actually want to use <ref name>!). This actually would be more problematic from the interface standpoint in a visual tool than in wikitext.

That said, a more limited version of such a tool (where a single ref would only provide citation for a single and adjacent and immediately preceding wikitext fragment) looks feasible to me, and hopefully it wouldn't be too awkward to use neither in wikitext nor in VisualEditor; but I think one should first think really hard about both the wikitext formats and possible visual interface for such a thing. Matma Rex talk 18:36, 27 June 2014 (UTC)

To clarify, here's a variant of your original examples that I believe to be feasible. I don't think any meaning is lost.

At any given time, about half of all patients with malignant cancer are experiencing pain^[1], and more than a third of those (and two thirds of all patients with advanced cancer^[3]) experience pain of such intensity that it adversely affects their sleep, mood, social relations and activities of daily living.^[2]

At any given time, about half of all patients with malignant cancer are experiencing pain^[1] and more than a third of those (and two thirds of all patients with advanced cancer^[3]) experience pain of such intensity that it adversely affects their sleep, mood, social relations and activities of daily living.^[2]

At any given time, about half of all patients with malignant cancer are experiencing pain^[1], and more than a third of those (and two thirds of all patients with advanced cancer^[3]) experience pain of such intensity that it adversely affects their sleep, mood, social relations and activities of daily living.^[2]

Matma Rex talk 18:43, 27 June 2014 (UTC)

I'll love the VE when it's finished. :o) The bug linked by WhatamIdoing below seems to aim at the solution you're targetting, Matma Rex. I might just add my support to that, with a proposal for the hover feature. Thanks for your input. --Anthonyhcole (talk · contribs · email) 02:34, 28 June 2014 (UTC)

This isn't entirely a new idea; Template:Bug was filed in 2009. Some of the comments there might be relevant. If you don't have or want a (free, but e-mail-address-exposing) Bugzilla account, then just leave a note on my talk page, and I can post any comments there that you'd like to add to the enhancement request. Whatamidoing (WMF) (talk) 22:39, 27 June 2014 (UTC)

Whatamidoing, I created a Bugzilla account last night, but I'm not sure what to say there. Can I just add a support for the feature and add a request that the "hover-over-the-footnote-marker" feature be included? That place looks like my "pending" basket, where I poke stuff I'm never going to get done. But if you think it's not utterly futile, I'll throw it in. --Anthonyhcole (talk · contribs · email) 02:34, 28 June 2014 (UTC)

I think it's not utterly futile, and I'd encourage you to post it. Bugzilla etiquette is generally that comments which say only "me too" are discouraged, but that any comment suggesting another way to do it (your hover-over idea, for example) or any related problem or implementation challenge is very welcome. Whatamidoing (WMF) (talk) 03:58, 28 June 2014 (UTC)

Thanks. Will do. --Anthonyhcole (talk · contribs · email) 04:59, 28 June 2014 (UTC)

I have implemented the functionality which is described above. I wanted a solution that would work for any reference regardless of which citation template was used, or even if a citation template is used at all. I created a new template, {{Ref supports}} – an alias {{Cite supports}} is available – which is used to describe the text supported by the reference. The {{Ref supports}} template is placed inside the <ref>...</ref> tags along with whatever the reference is (e.g. {{cite web}}, a non-template based reference, etc.). Currently, you can specify up to 10 text segments, but that could easily be expanded. The text segments are encoded into a span, similar to how COinS works. That information is then read by the user script described in the next paragraph. The {{Ref supports}} template itself displays nothing visible on the screen unless |show= is set to something non-blank. If |show= is set then whatever it is set to is output prior to a list of the quoted text segments. In general, the text segments are expected to be from the rendered page (i.e. without wiki-markup). However, there is minimal handling for [[some]] [[types|of links]] and not fully tested handling of a bit more wiki-text being within the {{Ref supports}} template. Currently, the text segments must be in the same paragraph and prior to the reference. I'm open to expanding that, but did not want to start out with doing a full search on the page due to unknown performance/possible miss-matches. Text segments will match only the single closest sequential set of words/punctuation. However, the formatting of the text is ignored (e.g. italics, bold, links).

You will also need to import the user script User:Makyen/RefSupports.js by adding importScript('User:Makyen/RefSupports.js'); to either your common.js, or the .js file for your skin. So far, I have only tested this using the Vector skin in Firefox and Chrome.

I still plan to put work into the package for cleaning up, optimizing, documentation improvement and further testing and improvements. Notably it does not intelligently deal with overlapping spans. If you have multiple references supporting similar, but not exactly the same text you will probably need to break the text segments described in the {{Ref supports}} templates such that the segments end at similar locations.

I used two test pages at which you can try it out: test01 and test02. On test01 I have only added {{Ref supports}} to the first three paragraphs. In addition, the following paragraph is a copy of test02 and should be fully functional. It is a functional version of the example paragraph above written by Anthonyhcole:

At any given time, about half of all patients with malignant cancer are experiencing pain, and more than a third of those (and two thirds of all patients with advanced cancer) experience pain of such intensity that it adversely affects their sleep, mood, social relations and activities of daily living.

— Makyen (talk) 17:26, 28 June 2014 (UTC)

Makyen, when you say "You will also need to import the user script User:Makyen/RefSupports.js by adding importScript('User:Makyen/RefSupports.js'); to either your common.js, or the .js file for your skin" do you mean the reader must add that code to their common or skin js in order for it to work? If so, can you tell me how to do that? (I use Monobook.) --Anthonyhcole (talk · contribs · email) 00:54, 29 June 2014 (UTC)

Anthonyhcole, yes. The person reading the page will need to have added the import of the user script User:Makyen/RefSupports.js to either their common.js page, or the .js page for the skin that they use. I just briefly tested it in all of MonoBook, Modern and Cologne Blue and it was working fine. Thus, your common.js page is probably the most appropriate.

The easiest instructions are to:

1. Copy the following:

   {{subst:iusc|User:Makyen/RefSupports.js}}

2. Then Click on this link to edit your your common.js page.
3. Paste the text you just copied onto the page that opens, which is your common.js.
4. Save the page and bypass your cache to make sure the changes take effect.

— Makyen (talk) 01:47, 29 June 2014 (UTC)

Ah. Sorry, I'm looking for this, but for all readers of the article, not just those with an account who've added js. Is there any way to tweak your solution so that the highlighting appears for all readers whose mouse hovers over a footnote marker? --Anthonyhcole (talk · contribs · email) 09:50, 29 June 2014 (UTC)

Regarding payment: Do you mind if I hold an RfC at the end of this process, to decide who deserves to be paid for this feature, and how the money should be distributed if there's more than one inventor? --Anthonyhcole (talk · contribs · email) 10:51, 29 June 2014 (UTC)

Technicals images shouldn't show in MediaViewer

Please see Template:Bug first. Purely informative images, like portal icons, should not appear in MediaViewer. So we have to add a metadata html class to templates like:

• {{Portal}}
• {{Portal bar}}
• {{Librivox author}}

--Rezonansowy (talk | contribs) 08:24, 27 June 2014 (UTC)

Be aware that the metadata class, when applied to a box-type object, hides the whole box from Mobile view (see e.g. #Closed AFDs not displaying on mobile version above). --Redrose64 (talk) 08:52, 27 June 2014 (UTC)

.metadata is for things that are not part of content. I think that traditionally, portal stuff etc generally is considered part of the content (they are classified as 'see also' content), though there is something to be said to classify it as metadata.... The metadata class is not to be randomly applied to hide images from MMV and I will revert such things on sight. This is MMVs problem, not ours. —TheDJ (talk • contribs) 09:00, 27 June 2014 (UTC)

See our discussion on Bugzilla. There's a noviewer class for this. The problem is that templates like {{Sister project links}} are still using the metadata class. Otherwise, we should link every portal icon to the corresponding portal. --Rezonansowy (talk | contribs) 06:12, 29 June 2014 (UTC)

Something changed font rendering in Chrome

I noticed last week on mediawiki.org, and now here, that Chrome is somehow forced to use its own method of font smooting, but I cannot determine what causes it. Ohter browser as well as other websites in Chrome are unaffected. Normally, I have ClearType enabled (on XP), and now I see that Chrome uses some, probably built-in "pseudo", ClearType-like method, which is not native to XP. It's not necessarily bad, just a slight degrade, but I really like to know what causes it. Has some webkit-specific CSS been introduced in the latest update? -- [[User:Edokter]] {{talk}} 08:35, 27 June 2014 (UTC)

Nothing that I know of. Could it be related to a Chrome update? Kaldari (talk) 00:40, 28 June 2014 (UTC)

Finding things in my user space.

Some while ago I made some useful notes in a subsection of my user space which I now cannot find. Is there any way to get a directory of your own user space? Martin Hogbin (talk) 09:08, 27 June 2014 (UTC)

Special:PrefixIndex/User:Martin Hogbin —TheDJ (talk • contribs) 09:22, 27 June 2014 (UTC)

Alternatively, e.g. If you can't remember this in the future, go to the foot of your "Contributions" page and click on "Subpages". (There is one less page if you search this way; as it searches for user space pages starting "Martin Hogbin/" rather than "Martin Hogbin") - Arjayay (talk) 09:37, 27 June 2014 (UTC)

Thanks. Martin Hogbin (talk) 12:56, 27 June 2014 (UTC)

Page title conflicts through newly assigned Unicode characters?

Tracked in Phabricator
Task T69193

Just out of curiosity, I wonder how the Mediawiki software will deal with the following (rather obscure) situation, or if anything should be done about it. We currently have a redirect entry at ϳ (i.e. Unicode U+03F3, an obscure codepoint clone of "j"), which redirects to a section in the article on the normal Latin letter, J. In the latest update of the Unicode standard, a new uppercase equivalent of this character was introduced, at U+037F. That codepoint, although previously not yet a legal character, has also had a Wikipedia redirect entry for some while, Ϳ. I suppose that once the MediaWiki software gets updated to work with the latest version of the Unicode character database, the software will recognize that these two page titles are case equivalents, which means that they can't be technically distinguished from each ther. Will the software somehow automatically resolve this conflict by removing or forgetting about one of the two pages; will it remain accessible; or should it be deleted first? Fut.Perf. ☼ 10:49, 27 June 2014 (UTC)

Update to 7.0 and your question outstanding in bugzilla:67193. —TheDJ (talk • contribs) 11:35, 27 June 2014 (UTC)

We had a problem two or so years ago with a user who had registered an account using a single character, U+0271, for their user name: ɱ (talk · contribs); at the time, MediaWiki did not recognise that this was the lowercase form of U+2C6E and so it allowed the account to be created with that name. Later, it decided that the user name should be uppercased and linked to Ɱ (talk · contribs) which was not the same account. More at Wikipedia:Village pump (technical)/Archive 105#Link in history says user does not exist. --Redrose64 (talk) 22:49, 27 June 2014 (UTC)

As yes, the problem of Eversonian capitals. The lack of capital forms for many Latin/Greek/Cyrillic characters has led to an unfortunate ad hoc approach where these get added to Unicode at a later time when the capital gets discovered at a later time. Unicode has been doing a lot better at just encoding both case pairs for new characters, but there are still a large number of old letters (encoded early in Unicode) that really can't be justified until we find actual capital forms being used. I'll put in a reminder at writing systems to remind people to file a bugzilla to update case matching whenever a new Unicode version gets release. VanIsaac_WS^cont 00:53, 28 June 2014 (UTC)

Yeah, this particular character is probably an especially absurd case. The existence of the lowercase codepoint never made much sense to begin with, and the proposal document for the uppercase one is nothing short of bizarre. It's the first character proposal I've seen that fails to cite even a single authentic instance of use of the character in print – the only thing shown is one where the proposer thought the author ought to have used it but didn't (and clearly intentionally so.) But anyway, that's not for us here to worry about. On another note, one wonders why Mediawiki even has to define all these case mapping pairs manually all the time. Doesn't PHP have built-in Unicode case-mapping functionality, like any other decent programming language today? Fut.Perf. ☼ 10:28, 28 June 2014 (UTC)

Sure it does. But "built-in case-mapping" still depends on having up-to-date data files that contain the casing conversions. So I'm not entirely certain that there is a substantial difference between "doing it manually" and "built-in functionality". VanIsaac_WS^cont 19:36, 28 June 2014 (UTC)

Improved Diff acting up

For the last week or so, whenever I try the improved diff button I don't get the diffs but instead get a passage from a wikimedia script file which, surprisingly, includes a change marked with the usual red/green coding of the improved diff display. I'd post it here, but I'm afraid what the code would do to the system. Hope someone can get this comment to the appropriate people. SteveMcCluskey (talk) 01:18, 28 June 2014 (UTC)

@SteveMcCluskey: I think the page you're looking for is User talk:Cacycle/wikEdDiff. It looks like there was a large update to the code 4 days ago.

Re: pasting text dumps, just enclose them in a <pre>...</pre> tag. (or if it's many screens long, either take a screenshot, or paste the text at http://pastie.org )

Before that though, try clearing your browser cache (WP:REFRESH), justincase.

HTH :) –Quiddity (talk) 08:55, 28 June 2014 (UTC)

Thanks for the advice. I tried purging my cache and it didn't fix it so I've posted at User talk:Cacycle/wikEdDiff. --SteveMcCluskey (talk) 20:29, 28 June 2014 (UTC)

Resuming PDF downloads

> Kindly add new feature of resuming pdf download because wikipedia pdf > download files does not support resume ! This is very sad after an error we > can not resume because resume unsupported — Preceding unsigned comment added by 107.167.99.170 (talk) 05:50, 28 June 2014 (UTC)

Could you please elaborate? I assume you're referring to Special:Book's rendering (from the 'Collection' MediaWiki extension). If you can give steps to reproduce the problem, please report it on Wikimedia's bugtracker. Does the page not refresh for you? If it doesn't refresh you can just reload the page. πr² (t • c) 03:37, 29 June 2014 (UTC)

jQuery update causes constant script error

Tracked in Phabricator
Task T65303

Ever since the begining of the jQuery update and its console tracking, I've been getting script errors. They don't typically cause a crash but they do seem to screw up loading/caching every so often.

The most common error message is: Expected identifier
and it points to: targetFn.super=originFn
in something (load.php?) starting with var targetConstructor=targetFn.prototype.constructor;

Any ideas on who or where I should refer this to? -- George Orwell III (talk) 05:03, 29 June 2014 (UTC)

That's not caused by jQuery upgrade, and is already fixed: Template:Bug (but probably not deployed; the error will disappear in a few days). I suggest upgrading to a newer browser that supports this syntax. Matma Rex talk 10:27, 29 June 2014 (UTC)

Thanks for your attention & the pointer re: OOJS issues. -- George Orwell III (talk) 13:29, 29 June 2014 (UTC)

GeoGroupTemplate not working

{{GeoGroupTemplate}} collects links from a page and displays all of them on a Google map at once. For example, clicking the link at National Register of Historic Places listings in Alexander County, Illinois causes the browser to go to [23], which typically plots the page's seven {{coord}} locations on Google's map of the county. However, it's consistently been down over the last few days. What's going on? The error message says that the tool isn't currently being maintained by its operator, Para. I suspect vandalism, as Para's made exactly one edit to this project, and it's worked fine for years with no problems bigger than the occasional hiccup. But how to revert it when I can't see any relevant edits that Para's made? I don't even know what site to check! The template itself hasn't been edited in eight months. Note also that there's a similar problem at Commons; hitting the GeoGroupTemplate at Commons:Category:Allen Street (Bloomington, Indiana) takes me to https://maps.google.com/maps?q=http%3A%2F%2Ftoolserver.org%2F%7Epara%2Fcgi-bin%2Fkmlexport%3Fproject%3DCommons%26article%3DCategory%253AAllen_Street_%2528Bloomington%252C_Indiana%2529, which returns only a "file not found" message. I'm sorry for the tone, but I'm highly dependent on this service, and WP:VOLUNTEER is a good reason not to complain about inaction, not a good reason not to complain about bad action. Nyttend (talk) 05:12, 29 June 2014 (UTC)

It's Toolserver, which (as we have been warned several times on this page over the last two years) won't last forever. To be precise, it's got just over 40 hours left. If we're lucky. --Redrose64 (talk) 07:46, 29 June 2014 (UTC)

The toolserver link is just a redirect since that one edit, and the tool is actually hosted on Tools Labs. Its web service for the project had died with the error "sockets disabled, connection limit reached", which never happened on the Toolserver. Looks like I'm hitting some sort of a difference between Toolserver's Zeus Web Server and Labs' lighttpd. The tool doesn't get an exceptional number of hits, so it's going to take a while before it has the chance to hit the limit again, and to figure out a way to monitor the web server and whether the options at http://redmine.lighttpd.net/projects/1/wiki/Docs_Performance might affect it. --Para (talk) 22:37, 29 June 2014 (UTC)

Servers not serving, and not timing out either

For about four hours now, I've been unable to get any normal Wikipedia page to load completely. Most of the page loads fine, but after it's mostly (all?) displayed, the spinny thing in the browser tab continues to revolve, with the status bar showing either "Read en.wikipedia.org" or "Read bits.wikimedia.org" - this continues indefinitely, I left one going for half an hour before deciding that it would neither finish loading nor time out. Pressing Escape removes that message and replaces the spinny with a favicon. All namespaces except Special: appear to be affected; but the problem does not show up at either Commons or Meta. I'm using Windows XP, Firefox 30, MonoBook; and I'm in England. --Redrose64 (talk) 18:57, 29 June 2014 (UTC)

@Redrose64: Look in the Network tab in the web developer to see which page it's stuck on. Jackmcbarn (talk) 19:14, 29 June 2014 (UTC)

Mostly it's either http://en.wikipedia.org/w/index.php?title=User:Equazcion/SkipFileWizard.js&action=raw&ctype=text/javascript or http://en.wikipedia.org/w/index.php?title=MediaWiki:RefToolbarLegacy.js&action=raw&ctype=text/javascript but I did spot http://en.wikipedia.org/w/api.php once, without a query string. Maybe Equazcion knows what's wrong with the first one. Since I tried that "Network" thing, I've not seen it stick on any bits.wikimedia.org files. However, the HTTP 304 code is always shown against these, so surely it shouldn't be trying to re-retrieve? --Redrose64 (talk) 19:41, 29 June 2014 (UTC)