Misplaced Pages

Revision as of 08:11, 7 June 2014

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

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

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

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

Village pumps

policy

tech

proposals

idea lab

WMF

misc

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

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

History merge and undelete

Dear technical experts: I am learning to perform history merges, and I want to make sure that I have a clear understanding of the process. I have two questions:

• Some articles have in their history revisions that are deleted even though the article itself is not deleted. For example, Madison Eagles has 250 deleted edits because it was deleted many times. Other articles may have had selective revision deletions. If in the process of a history merge, or as a result of an undelete request, a deleted article with this mixed history is to be undeleted, how can you tell which of the revisions to restore, and which should remain deleted? Or do you have to make a note of this ahead of time?

• Am I right in assuming that when an article is deleted, then selectively restored, and later moved leaving a redirect, only the restored edits are moved to the new title, leaving the deleted edits in the history of the old page which is now a redirect? —Anne Delong (talk) 02:39, 25 May 2014 (UTC)

• If it has mixed history, you need to make a note ahead of time. It's not as bad as it seems, though, since unless weird stuff already happened with the page, all of the "real" deleted revisions will be older than the temporarily deleted ones. Worst case, you may find yourself comparing timestamps on log entries.
• Yes. Deleted edits don't move. Jackmcbarn (talk) 02:51, 25 May 2014 (UTC)

• Thanks, Jackmcbarn. Okay, checking the deletion log times makes sense. However, sometimes an article is deleted and restored, and other times an article is deleted and then newly created. If an article is to be restored, for example as a result of a G13 refund request, it would seem that I should look down the list past any previous delete/restore pairs until I come to a page creation, and stop there even if there are more deletions and restorations further back. Is there no way in this case to detect selective revision deletions, since the article will have already been deleted before I see it? —Anne Delong (talk) 03:27, 25 May 2014 (UTC)

There's no way to know exactly which revisions used to be deleted. If you get a messy case like this, you can make it simpler by moving the pages elsewhere (to get a clean area to put the deleted revisions), performing the history merge, then moving the result back where it belongs. See for an example of when this was done. Jackmcbarn (talk) 03:45, 25 May 2014 (UTC)

• I tried this on one of my own user pages. First I copied User:Anne Delong/Burleigh Falls to User:Anne Delong/Burleigh Falls (2), and then added late edits to the first while improving the second. I followed the standard instructions, but although the article looked good on the surface, this left the late edits jumbled into the history as expected. Then I did another copy-paste to User:Anne Delong/Burleigh Falls (3), added AfC comments to the old page and editing the new one as well. This time I used the alternate instructions, moving the new page over the old, then undeleting everything except the AfC comments and the junk from the first failed merge. Then I moved the page back. I think it's right this time. Can someone check my work and see if I have forgotten anything? —Anne Delong (talk) 10:59, 25 May 2014 (UTC)
  • From my perspective, that looks good. I can't be sure, though, since I can't see what revisions are deleted. Jackmcbarn (talk) 15:05, 25 May 2014 (UTC)

• Okay, next question (sorry). I didn't see anything in the instructions about accompanying talk pages. I'm presuming that if I just move an article page, merge it with a draft, and move it right back, the talk page will just stay there and nothing will need to be done. But, now that the AfC submissions are being moved to Draft space, in the future there could be two talk pages involved. It doesn't seem right to leave old discussions on the talk page of a redirect, where they would never be seen. Should these just be cut and and pasted to the talk page of the mainspace article? Couldn't that cause broken links? I know that this isn't so much a technical question, but it kind of goes with the rest.... —Anne Delong (talk) 16:15, 25 May 2014 (UTC)
  • If they're worth keeping at all, then yes, just copy and paste them. Jackmcbarn (talk) 17:33, 25 May 2014 (UTC)
    • Since the talk page entries are supposed to be signed this sounds good, but to retain attribution it is better to histmerge the talk page too. All the best: Rich Farmbrough, 23:07, 2 June 2014 (UTC).
      

Infobox Image

Suddenly the infobox images all over Misplaced Pages 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)

• Issues in regular thumbnail sizes, see List of highest-grossing films in the United Kingdom. — Crisco 1492 (talk) 02:16, 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 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 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 , 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 Misplaced Pages. 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 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 . After manually purging the cache of an article, the proper infobox image size was restored. --NeilN 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 ] 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)

