Wikipedia:Village pump (technical)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

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

The technical section of the village pump is used to discuss technical issues about Wikipedia. Bugs and feature requests should be made at Bugzilla (see how to report a bug). Bugs with security implications should be reported to securitywikimedia.org or filed under the "Security" product in Bugzilla.

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

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

Template:TOC limit does not work in mobile view

Tracked in Phabricator
Task T73726

I was working on trying to limit the size of the ToC as it competes with the two infoboxes on Islamic State in Iraq and the Levant and I came to realize that that {{TOC limit}} does not seem to work as expected in mobile view. Take a look at this mobile view link here in mobile and desktop view and you'll see what I mean. I submitted a bug report to Bugzilla #71726 to see if there's anything that can be done to help get the desired results. It would also be nice if the TOC limit on mobile view can be set independently of normal view as well.~Technophant (talk) 03:07, 7 October 2014 (UTC)

The {{TOC limit}} template works by wrapping a normal TOC in a <div>...</div> which specifies an appropriate class, such as class="toclimit-3". The MediaWiki:Common.css file declares a CSS rule for those classes, but MediaWiki:Mobile.css doesn't. Since it's something that we have the ability to fix from our end, I don't think that it's a bugzilla matter. --Redrose64 (talk) 09:24, 7 October 2014 (UTC)

@Technophant: bugzilla:71726 has been marked "Resolved Wontfix". --Redrose64 (talk) 10:31, 11 October 2014 (UTC)

Right, we may want to add the same CSS classes to mobile.css as to common.css in order to get the template to work properly. This doesn't need support from MediaWiki itself. --ais523 10:34, 11 October 2014 (UTC)

I've produced a possible coding at User:ais523/mobile.css (it has to be different from the non-mobile view because the HTML layout is different). I'll go request that the edit's made; it should be uncontroversial. --ais523 10:48, 11 October 2014 (UTC)

And now the request's been submitted. We might want to continue this conversation over on the talk page for the site CSS, as the admins considering updating site CSS might not check this page. --ais523 10:57, 11 October 2014 (UTC)

protect?

[1]

• 19:07, 5 September 2013 Trust Is All You Need (talk | contribs) protect

What does it mean?--GZWDer (talk) 06:38, 11 October 2014 (UTC)

Remains of article feedback tool, it seems. https://en.wikipedia.org/w/index.php?diff=571681315 --Glaisher (talk) 06:43, 11 October 2014 (UTC)

These unreadable log entries needs to be cleaned up.--GZWDer (talk) 07:47, 11 October 2014 (UTC)

Weird log entry

Can someone have a look at [2]? I'm seeing this at the top:

18:29, 19 October 2013 Innotata (talk | contribs) protect

This looks very strange and might be a bug of some kind. (pinging Innotata because they might know what this is?) --NYKevin 13:51, 15 October 2014 (UTC)

Might it be from the Article Feedback tool? —innotata 14:16, 15 October 2014 (UTC)

Getting Started edit tag

Tracked in Phabricator
Task T74106

The "gettingstarted edit" tag is now shown as inactive on Special:Tags.

Since 10 October some edits still have been coming through with this tag, but only at about 5% of the previous rate. This has been the 8th most frequently used of all edit tags, and is of great value in WP:recent changes patrolling. It should not be de-activated without warning or explanation. Can it please be restored to full operation as soon as possible?: Noyster (talk), 17:54, 12 October 2014 (UTC)

Not sure if that's intentional. Maybe Superm401 or Robmoen know... --AKlapper (WMF) (talk) 09:26, 13 October 2014 (UTC)

I don't think you should be seeing those at all, except when the mw:Growth team is running an experiment with the mw:Extension:GettingStarted software. It's not a tag for new users; it's a tag to identify users that have been given a slightly different version of the software, such as the one described for mw:Onboarding new Wikipedians. I believe that they're a bit "between projects" at the moment, and today's a holiday for most of the WMF staff. It's likely that they'll have another one out before long. Whatamidoing (WMF) (talk) 22:14, 13 October 2014 (UTC)

OK if the stoppage of GettingStarted is just a short-term blip, but if it's more than that I'd like the community to be told and the WP:GettingStarted page to be amended. This feature has been active for quite a few months and over 230,000 edits have been tagged as made through it. GettingStarted has aroused considerable discussion, showing that those of us who deal with new users and their edits have a legitimate interest in the experience they are offered: Noyster (talk), 11:54, 15 October 2014 (UTC)

The Growth team has been retired, so it's unclear if/when we'll be able to continue experimenting with new GettingStarted features. Mattflaschen (WMF) (talk) 23:56, 15 October 2014 (UTC)

This change is intentional. I've updated Wikipedia:GettingStarted (sorry, we should have done that before). Note that the tag was never solely for new users (it applied to all edits using a particular interface, but even when that interface was being offered to everyone, so not only for experiments), nor did it cover all edits by new users. After we added a new experimental feature (Task recommendations) which could be used by new and existing users (which initially did not support edit tagging), we later decided not to use edit tagging for any GettingStarted edits.

There is a separate core feature that shows only contributions from new users (if I'm reading it right, it shows the 1% newest users) at [3]. This applies regardless of what interface people use. But remember to focus on the edit, not the editor. New users do a lot of good work (even though they're learning the ropes), and everyone makes mistakes, new and old. Mattflaschen (WMF) (talk) 23:56, 15 October 2014 (UTC)

Thanks for reply. I couldn't agree more: the ability to identify new editors is needed so that we can welcome and support good contributors, as well as to curb the vandals: Noyster (talk), 10:12, 16 October 2014 (UTC)

It appears that it is still tagging edits made by users with HHVM (a small minority, as you said, since HHVM is opt-in). This is bugzilla:72106.

Note, due to new WMF staff policy, I've split my work account off from my personal one. Going forward, User:Superm401 is now solely my personal account, and User:Mattflaschen (WMF) is my work account. (CCing User:Phuedx since he also worked on this). Mattflaschen (WMF) (talk) 23:56, 15 October 2014 (UTC)

Sorry, I meant to ping Noyster before. Mattflaschen (WMF) (talk) 23:57, 15 October 2014 (UTC)

User script suddenly not working any more

I use User:קיפודנחש/watchlistScout.js to alert me when something on my watchlist changes. It is supposed to run on page load and refresh every 60 seconds afterwards. For the past few days, though, I have been getting nothing from the script. All of my other scripts are working, I'm getting no errors on the javascript console, and it doesn't look like anything has changed in the code of the script recently (latest change was in 2012). Is there something else that may have changed site-wide that broke the script? Possibly an update to the API or something?--Dudemanfellabra (talk) 02:34, 14 October 2014 (UTC)

