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]
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]
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'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]
Another thing which would be great: Lua linter warning about globals other than built-ins (mw, table, ipairs, etc.), just like JSHint can do. Though this would probably require changes to Ace itself, and maybe even the underlying Lua parser. — Keφr14:02, 2 April 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]
The problem was that, with your edit, Val no longer produced the formatting seen at MOS:NUM. This had been a problem earlier, so I added a warning to the MOS that Val wouldn't actually produce what we recommend. Then we agreed to adjust Val, and I was able to remove the warning from the MOS. With your latest edit, we would have needed a warning again. The font we use at MOS:NUM is not important, but mixing lining and old style is like using camel case in a word that's not supposed to have it.
However, whatever you just did, you didn't just revert yourself. You are now forcing the display in all transclusions of Val, perhaps because of one of your changes at MediaWiki:Common.css? Using a set format for examples is one thing, overriding everyone's format choices across WP is another. Please stop messing with the formatting until there's a consensus to change. Until we can figure out how to handle the extremely minor issue this is intended to address, I'm removing the digits class, so that Val can accommodate user preferences as Gaps, SU, E, and other number templates do.
Here's my suggestion for a solution I hope everyone can be happy with:
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]
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.[2] 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. [3][4]
VisualEditor news
Blocked users now see the same messages in VisualEditor as in the wikitext editor. [5][6]
The search box for re-using a reference in VisualEditor is now cleared after each use. [7]
New links on sub-pages no longer point to the wrong location in VisualEditor. [8]
VisualEditor's media dialog no longer breaks when opening some types of images. [9]
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. [10]
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. [11]
Deleting a version of a file or a version of its description page will soon be shown differently in the logs. [12]
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]
Actually it's not a right to left mark; that's ‏ , but this is ‮ (U+202d to terminate). (For example) See Bi-directional text. As you can see from the example, I'm still a little hazy on how to control where the RTL text turns up. Wnt (talk) 15:15, 2 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]
I mean, it has a cause. The error is in custom code on top of Lucene that I've not delved into too much that does extra in memory caching of stuff like the article length. I took that as a hint and tried restarting the effected nodes. I waited "a while" between the two node but it still caused the rest of the system to become overloaded, dropping a bunch of requests presumably until caches warmed up enough that requests could be serviced in a timely manor. It also didn't fix the problem. I traced it down to one image's search record (File:American_dead_buna_beach.png) being corrupt (or something) so I did a null edit on the image. I'm not sure if that was required the old search system rebuilds the entire index every few days and doesn't react to edits at all. But I did it just in case something was busted about the revision. Given that my tinkering already caused a brownout across all namespaces, I'm inclined to wait until the index is rebuilt on its own, probably in a day or two. If that doesn't fix it then maybe more surgery. Or maybe make Cirrus the default for searches outside the main namespace. That'd be a bit drastic at this point but at least it doesn't crash and my tools for debugging it are infinitely better.NEverett (WMF) (talk) 14:21, 2 April 2014 (UTC)[reply]
Use interwiki links in Mediawiki interface messages?
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]
The easiest way is to tell us exactly how you want your talk page archived, and someone I'm sure would happily give you a snippit of code to use (or do it for you). So, some questions:
How do you want it archived?
Archive sections that are marked as {{Resolved}} or {{Done}}?
At some interval of time after the last post to the section?
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]
Would it be possible/desirable to create a gadget which would detect if a user opens a page (in edit mode), copies its contents and then closes the edit window? In this situation it could remind the user that he should give credits to the authors if he uses the copied material in some other place. It is relatively common to see users copying e.g. English Wikipedia's templates to other wikis, or translating articles, etc... without linking to the original pages. Helder.wiki15:19, 2 April 2014 (UTC)[reply]
I'd say it's not desirable to add code for all users (an opt-in gadget wouldn't apply) for such a narrow case. Pestering users won't change enough to be worthwhile. We aren't about to solve the problem of people plagiarizing Wikipedia, and it's obvious enough when people are copying, especially if it's to another MediaWiki-based wiki where the edit history is visible. If you see an unattributed use of your own template code or article text, feel free to make your own complaints or even your own DMCA letters—if they're not following the license, you're well within your rights to do so. If it's not your own content, then just pointing out how easy it is to satisfy the license is often enough to encourage compliance—I've done that myself a couple of times. {{Nihiltres|talk|edits}}15:34, 2 April 2014 (UTC)[reply]
Our only defense against the NSA making records of what users are doing is not to collect information in the first place. This kind of stuff that the user thinks of as his own private affair (hitting control/command-C) should stay that way, if we have anything to say about it. Wnt (talk) 20:35, 2 April 2014 (UTC)[reply]
Indeed. A good example of this is that we don't log what users search at all. A real example of the consequences of this is that CirrusSearch in MediaWiki will never be as rich in features as Google; for example, adding a "popular searches" feature was on the table, but then we realised we'd have to log what people are searching and we're not happy with that. We're okay with that tradeoff if it's being made to safeguard the privacy of our users. The feature proposed here has similar concerns as it's essentially a keylogger, which makes the proposal untenable. --Dan Garry, Wikimedia Foundation (talk) 21:10, 2 April 2014 (UTC)[reply]
If it's client-side (JS) and the data is never sent anywhere, what's the problem? I agree it should not be added, but I do not understand your reasoning. πr2 (t • c) 02:32, 3 April 2014 (UTC)[reply]
I usually leave Javascript off, so it wouldn't work then; and I have to say, the nag notice about leaving a page while editing it is already a nuisance. Adding another if you copy text... would be worse. And I'd worry that somehow the information could still end up becoming available over the internet, for instance if the notice affected the nature or timing of any subsequent upload(s)/download(s) from the server. Wnt (talk) 17:02, 3 April 2014 (UTC)[reply]
Wikipedia and Commons file upload broken
It appears that both Wikipedia and Commons refuse to allow file uploads with similar names. For example, if a poor-quality file named blah.jpg exits, and I want to upload an SVG equivalent of better quality called blah.svg, none of the dialogs permits the file to be uploaded, even though the name is clearly different. The system tells me that a file by that name already exists, yet when I try to access the file named blah.svg, it isn't there, either on Wikipedia or on Commons. As recently as a few weeks ago, there was no issue in using the same base file name, as long as the file name extension wasn't the same and the file type was different. In some cases the the original file name is poorly chosen and it is desirable to give the vector replacement file a different name, but in other cases forcing the user to change the base name is simply chicanery. The way it originally worked, the dialog would simply warn the user that a file with a chosen name already existed, but it wouldn't absolutely prevent the user from uploading it. This bug needs to be fixed ASAP. — QuicksilverT@02:31, 3 April 2014 (UTC)[reply]
to confirm, if you upload via special:upload (not upload wizard) and check the ignore all warnings box, does it work? There is an open bug about not working with upwiz, but it should currently work with old upload form when ignoring warnings. Bawolff (talk) 21:38, 3 April 2014 (UTC)[reply]
Category:HDS different on Wikidata
There are currently 340 articles in Category:HDS different on Wikidata, which doesn't exist. If anyone knows of an easy way to determine where it is generated, and whether it is useful in any way, then we can see whether it needs creation (and hiding) or removal. And a small trout for the editor adding some maintenance category to a template without creating it. Fram (talk) 07:20, 3 April 2014 (UTC)[reply]
Thanks. Seems to be the work of User:Docu. The proliferation of tracking categories, even hidden, is something that probably needs to be looked at. What's the point of this category? Our article on Aadorf has 5 different HDS because it covers sub-municipalities sa well; other languages do this differently. Is this a problem? Still, it isn't as silly probably as Category:Commons category with page title same as on Wikidata, a category hidden on 4,500 subcategories and 71,000 pages to tell us that nothing is wrong and, like the category states, nothing needs to be done for these articles. Then why track it? Created by User:Legoktm, should probably be deleted as a waste of resources. Could be wores, we could also have Category:Commons category with local link same as on Wikidata, which would have some 180,000 subcategories and 160,000 pages. Oh, wait... Fram (talk) 08:20, 3 April 2014 (UTC)[reply]
I read a report from a logged out user (an IP address) recently that he could see hidden categories, and I have just logged out and can confirm this. This is unwanted behaviour. Is this already being logged (Bugzilla?) and solved? Fram (talk) 08:25, 3 April 2014 (UTC)[reply]
I don't think it's a bug. See WP:HIDDENCAT 'Notice that "hidden" parent categories are never in fact hidden on category pages (although they are listed separately).', which was added with this edit - more than five years ago. --Redrose64 (talk) 10:24, 3 April 2014 (UTC)[reply]
It is noted (thanks, hadn't seen that), but I do believe it is a bug. I see no reason why hidden cats should be shown to logged out users when on categories, but not when on articles. Fram (talk) 10:31, 3 April 2014 (UTC)[reply]
My post was a reply to your "it would be nice if somebody could create a bug report in the Bugzilla bug tracker by following the instructions ". I assumed that was obvious because a) it was the only post you made here, and b) I explicitly referred to Bugzilla. Apparently not though... So, for clarity: @AKlapper (WMF): why don't you create the bugzilla report yourself, instead of hoping that "somebody" here would do it? You have access to and supposedly some knowledge of Bugzilla, and are now aware of the situation... Fram (talk) 12:24, 4 April 2014 (UTC)[reply]
Strange. Why would anyone who can't or doesn't want to see hidden cats on articles, want to navigate hidden cats in categories? The request doesn't make sense to me. Fram (talk) 11:00, 3 April 2014 (UTC)[reply]
Because otherwise they can end up at pages where there is basically no content and no links out except for the page furnature on the left hand side and top of the screen. Stuartyeates (talk) 19:39, 3 April 2014 (UTC)[reply]
Examples? I don't believe we should have any non-hidden categories which are only categorized in hidden categories, that doesn't make any sense. I have never noticed such a thing, does this scenario really happen? Fram (talk) 08:31, 4 April 2014 (UTC)[reply]
Page move from article space to the new Draft space should not create redirect
Move creates redirects automatically even when they're illegal, like moving an article to the draft namespace. If should notice this and not create them. Otherwise you end up with the situation like Sara shahmohammadi. Stuartyeates (talk) 09:15, 3 April 2014 (UTC)[reply]
Yeah, it's not ideal. Having said that, you can just tag the redirect with {{db-r2}} and an admin will come along and delete it shortly. Black Kite (talk) 10:08, 3 April 2014 (UTC)[reply]
Draft is not special. Any non-admin move from mainspace to another namespace will leave a redirect, and I think it should continue to do so. It would be very odd if a single move namespace combination main-draft would omit the redirect. The redirect is helpful to spot and track bad moves including vandalism. A move without leaving a redirect is not added to the page history (since the page is deleted). It's added to the log and seen when you click a red link, but if a new page is created at the same title then you have to click "View logs for this page" in the page history to discover the move. Most users expect they only have to view the page history, and some move vandals would probably learn to take advantage of this. PrimeHunter (talk) 12:46, 3 April 2014 (UTC)[reply]
Do you mean that it should leave a redirect until an admin can check and delete it (which is fine by me), or forever? The usual meaning of a move to Draft (or user space or the like) is that the article is, for some reason, not ready for the mainspace. Leaving the redirect removes this, a slinks from other articles to this page will lead people from the mainspace to the draft space without them even noticing this probably. If we consider a page not to be readu to be in the mainspace, we shouldn't link it as if it is still a part of it. Yes, this will make it slightly harder to spot bad moves, but we shuold ase our policies on normal usage, not on incorrect uses. Fram (talk) 14:05, 3 April 2014 (UTC)[reply]
I agree with Prime and we do need to consider deliberate malpractice. There is a risk to any cross-namespace move in that it can be (and sometimes is) used to "vanish" an article. Although the redirect leaves a record that this has happened, the perpetrator can request deletion of the cross-namespace redirect and a careless admin can perform the deletion leaving very slight trace of the missing article. Not having a redirect in the first place adds to this risk. Thincat (talk) 14:15, 3 April 2014 (UTC)[reply]
I think it's good to keep these redirects. It tells future editors that the article already exists (if someone were to try to create a new one on the same subject; duplicates happen all the time at AFC), it keeps any pre-move template/messages working, and it makes sure that anyone who'd seen it originally in the draft space has an easy way to find it again. I think they're especially important when the move to the mainspace results in a slightly different name (e.g., not plural or different capitalization). WhatamIdoing (talk) 17:31, 3 April 2014 (UTC)[reply]
A talkpage that is a redirectA talk page that only contains templates or is empty
copied from the Help desk, with small change of my own words, 14:30, 3 April 2014 (UTC)
Hello, when the word Talk of the talk page tab of an article is blue, I often click on it to see if there are any disagreements about the content of the article. I am used to do this as well when using Wikipedia to learn something, not only when editing.
On the English Wikipedia however, many talk pages only consist of a template with information about ratings, Wikiprojects, etc. I am not interested in those templates, so this causes many times a disappointment about unnecessary page loading. I once read that other people sharing this feeling made some gadget or so which changes the colour of 'Talk' in these cases. So there is not only red (when there is no talk page) and blue but also a third colour (green for example), for template-only 'Talk' pages. The word Talk only being blue when there is really talk.
I forgot to bookmark the place where I read this and now I can't find it any-more. Does anybody know about this?
But this is a good opportunity to remind you that all the fonts are scheduled to change (for people using the default/Vector skin, which is most of us) in about an hour. WhatamIdoing (talk) 17:34, 3 April 2014 (UTC)[reply]
Arrgghh!!! Well 1/2 Arrrgghh, anyway!! I like the new font. It's in line with research that I read a while back that Calibri (and its near relatives) are the best online/computer screen fonts. BUT, BUT, the difference between regular print/script and LINKS is hard to see. VERY HARD. I know I'm shouting, but I think this is a BIG DEAL. Tapered (talk) 09:20, 4 April 2014 (UTC)[reply]
Font size and style
What happened to the font? Suddenly, everything's a little bigger, as if I'd accidentally zoomed in with Internet Explorer, but the browser zoom is 100% just like normal. Page titles and section titles, including "Font size and style" here, are suddenly Times New Roman or another serif font, not the old sans serif font. I've looked at lots of pages, and it's all the same. 2001:18E8:2:28CA:F000:0:0:CB89 (talk) 19:22, 3 April 2014 (UTC)[reply]
Came here to complain about the same thing. Why have all article titles been replaced with a serif font? Not only is this inconsistent with the conventional online/Internet practice of all-sans-serif text (which is the convention by which Wikipedia has long adhered), this is also the EXACT OPPOSITE of standard print practice (sans serif for headlines, serif for text), and seems to have been arbitrarily imposed upon the community without any wider consensus (and don't say, "it's been in beta for a while" -- only a very, very small percentage of the wider community participated in the beta). At the least, can someone provide an example line of CSS on how to get the old article title font back? —Lowellian (reply) 19:32, 3 April 2014 (UTC)[reply]
Web is not the same as print, so the sans-serif headers/serif text does not necessarily apply to the web. Wikipedia also abandoned serif-only long ago; all remaining skins use sans-serif only. How about giving it 24 hours? — Edokter (talk) — 19:40, 3 April 2014 (UTC)[reply]
You said "all remaining skins use sans-serif only". That's not true and EXACTLY what we're complaining about: why have the titles and headings been replaced with serif text when the rest of the site uses sans-serif text? —Lowellian (reply) 20:08, 3 April 2014 (UTC)[reply]
I did see the "changing typeface" notice beforehand, but I didn't think it would look like this...holy crap! this is ugly and cartoonish. Thank goodness for the .css script above.--William ThweattTalkContribs19:51, 3 April 2014 (UTC)[reply]
Can we get an opt-in gadget for users who want to go back to the old vector style? This would be better than having lots of forks of the proposed CSS... Helder.wiki20:26, 3 April 2014 (UTC)[reply]
I just noticed this. It is a bit...strange. Mostly I was just wondering if my eyes were okay. I mean it's not -bad-, but...don't fix what ain't broke :P TangoFett (talk) 19:58, 3 April 2014 (UTC)[reply]
NOT easier to read. Not wide enough, to sharp, to thin, and it takes much more energy to read and concentrate. Makes it more difficult to concentrate on the text and read it. Hafspajen (talk) 20:01, 3 April 2014 (UTC)[reply]
Yeah, I'm still on monobook and thus this doesn't affect me but I've noticed the change as well on other computers. Infoboxes don't look pretty good with this new font style IMO. Connormah (talk) 20:19, 3 April 2014 (UTC)[reply]
Adding that code to vector it cames out Code that you insert on this page could contain malicious content capable of compromising your account. If you are unsure whether code you are adding to this page is safe, you can ask at the appropriate village pump. The code will be executed when previewing this page. eh, sad. Hafspajen (talk) 20:21, 3 April 2014 (UTC)[reply]
When discussion has ended, remove this tag and it will be removed from the list. If this page is on additional lists, they will be noted below.
Support changing back to original font
I encourage anyone complaining to create a screenshot of what it looks like for you, put that online and report your operating system and browser. That makes it much more likely that problems get dealt with. —TheDJ (talk • contribs)
I second this. I will personally make sure any bugs with the choice of fonts get dealt with. The problem with fonts is they look different depending on your operating system, browser and what fonts are installed on your system. It's possible one of the fonts is simply not rendering how it should on your display. Please include a screenshot, your browser and your operating system and I'm confident we will discover weird edge cases that can easily be resolved. Jdlrobson (talk) 05:45, 4 April 2014 (UTC)[reply]
As was already said, if it ain't broke.... Matty.007
Note that link doesn't actually show what you see. To show us what you see, you'll need to take a screenshot and upload the image somewhere (that somewhere can even be here). Anomie⚔13:37, 4 April 2014 (UTC)[reply]
I agree with the if it ain't broke, don't fix it rationale above. The new font is indeed much harder to read and more straining to the eye than the old appearance. Please reverse this change. -- ToshioYamaguchi20:28, 3 April 2014 (UTC)[reply]
It looks like the bold font is not loaded, and the italic font is not loaded. This causes faux-bold and faux-italics. Especially the faux-bold does not look good, see the bold "e". Also the normal "f". It creates a very busy, jagged and off-looking page. (Chrome + Windows = screenshot) Ahappylittletree (talk) 20:33, 3 April 2014 (UTC)[reply]
The old font was legible, simple and clean. The new one is harsh on the eyes and the spacing makes it rather difficult to read. I have had to tinker with my settings to be able to comfortably read more than a few lines at a time. If this font was used in a book (for example), there is no way it could be put on the market at nobody would be able to read it. The same standards of legibility should apply for a major website. This isn't some idiot's personal site from 1996 - this is a significant online resource and it should be presented with as much simplicity as possible. OwnBrand (talk) 20:37, 3 April 2014 (UTC)[reply]
Until I saw this thread, I thought someone had been playing with the font settings and screwed something up. Now it turns out this is actually by design? Wow. This needs to be reversed, quickly; it's embarrassing!—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); April 3, 2014; 20:42 (UTC)
So, it's not a late April Fools joke? - why do we have to endure these things? - no doubt someone will claim it was "consulted" about - hidden away somewhere where nobody looks. Arjayay (talk) 20:51, 3 April 2014 (UTC)[reply]
I also thought something was wrong with my browser. It evokes the bare-HTML style of the early Web, but without the readability. What's next, frames? It looks like Citizendium with less professional titles. It's simply hideous. Not that the Foundation gives a crap what we think.... Lagrange61321:00, 3 April 2014 (UTC)[reply]
Absolutely. To reiterate points that I made earlier, not only are the new titles/headings inconsistent with the conventional online/Internet practice of all-sans-serif text (which is the convention by which Wikipedia has long adhered), this is also the EXACT OPPOSITE of standard print practice (sans serif for headlines, serif for text), and seems to have been arbitrarily imposed upon the community without any wider consensus. —Lowellian (reply) 21:05, 3 April 2014 (UTC)[reply]
Hi Lowellian. To address a couple points... you bring up normal standards of sans vs. serif in print or Web. There are differences between the two, as you note, but the reasoning for the serif headers is really clearly articulated in the Signpost and the extensive FAQ about the changes. On the point about wider consensus: this change was beta tested on an opt-in basis by thousands of editors. Over the last five months, we've been collecting feedback (100+ discussion threads, for instance) and substantially changed what's released today based on editor feedback across wikis. Steven Walling (WMF) • talk21:16, 3 April 2014 (UTC)[reply]
I had assumed that someone had screwed up the font settings accidentally and it would be fixed within the hour. When I found out it was deliberate, I immediately put Kephir's CSS fixes into my vector.css. The serif headings in particular are absolutely horrendous. (I don't care if other websites have done it before successfully—I don't like it in this specific instance with this specific choice of fonts.) And no, I was not notified of the impending change, because they didn't run one of those top-of-the-page banners like they do for policy changes. "Thousands of editors" is a drop in the bucket compared to the total number of Wikipedia users. « Aaron Rotenberg « Talk « 21:37, 3 April 2014 (UTC)[reply]
The change has been available as a beta feature for a few months now. We've done multiple blog posts and informed mailing lists about this. Do you have ideas how else to do this? Vibhabamba (talk) 22:06, 3 April 2014 (UTC)[reply]
I don't use beta features, I don't read the Wikimedia blogs regularly, and I don't subscribe to mailing lists. Like I said, though, I do pay attention to more "push"-style notifications, including talk page notifications and the top banner. I know that getting people notified about changes is a persistent problem; almost every sitewide change (including ones I like personally) draws a stream of "I wasn't informed!" complaints like this. What I'd really like is a less obtrusive form of notification than the top banner that still allows almost every Wikipedia user who might be interested to be notified about and participate in upcoming changes before they occur. Something like a sidebar with community news headlines, on by default but with easy opt-out for people who don't want to read it? « Aaron Rotenberg « Talk « 22:19, 3 April 2014 (UTC)[reply]
Also, just to further clarify: the reason I don't pay attention to any of the things you mentioned is that they are all opt-in. Many more people would get notified if we had a notification system that was opt-out, without being too annoying. « Aaron Rotenberg « Talk « 22:25, 3 April 2014 (UTC)[reply]
Aaron, thanks for the feedback. Do you think you might have tried the beta if there were notifications about new beta releases? We updated the beta feature several times, and I think many people missed that because there weren't push-style notifications related to each update. Steven Walling (WMF) • talk23:07, 3 April 2014 (UTC)[reply]
I absolutely would have tried the beta if I was notified that a sitewide typography change was being considered, and I would probably have given (much less vitriolic!) feedback. Also, thank you Edokter for adding the opt-out gadget! « Aaron Rotenberg « Talk « 23:34, 3 April 2014 (UTC)[reply]
@Steven Walling (WMF): Err, push notifications for every iteration of every beta feature would be awful, and would lead to most people opting out of or ignoring the flood of notifications that would result (e.g. banner blindness). But a push notification that this was going to be enabled by default, along with updating the beta feature to show what the change would actually look like without extra changes, would have been much more helpful. I recall this advice was given to you before this rollout, too, but was apparently ignored. Anomie⚔13:38, 4 April 2014 (UTC)[reply]
Objectively? That's hard. Though: Arimo was updated less than a year ago with "improved hinting", so it already needed an update to improve legibility before this. Also see the screens posted (not every OS or browser renders this font without legibility problems) Ahappylittletree (talk) 22:36, 3 April 2014 (UTC)[reply]
Readability was certainly better with the old design. Now the text often seems somehow blurry to me and lacks the previous clarity. Gestumblindi (talk) 21:53, 3 April 2014 (UTC)[reply]
Actually, I agree with that revert. I'm one who has a negative reaction to change in general (and this in particular on those wikis where I haven't been using Monobook), but I don't agree that admins should be overriding it in the site-wide CSS for everyone. Creating a gadget for people to opt out is a much better plan. Anomie⚔13:44, 4 April 2014 (UTC)[reply]
I'm somewhat torn... I like the changes to the titles and headers, but the body text is to thin and I am having all I can do to read it. That being said, I support reversion of this change back to what it was. If you want to release a new Vector2 skin with this other font set, that is fine and I'm sure would cause the least headaches. You can even change it to site default for all I care... — {{U|Technical 13}}(t • e • c)22:36, 3 April 2014 (UTC)[reply]
Yes, absolutely awful. On default zoom the letters are too squat and far apart, zoom in one level and the lines are practically on top of each other. Completely pointless and self-indulgent change for change's sake. Apologies for half-copied text from Talk:Main Page, which is where the vast majority of Wikipedia readers - i.e. those that don't edit - will have heard about this. --77.102.114.99 (talk) 22:44, 3 April 2014 (UTC)[reply]
Whatever the merits (?) of this new font, it is downright rude to just drop it on us without warning. That the "mob" here is angry is entirely attributable to yet another botched rollout. ~ J. Johnson (JJ) (talk) 22:49, 3 April 2014 (UTC)[reply]
Regarding "without warning"... There has been a watchlist notice for several days before this change happened, I posted on this Village Pump days before it happened, and there were two articles in the Signpost about it. Pretty much the only other things we could have done would be to either use a banner or to message all editors directly. Do you think we should have done that? Steven Walling (WMF) • talk23:04, 3 April 2014 (UTC)[reply]
I think that the WMF did a better job with this rollout than with the VE rollout, so there is evidence of learning there. I think that with this project, and much more so with VE, there was a lack of interim notifications that said "Beta 2.0 of the foobar has been released. Please come try it and provide feedback." With VE, and again with the typo refresh, I tried it when it was first announced, saw that it needed a TON of work, and turned it off. As far as I remember, the next Watchlist notification (which is probably the best way to get frequent editors' attention without being obtrusive) was a few days ago. Additional interim notifications may be helpful. – Jonesey95 (talk) 23:19, 3 April 2014 (UTC)[reply]
Please either change it back, or make this "new" setting another skin that we can choose (in addition to the previous settings), and preferably NOT the default skin. Steel1943 (talk) 23:09, 3 April 2014 (UTC)[reply]
I agree with this. Please add the old Vector as a selectable theme in preferences. I don't mind if this is the new default, but I'd just like to select the previous Vector (as Vector-old?) and not have to come up with a CSS fix that fixes every little change while making sure it doesn't have unintentional side effects (because of using !important to override changes, etc). The Son of Man (talk) 23:40, 3 April 2014 (UTC)[reply]
I have the gadget enabled for now, but it doesn't revert everything and it uses Javascript. I have JS enabled most of the time, but sometimes I have it off (when coming from a site with obnoxious scripts, for example) and so I still end up being hit with the new changes. Adding a new skin that's just the same exact Vector as a few days ago shouldn't be that hard and would give everyone who doesn't like the new changes a quick, simple fix. The Son of Man (talk) 00:22, 4 April 2014 (UTC)[reply]
I initially liked the article font (not so much the serif font used for the titles), but after seeing how terrible bold/italics look...no. I'm changing my vote. ProtossPylon23:24, 3 April 2014 (UTC)[reply]
New font sucks. Unreadable on my display. (As a rule, condensed fonts should never be used for general purpose text! If the advantages outweighed the disadvantages, "condensed" would be the "standard", and "standard" would be "expanded", don'tcha think?) Utterly dumbfounded that this could pass any sort of committee review. Not that "you" care, but the site looks amateurish as hell, now. Succinctly: it just looks like someone made a mistake. Hopefully this ridiculous change will be reverted and soon. (And privileges for making changes of this nature should be revoked for whomever is responsible, as they have demonstrated BEYOND-ABYSMAL judgement in this matter.)BlackmailedIntoRegistering (talk) 23:36, 3 April 2014 (UTC)[reply]
It looks horrible. (And from other users' screenshots it looks like I had it better than some, as the measures I have already taken to block self-indulgent typographical tomfoolery on the web in general prevented the fancy fonts from being used.) I have applied User:Kephir/vector.css and now it is back to normal. Thanks, Kephir!
As has been said many times above: If it ain't broke, don't fix it. There was nothing wrong with the old style. This new style is far too widely spaced and is consequently harder to read. It also looks like a Peter and Jane book. My immediate thought when I first saw it was that the CSS had somehow become corrupted in loading. It does not look like an intentional change; it looks like a bug.
And it does not wash to bang on about "it was tested on thousands of editors, an insignificant percentage of the millions who use wikipedia" or "it was announced months ago in a locked filing cabinet in a disused lavatory with a sign on the door saying Beware of the Leopard." It is plain from previous comments that I am far from the only one who had not the faintest notion it was going to happen. "Did you see the Signpost..." The what? I never even knew that existed until I saw the above link. Same goes for all the other "obvious" places it was announced. As I said, I initially thought it was a bug. I only found out what was going on by googling wikipedia css changes. These announcement platforms may be "obvious" to those who implement the changes but they are entirely obscure to Joe Bloggs users like me. (Some users have mentioned the "top banner"; I vaguely remember that, but only vaguely, because I blocked it a long long time ago for getting in my face and being a pain in the neck.) It is well known that users of complex systems by and large only learn about the bits they need to do whatever it is they want to do, so it should be no surprise that people treat wikipedia in this way too.
Registered users at least would be more effectively notified by sending an email, but there appears to be no option to receive such emails.
There are multiple ways of getting e-mail notifications about changes like this, such as subscribing to a WMF mailing list or the WMF blog via RSS, but I don't know of any that only include upcoming potential changes and not a lot of other noise. I can sympathize with wanting to block the top banner, since it's usually very obtrusive. That's why I was arguing for a more subtle sitewide notification system above. « Aaron Rotenberg « Talk « 23:54, 3 April 2014 (UTC)[reply]
Change back as accessibility for those with visual problems has been lowered - the opposite of what we should be doing - also multiple fonts on the same page is not user friendly. I have used Preferences → Gadgets → Vector classic typography (use only sans-serif in Vector skin) but many others will not be aware of the new option nor will non registered readers. -- Moxy (talk) 00:13, 4 April 2014 (UTC)[reply]
The old font was a beautiful pixel font. This makes it very sharp and easy to read. The new font, for me at least, is heavily anti-aliased, making it look out of focus. My eyes hurt when trying to read it. That's an objective criticism for you, and I don't really see how anyone can claim a heavily anti-aliased font is better than a pixel font at small font sizes. --Muzer (talk) 00:17, 4 April 2014 (UTC)[reply]
Different situations at different PC's. If it ain't broke, don't break it. At one it made the body very difficult to read, a narrow font. For anybody who is on the edge, this makes it unreadable.North8000 (talk) 00:52, 4 April 2014 (UTC)[reply]
WP:BRD You were bold, we don't like it, so revert and let the discussions commence - then both sides can hold their heads up high and agree that; there was inadequate discussion, a lack of information for us to kn ow this was happening, no consultation with editors who had not taken part (14k out of several million is indeed NOT a large enough sample size), that MediaWiki is not our boss, and that it works for us - this is not an oligarchy yet (as far as I know) Chaosdruid (talk) 01:09, 4 April 2014 (UTC)[reply]
Text readability is diminished with a larger font, and its typeface looks less encyclopedic. Readers who have trouble reading Wikipedia can zoom their browsers in at 110% to produce the same effect instead. CR4ZE (t • c) 01:26, 4 April 2014 (UTC)[reply]
Another dreadful change. Just dreadful. Is the WMF's agenda now to force people to create accounts in order to get access to legible versions of Wikipedia articles? The new body text looks to me like what happened in a library I volunteered at a few years back, when somebody set a batch of new widescreen monitors to the wrong resolution. A few years back I was lucky enough to sit in on a presentation by Stephen L. Carter about education, who said (roughly) that the typography designers have been coming up with since at least the turn of the millennium may look nice, but in the long term, both in print and on screen, has proved to be less readable and, even worse, leads to weaker long-term memory retention of the content. That's not what we should want here. Hullaballoo Wolfowitz (talk) 01:27, 4 April 2014 (UTC)[reply]
Seriously. I spent a good five minutes twiddling with browser settings, because it did not even occur to me that someone would do this on purpose. This is the en.wikipedia village pump; can we please change the local default back to the original settings while WMF works their stuff out? VQuakr (talk) 02:40, 4 April 2014 (UTC)[reply]
I personally don't like it, and think the old font was perfectly fine. However, it does not go without saying that I strongly believe the developers are not getting the respect they deserve from our community. I think many of the above comments are failing to assume good faith on the foundation's part. They are not doing anything along the lines of holding projects hostage.--Jasper Deng(talk)03:19, 4 April 2014 (UTC)[reply]
Fully agree. I strongly support changing it back. It looks absolutely terrible. I actually spend quite a lot of time on Wikipedia and I had no clue this was even being considered (granted I only work on editing the site, not reading every single technical debate/idea/change/etc). It's very unpleasant to read, like physically unpleasant. And from what I can gather, there was no real endeavor at altering users to the potential change (such as a site wide notice, like when they're asking for donations) which I find a rude - best of intentions I know, but still. Coinmanj (talk) 03:30, 4 April 2014 (UTC)[reply]
I don't care about the actual font as much as I care about the font size. Sure, bigger font should be an option for those who want or need it. Forcing it on all of us without an opt-out other than a gadget is reprehensible behavior from any organization. The bigger font causes many problems for me; most importantly, it makes columned displays nearly impossible to read on my screen (1280x800) due to how narrow the columns must be. This is a huge issue for us users with small monitors who use Wikipedia both to read and edit. That being said, although I don't care about the font itself as much, it still seems to be completely arbitrary and now much harder to read and navigate than it was. I echo the above posters who say that this is obviously not an improvement. I see absolutely no possible way that this new font could improve browsing experience for anyone, including the print-disabled; as for the size issue, that should be an option anyways in preferences, even without this typography "refresh". Tl;dr though; change the font back to the original for readability purposes and make an option to change font size. That should please everybody, I think. StringTheory11 (t • c) 04:07, 4 April 2014 (UTC)[reply]
You may be interested then in the fact that fixed numbers of columns have recently been deprecated in {{reflist}}, in favor of columns based on the font size and screen space available. See that template's talk page for discussion. Anomie⚔13:53, 4 April 2014 (UTC)[reply]
The original font/size was more compact, more attractive, more "encyclopedic" dare I say. Articles now appear larger and I believe will scare off readers. Image captions now bleed into other sections. It's just a terrible idea. Also I echo the comments above that the new font is literally painful to read. - HappyWaldo (talk) 04:54, 4 April 2014 (UTC)[reply]
Support changing it back. As a former Web designer, I saw right away why so many users are complaining. The new CSS font stack SHOULD NOT HAVE listed Helvetica ahead of Arial for sans-serif body text. Any seasoned Adobe user or Web designer knows that Adobe apps always attempt to install Adobe fonts, including Helvetica, which render with very poor hinting and kerning at any size below 20px when put through the Windows ClearType rasterizer. This issue has been widely known since the mid-1990s; I remember this was a huge problem in Web design even back in the days of Windows GDI and dial-up modems. There are many blog posts out there on this issue, such as this one. And everyone installs Adobe Reader nowadays because so many corporate, government, and nonprofit sites use Acrobat to publish reports and data. Take a look at screenshots of Adobe Helvetica 10px and 12px as shipped with Reader as rendered by Windows ClearType in Windows Internet Explorer or Google Chrome, and it'll become very clear why half the Internet is screaming that Wikipedia went crazy ugly all of a sudden. Interesting how the new CSS stack looks okay in Firefox, probably because they use their own Azure rendering engine with subpixel rendering that has its own interesting way of rendering Helvetica. --Coolcaesar (talk) 07:08, 4 April 2014 (UTC)[reply]
As noted below, I stand corrected, this is HP's problem (Hewlett-Packard Helvetica version 1.3), not Adobe's. But either way, because HP has such a huge portion of the market share for printers, WP needs to adapt to the fact that HP's widely deployed version of Helvetica isn't hinted correctly. --Coolcaesar (talk) 13:15, 4 April 2014 (UTC)[reply]
Support changing it back. The new font is too big for me, so I had to scale down font size on my computer to be able to read comfortably. Hoevever, this causes problem for me when I go into edit mode where I find the text difficult to read. There should be some options about fonts, font size etc. Regards, Iselilja (talk) 07:25, 4 April 2014 (UTC) I have now been helped by the opt-out option though; so thanks for that. Iselilja (talk) 07:54, 4 April 2014 (UTC)[reply]
It seems the WMF is not willing to learn anything from all the disasters the produced within the last years (image filter, VE, ATF), they don't ask the community ether a changement is appreciated. While serifes in longer texts might be easier to read in titles they're doing the contrary, they make it harder, and having tw different fonts is ugly. Then the font is much lighter, more gray, it makes it very difficult to read for me. Obviously they forgot on people with glasses. Last but not least, as a partly Wikinewsian, I observe that much more article titles now break (titles of Wikinews articles tend to be much longer then in Wikipedia). Not good. It seems the changement wasn't a thoroughly thought-through decision. Please revert back soon. --Matthiasb (talk) 07:27, 4 April 2014 (UTC)[reply]
My main issue is that the new font size causes layout disaster to all templates/tables (e.g. WP:RDT) which are susceptible to increased font size. If one wants larger text, they can use their browser's zoom in function which posts smaller problem to the article layout. -- Sameboat - 同舟 (talk) 07:44, 4 April 2014 (UTC)[reply]
Chances are that they were broken for some readers anyway, since the "old font" was just "whatever font your browser is configured to use when asked to use any generic sans-serif font". Anomie⚔13:59, 4 April 2014 (UTC)[reply]
Please change it back. There is too much spacing on the titles/headers and it looks TERRIBLE. -- — Preceding unsigned comment added by 216.116.9.47 (talk • contribs)
I support changing back. The new font is not heavy enough and I (subjectively) find it much, much harder to read. It also looks quite unprofessional in my opinion. Moreover, on science page with formulas, there's a heavy clash between the new font and the font used in the formulas. If it ain't broke... Can we just revert and then have the new style as an option? Ollivier (talk) 09:32, 4 April 2014 (UTC)[reply]
I guess I could get used to it, and sometimes change is good. But in this case I do find it harder to read and personally prefer the old. Robvanvee11:00, 4 April 2014 (UTC)[reply]
This new font is an absolute eyesore and VERY hard to read, I start squinting as soon as the page loads. I'm seriously done editing on wikipedia if it stays. This is what it looks to me in Windows XP and the newest Firefox version (notice all the fs being randomly fat). --Feuerrabe (talk) 11:11, 4 April 2014 (UTC)[reply]
I do not see how this change increases legibility or aesthetics of Wikipedia pages. Everything is bold now and it looks like crap (I use the Vector theme). I find this superfluous change highly disturbuing and unprofessional and would go even so far as to demand a ban from Wikipedia for life for whoever made this change. ♆ CUSH ♆11:19, 4 April 2014 (UTC)[reply]
The new font is really hard to read. Anyway, editors can get away with scripts if they wish to, but what about our readers? Was there any feedback (the sort of Article feedback tool or surveys, not the kind of discussions on hidden talk pages) from ip users conducted? How can we know what the readers feel? It will be bad if they have to live with a wikipedia they don't like. If there has not been any feedback I think it is very important to conduct a survey. Fauzan✆ talk✉ email12:17, 4 April 2014 (UTC)[reply]
Restore: This new style is worse than the old one. I didn't see any need for a change. Also serifs for headings is a big no-no. Please change it back.Destruktor5000 (talk) 12:49, 4 April 2014 (UTC) Edit: Readability has also deteriorated. The lower bows of lower-case "a" in titles is so thin, it looks like a printer has run out of ink. See here: Win 7 & IE 10.Destruktor5000 (talk) 13:22, 4 April 2014 (UTC)[reply]
I was in the middle of working on an article and all of a sudden the font changed. I thought "wow, what did I do accidentally to turn everything into such a mess?" It took me a while to realise that it was a site wide change and no accident, somebody actually thought this was a good idea. What was wrong with the way it was before? Look how ridiculous a book title as the title of an article looks now -Martyrs of Palestine - it 's like an olde tyme embroidery sampler done by an old lady in 1840. Why did they just drop this change on everyone all of a sudden without giving anyone a chance to comment?Smeat75 (talk) 12:58, 4 April 2014 (UTC)[reply]
I haven't many contributions in this wiki but I have more 9 400 in french WP and I have SUL. Because this presentation is in WP-fr too, I can observe problems. Indeed, although the title is good, the body of article is in character who gives an impression of vagueness. --Gratus (talk) 13:04, 4 April 2014 (UTC)[reply]
Restore fonts: (edit conflict) (edit conflict) These Frankenfonts are so bizarre, with serif header titles joining the underline hr rule bar, or the reverse with arial headers at "*" bullets, while replies are Times New Roman or such. The peculiar fonts should be kept a user choice in each user's vector.css page. -Wikid7713:09, 4 April 2014 (UTC)[reply]
The new typeface looks horrible and is very hard to read (see screenshot to the right). --SelfishSeahorse (talk) 14:40, 4 April 2014 (UTC)[reply]Excerpt from the homepage of the German Wikipedia on 2014-04-04 to demonstrate problems with the new typeface (Microsoft Internet Explorer 9 on Windows 7)
Restore and have a vote before making this permanent! It looks awful (see my screenshot, Chrome, Windows 7; I have font smoothing switched off to improve performance, which makes it look especially bad, but was fine for the old layout), should have been raised before, and any problems with the old font were a problem with the generic san-serif displayed by web browsers, and should be addressed to them not patched up by us. ‑‑xensyriaT14:47, 4 April 2014 (UTC)[reply]
Please restore. I'm just a random viewer of wikipedia. I do not edit, nor do I want to register on the site just so I can use gadgets and css changes to restore the font to something readable. The proposed workarounds and opt-outs to fix a blunder in design is missing the point. The body font is too narrow and the vertical lines are too closely spaced. This makes it difficult to scan. It is heavily anti-aliased which leads to a sense that the text is 'blurry'. Those are objective issues. Like many here, I thought that this was an April Fools joke because the changes are so awful that I literally thought it was a joke. That a site such as wikipedia (which I love and easily spend an hour on per day) made such a huge mistake and changed to a font that literally hurts my eyes to read boggles my mind. — Preceding unsigned comment added by 76.226.162.220 (talk) 15:08, 4 April 2014 (UTC)[reply]
Restore. I agree with above, I have no registered username, but please ask the community before making things permanent. I'm not exaggerating: this really hurts my eyes. I'm using Firefox on Windows 7, looks similar to the Chrome screenshot above. Let's hope it will change, I can't just add a script to every computer I use Wikipedia on... I'm not saying change it bad, but firstly ask (poll on front page even), secondly test out different fonts and lastly, better be sure consensus is the change should be done before just making it permanent.93.125.198.182 (talk) 15:17, 4 April 2014 (UTC)[reply]
Oppose changing back to original font
Oppose poll Because polls of angry mobs don't give useful statistics, and only those unhappy tend to show up on locations like this in situations like this. —TheDJ (talk • contribs) 20:29, 3 April 2014 (UTC)[reply]
Comment - It is not angry mobs, but it is people's opinions. Shouldn't we listen to what people want to say? It is something that affects each and everyone of us, actually. Hafspajen (talk) 03:28, 4 April 2014 (UTC)[reply]
Conditional oppose. I like the new font, but the new title font needs to go. I almost threw up in my mouth when I saw that big ugly serif font juxtaposed against everything else. ProtossPylon20:31, 3 April 2014 (UTC)[reply]
Oppose poll this feature went through a huge discussion process. If people weren't involved they should make sure they get more involved in future. I worry reverting this change will result in nothing ever changing in Wikipedia and a loss of faith in the beta features process, no innovation and will ruin morale of all those involved in the discussion process. Also the change from my perspective is beautiful. Jdlrobson (talk) 21:20, 3 April 2014 (UTC)[reply]
I missed the discussion on our non-English Wikipedia. As of right now this font is causing me accessibility issues (I have enough trouble reading the text to stop reading and to stop editing). I love redesigns, and beauty is often a matter of taste, but this typography is causing me problems and is not too usable. Ahappylittletree (talk) 21:33, 3 April 2014 (UTC)[reply]
I work on putting content into articles and creating new articles on WP, nobody got my attention to tell me or ask my opinion of this impending change, you did not do a good job of getting that news to everybody, you should have put one of those banners that comes up across everybody's watchlist, that's the only way I see such things. I worry reverting this change will result in nothing ever changing in Wikipedia - why should things change for change's sake? a loss of faith in the beta features process I don't even know what that is, but whoever put this change through ought to have faith lost in them no innovation and will ruin morale of all those involved in the discussion process - there is nothing good about "innovation", ie messing around with things that don't need messing around with, just for itself. Apparently you are saying there is a project on WP which is devoted to thinking up "innovations" for stuff that is just fine the way it is and they will have their feelings hurt if this change is rejected. Tough. Also the change from my perspective is beautiful. the change from my perspective sucks.Smeat75 (talk) 13:12, 4 April 2014 (UTC)[reply]
I strongly oppose reverting the changes. I'm not saying I am blindly supportive of all the changes, but the overall effect is to have a consistent font scheme, especially across different systems. This is a much better situation than the one preceding it. If people take issue with the particulars, they are free to adjust them personally via their personal vector.css pages. {{Nihiltres|talk|edits}}21:56, 3 April 2014 (UTC)[reply]
Oppose poll Too much impassioned prattle here because the questions users are addressing in this forum are too arcane for them to fully grasp. The really interesting feedback lies not in opinions users express on launch day, but in their behavior over time. Deploy, measure, improve, repeat. Agile, y'know? 76.109.141.132 (talk) 22:08, 3 April 2014 (UTC)[reply]
Oppose It was a little weird at first (I had my font set to the quite small Calibri before) but having used the beta for a week or so it has grown on me. I do think the slightly increased size and leading is more readable once you get used to it. the wub"?!"22:39, 3 April 2014 (UTC)[reply]
Oppose Beta was extensive. Lots of notice was given to roll-out. The new default does what it advertises in the way of readability. Win for the developers. Saffron Blaze (talk) 22:54, 3 April 2014 (UTC)[reply]
Oppose We need the site to look better and we need to start accepting more creative answers and get professional design help doing so. And in doing so, perhaps we gain more diversity in editors the process. Jooojay (talk) — Preceding undated comment added 23:08, 3 April 2014 (UTC)[reply]
Oppose: Honestly, I prefer the new layout, and with the gadget to turn it back to the old font if you want, I see no reason to switch away from here. I know, I know, WP:ILIKEIT isn't a valid argument, but I don't know how else to put it. Supernerd11 :D Firemind ^_^ Pokedex00:07, 4 April 2014 (UTC)[reply]
I think the deployment of the new typography changes was well handled and for the better. But what I really want to say is that this poll has a problem with selection bias. Anyone who likes this change, or is indifferent, is far less likely to head to VPT and comment than anyone who dislikes the change. (That's what TheDJ is saying, I think.) — This, that and the other (talk)00:14, 4 April 2014 (UTC)[reply]
The same Wikiluddites show up anytime any change is ever made. The more I read the comments of the people who want to change this back, the more convinced I am WMF made the right decision in the first place. --Jayron3201:46, 4 April 2014 (UTC)[reply]
Per TheDJ. This is silly. Although I hate serif fonts and think the change should be reverted, I loathe making software decisions by mob rule. ^demon[omg plz]01:52, 4 April 2014 (UTC)[reply]
Per others. Not a good reason for mob rule. Also, I still use Monobrook because most of Vector sucks. This change isn't one of them, and I sort of which I had it by default on Monobrook. Resolute02:04, 4 April 2014 (UTC)[reply]
I have been trying out the new fonts in beta since the Signpost article came out and discovered I am able to reduce my zoom from 125 % to 110 % so there's an obvious improvement in readability for the weak of eye. Less zoom means that more of the article fits on the page, which is good. On my set-up (Toshiba laptop running Vista) it works better in Firefox than in Chrome. -- Diannaa (talk) 02:22, 4 April 2014 (UTC)[reply]
Interesting. I had just the opposite experience: my font is smaller and narrower and thereby less readable. I was using Verdana, a screen font specifically designed for screen readability, and it worked great on my Firefox/Mac combination. The new font (I have been unable to identify it; I copied a section of text into Word and changed it to Helvetica Neue, Helvetica, and Arial without finding a match) is smaller, much narrower, and aliased. I suspect that some of the different results that people are reporting are due to font interactions such as mine. I have enabled the "opt-out" gadget for now, and everything is fine again. I look forward to a more refined version of this typography refresh that addresses problems such as the one I experienced. (I do like the new spacing between lines; the old mix-and-match spacing always bothered me.) – Jonesey95 (talk) 03:07, 4 April 2014 (UTC)[reply]
That was my experience too when using Chrome. At 125% zoom the letters are clunky and horrible, and at 110% they are too small - illegible. But I got it to work in Firefox. Chrome is a better browser though for several reasons (handles scripts better, does searches better), so now that there's a gadget available for "classic Vector" I will be opting out of this change, at least for now. -- Diannaa (talk) 03:23, 4 April 2014 (UTC)[reply]
Thanks for the link. It will probably help others diagnose their font issues. I am using Liberation Sans, which I didn't know I had installed. It's pretty, but Verdana is much more suitable for screen reading, at least with my OS and browser combination. – Jonesey95 (talk) 14:49, 4 April 2014 (UTC)[reply]
Oppose These changes are tested on millions of users and based on sound, common typographic principles. Well-tested changes shouldn't be reversed because of a vocal minority's taste, or a knee-jerk opposition to WMF making changes. MAssaf (talk) 02:28, 4 April 2014 (UTC)[reply]
Oppose This work has been trialed for 6 months, creates consistency between desktop and mobile. The size change is very critical for non latin scripts. Vibhabamba (talk) 04:34, 4 April 2014 (UTC)[reply]
Looks good and very readable! Plus: it improves the overall look and feel, since it reuses the same font as used in the Wikipedia Logotype! Good job!--86.103.213.5 (talk) 08:22, 4 April 2014 (UTC)[reply]
This does not look horrible on my system. Oppose changing back, typography refresh is as easy to turn off as any other feature. It has a feedback channel.
If you would like new features (visual editor, typography refresh) to be easier to turn off, design and propose your thing for them all.
If you don't like current font, please use the typography refresh beta channel, not a village pump. Do proper multi-project outreach to gather comprehensive view on your subject put constructively.
Admittedly I don't appreciate you abusing the bulk of people who don't like new features through mailing lists@DGarry (WMF): for example. Okay, many won't like. They shouldn't complain here, they can give feedback at the feature's feedback channel.
Admittedly I don't appreciate it being removed from the beta tab. It provides easy access to disable and share feedback.
I like the new font for body text. The headings still look a little weird to me, but that will pass and I understand the rationale for using serif font there. older ≠ wiser12:25, 4 April 2014 (UTC)[reply]
Per TheDJ. Personally, I find I have to give myself some time to overcome the "Oh no, change!" reaction. For example, I recently uninstalled some fonts and installed others on my system which resulted in Gmail using a different font for me (Arimo rather than Arial). It took a while, but I've stopped being distracted by the "different" look. For the same reason, I haven't gone and changed my fonts or skin on mediawiki.org or other wikis where I've been using Vector to see how it goes after a few weeks before forming an opinion. Anomie⚔14:07, 4 April 2014 (UTC)[reply]
Discussion
I have been using this typography since it started being tested in beta and I have come to like it. My eyesight is not so good and I find it helps. Of course, it should not be aimed specifically for people like me but it is an aspect worth considering. I personally did not favour removing numbers from the sections in the table of contents (and I fed back on this) but I am still seeing numbers here so maybe that change was reverted. So, for me, I appreciate the change. Thincat (talk) 20:24, 3 April 2014 (UTC)[reply]
Well, "people like you" (and soon me too, maybe) were part of the reason, apparently, so that's a very valid comment. Drmies (talk) 20:31, 3 April 2014 (UTC)[reply]
There are obviously significant differences in perception or in the rendering between different systems because my eyesight is also not great and I find the new font harder to read, not easier. 109.147.187.61 (talk) 02:49, 4 April 2014 (UTC)[reply]
Hey Matty.007... I just wanted to address two things:
Regarding bugs, it is not possible for the font change to cause links to break. The code changes do not touch link behavior or styles at all. The link you mention in your draft seems to be working for me?
Have you checked out the Signpost piece about this? This change happened not just on English Wikipedia, but all versions of Wikipedia and other projects. It's been tested for five months, by more than 10,000 people here on this wiki alone. We had more than 100 discussion threads gathering feedback from the community across all wikis.
I think that when you take the great deal of discussion and iteration in to account, it feels a little hasty and contradicting WP:POLL to hold a straight-up vote when there was a long process based around consensus-building and testing by editors. Steven Walling (WMF) • talk20:29, 3 April 2014 (UTC)[reply]
But did you specifically test the most common scenario of all that I hinted at above? Specifically, a standard Windows system without any of the open-source craziness, but with Microsoft Office, Adobe Reader, and Internet Explorer installed. The vast majority of billions of barely computer-literate users out there still won't touch OpenOffice or LibreOffice with a ten-foot pole, and in the corporate world, most systems are rigorously locked down with Access Control Policies by understaffed, overworked IT departments who can barely keep MS Office running as is. Which means, if you specify Arimo, Liberation Sans, and Helvetica Neue, there is no way that more than a few percent of the WP user base is actually going to see those fonts. And then if you specify Helvetica before Arial on a Windows system running Adobe Reader (and keep in mind 75% of the computers out there run Windows), then Adobe Helvetica is what the vast majority of the WP user base is going to see by default, which looks absolutely hideous on Windows systems at less than 20 point, with or without ClearType turned on. That's a classic error and something most experienced Web designers learned to avoid back in the late 1990s, back when Acrobat was first taking off. There are screenshots all over the Web demonstrating how horrible Helvetica renders on most Windows systems at 10 or 12 point. I've added a screen capture to the right to illustrate the problem; if you had stress-tested the new CSS font stack from any FedEx Office or low-end public library system, the error should have been obvious. This whole debacle reminds me of my third favorite Bond film, Tomorrow Never Dies. Specifically, James Bond's words to Elliot Carver at the climax: "You forgot the first rule of mass media, Elliot! Give the people what they want!" --Coolcaesar (talk) 08:17, 4 April 2014 (UTC)[reply]
There are some mistaken assumptions I need to correct. 1) Adobe Reader hasn't come with a Helvetica (or substitute) for over 15 years now. If you see Helvetica on a stock Windows system, then something/someone else installed a bad Helvetica copy. It is safe to asume Windows does not have Helvetica, and is mapped to Arial. Helvetica is in the font stack to target Apple systems. 2) Default Windows installation since Vista have font smoothing enabled by default, just like ohter OSes, so i think we may asume that has become the default. Asuming there are no 'funky' fonts installed, the new font stack should show Arial. Those that do have Arimo/Liberation fonts (usually by way of OpenOffice), should see those fonts nicely rendered which font smoothing. Only with font smoothing disabled will you see problems, as non-Microsoft fonts are not optimized for display without smoothing. It is hardly worth the trouble optimizing fonts for pixel displays because they are rarely used anymore. Only the older MS fonts are optimized for that; their ClearType collection fonts (Calibri etc.) do not render well on pixel displays either. — Edokter (talk) — 12:05, 4 April 2014 (UTC)[reply]
Well, I stand corrected. Turns out it's not Adobe's fault, it's Hewlett-Packard's fault. I just manually traced this and it turns out the copy of Helvetica that's rendering locally is from the Hewlett-Packard screen font version of Helvetica, which is automatically installed by many (but not all) Hewlett-Packard printer drivers. (That would explain why this issue has been recurring for almost 20 years on a variety of Windows systems of all shapes and sizes, since Hewlett-Packard has the dominant market share for printers on the West Coast of the U.S., as in most areas of the world.) It's Hewlett-Packard Helvetica version 1.3, copyright 1992-1997. That version dates back to the dawn of the modern subpixel rendering age, which explains why the font hinting is so terrible. But the fact is that the Wikimedia Foundation has to adjust to what the majority of users have, which is HP printers and HP drivers, not the other way around. Telling people to change printers is not going to cut it. --Coolcaesar (talk) 13:01, 4 April 2014 (UTC)[reply]
And I almost forgot to add the most important point of all; WP is a nonprofit site competing for users' limited funds and attention, which means you need to always keep in mind what keeps readers happy on the largest percentage of systems. If WP stays with a stylesheet that is unreadable on about 65% of the systems out there (and most users are passive users who are too damn busy to figure out how to set up a WP account and customize WP's appearance), the Wikimedia Foundation can kiss its audience and donations goodbye. Which means EVERY major design change should be deliberately stress-tested on the most common plain vanilla, last-generation computer configurations out there (which I acknowledge is a pain in the neck). Beta testers aren't much help because most of them by definition live on the bleeding edge of technology. --Coolcaesar (talk) 08:46, 4 April 2014 (UTC)[reply]
I'm not one to complain about what goes on in changing the appearance of the site, and doing so most undoubtedly makes developers' jobs more stressful. But, I feel I must say I dislike the new font. It simply doesn't appear as clean. Now, I won't ask for it to be reverted simply because I don't like it. It would be nice, however, to have a gadget in "Preferences" to go back to the old font. That's just my two cents. Tyrol5[Talk]20:33, 3 April 2014 (UTC)[reply]
@Steven (WMF): Would a preference not be a possibility, not everyone has the same eyes and some text fonts impair/hurt more than others. For instance i find the new font to be worse for my eyesight than the original. Forcing one over an other isn't the best idea or practice in reality.BletheringScot21:09, 3 April 2014 (UTC)[reply]
I have an issue - I added the vector code to get the old font, but in the edit interface, I have some alternate font; is there a way to get the old editing window font too? GoPhightins!21:31, 3 April 2014 (UTC)[reply]
Hmm. The preferences related to the editing interface should not be changed at all. Can you hard refresh to clear your cache, and maybe share a screenshot with me? I will try to help debug. Steven Walling (WMF) • talk21:51, 3 April 2014 (UTC)[reply]
So Steven, about 8,000 editors on this wiki opted-in to try it, out of 48,283,984. That's roughly what, 0.017% of this wiki's users? Since you said it's been being tested for almost five months, I'm less inclined to base those stats on users active in the last month, but even if we do, 8,000 out of 121,641 (6.577%) isn't really that spectacular of a number either... — {{U|Technical 13}}(t • e • c)12:24, 4 April 2014 (UTC)[reply]
This is not only about webdesign, it is also about how the WMF treats Wikipedia users. We were not asked beforehand whether we would approve a different typography at all. It was tested in Beta status which means that the vast majority of users did not even learn about the changes coming up. I tried it out and switched beta typography off immediately because the TOC was completely unusable. The WMF will not succeed in imposing changes of this magnitude without a prior community consensus. We've been here when you tried to force users to work with the visual editor only, and failed. I suggest you switch back the serif headings to sans, and leave the rest as is now. Please think again. Thanks.--Aschmidt (talk) 21:59, 3 April 2014 (UTC)[reply]
I looked at the redesign rationale, and the screenshots there (coupled with the use of Helvetica as a fallback, which renders horribly on Windows) lead me to believe this redesign was done on a Mac or Linux. Chrome + Windows show all sorts of typography errors like faux bolding, different spacing, poor hinting, poor anti-aliasing and references hugging image-borders above them. See: Screenshot. Where can I contribute to get this fixed? The old situation on Linux + Firefox looks poor indeed, but could easily be handled by putting "nimbus sans l" in front of "arial". The same with "helvetica neue" for Mac. Ahappylittletree (talk) 22:10, 3 April 2014 (UTC)[reply]
Hey Ahappylittletree. The FAQ lists all the browsers and operating system combinations we tested this on. We did test the change on laptops with Windows and Chrome. Our developers do tend to either use Linux or OS X, but we always test on Windows since they're obviously very predominant among all Wikipedia users. Steven Walling (WMF) • talk22:47, 3 April 2014 (UTC)[reply]
Hi Steven Walling. I found the problem that is causing the font weirdness. To reproduce: Install Arimo 400. Do not install Arimo 700 (bold) or Arimo italics. This will cause the body text to render in Arimo and uses faux-bold or faux-italics for the rest. I don't see a cheap fix for this. My use case may be rare, but it is what it is, and really hampers legibility. Thanks, Ahappylittletree (talk) 23:25, 3 April 2014 (UTC)[reply]
@Steven Walling (WMF) Another unforeseen problem is users who installed Arimo before the "improved hinting"-update from May 2013. Windows 7 (standard no font-smoothing) may show these users something like this: Arimo beta on Windows 7 with smoothing off (BTW: Segoe may be a far better fallback than Helvetica, one being optimized for web, the other a print font that fares really badly on Windows) Ahappylittletree (talk) 00:34, 4 April 2014 (UTC)[reply]
Two condions must be met for that to happen: 1) user must have turned off font-smoothing/ClearType, which is enabled by default since Vista, and 2) user must explicitly install Arimo, which is an exceptional situation in itself. Usually, people that do install fonts like Arimo know what they are doing and know how to make it display properly. — Edokter (talk) — 00:38, 4 April 2014 (UTC)[reply]
1) Yes, I once turned it off (it is a valid configuration option, though I don't know exact stats). I also still use the classic accessibility theme. Should I change my settings so I can read Wikipedia again? 2) Arimo is not loaded from Google Webfonts right? So if installing Arimo is an exceptional situation, why even include it? To install all variants of Arimo or to install only a single variant shouldn't be so different (the latter causing problems). Installing a font is easy. Figuring out why Wikipedia won't display readable text almost a year later is a bit more difficult. Forcing me to install all variants, uninstall Arimo 400, or add a stylesheet to my user preferences, so I will see legible text only when I am logged in, is... not user-friendly. Once again, appreciate all the work, but also once again: I am not creating edge cases just to be a pain. This happened to be my use case. Ahappylittletree (talk) 01:06, 4 April 2014 (UTC)[reply]
Edit: I never explicitly installed Arimo 400. Arimo 400 (and only Arimo 400, no other variant) is installed by OpenOffice. So this may not be a rare use case at all. Ahappylittletree (talk) 01:24, 4 April 2014 (UTC)[reply]
If you have OpenOffice, you also have all variants of Liberation Sans, which are actually another version of Arimo. So if you have Liberation Sans, you can safely disable or remove Arimo. It may still render not so well, but free fonts were never designed with no-font-smoothing in mind. Only MS fonts (to their credit) have decent display quality without font-smooting, because they were specifically designed and hinted for grid-pixel displays. — Edokter (talk) — 01:42, 4 April 2014 (UTC)[reply]
We can perhaps continue this convo at my talk page? Wikipedia says: After 3.4 the GPL-licensed Liberation fonts were removed and replaced by the Apache-licensed ChromeOS fonts Arimo (sans serif), Tinos (serif) and Cousine (monospace). OpenOffice will also use the default fonts of the running operating system.. I really think that a fresh Windows 7 install with the latest OpenOffice will cause the exact problems I show in my screenshots. No manual installing fonts. No turning of Cleartype/font smoothing. [16][17]Ahappylittletree (talk) 02:00, 4 April 2014 (UTC)[reply]
Many people are automatically resistant to change in all its forms. I don't have a particular problem with this change, except that only page header and section header fonts seem to have been changed. Sub-sections still use the sans-serif font, which looks more than a little odd. I would have thought it would not be at all beyond the technical capabilities of the coders to have enabled a simple toggle in user preferences for serif/sans-serif in headings and/or indeed body text. Perhaps that could be considered as a future enhancement? regards, Lynbarn (talk) 23:28, 3 April 2014 (UTC)[reply]
Hello, I am a Opera user and it seems that the new appearance is not the same in Opera than with other browsers. Whereas in Firefox letters are tight, with Opera they are as round as the former fonts, but a bit bigger it seems. Moreover, whereas some headlines in Firefox tend to overlap (Main Page of French Wikipedia for instance), everything is fine in Opera. I don't know if this is worthy of note but anyway... Regards, Oie blanche (talk) 01:39, 4 April 2014 (UTC)[reply]
If you are using Windows and happen to have fonts from the Liberation family installed, the pages are going to look awful. I suggest you remove the Liberation fonts and you'll be left with the usual Arial text, just a tad larger than before. I think it looks good enough. Took me a while to figure that out! The CSS style sheets are a bit hard to read. 151.24.96.16 (talk) 02:55, 4 April 2014 (UTC) Valerio, user.[reply]
Given that the above vote is unlikely to bring the WMF to change anything, I still think it useful to see what the people this affects think about the change. Thanks, Matty.00709:29, 4 April 2014 (UTC)[reply]
I've already registered my discontent with this but in the constructive spirit of Wikipedia, I thought it was best for you to see for yourselves what my problem is. I am using Firefox and Windows 7. http://s22.postimg.org/u15674mz5/Hideous_Font1.png Incidentally, the screenshot looks smaller than actual size and actually looks a bit more balanced than the 'real' view on my screen but I still think it's very ugly and difficult to read. OwnBrand (talk) 10:59, 4 April 2014 (UTC)[reply]
Why was this not implemented as a completely new separate skin?
Are the developers all amnesiacs that they cannot remember the wars that break out every single time they change the default way that established users see and use WP? Give the noobs the "new improved better faster cooler" stuff and stop pissing off the hard core of established editors. Roger (Dodger67) (talk) 13:14, 4 April 2014 (UTC)[reply]
Future
¿Is this the future Wikipedia's screenshot —page 3—? If it is so, maybe the change of the typography is not a big deal... I mean, in comparation. Greetings from esWiki. Albertojuanse (talk) 21:56, 3 April 2014 (UTC)[reply]
Pissing crikey! "Meet Kim"? I would rather meet the sharp edge of a giant machete than corrode my eyeballs on that muck. Seriously, I thought Wikipedia was one of the last bastions of sanity, reason and information in a digital world that is becoming increasingly narcissistic and obsessed with the illusion of interactivity (i.e. to conceal the creeping anti-democratic impulses in western culture) but if that is the future of the internet, I will be returning to pen and paper. OwnBrand (talk) 23:45, 3 April 2014 (UTC)[reply]
FYI: Edit-war between German community and WMF on Typography refresh
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
FYI: Font refresh has been deactivated on German Wikipedia. Most users had complained about it and said they didn't like it.--Aschmidt (talk) 22:05, 3 April 2014 (UTC)[reply]
FYI2: WMF seeks a conflict with the German community. Steven Walling has reverted the deactivation of typography refresh. This is outrageous. I ask you to refrain from such action and to apologise to the German community. WMF has no right to change the typography of our project without seeking prior consensus.--Aschmidt (talk) 22:42, 3 April 2014 (UTC)[reply]
Aschmidt, not sure why'd you bring up German Wikipedia stuff on English Wikipedia? Anyway, I left DaB. (the admin involved) a note about it and said I was not interested in edit warring. Reverting someone's bold change once is not an edit war. It's a part of the normal BRD cycle. I asked DaB. to talk about it more and give people (including readers) a chance to try the changes for at least a few days. Steven Walling (WMF) • talk22:45, 3 April 2014 (UTC)[reply]
Actually its fairly enlightening that the WMF has to edit war to keep their poorly thought out product back in production. This reminds me of the VE disaster all over again. The WMF rolls out something that the local communities dont want, they ask for a reversal, the WMF says screw you, your having it if you want it or not, and eventually the community decides to make an end run and disable it via local css or js. Werieth (talk) 22:53, 3 April 2014 (UTC)[reply]
I don't really view them as the same. Local Vector CSS was made just for the purpose we're discussing: local overrides. I fully expect that some communities will tweak or change the styles over time. All I asked DaB. was to give it a chance, since we spent a lot of time trying to gather feedback and test it first. Steven Walling (WMF) • talk23:01, 3 April 2014 (UTC)[reply]
Steven, I bring this up here because this is where it belongs. I again ask you to refrain from such action. It is impolite, and you are not eligible to act like this on German Wikipedia. So would you please self-revert and apologise to German users?--Aschmidt (talk) 22:50, 3 April 2014 (UTC)[reply]
(edit conflict)Steven - Ermmm, not sure bringing up BRD helps your argument - the WMF made a bold change to the type face, DaB. reverted and so then it should have been discussed. What you've done is effectively BRRD. Now I think your argument of letting it run a few days probably has merit but relying on BRD to make your argument does not seem a good idea. Dpmuk (talk) 22:51, 3 April 2014 (UTC)[reply]
Oh, and I appreciate that the WMF really does seem to have made a proper attempt to get community input on this. I seem to have missed the notice about the testing so communication can possibly still get better (or I may have just been blind) but it does seem like you got comments from a good number of people. Hence while, from what I can see (I normally use monobook), I consider it a bad idea I think implementing it was quite reasonable. Dpmuk (talk) 22:55, 3 April 2014 (UTC)[reply]
Yeah I think the recent update was not really very bold. We took five months to test it, providing it on an opt-in basis to gather feedback from the ~14,000 people who opted to try the change. The change was made very after a lot of input from users across wikis and has changed a lot over time. We also have tried this out first with mobile readers, who represent about 20% of our pageviews every month. Steven Walling (WMF) • talk22:57, 3 April 2014 (UTC)[reply]
FYI: This is in the middle of the night European time, so you won't get much of a reaction until tomorrow. I'd like to add, however, that the WMF is about to lose its face. Again. And this makes me sad because we have already wasted our time and our energy on many conflicts like these over the past few years instead of working together on our common goals. Very sad to see that happen again. So, good night to San Francisco. We have a problem.--Aschmidt (talk) 23:06, 3 April 2014 (UTC)[reply]
This is reprehensible! It is bad enough that this has happened on the English Wikipedia but abusing the power of the English language website to make enormous changes on other languages' sites is truly disgusting. Although I am only a very small part of this website, I would like to apologise on the behalf of all English speaking people for our arrogance. This disgusts me too and I am sure you have the solidarity of many of our Anglophone editors. Additionally, as you can see from this page, there is far from a consensus on the use of this typeface on the English language Wikipedia and I very much doubt we have heard the end of this. If democracy has any value any more, I expect these changes to be quietly forgotten by those who run the website. Regards, OwnBrand (talk) 23:50, 3 April 2014 (UTC)[reply]
Hi OwnBrand. The "power of the English language website" doesn't really factor in. I can edit site CSS/JS globally as a member of Wikimedia Foundation technical staff. It is not related to local English Wikipedia elected admins. Local admin rights here do not extend to any other wikis, and permissions like that are separate for much the same reasons you talk about. Steven Walling (WMF) • talk00:01, 4 April 2014 (UTC)[reply]
Steven Walling (or any other WMF activist), please refrain from making any changes to the look of the German Wikipedia in advance of having got a consenus of the German Wikipedia community. The way of seeking a consensus is described in de:WP:Meinungsbilder, I am sure there are people in the WMF capable to translate it. Thanks. --Matthiasb (talk) 07:36, 4 April 2014 (UTC)[reply]
Stop it! All of you! I'm from German Wikipedia, I dislike most of Typography refreshs features but I totally agree with what Steven Walling did. DaB' changes to vector.css were a stupid solo action without any consent. Modifying global vector.css to "fix" things to one's personal likings is a no-go! There was plenty of discussion going on regarding typography refresh and everybody who cares had the possibility to at least voice his/her opinion. Most people that are complaining now didn't care. So for now accept the changes, look at them neutrally, decide what you might learn to like and what you will never be able to live with and discuss in a friendly manner. Anyway this is about the German Wikipedia, so it has no place here on English Wikipedia. Go home, calm down, and figure it out together there when you're ready! --Patrick87 (talk) 09:31, 4 April 2014 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Gadget to opt-out
Hey all. Thanks to Edokter, there is now a gadget under the Appearance section of gadget preferences. This will change back to the old sans-serif style in Vector, if you like. This should making opting out easier for anyone who wants to. Steven Walling (WMF) • talk23:11, 3 April 2014 (UTC)[reply]
Sorry for not advertising this, but I was qurious to see how badly people wanted such an option to go look for it (and I didn't want to seem unappriciative). This gadget reset some core changes like font family, size and color. Other changes such as line height and margins etc. are not reverted, becuase I think they are in fact beneficial. — Edokter (talk) — 23:41, 3 April 2014 (UTC)[reply]
May I get those line height and margins for my own personal CSS? I just enabled the gadget, but the spacing still looks hideous for me. Whisternefet23:52, 3 April 2014 (UTC)[reply]
Not sure how it's supposed to work, so i can't pinpoint what's wrong with it, but it is absolutely useless for me: it messes up the font size in my Monobook (while the description did say "in Vector skin", apparently there's no "only" before that, so it might affect other skins too...), and if i switch to Vector it doesn't actually change anything. -- Jokes Free4Me (talk) 01:03, 4 April 2014 (UTC)[reply]
Don't use this gadget under Monobook. The typography refresh does not apply to Monobook (only Vector, as does the gadget), so nothing should have changed for you. — Edokter (talk) — 01:06, 4 April 2014 (UTC)[reply]
I'm sorry guys, this shouldn't be an opt-out via gadget thing. As I said above, and I see others have said the same, feel free to create a new skin with this new look and set it as the wiki default (although some opposed that), but classic vector should stay classic vector and should not be changed like this. — {{U|Technical 13}}(t • e • c)00:21, 4 April 2014 (UTC)[reply]
Fully agreed - especially as the gadget creates its own problems:- the new fonts load and are visible before the gadget converts the fonts back, causing a delay and then a "jump" on the screen, which quickly brings on a headache and would give a migraine if I carried on using it. Arjayay (talk) 08:10, 4 April 2014 (UTC)[reply]
I am having the same problem with the gadget as Arjayay - a delay causing it to flick on the 'new' typography before flicking to the 'old version' - and it has very quickly given me a headache! Couldn't something along the lines of Technical 13's suggestion of setting up different skins be utilised? SagaciousPhil - Chat09:42, 4 April 2014 (UTC)[reply]
The problem with a large segment of the community immediately opting out of changes pushed down from WMF is that our experienced editors will always be seeing something different than new users. Over time, as the established editor base continues to opt-out of this, or that, helping new users with their experience becomes difficult because the helper and the helpee will see different things. –xenotalk13:26, 4 April 2014 (UTC)[reply]
No use whatsoever to those of us who don't edit and don't have accounts. (As it happens, I do have an account, but I no longer login into it.) A typical example of Wikicrats forgetting that Wikipedia editors are a tiny minority of Wikipedia users, and Wikipedia policy should have them in mind, not us. --93.152.83.69 (talk) 13:41, 4 April 2014 (UTC)[reply]
I'm amazed that this was implemented without an opt-out feature to restore Wikipedia to how it looked before already in place. But, however bad it looks to me, I don't want to change my display to be any more different than necessary to how the readers will see pages. Please make this feature opt-in, rather than force it on your users until they no longer complain. ‑‑xensyriaT15:00, 4 April 2014 (UTC)[reply]
How about all serif?
I know this is kind of radical — I'm certainly not expecting everyone to jump up and say "sure, let's do that!" but I'd just like to point out another option.
The reason I would personally like it is that there is an awkward conflict right now in technical articles with equations. Variable names are not so nice in sans fonts (hard to distinguish I from l, for example), and for that reason, things like the {{math}} template use serif. When these are mixed with sans fonts in running text, they look frankly appallingly bad, just vomitous (see e (mathematical constant) for an absolutely egregious example). For that reason, I oppose {{math}} in any article where it's not already established, but if we went to all serif, my objection would go away.
Now, as I say, I know it's kind of a radical suggestion, and I don't really expect everyone to say we should do this big change just for the benefit of articles with equations. However, if there were a constituency for it for other reasons, this is why I would join it. --Trovatore (talk) 00:13, 4 April 2014 (UTC)[reply]
How can you put aesthetics over legibility? You acknowledge that math in sans-serif is, by any definition, unreadable. Yet you will oppose the only method available (to editors) to remedy that illegibility. I just don't understand. — Edokter (talk) — 01:02, 4 April 2014 (UTC)[reply]
No, that's reading way too much into what I "acknowledge". Sans-serif for math is perfectly usable, with a restricted character set. Note that the de-facto standard for slide presentations in mathematics, the Beamer class, uses sans by default.
If you absolutely have to have "I" as a variable name (standard for a few things) then yeah, in that article, you might have to go with serif. But I see no reason at all to prefer e over e in running text, not if there isn't some other aspect of that article that requires one of the problematic characters. --Trovatore (talk) 01:07, 4 April 2014 (UTC)[reply]
Fwiw, I'm not sure why {{math}} exists - we already have <math> tags which do basically the same thing. Also fwiw wikipedia did originally use sans-serif at least if the so-called Nostalgia skin is an accurate reflection of the original appearance. (also I didn't realise you got an edit conflict when it was in another section...) Cathfolant (talk) 14:48, 4 April 2014 (UTC)[reply]
Cleartype?
Hopefully I'm putting this in the right place – without cleartype turned on (and using W7, FF28, 1680*1050 res), the new design is very difficult to read. I don't mean a simple "I don't like it" (which I admittedly don't, as the previous font was much easier to read without the cleartype feature), but most letters have a 'line width' of one pixel, while some are 'two pixels wide' and they almost look bold, e.g. vertical lines of both upper- and lowercase F, making for a messy text with seemingly randomly highlighted characters. Whatever happens to the new design, perhaps consider this issue as well. 89.176.87.169 (talk) 07:20, 4 April 2014 (UTC)[reply]
Seconded. See my screenshot for just how awful it is in Chrome, Windows 7 (I had no problems when san-serif was used). Please consider the effect this will have for all users. ‑‑xensyriaT15:04, 4 April 2014 (UTC)[reply]
Sidebar "Help" link broken
The "Help" link in the "Interaction" section of the left sidebar is broken; instead of jumping to a Wikipedia help page, it sends you off to a Mediawiki page. The corresponding link at Commons, "Help portal", is also broken. -- John of Reading (talk) 20:59, 3 April 2014 (UTC)[reply]
It points Here. It used to point to the Wikipedia help desk page, not Media Wiki. Same with Commons Help Portal,it points to that Media Wiki link, not the Commons help page. — Maile (talk) 21:41, 3 April 2014 (UTC)[reply]
The actual link is now mw:Special:MyLanguage/Help:Contents it used to be Help:Contents. One is local; the other isn't. The average very-newbie is going to be totally confused by being sent off to a page that has the same look and feel as Wikipedia but which is a completely different website. They might notice the yellow daisy instead of the puzzleball, but they'll probably think that it's still Wikipedia, and be unable to find the article that they're after. --Redrose64 (talk) 21:46, 3 April 2014 (UTC)[reply]
Right. That's Help's main page. It used to automatically go there. So you're saying it should no longer go there? I think it's easier for me to just bookmark the Help main page for myself.— Maile (talk) 22:07, 3 April 2014 (UTC)[reply]
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
The previous font size was perfectly fine as it was. Now, the new one is uncomfortable to read.
Different situations at different PC's. If it ain't broke, don't break it. At one it made the body very difficult to read, a narrow font. For anybody who is on the edge, this makes it unreadable. North8000 (talk) 23:49, 3 April 2014 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Extra scrolling
Is it just me, or is Wikipedia extra scrolly lately? I don't know if it's because of the new font or the fact that I'm temporarily stuck on IE 10, but now, whenever I scroll down to the bottom, I get an extra ~2 screen heights of blankness at the bottom. Any ideas? Supernerd11 :D Firemind ^_^ Pokedex00:14, 4 April 2014 (UTC)[reply]
There may be some technical explanation for this, but I don't know what it could be.
A few weeks ago, Deepak Chopra tweeted about a death threat in the Ralph Abraham article.[18] Responses to the tweet seem to acknowledge the vandalism, with one person posting a screenshot.[19] Someone else did a blog post about it.[20]
However, the only contemporaneous edits to the article were some vandalism by 71.119.92.56 four days prior to Chopra's tweet, which was immediately reverted by ClueBot.[21] Ah, but that just means the death threat was suppressed, right? That's what I had thought. However admins have told me that there are no suppressed edits in the Ralph Abraham article. I also know that 71.119.92.56's edits are in fact the death threats in question.
Now we shift to seemingly less probable explanations. Chopra was complaining about a non-vandalized article? And other people were too? The screenshots didn't have have the "old revision" tag on them, so people were using the latter part of an old diff to create screenshots? Well maybe, I guess, but here comes the monkey wrench: one screenshot was of the Google Knowledge Graph![22] You know, the thing that appears on the right when you type "Ralph Abraham" into Google.[23] Since ClueBot reverted the vandalism immediately, how the heck did Google pick it up? Just astoundingly unlucky timing? Perhaps there is a caching bug somewhere?
Resorting to other presumably less probable explanations: the vandal, having a freshly vandalized page, took the screenshots? The screenshots were faked? Multiple admins are lying about the page having no suppressed edits? There is an extra secret level of uber suppression that non-uber admins cannot see? I am somewhat kidding, but I'm still perplexed. vzaak05:04, 4 April 2014 (UTC)[reply]
You wrote "However admins have told me that there are no suppressed edits in the Ralph Abraham article." Which admins told you that, and where? Because that's not true. In the page history, there are 2 suppressed edits by User:71.119.92.56 from March 8, 2014. —Lowellian (reply) 06:28, 4 April 2014 (UTC)[reply]
If you want to split hairs about the differences between revdeletion and suppression, okay, then there's also your answer as to why some admins told you were there were no suppressed edits (because they weren't suppressed, they were revdeleted). In any case, you asked what happened to the vandalizing edits. They were revdeleted. Before they were revdeleted, the edits were cached, hence the screenshots. There's not much of a mystery here. —Lowellian (reply) 09:30, 4 April 2014 (UTC)[reply]
I appreciate that you are trying to help, but the distinction between suppression and revdeletion is a necessary one in my original post. Since the revdeleted edits were reverted immediately by ClueBot, and since people were complaining about vandalism four days after the vandalism was removed, I presumed there were suppressed edits that were invisible to me. It turns out it was a caching glitch instead. vzaak15:06, 4 April 2014 (UTC)[reply]
It was just incredibly unlucky timing, and the vandalized version probably sat around in the cache of the Wikipedia servers for a few days. Unregistered users always get the cached versions of pages where available. Graham8707:33, 4 April 2014 (UTC)[reply]
But articles are vandalized often. If the text in Google Knowledge Graph is updated as infrequently as every four days or more, then surely this problem would have been manifested, vociferously complained about, and fixed, by now? (I'm almost certain I've seen it update much much sooner; I suppose I can test it.) Another reason I was reluctant to accept the "incredibly unlucky" hypothesis is that it means the person taking the screenshot seems to be deceptive in apparently passing it off as the current screenshot. Though I agree the "incredibly unlucky" scenario seems to be more likely now. vzaak07:48, 4 April 2014 (UTC)[reply]
It's a deficiency in our caching system and not "incredibly unlucky". Google Knowledge Graph showed what IP's must have seen at Wikipedia for a long time. IP's often report seeing vandalized versions that were reverted within minutes long ago. Wikipedia's own caching does not happen at random times. Pages are usually cached right after an edit but some edits don't cause caching (I don't know why, limited resources are usually blamed for such things), so the probability of an IP seeing a vandalized version is not necessarily low just because the version was quickly fixed. PrimeHunter (talk) 10:20, 4 April 2014 (UTC)[reply]
Thanks for the explanation, I've wonderd why I see loads of OTRS tickets about vandalism that were fixed on Wiki hours before the ticket - now I know. Nthep (talk) 13:28, 4 April 2014 (UTC)[reply]
@PrimeHunter and Nthep: That sounds like Template:Bug. Something that should fix it will be deployed here on April 10; if you see the problem occurring with revisions after we get 1.23wmf21 here (see Special:Version to check the version of MediaWiki that is being used), please do comment on that bug. Anomie⚔14:25, 4 April 2014 (UTC)[reply]
Thanks, the caching glitch explanation is the only one I've seen that is consonant with all the evidence. vzaak15:06, 4 April 2014 (UTC)[reply]
Citation Excel File
Hello. I look here but I didn't find it. I want to make a citation for an excel file (is online), for a specific sheet. Is there any specific way? Xaris333 (talk) 05:18, 4 April 2014 (UTC)[reply]
{{cite web}} should work fine. Use |title= for a prose description of the file, |at= to indicate the sheet name, and |url= for the web address, including the http://. – Jonesey95 (talk) 06:31, 4 April 2014 (UTC)[reply]
If the information is on a particular row, column or cells, you can also use |at= for that - e.g. |at=Sheet 1, cells J20:L39 --Redrose64 (talk) 09:57, 4 April 2014 (UTC)[reply]
<ref>{{cite web |accessdate={{Subst:TODAY}} |title=Languages |work=Apache HTTP Server |agency=Ohloh |publisher= Black Duck Software |url=https://www.ohloh.net/p/apache/analyses/latest/languages_summary}}</ref>
{{Reflist}}
Does anyone know whether the X users have enabled this feature (in Beta features, accessible from the top right of your page) indicates the X "on enwiki", or the X "across all wikiversions"? I'm wondering because the high numbers of enabled users doesn't seem to correspond with the number of active editors, or the number of editors who use a feature on enwiki. For VisualEditor, it claims "29,074 users have enabled this feature." which is extremely unlikely to be correct for enwiki only, and which is very misleading otherwise because it is enabled by default for most other wikis, no becaues 29,000 people actually want and use it. Fram (talk) 13:00, 4 April 2014 (UTC)[reply]
As part of IEG project me and Ravid ziv wrote a user script similar to RefToolbar but for VisualEditor - it allows to easily add citations templates (Cite web/Cite book/Cite journal/Cite news). The scripts adds a "cite" option in toolbar, in which you can select a citation template, fill its parameters, and then it adds the template, within reference tag (<ref>) to article.
cite button
citation dialog (selecting template)
We think it can be very helpful for editors who use VisualEditor and makes it much easier to insert citations. To use the script add to your personal JS the following code:
{{subst:iusc|User:ערן/refToolbarVeLoader.js}}
We invite you to use and test it. You are welcome to suggest missing features or share other ideas that may improve the use of citations in VE (or a nice idea for icon ). Eran (talk) 14:55, 4 April 2014 (UTC)[reply]
Where do you want the feedback?
'month' is deprecated and will now give an error; 'date' now supports year, month year, season year and day month year/month day year. We are only keeping 'year' when a disambiguator is need for Harvard/shortened footnotes.
Unused parameters are added
Spacing around = is inconsistent (my preference is no space)
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
). Eran (talk) 14:55, 4 April 2014 (UTC)