• Very well put, Redrose64, thank you. The intention is to provide much better default behavior for images which are higher than they are tall, when no explicit size specification is given. See mw:Requests_for_comment/Square_bounding_boxes for some more background. C. Scott Ananian (talk) 20:56, 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 Misplaced Pages 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 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 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 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 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 Misplaced Pages 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 Misplaced Pages, and it seems, it was not even here. In German Misplaced Pages, 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 Misplaced Pages 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 Misplaced Pages 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 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 Misplaced Pages we saw the begin of what we call a Shitstorm (dewiki: de:Shitstorm), see de:Misplaced Pages 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 Misplaced Pages 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 Misplaced Pages. 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)

Nuking many redirects

After closing Misplaced Pages:Articles for deletion/List of Sonic the Hedgehog comic book characters, the closing script tells me that "Number of redirects exceeds limit of 50". Is there a way to delete them all at once?  Sandstein  19:14, 30 May 2014 (UTC)

@Sandstein: Add closeAFD_redirectlimit = 500; to User:Sandstein/vector.js. That will override the script's limit. Jackmcbarn (talk) 19:27, 30 May 2014 (UTC)

Thanks!  Sandstein  21:29, 30 May 2014 (UTC)

You closed with "Can be redirected at editorial discretion". Of course deleting all its own redirects makes this much harder. A redirect would have probably been a better close here. All the best: Rich Farmbrough, 16:03, 3 June 2014 (UTC).

Pageview data collection down

The pageview data is not dumping to the normal repository. It stopped over 24 hours ago.--TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 20:33, 31 May 2014 (UTC)

Issue has been fixed: Template:Bug. Also stats.grok.se and Wiki ViewStats went back to normal. --Hedonil (talk) 21:04, 3 June 2014 (UTC)

Forward/backward links in Special:ListFiles

The table is in chronological order, and sortable forward/backward by that column but no other. The links to jump between pages are named "First page", "Previous page", "Next page", and "Last page". Those terms are confusing because depending on sorting direction, "next" and "previous" could be parallel to the direction of time or opposite. For example, the default order appears to be newest first, then progressing back into history, but it's the "next" button that takes you to the next screen that is the previous timeframe. It would be clearer if they were called "older" (and "oldest") and "newer" (and "newest"), just like the analogous links are named in Special:Contributions.

Also, even on one of the extreme pages (first or last), all 4 links are still active, suggesting that there is something before the first page (or after the last). Again as with contributions-history and similar pageable lists, links that suggest additional content vs returning to the same page should be disabled. DMacks (talk) 02:13, 1 June 2014 (UTC)

• So, what you want to do is create MediaWiki:Table pager first with "Oldest", MediaWiki:Table pager prev with "Older", MediaWiki:Table pager next with "Newer", MediaWiki:Table pager last with "Newest"? Is that correct? — {{U|Technical 13}} 12:02, 1 June 2014 (UTC)

Those terms are the idea, but isn't "next page" the next older not newer, given default sorting is newest-to-oldest? DMacks (talk) 22:31, 1 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)

• GoingBatty, please read Misplaced Pages:Village pump (technical)/Archive 123#When will the Reflinks tool be moved to the stable server? where Dispenser has laid out his first demand for 24TB of disk space so that he can cache all 20 million external link so references can be done in a post processing stage where details (title, author, date) can be cross verified before he'll move the tool to Labs. — {{U|Technical 13}} 14:31, 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}} 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. πr (t • c) 12:36, 2 June 2014 (UTC)

Navigating mobile interface

I'm using Firefox on Android Galaxy S3 to access the mobile website. Is there any way to get to a talk page other than by manually editing the URL? Is there any way at all to do a wiki search? Please {{ping}} me. --Thnidu (talk) 05:20, 2 June 2014 (UTC)

@Thnidu: If you go into the Mobile website and into it's settings and then enable the Beta mode, you will get a new 'button' (with speech bubbles) that will take you to the Talk page. —TheDJ (talk • contribs) 07:36, 2 June 2014 (UTC)

Ping @Maryana (WMF): see above Steven Walling (WMF) • talk 23:02, 2 June 2014 (UTC)

