Wikipedia

Wikipedia:Village pump (technical)/Archive 127

< Wikipedia:Village pump (technical)
Village pump (technical) archive  

This page contains discussions that have been archived from Village pump (technical). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.

< Older discussions · Archives: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR, AS, AT, AU, AV, AW, AX · 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 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

Archive bots

LowercaseSigma bot seems down, is there any other bot that does what it does? Also any bot that archives on demand? Living in the Stone Age. All the best: Rich Farmbrough, 23:14, 2 June 2014 (UTC).

(Note:CluebotIII (which was recently blocked for a long time, for the most ludicrous reason) does not do what LCS bot does) All the best: Rich Farmbrough, 23:15, 2 June 2014 (UTC).
  • Have you tried pinging Σ to see if he can get it restarted? — {{U|Technical 13}} (e • t • c) 23:34, 2 June 2014 (UTC)
The most recent edit made by lowercase sigmabot III (lcSB3) was a about 54 hours ago. While that is longer than expected, it is not all that long ago. Given that short time, it is possible there are other issues causing whatever symptom resulted in your concern over lcSB3 not being operational. If you provide the name of the page on which you are experiencing the problem, we can look into it in case it is specific to that page. Another time, reporting issues at the User talk:lowercase sigmabot III page might reach a more targeted audience. — Makyen (talk) 04:07, 3 June 2014 (UTC)
The bot is running again and has even archived Rich's talk page. -- John of Reading (talk) 06:48, 3 June 2014 (UTC)
Good. Damn thing takes 24 hours to come around, even when it is working. (I'm still grateful to Σ, for running the bot, of course.) All the best: Rich Farmbrough, 16:09, 3 June 2014 (UTC).
Have you looked at this one click archiver? Ravensfire (talk) 18:12, 3 June 2014 (UTC)

Cannot open a page

I can't open MediaWiki talk:Titleblacklist on my browser, no idea why. The following link works: [1] but not without the oldid. Perhaps some temporary glitch? — Martin (MSGJ · talk) 13:16, 3 June 2014 (UTC)

  • I'm not having any troubles with it. What exactly is happening? Timeout? 404? Some other error? Anything in the error console? — {{U|Technical 13}} (e • t • c) 13:26, 3 June 2014 (UTC)
    Doesn't give any error. Just doesn't open. I can open this link [2] but not this link [3]. Works on IE but not on Firefox (22.0). — Martin (MSGJ · talk) 13:32, 3 June 2014 (UTC)
  • No idea, all I can suggest is to clear out your cookies and cache and see if it still happens. You may need to close your browser and reopen. — {{U|Technical 13}} (e • t • c) 13:38, 3 June 2014 (UTC)
No problems here on Firefox 29... — Mr. Stradivarius ♪ talk ♪ 13:45, 3 June 2014 (UTC)

IRC recent changes feed down

Huggle can't connect to the IRC recent changes feeds, and ClueBot NG isn't making any edits (since it draws from the IRC feeds). Neither is STiki able to find new edits. Any news on this? --k6ka (talk | contribs) 16:43, 3 June 2014 (UTC)

ClueBot NG appears to still be editing despite the loss of the IRC feed, but it's still a big problem for Huggle, since the API queries are slower than the IRC feed. Does anyone know what happened? Novusuna talk 17:49, 3 June 2014 (UTC)
The RC feed is up. Werieth (talk) 17:59, 3 June 2014 (UTC)
CBNG was down briefly during the outage, but mysteriously got back up while the IRC feeds were down. Perhaps it's a new feature that allows CBNG to automatically switch to API queries if it cannot access the IRC feed? If it is, it's pretty slow. --k6ka (talk | contribs) 19:57, 3 June 2014 (UTC)

Errant bot

After alerting a bot owner about problems their bot is creating, and after receiving no response and finding no evidence of the problem being fixed, how long should an editor wait before raising the issue elsewhere, and where should the issue be raised? -- 91.85.32.197 (talk) 17:29, 3 June 2014 (UTC)

What bot specifically? Jackmcbarn (talk) 17:32, 3 June 2014 (UTC)
See this for the first alert. -- 91.85.32.197 (talk) 17:38, 3 June 2014 (UTC)
Problem #3 you mention isn't really the bot's fault. If either of the first 2 problems reoccur, I'd go to WP:ANI or WT:BRFA. Jackmcbarn (talk) 17:48, 3 June 2014 (UTC)
Thanks for the info. They have happened again in various places on several occasions since. -- 91.85.32.197 (talk) 17:52, 3 June 2014 (UTC)
Well, despite being intended to run at the beginning of every month, the bot doesn't seem to have edited since April 1, which means it has missed 2 runs; perhaps it's just not being run any more? Since it's not currently editing, there's nothing that needs to be done. Writ Keeper ⚇♔ 18:06, 3 June 2014 (UTC)
Disagreeing, I've blocked the bot. "Not editing, so no need for a block" is good advice regarding a human editor, since humans change from time to time, but without coding fixes by the operator, the bot will keep on making messes if it's reactivated — we can't tolerate a bot that's malfunctioning so egregiously. OsamaK, the operator, will presumably understand that the block isn't a comment on him, and the bot won't care, so we lose nothing by having the bot temporarily blocked, and we avoid having some articles converted into chaos if the bot returns. By the way, WP:ANI is the best place to report a bot that's not operating in accordance with an approved plan, whether because it's malfunctioning or because it was never approved in the first place. Nyttend (talk) 23:43, 3 June 2014 (UTC)

Request for Comments (RFC) notice

There is a Request for Comments (RFC) at Help talk:Citation Style 1/Archive 5#RFC: Citation Style 1 parameter naming convention proposing that a naming convention be institued for Citation Style 1 parameter names. Please add your comments there if you are interested in participating in the discussion. Thanks!—D'Ranged 1 VTalk 20:09, 3 June 2014 (UTC)

Media Viewer just launched on the English Wikipedia

 
Media Viewer lets you see images in larger size

Greetings! As discussed in our earlier posts, Media Viewer has now been enabled by default on the English Wikipedia, to provide a better viewing experience for our users.

This new multimedia browser displays images in larger size when you click on their thumbnails, as an overlay on the current page. To reduce visual clutter, all information is shown below the image, and can be expanded at a click of a button. Usability studies suggest that Media Viewer provides a richer multimedia experience, right where people expect it. They tell us they can see the images more clearly, without having to jump to separate pages -- and that the interface is more intuitive, offering easy access to images and metadata.

Media Viewer has been tested extensively on many large wikis around the world, and the feedback collected from thousands of users suggests that this tool is generally useful to them, as outlined in these survey results. More importantly, the rate of favorable feedback keeps increasing across all languages over time, which is very encouraging. Here on the English Wikipedia, over 15,000 beta users have been testing it, since the tool was first deployed as a beta feature in November 2013. Thanks to all this helpful feedback, Media Viewer has been greatly improved in recent months, and is being rolled out on all wikis worldwide, as described in this release plan.

If you do not enjoy Media Viewer, you can easily disable this tool in your preferences: uncheck 'Enable Media Viewer' in the Files section, under the Appearances tab. Learn more in this Media Viewer Help page.

Please let us know if you have any questions or comments about Media Viewer. You are invited to share your feedback in this discussion on the English Wikipedia, to help improve this feature. You're also welcome to take this quick survey -- or join this in-depth discussion on MediaWiki.org, as you prefer.

Many thanks to all the community members who helped make Media Viewer possible! This tool was created with active community participation from its early planning phase -- all the way to its final release. This has been an exceptionally productive partnership, which we hope to build on for future projects. Fabrice Florin (WMF) (talk) 21:28, 3 June 2014 (UTC)

I've been using it for a while now; it's been a pretty neat tool. The only thing I don't like is that I can't just go to Wikipedia's (not Commons's) actual file page directly. I know there is an option in the lower right to go to the relevant file page, but since most files are on Wikimedia Commons, there is not usually a direct link to Wikipedia's page on the file. The tool is still alright, though. Dustin (talk) 21:35, 3 June 2014 (UTC)
Take the above file; say I wanted to go to Wikipedia's page describing the file at File:Media_Viewer_Desktop_-_Large_Image_Opaque_Info.png; well, when you are using Media Viewer, there is a link, but it is to the Commons page (commons:File:Media_Viewer_Desktop_-_Large_Image_Opaque_Info.png). I have some reasons for which I would sometimes prefer to see the Wikipedia file page. Dustin (talk) 21:38, 3 June 2014 (UTC)
Sure sure, good points Dustin. Hearing about workflows will help us make Media Viewer even more accessible in the next go-round. Keegan (WMF) (talk) 21:54, 3 June 2014 (UTC)
I love being able to go straight to the Commons description page. I never want the local one, because what I'm seeking is almost always the list of categories used on Commons. WhatamIdoing (talk) 21:57, 3 June 2014 (UTC)
@WhatamIdoing: That was possible before. Preferences → Gadgets and enable "Redirect image links to Commons for files hosted there". --Redrose64 (talk) 23:02, 3 June 2014 (UTC)
  • I find this thing a serious impediment. It just prevented me from seeing whether an image had been protected. I see at the Mediawiki feedback page that it is possible to opt out of it. Please, how? Yngvadottir (talk) 21:46, 3 June 2014 (UTC)
    • Uncheck "Enable Media Viewer" in the files section under the Appearance tab of your preferences. Dustin (talk) 21:51, 3 June 2014 (UTC)
  • 1) Is there a/what is the plan to integrate/harmonize video playing into media viewer? Visual consistency between the images and video would be nice. 2) I appreciate the direct link to the file description page (most power users want that, while most readers might want a flashy thing like media viewer). A link to the local page could also be useful, though that isn't usually my workflow. 3) The current version looks a little better than I remember it being earlier (maybe it's less black space). Chris857 (talk) 03:05, 4 June 2014 (UTC)
    • @Chris857: There is a link to the Commons page below, or, if the file is only on Wikipedia, to the Wikipedia description page. My preference would be for Media Viewer to be changed to include links to both the Commons and the Wikipedia version when the file is on Commons. Dustin (talk) 03:25, 4 June 2014 (UTC)

I love it. Thanks. --Anthonyhcole (talk · contribs · email) 05:35, 4 June 2014 (UTC)

Images

When I left-click an image, instead of getting at the ususal file description page, I am transported in a bizarre, black background place, where the image is not well-focused in the beginning, and then it shows up in the middle of the page (instead of the left) a little zoomed. Luckily, when I middle-click it, it appears in the right form. Can anything be done, or is this condition permanent?--85.74.125.119 (talk) 22:37, 3 June 2014 (UTC)