I am probably wrongly guessing here as I cannot see any suspicious function calls, but the timing would fit with https://lists.wikimedia.org/pipermail/wikitech-ambassadors/2014-September/000953.html --AKlapper (WMF) (talk) 05:40, 14 October 2014 (UTC)

Thanks for pointing that out. That was probably it. The creator of the script changed something related to an ajax call in the script and fixed it. I guess the old method was recently deprecated. Thanks for the help!--Dudemanfellabra (talk) 15:39, 14 October 2014 (UTC)

Search&Replace on Edit page

Using Firefox 31 and Vector skin on my laptop (Windows 7), I cannot make this function work. If I move the box to the column on the left, it disappears upwards as the page scrolls down on subsequent "Searches", and sometimes the "Search" will not highlight the word wanted at all, and is erratic at best. This even happens if the box is centred in the middle of the page. What is going wrong? I obviously use full screen mode when doing "Search&Replace". --P123ct1 (talk) 16:01, 14 October 2014 (UTC)

For small portions of text when the edit window does not have a scroll bar of its own, the search & replace window will always move along with the main browser page. When there's a large portion of text in the editor forcing its own scroll bar you can hold your cursor above the edit window and use the mousewheel to scroll it up and down with the S&R window staying in place. As to missing search results, the search function is case-sensitive, so you will have to do a separate search for words beginning with an upper-case letter (that's why there is a tickbox "match case"). De728631 (talk) 18:14, 14 October 2014 (UTC)

I always use "match case", but it still happens. I can't hold the cursor and move the mouse wheel, as I only have a touchpad. I'm not sure how to hold the cursor with it and still move things. --P123ct1 (talk) 07:48, 15 October 2014 (UTC)

signature Icon not responding in IE11

After opening an edit window, the signature icon (labelled 'signature and timestamp') works when using Opera 24 as browser but not when using Internet Explorer 11. This edit made and signed using Opera as browser. --— Philogos (talk) 18:22, 14 October 2014 (UTC)

When deleting BLP-prods, reason is not filled in

After clicking "delete" for a page with a standard CSD or PROD template, the reason is automatically filled in for every case except BLP-prod, when it is necessary to select it from the drop-down list. This may be be a hangover from the days when BLP-prod had a ten-day wait time, but now that it is seven days like normal PRODs, could automatic fill-in of the reason be provided? JohnCD (talk) 19:21, 14 October 2014 (UTC)

@JohnCD: I've been looking into this, and {{prod blp/dated}} actually does automatically fill in a deletion reason if you click the delete link in the template. The reason is set to a default of "Expired PROD, concern was: unsourced BLP", which cannot be changed with a parameter. From your post here, it looks like you're not seeing this text. Can you tell us exactly which delete link you're clicking? Is it the one that appears after the text in the middle of the template that looks like "Expired [[WP:PROD|PROD]], concern was: unsourced BLP"? — Mr. Stradivarius ^{♪ talk ♪} 11:05, 15 October 2014 (UTC)

The usual way I delete anything - click "Delete" on the drop-down menu under "More" just left of the search box (Win7, FF33.0, Vector). That fills in the reason for CSDs and normal PRODs. JohnCD (talk) 11:48, 15 October 2014 (UTC)

@JohnCD: Ok, this should be fixed now. {{prod blp/dated}} was missing an HTML element with an ID of "delete-criterion", which is why the reason wasn't being automatically filled in. I've added the correct HTML, as well as doing some general template clean-up. I've also removed the default reason from {{prod blp}}, but existing BLPPRODs still have it, so for the next seven days you will see a lot of deletion reasons that look like "Expired [[WP:BLPPROD|BLPPROD]], concern was: All biographies of living people created after March 18, 2010, must have references." — Mr. Stradivarius ^{♪ talk ♪} 14:24, 15 October 2014 (UTC)

That works, thanks - quick service! JohnCD (talk) 17:44, 15 October 2014 (UTC)

anchor template breaks → click in edit summary

I can no longer follow the → click in this edit summary. I had to move down the anchor template to make the → click in the edit summary work. Environment: Firefox 33, Ubuntu 12.04 LTS. --Ancheta Wis   (talk | contribs) 21:06, 14 October 2014 (UTC)

These links are always broken if there is a template in the heading. The subject of templates in section headings is under discussion at Template talk:Talk header#No links in headings. --Redrose64 (talk) 23:44, 14 October 2014 (UTC)

Why am I seeing a notice in my contributions list at times?

At times right now, I'm seeing a notice in my contributions list that says:

Changes newer than [anywhere from 10 to 15] seconds may not appear in this list.

I've never seen this notice before, ever. It's only showing up at times, not all the time. Did a new build just go out recently? Gparyani (talk) 00:26, 15 October 2014 (UTC)

It looks like a simplified database lag message. –xeno^talk 00:40, 15 October 2014 (UTC)

Very old page creations show major problems in history / contributions

Tracked in Phabricator
Task T38976

Tracked in Phabricator
Task T36873

Probably a known issue, but here goes...

Looking at the earliest edits by User:Damian Yerrick (for no particular reason, was browsing some old edits), I noted that many of those had huge negative diff sizes (up to -100 kB). Looking e.g. at the oldest edits to PUSA ([4]), we see this edit indicated with -100 kB, when it actually doubled the size of the article. The reason for these strange numbers appears when you look at [5], and there click on the "diff" link next to these contribs. For this particular page, the diff you get is this, comparing a version of late 2009 to a version of late 2001. Here as well, mid 2010 compared to October 2001. Or here, May 2011 to September 2001.

I haven't been able to find a pattern (e.g. this happens after X edits to a page), and don't know yet if it only happens with very old edits, but it is not really good of course. But another result of this problem is that e.g. User:Swhite created the page Spam[6], but it doesn't appear in his contributions[7]!

Are these inconsistencies still the result of that major database crash in the early years (2002?), or is it a new problem? I have never heard of edits appearing in one history (article history), but not in another (contributions list), but then again I haven't heard everything ;-) Fram (talk) 09:48, 15 October 2014 (UTC)

@Fram: This sounds like it might be in Graham87's area of expertise. I see that he's also documented some of his work at User:Graham87/Page history observations. — Mr. Stradivarius ^{♪ talk ♪} 11:10, 15 October 2014 (UTC)

Thanks. Hopefully he can shed some light on this, the section "Revision ID numbers" maybe relevant here, but he will be probably much better placed to judge this. Fram (talk) 11:16, 15 October 2014 (UTC)

