# Wikipedia:Village pump (technical)

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

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

« Older discussions, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128
Centralized discussion
Proposals Discussions Recurring proposals

Note: inactive discussions, closed or not, should be archived.

I've configured phpMyAdmin so anyone can run SQL queries on their own. Enjoy! — Dispenser 00:04, 9 July 2014 (UTC)

Err, no. I've deleted the tool immediately; not only is phpMyAdmin not allowed on Tool Labs, but having it open to all is a very poor idea even if it weren't.

It would be a good idea to have a tool by which users not very familiar with SQL or Labs can request queries to be run, provided it has human supervision, but that was just begging for trouble. — MPelletier (WMF) (talk) 00:28, 9 July 2014 (UTC)

And why not? Its under FLOSS license and up to date. And views it has aren't privileged. Unlike Toolserver, Labs doesn't contain sensitive data. Now why would queries need human supervision, wouldn't the query killer take care of any stray queries? — Dispenser 00:59, 9 July 2014 (UTC)
Watched pages is generally an agreed upon 'not privileged' but also still sensitive to release information. If vandals from 4chan or other boards knew which pages were watched the least, they would be perfect targets.--v/r - TP 01:02, 9 July 2014 (UTC)
That's Toolserver, there's no watchlist table on labs. Plus we were listing unwatched pages for nearly two years without problems. — Dispenser 01:31, 9 July 2014 (UTC)
Because, amongst other things, phpMyAdmin is a security hole with secondary database features. Besides that, (and I'm sure Legal would add "more importantly") database access is contingent upon being a user of Labs and to have agreed to its terms of use. — MPelletier (WMF) (talk) 02:54, 9 July 2014 (UTC)
Its pretty much expected that tools will have security vulnerabilities which is reflected in Labs' architecture. And by using updated off-the-shelf software like phpMyAdmin (whose team takes security seriously) will be better than any custom solution. Finally, could you quote the relevant passage because I don't see it on Labs Terms of use. — Dispenser 03:42, 9 July 2014 (UTC)
I can think of all sorts of reasons why Joe Public shouldn't be let loose on a SQL command line. --Redrose64 (talk) 11:17, 9 July 2014 (UTC)
The user account separation does not allow modifying or deleting other databases. In fact, tables are unreadable unless the read permissions are set. — Dispenser 13:48, 9 July 2014 (UTC)

So I take it that all issues have been addressed and we can reinstate this incredibly useful tool? — Dispenser 15:47, 12 July 2014 (UTC)

• Implementation of phpMyAdmin at Labs is a great idea! I fully support it.--XXN (talk) 21:23, 15 July 2014 (UTC)
So can we re-instate this? — Dispenser 00:25, 17 July 2014 (UTC)
• No, you may not. As I've stated previously, access to the databases requires the user to be a registered wikitech user (and thus subject to the TOS); any tool that allows unsupervised queries into the database is not permitted, as it may severely impact database performance. (This should come as no surprise to you since the Toolserver also did not allow this for the same, obvious, reasons).

I would have though this obvious enough to go without saying, but I've added a point to the Tool Labs rules to reiterate common sense. — MPelletier (WMF) (talk) 15:11, 17 July 2014 (UTC)

So do these users need a Wikitech wiki account or shell account? Is OAuth ok? — Dispenser 14:58, 20 July 2014 (UTC)
• I oppose phpMyAdmin, being publicly available. Tool labs users have access to a table, not accessible in the dumps, which can easily be abused.—cyberpower ChatOnline 15:30, 20 July 2014 (UTC)
• I will however support it iff the security issues are resolved && access to the db is only allowed through the supplied username and password issued in the replica.my.cnf && nothing is logged. I also want to see a WMF staff member be listed as a maintainer, preferably Coren.—cyberpower ChatOnline 15:38, 20 July 2014 (UTC)

## Time for the semi-annual enlarging of thumbnail images

Bigger screens, both on desktops & laptop, as well as mobile device have left images on foundation wikis looking rather small these days.

Based on research from the Analytics group "There are 15580 instances logged across 393 wikis in log.PrefUpdate_5563398" to the preference that stores thumbnail default size. On english Wikipedia the current value is 220px for "default" sized thumbnail images, the size logged in and logged out users see if they haven't manually changed their preference. Of the ~15k users who have changes this preference the trend is to set the preference to a larger size, usually 300px as seen by the graph included in the bug for this issue eventually I'd love for us to move to responsively sized images, but perhaps thats a seperate discussion.

As proposed this would change the default value for "Thumbnail size" which would affect logged out users, and users who had never modified the value of "Thumbnail size" in preferences.

### Some points of clarification to questions that have come up

• Thumbnail size affects desktop and mobile, however MobileFrontend constrains images to the device width so a default greater than the device width will still look properly formatted
• Responsive/dynamically sized images are the eventual goal but that isn't the point of this discussion as there are unsolved technical challenges before this can be tackled
• This change will not affect the ability of logged in users to choose the thumbnail size they prefer
• This change will have no effect on users who have manually set their thumbnail size
• Due to the recent switch to have small screen devices like tablets redirect to the mobile formatted site, more users are seeing the mobile site on devices with larger screens than they historically have, feedback and bugs have been logged by these users complaining that the current default of 220px appears too small on these devices.
• This change has no effect on Mediaviewer
• Most logged in users make very few changes to settings in their user preferences, those who have changed thumbnail size have made it larger in almost 90% of cases, it is probably reasonable to assume this desire is present in readers but is not possible for them to do.
• This change would affect all readers

### Concerns

• Possible typographic layout issues on small screens (<800px wide)
• Large images could break mobile layout (be larger than the screen)
Resolved : MobileFrontend limits image width to the device width, so this change will not break mobile layout
• Performance issue due to more requests for larger images (investigating)
Resolved : Ops and platform recommend small to large site rollout to offset server load during thumbnail image generation
• Accessibility: larger images that cramp text can be difficult for readers with dyslexia - DrKiernan (talk) 20:12, 14 July 2014 (UTC)
Resolved : Larger images lead to shorter line lengths which studies have shown are easier on dyslexic readers - Jared Zimmerman (talk) 06:50, 15 July 2014

I'd like to close this discussion by Wednesday July 16 2014

Jared Zimmerman (talk) 19:35, 9 July 2014 (UTC)

### Proposal

Make foundation wikis and mediawiki software thumbnail style images use 300px (rather than current default of 220px used by most sites) size based on user data provided by Analytics Team.

### Discussion

• So, based on your graph, about 9K (~0.04%) editors have increased their thumbnail size to 300px. This hardly seems to be a trend to have larger thumbnails to me as it would then require the other 21,843,704 editors (~99.96%) to have to change their settings to restore the accepted 220px current size. — {{U|Technical 13}} (etc) 19:50, 9 July 2014 (UTC)
• That's hardly scientific. Most users don't change any settings. That says nothing about their preferences. —Designate (talk) 19:56, 9 July 2014 (UTC)
• Technical 13, Its a good point, but we don't have a great way of asking readers/logged out users for their opinion. To assume that users are "happy" with the default is a pretty big assumption, I think it would be safer to assume that most users are either unaware there is a preference to change this, they don't have an opinion about thumbnail images sizes. I don't feel comfortable saying that inaction by users is a sign that they are happy with the current state of things. We can however look to purposeful user actions (changing the preference) to show a trend toward preferring larger images. Jared Zimmerman (talk) 20:10, 9 July 2014 (UTC)
• I would wholeheartly support responsively sized images, but I can't support a change that only benefits less than 3% of users. I think that if users where unhappy about the size of thumbnails, they would either change the preference or they would ask at any one of the over a dozen different forums available for such a change to be made for them. In the interest of full disclosure, I am one of the 9,000 that has my thumbnail size set to 300px, yet I still oppose a change such as this currently because I see it as intrusive. Another thing that I would support in the mean time, is expanding the list to offer larger thumbnail sizes. Currently the list of available thumbnail sizes caps out at 300px, this leaves no room for expansion above that threshold. If there was a 360px and 480px option that was being utilized frequently, then I could perhaps support that 300px is a reasonable "average" size. As it stands, 300px is only reasonable as a max size. — {{U|Technical 13}} (etc) 20:21, 9 July 2014 (UTC)
• Technical 13, where are you getting the 3% number, this would benefit most readers. Readers don't have the option to increase the image size (short of making an account). As I said before if only a small subset of users have changed this preference from the default, I'd still argue that this is due to user not being aware of the preference even existing. I like your idea of adding new thumbnail sizes, and we can log that as a bug, but Ideally the bug to have responsive images would negate the need for having this setting at all. Jared Zimmerman (talk) 20:52, 9 July 2014 (UTC)
• And why do you think that "most readers" benefit from reducing the share of the smaller screen devoted to text? Unlike certain publications, Wikipedia is one where most readers actually come toit to read the articles rather than browse the pictures! The Big Bad Wolfowitz (aka Hullaballoo) (talk) 12:01, 12 July 2014 (UTC)
• Citation needed? Dubious–discuss? Or, more relevantly, how do you know that readers are here for the articles instead of the pictures? (Or, for that matter, for the external links, which some people have told me in person is the best part?)
It is always pleasant to assume that readers are all interested in reading every word of my brilliant prose. However, I have generally found that the assumption that I and the readers value the same things is invalid. But even if it were a valid assumption, I sometimes go to articles in search of an image myself, so at least some of them are here to browse the images. WhatamIdoing (talk) 16:12, 12 July 2014 (UTC)
• (edit conflict) Do you have any data to support it would benefit most readers? Based on my Google searches the majority of mobile devices still use a smaller screen size. Even if they are unaware of the preference and the ability to change it, they certainly should be familiar with the most fundamental concept of talk pages where they can complain (because that is the most likely form of a report if they were unaware they had some control). — {{U|Technical 13}} (etc) 21:03, 9 July 2014 (UTC)
• Technical 13, honestly I think its also a very generous to say that anonymous users (readers in this case) can find, and more specifically, participate in a talk page. Jared Zimmerman (talk) 04:21, 10 July 2014 (UTC)
• No one has actually suggested changing it to 300px. The discussion so far is just about enlarging it. What if it was only a moderate increase, like to 250px? Kaldari (talk) 20:48, 9 July 2014 (UTC)
• (edit conflict) I just did a search on Google, and it appears that the majority of current mobile devices have a screensize of <= 250px, so I would be fairly hesitant to think that is a good idea until we have more data on people that would use a higher size than that by adding at least a 360px tier. If that higher option was offered, and it was brought back to the community a few months later showing data that users are selecting these higher sizes, then I would support it. For now though, the current data and research on screen sizes indicates that 220px is appropriate. — {{U|Technical 13}} (etc) 21:03, 9 July 2014 (UTC)
• Technical 13, I don't know that that number is correct… this source makes it looks like 320px is on the low end for most mobile devices, I'm not sure where you'd find definitve info about this though. Jared Zimmerman (talk) 22:16, 9 July 2014 (UTC)
• Kaldari & Technical 13, I was actually suggesting 300px based on actual user data provided by Analytics. Jared Zimmerman (talk) 20:54, 9 July 2014 (UTC)
• Support. Gradual increase in screen resolution means the thumbnails are actually getting smaller, which is a disservice to people. A little inflation would be an improvement. —Designate (talk) 19:56, 9 July 2014 (UTC)
• I agree, but jumping right to the max size is too much inflation at this time. — {{U|Technical 13}} (etc) 20:21, 9 July 2014 (UTC)
• Support anyone who likes smaller thumbnails can always shrink them, can't see any harm in this. GimliDotNet (Speak to me,Stuff I've done) 20:07, 9 July 2014 (UTC)
• I can in the form of people with smaller screened devices being unable to load pages because the thumbnails are too large. — {{U|Technical 13}} (etc) 20:21, 9 July 2014 (UTC)
• Technical 13, It might be helpful if you can upload a screenshot of any technical issues you're having. We already have a bug that images on mobile are too small, if you're experience issues it would be great to learn more about that. — Preceding unsigned comment added by Jaredzimmerman (WMF) (talkcontribs) 20:52, 9 July 2014 (UTC)
• I've tried to download and run various screen grabbing and screenshot applications on my phone and they have all resulted in me having to factory restore my phone, so I'd rather not at this point. I will say that when I'm on my phone, I never intentionally use the mobile site because it just doesn't work most of the time and is way too limited for an editor of technical code (such as javascripts and templates). I use the desktop version of the page, and I've come across pages where the initial size of an image is forced at a higher pixel level than it would be if it was a thumbnail. Not only does it take a substantial amount of extra time to load the page, it covers the entire screen which is disorienting and I'm forced to have to zoom out and have to try and figure out where on the page I am. On the flip side, if the image is too small, it is harder to see and I have to zoom in, but it loads exceptionally fast and I'm not disoriented on page load. I can always click on the image to go to the file page and see it fullscreen. — {{U|Technical 13}} (etc) 21:14, 9 July 2014 (UTC)
• Technical 13, you shouldn't need 3rd party software, try this if you're on android or this if you're on an iphone to document the issue you're having — Preceding unsigned comment added by Jaredzimmerman (WMF) (talkcontribs) 22:10, 9 July 2014 (UTC)
• That's already a problem for people using the desktop site on a mobile device. Most articles these days have intro images set to 280px or 300px anyway. That's an edge case, problem, IMO. If you're using the mobile site (which is the default for all mobile devices and tablets), we limit the image max-width to the width of the device anyway, so it's not a problem. Kaldari (talk) 22:34, 9 July 2014 (UTC)
• Oppose: 220px is a size that works well at almost all reasonable screen-widths for reading (e.g. works perfect for approx. 1000 px width, is only slightly too small for ~ 1200 px width and is already slightly too large for ~ 800 px width. All widths above ~ 1200 px are nonsense from a typographic point of view anyway (Typography refresh even tried to fix the width at somewhere around 1000 px during the beta stages for this exact reason). Higher resolution displays therefore do not really mean "more space" but either better resolution for "zoomed" content (e.g. TVs) or the possibility to arrange multiple windows on one display.
If people really happen to think it makes sense to maximize their browser and use the full 1920 px (or higher) width of their display for non-zoomed content (and then claim the images where to small relatively to the page width) this is a problem of those individual users.
Last but not least think about a Wikipedia page printed in A4 or letter format (which results in something similar to 800 px screen width): Do you really think larger images would be a good idea here? Obvious answer to the rhetorical question: No! --Patrick87 (talk) 20:42, 9 July 2014 (UTC)
• 220px is a size that works well at almost all reasonable screen-widths for reading – not really, since the rise in popularity of tablets. Related bug: [1]. Keep in mind that tablets represent ~1 billion pageviews per month to all our projects, and growing... Maryana (WMF) (talk) 21:07, 9 July 2014 (UTC)
• Maryana based on what data do you come up with ~1 billion pageviews per month? I'm guessing the amount of pageviews per month from mobile devices with smaller screens such as cellphones are likely higher. Please just show the data. Thanks. — {{U|Technical 13}} (etc) 21:19, 9 July 2014 (UTC)
• For one thing the bug you linked is about mobile UI, so not really applicable to the topic here which I assumed was mainly about desktop UI. If another thumbnail size in mobile UI is needed it's pretty much independent of desktop UI I assume? For another thing the thumbnails in the bug report rather show how bad it looks if thumbnails grow too large: They occupy a line on their own but are not large enough to fill it. On everything that is not a "mobile device" in the broadest sense, thumbnails are supposed to be placed inline with text content which a larger thumbnail size will pretty much break. --Patrick87 (talk) 21:46, 9 July 2014 (UTC)
• Here is the monthly trendline for all mobile pageviews, and here is tablet's share of that. So 5 billion total mobile pageviews times 0.25 (the % of tablet pageviews from all mobile device pageviews) = roughly 1.25 billion. Maryana (WMF) (talk) 21:39, 9 July 2014 (UTC)
• Support, the easier is it to see the image's contents, the better. Let's not forget that the main purpose of images is not to look great in article flow but to give reders additional information. Considering this, please yes - let's do it. Max Semenik (talk) 20:58, 9 July 2014 (UTC)
• Support. I'm not sure if 300px is the right number, but it's definitely time for an increase. I would also support adding some larger values to the non-default options. Kaldari (talk) 21:17, 9 July 2014 (UTC)
• Strong oppose If we consider the default, non-resigtered user, they are going to be ones likely to visit on older devices and thus the 220px size is best suited for them. It is far far too early in technology adoption curve to consider the possibility of larger screen sizes, in addition to how this will affect NFC aspects too. --MASEM (t) 22:20, 9 July 2014 (UTC)
• Masem Mobile frontend already scales image down to the width of the device, so this is a non-issue. It does not however scale images up to the width of the device, so having images that are greater than the device width will result in properly formatted images on mobile, rather than postage stamp size ones. Jared Zimmerman (talk) 22:35, 9 July 2014 (UTC)
• I'm more thinking of laptop and desktop systems. I know 220px on a 25" monitor is tiny, but I doubt most unreg'd users are using 25" monitors, but even a heavily reliance on CRTs. (COnsider that when Win XP expired earlier this year, it was estimated the system was still used by 40% of the Windows install base - the average person moves slow on technology improvements) --MASEM (t) 22:45, 9 July 2014 (UTC)
• Masem, not sure where you're getting your number, but even on a 13" or 15" laptop screen 220px feels very small. Jared Zimmerman (talk) 22:49, 9 July 2014 (UTC)
• I disagree. It's the very purpose of thumbnails to provide small images that can be enlarged for better viewing. As has been rightly observed above, images are meant to provide additional information in an article. However, they are not meant to dominate entire sections of the article which will quickly become the case with enlarged images on 13" or 15" inch screens. At the same time, I question the necessity of enlarged thumbnails now that Wikimedia has only recently launched the image viewer which, as far as I recall, was meant to aid viewing images without much obstructive meta-data like licence templates and whatnot. Let's not remember that the main focus of Wikipedia is still on text, and I oppose the recent tendency of it becoming Picturepedia. De728631 (talk) 23:05, 9 July 2014 (UTC)
• Totally concur with De728631! On a 13" laptop screen 220 px is the perfect size to properly balance text content against image content. While the images might seem a little small on 15" screens (note however that many "cheap" 15" are actually the same resolution than a highly resolved 13" screen) there is no point in increasing image size as long as no flexible design is used that (as an example) defines image size in percentage of page width (plus a minimum size). Otherwise we break design for all smaller screens to make it look OK on larger screens instead of the current situation wich give good layout on small screens and acceptable layout on large screens. --Patrick87 (talk) 23:21, 9 July 2014 (UTC)
• Patrick87 & De728631 I'll have to disagree with you that "the point of Wikipedia is text" the point is to be an educational resource, and we should help people learn about the world around them in ways that work for everyone, whether that is text, images, video, audio, or other means of representing knowledge. I see no reason why images cannot have equal weight or importance to text based content.
• Patrick87, as you can see from the initial post I am proposing that we eventually move to responsive images, but that will require significantly more work than the simple 2 line fix that will update the default image size. Can you show some pages that feel would be made worse by larger images? it might be useful for other to see what your concern is rather than have to imagine. I hear an image is worth 1,000 words… Jared Zimmerman (talk) 00:08, 10 July 2014 (UTC)
• That's a singularly smug, wrongheaded comment. A picture may be worth a thousand words in conveying information about appearances, but finding out what a subject looks like is not the primary reason readers come to Wikipedia. Especially when we're talking about images associated with article ledes, increasing the size means reducing the amount of text the reader initially encounters, and that's a very bad idea. The Big Bad Wolfowitz (aka Hullaballoo) (talk) 12:09, 12 July 2014 (UTC)
• For an encyclopedia, the finest image is worthless if there is no text to describe it, and in fact it is media like images, videos, audio etc. that complement the information provided in the text of an article, and not the other way around. And 220px do not look small on a 15" screen at all. In my sandbox I'm showing the first two paragraphs from the article Amrum with the current default thumb size and with images extendend to 300px. On my screen, the latter version reduces the text column in the Geography section to 50% of the page width excluding the toolbar on the left, while the default size now provides about 66% of text between the first image and the infobox. With a thumb size at 300 px the images on that page become in fact distracting when you want to read the first few paragraphs.
Also, you wrote above that assuming that most user are "happy" with the current situation was a big assumption. I challenge you to show that the majority is actually unhappy with the current default size so the WMF needs to act. Has the WMF gotten a vast number of complaints about inadequate file sizes from desktop pc and laptop users? The number of mobile page views may be increasing but compared to the remaining 75% of users (20 billion total views - 5 B mobile = 15 B desktop views) they're not representative. So applying any changes the majority of users might not even need for the sake of making Wikimedia more accessible to the mobile community is the wrong approach imho. If there's a bug for tablets you should try to find a workaround that addresses the specific problems there instead of forcing changes on the entire community (yes, I wrote "forcing" because, speaking strictly for myself, I regard any change from the default that afterwards requires me to change my settings as forceful). De728631 (talk) 18:33, 10 July 2014 (UTC)
• Jared, please compare the images below. They show a screenshot of Miroslav_Klose#Club_career with 800 px screen width as well as an A4 print preview: The versions with 220 px thumbnail size have the images fill about 1/3 of the screen width looking pleasant to the eye and working OK in regard to typographic standards. The versions with 300 px thumbnail size have the images fill 1/2 of the screen width, therefore mostly breaking the flow of text, looking bad and being a nightmare from a typographers standpoint.--Patrick87 (talk) 22:04, 10 July 2014 (UTC)
• Patrick87, I'm not seeing quite the disjointed flow of text you are seeing, however I'm testing the new image styling as well, which should be in place within a few weeks. While in your screenshot the text flow is less than ideal, "nightmare" is a bit of a stretch, part of the issue is the skin's non-responsive layout. If you view the mobile (tablet) layout for the same page on desktop you'll see a much smarter layout of the same content when a browser is that narrow. 800px width seems to be an outlier for me, and no doubt when this becomes the default you'll see users shifting a few images around here and there when they feel the layout could be improved. Jared Zimmerman (talk) 23:11, 10 July 2014 (UTC)

• As a side note, a) the problems here are exacerbated by placing the images alternatively on left and right instead of just right (the default), and b) these are portrait-orientation images, and they should probably be using the |upright parameter (which reduces the default width by 25%), see Wikipedia:Picture tutorial#Upright images. I just applied these two fixes to the article, care to look again? Matma Rex talk 17:24, 11 July 2014 (UTC)
• For obvious reasons, I didn't chose the example, that shows the issue worst. Surely one can tweak size and orientation of some thumbnails on some pages, but the fundamental issue stays the same: A 300 px wide thumbnail fills at least half the page for 800 px wide screens or paper prints of Wikipedia articles. This is too much and layout issues are much more probable than for slightly smaller thumbnails of 220 px width. --Patrick87 (talk) 17:40, 11 July 2014 (UTC)
• Wait, are you saying you would expect new editors and IP editors to know that they should use an obscure parameter that I barely know about (as it is fairly new) even with my spending hours on mw:Help:Images learning everything I could about how to format and lay them out the way I want them to appear? That seems like a pretty tall order to me. — {{U|Technical 13}} (etc) 17:54, 11 July 2014 (UTC)
• |upright is not new, it has existed for years. It doesn't matters much anyway, it is sufficient not to use |left. MediaWiki should be smart enough to "turn |upright on", in a way, but it currently isn't – there was a plan to fix it, but like every new idea it was met with a backlash right here. (I don't have links handy, you can probably find it somewhere, google "square bounding box thumbs mediawiki".) Matma Rex talk 18:07, 11 July 2014 (UTC)
• Technical 13, no one is suggesting that readers do this (they can if they'd like) but editors are always gnoming and making small changes, i frequently find instances of weird hackish ways that people have put images next to each other and replace it with MulitpleImages template, its already happening and Matma Rex is just saying it will continue to happen in the case you mentioned. Jared Zimmerman (talk) 19:02, 11 July 2014 (UTC)
• I don't think anyone will disagree that people are using weird hackish ways to put images next to each other or format them a specific way that looks good at their resolution (I'd guess most have no idea that a slight change from their resolution completely breaks their "perfect" formatting). The point is, that there has to be a reason they are using these methods, and my guess is because the "default" method doesn't work right or doesn't look right at the OPs resolution, so they try to "fix" it, which of course breaks it for almost everyone else. I think the point being made here is that failing to consider these issues and changing the default size is going to exponentially worsen said cases and we are going to see more of said cases. So, the question becomes, how do we fix the root cause and how do we make this work for as many readers (whether they edit or not) as we can. The first thing that comes to mind is to actually make use of @media css and set different defaults for different viewing screen sizes and get rid of the option all together. This would be the best stopgap in my mind until the dynamic size blockers are fixed. — {{U|Technical 13}} (etc) 19:11, 11 July 2014 (UTC)
it was Wikipedia:Village pump (technical)/Archive 127#Infobox Image. --Redrose64 (talk) 20:17, 11 July 2014 (UTC)
• Support— pictures are worth a thousand words after all. Imzadi 1979  03:32, 10 July 2014 (UTC)
• Support. The file size increase is negligible and if 220px is really wanted it should be done via CSS - the images will be much crisper as a result. Noteit seems we support responsive images already on my retina device. The srcset attribute seems to be set on images when I inspect on my desktop computer (although sadly the larger resolution images are not loaded :-(. — Preceding unsigned comment added by 76.21.59.101 (talk) 06:17, 10 July 2014 (UTC)
• Comment I though we already had support on this from the community ? Wasn't it mostly stuck on technical/operational issues on the WMF side ? —TheDJ (talkcontribs) 10:09, 10 July 2014 (UTC)
• Support if tech opinion doesn't throw up serious issues. I co-led the push to increase the tiny 180px default to 220px, in 2009 (a 49% increase in area). I remember senior tech at the WMF writing on the subsequent Bugzilla request something like: "Yeah, 'bout time". There was strong support from the community. I'd cautiously suggested 220px in the hope it would fly more easily, but numerous people wanted more than that. I'd have been happier with 240px myself. 300px, even now, sounds rather large. If there's going to be resistance, I'd go for 240px or 250px. As a matter of interest, the WMF waited until a new bank of servers was installed before they upgraded en.WP, just so there would be sufficient back-up if it crashed the system. They did Commons within a month, and rolled it out to the other sites in the subsequent months. Keen to hear more from techs. Tony (talk) 12:53, 10 July 2014 (UTC)
• I've pinged people from platform:performance and operations to have them weigh in if there are any technical concerns. Jared Zimmerman (talk) 17:17, 10 July 2014 (UTC)
• Support - Content should improve (in this case, increase in size) as technology improves, and anyone can ultimately control size via preferences. 300px seems about right. For similar reasons, I favor a move toward responsive sizes sooner rather than later.- MrX 19:03, 10 July 2014 (UTC)
• Question on implementation - If 300 px is going to be the default size, does this imply that user prefs will allow for larger sizes? Because if this is the implication, then I have to reiterate a extremely strong oppose on the basis of non-free images. We have a good system that aims for uploading NFC images (where finer details are otherwise not needed) at a size that a 300px max possible thumbnail size works well and maintains the minimization of copyright-taking (eg ablum covers are reduced to 300x300px). If now we can go past 300px for maximum image size, that is going to encourge people to upload larger resolution images so they look right at the newest larger size, and that breaks the purpose of non-free minimization. --MASEM (t) 22:15, 10 July 2014 (UTC)
• I don't get this objection, though I've heard you repeat it several times this year. If 300 px is actually the limit for Fair Use according to our policy, then write down in the policy that 300 px is the limit for Fair Use images, full stop, no matter what other settings are possible in prefs or what might make sense for particular circumstances, and then go delete anything that has a FUR and is 301 px or larger in either direction. If 300px isn't the limit, then you shouldn't oppose it on the grounds that it might embolden someone to upload an image that fully complies with the written policy, even if that means uploading an image that is 360 or 400 px in one direction or the other. You know that I'm never sympathetic to arguments that amount to failing to get consensus for putting a 300-px limit into the policy, and then trying to enforce your preferred size restriction through other means. If they're real consensus for that 300 px limit, then you ought to be able to get that limit enshrined in the policy and enforced through deletion of larger images.
Having said that, this proposal says nothing about allowing larger sizes. It would just set the default to one of the two, already-existing, larger sizes. WhatamIdoing (talk) 22:40, 10 July 2014 (UTC)
• 300px is not a hard limit on non-free - but even through the 180->220px default thumb change, the nominal size that we encouraged editors to upload materials of non-free nature remained mostly unchanges - albums at 300px square, screenshots at 480x360 / 480x270px for screenshots, etc. These sizes balance the viewability of the content of the image with the need to reduce non-free works without too much problem. In other words, these image sizes work for these type of media and hence there's rarely a need to go larger with these types of works. You can go larger on other types of non-free but there has to be a good reason to go larger (for example, to show finer detail on a work of art). But as the bulk of non-free is cover art and screenshots, these former sizes worked given the range of allowable thumbnail sizes. If the increase of the default thumbnail size is accompanied by an increase in the maximum preference setting range (Which didn't happen with 180-->220px) editors would start uploading at larger sizes to meet the larger thumbnail size without considering that smaller sizes for these images have worked for us in the past without problem. But again, this is going on the basis that if we make larger thumbs at 300px, that there would also be a new larger preference size that could be set. If no new larger thumbnail preference size is being set, then there's not as much an issue here with non-free. --MASEM (t) 23:02, 10 July 2014 (UTC)
• Just to echo what WhatamIdoing has said, this proposal/bug does not seek to increase the maximum thumbnail size. However, the bug i logged at the same time, might possibly increase the effective "largest thumbnail size" while simultaneously removing the preference all together. see Bugzilla: 67695 but lets keep that issue separate for now, for simplicities sake. — Preceding unsigned comment added by Jaredzimmerman (WMF) (talkcontribs) 23:20, 10 July 2014 (UTC)
• Support. 220px looks very small on most modern displays, and on an increasing number of mobile displays. And the work on the mobile site means that mobile users with smaller screens will not be at a disadvantage. The only people who will be at a disadvantage are desktop users who are still stuck with 800x600 displays. And these days, even PCs that make me think "wow, that's an old PC" almost never have less than 1024x768. (That is, PCs that people are actually still using.) According to w3schools, 800x600 and lower count for 0.5% and 0.5% of global pageviews respectively. — Mr. Stradivarius ♪ talk ♪ 09:54, 11 July 2014 (UTC)
• Support just don't go crazy with it. I usually keep my browser on a monitor turned on its side, so consider that use case as well. Make sure it looks ok with a width of around 1000px for people with portrait turned monitors. Gigs (talk) 16:50, 11 July 2014 (UTC)
• Support Entirely reasonable and well-timed change. — Scott talk 19:12, 11 July 2014 (UTC)
• Oppose per Technical 13. Wikipedia is about text, not images. 20:20, 11 July 2014 (UTC)
• Oppose - It's fine as it is, Don't fix what isn't broken. –Davey2010(talk) 22:28, 11 July 2014 (UTC)
• Maybe. What is the distribution of screen sizes (in pixels) among our readers? MER-C 10:05, 12 July 2014 (UTC)
@MER-C: I've asked a dev: we don't currently collect that data (even in anonymized aggragate). Hopefully they'll add that in the future. Quiddity (talk) 01:12, 17 July 2014 (UTC)
• Oppose. Because some viewers are using smaller screens, we should reduce the share of the screen devoted to text? That's pinheaded and shortsighted. The Big Bad Wolfowitz (aka Hullaballoo) (talk) 11:56, 12 July 2014 (UTC)
• Strong oppose per Hullaballoo Wolfowitz. Breaking news: most of mobile users doesn't use Galaxy V nor iPhone 5 nor any other two square kilometers-wide screen device. --Vituzzu (talk) 20:31, 12 July 2014 (UTC)
• Vituzzu, as has been mentioned at least 3 times in this discussion, MobileFrontend has code that limits the max width of thumbnail images to the device width, so this will change the postage stamp sized images on mobile to be full width, but will not cause text rendering issues or images larger than the device screen size. You can test it yourself by setting your preference to 300px then visiting the mobile site, while logged in from your phone. Jared Zimmerman (talk) 06:04, 13 July 2014 (UTC)
• Perhaps I'm missing the obvious, but the proposal is pretty confusingly phrased - what would the enlargement actually be? 250px would seem unproblematic but 300px is perhaps a little more concerning. Andrew Gray (talk) 21:11, 12 July 2014 (UTC)
I thought the same, but "I was actually suggesting 300px based on actual user data provided by Analytics. Jared Zimmerman (talk) 20:54, 9 July 2014 (UTC)" is in the middle somewhere above. I have clarified at the top. Options for 250 or 300 might have led to clearer comments. Johnbod (talk) 00:27, 13 July 2014 (UTC)
• Support essentially per Mr. Stradivarius.Blethering Scot 21:52, 12 July 2014 (UTC)
• Strong Support 250px should be fine, maybe 300. I'd also support a larger max option for preferences - 350px at least. If I remember correctly, last time existing registered users who had never set a preference saw no change. If this is still the case the change needs good advertising. Johnbod (talk) 00:17, 13 July 2014 (UTC)
• Support a change in the default to 300px. We have data showing that only a trace of users are using 800x600px displays anymore. Anyone using a mobile device or tablet gets the mobile site, which has special handling of images that would be unaffected by this change. I also support larger sizes being available in user preferences, as well as the removal of a few of the smaller sizes. Why we ever needed the granularity of 120,150,180,200,220,250,300 is beyond me; this could be changed to, say, 120,180,220,250,300,350,400. — This, that and the other (talk) 04:11, 13 July 2014 (UTC)
• Support a change, but 300px seems a little too much to me. 250px would be more appropriate IMHO (and some sort of a compromise with opposers, too). Cavarrone 10:03, 13 July 2014 (UTC)
• Strong Support for 300px as default and I'd also support a larger max option for preferences (400px).--LikeLifer (talk) 11:27, 13 July 2014 (UTC)
• Don't care, as the entire website and skin will be redesigned soon (including typography refresh, new mobile skin potentially coming to desktop, etc) and the thumbnail size will be irrelevant or just different. --Gryllida (talk) 11:32, 13 July 2014 (UTC)
• Strong Support per Johnbod. Alberto Fernández Fernández (talk) 16:37, 14 July 2014 (UTC)
• Oppose; the Manual of Style explicitly allows alternating left-and-right images, and this change would exacerbate and introduce "sandwiching" problems in many articles, as seen on the Miroslav Klose article screenshots posted above. Titoxd(?!? - cool stuff) 17:00, 14 July 2014 (UTC)
• Support, wholeheartedly. Mobile/small screens aren't an issue. The issue is only desktop browsers and since 2009 the average screen size of these devices (in pixels) has increased dramatically. I know we're focused on providing support for readers with older, cheaper and smaller devices and that's a great goal. But let's not conflate supporting those users with retaining a default setting which works best largely for a small and shrinking proportion of the reader base. Protonk (talk) 19:28, 14 July 2014 (UTC)
• Oppose: conflicts with wikipedia's supposed policy to provide an educational resource for everyone. Note dyslexia style guides recommend against the sort of layout shown by the example screenshots because they can be much harder for dyslexics to understand.[2][3] There is also a mistaken assumption by young or Western editors that everyone has new devices. The image size shown in the example screenshots in the bugzilla report look fine to me. DrKiernan (talk) 20:11, 14 July 2014 (UTC)
• The first link only opposes "very large graphics", and if 300px-wide images are "very large", then they've violated their own advice. I conclude from their own use of graphics that 300px images aren't "very large" by their standards. WhatamIdoing (talk) 02:19, 16 July 2014 (UTC)
• The first link says "Avoid cramping" and "Avoid narrow columns". The example screenshots with the new image widths have cramped text in narrow columns. DrKiernan (talk) 08:01, 16 July 2014 (UTC)
• Oppose - I like the looks of layouts using the 220px standard. Bear in mind that some horizontally-oriented graphics need to be pumped up to as much as 450px to look proper; 300px is too large for vertical graphics, however. Carrite (talk) 16:15, 15 July 2014 (UTC)
@Carrite: Vertical/Portrait oriented images are meant to use the "|upright" parameter, which shrinks the thumb to ~75% width (details in WP:PIC#upright). That results in these size-pairs, for each of the standard (and considered) options: 220px/170px, 250px/190px, 300px/230px. See the images in the FA Cuban macaw, for examples. Quiddity (talk) 20:53, 16 July 2014 (UTC)
• Oppose. From my perspective, the current default size is quite adequate for encyclopedia entries that are primarily textual. (Disclosure: my desktop is a mere 1440 px wide.) Statistics based on people who fiddle with the user preference may not be the most unbiased sample – folks with a particular interest in pictures could be overrepresented.

A larger format is appropriate is some situations. I could support the idea of offering two default sizes, if that is not a contradiction in terms, one for a "thumbnail" image (already much larger than the nail of most people's thumbs – elephants don't count), and one for an "expanded" or "prominent" image on the order of half the width of a desktop screen. ~ Ningauble (talk) 17:54, 16 July 2014 (UTC)

We do already have policy/guidelines for larger Lead images. See details in WP:Image use policy#Size, and in MOS:IMAGES#Size, and in WP:PIC#Thumbnail sizes.
Also, I've been looking through some recent FAs, and many of them are either not using the |upright parameter where they should, or are specifically overriding the default sizes in various places, eg. Roy Phillipps, SS Arctic disaster, Royal baccarat scandal and Pope Paul III and His Grandsons. Possibly, increasing the default size would help resolve these issues. Quiddity (talk) 00:55, 17 July 2014 (UTC)
My experience here is that the "upright" parameter is not well known and/or somewhat difficult to understand and tends to get lost over the more direct "width" one. I know it is doing exactly what we want in terms of technical implementation, but it's not very easy to explain to people that are not used to flexable formatting approaches. It's much "simpler" to recognize that "width" can narrow the size that a portrait-style image appears at than adding "upright" that does that automagically. --MASEM (t) 01:36, 17 July 2014 (UTC)
@Quiddity: Yes, I know all about the various ways of tweaking image sizes. They are a bit fiddly and, as Masem notes, not as well understood as they might be. I was only suggesting, as an aside here, that it might be simpler to have a second default, an alternative to "thumb", for situations where a larger presentation is appropriate. A half page graphic is not a thumbnail image.

And no, I really do not think making all of the images larger by default is a satisfactory resolution for the need to make some of the images larger. I was specifically referring to situations where one-size-fits-all is not fitting. If this is too far off topic or outside the box in a discussion of what the single default size should be, then please disregard it. ~ Ningauble (talk) 13:20, 17 July 2014 (UTC)

• Partial Support I'd say about 260px. 17:59, 16 July 2014 (UTC)
• Support. Definitely. I could've said the same thing even 4 years ago. -- œ 03:39, 18 July 2014 (UTC)
• Support There is a clear interest in displaying images at higher resolution given changes to technology. I approve of this, even as a user of what most would consider an old, small-screened laptop (my hard drive is smaller than the Wikipedia:Database download). I don't find any of the above reasons reasons against convincing. The Klose article clearly had presentational issues in the screenshots above before we started (images should not bump out headings), so it's not a good test case. These are manual of style issues that would already be exacerbated for the 10,000 users manually opting for larger image size. I don't find it convincing that larger images will detriment encyclopaedic presentation. Images are often an undervalued element of articles that readers will mostly want to see at higher resolution, and will be better served from a learning perspective by that change (see Cheetah for example). If images are not bringing extra value to an article, they should be excluded as an editorial decision. The one concern I do have is that this is quite a big jump up in size. I would prefer an upgrade to 250px with A/B testing for 300px, if that is possible. SFB 10:50, 19 July 2014 (UTC)

---

Thank you everyone who added feedback, concerns, responses, and clarification. We appreciate your time and involvement. At this time I'd like to request an uninvolved 3rd party close and summarize the thread. Thank you again. Jared Zimmerman (talk) 06:00, 18 July 2014 (UTC)

## Missing reference markup will no longer show an error

As noted above, "If you use references on a page, you will soon always see them at the bottom of the page, even if you forget to add the <references /> tag (or a template)."

This has been deployed and has a few issues:

• It does not work for reference lists with groups. bug 67847
• There is no tracking category. bug 67700
• A missing </ref> no longer generates the missing reference list error, it now mangles the following rendered markup. bug 67845

More discussion at Help talk:Footnotes#Missing reference markup will no longer show an error. -- 11:08, 11 July 2014 (UTC)

@Gadget850: bug 66700 doesn't look related, did you mean something else? — This, that and the other (talk) 11:22, 11 July 2014 (UTC)
Fixed. Thanks! -- 11:29, 11 July 2014 (UTC)
bug 67854 doesn't exist? --Redrose64 (talk) 12:09, 11 July 2014 (UTC)
bug 67845. --Glaisher (talk) 12:13, 11 July 2014 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────Can the auto system be upgraded to add a References section header, and keep the references section at the bottom? We are now getting talk pages, with no separation between one post and the ref-list, and another post is then added beneath it e.g. Talk:Soka Gakkai where it appears that the references relate to the post above them, although they don't.

The current arrangement means that, althiough the list appears, someone has to go around and manually add the ==References== section header, which is also one of the most common misspellings (I have corrected "Refrences" at least once in 140 of the last 142 weeks, plus the corrections to "Refferences" "Referrences" and "Referneces") - Arjayay (talk) 13:37, 12 July 2014 (UTC)

Depending on how bug 67700 is resolved, I would add namespace detection like we do with the other cite errors. On talk pages, we could just not show the list or show it with a header. -- 23:21, 12 July 2014 (UTC)
Looking at the patch, I think it is just going to add a maintenance category, which would be blank by default. I will have to see this implemented to see how it actually works. -- 23:38, 12 July 2014 (UTC)
@Arjayay: Based on your post, I created Wikipedia talk:AutoWikiBrowser/Feature requests#Update FixHeadings to fix misspelling of References. GoingBatty (talk) 17:41, 13 July 2014 (UTC)
Thanks - but if it automatically added the (correctly spelled) References section, this would not be necessary. - Arjayay (talk) 17:48, 13 July 2014 (UTC)
It won't. And the auto reference list will always be put in the wrong place. If we had kept the previous error checking, then we could have done this. -- 13:25, 14 July 2014 (UTC)
The tracking category should be deployed in 1.24wmf14. -- 15:59, 16 July 2014 (UTC)
• bug 68324 - Cite: Add namespace detection for automatically generated reference list -- 15:05, 21 July 2014 (UTC)

Adding this feature caused explosion on pages with missing references section. -- Magioladitis (talk) 18:02, 21 July 2014 (UTC)

Did something change in recent months relating to the way MediaWiki handles [[w:(lang):Example]] links? Previously, [[w:de:Australien]] should have worked in exactly the same manner as [[:de:Australien]] to produce a link to this page, however it doesn't seem to work anymore, for any non-English language code. For some reason, the en language code still works: w:en:Test and en:Test both do the same thing. --benlisquareTCE 17:45, 15 July 2014 (UTC)

It has changed [4], there have been some fixes aiming to make the handling of "local interwiki links" like [[en:Dog]] or w:Dog more consistent. It seems that the fixes indeed introduced a little regression, [[w:de:Australien]] is now handled like [[de:Australien]] instead of [[:de:Australien]]. This, that and the other should know what to do with this. Matma Rex talk 19:00, 15 July 2014 (UTC)
Hmm, this is interesting. The new behavior is arguably more correct, and I suppose I designed the changes so it would work this way. But on reflection, it doesn't seem quite right; in particular, from a cross-wiki code reuse/transclusion perspective, it is definitely not right. I'll have a think about this and perhaps write a patch for MW core. Benlisquare, thanks for bringing this up! — This, that and the other (talk) 02:52, 16 July 2014 (UTC)
Now that I've looked a bit more deeper into the issue, does this apply to enwiki only? w: links seem to still work just as before on the Chinese Wikipedia and other language Wikipedias. --benlisquareTCE 06:23, 16 July 2014 (UTC)
I've found (see User talk:RexxS#Oh no, not her again) that all you need to do to fix these is either insert a colon right at the start ([[:w:de:Australien]]w:de:Australien), or omit the initial w ([[:de:Australien]]de:Australien). So long as it begins with a colon, it's treated as a clickable link, not a H:ILL.
That's true, but the intention is to restore the old behavior, so there is no need to go around willy-nilly adding leading colons everywhere! — This, that and the other (talk) 02:48, 17 July 2014 (UTC)
Yes, there is the chance that templates and pages throughout Wikipedia have such links which have yet to be modified by someone following the change to link behaviour, meaning that there may be non-functional links lying around. --benlisquareTCE 04:58, 17 July 2014 (UTC)
Given Wikidata has removed the old way of doing interwiki links that needed a colon, should the non-colon functionality be made identical to colon, or is there anything where it's still relevant? 20:46, 16 July 2014 (UTC)
ILL are still needed for #section links, and for topics with 2 pages at wiki-A but only 1 page at wiki-B. See H:ILL#Local links (2nd bullet point) and d:Help:FAQ#Editing (#14 and #15) for details on each. Quiddity (talk) 21:16, 16 July 2014 (UTC)
Also for pages in User: space. --Redrose64 (talk) 21:54, 16 July 2014 (UTC)

This is now tracked as bug 68085, with a fix pending review. Matma Rex talk 23:05, 16 July 2014 (UTC)

## Can I get consensus for Special:Email to point to Special:EmailUser

It seems intuitive to me: Special:Email should redirect to Special:EmailUser. I was having a chat in IRC, on #wikipedia-en-help, and I asked a user to email me, and gave the wrong link. Redirects are cheap and this should save (some) time and confusion. I mean, who would you be emailing other than users? I was going to go to bugzilla but decided to get consensus first. Comments? Thanks, Lixxx235Got a complaint? 04:48, 16 July 2014 (UTC)

I would support such a change. Special:Contribs points to Special:Contributions, so why shouldn't Special:Email point to Special:EmailUser? Dustin (talk) 05:03, 16 July 2014 (UTC)
Technically, as a software change, this doesn't need consensus. Anyway, I submitted gerrit:146798 that will add it. Jackmcbarn (talk) 16:11, 16 July 2014 (UTC)
I gave the patch a +1. I'm wary of adding in aliases for every possible thing, but this one seems pretty sensible and common to me. --Dan Garry, Wikimedia Foundation (talk) 03:26, 22 July 2014 (UTC)
Agree. — xaosflux Talk 04:07, 22 July 2014 (UTC)
We should probably do the same for Special:E-mail and Special:E-mailUser. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:52, 17 July 2014 (UTC)
Might be going a bit too far, along the lines of DGarry's comment, not as useful. — xaosflux Talk 04:07, 22 July 2014 (UTC)
My change has been accepted. It will be live here effective July 31st. Jackmcbarn (talk) 18:13, 22 July 2014 (UTC)

## More templates not appearing on mobile

Further to recent discussion, about {{Authority control}}, it also appears that {{Commons category}} does not appear on our mobile view or app; and no doubt its sibling templates and others are similarly affected.

This will affect editors little, since most are likely to be working on in desktop-view, but a significant number of our readers are on mobile devices. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:45, 17 July 2014 (UTC)

{{Commons category}} ultimately uses Module:Side box, which adds the invisible-for-mobile metadata class. About 380 other templates also use the module. 14:20, 17 July 2014 (UTC)
All those elements are also not present in print. This is by choice. They are not part of the 'content proper', but are 'internal' in nature. Now with the more advanced mobile website might slowly start losing the requirement to hide some of those elements by default, I think it was mostly hidden originally because of the maintenance templates, and even those are being represented now, so perhaps someone should file a bug against Mobile to revert the decision to hide .metadata in the mobile view. —TheDJ (talkcontribs) 14:56, 17 July 2014 (UTC)
Alternatively, we can of course say that {{Sister}}, should just not call the metadata version of {{Sidebox}}, but that is a community decision. —TheDJ (talkcontribs) 15:01, 17 July 2014 (UTC)
It's Template talk:Listen/Archive 3#Does not render in mobile view. once again. Just add |metadata=no to the {{side box}} that is inside Template:Sister. --Redrose64 (talk) 16:44, 17 July 2014 (UTC)
Done; please let me know if anything breaks. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 08:37, 22 July 2014 (UTC)

### Collapsed sections not showing

It also appears that anything inside {{Collapse top}}/{{Collapse bottom}} is hidden on mobile. See:

This really isn't on. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 08:33, 22 July 2014 (UTC)

{{Archive top}} has the navbox class. Same issue as with Template:Authority control. 09:25, 22 July 2014 (UTC)

Guys, what is the RGB code for blue and red links? --Edgars2007 (talk/contribs) 08:31, 19 July 2014 (UTC)

They are listed at Help:Link color -- John of Reading (talk) 08:40, 19 July 2014 (UTC)
Silly me. Thanks! :) --Edgars2007 (talk/contribs) 08:44, 19 July 2014 (UTC)
They also vary between skins: links in Vector are darker than those in MonoBook. --Redrose64 (talk) 08:53, 19 July 2014 (UTC)

## two annoying problems

I mostly edit from an iPad. So, a while back they switched in the mobile site by default. As it does not support admin tools I opted to go back to the desktop version. For some reason in the last 48 hours I keep getting sent to the mobile version at the start of each new session, even though I'm still logged in from before. I've searched my preferences and can't find anything in there to deal with this. Is there a way to permanently disable the mobile site?

Also, I though maybe I'd try asking the devs over at the technical forum on meta and it seems SUL is not working over there. I navigated there from here and when I got there I was not logged in and for some reason it is not accepting the password I use here. I may have had a separate password over there in the pre-SUL days but I certainly don't remember what it was now. Beeblebrox (talk) 21:05, 19 July 2014 (UTC)

Beeblebrox, I don't know much about tablets, but it sounds like the two most common problems when this happens are the user going directly to the mobile website via the URL (if you type "http://en.m.wikipedia.org", then you'll get the mobile site no matter what your prefs say and no matter what kind of device you're using), and corrupted cookies. So you might double-check the URL, and you might see if there's a way to clear cookies. If neither of those help, then perhaps someone else will know more than I do. Whatamidoing (WMF) (talk) 23:54, 19 July 2014 (UTC)
I've never navigated directly to the mobile site, so it's not that. I've had the same link in bookmarks for three years and it has always taken me to the desktop version of my watchlist. The way they do watchlisting on mobile is one of the worst things about it, I can't understand why anyone thought it was a good idea. I cleared all my cookies and loged back in and it took me to the mobile site again, so it looks like it's not that either. Beeblebrox (talk) 01:27, 20 July 2014 (UTC)
Hrm. ? Ironholds (talk) 04:11, 20 July 2014 (UTC)
[Re: The second problem, your Meta account is attached to your SUL account, so you theoretically shouldn't have a problem logging into that site. Graham87 12:16, 20 July 2014 (UTC)
Tried again just now. Once I bypassed the mobile version over there, it prompted me to reload the page to apply my user settings, seems to be ok now. When I clicked back over here I got the mobile version again.... Beeblebrox (talk) 17:24, 20 July 2014 (UTC)

For the questions about the mobile web interface, Maryana is your woman. For the SUL stuff, Special:CentralAuth/Beeblebrox says that Beeblebrox on Meta is attached to your global account, so I can't explain the issues you're having crossing wikis. Try totally clearing your browser cache and cookies, and if the problem still persists then, file a bug on Bugzilla with as much information as possible. --Dan Garry, Wikimedia Foundation (talk) 17:00, 21 July 2014 (UTC)

The SUL thing seems to have resolved itself, must have been a temporary issue. I've completely reset my browser, removing all history and cookies, twice. Pretty sure the problem is not on my end. But I have to say I hate the idea that I have to set up an account on another website to get attention to an issue on this website. If someone with a bugzilla account wants to copy this over that would be great:
• Issue:persistently redirected to mobile site despite repeatedly trying to opt out. If I leave WP, even without logging out, when I return I am sent to the mobile site. I can see the URL for the desktop site actually change to the mobile site about a half second after I click the link. Have removed all cookies and cleared all history, issue is persistent.
• Time frame: last 3-4 days
• OS:ios7.1.4
Thanks in advance, Beeblebrox (talk) 17:31, 21 July 2014 (UTC)
• Hmm, that's no good... Thanks for the bug report, Beeblebrox; I've added it to Bugzilla. Will get the devs to take a look. Maryana (WMF) (talk) 22:19, 21 July 2014 (UTC)
Ok, here's a weird thing: I went into my bookmarks menu to look at the actual URL, which did not have the "m" for the mobile site in it. I removed it anyway, went to my watchlist and added a new bookmark with the same URL and now it isn't redirecting me. I have no idea how that makes the least bit of sense but there it is. Beeblebrox (talk) 19:18, 23 July 2014 (UTC)
That could potentially make sense if the mobile redirect thingy is, or has ever been, using a wrong kind of HTTP redirect (permanent HTTP 301 instead of one of the temporary ones). I haven't checked if it does. Matma Rex talk 22:43, 23 July 2014 (UTC)

The cite tools don't work on safari or chrome on the iPad, the window pops up but the fields are not editable. Anyone else have this issue? GimliDotNet (Speak to me,Stuff I've done) 21:10, 19 July 2014 (UTC)

## Made an edit and it didn't show up

[5] versus [6] Where did it go?? -- Kendrick7talk 02:56, 20 July 2014 (UTC)

I fixed it but had to remove your signature (which was just four tildes!) because my signature was shown. The problem was that someone had used text like <ref example> which made an unclosed reference. Please add your signature again. Johnuniq (talk) 03:54, 20 July 2014 (UTC)

Greetings, (I have forgotten), could someone provide me the page link that controls notifications above watchlist (example: A new discussion is taking place on ABC. [dismiss]). Thanks TitoDutta 05:13, 20 July 2014 (UTC)

, I am pretty sure you do not mean the Wikipedia:Requests_for_comment#Before_starting_the_Request_for_comment_process because that is for pages that are prone to adversarial action. As far as I can tell, you can get notified about any wide-ranging discussions about watchlisted pages only if you created that page. In that case, in the top right corner of that page | Preferences | check Page link, or check Page review (you can hover your cursor over the question mark to get help) | Save .
It occurs to me that an editor could simply post a section to any watchlisted talk page about discussion or request for comment. You would see that by virtue of your watchlist.
PS: wp:flow may make it possible to get notified about pages which you did not create yourself (but not yet). Pinging @Quiddity: about this application for the Flow project. --Ancheta Wis   (talk | contribs) 06:58, 20 July 2014 (UTC)
MediaWiki:Watchlist-details. — Mr. Stradivarius on tour ♪ talk ♪ 08:56, 20 July 2014 (UTC)
I think you're misunderstanding Titodutta. The query is about "notifications above watchlist". This would be about the banner adverts occasionally appearing there, and which can be [dismiss]ed with a click. AFAIK, there is no way to opt out of them, and I don't recall opting in. Actually, I don't have the slightest idea who or what is reponsible for these. Paradoctor (talk) 10:56, 20 July 2014 (UTC)
Wikipedia:Watchlist notices has some CSS fragments that make them invisible. -- John of Reading (talk) 11:07, 20 July 2014 (UTC)
There are two sets of these. Watchlist notices are displayed to all users; geonotices, which are displayed just above that (and in a different font, for reasons I've never worked out) are shown to all users in a specific region. These tend to be for local events rather than for on-wiki discussions, as it wouldn't make much sense to limit on-wiki stuff by geography. At some point they should probably be combined :-) Andrew Gray (talk) 19:12, 20 July 2014 (UTC)
I can never remember the exact page name that works as the linkhub, but the shortcut is easy: WP:NOTICES. :) Quiddity (talk) 18:34, 21 July 2014 (UTC)

## Use old version of a template

At Template:IPvandal/testcases, I want to include a set of tests that showed the results given by a specific old version (581205260) of the template. I read and tried Help:Permanent link, but it doesn't work for templates (it just becomes a link to the specified template; it doesn't transclude it). How can I transclude this old version of {{IPvandal}}? —[AlanM1(talk)]— 14:21, 20 July 2014 (UTC)