Read the section directly above this one; this is a new feature. You can opt out of it; that information is given in the post above.—D'Ranged 1 VTalk 22:40, 3 June 2014 (UTC)
You can opt out if you make an account! Johnuniq (talk) 00:26, 4 June 2014 (UTC)
"One of the benefits of making an account: you don't have to put up with the junk that WMF imposes on you!" Can someone remind me why we keep donating to an organisation that doesn't care about us? Nyttend (talk) 00:41, 4 June 2014 (UTC)
{{Citation needed}} for that quote, please. Nyttend, I hardly consider you not liking something to translate into the Wikimedia Foundation not caring about its contributors. Massive piles of feedback and requests for this feature came from community members- cross-project- as well as readers. You, specifically, might not have asked for it, but that does not make it any less valuable of a tool for everyone else. Let's bring the rhetoric down a touch and see how we can further develop Media Viewer. Keegan (WMF) (talk) 01:10, 4 June 2014 (UTC)
This is my own quote. You impose something on us, objections get pooh-poohed as "rhetoric", and you put words in my mouth. After you learn to stop affirming the consequent, go read the statements up above about how this gets in people's way when they're attempting to gain information about files: your actions are causing problems, despite all your claims of their value. Comments in earlier sections (e.g. "Infobox Image") regarding the image-size mess, such as Aschmidt on 23:00, 31 May 2014 (UTC), are particularly relevant. Nyttend (talk) 01:48, 4 June 2014 (UTC)
The Media Viewer team (which I'm not part of, and which additionally had nothing to do with the image-size issue) has been running surveys on this, and I've seen the results. It's getting about 70% approval, with some variation by language edition, but in all cases with the numbers slowly climbing higher each week after deployment. That suggests that most people would disagree with your view that it's "junk" and proof of "not caring about us", especially after they've had a few days to get familiar with it. Survey responses from readers are more positive than from technically minded editors (like you and me).
Additionally, I believe that most of the donors aren't experienced editors. There are thousands of donors who appear to have never made a single edit. The Wikimedia Foundation's finances appear to be largely supported by readers or occasional editors (or perhaps former editors; I like to hope that people who edited in the past still have fond memories of this place), rather than by the core of active editors who keep the encyclopedia project going on a day-to-day basis. Whatamidoing (WMF) (talk) 02:03, 4 June 2014 (UTC)
And how come I am in the happy state of NOT having the Visual Editor imposed on me, but the policy differs for Media Viewer?--85.74.125.119 (talk) 02:16, 4 June 2014 (UTC)
And why are you asking questions that will never receive an actual answer (I am not taking a side in saying this)? This stuff has already been discussed. Dustin (talk) 04:23, 4 June 2014 (UTC)

Cannot undelete

Tracked in Phabricator
Task T45911

I am trying to undelete the revisions of Denise Donnelly from 17 April 2014 all the way back to 13 March 2004. I select those revisions and click "Restore," but it takes me to https://en.wikipedia.org/w/index.php?title=Special:Undelete&action=submit which says "Search deleted pages" at the top (as opposed to a confirmation page), and does not perform the restoration. Can someone else try performing the restoration? -- King of ♥ ♦ ♣ ♠ 00:20, 4 June 2014 (UTC)

Maybe you're doing too many? I tried to do a few hundred, but it did as you said. Restoring just one, on the other hand, worked fine. Let's hope we don't need to do hundreds and hundreds of separate restore actions...Nyttend (talk) 00:37, 4 June 2014 (UTC)
Well, guess it worked, thanks! By the way, is there currently a Bugzilla for this? If not I'm going to file one. -- King of ♥ ♦ ♣ ♠ 00:44, 4 June 2014 (UTC)
I've done larger undeletions than this in the past, but I've not had this kind of problem, so I doubt that it's a simple bug — probably a hiccupping server. Nyttend (talk) 00:46, 4 June 2014 (UTC)
This is bug 43911. Another way to get around this problem is to move the revisions you don't want to undelete to a temporary subpage, then undelete all the other revisions by not checking any boxes, like this. Graham87 02:49, 4 June 2014 (UTC)

sigma/created not working

I just clicked on "Articles created" at the bottom of my contributions page and got:

No webservice

The URI you have requested, /sigma/created.py?name=Anthonyhcole&server=enwiki&ns=,,&redirects=none, is not currently serviced. If you have reached this page from somewhere else...

This URI is part of the sigma tool, maintained by Σ.

Anthonyhcole (talk · contribs · email) 05:31, 4 June 2014 (UTC)

So this is about a tool on https://tools.wmflabs.org/sigma/. Did you contact its author? --AKlapper (WMF) (talk) 10:11, 4 June 2014 (UTC)

Problem with edit window

When I click "Edit" and get to the edit window, many times (but not always) the first few lines are not visible, and I am not able to take the cursor to the top of the text. I have been experiencing this problem for several days.

At first I thought there may be something wrong with ProveIt, but when I disabled this gadget, the same thing is happening.

Is this a problem for anyone else, or just me?- Gilliam (talk) 06:50, 4 June 2014 (UTC)

@Gilliam: This might be the same as Wikipedia:Village pump (technical)/Archive 126#Edit window annoyance. --Redrose64 (talk) 09:38, 4 June 2014 (UTC)
Thanks! Pressing the 'Advanced' tab solved it.- Gilliam (talk) 12:39, 4 June 2014 (UTC)

Reminder: Tools only on Tool Labs from July 1

About one year ago, we, Wikimedia Deutschland e. V., announced June 30th as the deadline of the Toolserver migration (Roadmap). This deadline is approaching. The Toolserver will stop working on June 30th. What will happen afterwards?

Background information

The Toolserver is a community based infrastructure that hosts software supporting Wikipedia and its sister projects. Over the years many active volunteers have developed helpful and great software tools that are running on several Wikimedia projects. The Toolserver is operated by Wikimedia Deutschland with assistance from the Wikimedia Foundation and several chapters. For many reasons, the Toolserver will be discontinued and replaced by Tool Labs, a platform operated by the Wikimedia Foundation. Please see the reasons here: https://toolserver.org. For more than one year Wikimedia Deutschland has been coordinating the migration of software tools from Toolserver to Tool Labs.

What editors should know

The toolserver is a community-driven project. The tools shall be migrated by the developers resp. maintainers themselves. Many of them have already migrated their tools or have indicated that they will do so before the end of this month. We have a special agreement with the OpenStreetMap projects and with the developer of MerlBot to ensure these tools don’t stop working. All other tools will stop working by July 1st.

What editors can do

  • On Tool Labs, you can look up if the tools that you use and need have already moved there.
  • Talk to the developers of your favourite tools: It is important to let them know how much you appreciate their tools and that you need them to do your work.
  • Contact us if you don’t know who these developers are or if you have any questions or if you want us to forward wishes or requests to tool developers. Contact information is given at the end of this text.

Information for tool developers

If you are still facing the migration of your tools, please keep in mind that lots of people use your tools. They are a great support for their daily work and will be missed when they fail. Please take the time to migrate them or poke us: WMDE can still support you during migration - what we can’t do is maintain abandoned tools in the long run. From July 1st on, the toolserver admins will still hand you over your backups upon request and create redirects to Tool Labs for you. You won’t be able to log in to the toolserver anymore though. If anyone wants to have and reuse other people’s code, we recommend to seek approval from them directly, even if from a legal point of view there is no problem. Don’t hesitate to talk to us if you need a contact person.

Here is a collection of the relevant links for you again:

We invite you to join our IRC office hour in #wikimedia-office on Wednesday, June 11th, at 5 p.m. UTC.

Contact

The migration is coordinated by Silke Meyer (WMDE). Birgit Müller supports her in communications. The two toolserver admins Marlen Caemmerer und Alexander Mette are glad to help you with advice. Marc-André Pelletier can answer all questions concerning Tool Labs. Contact us at

We hope that the transition will happen as smoothly as possible! Silke WMDE (talk) 08:32, 4 June 2014 (UTC)

Duplicated article

Hi, can someone mark ...And Some Were Human for deletion as it is a duplicate of ... And Some Were Human. I have copied extra info into the latter so the former can now be deleted (or at least marked for deletion) but I'm not sure how... I beleive the remaining article ought then be renamed to ...And Some Were Human which I beleive is the actual title of the book in question, thanks GrahamHardy (talk) 14:16, 4 June 2014 (UTC)

Update: I've started a requested move on the talk page, but I request it moved to "...and some were human." as that is what the actual book title appears to be looking at the cover. — {{U|Technical 13}} (e • t • c) 15:21, 4 June 2014 (UTC)

What ?

Why am I getting notifications about my edit being reverted when in fact this is my edit quite confusing. Or am I not reading the notification correctly. Mlpearc (open channel) 16:53, 4 June 2014 (UTC)

If one revert operates on two or more consecutive edits, each of the users who made those reverted edits is notified. --Redrose64 (talk) 16:57, 4 June 2014 (UTC)
That makes sense (I think). Thank you Mlpearc (open channel) 17:47, 4 June 2014 (UTC)

Four-column infoboxes?

I'm aware of {{infobox3cols}} which allows formatting of infoboxes in three columns, rather than the standard two. But are there any infoboxes out there that use four columns or more? (There is no Template:Infobox4cols, so they would have to be custom-made.) The reason I ask is because I have been looking at the new mw:Extension:Capiunto, and thinking of possible useful features for it. (Capiunto is a framework for converting infobox templates to Lua.) I imagine that there are some pretty strange infobox templates out there, and some of those we will probably need to convert using custom Lua modules. However, in general, the more infoboxes that can be converted using Capiunto, the better. So if there are infobox features that you would like to see in Capiunto, then now would be a good time to make them known. — Mr. Stradivarius ♪ talk ♪ 11:48, 2 June 2014 (UTC)

{{infobox3cols}} despite its name, outputs four columns in total: for each row, there are either one cell having colspan=4; two cells (the second one having colspan=3) or four. At Teddy Sheringham, for example, the four columns are headed "Years"; "Team"; "Apps†"; "(Gls)†". --Redrose64 (talk) 12:35, 2 June 2014 (UTC)
Good point, I hadn't realised that. So, we have four-column infoboxes - is anyone aware of a five-column one? — Mr. Stradivarius ♪ talk ♪ 14:48, 2 June 2014 (UTC)
Mr. Stradivarius, if you're interested in converting "some pretty strange infobox templates", may I suggest that {{Infobox ship}} and related pieces be high on your list? It's a series of subtemplates that has to be manually wrapped inside table formatting. There's more information at Wikipedia talk:WikiProject Ships/Archive 40#Infobox_ship_begin. WhatamIdoing (talk) 19:04, 2 June 2014 (UTC)
@Mr. Stradivarius: maybe Special:MostLinkedTemplates would be a good place to search some infoboxes to convert to Lua? --Edgars2007 (talk/contribs) 16:00, 5 June 2014 (UTC)
The point of this thread isn't just to convert infoboxes, it's to make sure that mw:Extension:Capiunto can handle converting as many infoboxes as possible. — Mr. Stradivarius ♪ talk ♪ 22:03, 5 June 2014 (UTC)

What's going on with WikEd, the edit window and Reftoolbar 2.0?

Just started happening, and was not happening a couple of hours ago. WikEd is involved. If I try to edit as usual with WikEd installed, text in the edit window is splayed outside the borders of the edit window, as a transparancy overlay on the rest of the page. I can type in a blank edit page, but part of the bottom portion of the Reftoolbar displays briefly and then disappears entirely. It will not allow me to "Save Page" or "Preview". Right now, I have WikEd turned off in order to do this post. However, not all of the Reftoolbar is showing. What's going on all of a sudden? NoScript was disabled, so that was not the conflict. Windows 8 Firefox 32.0 — Maile (talk) 18:42, 5 June 2014 (UTC)

Getting no answer here, I also posted over at User talk:Cacycle/wikEd. — Maile (talk) 22:22, 5 June 2014 (UTC)

Fixing initial case

I'm trying to fix the article on the band iVardensphere to have the correct lower case initial letter in the title (it is already correct in the lead but currently the article is incorrectly titled IVardensphere). But a simple move complains that the destination is the same as the source.... Is there something I'm missing, or does this need an admin to fix? If so could someone fix it - if it isn't clear enough from the lead that this is correct then see www.ivardensphere.com for confirmation that it should be a small 'i'

Roybadami (talk) 21:49, 5 June 2014 (UTC)

@Roybadami: You can't move IVardensphere to iVardensphere because they are the same - all Wikipedia page names are case-insensitive on first letter, and by default are displayed with a capital letter, see WP:NCTR. What you need to use is the same technique that an article like eBay uses, which is {{lowercase title}}, like this. --Redrose64 (talk) 21:59, 5 June 2014 (UTC)
Ah thank you! I remember the days when lower case titles were impossible - and then it was fixed. But I never needed to look into how it was fixed before today - I just assumed (incorrectly) that the old rule about initial letters had been removed. Roybadami (talk) 22:06, 5 June 2014 (UTC)

Infobox Image

Suddenly the infobox images all over Wikipedia are appearing shorter in size and width, without any changes in their size in infobox. Why?--Jockzain (talk) 21:05, 29 May 2014 (UTC)

Does "suddenly" mean "only in the last hour or so, while the site is experiencing some significant performance problems" (see the two previous sections)? WhatamIdoing (talk) 21:13, 29 May 2014 (UTC)
Yes this error occur in the last hour or so, another thing which I found that images in Infobox film festival and Infobox book are fine only the images in Infobox person and Infobox film are screwed up.--Jockzain (talk) 21:19, 29 May 2014 (UTC)
Good: Infobox News event / musical artist / NRHP / settlement / film festival / book / hospital / venue / person / song / country / university / non-profit / engineer / bridge / park / French commune / officeholder / museum / building
Bad: Infobox film /
BMK (talk) 22:27, 29 May 2014 (UTC)
I think that the variation between infoboxes is down to whether their default width is a pixel count (those shown as "good") or as frameless (those shown as "bad"). The width of a frameless image should be the same as a thumb image. --Redrose64 (talk) 22:34, 29 May 2014 (UTC)
Infobox person without imagesize were also appearing bad like at Kate Winslet but after adding it become same as everyone. But it is not working at Infobox film.--Jockzain (talk) 22:48, 29 May 2014 (UTC)
Except for the flakiness of Infobox person, I can't find an infobox other than infobox film which is exhibiting this behavior. BMK (talk) 00:25, 30 May 2014 (UTC)

How long is this change going to last? I much prefer the images to be bigger in the infoboxes! What is the probability that it will go back to what it was?! Infobox person is not good as every picture in every infobox on pages for people has been reduced in size.Nick B 1993 (talk) 01:44, 30 May 2014 (UTC)

  • ‎Mr. Stradivarius, could this be related to the new Module:Image you created? Betty Logan has found that images appear to be being forced to 220px on the longest side, resulting in wonky images throughout. — Crisco 1492 (talk) 02:26, 30 May 2014 (UTC)
    Nope, that module isn't used anywhere yet. But thanks for the advert. :) — Mr. Stradivarius ♪ talk ♪ 02:32, 30 May 2014 (UTC)
    Alright. — Crisco 1492 (talk) 02:36, 30 May 2014 (UTC)
  • I'm thinking this may be related to a module, or something that affects images in many places (Red Skelton's infobox is having issues if we don't force the size, as are almost all the film articles with infoboxes, and even some articles without infoboxes) but I couldn't see anything in recent changes that could explain this. This appears most prominent in images which are considerably taller than they are wide. — Crisco 1492 (talk) 02:36, 30 May 2014 (UTC)

Please see Template talk:Infobox film#Another temporary revert request. When the recent edit which eliminated the "image_size" parameter from the film infobox template was undone, film infoboxes which specified the image size with "image_size=X" displayed properly, while any film infobox which did not specify the size had the small image (about 150px). Specifying the image size brought the image to the proper size. So, something has changed, since the "image_size"parameter was removed on March 21, and there hasn't been a problem until today. Something upstream of the infobox template - a module? - seems to be interacting with the template to screw up the default size. BMK (talk) 04:18, 30 May 2014 (UTC)

This is probably caused by something in yesterday's rollout of MediaWiki 1.24/wmf6. To me, the most likely culprit looks like the fix for bugzilla:63903, "Use square bounding boxes for default-sized thumbnails". See the full commit message for a detailed rationale. — Mr. Stradivarius ♪ talk ♪ 04:22, 30 May 2014 (UTC)
Great, now they expect us to go around 'manually' adding 220px image size parameter to all infoboxes affected which may be over 5000...there was never any need to make this change in the first place...--Stemoc (talk) 04:36, 30 May 2014 (UTC)
  • This is broken. The WMF should roll that back right quickly. They kinda went too far in the opposite direction. — Crisco 1492 (talk) 04:37, 30 May 2014 (UTC)
  • It would better if editors didn't manually fix the size, for two reasons:
  1. Hardcoding the size overrides browser settings i.e. someone on a lower resolution who has purposefully set a lower default image size could end up with an image monopolising the screen, because hardcoding an image size overrides the browser's settings.
  2. We can manually add a scaling factor to the infobox itself. As you can see at [4], adding a scaling factor solves the problem and has the added benefit of not overriding browser settings. Basically all we have to do is add one line of code to the infobox template and the problem is fixed. Obviously this doesn't address the problem in the case of images outside the infobox.
Betty Logan (talk) 06:06, 30 May 2014 (UTC)
We can still use "Upright" outside of infoboxes, and I don't know why the documentation for infobox templates doesn't recommend using that instead of hard coded pixels. Odd how upright=1 fixes this problem.  — Crisco 1492 (talk) 08:25, 30 May 2014 (UTC)
The fact that upright=1 fixes the problem is itself a misfeature which is scheduled to be fixed. I don't recommend using upright to fix this issue, it is just pushing the problem down the road. (That is, upright will shortly scale the same size as thumb uses, instead of being width-based.) It is best to use an explicit width bound, if the infobox expects a given image width. C. Scott Ananian (talk) 21:09, 30 May 2014 (UTC)
Which has the minor setback of being against the MOS on the English Wikipedia. There've been edit wars over this, and the WMF is coming in both fists flying? — Crisco 1492 (talk) 13:39, 31 May 2014 (UTC)
The lead section is one of those places where a forced image size is permissible, see MOS:IMAGES#Size and WP:IMGSIZE. --Redrose64 (talk) 15:36, 31 May 2014 (UTC)
  • None of these are forced image sizes (i.e. hardcoded ones), but "upright"... and even between upright and no parameters, there've been edit wars. — Crisco 1492 (talk) 05:11, 1 June 2014 (UTC)

Is WMF taking action on this? Hardcoding widths on hundreds of thousands of infoboxes is... stupid. --NeilN talk to me 12:31, 30 May 2014 (UTC)

If nothing can be done, then doing this is better than leaving them like that for ever.--The Theosophist (talk) 13:21, 30 May 2014 (UTC)
Frietjes has tweaked one infobox [5]. After manually purging the cache of an article, the proper infobox image size was restored. --NeilN talk to me 13:48, 30 May 2014 (UTC)
  • That does jack for images which are not in infoboxes and still affected — Crisco 1492 (talk) 14:28, 30 May 2014 (UTC)

The problem is nothing to do with infoboxes, modules, templates or anything else that we have control over. See User:Redrose64/Sandbox14 where the four images use the normal syntax like [[File:Noimage.svg|thumb]] and as may be seen, the height of the two vertical images is the same as the width of the two horizontal images. What I believe has happened is that the processing for "thumb" and "frameless" images (see WP:EIS) has changed for those images that are taller than they are wide. The previous behaviour of thumb/frameless was to set the image width to that specified by the "Thumbnail size:" setting in Preferences → Appearance; it seems that the new behaviour of thumb/frameless is to set the image's larger dimension to that specified by the "Thumbnail size:" setting in Preferences → Appearance. This is why only portrait-format images are different; for landscape-format and square images, the width is the larger dimension. --Redrose64 (talk) 14:24, 30 May 2014 (UTC)

  • Thanks for putting it more simply. (It was explained in the link Mr. Stradivarius gave, but in more technical language). — Crisco 1492 (talk) 14:28, 30 May 2014 (UTC)

Brill! So adding "|upright=1.0" immediately after the file name is all that need be done in order to restore images in infoboxes to the size they were before. Gonna be one hell of a time though restoring every image in every infobox on every page across Wikipedia which would procure uniformity of infobox image size!! — Nick B 1993 (talk) 16:05, 30 May 2014 (UTC)

No, for infoboxes, fix the infobox template. --NeilN talk to me 16:21, 30 May 2014 (UTC)
Yet another badly thought out "upgrade" being forced on the community without consultation...--ukexpat (talk) 16:38, 30 May 2014 (UTC)
  • The 'upright' parameter is scheduled for deprecation as well. It would be better to use an explicit width, since that is apparently what is expected. See mw:Requests_for_comment/Square_bounding_boxes. Feel free to comment further here. But in general, if you want a specific size for your thumbnails you should be using an explicit size specification. I can help update infobox templates where that is needed. C. Scott Ananian (talk) 20:54, 30 May 2014 (UTC)
    • @Cscott: Are you saying the WMF is completely deprecating the functionality of the thumbnail size user preference? --NeilN talk to me 00:17, 31 May 2014 (UTC)
      • User:NeilN: That is not what I am saying. The user preference is still active, it just scales the image so that it fits within a square bounding box of the user's prefered size. This gives better default results for portrait aspect ratio images. (The 'upright' option was a clumsy workaround which required manual computation of aspect ratio; plans are for its functionality to remain but aliased as 'scale', which is a better name for what it actually does.) See the linked RfC for more details and discussion. Please don't think I'm not listening to the feedback here; I've heard that several people have concerns. If there are particular examples pages/templates you'd like me to look at, go ahead and list them here. From User:Beyond My Ken's comment above, it seems that the problem is isolated to infoboxes which don't specify default sizes. I can help find there and add appropriate size parameters if that would help. C. Scott Ananian (talk) 01:47, 31 May 2014 (UTC)
        • @Cscott: Take a look at Jessica Chastain. After the WMF change was deployed but before the infobox upright parameter was added the picture shrunk. After the parameter was added, the picture took my default of 220px. If I change my default to 300px, the picture changes to that. If you set an explicit width in the infobox as you suggested, won't that override preferences? --NeilN talk to me 03:07, 31 May 2014 (UTC)
          • NeilN, it seems like what you actually want is for info box pictures to be "larger than usual"? To my eye, the infobox is much larger than all of the other figures in the article. If so, then would 'scale=1.5' (not yet implemented, but that's the plan) do what you want? C. Scott Ananian (talk) 23:41, 31 May 2014 (UTC)
            • @Cscott: No. I want all thumbnail images to adhere to my preference if an explicit width is not set. The infobox image width is correctly at 220px thanks to the upright tweak. If you read above, Crisco 1492 pointed out the change also affected non-infobox images. Editors have not gone around manually fixing millions of those. --NeilN talk to me 04:04, 1 June 2014 (UTC)
    • "It would be better to use an explicit width, since that is apparently what is expected." There seems to be a misunderstanding. Problem is: On pages with several images, every one of them now appears with different widths. Some images are so small now that they are useless as long as they are not viewed enlarged. I - and I assume many others - prefer a default width (set by "thumb", whatever width there is set in the CSS) that apllies to all images. It's not about a width set in pixel for each and every image, but about the same relative width of every image with the parameter "thumb". --Tsui (talk) 02:19, 31 May 2014 (UTC)

Coming here from bugzilla 63903. This change is a desaster for the layout/screendesign of all Wikipedias in all languages. The result of making the image widths change according to this bounding box model is, that many images are so tiny that they are rather useless in articles, on aother pages with several images every one of them now is displayed with a different width - that is the exact opposite of a well-planned screendesign/layout. If this change prevails people will start using absolute widths, set on pixel, again. --Tsui (talk) 02:08, 31 May 2014 (UTC)

  • User:Tsui: It's hard for me to evaluate what you're saying without specific examples. Can you show me a page with "images so tiny that they are rather useless in articles"? WRT to consistent image sizes, you may be interested in bug 35756, which would give us the ability to have exactly consistent images. C. Scott Ananian (talk) 02:32, 31 May 2014 (UTC)
Unfortunately I can't find the article again, where a portrait image was so small, that the man depicted could hardly be seen at all now, because the rather high (or ist it tall in english?) picture was extremely scaled down. Another example that may give an impression is de:Edikte des Ashoka where the map is now scaled down so much, that it is rather useless at that size. An example for an extreme variety of images widths: de:Buddhistische Kunst. A good layout has a grid for image widths. There is one basic size (here "thumb" served in that sense until now) and a variation for portraits and maybe another one for extremely wide panoramas - but no real layout/screendesign has different widths for almost every picture on a page. --Tsui (talk) 02:50, 31 May 2014 (UTC)
A grid layout would be a welcome step toward semantic markup of image sizes. You might look at mw:Requests_for_comment/Grid_system, although it's not (yet) talking about article layout (perhaps it should!). C. Scott Ananian (talk) 03:53, 31 May 2014 (UTC)
A fundamental change, affecting all Wikipedias, destroying the design of millions of articles and leading to frustration of thousands of users, thanks Cscott. I don't see any reason for changing the way pics are displayed. On de.wp we rarely use infoboxes at all. Now we have all those tiny images at the beginning of biographical articles which are of no use for anyone. Just have a look at de:Ata Demirer, it's horrible. --Paulae (talk) 09:03, 31 May 2014 (UTC)
  • Okay, this is broken. Absolutely, 100% broken. The WMF, with who knows how many million dollars, certainly has the ability to hire an aesthetic adviser to tell them that images of varying widths is going to look like ***. There is no use for a 250px tall full-length image; no details are visible, and thus the image has no use in identifying the subject of the article. If anything, image size for the non-mobile version of Wikipedia should be getting a little bigger, considering how commons higher resolution screens are getting. — Crisco 1492 (talk) 13:36, 31 May 2014 (UTC)


Is there any way to voice our complaints directly to the WMF so as to prompt them to revert these atrocious changes or at least to make they themselves offer some kinda antidote or work-around method instead of having to make us suffer, experiment tirelessly and compromise endlessly to find work arounds and solutions for a problem they are evidently the author of?? — Nick B 1993 (talk) 17:35, 31 May 2014 (UTC)

As far as I can see, there was one longer disc on that in April, with a lot of confusion, some people not getting why the whole change is necessary and usefull, and a somewhat hasty ending of the disc. It also becomes clear that those few, taking part in the disc, actually have no idea, how the bigger WPs deal with their pictures. At de.wp we do not use explicit width and we're telling all users (for years!) just to use thumb (the only exception are info boxes which we rarely use). And why thumb: Because the automatically given size was perfect the way it was and we had no problem with it! Hearing something like "It's hard for me to evaluate what you're saying without specific examples." from the user, who started this whole nonsense, is such a bad joke: Look at de:Pfälzischer Erbfolgekrieg, users don't even know that they are destroying the design of the articles by doing one minor edit. There is no way to tell us "Deal with it!" or "note that this code change has already been merged and is now live on all Wikimedia wikis." Revert those changes, asap. --Paulae (talk) 21:30, 31 May 2014 (UTC)

I do only say one thing: Correct this immdiately! It's a blatant ignorance of the Media-Wiki-Programmers against all authors, that were designing their articles with a good text-picture-balance. and just another sign, how far the disconnect from the Foundation employees to the needs of the Community really is. --Magiers (talk) 22:29, 31 May 2014 (UTC)

+1. — I understand that the Wikimedia Foundation are working hard to eventually make all editors go away.--Aschmidt (talk) 23:00, 31 May 2014 (UTC)

Hey folks, I am indeed listening to you. There's no need to be hostile. I'm trying to make image options better. It would help me if, instead of just yelling "revert it immediately" you could compose some reasoned arguments, hopefully backed up with specific pages and templates. For example, I looked at de:Pfälzischer Erbfolgekrieg as well as de:Ata Demirer; are those the best examples of the problems you see. If you can, underneath this comment, write some sober reflections on image sizing and describe your use cases as well as (putting aside current image option syntax for the moment) what it is that you *really* want, it would be very helpful. I can collect all the feedback and make some proposals. The suggestions I've heard/made so far have included "a grid system", "better semantic labelling of sizes" (so that explicit sizes aren't required), and a "crop" option so that an image labelled "100x200px" would actually *be* exactly 100x200px. If you want columns of width-aligned images, how do you typically handle images which are much taller than they are wide? Note that original complaints about portrait images were from gallery, image category, and "two wide" image templates, where having width-only thumbnail bounds on portrait images was not helpful. There have been some UX issues raised as well, since the current "100x200px" specification makes at least one of those numbers do nothing. It was suggested that using square bounding boxes would lead to more visually-consistent thumbnail sizes, especially where the authors of the page did not put in a specific size request, as well as removing the need for the "upright" option hack. But anyway: I would like to continue working on image handling for quite a while. So the more you can tell me about what you'd like, the more I can help implement features you will find useful. C. Scott Ananian (talk) 23:37, 31 May 2014 (UTC)

Hey folk, sorry, but what I expect is that the Employees of the Foundation talk to the Communities before they make such massive changes in the Layout of Millions of articles, not afterwards. This one was not announced in German Wikipedia, and it seems, it was not even here. In German Wikipedia, there was a consensus in the community to only use relative picture size. So most articles were designed with the expectation, that all pictures have the same relative width. This gives the article a stable view with constant text margins. For an extreme example see de:Chanson or de:Liste der Teilnehmer der Gruppe 47. On the first one, You just need to edit and preview, to see, that the article design is totally destroyed now. Not only the pictures have all different width, but the text margin is a chaos and reading is much more difficult. The last one still works at the moment, but I have read, You even plan to "fix" the "upright"-parameter, so then the next design chaos waits. Even on normal arcticles as de:Wisława Szymborska the first picture, the eye catcher of the article, is now far too small. Do I have to repair the balance of the pictures in hundreds of articles just because of a software change, that was not well communicated and did not look for the standards of the projects in advance? --Magiers (talk) 00:33, 1 June 2014 (UTC)
+1. – C. Scott Ananian, I am asking you to revert your changes and to make fix the damage this has done to all language versions, please. Immediately.--Aschmidt (talk) 00:58, 1 June 2014 (UTC)
+ 1 C. Scott Ananian what you are talking about? Many thousands authors are wrong an you are right? I can´t believe it! If you cannot estimate the results of your actions in advance, then there are two options: Simply do not act or ask the community before. But don´t tell us not beeing hostile after doing such crap!--Hubertl (talk) 06:17, 1 June 2014 (UTC)

Until now I can find not a single user who welcomes this change - but quite a lot who oppose it and wish to see it undone. Can we expect this or will all these comments be ignored? --Tsui (talk) 06:08, 1 June 2014 (UTC)

I'd hope WMF/WP is not that unflexible yet. This clearly seems to be an unwanted change causing problems all over the place.--Kmhkmh (talk) 09:26, 1 June 2014 (UTC)
Well, there wasn't a single user who supported the RfC at mw:Requests for comment/Square bounding boxes. It only got one comment by Anomie and that said: would be a torches-and-pitchforks change, as it breaks changes in an incompatible and likely unappealing manner any existing usages of "portrait"-oriented images. -2 from me on this. "torches-and-pitchforks change" seems to be spot on. PrimeHunter (talk) 09:38, 1 June 2014 (UTC)

Just another blatant example of the general aloofness at the Wikimedia Foundation. Playing around with the code takes precedence over the needs of countless of authors. On the other hand, dozens of employees write alarming reports about the ongoing decline of the number of authors. I'm sure it has hardly anything to do with gender imbalance, north/south divide or anything like that. No, the main reason is certain techies' complete lack of respect for authors. --Voyager (talk) 10:10, 1 June 2014 (UTC)

One could say "ack" to Voyager; I would only change it in the sense, that the problems is to be searched for at the WMF directly, that has no strategy and no plan how to coordinate the development of the software. -jkb- (talk) 10:43, 1 June 2014 (UTC)

@User:Cscott: ″I'm trying to make image options better.″ Not really. As far as I can see, there was no support for your request in the first place, and the discussion at the architecture meeting was not strongly in favour but more or less like "we don't really get, why this is necessary". You kinda used the hasty ending to get an ok for this. You obviously did not forsee, what your change actually does in millions of articles + the disc showed a complete lack of knowledge on how different wikipedias deal with their pics (No wikipedia uses the upright parameter? Only fr.wp uses this parameter? What a joke!). You changed the size of all portrait formats to a height of 220px, when all pics before had a width of 220px. Portraits in biographical articles usually have a pic in portrait format at the beginning. The thumb size we used so far was perfect, ususally you have the introduction and the index around it. Now these pics are extremely tiny and you can't use them to actually show what a person looks like. You want to know what we do with extremely tall pics? We make them smaller with upright or we don't use them, because they dominate the article (those cases are rare though). You playing around with sizes won't change that. Extremely wide pics usually are panorama shots which are rather rare too. So putting the width at 220px via thumb is ok, one deals with panorama pics separately (via upright=2.5 or similar, yeah, funnily we use upright on de.wp a lot). To put it in a nutshell: The communities had no problem with pic sizes, you changed the pic size, users protest, and now you want us to tell you what we actually want. Ah well, we want to deal with pics the way we did for the last ten years or so. ″I would like to continue working on image handling for quite a while.″ Please start by reverting this change, asap. --Paulae (talk) 11:56, 1 June 2014 (UTC)

@User:Cscott: this change is a disaster on it.wiki too, like in de.wiki we try to use only to regulate image size and we say to user do not set size in px.--Moroboshi (talk) 16:09, 1 June 2014 (UTC)

@User:Cscott: The matter is actually quite simple: this used to work, now it’s broken. The solution is equally simple. And it’s not to tell us it wasn’t broken at all, in spite of all those people saying otherwise. Rgds •   • hugarheimur 20:47, 1 June 2014 (UTC)

@User:Cscott: Is usability of the Wikipedia projects and the MediaWiki software still a concern? If yes, we should consider that the width and the height of an image included in an article work out differently. Articles with many images appear rugged if the individual images have different widths. Different heights and even extreme heights are much less disrupting in such a column of images than different widths. Examples like de:Chanson and de:Liste der Teilnehmer der Gruppe 47 have already been named. If this option that allows to use a common default width for a series of images is taken away, we have a significant layout problem. Using fixed pixel widths is not a solution. It took years to move from image inclusions with fixed pixel widths to a flexible solution where the user (think about usability!) is able to define his prefered width and where the characteristics of reading device can be taken into consideration. The problem that was perceived at MediaWiki, i.e. the current mediawiki syntax for image thumbnails and resizing works poorly for images which are taller than they are wide, is, if compared with the other problem, negligible as it was, where necessary, fixed with the upright option. Yes, the upright was indeed not perfect as it ignores the actual aspect ratio of the image but this should give reason to think about the upright option and not to break the default when upright was not used. If you want to support the new approach nonetheless, I would suggest to give it a new name like boxed or to improve the upright option. Extend functionality and keep it upward compatible. Or simply revert the change. But please do not hesitate and act swiftly as the current state of affairs has created a huge problem across all Wikipedia projects which gets worse whenever one of these articles gets edited. And please discuss such proposals of this magnitude that affects the layout of most articles first with the communities, not just at the MediaWiki wiki. Thanks and regards, AFBorchert (talk) 22:05, 1 June 2014 (UTC)

I reverted this software change. I recommend reverting any article changes you have done to add upright=1. We will have a public IRC discussion about what to do next, but I think it's very unlikely that upright=1 will be the preferred way to maintain the existing layout. -- Tim Starling (talk) 02:12, 2 June 2014 (UTC)

Tim, thank you. --Ancheta Wis   (talk | contribs) 02:22, 2 June 2014 (UTC)

Thanks for all the input, everyone. As Tim mentioned, the change has been reverted and we'll return to the drawing board on this one. It's likely the 'upright' flag will be next to be examined (see bug 63904), so keep your comments and use-cases coming. We'll try to do a better job soliciting input outside the wikitech-l community next time, my apologies for that. But again, thank for you everyone who patiently provided input and feedback. The benefit of a quick dev cycle is that we can also quickly revert things when we get them wrong. C. Scott Ananian (talk) 02:52, 2 June 2014 (UTC)

Cscott, now that you know some of the users, perhaps you might make informal offline changes and solicit feedback which is less formal or process-dependent. Thank you for considering these users. --Ancheta Wis   (talk | contribs) 03:21, 2 June 2014 (UTC)

@Tim Starling: @Cscott: WMF has a test environment right? Here's an idea: Grab fifty Featured Articles, fifty Good Articles, and one hundred regular articles, transclusions and all, and copy them to this test environment. Do a sanity check and invite editors to look at these articles with the coding changes applied before deploying them into production. Honestly, even if you do a better job of drawing attention to proposed change documents, you're still going to get a lot of "huhs?" as people try to parse the techie-speak. --NeilN talk to me 03:42, 2 June 2014 (UTC)

Thanks for the revert and sorry for the rough tone before, but this kind of uncommunicated change of design really made me speechless in the first moment. I would propose a better communication process in the future, that not only involves the English Community. It's nice, that You want to listen to users' comments. But I still think, more editing experience and focus on the main goal (how well helps a change the readers and editors of an article) should be added in the development process before contacting the communities. There must be enough of this knowledge inside the Foundation, or at least it should. --Magiers (talk) 05:50, 2 June 2014 (UTC)
It is my fault to some extent, since I reviewed it and approved it. I should have known that it would have a negative impact on the appearance of some articles. I will try to do better in the future. -- Tim Starling (talk) 06:25, 3 June 2014 (UTC)
+1 --Hubertl (talk) 05:52, 2 June 2014 (UTC)
This is a case where multiple people misjudged the impact of a change, it's very hard to guard against that. The change was made after an RFC discussion (that perhaps not all devs might have commented on, but that at least was read by more developers than might be apparent to us). As you can see from the commit, multiple people reviewed this change, all of them SEEING that the parser tests were being changed (and thus output) for this change and the reviewers included both Tim Starling and Brion Vibber, the most seasoned and most wiki experienced developers that we (and with we I always refer to the broader wiki community) have. And once the impact did become apparent, the feedback was collected and evaluated leading up to eventual revert. I understand that people don't want to be bothered by things like this, but it happens and appropriate action was taken in a timely manner (during the weekend even). So let's make sure the next time the 'upright' problem is being tackled, it is being fixed correctly. —TheDJ (talk • contribs) 07:57, 2 June 2014 (UTC)

FYI: Thank you honestly for the rather quickly performed revert, as in the German Wikipedia we saw the begin of what we call a Shitstorm (dewiki: de:Shitstorm), see de:Wikipedia Diskussion:Kurier#Neues Media-Wiki-Geschenk. Momentarily we are serving an IP's complaint concerning the matter (see de:WP:FZW#Bildgröße), which hopefully will stay a single one. Regards, --YAAA (talk) 18:35, 2 June 2014 (UTC)

An additional note: It was mentioned above, that you are going to "deal" with the picture-parameter "upright" (in dewiki "hochkant"). Please note, that this parameter is currently used in thousands (!) of articles in dewiki. German Wikipedia authors will surely not be amused, should the current behaviour of "upright" be changed in a way that will cause remarkable changes in optical display of pictures in articles. Regards, --YAAA (talk) 18:47, 2 June 2014 (UTC)

IRC office hours starting in 30 minutes

There's a related discussion starting in about half an hour (2300 UTC, 1600 San Francisco, 0900 Sydney), on the subject of using a grid layout: mw:Architecture meetings/RFC review 2014-06-02 The RFC is posted at mw:Requests for comment/Grid system. This discussion is an m:IRC office hours discussion on the Internet Relay Chat channel #wikimedia-office Instructions for joining are at the Meta page.

This is mostly about technical stuff to do with accomodating the wide variety of screen sizes and shapes, including smartphones, tablets, etc, but it may interest some of you. Whatamidoing (WMF) (talk) 22:39, 2 June 2014 (UTC)

More

Is this the reason why there is now a really ugly unnecessary gap between the infobox border and the infobox image? Is this likely to be reverted? Nick B 1993 (talk) 23:06, 3 June 2014 (UTC)

Nick B 1993, are you talking about Andy Murray? I don't think that it looks ugly. Perhaps you could describe what you're seeing in a little more detail? WhatamIdoing (talk) 23:17, 3 June 2014 (UTC)

The Andy Murray page has it yeah as well as every infobox image on Wikipedia. You've identified my problem fine, you just don't perceive it as a bad thing like I do evidently Nick B 1993 (talk) 23:26, 3 June 2014 (UTC)

Or perhaps it doesn't look the same on my screen as it does on yours. Different settings for font size and image sizes sometimes produce surprisingly different results. WhatamIdoing (talk) 01:53, 4 June 2014 (UTC)

WhatamIdoing, that could be the case but somehow…I just don't think so. 

My settings are most probs the exact same as yours. We're entitled to our opinions I suppose.

Incidentally I should say that I have actually come to like the infobox image thing and I share in your view on it now. — Preceding unsigned comment added by Nick B 1993 (talk • contribs) 04:15, 7 June 2014 (UTC)

logo correction

I have some technical problems with one graphic. I am trying to update TV channel logo from infobox from JPG to SVG file on this site. The new SVG version name is: TV6 logo.svg and it is available on commons (link). The problem is – if I paste this name to this infobox I get link to file that has exactly the same name, as file stored here (which is this) – they are logo's from different countries; is there a way that proper graphic can be visible? 149.156.172.74 (talk) 16:03, 5 June 2014 (UTC)

You need to ask to rename en wiki file or Commons file. --Edgars2007 (talk/contribs) 16:14, 5 June 2014 (UTC)
@Edgars2007: Oh, OK - would you please do such thing? 149.156.172.74 (talk) 16:45, 5 June 2014 (UTC)
Local file has been moved to File:V6 (Sweden) logo.svg. — Edokter (talk) — 23:12, 6 June 2014 (UTC)

Teahouse userbox problem

I see a userbox either with the first or second question after this one or alongside the heading for the second question. I have Windows Vista and Internet Explorer 9.— Vchimpanzee · talk · contributions · 21:31, 6 June 2014 (UTC)

  • Should already be resolved after my edit, no? — {{U|Technical 13}} (e • t • c) 21:38, 6 June 2014 (UTC)
At least the userbox is in the right section now. More importantly, you seem to have helped the person with the question. Thanks.— Vchimpanzee · talk · contributions · 21:49, 6 June 2014 (UTC)
I've left an explanation at Wikipedia:Teahouse/Questions#userbox help. --Redrose64 (talk) 22:44, 6 June 2014 (UTC)

Adding merges to article alerts

I am sure this is a perennial topic, but it would be very helpful if proposed merges, like moves, were listed on the article alerts system. --LT910001 (talk) 01:59, 7 June 2014 (UTC)

@LT910001: The place to check for that - and make a request if there hasn't been one before - is WP:AAlerts/FR. Don't forget to check its archives. --Redrose64 (talk) 08:49, 7 June 2014 (UTC)
Whoops, it seems like I've already commented several months ago on that very proposal. Unfortunately it doesn't seem like there's much activity, there are still requests from 2011 logged on the talk page, and no sign of replies... --LT910001 (talk) 09:36, 7 June 2014 (UTC)
Apparently AAlertBot (talk · contribs) is a bot operated by Hellknowz (talk · contribs) and Headbomb (talk · contribs). Maybe they know what the situation is. --Redrose64 (talk) 14:25, 7 June 2014 (UTC)

Request for Comment: Media Viewer

I am not voting but I see that a number of editors have expressed opinions about Media Viewer, especially here on MediaWiki, and I think it would be beneficial for the English Wikipedia community to have a consensus about this issue, so please comment on Wikipedia:Media Viewer/June 2014 RfC --Pine✉ 08:09, 7 June 2014 (UTC)(UTC)

Login issue

This morning I log in and click links and am still logged in, but if I open a link in a new window or in a new tab, it doesn't see that I'm logged in any more. I always click the "stay logged in for 30 days" box, but if I close the window where I logged in and then reconnect to WP, it doesn't think I'm logged in any more. And things I've looked at this morning are still showing the green blob on my watchlist. IE11, Vector skin. --Stfg (talk) 09:11, 7 June 2014 (UTC)

It might be that you have a corrupt cookie. Try logging out and logging in again (see my last comment at Wikipedia:Village pump (miscellaneous)#Wikidata game). --Redrose64 (talk) 10:17, 7 June 2014 (UTC)
Thank you, Redrose64. It was probably something like that. Just logging out and logging back in again didn't fix it, but deleting all history and cookies, signing out, swearing loudly, then restarting the system, seems to have. Thanks. --Stfg (talk) 12:14, 7 June 2014 (UTC)

Twinkle and Popups down?

My ability to use Twinkle and Popups just completely disappeared. I've tried using them both in Firefox and Chrome, reset all my preference, even changed skins, and yet I can't get either to work. I also tried using them on my iPhone with Safari, still no luck. Calidum Talk To Me 21:48, 7 June 2014 (UTC)

(edit conflict) Over at WT:TW. However, popups is still working for me, it's only Twinkle that stopped working for what seems like everyone. --k6ka (talk | contribs) 21:50, 7 June 2014 (UTC)
Yeah, it seems that Twinkle is not working for some reason. Dustin (talk) 21:53, 7 June 2014 (UTC)
(edit conflict × 2) I used popups thirty minutes ago to revert an edit and it works even now when I hover over your user name, so this at least isn't a universal problem. Dustin (talk) 21:51, 7 June 2014 (UTC)
  • Thanks. I forgot to re-able popups after I tried resetting my preferences, so that works now. But twinkle is out still. Calidum Talk To Me 21:55, 7 June 2014 (UTC)
Should be fixed by now. --k6ka (talk | contribs) 22:07, 7 June 2014 (UTC)
Thanks. Calidum Talk To Me 22:09, 7 June 2014 (UTC)

Migrating Reflinks, Dab solver, and User:Dispenser's other tools to Tool Labs

According to the notice posted on http://toolserver.org/, "All tool maintainers should migrate their tools to Tool Labs before June 30th 2014." User:Dispenser was maintaining some of my favorite tools, including Reflinks (which is linked from {{cleanup-bare URLs}}) and Dab solver. Since Dispenser has not spent much time on-wiki lately, and has not addressed several bugs in these tools, I'm concerned that they will just simply go away when the Toolserver is taken offline. Is there anyone willing to migrate these to Tool Labs? I'd be willing to be a tester. Thanks! GoingBatty (talk) 14:05, 1 June 2014 (UTC)

  • @Technical 13: Thanks for providing that link - I missed that conversation when it happened in February. Have there been any updates in the last 100 days? Would a targeted fundraiser still be an option? GoingBatty (talk) 14:44, 1 June 2014 (UTC)
  • @GoingBatty:, not that I'm aware of. Was a targeted fundraiser ever made an option? I'd love to hear from the MediaWiki Labs people on what their side of it is. I sense there is a lot of tension and hard feelings between Labs and Dispenser, but have no details. — {{U|Technical 13}} (e • t • c) 15:28, 1 June 2014 (UTC)
  • @Technical 13: In the thread you referenced, Dispenser said that if other options didn't work out, "I may need to solicit donations". What's the best way to solicit input from the Labs people? GoingBatty (talk) 20:21, 1 June 2014 (UTC)
    Probably the mailing list (labs-l) or IRC #wikimedia-labs. πr2 (t • c) 12:36, 2 June 2014 (UTC)
Would someone be willing to ask them to post here? Thanks! GoingBatty (talk) 04:09, 8 June 2014 (UTC)

Request for Comment: VisualEditor RfC 2014 part 1

Request for Comment is active at Wikipedia:VisualEditor/VisualEditor RfC 2014 part 1 (note title change on June 8). Please participate if you are interested. --Pine✉ 07:39, 7 June 2014 (UTC)

I think this is too soon. Here I was finally finding a few minutes to respond to your question of earlier this week about how we should consider collecting data on whether or not VE actually meets elementary editing needs, and the RFC is already posted, with no data collection at all. Here's a hint: if you're posting an RFC, you've already expressed your opinion. The fact that you think that an RFC is appropriate is an opinion. And nobody, but nobody, was talking about making VE the default state in any of the discussions anywhere over the last week. So there's another opinion. Risker (talk) 16:01, 7 June 2014 (UTC)
I have responded on the RfC page. I would also point out that "if you're posting an RFC, you've already expressed your opinion." is true only to the extent that my opinion is that it's a reasonable time for the community to be consulted. --Pine✉ 18:13, 7 June 2014 (UTC)
I have tweaked the title per discussion on the RfC page. --Pine✉ 06:31, 8 June 2014 (UTC)

Odd template behavior

Hi, I was looking at Blackgaia02's talk page and spotted an "adoption expired" notice that contains my user name. I did not leave it, though. Looking through the edit history, I found the edit that added the content: [6]. The preview underneath the diff clearly displays JCC's username, but if you step forward to the next diff, it changes to Ryulong, who made the next edit to the page. I edited this user's talk page a few minutes ago, so my educated guess is that the template is pulling the name of the last editor who edits the talk page and displaying it in the template, thus, my name is appearing there. Can someone please take a look at this? Is it because the original user didn't sign his post? Thanks, Cyphoidbomb (talk) 22:34, 7 June 2014 (UTC)

It's because the template wasn't substed when the original user placed it. I've updated the template to make it be automatically substed in the future, and I'll make sure all current ones get the right username attached. Jackmcbarn (talk) 22:38, 7 June 2014 (UTC)
Oh okay, so it was a a minor dealy, not something wrong with the template. Thanks for looking into it! Cyphoidbomb (talk) 08:00, 8 June 2014 (UTC)

Desperate

I cannot get back into my account for what reason I cannot understand. Can someone at the pump PLEASE help MARKDASK get back my account - ffs I just want to log back in and I cannot because wiki-email is not coming to my email address. F the fuck elp!!!Markdask1 (talk) 01:48, 8 June 2014 (UTC)

Oh, dear. I don't suppose that the e-mail address on that account is with Yahoo!, by any chance? WhatamIdoing (talk) 03:24, 8 June 2014 (UTC)

Only secure content is displayed

Just in the last few minutes, something's changed, either with my browser or with our servers somehow. In the last ten minutes, I've started getting this little browser popup, "Only secure content is displayed", on any Wikipedia page that I load. It doesn't have too much effect, but it is blocking the possibility of clicking the edit buttons; I had to use a keyboard shortcut to get into edit mode, and to create a new section, I had to type &section=new at the end of the URL, since there was no way to select the "new section" tab. Any idea what could be going on? I'm running Windows Eight with Monobook; aside from occasional times (typically an hour or two) when I'm testing something, I've used no other skin since registering in 2006. Nyttend (talk) 18:44, 8 June 2014 (UTC)

Try resetting your browser, I know IE can be a pain. IE has an option with HTTPS to either ignore mixed content web pages, or only show HTTPS content. My guess is that you have the latter enabled. Werieth (talk) 18:46, 8 June 2014 (UTC)

Annoying problem with Firefox and Javascript

OK, this is maybe outside the scope of this board, but my problem is, I got the new version of Firefox (they essentially annoy you until you do) and now when I allow Javascript on Wikipedia, it's horribly slow to load pages, so slow that allowing Javascript here is not an option. There's no degradation on other sites with or without Javascript allowed, and Wikipedia works fine with Javascript disabled. Did not have this problem before I upgraded. Not having Javascript significantly degrades my experience here -- no Twinkle, and other annoyances. Anybody else have this or heard of this and is there any solution? (Downgrading to my earlier Firebox version would be a last resort if even possible; moving to another browser I would prefer not to do.) Thanks. Herostratus (talk) 20:48, 8 June 2014 (UTC)

Which exact Firefox version is this? If it is slow, "Tools > Web Developer > Network" will tell you which exact parts spend the longest time for loading. Would be helpful for debugging. --AKlapper (WMF) (talk) 08:59, 9 June 2014 (UTC)

Search stuck at 29 May 2014

Wikipedia's search index has not updated since 29 May, which will give us WikiGnomes a huge backlog when it is re-started - any idea when this might be?
My test search is for recieve which usually has 7-8 misspellings/day. A "find" on that search shows 9 results for 29 May (including those I corrected on 30 May), but none on 30, 31 May, 1, 2, 3 or 4 June - Arjayay (talk) 12:41, 4 June 2014 (UTC)

I see one result updated June 2, that's J. Esmonde Barry but this sort of behavior doesn't surprise me at all with lsearchd anymore...it's always having troubles. Might I suggest using the new search engine available in your beta preferences? It updates much faster (seconds to minutes instead of once a day) which sounds like it'd be useful for your work here. If you try it out and have any problems we'd love the feedback! ^demon[omg plz] 14:18, 4 June 2014 (UTC)
I'm not sure that the revision to J. Esmonde Barry on 2 June 2013 counts as a "recent" update ;-) so it is definitely stuck - I'll have a look at the beta option, but who do I prod about the "normal" search ? - Arjayay (talk) 14:29, 4 June 2014 (UTC)
OK - I've tried the beta version, and as you asked for feedback:- the beta version is totally useless.
I have my search settings set for Article, Category and Portal. As explained above, the standard search has been broken since 29 May, but finds 80 matches for "received".
The Beta version finds just 13, 7 of which are since 29 May, so would not be on the standard search - The Beta version, therefore, appears to be missing over 90% of the matches.
May I repeat my, still unanswered, question - when will the standard search be updated? - Arjayay (talk) 17:46, 4 June 2014 (UTC)
A good number of those 80 results look like URLs, not actual prose which explains why new search won't match them (we strip those from the normal text prior to indexing). As far as when will the standard search update -- I've been having a look since this thread popped up but don't have a solution just yet. ^demon[omg plz] 22:05, 4 June 2014 (UTC)
Tim Starling and I poked at this and think we've found the root cause. Tim's kicked off the indexers again and hopefully they'll index properly again. ^demon[omg plz] 23:47, 4 June 2014 (UTC)
Thanks for trying with the standard index - although it hasn't changed yet.
A major problem with the Beta search is that the searched for term does not appear in the short text extract, requiring every entry to be opened in order to assess whether it is relevant.
As an example from my word searches - "thier" is a common misspelling, but also a placename and the family name of many people, especially the author Dave Thier.
A Beta search gives 237 matches, but only one of those matches Thiersee Lake includes the search term in the text extract.
A Standard search gives 156 matches, but every single one includes the word in the text extract - it is, therefore, easy to ignore the placenames, such as "born in Thier" or "villages include Wath-Thier", football clubs such as "Thier-à-Liège", people such as "last Thier | first Dave" or "Steffen Their", foreign words such as ""Thier Pirard" (rockpile)" misspellings in quotes "their(sic)" and even the use in an old text "manie a time deliuered him from their treasons and conspiracies, euen by thier barking"
This is not just about misspellings; any search will produce relevant and irrelevant matches - how is any editor to sift though them without the context? - Arjayay (talk) 08:16, 5 June 2014 (UTC)
I now see that some searches, such as receive and retrived do include the search term in the text extract, but others such as their and beginning, do not. Although thier and begining give many results, it is not just the searches with numerous matches that fail, refered with 6 matches, does not. - Arjayay (talk) 08:58, 5 June 2014 (UTC)
The Beta version also has a high proportion of false links to redirected pages. Currently. refrences] has four matches, but London Buses route 388 has been a redirect to List of bus routes in London since 17 January, and Programming on Disney XD (Canada) has been a redirect to Disney XD (Canada) since 27 January. Can these be filtered out? - Arjayay (talk) 11:56, 5 June 2014 (UTC)
The removal of the URL from the search text is not much use - there should be an option to include a search in the URL in the search results. A URL in the actual text not include from template expansion. Keith D (talk) 10:35, 5 June 2014 (UTC)
Totally agree - how does one find known spam-links, if you can't search for a URL? - Arjayay (talk) 11:59, 5 June 2014 (UTC)
You know about Special:LinkSearch? Johnuniq (talk) 12:07, 5 June 2014 (UTC)
Yes am aware of that - but that gives links that are in transluded templates which the standard search does not. You need to have the search only return a result when the URL appears in the actual wiki text of the article. Keith D (talk) 00:01, 7 June 2014 (UTC)
Bugzilla 66011 was submitted on 2 May 2014. The response to that bug report is contrary to what Tim and Demon are trying to accomplish (for whose efforts I am grateful, though they has not yet shown any success). Nemo wants to push the new search (CirrusSearch) from beta into production, in light of the current failure of lsearchd indexing, though I have pointed out how thoroughly useless CirrusSearch is for finding mistakes in hyphenation. - [Chris the speller 13:35, 5 June 2014 (UTC)]
Summary: The bug was reported on June 2. It WILL NOT be fixed (by troubleshooting). It WILL be fixed (by replacement), but the date is not known. Index update is not completely frozen, but pretty close. The problem has resisted repair. A major repair effort would be wasteful because the current search engine (lsearchd) is slated to be discarded and replaced by a new search engine (CirrusSearch) already in beta. Resources are focused on Cirrus, so they are not available to fix lsearchd. If you want updated search results NOW, go to your Preferences:Beta features, and turn on "New search". -A876 (talk) 20:12, 5 June 2014 (UTC)
Sorry about that wrong month on the bug report. If a major repair effort on lsearchd would be wasteful, then instead let's have a major effort on making CirrusSearch useful for the editors; teach the stinker what a hyphen is. Chris the speller yack 20:22, 5 June 2014 (UTC)
Rather then reply inline and make an indentation mess I'm going to try to summarize here. Please correct me if I make any mistakes or leave anything out. Point one: lsearchd is updating again. I checked and saw an update from yesterday which is pretty good for lsearchd. Now I'm going to try to cover some of the propblems folks mentioned with the beta search above.
  1. Hits missing from the snippets - I searched for "thier" this morning and everything looked good. The only hit that didn't contain the word in the snippet was for the redirect Thier See Lake which points to Thiersee Lake which doesn't contain the word "thier" in the text. I opened bugzilla:66279 to track this then closed it WORKSFORME because I cannot reproduce the problem. If you can then please please reopen it and attach a screenshot and a url. Or if you don't like bugzilla then get me one in your favorite way.
  2. Pages that turned into redirects are still in the index as ghosts - I created bugzilla:61211 to track this when I saw it a few month ago but then I never prioritized it. I don't know why and won't try to make excuses because its kind of a waste of time at this point. Anyway, I've put together a patch to prevent the behavior in future and I'll have a think about ways to clean up the mess over the weekend. If its just a few pages then they can be fixed with a null edit after the patch is deployed. I imagine its quite a few pages so I'll have to build a tool.
  3. Dashes - Chris let me know about this something like six month ago and I haven't done anything about it. Mostly because fixing it is way way way harder then it should be in the new system. I'd have to deal with my upstream component's upstream component and convince them to add this special thing in on top of a widely accepted algorithm. There are other options but they don't seem good either. So, the last few days we've been working on real source search with regular expressions. Its not the same thing, but I'm *hoping* that the extra power will make it worth it. We'd be planning on this for months but we kept waiting on support from external resources that kept being slow. Anyway, this week we decided it wasn't worth waiting and we were going to build _something_. Right now we've got it working in development but not deployed. It needs some review and polish (syntax errors in the regular expression cause the search to come back with "there has been a temporary problem" right now) but we'll try to get it exposed soon. And it isn't highlighted at all, which, given the first issue I listed above is at least ironic. The highlighting problem is solvable, but it'll take a few days of solid coding and I have no doubt it'll take time to find those days. The way I see it deploying without highlighting for a week or two is better then what Cirrus had if not better then when lsearchd provides in the case of dashes. Tracking bugzilla:43652 and bugzilla:65783.
I _think_ that is it. Please correct me if I missed something.
NEverett (WMF) (talk) 21:26, 6 June 2014 (UTC)
Good news about lsearchd updating again! Better news about making progress with finding hyphens/dashes!! Your efforts are truly appreciated. For now, lack of highlighting is not a show-stopper for me personally. As for ghost hits on redirects, I don't mind making a few null edits when I see them. Having hits missing from the snippets has not been a problem for me recently, but I'll keep an eye out for it. Thanks again! Chris the speller yack 20:24, 7 June 2014 (UTC)
NEverett (WMF), does this "real source search with regular expressions" mean that we'll be able to search for what's in the wikitext itself, rather than what's in the rendered pages? Specifically, is this going to make it possible to search for "Secondary cutaneous CD30+ large cell lymphoma" without picking up every page that transcludes {{Lymphoid malignancy}}? WhatamIdoing (talk) 21:53, 7 June 2014 (UTC)
Yup, the syntax I'm working with now is insource and stuff like insource:"Secondary cutaneous CD30+ large cell lymphoma" works. You can also use -insource:"Secondary cutaneous CD30+ large cell lymphoma" ""Secondary cutaneous CD30+ large cell lymphoma" to find places where the text is only transcluded.NEverett (WMF) (talk) 17:42, 9 June 2014 (UTC)
You do not mention of what is to be done about URL searching in the new search. Tying in with the above comment searching in wikitext and not including transluded text. Keith D (talk) 18:19, 8 June 2014 (UTC)
Sorry, yeah, I lumped that in with the wikitext (insource) search in my head. Do you think that'll be enough?NEverett (WMF) (talk) 17:42, 9 June 2014 (UTC)
May be as long as the previous statement that URLs are stripped out of the text before indexing will not prevent searching for these and that the -source flag does not include transluded text. Keith D (talk) 20:05, 9 June 2014 (UTC)
When you search the source its just the source so it ought to work. I'll add writing an integration test for url in the source to my board of things to do.NEverett (WMF) (talk) 20:46, 9 June 2014 (UTC)

email

Recently, when I use "email this user", nothing arrives, even when I wiki-email myself. Presumably this isn't happening to everyone else, so what's wrong? Jimfbleak - talk to me? 17:05, 7 June 2014 (UTC)

How recently? Which is your email provider? If it's Yahoo, and it began happening in April this year, see Wikipedia:Village pump (technical)/Archive 125#Wikipedia email not working when I send but works when others send to me. --Redrose64 (talk) 17:50, 7 June 2014 (UTC)
Interesting, because other than one email from the ACC mailing list (which I had to mark as "Not spam"), I've had no issues getting my messages with Yahoo (and often get too many of them). — {{U|Technical 13}} (e • t • c) 18:03, 7 June 2014 (UTC)
The problem is when you send messages from Wikipedia (or any other website) and tell the website to say that it's "from" your Yahoo account. If you want Special:EmailUser to work for you (not for people who send you e-mail, but for you to be able to send e-mail to them), then your account must have a non-Yahoo address. Whatamidoing (WMF) (talk) 22:22, 7 June 2014 (UTC)
See bugzilla:64795. The workaround is to leave Yahoo... --AKlapper (WMF) (talk) 08:48, 9 June 2014 (UTC)
I've been using Yahoo since 1997, I'm not about to give up and go to another mail client just because the WMF can't fix their ability to send emails to users with proper headers. I also seem to get all my emails, but I will add in my Emailnotice that my mail client is Yahoo and if the emailer want to be sure that their email got to me to simply post a {{YGM}} on my talk page. I've never seen any emails get dumped into my spam folder, nor have I ever had anyone claim to have sent me an email I haven't received. I check my spam folder religiously (never more than 20 emails in there at a time and usually less than 5). That is not an acceptable workaround... — {{U|Technical 13}} (e • t • c) 13:13, 9 June 2014 (UTC)
@Technical 13:, you misunderstand. The problem is not one of receiving an email in Yahoo: it's one of sending one out from Wikipedia (or any related site) purporting to come from Yahoo when in fact it comes from wikipedia.org. If the email address that you have set at Preferences is a Yahoo address, and you email somebody else, that other person will not receive the email - even if their email provider is not Yahoo but something else. My email address is a gmail one - if I were to email you from Wikipedia, you'd get the mail; but if you were to email me from Wikipedia, I wouldn't get it, it would have been bounced before it even got as far as gmail. --Redrose64 (talk) 14:48, 9 June 2014 (UTC)
I don't think Wikipedia should be spoofing the sender. Why not just put the sender's email address in the reply-to? –xenotalk 14:52, 9 June 2014 (UTC)
Exactly what I was trying to say. God, I'm horrible at wording what I'm thinking so others can understand. Thanks Xeno. — {{U|Technical 13}} (e • t • c) 16:15, 9 June 2014 (UTC)
It's not spoofing though. It's sending on your behalf, which is basically the same thing as when you send email to a mailman list. Legoktm (talk) 19:57, 9 June 2014 (UTC)
An editnotice for people sending mail to you isn't going to help, but it would be helpful if Special:EmailUser had a note up saying that if your (the sender) e-mail address is with Yahoo! Mail, that any message you send (but not messages sent to you) is going to be dropped into a bit bucket by Yahoo, and thus will never reach its intended recipient. Or maybe we could even disable access to Special:EmailUser (but not, e.g., to password resets) for these users. WhatamIdoing (talk) 23:29, 9 June 2014 (UTC)
MediaWiki:emailpagetext is the place to put such a note, but it's already quite crowded because of heavy customisation (compare MediaWiki:emailpagetext/en, which is the uncustomised message). We may also need a note at MediaWiki:changeemail-text (which hasn't been customised) that discourages the entry of a Yahoo email address. --Redrose64 (talk) 10:35, 10 June 2014 (UTC)