Tech News: 2014-23

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.24wmf7) was added to test wikis and MediaWiki.org on May 29. It will be added to non-Misplaced Pages wikis on June 3, and to all Wikipedias on June 5 (calendar).
• CirrusSearch was enabled as the primary search method on all Wikipedias with less than 100,000 pages on May 30.

VisualEditor news

• Templates that redirect to other templates now get the TemplateData of their target.
• The toolbar of the PageTriage extension will no longer be visible after you save an edit with VisualEditor.
• VisualEditor now checks if your browser supports SVG files to avoid displaying broken icons.
• There is now a new type for TemplateData parameters: date for dates and times in the ISO 8601 format.

Future software changes

• MediaViewer will be enabled on the German (de) and English (en) Wikipedias on June 3. Feedback is welcome.
• You will soon see a warning if you visit a contributions page for a user that does not exist.
• The search tab will soon be removed from user preferences. You will be able to set your search preferences on Special:Search.
• You will soon see a label next to the little triangle arrow for the Actions menu in the Vector skin (screenshot).

Problems

• For about 20 minutes on May 29, all wikis were broken due to a configuration error.

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

08:08, 2 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 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 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 Misplaced Pages talk:WikiProject Ships#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 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 22:03, 5 June 2014 (UTC)

Finding earliest version of a Wiki article

I know clicking a date in an article's "Revision history" pages will show the version on that date, but I cannot see how to locate the earliest version of an article. This because at the top of the first page in "Revision history":

• I can't see how to fill in the box to find the earliest date.

• Clicking on external tool "Revision history search" below the box leads to a WikiBlame page, but I don't know how to fill it in correctly. (I tried putting in an early date, pressed "Start", but nothing happened.)

• I looked at Help:Page history and Help:Edit summary, but still couldn't understand how to find an article's earliest version.

Some help, please. --P123ct1 (talk) 12:46, 2 June 2014 (UTC)

There is a link called oldest: example after clicking Werieth (talk) 12:52, 2 June 2014 (UTC)

(ec) ...at the bottom of the page, not the top. Roger (Dodger67) (talk) 13:07, 2 June 2014 (UTC)

Thanks. I couldn't find that answer in the Help pages. --P123ct1 (talk) 16:58, 2 June 2014 (UTC)

Installing scripts

Any one know how to install scripts at Welish Misplaced Pages? I have asked a local admin there but I haven't got any proper answer. I mean I haven't understand what he said. So, can anyone help me? Jim Carter 19:13, 2 June 2014 (UTC)

• Jim, what do you mean by "installing"? — {{U|Technical 13}} 19:19, 2 June 2014 (UTC)

Technical 13 Just like we install scripts by importing the script to our common page on English Misplaced Pages. But how to do it on Welish Misplaced Pages? I mean is the process to install scripts at other Wiki's are same. Jim Carter 19:31, 2 June 2014 (UTC)

• So, Jim, you want to use enwp scripts on cywp? In that case, if you are using:

importScript( 'User:This_script.js');

Then you would use instead:

mw.loader.load( 'https://en.wikipedia.org/search/?title=User:This_script.js&action=raw&ctype=text/javascript' );

If you need further help, let me know. :) — {{U|Technical 13}} 19:38, 2 June 2014 (UTC)

I need help with coding a template...

I have recently created User:Josve05a/template-sanbox. RIght now I have to type {{User:Josve05a/template-sanbox|1=yes}} to show Reason 1 and {{User:Josve05a/template-sanbox|2=yes}} for Reason 2.

I just want to write {{User:Josve05a/template-sanbox|1}} (meaning it is |1=1) For Reason 1 and {{User:Josve05a/template-sanbox|2}} (meaning it is |1=2) for Reason 2.

Is it possible to do this? (t) Josve05a (c) 19:26, 2 June 2014 (UTC)

Yeah, it's pretty easy. Instead of #if: conditions, you want to use a #switch:. So something like {{#switch: {{{1|}}} | 1 = reason #1. | 2 = reason #2. }} will check the first parameter, {{{1|}}}, and send "reason #1." if that parameter is equal to "1", and "reason #2." if that parameter is set to "2". VanIsaac_WS 19:31, 2 June 2014 (UTC)