Create {{Template:IPvandal/old}} with the version you desire and transclude it. -- 16:57, 20 July 2014 (UTC)
@AlanM1: I copied the request to bugzilla:68399, because I wanted this same feature in few occasions before. Helder.wiki 20:52, 22 July 2014 (UTC)

## Running template within Lua and a few other questions

I'm working on a Lua replacement for {{UND}}

My original goal was to allow an optional parameter to indicate that it should be signed. I'm still mulling how to do that, but wanted to recreate the existing functionality first.

My draft attempt is Module:Sandbox/Sphilbrick/UNDiftest

My main issues:

1. Several of the output strings include a template. I don't quite see how to run a template inside a string. For example, one of the output strings has {{Font color|white|green|Submit your draft when you are ready for it to be reviewed!}}. That one should be easy, but I also have to accept an admin name and convert that to the usual output.
2. The copyvio option has an optional input. - you can run it with or without an external site name. I think I want to do something like if frame.args[2] but I'm not quite sure.
3. I believe we don't usually end with a module, but wrap the module in a template. I'm missing how to deal with the fact that the module will have 1-4 arguments
4. In some cases, the template used safesubst rather than subst. I didn't use either. What should I do?
5. I'd like to convert upper case input to lower case for the parameters. I know Lua is case-senstive, so if someone passes "D" as an argument, I'd like to autoconvert to "d". I chexkws the refernce manual and didn't see such a function.