WP search engine appears to be down

Is this problem related to the above problems? I'm finding that I cannot search for articles altogether or search for words within articles. This has been going on since yesterday. I keep receiving "An error has occurred while searching: We could not complete your search due to a temporary problem. Please try again later." Simply south ...... time, department skies for just 8 years 17:27, 7 June 2014 (UTC)

I'm having the same problem, I wouldn't be suprised if it was related to the bug above, but it's not the same bug. I can't even get WP:RFD to expand, I get the same error as you. Crazy. --j⚛e deckertalk 21:05, 7 June 2014 (UTC)
@^demon: might know. In general I'd recommend to enable the "New Search" backend in BetaFeatures anyway. --AKlapper (WMF) (talk) 08:55, 9 June 2014 (UTC)
@Simply south and Joe Decker: there was an issue with one of the search servers yesterday, it should be fixed now. Legoktm (talk) 20:00, 9 June 2014 (UTC)
Cool, thanks. --j⚛e deckertalk 20:05, 9 June 2014 (UTC)

Weird glitch on Joe Firstman

So, you see that link to "NBC" in the lede? Perfectly normal lede. But further down on the page, where it says "In 2005, Joe Firstman left Atlantic Records to become the bandleader for NBC’'s late-night program, Last Call with Carson Daly."? The "NBC" link there shows up as a redlink to me. And when I click it, it tells me the page "NBC" does not exist. But when I try to "create" it from that redlink, it tells me the title is blacklisted. Is there some kind of weird Unicode glitching on this page that is messing up the second "NBC" link somehow? Ten Pound Hammer • (What did I screw up now?) 08:17, 8 June 2014 (UTC)

  • There was a strange private use control character (U+0092) after the "C". I've removed it. I don't know how that could have gotten added to the text stream without it being intentional, but I'm sure C0 and C1 controls are not allowed in Wikipedia page names. VanIsaacWScont 08:36, 8 June 2014 (UTC)
  • It was added in this edit by 5804FL and has Tag: via Getting Started edit suggestions. I have no idea what Getting Started is exactly, is it a script that helps new editors make their first edits? If so, how does it do that? It is possible that if it is done via a script, then that script injected that character in there trying to escape the apostrophes (there is actually another control character you missed in "new gig didn(U+0092)'t", which I've removed) and that should certainly be looked into. I'm researching more now. — {{U|Technical 13}} (e • t • c) 14:35, 8 June 2014 (UTC)
It doesn't appear to be injected by the guided tour. I'm sure it wasn't intentional because it was added when the text was originally added and didn't become and evident problem until someone tried to wrap it inside a link. — {{U|Technical 13}} (e • t • c) 14:45, 8 June 2014 (UTC)
He might have been editing through a proxy. Even that is just a guess, though. Sometimes proxies will mess up Unicode characters, but I've never seen one that adds Unicode characters were none previously existed. —Soap— 20:36, 9 June 2014 (UTC)

Editor blanks the page

Weird behaviour of the editing pane.

When I click the Edit link, the editing panel first opens as normal with the editable raw code. Then, after a couple of seconds the page updates with the arrival of the editing toolbar and at the same time the editing panel blanks. If I type in my edit and save, the previous content is blanked in the article, i.e. my blanked editing pane is faithfully saved over the previous content. When I preview an edit, the preview is displayed but the edit pane is blanked again and if I simply save from the preview then that previewed code is blanked in the current page too.

I can just about copy the page before it disappears (click in panel, ctrl-A, ctrl-C), make my changes in a text editor and then paste it all back and preview-repaste-save, but this is not good.

This has happened before and cleared up after a day or so.

This time I have investigated a bit more. It applies to a rather old Firefox 3.5.16 when I am logged in. Logged out and/or using Epiphany, there is no problem. It sticks when I close and restart Firefox, and when I shut down and restart my PC.

Has this kind of behaviour been reported before? — Cheers, Steelpillow (Talk) 11:48, 9 June 2014 (UTC)

  • I'm curious, what beta features and gadgets do you have enabled in your preferences. I'm guessing you have some JavaScript that is causing you grief, and this information will be good for trying to figure out where. — {{U|Technical 13}} (e • t • c) 13:07, 9 June 2014 (UTC)
In gadgets > Editing I had wikiEd selected. "for Firefox, Safari, and Google Chrome" I read so, knowing how ancient my Firefox is, I turned it off. Issue resolved. Must presumably have been ongoing updates and incompatibilities between the old and the new.
That would explain why anonymous editing and Epiphany worked fine.
Many thanks for the lead, with these unsynchronised and intermittent things one tends to assume that the causes are independent of one's own actions, I would never have thought to check.
Sorry to have bothered you.
— Cheers, Steelpillow (Talk) 17:02, 9 June 2014 (UTC)

Engineering goals, fiscal year 2014-2015

Hi, guys. This was announced on Wikimedia-L about 14 hours ago.

Erik's announcement

We've got the first DRAFT (sorry for shouting, but can't hurt to emphasize :)) of the annual goals for the engineering/product department up on mediawiki.org. We're now mid-point in the process, and will finalize through June.

https://www.mediawiki.org/wiki/Wikimedia_Engineering/2014-15_Goals

Note that at this point in the process, teams have flagged inter-dependencies, but they've not necessarily been taken into account across the board, i.e. team A may say "We depend on X from team B" and team B may not have sufficiently accounted for X in its goals. :P Identifying common themes, shared dependencies, and counteracting silo tendencies is the main focus of the coming weeks. We may also add whole new sections for cross-functional efforts not currently reflected (e.g. UX standardization). Site performance will likely get its own section as well.

My own focus will be on fleshing out the overall narrative, aligning around organization-wide objectives, and helping to manage scope.

As far as quantitative targets are concerned, we will aim to set them where we have solid baselines and some prior experience to work with (a good example is Wikipedia Zero, where we now have lots of data to build targets from). Otherwise, though, our goal should be to _obtain_ metrics that we want to track and build targets from. This, in itself, is a goal that needs to be reflected, including expectations e.g. from Analytics.

Like last year, these goals won't be set in stone. At least on a quarterly basis, we'll update them to reflect what we're learning. Some areas (e.g. scary new features like Flow) are more likely to be significantly revised than others.

With this in mind: Please leave any comments/questions on the talk page (not here). Collectively we're smarter than on our own, so we do appreciate honest feedback:

  • What are our blind spots? Obvious, really high priority things we're not paying sufficient attention to?
  • Where are we taking on too much? Which projects/goals make no sense to you and require a stronger rationale, if they're to be undertaken at all?
  • Which projects are a Big Deal from a community perspective, or from an architecture perspective, and need to be carefully coordinated?

These are all conversations we'll have in coming weeks, but public feedback is very helpful and may trigger conversations that otherwise wouldn't happen.

Please also help to carry this conversation into the wikis in coming weeks. Again, this won't be the only opportunity to influence, and I'll be thinking more about how the quarterly review process can also account for community feedback.

As per the announcement, please see MW:Wikimedia Engineering/2014-15 Goals and leave any comments at MW:Talk:Wikimedia Engineering/2014-15 Goals. Thanks! --Maggie Dennis (WMF) (talk) 15:38, 10 June 2014 (UTC)

Red warnings on WP:MFD

Tracked in Phabricator
Task T68328

If you scroll down to the entries for June 8, something seems to have gone wrong with Wikipedia:Miscellany for deletion/User:Victor "Toast" Gardenhire which has produced a red "Script error" and red warnings all down the rest of the page. I don't see anything obviously wrong either with that MfD page or with its transclusion. JohnCD (talk) 17:15, 10 June 2014 (UTC)

There's nothing wrong with the page. There's an issue in MediaWiki's code that I've already opened a bug about. Jackmcbarn (talk) 17:16, 10 June 2014 (UTC)
Wikipedia:Miscellany for deletion is in Category:Pages with too many expensive parser function calls due to the many transclusions of {{Pagelinks}}. PrimeHunter (talk) 17:28, 10 June 2014 (UTC)
Right. The bug is that the server is unnecessarily doing expensive things inside of {{Pagelinks}}. Jackmcbarn (talk) 17:32, 10 June 2014 (UTC)
The problem was that one mass nomination of over 200 pages used over 200 {{pagelinks}}, rather unnecessarily in the grand scheme of things, so I've switched them to plain wikilinks and the problem has gone away. BencherliteTalk 17:57, 10 June 2014 (UTC)

MediaViewer, the new VE / Flow / ...?

Has MediaViewer been extensively tested, as stated in a section above? Let me describe my experiences with it...

Random article: KQAL. Click on the logo in the infobox

  • I get a black screen, with the image in the middle. Not very informative or useful.
  • The bottom white part of the screen changes size before this stops.
  • Closing it (cross at right top) works
  • Resizing it (arrow at top right) gives a huge warning that Wikipedia now uses the complete screen. Clicking on "disallow" (or whatever you get in English) doesn't bring me back to the black screen, but to the article. Not really what I expected.
  • Bottom left, link to original source: why doesn't this open in a new tab?
  • "Use this file"? What's that about? Oh, let's "preview in browser" before I do anything. Um, this opens a new window, which again shows me the image at the same size on a black background. Isn't this what I just saw? Useless option, here.
  • I can download it in original or small size. This is a fair use file, should Wikipedia / Wikimedia really have the option to download fair use images?
  • Share? Yeah, that's the link from the top of my browser, not really much help.
  • Embed? I get a dropdown with one option, "Default thumbnail size". What's the point of a dropdown with one option?
  • Hey, I can scroll down? Perhaps they could have given me less black screen and more info right from the start... Oh, when I scroll down, half of the small image is obscured (the image screen doesn't scroll). And if I now use the "use this file" option, I get a popup screen where nearly everything is placed too high.
  • On the right, I get "All non-free media, Non-free images for NFUR review, Non-free logos". These are two of the three hidden categories, and one non-hidden. No idea why the third hidden category isn't shown. No idea whether editors who don't have the "show hidden categories" checked get to see these hidden categories here or not.

Testing with other images, I note that it takes too long to get a good image, and the first blurry one is very annoying. Tested this with Exposition des primitifs flamands à Bruges. I note that on many of these images of old works of art, the "Date" in the summary underneath the file (old file view) gave the date the painting was created (which is I think correct and certainly logical). However, the result is that in MediaViewer, you get "Created on circa 1433", "Created on circa 1490", "Created on between 1464 and 1467", "Created on after 1468", which is ... weird. The possibility to scroll through the images in an article is nice.

I'll probably opt-out, I will very rarely have a need for this tool compared to the standard tool. Would have been better if they started with an opt-in, but I guess the WMF is a rather slow learner... Fram (talk) 12:07, 6 June 2014 (UTC)

It was opt-in as a beta feature for quite some time before it was enabled by default last week. SiBr4 (talk) 17:43, 6 June 2014 (UTC)
Hey User:Fram, thanks for taking the time! Yes, Media Viewer has been extensively tested. As mentioned above it was one of the pilot Beta Features six months ago. At the time that we turned it on here it had around 15,000 opt-in user beta testing it. Media Viewer has also been very slowly released over the past two months, starting with smaller but established editing communities on the Catalan, Hungarian, Vietnamese, Polish and Thai Wikipedias, among others, as well as the English Wikivoyage. It was also released on all the other top ten Wikipedias before here, except for German, where it was released concurrently.
Now, as you have noticed, Media Viewer isn't quite 100% on most of the issues that you point out, and thanks to the big English release this week others have highlighted these same issues and they're getting fixed over the next couple weeks (like embed, download, a more prominent link to files hosted on commons, some scrolling issues). That should help you out a bit much sooner than later. For the next cycle of its development, Media Viewer will have a good solid zoom function as well as better/more clear access to other available file sizes, including full resolution. There will be other improvements as well. As for image load times, Media Viewer actually is loading images faster than a File page loads. There seems to be a perceptive difference between an entire page loading at once, like File pages do, versus launching Media Viewer immediately.
There's always room for improvement, and thanks for the feedback- we will certainly be looking at these issues :) Keegan (WMF) (talk) 20:21, 6 June 2014 (UTC)

Hi @Fram:, thanks for the constructive criticism, we really appreciate it! Let me claridy a few things:

  • The bottom white part of the screen changes size before this stops. - this is a clue that it can be scrolled up. Once you do scroll it up, it won't happen anymore.
  • Resizing it (arrow at top right) gives a huge warning that Wikipedia now uses the complete screen. Clicking on "disallow" (or whatever you get in English) doesn't bring me back to the black screen, but to the article. - this is T64578. As can be seen there, I am not a fan, but there is a good reason behind it: Esc should close MediaViewer, whether it is in fullscreen or not. The way fullscreen is handled by the browser, when you press Esc, the browser will exit fullscreen mode and "eat up" the keypress, MediaViewer will not know the user pressed Esc, only that they exited fullscreen (typically by pressing Esc, but clicking on Disallow is another way of doing that). So we either force the user to press Esc twice to close MediaViewer, or we close it every time the user exits fullscreen (which has the side effect you described). This is confusing, but given that people don't usually open up something in fullscreen just to immediately disallow it, it's not a big deal, IMO.
  • Bottom left, link to original source: why doesn't this open in a new tab? - should it? It does not do that on the file page either.
  • Oh, let's "preview in browser" before I do anything. Um, this opens a new window, which again shows me the image at the same size on a black background. Isn't this what I just saw? - actually, what you are seeing is the original file, as displayed natively by the browser (all modern browsers resize it to fit the screen and allow you to zoom by clicking on it). This is the exact same experience you get when going to the file page and clicking on the image. If you found it confusing, you might see why we wanted to enable MediaViewer to logged-out users, instead of subjecting them to the same confusing experience every time they want to view an image in larger than CD cover size...
  • This is a fair use file, should Wikipedia / Wikimedia really have the option to download fair use images? Absolutely yes. Wikimedia should not play copyright police. Fair use means the image can be used, subject to certain conditions; obviously a website cannot tell whether those conditions apply so it shouldn't prevent downloading the file but leave it to the user's judgement.
    Some sort of warning/explanation might be in order, though. Not sure what would be the best way to do that; we clearly don't want to build that into the software (too inflexible), it should come from the file description page somehow...
  • Share? Yeah, that's the link from the top of my browser, not really much help. - actually not. Sharing the link in your browser allows others to reproduce the exact same situation you have: the same image open over the same article. The link in the share panel is a sort of permalink, it opens the image over the file description page. (To see why that's useful, consider someone finding an image on the main page. If they share the link, it will stop working in a few hours as the content gets replaced.)
    Was it stupid of us to not explain this on the interface in any way? Yes it was. But the feature itself is useful, I think.
  • Embed? I get a dropdown with one option, "Default thumbnail size". What's the point of a dropdown with one option? - we offer several standard size options, if the image is large enough. You probably chose one which was smaller than the smallest option, which is 300px.
  • Hey, I can scroll down? Perhaps they could have given me less black screen and more info right from the start... - images are fit to the screen when possible, so unless the image is very small or has an atypical shape, it will be constrained by width; the black area will be on the left and right side of the screen, so there will be no way to increase the size of the metadata panel without decreasing the size of the image.
  • Oh, when I scroll down, half of the small image is obscured (the image screen doesn't scroll) - if it did scroll, it would be obscured by the top of the screen, so there wouldn't be much difference except it would be more visually distracting because there would be more moving parts.
  • These are two of the three hidden categories, and one non-hidden. No idea why the third hidden category isn't shown. - we only show three categories due to the limited space. This is a temporary solution, we hope to figure out a better one eventually .
  • No idea whether editors who don't have the "show hidden categories" checked get to see these hidden categories here or not. - this is a technical limitation that would have been too much effort to fix compared to how much we would win with it. Basically MediaWiki does not attach that piece of information to files which come from Commons. Again, we hope to fix this eventually.
  • However, the result is that in MediaViewer, you get "Created on circa 1433", "Created on circa 1490", "Created on between 1464 and 1467", "Created on after 1468", which is ... weird. - it is. Unfortunately, the way {{Information}} parameters are used is just way too diverse to come up with wording which does not get weird occasionally (compare how Date is used in File:AM._Lynen.jpg and File:The_Enthronement_of_Saint_Romold_as_Bishop_of_Dublin,_c1490.jpg, for example). The long-term plan is to replace these templates with something Wikidata-ish which can be interpreted properly by software.
  • as for speed, try to open the same image as well, and you will find that it loads quite fast, even if you clear your browser's cache (and it will be fast for everyone else, as well). Basically the servers of Wikipedia are pretty slow when showing the a certain image in a certain size for the first time. This was not apparent because we used the same small, hard-to-see sizes everywhere. MediaViewer uses new, larger sizes, so it will be slower for a short while, until those sizes are used everywhere as well - you only get the slow loading if you are the very first reader opening up that file.
    (Again, a more generic solution is in the works, to make all images load fast all the time.)

Comments like yours are very useful for development; if you have further criticisms, please share them here or on the project page at mw:Talk:Multimedia/About_Media_Viewer. --Tgr (WMF) (talk) 03:12, 7 June 2014 (UTC)

  • One of my many gripes with FLOW is that it takes up so much space on a screen. One lines of a non-flow discussion takes up about 18-20 pixels of vertical space. One line in a flow conversation takes up 99 pixels of vertical space. Just for one line. —  dainomite   03:43, 7 June 2014 (UTC)
Tgr (WMF), one possible way to resolve the "Created on" wording problem would be to drop the word "on". That should give you acceptable wording in almost all cases, e.g. "Created 6 June 2004", "Created June 6, 2004", "Created June 2004", "Created 2004-06-06", "Created c. 1642". Those all look reasonable to me, certainly better than "Created on" for the last three cases. – Jonesey95 (talk) 14:26, 7 June 2014 (UTC)
@Jonesey95:: that sounds reasonable, thanks! I submitted a patch. --Tgr (WMF) (talk) 21:35, 7 June 2014 (UTC)

Many faults with new media viewer

Is everyone happy with the new default viewer when they click on an image? Many are not. Most of the "approval" comes from casual readers who occasionally click on an image, but judging from the media viewer talk page most editors who edit and build wikipedia have noted one fault after another. e.g.Many images with very hi resolution and need(ed) to be clicked on a second time to view in full don't work right. There are numerous problems with this thing. Please look into the Media Viewer feedback conference If you wish to disable this new viewer as your default viewer you will have to go to MediaWiki.
Here is a survey you can also fill out.
-- Gwillhickers (talk) 17:16, 6 June 2014 (UTC)

You can disable it by unchecking the "Enable Media Viewer" box at Special:Preferences#mw-prefsection-rendering. Also if you don't use an account and therefore don't have the option of unchecking a box in preferences and you use Mozilla Firefox you can get the Tampermonkey extension which allows you to disable it with the following script wgMediaViewerOnClick = false;. —  dainomite   17:33, 6 June 2014 (UTC)
Thanks for that Tampermonkey script, that's helpful to share :) Keegan (WMF) (talk) 20:22, 6 June 2014 (UTC)
Oh, yeah, to note: Tampermonkey is also available for Chrome. Keegan (WMF) (talk) 20:35, 6 June 2014 (UTC)
Touche! Also I can't take full credit for the script. My friend who doesn't use an account figured it out and told me about it so I figured I'd share for those who edit without an account. —  dainomite   20:38, 6 June 2014 (UTC)
I see. Thank you friend who edits anonymously :) Keegan (WMF) (talk) 20:49, 6 June 2014 (UTC)
  • (edit conflict)This thing was so horribly unintuitive and opaque in trying to find the information I was looking for that my first experience led to me immediately disabling it. The last thousand times I've clicked on an image in Wikipedia, it sends me to a file page that has all kinds of information that I'm looking for. When WMF introduces some new shiny thing that completely overturns what has happened for the last decade when you click on something, we shouldn't have to play "I wonder which of the meaningless, indecipherable icons scattered across this black page of death might get me the content I need?" So I'm just going to come out and say it: if the media viewer does not have "File information page" and its link directly beneath the image, it is critically and unacceptably broken.
My other suggestion is that instead of loading gargantuan versions of the image you just clicked on, that it load the same image size, and provide a nice magnifying glass that enables those who have connection speed to spare to load the bandwidth-hogging mega-images that this things seems desperate to foist on us. VanIsaacWScont 21:35, 6 June 2014 (UTC)
@Vanisaac: For the first bit; a clearer way to get to the file page, there are a couple of things being worked on you'll see in the coming weeks to help with that, including a bigger, clearer link to the Commons file page if the file lives over there. Down the road, more information will be available/easier to access "below the fold" of the Viewer as work on structured metadata for Commons is moving into High Priority mode, with Wikidata as well. As for the magnifying glass/zoom/other resolutions options, we absolutely will have those available in Media Viewer v.3. There was not a real workable implementation for that at this time, but it will definitely be in the near future. Maybe you can revisit in six months or so and see what you think? Anyway, thanks for your time. Keegan (WMF) (talk) 21:54, 6 June 2014 (UTC)
@Keegan (WMF): This sort of thing is exactly why WMF is so despised by the en.wiki community. A clear and unambiguous link to the information that was previously accessed isn't an add-on for some future version six months down the road, it is a prerequisite to this thing ever seeing the light of day. I don't know how to make you people understand that productive Wikipedia editors cannot keep dealing with this shit. We are not some experiment; we are the flagship of this movement to bring information to the world, and the basic workings of the site - what information is available when I click on a picture; can I change template code when I click "edit" - keeps getting disabled by these little experiments that WMF puts out. A visual editor that doesn't let you edit templates is not "in beta", it is critically non-functional. A media viewer that doesn't let you access file information is broken. Whatever newfangled "let's turn Wikipedia into <insert social media site here>!" gadget that WMF comes up with next that completely destroys critical functionality for productive editors should not, can not, emphatically MUST NOT be deployed until productive editors can still do what they need to do. VanIsaacWScont 22:29, 6 June 2014 (UTC)
@Vanisaac: This might sound nuts, but sometimes turning the thing on really is what finds something community specific. The thing about the file linking, how it can be tweaked to suit English Wikipedia needs, as we are doing now, could only be found through release and feedback like yours. Every single project is going to have a slightly different preference on how to do any particular thing with new software, and how Media Viewer handles local file linking had not caused major comments or concerns for the other twenty-two major Wikipedias that we have released to, as well as the English Wikivoyage and all language editions of Wikisource. This was a slow, deliberate release plan built for the care and concerns of communities as we released. The same is being done here with working to get this right for the English Wikipedia now that everyone, not just beta testers, have a voice. Yours is one of those, and thank you for taking your time to share this. Keegan (WMF) (talk) 22:46, 6 June 2014 (UTC)
Fast ways to get where you want to go:
  • Open the file in the background, which skips the media viewer and goes directly to the file page. (Depending on browser/OS: right-click/"open in new tab", middle-click, cmd-click, etc.)
  • Scroll down and click the "Learn more" link.
Keegan is referencing improvements to discoverability, but to claim that media viewer "doesn't let you access file information" is flat out incorrect. It summarizes a lot of file information immediately, and makes the full description page accessible with a single click. It is also easy to skip or disable.--Eloquence* 22:43, 6 June 2014 (UTC)
No, the way to get where I want to go is to disable another non-functional piece of crap from WMF. The heuristic that every single one of these things has to go through is as follows:
  1. Is every piece of information, every editing ability, every link, every toolbar item, every keyboard shortcut, every label still present and identically functional? If yes, ok to deploy; if no, then
  2. Is there a prominent and unambiguous link to the previous functionality, available with a single left click, provided on this new tool? If yes, ok to deploy; if no, it is not acceptable to deploy it on en.wiki.
It's really not a big mystery as to what is going to piss people off here. If all the same information is found, and every sidebar gadget, link, keyboard shortcut, label, etc. is still present, even if it's not necessarily in exactly the same place, but still labeled the same, then it's not going to screw over editors. If it doesn't have all those things, then it damned-well better have the link to the old way right up at the top for all to see, with absolutely no uncertainty that this is how you get to the old functionality. VanIsaacWScont 23:17, 6 June 2014 (UTC)

Utter crap

I've just come across this dire 'improvement', having not had much editing time in the last week. To my mind, it looks like a pointless imitation of something found on a social media site, or a website that's trying to be fashionable and succeeding in being almost incomprehensible. That silly white thing with the data on it has such tiny type on it that for many it will be unreadable, and why does it scroll up and down across the picture? If I click on an image, it's because I want a quick and simple enlarge, or to read the attached data - not all this complication. How does one opt out of this bloody awful thing? Peridon (talk) 13:20, 11 June 2014 (UTC)

@Peridon: Preferences → Appearance → Enable Media Viewer, like it says in the thread above. --Redrose64 (talk) 15:59, 11 June 2014 (UTC)
Thanks for that - I had already looked through prefs but didn't expect to find it in a section that looked highly technical, and centralised rather than being an obvious option for people that weren't of a technical bent. One of the best hidden 'off' switches I've seen in some time. Peridon (talk) 16:06, 11 June 2014 (UTC)

Just another data point

I haven't encountered this "improvement", which puzzled me. I checked my preferences, & was surprised to find this enabled without my knowledge. So I repeated Fram's instructions above, & discovered that if one does a left-click on the image (instead of a right-click, as if to follow a link), then select "Open link in a new Tab", then the familiar page full of meta-information appears. Under a new tab. Which is how I habitually view that metadata.

No, this is not a feature request or bug report. Just stating how one can avoid it without changing preferences. -- llywrch (talk) 16:48, 11 June 2014 (UTC)

File usage not shown

As you can see from the article source code, File:FSJ Logo.svg is used in the infobox of Fort St. John, British Columbia. However, the usage is not indicated in the "File usage" section at the bottom of the file information page. What is going on here? It is possible that the file usage might show up if I use curl -d 'titles=Fort_St._John%2C_British_Columbia&action=purge&forcelinkupdate=1' http://en.wikipedia.org/w/api.php, but this is not going to help if I have no idea that the file is used there in the first place. --Stefan2 (talk) 20:15, 8 June 2014 (UTC)

Normally, this would be the case if you were linking to a redirect; I don't think redirect usage shows up in the "File usage" section. However, since the article is definitely linking this image directly, I can't explain it. I thought perhaps it would work if I did something drastic, so I've deleted the image and restored it — but that didn't fix anything. Nyttend (talk) 01:18, 9 June 2014 (UTC)
New idea: changing the name. I moved the file without leaving a redirect and then changed the filename in the article, and everything works fine. That still doesn't answer the "why" question, however. Nyttend (talk) 01:21, 9 June 2014 (UTC)
On commons, I occasionally see the opposite situation: an article from which a file had been removed weeks/months ago still appears in the "File usage" section. I've poked a few folks and nobody can figure out a cause or even pattern for it. Sounds like there's some generic way the File-usage list is generated that occasionally crashes or somehow else the data/cache it reads occasionally gets out-of-sync with reality. DMacks (talk) 02:56, 9 June 2014 (UTC)
There are plenty of bugs with redirects. I can think of three situations in which there may be redirects:
  • Local redirect to local file: The file usage seems to show up in the "File usage" section, at least usually. Some database reports (such as Wikipedia:Database reports/Overused non-free files) do not show redirect usage.
  • Local redirect to Commons file: The redirect doesn't work at all. There is a red link in articles if you attempt to use it.
  • Commons redirect to Commons file: The redirect works, but as far as I can tell, file usage doesn't show up. I think that this is why Commons file movers need to update all file usage globally when moving a file (either using a file mover script or by giving instructions to CommonsDelinker).
This seems to be a different bug. It is good that it was fixed for this file, but there could be problems if there are other affected files. Unused files are often deleted, either as having no foreseeable use, or for violation of WP:NFCC#7. There could be a problem if files accidentally become deleted because the file usage isn't properly indicated. --Stefan2 (talk) 16:08, 10 June 2014 (UTC)
  • This is annoying: the same problem apparently also occured with File:Pink Floyd - Time (label).png, but I could make the file usage appear by posting titles=Time (Pink Floyd song)&action=purge&forcelinkupdate=1 to the API. --Stefan2 (talk) 15:37, 13 June 2014 (UTC)

Background colour on mobile devices

Tracked in Phabricator
Task T68413

I am not sure if this has been reported, but there is an issue with using the "bgcolor" wiki mark-up on mobile devices. The colours no longer appear as they should, instead appearing as white backgrounds. This change coincides with the recent updates to the mobile site. It is an issue, because the results matricies at 2014 Formula One season#Results and standings use these colours extensively. I noticed in particular for Daniel Ricciardo's results: the first box should be a white "DSQ" on a black background. On my mobile, this appears as a white box, so while the background colour is not working, the text colour is. I have checked other articles that I know contain background colours, like Volkswagen Polo R WRC, and the problem persists, so it is not an issue with the templates used in the 2014 F1 season article. Prisonermonkeys (talk) 04:21, 9 June 2014 (UTC)

Prisonermonkeys, IIRC the bgcolor attribute has been deprecated for some time in the html standard. You should be able to fix it with inline css like this by replacing bgcolor=" with style="background-color:. It's 1am here and I'm about to pass out. Good luck from here, someone else will have to answer further questions tonight, or I'll get them in the morning when I awaken. :) — {{U|Technical 13}} (e • t • c) 05:02, 9 June 2014 (UTC)
Thanks. That has fixed it. Prisonermonkeys (talk) 05:07, 9 June 2014 (UTC)
@Prisonermonkeys: The bgcolor= attribute was first described by the W3C as part of the HTML 3.2 spec, but only for the BODY element. Some browsers (such as IE2 and Netscape 3) had already permitted it to be used on the TABLE, TR, TH and TD elements as well; that usage was not part of HTML 3.2 but was included in the HTML 4.01 spec, where it was also marked as deprecated (in common with the bgcolor= attribute on the BODY element); and in HTML5 is now marked as obsolete. This deprecation and obsolescence means that vendors whose browsers are described as being compliant to HTML 4.01 or HTML 5 are under no obligation to provide support for bgcolor=. --Redrose64 (talk) 10:28, 9 June 2014 (UTC)
I think this is an argument to start auto converting these statements to proper style attributes when rendering. I have filed a bug report. —TheDJ (talk • contribs) 12:44, 10 June 2014 (UTC)
Unless you want to elevate the status of these attributes to official wiki markup, I think we should no longer support them at all. — Edokter (talk) — 10:32, 12 June 2014 (UTC)
  • I agree with Edokter here, we shouldn't be supporting this markup at all. I would support an edit filter to warn people when deprecated code is on the page and I would support a different edit filter that prevents people from adding new deprecated content. — {{U|Technical 13}} (e • t • c) 12:07, 12 June 2014 (UTC)
