Would someone be kind to look into the [[Valls Cabinet]] article and see what's wrong with the formatting since "References" pops up in the middle of a table instead of at the bottom where it as customary is inserted. Regards, [[User:Iselilja|Iselilja]] ([[User talk:Iselilja|talk]]) 11:05, 2 April 2014 (UTC)
Would someone be kind to look into the [[Valls Cabinet]] article and see what's wrong with the formatting since "References" pops up in the middle of a table instead of at the bottom where it as customary is inserted. Regards, [[User:Iselilja|Iselilja]] ([[User talk:Iselilja|talk]]) 11:05, 2 April 2014 (UTC)
:[https://en.wikipedia.org/enwiki/w/index.php?title=Valls_Cabinet&diff=602404220&oldid=602403175 Done]. [[User:Blackfish|Blackfish]] ([[User talk:Blackfish|talk]]) 11:37, 2 April 2014 (UTC)
The technical section of the village pump is used to discuss technical issues aboutWikipedia. Bugs and feature requests should be made at Bugzilla (see how to report a bug). Bugs with security implications should be reported to securitywikimedia.org or filed under the "Security" product in Bugzilla.
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 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.
Currently under preferences the max selectable thumb size in articles is 300px (the default being 250px ). On many of today's monitors that is not much larger than a postage stamp. Can we get that limit increased? Saffron Blaze (talk) 22:03, 20 March 2014 (UTC)[reply]
The default is 220px. Thumbnails are not ment to act as full size images; they are 'thumbnails' after all. Try the new Media Viewer beta. — Edokter (talk) — 22:25, 20 March 2014 (UTC)[reply]
Further, our non-free content policy, which uses low-resolution non-free images, would not allow for images to be displaed at much larger sizes. --MASEM (t) 22:28, 20 March 2014 (UTC)[reply]
Why the lecture as if I am an idiot? I know what thumbnails are intended to do. I am saying they too small to be of any use on high resolution monitors. It was fine when all we had was 1024x monitors but now the defaults are often higher than 2560x. Moreover I wasn't asking for full resolution images, just slightly larger thumbs so I could at least see enough detail to decide whether the image is even worth opening. As to the beta Media Viewer, how is that functionally different from clicking on a thumb? Even if I were to use the viewer I would still need the thumbs to be larger.
The issue of "fair use" is a red herring. I was not asking for the actual image to be larger just the thumbs in the articles. Moreover, there is no firm legal criteria on allowable resolutions for non-free content. The guidelines only mention that images should be rescaled as small as possible to still be useful as identified by their rationale, and no larger. The image size to respect this notion seems based on old criteria and predicated on lower resolution monitors. Saffron Blaze (talk) 22:53, 20 March 2014 (UTC)[reply]
In general, it is inappropriate to assume any particular window size. You are applying what is typical for you and desiring to push it onto everyone viewing a particular article when doing so might make the article look much worse to them than the inconvenience of having a relatively small thumbnail image is to you. When adjusting this sort of thing on an article it is a good idea to view the page in a window which you can resize to a variety of widths so you can find a compromise which is reasonable for everyone. Further, keep in mind that a considerable amount of WP readership is now on mobile devices which tend to have a much smaller number of pixels available to display content.
As an example of going the other direction, the mw:Typography refresh recently was intending to force all MediaWiki projects using the Vector skin to a maximum page width of 715px. Upon getting negative feedback, they relented. This is intended as an example to indicate that opinions vary greatly as to the "proper" size of the window to view anything. The reality is that we should adopt page layouts which look acceptable under a variety of conditions. — Makyen (talk) 23:55, 20 March 2014 (UTC)[reply]
I am not doing any such thing and I would appreciate people stop talking out of their arse. If you go to your preferences and select appearance then look at the file options you will see an option to select your preferred thumb size. Default as pointed out is 220px. The max you can select for yourself is 300px. This is the size you will see when a hard pixel size is not included in the wiki code for a thumbnail. These smaller resolutions were fine on lower resolutions monitors, but is becoming inadequate now with QHD and 4K monitors. I asked that users be able to select a larger thumb size for themselves... NOT everyone else. Saffron Blaze (talk) 00:39, 21 March 2014 (UTC)[reply]
I'm not sure I understand the problem here: On QHD/4K Monitors you would have to scale up the text anyway (otherwise it would be much too small to read). If you scale up the text your browser should also scale up the thumbnails for you (if it doesn't maybe check you browser settings). Therefore the thumbnail is shown much larger than 220px, even if the setting you mentioned is kept at it's default. Therefore problem solved, isn't it? Since the images have defined a srcset HTML attribute you won't just see an upscaled image but an actually a higher resolved version therefore even gaining quality. --Patrick87 (talk) 01:43, 21 March 2014 (UTC)[reply]
Your inability to understand the issue makes it seem clear you won't have the answer yet I am confronted with another patronizing response. The assumption in your response is wrong. I don't want the text to get larger, I just want the thumbs to be larger. Saffron Blaze (talk) 04:31, 21 March 2014 (UTC)[reply]
Text sizes are normally given in points, not hard pixel values. Hence, for text, a properly-configured system should use however many pixels are needed for the text to appear at the desired size. E.g. 12 pt text should appear at a height of about 1⁄6 of an inch. However, image sizes are given in pixels. The same number of pixels are used regardless of resolution, so the physical size of the image is smaller at higher resolutions. Zooming is not a solution, since it also affects the properly-sized text. – PartTimeGnome(talk | contribs)22:52, 22 March 2014 (UTC)[reply]
First off, I do apologize, I certainly misunderstood what you were asking about.
However, I strongly suggest that you step back and assume good faith on the part of other editors. In response to three different editors you have come back with a response that has a belligerent tone and indicated that you believed the editors were "lecture[ing] as if I am an idiot", "talking out of their arse", or giving you a "patronizing response". Of the three, perhaps you could characterize what I said as "talking out of [my] arse", but it is much more productive to say something like "You appear to have misunderstood what I was talking about. I was referring to the personal preference available from the Appearance tab in your Preferences."
As a side note, you might find it beneficial to ask a more generalized question about how others deal with having small images on high resolution monitors rather than locking yourself into only thinking about one way to solve the generalized problem. There are a variety of methods to solving, or at least alleviating, the problem. — Makyen (talk) 06:04, 21 March 2014 (UTC)[reply]
If all people ever do is lecture about things they don't even understand it gets annoying and frustrating. People spend more time in telling people why they are wrong than actually helping. It's the power culture here at WP. I am just tired of it. Thanks for another useless lecture that serves nothing other than to bolster your own ego. Your suggestion does not address my concern nor help me in any fashion. Saffron Blaze (talk) 10:42, 21 March 2014 (UTC)[reply]
Makyen, you were clearly talking out of your a**. "Under preferences the max selectable thumb size in articles is 300px ... Can we get that limit increased?". This is not regarding MOS, not regarding how it displays with others, and it is definitely not related to window size (except as it is related to the screen's absolute maximum). The question was clear. The initial answers were well out of left field. PrimeHunter's answer below is much more useful. — Crisco 1492 (talk) 11:33, 21 March 2014 (UTC)[reply]
Saffron, I understand your annoyance. Replying without understanding the question is a frequent problem when discussing technical matters. However, venting off at people who get it wrong is not constructive. It deters others who might be able to help. Politely saying that a response is unhelpful and discussing why is better; if you can get someone to understand the issue, there's still a chance they could help. Even where they can't help, there could be others who didn't understand at first who could assist once given further explanation. – PartTimeGnome(talk | contribs)23:22, 22 March 2014 (UTC)[reply]
I was hoping it would deter others from spouting wiki-isms and nonsense, as is all too frequent. I am indeed glad PrimeHunter wasn't scared off. Then again, he knew what he was talking about. Funny how that works. Saffron Blaze (talk) 23:36, 22 March 2014 (UTC)[reply]
Bugzilla:11118 - "Allow larger/user-specified thumbnail sizes" was closed as WONTFIX in 2008, apparently based on this 2007 statement by Brion Vibber: "That's not likely to happen; we'd prefer to reduce the number of available thumbnail sizes to save on bandwidth, cache, and thumb disk space."
Bugzilla:27839 - "Offer 460px and 620px as thumbnail size preferences" was a request for the French Wikipedia. It was first accepted but later reverted in 2013 by Antoine Musso as WONTFIX with the statement "The original request can not be fulfilled, that will cause too much stress on our caching and storage infrastructure. I have reverted the original fix with: https://gerrit.wikimedia.org/r/51182". That says: "Having different thumbnails sizes per wiki is not something we can properly support right now. Our cache and files infrastructure will end being filled with thumbs which are barely used beside on the french wiki."
Bugzilla:41712 - "hewiki asks to change default image sizes for thumb and gallery" was not about the maximal options but also had some relevant posts.
The English Wikipedia is the largest but perhaps a suggestion for larger thumb options should be at meta: and linked at other wikis? The max of 300 appears to be older than 2007. That seems like a long time considering the development in screen resolutions and storage prizes, but the number of files is growing and I don't know the involved costs. PrimeHunter (talk) 11:27, 21 March 2014 (UTC)[reply]
Since the new "Media Viewer" is being developed (which will requires the creation of a whole lot of new Thumbnails anyway) and srcsets are used as stated in my "useless and patronizing" answer above (that means thumbnails are already generated at sizes of 330px and 440px as alternatives to the standard size of 220px and similarly at 1.5x and 2x the size of the other selectable thumbnail sizes) I think in principle a big number of cached resolutions should already be available and storage space / RAM seems not to be that much of an issue any more. I think it would be important to choose the sizes wisely though (so the already cached versions can be reused and as few new thumbnails as possible need to be created/cached) and all projects should use the same values. However larger thumbnails require a lot more of space, maybe that's the reason many small sizes but no large sizes are available. --Patrick87 (talk) 15:58, 21 March 2014 (UTC)[reply]
Before bitching at you I tried the media viewer. It does nothing until you click on the image. What I was hoping for was to see the article itself illustrated with larger images. If I wanted larger images by clicking I can get that already. Perhaps I am missing something as the viewer is beta, but if the viewer is intended to provide larger thumbs at some point that would indeed meet the aim. Saffron Blaze (talk) 22:54, 21 March 2014 (UTC)[reply]
Blaze Saffron, I am trying to understand the issues you are raising. I offer my personal setup and experience with a section in one of the oldest WP articles, scientific method#Overview, specifically the Galileo image in the Overview section. The markup is in old-fashioned style, from about 10 years ago.
[[Image:Galileo.arp.300pix.jpg|thumb|150px|According to Morris Kline,... ]]
If I edit the wikilink so the width of the thumbnail is 450px, After clicking 'Show preview' I get the article, with Galileo embedded in it, but with Galileo's image increased in size (similarly, Galileo decreases if I edit the width of the thumbnail to, say 50px).
Is that what you are trying to accomplish for viewing on your hi-resolution display?
On the secondary monitor, the article is 22.5" wide, with Galileo's image width 2.4" wide when viewed with defaults.
My current secondary monitor is 24" diagonal, about 22.5" across, and 12.75 " high. The displayed resolution is 1366x768. I can view the secondary monitor without strain or magnification, while leaning back in my chair, a viewing distance of 48". The primary monitor is 11.6" diagonal, 10" across, about 5.6" high (a Chromebook, but I am running Ubuntu on it). I can read Wikipedia without strain on the Chromebook (I do lean forward when viewing the Chromebook), but the secondary monitor is essential when trying to read the details in stopped videos, for example.--Ancheta Wis (talk | contribs)00:34, 22 March 2014 (UTC)[reply]
Ancheta Wis, In the example you provided the markup has a hard pixel size of 150px. That is very unfortunate as it forces me to view that image at the forced size despite using a WQXGA+ monitor. If you remove that hard pixel size then people will see it at 220px unless they change the default setting in their preferences. A user can increase their default thumb size is to a max of 300px. On any monitor at QHD or above, that 150px image is but a tiny bit of colour and even at 300px it is barely acceptable, especially for landscape oriented images. I would find my reading and viewing of articles more rewarding if the thumbs were more like 400-450px. So, you essentially described the effect I want to achieve, but I don't want it done through hard pixel sizes as in your example (using hard pixel sizes is actually frowned upon in the WP MoS and image use policy). Does that answer your question? Saffron Blaze (talk) 04:21, 22 March 2014 (UTC)[reply]
Coming back from above, non-free images are not a red herring in this discussion. People reduce non-free to no more than 300px - for the most part - because no thumbnail presently can go above this size. If we increased the max thumbnail size that people would select, this would encourage (not via policy) for people to reduce only down to that size, which harms the free content mission and our fair use defense should that ever be challenged. Yes, free imagery doesn't have this problem but the max thumbnail size is irrespective of works being free or not. So there is more to this than just making WP look better for people with large monitors. --MASEM (t) 04:42, 22 March 2014 (UTC)[reply]
Actually "fair use" is anathema to the free cultural works movement because by definition "fair use" imagery is not actually free. That's why it is not hosted on Commons where "free to use" is taken literally. Regardless, I think your concerns over "fair use" image size is unwarranted when you see what sizes news media orgs use when applying "fair use" doctrine. The case law does not support your position as well. You are looking to restrict people's enjoyment and access to this project over the boogey man in the closet and we all know the bogey man does not exist. Saffron Blaze (talk) 18:10, 22 March 2014 (UTC)[reply]
It's not just "fair use" issues, it's our non-free policy. We are specifically more stricter than fair use so that we stay fair outside the point where the legal defense of fair use could be possibly challenged. One example is stressing we use smaller images to avoid our fair use taking from being too large and/or impact the commercial value. Thus why NFCC Policy is related to the thumbnail max size since we're not going to want to store images that are much larger than that. This is a mandate from the Foundation so this is not a boogeyman to worry about but part of the limitations that the Foundation has set for non-free use. --MASEM (t) 18:28, 22 March 2014 (UTC)[reply]
Even the strict image use guidelines for non-free content places the lower end at 320px and discusses images up to 1000px. Suggesting 300px is the upper end is not only wrong it is detrimental to the project. Saffron Blaze (talk) 18:55, 22 March 2014 (UTC)[reply]
I never said the max image size for NFC can be 300px, but that 300px is generally the max size because 1) for nearly all original media, this size is of sufficient reduction to be okay by fair use, and 2) the max thumbnail size is 300px and we shouldn't be uploading pics of normal aspect rations that go much above that. --MASEM (t) 19:24, 22 March 2014 (UTC)[reply]
Oh for crying out loud User:Masem, I can see why Saffron is frustrated when met with such responses. As you say, our restriction on non-free images is to ensure they are not detailed enough to have commercial value. This applies to the image we host, not the size as it appears on the user's display. If the underlying image is restricted at 300px, say, then displaying it as a thumbnail at 400px involves basic digital enlargement the same as someone using the Zoom feature on their browser, and not dissimilar to just moving their nose closer to the monitor, neither of which breaks any copyright laws. There is no fundamental reason why the fair-use cap cannot remain at 300px while the displayed thumbnail is 2 or 3x that if desired. If current guidelines/practice have conflated thumbnail size with free-use max then that is trivial to rectify. Let's not create imaginary obstacles.
While the web has moved forward towards recognising differing display abilities, Wikipedia has not advanced. I've not been impressed with the beta features and had to turn them off. I see more and more editors using hard pixel sizes and ignoring the standard thumb. This stores up a problem that is not trivial to fix. If the default/max thumb does not increase with technology then editors will find a way round it, and do, to the detriment of users stuck with older tech in the third world, say. Better that editors could choose small/medium/large for thumbnails and leave the user's preferences to sort it out (or better still, adaptable per display). Many of use use different monitors at various times. I have an 1920 x 1080 display on a laptop, a measly 1280 x 1024 at work, a super 2560 x 1440 in my study, a lowly 960 x 540 on my phone and 1920 x 1280 on a tablet. If storage/memory-use is an issue for caching (and I suspect it is less of an issue than it used to be) then fewer choices are the answer -- it should be straightforward to get stats on which sizes are widely used. Larger sizes aren't just a cosmetic issue -- the richer an image we can display the more our educational mission is served. A map or diagram with more readable legends, a building with more detailed features, a face with more character. Really, this is a discussion about a decade past its date. -- Colin°Talk19:38, 22 March 2014 (UTC)[reply]
I'm not complaining that a thumbnail that is scaled from a 300px to a larger size is a fair use issue. But what can happen is that if we do allow a larger size of thumbnail for all images, people that use the larger size, let's say, 450px will upload non-free thinking their image size is fine considering this thumbnail policy. And then others will follow to upload at this size, even though 300px is just fine otherwise. I won't deny that this argument alone is a potential slippery slope in considering the non-free aspect only, but it is a point in conjunction with the other arguments against the size increase (including the server limitations for thumbnails) to keep 300px as max. --MASEM (t) 20:52, 22 March 2014 (UTC)[reply]
I contend that your basic premise and concern that non-free content only be uploaded at 300px is baseless and bankrupt and not predicated on anything but a guess and a wave of the consensus hand. It has no legal standing and is not part of any policy statement from the WMF. However, I am willing to be proven wrong so I brought this issue to the WMF legal via Meta. Saffron Blaze (talk) 22:53, 22 March 2014 (UTC)[reply]
Again, I never said the maximum size a non-free could be uploaded is 300. But 300px is a good size to encourage uploaders to reduce their works to via the fact that thumbnail can never go larger than that (if no other size parameters are given), and thus better keeps us within the issues of fair use. There are certainly plenty of places for >300px non-free, but the issue I'm point out that we can maintain the average (this typically being covers of published media) at ~300px by noting that thumbnails max out there. If you increase the maximum size of thumbnails readers can set, that could potentially drive editors to upload at higher resolutions and that starts putting us more at risk, espcially when most art doesn't need to be at that size (per WP:NFCC#3a non-free should only be used at the size that is necessary.) --MASEM (t) 22:59, 22 March 2014 (UTC)[reply]
It is NOT a good size. 300px is too small. 400px or even 500px sizes are still small enough to respect fair use doctrine and they will not break the bank, particularly if they are being generated for the media viewer anyway. Saffron Blaze (talk) 23:27, 22 March 2014 (UTC)[reply]
(edit conflict) There seems to be a level of FUD about this argument to keep the maximum thumbnail size at 300px. It seems daft (to me at least) to impose such a major restriction out of fear and speculation that others could get thumbnail sizes mixed up with our non-free content policies. Even if they did, it can be fixed in the usual wiki way: upload a new copy of the image at a smaller size then delete the old version, while giving the original uploader a talk page message explaining why the original image size was inappropriate. – PartTimeGnome(talk | contribs)23:39, 22 March 2014 (UTC)[reply]
I tend to agree. Sorry Masem, but of reasons not to allow for larger thumbnail sizes in preferences, I do not find the NFCC argument compelling in the slightest. Resolute23:51, 22 March 2014 (UTC)[reply]
First, I am not trying to say "no we can't increase the thumbnail size above 300 px only due to NFC.", because as you've misintepreted what I've said, NFC does not have a hard limit, but we strongly encourage the 300px limit as a natural balance of the max available thumbnail size presently, and the nature of WP's policies to keep non-free use to minimum take and avoid endangering commercial opportunities. What I've been saying here is that considering the suggestion to increase the thumbnail size, the issue of NFC should be considered along with the stronger issues regarding the WMF's choice to keep thumbnails small to prevent stressing servers.
Second, this is not FUD. We presently are in no danger of any legal issues with NFC, but that's because we tell people to keep images small. If we suddenly had thumbs at, say, 500px, and suddenly 500px was commonly used for NFC uploads, we probably wouldn't be in any legal trouble but we are going against the Non-Free Resolution to minimize non-free use (as defined by policy). And of course, what happens when the next big screen resolution comes in and we want to get to 700px or higher? Remember, DVD resolution is around this size, so a screenshot at this size would be no longer respecting commercial copyright. This is why 300px is naturally a decent size to aim for for NFC images - for nearly all standard images one can imagine that would fall under NFC, this is far from challenging the commercial opportunity. Yes, even if we had 700px non-free images, the rest of non-free would help to be our fair use defense (education/transformation use, single images or frames, etc.), but this weeks how strict our NFC has been.
Yes, we could always fix uploads that are larger than 300px back down (we have a tag and category for that) , but one has to realize that non-free imagery, one of the few areas that the Foundation requires us to be proactive in, is woefully under-admined. This would be more work for us.
But again, I stress this is like the second or third reason to not change the thumbnail size, with a lot more weight on the first, primary argument of the stated server issues that would happen with larger sizes, given above. That factor has to be overcome first, before we talk the effects on NFC. --MASEM (t) 02:44, 23 March 2014 (UTC)[reply]
You keep stressing something that four other people have told you is baseless. Your concern has been weighed, measured in pixels and found wanting. Now, if server load is truly an issue I am sure someone will chime in and that will be that. However, as pointed out earlier, with media viewer development the availability of the larger thumbs may render both your concerns mooted. If that is the case then those same thumbs should be made available to those not using media viewer through larger pixel preference choices for thumb sizes on article pages. Saffron Blaze (talk) 03:04, 23 March 2014 (UTC)[reply]
BS, I have to refute the misstatements others are making on what I am saying (like the claim that I said the max NFC size was 300px, which I never said). And any change that has the potential to affect NFC handling has to be considered because this is mandated policy by the Foundation. It doesn't need to be determined now, but if you somehow get the Foundation to allow that change to thumbnail size, then we have to review that change in the NFC framework. That's all I'm saying - there are tied issues in this but they don't come into play until you have the larger thumbnail size possibility. --MASEM (t) 03:16, 23 March 2014 (UTC)[reply]
What you said was using thumbs larger than 300px would counter our non-free content usage guidelines and bring legal risk to the project. As a consequence it should be a factor is not allowing people to select larger thumb image sizes in their preferences as it would encourage people to upload non-free content at larger sizes. We understood you perfectly and found your rationale and concerns unfounded. Moreover, there is no "Foundation" policy that dictates image size for non-free content use. I invite you to prove me wrong on this issue. Regardless, the sizes being considered would never invoke the kind of concern you seem to be harboring. What stands as a guideline has been continually debated and subject to interpretation by the community for years. People use WP differently today than they did 10 years ago. They need choices to deal with all the various ways they access WP content. The old tired guidelines you keep espousing, if they actually exist, are not fulfilling that aim. Saffron Blaze (talk) 06:49, 23 March 2014 (UTC)[reply]
What I am saying, Masem, is that the NFCC argument is not even valid. There is no argument to be made at all to limit images sizes - and therefore limit Wikipedia's usability - due to an imaginary problem. Particularly given the basis of your argument: A non-free image at 500px would still be smaller, relative to users on high screen resolutions today than one at 300px was at what was a high resolution in 2007. This point is simply irrelevant to me. The question of bandwidth and other technical limitations is really the only one that should be persuasive here. Resolute03:14, 23 March 2014 (UTC)[reply]
Masem, if I didn't know you better, I'd say you were trolling. Several people have told you your argument is baseless. You've created an imaginary concern. Please drop it. If you don't, I suggest others treat Masem's concern as though he were trolling (which I'm absolutely not saying he is) and ignore it. It is not helping this discussion by creating a huge timesink irrelevance. Masem, if privately you still think your concern has any weight whatsoever, then please go chat with WMF legal and come back when the argument has some backbone. -- Colin°Talk10:05, 23 March 2014 (UTC)[reply]
I've been involved in the NFC area for the last 6 years - I know there is an issue here that is not obvious if you don't spend time in that area. It is not a direct legal concern but it does involve the Foundation's free content mission and how we have practiced that through NFC for the last 6 years since that Resolution was stated (And perhaps even earlier since en.wiki's NFC policy was the basis for how the Resolution was made). To restate, we don't have a hard (server or policy) px limit for non-free content, but we strongly encourage non-free images to be no larger than 300 px because with the 300 px max thumbnail, there's no reason to upload higher resolution images, and 300px is a good size that assuredly makes sure our fair use taking of commercial and copyrighted works stays small for the bulk of available copyrighted media. That is, we ask people to aim for about 0.1MP in image size (per WP:NFC). We obviously allow larger sizes, but higher resolutions require a justification in the non-free rationale about why the image needs to be that large. But I'd guess that right now, about 90% of our non-free images are tuned to the 300px/0.1MP size range. Should the max thumbnail size become 500px, and we make no change on what non-frees we have, we are either going to have the case that non-free images would be scaled up to 500px from their current size (which could make them blocky-looking), or that they would be fixed at a max size of 300px and appear small against all all free images. For the same reason this change was suggested - that on monitors with large resolution that the images look tiny - I can foresee a demand to increase the target non-free file size to 500px - doubling the number of pixels from 0.1MP and 0.2MP. For most non-free this is still probably nowhere close to tipping the fair use, but the issue becomes "where will this end"? What if people want 700px thumbnails (in general)? That's 5x increase in pixel count from 300px thumbs, roughly, and approaches the default size of many visual works.
Let me restate this is another way: should the thumbnail size increase, you cannot expect non-free images to follow. We are still going to aim to keep images around 300px/0.1 MP because that is a "right size" that balances all aspects, and still the thumbnail size that the majority of readers will not exceed. So as long as those that go to 500px understand that non-free will not follow, then there's no issue. But if you are expecting non-free policy to allow higher-resolution uploads to meet this new larger thumbnail size, then there's a major issue that has to be resolved.
I'm absolutely not trolling about this - this is a serious issue for non-free policy has it has been practiced. --MASEM (t) 15:31, 23 March 2014 (UTC)[reply]
Actually, even if you remove the whole issue of thumb sizes, your concern and adamant belief 300px/.1mb is the right size for NFC is also wrong and baseless, but this isn't the venue for that. Saffron Blaze (talk) 17:09, 23 March 2014 (UTC)[reply]
Masem, would it help if I said I was in no doubt that the maximum thumbnail size has no link whatsoever to acceptable sizes for non-free content? I would not expect any tolerance of larger non-free images due to a change in thumbnail sizes. I'm also not sure it's a good idea to encourage non-free uploads at 300px – they should be uploaded at the smallest size that allows them to be of use in the relevant article(s). For many images, this could be less than 300px. – PartTimeGnome(talk | contribs)23:28, 23 March 2014 (UTC)[reply]
Resolute, restricting the pixel size of non-free images is about restricting the amount of detail in the image, not their size relative to the monitor. (We can't do anything to restrict their physical size; people can easily zoom in.) – PartTimeGnome(talk | contribs)23:28, 23 March 2014 (UTC)[reply]
There is a non-direct but important connection between thumb sizes and how've handled non-free reductions due to the fact we encourage and/or require scaling to no larger than the largest possible thumb size to minimize non-free particularly those higher resolutions where it would not be used. As long as it understood that we at NFC will continue to encourage and enforce the 300px/0.1MP size regardless of how big the thumbnails for free images may go, then we're fine and the matter is nothing else. --MASEM (t) 23:50, 23 March 2014 (UTC)[reply]
It was nothing to begin with but your insistence has highlighted another problem not related to the OP. You have made it so abundantly clear that a baseless guideline at NFC is making a mockery of fair use doctrine. Its overly restrictive nature serves nothing other than someone's arbitrary belief. I will have to see about addressing that as well. Saffron Blaze (talk) 02:42, 24 March 2014 (UTC)[reply]
Clearly you aren't clear how important and the goals of NFC policy here. It is two fold: one: to encourage free content over non-free content and meet the free content mission, and two: to keep us as far from possible from tripping over the fair use defense in what non-free we offer. Size is a critical importance, because one aspect of fair use is to respect commercial opportunities, and thus reducing images to ~300px/0.1MP easily avoids treading on that. The combination of these two are summarized in NFCC#3b as well as the Foundation's resolution to minimize non-free taken. This is has been the case for 6+ years if not longer. This is why this is all connected to the thumbnail, because, as you are imply, you're going to be asking for larger NFC images to be used, and that will not fly. --MASEM (t) 02:56, 24 March 2014 (UTC)[reply]
Sure it will. If you build it they will come. Did you really think 300px as a guideline would last forever? It is not even founded in any case law. It's just a 7 year old wild ass guess made by a very small crew of involved editors. Certainly well meaning but getting out of date. Saffron Blaze (talk) 21:10, 25 March 2014 (UTC)[reply]
Can I suggest the discussion about max thumbnail size be rebooted void of any concerns about Fair Use image size thresholds. Let's discuss how best images can be displayed on Wikipedia articles given the variety of display sizes available to users. The opening suggestion is that for logged-in users, they should be allowed to set preferences higher than 300px. At present, there is no suggestion the default or the size used for non-logged-in users be increased. I think offering a higher threshold for preferences is a reasonable step. However, I'd also like the software to consider display size to offer some intelligent rendering. That surely is the best option when one may flip between a 100dpi 17" display at work to a 250dpi 9" tablet or a 220dpi 27" display at home. One thing I don't know is whether the page caches all thumbnail sizes available, or just those actually requested. If the latter, then my guess is that the choices used by logged-in users are a drop in the ocean compared to normal readers, and thus of little concern wrt hardware resources. -- Colin°Talk10:05, 23 March 2014 (UTC)[reply]
I see a lot of uncertainty in the sections above and little facts or context that matters. As can be seen from a few of the bugzilla tickets linked above, there are some technical considerations here. I'll try to explain:
The request of a higher default thumb size has been uttered quite a few times before. The foundation itself (or the designers it employs) have also shown interest in higher resolution thumbnails.
We need to remember that any thumbnail that is generated is a file that needs to be stored on a disk. The more available thumb sizes for users, the more files. This is also why the sysadmins don't want to cause too much more divergence between the different sites. There is a lot of diskspace, but that is no reason to 'waste' it.
To change default thumbsize for everyone, we are talking more than just a configuration change. To do so instantly would mean that the thumbnail servers need to render a file for almost every single image viewed just after the switch. This would significantly impact the stability of the website. As such sysadmins would have to do a staged switch, which is much more labor intensive
Regarding the beta media viewer. Yes this will result in a lot more thumbnails and it is a concern that is being taken into account with the design of the media viewer. The current thinking is that likely it is going to be something like size bucketing. That means that there will be a preselected set of sizes that the MMV will always use, regardless of your window size, and will simply use browser downscaling at the client size from a size that is 1 step larger than your window size requires.
Bucketing will possibly (or is already ???) used by the mobile website for the same reasons.
There is a chance that this bucketing technique will also be used for thumbnails in the normal website. Experiments need to show first though what are suitable sizes and if the quality of this process is not going to have too much of an effect on users.
There has even been some discussion if the 'buckets' should be pre rendered (even before the first user requests the image).
Most of all, as might be obvious from these points, this is not something you can 'do' at the English Wikipedia level, since it affects the infrastructure of all Wikimedia wikis to such a high degree. So the place to get this done is as always on wikitech-l mailinglist and of course the assortment of other places (mostly IRC and Mediawiki.org) where the developers and sysadmins operate and expect the progress to be SLOW, up until the time where there is a reason for WMF to allocate time and resources to the problem. —TheDJ (talk • contribs) 11:30, 23 March 2014 (UTC)[reply]
As far as I can tell, 300 has been the largest option at nearly all wikis since at least 2007. There must be many registered users who chose that long ago and caused generation of lots of 300px thumbnails for images used as thumbs with no size specification. If the default for everybody was changed from 220 to 300 then wouldn't that greatly reduce the server load right after the switch? Or maybe the default could be increased at different times for different wikis. I don't know whether that would require other sysadmin work than changing wgThumbLimits in InitialiseSettings.php more than once. PrimeHunter (talk) 12:10, 23 March 2014 (UTC)[reply]
True, but how do we get from here to there. I am not bugzilla literate enough and the process from idea to resolution is not clear. If I drop in over there with my wishlist they will likely see me as a fly buzzing in the room. Saffron Blaze (talk) 17:16, 23 March 2014 (UTC)[reply]
I suggest we take the opportunity given by the work on the Media Viewer / UI enhancements to improve thumbnails at the same time as their other features. If you read the feedback, the #1 problem is that it is too slow (the main reason I turned it off) and they are looking at caching. If they can cache large screen-filling images then there is no reason they can't cache smaller (or downsize from those rather than the original, as suggested above). The media team, despite getting some things wrong, do seem to be trying to improve WP's visual experience and considering multiple display issues. Talk to those working on these beta features, and see if they can raise a bugzilla report that won't just be ignored. They seem to like "user stories"
"As a WP reader, I want the article thumbnails to display appropriately for my screen size/resolution, so that I get the maximum detail visible while not overwhelming the article text."
"As a WP editor, I don't want to have to hard-code thumbnail size in order to ensure the detail on my map/diagram/photo is legible to most viewers." -- Colin°Talk11:12, 24 March 2014 (UTC)[reply]
Hey Colin. Thanks for looking into the Media Viewer development. I'm working a bit as a community liaison for Media Viewer's release. I hope you can contribute thoughts to developing that product. While Media Viewer deals with rending the image after you click on the thumbnail for a better visual experience, the development of Media Viewer is unrelated to how thumbnails are displayed on-wiki in terms of size. The only real interaction is with caching, as you noted. By all means continue on with the conversation about default thumbnail sizes here, on wikitech-l, bugzilla, or the many, many other places this conversation has taken place. However, it will have little to do with Media Viewer. Pardon the interruption :) Keegan (WMF) (talk) 21:21, 25 March 2014 (UTC)[reply]
which has (1) only five sizes being cached and (2) one size larger than what's currently available here? (The exact numbers could be adjusted based on Mobile's needs, etc., but the idea should be clear enough.) WhatamIdoing (talk) 16:25, 27 March 2014 (UTC)[reply]
It's mostly arbitrairy anyway. But you raise a good point. MediaWiki already support srcset for images, being used for 1.5x and 2x pixel aspect ratios. That means that for every thumbnail size, MW will also need to cache every thumbnail size three times. In case of a 220px image, an additional 330px and 440px version, and so on. So picking a few smart values to minimize caching would be a good idea, in which case: 150, 225, 300, 450. — Edokter (talk) — 21:31, 27 March 2014 (UTC)[reply]
Apologies if I am being daft, but you indicated earlier MWV had nothing to do with thumb sizes other than caching. So why would I want to have a conversation about thumb sizes at that multimedia list? Saffron Blaze (talk) 23:14, 29 March 2014 (UTC)[reply]
The multimedia list is not restricted to discussion about MWV. It is for discussion about all software that deals with multimedia (images, audio, video, etc) on Wikimedia sites. This includes the thumbnail support in core MediaWiki. – PartTimeGnome(talk | contribs)21:16, 30 March 2014 (UTC)[reply]
Ok, thanks. I must have misconstrued the front page's discussion of MWV. That said I can't see myself engaging again on this topic elsewhere. Trying to effect change on WP is just a recipe for grief and frustration as this episode only reiterated to me. Saffron Blaze (talk) 23:54, 31 March 2014 (UTC)[reply]
I've noticed that some sites are doing a strange thing where they write different code for Retina display browsers than others.[1] I can't help but feel that this is back-assedwards; if they want to break their web browser why should the developers have to write special code to fix it? Nonetheless, desperate for hits, it seems some do. Without suggesting any excessive degree of accommodation, it does provide an argument for letting thumbnails go bigger, I think. (I haven't actually done this coding though) Wnt (talk) 17:39, 1 April 2014 (UTC)[reply]
Automatically prompt editors before saving common mistakes
There are certain common errors that editors make that are often missed when saving before previewing a page, for example, adding a reference without including a closing </ref> link, adding reference links with out a {{reflist}} tag, or creating a link to a disambiguation page. I propose that, in the same way that an editor will be prompted if they attempt to save certain templates that must be substed, an editor attempting to make a save that would introduce an error of these types should get a notice before saving, saying something to the effect of "This edit will add a <ref> tag without including a closing </ref> tag. Do you wish to continue?", or "This edit will add a link to the disambiguation page, Phoenix. Do you wish to continue?" The editor would then be given the option to go ahead and save despite the error, or to return to editing in order to fix it.
I believe that such a system would help prevent a lot of maintenance fixes from being required in the first place, particularly with respect to disambiguation links, which most editors can not tell are ambiguous without clicking on the link. Cheers! bd2412T17:36, 24 March 2014 (UTC)[reply]
I imagine this would be quite the technical feat and would slow down the save page time considerably as every save would need to be run against the list of errors. –xenotalk17:58, 24 March 2014 (UTC)[reply]
Sounds like something that an edit filter could do. I don't foresee it as too big of a deal to code a couple up, but I'm not sure it would be supported by the community. It may overly frustrate new editors is my biggest concern. Worth discussing though. — {{U|Technical 13}}(t • e • c)19:30, 24 March 2014 (UTC)[reply]
@xeno, we are apparently already doing this, or something like it, when we cause this kind of alert to be issued for certain unsubsted templates, and for that matter for a fairly enormous list of blacklisted websites. For the latter, the page just won't save at all while the link is on the page. @Technical 13, I thought about this, but I think that by the time a user gets around to using reference tags, they probably know their way around enough that they won't be put off by an alert. With respect to disambiguation pages, it's just such an enormous problem, I think it's worth it to educate people early and often that they should avoid linking to these. Perhaps a warning could be tailored to specify a handful of most frequently linked disambiguation pages, like heavy metal, rock, English, Spanish, Amazon, etc. I asked about doing something like this through an edit filter once and heard nothing back. bd2412T23:38, 24 March 2014 (UTC)[reply]
Well, I'm no expert, but I doubt the edit filter could handle things like this without running into performance/condition limit issues. Things like dablink detection would be impractical, as the edit filter has no way to tell whether a link is to a dab page or not; it would have to check against a predefined list of pages, which is fairly unmaintainable. Writ Keeper⚇♔23:50, 24 March 2014 (UTC)[reply]
@User:Writ Keeper, I don't see why a predefined list of disambiguation pages would be at all difficult to maintain. I have been fixing dabs for nine years now, and have a very clearly defined list of a few dozen pages to which links are persistently made, generally names of major language/nationality groups (e.g., German, Swedish, Japanese), names of music genres having competing meanings in other fields (rock, pop, swing), and a few other usual suspects (Phoenix, Georgia). bd2412T01:14, 25 March 2014 (UTC)[reply]
I may support the edit filter idea for simple things like ref syntax. For DABs, a userscript may be better, though you would need to opt in to gain benefit. We already have a couple userscripts for detecting DABs on a page. One could probably be modified to detect them while editing a page. —PC-XT+05:37, 27 March 2014 (UTC)[reply]
Many/most people ignore warnings and save text: A wikitext syntax checker for WP should be an extra button "[Check_format]" near "[Show_changes]" but we know, absolutely, how the red-error messages are often ignored, as with the wp:CS1 Lua-based cite templates, with messages issued in March/April 2013, but most errors were still left in thousands of semi-major articles all year. Plus, some pages were edited over 150 times, and get this: by experienced editors who also left the cite errors, with glaring red messages in those pages all year. The pattern is quite clear: the people who edit most Wikipedia pages do not proofread those pages, or care enough about other issues. Instead, the user-scripts with JavaScript seem to be the best tool for users who actually proofread (part) of the text. For everyone else, several Bot-assisted tools should be used, while edit-filter warnings might make people cancel the edit. However, a "[Check_format]" button will likely be offered about 10-20 years from now, when most wp:edit-conflicts are also auto-merged in last-in-first-out (LIFO) order, perhaps with simple weave merge to retro-fit changes to moved paragraphs. The power users have made it abundantly clear, they are unlikely to use the extravagant, cumbersome VisualEditor, which most newcomers have also disliked, in favor of the wikitext source editor, and hence, a wikitext syntax checker, with a user exit to detect common dab pages, will be implemented when the developers run out of distractions. -Wikid77 (talk) 07:27, 27 March 2014 (UTC)[reply]
The citation errors are a bad example and a poor comparison. The significant majority of red error messages generated for citations only show up within the references section. Such errors show nothing while editing a section of an article, even when previewing the changes made. If one wants to see if any errors were caused, the editor has to specifically add a dummy {{reflist}} to the end of the section and then preview. Once any errors are taken care of, the dummy {{reflist}} must then be deleted. If editors were actually informed of these errors while editing, or previewing, then many more editors would fix the errors. In this case, the issue is not that editors don't care, it is that the errors are not presented to the editors in a manner that is effective. If the resulting references were easily available for editors to see while in the edit-preview-edit-preview-save cycle it would at least enable editors to have the possibility to know about any error to be able to fix it. I care about citations, but I have to put specific extra effort into going and looking for such errors while editing a page. There is a huge difference between prominently showing the editor a warning that there is a problem and asking for confirmation to continue vs. the indications of problems currently displayed by the citation templates. Frankly, I don't consider the two situations comparable. I don't believe it is reasonable to draw any conclusions about editor apathy from a lack of fixing errors which are displayed in an manner such that they are can only seen by editors if the editor puts out significant extra effort to look for the errors. If we want editors to fix errors, the editor needs to know that the error exists. — Makyen (talk) 13:23, 27 March 2014 (UTC)[reply]
I would really like an extra <references/> at the end of the section in preview mode. I don't think it would matter if it was blank, so detection may not even be needed. It shouldn't be used for the whole page, though, since that actually needs a reflist tag to show one. The appended tag could be separated, somehow, to avoid confusion. —PC-XT+19:06, 27 March 2014 (UTC)[reply]
I would also like to have the references displayed when previewing the edit of an article section. Personally, it would same me quite a bit of effort. From an overall Wikipedia point of view, I think that having such would cut down significantly the number of referencing errors and save considerable effort for editors both in initial entry of references and in having to go through an clean them up later. — Makyen (talk) 22:05, 27 March 2014 (UTC)[reply]
Actually, such a feature already exists in the wikitext editor, but only if you use the link tool in the toolbar (which no one does). It would also be possible to add functionality to the AbuseFilter extension to allow it to check for links to disambiguation pages and show a warning (or extend the Disambiguator extension to do the same) when an editor clicks Save. There would likely be a performance hit on save, but I'm not sure how bad it would be. Kaldari (talk) 19:20, 31 March 2014 (UTC)[reply]
You could use {{Reflistp}} for seeing the references in a section (which is hidden and categorized if you accidentally save and leave it there) and follow the tracked bugs for the fixes for many of these things on Bugzilla... — {{U|Technical 13}}(t • e • c)21:15, 31 March 2014 (UTC)[reply]
Alternatively, I would recommend using Anomie's Ajax Preview, which adds an extra button between Save and Preview, and allows you to view a section with refs laid out. The added bonus is that you avoid the mistake of leaving Reflist in the section by accident. Green Giant (talk) supports NonFreeWiki01:17, 1 April 2014 (UTC)[reply]
There's already a sort of way to do this for Lua scripts or templates: just make your script return a dead blacklisted link to, say, Encyclopedia Dramatica (www.encyclopediadramatica.com) in its error message. The edit filter will refuse to save whenever this message is displayed. Then you can add an override parameter to your script to suppress the link from being displayed if you really want to save with the error. Wnt (talk) 21:29, 1 April 2014 (UTC)[reply]
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.23wmf19) was added to test wikis and MediaWiki.org on March 20. It will be added to non-Wikipedia wikis on March 25, and all Wikipedia wikis on March 27 (calendar).
VisualEditor news
You can now double-click or press the ↲ Enter key on an image or template to change its settings. [2][3]
Pages that don't exist will now show as red links in the edit mode. [4]
You will no longer be able to try to use VisualEditor on pages translated using the Translate extension, and you will see a warning if you try to edit pages marked for translation. [5]
You will now see a full warning, including the most recent log entry, when you try to edit protected pages with VisualEditor. [6]
Future software changes
Typography Refresh will be enabled for test wiki and MediaWiki.org users who use the Vector skin on March 27. For users on non-Wikipedia wikis, it will be enabled on April 1, and for Wikipedia users on April 3. If you don't use Vector as your skin, you will not be affected.
You will be able to use the Hovercards tool as a beta feature on all wikis from March 26.
You will soon be able to include the Whatlinkshere special page in other pages. [7][8]
This is not true as far as I'm aware. Those changes are in the Beta, but that doesn't mean they will be deployed. Steven Walling in the past has assured me that only these changes will be deployed and specifically Block quote changes will NOT be deployed. —TheDJ (talk • contribs) 09:15, 25 March 2014 (UTC)[reply]
Yes, we're not going to include the following changes that (for now) appear in the beta:
Blockquote style
Thumbnail style
TOC style
Simpler external link style
These are potentially very good changes but they need work. The core of what we're shooting for is related to text readability and consistency across devices/operating systems, so it's tertiary to our goals. More information is coming soon in the form of a Signpost op-ed, watchlist notice, and blog post. Steven Walling (WMF) • talk21:32, 25 March 2014 (UTC)[reply]
So why not fix these other things and then release it all in one shot as a working product instead of releasing half of it when it can then have developers loosing interest and having the community having to deal with a hack job half conceptualized idea? I think the community would prefer you have a fully working feature before releasing it... — {{U|Technical 13}}(t • e • c)22:08, 25 March 2014 (UTC)[reply]
Actually, it started out as "typography refresh" and this other stuff kind of crept in as loose experiments, but were sebsequently met with some fierce objection. So this is essentially going Back to Basics. — Edokter (talk) — 22:48, 25 March 2014 (UTC)[reply]
Actually there was so much discussion about the "creepy" features that were too prominently and too numerous that the point of typography refresh – typography – was not perceived sufficiently and therefore not discussed in all necessary depth. I think that although we had at least three iterations of this beta feature, typography was lost somewhere in between, not tested thoroughly by the community and therefore the result is probably still far from the optimum. Let's hope this will not again result in bad blood when this is now forced on everybody using vector skin.
@WMF team: Please restrict beta features to only one feature in future!
Make one change at a time.
Iterate with this one change and optimize together with the community until it really is ready for deployment.
Then deploy and see how the rest of the community reacts.
If there are problems back to iterating
Only if everything is working really stable continue with the next change.
I'm not sure that's a fair assessment. If you look at the two Talk archives for the beta feature, you'll see many comments about the core typography changes. Font choice was hotly debated and analyzed in-depth with a qualitative scoring system, and there was a large amount of off-wiki debate on the public community developer mailing list, Wikitech-l. We went through three major iterations where we served different primary font stacks for the body copy and headings, experimenting with putting different font-families first. The version that's being released is very much the result of feedback from the community. Steven Walling (WMF) • talk16:53, 26 March 2014 (UTC)[reply]
I didn't want to say that there was no discussions going on regarding typography, but I believe they got mixed up with other features a lot substantially reducing the overall efficiency of the beta feature process. I think that if typography and the other UI changes would have been separate beta features from the start we would have deployable code for both now, with higher quality than we have now, with altogether less discussion needed. I don't want to suggest that the result of typography refresh is an overall failure, but I think that the whole process was very inefficient, creating unnecessary workload for a suboptimal result. --Patrick87 (talk) 18:15, 26 March 2014 (UTC)[reply]
"I believe they got mixed up with other features a lot substantially reducing the overall efficiency of the beta feature process". Yes, this is a good point and something to correct next time. We need to avoid scope creep like that in the future, even if beta features are meant to be experimental. Steven Walling (WMF) • talk19:41, 26 March 2014 (UTC)[reply]
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
So what has been demonstrated is that due to creeping featurism the Typography Refresh has never had an actual beta test? Then why is the Typography Refresh being rolled out? The entire point of a beta test is to test the actual changes that are going to be made prior to rolling them out on a large scale. Nothing like this should be rolled out without actually testing it in a beta that has the actual features which are proposed to be rolled out. — Makyen (talk) 21:50, 27 March 2014 (UTC)[reply]
It is not unusual for beta programs to test out several features at once, then roll out those that satisfy demand while trowing out the rest. In this case, it ended up with the same feature set that it originally started out with: just the typography. — Edokter (talk) — 22:15, 27 March 2014 (UTC)[reply]
For a quick look at what's likely to change, first turn off the Beta Feature here at en.wp, and then look at the current style versus the expected style. (Don't forget to re-enable the Beta Feature if you want to follow the other changes.) WhatamIdoing (talk) 22:22, 27 March 2014 (UTC)[reply]
Edokter For many things, I can understand cutting out features from the beta in what is being deployed and deploying it based on testing which included features not in the generally deployed version. However, I have a few problems in this specific instance.
The first is that UI issues are often a gestalt from which it is difficult for many users to separate out specific issues. If they do so, then it is usually to select the one or two most significant issues to them. For UIs, issues are often things which take people time using the interface to generate good feedback. Often, if they are generating immediate feedback it is because there are significant problems for them in specific areas where they are immediately using the UI under test.
Second, the other issues introduced by the creeping featurism so significantly overshadowed any issues that might exist in what is being rolled out so as to make it such that the changes actually being made have had little consideration by those very few users who have used the beta. For me personally, I turned the beta on briefly to look at it. In doing so, I found that the TOC and blockquote changes were so wrong for me, that I just immediately turned it off and went to try the Monoblock skin to make sure I had a alternative if it was actually deployed. Yeah, for me those issues (and the max 715px width restriction, no longer in the beta) were so bad it just wasn't usable. I then went to look at the talk page and found that those items were going to be taken out due to others already objecting. I had assumed that there would be some amount of time in beta that would actually reflect what was being proposed for deployment. Obviously, I was wrong in that assumption.
Third, the present beta, as currently available days away from the change being deployed across Wikipedia still includes features which greatly distract from the ability to get reasonable feedback about the changes actually being made. As an example of this, note that the title of this subsection is "Blockquotes", a feature which is still enabled in the beta, but not going to be deployed.
It just feels that this is being pushed out to meet some schedule rather than being adequately tested. My feeling is that general deployment across Wikipedia should be delayed until there has been a beta that includes just the features intended to be deployed and allowing some reasonable time for users to try it and provide feedback. I note that the project has started to get some reasonable feedback specific to the fonts at Typography Refresh.
Makyen, first off, thank you for the thoughtful feedback. I fully agree with you about points regarding mixing in features, and the way that most users always assess something as a whole. However, we really did get a lot of specific feedback that didn't have anything to do with the blockquotes, TOC, etc. The primary body content and header styles really were hotly discussed, both in many of the 100+ threads on mw:Talk:Typography refresh and in venues like some our largest public mailing lists (specifically Design-l and Wikitech-l, if you follow those). The fundamental font styles went through several releases with different settings tried out, and we moved forward with the current settings based on community feedback. Steven Walling (WMF) • talk23:20, 28 March 2014 (UTC)[reply]
I was first alerted to this problem through an edit request, specifically to "fix the script error in the line for Resident Evil 5". The error message reads "Lua error: Too many calls to mw.language:formatDate()." I'm guessing this has to do with the date formatting done by {{vgrtbl}} used to format the release dates. What, if anything, can be done about this? Some searching reveals that similar problems have been brought up before. Anon126 (talk - contribs) 01:05, 25 March 2014 (UTC)[reply]
@Anon126: Some optimization no doubt can be done (use fewer and less complex templates), but when you build a jenga tower as high of the roof, expect it to collapse. I suggest building multiple towers, or choosing a different technology (not wikitext, but wikidata for instance) to build your tower. But consider replacing dts template with data-sort-type and data-sort-value attributes for instance. Should remove a bit of the complexity already. —TheDJ (talk • contribs) 09:56, 25 March 2014 (UTC)[reply]
Jackmcbarn and I just went through and dealt with a transclude inclusion size on that page. We trimmed some templates and the page was rendering again. Perhaps he can help with the Lua issue as well (as I'll admit, I still know little about Lua). — {{U|Technical 13}}(t • e • c)12:19, 25 March 2014 (UTC)[reply]
I just discovered this under Preferences --> Gadgets --> Testing and development. It makes images look so much nicer, without the extra lines around them. Thank you to the people who developed it! SlimVirgin(talk)03:49, 25 March 2014 (UTC)[reply]
I've added a thumbnail of the 3 variants that I'm aware of. (1) The Default. (2) Edokter's gadget. (3) The WMF Design Team's design, as seen in a few iterations of the Typography refresh; (pinging Steven and Jared).
I like both the alternatives, and would like to see any other options that have been previously discussed, or can be brainstormed. HTH. –Quiddity (talk) 00:36, 27 March 2014 (UTC)[reply]
I like the version of Edokter and liked his previous version with a stronger drop shadow even more. The Typography Refresh version without any border at all doesn't work out in my opinion – it's just too unstructured. --Patrick87 (talk) 00:59, 27 March 2014 (UTC)[reply]
Redrose64, thanks for the information. Edokter, I really love what you've done, so thanks again. The images are really popping off the page. Quiddity, thanks for posting those. I like the third option too, but Edokter's seems to lift the image more. SlimVirgin(talk)01:29, 27 March 2014 (UTC)[reply]
AFAIK we didn't change any of the code in those templates: this was the only edit made as a consequence of that discussion. No other pages should have been affected. --Redrose64 (talk) 19:59, 25 March 2014 (UTC)[reply]
We have a nice thing called history pages... They work. But those 2 changes should not affect the rendering of the page. But yeah "different" isn't really a problem description that makes it easier to figure out what the problem is. —TheDJ (talk • contribs) 23:57, 25 March 2014 (UTC)[reply]
Sorry, I was hoping someone would just recognize what had happened without my having to describe it in detail. OK, up until a day or so ago, the following code:
{{col-begin}}{{col-break}}
*List element 1
*List element 2
*List element 3
*List element 4
{{col-break|gap=4em}}
*List element 5
*List element 6
List element 7
{{col-end}}
Would result in a list such as this:
List element 1 List element 5
List element 2 List element 6
List element 3 List element 7
List element 4
Now, it results in a list like this:
List element 1 List element 5
List element 2 List element 6
List element 3 List element 7
List element 4
So the ability to control the separation of one part of the list from the other (using the "gap=" parameter) seems to have disappeared, and both parts of the list are presented at what seems to be a standard distance apart. Thus lists that fit in nicely to the left of an infobox, for instance, are now forced down to below the infobox, leave a whopping big block of whitespace. (Ironically, since the columnization of the list was done in order to reduce the whitespace in the article caused by a single column list).
Yes. "{{col-begin}}{{col-break}}" creates invalid HTML. Because of this, the last part of col-begin gets stripped off. Before the last part was "width:100%". Now the last part is "role=presentation". So effectively for you width:100% is getting added all of a sudden. I do not consider this a bug, it's an incorrect usage leading to side effects. —TheDJ (talk • contribs) 08:21, 26 March 2014 (UTC)[reply]
Whether that's the case or not, the "incorrect usage" created the desired result, now it does not, so the large number of articles in which this is used are now badly formatted -- so "fixing" the problem did not help Wikipedia, it hurt it.
They're on the same line because that was how I found I could control the spacing between the columns. And, no, putting them on separate lines does nothing, it was the first fix I tried when this came up. BMK (talk) 22:26, 26 March 2014 (UTC)[reply]
You mention a |gap= parameter, which I see is coded into {{col-break}} but is not mentioned in the documentation for that template. But I'm afraid that I can't work out what is being attempted here, since the above examples are not real-world. Please give an example (two or three would be better) of an actual article which uses {{col-begin}}{{col-break}} and {{col-break|gap=4em}} in the manner shown above, and where the intended appearance has changed. --Redrose64 (talk) 23:53, 26 March 2014 (UTC)[reply]
I'm not sure what you mean by my examples not being "real world", since they simulate as exactly as possible what happens on my screen using the code I referred to. I can point you to an article that uses the coding, and you would see the same result as my second example, but it is not possible for me to point to an article that showed what used to happen, because it doesn't happen anymore, due to some change in the functionality of the code.
In any event, take a look at the article Without Pity, in which the cast list uses the above code and, on my screen, with my resolution, used to live nicely to the left of the infobox. Now (with no change in the code, on my screen, at my resolution), the gap between the two columns of the list is very large, and is therefore pushed down to below the infobox.
When you used "List element 1", "List element 2", "List element 3" etc. for a list, that is an example which is clearly contrived for the purposes of demonstration. A real-world example would be a copypaste from an antual article where the problem occurs, or better still, a link to such an article. The presence of that infobox to the right of the list is significant, and means that now I have made this change, I can look at Without Pity and honestly state that I see a change; is that now back to how it was before? --Redrose64 (talk) 16:45, 27 March 2014 (UTC)[reply]
Hallalujah! Yes, indeed, that is what it used to do. Many thanks for tracking that down and fixnig it, it is much appreciated. BMK (talk) 19:11, 27 March 2014 (UTC)[reply]
@Beyond My Ken:, regardless of wether this now 'works' again, I cannot stress enough that using {{col-begin}}{{col-break}} like this is a BROKEN and incorrect methodology and you can thus NOT rely on it to be working in the future. Col-break needs to go on a new line anything else is simply not valid. What you want is the to either specify the width of the column, or at the very least, you want to change the width of the block. {{col-float}} might be an option for instance. —TheDJ (talk • contribs) 19:23, 27 March 2014 (UTC)[reply]
Thanks. I am not planting my boots in the mud or my head in the sand on this (choose your metaphor), once I understand a valid way to get the same result as I got before, I'll change the columnization of articles I've worked on as I come across them. I was simply happy that all those articles are not now displaying poorly because of the functionality change. I'll certainly take a look at col-float. BMK (talk) 01:42, 28 March 2014 (UTC)[reply]
CodeEditor Feedback desired
I've been doing some work on the Lua/CSS/JS CodeEditor to make it and its toolbar a bit more usable, but I'm looking for some input on what YOU want in the toolbar
Some possible options are:
show invisible chars
search and replace
undo/redo
indent/unindent
Enable soft wrapping of lines
tab and page guides
Disable syntax checking/linting
Disable gutter/linenumbers
Select editor skin
Edit snippets
Go to line
A list of existing key commands is here And ACE itself has a demo site that shows a few of the options as well, if you want to experiment.
I've now got a button to show invisible characters, and a button to show the find and replace dialog and wondering where to go next. Of course most options are available already trough key commands but many people are not familiar with those, so what do you think should be in the toolbar, what do you think should NOT be in there, and do you have additional ideas to the ones I listed above. I can really use the input. —TheDJ (talk • contribs) 00:11, 26 March 2014 (UTC)[reply]
Wait, the editor has syntax checking that works? Right now I rely on a crude hack to have it.
"Go to line", indentation guides and indentation converter would be great. Also, remove buttons that are only relevant to wikitext. Keφr06:34, 26 March 2014 (UTC)[reply]
A patch to remove all the other buttons is being worked on, a patch for code completion is waiting for review and a patch to enable syntax checking is already merged (preview of the last available on beta labs) —TheDJ (talk • contribs) 07:26, 26 March 2014 (UTC)[reply]
Finally. Those forgotten commas were driving me nuts. How about stripping trailing whitespace from lines? I think it should even run automatically before saving a JS/CSS page.
Also, can the JS linter be customised or hooked somehow? For example, I would like to turn off warning about assignment-expressions in conditionals (I like using the if(m=/regex/.exec(s)) idiom). Or warn when using some specific symbols, like deprecated MediaWiki features. Keφr15:22, 26 March 2014 (UTC)[reply]
As long as it is supported in JSHint, then with this technique, we can make some 'initial' changes, or even you as a user can make some changes, by hooking into codeEditor's mw.hook event. (I should document that part btw). —TheDJ (talk • contribs) 15:56, 26 March 2014 (UTC)[reply]
Nothing to do with the toolbar, but could we make the font size a bit bigger? For me it is significantly smaller than the default wiki font size, so I have to change the browser font size every time I switch from wiki pages to CodeEditor if I want to avoid squinting. I'm not sure where the setting is best applied though. Also, is there a way to override the ctrl+R shortcut? I have been known to press that instead of ctrl+F, and it has made me lose work more than once, as on Firefox and Chrome it is the shortcut to refresh the page. Out of the toolbar buttons listed above, I think the most useful ones would be enable soft wrapping of lines, show invisible chars, search and replace, go to line, and indent/unindent. I don't see myself using disable gutter/line numbers or tab/page guides. Also, what does the "edit snippets" feature do? — Mr. Stradivarius♪ talk ♪12:29, 27 March 2014 (UTC)[reply]
We can, though for me it's already quite big (12px Monaco). I think that if you don't have the Monaco, it's probably significantly smaller. I'll think about how to solve that. With regards to the shortcuts, I plan on adding the dialog to warn you about unsaved changes, but currently it's conflicting with dialog of the plain wiki editor, so I need to spend some time refining it. But having that dialog should make the problem of keyboard shortcut conflicts less problematic I think. Edit snippets is a mode where you can maintain and keep templates that you can reuse. I'm not sure on how to do that yet, preferably they are saved to some userspace page. It will likely be last on my list, since there is plenty low hanging fruit for now. —TheDJ (talk • contribs) 12:50, 27 March 2014 (UTC)[reply]
Yes, having the dialog to warn about unsaved changes would do the trick. I don't think there's any need to make the edit snippets feature available for now, either. — Mr. Stradivarius♪ talk ♪13:28, 27 March 2014 (UTC)[reply]
Keep the font size as it is, please. These old eyes have no problem reading the text in the editor using Chrome.
Tool bar help menu should be appropriate to the code editor and should include the list of keyboard commands and perhaps links to css/js/lua references.
Screenshot of Wikipedia beta code editor in Chrome on Trappist the monk's winxp machineFont on my machine is completely different from yours. The code editor font and the font in this edit window (not the enhanced editor) are similar to each other. The beta code editor and the current code editor, for me, have similar fonts.
Every editor that supports Unicode should have a function to display the code (and perhaps name) of a character. This could be a character pointed to by the mouse, or the character at the cursor location. Jc3s5h (talk) 12:37, 27 March 2014 (UTC)[reply]
Remembered something now: relegate the "search and replace" function to another shortcut (Ctrl+H seems customary), instead of Ctrl+F twice. The rationale is that I often use Ctrl+F with the intention to simply move the keyboard focus to the search box, and sometimes I forget it was already there. — Keφr06:05, 31 March 2014 (UTC)[reply]
There are a couple of commands that have already been removed (not reassigned) for similar reasons. The problem with reassigning is that it also 'messes' with your expectations. I'm not sure what is better. —TheDJ (talk • contribs) 08:18, 31 March 2014 (UTC)[reply]
I'm seeking confirmation that "Block account creation stops the user from creating a new account for 24 hours after the block is made" as described at Wikipedia:New admin/Blocking#User blocks.2Funblocks only disables that feature for 24 hours even if you're blocking the account indefinitely. This is the only place where it seems to state this, as at WP:HARDBLOCK (which is only for IP's but the only place that mentions account creation block but not how the mechanism works) it does not mention it and thus implies the account creation block lasts the duration of the time of the block (for example an indefinite block with that setting ticked would disable account creation indefinitely as well). Thanks! Mkdwtalk18:26, 26 March 2014 (UTC)[reply]
AUTOBLOCK is for IP addresses as well so not really closer. My initial question is not about that anyway but about the timer on the setting "block account creation" and conflicting information. I will probably need a sysop to answer my question but thanks for pointing that detail out. Mkdwtalk21:54, 26 March 2014 (UTC)[reply]
There are two types of account creation blocks. The type you are referring to is caused by the autoblock functionality of mediawiki. When an account is blocked their are two boxes that are checked by default. Prevent account creation and Automatically block the last IP address used by this user, and any subsequent IP addresses they try to edit from. In some cases (spam, COI username) an account can be blocked and instruct the user to create a new account. In those cases the the admin would uncheck the Prevent account creation box, which would enable the user to create a new account after their existing account is blocked. It has the same effect as autoblock with a limited duration (24 hours). When making the same settings on an IP block it prevents account create for the duration of the block period. @Mkdw: hope that helps. Werieth (talk) 00:43, 27 March 2014 (UTC)[reply]
You can actually see this behaviour at the blocklist. If you were to select the "Autoblock any IP addresses used" setting while blocking an account the blocklist would state "Autoblocked because your IP address was recently used by (Username)". This block is always 24 hours and the target is always "Autoblock #(Number)" (The actual block is placed on one or more IP addresses, but since that information may not be shown publicly the autoblock entry is used to hide this).
If you were to block an IP address directly you could select the setting "Block account creation". This setting will prevent account creation for the entire duration of the block. In other words: If you select this setting and block the IP address for a week, account creation would also be blocked for a week from this address. Excirial (Contact me,Contribs)12:01, 27 March 2014 (UTC)[reply]
Article creation by editor (Page creator tool)
Does anyone know the current link to check how many articles an editor has created? I would like to check my own creation stats. I seem to have lost the link for that, but I believe it was once on Toolserver and then Labs, tools.wmflabs.org/xtools/pcount/, but this one does not seem to be active. — Maile (talk) 13:04, 27 March 2014 (UTC)[reply]
Using wikipedia.org domain spelling bastardizations for phishing
So, I was a bit quick to the draw in my browser the other day and found myself going to wikipeda.org (2 i's instead of 3). What I found was a portal that looks to pseudo-randomly refer traffic to spamming and phishing affiliate pages, for example allclktrk.com which plays an audio file and attempts to phish users into downloading a fake "update" for adobe. I haven't had enough time to check and see if the audio file was part of an overflow attempt. I'd be really surprised if it wasn't. Sometimes if you're lucky you get looped through a couple of extra affiliates and end up somewhere like a landing page on intuit's (real) web page.
They forward subdomains using a wildcard, for en.wikipeda works but also stuff that we wouldn't cover like cn.wikipeda.org or isuck.wikipeda.org. The domain is registered by Jasper Developments Pty Ltd, a web design firm in Australia. (note: I am not affiliated with them, and in fact I've never heard of them)
http://reports.internic.net/cgi/whois?whois_nic=wikipeda.org&type=domain
I have some additional data and would be happy to provide more. There are strong and easy remedies to deal with domains outside of the foundation's control but that are preying on Wikipedia users in this manner. I am happy to discuss further so we can figure out how to best protect users that may not be technically proficient. While I have a significant amount of professional experience in network security, Im not interested in selling my services; just trying to protect other users. Thanks. Jay Dubya (talk) 18:06, 27 March 2014 (UTC)[reply]
You can send a mail with details to legal-tm-vio at wikimedia.org and maybe the legal team can file a case to do something about it. Technical information that might help protect users can be reported to security at wikimedia.org —TheDJ (talk • contribs) 19:40, 27 March 2014 (UTC)[reply]
Font format messed up in common template
{{Val}} has started forcing numbers to display in a monospace font, contrary to other templates such as {{gaps}} and making it an eyesore in our articles (especially when tables randomly display different numbers in different sizes). But I can't find the dependent template where the change was made. Can anyone help? — kwami (talk) 04:47, 28 March 2014 (UTC)[reply]
No, it's still messed up. I just tried it out to make sure it wasn't a caching problem, and it still forces a monospace font. — kwami (talk) 08:24, 28 March 2014 (UTC)[reply]
How about an example? The following seem to use the standard font for me:
The two don't match. At left is my browser font, at right the one forced by the template. The digits on the right are twice the size of the ones on the left.
This should be what I see one the left. I don't know which font I'm seeing on the right, but maybe it's the same for both of us:
I think I know what you see (but not certain); There is CSS in place (for a few weeks now) that forces digits in {{val}} to display as tabular, lining numerals as opposed to proportinal non-lining numerals. They behave as monospace, but they are showing in your default font, just in the lining variant. This is done because val is often used in tables and scientific notations where non-lining, proportional numerals were detrimental to formatting. Fonts like Candara and Georgie use old-style (non-lining) numerals by default. Below example shows what effect this CSS has:
I see. In other words, it's like {{Allcaps}} for numbers. This still needs to be reversed, or at least made optional, because it screws up the formatting: Graphically, it does not match numbers that aren't formatted with Val, nor does it match Gaps, Convert, or other number templates. Using Val for everything is not a solution, because Val can't handle everything. It would be fine to have this as an option, say in a table where all numbers are formatted the same, but not as the default for text or info boxes where it's mixed with other formatting.
One example of the problem is that we recommend Val at the MOS to get certain formatting effects, but now Val does not produce the recommended formatting. — kwami (talk) 00:41, 29 March 2014 (UTC)[reply]
Which MOS are we talking about? I am aware there are many more templates that may benefit from this; all you need to do is add the .digits class to the template, or even the table. Note that this was done specifically to counter formatting issues caused by fonts with old-style numerals. Candara and Georgia are the most notable. Not many other sans serif fonts even have these; you just happened to pick a font that does. Try using Calibri instead, and you will notice all digits are the same again. If you want to keep Candara, I can give some CSS to counter it. — Edokter (talk) — 01:11, 29 March 2014 (UTC)[reply]
MOS:NUM. BTW, although they use Val in their examples, they've enclosed it in further formatting (the brown and green) that reverts the effect of .digits class.
Why should we force browsers to display a certain way when it's unnecessary, or make users pick a font they don't like? I edit here, but most of our readers do not, and are not going to start adding to their CSS just for when they're on WP. Most of the time it's not important to have tabular figures, and where it is important, we could have an option for it. The whole reason I chose Candara as my default font is that I DON'T WANT NUMBERS DISPLAYED IN ALL CAPS LIKE THIS. IMO they look bad, and they're more difficult to read. — kwami (talk) 01:40, 29 March 2014 (UTC)[reply]
The {{xt}} templates do not cancel out the .digits class (otherwise, you would not complain). I have to say, you are probably one in a million to have such a default font. I was thinking about applying the same to example text, as I despise how Georgia uses old style numerals; I truly believe it hurts readability. Never the less, I can try disabling the lining (caps) while maintaining tabular display and see how that works out. — Edokter (talk) — 02:09, 29 March 2014 (UTC)[reply]
As it turns out, Georgia (the font used for examples) does not support tabular display unless lining is also enabled. That means examples using {val} have non-aligned numbers. I'll leave that be for now, as {val} in example text rarely needs alligned (sub/sup) numbers. — Edokter (talk) — 02:29, 29 March 2014 (UTC)[reply]
Thank you, that looks so much better! For me, old-style digits are more legible because you can recognize numbers by their shapes, as you do words, without having to look at each digit individually. That's what makes text like this more legible than all-caps. But the reason it was an eyesore was the random mixture of old-style and tabular in text and tables. Since we're never going to template all numbers in our articles (and given the limitations of the templates, we can't template them all), that would be an eternal problem. — kwami (talk) 03:40, 29 March 2014 (UTC)[reply]
I'm confused by the mentions of "all caps" in relation to numbers. Letters have two main forms: uppercase (also known as capital letters - "ABCD") and lowercase (or small letters) - "abcd". Numbers have only one form - "0123" (if I type ⇧ Shift+4 I don't get a variant on the figure 4, I get the dollar sign $) and so the concept of "capital numbers" is surely meaningless. --Redrose64 (talk) 10:19, 29 March 2014 (UTC)[reply]
Redrose64, see Text figures. Kwami, I cannot guarantee the current situation will remain. If situations come up with the {{xt}} templates that involve text figures messing up the display, I may have to re-enambe the lining. Also, there is a chance that the font used for example may be changed to Times, which does not have text figures (meaning they only have 'upper case' numbers). — Edokter (talk) — 13:45, 29 March 2014 (UTC)[reply]
Why not add a lining option, then? It seems overkill to change the entire project because of the rare instances that may need it. — kwami (talk) 13:59, 29 March 2014 (UTC)[reply]
From my reading of Text figures, it seems that it's not really a capitals/lowercase issue, but a variation of the font family which causes use or non-use of ascenders and descenders. In a few of the examples above, I see variation in font family: in that provided by kwami at 10:12, 28 March 2014, the right-hand side is normal, the left-hand side is different. In the case of the examples by Edokter at 11:18, 28 March 2014, the fonts on left and right are the same, but differ from the rest of the page. In all other cases, I see the same font on the right as the one on the left, and it's the same as normal text. I presume that whatever font is intended, my computer hasn't actually got it and so my browser is falling back on something that it does have, per Basic Font Properties. --Redrose64 (talk) 15:26, 29 March 2014 (UTC)[reply]
The above example no longer shows the difference becuase I limited the use of the digits class. If you have Windows, you should have both font used there: Candara and Georgia. Here they are hardcoded:
Aargh! You just added .digits to {su}, didn't you? Now we're back to the situation that created the last, huge argument, where assymmetrical uncertainties like 123+456 −789 is screwed up (cf. 123+456 −789). Literally half of all instances of this on Wikipedia (I've counted) are due to my edits, and last time I reverted them all so that our tables and infoboxes wouldn't look horrible. We debated how to handle this for weeks, and finally came to consensus. Could you just allow that hard-won agreement to stand, and revert this edit? — kwami (talk) 23:17, 29 March 2014 (UTC)[reply]
I see absolutely no difference between 123+456 −789 and 123+456 −789. Moreover, their fonts are just the same as the rest of the page. --Redrose64 (talk) 23:22, 29 March 2014 (UTC)[reply]
Depends on which font you're using. To me, in the first case the super- and sub-scripts look like they've been enclosed in < code > formatting. We debated this for a month. The resulting consensus shouldn't be unilaterally changed like this. — kwami (talk) 23:24, 29 March 2014 (UTC)[reply]
Kwami, I must say this, but 99.9% of our readers are not using a font with old-style numerals like you do. Are you telling me that whole discussion was a result of you using a non-standard and non-common font? And have you been reverting stuff based on what you see on your screen as opposed as to what the other 99.9% see? If that is so, please stop. Practically every participant in that discussion is using regular font with lining numerals, and their main problem was that they did not line up horizontally, which is why they were using monospace fonts in the first place. I fixed that by disabling the kerning, so that the assymmetrical uncertainties would show in at least in the same font. However, I found that did not fix Georgia, which is our main font used in example text. So I found a ways to make Georgia behave as well, but it invloves forcing numerals to show in 'upper case'.
The only way I can help you is to provide some CSS so that Candara wil use old-style numerals while maintaining horizontal alignment (which is not possible in Georgia). I will need to know your browser and skin. — Edokter (talk) — 23:45, 29 March 2014 (UTC)[reply]
I don't know what you mean by a "non-standard font". Candara is a default font in Windows (or at least MS Office, I forget which), so it is extremely common. I don't know what %age of people have the same problem I do, but it looks like you're just making numbers up.
If the specific font formatting of our examples is the problem, can't we fix it in the examples, rather than forcing that solution on the whole encyclopedia?
And looking at Candara vs. Georgia, it appears that adding digits class does not fix the problem in Georgia anyway:
21563 +1111 −9999 vs. 21563 +1111 −9999 (default font)
Kwami, Candara may be installed by default in Windows, but no browser has ever used it as a default sans-serif font. You made that change, but you cannot expect that enyone else has. I am not making anything up; I consider myself quite knowledgable when it come to web typography. The fact is, I am not forcing anything to the encyclopedia, other then making numerals line up. For the 99.9% that means they see the digits as they have always seen them, but with the same width (as most standard sans-serif fonts used by web browsers do not use old-style numerals). Those 0.1% that do use a font with old style numerals will see lining numerals instead. I have changed the examples to demonstrate the problem more clearly. Georgia should show lining (upper case) numerals with the class.
April 3rd will see the introduction of the new typography, which may startle you, as it will probably force Arial as the default font on your PC. Now everything is fixable, I just need to know what browser and skin you are using. — Edokter (talk) — 00:39, 30 March 2014 (UTC)[reply]
Firefox, default skin.
Unless you've actually done a survey of who has the same issue as I do, you made up the figure of 99.9%. You can't make stuff up and then take issue when I object that you're making stuff up.
"Georgia should show lining (upper case) numerals with the class". No, it doesn't: Your change to ones and nines makes it all the more obvious that the digits do not line up on either side of the "vs". So, again, since your fix doesn't actually fix anything that you've shown, but does interfere with the reader's ability to choose how their browser displays, what's the point?
Also, what's the advantage of moving digit class to the {su} part only? Wouldn't it be better to have the whole number display the same way? — kwami (talk) 05:21, 30 March 2014 (UTC)[reply]
This is what I see
If you don't see a difference in the above example, then you should definitely not even see any difference in {val} either, and you are just complaining about absolutely nothing. Are you trying to trip me over or something? OK, last time... do you see any difference now in the top line? (the rest may see a difference in spacing). — Edokter (talk) — 12:46, 30 March 2014 (UTC)[reply]
Of course I see a difference! But the difference is in Candara. I don't see a difference in Georgia. So, from my POV, you've messed up my browser defaults, but you haven't done anything to resolve the issue you're trying to fix.
What you see for Candara is exactly what I see. However, what you see for Georgia is not what I see. What I see is Old Style on both sides: The "fixed" digits on the right look exactly like the unfixed digits on the left. So you changed the Candara from Old Style to tabular, but had no effect on the Georgia, which is still Old Style. It would appear that your fix isn't going to work for many people. It's not like FF on Win7 is an unusual combination.
Just to be clear, let's number the examples like this: . For (2), (3), and (5), I see what you see. But (6) looks just like (3). If anything, the discrepancy in width I see between the ones and the nines is a bit greater, even in supposedly "tabular" form: The Georgia nines are 11% wider than the ones in your screen shot, but 22% wider on my display. That's true on both the left and the right.
[Also, (1) and (4) look like (2) and (5), given that's my default font.]
Since Georgia is so difficult to work with, maybe the solution is to choose a different font for our examples, and let people *choose* whether they want an Old Style font? — kwami (talk) 19:54, 30 March 2014 (UTC)[reply]
Well that is new, and makes no sense. What is you default serif font? And in what font do you see example text? If you see that in Georgia, you should not see uppercase numbers in example text... yet that is exactly what you complain about in MOS:NUM(!) So forgive me for being so confused... I want to help anyone, but I have spent way too much time on this alreaady, given your default font is rather exceptional. You know what? I am going to give you some custom CSS that should simply cancel the lining numerals that you find so distracting. That should hopefully put this to rest. — Edokter (talk) — 20:25, 30 March 2014 (UTC)[reply]
And regarding a different font for examples, I have proposed changing it to Times New Roman, but that font has no old style numerals, so you'd end up with the same problem. — Edokter (talk) — 20:29, 30 March 2014 (UTC)[reply]
My default serif font is Palatino Linotype. Yes, your example appears to be Georgia, and correct, the examples at MOS:NUM are old style digits. However, we don't use Val at MOS:NUM, so what you're doing here has no effect there.
Break
I don't understand. Since you know that the examples at MOS:NUM do not display tabular digits and do not line up, why have you set Val for tabular digits? That screws up Candara, but has no effect on Georgia, and has no effect on the MOS. And why set Val for tabular digits only some of the time, so that different parts of a number conflict?
I also don't understand about TNR. If it doesn't have OS digits, wouldn't that be exactly what you want, since it would avoid the problem?
As for your adjustment of my CSS, now Candara displays tabular Old Style digits, which is a good result. Georgia, however, is still messed up. So, (1) wouldn't that CSS fix be good to add to the WP default CSS, so that everyone gets the benefit, and (2) how does any of this address the supposed problem, that Georgia does not have tabular digits?
Here are the previous examples, but using the Val template (this after you installed my CSS, which allows lining/tabular spacing, but keeps OS forms):
21563+1111 −9999 vs. 21563+1111 −9999 (Candara)
21563+1111 −9999 vs. 21563+1111 −9999 (Georgia)
The digits class makes no difference in Georgia. In Candara, the digits class makes no difference to the {su} part, of course, but does affect the width of the one in the main part. In Georgia, it makes no difference at all. Also, in Candara, the super- and sub-scripts are tabular Old Style digits. In Georgia, they are non-tabular Old Style digits, the same as they were before you adjusted my CSS, and the same as they are (and were) at MOS:NUM. So, with all this work, you've corrected the display for a single person (me), but haven't addressed the fact that the digits don't line up in Georgia, which was supposed to be the reason for the fix, nor that you've made Val to screw up the display of assymmetrical uncertainties for everyone who's chosen a font with Old Style numbers, apart for Georgian, which has thwarted your fix. — kwami (talk) 21:29, 30 March 2014 (UTC)[reply]
{val} uses the .digits class only on the numbers passed to {su} for asymmetrical uncertainties. I did that in response to your your Aargh! comment above. I don't know what you have been editing/reverting based on that complaint, but rest ashured, you should not see any lining digits in {su} or {val} anymore. — Edokter (talk) — 21:19, 30 March 2014 (UTC)[reply]
No, just the opposite: My "Aargh!" comment was in response to your change of the digits class to only the {su} part. Val displayed fine before; that was the edit that messed it up.
I see tabular OS in the {su} part of Val, and non-tabular OS in the other part. But that's just because you fixed my personal CSS. For other people, the {su} part is still messed up.
You did not fix Georgia, which still have non-tabular OS digits everywhere. So, what is the point of your edit? It doesn't fix anything, AFAICT, but it does screw up the display for our readers, depending on what they've chosen as their default font. If it breaks things but doesn't fix anything, you should just revert it. — kwami (talk) 21:37, 30 March 2014 (UTC)[reply]
I did fix Georgia, as you can see from my screenshot. I did not apply your custom CSS site wide becuase it breaks Georgia for me as well, so I had to apply both lining and tabular. I have no idea why this fix does not seem to work on your PC. I suspect you copy of Georgia may be outdated or corrupt (I have version 5.51). — Edokter (talk) — 22:09, 30 March 2014 (UTC)[reply]
I have whichever version of Georgia came with my OS, which I suspect is what 99.99% of our readers have (not my version, but whichever version came preloaded on their OS's). So you did not fix the problem for our readership, you fixed it for yourself and people like you. That's not a good reason to change a widely-used template. You also said the change was for my benefit, but I didn't want it. If it was just to placate me, could you revert it? — kwami (talk) 06:13, 31 March 2014 (UTC)[reply]
Then we need to set up a poll to find out who is affected. For now, I have tested four PCs ranging from XP to Windows 7 with Georgia installed and they all work on my end. — Edokter (talk) — 10:35, 31 March 2014 (UTC)[reply]
This is Georgia with lining numerals: 0123456789. Do you see it now? If so, your Georgia copy does not support lnum/tnum combination
This is Times New Roman with old-style numerals: 0123456789. Works only with proportional numbers.
OpenType font settings are a strange beast. For me, the lining/tabular feature combination work on Candara, Georgia and most other fonts with defualt old-style numerals. The Time New Roman example was to see if it contains old-style numerals; it does, but they only work whn not using tabular display, so tabular would automatically force lining numerals. — Edokter (talk) — 11:23, 31 March 2014 (UTC)[reply]
Not sure what I'm supposed to be seeing. The Georgia digits are Old Style. They are not equal width. The TNR digits are full height ('caps') and equal width. So both appear to me as the opposite of how you describe them. From what I see, TNR would be better of the examples, because there would be no alignment problem, and no inconsistency between character height between the main part of the number and the {su} part. — kwami (talk) 02:12, 1 April 2014 (UTC)[reply]
You see both in the opposite of what you're supposed to see. I'm more then happy to use Times as example font (instead of Georgia), but I though you didn't want any lining digits? — Edokter (talk) — 10:21, 1 April 2014 (UTC)[reply]
No, I don't mind lining digits, I just object to mixing them in haphazardly. So if one number in a table is OS, and the next is lining, to me that's an eyesore, and in any case is distracting. It would be like typesetting a few random countries in a list in all caps. Also, if a base number is in OS, but its uncertainty is in lining, that is also an eyesore/distracting. I don't care if the examples at MOS:NUM are lining or Old Style, as long as they're all the same. But again, your edit here had no effect on MOS:NUM, so why do you keep referring to it? As for WP articles, the reader should get to decide for themself which they use, just as they get to decide whether to use a serif or sans serif font, or to have links display with an underscore. — kwami (talk) 05:23, 2 April 2014 (UTC)[reply]
Because you brought it up first: One example of the problem is that we recommend Val at the MOS to get certain formatting effects... You also said you preferred old-style numerals in general. But I'll move the digits class back oto val. — Edokter (talk) — 10:18, 2 April 2014 (UTC)[reply]
FWIW the right column of the three examples works for me on Windows 7 with Chrome, the left side for the default sans-serif font (should be Tahoma on my box) is also okay, but the left sides for Candara and Georgia are ugly. Chrome's "inspect element" function reports that these fonts (sans-serif, Candara, Georgia) actually arrived at their intended places. My Georgia version is 5.00. –Be..anyone (talk) 18:53, 31 March 2014 (UTC)[reply]
MW SVG to PNG conversion issue
This SVG looks fine, has valid code (I checked), and yet is displaying very poorly on the page. Not sure how to fix this. It's a shame that we can't have SVGs be SVGs because some people still use IE8. Any ideas as to what's causing this, or is it just a bug in MW? ▫ JohnnyMrNinja17:07, 28 March 2014 (UTC)[reply]
This is weird... I purged the image, now all PNG copies have white letters. I suspect a regression in libsvg (or was it libpng?) — Edokter (talk) — 18:36, 28 March 2014 (UTC)[reply]
@AKlapper (WMF): Since you've been the bug wrangler for WMF and have worked with GNOME, you probably are the best person to look into this issue. There's librsvg.git, but I'm not sure what the exact differences are. rsvg-convert --version on Labs gives me the result rsvg-convert version 2.36.1 (Wikimedia). πr2 (t • c) 15:24, 31 March 2014 (UTC)[reply]
I was refering to the statement "Wikimedia's patched version" specifically - do you know that there *are* differences, or did you assume? I'm just curious. --AKlapper (WMF) (talk) 19:31, 31 March 2014 (UTC)[reply]
@AKlapper (WMF): Yes, see here are the patches (not as much as I expected). I don't see anything significant there, so I guess this is an upstream librsvg bug. Can you confirm? πr2 (t • c) 20:26, 31 March 2014 (UTC)[reply]
Downloading to PDF
I'm working with a group of students who want to download their sandboxes in PDF form, using the link in the sidebar. However, even after trying this on multiple computers/setups, we've found that some of the references do not appear in the PDF version, even when they are part of the article body (ie. not in any template that should be excluded from download). For example, User:CodyG123/sandbox has 10 references, but when downloaded has nine, and two of those are part of the sandbox template. Anyone know what the problem is? Nikkimaria (talk) 01:36, 30 March 2014 (UTC)[reply]
My testing of your example shows that the PDF fails to include the three named references which are first used in the lead but defined later. If their definition is moved to the first use then they are included. I don't know whether this is a general error in PDF's. The sandbox "references" are caused by url's in {{User sandbox}} and can be avoided by removing the template. PrimeHunter (talk) 02:55, 30 March 2014 (UTC)[reply]
Your talk page mentions another example of missing PDF references apparently at User:Yangtana Li/sandbox. I got none of the 23 references. I kept simplifying the page but didn't get any reference until I removed the citation template from it.[9] It's annoying to test this when you can only download saved pages and not previews. I stop now. PrimeHunter (talk) 03:42, 30 March 2014 (UTC)[reply]
In this edit, I've added Template:Columns-list to a list. This required editing in not only the two places expected (opening the template at the start, closing it at the end) but also replacing an "=" with "=". Without this additional fix, the entire list would display as just the single character "2".
It wasn't that hard for me to locate the problematic character as I dimly recalled that "=" had caused trouble with some other template a while back.
Passing an "=" to any unnamed template parameter always requires a little care. The easiest way to handle this is to start the parameter with |1= (or |2=, depending on which parameter is used), or use {{=}} instead of a regular "=". Or you may use {{div col}} directly so you dont have to use parameters. — Edokter (talk) — 13:23, 30 March 2014 (UTC)[reply]
Aha, "{{=}}". I'd forgotten about that, if I ever knew of it. It takes no fewer keystrokes than "="; but it doesn't seem to call for a <!-- hidden comment explaining it --> whereas "=" does, so its use seems a good idea. Thank you! -- Hoary (talk) 00:24, 31 March 2014 (UTC)[reply]
Animated article history revisions
On IRC a few days ago, someone asked, "Does anybody know a tool that can automatically "play" all the diffs or the versions of an article? To show how it grew over time?"
We used to have a few that worked (listed at Wikipedia:Tools#Visualization and elsewhere) but I can't find anything that works currently.
(I checked the "AniWiki"[1] and "Wikipedia Animate"[2] greasemonkey scripts, as mentioned in The Signpost in 2005, but neither worked anymore.)
I am trying to notify @Thardin12: that I placed a GAN of theirs on hold but when I went to edit their page I noticed several delivered messages that were not showing up when the page was loaded. Can someone take a look at this? LazyBastardGuy19:33, 30 March 2014 (UTC)[reply]
When I edit in template space, I see a box below the editbox that says Preview page with this template Page title: <inputbox> Show preview (button). I have no idea what it does. Can someone link to some documentation or background page for this one? -DePiep (talk) 06:45, 31 March 2014 (UTC)[reply]
That's mw:Extension:TemplateSandbox. It lets you preview how any page would look with the template text that is currently in the edit window. For example, say you edit Template:High-risk, and in the edit window you replace all the existing text with the text "Foo", without saving the page. Then you type in "Template:Hatnote/doc" to the input box you mentioned, and click the "show preview" button. You will then see the Template:Hatnote/doc page, except instead of the big orange banner saying "This template is used on 320,000+ pages", you will just see the text "Foo". (Be careful you don't save the page while testing, though - for serious testing, the /sandbox page is still best.) It also works with Lua modules, and you can preview more than one template at once by using a prefix in your userspace. For that last one, see the extension page for documentation. — Mr. Stradivarius♪ talk ♪07:35, 31 March 2014 (UTC)[reply]
Thanks 'gan. So it is a transclude-preview. (We need an internet convention sign that says "just the link to start with please, then I'll do some research myself first"). -DePiep (talk) 10:44, 31 March 2014 (UTC)[reply]
Broken HTML lists: an indicator of a deeper problem?
{{Nutshell
|It is not necessary or desirable to reply to every comment in a discussion.
|The more often you use the same reason in a given discussion, the weaker it becomes.
|Everyone has the same right to be heard in any discussion.
}}
Because these are positional parameters, whitespace is not trimmed, and the line break at the end of each of the parameters is passed through to the template. You could fix this in the invocation by doing this:
{{Nutshell
|1=It is not necessary or desirable to reply to every comment in a discussion.
|2=The more often you use the same reason in a given discussion, the weaker it becomes.
|3=Everyone has the same right to be heard in any discussion.
}}
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.23wmf20) was added to test wikis and MediaWiki.org on March 27. It will be added to non-Wikipedia wikis on April 1, and all Wikipedia wikis on April 3 (calendar).
Typography Refresh was added to test wikis and MediaWiki.org on March 27. You'll only see it if you use the Vector skin. For users on non-Wikipedia wikis, it will be enabled on April 1, and for Wikipedia users on April 3.
CirrusSearch, the new search tool, was enabled as a beta feature on over 30 new wikis on March 27. [10][11]
VisualEditor news
Blocked users now see the same messages in VisualEditor as in the wikitext editor. [12][13]
The search box for re-using a reference in VisualEditor is now cleared after each use. [14]
New links on sub-pages no longer point to the wrong location in VisualEditor. [15]
VisualEditor's media dialog no longer breaks when opening some types of images. [16]
Future software changes
You will not be able to use the Wikitech wiki for a short period around 16:00 UTC on April 1 due to a server change. [17]
CirrusSearch will become the main search engine for all non-Wikipedia wikis except Commons, Meta and Incubator on April 2.
You will soon be able to use a new special page listing duplicate files. [18]
Deleting a version of a file or a version of its description page will soon be shown differently in the logs. [19]
Changes to the default site typography coming soon
This week, the typography on Wikimedia sites will be updated for all readers and editors who use the default "Vector" skin. This change will involve new serif fonts for some headings, small tweaks to body content fonts, text size, text color, and spacing between elements. The schedule is:
April 1st: non-Wikipedia projects will see this change live
April 3rd: Wikipedias will see this change live
This change is very similar to the "Typography Update" Beta Feature that has been available on Wikimedia projects since November 2013. After several rounds of testing and with feedback from the community, this Beta Feature will be disabled and successful aspects enabled in the default site appearance. Users who are logged in may still choose to use another skin, or alter their personal CSS, if they prefer a different appearance. Local common CSS styles will also apply as normal, for issues with local styles and scripts that impact all users.
So that's the secret. I don't know whether I am the only one who almost went crazy trying to understand how the fake warning from User:Σ/Userpage/1 April could get transcluded on Sigma's user page, though that was probably exactly the joke ("Hmm, Template:PleaseDontEdit/ doesn't exist, maybe there's some magic word called "PleaseDontEdit/" or something?"). SiBr4 (talk) 20:32, 1 April 2014 (UTC)[reply]
The same trick is used in the /tidEtnoDesaelP subpage as well. After copying the subpage's code to Notepad and Ctrl-H-ing away all comments, it turns out it actually just transcludes User:Σ/Userpage, which in turn shows the warning on 1 April and the "normal" userpage on other dates. SiBr4 (talk) 20:51, 1 April 2014 (UTC)[reply]
Page not found watchlist-contributions sporadic issue
There's something funky going on, not because of April 1, and not for the first time. I just created Template:Did_you_know_nominations/Snow_in_Louisiana. I can transclude it with no problem. I can open it from Template Talk: Did You Know. And I can otherwise insert it as a blue link. But if I try to pull it up from my Watchlist or my Contributions, I get "File not found". After an hour or so, that problem will disappear. I know, because it's happened before. Something delayed in how a new file shows on the Watchlist or Contributions before it can actually be accessed. Strange stuff, but it's not a new happening.— Maile (talk) 21:16, 1 April 2014 (UTC) And true to what I just said, it has now cleared itself and is pulling up fine. — Maile (talk) 21:19, 1 April 2014 (UTC)[reply]
If it's not a fake error for April Fools' Day too, that error is unrelated to the one on Σ's user page and should be moved to a separate section. SiBr4 (talk) 21:25, 1 April 2014 (UTC)[reply]
Cirrus seems to handle the search fine so you can use that while this is happening. Add &srbackend=CirrusSearch to the results page (every time it loads) or switch on the BetaFeature. In the mean time I'll look into the error. NEverett (WMF) (talk) 21:30, 1 April 2014 (UTC)[reply]
I was just reproducing it at that time, at least ten times with various permutations of the words. I got it down to "to two of individual" with the same error message, and "to two of" with error "An error has occurred while searching: HTTP request timed out." All the errors take longer than a normal search, so I think this is timing out based on very general search terms. (If I had to take a wild guess I'd suspect the generic error happens when a subset of the search comes back with an HTTP request timed out error and then it tries to add another word to those results???) Wnt (talk) 21:38, 1 April 2014 (UTC)[reply]
Got it back. Looks like I turned on Cirrus and that "fixed" it for me. I found the log for it but it isn't helpful in diagnosing it other then to tell me that it happens every few seconds mostly on enwiki. It seems to be "confined" to searches outside the MAIN namespace. NEverett (WMF) (talk) 21:57, 1 April 2014 (UTC)[reply]
Is there an easy to find page with instructions on specifically what to copy to a talk page to get automatic archiving started? Am extremely confused and can't find a clear answer. Hopeful thanks in advance! --LT910001 (talk) 10:20, 2 April 2014 (UTC)[reply]
Would someone be kind to look into the Valls Cabinet article and see what's wrong with the formatting since "References" pops up in the middle of a table instead of at the bottom where it as customary is inserted. Regards, Iselilja (talk) 11:05, 2 April 2014 (UTC)[reply]
wikimedia.org or filed under the "Security" product in Bugzilla.
. For (2), (3), and (5), I see what you see. But (6) looks just like (3). If anything, the discrepancy in width I see between the ones and the nines is a bit greater, even in supposedly "tabular" form: The Georgia nines are 11% wider than the ones in your screen shot, but 22% wider on my display. That's true on both the left and the right.
Done You're right, the name parameter was wrong, so the edit link didn't work correctly. I fixed it. VanIsaacWScont 12:28, 30 March 2014 (UTC)
Resolved