Misplaced Pages

Revision as of 07:22, 27 June 2014

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

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

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

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

Village pumps

policy

tech

proposals

idea lab

WMF

misc

• Refining the administrator elections process
• Blocks for promotional activity outside of mainspace
• Voluntary RfAs after resignation
• Proposed rewrite of WP:BITE
• LLM/chatbot comments in discussions

• view
• edit
• history
• watch
• archive
• talk
• purge

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 Misplaced Pages 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-Misplaced Pages 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.

VisualEditor news

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

Future software changes

• MediaViewer will be enabled by default on all wikis on June 12. Feedback is welcome.
• You will be able to use information from Wikidata directly in Wikiquote pages starting on June 10.
• 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.
• 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.
• Templates containing <ref> or <references> tags will no longer need dummy parameters to prevent caching.
• You will no longer be able to use Special:Thanks directly. The page will soon show an error message when you visit it.
• Hovercards will no longer flicker.

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._or_<references>_tags_will_no_longer_need_dummy_parame-Tech_News:_2014-24-2014-06-09T10:41:00.000Z">

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 10:41, 9 June 2014 (UTC)_or_<references>_tags_will_no_longer_need_dummy_parame"> _or_<references>_tags_will_no_longer_need_dummy_parame">

We are now running 1.24wmf8. This fix is not deployed and is not listed in the 1.24wmf8 change log. --  Gadget850 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 13:38, 15 June 2014 (UTC)

1.24wmf9 is now deployed, but this fix is not. --  Gadget850 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 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)

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

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 Misplaced Pages 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 05:43, 24 June 2014 (UTC)

All fixed. ^demon 15:22, 24 June 2014 (UTC)

Size of tables

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

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

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

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

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

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

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

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

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

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

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

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

Thanks once again! SpinningSpark 07:23, 22 June 2014 (UTC)

Removal Of Edit Counter?

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

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

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

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

Image position change

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

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

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

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

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

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

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

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

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

ProveIt glitch

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

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

Extracting biographical data from Misplaced Pages

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

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

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

Cross site communication with ToolLabs from Wikimedia

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

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

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

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

Yep, that was it; thanks. Magog the Ogre (t • c) 20:40, 21 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)

Javascript warning boxes

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="/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="/Wikipedia:Geonotice" title="Misplaced Pages: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)

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 16:35, 22 June 2014 (UTC)

Yes it is, Thank you Fixed, like this. --Redrose64 (talk) 16:47, 22 June 2014 (UTC)

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/Felipe_VI_of_Spain will automatically jump to https://en.m.wikipedia.org/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/費利佩六世 . 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)

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

advanced search?

I want to find all the articles I contributed to, in Misplaced Pages: 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)

I found something at Misplaced Pages: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)

@RoySmith: Try searching for Misplaced Pages:intitle:review. — This, that and the other (talk) 12:12, 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/search/?title=Category:Water_in_Texas&action=edit, from 10.128.0.110 via cp4010 frontend (: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 Misplaced Pages: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)

Mobile Browsing Issues

This page 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 06:21, 23 June 2014 (UTC)

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

Works great now, can fix any more I come across. Thank you GimliDotNet 13:50, 23 June 2014 (UTC)

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-Misplaced Pages 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.
• When dragging an item, you will now see a line that helps you to drop it.
• 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.
• You will now be warned if you add wikitext to file captions and references.

Future software changes

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

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.

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

07:20, 23 June 2014 (UTC)

Missing piece of wiki table syntax/markup?

In tables, wiki syntax/markup offers...

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

...as an alternative to...

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

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

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

...as an alternative to...

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

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

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

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

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)

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. -- ] {{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)

Technical input requested

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

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)

Yeah we have seen this discussion before. Good luck. —TheDJ (talk • contribs) 18:56, 23 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 Misplaced Pages: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 Misplaced Pages:Village pump (technical)/Archive 116#CfDs in mobile view - there is much related detail at Misplaced Pages:Village pump (technical)/Archive 116#'Listen' template not rendering in mobile view. There were one or two related threads, see for example Misplaced Pages:Village pump (technical)/Archive 119#Misplaced Pages 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}} 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}} 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}} 01:34, 25 June 2014 (UTC)

Initial trial run has completed, if anyone has any comments, please bring them to Misplaced Pages:Bots/Requests for approval/T13bot. Thank you, — xaosflux 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 _Online 03:55, 24 June 2014 (UTC)

html tags in PC error popup

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 Misplaced Pages: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)

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-Misplaced Pages 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 Misplaced Pages. 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 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_{✉ 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 Misplaced Pages 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)

Another question on Misplaced Pages traffic statistics

I want the stats-classic.grok.se version's top 1000 list to be downgraded to December 2010 data. I didn't want January 2014 data to be on the list when it went down back in early May. I'm ok if data is outdated; plus I prefer the old version, and I forgot to check a few articles' 2010 rankings, and I want to know them. The old version won't show data in 2010 for any article (not even topics that existed).

(Article) has been viewed 0 times in 201012. I want this issue to be fixed. Anyone? A Great Catholic Person (talk) 04:29, 27 June 2014 (UTC)

• Misplaced Pages noticeboards
• Pages automatically checked for accidental language links