Well they sort of are wikimarkup, since {| bgcolor does a 1-1 mapping of wikitables to html tables when it comes to attributes. It's thus valid syntax to describe a table of a wiki. It's unlike center/font etc in that regard. —TheDJ (talk • contribs) 14:25, 13 June 2014 (UTC)

Navigation popups

Am I the only person who has lost popups over the weekend? I've tried uninstalling, then reinstalling and purging my cache, but no go. I'm using Monobook via Firefox. I'm reminded of this song.--Jezebel'sPonyobons mots 16:06, 9 June 2014 (UTC)

I'm having issues too. Seems to work for a bit after purging the cache but then stops working. –xenotalk 17:01, 9 June 2014 (UTC)
Hmm... that's strange. I haven't had any problem with NavPops. Maybe it has something to do with the browser you are using. It's not a universal problem, in any case. Dustin (talk) 17:08, 9 June 2014 (UTC)
I'm with Xeno. It worked briefly when I switched to Chrome, them stopped there as well. Not having popups makes running CUs incredibly tedious for me.--Jezebel'sPonyobons mots 17:22, 9 June 2014 (UTC)
@Ponyo: I've not heard of that song... I have heard of this song ("Don't it always seem to go/that you don't know what you've got 'till it's gone"}. --Redrose64 (talk) 17:19, 9 June 2014 (UTC)
That may have been my fault, at least anything you've seen since Sunday 11:34 UTC. Can you keep having an eye on it and let me know if you're still having problems? I've changed some of the logic back about 40 minutes ago. Amalthea 17:23, 9 June 2014 (UTC), now heading for a beer garden.
They were just working about 90 seonds ago, then *poof*, gone again. Sometimes they appear with no issue, other times it's a miniature of the pop-up box (maybe 1cm x 1cm) with no content. --Jezebel'sPonyobons mots 17:28, 9 June 2014 (UTC)
When scanning through diffs on your watchlist or one of the special pages, whether you are looking for vandalism or something else, NavPops simplify the process by many, many times. I am sorry to hear that it is not working for some of you. There was this issue where Twinkle briefly was not working, but that problem was quickly fixed. Maybe the same will happen here. Dustin (talk) 17:32, 9 June 2014 (UTC)
Please let me know at Wikipedia talk:Tools/Navigation popups#Recent problems? if you still have problems. That script is very old and fickle … Amalthea 15:41, 10 June 2014 (UTC)
Sorry for the long delay in replying Amalthea, popups are working fine for me again. Whatever you did, thank you!--Jezebel'sPonyobons mots 21:58, 12 June 2014 (UTC)

Subtitles showing up with soundfile

Sound file File:open-mid front unrounded vowel.ogg has "subtitles". They show after having played the sound (the box expands with text in top). Manually they can be set/hidden through the "CC" menu button in the soundfile box. Can I hide them through code? Not mentioned in WP:EIS. (To complicate matters: File:open-mid front rounded vowel.ogg has & shows German (de) subtitles). -DePiep (talk) 12:44, 12 June 2014 (UTC)

Read mw:Extension:TimedMediaHandler and c:Commons:Timed Text. -DePiep (talk) 15:04, 12 June 2014 (UTC)
Update:
1. It is about namespace TimedText.
2. I did not find a code option to switch it off. I could actually remove the English subtitles from the individual file (by bold or by talk), but that is not an option for German (de:) subtitles.
3. CC? Does not stand for WP:CC or commons:COM:CC or any copyright issue (a topic I prevent clicking at all costs, like the plague). Its abbreviationee or association (mnemonic?) I cannot recall. I assume I am the only one of our Mreaders in this.
4. The question stands. -DePiep (talk) 20:15, 12 June 2014 (UTC)
3. Closed Captioning. — Edokter (talk) — 21:39, 12 June 2014 (UTC)
Yeah, now I recognise the abbreviationee Closed captioning. But hey, wasn't that the easiest one? ;-) -DePiep (talk) 22:13, 12 June 2014 (UTC)

Misinterface layout

Issue has been fixed. All is well again. Yay.—cyberpower ChatOnline 12:37, 13 June 2014 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

The Twinkle looks completely weird. Am I the only one?—cyberpower ChatOnline 20:22, 12 June 2014 (UTC)

Looks normal to me. Does it display differently in different skins? I'm in Monobook. Peridon (talk) 20:35, 12 June 2014 (UTC)
Two superimposed "TW"'s? Same here. הסרפד (call me Hasirpad) 20:43, 12 June 2014 (UTC)
Checking at with different skins, I notice the problem only occurs with the Vector skin. הסרפד (call me Hasirpad) 20:46, 12 June 2014 (UTC)
I'm seeing multiple downward pointing grey triangles – six distinct with maybe more overlapping, in a rectangle much like the pips on a die or domino for number six – overlapping the letters 'TW' which also seem to be duplicated. Everything else looks fine and the menu works. Using the default Vector skin.--JohnBlackburnewordsdeeds 20:47, 12 June 2014 (UTC)
Here's how it looks on my end screenshot P.S. I've had a similar issue on my project, it was found to be an interfering gadget .js file. Mlpearc (open channel) 20:56, 12 June 2014 (UTC)
Same problem here, along with the other gadgets that have drop-down menus. — MusikAnimal talk 21:01, 12 June 2014 (UTC)
I haven't changed any settings recently on Wikipedia or my PC, and I'm having that same issued on newest Firefox with Vector the panda ₯’ 21:14, 12 June 2014 (UTC)

Looking at the HTML it looks like the menu's been added twice, the second time as a sub-menu to itself. This explains the TW and the arrows, as the six+ arrows are a repeating pattern which would look like one if properly bounded. It also matches the other gadgets. Nothing's changed in Twinkle for weeks. I tried disabling the gadget in prefs and adding mw.loader.load(['ext.gadget.Twinkle']); directly to my Vector.js but that made no difference. It looks like something inside Mediawiki has changed so gadgets are being initialised twice.--JohnBlackburnewordsdeeds 21:21, 12 June 2014 (UTC)

Similar discussion at WT:TW, although it's been noted that it's not a Twinkle issue alone. Should be centralized the panda ₯’ 21:28, 12 June 2014 (UTC)
Still not seeing anything different in Monobook, Firefox 20 and XPPro (classic view). I have just noticed a button that I've not seen before - 'last'. And a 'since' under some circumstances. On the row where 'tag' csd' and so on are to be found. Might just not have seen it before, though. Peridon (talk) 21:40, 12 June 2014 (UTC)
Same here, 6 triangles with 2 "TW"'s. –Davey2010 • (talk) 21:43, 12 June 2014 (UTC)
  • It's not a Twinkle issue, nor is it a browser issue. It happens on every browser and is apparently limited to Vector.—cyberpower ChatOnline 21:56, 12 June 2014 (UTC)
  • The HTML structure has been changed in order to show the "More" header next to the arrow on the Vector tabs (specifically: [7] [8]) This means any script and gadget that relies on the tabs structure needs to be modiefied (again!). — Edokter (talk) — 21:57, 12 June 2014 (UTC)
It's definitely not in Monobook. I was having trouble understanding what everyone was on about until I went into Vector (spit) and saw it there. Going back to the far superior Monobook now. Peridon (talk) 22:04, 12 June 2014 (UTC)
The reason Monobook is superior is that it is now so unfashionable that no one bothers developing new bugs features for it any more. SpinningSpark 22:57, 12 June 2014 (UTC)
  • Yeah, anything with a dropdown in any skin isn't working. This is not just a Vector issue. — {{U|Technical 13}} (e • t • c) 22:04, 12 June 2014 (UTC)
  • Same thing happened to me – six triangles, two "TW"s. It's a MediaWiki-namespace issue. By the way, I'm seeing a perfectly functional "More" tab, inside where my AutoEd and move buttons are; the "More" tab wasn't there before, so it must be a MediaWiki thing. Epicgenius (talk) 22:11, 12 June 2014 (UTC)
  • This is my screenshot so we don;t have to keep describing it! Stephen 22:54, 12 June 2014 (UTC)
 
 
Here's my screenshot
    • @Epicgenius: The "More" tab was technically there - it just wasn't labelled and was simply an arrow pointing down. Seems like WMF changed things up a bit so people would notice it more easily, but it apparently broke Twinkle's drop-down menu, at least appearance-wise. The Twinkle options still appear to work, it just looks hideous. --k6ka (talk | contribs) 22:59, 12 June 2014 (UTC)
    • I also have the same problem. First I disabled TW in my preferences and when I loaded a page I saw a "More" icon where previously an inverted triangle appeared. I don't want this "More" icon, I want that inverted triangle icon.--Skr15081997 (talk) 03:22, 13 June 2014 (UTC)

Hi, I'm the developer who introduced the change. It was announced in the previous tech news, and I've already posted a CSS workaround for those who want the text gone ([9]). Things are broken because Twinkle does weird things instead of using the standard menu structure, but this looks very easily fixable (in fact, I'll just need to delete some of your code that breaks the normally functioning menu). Matma Rex talk 05:06, 13 June 2014 (UTC)

I submitted a patch for Twinkle: https://github.com/azatoth/twinkle/pull/225. Thank you for being reasonably non-abrasive about this problem (maybe the abrasive people haven't woken up yet, heh). Matma Rex talk 05:20, 13 June 2014 (UTC)
Matma Rex, thanks for the quick fix! ~SuperHamster Talk Contribs 05:44, 13 June 2014 (UTC)
Sorry if I'm being a bit dim but do I have to add that patch to something to get rid of the malformed Twinkle display? SagaciousPhil - Chat 05:57, 13 June 2014 (UTC)
@Sagaciousphil: While the fix was submitted a while ago, it was only just committed and put live a few minutes ago by AzaToth. Should be working for you now (try clearing your cache if it isn't). ~SuperHamster Talk Contribs 06:11, 13 June 2014 (UTC)
Yes, thanks! The screen suddenly gave a little flicker and hey presto it was all fixed! SagaciousPhil - Chat 06:14, 13 June 2014 (UTC)
  Fixed - Thanks! →AzaToth 06:09, 13 June 2014 (UTC)
I'm still getting the duplicate text on 'User' and 'Page'? Stephen 07:42, 13 June 2014 (UTC)
@Stephen: Do you know which scripts are adding those menus? They will need to be adapted as well. Amalthea 08:55, 13 June 2014 (UTC)
That would be Mediawiki:Gadget-dropdown-menus.js and CSS. The biggest problem is the change in CSS which makes it impossible to fix my own gadget (Mediawiki:Gadget-MenuTabsToggle.css). — Edokter (talk) — 10:08, 13 June 2014 (UTC)
@Edokter: Hmm, ok. I've quickfixed it I think, a proper fix would probably make use of Vector's own drop down menu code ... Amalthea 10:34, 13 June 2014 (UTC)
That's fixed it for me. And thanks for working out my scripts. As far as I know they were something I added last decade! Stephen 10:45, 13 June 2014 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Creating a new page: diff not available

When creating a new page, I'm sure that the behaviour of Show changes has changed. IIRC, it used to show a normal diff; now, it shows a total lack of a diff. The diff was useful if you were creating a user talk page and were substing a standard message which you wished to customise for the circumstances. You could produce the diff, copy the emitted wikitext, paste it into the edit box in place of the {{subst:whatever}}, adjust as required and save. That feature has been lost. --Redrose64 (talk) 10:46, 13 June 2014 (UTC)

I'm under the impression this has always been the case. For exmaple, I use Template:Copied a bit and it's always had a pointer for what to do if you want to link to a diff but the edit in question is the creation of a page. Jenks24 (talk) 11:54, 13 June 2014 (UTC)
When looking at a diff of a page creation we never showed the page source diff, or at least not in recent times. Redrose64 is correct however that you used to be able to get output from the Show Pages button even during page creation. You can still get the preview, but the changes are hidden now. Amalthea 12:09, 13 June 2014 (UTC)
It was very useful when attempting to subst templates and ensuring a clean result, as I know some templates can spew parser functions into pages if the correct params are not passed. Werieth (talk) 12:31, 13 June 2014 (UTC)
  • Can someone please file a bug for this? Werieth (talk) 12:15, 13 June 2014 (UTC)

Making a tree view tool bar into a wikipedia page

Hey Wikipedia,

I am trying to code a tree view into a wikipedia page that would allow the user to navigate between parent and child pages (i.e. USA-> Michigan-> Detroit). The tree view would have a single click from Detroit to USA. An example is below:

tree view

Do you think this can be done at all? — Preceding unsigned comment added by S.ivanchuk (talk • contribs) 13:21, 13 June 2014 (UTC)

Special:WhatLinksHere

Tracked in Phabricator
Task T68593

On Special:WhatLinksHere/Main Page (or any page with many links to it) there are "previous 50" and "next 50" links to navigate between pages. It's possible to go forward through them but not to go back more than one page, because the "from" and "back" parameters in all "previous 50" links are identical. Is this bug already known? Peter James (talk) 15:15, 13 June 2014 (UTC)

I just tried this on an ancient MediaWiki 1.15 where it behaves the same so I'm betting it isn't. I'll file it at Bugzilla ... Amalthea 15:40, 13 June 2014 (UTC)

Templates and tables

Hello to everyone! With this edit the template goes like this:

Pos Team Pld W L PF PA PD
Qualification or relegation

without the |pts_no=yes

Pos Team Pld W L PF PA PD Pts
Qualification or relegation

Some code to fix the PD in first table? --Edgars2007 (talk/contribs) 15:57, 13 June 2014 (UTC)

  fixed but you should be aware that |pts_no=yes, |pts_no=no, |pts_no=, and |pts_no=anything at all will all give the same result. I might suggest wrapping {{#if:{{{pts_no|}}}||... so that it only works if "yes" is returned like {{#ifeq:{{Yesno|{{{pts_no|no}}}}}|yes||.... — {{U|Technical 13}} (e • t • c) 16:19, 13 June 2014 (UTC)
This edit by Technical 13 was part-way there - this edit finished it off. The purpose of those &#32; at the end of certain lines is to prevent the immediately-following newline from being stripped. I'm sure I've explained this before, in relation to Template:2013–14 Premier League table/sandbox. --Redrose64 (talk) 16:23, 13 June 2014 (UTC)
Thanks! --Edgars2007 (talk/contribs) 18:29, 13 June 2014 (UTC)

Wikidata issue

Moved from user talk:Pigsonthewing


So here am I writing content on Baumwollspinnerei Hammerstein taking a lot of material from a book and de:Baumwollspinnerei Hammerstein which is actually a redirect from de:Hammerstein (Wuppertal)#Industrie. I want to put an interwiki link between the two pages. The good old : code has gone- but no problem- time to try wikidata.

How? there are not a lot of clues

  • Click on the language wheel. No not that. x
  • Goto unrelated page and look for help. That sort of works- it says that
  • I need to go to the original page- that is de:Hammerstein (Wuppertal)#Industrie and look for an edit icon, and get in that way! *x Neither pages have an edit icon.

So I must manually create a Wikidata item

  • x Mumble to myself about just typing [[:de:Baumwollspinnerei Hammerstein ]] - and through an unrelated page, get in and find the create new item. !.Easy

Now I enter Baumwollspinnerei Hammerstein as the name and c&p a sentence from the en:Baumwollspinnerei Hammerstein lede. the page is created and it is given a Q number. (Q17164698). Refresh en:Baumwollspinnerei Hammerstein and no sign of it. No link.

I go back to Wikidata (do we type that up as q:Baumwollspinnerei Hammerstein ?) and decide I should try to add another language to Q17164698.

I am given one box to enter a language code and the sitename followed by a □ [save]|[cancel]. Save is grayed out.

  • x Stalemate.Cup of coffee/ check email and clean up the page.

Change preferences from Vector to monobook. Try again- but this time I see two dataentry boxes !Success? I have added en:Baumwollspinnerei Hammerstein to Q17164698. Vector doesn't work- monobook does on Firefox 26.0 for Linux Mint

Now back to en:Baumwollspinnerei Hammerstein to see the wikidata below the languages.

  • X (refresh) and nothing. Hour later nothing and nothing in history. This is not the way to manually add a interwiki link

Lets try the German article. Back to Wikidata and add another language. Failed with error message : An error occurred while trying to perform save and because of this, your changes could not be completed.Site link dewiki:Hammerstein (Wuppertal) is already used by item Q1573863. At least that is clear- You cannot link to an anchor. You cannot link to a redirect page that is linked to an anchor.

Which in this case rather defeats the object of interwiki links.

OK leave it there. — Preceding unsigned comment added by ClemRutter (talk • contribs) 14:28, 11 June 2014 (UTC)

I don't know where to begin with this; can someone assist ClemRutter, please? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:36, 12 June 2014 (UTC)
About 10mins ago- we got a working link. My watchlist suggested that a new Q code had been given- then the old Q code delinked- by me. I then followed instructions (Edit links add) a new better dataentry page appeared, I filled it in for de: and it worked. Thanks- I hope the other items in the feeback are as easily solved-- Clem Rutter (talk) 22:32, 13 June 2014 (UTC)
Hi Clem! There are two places on an Wikipedia article where you can go directly to the Wikidata entry if it exists. Both are in the left column in Monobook skin: "data item" in the tools section and "edit links" in the languages section. Of course somebody or somebot has to make the Wikidata entry first. To refer to a Wikidata entry, we can use "d:" as the project identifier, so d:Q1573863 will link to the data entry - or you can search for "Baumwollspinnerei Hammerstein" on d:Wikidata:Main_Page. Drop me a note if you get stuck in future. --RexxS (talk) 13:06, 14 June 2014 (UTC)
Hi RexxS- thanks for the post. I have got the link working- I just think it was important to register a user experience.The second time around it worked like clockwork. I think we have proved that the process can work, but a lot of attention needs to be paid to making intuitive. Both to oldtimers and the group of newbies I will be training next week. I missed the "Data item" in tools- which suggests to me that I need to up my caffeine intake, or this needs to be renamed to "Wikidata links". I can't recall seeing a reference in any of the Help documentation... but that is for another day. Do keep me in the loop,, and contact if you want an opinion from someone with a little distance from the group.-- Clem Rutter (talk) 15:29, 14 June 2014 (UTC)

Unable to view diffs logged in

Tracked in Phabricator
Task T67793

I'm getting a page that says "Fatal exception of type MWException" whenever I try to view diffs from my watchlist (in Chrome, on OS X, with either Vector or Monobook appearance, if any of that makes a difference). If I copy-and-paste the same URL to a not-logged-in copy of Safari it works normally. Is anyone else seeing this? —David Eppstein (talk) 21:02, 12 June 2014 (UTC)

@David Eppstein: That sounds unusual. Can you provide a link here to one of the diffs that causes this error? --Dan Garry, Wikimedia Foundation (talk) 22:08, 12 June 2014 (UTC)
Some diffs that are causing this error: [10] [11] [12] [13] [14]. Some diffs that are *not* causing this error: your reply above, [15] [16] [17] [18]. I have not made any changes to my rendering preferences (other than trying a switch to monobook to see if it would make a difference). Looking at the titles of the problematic and unproblematic diffs makes me wonder: could this be a problem with <math>/mathjax? —David Eppstein (talk) 22:38, 12 June 2014 (UTC)
They all loaded for me.—cyberpower ChatOnline 23:09, 12 June 2014 (UTC)
There's an ongoing issue with MathJax right now, to avoid issues set your preferences to render in PNG temporarily. Legoktm (talk) 01:20, 13 June 2014 (UTC)
Yes, it appears to be a combination of (in prefs => appearance) "Leave it as TeX" and MathJax. Instead setting it to "Always render PNG" (but still keeping MathJax checked) avoids the problem and still leaves me seeing the formulas as MathJax. —David Eppstein (talk) 04:03, 13 June 2014 (UTC)

Volume of an n-ball

Everytime I try to browse the page Volume of an n-ball, I get the following error: "[b485a8cb] 2014-06-13 00:10:09: Fatal exception of type MWException". I use Debian 7 and this happens with both Firefox and Chrome. It works properly in Windows but worked the results with different browsers in iOS are mixed. Taha (talk) 00:26, 13 June 2014 (UTC)

It happens if in the "Math" secion of user preferences the choice "Leave it as TeX" is selected (regardeless of wether MathJax is enabled or not). Anybody knows if this bug is already known / worked on and if / where it is tracked? --Patrick87 (talk) 01:02, 13 June 2014 (UTC)
OK, my bad, see section above... --Patrick87 (talk) 01:28, 13 June 2014 (UTC)
Thank you for the response. Taha (talk) 03:46, 13 June 2014 (UTC)

Internal error on Wikipedia:Reference_desk/Science

I'm getting "[698df09b] 2014-06-13 08:51:10: Fatal exception of type MWException" on Wikipedia:Reference_desk/Science. I've tried it a few times in the last couple of minute and it does not seem to affect other pages.--Salix alba (talk): 08:55, 13 June 2014 (UTC)

@Salix alba: See previous two threads concerning Preferences → Appearance → Math and the "Leave it as TeX" preference. --Redrose64 (talk) 09:01, 13 June 2014 (UTC)

Interface problems

[To forestall recommendations that I abandon my carefully-customized skin and just use standard Vector: No. Standard Vector is an ugly piece of shit. Its fonts, colors, layout, and overall design elements all suck. Monobook, Modern, and Cologne Blue are equally problematic. There's a reason I spent so long getting people to change all the components in Vector for me until it looks and feels like Classic -- and that reason is, standard Vector is an ugly piece of shit.]

I've recently (within the past week) noticed several annoying changes in the overall interface. For instance, when I go to a page that doesn't exist, I'm presented with only the text "There is currently no text in this page. You can search for this page title in other pages, search the related logs, or edit this page", with no links to any other WMF projects, no mentions of other reasons that the 'no page here' message might be displayed, no link to the article wizard, etc etc. This particular change is quite minor, of course, and it's not something that really bothers me, but it's indicative of the greater issue. Although there used to be a function that would, if you went to a nonexistent page for an address with a mismatched parenthesis, suggest the version with the matched parentheses (i.e., 'there is no article called "blorg (blorg", did you mean "blorg (blorg)" ?'), and that doesn't seem to be available any more regardless of whether I'm logged in.

I'm also vaguely disappointed that, when the page for file:Example.jpg tells me that the file is actually on Commons, the Commons icon isn't displayed any more. Still not a major issue, though.

What is a major issue is that Page History no longer has any links to the external tools.

"For any version listed below, click on its date to view it. For more help, see Help:Page history and Help:Edit summary. External tools: Revision history statistics · Revision history search · Contributors · Edits by user · Number of watchers · Page view statistics (cur) = difference from current version, (prev) = difference from preceding version, m = minor edit, → = section edit, ← = automatic edit summary -- what I see when I'm logged out.

"Diff selection: Mark the radio boxes of the revisions to compare and hit enter or the button at the bottom. Legend: (cur) = difference with latest revision, (prev) = difference with preceding revision, m = minor edit." -- what I see when I'm logged in.

Another major problem is the little box that's found at the bottom of the contributions page... but isn't there any more.

Here's what I see when I'm logged out:

"(username): Subpages · User rights · Edit count · Edit summary search · Articles created · Global contributions / log · SUL / accounts"

and here's what I see when I'm logged in:

<nothing>

This is presumably the result of someone making changes to MediaWiki code without considering the results it might have. I would like to know what can be done to remedy the issue. Thank you. DS (talk) 15:39, 13 June 2014 (UTC)

You didn't change your language settings, by any chance? Check that your language is set to "en" (not "en-GB" or "en-CA") and see if that fixes the problem. Most of enwiki's customised messages are only available when you set your language to "en". — Mr. Stradivarius ♪ talk ♪ 15:42, 13 June 2014 (UTC)
Ah! Thank you. Always good when a seemingly complex problem has a simple solution. DS (talk) 15:58, 13 June 2014 (UTC)
You know, any admin who wanted to, could make the "translations" for these MediaWiki: messages, and then people could set their preferred languages to an English variant without losing access to useful information and links. WhatamIdoing (talk) 18:46, 13 June 2014 (UTC)
I could, but I don't want to. There are hundreds of customised messages to try and keep track of. This morning I amended two of them - for vanilla English only - but I'm not going to "translate" them for some trivial tomato/tomato difference. --Redrose64 (talk) 19:30, 13 June 2014 (UTC)
Exactly. It's just not maintainable. If you change your interface language, you are going to miss some information. Simple as that. Perhaps we should add a warning to one specific message that is always visible... —TheDJ (talk • contribs) 13:56, 15 June 2014 (UTC)
We could have a bot do it for en-CA, en-GB of course, ignoring any CA, GB specifics, and auto synchronizing after every change in the main message. —TheDJ (talk • contribs) 14:03, 15 June 2014 (UTC)
By far the best solution would be wholesale deprecation of all en-* localisation; it's really not needed in any meaningful way and it just soaks up time, leads to problems like above, etc. Andrew Gray (talk) 15:10, 15 June 2014 (UTC)

Media viewer fails to give credit to all people in specific circumstances

Tracked in Phabricator
Task T68606

The Media viewer fails to give credit to all people listed under author in situations where:

  1. There is a {{Creator:Foo}} tag used for one of the authors, but
  2. Other authors are listed below said tag.

For example,  , if viewed in media viewer, will only credit Mathew Brady, leaving out my restoration work.

Given the amount of times that I have my restoration work grabbed without credit already, I'd rather not encourage people. Adam Cuerden (talk) 01:16, 14 June 2014 (UTC)

Thank you for reporting and filing a bug about this. You will see this more often for quite a while. We are at the start of a VERY long path where we need to translate all our 'human readable' data with regard to image pages into machine readable information, and that attempt is going to be incomplete for many years. (Remember when we didn't even have {{Information}} and how many files still don't ?) —TheDJ (talk • contribs) 13:48, 15 June 2014 (UTC)

Watch vs. Contrib.

My most recent edits (to Geography of South Korea and Flight of the Phoenix (2004 film) do not show up on my Watching list, even though they are marked as "to watch" by me. I'm practically certain that in the past my own edits were always included in the Watching list as long as they were current. Am I wrong, have things chagned, or is there a bug?Kdammers (talk) 05:26, 14 June 2014 (UTC)

Did you change your preferences to "Hide my edits"? VanIsaacWScont 07:12, 14 June 2014 (UTC)
No, I didn't, but I'll check to see if it got changed "for me" some-how. Kdammers (talk) 10:26, 14 June 2014 (UTC)
Uuu, that was a bad choice of words. Any-way, I looked at my settings. "Hide my edits" is not ticked.Kdammers (talk) 10:31, 14 June 2014 (UTC)
  • Kdammers, there are two hide/show my edits toggles. I know I've absent mindedly checked the wrong one before. There's one on the watchlist tab and one on the recentchanges tab of your preferences. Also to check is if edits by registered users is checked or hide minor edits is checked, I've seen some combinations return initially unexpected results that were logically sound. — {{U|Technical 13}} (e • t • c)% — Preceding undated comment added 14:07, 14 June 2014 (UTC)

Teahouse question indicated user signed when he/she didn't sign

This question on The Teahouse appears to indicate a situation that should be corrected. If a person does not actually notify someone, but the notification comes from him/her by some automatic process, that person's notification shouldn't appear in any history as coming from that person, or in that person's contributions. And yet Twinkle has an automatic notification feature which, in this case, sent a user a notification from himself on his own talk page. He was afraid his account had been compromised.

I probably haven't explained this well, so I will include this description of the problem:

Hey Jodosma. Here's what happened. When you list a discussion at RfD using Twinkle it gives you an option to "Notify page creator if possible?"; if you don't take the checkmark out of the box Twinkle then provides a warning for editors of the category through your account automatically when you save. Here, since you are the only editor of Category:Mountain passes of the Appenines, when you listed it for discussion in this edit using Twinkle, you automatically warned yourself the same second (and then yelled at yourself for doing so:-)--Fuhghettaboutit (talk) 00:52, 13 June 2014 (UTC)

When I thought this was something that really happened, I took it to the proposals page, because I didn't think any automatic action ought to be credited to a user, and this was the response:

Twinkle isn't automatic. It is your responsibility to read the user manual. Legoktm (talk) 23:54, 13 June 2014 (UTC)

So can anyone say why this person found his/her own name in the history when he/she didn't do anything?— Vchimpanzee · talk · contributions · 15:51, 14 June 2014 (UTC)

They DID do something. They used Twinkle to perform an action. That's what Twinkle (and I suppose other automated things) are for. It's not Twinkle doing an action - it's not a full bot. The person who starts things off by using Twinkle is responsible for the edit just as surely as if they had typed it all up themselves. Before I became an admin, I'd done 12,000 edits. All purely manual. One or two people found this hard to believe. After I got my mop, I also started using Twinkle to save time and typing. That's all Twinkle is. A set of templates and a script or two to post them. Full bots run by themselves, and sign for themselves - but ultimately the bot owner is responsible for what the bot does. Users of scripts are responsible for what they do and their actions through the scripts need to be attributed. If you or they don't like it, do it the hard way. Like I used to. Can be done - just needs memory and fingers. Peridon (talk) 17:59, 14 June 2014 (UTC)
  • Hopefully my fairly drawn out explanation on THQ with timestamps and links to their contribution history will clarify. — {{U|Technical 13}} (e • t • c) 18:36, 14 June 2014 (UTC)

Other Twinkle issues

Hello! I don't get it. On en.wikipedia, I have all the TW rollback options. But when I access the ro.wikipedia or uk.wikipedia, those options are simply not there. Can someone tell me how is this possible? I don't know if it's very relevant, but I'm using Chrome. I also tried with Safari, but it's the same thing. Thank you. --Wintereu (talk) 17:56, 14 June 2014 (UTC)

I was going to say "Go into 'Preferințe', then 'Gadgeturi' and click the box by Twinkle. I'll leave you to work out the Ukrainian one - same idea though." but I can't get it either. It may not be available there in Twinkle. I can't even find Twinkle on the French WP. Peridon (talk) 18:13, 14 June 2014 (UTC)
Not all Wikipedias have Twinkle. There are no universal gadgets, not even HotCat, since Welsh Wikipedia has no gadgets at all. You can use Wikidata to get an approximate idea: these Wikipedias all have Twinkle; others may have as well, but any others don't have an equivalent to our WP:TW page.
The Gadgets list in prefs is rarely translated into anything other than the local language, so if you don't read the local language it can be tricky looking through a gadgets list. However, you can use the ?uselang=qqx trick - here are the gadgets lists for French, Romanian, and Ukrainian Wikipedias. In those, look for "(gadget-Twinkle)", count the number of lines from the top (or bottom) of the section (e.g. third from top of the second section for Romanian), switch back to the normal language, set the option and save. --Redrose64 (talk) 20:41, 14 June 2014 (UTC)
Thanks for all the answers. On ro.wikipedia worked just fine until 5 days ago. Since I'm one of the recent changes patroller there, my work just became a bit harder without these options. I checked the site, Redrose64, thanks. It's there and already checked. Two days ago was probably the weirdest TW issue. Several recent changes patrollers complained that Twinkle appeared doubled on their browsers and without any possibility to use it whatsoever. Since no one had a clue of what could have possibly gone wrong, I thought to give a shot here. Thanks again, and to you too, Peridon. --Wintereu (talk) 22:11, 14 June 2014 (UTC)
@Wintereu: By "Twinkle appeared doubled on their browsers", is this the issue described at #Misinterface layout above? --Redrose64 (talk) 22:19, 14 June 2014 (UTC)
If it is the same problem as above, try Monobook instead of Vector until they get it fixed. It worked just fine here right through... Peridon (talk) 22:37, 14 June 2014 (UTC)
Exactly the same, Redrose64. Thankfully, the problem was fixed. As for the missing RB options, I'm still hopping. --Wintereu (talk) 13:23, 15 June 2014 (UTC)
@Wintereu: Twinkle is not internationalized. There are forks for other wikis, but you need to talk the the respective Twinkle maintainers there if you see any issues. For ro-wp that seems to be ro:User:Andrei Stroe, I can't find a Twinkle Gadget on uk-wp. Amalthea 17:05, 15 June 2014 (UTC)
I'll do that. Thanks for the time with the explanations. --Wintereu (talk) 17:53, 15 June 2014 (UTC)

Strange message

Tracked in Phabricator
Task T68624

I see the message:

"<IP address removed for privacy reasons> is a student in Intellectual Freedom - LIS 493 (course talk)."

on the contributions pages of many IPs (all that I've tried) that are not <IP address removed for privacy reasons>, and who do not appear to have any connection to that course (example: Special:Contributions/71.198.212.248, Special:Contributions/37.230.4.122). This only happens with IPs, not registered users. I'm not sure if this is the best place to report this, but I couldn't find any mention of this elsewhere. ʍw 19:57, 14 June 2014 (UTC)

I'm seeing a slightly different message starting with my IP address. I've therefore redacted the IP address from your post, since it is likely to be yours. Someone will be receiving a trout once this is resolved... -- John of Reading (talk) 20:07, 14 June 2014 (UTC)
Seems to be resolved now; I hope an explanation is forthcoming. TenOfAllTrades(talk) 20:16, 14 June 2014 (UTC)


  • Weird. I don't know! I have 5 students & they all set up user accounts, and were all novices. As to "a student in the class" -- when I was setting up the course page today, I clicked on "add a student", and tried to add myself (with my userid); when I saved, it listed that IP address, and did not list my userid. I'm not sure if that was a cause of the IP address or merely a correlation in time. I tried then to delete the IP address from the students in the course ("remove from course") -- have tried twice! -- and it won't delete. I imagine that my efforts to remove the IP from the class are why it has the "privacy reasons" message. But how did the IP address get added to begin with? Why are they trolling the Jimbo Wales page? --Lquilter (talk) 20:10, 14 June 2014 (UTC)
    • responded on my talk page & on the Help desk page too. --Lquilter (talk) 20:17, 14 June 2014 (UTC)
      • Those IPs were picked more-or-less at random, I'm sure the "trolling the Jimbo Wales page" is completely unrelated to the course. ʍw 20:41, 14 June 2014 (UTC)
  • (edit conflict) I don't see that message, can one of you post a screenshot and can you both check your preferences and tell me if Preferences → Appearance → Show a link to your courses at the top of every page. is checked or not? If either of you has wikEd enabled, can you hold down your control key, and click on the wikEd icon in the very top right corner of the screen and paste the results into a page someone and point me to it, if you put it here, please put it in an {{Hst}}{{Hsb}} collapsed section. Thanks. — {{U|Technical 13}} (e • t • c) 20:23, 14 June 2014 (UTC)
    • You don't see it because this is in the middle of being fixed. The bad database entry has been removed and I believe we are waiting for a fix so this doesn't happen again. --Krenair (talk • contribs) 20:30, 14 June 2014 (UTC)
    • (ec) No, I don't have Show a link to your courses... or wikEd enabled. (I am kicking it old-school with Monobook, incidentally.) Looks like the Bugzilla report has a screenshot now. TenOfAllTrades(talk) 20:31, 14 June 2014 (UTC)
    • I don't even know how I would enable wikiEd! I do have a "show a link to your courses", since I just went through & checked that. This is my first time doing an official course assignment in wikipedia & clearly there's a bit of a learning curve ahead. I'm relieved that the bug was fixed, although still mystified about what it was and if I triggered it. --Lquilter (talk) 20:34, 14 June 2014 (UTC)
    • The problem does seem to be resolved now, but, FWIW, I did take a screenshot when I first noticed (I haven't uploaded it yet, is there still any need?) and I don't have said box checked in my preferences (I've never done anything related to these courses). ʍw 20:41, 14 June 2014 (UTC)
@Mysterious Whisper: No, there's no need to upload a screenshot. The behind-the-scenes experts are dealing with it. -- John of Reading (talk) 20:47, 14 June 2014 (UTC)

Hi. There were a few bugs in the EducationProgram extension that stacked up on top of each other and caused this to happen. The immediate cause has been fixed, and there are some patches in progress to prevent this from happening again. There are technical details on bugzilla:66624 if you're interested. Sorry about the trouble. Legoktm (talk) 00:19, 15 June 2014 (UTC)

Any chance of reviving Wikipedia:Dump reports/Missing articles?

I just discovered this and it's a pretty neat idea. The last report is from 13 December 2011.-- Brainy J ~✿~ (talk) 21:18, 14 June 2014 (UTC)

Unstyled and non-loading pages

 

Anyone else having the unstyled pages or the pages that never load? This is really starting to irritate me. Dustin (talk) 21:23, 14 June 2014 (UTC)

The issue may have suddenly resolved itself within the past ten seconds, so no response may actually be necessary. Dustin (talk) 21:25, 14 June 2014 (UTC)
Yeah, I think most of the problem was on my end. However, at one point, I did receive this message:

WIKIMEDIA FOUNDATION

ERROR

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: /5.0 http://(null)(Windows, from 72.198.94.xxx via cp1055 frontend ([208.80.154.xxx]:80), Varnish XID 2897667758 Error: 403, HTTP method not allowed. at Sat, 14 Jun 2014 21:20:11 GMT

Thanks if you respond. Dustin (talk) 21:49, 14 June 2014 (UTC)

@Dustin V. S.: This sort of thing happens every few months. See WP:WFEM, Wikipedia:Village pump (technical)/Archive 120#Style load problems continue, Wikipedia:Village pump (technical)/Archive 120#Wikimedia error, site very slow, looks like when Internet first developed, Wikipedia:Village pump (technical)/Archive 120#"Wikipedia Error" ?, Wikipedia:Village pump (technical)/Archive 122#Wikimedia Foundation Error, Wikipedia:Village pump (technical)/Archive 123#Wikimedia Foundation Error. --Redrose64 (talk) 22:42, 14 June 2014 (UTC)
Yes, my error page looked like that one. But I don't understand part of this; did anyone else see that same error page today? Dustin (talk) 23:37, 14 June 2014 (UTC)
It's random and unpredictable, although there are phases when it happens more often. Go to another tab in your browser, check your contributions. If the edit is shown, you're OK; if it's not, return to the first tab, use the browser's "back" button to return to the editing screen, and click Save page again. --Redrose64 (talk) 00:30, 15 June 2014 (UTC)
Well random and unpredictable they are not of course. It's just like it says, the servers ran into a problem. There are however 100s of servers and hundreds of reasons why there might be problems (giving the appearance of randomness perhaps). The error code 403 is unusual here btw. usually it's 503 (which would basically be 'server is too busy to deal with you now'). As long as it doesn't happen too often, it's not something to worry about though. —TheDJ (talk • contribs) 13:32, 15 June 2014 (UTC)

Automation of Wikipedia:Requests for comment/All and related pages

From what I understand this list is manually maintained. This leads to quite a messy appearance and surely is fairly effort intensive. Could this process be automated? A short statement could be included in the RfC template, and pages holding the template of an active RfC could be listed by a bot. Thoughts? --LT910001 (talk) 22:49, 14 June 2014 (UTC)

@LT910001: Why do you think it's manually maintained? Legobot (talk · contribs) does pretty much all of the necessary editing. --Redrose64 (talk) 23:31, 14 June 2014 (UTC)
I see. The subpages all have the text "This is a human-edited list of requests for comment", which I thought referred to the page itself rather than the request board.--LT910001 (talk) 23:38, 14 June 2014 (UTC)
The text "This is a human-edited list of requests for comment" relates specifically to Wikipedia:Requests for comment/Request board, which is linked from the bottom of each subpage because {{RFC list footer}} is included at the bottom of each of those subpages. Not many edits get made to that page. If I try to edit one of the other subpages - for example Wikipedia:Requests for comment/Biographies - I see this notice which warns me against editing it. These subpages have histories like this which doesn't show much human editing. There is some, but the bot often reverts the human with its next edit. --Redrose64 (talk) 00:05, 15 June 2014 (UTC)

Username magic word

Is there a magic word, like {{PAGENAME}}, which will substitute my username? I'd like to create a button that creates a new level 4 section for a talk page titled "Comments from (user name)", but I can't find whether there's a magic word that can insert the user's username. --LT910001 (talk) 23:43, 14 June 2014 (UTC)

There is actually: {{subst:REVISIONUSER}}. — Edokter (talk) — 23:47, 14 June 2014 (UTC)

Helpful links move with Help Desk

I thought it was a glitch, but it appears to be an intentional new feature. Several helpful links stay in the lower left corner of the screen as you scroll down in the Help Desk.— Vchimpanzee · talk · contributions · 19:00, 11 June 2014 (UTC)

Yes, Technical 13 (talk · contribs) added this to the Wikipedia:Help desk/Header. -- John of Reading (talk) 19:09, 11 June 2014 (UTC)
  • I've added the ability to collapse the section per request of some editors and there is also an id for the section so those that don't like it can completely make it go away. Still trying to figure out how to make it remember its last state. Maybe Krinkle can help with that as he seems to have done a lot of testing for this on testwiki. — {{U|Technical 13}} (e • t • c) 19:35, 11 June 2014 (UTC)
I see that this is used with other help pages. Yes, I would like this to go away if I can do so. I tried "collapse" when I first saw it and the result was actually annoying. — Vchimpanzee · talk · contributions · 19:55, 11 June 2014 (UTC)
It worked! Thanks.— Vchimpanzee · talk · contributions · 19:56, 11 June 2014 (UTC)
Disabled it again, this is very disruptive on monobook as it overlays the footer and several navigation divs in column-one. It's also broken on monobook, there is no #mw-head. I recommend to put this in a user script/gadget to make it opt-in, and to test it on all skins before deployment. Amalthea 21:34, 15 June 2014 (UTC)

Broken diffs

Ive been using several reports and a tool for checking NFCC issues, today I ran across something Ive never seen before. It appears that our diff system is completely broken I just removed a file for WP:NFCC#9. http://pastebin.com/XSy8741u is the diff table that I was shown, and this was the saved diff completely different than what I was shown the first time. Werieth (talk) 13:01, 13 June 2014 (UTC)

  • Bump Werieth (talk) 02:03, 16 June 2014 (UTC)
    There have been a lot of problems with "show changes" recently. Does it look like the same issue as below? πr2 (t • c) 04:34, 17 June 2014 (UTC)

CSS files and text using <font>

Okay, at my css file at User:Dustin V. S./common.css, I have been attempting to get past the unsatisfying default font of Wikipedia such that the standard is to use Times New Roman instead, but when I made a change to my css file as to try to do so, I realize that the change made it to where regardless of whether or not a certain text piece already has a set font, Times New Roman will be used if <font> was used instead of <span>. A lot of places use the old <font> method of changing text, though, so is there a way to keep my skin from changing those pieces of text? "Blackletter using font" compares to "Blackletter using span". Only the second one will work. Is there a way of fixing this? Especially with user signatures using <font>, this forces them to display in my set font from my css file, Times New Roman. Dustin (talk) 15:55, 15 June 2014 (UTC)

  • Please read Wikipedia:Village Pump (proposals)#RfC: Should deprecated/invalid/unsupported HTML tags be discouraged?, where there is an attempt to start a process to remove all of these deprecated and obsolete HTML elements from the wiki in as little of a jarring way as possible. — {{U|Technical 13}} (e • t • c) 17:17, 15 June 2014 (UTC)
  • AFAIK HTML attributes such as face="..." cannot be changed using CSS. The obsolete <font> element doesn't appear to support any CSS at all. The first example in your post inherits the font from your skin because of a missing "; "Blackletter using font" does work. SiBr4 (talk) 17:36, 15 June 2014 (UTC)
    • <font face="FOOBAR">...</font> can be replaced with <span style="font-family: FOOBAR">...</span>. — {{U|Technical 13}} (e • t • c) 17:43, 15 June 2014 (UTC)
Sorry to seem ignorant about this; I'm no professional when it comes to css; the most I ever learned much about was Java, a completely unrelated programming language. And Technical 13, I actually was aware of that last part, and I have modified my signature to reflect it. Thanks for the responses. I still want there to be a way for situations where another font is already used, for Times New Roman to not be used, though. I didn't know if it was possible to change my css file in some way to fix this problem, so I thought I should ask. Also, SiBr4, could you show me the "working" version of the first example then? I really don't understand exactly what you mean, sorry. Also, I didn't notice the missing quotes, but I re-added them and it still displays as Time New Roman instead of Lucida Blackletter. Have you looked at the css file of mine I linked? Thanks anyway. Dustin (talk) 19:35, 15 June 2014 (UTC)
A correctly coded element with specified font should overwrite the font used in the surrounding text: "Lorem ipsum dolor sit amet" (using <font face="Arial"> within <span style="font-family:Times New Roman">). Having looked up what Lucida Blackletter looks like, the example from my previous comment doesn't appear to display in that font, but that's probably because my browser doesn't recognize or support the font (it does work for me in the Arial example). SiBr4 (talk) 20:20, 15 June 2014 (UTC)
@SiBr4: I don't know how to resolve this issue; the outer font with "span" appears to sometimes override the inner font with "font". See these examples:
<span style="font-family:Lucida Blackletter;">One <font face="Times New Roman">Two</font></span>: "One Two" - this works as I would expect
<span style="font-family:Times New Roman;">One <font face="Lucida Blackletter">Two</font></span>: "One Two" - this does not. Dustin (talk) 20:36, 15 June 2014 (UTC)
I see everything in TNR because my browser apparently does not support Lucida Blackletter. Substituting the latter with a Lucida font Firefox can display, like
<span style="font-family:Lucida Handwriting;">One <font face="Times New Roman">Two</font></span>: "One Two"
<span style="font-family:Times New Roman;">One <font face="Lucida Handwriting">Two</font></span>: "One Two"
it works like it should for me (showing "One" in Lucida and "Two" in TNR in the first case, and the other way around in the second). SiBr4 (talk) 20:48, 15 June 2014 (UTC)
You want to show everything in TNR, unless someone uses a <font> tag or a different font in anyother way. Your * selector is to broad as it includes <font>, and therefor overrides the <font face="..."> attribute. What you want is to match the selector that sets our default font:
html, body {
    font-family: "Times New Roman", serif;
}
That should retain all custom font set in signatures etc., wether they use <font> or <span>. -- [[User:Edokter]] {{talk}} 21:37, 15 June 2014 (UTC)
Thanks; in making that change to my css file, both lines from my example work now! Thanks for the help. Dustin (talk) 01:29, 16 June 2014 (UTC)
So apparently <font> does accept CSS and CSS overrides attributes (test: <font face="Arial" style="font-family:Times New Roman;">Foo</font> → Foo displays in TNR). Thanks for clarifying that. SiBr4 (talk) 09:28, 16 June 2014 (UTC)
Correct. All (even obsolete) elements accept CSS, and CSS always supercedes old HTML styling attributes. -- [[User:Edokter]] {{talk}} 10:42, 16 June 2014 (UTC)

Tech News: 2014-25

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

Reminder

  • You can subscribe to the wikitech-ambassadors mailing list to get news more quickly and to send feedback or report problems.

Recent software changes

  • The latest version of MediaWiki (1.24wmf9) was added to test wikis and MediaWiki.org on June 12. It will be added to non-Wikipedia wikis on June 17, and to all Wikipedias on June 19 (calendar).
  • You can now read a summary of the Wikimedia technical report for May 2014.

VisualEditor news

  • You can now easily see the target of a link or other information using the context menu. [19]
  • When you edit a reference, you can now empty it and click the "use an existing reference" button to switch it to re-use another reference. [20] [21]
  • You can now add and edit {{DISPLAYTITLE}} and __DISAMBIG__ in the page settings menu. [22] [23] [24] [25]
  • The tool to insert special characters is now wider and simpler; the order of mathematical symbols is now correct. [26] [27] [28]

Future software changes

  • Media Viewer will be enabled by default on all wikis on June 19. Feedback is welcome. [29]
  • You will no longer be able to use navigation popups and Hovercards at the same time. [30]
  • You will no longer see image thumbnails on search results pages on Wikibooks and Wikisource wikis. [31] [32]
  • It will soon be possible to globally rename global (SUL) users. [33] [34]
  • Tablet users will be redirected to the mobile view of Wikimedia wikis starting on June 17. [35]
  • The special page that lists most linked-to templates will soon include pages from all namespaces; it will also be renamed to Special:MostTranscludedPages. [36]
  • An IRC discussion about Phabricator will take place on June 17 at 17:30 UTC on the channel #wikimedia-office on freenode (time conversion). You can also read a blog post about the upcoming switch to Phabricator.
  • You can now comment on the draft 2014-15 goals of the Wikimedia Foundation engineering department. [37]

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

07:13, 16 June 2014 (UTC)

The global rename news is also being discussed by stewards on m:SN. It has recently been postponed until July 1. You can read the details on MediaWiki.org. πr2 (t • c) 04:04, 17 June 2014 (UTC)

Copyrighted image upload

Is there a guide anywhere to helping to decide how to upload a coprighted image? I have found using the upload wizard disconcerting with finding the right option when I am unsure. I have also asked for help on this on the image copyright noticeboard but nobody responded. Difficultly north (talk) Simply south alt. 12:23, 16 June 2014 (UTC)

Can you explain the problem? You can only upload a copyrighted file if it will qualify as a fair use image. The current step 3 in the upload wizard has a checkbox stating
This is a copyrighted, non-free work, but I believe it is Fair Use.
What is unclear?--S Philbrick(Talk) 13:57, 16 June 2014 (UTC)
It is once I tick that box and move into the area with all the information. The image I would like to upload is an artist's impression of a future sculpture planned for the Scottish Border called the Star of Caledonia. If for example I select "This image is the official cover art of a work", do I put the Author\Owner as the Gretna Landmark Trust as I am unsure of the actual artist. The source of this particular image is from BBC News, for example but there is a similar darker image from the Gretna Landmark Trust website. Which would be the best option to select for artist's impression? The images in question, for example, can be found here or originally here.
And when it asks how the image use will be minimal, should I put that it is an artist's impression and will only be used in the article in question to show what the sculpture is designed to look like until it is actually built or along the lines of this? Difficultly north (talk) Simply south alt. 14:18, 16 June 2014 (UTC)
The place to ask these questions is Wikipedia:Media copyright questions, not here. The details of copyrights aren't technical Wikipedia issues. עוד מישהו Od Mishehu 16:38, 16 June 2014 (UTC)
Difficultly north, I don't see why you chose "This image is the official cover art of a work". That is usually for album/cd/dvd covers. Doesn't seem to be applicable. In fact, I perused the six alternatives, and do not see one that fits, leaving only option seven some other kind of non-free work.
My suggestion is to go to Wikipedia:Non-free content review, where editors experienced in the criteria can help you.--S Philbrick(Talk) 17:03, 16 June 2014 (UTC)

Finding a particular use of a parameter in a template

I noticed that Template:Geographic reference has a source listed that's obsolete. If this were a separate template, it would be simple to find but is there a way to search and find all the uses of that specific usage. This template is used in practically every single US city article, and many articles it seems, including Houston which is a featured article, have the old version and need to be updated so it is pretty important to figure it out. From Template talk:Geographic reference, there was a discussion of a bot request to do. If so, can we run it again? The latter discussion ended with a note in the documentation and no fix. -- Ricky81682 (talk) 23:19, 16 June 2014 (UTC)

Have you tried Special:LinkSearch for factfinder2.census.gov ? WhatamIdoing (talk) 23:35, 16 June 2014 (UTC)
That link goes to the actual text ones, and to both of the templated ones. I have no idea why this was done this way. I guess we could search for the text string in the wrong one. -- Ricky81682 (talk) 23:54, 16 June 2014 (UTC)
  • I think what you want is what is called an administrative category, added to the template. It will take a few hours to a couple months to filter through the WP:Job queue, but you'll find all the pages using the that parameter via the template. — {{U|Technical 13}} (e • t • c) 00:06, 17 June 2014 (UTC)

@Ricky81682: If you can spell out exactly what is wanted, I can search the database dump from 2 May 2014 and make a list in a sandbox. Johnuniq (talk) 00:14, 17 June 2014 (UTC)

All pages that have the text {{GR|R2}}, {{GR|2}}, {{Geographic reference|R2}} or {{Geographic reference|2}}. -- Ricky81682 (talk) 00:27, 17 June 2014 (UTC)
  • John, where are you going to put that? I actually just DLed the DB today and as such have a more up to data copy if you prefer I run it. — {{U|Technical 13}} (e • t • c) 01:07, 17 June 2014 (UTC)
  • I put the (big!) results in my sandbox2 (permalink). That list could be used with WP:AWB to do automated changes, if something systematic is needed.

    @T13: Thanks but I've got a few home-grown scripts for the search that are too messy to upload. My bluesky plan is to develop a WP:Labs tool that could be asked to index a particular template—it would build a database of all occurrences in articles with parameters indexed, and queries could be submitted to list various things. That's not going to happen anytime soon, unfortunately. Johnuniq (talk) 02:57, 17 June 2014 (UTC)

    A tool like that could be very useful. πr2 (t • c) 04:12, 17 June 2014 (UTC)

@Ricky81682: Did you try the TemplateTiger? I think the fantastic user:Kolossos recently moved it from the templatetiger@toolserver to TemplateTiger@tools.wmflabs.org. Try both. See for example this for dewiki. --Atlasowa (talk) 07:50, 17 June 2014 (UTC)

Technical 13 took care of it. Thanks! -- Ricky81682 (talk) 07:54, 17 June 2014 (UTC)

Template usage

I'd like to know how often {{cite doi}} is used. I am interested in both

  1. article count and
  2. total count (because it may be used multiple times on a page).

From this page I see that {{Cite doi/doc/format}} is used oin 47581 pages, while {{Cite doi/subpage}} is used on 47577 pages. I'm not quite sure why {{cite doi}} is not on the list. Is this the answer to the first part of my question? How do I get the answer to the second part?--S Philbrick(Talk) 14:18, 7 June 2014 (UTC)

  • I don't know if a data dump will give you that information or not. I don't think it does. You'd either have to have a script that pings the api for every page that uses the template and counts the instances in the wikitext source of that, or do it manually. Running a script like that would take a great deal of time (even though it shouldn't be overly difficult to write the script I suppose) and would likely hang (or appear to) your system. Would you like me to try writing you such a script? Would it be something a specific wikiproject would be interested in and would use more than once or twice, like a weekly run to update some table or something? Let me know... — {{U|Technical 13}} (e • t • c) 14:27, 7 June 2014 (UTC)
That sounds like more work than is necessary. For my present needs, I simply need a roguh number. I literaly could live with knowing how many zeros. I plan to write up a prososal, and want to say somethign like, "Wikipedia currently has roughly 100,000 usages of the template". If the real number is 200,000, it doesn't change what I have to say, but if it is 1 million or 1 thousand, it would make a difference. I was hoping that there was something that already tracked this, and I just didn't know where to look.--S Philbrick(Talk) 14:48, 7 June 2014 (UTC)
As background, my goal is to try to expand doi usage to more than just technical papers, but as part of my proposal, I'd like to cite the current usage.--S Philbrick(Talk) 14:51, 7 June 2014 (UTC)
  • According to [38] there are "16087 transclusion(s) found." (number of articles it is on directly). There is no existing tool I'm aware of that will tell you haw many times it is used on each page. You could pick 161 of them at random (1%), and average that number to get a rough estimate I guess. — {{U|Technical 13}} (e • t • c) 15:11, 7 June 2014 (UTC)
Thanks. Yes, I was thinking of doing a small sample, which will be good enough for my purposes.--S Philbrick(Talk) 17:24, 7 June 2014 (UTC)
I did a small sample, got 5.9 per page so roughly 100,000 usages.--S Philbrick(Talk) 17:47, 7 June 2014 (UTC)

You will probably want to look over the March 2014 discussion at Wikipedia talk:WikiProject Medicine/Archive 47#Replace .22cite pmid.22 with .22cite journal.22, in which people mostly said that they dislike that type of citation template. WhatamIdoing (talk) 22:20, 7 June 2014 (UTC)

Wow, I thank-you for pointing me to that discussion, but it is quite confusing. I'm not quite sure what was proposed, I am sure I don't know what, if anything was agreed to. However, I definitely did not come away with the impression that there is widespread opposition to the {{cite doi}} template. I see disagreements over horizontal versus vertical formats, and disagreement over LDR style references, but those issues are orthogonal to my interest in the doi template - I want a template which requires a single entry and fills out the full reference. We can debate where that reference appears (silly me, I think references belongs in the reference section), whether the formatting should be vertical or horizontal, whether white spaces should be included or excluded, and exactly how to format the names, but all of those issue are distinct form the concept of a citation template requiring only one parameter.--S Philbrick(Talk) 13:43, 9 June 2014 (UTC)

@Sphilbrick I have a script to search an all-pages database dump, and I have a dump from 2 May 2014. I put the (big!) results in my sandbox2 (permalink). There were 12,197 articles with 23,501 unique {{cite doi}}. 5,695 (24%) of those are repeated, giving a total of 29,196 occurrences. This is also discussed at WP:BON and WT:Template namespace. The WP:BON discussion points out that Category:Cite doi templates lists 49,409 pages—I have not looked at why that number is much bigger than mine. Actually, a lucky click might explain the answer: I noticed that one of the templates listed in the category is not in my list, and the template is used only at WP:Choosing Wisely/American College of Surgeons (my list only shows usage in articles). Johnuniq (talk) 11:32, 12 June 2014 (UTC)

Thanks for sharing those numbers. I'm slightly surprised that your implied templates per page (roughly 2) is so much lower than the (admittedly) small sample value I calculated (5.9). I briefly wondered if I were getting a non-representative sample. I reject that possibility, but perhaps it is the case. In any event, while your numbers seem a fair bit lower than my estimate, for my purposes I only need an order of magnitude number. So your results actually corroborate the conclusion that the number is more than "thousands" but not as high as "hundreds of thousands". Thanks also to User:Keith D for that discussion, very relevant to my interests.--S Philbrick(Talk) 13:06, 12 June 2014 (UTC)

@S Philbrick:

  • The Wikipedia Cite-o-Meter (provides a conservative estimate of the number of times journal articles from a particular publisher are cited in the 100 largest Wikipedias. Using the Wikipedia API, Cite-o-Meter searches for occurrences of a DOI prefix in the main namespace of these Wikipedias.)
  • The Topmost Cited DOIs on Wikipedia (Max Klein on Apr 10, 2014): "Note this analysis is strictly looking for the Cite doi template, so it doesn’t take into account DOIs that are mentioned in the Cite journal template." ... "What are the most used DOI prefixes? Below are the top 10. (...) With Elsevier dominating the top spot"... "which pages use the most DOIs? (...) The list is as you might expect is power-law distributed. In fact 60.6% of pages that have any DOI citation, have only one." etc.

I think we should be having much better stats about all refs on Wikipedia (see also my little collection at de:Benutzer:Atlasowa/ref stats with studies). refs are one of the most important quality indicators, and Wikipedia should build a reference database (across WP language versions and including wikidata)! --Atlasowa (talk) 07:27, 17 June 2014 (UTC)

Thanks for all that information. I've bookmarked the cite site. The blog post was interesting, and I am still absorbing it. I agree we ought to have a refernces database. I haven't been very involved in wikidata, my guess it is on their list.--S Philbrick(Talk) 12:37, 17 June 2014 (UTC)

Weird pageview statistics

I'd previously asked User:Henrik, but he doesn't seem to be currently available.

I noticed some weird entries in the popular pages tool's May listing for Thailand, and checked the pageviews statistics tool and it also showed abnormal spikes for the Thailand women's national football team article on 21–22 May and for the Bhumibol Adulyadej article on 12 May. (The same issue affecting a user page was mentioned at User talk:Cunard#Weird pageview stats.) Any idea what's going on? --Paul_012 (talk) 08:58, 13 June 2014 (UTC)

Earlier today, someone inquired about the User_talk:Cunard case in the Wikimedia Analytics IRC channel (see #wikimedia-analytics log from 16:22). I never got an email about it, but it seems to have started on that page sometime between December 2012 and January 2013. These hits are almost surely from an automated script or bot of some sort. I recommend you contact the Analytics team. I see you have already asked stats.grok.se's owner Henrik (though he likely does not know exactly where these are coming from). πr2 (t • c) 04:24, 17 June 2014 (UTC)
See post by Ironholds below. πr2 (t • c) 11:22, 18 June 2014 (UTC)

broken redirects are transcluded

If a page transclude a template which is a broken redirect, then the page will transclude the content of the broken redirect. I dont think that was an issue before the content of redirect was shown on the redirect page itself. See List of members of the European Parliament for Portugal, 2009–14 (its has category:Redirects from moves and category:Redirects for discussion too). The reason is that Democratic_and_Social_Centre_–_People's_Party is RfD. Is it a bug or a feauture? (should RfD be noincluded?) Christian75 (talk) 06:41, 16 June 2014 (UTC)

I can't make sense of what you're saying. None of the pages you linked to are broken redirects. Jackmcbarn (talk) 17:02, 16 June 2014 (UTC)
What Christian75 means is that on the rows for Diogo Feio and Nuno Melo, in the second column, the Wikicode has {{colorbox|{{Democratic and Social Centre – People's Party/meta/color}}}} but the intended redirect at Template:Democratic and Social Centre – People's Party/meta/color is not being followed, instead, the page is being transcluded including the RfD notice, the broken redirect directive, and the {{R from move}}. It is that last template that is producing the unwanted categorisation. This is not a bug, but is expected behaviour if the #REDIRECT [[]] is not the first item on the very first line. --Redrose64 (talk) 17:38, 16 June 2014 (UTC)
Redrose64 - It didnt work that way before redirect pages displayed its content. Check this real broken redirect, {{User:Christian75/test-pump}}: Christian75 (talk) 20:14, 16 June 2014 (UTC)
  • Is it still broken? I fixed the page based on what Redrose64 said (put the redirect itself back on the top line and the RfD notice after it) and it seems to be working fine to me... — {{U|Technical 13}} (e • t • c) 20:45, 16 June 2014 (UTC)
  • but thats not the point... The documentation of RfD says "This template must be placed above the redirect; otherwise, the page will redirect as normal and users of the redirect will not be informed of the nomination." - it worked a few month ago... Christian75 (talk) 21:13, 16 June 2014 (UTC)
For clarification, User:Christian75/test-pump is a broken redirect, and Democratic and Social Centre – People's Party isn't a redirect at all. Transclusions of either of these appear to function normally. Jackmcbarn (talk) 04:16, 17 June 2014 (UTC)
@Jackmcbarn: The problem wasn't with Democratic and Social Centre – People's Party but with Template:Democratic and Social Centre – People's Party/meta/color. It was a functioning redirect, until that RfD notice got added before the #REDIRECT [[Template:CDS – People's Party/meta/color]] with this edit. Adding anything at all - whether plain text or a template - before the #REDIRECT means that the page is no longer a redirect, but a normal page, the whole of which gets transcluded by markup such as {{Democratic and Social Centre – People's Party/meta/color}} Since it's treated as a normal template, not a redirect, any templates on that page get expanded, and the transclusion therefore includes any categorisations made by those templates, which is why the article List of members of the European Parliament for Portugal, 2009–14 was appearing in Category:Redirects for discussion (because of the {{Rfd/core}}) and in Category:Redirects from moves (because of the {{R from move}}). --Redrose64 (talk) 11:00, 17 June 2014 (UTC)
I got that much. I just had (and still have) no idea why broken redirects were ever brought into the discussion. Jackmcbarn (talk) 16:06, 17 June 2014 (UTC)

"Stranded" on IP User Talk Page

What I am about to describe has happened several times today. I see a red link for an IP address talk page, which means that the user has not received any traffic. I click on the red link and am taken to the empty talk page. I use Twinkle to welcome the IP with a template suggesting creating an account. Then I click on the Back button to go back to the talk page that the IP had been editing or the history that I had been viewing. Nothing happens. The Back button doesn't take me back. I am "stranded" on the IP talk page. I have to type in the previous page, or go to my Watchlist. I know that in the recent past I did not have this problem. Does anyone have any suggestions? By the way, I am using Firefox 30.0. Robert McClenon (talk) 22:56, 16 June 2014 (UTC)

What happens if you right-click the "back" button? In FF this should give a trail of the most recently visited pages (up to 50 are stored, although often only the last 10 are shown). Can you select from that list? --Redrose64 (talk) 23:07, 16 June 2014 (UTC)
  • It is because you visit the page, you edit the page (via twinkle) and it is reloaded. This first click of back is taking you back to the IP's talk page at a time before you welcomed them with Twinkle (although it may not be updating what you see, because it realizes the url is the same). What you need to do is hit back twice (or maybe three times) and you will get back there. — {{U|Technical 13}} (e • t • c) 00:01, 17 June 2014 (UTC)
I tried hitting back two or three times and it didn't work. Maybe I should have tried four or five times, but that would be tedious. Right-clicking the back button does work. Robert McClenon (talk) 20:07, 17 June 2014 (UTC)

Incorrect ref formatting

Hi Guys, I have been trying to clear some of the backlog on Pages with incorrect ref formatting and am stuck with regard to Portal:Northern Ireland it appears on the listing and has no such notice either on the page or in the hidden cats, can one of you boffins help? cheers The Original Filfi (talk) 09:37, 17 June 2014 (UTC)

I don't see it in that category at all, so the problem appears to be resolved. {{Nihiltres|talk|edits}} 14:55, 17 June 2014 (UTC)

Searching "View history"

Is there a gadget that can search for a particular set of words within a parameter of revisions listed on the "View history" pages as a whole, i.e. a global search within that parameter? Or can a search only be done by calling up each revision separately and then doing the search? Trying to pinpoint when a particular set of words has been changed/deleted can be like looking for a needle in a haystack. --P123ct1 (talk) 09:48, 17 June 2014 (UTC)

A tool called "Revision history search" is linked from all history pages. Matma Rex talk 09:57, 17 June 2014 (UTC)

I have never understood this tool properly. Take the wording at the bottom of the page after the search has been done. What does - as an example - "Comparing differences in [time&date] between 5 and 6 while coming from 9.00 [Search from here]" mean? --P123ct1 (talk) 12:37, 17 June 2014 (UTC)

That's just the tool describing how the iterative search was done. –xenotalk 12:43, 17 June 2014 (UTC)

Then why does it give options, in the example I gave, to click on the date and "Search from here"? And what does "5 and 6 while coming from 9.00" mean? --P123ct1 (talk) 14:32, 17 June 2014 (UTC)

The system uses a binary search by default, which is where the numbers are coming from. The idea is to halve the number of revisions to search, making the search much faster than a linear one. You take the list of revisions and divide it in half, then try to determine if your change is in that half-list. If it isn't, you try the other half. If it is, then you halve the half-list into a yet smaller list and search again, and eventually you'll find the single revision with the change, or decide that it isn't present. {{Nihiltres|talk|edits}} 15:18, 17 June 2014 (UTC)
  • I've tried to use that tool in the past. That tool's UI needs a thorough workover to make it intelligible to ordinary people. 86.179.5.128 (talk) 00:25, 18 June 2014 (UTC)
If you want an easier-to-understand GUI, you might also give this a try: https://tools.wmflabs.org/xtools/blame/?style=new .(new style will be default in a few days). --Hedonil (talk) 13:55, 18 June 2014 (UTC)
  • @Hedonil: Thanks! I was just getting the hang of the other method, but this tool looks much simpler to use. --P123ct1 (talk) 20:12, 18 June 2014 (UTC)
  • @Hedonil: It works like a dream! --P123ct1 (talk) 00:18, 19 June 2014 (UTC)

Page view stats

Page view statistics not working. Any chance someone could put another coin in the meter? 86.179.5.128 (talk) 00:23, 18 June 2014 (UTC)

Auto archive hasn't kicked in...

...on Talk:Pro-ana. Did I mess up something with the template?-- Brainy J ~✿~ (talk) 02:41, 18 June 2014 (UTC)

  • Should be fixed and archive on it's next pass. Which may or may not be tomorrow. — {{U|Technical 13}} (e • t • c) 02:54, 18 June 2014 (UTC)
Thanks. I think I see what I did wrong now. I goofed and specified a completely different talk page.-- Brainy J ~✿~ (talk) 13:26, 18 June 2014 (UTC)

Edit conflict reports when I've saved

For some time now I've noticed that I occasionally get edit conflicts when I save - ie I try to save, I can't because of an edit conflict, I go out of the page and see my edit has been saved. Using Chrome. Dougweller (talk) 09:04, 18 June 2014 (UTC)

Maybe "occasionally" is the wrong word as it happened with this edit and my last talk page edit. Dougweller (talk) 09:07, 18 June 2014 (UTC)
I occasionally get it, when I think I clicked on the "Save" button, nothing happens, and I click again. עוד מישהו Od Mishehu 09:15, 18 June 2014 (UTC)
Might be related to bugzilla:56849. --AKlapper (WMF) (talk) 10:00, 18 June 2014 (UTC)
Possibly. It's certainly a pain! Dougweller (talk) 18:11, 18 June 2014 (UTC)

Size of the DB, but latest revisions only

Is there a report anywhere showing the size of the en.wp database, but only including the latest revision of each page? That would be an interesting measure of the "real" size of the project. — Scott • talk 09:17, 18 June 2014 (UTC)

Dumps.wikimedia.org shows the compressed size of various dumps from en.wp. The main one "enwiki-20140614-pages-articles.xml.bz2" has the current version of every page, excluding the user namespace and all talk namespaces, and excluding all images. That's 10.2 GB, and it expands to 45.3 GB. -- John of Reading (talk) 09:39, 18 June 2014 (UTC)
Great, thanks. I see the dump formats are explained here. — Scott • talk 14:02, 18 June 2014 (UTC)T

Module redirects?

Is is possible to have Redirect pages in the Module namespace? E.g. if I make Module:F → Module:G, then:

  1. Will {{#invoke:F|ψ}} work the same as {{#invoke:G|ψ}}?
  2. Will typing the internal link [[Module:F]] correctly take people to Module:G?

It Is Me Here t / c 11:57, 18 June 2014 (UTC)

Sort of. You can create Module:F with the code:
return require('Module:G')
Then {{#invoke:F|ψ}} will work the same as {{#invoke:G|ψ}}, but [[Module:F]] won't take people to Module:G, as it is using a Lua "redirect", rather than a MediaWiki redirect. — Mr. Stradivarius ♪ talk ♪ 12:21, 18 June 2014 (UTC)
The problem with MediaWiki redirects right now, is that they can only be defined in wikitext, not in JS, CSS or Lua. Maybe at some point in the future, we can move that into the UI of mediawiki, and kill the dependency on wikitext. But right now, the above solution is the best approach, and actually fairly lightweight. —TheDJ (talk • contribs) 14:23, 18 June 2014 (UTC)
OK, thanks! It Is Me Here t / c 14:37, 18 June 2014 (UTC)

Redirecting a category on MediaWiki software

Just a heads-up, an editor is asking for assistance regarding a personal project using MediaWiki software. The original posting can be found here. Kurtis (talk) 20:29, 18 June 2014 (UTC)

Tool for Page →History → Contributors

Tracked in Phabricator
Task T60869

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

You could use XTools - and if you like it, it's new gadget-helper. Migration from toolserver is done and I'm about to put the finishing touches on it. Hope you like it. --Hedonil (talk) 00:09, 11 June 2014 (UTC)
XTools is pretty neat . I see what I'm looking for. It's the Page History tool at XTools, which gives a pretty awesome account. And scrolling down to the bottom, I see the information Contributors tool used to give. XTools Page History is way more cool and informative than the old tool was.— Maile (talk) 11:58, 11 June 2014 (UTC)
Also, I following your instructions on adding this as a Gadget, and now I see the stats showing at the top of my article pages. Thank you so much. — Maile (talk) 12:09, 11 June 2014 (UTC)
Very nice.--S Philbrick(Talk) 17:40, 11 June 2014 (UTC)
  • Yeah, when is the old "Contributors" thing coming back? pbp 04:03, 12 June 2014 (UTC)
Ditto, this is a useful feature.--♦IanMacM♦ (talk to me) 06:38, 12 June 2014 (UTC)
See also Wikipedia:Village pump (technical)/Archive 126#Contributors to a Wikipedia page, and probably a couple of others. As I understand the situation, the actual "problem" is that volunteers can't be forced to port their tools to WMFLabs if they don't want to (and I'm not sure that the independence of volunteers is truly a "problem" in the end, although this particular volunteer's choice is inconvenient for me, too). WhatamIdoing (talk) 18:14, 12 June 2014 (UTC)
And to add on to what WhatamIdoing said, these topics also don't encourage these volunteers to do it either. Why not go to their page and say "I really love your tool, it's super useful, we appreciate your technical expertise, and value your time on this project. Could you please migrate? We promise Wiki-cookies". That'll do 1 x 10 ^ 6 more towards getting them to actually do it than complaining here and calling them out. From a tool owner perspective, it essentially feels like being called lazy and you come off as unappreciative.--v/r - TP 18:44, 12 June 2014 (UTC)
I'm not sure which one of us on this thread you are referring to. However, my initial question was because I have no idea who maintains or created a lot of those tools on page history. — Maile (talk) 19:03, 12 June 2014 (UTC)
It's really directed at anyone who has ever come here for a tool written by a volunteer - ever :). That particular tool is run by meta:User_talk:Duesentrieb.--v/r - TP 19:16, 12 June 2014 (UTC)
I left a note on Duesentrieb's talk pages - both the English page and the German page. And I found a few notes by other people. Perhaps if enough of us ask, it will eventually be fixed. Dirac66 (talk) 20:01, 13 June 2014 (UTC)
Article Info is also a good tool.--v/r - TP 22:08, 13 June 2014 (UTC)

Solution found

Thanks very much to TP for suggesting Article Info! This leads to a form which says "Page history - Get various statistics about the history of a page", so I tried the Revision history statistics link on an article History page, and found an even more direct route to the List of contributors, now called Top Editors.
So my directions would be - choose any article, go to the History page and click on Revision history statistics, then scroll down to Top editors. True, the list doesn't include the least frequent editors with 1 or 2 edits, but one can still check for any single editor's contributions by using Edits by user. Dirac66 (talk) 19:41, 14 June 2014 (UTC)
That's the XTool that Hedonil mentioned above, which you can add this as a Gadget. There's a draw-back to the XTool, I'm just noticing. It only gives the select "top" editors, not all of them. That's very limiting on many articles. While I like the XTool, I'd really like to have the old one working. Sometimes there is a need to see ALL the contributors of an article, in particular the IPs. — Maile (talk) 22:13, 14 June 2014 (UTC)
I've added a line to topeditors section which now shows the number & count of all other editors (besides the top 30) - and a link that provides an extra url-parameter editorlimit for more results. This value decuples on each more call (30, 300, 3000 ...), or you can set it by hand. This way, you have free choice on how many rows you want to retrieve. --Hedonil (talk) 15:49, 17 June 2014 (UTC)
Excellent. I think that with these more calls, Revision history statistics now provides all the information formerly given by List of contributors plus a lot more. The only remaining problem I see is that many people don't know where to look, since List of contributors still leads to the wrong form. Would it be possible to put some sort of redirect on List of contributors, so that it leads to Revision history statistics? Dirac66 (talk) 19:43, 17 June 2014 (UTC)
Thank you, Hedonil. I just discovered this tool has been substituted for the old one under the Article history "Contributors". And I do see where you added the extra "more" so we can see all the editors. This tool is awesome. Thank you for all the time you spent developing it and deliverng it to us. — Maile (talk) 21:38, 19 June 2014 (UTC)
Well...Labs now says there's "no service". Let's hope that's temporary, because the little gadget for the XTool is not functioning right now, either. — Maile (talk) 21:43, 19 June 2014 (UTC)
Labs and the gadget back to normal now. So thanks again for this tool. — Maile (talk) 22:11, 19 June 2014 (UTC)

Posting data a diff from an external site

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

Click here for an example: [39].

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

This is what my bot is submitting:

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

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

Strange. It seems that show changes may be broken. πr2 (t • c) 00:59, 16 June 2014 (UTC)
Try adding wpUltimateParam. πr2 (t • c) 01:44, 16 June 2014 (UTC)
Tried, no dice.   Magog the Ogre (t • c) 21:32, 16 June 2014 (UTC)
Perhaps you need an edittoken in order to send the diff nowadays. In general I would say, it's either an encoding mistake, or you are just missing too many of the fields. —TheDJ (talk • contribs) 09:24, 17 June 2014 (UTC)
  • "Cleanup v2" works for me, but there are character set problems with some files. Note that "cleanup v2" sets wpDiff to "Click me if you have JavaScript disabled", not "wpDiff" as you wrote above. --Stefan2 (talk) 21:18, 19 June 2014 (UTC)

New mobile site for tablets

 
Screenshot of the new tablet look

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

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

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

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

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

If I now visit an en.m. URL in my desktop browser, will I see the tablet or phone version? How may I switch to the other? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:20, 18 June 2014 (UTC)
Hi Andy – it's based on your browser window screen size. If it's larger than 768px by 768px, you get the tablet view, but if you shrink the window below those dimensions, you get the phone view. You can play around with resizing the window to see the changes between the two :) Maryana (WMF) (talk) 17:23, 18 June 2014 (UTC)
I am using Wikipedia on an iPad mini. I always want to see the desktop site, never the mobile site. Is there any way to achieve this without having to now scroll down to the bottom of the page and select desktop every single time I visit Wikipedia ? Can I opt out of the mobile version in some way ? Gandalf61 (talk) 06:31, 20 June 2014 (UTC)
You can opt out by clicking the 'Desktop' link at the bottom; a cookie will remember your preference. If you do get the mobile site again, check if cookies are not blocked, and your bookmark is not set to go to 'en.m.wikipedia.org'. -- [[User:Edokter]] {{talk}} 10:06, 20 June 2014 (UTC)

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

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

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

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

In my professional capacity I'm the person actually rewriting the pageviews definitions, so:
  1. This is a problem. I'm going to kick people internally to send him a note since, given that we bought him a new machine for the service, he should presumably want to reply to us. It could just be a TZ thing, though.
  2. I have been investigating a similar problem reported by User:Gigs and User:PiRSquared17; having gone through the request logs of a page they highlighted, I'm pretty sure it's a bot attack wide disparity in IPs, circular referer chains and a single point of commonality in user agents - that most of them are on Windows XP. We're talking through ways of detecting this in the future.
  3. Yes, it'll absolutely include mobile pageviews, if by that you mean 'pageviews through the mobile site'. Splitting out tablets versus phones on a per-article basis is potentially a pain, but it'll certainly be investigated. We're also looking at distinguishing different types of views: so, you'd have X pageviews, Y history pageviews and Z talkpage page views, or something. We'll see. Ironholds (talk) 05:25, 18 June 2014 (UTC)
  • Are hits from search engines crawling Wikipedia still included? Is there any kind of estimate of how many page hits these are likely to contribute? I seem to remember from a previous discussion that search engine hits could be a significant fraction of total hits for low-visited pages. I would like to see a disclaimer, or some information about this, on the page view statistics page. Sometimes people say "look, people do read this article, there are around 50 hits every day", but if 49 of those are non-human then it's misleading. 86.179.4.47 (talk) 13:25, 18 June 2014 (UTC)
    They are, in some form. We have a relatively crude regular expression currently identifying spiders, although what happens to the spider after it's been identified is unknown to me. This is also something we're factoring into the newer version (we have a user agent parser now, which means we can exclude/specially identify and segment hits from spiders). Google, at least, is sensible about their crawling, and pairs crawls of a page with edits to that page. Ironholds (talk) 16:36, 19 June 2014 (UTC)
I'm puzzled by your last sentence. I wonder if you could explain that a little further? Surely you are not suggesting that Google's search engine edits Wikipedia pages?? 86.179.119.9 (talk) — Preceding undated comment added 17:31, 19 June 2014 (UTC)
I'm assuming that Ironholds mean Google is accessing the edit page during its crawling of the Web; by "clicking" all the links on the page it will eventually "click" the edit button. It does not edit pages. -- 140.202.10.134 (talk) 19:32, 19 June 2014 (UTC)
Neither, actually (although we do have edits that claim to be from google bot, because there are a couple of users who (a) spoof their user agent and (b) think they're a lot funnier than they actually are). So, google has a bot built just for crawling Wikimedia sites. We have millions (or billions?) of pages, some of which change very rarely, some of which change very statically; crawling them all, constantly, would be untenable, and crawling them all in one big load once a month would lead to outdated information about things people care the most about. Instead, google's bot crawls the recentchanges feed; when it sees a new entry, it goes to that article, and crawls it, and caches the results. That way things are always pretty much up to date, but google doesn't have to crawl every article - just the ones being updated. Ironholds (talk) 23:12, 19 June 2014 (UTC)
Thanks, that's interesting to know ... 86.179.119.9 (talk) 01:02, 20 June 2014 (UTC)

Magic word for Wikidata ID?

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

The nearest thing I could find was {{PAGEID}}, but I'm not sure that's the same thing. It Is Me Here t / c 12:01, 18 June 2014 (UTC)
No, the page ID isn't the same thing as the Wikidata item ID. And Andy, I assume that you want the item ID (e.g. "Q142" for France) rather than a property belonging to an item (e.g. Q142's property P36, the capital, is "Paris"). You can get the item ID by using Module:Wikibase:
  • {{#invoke:Wikibase|id}} → Script error: No such module "Wikibase".
That only works for the current page. Also, it doesn't appear to be documented either on the module page or at mw:Extension:WikibaseClient/Lua. The Lua part of the Wikibase extension is being rewritten, so there is a chance this functionality might be removed at some point (I'd have to ask the developers to find out for certain what's happening to it), but it works for now. — Mr. Stradivarius ♪ talk ♪ 12:55, 18 June 2014 (UTC)
I'll also note that if you have the XTools gadget installed, the link to See full page statistics shows the Wikidata ID (Might not help for a template, but other readers might be interested)--S Philbrick(Talk) 18:48, 18 June 2014 (UTC)
It is also listed in the "page information" link on the left-hand panel. --Mdann52talk to me! 21:43, 18 June 2014 (UTC) ← Thanks. --User:Ceyockey (talk to me) 23:30, 18 June 2014 (UTC)
@Mr. Stradivarius:} Thank you, I'll give that a try. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:15, 18 June 2014 (UTC)
Now working, on {{Gender unclear}}. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:25, 19 June 2014 (UTC)

Watchlists

Tracked in Phabricator
Task T33881

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

You can have many pages on your watchlist and choose to only see the most recent edit on each. See Help:Watching pages and Special:Preferences#mw-prefsection-watchlist. PrimeHunter (talk) 09:35, 19 June 2014 (UTC)
AFAIK the default setting is to only show the latest edit to each page on watchlists (but obviously not on page histories). The preference to change this is called "Expand watchlist to show all changes, not just the most recent" in the "Watchlist" tab (direct link in previous comment). The advantage of a watchlist is that you can keep track of many pages in one list; if you are watching only one page it's essentially the same as that page's history. SiBr4 (talk) 11:08, 19 June 2014 (UTC)

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

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

Poor search suggestions in search box

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

I believe the algorithm looks at the "what links here" figures to work out which articles are most popular. Bakhsh and Iran Standard Time are linked from the infobox of just about every Iranian place name article (example). The algoithm isn't clever enough to see that these links are not important. -- John of Reading (talk) 21:23, 19 June 2014 (UTC)
Hmm...if suggestions are based solely on the popularity of links, I wonder if it'd be worth considering ignoring links that are a result of template transclusions? ~SuperHamster Talk Contribs 21:26, 19 June 2014 (UTC)
Accurately discounting links arising on transcluded templates from a count of 'what links here' is a rather difficult and expensive operation. However, having generated the most wanted lists for years, I do have a fairly efficient approximation that works well if this is useful - posted at Wikipedia:Most-wanted articles/wantedness.sql in case it it useful. - TB (talk) 21:41, 19 June 2014 (UTC)

Any changes to the Watchlist?

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

You're a little out of date. We're at 10.9, 10.10 if you use the beta OS, at this point.—cyberpower ChatOnline 00:56, 20 June 2014 (UTC)
Thanks, C678, there there are good reasons to remain with system 10.6.8 for the time being as a lot of Apple users do because it was the last version with Rosetta. But I did not ask about that. I asked about the changes that have obviously taken place. Any hint?--Aschmidt (talk) 12:52, 20 June 2014 (UTC)
And those might be good reasons, but that doesn't make it easier to solve your problem. Lots of stuff changes every week, yesterday some 238 changes went live. To find out where something went wrong, it is needed to reduce the footprint significantly. That means disabling all your gadgets etc and see if you still have the problem, trying with a 'clean' account, trying with a different browser etc. The more outdated your browser, the more work you probably have to put into it yourself to keep it somewhat working, because rare browsers are harder to support. New versions of Google Chrome still run on 10.6. If you can't migrate away from 10.6 you at least might consider migrating to a newer browser that is available for the platform. —TheDJ (talk • contribs) 13:24, 20 June 2014 (UTC)

Issues using Recent Changes

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

Summary:

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

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

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 ♪ talk ♪ 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 ♪ talk ♪ 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 ♪ talk ♪ 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 ♪ talk ♪ 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 ♪ talk ♪ 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 ♪ talk ♪ 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? —[AlanM1(talk)]— 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)? —[AlanM1(talk)]— 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. -- [[User:Edokter]] {{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. -- [[User:Edokter]] {{talk}} 12:18, 21 June 2014 (UTC)
...and that is what has now been done to fix the problem. —[AlanM1(talk)]— 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 Wikipedia

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

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. [41] (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 Wikipedia:WikiProject Countering systemic bias. --Piotr Konieczny aka Prokonsul Piotrus| reply here 09:11, 22 June 2014 (UTC)

Cross site communication with ToolLabs from Wikimedia

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

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)

Javascript warning boxes

  Resolved

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

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

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

Redrose64: It seems to be from Template:Editnotices/Page/MediaWiki:Geonotice.js, or at least the exact same text is there, and the box has class="plainlinks fmbox fmbox-editnotice". If so, the <b> issue is due to an unclosed ''' in the template:Jay8g [V•T•E] 16:35, 22 June 2014 (UTC)
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/wiki/Felipe_VI_of_Spain will automatically jump to https://en.m.wikipedia.org/wiki/Felipe_VI_of_Spain

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

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

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

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

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

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

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 Wikipedia: namespace, which contained the word "review" in their title. Is there any sort of advanced search page which lets me do that? -- RoySmith (talk) 23:32, 22 June 2014 (UTC)

I found something at Wikipedia:Tools#User edit counts and analysis that almost does this - results. That's a list of edits, not of pages, so there are some duplicates, but it's close. -- John of Reading (talk) 07:01, 23 June 2014 (UTC)
@RoySmith: Try searching for Wikipedia:intitle:review. — This, that and the other (talk) 12:12, 23 June 2014 (UTC)

Mobile Browsing Issues

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

@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 (Speak to me,Stuff I've done) 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-Wikipedia wikis on June 24, and to all Wikipedias on June 26 (calendar).

VisualEditor news

  • You can now drag-and-drop selections of content, not just files and templates. [43] [44]
  • When dragging an item, you will now see a line that helps you to drop it. [45] [46]
  • 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. [47] [48]
  • You will now be warned if you add wikitext to file captions and references. [49] [50]

Future software changes

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

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

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)

Technical input requested

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

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)

IP disruption proposal

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

I think it is a marvelous suggestion for lessening disruption by IP-hopping vandals. Binksternet (talk) 16:36, 15 June 2014 (UTC)
Well first of all, people can choose not to have cookies enabled of course. Plenty folks do that. Second a browser cannot easily return the MAC address in a cookie. If that was possible, advertising agencies would have a field day. Lastly, cookies expire at some point and can be deleted by users, killing your tracker. Also it might conflict with our current privacy policy (not sure). —TheDJ (talk • contribs) 17:11, 15 June 2014 (UTC)
Cookies may not be the best method of retrieving the MAC address, I don't know, that's why I am asking for technical review. Perhaps I ought just to say what we want to achieve and leave it to the devs to find a method. However, I don't think a user clearing out cookies would be a problem. The history associated with that MAC will still be there on the server and the server will place a new cookie the next time that machine tries to edit. The new edits will still be added to the right history. SpinningSpark 17:26, 15 June 2014 (UTC)
It is not possible to retrieve the MAC address via the web browser without the use of custom plugins, even if it were possible MAC addresses are modifiable, and even if they weren't this is most likely not going to fly with Wikimedia Foundation's privacy policy. Matma Rex talk 17:33, 15 June 2014 (UTC)
I can't see what the privacy issue is. Hiding the IP address is improving privacy, not breaching it. I also don't understand why access to the MAC address is a security issue, but I expect there is a good answer to that. If it is technically impossible then it is a dead idea anyway, but before I let go of it altogether, this forum suggests that it might be possible with Java or signed Javascript. I appreciate that MAC addresses can be spoofed, but I am not looking for something that is completely unbreakable; we are not guarding nuclear secrets here. Yes, a MAC address can be spoofed, but it is not as easy as getting a new IP from an ISP that dynamically allocates them on each connection. This would be putting one more obstacle in the way of the trolls, most of whom are amateurs and would be stopped by this. SpinningSpark 19:56, 15 June 2014 (UTC)
This just isn't technically feasible. There's no way that the developers would ever go for running signed JavaScript or a Java applet just to retrieve a user's MAC address. Jackmcbarn (talk) 20:09, 15 June 2014 (UTC)
Humour me for a moment. What are the difficulties? SpinningSpark 20:29, 15 June 2014 (UTC)
Using JAVA to achieve this, is like attaching an unreliable Tank to a bike, when you are competing in the Tour de France. You just don't do it. —TheDJ (talk • contribs) 00:42, 16 June 2014 (UTC)
I'm pretty sure the JavaScript part is untrue, or at least I don't know of any API that would allow this (and the post doesn't mention any either). It might be possible with Java applets (I'm not experienced enough in this to know for sure), but wouldn't be feasible because a) signing applets is apparently non-trivial and unsigned ones pop up huge red warnings in browsers, b) Java security vulnerabilities appear often enough that browsers often automatically disable the plugin even if it's installed, but outdated, and updating it is not straightforward, and c) these days people very often[citation needed] don't even have Java installed (assuming their device can even run it), as it's been largely displaced by Flash and HTML5 for web usage. (The Java applet page is an interesting reading, although it seems outdated by a year or two.) Matma Rex talk 01:18, 16 June 2014 (UTC)
I mostly meant the part about cookies when I mentioned the privacy policy, I vaguely recall that there used to be some rather draconian limits on cookie usage and expiration defined there (IIRC this was the reason why the login cookies used to expire in 30 days), but they seem a bit more lax these days (wmf:Privacy_policy#Information_We_Collect, wmf:Privacy_policy/FAQ#cookieFAQ). If we were to identify users by their MAC addresses (which is probably not possible and definitely not feasible), this would surely have to be incorporated there as well. Disclaimer: I am, obviously, not a lawyer :) Matma Rex talk 01:18, 16 June 2014 (UTC)
Without some other unique, system-based, non-spoofable identifier it would be inappropriate to hide the IP address for the record of any such edits.
However, the issue of obtaining the MAC address is something of a red herring. While it would be nice to have a non-user-changable method of uniquely identifying the machine from which edits were being made, having a way to uniquely identify the hardware does not appear reasonable. On the other hand, just having the servers assign a unique code to the machine in a cookie, even if the code is only valid for a set period of time (e.g. 30 days), could go a long way toward tracking vandals across IP changes. Alternately, the cookie could just record the IP addresses from which the non-logged-in editor has been editing. These could be checked against being blocked and if the majority are blocked then edits are disallowed. Obviously, the vandal could just disable cookies, or delete the cookie. While it would be possible to require cookies be enabled in order to edit as an IP, that is probably not a good idea. Limiting it to a just a cookie without unique physical machine ID allows for the possibility of multiple user accounts on the same machine (e.g. a family's shared computer).
Basically, there are multiple ways in which it would be possible, although imperfectly, to determine that IP edits are being performed by the same machine/user from different IP addresses. Using just cookies is imperfect, but would probably hinder, or at least make life a bit less convenient for, a significant percentage of vandals. — Makyen (talk) 02:07, 16 June 2014 (UTC)
I like the idea that a Wikimedia-centric cookie would assign a unique identifier, the cookie lasting 30 days. Such a feature would catch many of our vandals and socks, despite some of them being savvy enough to employ a workaround. Binksternet (talk) 05:03, 20 June 2014 (UTC)
At a time when the continual decrease in editors, and the lack of new editors, is an increasing problem, is trying to make things less convenient for IP editors and raising barriers to those first few edits really a big priority? Solutions such as "requiring cookies be enabled to edit as an IP" suggest that IP hopping to edit anon is more of a problem than IP hopping to better manage a sock farm without alerting checkuser. Is that really the case? And once you're positing a troll who is deliberately IP-hopping in order to persistently vandalise and disrupt, the idea that a cookie is going to even inconvenience them is silly. 86.129.13.205 (talk) 18:11, 24 June 2014 (UTC)

Random file tool returns files from Commons

Tracked in Phabricator
Task T68643

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

Filed as bugzilla:66643. NEverett (WMF) (talk) 19:41, 15 June 2014 (UTC)
I'm pretty sure you rock :D Thanks! --Gikü (talk) 19:55, 15 June 2014 (UTC)
Should be fixed in gerrit:139833 by Manybubbles aka NEverett (it now has code to restrict results to the local wiki). It should have also fixed an issue where Special:Random/Talk, /User, etc. did not always forward to the correct namespace, and added Selenium tests for good measure. Thanks NEverett (WMF)! πr2 (t • c) 04:08, 17 June 2014 (UTC)
Just pushed the fix live a few minutes ago. Please let me know if you notice anything funky.NEverett (WMF) (talk) 15:20, 17 June 2014 (UTC)

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

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

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

Sysops stats

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

I'm pretty sure that equivalent tools on labs already exist, but I don't know what they're called. I do know that some pages which show adminstats info are generated from data on Labs, so you could ask JamesR (talk · contribs) - operator of AdminStatsBot (talk · contribs) which updates WP:ADMINSTATS, or Cyberpower678 (talk · contribs) - operator of Cyberbot I (talk · contribs) which updates subpages of Template:Adminstats. --Redrose64 (talk) 09:21, 22 June 2014 (UTC)
I'm not too sure if that user has migrated their scripts to Tool Labs yet. I will sought the license and set up a clone if I am able to obtain the script. I'll get back to you. — JamesR (talk) 10:25, 22 June 2014 (UTC)
As a quick fix, I've added some AdminStats to XTools. Currently fixed to a period of the past 365 days, but I hope it serves the purpose. --Hedonil (talk) 05:01, 23 June 2014 (UTC)
@Hedonil: thanks, yes, it is what I wanted to see, but of cource it would be nice, if the all-time stats would be enabled. --84.245.230.150 (talk) 09:06, 24 June 2014 (UTC)
See also no:Spesial:Prefiksindeks/MediaWiki:Gadget-show-sysop-activity. Helder.wiki 13:31, 23 June 2014 (UTC)

I keep getting an error when going to edit a page

 

Our servers are currently experiencing a technical problem. This is probably temporary and should be fixed soon. Please try again in a few minutes.

If you report this error to the Wikimedia System Administrators, please include the details below.

Request: GET http://en.wikipedia.org/w/index.php?title=Category:Water_in_Texas&action=edit, from 10.128.0.110 via cp4010 frontend ([10.128.0.110]:80), Varnish XID 83774727

Forwarded for: 67.160.184.158, 10.128.0.110

Error: 503, Service Unavailable at Sun, 22 Jun 2014 23:51:08 GMT

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

@Lestatdelc: This sort of thing happens every so often, last reported at Wikipedia:Village pump (technical)/Archive 127#Unstyled and non-loading pages and see WP:WFEM. If you get this error when starting to edit a page, then generally, all you need do is try again a minute or so later; if that fails three times (three minutes), wait a longer period (ten minutes); if you still can't edit after 30 mins or so, file a bugzilla ticket. When doing that, be sure to tell them when the problem started; if it affects all pages, all pages in a given namespace (specify which ones), or just a few pages (specify which ones). --Redrose64 (talk) 09:18, 23 June 2014 (UTC)
Thanks. It was doing it for over an hour before I posted here about it, but seems to work today. That said, there still doesn't seem to be clear where you are supposed to actually report it. Where is the contact info for Wikimedia System Administrators (if future issues arise that don't get fixed within 30 mins.? Lestatdelc (talk) 01:16, 24 June 2014 (UTC)
As I say, bugzilla:. --Redrose64 (talk) 08:50, 24 June 2014 (UTC)

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

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

html tags in PC error popup

Tracked in Phabricator
Task T69023
 

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

Filed in bugzilla. —TheDJ (talk • contribs) 09:03, 24 June 2014 (UTC)
@Elipongo: The FAQ box has gone missing from this page (see Template talk:Village pump page header#Missing FAQ at VPT)... but according to Wikipedia:Village pump (technical)/FAQ, your problem might be the StumbleUpon browser extension. --Redrose64 (talk) 09:48, 24 June 2014 (UTC)
@Redrose64: I'm glad if I'm the catalyst that helped get the FAQ restored, but I do not have StumbleUpon installed on my phone. I use my Droid 4's native browser which I don't even think CAN have extensions installed; I see from the article that StumbleUpon comes as a separate app from the play store. Thanks! —Elipongo (Talk contribs) 15:13, 24 June 2014 (UTC)

VisualEditor global newsletter—June 2014

 
 

Did you know?

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

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

The user guide has information about how to use VisualEditor.

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

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

Looking ahead

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

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

Supporting your wiki

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

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

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

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

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

Move stopped because of blacklist

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

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

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

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

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

It's not about the total length but this:
.*\p{Lu}(\P{L}*\p{Lu}){9}.* <casesensitive | moveonly> # Disallows moves with more than nine consecutive capital letters
Admins can make the moves but considering the number of articles, I think you should seek consensus first and notify at Wikipedia talk:WikiProject Football. PrimeHunter (talk) 14:20, 25 June 2014 (UTC)
Great. I'll do that. Thanks. HandsomeFella (talk) 14:51, 25 June 2014 (UTC)

Invitation to test Hovercards

Hi everyone,

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

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

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

Thanks!

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

This is just my occasional reminder that if you don't have a Bugzilla account (which not only is completely separate from your Wikipedia account, but which also publishes your e-mail address to the world), and you ever need to get a bug filed, then you can always leave a note on my talk page with the written report that you need filed. There are a lot of volunteer and staff devs who are also willing to help out with these things. Whatamidoing (WMF) (talk) 19:52, 6 June 2014 (UTC)
I had it enabled for a few weeks before but had to stop using it because of this annoying bug. However, it's fixed now thankfully and I've reenabled Hovercard. Huzzah!, —  dainomite   20:11, 6 June 2014 (UTC)
Indeed. We waited to post this notice until after we got the fix for that bug merged. I'm glad you're enjoying it! --Dan Garry, Wikimedia Foundation (talk) 00:06, 12 June 2014 (UTC)
  • Having read "provides the casual reader with a streamlined browsing experience" in the description (and then read the rest too...), my reply to the invitation is "thanks, but no thanks". I hope it will be an opt-in feature, or at least have an easily accessible opt-out. Peridon (talk) 13:26, 11 June 2014 (UTC)
@DGarry (WMF): I would have left a comment at mw, but I don't appear to have the privilege of editing there. The 'Add new topic' button is greyed out, and there is no 'edit' button that I can see. Yes, I was logged in. If that is how Flow works, you can keep it for me. It looks as bad as this new Media viewer thing in the thread below this one. Peridon (talk) 13:34, 11 June 2014 (UTC)
BTW I regard 'being focussed on someone's experience' as an indicator of spamming... PR or marketing talk. Peridon (talk) 13:38, 11 June 2014 (UTC)
High-level design briefs can often sound like that. You'll notice I've kept my messages on this board a lot more precise, as the audience here appreciates more specificity. --Dan Garry, Wikimedia Foundation (talk) 00:02, 12 June 2014 (UTC)
I've just re-created my user page at mw (someone having deleted my previous one for being 'spam'), but still cannot edit the page linked above, or the Flow talk page. Does this mean that I will be unable to use Flow if it gets rolled out here? Peridon (talk) 10:25, 12 June 2014 (UTC)
Peridon, what happens with you click in the text box that you described as "grayed out", where it has a + sign and says "Start a new topic"? WhatamIdoing (talk) 18:07, 12 June 2014 (UTC)
Absolutely nothing. No little hand to show I'm over a link, no action. There's no 'edit' button either. I can view history, or click other little buttons, and even (it seems - I haven't saved) edit the header (there's a little pencil for that). No new topic, though. Just grey. They're welcome to the thing - I don't want to see it brought in here without some sort of opt-out. Probably impossible, as with so much of the technical wizardry that only serves to confuse people. Peridon (talk) 20:06, 12 June 2014 (UTC)
@Peridon: Thanks for the feedback on the design - the grey text has been mentioned a few times, and is being addressed in the almost-finished redesign - in the current version, it looks even lighter in Firefox, which adds additional opacity to "placeholder" text, which is very annoying.
Regarding the problem with not being able to create a new topic, I'll look into it. Could you let me know what browser/OS you're using, and if there are any non-standard settings, so that I can try to reproduce the problem in order to file a bug? Much thanks. Quiddity (WMF) (talk) 01:08, 13 June 2014 (UTC)
@Quiddity (WMF): Firefox 20 on XP Pro (classic view) with Monobook. I change settings only when needed, so I couldn't tell you what is standard and what not. So far as I know, the only changes I've made at mw would be to use Monobook as I loathe Vector. I'm not in mw very often, and probably won't be after someone deleting my user page as spam without warning or notice. The grey doesn't look like a deliberate grey - it looks like a something missing (like the link that's supposed to be there) grey. If it IS a deliberate grey, please bin it and use a decent black. Grey is hard to see for a lot of people, as are thin lined fonts (such as New Scientist uses). To hell with fashion - go for clarity. Peridon (talk) 19:38, 13 June 2014 (UTC)
I wonder if the designers could be convinced to make it exactly the same colors as the Search box. That's "grey", but nobody looks at that and says it's not working or "greyed out". WhatamIdoing (talk) 14:46, 18 June 2014 (UTC)
Which search box? The one I get in Monobook looks black (or so close to as doesn't matter). I haven't tried searching in Vector or a Flow page. Peridon (talk) 17:49, 22 June 2014 (UTC)
 
The search box in Vector: gray lines, gray word, gray icon 		 
The search box in Monobook: gray lines, gray word, gray buttons

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

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

Closed AFDs not displaying on mobile version

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

probably it's the metadata class. That's stuff that should be hidden in the content namespace, but perhaps mobile has an overly 'active' implementation of it. There are 2 solutions, remove that class, or fix mobile :) —TheDJ (talk • contribs) 05:30, 24 June 2014 (UTC)
It's the metadata class, and a related matter has come up before, see Wikipedia:Village pump (technical)/Archive 116#CfDs in mobile view - there is much related detail at Wikipedia:Village pump (technical)/Archive 116#'Listen' template not rendering in mobile view. There were one or two related threads, see for example Wikipedia:Village pump (technical)/Archive 119#Wikipedia mobile page have a bug for sister project links. --Redrose64 (talk) 09:25, 24 June 2014 (UTC)
So is this something that should be raised on bugzilla? I could ask for a bot to change all the templates in the archive, but this does not seem like the right approach. We can never be sure we have found all the entities generating that class. SpinningSpark 15:43, 24 June 2014 (UTC)
Bugzilla is only for things that we can't fix ourselves. We have two possible approaches here: either remove the metadata class from {{afd top}} or modify the relevant rule in whichever CSS file is setting a rule like 
.metadata { display: none; }
I think that altering none to block whilst being the "obvious" thing to do would unhide things that should remain hidden. If we choose the first approach - which has, in fact, already been done - we need to do something about those AfDs closed prior to that modification, perhaps send in a bot to remove the metadata class. --Redrose64 (talk) 16:06, 24 June 2014 (UTC)
Yeah, I thought that would be the answer on Bugzilla, just checking. Are you sure that my example was created with {{afd top}}? It does not have the template name in hidden text as more recent ones do. If we are sure that there is nothing currently creating this class, then yes, a bot would be the solution. SpinningSpark 17:00, 24 June 2014 (UTC)
  • If you can get me a list of pages, I can run through once with AWB and remove the "metadata" classes. — {{U|Technical 13}} (e • t • c) 20:01, 24 June 2014 (UTC)
  • @Technical 13: The pages that need checking should all be in the following searches:
Update: My request for T13bot has been   Approved for trial (175 edits or 10 days). Please provide a link to the relevant contributions and/or diffs when the trial is complete. by Xaosflux. I'll complete his request for 25 trials in each prefix tomorrow. (bed time for me here). — {{U|Technical 13}} (e • t • c) 01:34, 25 June 2014 (UTC)
Initial trial run has completed, if anyone has any comments, please bring them to Wikipedia:Bots/Requests for approval/T13bot. Thank you, — xaosflux Talk 00:20, 26 June 2014 (UTC)

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

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)

Tech News: 2014-24

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

Recent software changes

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

VisualEditor news

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

Future software changes

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

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

07:39, 9 June 2014 (UTC)

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

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

We are now running 1.24wmf8. This fix is not deployed and is not listed in the 1.24wmf8 change log. --  Gadget850 talk 20:32, 12 June 2014 (UTC)
That change is coming with 1.24wmf9. Jackmcbarn (talk) 16:02, 13 June 2014 (UTC)
Not listed in the 1.24wmf9 change log. --  Gadget850 talk 13:38, 15 June 2014 (UTC)
1.24wmf9 is now deployed, but this fix is not. --  Gadget850 talk 18:37, 20 June 2014 (UTC)
Yes it is. See Special:Permalink/613719402. Jackmcbarn (talk) 18:39, 20 June 2014 (UTC)
Yes. Needed a purge. --  Gadget850 talk 18:53, 20 June 2014 (UTC)

Question re Special: Thanks

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

@Maile66: No, this will continue to work exactly as it does now. If you've never typed "Special:Thanks" into the search box, this doesn't affect you. :) Matma Rex talk 19:38, 9 June 2014 (UTC)
@Maile66: At the moment, you can go to Special:Thanks, type in the revision ID for an edit (for example, the revision number for this edit is 612255080), click Submit and you then see "(Example) was notified that you liked their edit". In future, this method will not be available, but the "thank" link on the edit will still work. --Redrose64 (talk) 19:58, 9 June 2014 (UTC)
Thanks to both of you for this information. — Maile (talk) 21:01, 9 June 2014 (UTC)
Hmmm, the thank button appears not to be working. Either that, or it is working but the thanker is not being told that the thankee has been thanked, if you get my meaning! Mjroots (talk) 10:01, 24 June 2014 (UTC)
I've just thanked you; I saw the usual "Are you sure?" popup, and the action was logged. You last thanked someone on 15 June. -- John of Reading (talk) 10:12, 24 June 2014 (UTC)
@John of Reading: - yes, I got your thanks. Confirms what I said though. Button not working for me. I tried to thank two separate editors today without success. Mjroots (talk) 11:46, 24 June 2014 (UTC)
If memory serves, User:Steven (WMF) is the contact for Thanks. He'll probably need to know things like what web browser and computer system you're using, Mjroots. Also, do you have JavaScript disabled? Whatamidoing (WMF) (talk) 05:08, 25 June 2014 (UTC)
I'll keep this in one place as it may benefit others.
@Steven (WMF): - I'm using Firefox (not sure what version, but it's the latest one) and Windows XP. JavaScript is enabled as far as I know. Mjroots (talk) 06:04, 25 June 2014 (UTC)
@Mjroots: To find out your Firefox version: in the menu bar at the top, select Help → About Mozilla Firefox. --Redrose64 (talk) 21:46, 25 June 2014 (UTC)
I've got Firefox 30.0 installed. Mjroots (talk) 04:30, 26 June 2014 (UTC)

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

  • I'm not at all impressed by the decision to do away with Special:Thanks. This decision forces those people that want to occasionally thank people for an edit here or there to have to put up with the horrible in-line thank process (poorly placed link, required confirmation for a simple process because of the poorly placed link, additional page history clutter). I vaguely remember that it may be possible to thank a user via the API, and I suppose I should finish my NoThanks script to be able to make use of this and better customize the thanking process. It won't be this week or next though as I'm cramming to complete the equivalent of four biology finals in the next week or so, but I'll get to it... — {{U|Technical 13}} (e • t • c) 15:24, 27 June 2014 (UTC)
I like the confirmation required bit, saved me from thanking the wrong person once. Dougweller (talk) 15:39, 27 June 2014 (UTC)
  • When I'm done with NoThanks, it will have an option to undo the thank instead of having to confirm which will reduce the "normal operation" of thanking someone to one click... — {{U|Technical 13}} (e • t • c) 15:52, 27 June 2014 (UTC)

Automating the creation of Wikidata articles

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

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

The tool could grab data from categories and infoboxes.

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

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

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

Upload a file through the API

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

Have a look at the code of the SVGEdit extension. (+ FormMulitpart), it just does what you want: Upload an SVG created by script. And of course it is possible to upload other formats as well, though a bit more complicated. (You would have to use the native FormData object, and get the binary data from somewhere, e.g. a canvas element.) --132.230.1.28 (talk) 09:54, 27 June 2014 (UTC)
Thank you for that response. I haven't tried anything yet, but from what I can gather from the code, it seems as if I can copy the code from both of these sources into a JS page on-wiki, call saveSVG("FILENAME", {...., data:SVGTEXT, ...}, "EDITSUMMARY", CALLBACKFUNCTION) where the ellipses would have all the other file data like encoding, etc., and it should work? Do I need to format SVGTEXT in any certain way, or can it just be regular text?--Dudemanfellabra (talk) 13:03, 27 June 2014 (UTC)

Classic Wikipedia article traffic stats not working. What!?

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

Try "View history" | "external tools: Revision history statistics" | scroll down to the traffic history |scroll down to other items like user edits
--Ancheta Wis   (talk | contribs) 22:21, 27 June 2014 (UTC)
This message was a replacement for an older one (see this diff) and that's why it's out of chronological order. Graham87 08:14, 28 June 2014 (UTC)

Something changed font rendering in Chrome

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

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

Finding things in my user space.

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

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

Page title conflicts through newly assigned Unicode characters?

Tracked in Phabricator
Task T69193

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

Update to 7.0 and your question outstanding in bugzilla:67193. —TheDJ (talk • contribs) 11:35, 27 June 2014 (UTC)
We had a problem two or so years ago with a user who had registered an account using a single character, U+0271, for their user name: ɱ (talk · contribs); at the time, MediaWiki did not recognise that this was the lowercase form of U+2C6E and so it allowed the account to be created with that name. Later, it decided that the user name should be uppercased and linked to Ɱ (talk · contribs) which was not the same account. More at Wikipedia:Village pump (technical)/Archive 105#Link in history says user does not exist. --Redrose64 (talk) 22:49, 27 June 2014 (UTC)
As yes, the problem of Eversonian capitals. The lack of capital forms for many Latin/Greek/Cyrillic characters has led to an unfortunate ad hoc approach where these get added to Unicode at a later time when the capital gets discovered at a later time. Unicode has been doing a lot better at just encoding both case pairs for new characters, but there are still a large number of old letters (encoded early in Unicode) that really can't be justified until we find actual capital forms being used. I'll put in a reminder at writing systems to remind people to file a bugzilla to update case matching whenever a new Unicode version gets release. VanIsaacWScont 00:53, 28 June 2014 (UTC)
Yeah, this particular character is probably an especially absurd case. The existence of the lowercase codepoint never made much sense to begin with, and the proposal document for the uppercase one is nothing short of bizarre. It's the first character proposal I've seen that fails to cite even a single authentic instance of use of the character in print – the only thing shown is one where the proposer thought the author ought to have used it but didn't (and clearly intentionally so.) But anyway, that's not for us here to worry about. On another note, one wonders why Mediawiki even has to define all these case mapping pairs manually all the time. Doesn't PHP have built-in Unicode case-mapping functionality, like any other decent programming language today? Fut.Perf. ☼ 10:28, 28 June 2014 (UTC)
Sure it does. But "built-in case-mapping" still depends on having up-to-date data files that contain the casing conversions. So I'm not entirely certain that there is a substantial difference between "doing it manually" and "built-in functionality". VanIsaacWScont 19:36, 28 June 2014 (UTC)

Improved Diff acting up

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

@SteveMcCluskey: I think the page you're looking for is User talk:Cacycle/wikEdDiff. It looks like there was a large update to the code 4 days ago.
Re: pasting text dumps, just enclose them in a <pre>...</pre> tag. (or if it's many screens long, either take a screenshot, or paste the text at http://pastie.org )
Before that though, try clearing your browser cache (WP:REFRESH), justincase.
HTH :) –Quiddity (talk) 08:55, 28 June 2014 (UTC)
Thanks for the advice. I tried purging my cache and it didn't fix it so I've posted at User talk:Cacycle/wikEdDiff. --SteveMcCluskey (talk) 20:29, 28 June 2014 (UTC)

Resuming PDF downloads

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

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

jQuery update causes constant script error

Tracked in Phabricator
Task T65303

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

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

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

That's not caused by jQuery upgrade, and is already fixed: T65303 (but probably not deployed; the error will disappear in a few days). I suggest upgrading to a newer browser that supports this syntax. Matma Rex talk 10:27, 29 June 2014 (UTC)
Thanks for your attention & the pointer re: OOJS issues. -- George Orwell III (talk) 13:29, 29 June 2014 (UTC)

GeoGroupTemplate not working

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

It's Toolserver, which (as we have been warned several times on this page over the last two years) won't last forever. To be precise, it's got just over 40 hours left. If we're lucky. --Redrose64 (talk) 07:46, 29 June 2014 (UTC)
The toolserver link is just a redirect since that one edit, and the tool is actually hosted on Tools Labs. Its web service for the project had died with the error "sockets disabled, connection limit reached", which never happened on the Toolserver. Looks like I'm hitting some sort of a difference between Toolserver's Zeus Web Server and Labs' lighttpd. The tool doesn't get an exceptional number of hits, so it's going to take a while before it has the chance to hit the limit again, and to figure out a way to monitor the web server and whether the options at http://redmine.lighttpd.net/projects/1/wiki/Docs_Performance might affect it. --Para (talk) 22:37, 29 June 2014 (UTC)
Labs is a real pain. I used to be able to get a list of pages that I'd created, excluding redirects, at http://toolserver.org/~tparis/pages/index.php?name=Redrose64&namespace=0&redirects=noredirects - that now sends me to http://tools.wmflabs.org/xtools/pages/index.php?name=Redrose64&namespace=0&redirects=noredirects which has never worked for me - it takes absolutely ages before throwing a 504 Gateway Time-out. --Redrose64 (talk) 23:16, 29 June 2014 (UTC)

Servers not serving, and not timing out either

  Resolved

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

@Redrose64: Look in the Network tab in the web developer to see which page it's stuck on. Jackmcbarn (talk) 19:14, 29 June 2014 (UTC)
Mostly it's either http://en.wikipedia.org/w/index.php?title=User:Equazcion/SkipFileWizard.js&action=raw&ctype=text/javascript or http://en.wikipedia.org/w/index.php?title=MediaWiki:RefToolbarLegacy.js&action=raw&ctype=text/javascript but I did spot http://en.wikipedia.org/w/api.php once, without a query string. Maybe Equazcion knows what's wrong with the first one. Since I tried that "Network" thing, I've not seen it stick on any bits.wikimedia.org files. However, the HTTP 304 code is always shown against these, so surely it shouldn't be trying to re-retrieve? --Redrose64 (talk) 19:41, 29 June 2014 (UTC)
I turned it off overnight, cleared all the Web Content Cache, now working. But slower, because it's got to bring back a whole bunch of images that are frequently used. I guess it'll get faster once those are all in my content cache again. --Redrose64 (talk) 16:23, 30 June 2014 (UTC)

Flags and text distorted when editing (Chrome, Firebox)

(Chrome 35.0.1916.153 m, Firebox 30)

Extraneous links have been viewed in Preview or in 'Check changes' on the parts being later damaged.

Computer's check by Spybot & AVZ didn't help as well as Chrome restart.

It's possible to work only in Firebox restarted with adds-on disabled,

In IE-8 all is Ok.

The same browsers work well at other computer.

More details are at parallel ru.wikipedia tech forum where no solution has yet been found. :( --Igorp_lj (talk) 23:43, 29 June 2014 (UTC)

@Igorp lj:, perhaps you can post a screenshot or something on imagebin.ca That might be easier for everyone to understand the problem. —TheDJ (talk • contribs) 08:42, 30 June 2014 (UTC)
@TheDJ:, thank you. Here the are:
versus
and this is 'Show changes' window in Chrome & Firefox (again there is no edit yet):
Sure there is now change for 'firefox-no-adds-on' case.
Such results one can view opening one of 'дифф1-дифф7' diffs at mentioned ru.wikipedia tech forum.
By the way : I have to pass to 'firefox-no-adds-on' to post this because of there there was same link for Russia again ({{Flag|Russia}}--> {{Flag|}}) in Chrome preview. :(
--Igorp_lj (talk) 11:03, 30 June 2014 (UTC)

Tech News: 2014-27

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.24wmf11) was added to test wikis and MediaWiki.org on June 26. It will be added to non-Wikipedia wikis on July 1, and to all Wikipedias on July 3 (calendar).

VisualEditor news

  • Context menus in VisualEditor will no longer flicker and disappear when you insert a new reference, formula, image, etc. [81] [82]
  • A bug that prevented relocating items due to cache was fixed last week. [83] [84]
  • VisualEditor will no longer scroll to the bottom of the page when you try to edit section 0. When you try to add a formula, VisualEditor will no longer scroll to the top of the page. [85] [86] [87] [88]
  • Links to category pages or file pages added with VisualEditor will now work correctly. [89] [90]

Future software changes

  • You will no longer be able to upload files on wikis that do not have any copyright tags. [91] [92]
  • Toolserver tools will be stopped on June 30. Please make sure to change gadgets that link to the Toolserver to point to Tool Labs instead.
  • CirrusSearch will be enabled on June 30 as the primary search method on 34 new wikis, including the Czech (cs), Danish (da), Finnish (fi) and Hebrew (he) Wikipedias. [93]
  • All Wikimedia wikis will be using a security method called perfect forward secrecy starting on July 1. If you see a problem, please report it. [94] [95]
  • Starting on July 1, it will be possible to globally rename global (SUL) users. [96]
  • You will soon see block information when you visit the contributions page or try to edit the user page or user talk page of a user who is affected by an IP range block. [97] [98]
  • You will soon be able to use {{!}} as a magic word to produce the pipe character, for instance for use in tables. [99]

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

06:53, 30 June 2014 (UTC)

Template code help please!

Hello technical people.

There's a a discussion going on at Wikipedia talk:WikiProject Cricket here about whether the Template:Infobox cricketer should include more than four fields in its "competition" coding.

I started Template:Infobox cricketer six columns and a mock-up test pseudo-article User:Shirt58/Xavier Tras to test it out, but no dice: my horribly malformed code still only outputs four "competions" fields. I am confident that this is because, ahem, I have very little clue at all about how the more complex template code works.

Could someone who groks template code possibly have a little look into this? Thank you!

Peter in Australia aka --Shirt58 (talk) 13:40, 30 June 2014 (UTC)

That's a good start, but you will also need to add to Template:Infobox cricketer/career which formats the table. I love the pseudo-article! -- John of Reading (talk) 13:51, 30 June 2014 (UTC)

Collection: Missing tools from Toolserver?

On July 1st 1:00 am UTC, the Toolserver accounts will be expired and tools which haven’t been migrated yet to Tool Labs will stop working. More information can be found here. To get an overview, we started a collection: Do you miss any tools or have you observed any broken redirects? Would you like to maintain a orphaned tool? If so, please post them here. Thank you very much! Silke WMDE (talk) 15:30, 30 June 2014 (UTC)

Technicals images shouldn't show in MediaViewer

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

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

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

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

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

Line spacing

Where can I find the Wiki Help on line spacing and how to change it? (For example, if I want to make the space between a heading and the text under it not a double-line space, but a 1.5 line space.) I have looked everywhere but cannot locate it. . --P123ct1 (talk) 19:21, 30 June 2014 (UTC)

Duplicate of Wikipedia:Help desk#Line spacing but this is the better place.
The space between a heading and the text is governed by two properties: the bottom margin of the heading (which for level 1 and level 2 headings is 0.25em, and for level 3/4/5/6 headings is 0px), and the top margin of the paragraph (which is 0.5em). It's probably easiest to reduce the top margin of the paragraphs; you can change it on a personal basis by adding some code to Special:MyPage/skin.css. The code to add varies depending on the skin that you are using. If you have the default (Vector) skin, try this: 
div#content p { margin-top: 0.3125em; }
If you use a different skin, another value may be necessary. --Redrose64 (talk) 21:42, 30 June 2014 (UTC)
That looks mind-shatteringly complicated. Having looked at the link I wouldn't know where to being with skin.css. I will find another way round it. --P123ct1 (talk) 22:15, 30 June 2014 (UTC)
You copy that single line of code, click the link I gave, edit the page, paste in the line of code, and save. --Redrose64 (talk) 22:38, 30 June 2014 (UTC)
Thanks. I have done that (and bypassed the cache as instructed) but it makes no difference. I am trying to widen the line spaces before headers I have made in a text I am editing, after turning some of the text into a long bulleted list with some headings. I am using the Vector skin. What am I doing wrong? --P123ct1 (talk) 10:35, 1 July 2014 (UTC)
Is this one specific page? If so, which one? --Redrose64 (talk) 10:50, 1 July 2014 (UTC)
It is section 7.7.5 "2014 events" in the Islamic State of Iraq and the Levant#2014 events article. I can't widen the gap between the month headings and text above them. Clicking enter twice makes the gap too big. Someone had already started putting in some bullet points and I see in the wikitext they put in a semicolon before the months. I don't know if this has anything to do with widening the line space before the first entry for the month. I haven't been editing in Wikipedia for long and am still learning the basic technical stuff! --P123ct1 (talk) 12:17, 1 July 2014 (UTC)
It is usually best not to change the default styling. The "2014 events" is actually a list item, not a header. Try using a level 4 header (====) instead. -- [[User:Edokter]] {{talk}} 12:29, 1 July 2014 (UTC)
I was under the impression that P123ct1 wanted to set styling on a personal basis: some people do find that varying the spacing between paragraphs improves readability.
Anyway, the text "2014 events" is a level 3 heading; the text "January 2014", "February 2014" etc. is marked up with a semicolon, so is technically a term in a definition list. The bulleted lists that follow the months should not have blank lines between list items, so I removed those per WP:LISTGAP. --Redrose64 (talk) 12:37, 1 July 2014 (UTC)
Thanks to both - it makes more sense now. I will use the "definition list" method next time. --P123ct1 (talk) 13:28, 1 July 2014 (UTC)

Multiple pinging

Can it be made possible to ping several editors simultaneously (in a multiple ping)? They might be listed as participants or members in a WikiProject (see Category:WikiProjects). They might be categorized in a category of Category:Wikipedians.
—Wavelength (talk) 00:02, 1 July 2014 (UTC)

If so, should be restricted to mass-message-senders! — xaosflux Talk 00:13, 1 July 2014 (UTC)
For several years, I have participated at Wikipedia:Reference desk, asking and answering questions. A few times, I have visited the talk pages of WikiProjects to invite comments from their members in answers to those questions. A typical question at one of the reference desks might be relevant to two or three WikiProjects, and it would be convenient to be able to ping them from a discussion in progress. Also, sometimes a question might involve experience or expertise in a foreign language, and it would be convenient to be able to ping certain editors (with the experience or expertise) from a discussion in progress. (Ideally, every editor would watchlist all the reference desks, and every discussion would have a brief, informative heading.)
—Wavelength (talk) 00:38, 1 July 2014 (UTC)
@Wavelength and Xaosflux: You can already do this. As with any single-person ping, you need to ensure that all the relevant links to user pages are added in the same post as your own signature. --Redrose64 (talk) 07:35, 1 July 2014 (UTC)
It would be possible to make a module so that you could do this without knowing all the participants' usernames. There would be a submodule for each project, each with a list of usernames. To use it, you would type {{mass notification|WikiProject Foo}} My message. ~~~~, and the module would insert all of the usernames in the submodule. (The font could be small, or the usernames could even be hidden.) One drawback: I seem to remember that after a certain number of userpage links are included in a post, notifications are no longer sent out. I can't seem to find the number on the extension page or on a few other pages I looked at, though. Is the username limit just my imagination? — Mr. Stradivarius ♪ talk ♪ 09:49, 1 July 2014 (UTC)
  • Mr. Stradivarius, if you are going to undertake a project like this, it would likely be a good idea to incorporate it into a converted {{Ping group}}... — {{U|Technical 13}} (e • t • c) 12:03, 1 July 2014 (UTC)

I've now got provisional code working at Module:Mass notification. Please see Template:Mass notification for documentation. Here's some example output:

Notifying all members of WikiProject Example (more info · opt out): (User:Example, User:Example2, User:Example3, User:Mr. Stradivarius) A message. — Mr. Stradivarius on tour ♪ talk ♪ 16:26, 1 July 2014 (UTC)

@Wavelength: And as I just got a ping from my alternative account about the message above, I'm satisfied that everything is working properly. Suggestions for formatting the module output are welcome. — Mr. Stradivarius ♪ talk ♪ 16:28, 1 July 2014 (UTC)
  • {{MN|T13}} should ping me on all my accounts (except the one I'm currently on of course)? — {{U|Technical 13}} (e • t • c) 16:57, 1 July 2014 (UTC)
Hmm, it looks like this will need to be inline if it's going to play nicely with bulleting and indenting. Here's a new inline version which also hides the individual member links: Notifying all members of WikiProject Example (more info · opt out): (User:Example, User:Example2, User:Example3, User:Mr. Stradivarius) my message. — Mr. Stradivarius on tour ♪ talk ♪ 17:35, 1 July 2014 (UTC)
Mr. Stradivarius, can you add functionality to the module to make the "group" name linked? Since the name may not be an actual page, this would need to be an include-able option from the list page. Also, will this template accept parameters if you want to use it to ping a half dozen or so users and you know all their names (like {{Ping group}} does)? with these two additions, {{Ping group}} can probably be replaced with a redirect to this template/module. — {{U|Technical 13}} (e • t • c) 18:09, 1 July 2014 (UTC)
@Technical 13: I've done the first part. I'm not sure adding other users in separately is really necessary. You can just use other notification templates at the same time, or include the usernames manually. — Mr. Stradivarius ♪ talk ♪ 00:00, 2 July 2014 (UTC)
Please see Wikipedia_talk:Mass_message_senders#Bypassing_mass-message_controls.3F. Need to get some details of how this is going to be controlled to prevent making an end-run around the mass messaging controls. — xaosflux Talk 14:54, 2 July 2014 (UTC)

Another new bug today - don't know the terminology

Probably related to all the July 1 changes going on. Pick any article, because it doesn't matter which one or which edit. Go to the article Page → History → Compare Selected Revisions. You get the usual Diffs view. What has changed today is below the diffs. There is a toggle arrow that, prior to today when clicked, opens a window below it and always shows you clearly "red" highlight for what was taken out and "green" highlight for what was added. But clearly. If it's a word or a symbol, that's what you see in red or green, in its regular place within the prose. The diff today that I've linked above will still open a window below with the toggle arrow. And there's still red and green highlights. But to a non programmer, it's just a bunch of unusable code:


NewPP limit report Parsed by mw118066 CPU time usage: 01.828116 seconds Real time usage: 01.966262 seconds Preprocessor visited node count: 1223/1000000 Preprocessor generated node count: 5661/1500000 Post‐expand include size: 12394/2048000 bytes Template argument size: 732/2048000 bytes Highest expansion depth: 14/40 Expensive parser function count: 1/500 Lua time usage: 0.080114/10.000 seconds Lua memory usage: 1.81 MB/50 MB

Etc. etc. etc. and on it goes. — Maile (talk) 21:05, 1 July 2014 (UTC)
  • Entirely unrelated. @Cacycle:, this has bren happening sporadicallysince Special:ComparePages support was added to wikEdDiff and I can't remember if I reported it or not... — {{U|Technical 13}} (e • t • c) 21:37, 1 July 2014 (UTC)

Significant backlog at Wikipedia:Templates for discussion/Holding cell

I'm hoping to find some interested template editors to assist with the significant backlog found at Wikipedia:Templates for discussion/Holding cell, particularly with the merge results. Thanks in advance. -- Netoholic @ 21:17, 1 July 2014 (UTC)

Empty group of users

Would someone mind explaining what this is? The listing at Special:Statistics just links to Wikipedia:Users, which is rather unhelpful. --NYKevin 00:42, 2 July 2014 (UTC)

It's a form in which you enter the first few chars of the user name [e.g., Example], and select the role [e.g., Rollbacker], then click Go, and you will see a report of those users with that privilege. --Ancheta Wis   (talk | contribs) 00:56, 2 July 2014 (UTC)
I think NYKevin is specifically asking about the access group 'users' - which has no members. — xaosflux Talk 01:05, 2 July 2014 (UTC)
IIRC it's for IPs. Ansh666 03:11, 2 July 2014 (UTC)
It was caused by an erroneous change to the EducationProgram extension (gerrit:139646). I've commented there. — This, that and the other (talk) 05:50, 2 July 2014 (UTC)

Mobile view being intrusive

I have disabled mobile view on my tablet because I find editing easier on desktop view. However, when following certain links to Wikipedia (specifically those of the form http://en.wikipedia.org/wiki/James_Bond - note, not https:// and not index.php) I am nevertheless sent to the mobile page, even though the mobile site recognises I am logged in. Unfortunately, several useful sites use this sort of link, not least Google.

Is there a way to permanently disable mobile in Preferences, and if not, why not? BethNaught (talk) 09:11, 2 July 2014 (UTC)

PS following the link I typed will not demonstrate the behaviour as MediaWiki appears to automatically use https:// when rendering links if you have that enabled in your Preferences. BethNaught (talk) 09:12, 2 July 2014 (UTC)
It seems that the cookie that is set to keep track of this is set as a 'secure' cookie. that means it is not visible when entering form an http link. I'm not sure why this is. I'll look a bit further or report it as a bug. —TheDJ (talk • contribs) 14:19, 2 July 2014 (UTC)
Thank you. Sounds like it's easy to fix for the relevant people. BethNaught (talk) 14:45, 2 July 2014 (UTC)

Authority control template not showing in mobile

The {{Authority control}} template is not showing in the mobile versions of our pages (nor the new android app). Is this because the HTML table is classed navbox-inner? It should display, since its content is data, not navigation-chrome. I'm also concerned that other data-containing templates may be hidden by the same cause, whatever it is. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:37, 1 July 2014 (UTC)

No it's because the the HTML table has the class navbox which like the metadata class (and four others) is set display: none !important; in mobile. --Redrose64 (talk) 18:38, 1 July 2014 (UTC)
@Redrose64: Thank you. So, what's the bast way to fix this? Assuming we really don't want navboxes to display in mobile, what's the best alternative class to give the template (which, semantically, is not a navbox), to preserve the appearance on desktop, yet display in mobile? Do we need a new class? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:01, 1 July 2014 (UTC)
I now see that I missed that class, because the template's using nested tables, that's surely unnecessary? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:03, 1 July 2014 (UTC)
The template was Lua-ised over a year ago, the workings are impenetrable. I left a note at Template talk:Authority control#Not on mobile which may be spotted by those responsible. --Redrose64 (talk) 20:05, 1 July 2014 (UTC)
Thanks. I also find my ability to contribute to template development is reduced, since I can't code Lua. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:40, 1 July 2014 (UTC)
If you make it look like a navbox, by pretending it to be a navbox, then it will behave as a navbox. Currenly navboxes are not shown in Mobile, because they pose significant interaction design problems when it comes to usability on smaller devices (a problem that the Mobile team will work on long term). Navboxes are also traditionally internal links. External links should go into the external links section. This is a side effect of it being aligned with "person data", but person data is metadata (primarily for search engines) that is hidden (and long term can be sourced from WikiData). Navboxes also don't count as the 'content proper'. They are 'assistive', you could call them User interface elements defined in content, the content should be complete without their presence just as much as with their presence. If you want to find longterm solution to you immediate problem, then those are the issues that need to be dealt with. —TheDJ (talk • contribs) 14:44, 2 July 2014 (UTC)

A few points of clarification:

  1. I didn't make {{Authority control}} look like anything.
  2. It's not a navbox
  3. The Authority Control links in the template are not internal links
  4. There is community consensus (after RfC, IIRC) to have these Authority Control links display in a horizontal template, below the external links section where one exists.
  5. The Authority Control values are content, and should show, to humans, in mobile
  6. This is nothing to do with PERSONDATA

So, to reiterate my questions: what's the best alternative class to give the template, to preserve the appearance on desktop, yet display in mobile? Do we need a new class? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:44, 2 July 2014 (UTC)

You'd just need to give it a new box that didn't use Module:Navbox. If someone wants to hack at the HTML of the "navbox classes removed" box in my sandbox until it looks acceptable, I can add that to the module. TheDJ does have a good point, though - long horizontal lists generally look terrible on mobile, so you might want to bear that in mind when designing it. — Mr. Stradivarius ♪ talk ♪ 15:08, 3 July 2014 (UTC)

PDF printouts have lost some harv citation detail

Tracked in Phabricator
Task T48115

In PDF printouts, harvnb citations are not rendered in the footnotes. The ordinary web pages are working; it's just the PDFs that are not working. For example, in Sequent, footnote 2 has a harvnb "Lemmon 1965 p.12" as expected in the web page; however, when 'download as PDF', that pdf's footnote 2 will have a bunch of commas. Same issue with footnote 1 in the PDF. Footnotes work in both IE 11 (Win 7) [which has Acrobat 8.1], and in Firefox 29.0 (Ubuntu 14.04) [which has PDF Producer: ReportLab PDF Library - www.reportlab.com PDF Version:1.4 Page Count:7] --Ancheta Wis   (talk | contribs) 00:42, 2 July 2014 (UTC)

@Ancheta Wis: It's not a problem with {{harvnb}} but with templates that are enclosed in parser tags such as <ref>...</ref> - the PDF renderer doesn't handle them at all well. There is plenty on this at Help:Books/Feedback (and its archives), in the archives of this page (e.g. Wikipedia:Village pump (technical)/Archive 116#PDF output of Wikipedia Page is Missing its References Wikipedia:Village pump (technical)/Archive 124#Re "Download as PDF" function), and in bugzilla:46115. Pages that use {{sfn}} instead of <ref>{{harvnb}}</ref>, such as NBR 224 and 420 Classes, render just fine as PDF, which suggests to me that one way of fixing it without using {{sfn}} is to use {{#tag|ref|...}} instead of <ref>...</ref> - but that's cumbersome. --Redrose64 (talk) 08:24, 2 July 2014 (UTC)
{{refn}} uses {{#tag|ref|...}}, but we really need to fix the PDF processor. --  Gadget850 talk 15:24, 3 July 2014 (UTC)

Where are my search prefs?

I would like to change my search preferences, but cannot find them. All the help links indicate that there is supposed to be a "Search" tab on my preferences page, but it is not there. Help? — Gorthian (talk) 03:27, 2 July 2014 (UTC)

@Gorthian: You can set default namespaces to search for at Special:Search under the "Advanced" tab, tick the box next to Remember selection for future searches. Other customisations can be done by using gadgets. There are several gadgets to customize search. --Glaisher (talk) 06:07, 2 July 2014 (UTC)
Thanks, Glaisher, but I've already set an "Advanced" search, and now my search-result page always shows the whole kit and kaboodle of the "advanced" checkboxes, and I have to scroll a ways to see the actual results. (I work chiefly on my iPad, and screen space is precious.) I was hoping to have a better solution. I will check out the gadgets. — Gorthian (talk) 06:22, 2 July 2014 (UTC)

It turns out that there are very few gadgets that do anything for searches. There should be a tab labeled "search" on my preference page, but it's not there. I remember seeing it in the past. Can anybody shed some light on this? — Gorthian (talk) 21:19, 2 July 2014 (UTC)

The "Remember selection for future searches" checkbox was added inside the "Advanced" link of Special:Search with mw:MediaWiki 1.24/wmf8 (bugzilla:52817 and Wikipedia:Village pump (technical)#Tech News: 2014-24). I think that the tab was removed from Special:Preferences at the same time. The list of checkboxes for namespaces is the same, just organised as several columns instead of a single column. --Redrose64 (talk) 21:42, 2 July 2014 (UTC)
I didn't remember what the preferences were; if they were just the same checklist that's on the Search page, then it makes sense they were switched out that way. Thanks, Redrose64. — Gorthian (talk) 01:59, 3 July 2014 (UTC)
Under the old method ("Search" tab in prefs), there was one selection that wasn't copied over in exactly the same form: "Search in all namespaces". The same effect may be achieved in the new method by clicking the All button upper right of the "Search in namespaces:" list. In the past, in that "Search" tab in prefs, there were also three other options, named: "Hits per page"; "Enable simplified search bar (Vector skin only)"; and "Disable search suggestions", IIRC. These were removed some months ago, certainly by 15 April 2014 but no earlier than 28 September 2013. --Redrose64 (talk) 08:07, 3 July 2014 (UTC)
"Disable search suggestions" has moved to the "gadgets" tab, "Disable the suggestions dropdown-lists of the search fields" -- John of Reading (talk) 08:26, 3 July 2014 (UTC)

Looking for a class

Is there a class that produces <code>...</code> formatting? If so, I'd be grateful to know more – I haven't noticed anything in MediaWiki:Common.css or Wikipedia:Catalogue of CSS classes. Sardanaphalus (talk) 11:26, 2 July 2014 (UTC)

<code> is an HTML tag. --Glaisher (talk) 13:22, 2 July 2014 (UTC)
I think that what Sardanaphalus is after is a class that mimics the normal styling of the <code> tag, so that the class can be applied to a table cell, with the effect that everything in that cell will be styled as if it were enclosed in <code>...</code> --Redrose64 (talk) 13:29, 2 July 2014 (UTC)
Not really, there is mw-code, but that is part of the interface, it's not really intended for content and might have sight effects (either now, or in the future), so not to be advised. Also, using the html tag does more than apply styling, it also indicates semantics, you should therefor use it whenever you write a code block. —TheDJ (talk • contribs) 14:00, 2 July 2014 (UTC)
@Sardanaphalus: It is not clear for what purpose such is needed. How about the {{code}} template? Its documentation shows some uses in tables.
—Telpardec  TALK  01:42, 3 July 2014 (UTC)

I am not getting pinged

Edits like this and this have not resulted in me getting notifications - any reason why? Is it because I am already watching those pages? GiantSnowman 18:25, 2 July 2014 (UTC)

Pinging only works if a signature is added with the same edit as the userpage link; see the documentation at mw:Echo/Feature requirements#User Mention. In the first diff the link was added when the comment was already there, which doesn't trigger a notification. The ping in the second diff should have worked though. SiBr4 (talk) 18:32, 2 July 2014 (UTC)
(edit conflict) It's not related to watching the pages. You are only pinged when the post which linked you was signed in the same edit (see Wikipedia:Notifications), so your first example did not cause a ping. The second should, assuming you have a checkmark in the Web column at "Mention" at Special:Preferences#mw-prefsection-echo. It was two weeks ago. Are you sure you weren't pinged? If you were then it should still be listed when you click the number next to your user name at top of pages. PrimeHunter (talk) 18:35, 2 July 2014 (UTC)
Yes, I definitely wasn't pinged for any of those direct posts, see this - though I did receive a 'ping' for this recently... GiantSnowman 18:52, 2 July 2014 (UTC)
@GiantSnowman: Strange. Assuming those signatures were generated with 4 tildes ... Peradventure the failure of 613463902 and 613555517 is due to confusion because the messages were signed with 2 usernames, User:Davykamanzi, and User:DavyK17, the "alter ego" part. How is the parser supposed to "know" which username to credit the notification to? (Duh-uh :)
—Telpardec  TALK  01:49, 3 July 2014 (UTC)
  • Yes, two usernames in the sig makes sense. Bsitu, can you confirm that? If so, we may need to adjust our policy to ensure only one username is in a signature... — {{U|Technical 13}} (e • t • c) 02:25, 3 July 2014 (UTC)
@Technical 13 and Mr. Stradivarius: Well, this post should tell us if that works or not. --User:Not Mr. Stradivarius on tour (some other guy) 02:59, 3 July 2014 (UTC)
I didn't get a notification for the above post (which I made with my alternative account User:Mr. Stradivarius on tour). That suggests that having two different usernames in a signature doesn't trigger notifications. — Mr. Stradivarius ♪ talk ♪ 03:03, 3 July 2014 (UTC)
@Technical 13 and Mr. Stradivarius: This is another test, using one username that is different from my real username. --User:Still not Mr. Stradivarius on tour (talk) 03:07, 3 July 2014 (UTC)
@Technical 13 and Mr. Stradivarius: Another test, using two usernames: my real one, and a fake one. --User:Mr. Stradivarius on tour (User talk:Not Mr. Stradivarius on tour) 03:11, 3 July 2014 (UTC)
@Technical 13 and Mr. Stradivarius: A final test using my real username. --User:Mr. Stradivarius on tour (User talk:Mr. Stradivarius on tour) 03:14, 3 July 2014 (UTC)
The results: the only notification I got from the posts above was for the last one that used my alternative account's real username. So Echo only issues notifications if your signature contains one username (although that username can be used multiple times), and only if that username is your real username. Technical 13, can you confirm that you only got one ping from the above messages? — Mr. Stradivarius ♪ talk ♪ 03:21, 3 July 2014 (UTC)

This post included my real username, but it didn't generate a notification. I suppose if a user is using an account name that isn't theirs, non-existent usernames may work differently to existing usernames. We would need some more tests to see if that's correct, but at least now we know the basic reason that GiantSnowman wasn't pinged. — Mr. Stradivarius ♪ talk ♪ 04:32, 3 July 2014 (UTC)

@Technical 13: Does this edit ping you? עוד מישהו Od Mishehu 12:24, 3 July 2014 (UTC)
@Technical 13: Or this one? User:Od Mishehu AWB, operated by עוד מישהו Od Mishehu 12:25, 3 July 2014 (UTC)
@Technical 13:Did either of them? עוד מישהו Od Mishehu 12:26, 3 July 2014 (UTC)
I'm not entirely sure who's handling Echo after everything got rearranged last month. I wonder if User:Kaldari is around and could help us out. Whatamidoing (WMF) (talk) 15:57, 3 July 2014 (UTC)

Preferences "Search and Replace" not on the toolbar

The the search and replace function on the toolbar seems to be missing today. Any word on this? — Maile (talk) 21:27, 2 July 2014 (UTC)

Never mind. It's there. It just doesn't automatically show up where it did before. Now it's a small icon over to the bottom right. And my edit screen looks different today. Like maybe WikEd is funky or missing. Maybe tomorrow will be different. — Maile (talk) 00:43, 3 July 2014 (UTC)

No Lua module at the Tigrinya Wikipedia (inquiry also posted to Lua project page)

At Wikipedia_talk:Lua#Lua_module_needed_at_the_Tigrinya_Wikipedia_.28TI.WIKIPEDIA.ORG.29 I posted a request for a Lua module at the Tigrinya Wikipedia. Several templates do not work without this module. What needs to be done to have this module installed? WhisperToMe (talk) 00:48, 3 July 2014 (UTC)

Citation bot v. 552 is running...

Not knowing if the bot will terminate in a timely way, I moved the punctuation, started the citation bot, and I'm waiting ... The citation was hand crafted already. Is that confusing the bot? --Ancheta Wis   (talk | contribs) 01:52, 3 July 2014 (UTC)

Happy ending. I found out that since I know how to use citations, I should stick with the nonBeta bot, r543, because it terminates in a timely way. --Ancheta Wis   (talk | contribs) 02:26, 3 July 2014 (UTC)

Citation Bot is blocked pending the operator's upload of updated code that addresses a couple of bug requests. – Jonesey95 (talk) 04:11, 3 July 2014 (UTC)

Disambiguation pages in search results on mobile devices

Tracked in Phabricator
Task T69471

In ictu oculi (talk · contribs) noticed that when using the Wikipedia search box on mobile devices, disambiguation pages appear with a "missing image" symbol on many mobile browsers. The problem is, articles with no images appear the exact same. This makes the disambiguation page hard to spot, even though it is frequently the page people are looking for. Could the search function be revised to automatically show a disambiguation symbol on a search result that's a disambiguation page? Ego White Tray (talk) 05:00, 3 July 2014 (UTC)

On a related note, you could make an argument that the disambiguation should always appear at the top of the results, but I could imagine people would disagree. Ego White Tray (talk) 05:00, 3 July 2014 (UTC)
Thank you for having brought this this here. Yes, exactly as stated. I suppose it'd be possible for the Wikimedia Foundation to investigate other alternatives with Android and Apple (I presume they meet regularly?) but a 3kb gif ? inserted in every dab top rh corner would do the job for Android's at least.
Ego White Tray's additional/alternative suggestion that the disambiguation should always appear at the top of the results, might also address the same problem, though if it's possible technically a ? gif would look neater and the dab still occur at 3rd or 5th place in results, which I'm guessing many readers prefer (though I wouldn't mind as Ego White Tray). In ictu oculi (talk) 05:11, 3 July 2014 (UTC)
I'd rather fix this without having to make any annoying tiny change to thousand upon thousands of disambiguation page. And what about new disambiguation pages, editors won't know to add it. If we're gonna fix this, let's do it the right way. Ego White Tray (talk) 05:39, 3 July 2014 (UTC)
Editors shouldn't have to add anything, a bot detects { dab } tag, then adds [File ?.gif | ], if the page changes from a dab to say a surname article or list, when the { dab } tag goes, then the bot deletes [File ?.gif | ] as well. Incidentally this doesn't affect whether there's an infobox or not. Composers with jpgs come up with an image on Android despite no infoboxes. In ictu oculi (talk) 07:10, 3 July 2014 (UTC)
That is just a horrible idea... We really should stop doing hacks like that, they have a history of backfiring. I have filed a bug report with the Mobile team. —TheDJ (talk • contribs) 10:32, 3 July 2014 (UTC)

On a closely related note, could the search software be written to include (disambiguation) at the end of all disambiguation pages, whether the page is titled with it or not? This would also help users find the disambig page. Ego White Tray (talk) 14:54, 3 July 2014 (UTC)

data: pages

There are many requests for pages which it seems are misinterpretations of the embedded codes for standard images. T68112 applies. I have however noticed over the last year or so many occasions when a MediaWiki page loads apparently without any style information. Is it possible that an attempt to load the CSS has failed, or partially failed, and results in the browser attempting to interpret data uris as absolute urls? All the best: Rich Farmbrough, 19:30, 3 July 2014 (UTC).

Duplication detector

Hello again! Since the Toolserver is gone, so has Duplication Detector. Has it migrated somewhere? Or, if not, is there an alternative? I am already in withdrawal over Reflinks... —Anne Delong (talk) 22:19, 1 July 2014 (UTC)

Yes. Dup Detector at Labs — Maile (talk) 22:22, 1 July 2014 (UTC)
Thanks. I was likely still using an old bookmark in my browser. I tried looking for for the WP:Duplication detector page to find the replacement, but didn't find it. It's obviously there, so I guess my bad typing is to blame. I later found a link to the new version in the template on a page which was tagged for deletion because of copyvio, but not in time to remove this query. —Anne Delong (talk) 04:19, 2 July 2014 (UTC)
Is there a list somewhere of the toolserver tools and their wmflabs replacement? Anna Frodesiak (talk) 23:25, 1 July 2014 (UTC)
Now there's a good question! —Anne Delong (talk) 04:19, 2 July 2014 (UTC)
I started this (Feel free to change the transclusion to a link if you like.):
Link: Wikipedia:Wikimedia Labs/Toolserver replacements


Name Toolserver Wmflabs replacement
(or other tool) 		Notes
Admin score tool tools:~snottywong/adminscore.html toollabs:jackbot/snottywong/adminscore.html
toollabs:apersonbot/aadminscore/ 		For the jackbot version, as the complete counter systematically times out, it only calculates five of 11 criteria.
Admin stats tools:~vvv/adminstats.php toollabs:xtools/adminstats/
Blockrange calculator tools:~chm/blockcalc.php toollabs:blockcalc/
Alternate tool: Template:Blockcalc 		Automatically redirects.
Citegen tools:~citegen/
CheckUsage tools:~daniel/WikiSense/CheckUsage.php toollabs:wikisense/CheckUsage.php Redirects to an RIP message stating the tool is defunct and will not be recreated.
Dablinks tools:~dispenser/view/Dablinks http://dispenser.info.tm/~dispenser/view/Dablinks Used on Template:DYK tools
Toolserver account blocked Aug 27, 2014[1]
Dab solver tools:~dispenser/view/Dab_solver http://dispenser.info.tm/~dispenser/view/Dab_solver Toolserver account blocked Aug 27, 2014[1]
Duplication detector tools:~dcoetzee/duplicationdetector/ toollabs:dupdet/ Maintainer Dcoetzee was banned from Wikimedia.
Tool is still accessible and functional (Dec 12, 2014).
Earwig's Copyvio Detector tools:~earwig/copyvios toollabs:copyvios Automatically redirects.
FIST tools:~magnus/fist.php toollabs:fist/fist.php Automatically redirects.
Flickr2Commons (Bryan's) tools:~bryan/flickr/upload
Flickr2Commons tools:~magnus/flickr2commons.php toollabs:flickr2commons/
Interaction analyzer and Stalker tools:~snottywong/editorinteract.html
tools:~mzmcbride/stalker/ 		toollabs:sigma/editorinteract.py
Log actions tools:~dungodung/cgi-bin/recentlogs? toollabs:rightstool/cgi-bin/recentlogs From the RfA toolbox
Meta rights log tools:~dungodung/cgi-bin/rightslogsearch? toollabs:rightstool/cgi-bin/rightslogsearch From the RfA toolbox
NAC of AfD's tools:~snottywong/cgi-bin/afdadminstats.cgi? https://tools.wmflabs.org/jackbot/snottywong/cgi-bin/afdadminstats.cgi? From the RfA toolbox
New page patrol report tools:~snottywong/cgi-bin/patrolreport.cgi toollabs:jackbot/snottywong/cgi-bin/patrolreport.cgi
Reflinks tools:~dispenser/view/Reflinks See here for status updates. Toolserver account blocked Aug 27, 2014[1]
Shootme tools:~magnus/wikishootme/ toollabs:wikishootme//index.html Automatically redirects.
Show redirects only tools:~dispenser/cgi-bin/rdcheck.py/ http://dispenser.info.tm/~dispenser/cgi-bin/rdcheck.py Link on Special:WhatLinksHere, redirects to a connection timed out message. Toolserver account blocked Aug 27, 2014[1]
Sortable article history tools:~daniel/WikiSense/Contributors.php toollabs:xtools/articleinfo/ Automatically redirects.
User rights tools:~dungodung/cgi-bin/userrights? toollabs:rightstool/cgi-bin/userrights
Can be handled by the link at the bottom of the user contribs link:
http://en.wikipedia.org/w/index.php?title=Special:ListUsers&limit=1 		From the RfA toolbox
Watcher tools:~dispenser/cgi-bin/watcher.py http://dispenser.info.tm/~dispenser/view/Watcher
The "Page information" link in the sidebar box titled "tools" handles this. 		Labs missing required database views

Toolserver account blocked Aug 27, 2014[1]

Webchecklinks tools:~dispenser/view/Checklinks http://dispenser.info.tm/~dispenser/view/Checklinks Used on Template:DYK tools
Automatically redirects

Toolserver account blocked Aug 27, 2014[1]

Other replacements

A replacement for http://stats.grok.se/ can now be found at toollabs:pageviews.

Notes

  1. ^ a b c d e f Post on User talk:Dispenser on Wikitech
If it exists already somewhere, please say and I'll delete it. Otherwise, please help expand it and we can stick it somewhere useful or link to it. Many thanks, Anna Frodesiak (talk) 08:39, 2 July 2014 (UTC)
The main list is mw:Wikimedia_Labs/Tool_Labs/List_of_Toolserver_Tools. --Nemo 10:03, 2 July 2014 (UTC)
Wow, that's a monster. I think the table might still be useful. Thoughts? Anna Frodesiak (talk) 10:21, 2 July 2014 (UTC)
toollabs:tools-info/migration-status.php --Glaisher (talk) 11:31, 2 July 2014 (UTC)
Thanks for the link. :) Anna Frodesiak (talk) 11:45, 2 July 2014 (UTC)
  • I added Dispenser's "Dab links" to the above table. Haven't figured out how to add it anywhere else. But this tool has been essential to the review process at Template:DYK tools. — Maile (talk) 13:07, 4 July 2014 (UTC)
I'm not able to get Reflinks with any of the above substitutions/replications or whatever.
Can't help but noticing the similarity between the Vogon's reply to Earth's complaint just before he annihilates it to make way for a hyperspace bypass in Hitchhikers Guide to the Galaxy. "You should have read the notice down at the main office on Alpha Centuri. It was posted there months ago!" :) Student7 (talk) 21:12, 4 July 2014 (UTC)
@Student7: What happens when you try https://tools.wmflabs.org/dispenser/cgi-bin/webreflinks.py?page=The_Hitchhiker%27s_Guide_to_the_Galaxy&client=script&citeweb=on&overwrite=simple&limit=10&lang=en GoingBatty (talk) 21:18, 4 July 2014 (UTC)
"Server not found." The same as with the other trials. Thanks for your interest! I am using Firefox. I can't think of any other useful differences... Student7 (talk) 01:36, 5 July 2014 (UTC)
@Student7: Just worked for me. Keep trying - maybe Dispenser is having troubles keeping the server up 24/7. GoingBatty (talk) 13:29, 5 July 2014 (UTC)
Thanks. No. After a dozen tries, still get same message with "Firefox can't find the server at dispenser." I am on Windows XP. Will try Windows Vista and see if that works. Student7 (talk) 18:30,5 July 2014 (UTC)
Just tried Windows Vista for a dozen consecutive "..not found"s. So my problem is not the version of Windows. Some consolation!  :) Student7 (talk) 19:33, 5 July 2014 (UTC)

Ancestry section when using ipad4

This generally does not open properly to reveal show or hide. The solution is to remove m. In the URL. Please fix. Kittybrewster ☎ 07:42, 4 July 2014 (UTC)

@Kittybrewster, I'm having trouble unravelling the riddle, but if the issue appears to be the m in the url, as in "mobile view", the issue is that a template is not expanding? For example, in https://en.m.wikipedia.org/wiki/Template:Ancestry_of_Australians#editor/0 ?
Now if I select "mobile view" at the foot of the Anglo-Celtic Australian article, I don't see the templates at the foot of the article in mobile view anyway.
In desktop view, the template expands / contracts as usual, for me. I'm trying to duplicate the problem on a Chromebook. But if you are using desktop view on your iPad4, the template doesn't expand / contract? What is an example article with the issue? --Ancheta Wis   (talk | contribs) 13:29, 4 July 2014 (UTC)
[100] Kittybrewster ☎ 16:27, 4 July 2014 (UTC)
The box has the navbox class. Same problem as #Authority control template not showing in mobile above. --Redrose64 (talk) 16:40, 4 July 2014 (UTC)
well the ancestry of Queen Elizabeth II reveals itself so I can't see why they are, not treated the same. Kittybrewster ☎ 17:37, 4 July 2014 (UTC)
It is treated the same. When I go to Elizabeth II, I see one line:
Main articles: Ancestry of Elizabeth II and Descent of Elizabeth II from William I
I don't see the "Ancestors of Elizabeth II" box. This is consistent with Charles I, Duke of Brunswick-Wolfenbüttel, where the box "Ancestors of Charles I, Duke of Brunswick-Wolfenbüttel" is also undisplayed. As I say, it's because that box has the navbox class, which doesn't display in mobile. --Redrose64 (talk) 19:10, 4 July 2014 (UTC)

Categorization

Is there a way to have only articles in a category by default? Xaris333 (talk) 17:38, 5 July 2014 (UTC)

@Xaris333: By default categories are empty, in order to get put in a category a page must be specifically edited to add the category. — xaosflux Talk 17:41, 5 July 2014 (UTC)

Ok, I wasn't clear. I have a template that put pages in a category if they have a specific problem. (The pages may use the template and if they don't have the problem, they will not been in the category). I want only tha articles to put in that category, no the others pages. Xaris333 (talk) 17:45, 5 July 2014 (UTC)

@Xaris333: You could use coding like {{#ifeq:{{NAMESPACE}}|{{ns:0}}|Stuff for articles only|Stuff for other namespaces}}, or the template {{Main other}} which also uses that method. SiBr4 (talk) 17:57, 5 July 2014 (UTC)
Refer us to your template and what you want to accomplish and someone should be able to help. What you want to do sounds like it is possible, but the syntax may need adjusting if you want a template argument to change the categorization included. — xaosflux Talk 18:03, 5 July 2014 (UTC)
@SiBr4: BTW, can't {{Main other}} and other "[foo] other" templates use namespace detect module? --Edgars2007 (talk/contribs) 18:15, 5 July 2014 (UTC)
They could be changed to use Lua instead, though they currently use parser functions (easily verified by looking at their code). SiBr4 (talk) 18:20, 5 July 2014 (UTC)

Copied Xaris's reply from my talk page:

The template is el:Πρότυπο:Football teams/Κατάλογος ομάδων and the category is el:Κατηγορία:Πρότυπο:Football teams για ομάδα που δεν υπάρχει στον κατάλογο. I tried to do what you said but maybe I write it wrong. Xaris333 (talk) 18:29, 5 July 2014 (UTC)

SiBr4 (talk) 18:33, 5 July 2014 (UTC)

@Xaris333: In that case you would change the part <includeonly>[[Κατηγορία:Πρότυπο:Football teams για ομάδα που δεν υπάρχει στον κατάλογο]]</includeonly> to {{#ifeq:{{NAMESPACE}}|{{ns:0}}|[[Κατηγορία:Πρότυπο:Football teams για ομάδα που δεν υπάρχει στον κατάλογο]]}}. The <includeonly>...</includeonly> tags are no longer necessary, though it doesn't hurt to keep them. SiBr4 (talk) 18:39, 5 July 2014 (UTC)

It works for templates and user pages! Doesn't working for user talk page. Maybe I have to wait more. Xaris333 (talk) 18:47, 5 July 2014 (UTC)

The one user talk page is in the category because of an inline link to the category missing a :, putting the page itself in the category. I've fixed that here. The namespace selection works fine. SiBr4 (talk) 18:55, 5 July 2014 (UTC)
Thx for everything User:SiBr4. Thx everyone for you help. Xaris333 (talk) 18:58, 5 July 2014 (UTC)

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

Tracked in Phabricator
Task T20231

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

So, in this example:

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

hovering the mouse over [1] produces:

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

hovering the mouse over: [2] produces

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

hovering the mouse over [3] produces:

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

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

I built this (one of several systems) for such markup back around 2000. It's a nightmare. The extra markup you have to place into the body text to indicate just what and where is being sourced quickly becomes onerous. It's especially bad when there are multiple citations and they overlap, but not in a nested fashion. No-one bothers with it these days. Take a look at TEI for what's probably the lead in this sort of system.
Better approaches seem to take it the other way. Annotate the citations to indicate the scope to which they apply. This can use techniques like XPointer or even the old Purple Numbers. Most of these systems for practical use then need auto-coalescence of the cited regions, such that citation markers only appear once per joined block, not repeated for every region.
The systems that mostly work for such needs are legalistic and work by formalising the structure of the text. Everything breaks down to statements or clauses, none of which can be compounds. It's easy (and usually verbose) to number each of these. The addressing becomes a simple matter of listing numbered paragraphs. It works, it's specific and it's also horribly unreadable. Not what we want at all. Andy Dingley (talk) 12:21, 27 June 2014 (UTC)
Well, that doesn't sound very useful! :o) (I didn't understand most of what you said.) I'm not too bothered - at least in this prototype stage - how much effort it takes on the editor's part, but if it's really very onerous others will object to me putting it on articles. And it would need to appear to the reader like any other en.WP citation, except for the extra feature. If it can't effectively be done, no worries.
I was thinking the editor could just copy and paste the relevant article text against a template parameter
|supports="Blah blah blah" "Alpha beta gamma"
and any text on the page exactly matching the text within quotation marks would be automatically highlighted. From this user-point-of-view that would be the simplest, but if that's not doable, then the simple feature I'm looking for is probably unattainable. --Anthonyhcole (talk · contribs · email) 12:40, 27 June 2014 (UTC)
@Anthonyhcole: What you described is doable, of course, but I'm not sure if it would be practical:
  • I can't think of a way to do this without forcing the user to adjust technicalities about such tags when new content is added (in your example, the texts would have to be updated in both places; some numbering approach like what Andy described would require updating the numbers). This could be avoided by implementing this in VisualEditor, but then VisualEditor is hated around here for some inexplicable reason and doing that would surely get someone hanged.
  • Allowing one <ref> tag to provide a citation for several text fragments instead of just one also feels problematic (if you think you need this, it means you actually want to use <ref name>!). This actually would be more problematic from the interface standpoint in a visual tool than in wikitext.
That said, a more limited version of such a tool (where a single ref would only provide citation for a single and adjacent and immediately preceding wikitext fragment) looks feasible to me, and hopefully it wouldn't be too awkward to use neither in wikitext nor in VisualEditor; but I think one should first think really hard about both the wikitext formats and possible visual interface for such a thing. Matma Rex talk 18:36, 27 June 2014 (UTC)
To clarify, here's a variant of your original examples that I believe to be feasible. I don't think any meaning is lost.
At any given time, about half of all patients with malignant cancer are experiencing pain[1], and more than a third of those (and two thirds of all patients with advanced cancer[3]) experience pain of such intensity that it adversely affects their sleep, mood, social relations and activities of daily living.[2]
At any given time, about half of all patients with malignant cancer are experiencing pain[1] and more than a third of those (and two thirds of all patients with advanced cancer[3]) experience pain of such intensity that it adversely affects their sleep, mood, social relations and activities of daily living.[2]
At any given time, about half of all patients with malignant cancer are experiencing pain[1], and more than a third of those (and two thirds of all patients with advanced cancer[3]) experience pain of such intensity that it adversely affects their sleep, mood, social relations and activities of daily living.[2]
Matma Rex talk 18:43, 27 June 2014 (UTC)
I'll love the VE when it's finished. :o) The bug linked by WhatamIdoing below seems to aim at the solution you're targetting, Matma Rex. I might just add my support to that, with a proposal for the hover feature. Thanks for your input. --Anthonyhcole (talk · contribs · email) 02:34, 28 June 2014 (UTC)
This isn't entirely a new idea; T20231 was filed in 2009. Some of the comments there might be relevant. If you don't have or want a (free, but e-mail-address-exposing) Bugzilla account, then just leave a note on my talk page, and I can post any comments there that you'd like to add to the enhancement request. Whatamidoing (WMF) (talk) 22:39, 27 June 2014 (UTC)
Whatamidoing, I created a Bugzilla account last night, but I'm not sure what to say there. Can I just add a support for the feature and add a request that the "hover-over-the-footnote-marker" feature be included? That place looks like my "pending" basket, where I poke stuff I'm never going to get done. But if you think it's not utterly futile, I'll throw it in. --Anthonyhcole (talk · contribs · email) 02:34, 28 June 2014 (UTC)
I think it's not utterly futile, and I'd encourage you to post it. Bugzilla etiquette is generally that comments which say only "me too" are discouraged, but that any comment suggesting another way to do it (your hover-over idea, for example) or any related problem or implementation challenge is very welcome. Whatamidoing (WMF) (talk) 03:58, 28 June 2014 (UTC)
Thanks. Will do. --Anthonyhcole (talk · contribs · email) 04:59, 28 June 2014 (UTC)

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

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

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

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

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

  1. ^ "test 1". 
  2. ^ test 2 
  3. ^ test 3 

— Makyen (talk) 17:26, 28 June 2014 (UTC);update to be an exact match to the requested highlighting. Add |url= to {{cite web}}14:48, 2 July 2014 (UTC)

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

Anthonyhcole, yes. The person reading the page will need to have added the import of the user script User:Makyen/RefSupports.js to either their common.js page, or the .js page for the skin that they use. I just briefly tested it in all of MonoBook, Modern and Cologne Blue and it was working fine. Thus, your common.js page is probably the most appropriate.
The easiest instructions are to:
  1. Copy the following:
    {{subst:iusc|User:Makyen/RefSupports.js}}
  2. Then Click on this link to edit your your common.js page.
  3. Paste the text you just copied onto the page that opens, which is your common.js.
  4. Save the page and bypass your cache to make sure the changes take effect.
— Makyen (talk) 01:47, 29 June 2014 (UTC)
Ah. Sorry, I'm looking for this, but for all readers of the article, not just those with an account who've added js. Is there any way to tweak your solution so that the highlighting appears for all readers whose mouse hovers over a footnote marker? --Anthonyhcole (talk · contribs · email) 09:50, 29 June 2014 (UTC)
Ahh..I see. I can understand that you actually desire functionality to be available to everyone. Another time, it would be very helpful for that to be stated up front. There is a very significant difference between all levels of use for something that is available for you, that is available optionally to small groups of people, available optionally to larger groups of people, and something that is basic functionality provided by default to everyone.
It is possible to have JavaScript that is run for all people viewing the page. It is a significant process to go from a user script to something that is run for everyone. Usually a user script is offered by a user to be available to the community. Then, if it becomes sufficiently used and desired by the community, it can be adopted as a gadget, which gives it more visibility and makes it easier to enable/disable. It is possible, but very unusual, for it to be included such that it is automatically loaded for everyone.
However, it is not clear to me that there is consensus that this is functionality the community desires to have for everyone. Although I could have easily missed it, I am not aware of any RfC that was done to see if the community desires this functionality. As I understand it, one method of beginning to see if it is something the community desires is to post an RfC at Village pump (proposals)‎‎. However, that is only for the English Wikipedia. If you are desiring it to be standard functionality across all Wikipedias, then an RfC is needed on Meta with global participation. I would suggest initiating an RfC to determine if this functionality is desired by the community prior to proceeding further. If there has been such an RfC, I would appreciate a pointer to it. — Makyen (talk) 02:35, 30 June 2014 (UTC)
Sorry, I've just noticed this comment. --Anthonyhcole (talk · contribs · email) 12:26, 2 July 2014 (UTC)

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

Do I mind? The short answer is yes. On the other hand: Ultimately, it is your money and you get to make the choice as to how to, when to, or even if to, disburse it. Another time, I would have appreciated that being stated up front, or at least phrasing the offer in a manner that does not imply the urgency/competition of being "first". While I might have worked on something had I known this to be the case, I certainly would not have done so in the time-frame I did. — Makyen (talk) 02:35, 30 June 2014 (UTC)
Makyen, just to be clear, I offered the money to whichever person or team met the brief. Do you claim to have met the brief? --Anthonyhcole (talk · contribs · email) 15:25, 30 June 2014 (UTC)
Anthonyhcole:
[Note: Shortly before this post, I updated the script with improvements and additional features.]
My belief is: Yes, the original brief is fulfilled. However: This is a situation where I am attempting to write something that fulfills your requirements. In such situations, it is much easier to match your requirements and desires if you can tell me where you see issues or features that are lacking, or where you would like improvements. I can program for years attempting to guess at what it is that you desire to be changed. Without feedback as to what features you desire to have changed, improved, or added I have to go off of what I feel should be included and guess at what more/different it might be that you want.
As to specific enhancements/fixes, I would suggest that we move that portion of this discussion to User talk:Makyen/RefSupports.js so as to not clutter this page with the specifics of the development of the script. Of course, any unresolved issues that you believe cause there to be a failure to meet the brief can be mentioned here. I, of course, am also interested in fixing any bugs which you, or others, might find. If you find one please inform me. If so, please provide an example page where the bug shows up.
The goal is to get you what you want while not significantly exceeding what I understood the brief to be. [I'm not trying to hedge here, nor say that I am unwilling to go beyond what I understood the brief to be.] This is a normal issue for contract work. The goal is to fulfill the customer's requirements while staying within both what is possible and reasonable (for both parties and the environment in which it is done). This can often be a source of concerns for both parties as things not specified in the original brief or foreseen by one party or the other come to light. [I'm not trying to hint at anything specific, just a general statement about performing work to specification.]
I would appreciate any feedback you can provide as to what you would like to see improved. I have put a brief list of ease-of-use improvements I see as desirable for something which would be deployed to a wide group of people, and which I plan to work on in the near future, at User talk:Makyen/RefSupports.js#Planned improvements. — Makyen (talk) 14:48, 2 July 2014 (UTC); remove reference to deleted post 23:41, 2 July 2014 (UTC)
I've deleted my last post (that you refer to) so as not to distract us, for now. If you'd prefer to restore it, go right ahead.
I want to add citations to an article, Cancer pain, that function like this: When a reader - any reader, not just logged-in readers, or readers who have installed a script or enabled a gadget - hovers their mouse-pointer over a footnote marker, the text supported by the source that footnote marker links to is highlighted. I'm not bothered how fiddly or arduous it is for the editor, at this prototype stage. But I would expect it to function, from the readers' point of view, just as our existing footnoting does, with the addition of this one feature. For now, I just want to put it on one article, Cancer pain, as a trial. It doesn't need to be something that can be easily replicated right across this or other projects.
If we need to dispense with the existing citation templates, I'm quite happy to rewrite all the citations by hand. --Anthonyhcole (talk · contribs · email) 15:24, 2 July 2014 (UTC)
Anthonyhcole: Having a solution that works for everyone requires relying on either using elements that already exist, or making changes to universally served pages (CSS or JavaScript). With changes to CSS, the format where text adjacent to the reference is highlighted upon hovering the mouse over the entire text is possible (it would likely be that it would be highlighted if you hover the mouse anywhere in the suported text, not just the reference marker). This would look something like what Matma Rex posted above. With JavaScript (JS), what I implemented is possible where the text supported by the reference is highlighted everywhere on the page when you hover on the reference. For an example see reference 28 in test01 which has text supported prior to all 5 places where it is used. However, significant changes to the information universally served only happen (in theory) when it is a change for which there is widespread consensus that it should be default functionality (see my posting above regarding an RfC, etc.).
As to using CSS or JS based on only changes that a regular editor can make to the page: it is something that is actively restricted by Wikipedia. Permitting users to add JavaScript to pages would present serious security issues and thus is technologically prevented. Being able to add a CSS sheet would result in a loss of uniform look-and-feel for Wikipedia (and other issues), and is thus also not permitted. That is why changes to files of these types (.css and .js) which affect your viewing experience are limited to a very few, specially protected files within each individual user's user-space.
The choices of ways to accomplish this using elements that are already available are, at best, very limited. I have not determined any way to get to what you describe (highlighting supported text on the page) using the available elements. However, I have implemented one method which gives that information at test02/sandbox2.
Here it is implemented on your example text:

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

  1. ^ "test 1".
  2. ^ test 2
  3. ^ test 3
This will work for everyone (or at least close to everyone), but is not quite what you have asked for. You will need to have both Navigation popups and Hovercards disabled, or hover over the area just below, but not on, the citation number. — Makyen (talk) 23:41, 2 July 2014 (UTC); Added the implementation of the example text in-line to be consistent with the other implementation examples. 13:26, 4 July 2014 (UTC)
Anthonyhcole: I have implemented another method of doing something that approximates what you described in a way which can be viewed by everyone. The primary difference with this one is that instead of hovering over the [1] you have to click on the "s" that is just below the reference (e.g. [1]
s). Another significant difference is that when you click on the "s" your browser will scroll the window to the supported text. Personally, I find the scrolling of the window to see the reported text a bit annoying. On the other hand, as I use it I am getting a bit more used to the scrolling for this purpose. For this method there has to be a separate "s" for each non-contiguous supported text segment. The example is also at test02/sandbox4.
Here it is implemented on your example text:

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

  1. ^ "test 1".
  2. ^ test 2
  3. ^ test 3
I have also added the tooltip version example text in-line within my prior post (above) to be consistent with having the other examples in-line instead of only at a linked page.
I would appreciate some feedback as to if either of these implementations is something you desire to pursue, or if you would like changes to either of them. — Makyen (talk) 13:26, 4 July 2014 (UTC)
I really like the tooltip (underline) idea. Sold. Can you please email me with your account details or other preferred payment instructions? I'm in Australia but I can arrange a direct deposit into a bank account anywhere. And will you talk me through any technical implementation problems when I get around to adding it to the article? (It will take a while before I start because I'll need to hit the books again to establish what supports what - it's been a couple of years.) --Anthonyhcole (talk · contribs · email) 01:19, 8 July 2014 (UTC)
I am glad you like it. I have expanded the documentation at {{Ref supports2}} which is the template used for that method. If you would like, we can, of course, change the template name, or make an alias which is more convenient to use.
I am happy to continue to provide support, which includes talking you through any problems and making any changes to the template which are needed/desired. My expectation is that adding these to the page will take some time as it requires reading each reference to determine exactly what is supported by which reference. — Makyen (talk) 02:49, 8 July 2014 (UTC)

Rough translation template, listed parameter

I added the listed parameter to the {{rough translation}} template at Church of the Holy Mother of God, Kuršumlija but the PNT section still isn't showing up. Did I do something wrong? —Largo Plazo (talk) 13:41, 3 July 2014 (UTC)

From what I can tell, the message

If you have just labeled this page as needing attention, please add
{{subst:Needtrans|pg=Wikipedia:Village pump (technical)/Archive 127 |language=Serbian |comments= }} ~~~~
to the bottom of the WP:PNTCU section on Wikipedia:Pages needing translation into English.

is only shown if |listed=yes is absent. Is that not the correct behaviour? However, on examination of {{pnt notice}} I do notice that the coding is a mess: although all the opening brackets are balanced by closing brackets, the nesting is wrong, with the result that a <small> is left open, which is why this paragraph is small, so I need to explicitly fix it like this:</small> - now back to normal. The brackets, etc. that are misnested may be summarised as 
<small> [{{ ]}} {{ </small>}}
It's also got two </br> which are invalid, presumably these should be <br />. --Redrose64 (talk) 14:20, 3 July 2014 (UTC)
I cleaned up {{pnt notice}}. --Redrose64 (talk) 21:00, 3 July 2014 (UTC)
Sorry, I wasn't clear. If the template is marked as listed, then it ought to display a link taking the reader to the listing. Compare this from the {{Not English}} template, as currently displayed, for example, at ശ്യാമ പ്രസാദ് മുഖര്ജീ: "Please see this article's entry on Pages needing translation into English for discussion." —Largo Plazo (talk) 23:09, 3 July 2014 (UTC)
Never mind, the problem wasn't that the link to PNT wasn't being displayed, it's that there wasn't any code to display it. I took care of it. —Largo Plazo (talk) 13:50, 6 July 2014 (UTC)

Autoblock checker

Since this left Toolserver, I've not been able to make any sense of this. Previously, it was slow, but it returned an answer automatically. All I seem to get is a box to put something in and submit, and when I do (in the latest case, an IP address), I get no response that is comprehensible to me. Am I missing something, or doesn't it work? Peridon (talk) 09:06, 5 July 2014 (UTC)

Can you provide an exact link to the tool you're referring to? — This, that and the other (talk) 10:15, 5 July 2014 (UTC)
https://tools.wmflabs.org/xtools/autoblock/?user=202.130.202.250 for an example. Peridon (talk) 10:43, 5 July 2014 (UTC)
@Cyberpower678: ?? — This, that and the other (talk) 11:57, 5 July 2014 (UTC)
All I'm doing is clicking the link 'autoblocks' at the top of an unblock request. It doesn't put 'project' in. Peridon (talk) 15:25, 5 July 2014 (UTC)
Just clicked T13's link - still no better. Tells me absolutely nothing. There's a choice of four buttons (# id admin action) and no indication of what they are or if I'm supposed to click one of them. Doesn't even have one labelled 'Drink me'... For all I know, one might be the ejector seat. Peridon (talk) 15:30, 5 July 2014 (UTC)
It's the content underneath it that matters, and since there's nothing, it means there's no autoblock.—cyberpower ChatOnline 15:39, 5 July 2014 (UTC)
Couldn't a little message appear to say that? Better to say 'No' than to just stare blankly at you and say nowt. Peridon (talk) 15:47, 5 July 2014 (UTC)
I opened a request for you here.—cyberpower ChatOnline 18:48, 5 July 2014 (UTC)
I'm confused. Bugtracker is Wikimedia Bugzilla as per the request here, wondering when and why GitHub comes into play. Or maybe people don't find two bugtrackers confusing and it's just me? --AKlapper (WMF) (talk) 11:21, 6 July 2014 (UTC)
Updated Template:unblock to include "&project=en.wikipedia.org" to avoid the error message. — xaosflux Talk 15:49, 5 July 2014 (UTC)
Thank you for correcting that, Xaosflux. Would you (or someone else) mind also updating {{unblock-un}}, {{unblock reviewed}}, and any other of these that require it? Thanks ​—DoRD (talk)​ 16:16, 5 July 2014 (UTC)
  Done. — xaosflux Talk 17:09, 5 July 2014 (UTC)
Excellent! ​—DoRD (talk)​ 17:46, 5 July 2014 (UTC)
Ta muchly. Peridon (talk) 18:43, 5 July 2014 (UTC)

Problems with sortable tables in this article

The article List of countries by electricity production from renewable sources has a problem with the second sortable table (all countries). The problem is the note on Canada item (Geothermal column). Scrapping it, the table sorts perfectly. But also some items on Biomass column have notes (i.e. Italy), and I don't know why the table is all right with this one and it has problem with the former. Could you help me? Thanks.--Carnby (talk) 12:31, 6 July 2014 (UTC)

@Carnby: I added a data-sort-value in the table to get it to sort properly - see Help:Sorting#Specifying a sort key for a cell. Happy editing! GoingBatty (talk) 13:21, 6 July 2014 (UTC)
  Thanks--Carnby (talk) 20:48, 6 July 2014 (UTC)

Template:Extra music sample

I noticed when this template in invoked in infoboxes, there's no option to change the language of the subtitles. That makes it a bit confusing or frustrating for a reader who, for example, is listening to a sample of a non-English song and wants its subtitles in English, or is seeing its subtitles in English but wants them in the song's given language (e.g. see the articles of the song "Bloqué" and its album Orelsan et Gringe sont les Casseurs Flowters). The captions option only appears when {{Listen}} is used (as with the album's article), but not when {{Extra music sample}} is used (as with the song's article). I have no idea how to fix that so here I am. Davykamanzi → talk • contribs • alter ego 14:50, 6 July 2014 (UTC)

The template used a fixed width (140px) and that in effect hid the other options. I removed the fixed width value and now {{Extra music sample}} seems to be showing everything {{Listen}} does. -- George Orwell III (talk) 16:16, 6 July 2014 (UTC)

Edit no longer works with Firefox 3.6.28

Edit has topped working with Firefox 3.6.28, which is the latest than can be used with a PPC Mac; although it does still work with Safari 4.1.3 (ditto).

In the former case, it looks as if it's going to work, but then the editable content goes completely blank.

Is this a bug that can be fixed, or is it just the March of Progress?

Paul Magnussen (talk) 15:46, 6 July 2014 (UTC)

I guess this refers to classic editing of a wikipage (and not something like VisualEditor or so)? If there is anything like an error console in that Firefox version (or some extension providing that), you could check for errors. (According to mw:Compatibility/Software for using MediaWiki FF3 receives Grade B support.) --AKlapper (WMF) (talk) 20:50, 6 July 2014 (UTC)
Interestingly, however, Safari 4 support does not meet even Grade B requirements, since italicised text appears offset by three characters, e.g. (to take today's featured article), 'Pope Paul III and His Grandsons' appears as 'Rqrg"Rcwn"KKK"cpf"Jku"Itcpfuqpu'. Paul Magnussen (talk) 22:02, 6 July 2014 (UTC)
No, there is no error console or other error indication, so I guess this is indeed just the March of Progress. 98.248.106.108 (talk) 22:08, 6 July 2014 (UTC)

False positive for shouting when using {{ITALICTITLE}}

See https://en.wikipedia.org/w/index.php?title=Americans_for_Safe_Access_v._Drug_Enforcement_Administration&diff=prev&oldid=615877069 ValorMauls (talk) 23:06, 6 July 2014 (UTC)

@ValorMauls: The template is {{Italic title}} so I wouldn't necessarily call this a false positive even though ITALICTITLE does redirect to the non-shouted version. Did you see some page or message that instructed you to use the all caps version? If you did, please advise as that should be fixed.--Fuhghettaboutit (talk) 00:01, 7 July 2014 (UTC)
Note, the shouting tag came from Special:AbuseFilter/50. — xaosflux Talk 00:34, 7 July 2014 (UTC)
  Done I've updated the filter to not tag when adding uppercased templates. — xaosflux Talk 00:41, 7 July 2014 (UTC)
  Done - thanks for the list! GoingBatty (talk) 17:28, 7 July 2014 (UTC)

Tech News: 2014-28

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

Tech News updates

  • We are looking for contributors to help write a new issue every week. If you would like to help, please contact us.

Recent software changes

  • The latest version of MediaWiki (1.24wmf12) was added to test wikis and MediaWiki.org on July 3. It will be added to non-Wikipedia wikis on July 8, and to all Wikipedias on July 10 (calendar).
  • CirrusSearch was enabled on July 1 as the primary search method on 36 new wikis, including the Norwegian (no), Portuguese (pt) and Ukrainian (uk) Wikipedias. [101]
  • It is now possible to create Atom or RSS feeds for Word of the Day, Word of the Week and similar entries on Wiktionary wikis. [102] [103]
  • You can now use a graphical interface to edit TemplateData information on the English (en), French (fr) and Italian (it) Wikipedias. [104] [105]

VisualEditor news

  • Saving an edit with VisualEditor will now be much faster. [106] [107]
  • You can now add a caption when you add a file to a page with VisualEditor. You can also change the file to a different one and keep the existing caption. [108] [109] [110]
  • When you switch to the Edit source tab, you are now asked to keep your changes. You no longer need to find the option in the menus. [111] [112] [113]
  • The reference tool that adds empty <ref></ref> tags is now at the bottom of the Cite menu, below references that use templates like {{Cite web}}. [114]
  • Context menus will no longer be shown over items that you can edit directly, for example formulæ. [115] [116] [117]

Future software changes

  • Starting on July 9, it will be possible to globally rename global (SUL) users. The feature was first scheduled for July 1, but was delayed due to bugs.
  • A plan to enable CirrusSearch as the primary search method on the 11 largest Wikimedia wikis has now been prepared. [118]
  • If you use references on a page, you will soon always see them at the bottom of the page, even if you forget to add the <references /> tag (or a template). [119] [120]
  • Black-and-white XCF images will soon display correctly. [121] [122]
  • Description pages of SVG files will soon always show download links for multiple resolutions (example). The links were previously shown only for SVG files in large original resolutions. [123] [124]

Problems

  • Between July 2-3, there were problems with loading pages on multiple wikis due to a configuration issue. [125] [126]
  • For a few hours on July 1, there were problems with uploading new files on Wikimedia Commons due to a configuration error. [127] [128]

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

07:07, 7 July 2014 (UTC)

2010 Jacksonville Sharks season

Can someone please remove the Jacksonville Sharks category from this page? I don't know how to do it. Thanks, Arena Football Rooter (talk) 22:14, 7 July 2014 (UTC)

@Arena Football Rooter:   Done via this edit to Template:Jacksonville Sharks roster. That template is on both 2010 Jacksonville Sharks season and List of current Arena Football League team rosters. If the template is truly a current team roster, it probably doesn't belong on an article about the 2010 season. Happy editing! GoingBatty (talk) 22:23, 7 July 2014 (UTC)
Thank you for finding the problem! I've removed the template from the 2010 article and reverted your edit on the template so that it (the template) will go back in the Jacksonville category. Thanks again, Arena Football Rooter (talk) 22:26, 7 July 2014 (UTC)
@Arena Football Rooter: By reverting my edit to Template:Jacksonville Sharks roster, you readded Category:Jacksonville Sharks to List of current Arena Football League team rosters. You may want to revert your reversion. GoingBatty (talk) 22:33, 7 July 2014 (UTC)
Done. I didn't realize it was going to do that. Arena Football Rooter (talk) 22:45, 7 July 2014 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)/Archive_127&oldid=1138189078"