I know I still have to write documentation and create testcases. I will work on that, but want to make sure I don't have to fundamentally restructure first.--S Philbrick(Talk) 17:39, 20 July 2014 (UTC)

As I look at that template, I don't see any advantage to converting it to Lua. Jackmcbarn (talk) 18:21, 20 July 2014 (UTC)

What I really want is a better version of the CBB templates, as seen in:
North Carolina Tar Heels women's basketball
The problem:
When adding the 2013–14 entry, it isn't hart to enter the wins and losses overall and by conference. But it is a pain to update the coach records and the overall records, especially when you consider that they are occasionally done wrong, so you should verify the complete sums, not just add the most recent year to the totals.
AFAIK, ordinary templates don't do math well. They can calculate ratios within a row, but I don't know how to sum across records.
My impression is that Lua can do this, so I thought I would learn Lua to work on it.
However, I wanted to tackle something easier as a start.
I had independently been working at both WP:SCV and Wikipedia:Requests for undeletion. In each case, there are canned templates to deliver standardized answers. However, the SCV templates automatically add a signature, and a bullet point, and are designed to be added to the end of the entry, rather than the next row. In contrast, the UND templates do not automatically add a signature, and you need to add your own indention and place on the next row. Not a big difference, but when going back and forth it means I have to stop and think each time which convention has been adopted.
I suggested that the UND templates be modified to auto add signatures, and that was rejected. So I thought it would be a good excuse to learn some Lua skills and either create some templates which could handle either case, r if not, at least create some that would work for me.
If you tell me either how to do math in traditional templates, or that Lua can't handle math, I'll probalby abandon my attemtps to lean Lua, and simply make a custom version of UND templates for my own use.--S Philbrick(Talk) 19:42, 21 July 2014 (UTC)
You can use the {{#expr:}} parser function, covered at m:Help:Calculation. For example, {{#expr:2+2}} → 4 --Redrose64 (talk) 20:54, 21 July 2014 (UTC)
That would actually be mw.ext.ParserFunctions.expr("2+2") inside Lua. Jackmcbarn (talk) 20:59, 21 July 2014 (UTC)
It was in reply to Sphilbrick's q "how to do math in traditional templates". --Redrose64 (talk) 21:53, 21 July 2014 (UTC)
I know how to do something simple like add two numbers in the same string. However, I have wins for each year, and need a total. For example, in Karl_Smesko#Head_coaching_record, the current approach has a separate template for each year, and subtotal templates. As you can see, I calculated the win loss ratio for the Walsh University year, but tpo get the sums of wins and losses for the subtotal and total lines, I need to do it in an external spreadsheet. That works if I always do the updates, but many of these were already created, so adding a new year, which is an upcoming task, is quite a pain.--S Philbrick(Talk) 22:07, 21 July 2014 (UTC)
I think I asked once before and was told I cannot do math across templates, if that makes sense, so I need to build the table as a simple template, to have access to all the values. I'm assuming that is that much rework is needed, it ought to be done in Lua.--S Philbrick(Talk) 22:09, 21 July 2014 (UTC)

## Suggestion for a new tool

With certain articles, we get a lot of editors working at once on the article, with multiple edit conflicts etc. Recently, Malaysia Airlines Flight 17 has been affected by this.

Would it be technically possible to introduce a "timer" preventing the article from being edited for a short period of time (i.e. not more than 5 minutes) after the last edit? Of course, if such a feature was technically possible, there would need to be due discussion as to its desirability, but there's no point in discussing the latter if the former isn't possible, is there? Mjroots (talk) 20:51, 20 July 2014 (UTC)

@Mjroots: Would reasonable use of {{in use}} (with a parameter as needed) be appropriate? GoingBatty (talk) 21:15, 20 July 2014 (UTC)
- No, because that is only a courtesy request, as is {{underconstruction}}. There is nothing to stop an editor from editing an article where these templates are displayed. Mjroots (talk) 21:21, 20 July 2014 (UTC)
@Mjroots: Note that {{under construction}} is an invitation for others to help with editing, whereas {{in use}} is a courtesy request not to edit for a short period of time. GoingBatty (talk) 21:35, 20 July 2014 (UTC)
I believe he's looking for something that's enforced in software, not something that depends on the courtesy, or even the attention of, dozens or hundreds of other editors. WhatamIdoing (talk) 22:29, 20 July 2014 (UTC)
On the actual question: It is technically feasible, but it'll never be agreed to. WhatamIdoing (talk) 22:30, 20 July 2014 (UTC)
I think this is a bad idea. At best, it would mean every act of vandalism would remain for 5 minutes at a minimum. At worst, it would discourage positive contributions and allow users to effectively lock down a page (by timing their next edit to the end of each time period). SFB 16:43, 21 July 2014 (UTC)
I'd already thought of that. One way around this would be to enable admins (or maybe admins and confirmed editors) to be able to edit during the temporary lockdown time. Mjroots (talk) 14:55, 22 July 2014 (UTC)

I noticed that sometimes I have been getting edit conflicts on that same article's talk pages... caused by editors editing different sections (I am relatively sure of this, although I am not certain). Has anyone else experienced this issue? Dustin (talk) 22:34, 20 July 2014 (UTC)

Yes, I ran into that issue on that article's talkpage myself a few times, I believe. Similar matters tend to happen if I take a while writing an edit on huge pages like ANI. AddWittyNameHere (talk) 06:34, 21 July 2014 (UTC)
Flow is intended to replace current Wikipedia talk page system. -- 15:38, 21 July 2014 (UTC)

## LaTeX, Cyrillic, UTF8, oh my!

I'm in the process of converting lots of Bibtex entries into wikipedia-friendly UTF-8. Consider the following bibtex entry taken from Mathematical Reviews:

 @preamble{
"\def\cdprime{$''$} "
}
@article {MR0178390,
AUTHOR = {Erd{\H{o}}{\v{s}}, Paul},
TITLE = {On some geometric problems},
JOURNAL = {Fiz.-Mat. Spis. B\u ulgar. Akad. Nauk.},
FJOURNAL = {B\cdprime lgarska Akademiya na Naukite. Fizicheski Institut.
Matematicheski Institut. Fiziko-Matematichesko Spisanie},
VOLUME = {5 (38)},
YEAR = {1962},
PAGES = {205--212},
ISSN = {0015-3265},
MRCLASS = {50.00},
MRNUMBER = {0178390 (31 \#2648)},
}


Per [7], I'm guessing \cdprime is supposed to be ъ or something similar, and MR def'ed it to a null character on the assumption that most people wouldn't have the cyrillic style file included. But honestly, my LaTeX isn't good enough to be sure that's what's going on. I'm not able to get this to compile on my home machine.

1. Is ъ the intended symbol?
2. Should the start of the full journal name look like "Bъlgarska"?

Thanks, Lesser Cartographies (talk) 04:36, 21 July 2014 (UTC)

(update) Worldcat uses "Bŭlgarska akademii︠a︡" and "Bulgarska Akademii︠a︡ ". Way out of my depth here.... Lesser Cartographies (talk) 04:57, 21 July 2014 (UTC)

No, it doesn't make sense to mix latin and cyrillic letters in one word, so Bъlgarska shouldn't be an option. You can use ŭ if you want. The sound is like the schwa sound of the letter u in the word Bulgaria. It can also be transliterated as a, with or without diacritics, but for English speakers even plain u works. It depends on which of the many transliteration standards you want to follow. Some standards use " (double quote) to transliterate ъ from all languages that use the Cyrillic alphabet, that's because ъ is silent in Russian, so you can't use a or u there. I suspect that line 2 of your bibtex code defines cdprime as double quote. --V111P (talk) 04:17, 22 July 2014 (UTC)
@V111P:, I just figured out how to compile this and the results aren't particularly sensible: B′′lgarska. I'm going to chalk this up to a strange error at MR and follow your advice and use Bŭgarska. Thanks for the help, I really appreciate it. Lesser Cartographies (talk) 06:00, 22 July 2014 (UTC)

Dear technical experts: When I first joined Wikipedia I remember that there was a bot that went around checking and tagging pages for copyright violations. I haven't seen any pages so tagged for some time, and of course the ones it tagged have either been deleted or had tags removed. Can someone tell me the name of this bot and if it's still around? It appeared to be very useful. —Anne Delong (talk) 05:07, 21 July 2014 (UTC)

User:CorenSearchBot and WP:SCV? MER-C 05:23, 21 July 2014 (UTC)
Also see WT:MED#Exhausted which points to WP:Turnitin. CorenSearchBot handles new pages only, not changes to existing pages, and the others are hopes that something might be done for additions to existing pages. Johnuniq (talk) 06:25, 21 July 2014 (UTC)
As noted above CSB only searches new pages. If you want to see some, see Wikipedia:SCV. There are dozens of new ones every day, and not a lot of editors clearing them. If anyone has any spare time...--S Philbrick(Talk) 19:47, 21 July 2014 (UTC)
If the bot only tags new mainspace articles, that explains why I haven't encountered it lately. I've been working mainly with pages in the Category:G13 eligible AfC submissions, which are all at least six months old, although, surprisingly, many of them are copyright violations. It would be nice if the bot could also check newly created pages in the Draft: namespace. Thanks for taking time to reply. Sorry, I won't have spare time to help with that backlog until I clear out my own.Anne Delong (talk) 20:30, 23 July 2014 (UTC)

## Tech News: 2014-30

07:42, 21 July 2014 (UTC)

I'm increasingly seeing links (and sometimes even templates) in section headings. AIUI, this shouldn't be done. How can we encourage editors not to do so? Should we raise a bug for mediawiki to remove such markup from headings? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:13, 21 July 2014 (UTC)

## Ref tags cluttering an article talk page

Have a look at the end of Talk:Malaysia Airlines Flight 17; there are many sections of discussions where editors are proposing or challenging text from the article, and have included said text from the main page, refs tags and all. Is there a way to address this via technical means, e.g. suppress the output of a reflist on a page? Tarc (talk) 14:36, 21 July 2014 (UTC)

Not anymore. See #Missing reference markup will no longer show an error. Until that enhancement was deployed, we had namespace control over the previous error message and did not show it on user and talk pages because of the copy/paste references. This keeps coming up, so I will file a bug report on this. -- 14:40, 21 July 2014 (UTC)
bug 68324 - Cite: Add namespace detection for automatically generated reference list. Now marked as WONTFIX. -- 01:22, 22 July 2014 (UTC)
Well, thanks for trying. The WMF is too busy wasting millions on features no one wants (flow, visual editor) and rejecting small things that may actually be of value to the community. Tarc (talk) 12:13, 22 July 2014 (UTC)
The practical solution is pretty easy, and has the advantage of making it possible to evaluate the sources in that section. WhatamIdoing (talk) 18:16, 22 July 2014 (UTC)

## requesting help for 'help video clip'

Hi, I came across one video clip for ULS help for Telugu language wikipedia as shown below. The clip is usefull but it does not show how to access help page. We will apreciate if some one helps us with simmiller clip for Marathi language.

Thanks & Regards Mahitgar (talk) 15:16, 21 July 2014 (UTC)

Click on the 'cc to change the subtitle language and learn how to type in Telugu on Telugu Wikimedia projects from this video

## Viewing SVGs in IE

I'm running IE11, and I've always used this or previous versions since I began editing in 2006. I've always known that I can't get a full-resolution SVG by clicking on the image when viewing its description page: I have to click one of the links after "This image rendered as PNG in other sizes", or rightclick to get Properties and go to the address given in the "Address (URL)" line, because I've never had software capable of viewing or editing SVGs (aside from Notepad), and as a result it's always asked me if I want to download the SVG, or download software to view it, or something like that.

In the last couple of weeks, I've discovered that this is no longer the case: going to an SVG's description page and clicking on the image will take me to a larger-resolution version of the image, as if I'd clicked on a PNG or JPG. For example, clicking on the image itself at File:NRHP Counties Net Quality.svg takes me to https://upload.wikimedia.org/wikipedia/commons/1/12/NRHP_Counties_Net_Quality.svg without problem. Is this something new with our software, or something new with IE? I've not changed anything with my browser, aside from routine updates from Microsoft which, I suppose, could have included the capability to view online SVGs. Nyttend (talk) 01:05, 22 July 2014 (UTC)

Internet Explorer has included the ability to natively view SVGs since version 9. Nothing really new. — This, that and the other (talk) 01:32, 22 July 2014 (UTC)
@Nyttend: It's been the case for some years that on a file description page (including that for a SVG), clicking the image is the same as clicking the Original file link; this is how I obtained the original SVG files so that I could make my first derivative work way back in 2010. What your browser does upon clicking the image (or the link) is down to itself. When I try it in IE8 (having Windows XP, I can't use IE9 or later), it pops up a box headed "0% of ...NRHP_Counties_Net_Quality.svg from upload.wikimedia.org" and in front of that, another headed "File Download" containing "Do you want to open or save this file?" and some buttons. --Redrose64 (talk) 10:13, 22 July 2014 (UTC)
I was running IE8 until the end of last year, when I bought the current computer. Maybe it's just taken me eight months to notice the additional capability that this newer browser has? Nyttend (talk) 12:21, 22 July 2014 (UTC)

## SUL question

So, according to this, once an account is unified that name is reserved on all Wikimedia wiki's. So I have a few questions:

1. Does this preclude a bureaucrat on a local wiki from renaming a local user to a name that isn't (locally) taken yet (but is globally unified)? Or one that is taken but has zero edits?
2. Does this break the "unification"?
3. Is there a log/view that shows if/when an account was unified?

Back when this feature was enabled I could have swore I successfully unified my account. Then, sometime in 2010 or so, another user wanting to use my username on pt-wiki got a bureaucrat to rename them to my name. Now my account is not unified and refuses to unify as I don't have the password for that account. Is this a bug, or a feature, or am I misremembering that I unified my account? =)

Thanks! —Locke Coletc 01:42, 22 July 2014 (UTC)

1. No. Local bureaucrats have the ability to arbitrarily detach local accounts from global ones using Special:RenameUser.
2. Yes. As you can see from the bottom of Special:CentralAuth/Locke Cole, your account is no longer fully unified.
3. Not to my knowledge. Special:CentralAuth/Locke Cole is probably the closest you can get, but it's hardly comprehensive and there are errors for older accounts.
However, don't fret too much. When we finally do the SUL finalisation and forcibly rename users to resolve every single clash, the user on ptwiki will be renamed out of the way for you and your account will be permanently fully unified; I decided a while ago that if someone had already taken a global account then they'd get to keep it, irrespective of any other factors. --Dan Garry, Wikimedia Foundation (talk) 03:15, 22 July 2014 (UTC)
Sounds good, thanks for your help Dan! =) —Locke Coletc 04:13, 22 July 2014 (UTC)

## Watchlist on Android beta

I regularly use my Android mobile phone to look for changes on my (ridiculously large) watchlist: we're a two-person one-computer household. I'm using Beta but not "experimental". I have set my watchlist to "Hide bot edits from the watchlist", in my preferences. This works fine on the desktop, but seems to be ignored on the mobile: every bot edit is still listed.

Three other annoying factors about the mobile watchlist:

• The only way to see User Talk pages is under "all"
• There is no "more" option at the bottom of each list, so the system restricts how many changes are shown
• Multiple changes to one page are all shown individually, rather than aggregated as on the normal watchlist.

Like many people, I have DGG's talkpage watchlisted. He currently gets a massive number of separate messages from HasteurBot every morning. As a result, I cannot see on my mobile watchlist any changes made to User talk pages between the last time I looked and about 2am UK time: the day's bundle of HasteurBot messages shifts anything earlier into invisibility.

Is there any chance of any of the 5 contributing factors being fixed?

1. Make the "hide bot edits from watchlist" preference work on mobile
2. Add a "more" option at bottom of watchlist listings on mobile, so I can see the rest of the changes
3. Create a 5th heading for the mobile watchlist, for "User talk" (or include them in "Other")
4. Aggregate changes to a page so that they list as one item in the mobile watchlist, capable of expansion, as on the desktop version
5. Get HasteurBot to aggregate its daily messages per talk page.

I get the feeling that mobile users are considered to be the great unwashed, encouraged to upload photos but not expected to be serious editors. More and more people expect to be able to use their phone for a wide range of activities, and aren't always sitting at a desktop. Please can someone offer some help in this area of mobile watchlists? Thanks in advance! PamD 07:19, 22 July 2014 (UTC)

bugzilla:68365, bugzilla:68367, bugzilla:68368, bugzilla:68369. And it is not 'unwashed', it is strategy. The thing is still being build and the initial focus was to make Wikipedia accessible to readers on Mobile devices. Only THEN the team would start looking at what editor related functions would make sense on mobile and slowly build that out. —TheDJ (talkcontribs) 10:02, 22 July 2014 (UTC)
Thanks. Will await progress with interest. PamD 21:22, 22 July 2014 (UTC)

## is there a way to change the highlighted reference colour?

on pages with many references i find it difficult to find the reference i clicked because the highlight colour is too much like the page colour. is there a way i can make it more obvious? — Preceding unsigned comment added by Xxami (talkcontribs) 10:31, 22 July 2014 (UTC)

You can put the following rule in your common.css and change the color to your liking:
ol.references li:target, sup.reference:target, span.citation:target {
background-color: #DEF;
}

-- [[User:Edokter]] {{talk}} 10:49, 22 July 2014 (UTC)

## Tables / HTML

What is the correct sintax for some HTML code?

Variant A Variant B Variant C
background bgcolor=#RRGGBB style="background-color:#C0C0C0;" style="background:#C0C0C0;"
RGB - U/l #RRGGBB #rrggbb
RGB - 3/6 #RGB #RRGGBB

For now it's all, but I think I had something more :) And am I right, that mixing bgcolor and background/background-color in one article could cause some problems with some browser? I read about it in one talk page. And which is the place (Wikipedia, Internet) where I could get the correct sintax?

For the tables, I think the Help:Tables could be expanded (in code size). These are the changes (never mind the reference, it is unrelated). And the tool warned for the deprecated HTML elements. --Edgars2007 (talk/contribs) 15:06, 22 July 2014 (UTC)

Technically, variant B is the only correct one (though the RGB values may be specified using eiter 3 or 6 octets in either upper or lower case). Variant C will work, but is actually a shorthand for background-color, background-image and background-position combined. If you only want to change the color, don't use it to prevent potential CSS inheritance issues (when overriding it on a cell level for instance). -- [[User:Edokter]] {{talk}} 15:59, 22 July 2014 (UTC)
See Wikipedia:Village pump (technical)/Archive 127#Background colour on mobile devices regarding bgcolor= and compatibility. If you find that bgcolor= is still mentioned in help pages, please list them here and we'll fix them up. --Redrose64 (talk) 17:48, 22 July 2014 (UTC)
Thanks. What about making changes to Help:Table? --Edgars2007 (talk/contribs) 08:51, 23 July 2014 (UTC)
I have already amended it to not use the bgcolor= attribute (six weeks ago). What's still wrong with it? --Redrose64 (talk) 09:12, 23 July 2014 (UTC)
I was talking about these changes (most of which were made with Dispenser Reflinks tool), there are some deprecated HTML elements, too. --Edgars2007 (talk/contribs) 13:54, 23 July 2014 (UTC)
I've eliminated all use of the bgcolor= attribute from Help:Table. Is any of the other deprecated markup actually causing problems? --Redrose64 (talk) 15:15, 23 July 2014 (UTC)
I just thought, that help page should represent correct sintax, so that people could use it (at least those, who read that page), but OK, if I'm wrong, then it's my problem :) And yes, I know about the WP:AINT. --Edgars2007 (talk/contribs) 15:26, 23 July 2014 (UTC)
There is a demonstrable problem with the bgcolor= attribute on mobile devices, this is mainly because that attribute was never a formal part of the HTML spec except when used in the <body> tag, so it is good practice to hunt down and fix such markup.
However, a lot of other deprecated markup was valid at some time or other - this includes align= on a <table>, <tr> or <td>; valign= on a <td>; and width= on a <th>. In particular, the border= attribute is still valid on the <table> tag and is not deprecated. Some of the changes made in that edit to User:Edgars2007/tables was completely unnecessary, such as changing underscores to spaces in the left-hand side of piped links, changing the case of hex colour values, and adding spaces in section headings. Trivial changes like those make it difficult to spot the real changes. --Redrose64 (talk) 16:25, 23 July 2014 (UTC)
The latest HTML5 draft is showing align= on <table>, <tr> or <td> under "11.2 Non-conforming features": "Elements in the following list are entirely obsolete, and must not be used by authors". border= on <table> is not showing as obsolete or deprecated, but the W3C validator gives a warning that "The border attribute on the table element is presentational markup". -- 17:02, 23 July 2014 (UTC)

## My preference for the desktop version of Wikipedia on the iPad doesn't stick! Any solutions, including JavaScript?

I am using Wikipedia in Chrome on the iPad. When I visit the site, I am redirected to the mobile version. I always tap on the desktop link at the bottom of the page and I get the desktop version. Wikipedia used to remember my preference and give me the desktop version on subsequent visits, but now it always redirects me to the mobile version. I don't want the mobile version - I want the desktop version! Any solutions - I don't mind using JavaScript?

Tracey Lowndes (talk) 17:35, 22 July 2014 (UTC)

Please see #two annoying problems above. --Redrose64 (talk) 17:49, 22 July 2014 (UTC)

## RfC: Should the hidden navbar be removed from the base Stub and WikiProject banner templates?

Should the CSS-hidden navbar be removed from the base Stub (1.8 million pages) and WikiProject banner (5.5 million pages) templates? -- Netoholic @ 23:44, 22 July 2014 (UTC)

### Survey

• Procedural close as wrong venue. It has been pointed out before that RfCs are not hosted at VPT; if the template's own talk page is unsuitable (why might that be?), it's a WP:VPR matter. --Redrose64 (talk) 08:07, 23 July 2014 (UTC)
This applies to templates, not policies, and is fairly technical to understand. And since the identical issue is present on two different templates, no one talk page is appropriate. -- Netoholic @ 09:05, 23 July 2014 (UTC)
VPR is proposals, not policies. That page is currently carrying several RfCs, some of which are technical (including the very first one on the page). --Redrose64 (talk) 09:40, 23 July 2014 (UTC)

## Need directions with MediaWiki:Spam-blacklist

There is a very simple way to bypass the MediaWiki:Spam-blacklist and insert any blacklisted link, and this was exploited recently. Where to report this bug for urgent attention? The related talk pages don't seem active, and, though the exploit is simple, I hesitate to post it in open. Any advice? Materialscientist (talk) 05:10, 23 July 2014 (UTC)

securitywikimedia.org or bugzilla (check the options, public posting is the default). MER-C 06:51, 23 July 2014 (UTC)
https://bugzilla.wikimedia.org/enter_bug.cgi?product=Security allows creating a bug report with very restricted visibility. I am aware of some reports about Spam Blacklist, so dropping an email to the security mailing list might be less work to start with. :) --AKlapper (WMF) (talk) 09:32, 23 July 2014 (UTC)
There's no real problem here. It's well-known that it's trivial to bypass the spam blacklist. It's also not fixable, since fixing it would require checking the blacklist every parse, which has been tried before and undone because it was so bad for performance. Jackmcbarn (talk) 16:07, 23 July 2014 (UTC)

I have just repaired a broken-link footnote and now see a small padlock symbol beside the footnote in the "References" section of the article. None of the other footnotes show this symbol. Does this affect the footnote in any way? How can I ensure the symbol does not appear when I next mend a broken-link footnote? What does the padlock symbol mean anyway? You can see the padlock at footnote #171, "Another wave of bombings hit Iraq", in Islamic State of Iraq and the Levant. --P123ct1 (talk) 09:26, 23 July 2014 (UTC)

@P123ct1: The padlock appeared because you used a https: URL in this edit. The web.archive.org website allows both http: and https: forms, so you could have used http: - but it is better to omit it entirely, to give a protocol-relative URL.
Please note that a URL of an archive site shouldn't be put in the |url= parameter, but in |archiveurl= instead, like this. --Redrose64 (talk) 09:51, 23 July 2014 (UTC)
Thanks for making the adjustment. I had no idea about this. There is nothing in the Wiki help on link-rot about how to deal with archive.org URLs, or have I missed it? I have used the Wayback Machine a lot to mend broken links, but never had this problem before, so can only assume it always came up with an http. --P123ct1 (talk) 11:30, 23 July 2014 (UTC)
Some websites allow only the http: form; some allow only the https: form; some allow either. For those that allow either, it can normally be omitted - such as [//www.example.com Example web page] or {{cite web |url=//www.example.com |title=Example web page }}, and this is known as a protocol-relative URL. This does not work for bare URLs like http://www.example.com
The {{wayback}} template uses the https: form internally, so you always get the little padlock when you use that template. It should be possible to alter it to be protocol-relative, and I see from the template's talk page that a discussion was raised about six months ago on this matter, but which doesn't seem to have been resolved. --Redrose64 (talk) 13:47, 23 July 2014 (UTC)
I wonder why we kept the icon for HTTPS while removing all the others? (PDF is added locally). -- 20:32, 23 July 2014 (UTC)

## Problem with template

I'm not sure where to post this, but this seems a good fit. A 2013 (!) edit to Template:Current Kenyan MPs updated the template, but also changed something so that the information will not display. See my post on the talk page for a diff. This needs fixing. -- 13:45, 23 July 2014 (UTC)

Replied there. --Redrose64 (talk) 13:52, 23 July 2014 (UTC)

## Can you transclude pages from other projects?

I would like to transclude Tech News weekly summaries on my user page: {{m:Tech/News/Latest}}. Is this possible? Wbm1058 (talk) 14:16, 23 July 2014 (UTC)

Or a solution similar to {{Signpost-subscription}} for Tech News? Wbm1058 (talk) 14:26, 23 July 2014 (UTC)
It's not possible to transclude across wikis. A number of things would be much easier if it were. Re your second suggestion: you could ask for this at m:Talk:Tech/News. --Redrose64 (talk) 15:06, 23 July 2014 (UTC)
Thanks for the tip to look at that talk page, where I found the section Template for user pages?, which pointed me to {{Latest tech news}}. Just what I was looking for! Look at the syntax of that template code. I'll have to study that to figure out how it magically transcludes the current news. Wbm1058 (talk) 16:14, 23 July 2014 (UTC)
I see that I'm just the third editor to transclude {{Latest tech news}}. A tip of the hat to the Technical Communications Manager, Wikimedia Foundation for creating it. Wbm1058 (talk) 19:45, 23 July 2014 (UTC)
He also set up Wikipedia:Tech news and signed that page up for Global message delivery of the news from meta. #lst: must be a parser function for the last section on the page (i.e., the most recent mass message delivery is added at the bottom). Nice! I don't see #lst: documented at Help:Magic words. @Guillom: Where is that documented? Wbm1058 (talk) 20:16, 23 July 2014 (UTC)
#lst is labeled section transclusion. But it won't work across wikis. It is not documented at Magic Words because it is part of a software extension. -- 20:18, 23 July 2014 (UTC)
Thanks, I recall having run into documentation of that feature before but had never seen it in action, and this specific example is helpful. I just noticed the <section begin="technews-2014-W17"/> and <section end="technews-2014-W17"/> tags etc. in Wikipedia:Tech news that make it work. Too bad that per mw:Extension:Labeled Section Transclusion#Transcluding sections by headings we can't just use the regular headings, but I guess the work-around isn't that difficult.
Is there a list of all the extensions that are enabled on English Wikipedia anywhere? Wbm1058 (talk) 01:08, 24 July 2014 (UTC)
See Special:Version for a listing. Fwiw... we use #lst like crazy over on Wikisource and have scripted/templatized several solutions to make using it a bit easier, though still nothing simple abut using "regular" headings there as well. -- George Orwell III (talk) 01:50, 24 July 2014 (UTC)
... and fwiw - I recall cross-domain transclusions through the API are possible with some scripting(?). Somebody tried something like that with s:MediaWiki:InterWikiTransclusion.js but we never really wound up using it so I can't tell you much more about it. -- George Orwell III (talk) 01:58, 24 July 2014 (UTC)
We use {{#lst:}} for the Citation Style 1 error help pages to transclude the help section to the tracking category. I have used it a few other places. -- 02:15, 24 July 2014 (UTC)

## Looking for user script

Is there, or can there be a script that would change selected/detected ALL CAPS as in this diff ? I assume maybe AWB has a setting for this but, I'm hoping for a .js script or something or even a lab tool. Thanx, 18:54, 23 July 2014 (UTC)

• Is "navigation links" the right term to use to refer specifically to the links that appear at the top of every page while viewing Wikipedia, or is there some other preferred term?
• Is adding addPortletLink() statements to one's own "common.js" file still the recommended way of customizing these links, or has this been deprecated in favor of some other method?
• Can the default links be removed or redefined? If so, how?
• I can't seem to find any documentation for addPortletLink(); using Google I was able to locate only this brief discussion. Help?

Thanks, — Jaydiem (talk) 19:48, 23 July 2014 (UTC)

The gadget 'Add a "Sandbox" link to the personal toolbar area.' calls it the "personal toolbar area" but its script calls it the "personal portlet menu"; it uses mw.util.addPortletLink(). --Redrose64 (talk) 20:10, 23 July 2014 (UTC)
There is some documentation here. -- WOSlinker (talk) 20:22, 23 July 2014 (UTC)
I don't know about removing links, but I was able to add one. Look for the portlet code in User:Jonesey95/vector.js. — Preceding unsigned comment added by Jonesey95 (talkcontribs) 20:37, 23 July 2014 (UTC)
There is proper documentation for addPortletLink here. —TheDJ (talkcontribs) 07:12, 24 July 2014 (UTC)

## User:Mr.Z-man/closeAFD.js (2)

... does not seem to be working properly (it's been a while since I was going through the AFDs, back in March it was still fine). I found that a similar problem has been discussed back in 2012 already, then fixed. But there may be another reason now. Help kindly requested. --Tone 20:45, 23 July 2014 (UTC)