Jump to content

Wikipedia:Village pump (technical)

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by A Great Catholic Person (talk | contribs) at 19:20, 27 June 2014. The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

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

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


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!, —  dainomite   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]
Vector
The search box in Vector: gray lines, gray word, gray icon 		Monobook
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]

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)[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]
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)[reply]
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)[reply]
@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)[reply]
I've got Firefox 30.0 installed. Mjroots (talk) 04:30, 26 June 2014 (UTC)[reply]

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

  • 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)[reply]
I like the confirmation required bit, saved me from thanking the wrong person once. Dougweller (talk) 15:39, 27 June 2014 (UTC)[reply]
  • 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)[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. SpinningSpark 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. SpinningSpark 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. SpinningSpark 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? SpinningSpark 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)! πr2 (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]

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]
See also no:Spesial:Prefiksindeks/MediaWiki:Gadget-show-sysop-activity. Helder.wiki 13:31, 23 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="//upload.wikimedia.org/wikipedia/commons/thumb/d/dd/Achtung.svg/80px-Achtung.svg.png" width="80" height="70" srcset="//upload.wikimedia.org/wikipedia/commons/thumb/d/dd/Achtung.svg/120px-Achtung.svg.png 1.5x, //upload.wikimedia.org/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/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 [22] 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. [23] [24]
  • When dragging an item, you will now see a line that helps you to drop it. [25] [26]
  • 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. [27] [28]
  • You will now be warned if you add wikitext to file captions and references. [29] [30]

Future software changes

  • You will no longer be able to upload files on wikis that do not have any copyright tags. [31] [32]
  • CirrusSearch will be enabled as the primary search method on additional 70 new wikis, including Meta-Wiki and Wikimedia Incubator, during the next week. [33]
  • 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. [34]
  • You will soon be able to watch translations for e-mail notifications without receiving an e-mail when they are reviewed by another translator. [35] [36]
  • 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). [37]

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. [38]

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?

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)[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]
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]
  • 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)[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]
correct, thank you, the 1998 was a typo (still very old). Frietjes (talk) 23:56, 24 June 2014 (UTC)[reply]
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)[reply]

(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)[reply]
HTML Tidy is disabled by default in MediaWiki,[39] 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)[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? SpinningSpark 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. SpinningSpark 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. SpinningSpark 17:00, 24 June 2014 (UTC)[reply]
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)[reply]
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)[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 ChatOnline 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]

VisualEditor global newsletter—June 2014

The character formatting menu

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)[reply]

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)[reply]

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)[reply]
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)[reply]
Same here.(Chrome35)--Freshman404Talk 17:44, 25 June 2014 (UTC)[reply]
Ditto--☾Loriendrew☽ ☏(talk) 02:58, 26 June 2014 (UTC)[reply]
It has happened before. From my end all seems fine. --Fauzan✆ talk✉ mail 13:21, 26 June 2014 (UTC)[reply]

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)[reply]

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)[reply]
Great. I'll do that. Thanks. HandsomeFella (talk) 14:51, 25 June 2014 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]
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)[reply]

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)[reply]

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

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)[reply]

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)[reply]
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)[reply]
@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)[reply]
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)[reply]

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:

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

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)[reply]

.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)[reply]

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)[reply]

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)[reply]

Special:PrefixIndex/User:Martin Hogbin —TheDJ (talk • contribs) 09:22, 27 June 2014 (UTC)[reply]
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)[reply]
Thanks. Martin Hogbin (talk) 12:56, 27 June 2014 (UTC)[reply]

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)[reply]

Update to 7.0 and your question outstanding in bugzilla:67193. —TheDJ (talk • contribs) 11:35, 27 June 2014 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&oldid=614672826"