The problem with erroneous byte differences in page histories is tracked as Bug 36976, and is indeed related to revision ID numbers, as they are used to calculate the previous and next revision of a page. The problem with missing contributions is tracked as bug 34873, and occurs because many older edits are stored with a user ID of 0; the reason for this is that the accounts of the affected usernames hadn't been created in September 2002, when the older edits were mass-imported into the Wikipedia database. Graham87 11:25, 15 October 2014 (UTC)

OK, thanks! I'm glad that they aren't new problems. Fram (talk) 11:33, 15 October 2014 (UTC)

Is it because I'm user 1? I've been confused with a mop bearer more than once. Anyway I clicked "next" on that edit and expected to see a revert. My, how Wikipedia has changed since then. --Damian Yerrick (talk) 23:31, 15 October 2014 (UTC)

@Damian Yerrick: Nope, it's because I've done so many imports of your edits from the Nostalgia Wikipedia and other places. Graham87 09:34, 16 October 2014 (UTC)

Pages in category Section name

What is the technical Section name for what appears as 'Pages in category "Φ"' in read mode? In other words, how do I get this edit to work properly? Thanks It Is Me Here ^{t / c} 14:50, 15 October 2014 (UTC)

I tweaked it to use {{anchor}} instead of the section header.

—Trappist the monk (talk) 15:30, 15 October 2014 (UTC)

The html source of the rendered category page contains:

<h2><a name="Pages_in_category" id="Pages_in_category"></a>Pages in category "CS1 errors: dates"</h2>

So the anchor name is "Pages in category". You had the right name but swapped the parameter order in {{sts}}. PrimeHunter (talk) 15:39, 15 October 2014 (UTC)

I have changed it with edit summary: use MediaWiki's anchor "mw-pages" instead of "Pages in category" which is an ugly hack added in MediaWiki:Category header so the link would fail in other user languages than the default en.[8] That hack can cause other problems and should probably be removed but I don't know whether we rely on it elsewhere. PrimeHunter (talk) 16:12, 15 October 2014 (UTC)

older version of the map

hello, I have uploaded a map for an article Im working on Yamhad.

the problem is that the infobox is showing an older version of the map, instead of showing this : https://en.wikipedia.org/wiki/File:Yamhad_and_Vassals.png its showing this ! : https://upload.wikimedia.org/wikipedia/commons/archive/2/22/20141015123556!Yamhad_and_Vassals.png is there anyway to fix this problem ?--Attar-Aram syria (talk) 17:29, 15 October 2014 (UTC)

I purged the version in the article with https://upload.wikimedia.org/wikipedia/commons/thumb/2/22/Yamhad_and_Vassals.png/250px-Yamhad_and_Vassals.png?action=purge. It displays right now. PrimeHunter (talk) 17:57, 15 October 2014 (UTC)

Why do time stamps use DMY regardless of what I set my preferences to?

In my preferences, I set my timezone to CDT (America/Chicago on the list), and so that properly converts the timestamps from using UTC to instead display CDT, but regardless of what date format I set it to use, it displays in DMY. What is the problem here? Dustin (talk) 21:43, 15 October 2014 (UTC)

It works for me at for example the history of this page.[9]. What is your date format setting at Special:Preferences#mw-prefsection-rendering and where do you see DMY? If you mean in signatures then they are not software-generated but saved in the wikitext as UTC and DMY. The MediaWiki software does not change them according to your preferences. The English Wikipedia has added an option at Special:Preferences#mw-prefsection-gadgets: "Change UTC-based times and dates, such as those used in signatures, to be relative to local time". This changes the displayed time in signatures but is not supposed to affect the date format. PrimeHunter (talk) 22:51, 15 October 2014 (UTC)

@PrimeHunter: Just as through my preferences, date format in page histories can be chosen, and the display timestamp can be modified to work for a user's timezone, why can the date format of time stamps just be auto-converted? I don't particularly like DMY as it puts the least significant values before more significant values. I set my preferences at at Special:Preferences#mw-prefsection-rendering to use MDY because that is what I am used to, but I also have tried out or used YMD on occasion, but neither actually change how the time stamps display for me, even though they change the date format of revisions on page histories. Dustin (talk) 16:05, 16 October 2014 (UTC)

The MediaWiki software only has built-in functions to change the display of times which are stored as database entries, for example edit times in page histories, user contributions, watchlists, recent changes. This display is controlled by Special:Preferences#mw-prefsection-rendering. When you sign with ~~~~, the time and date is not stored as a database entry in a time field but as actual text in the wikisource of the page. That text can then be treated like any other wikitext. It is an editor at the English Wikipedia who created the gadget to identify times in wikitext and change the time zone display. If a user enables the gadget then MediaWiki:Gadgets-definition tells the software to run MediaWiki:Gadget-CommentsInLocalTime.js which loads User:Gary/comments in local time.js which is made by User:Gary. Your browser receives the original UTC time but the JavaScript then runs in your own browser and changes what you see. I'm not a JavaScript programmer and don't know whether it could be modified to get the date format from your preferences and also change that, or maybe a new gadget or user script created to do it so users can choose independently. If somebody writes the code then administrators can add gadgets with easy one-click enable/disable at Special:Preferences#mw-prefsection-gadgets. Any registered user with the right knowledge can write and run their own JavaScript or import it from elsewhere by editing their own Special:MyPage/common.js. I don't know whether somebody has a script somewhere to change the displayed date format. PrimeHunter (talk) 18:06, 16 October 2014 (UTC)

With the Comments in Local Time script, you can set the date format with the instructions found here. Available date formats are DMY, MDY, and YMD. Gary (talk · scripts) 18:38, 16 October 2014 (UTC)

Randomly logging out