• (edit conflict) Sure, not defining 1= or 2= implies the first parameter is 1=. Therefor, you just need to adjust your code so that if 1=1 use reason 1 and if 1=2 use reason 2. Might look something like {{#switch:{{{1|0}}}|1=Reason 1|2=Reason 2|#default=}} — {{U|Technical 13}} 19:34, 2 June 2014 (UTC)
  • Thanks! I rellly have no idea how wiki-template-code works, so THANK YOU! (t) Josve05a (c) 19:40, 2 June 2014 (UTC)

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}} 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: 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}} 13:26, 3 June 2014 (UTC)

  Doesn't give any error. Just doesn't open. I can open this link but not this link . 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}} 13:38, 3 June 2014 (UTC)

No problems here on Firefox 29... — Mr. Stradivarius 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 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#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 VT 20:09, 3 June 2014 (UTC)

Media Viewer just launched on the English Misplaced Pages

Greetings! As discussed in our earlier posts, Media Viewer has now been enabled by default on the English Misplaced Pages, 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 Misplaced Pages, 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 Misplaced Pages, 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 Misplaced Pages'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 Misplaced Pages'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 Misplaced Pages'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 Misplaced Pages 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)
    • Thank you! Yngvadottir (talk) 22:05, 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 Misplaced Pages, to the Misplaced Pages description page. My preference would be for Media Viewer to be changed to include links to both the Commons and the Misplaced Pages 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 VT 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

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

• Yes, please do take this to Σ (talk · contribs)'s talk page. — {{U|Technical 13}} 12:50, 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 Misplaced Pages: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 Misplaced Pages 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:

• Tool Labs
• Tool Labs help pages
• How to create redirects to Tool Labs
• Magnus Manske’s migration manual
• Scripts to clean up your toolserver account after migration
• Mailing list Labs-l
• IRC channel #wikimedia-labs
• Marc-André Pelletier (Coren) and Andrew Bogott (andrewbogott) are the WMF Tool Labs ops. Petr Bena (petan) and Tim Landscheidt (scfc_de) are voluntary Tool Labs admins.

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

• Silke: Silke Meyer (WMDE), IRC: Silke_WMDE
• Birgit: Birgit Müller, IRC: Birgit_WMDE

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

Search stuck at 29 May 2014

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

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

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)

•  Done. I've replaced the content on ...And Some Were Human with a redirect to ... And Some Were Human and suggest that if you want the content moved to the latter that you start a WP:RQM on its talk page. — {{U|Technical 13}} 14:39, 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}} 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)

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

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)

Invitation to test Hovercards

Hi everyone,

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

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

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

Thanks!

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

This is just my occasional reminder that if you don't have a Bugzilla account (which not only is completely separate from your Misplaced Pages account, but which also publishes your e-mail address to the world), and you ever need to get a bug filed, then you can always leave a note on my talk page with the written report that you need filed. There are a lot of volunteer and staff devs who are also willing to help out with these things. Whatamidoing (WMF) (talk) 19:52, 6 June 2014 (UTC)

I had it enabled for a few weeks before but had to stop using it because of this annoying bug. However, it's fixed now thankfully and I've reenabled Hovercard. Huzzah!, —  dainomite   20:11, 6 June 2014 (UTC)

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

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 Misplaced Pages 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 Misplaced Pages / 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. SiBr₄ (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 Misplaced Pages 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 Template:Bug. 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 Misplaced Pages / 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 Misplaced Pages 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)

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 Misplaced Pages, 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. VanIsaac_WS 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 Misplaced Pages 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 Misplaced Pages 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. VanIsaac_WS 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 Misplaced Pages 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 Misplaced Pages 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. VanIsaac_WS 23:17, 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}} 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 Misplaced Pages: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)

Request for Comment: VisualEditor default state 2014 part 1

Request for Comment is active at Misplaced Pages:VisualEditor/VisualEditor default state 2014 part 1. Please participate if you are interested. --Pine 07:39, 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 Misplaced Pages community to have a consensus about this issue, so please comment on Misplaced Pages:Media Viewer/June 2014 RfC --Pine 08:09, 7 June 2014 (UTC)(UTC)

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