Every time I open a new tab (and sometimes even if I don't), I randomly log out. Help? --User J. Dalek (talk | contribs) 22:39, 15 October 2014 (UTC)

By the way, I use IE 11. --User J. Dalek (talk | contribs) 22:43, 15 October 2014 (UTC)

@UserJDalek: try reloading; Works for me. --Mdann52talk to me! 16:38, 16 October 2014 (UTC)

It seems to work now. Thanks. --User J. Dalek (talk | contribs) 22:15, 16 October 2014 (UTC)

Can someone make a list for me?

I'd like to better understand WP:LEADLENGTH—how we do it in actual practice, not just the theory on the guideline page. One way to address this, I thought, would be to compare our (old) advice against our (recent) WP:TFAs. Does someone know how to make a table (or spreadsheet, or text file) that has this kind of information, without having to do it all by hand?

Article name	Number of characters	Number of words	Number of sentences	Number of paragraphs	Characters in the lead	Words in the lead	Sentences in the lead	Paragraphs in the lead
Tropical Storm Kiko (2007)	6,050	965	50	6	1,010	160	8	1
Colorado River	67,400	11,100	510	82	4,425	716	34	4

I'd like to have this data for, say, the last 100 consecutive TFAs. Since my manual method is slow, and since eyeballing the text to remove section headings and ref numbers is doubtless sloppy, I'm really hoping that someone can come up with a fast, easy, automated method. It seemed to me that the WP:DYK script might be useful for the character counts, but that still leaves the rest.

If you can produce the list and also feel like doing the basic analysis for me (which of the whole-page numbers correlates best with which of the lead-only numbers?), then so much the better. WhatamIdoing (talk) 22:59, 15 October 2014 (UTC)

• If you are going to build a small task force to do this work (5 members, 20 articles), or cerate a sub-page under your user-page, you may call me in there. Thanks. --Tito☸Dutta 23:18, 15 October 2014 (UTC)
  • Umm, I might be able to whip up a script to do this automagically. I'll give it a shot.--v/r - TP 00:00, 16 October 2014 (UTC)
  • Thanks for the offer, Tito. TParis, I hope that the script works. WhatamIdoing (talk) 20:16, 16 October 2014 (UTC)

Improving article history

I think article history should more often than it does not show information is removed then added. For example, the first sentence is all I removed from Chess#Promotion here and it still treats it like I removed the whole thing and wrote something else. Blackbombchu (talk) 21:11, 16 October 2014 (UTC)

By 'history', you mean the diff, right? Try wikEdDiff. — HHHIPPO 21:22, 16 October 2014 (UTC)

Wikimedia Tool Labs

Tracked in Phabricator
Task T74104

I use a couple of wikimedia tool labs sites such as [10] to check my user statistics and [11] to check article statistics, bugs and such. They are really useful sites but for the last few days they have been down. I can't seem to find a place to report the sites being down and I was referred to here by the IRC help chat. I hope you can help and I appreciate you looking at my request. - SantiLak (talk) 22:08, 16 October 2014 (UTC)

See bugzilla:72104. PrimeHunter (talk) 22:52, 16 October 2014 (UTC)

I appreciate the help. - SantiLak (talk) 23:28, 16 October 2014 (UTC)

Is this why I keep seeing spinning donuts and the message Waiting for tools.wmflabs.org... most every time I read or update a page? Wbm1058 (talk) 23:30, 16 October 2014 (UTC)

User:Wbm1058/common.js contains

mw.loader.load('//meta.wikimedia.org/w/index.php?title=User:Hedonil/XTools/XTools.js&action=raw&ctype=text/javascript');

The loaded meta:User:Hedonil/XTools/XTools.js contains

importScriptURI("//tools.wmflabs.org/xtools/api.php?pageid=" + ...

I guess that's the cause. PrimeHunter (talk) 23:57, 16 October 2014 (UTC)

I see, thanks. That's probably one of the causes. Perhaps there's another one or more... Wbm1058 (talk) 00:25, 17 October 2014 (UTC)

I think the labs bug is the entire cause of the spinning donut and message about labs, if the Hedonil tool scrpt is loaded on the user's .js page. I've been getting it for several days. When it finally stops spinning, which seems to take forever, the Hedonil tool does not show at the top of the article page — Maile (talk) 14:47, 18 October 2014 (UTC)

What links here

Before October 16, when I type in a page for What links here, there would be no suggestion drop down list. Now there is. Usually, I know what exact article title I'm going to put in there. I don't need the dropdown list's help. Any way to disable it? (Don't completely remove it, I sometimes want it enabled.) The only way to disable it is to check box but that does it for the search box, too. I would like it to be kept for the search boxes but disabled (however I sometimes want to re-enable it) on the What links here. I did not find this in any tech news. A Great Catholic Person (talk) 05:32, 17 October 2014 (UTC)

[OAuth page] some internal links not working (e.g. Facebook)

There are several links on the OAuth page that are not rendering. Specifically, in the List of notable OAuth providers the links for Facebook, LinkedIn, and Twitter do not show on the article view. What could be the cause of these links not rendering? Brylie Christopher Oxley (talk) 06:54, 17 October 2014 (UTC)

Someone else mentioned a similar problem a few days ago over on ANI. It seems to come down to AdBlock Plus and Fanboy's Social Blocking List. They mentioned that it should be fixed now though, perhaps if you update the extension/list? Organics ^talk 12:34, 17 October 2014 (UTC)

Did something happen to Ambox?

I am using Monobook, and all of the templates based on {{ambox}} such as {{POV}}, {{refimprove}}, {{FAQ}}, etc. are displayed in a strange manner. See this image. --benlisquare_T•C•E 08:22, 17 October 2014 (UTC)

I don't see a problem in Monobook. Try clearing your cache. -- [[User:Edokter]] {{talk}} 10:43, 17 October 2014 (UTC)

Dark colour schemes and the interface between the system, browser and Wikipedia

Tracked in Phabricator
Task T74188

Tracked in Phabricator
Task T74192

I hope this is the right place to ask this question. This is the number one issue that stops me editing Wikipedia comfortably, and it's an issue that hasn't yet been resolved, due to its technical nature. There are issues with formulae, box quotes, transparency in images (e.g. chemical structure diagrams), and the list just goes on. Adding the the problems is the new software that is coming out through 2014-15 (Media Viewer, VisualEditor, etc.) which utilises set colour schemes which from my (poor) understanding are hard to change with CSS script. I haven't filed a bug report, because it seemed others already had for the exact same issue.

Poor contrast on flow forms, most probably due to system colour scheme.

One of my last sentences on that discussion page, "However, on Wikipedia, [the stylesheet is] already suitable for my daily use", has since been found to only be true for the reading of non-technical articles which didn't contain box quotes. It's very frustrating, in that it severely impedes my use of this amazing website.

The other annoying behaviour, which is related, is the actions of certain text-entry boxes. The new piece of software, Flow, is an example, as is the larger search box that pops up under the heading "Search results" when your search query isn't found. The text and text box are almost the same colour; really dark. This is probably caused by the interaction between the system and browser, but changing the browser's default colour settings isn't an option, because then everything else is unreadable. I don't know how to tell my browser to ignore my dark system colours on websites and use the default light ones (I've tried playing around with all the colour settings in Firefox already).

Another interesting observation is that the source editing form I'm using to write this is using the dark background too, but it uses the light-grey text from my system theme in tandem, meaning that reading the text is not a problem. Same with the buttons down the bottom. I'm not sure if perhaps the specific input boxes I'm having trouble with take information from the system for the background, but none for the text, which might just be set as an unchanging black?

If any of this doesn't make sense, I can post more screenshots.

I'm running Linux Mint 17 Cinnamon, with a dark colour scheme for my window manager. Firefox 33.0 is my browser.

Any help would be vastly appreciated. Thanks, Thennicke (talk) 13:24, 17 October 2014 (UTC)

The issue for the larger search box, and probably for other things such as flow, is that the WMF UX designers have fallen in love with using dark grey rather than black text all over the place but they're only overriding the text color and not the background color. This works fine with the default white, but for people like you who've set the browser to a different color scheme this causes problems. This should be filed as a bug if it hasn't been already. Anomie⚔ 14:45, 17 October 2014 (UTC)

Anomie⚔, I thought it was a bit strange that only the text should be set to a different colour; that explanation makes sense though. Thank you, I'll file that bug. The issue with Wikipedia's lack of support for dark colour schemes is obviously a much bigger task. Thennicke (talk) 15:29, 17 October 2014 (UTC)

Thennicke, you might be interested in my suggested Appearance and accessibility panel (see Wireframe/napkin-sketch illustration in particular) - feedback appreciated!. And thanks Thennicke and Matma_Rex for filing those bugs. Quiddity (talk) 19:49, 17 October 2014 (UTC)

I would also like light colored text on a black background, but gave up on it due to all the issues it seems to cause. If it would work, it would solve several problems. On my CRT monitor, light backgrounds require more electricity, generate more heat, cause more damage to the eyes, make flickering appear worse, and cause more electromagnetic interference. Depending on the technology, this may be true for various flat screen monitors, too. If the screen was white when you turn the monitor off, and LCDs were used to block portions of that white background, then Wikipedia's default white background would make more sense. StuRat (talk) 21:26, 17 October 2014 (UTC)

StuRat, check out User:Dodoïste/vector.css for a prototype skin. You and I are not alone in this issue; Axl mentioned it as well, for example, and there are definitely others. The main issues with this skin at the moment are as follows:

• Interaction with the UI elements in the new beta software
• Templates with user-defined colour schemes are also a huge issue
• Mathematical formulae are unreadable
• Box quotes are unreadable
• There's a lot of generally ugly and incompatible stuff

Quiddity, that wireframe looks really good at the moment! I honestly don't have any suggestions to add, other than perhaps an "advanced" menu where every font size and UI element colour is customisable for people who find the defaults unsuitable. (e.g. a direct inversion of the default colour scheme, for me, is too harsh. Hence the greys used on User:Dodoïste/vector.css)

This dark colour scheme is certainly a critical feature for me and others, and it will obviously require a community effort, because it's such a big project. Too bad I can't code. Cheers to everybody here for their help! Thennicke (talk) 05:44, 18 October 2014 (UTC)

Thank you for pinging me, Thennicke. For the benefit of other readers: I use the green-on-black skin to reduce background glare. However I am unable to view many diagrams properly—often the labels or lines do not appear. Also, I am not able to view the WP:GAN pages. As a result, I have stopped undertaking GAN reviews. Axl ¤ [Talk] 08:39, 18 October 2014 (UTC)

Watchlist option when moving pages

When moving a page, one has an option to tick or untick the "Watch source page and target page" box. However, more often than not, I am finding myself in need of watching only the target (i.e., where the article is being moved to) but not the source (which will become a simple redirect). Is there a technical reason why the source and the target can't be unbundled into separate boxes? It's somewhat annoying to have to go through an extra step of going back and watching the target (if the box was not checked during the move) or unwatching the redirect (if the box was checked). Surely I'm not the only one feeling so?—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); October 17, 2014; 14:03 (UTC)

Watchlists can have thousands of entries and redirects are rarely edited so I don't see a problem in adding the redirect to the watchlist. Maybe some users would like the option but it doesn't seem significant enough to clutter the interface and ask for developer work. Note that if others move a page on your watchlist then the new title is also added to the watchlist without removing the old title. PrimeHunter (talk) 15:49, 17 October 2014 (UTC)

I have no problem with the old title being kept on my watchlist when others move a page—in this case retaining the redirect in the watchlist actually helps see that the article has been moved, especially if consequent edits are done to the target before the move is seen on the watchlist. But keeping unnecessary (to me) records of redirects on my already overly long watchlist does not seem to be useful at all. If I kept every such redirect, my watchlist would not be just difficult to edit (as it is now, with 14,000+ entries and counting), but extremely so (I did have browsers on older PCs crash and hang when trying to open my watchlist in edit mode). And just how much of developers' time would splitting the option in two take, anyway? Ten, fifteen minutes? :) And if both options ("watch source", "watch destination" are placed on the same line, the cluttering is going to be minimal. Come to think of it, the "leave a redirect behind" seems a lot less useful than what I'm proposing. Yes, occasionally there is a need to suppress the creation of a redirect when moving a page, but does that really happen so often we need a separate option for that? Anyone else cares to chime in?—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); October 17, 2014; 17:11 (UTC)

"leave a redirect behind" is only seen by admins. I often use either option there. Non-admins only have one checkbox on the move form. Many of them may not realize that anyone can change the redirect, and watching the source will inform them of such changes. PrimeHunter (talk) 17:35, 17 October 2014 (UTC)

The ability to suppress redirects by unchecking the "leave a redirect behind" box makes some history merges and swaps much much easier, and I would vociferously object to the removal of that check box. Graham87 08:52, 18 October 2014 (UTC)

Tearing its guts out

Here's another bit of enigmatic (for me, at least) template stuff:

• User:Paine Ellsworth/Sandbox2

The way that grouping should appear is as follows:

• User:Paine Ellsworth/Sandbox3

I actually came across a redirect that was tagged like that first link above. The separation of the innards of the {{Redr}} template doesn't happen if the external rcat, {{R to section}}, is removed. When the Redr is placed in the usual position on the third line (or even on the second line), then all is normal. I tried using other independent rcats and received mysterious results – {{R with possibilities}} gives the same puzzling separation, while {{R from subpage}} looks normal. Of course, I'd like to fix this so editors don't have to be concerned about where they position the templates on a redirect, but I have no idea where to start. Is there maybe an easy fix to the template(s) for this? Is this suitable for a bug report? – Paine Ellsworth ^CLIMAX! 16:24, 17 October 2014 (UTC)

Sorry, I should have been looking at this. The problem is that {{mbox}}-based templates only work properly if placed at the start of a new line, otherwise HTML Tidy screws with what's inside the box. In the case of Sandbox2, you've got a table inside a list item of an unordered list; in the case of Sandbox3, the table is after the unordered list. It often happens with {{edit protected}} - compare old version with fixed version; the only difference is the presence of a colon in the first one. --Redrose64 (talk) 17:16, 17 October 2014 (UTC)

No problemo, and thank you for your explanation! The colon works well to spoil Redr as well:

• User:Paine Ellsworth/Sandbox2

I'll note it in the documentation. – Paine  22:11, 17 October 2014 (UTC)

Change in behaviour of Special:LinkSearch

It is possible to link Wikipedia pages in two ways: as an internal Wikilink, which shows in "What links here", or as an external link, which does not. In the past it was possible to use Special pages → External links search for such links. At the top of that page it shows MediaWiki:Linksearch-text, which advises "To search for external links to pages on this site, start with en.wikipedia.org/wiki/".

This no longer works. According to bugzilla:72185, this is because $wgRegisterInternalExternals is not switched on. But, this certainly used to work, so when was it turned off? Bawolff (talk · contribs) and AKlapper (WMF) (talk · contribs) both say that it was intentional. --Redrose64 (talk) 19:08, 17 October 2014 (UTC)

I believe it was turned off at about MediaWiki 1.16 (2010-ish). See rev:53104. Following the link to bugzilla:19637, this appears to be a performance optimization (I didn't realize that when I commented on the bug). User:SPringle (WMF) would be the one to ask if the performance concerns are still valid, or if it can be re-enabled. Bawolff (talk) 19:44, 17 October 2014 (UTC)

SSL 3.0 discontinued

Possibly only dozen people in the world noticed this, but in case any of them are wondering: it appears that SSL 3.0 was disabled yesterday on the Wikipedia secure server. If you try to login via https: (and of course no one passes login data over http:) and your browser has "SSL 3.0" enabled—oops! The initial error message was:

 Error code: ssl error no cypher overlap

At the end of the day message changed to:

 SSL protocol has been disabled.

This apparently unannounced change (I haven't seen any mention of it) is presumably due to a "critical flaw in SSlV3" — "POODLE" — discovered just last month.

Anyone encountering this problem should go into their browser settings and disable SSL 3.0. If you have really old browser, it's time to upgrade. ~ J. Johnson (JJ) (talk) 00:23, 18 October 2014 (UTC)

If your browser has TLS 1.2, 1.1, or 1.0 enabled, those should be preferred (in that order) to SSL 3.0. As for announcements, see [12] Anomie⚔ 00:46, 18 October 2014 (UTC)

Error when searching for template "a"

This query results in the error message "An error has occurred while searching: The search backend returned an error:". Other single-letter templates are found just fine, maybe someone should take a look at this. Paradoctor (talk) 08:56, 18 October 2014 (UTC)

When that happens, I try to get to the bare URL, as in http://en.wikipedia.org/wiki/Template:A. – Paine Ellsworth ^CLIMAX! 14:31, 18 October 2014 (UTC)

It works when I enable "New search" at Special:Preferences#mw-prefsection-betafeatures. I think New search is planned to become the default or only search and there is limited interest in using resources on fixing such problems with the old search. PrimeHunter (talk) 14:39, 18 October 2014 (UTC)

No sweat, it's just something I noticed and thought might be of interest. Paradoctor (talk) 17:45, 18 October 2014 (UTC)

Xtools / edit counter

Tracked in Phabricator
Task T74104

Does anyone here know the status of the Xtools edit counter? I have been unable to access the tool for several days, and this does not appear to be one of the usual temporary service interruptions. Does anyone know anything about this? Dirtlawyer1 (talk) 14:12, 18 October 2014 (UTC)

All Xtools have been down for some days. See #Wikimedia Tool Labs and bugzilla:72104. PrimeHunter (talk) 14:18, 18 October 2014 (UTC)

I have mentioned it's down in the interface message Template:Sp-contributions-footer.[13] I did the same yesterday for MediaWiki:Histlegend.[14] PrimeHunter (talk) 14:27, 18 October 2014 (UTC)

If you go to the Github report you see: "Labels: None! No milestones! Nobody assigned!" The Bugzilla thread is equally discouraging: "Unprioritized! Assigned to nobody!" Except for Wikiviewstats, trying to use any of these tools does not even produce an error message, just a blank screen endlessly showing "Waiting for tools.wmflabs.org". (See the thread above, "Wikimedia Tool Labs", for some of the problems caused for users). Well I think this is not good enough for a facility used by many thousands. How do we jog Wikimedia to get going and resolve this?: Noyster (talk), 08:43, 19 October 2014 (UTC)

@Dirtlawyer1, PrimeHunter, and Noyster: Looks like the counter is operational again. GoingBatty (talk) 15:16, 19 October 2014 (UTC)

Great! I have removed the down messages from Template:Sp-contributions-footer and MediaWiki:Histlegend after testing the three linked xtools. PrimeHunter (talk) 16:14, 19 October 2014 (UTC)

@GoingBatty: I'm a writer/editor, not a wiki-coder tech guy. When there are problems with X tools (or other Wikimedia Lab Tools), where is the appropriate interface to go with questions? Once upon a time, we could go to X!'s talk page . . . . Dirtlawyer1 (talk) 15:29, 19 October 2014 (UTC)

@Dirtlawyer1: This page seemed to work pretty well for you. GoingBatty (talk) 15:38, 19 October 2014 (UTC)

• (edit conflict) For X! tools, there are a few maintainers... The best ways to do it is post the issue on bugzilla (phabricator soon replacing this), on github (here), or ask a maintainer: Cyberpower678, Hedonil and Tparis (may be more, not sure). — {{U|Technical 13}} ^{(e • t • c)} 15:41, 19 October 2014 (UTC)

• Thanks, guys. Dirtlawyer1 (talk) 15:45, 19 October 2014 (UTC)

• One more question: pardon my ignorance, but what is the relationship of Phabricator and Bugzilla to Wikimedia Labs? I don't wander outside of English Wikipedia or Wikimedia Commons very often, so all of these support groups are a bit of a mystery to me. Dirtlawyer1 (talk) 15:53, 19 October 2014 (UTC)

FeaturedTopicSum

Can anybody work out what the "-2" in Template:FeaturedTopicSum is for? I've been trying to convert this template to Lua at Module:FeaturedTopicSum, because it will be used in Module:Article history, but I can't work out why the current template code is the way it is. The template takes a topic name as {{{1}}}, returns {{{2}}} if the topic is a featured topic, and returns {{{3}}} otherwise. Now, one of the featured topic criteria is that 50% or more of the articles in the topic are featured articles. This criterion is translated into the following template code:

{{#ifexpr:{{PAGESINCATEGORY:Wikipedia featured topics {{{1}}} featured content}} >= ({{PAGESINCATEGORY:Wikipedia featured topics {{{1}}}}} + {{PAGESINCATEGORY:Wikipedia featured topics {{{1}}} good content}}-2)
|{{{2}}}
|{{{3}}}
}}

For a figure of 50% or more, I would expect the calculation to be "featured >= good + other", not "featured >= good + other - 2". Am I missing something here? — Mr. Stradivarius ^{♪ talk ♪} 18:11, 18 October 2014 (UTC)

Also, I should leave a ping for User:Ucucha, who made the most recent edit to the template. — Mr. Stradivarius ^{♪ talk ♪} 18:12, 18 October 2014 (UTC)

My guess: "Wikipedia featured topics ... good content" and "Wikipedia featured topics ... featured content" are subcategories of "Wikipedia featured topics ...", so subtracting two from the {{PAGESINCATEGORY:Wikipedia featured topics {{{1}}}}} term ensures that these subcategories are not included in the article count. SiBr₄ (talk) 18:49, 18 October 2014 (UTC)

(edit conflict) It appears the reason for this adjustment is that the page:

• Category:Wikipedia featured topics *

contains both category pages:

• Wikipedia featured topics * featured content
• Wikipedia featured topics * good content

I expect the "-2" is to adjust for this inclusion. A quick look at the first category in the list shows:

• Category:Wikipedia featured topics 1906 Atlantic hurricane season pages:1 (with no pages actually in this category)
• Category:Wikipedia featured topics 1906 Atlantic hurricane season featured content pages:0
• Category:Wikipedia featured topics 1906 Atlantic hurricane season good content pages:3

— Makyen (talk) 19:12, 18 October 2014 (UTC)

Indeed, see mw:PAGESINCATEGORY. An alternative would be to use {{PAGESINCATEGORY:Wikipedia featured topics {{{1}}}|pages}}, which doesn't count subcategories. — HHHIPPO 19:19, 18 October 2014 (UTC)

Aha, that makes sense. I was getting messed up because the equivalent code in Lua doesn't count subcategories. (Or more accurately, you can specify whether you want it to count pages, subpages, files, or all three.) Thanks, everyone. — Mr. Stradivarius ^{♪ talk ♪} 19:50, 18 October 2014 (UTC)

And looking at the PAGESINCATEGORY docs, I see that the parser function works that way as well. The option to specify pages only came in MediaWiki 1.20, though, which would be why the template didn't use it. The last update to the template was in 2010, and 1.20 was released in 2012. — Mr. Stradivarius ^{♪ talk ♪} 19:57, 18 October 2014 (UTC)

Special talk namespace

It's not obvious where to discuss Special pages, but it seems the typical place for them is Wikipedia:Talk:Special:Foo. On the other hand, sometimes they are at Help:Talk:Special:Foo, so it's not even consistent. In my view, this should instead be Special talk:Foo, and Special:Foo should have a discussion tab just like any other page. This would give a place for people to discuss special pages that they would actually be able to find. Oiyarbepsy (talk) 18:48, 18 October 2014 (UTC)

Note: Please see Wikipedia talk:Criteria for speedy deletion#Proposal to update R2 criterion for "Special talk:" redirects for the discussion that prompted this one. Steel1943 (talk) 18:52, 18 October 2014 (UTC)

• Per my comment in the other discussion Steel linked to (please respond there), creating a NSA for the "Special talk:" to point to "Wikipedia talk:Special:" is pretty easy. To get a "discussion tab" on Special pages would be more difficult to do in core because, as I understand it (which isn't always the way it is), special pages aren't normal pages in a normal namespace (hence the NS number of -1); that said a gadget could be created that would simulate a "discussion tab" on most special pages (there are a couple where .js won't run for security reasons). — {{U|Technical 13}} ^{(e • t • c)} 21:41, 18 October 2014 (UTC)

Template:CoNo to speedily insert <code><nowiki>...</nowiki><code> markup

For your coding pleasure, try out {{subst:CoNo|1=your code here}}.

This has been a bit of a wiki-Grail of mine for years, because I hate manually typing out "<code><nowiki>...</nowiki><code>" all the time. {{CoNo}} stands on the shoulders of the giant Zenexer, whose {{Nowiki}} finally makes this work.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  23:30, 18 October 2014 (UTC)

Glad to see my coding hacks put to good use! I wish I could remember who taught me the trick that I used, but it was a long time ago. —Zenexer [talk] 00:07, 19 October 2014 (UTC)

Not to take anything away from anyone here but isn't simple stuff like this the reason User:s can add there own toolbar of useful/repetitive "inserts" using the CharInsert gadget via one's common.js file? Once in place there is no need to type anything - just highlight the target text and select the tags from your custom menu of stuff.

For example; if you add the following to your common.js file....

/* CharInsert specific */
window.charinsertDontMove = false;
window.editToolsRecall = true;
window.charinsertCustom = { User: ' |  =  {\{+}}  [\[+|]]  —  Æ  æ  Œ  œ  <code><nowiki>+</nowiki></code>  {\{ping|+}}' };
if(window.updateEditTools) window.updateEditTools();

... A new menu labeled "User" containing your custom inserts will appear in the menu of CharInsert (EditTools). Hope that made sense -- George Orwell III (talk) 00:38, 19 October 2014 (UTC)

There is a suggestion at MediaWiki talk:Edittools#Individual customization? to add it for everybody like meta already does. PrimeHunter (talk) 00:47, 19 October 2014 (UTC)

This doesn't actually work. For example, {{subst:CoNo|~~~~}} generates a nowiki'd version of my signature wrapped in <code> tags, rather than 4 ~s. For this functionality to work, it would have to be done in JavaScript in the edit window, rather than in the parser. Jackmcbarn (talk) 03:27, 19 October 2014 (UTC)

Inserting <code><nowiki></nowiki></code> can already be done - but in two clicks, not one. Make sure the dropdown menu below the edit box set to "Wiki markup" rather than "Insert"; I never leave mine on "Insert", because everything in there is also available in "Wiki markup". --Redrose64 (talk) 07:30, 19 October 2014 (UTC)

Some of our sister projects have a single button for this; could we not do so also? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:35, 19 October 2014 (UTC)

Login problems on IE9 Vista

I'm currently having problems logging into my account using Internet Explorer 9 on Windows Vista. I'm having no problems using this wiki when not logged in, but when attempting to log in, I get a "Internet Explorer cannot display the webpage" error; any attempt to refresh quickly regenerates the error screen, as if it's not even trying to load the login screen. I really prefer to be logged into my account whenever possible, so it is possible to do something about this issue? Thanks. --76.92.210.183 (talk) 00:09, 19 October 2014 (UTC)

Found out what was wrong. I didn't have a specific value turned on--I had "Use TLS 1.0" off when it should have been on ("Use SSL 2.0" and "Use SSL 3.0" were already on, anybody else who's going through what I went through might want to check those as well). Shouldn't have a problem logging on now...--76.92.210.183 (talk) 06:10, 19 October 2014 (UTC)

You were using SSL 3.0? See #SSL 3.0 discontinued, above. ~ J. Johnson (JJ) (talk) 20:44, 19 October 2014 (UTC)

Custom CSS

"Code that you insert on this page could contain malicious content capable of compromising your account. If you are unsure whether code you are adding to this page is safe, you can ask at the appropriate . The code will be executed when previewing this page."

This is shown when I preview the CSS page. "you can ask at the appropriate ." seems to be unintended and something is missing. I post here to make you aware of it in case you want to change it. Iceblock (talk) 01:06, 19 October 2014 (UTC)

I see MediaWiki:Jswarning which says "Code that you insert on this page could contain malicious content capable of compromising your account. If you are unsure whether code you are adding to this page is safe, you can ask at the appropriate village pump". The text "village pump" is a link to this page, but it displays bold here instead because it's a link to the page itself. Are you sure you have nothing after "appropriate"? If you see a large space but cannot make out any text then it may be a textcolor versus background color problem on your computer. Try holding your mouse over the space. And did you copy-paste the text with your browser or retype it manually? PrimeHunter (talk) 01:24, 19 October 2014 (UTC)

Thanks for your reply! It's my fault, it was hidden because of some settings on my computer. I have resolved it. Iceblock (talk) 01:43, 19 October 2014 (UTC)

Checking custom tables of contents

Does anybody know of an automated or partially automated way to check the accuracy of the table of contents on pages like List of birds of French Guiana? I've been checking them by clicking on each heading to see if it has a target, then generating a normal table of contents and visually comparing it to the list to see if any headings have been missed. It is tedious and there are hundreds of articles in the series List of birds of ... which I'm hoping to clean up. SchreiberBike talk 03:40, 19 October 2014 (UTC)

Page in "edit" mode is broken

Page in "edit" mode is broken, left side navigation bar is pushed down, no WP logo. --Tito☸Dutta 23:22, 19 October 2014 (UTC) Here is a screenshot (use "zoom") --Tito☸Dutta 23:27, 19 October 2014 (UTC)

Have you tried to clear your entire cache? PrimeHunter (talk) 02:52, 20 October 2014 (UTC)

Creating a Help article

I would like to create an article named Help:Automatically generated reference list, and copy into it the information in this draft page, per the discussion at Help talk:Footnotes. But whenever I search for the not-yet-existing new page, I get "An error has occurred while searching: The search backend returned an error:". Does creating a page in the Help namespace require some kind of administrator privileges? – Margin1522 (talk) 02:32, 20 October 2014 (UTC)

@Margin1522: Nope, this looks like a search bug rather than a page creation bug. If you click on the link you've made above you should be able to create the page. — Mr. Stradivarius ^{♪ talk ♪} 02:47, 20 October 2014 (UTC)

Yes, this has unfortunately become a common error for the default search engine. At Special:Preferences#mw-prefsection-betafeatures you can choose "New search" which doesn't have the problem. Clicking the red link also works fine. PrimeHunter (talk) 02:50, 20 October 2014 (UTC)

Success! Thank you both very much. Now I will go and select the new search engine. – Margin1522 (talk) 03:10, 20 October 2014 (UTC)

Another time, it would be more appropriate to WP:MOVE the draft to the new location. Doing so preserves the edit history, which is what is used to attribute the work and comply with the licensing model which Wikipedia uses. Even though it is (mostly) your work (there is one edit of the draft by BattyBot), preserving the edit history is one of the things that demonstrates that it is the work of the people credited in the history. Having a history that shows the development of the content is much stronger than having a fully formed version appearing in a first edit. — Makyen (talk) 06:05, 20 October 2014 (UTC)

Actually most of the content on that page was developed on the Help:Footnotes page. I just expanded it a bit and added some formatting and examples. I should have mentioned that in the edit summary. Now that you've reminded me, I will mention it on the Talk page of the new article. (The rest of the history on the draft page, including BattyBot, is for a completely different article, Bettina von Zwehl, which is why I copied it instead of moving it.) – Margin1522 (talk) 07:58, 20 October 2014 (UTC)

@Margin1522: If you made the new page by copying text from another page, WP:SPLIT applies and attribution is still required. --Redrose64 (talk) 15:13, 20 October 2014 (UTC)

Tech News: 2014-43

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. You can read translations.

Recent changes

• You can test a new system to see math using MathML. Go to your display options and choose "⧼mw math mathml⧽".
• You can add badges in Wikidata for quality articles and featured lists. [15] [16]

File information cleanup

• You can join a wiki project to help tools read file information. It will help people reuse files.
• See how to fix metadata. You can fix it by adding markers to templates and adding templates to files.
• You can see a list of files missing machine-readable information on your wiki.
• The files missing readable data are also in these categories: no license, no description, no author or no source. [17]

Problems

• Developers fixed a security problem. If you use Internet Explorer 6, you won't be able to log in any more. You should use a newer browser. [18]

Changes this week

• The new version of MediaWiki (1.25wmf4) has been on test wikis and MediaWiki.org since October 16. It will be on non-Wikipedia wikis from October 21, and on all Wikipedias from October 23 (calendar).
• 10% of logged-out readers are getting pages from servers that run the HHVM tool. HHVM should make pages load faster. You can also test it as a Beta Feature. [19]
• If you add the same parameter twice in a template, it now puts the page in a tracking category. [20] [21]

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

13:48, 20 October 2014 (UTC)

External link CAPTCHA, PMID, and protocol-relative URL

If an anonymous editor adds an external link to a page, a CAPTCHA interface is normally triggered, this is to protect against spambots. In 2012, I suggested a whitelist for links that are never going to be used for spam. This was implemented in 2013, and is at MediaWiki:Captcha-addurl-whitelist.

One of the items on the list is nih.gov, which houses PubMed, and is linked to in Template:Cite journal when a PMID number is provided, and in Template:PMID. In the latter template (and I assume in the former as well), the link is in protocol-relative form, i.e. like so: //www.ncbi.nlm.nih.gov/pubmed/15988469. For me, this triggers the CAPTCHA interface, whereas http://www.ncbi.nlm.nih.gov/pubmed/15988469 does not. Is there any way to allow protocol-relative URLs in the whitelist? Or can anyone think of another way of remedying this in the templates? 137.43.188.126 (talk) 15:36, 20 October 2014 (UTC)