Wikipedia:Village pump (technical)/Archive 129

If I read an article to look for information (as a reader rather than an editor), I usually click on "history" to see whether it's been the subject of controversy, vandalism, etc (and I advise others to do so too, when discussing the reliability of Wikipedia). If I read an article on mobile (Android, beta), I see "Last edited x days ago by Editor", and I know that if I click on the first half of that line, even though it isn't bolded, I get to see the history. If I click on a diff, I get to see the diff and, below it, a link to the editor who made it. If I follow that link and they're a named editor, I get to see a rather strange profile page (is it really appropriate to show the latest file they uploaded, however many years ago? Or to identify the editor who last thanked them - thanking is usually confidential, surely?). I can get to see their contributions list, by clicking on the number of edits where it's stated: "Joined over x years ago with y edits and z uploads". I can also get to their talk page, to make a comment.

But if it's an IP editor I don't get any of that. I get the message "Redirecting to editor", followed by a flash of "This page doesn't exist, why not be bold and create it?", and am then set up in edit mode to create a user page for the IP editor. Not a good idea, surely. In fact, I think it's a bug. Or three bugs:

(a) It's not appropriate to encourage mobile editors to create user pages for IP editors

(b) It should be possible for mobile readers to get to see the user contributions for an IP editor (OK this is probably more for mobile editors: I want to see whether the bit of vandalism I've just found on my watchlist is part of a spree of related rubbish, but even for an IP address the contributions list can give an indication of the seriousness of the editor). The only way to do this at present is to get back to the article, go into desktop mode (which involves stretching each page manually to make it a just-legible font size on my not-very-smartphone), click "history", get the editor, get the contributions list ... only to find it was their one and only edit, usually.

(c) It should be possible for mobile readers to get to see, and edit, the User Talk page of IP editors. I've just checked, and the above result, that clicking the red IP address link leads to an offer to create a user page for them, applies whether or not that IP address has a User Talk page.

A possible solution to all 3 problems would be if clicking on an IP editor led to a "profile" page saying something like "The editor using this IP address has not registered a Wikipedia username. There may be more than one person editing from this IP address. The most recent edits from this IP address are shown _here_. See/Start the _User Talk Page_ for this IP address." (As appropriate) PamD 20:09, 25 July 2014 (UTC)

Most of this is for Maryana, but I can tell you that Thanks is only semi-confidential at best. You can see in the public logs who is thanking whom. You can't see which diff the person was thanked for. However, for people involved in disputes, you can often guess very easily. Whatamidoing (WMF) (talk) 22:55, 25 July 2014 (UTC)

But User:Maryana_(WMF) describes her involvement in Mobile as being in the past and says that she's now working on Flow. @Maryana (WMF): are you still involved in Mobile? The comment about Thanks was just in passing (just one of the weirdnesses of the Mobile interface, that something normally not displayed is here displayed prominently, however long ago the thanking may have taken place): my main concerns are the bullet points shown above. PamD 10:46, 28 July 2014 (UTC)

They rearranged the product managers: Danny Horn now has Flow, Maryana has Mobile web and Deskana has Mobile apps. (And now that I've got them sorted out, they'll probably rearrange everyone again.  ;-) Whatamidoing (WMF) (talk) 19:00, 28 July 2014 (UTC)

• PamD, that behavior (IP link in diff taking you to the userpage) is indeed a bug; thanks for reporting it! The link should go to IP contribs. Maryana (WMF) (talk) 22:55, 28 July 2014 (UTC)

When restoring a deleted article, one enters a reason and clicks on the "restore" button". I assume that button activates some script. Is that scrip user accessible or only to the development team?

My motivation is that when restoring a CSD or Prod, one then has to edit the restored article and remove the CSD or prod template. There may be times this needs to be done manually, but it would be nice to have another option. One button could still say "restore" and the next one "Restore and remove CSD/PROD notice".

I was contemplating whether one could build a script to do the restore and remove the notice semi-automatically, but it occurs to me that the capability ought to be done in the restore step.--S Philbrick(Talk) 14:31, 26 July 2014 (UTC)

The button triggers an HTML request. I guess someone could build a javascript that would cleanup a page after such an action, by overriding this HTML request and doing the same actions using the API, then following a successful undelete, do some edit actions to remove the templates. Not impossible. Then again, there might be exceptions to this, so it would probably have to ASK with a dialog if the templates should be removed. —TheDJ (talk • contribs) 09:10, 28 July 2014 (UTC)

So what should I do next, given that I cannot write javascript. Should I search fro someone who can, or should I file this as a feature request via Bugzilla?--S Philbrick(Talk) 17:08, 28 July 2014 (UTC)

This is clearly a javascript issue, not a MediaWiki software issue, so you should take a javascript approach. עוד מישהו Od Mishehu 06:52, 29 July 2014 (UTC)

Apparently multiple uses of the DISPLAYTITLE magic word on one article produce a warning at the bottom of the page: Warning: Display title "Bambi Kino" overrides earlier display title "<i>Bambi Kino</i>". here, for example. While that can be resolved by setting the album infobox not to italicize the title, I wonder whether this warning isn't too false positive-prone to be useful. Thoughts? Huon (talk) 17:29, 26 July 2014 (UTC)

This is new from mw:MediaWiki 1.24/wmf14#Core changes:

• #af66fecb - Warn when DISPLAYTITLE is used more than once (T52449)

It works poorly at the English Wikipedia where DISPLAYTITLE is often used by infoboxes and changed later. Without a tracking category it seems hard to find the occurrences and set the infobox parameters to not use DISPLAYTITLE. PrimeHunter (talk) 20:52, 26 July 2014 (UTC)

Please note the new parameters: {{DISPLAYTITLE:...|noerror}} suppresses the warning and {{DISPLAYTITLE:...|noreplace}} does not replace the DISPLAYTITLE. noerror could be added to the infobox template, couldn't it? Raymond (talk) 07:21, 27 July 2014 (UTC)

I don't think that adjusting the infobox template would do much good, as it's likely the infobox that's being overridden. It's the second call that needs "noerror" added.

The error message can be adjusted using MediaWiki:duplicate-displaytitle. The best course of action would be to add a tracking category to that message, much like we already do with MediaWiki:duplicate-defaultsort. If the problem is widespread enough, the message could (temporarily!) add the tracking category with no visible error message until people have a chance to clean things up. Anomie⚔ 23:46, 27 July 2014 (UTC)

I decided to just be bold and add the tracking category. It should populate as pages are edited or otherwise purged. This isn't to say we shouldn't do the "tracking category with no message" idea if further discussion decides that's a good idea, but we certainly want a tracking category so we may as well not wait on that part. Anomie⚔ 23:52, 27 July 2014 (UTC)

Seems to be working, that's how I found this. --Redrose64 (talk) 08:11, 28 July 2014 (UTC)

Hello. I have noticed that the {{nobr}} template uses the HTML <span> tag rather than converting spaces to not breaking spaces in the HTML rendering. Previously I assumed both methods to keep text together to be equivalent, but now I'm afraid that they will have different behaviors. For example, I think that it may be possible (I'm not an expert in HTML) that a browser may copy text produced by the template as containing ASCII spaces, while text using &nbsp; will be copied as such (U+00A0). I think that just with the issue of Unicode superscripts and the usage of <sup>, Wikipedia should settle on a single style and standardize it in its manual of style. I suggest modifying the {{nobr}} template so that it replaces spaces with U+00A0. I don't know which one to use when writing and editing articles, please provide me with feedback on this choice (Accounting for the current situation) as well (I tend to use {{val}} for quantities, since it's the most specific template). QrTTf7fH (talk) 17:37, 27 July 2014 (UTC).

The <span>...</span> element does nothing, other than define the scope of its attributes. It is the class="nowrap" attribute, as used in {{nobr}}, that does the work; this class is associated with the rule

.nowrap,
.nowraplinks a,
.nowraplinks .selflink,
sup.reference a {
  white-space: nowrap;
}

This uses the white-space property, which has been a perfectly acceptable way of controlling word wrapping since CSS 1.0 - over seventeen years ago. It's in CSS 2 (three years old) and will (virtually) certainly be retained in CSS 3 when that finally reaches the W3C Recommendation stage. --Redrose64 (talk) 18:59, 27 July 2014 (UTC)

Thanks for the information, but it doesn't answers my query. — Preceding unsigned comment added by QrTTf7fH (talk • contribs) 14:13, 28 July 2014 (UTC)

Non-breaking spaces are presentational; they are not supposed to be part of the content. Most browsers substitute them for normal spaces anyway when copied. If you still encounter them, it is because of some old template, but CSS is the preferred method to create non-breaking text. -- [[User:Edokter]] {{talk}} 14:20, 28 July 2014 (UTC)

I have found something strange on a page named Kiler (company). External links and References sections are "mixing" one into another. Is something wrong with the template coding? --BiH (talk) 08:06, 28 July 2014 (UTC)

A <ref> tag was left unclosed:

==History==

From 1984 onwards members of the Kiler family opened a number of supermarkets in the Istanbul area, which in 1994 were incorporated as Kiler Supermarket Gıda Sanayi ve Tic. A.Ş. By 2004 the group had 33 stores in the Istanbul area and went to acquire chains of supermarkets in other parts of Turkey. By 2010 Kiler had 172 stores in 26 cities. Stores range from 600 to 2,500m2 but the Kiler concept is based on supermarkets with an average size of 900m2. <ref name="About Kiler">{{cite web|url=http://www.kilerkurumsal.com/content/about.aspx|title=Company Profile |publisher=kilerkurumsal.com|accessdate=2014-07-28}}

==References==
{{Reflist}}

==External links==
* {{Official website|http://www.kiler.com.tr}}

{{Istanbul Stock Exchange companies}}

Note the lack of a </ref> at the end of the {{cite web}} template. 23W 08:35, 28 July 2014 (UTC)

T17712 --  Gadget850 ^talk 15:07, 28 July 2014 (UTC)

08:09, 28 July 2014 (UTC)

For the past couple of days, I have experienced errors in Firefox when trying to view various Wikipedia pages.

Has anyone else had this problem?- MrX 17:28, 28 July 2014 (UTC)

https://support.mozilla.org/en-US/questions/982298 or https://support.mozilla.org/en-US/questions/991444 ? --AKlapper (WMF) (talk) 13:06, 29 July 2014 (UTC)

Thank you.- MrX 14:05, 29 July 2014 (UTC)

I have a proposal of cross wiki notifications in one list. That means that no matter in which wiki you work in the moment, there is only one notification list. If you work in q:en: and get a post in s:de:, you will be alerted within the same second and will have a chance to respond immediately. --Janezdrilc (talk) 11:22, 29 July 2014 (UTC)

There are bugs about this already. --Glaisher (talk) 11:35, 29 July 2014 (UTC)

I am reporting what appears to be a bug in Notifications, and my workaround to suppress messages such as

• Query from No Page
• Sumatran muntjac from List of megafauna

Since these unwanted messages were not the usual Thank or Mention notifications, I altered my Preferences, Notifications, uncheck all but Thank or Mention or User rights, Save.

I kept the check marks for New message indicator and Talk page message.

Since this change, there have been no notifications of Query from [No Page], etc., which started appearing 4 or 5 days ago. --Ancheta Wis   (talk | contribs) 14:38, 25 July 2014 (UTC)

This is a known bug – it happens when the page which the notification was about gets deleted. See T52829. Matma Rex talk 18:37, 25 July 2014 (UTC)

Happy to report that my Notifications workaround is letting in the Thank or Mention notifications. --Ancheta Wis   (talk | contribs) 07:24, 31 July 2014 (UTC)

Hello everyone! Here's something that either seems to be an issue with the "what links here" feature, or I'm horribly missing something. In a few words, when I try to see what links to the kernfs disambiguation page, I get over 50 pages; however, when checked by hand (at least for 10+ I've checked) those pages have no links to the kernfs page, while they include the {{Linux kernel}} template. This template used to have a link to kernfs, but it has been replaced with a link to kernfs (Linux).

Any clues? Am I wrong somewhere? — Dsimic (talk | contribs) 21:13, 25 July 2014 (UTC)

For about a year now, there has been a problem with the job queue whereby a change to the linking within a template such as {{Linux kernel}}, the what links here has often failed to update (there are other demonstrable problems too). There was definitely a change to the job queue software about that time, connected with Visual Editor, but various explanations have been put forward, ranging from "there is no problem, it's supposed to work like that" to "yes it is a problem, but we don't really know how to fix it". --Redrose64 (talk) 22:09, 25 July 2014 (UTC)

Thank you for the explanation! As far as I can see, unfortunately there's little to be done there. — Dsimic (talk | contribs) 22:20, 25 July 2014 (UTC)

Sometimes, if you leave it a few days, it sorts itself. Or it might take weeks. If you get fed up waiting - or it's clear after a month or three that nothing is happening - the only fix is to WP:NULLEDIT every page that is in "what links here" that shouldn't be. That won't fix pages that should be in "what links here", but aren't. In a recent post on this page, the forcerecursivelinkupdate API call was suggested, but I've never succeeded in getting that to work. --Redrose64 (talk) 22:59, 25 July 2014 (UTC)

Hm, that's pretty much crazy, if you ask me. How can it be that WikiMedia developers can't fix this issue, what's even more surprising knowing that it's an old and well known bug? Even more, I'm receiving "Kernfs (Linux) was linked from XYZ" notifications for articles that have {{Linux kernel}} template included, and by no means links to kernfs (Linux) were added to those articles in referenced edits – that seems to be inline with your description of updates to internal caches upon editing pages. — Dsimic (talk | contribs) 00:25, 26 July 2014 (UTC)

From what I've been told, the HHVM project which is being worked on, which should improve performance of MediaWiki across the board, will also increase the rate at which jobs in the job queue are processed. As part of the phasing in of HHVM, part of the job queue is currently running on HHVM, but unfortunately that part doesn't increase the rate. The plan is that the rest of the queue will get migrated over, but only when it's ready. However, bear in mind that I am only relaying what I have been told as I am only tangentially involved in this project. --Dan Garry, Wikimedia Foundation (talk) 01:00, 26 July 2014 (UTC)

So that isn't a bug, but an issue associated with too much data? — Dsimic (talk | contribs) 01:06, 26 July 2014 (UTC)

@Dsimic: In fact, I don't know how it's classified. I was just commenting on the fact that there is engineering work being done that'll speed the queue up. --Dan Garry, Wikimedia Foundation (talk) 01:30, 26 July 2014 (UTC)

That sounds good to me, the issue/bug/whatever is being worked on. — Dsimic (talk | contribs) 01:34, 26 July 2014 (UTC)

Just as a note, "what links here" looks good now for kernfs, seems that some internal caches got refreshed over these few days. — Dsimic (talk | contribs) 05:14, 27 July 2014 (UTC)

It would be even better to be able to see what pages link to something other than only in a navbox. --NE2 01:18, 26 July 2014 (UTC)

Totally agreed. — Dsimic (talk | contribs) 01:23, 26 July 2014 (UTC)

We've been asking for that since at least 2005. From what I've read in previous discussions, the most we can hope for is to have an outside tool (running at tools.wmflabs.org) working from a copy of the database. It wouldn't be real-time, but it would be adequate for most purposes. Whatamidoing (WMF) (talk) 22:24, 27 July 2014 (UTC)

Yeah - this one is "it would be good but it's not possible to do it without rebuilding everything", simply due to the way the page-links are recorded in the database. Sadly rebuilding everything is not a practical solution :-) Andrew Gray (talk) 23:05, 29 July 2014 (UTC)

That's just one of the things that look simple from the outside, but the story is completely different on the inside. BTDT, numerous times. :) — Dsimic (talk | contribs) 04:32, 31 July 2014 (UTC)

I get this message even when I have not saved a page, for instance after having looked at the history of an article, when I press the back button.

However, when I look at the history again, nothing has been saved.

HandsomeFella (talk) 12:07, 29 July 2014 (UTC)

Always in that situation? Where is "the back button"? Which browser and operating system is this? --AKlapper (WMF) (talk) 13:07, 29 July 2014 (UTC)

Browser: IE 11, operating system: Windows 7. The "back" button is the top left button.

When I posted this, it seemed to occur every time I did it, but now it seems to have gone away.

HandsomeFella (talk) 14:50, 29 July 2014 (UTC)

HandsomeFella, does this happen if you take these steps in order?

1. Make a change and save it
2. Go immediately to the history page
3. Go back (to the page that you just saved)

Whatamidoing (WMF) (talk) 15:55, 29 July 2014 (UTC)

That sequence appears similar to what I did, but now that I tried, the problem was gone.

HandsomeFella (talk) 17:59, 29 July 2014 (UTC)

HandsomeFella Are you using VisualEditor when you do this, or wikitext? Steven Walling (WMF) • talk 22:20, 31 July 2014 (UTC)

I just edit straight-up. HandsomeFella (talk) 06:10, 1 August 2014 (UTC)

It seems that the code [[w:File:Example.jpg]] makes the image display at its full resolution. See for example Wikipedia:Help desk/Archives/2008 June 29#Resizing images already used on Wikipedia, which contains images File:YGW Cover 1.jpg and File:ID eNTITYvol1cover.jpg. Looking at the linked discussion, it would seem that MediaWiki presumably used to link to the file instead of displaying it when using an interwiki prefix to enwiki. Has MediaWiki been changed? In any case, it is possible that lots of images currently are displayed unintentionally on various talk pages across the project. This makes it harder to read the talk pages, and in some cases, it makes the talk pages violate WP:NFCC#9.

What should be done with these files? Per WP:NFCC#9, it is at least necessary to do something with the non-free files. If a colon is added (that is, [[:w:File:Example.jpg]]), then the images will again become linked. Maybe a bot could change all pages with inappropriate links? Or should MediaWiki be changed?

Note that there are two namespace names ("File" and "Image") and at least two interwiki prefixes pointing at this project ("w" and "en"). You get the same behaviour regardless of which interwiki prefix and regardless of which namespace name you use. Also note that images display if you bundle multiple interwiki prefixes in a row, e.g. [[w:w:en:File:Example.jpg]], as long as all prefixes point at this project. Images do not display if routed via another project (e.g. m:w:File:Example.jpg).

This problem probably also causes disruption on other projects as well. --Stefan2 (talk) 13:35, 29 July 2014 (UTC)

Thats does seem like a bug. It also implies one can transclude an image from another project, but that is not the case; that (correctly) produces a link. But local file links are interpreted as being transclusions instead of links. The obvious workaround is to remove the prefix, as it is redundant anyway. In the mean time, I have reposted the bug here. -- [[User:Edokter]] {{talk}} 13:54, 29 July 2014 (UTC)

Either add a colon at the start ([[:w:File:Example.jpg]] → w:File:Example.jpg) or remove the "w" ([[:File:Example.jpg]] → File:Example.jpg) - it's the same issue as Wikipedia:Village pump (technical)/Archive 128#w:(lang) links. --Redrose64 (talk) 14:32, 29 July 2014 (UTC)

The issue is a regression; it didn't use to act like this. -- [[User:Edokter]] {{talk}} 16:00, 29 July 2014 (UTC)

Stefan2: This one is my fault. It would only be affecting English-speaking wikis, as well as Meta, Commons (new "c:" prefix only) and a few other minor wikis. I will work to get it fixed ASAP. — This, that and the other (talk) 10:42, 30 July 2014 (UTC)

When did it become possible to move categories to another title? I remember this was not technically possible until recently. What was the precise date when this function was enabled? --Theurgist (talk) 12:14, 30 July 2014 (UTC)

May 22? Wikipedia:Administrators' noticeboard/Archive262#Category pages will be movable soon. --Edgars2007 (talk/contribs) 12:22, 30 July 2014 (UTC)

Note that the articles belonging to the category will not appear on the new name; instead, they will be presented at the old name (which will not be a redirect), until moved manually (or with a bot). This really is a very limited functionality. Matma Rex talk 14:02, 30 July 2014 (UTC)

See also Wikipedia talk:Moving a page#Category moves. For now, the WP:CFR and WP:CFDS processes should still be used, although Cydebot (talk · contribs) is still using the old cut&paste method for renaming a cat. --Redrose64 (talk) 14:13, 30 July 2014 (UTC)

I'm a little confused as to why WP uses a gadget named charinsert and an extension named charinsert. All the other WMF projects don't include a charinsert gadget. I can see that MediaWiki:Edittools gets used when JS is unavailable and that MediaWiki:Edittools.js gets called when JS is enabled. That script loads MediaWiki:Gadget-charinsert-core.js but that was already loaded by a hidden gadget. So I have two questions. What does the charinsert gadget do for WP (how is it different from the extension) and why did Gadget-charinsert-core.js have to be loaded by Edittools.js and the hidden gadget? Thanks, -24^Talk 17:39, 30 July 2014 (UTC)

Edokter, one for you I think. --Redrose64 (talk) 19:14, 30 July 2014 (UTC)

Passing to Helder.wiki, he came up with this structure. -- [[User:Edokter]] {{talk}} 20:30, 30 July 2014 (UTC)

Having had a look, I remember that MediaWiki:Edittools.js is only there to facilitate other projects that import this file (the code used to be there before being moved to the default gadget); it is not loaded automatically. The gadget now governs whether Charinsert-core is loaded, but only when the proper user preference is set. -- [[User:Edokter]] {{talk}} 20:36, 30 July 2014 (UTC)

Yep! "MediaWiki:Edittools.js" is working just as a "redirect". It is not used by English Wikipedia.

I suggested at MediaWiki talk:Edittools/Archive 9#MediaWiki:Edittools.js that we should add a mw.log call to it, so that users who are importing the code from the old title receive a notice in the console. It seems we never did that though.I added the warning.

For more details on the implementation of the gadget, see MediaWiki talk:Edittools/Archive 9#Why is this loaded for readers? Helder 21:57, 30 July 2014 (UTC)

Does anyone have any idea what is causing the lag? The changes can only be seen after around ten minutes. Dustin (talk) 04:28, 1 August 2014 (UTC)

Lag is back to normal now. The high lag was caused by a script that is being used to populate some newly added database fields (T62618), which because of a bug, was running too fast for the watchlist/contributions DB server (db1055) to keep up. That script has been stopped on enwiki until it can be fixed. (see #wikimedia-operations IRC log) PleaseStand (talk) 06:45, 1 August 2014 (UTC)

I'm not a registered user. I frequently use my mobile (android) to access Wikipedia but I'm facing trouble. I can't edit pages from the mobile version Wikipedia. Even this edit was made by toggling to desktop version from mobile. This is a serious problem for me, why can't I edit pages from the mobile version?? I can't register an account due to privacy reasons. I want to edit pages by mobile without getting registered. Is it possible?? Since the slogan of Wikipedia says "anyone can edit" - why can't I edit?? There are some countries were desktop, laptop etc is not available widely; they use there phone. I think it is acting as a barrier between people like me and editing a page. I hope someone can help me. :) 101.221.128.88 (talk) 13:55, 25 July 2014 (UTC)

You will get better privacy editing with an account than without. Johnbod (talk) 13:57, 25 July 2014 (UTC)

I guess, I haven't asked a question about privacy. I want to know why I can't edit through mobile version. 101.221.128.88 (talk) 14:01, 25 July 2014 (UTC)

Are you getting a specific error, or is the edit function just not available? Which mobile platform are you using? — xaosflux ^Talk 15:02, 25 July 2014 (UTC)

You cannot edit via mobile as a non-registered user because it is not enabled. Bug 53076 implies that some work is ongoing. --AKlapper (WMF) (talk) 15:26, 25 July 2014 (UTC)

User:Maryana (WMF) is the product manager for mobile editing and could tell you the current status, but I believe that the overall plan is that logged-out editing will be permitted eventually. Whatamidoing (WMF) (talk) 19:09, 25 July 2014 (UTC)

To clarify, Maryana is the product manager for mobile web, whereas I am the product manager for mobile apps. And, also to clarify, you can edit anonymously on the mobile apps. :-) --Dan Garry, Wikimedia Foundation (talk) 01:09, 26 July 2014 (UTC)

Thanks for the reply Whatamidoing (WMF), AKlapper (WMF) & Xaosflux. I hope to see this function quickly. Btw I've found another problem. I can't see the "go" button and the drop down menus in this special page when I was browsing through my andriod phone. Both, the go button and those two drop down menu were vanished when I saw it through my phone. Can someone fix it?? Thanks -- 101.221.130.34 (talk) 19:30, 25 July 2014 (UTC)

• You can not edit using the mobile version if you use certain browsers (such as Opera Mini). I hope that this will be fixed. --Stefan2 (talk) 13:30, 29 July 2014 (UTC)

No it won't. See wp:open proxies. --117.201.38.153 (talk) 03:30, 31 July 2014 (UTC)

Opera Mini is not blocked under WP:Open proxies (because it uses the X-Forwarded-For header), and editing is possible using the immobile edition of Wikipedia. The problem is something else. --Stefan2 (talk) 12:18, 2 August 2014 (UTC)

A recent software change added a reference list to the bottom of talk pages even if a {{reflist}} tag wasn't present. Can a small horizontal line appear before the list? It can be distracting when the last post on a page bleeds into the list. --NeilN ^{talk to me} 14:13, 29 July 2014 (UTC)

This is related to #Automatically generated reference lists- tracking and several recent threads in the archives. --Redrose64 (talk) 14:35, 29 July 2014 (UTC)

I'll ask, possibly naively, is there ever a case where you want to add references to a talk page and you want them at the bottom of the page, as opposed to the bottom of the section? I'm thinking that the references are always intended to apply to a particular section, and it would be better if they appeared at the bottom of the section. Wouldn't it be relatively simple to tweak the algorithm as follows:

If page contains ref tags with no reference list markup AND the page is a talk page, add {{Reflist-talk}} to the section containing the ref tags.

In the rare case where someone can dream up why they should be at the bottom, then the editor wanting that can add the {{reflist}} themselves.--S Philbrick(Talk) 12:56, 30 July 2014 (UTC)

See HELP:ARGL. --  Gadget850 ^talk 19:44, 30 July 2014 (UTC)

... or Help:AGRL -- John of Reading (talk) 19:58, 30 July 2014 (UTC)

<D'oh!> --  Gadget850 ^talk 20:00, 30 July 2014 (UTC)

So is that a no? :-) --NeilN ^{talk to me} 17:34, 31 July 2014 (UTC)

It uses a bare <references /> element, not the {{reflist}} template (you can tell because an examination of the page's HTML shows that it's not wrapped in <div class="reflist" style="list-style-type: decimal;">...</div>), and that is the Cite.php extension so it's part of the MediaWiki software and largely out of our control. --Redrose64 (talk) 20:28, 31 July 2014 (UTC)

If people want this, then I (or anyone else) can file a request on Bugzilla for it. It's probably something that would affect all wikis (not just Wikipedias, and not just the English one), so it's probably wise to think it through carefully before requesting it. Whatamidoing (WMF) (talk) 22:22, 31 July 2014 (UTC)

I think it would be worth having. I accept that it is not a minor deal, so worth thinking about what could go wrong. My main reason for thinking that there is little downside is that if you really wanted the refs at the bottom of a talk page (which is difficult to imagine) you can always force it to do so adding {{reflist}} at the bottom, so to envision a problem we need to dream up a situation where someone wants the refs to appear at the bottom, but does not want a proper References section at the bottom. I can't think why that would be, but perhaps someone else can imagine such a situation.

Another argument in support of implementing it; One might argue that there were a flurry of instances right after implementation, as all refs on talk pages ever added started appearing on the bottom, and most will now be cleared up, which is correct, but the problem is not resolved. As we continue to add new editors, someone, somewhere is going to use the talk page to discuss an edit, and may copy paste some part of the article, including a ref, to the talk page, and initially that ref will locate at the bottom of the added section, where it seems to belong. But then someone will add a new section, and the refs will float down, causing confusion. Or it could happen directly. Someone adds a comment to a thread up on the page, and doesn't notice that the ref is sitting down there at the bottom. Those involved in the discussion at the bottom might not realize why the ref is there. If we have the rule that refs on a talk page, without an associated ref template, are displayed in the section containing the ref, they will appear almost certainly where they are intended to appear, and in the rare case they belong elsewhere, it is easy to fix.--S Philbrick(Talk) 12:02, 1 August 2014 (UTC)

Before the deployment of 1.24wmf12, we had an error message that the reference list was missing. We used namespace detection to not show the error on user and talk pages. We were able to clean up missing reference lists fairly quickly. I'm starting to think that way the AGRL was implemented is more painful than useful. --  Gadget850 ^talk 12:21, 1 August 2014 (UTC)

I agree. Before the deployment, as editor making an error (ref without the needed code) generated an ugly red error message. Post-deployment the ugly red error message is gone, which sounds like a positive, but at the cost of introduction a "fix" which is almost certainly not what the editor wanted. What makes it worse is that now there is no error message to give a hint at the problem so the page is malformed, and it isn't obvious why.

I've never filed a bugzilla, guess it is time to bite the bullet.--S Philbrick(Talk) 14:31, 1 August 2014 (UTC)

How would you like it to handle ===Subsections===? Imagine that it's an RFC or a proposal for a major re-write to a large section of an article. Do you want separate refs for each subsection, or all together?

(Bugzilla requests aren't hard, but they do require publishing your e-mail address to the world.) Whatamidoing (WMF) (talk) 02:41, 3 August 2014 (UTC)

How to add some extra buttons in toolbar? I copied some stuff from one javascript page, but this isn't working:

jQuery.getScript('//meta.wikimedia.org/w/index.php?title=User:Krinkle/Scripts/InsertWikiEditorButton.js&action=raw&ctype=text/javascript', function () {
 
        // Reflist
        krInsertWikiEditorButton({
                "id": "mw-customeditbutton-myspecialbutton",
                "icon": "http://upload.wikimedia.org/wikipedia/commons/2/2b/Button_ref_inscription.png",
                "label": "Reflist",
                "insertBefore": "==References==\n{{reflist}}\n\n",
        });
 
});

I'm using the old toolbar, if it matters. And by the way, how to enable the old CodeEditor? something like $wgCodeEditorEnableCore = true; (this line doesn't work)? --Edgars2007 (talk/contribs) 11:43, 30 July 2014 (UTC)

That script is very old itself, and is for the WikiEditor, not for the old toolbar.

The documentation for adding buttons is here. We have an example MediaWiki:Common.js/edit.js

The CodeEditor only works if you have the Enhanced toolbar/WikiEditor option enabled, since it strongly depends on it. I'm working on decoupling that, but I haven't had any time in weeks to work on it. bugzilla:45850 is about this. Hopefully after wikimania i should have it fixed, but not 100% sure. —TheDJ (talk • contribs) 11:56, 30 July 2014 (UTC)

Ok, I suppose I copied too much/less. And can the sampleText be removed if there isn't anything between open and close tags?

function addExtraButtons () {
	mw.toolbar.addButtons(
	{
		'imageId': 'button-references',
		'imageFile': '//upload.wikimedia.org/wikipedia/commons/2/2b/Button_ref_inscription.png',
		'speedTip': 'References',
		'tagOpen': '==References==\n',
		'tagClose': '{{reflist}}\n\n',
		'sampleText': 'nothing'
	}
);
}

--Edgars2007 (talk/contribs) 12:10, 30 July 2014 (UTC)

@Edgars2007: I changed your JS by adding the loader code which was missing. I also removed the sampleText in the same edit, so it should be working the way you want now. Could you check? Helder 22:09, 30 July 2014 (UTC)

@Helder.wiki: Yes, it works. Big, big thanks! :) --Edgars2007 (talk/contribs) 08:50, 1 August 2014 (UTC)

Is there a template (or some other automated method) that will break a long word into pieces that do not exceed a specified maximum length? Ideally it would break up the word by inserting hyphens or spaces at regular intervals. I'm asking because I sometimes need to display a long word in an infobox without making the infobox abnormally wide. Any ideas or tips would be appreciated. Lambtron (talk) 15:53, 31 July 2014 (UTC)

You can use a soft hyphen with {{shy}}. /~huesatlum/ 16:16, 31 July 2014 (UTC)

Unfortunately that would require manual insertion of soft hyphens, which I could just as easily do by inserting hard hyphens. What I really need is an automatic way to insert hyphens in a fashion similar to this: {{Hyphenate|20|Averyveryverylongword}}. Lambtron (talk) 16:25, 31 July 2014 (UTC)

Hmmm. I suppose the <wbr /> element is no use then (see Wikipedia:Village pump (technical)/Archive 117#nowrap vs please-wrap-here option?). --Redrose64 (talk) 16:35, 31 July 2014 (UTC)

Another possible solution would be to somehow prohibit automatic infobox widening so that the infobox itself would force the word to wrap. Is there a way to do that? Lambtron (talk) 16:45, 31 July 2014 (UTC)

Which infobox; or, better still, which page is the problem manifest on? --Redrose64 (talk) 17:16, 31 July 2014 (UTC)

It's not an immediate problem but rather one that comes up from time to time. I'd like to find a solution for the next time it comes up. In case the issue isn't clear, here's a simple example that shows what can happen when a long word or url appears in an infobox:

BTW, the same problem shows up in userboxes and possibly in other visual containers as well. In the case of urls, the ideal solution would be to have the container force visual wrapping so that a url copy-paste would not include any bogus hyphens. Lambtron (talk) 17:38, 31 July 2014 (UTC)

I may have found a solution: encapsulate the word in a div styled with word-wrap:break-word. More exploration is needed, but here's an example:

http://www.example.com/Averyveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryverylongurl.htm

Lambtron (talk) 18:18, 31 July 2014 (UTC)

Many infoboxes wrap a URL in {{URL}}, others expect you to provide that template yourself. Either way, I think that the place to address this is in the {{URL}} template. Which is now Lua-ised at Module:URL; but discussions are still held at Template talk:URL. --Redrose64 (talk) 18:38, 31 July 2014 (UTC)

Note that {{URL}} has as specific purpose, which is the emission of metadata, not formatting. (Why does it need to be in Lua, BTW?) Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:23, 1 August 2014 (UTC)

I posted the following to User:Smith609's talk page: "When I click on Edit history stats, or page watchers under the Statistics toolbox in the right margin, I get the following - 403: User account expired The page you requested is hosted by the Toolserver user wiki_researcher, whose account has expired. Toolserver user accounts are automatically expired if the user is inactive for over six months. To prevent stale pages remaining accessible, we automatically block requests to expired content. See: [13] ???" Martin replied..."Well, the toolserver itself is expired, now. Do you have an updated link, or any suggestions of how to find one?" Does anyone know if there's a fix? Atsme☯^Consult 18:32, 31 July 2014 (UTC)

Everything on Toolserver, that was worth moving is now at Labs, not sure if the item you are looking for is active or maintained. (oh some links in the sidebar are broken) "Edit history stats" and "Page watchers" can be retrieved by the "page information" link in the above "tool box" section. Cheers, Mlpearc (open channel) 18:49, 31 July 2014 (UTC)

That is simply not true by a very, very long shot. And for the 90% most hit tools it raises the question, "Why does the foundation refuses to move them into production". Anyway, the place to post to is mw:Tool Labs/Collection of issues after Toolserver shutdown, better act quick because WM-DE is outright deleting ~8 TB of Toolserver data in a month. — Dispenser 19:32, 31 July 2014 (UTC)

Moreover it seems that the labs is exclusive, it shuts out anyone who doesn't comply with "Open" sourcing their tools. It is a sad affair. All the best: Rich Farmbrough, 22:36, 31 July 2014 (UTC).

That is out of years of experience with abandoned projects that was upsetting to users. So that's why people decided they wanted to prevent similar problems in toolslabs. And of course it is just as exclusive as requiring editors to share their contributions (even for commercial purposes), which we think is totally normal in our movement. This is just for toollabs btw. Labs itself does not have such a restriction and can be granted and used on a case by case basis for exceptions. There even might be some exceptions on toollabs for research purposes I suspect, but defaults match that what we do throughout all our knowledge sharing indeed. —TheDJ (talk • contribs) 10:53, 1 August 2014 (UTC)

IIRC wikidashboard was GPL'd, so there's no open sourcing issues with it. The reason Toolserver wasn't saved was because it was too much work for foundation staff whose always squeezed on time. WM-DE saw Toolserver as a white elephant and wants to get quickly get ride of it.

That's just organizational politics, it doesn't explain why we need to break up tools (mine are cross integrated), the web server sucks, refusal to implement a namespace table, why database names are inconsistent, the second rate security practices, popular unix commands are missing, cron is forbidden, or the oh so fucking wonderful privacy policy.

But hey it's open source, so we can put that into the Foundation's Google Docs presentation on their "successful migration". — Dispenser 13:45, 1 August 2014 (UTC)

When and why did we start styling the <code>...</code> element with a border? --Redrose64 (talk) 18:41, 31 July 2014 (UTC)

That would be Gerrit:148397 with the intention to make it look the same like <pre> blocks. --Patrick87 (talk) 19:22, 31 July 2014 (UTC)

I didn't like the change, the code seems too highlight, like bold text. I prefer some like this, used in python documentation. Danilo.mac (talk) 01:15, 1 August 2014 (UTC)

The border on the <code>...</code> element can be undesirable: see MediaWiki talk:Common.css#Double border and Template talk:Pre#Double border. --Redrose64 (talk) 09:19, 1 August 2014 (UTC)

It seems that Edokter fixed the templates, thanks! Matma Rex talk 11:27, 1 August 2014 (UTC)

Which templates would those be? --Redrose64 (talk) 11:35, 1 August 2014 (UTC)

The {{pre}} that you linked? Matma Rex talk 13:22, 1 August 2014 (UTC)

I didn't like the change either -- I thought <code> formatting was just fine the way it was. Now many inline snippets of code have distracting borders around them. Lambtron (talk) 15:12, 1 August 2014 (UTC)

• code text && code text && code text && code text && code text && code text && code text && code text && code text && code text && code text && code text && code text && code text && code text && code text && code text && code text && code text && code text && code text && code text && code text && code text && code text && code text && code text && code text && code text && code text && code text && code text && code text && code text && code text still looks bad to me... If there where no left or right borders, I would be okay with it though (I'm guessing there are others that wouldn't be though).

code text && code text && code text && code text && code text && code text && code text && code text && code text && code text && code text && code text && code text && code text && code text && code text
code text && code text && code text && code text && code text && code text && code text && code text && code text && code text && code text && code text && code text && code text && code text && code text

Nested doesn't look any better, which shouldn't happen; however, based on the fact there are multiple other discussions about it, it apparently does. — {{U|Technical 13}} ^{(e • t • c)} 15:21, 1 August 2014 (UTC)

HTML doesn't allow you to nest <pre> inside <code>, as the former is a block element and the latter is an inline element. When you look at the HTML source of parsed page, you'll notice that HTML Tidy "interweaved" them, nesting <code> inside <pre>, which obviously looks stupid. Why do you want to do that anyway? Matma Rex talk 18:07, 1 August 2014 (UTC)

An example of the annoying pseudo-nested border now seen throughout Intel HEX: :0300300002337A1E. Lambtron (talk) 15:37, 1 August 2014 (UTC)

Why is that article using <code> tags? This doesn't appear to be computer code. Perhaps the tags should be removed, and the template should be changed to use a monospace font? Matma Rex talk 18:07, 1 August 2014 (UTC)

It actually is "computer code" (perhaps you meant it's not high-level language source code?). Computer codes such as this appear as inline snippets and larger blocks in many articles. I realize this may not be the correct place to ask, but if <code> is not the right way to format codes such as this, what is the proper way? Lambtron (talk) 18:46, 1 August 2014 (UTC)

It's a data sample, so how about <samp>...</samp>? :0300300002337A1E --Redrose64 (talk) 18:59, 1 August 2014 (UTC)

Thanks for the tip, Redrose, I'll look into that. BTW, this is not the only thing screwed up by this formatting change. For example, have a look at the example in MOS:CODE. Lambtron (talk) 19:07, 1 August 2014 (UTC)

As an aside, <samp>...</samp> should be mentioned in the MOS if it's the preferred way to style this sort of thing. Perhaps it's already there but I just didn't see it. Lambtron (talk) 19:15, 1 August 2014 (UTC)

@Lambtron: I updated that MOS page, it was incorrect (or at least misleading); <code><pre></pre></code> (or <code>(space-indented code block)</code>) was never correct, like I explained above, and should never be used. The <pre></pre> or space-indentation (this produces the same HTML) suffices entirely. Matma Rex talk 19:35, 1 August 2014 (UTC)

When I surround with pre tags I get this:

{{Intel HEX|03|0030|00|02337A|1E}}

-- not quite what is needed. But with Redrose's suggested samp tags I get this: :0300300002337A1E. Which is correct? Lambtron (talk) 19:50, 1 August 2014 (UTC)

• Note that <tt>...</tt> is still available for styling text without the border. - Evad37 [talk] 03:38, 2 August 2014 (UTC)

  Use <kbd>...</kbd> instead, as <tt>...</tt> is deprecated. -- [[User:Edokter]] {{talk}} 09:19, 2 August 2014 (UTC)

  Yeah... Please don't add more <tt>...</tt>s. Helder 11:12, 2 August 2014 (UTC)

  • Really, <tt>...</tt> doesn't render in some browsers and instead leaves blank sections. See Media:Bad elements.png from this discussion then later this proposal for an example. — {{U|Technical 13}} ^{(e • t • c)} 15:47, 2 August 2014 (UTC)

I've been using <code>...</code> because it seemed correct according to MOS and it worked perfectly until the recent changes to it and the MOS, but now that's broken. I've received tips about using <pre>...</pre>, which doesn't work; <samp>...</samp>, which no one else seems to support; <tt>...</tt>, which is deprecated; and now <kbd>...</kbd>. Before I start replacing problematic <code>...</code> tags with something else, I must know that the replacement is (1) functional, (2) sanctioned for this purpose, and (3) will not change in the future like <code>...</code> did, thereby making my work pointless. Which one is correct, and shouldn't it be mentioned in MOS? Lambtron (talk) 15:52, 2 August 2014 (UTC)

It depends on what is being marked up with the tag. See the specs of each one of them: pre, code, kbd, samp and var. There is also a short table of conversions at de:Wikipedia:WikiProjekt HTML5 which I think would be useful on English Wikipedia as well. Helder 16:11, 2 August 2014 (UTC)

This needs to be explicitly covered in the MOS. The w3.org spec for <code>...</code> says that it "represents a fragment of computer code ... or any other string that a computer would recognize". That certainly seems applicable to Intel HEX and many other types of non-high/low-level-language computer codes. It's unreasonable for editors to have to search outside the MOS for this. Also, how do I know that whatever tag I choose as a replacement won't have its style changed in the future? Lambtron (talk) 16:41, 2 August 2014 (UTC)

You don't. But it is its semantic which matters the most. The style can always be overriden on a per wiki, per skin or per user basis through CSS. Helder 16:47, 2 August 2014 (UTC)

• Helder, can you translate that table to a page here on enwp in English? If so, that would be great. As best I can tell (I can't read the words but get the jist of most of it), it only needs a few tweaks to go live. That is exactly the kind of page I was talking about in the proposal to help editors know what they should be using instead of deprecated elements. Thanks. — {{U|Technical 13}} ^{(e • t • c)} 16:54, 2 August 2014 (UTC)

  @Technical 13: Done. Please review and feel free to move to a more appropriate title. Helder 18:34, 2 August 2014 (UTC)

I recently left a suggestion on DPL bot's talk page and Steel1943 recommended that I make it here as well. The sad demise of DAB Solver has created a search for alternate solutions, and I would like to propose one. It has come to my attention that, on Russian Wikipedia, if you create a link that leads to a disambiguation page it comes up highlighted in pink, so you know immediately. Would something like this be feasible for English Wikipedia? WQUlrich (talk) 23:11, 31 July 2014 (UTC)

@WQUlrich: Dab Solver still works well for one article at a time - the old links redirect to Dispenser's new home. WPCleaner is another option. GoingBatty (talk) 23:29, 31 July 2014 (UTC)

You won't know immediately, you will know on page preview (or after you save the page) if you notice the different color of one of the links. But even then that won't help you if you are linking to the wrong article which is not a disambiguation page (i.e. linking to Milky Way when you meant to link to Milky Way (chocolate bar)). So that's just half a solution. You don't have to use my Smart Linking script, the other way is to check your links with the Navigation Popups gadget, I just made it a little more convenient to use while editing. But there is really no other way as far as I know. --V111P (talk) 07:16, 1 August 2014 (UTC)

By the way you can just put this into your common.css to get the result you want: a.mw-redirect {color: green;} --V111P (talk) 07:37, 1 August 2014 (UTC)

@V111P: That's for redirs, not dab pages. What WQUlrich wants is something that will style a link like Lincoln differently. If you examine the source for that link, you'll find <a href="/wiki/Lincoln" title="Lincoln">Lincoln</a> which has no class= or id= that might be used to trigger a different style. --Redrose64 (talk) 12:17, 1 August 2014 (UTC)

Thanks, Redrose64. I got confused because on Russian Wikipedia they have a gadget that does that for you for the redirects. However I don't see any gadget for dabs, and the default color for links to dabs is the same as for other links (and they don't have any class or id). --V111P (talk) 17:44, 1 August 2014 (UTC)

@Redrose64: OK, I was wrong. I was only looking at the links on page preview, where the links are the same color, but on saved pages the links to disambiguation pages are with a pink background (ru:2D - the link to 3D). I found the script that does it: ru:MediaWiki:Gadget-bkl-check.js. I can't immediately make it work here, but it can be done (and there is a better way to do it now that we have __DISAMBIG__ in the disambiguation templates). --V111P (talk) 19:57, 1 August 2014 (UTC)

@V111P: Although it is not set up as a gadget, User:Anomie/linkclassifier knows how to change the colour of links to dab pages. See that page for instructions. It works on saved pages and in previews. -- John of Reading (talk) 20:02, 1 August 2014 (UTC)

Wow, thanks for the response. All a bit over my head, though... WQUlrich (talk) 22:08, 1 August 2014 (UTC)

Thanks from me too, John of Reading. --V111P (talk) 06:21, 3 August 2014 (UTC)

I get [14] when I click on the edit summaries link at the bottom of my contributions page. I really hope we get this back as for those of us who use edit summaries a lot it can be extremely useful if you are trying to find old contributions. Thanks. Dougweller (talk) 12:52, 1 August 2014 (UTC)

@Dougweller: It works for me. What error message you saw? Zhaofeng Li [talk... contribs...] 07:33, 2 August 2014 (UTC)

@Zhaofeng Li: Can't recall and as it works for me now... Thanks for letting me know. Dougweller (talk) 10:57, 2 August 2014 (UTC)

I was editing a page on Google Chrome using the Visual Editor and for some reason overtype mode turned on. I switched from Visual Editor to the regular editing mode, but that didn't fix it. Has this ever happened to anyone (Visual Editor bug, maybe?) and how do you turn off overtype mode? Altamel (talk) 22:40, 1 August 2014 (UTC)

Did you hit the insert key? --NE2 22:42, 1 August 2014 (UTC)

Maybe I did. I just tested it, and the strange thing is that triggers overtype in VE but not in regular editor. I'll just hit the insert key to turn overtype off if it happens again. Thanks, Altamel (talk) 22:46, 1 August 2014 (UTC)

Links are sometimes getting injected into the article Planarian by a hyperlink virus when using Google Chrome. Some of the phrases hacked by that virus are 'eat,' 'encyclopedia,' 'family,' 'food,' 'play,' and 'system.' I mentioned this in case there's a way for Wikipedia to evolve to block the action of that virus and any future hyperlink viruses. I don't mind them but I mentioned this in case some people mind and will never learn how use internet settings to block the action of that virus. Blackbombchu (talk) 04:35, 1 August 2014 (UTC)

@Blackbombchu: Diffs? --NeilN ^{talk to me} 05:03, 1 August 2014 (UTC)

The linked hyperlink virus is confused but I Googled the alleged "hyperlink viruses" BestSaveForYou and ArcadeYum. This is apparently about readers who have bad browser extensions which inject links not present on the visited website. I don't see what Wikipedia can do if the links are inserted by the user's own software after the page is sent to the user. PrimeHunter (talk) 12:42, 1 August 2014 (UTC)

I created the article hyperlink virus myself, but it doesn't look like it because I did so as Fierce Deity Mask. Speedy deletion Wiki doesn't have a rule about verifiability like Wikipedia does. I created an account on Chips Challenge Wiki as Blackbombchu but I never clicked 'Stay logged in' as Blackbombchu then gone to another wikia.com website while signed in after signing into Chips Challenge Wiki so I didn't realize Chips Challenge Wiki was part of a large group of websites. Later I tried to create an account on Speedy deletion Wiki as Blackbombchu but it said that username was already taken so I registered as Fierce Deity Mask. I didn't realize that the account it was taken by was my own account that I created on Chips Challenge Wiki because I didn't create it on Speedy Deletion Wiki. Blackbombchu (talk) 15:42, 1 August 2014 (UTC)

Regardless, this has nothing to do with Wikipedia. --NeilN ^{talk to me} 16:04, 1 August 2014 (UTC)

Despite the phrase you're using, these aren't viruses and there's nothing Wikipedia can do to "block" them - it's entirely happening on your own computer within your own webbrowser. Andrew Gray (talk) 17:38, 1 August 2014 (UTC)

It's actually the CAMMAC computer. I haven't used Google Chrome for a long time on my computer after I accidently downloaded the Java update virus which made Google Chrome work very badly so I didn't see whether Google Chrome had the problem of injecting hyperlinks on my computer. Speedy deletion Wiki can be edited by anyone so fell free to edit Hyperlink virus to correct the wrong information in it. Blackbombchu (talk) 23:13, 1 August 2014 (UTC)

Actually, Wikipedia does have one tool which can block these actions - the edit filter. The question is, is the disruption caused by this issue bad enough to justify that? עוד מישהו Od Mishehu 12:03, 3 August 2014 (UTC)

I don't think the edit filter would have any effect here - these aren't actually being added to the Wikipedia article by editing; they're being added to the browser at the time of display on the user's computer. Nothing we can do at this end. Andrew Gray (talk) 14:08, 3 August 2014 (UTC)

• I have used a tool to find incidents of editing an article about the same time as another editor. It was at http://toolserver.org/~snottywong/editorinteract.html It did not work as of 1 Aug 2014. Wikipedia:Tools lists "Editor interaction analyzer," and clicking on it leads to toollabs:sigma/editorinteract.py which is out of service. Possibly this is due to some tool server update I seem to remember reading about months ago. I love "improvements" which take away important functionality, without any redirect or accessible explanation. Is there a replacement Editor Interaction Tool that actually works? If all the "tools" are at some other website now, could someone please update Wikipedia:Tools? Edison (talk) 15:36, 1 August 2014 (UTC)

"It did not work as of 1 Aug 2014" - it shouldn't have worked since 1 July 2014, which is when Toolserver went down, permanently. There's been plenty about it on this page, much of which may now be found in the page archives. --Redrose64 (talk) 15:54, 1 August 2014 (UTC)

The problem is that the version at WMF labs seems down as well, along with the rest of the scottytools. (toollabs:scottytools/index.html)AddWittyNameHere (talk) 22:52, 1 August 2014 (UTC)

Editor interaction tool went to Labs intersect-contribs — Maile (talk) 23:15, 1 August 2014 (UTC)

Also, the tool you linked above toollabs:sigma/editorinteract.py opens fine for me. — Maile (talk) 23:20, 1 August 2014 (UTC)

The toollabs:sigma/editorinteract.py replacement tool absolutely did not work, and only provided an error message at the time I said it did not work. So just call it "intermittently operating." The "Wikistalk" tool on that page is still a toolserver tool, and just generates a 404 error. If the wizards of Wiki software knew toolserver was shutdown July 1, since "there's been plenty about it on this page" as you state, why are there still links on the Tools page to Toolserver scripts? Thanks. Edison (talk) 12:34, 2 August 2014 (UTC)

Some tool providers knew full well that Toolserver was going down, and did nothing (wilfully or otherwise) about it; some tool providers are no longer with us. It is generally the responsibility of a tool's provider to ensure that the information about that tool at Wikipedia:Tools - which is a regular editable page - is up to date. --Redrose64 (talk) 16:58, 2 August 2014 (UTC)

The community should be able to remove any tools which have been inactive for a long time, after attempting to discuss it wit the tool's operator. עוד מישהו Od Mishehu 12:01, 3 August 2014 (UTC)

Reflinks seems to be working again. Was the decision to withdraw it reversed? --P123ct1 (talk) 08:22, 2 August 2014 (UTC)

"decision to withdraw it"? Never heard of any. I think it was just broken and now is fixed. Matma Rex talk 10:38, 2 August 2014 (UTC)

If you look in the VP archives, you will see a tremendous amount of discussion about its supposed withdrawal on 1 July this year. There was a big outcry against it. When I tried it then, it did not work, but now it is back to normal. --P123ct1 (talk) 18:50, 2 August 2014 (UTC)

I'm aware of that, and like I said, there wasn't any decision made by any powers that be I'm aware of. The tool was just broken for some time due to unfinished Toolserver migration. Matma Rex talk 18:55, 2 August 2014 (UTC)

@P123ct1: It wasn't withdrawn. The author of the tool initially decided not to migrate it to the new WMF-hosted toolserver. After some pleas, he changed his mind. --NeilN ^{talk to me} 18:56, 2 August 2014 (UTC)

I see, that explains it. --P123ct1 (talk) 19:05, 2 August 2014 (UTC)

It appears it's on http://dispenser.homenet.org - not toollabs. GoingBatty (talk) 22:57, 3 August 2014 (UTC)

I had made a user flags change that failed, but the log entry shows that it was completed. I opened a bug 68133 a couple of weeks ago, but not sure if there is anything else that should be done? — xaosflux ^Talk 15:08, 3 August 2014 (UTC)

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

Is it still not working for you? I just closed Wikipedia:Articles_for_deletion/Dunmore_Candy_Kitchen successfully with it. --j⚛e decker^talk 18:41, 24 July 2014 (UTC)

What exactly is wrong with it? I've closed several in the past month, seemed to be working fine. Ansh666 08:43, 25 July 2014 (UTC)

Still not working. The first part (hide closed AFDs) works fine, but the closing component itself does not. The drop down menu where you choose the closing options does not show up. Could it be a side effect of mediawiki changes? Using Firefox, btw. Since this talk got archived in the meantime, pinging j⚛e decker and Ansh. Thanks. --Tone 16:33, 3 August 2014 (UTC)

It might be a race condition. For example, User talk:Timotheus Canens/displaymessage.js#Missing dependency or another one due to the fact that Mr.Z-man's closeAFD.js seems to assume the function displayMessage from User:Timotheus Canens/displaymessage.js will be available as soon as the line importScript('User:Timotheus Canens/displaymessage.js') is executed (which I don't think is the case, because it is asynchronous). And there is also the fact that it still uses the deprecated addOnloadHook instead of $. Helder 01:28, 4 August 2014 (UTC)

@Tone: Do you see anything in your Javascript console? T. Canens (talk) 01:49, 4 August 2014 (UTC)

@Tone: I can reproduce this from your vector.js. It appears that fixTab() is broken by...something, which I didn't investigate further. When I deleted that code and left only the two importScript lines, it works for me. T. Canens (talk) 02:03, 4 August 2014 (UTC)

@Timotheus Canens: Excellent, seems to be working now. I don't remember where the rest of the code came from. Thanks a lot! --Tone 07:16, 4 August 2014 (UTC)

How do I centralize headings or text in an infobox? i.e. not justified to L or R. I cannot find how to do it in MoS. --P123ct1 (talk) 17:23, 3 August 2014 (UTC)

Generally, the rows of an infobox may be given in one of three ways.

• The |headern= parameters produce a full-width row that is boldfaced and centred (semantically, it's a <th>...</th> element).
• The |datan= parameters, when used alone, also produces a full-width row that is centred, but normal weight (semantically, it's a <td>...</td> element).
• A |labeln=|datan= pair yields two columns, both left-aligned: the left-hand column is boldfaced (a <th>...</th>); the right-hand column is normal weight (a <td>...</td>).

In each case, n is a positive integer, and each row needs to have a unique value for n; for a label/data pair, n must match. --Redrose64 (talk) 19:39, 3 August 2014 (UTC)

Thanks for that answer. --P123ct1 (talk) 12:55, 4 August 2014 (UTC)

Can someone have a look at Arms industry using Vector and IE11 and see if they can work out what's happening to the tables. I'm assuming it's something to do with the width command. It needs to be seen in Vector, monobook and modern provide no issues to the rendering. Nthep (talk) 18:25, 3 August 2014 (UTC)

That page looks okay to me. Can you at least describe what are you seeing, and preferably also provide a screenshot? Matma Rex talk 18:39, 3 August 2014 (UTC)

(edit conflict) The caption and the table contents were coded as separate tables, the first of which was not properly closed (a closing |} was missing), actually putting the rest of the article into the table. Apparently, IE makes this table 25% of the screen due to the width="25%" applied to the caption cell while Firefox doesn't. I've fixed it by putting the caption inside the data table using the |+ syntax described at Help:Table. SiBr₄ (talk) 18:47, 3 August 2014 (UTC)

Why are the servers overloaded? At AFD I get the error message: "Wikipedia:Articles for deletion/Log/2014 August 3 From Wikipedia, the free encyclopedia < Wikipedia:Articles for deletion‎ | Log Sorry, the servers are overloaded at the moment. Too many users are trying to view this page. Please wait a while before you try to access this page again. Timeout waiting for the lock" Edison (talk) 18:29, 3 August 2014 (UTC)

Is there any script or tool available that makes doing WP:BUNDLE easier? A socking user has recently created a rather large walled garden of articles I would like to nominate for deletion/merge but twinkle would make all separate discussions, and doing the nominations by hand is a pain. Gaijin42 (talk) 18:32, 3 August 2014 (UTC)

You could start the first discussion using Twinkle, then add the subsequent articles to the nomination by hand. — This, that and the other (talk) 08:06, 4 August 2014 (UTC)

Adding the AfD notice to the subsequent pages can be easily done using the prepend text function of AWB. You could apply for the tool yourself or ask someone else at WP:AWB/Tasks. SiBr₄ (talk) 10:08, 4 August 2014 (UTC)

07:37, 4 August 2014 (UTC)

Hello! Am aware of the Template:Location map+ where multiple locations can be highlighted on a map. But is there any template to draw a line between such locations? These could be useful for drawing maps of roads/rail routes etc. §§Dharmadhyaksha§§ {T/C} 08:21, 4 August 2014 (UTC)

There seems to be an automated system for adding template data. (Once again we have used CamelCase - so user unfriendly! Please stop doing that everyone! Especially as an adjunct to a supposedly user-friendly change!)

But the problem is it adds the template data in templatedata tags (run together words, but at least not camel case!) without making sure they are in the appropriate noinclude tags.

Possibly it is is only supposed to work on template documentation pages, but it pops up on template pages too.

Is this a bug?

All the best: Rich Farmbrough, 22:40, 31 July 2014 (UTC).

I think this was discussed at Wikipedia:Village pump (technical)/Archive 128#MW extension "Manage template documentation" now affecting every template. --Redrose64 (talk) 23:13, 31 July 2014 (UTC)

So, the page Ovin was speedy deleted. Disagreeing with the decision, I restored the page. However, I didn't know there was a deletion review discussion happening at the time I re-created it. Would it be possible to create a note on the deletion log that the deletion of an article is currently under discussion? Oiyarbepsy (talk) 04:48, 3 August 2014 (UTC)

Judging by the article history and the deletion log, you didn't restore the page but created a new one using the same name as the one that had been deleted. But the deletion log records only what is known at the time of the deletion; and since the DRV was filed on 26 July, the deletion on 23 July cannot have known of its existence, that being an event in the future. It is rare (if not unknown) for a DRV to be raised before the deletion takes place. --Redrose64 (talk) 09:29, 3 August 2014 (UTC)

Actually, I re-created it on July 31, when the Deletion Review was in progress. But I had no idea it was happening. It's the re-creator that should receive a notice. Oiyarbepsy (talk) 02:24, 4 August 2014 (UTC)

Yes, you recreated it on 31 July - that date is shown in the page history that I linked, and I didn't claim otherwise. When you recreated the page, you will have seen the deletion log for the page. The deletion log includes restorations of deleted pages, and the entries in this log do sometimes contain links to a DRV page, often when a page is restored following a DRV, but these links are always manually added by the person restoring the page at the same time that the restoration is carried out. For example, see the deletion log for Fomato - which coincidentally links to the same DRV page that you mentioned. Occasionally a link to a DRV is included in the entry for a deletion: the sequence might be (i) page is deleted; (ii) page is restored; (iii) a DRV for that restoration is started; (iv) the DRV upholds the original deletion, so the page is deleted again and this time the link to the DRV is included in the log. But such links cannot be retrospectively added: log entries may be redacted in full, but cannot be modified. --Redrose64 (talk) 07:11, 4 August 2014 (UTC)

Yes, that's as I understood it. I was wondering if a software change could allow editors to place a notice on a deleted page that would appear above the deletion log, as a solution to this issue. Oiyarbepsy (talk) 05:49, 5 August 2014 (UTC)

As someone who has been doing this manually for years, I hereby dutifully beg of anyone who is technically proficient and knows how to create and run a bot that will:

1. Automatically sort all Categories on each article and category page alphabetically;
2. Create a uniform system for where to place categories on each article and category page that commence with numbers, such as years of birth/death, centuries, and any category that starts with a number/numeral.

Please see the centralized discussion at Wikipedia:Bot requests/Archive 61#Create a BOT to alphabetize and organize categories automatically. Thank you, IZAK (talk) 09:10, 4 August 2014 (UTC)

Please see Wikipedia:Village pump (policy)/Archive 114#Create a BOT to alphabetize and organize categories automatically. Thank you, IZAK (talk) 22:48, 5 August 2014 (UTC)

I just noticed a strange crunk on Derek Jeter and can't find if this is a known issue. While viewing the mobile version of the page at en.m.wikipedia.org, I noticed that one (and only one) of the images is displayed vertically compressed to about half its height - it's this one: File:Derek Jeter 2004.jpg. The image isn't compressed on the desktop view, nor can I see any code that would cause it to be squished in mobile view. Given how high-traffic this article is I thought I'd bring it up here. I'm using Safari for iPad, if that helps. --NellieBly (talk) 16:16, 4 August 2014 (UTC)

I see exactly the same problem with Firefox 31 (using the mobile view link at the bottom). I thought that perhaps you had an old image cached on your machine; but since I've not having visited that page before, and so I can't have the image cached myself, it's not that problem. --Redrose64 (talk) 17:31, 4 August 2014 (UTC)

That image is using the |upright| tag in the code - is this related to T65134? Andrew Gray (talk) 18:40, 4 August 2014 (UTC)

Image is taller than it is wide, so |upright is valid. --Redrose64 (talk) 18:50, 4 August 2014 (UTC)

The HTML for the page has a <img /> element, some of the attributes are: src="//upload.wikimedia.org/wikipedia/commons/thumb/a/ae/Derek_Jeter_2004.jpg/170px-Derek_Jeter_2004.jpg" class="thumbimage" data-file-width="623" data-file-height="935" height="255" width="170" I've omitted the alt= and srcset= attributes because I don't think that they affect it. In particular, the specified width and height seem to be correct for an upright thumb image. --Redrose64 (talk) 19:02, 4 August 2014 (UTC)

It's certainly a valid use of the tag, but it looks like upright has weird effects on mobile, at least for some images. The ratios given for file-size in the HTML source are the same ratio in both - but the file itself which is being loaded in is corrupt. Weird. Andrew Gray (talk) 19:37, 4 August 2014 (UTC)

I cleared the cache of the Commons File page and it seems to be better now. —TheDJ (talk • contribs) 08:17, 5 August 2014 (UTC)

Fine for me too now. Thanks, everyone. --NellieBly (talk) 05:21, 6 August 2014 (UTC)

A company representative provided a logo File:HG logo-2012-spot Col-01.jpg

The image clearly has a white background.

Yet in the file history, as in the article Hydrogenics, the background is black.

What am I missing?

(My guess is that the background is not actually white, but transparent, but it should still not display as black, should it?)--S Philbrick(Talk) 13:05, 5 August 2014 (UTC)

The image is a JPEG, so it can't have a transparent background. I bet the old version with the black background was still being used on the article due to a delay in the job queue. It looks fine now, and a purge or null edit should have fixed it. /~huesatlum/ 13:57, 5 August 2014 (UTC)

Thanks, I think you are right. I tried Purge, but didn't think to do a null edit.--S Philbrick(Talk) 14:14, 5 August 2014 (UTC)

  Resolved

(ec)I didn't do anything, but it looks better now.--S Philbrick(Talk) 13:59, 5 August 2014 (UTC)

This is just to let people know that all the protection templates have now been converted to use Module:Protection banner. See this thread for the background behind the switch and for the list of templates affected. Also, please leave a note there if you notice anything strange with the converted templates. — Mr. Stradivarius ^{♪ talk ♪} 18:12, 5 August 2014 (UTC)

Hi, at List of longest cantilever bridge spans the table sorting does not work properly (e.g. click to sort on "Main span" column, then click again and nothing happens). This seems to be something to do with the row "many bridges with shorter span". What is the best way to fix this? Is there a way to fix it other than just removing that row from the table? 86.128.1.157 (talk) 00:19, 6 August 2014 (UTC)

Sorting does not work if columns are merged. I fixed it by removing the last row. Ruslik_Zero 09:05, 6 August 2014 (UTC)

Making the row as header cells (which in this case actually would make it a footer) or using the sort bottom class would have worked as well in this case. —TheDJ (talk • contribs) 09:25, 6 August 2014 (UTC)

Hi, We came across the following service http://geoiplookup.wikimedia.org/, and would like to know few things associated with this service:

1) How much traffic we can cope with this service. 2) How reliable is this service in terms of availability and results. 3) Is there any pricing associated with this service or is it free of cost.

Looking forward to a reply from your end. — Preceding unsigned comment added by Nmalh7 (talk • contribs) 03:24, 6 August 2014 (UTC)

@Nmalh7: This is not a commercial service and has a reserved nature. Using it more than incidentally is not appreciated. —TheDJ (talk • contribs) 09:18, 6 August 2014 (UTC)

Where do I complain/offer feedback about the Wikipedia app/mobile version (not sure if those are the same thing, but I think they are). If that place is here, I'd like to suggest that the preloaded edit summaries be removed or de-emphasized. I'm talking about the screen that comes up on the app after you have made an edit, but before saving, that asks "How did you improve this article?", with four options: Fixed typo, Fixed grammar, Added links, and Other. Since this feature was added, the "Fixed typo" edit summary has predictably become very popular - it is the first and most prominent option, and it's not obvious that skipping the edit summary is possible - but almost never accurate. As a patroller, I would rather see no edit summary at all than a false one; false edit summaries, until recently, usually indicated to me that a user was purposefully trying to evade detection. --Bongwarrior (talk) 09:35, 6 August 2014 (UTC)

Seems this is specific to the Mobile app. I filed a bug report on bugzilla:, the place where these things go. The suggestion is known as bugzilla:69168. —TheDJ (talk • contribs) 10:29, 6 August 2014 (UTC)

Thanks. I've responded on the bug. TO keep the discussion in one place, please respond there. --Dan Garry, Wikimedia Foundation (talk) 14:55, 6 August 2014 (UTC)

Thanks to both of you. --Bongwarrior (talk) 17:18, 6 August 2014 (UTC)

When editing many pages (in Chrome + Windows 7), for instance List_of_longest_cantilever_bridge_spans, I see two errors in the console:

1. JavaScript parse error: Parse error: Missing operand in file 'MediaWiki:Gadget-geonotice.js' on line 11
2. XMLHttpRequest cannot load https://commons.wikimedia.org/w/api.php. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'https://en.wikipedia.org' is therefore not allowed access.

Ruslik_Zero 10:37, 6 August 2014 (UTC)

First should be fixed. I cannot reproduce the second error, which is not Geonotice related. -- [[User:Edokter]] {{talk}} 10:45, 6 August 2014 (UTC)

(edit conflict) Sounds like they've actioned #Migrating Geonotice to a gadget above. Helder.wiki, Edokter: what say you? --Redrose64 (talk) 10:52, 6 August 2014 (UTC)

I would like to move MediaWiki:Geonotice.js to MediaWiki:Gadget-geonotice.js, so that

• Users can opt-out and disable the feature in their preferences (requested in 2010 by Peter, at MediaWiki talk:Geonotice.js#Can I turn this off? and by other user at Wikipedia talk:Geonotice#Shut it off??);
• The CSS (presentation) is separated from the JS code (logic); and
• ResourceLoader will minify the code
• ResourceLoader will load it in the same HTTP request used for other gadgets

If you enable the option "<gadget-geonotice>" which I added to testwiki:Special:Preferences#mw-prefsection-gadgets, you should see a test notice on testwiki:Special:Watchlist. On English Wikipedia, the gadget would be enabled by default, to keep the current behavior. Helder.wiki 00:18, 27 July 2014 (UTC)

It already is opt-out; I've explained at least three times how to do it. Most (if not all) should be in the archives of this page.

li.geonotice { display: none; }

in Special:MyPage/common.css. --Redrose64 (talk) 00:26, 27 July 2014 (UTC)

That would still load the JavaScript (in a separate request) and keep the CSS mixed in the middle of the JavaScript code. Helder.wiki 00:29, 27 July 2014 (UTC)

Seems sane, though it might be confusing to some users why they would find that type of notification in their gadgets... Perhaps simply makt it a hidden always on gadget, and continue to have the opt out behavior as before (as described by Redrose). —TheDJ (talk • contribs) 08:57, 28 July 2014 (UTC)

@TheDJ: I don't think it is confusing to have this script in the list where (most) other local scripts are.

And "hidden" default gadgets are not supported (mw:Gadgets 2.0 is not a reality yet, and we are using a hack to implement "hidden" gadgets). Even if it was supported, it would not allow users to opt-out from loading the script code, which is one of my objectives. Helder 12:32, 28 July 2014 (UTC)

• Making this a gadget seems reasonable (on the condition it's definitely opt-out; opt-in would be self-defeating). However, it might be a good opportunity to look at changing all watchlist messaging including non-geotargeted messages into a single opt-out gadget (as I believe Commons uses). Andrew Gray (talk) 11:47, 28 July 2014 (UTC)

One other question - would this materially affect how we add new geonotices? There's only two or three of us regularly maintaining them and I for one don't really understand the backend very well :-). Andrew Gray (talk) 11:59, 28 July 2014 (UTC)

@Andrew Gray: Not really. The only change would be the title of the page used for that. And I think you could use the existing geonotice script/gadget for non-geotargeted messages as well: just set large coordinates (e.g. corners:[ [-1000,-1000], [1000, 1000] ], as I did on the testwiki) and it should be visible for all (most?) users. Helder 12:19, 28 July 2014 (UTC)

On reflection, I think keeping existing watchlist notices as they are is probably good (though styling them to be consistent with geonotices one way or another would help) - they're a pretty core tool for "active promotion of important issues" and we should probably ensure they remain visible even to people who've opted out of local notices. Andrew Gray (talk) 19:18, 28 July 2014 (UTC)

You are referring to the part which appears above the horizontal rule on the watchlist right? Helder 19:58, 28 July 2014 (UTC)

Yes indeed :-) Andrew Gray (talk) 20:28, 28 July 2014 (UTC)

Any more comments? Any problems found in the test version? Can this be implemented now? Helder 13:59, 4 August 2014 (UTC)

I see no problem. Need exact instructions though, unless it is a straight move (in which case, I just need to didable it in Common.js and make a gadget definition). -- [[User:Edokter]] {{talk}} 18:42, 5 August 2014 (UTC)

@Edokter: we can copy the the JS from test wiki (just updating the list of notices to match what is on English Wikipedia right now), move the CSS into a separate page, remove the loader code from MediaWiki:Common.js/watchlist.js, add a line to MediaWiki:Gadgets-definition and create the gadget's description. I have the (global) editinterface permission now, so I could recheck my edits on testwiki and replicate the relevant changes to enwiki. Helder 21:23, 5 August 2014 (UTC)

Ah, you don't really need my help then :) The plan is sound. Create the gadget here and I will double-check the code before we activate it. -- [[User:Edokter]] {{talk}} 21:53, 5 August 2014 (UTC)

@Edokter: when moving the page we will need to activate the gadget and remove the old loader code at the same time, so in order to give you the chance to review the code, I updated the version on testwiki instead. On the other hand, creating MediaWiki:Gadget-geonotice.css and MediaWiki:Gadget-geonotice would not cause problems while the gadget is not created, so these are done. Helder 23:16, 5 August 2014 (UTC)

I copied the .js gadget from testwiki. Since the code is modified, a move would not work anyway. -- [[User:Edokter]] {{talk}} 08:09, 6 August 2014 (UTC)

I'll copy, then move. That will move all watchers. I'm going to make the switchover. -- [[User:Edokter]] {{talk}} 08:36, 6 August 2014 (UTC)

  Done. Geonotice is now a (default enabled) gadget. -- [[User:Edokter]] {{talk}} 08:56, 6 August 2014 (UTC)

The bulk is still loaded on every page load. How about moving the bulk to MediaWiki:Gadget-geonotice-core.js? -- [[User:Edokter]] {{talk}} 10:46, 6 August 2014 (UTC)

@Edokter: that is a good idea. How about splitting it like this?

1. Module "ext.gadget.geonotice"
   • MediaWiki:Gadget-geonotice.js: only a loader module (tests if the user is in the watchlist, load the other module if needed)
2. Module "ext.gadget.geonotice-core"
   • MediaWiki:Gadget-geonotice-core.css: the current MediaWiki:Gadget-geonotice.css
   • MediaWiki:Gadget-geonotice-core.js: the code of geoWikiLinker, hideGeonotice, displayGeonotice and runGeonotice (which is currently at the bottom of MediaWiki:Gadget-geonotice.js)
   • MediaWiki:Gadget-geonotice-list.js: the list of notices

The separation between the list of notices and the code which uses it should help avoiding accidental changes in the core code, and allow people to watch for changes in the core script separately. It may also help in using the code on other wikis (which have their own list of notices, but could use a common "core" JS). Helder 13:35, 6 August 2014 (UTC)

Lazy-loading the core part is easy, but can I lazy-load the list in the same way (by defining it as a gadget and call mw.loader.load)? -- [[User:Edokter]] {{talk}} 14:56, 7 August 2014 (UTC)

@Edokter: check the current version on the test wiki: testwiki:Special:PrefixIndex/MediaWiki:Gadget-geonotice. We can add more than one js page to each gadget, and they are merged together in a single module. Helder 01:43, 8 August 2014 (UTC)

That is what I needed to know. Thanks. -- [[User:Edokter]] {{talk}} 07:46, 8 August 2014 (UTC)

Also   Done. That should save some heap of code being loaded. -- [[User:Edokter]] {{talk}} 08:41, 8 August 2014 (UTC)

During the past week I have running reflinks tools on the Sonia Sotomayor page to bring things up to date. It seemed to work well for the first 170 references, but cite #180 and #185 do not seem to match up with the actual article citations. In reflinks tools cite#180 gives a redlink for a "Gingrich" citation, but the article citation number has nothing to do with Gingrich. Could someone look at this, since it has not worked for two days. This is the reflink invoked to produce the list of link checks checklinks report. LawrencePrincipe (talk) 00:14, 5 August 2014 (UTC)

Reflinks is still not working after 2-3 more days, and I noticed there is another Reflinks village pump section above currently at #13 on this page. Could someone do a look and see at this. For example on Sonia Sotomayor footnote #263 does link successfully to Esquire magazine, but Reflinks gives a deadlink notice for it to somewhere at an Arizona news press. LawrencePrincipe (talk) 13:42, 7 August 2014 (UTC)

@LawrencePrincipe: It appears you (and others) have done a lot of work on the Sonia Sotomayor article, so we can't reproduce the issue by running Reflinks on the current version. You may want to create a test page in your userspace that will generate the same issues you were seeing, and then provide a link on User talk:Dispenser/Reflinks. Good luck! GoingBatty (talk) 16:40, 7 August 2014 (UTC)

@GoingBatty:, Hi Going Batty, yes, that's a good point. I will stop all editing for the next 24-48 hrs until someone can confirm the reflinks error. Cite Number 263 gives the following deadlink warning:

263 Sotomayor urges anxious grads to embrace future (info) [kold.com]

accessdate=May 19, 2010

date=May 8, 2010

publisher=KOLD-TV

410 Dead since 2011-01-17

However, when you go straight to footnote #263 in the article, the article footnote at 263 has nothing to do with the KOLD-TV deadlink notification from reflinks but uses Esquire magazine instead. I will postpone all update edits until someone confirms. LawrencePrincipe (talk) 18:21, 7 August 2014 (UTC)

@LawrencePrincipe: Oh, you're using Checklinks, not Reflinks. I confirm that Checklinks is showing that #263 is kold.com, even though the article shows kold.com is #259. The proper place to report this issue is User talk:Dispenser/Checklinks so Dispenser can resolve the issue. Good luck! GoingBatty (talk) 03:23, 8 August 2014 (UTC)

Without logging on I look at any WP article and the first two tabs across the top read "Article" and "Talk".

Then I log on and the tabs change to "Page" and "Discussion". Why? This might confuse a new user.

Suggest changing the tabs to read "Article" and "Talk", to agree with the way articles and talk pages are referred to throughout the project.

Monobook skin, Firefox 31: Noyster (talk), 10:12, 6 August 2014 (UTC)

On Vector you should not have that problem, and that's what most 'new' people are on, so I wouldn't worry about it too much. —TheDJ (talk • contribs) 10:21, 6 August 2014 (UTC)

I cannot reproduce. Do you have any specific pages as examples? -- [[User:Edokter]] {{talk}} 10:23, 6 August 2014 (UTC)

This looks like an issue where English Wikipedia's customised MediaWiki messages were only set for English (en) and not for any other language. (The messages are MediaWiki:Nstab-main and MediaWiki:Talk.) Noyster, what language have you set in your settings? If it is en-GB or en-CA then these edits should have fixed the problem, but if it is something else then it will still be as it was before. Quite a lot of messages have only been customised for English (en), not British English (en-GB) or Canadian English (en-CA), so a lot of users choose to set their language to en. — Mr. Stradivarius ^{♪ talk ♪} 10:56, 6 August 2014 (UTC)

Yes, it was en-GB. The change has already taken effect. Quick work!: Noyster (talk), 11:00, 6 August 2014 (UTC)

Per Wikipedia:Database reports/User preferences Spanish, French, Indonesian, British English and Arabic are the top five languages. --  Gadget850 ^talk 00:50, 7 August 2014 (UTC)

The following is copied from the Help desk:

The link in a tab button at the top of Wikipedia pages to a non-existing page (like say a non-existing talk page) displays bluish purple. It is hard to distinguish them from existing pages. Is there css code that will make them red like normal links to non-existing pages. —teb728 t c 00:57, 6 August 2014 (UTC)

Actually, they normally are red. No idea why you are seeing that colour. Try temporarily removing your existing css and see what you then get, though I can't see anything that should change the tab colours in your vector css. SpinningSpark 02:15, 6 August 2014 (UTC)

I tried not-logged-in sessions on another browser and another PC; they looked the same.

I looked at the generated HTML: For a normal red link class="new" is applied to the anchor. For a tab button the anchor is inside span inside li; class="new" is applied to the li; the anchor has no class.

As a workaround I added li.new a {color:Black; background:#ffc0c0;} to my vector css. The background is pale red as intended, but the text is still purple. —teb728 t c 10:28, 6 August 2014 (UTC)

Yes, in fact, I can't even get it to change colour at all. I thought that this css

  #p-cactions a.new {
	color: #ba0000;
  }
   #p-cactions a.new:visited {
	color: #a55858;
  } 

should do the job, but I can't get it to work, even though similar css succeeds in changing the colours of the non-redlinked tabs. Try asking at WP:VPT. SpinningSpark 10:44, 6 August 2014 (UTC)

@Spinningspark: The problem is that it's not the <a> tag that has the new class, but the <li> element around it. I think the CSS

#p-cactions li.new a {color:#ba0000}

should work. I'm assuming you use Monobook, since in Vector #p-cactions appears to be a div containing the "more" dropdown menu only rather than all tab links.

Though for me non-existing top menu links are red as normal in all four major skins. SiBr₄ (talk) 21:50, 6 August 2014 (UTC)

@SiBr4: So why does li.new a {color:Black;} not change the color for me? I see purple no matter what color I specify. (I use Vector.) SpinningSpark is the helper at help desk; I'm the one with the problem. —teb728 t c 23:10, 6 August 2014 (UTC)

It's possible the CSS rule is getting overwritten by sitewide CSS rules applied to each individual tab link. Does it work if you add !important, as in li.new a {color:black !important;}? SiBr₄ (talk) 23:17, 6 August 2014 (UTC)

That works. Thank you! —teb728 t c 00:12, 7 August 2014 (UTC)

This was originally posted here, but then moved to help desk for some strange reason. --Redrose64 (talk) 12:45, 6 August 2014 (UTC)

For whatever it is worth, I moved it the help desk because I thought that was a better for non-bug questions. I moved it back not only on Spinningspark's recommendation but also because I now suspect there is a bug in either the generated code and/or the css files. —teb728 t c 20:20, 6 August 2014 (UTC)

I think that there's a problem with the site CSS for Vector skin:

div.vectorTabs li.new a,
div.vectorTabs li.new a:visited {
    color: #A55858;
}

this sets the colour of redlinks in the tabs of Vector skin to #A55858   - whether visited or not. That dark red might seem purple. Contrast that with Monobook, which has

#p-cactions .new a {
    color: #BA0000;
}

this sets the colour of redlinks in the tabs of Monobook skin to #BA0000   - a much brighter colour. To use this brighter colour in Vector, add

div.vectorTabs li.new a,
div.vectorTabs li.new a:visited {
    color: #BA0000;
}

to Special:MyPage/vector.css --Redrose64 (talk) 23:31, 6 August 2014 (UTC)

Thank you! Shouldn't that value be used in the site CSS Vector file? Even #BA0000 seems a little dull to me. Ordinary red links look closer to #E00000. —teb728 t c 00:12, 7 August 2014 (UTC)

@TEB728: I've checked how normal in-text redlinks (i.e. those not in the tabs etc.) are styled - for Vector the site CSS is

a.new,
#p-personal a.new { 
    color: #BA0000;
}
a.new:visited,
#p-personal a.new:visited { 
    color: #A55858;
}

and for MonoBook the site CSS is

a.new,
#p-personal a.new { 
    color: #CC2200;
}
a.new:visited,
#p-personal a.new:visited { 
    color: #A55858;
}

so in normal text, the visited redlinks are the same for both Vector and MonoBook, i.e. #A55858  , but the unvisited redlinks differ: in Vector they are #BA0000   and in MonoBook, they are #CC2200  . --Redrose64 (talk) 09:50, 7 August 2014 (UTC)

There seems to be an issue with the {{DISPLAYTITLE}} template. When it's used in a article about an album, to override the normal italic formatting for the article title that's embedded in the {{Infobox album}} template, an unsightly red warning is displayed at the beginning of the article. An example is the current version of "Europe '72 (Live)", here. Without the Displaytitle override, the article title would be displayed as "Europe '72 (Live)", but the parenthetic text is part of the album title and so should also be italicized. This was working fine before -- and the italicization is still working -- but now there's a nasty message displayed, saying "Warning: Display title "<i>Europe '72 (Live)</i>" overrides earlier display title "<i>Europe '72</i> (Live)"." Anyone know how to get this fixed? — Mudwater ^(Talk) 19:53, 6 August 2014 (UTC)

@Mudwater: If you want to use {{DISPLAYTITLE:}} (which is a behaviour switch, not a template), you need to also use |Italic title=no as advised in the box near the top of the documentation for {{infobox album}}. It's the same problem as described at Template talk:Infobox film#Warning. --Redrose64 (talk) 21:51, 6 August 2014 (UTC)

@Redrose64: Very good, thanks for providing the answer. The "Italic title = no" didn't used to be necessary, something's changed, but that's okay, this works now. I appreciate the help. — Mudwater ^(Talk) 22:16, 6 August 2014 (UTC)

@Mudwater: The "something" that changed is covered at Wikipedia:Village pump (technical)/Archive 128#Tech News: 2014-29 and Wikipedia:Village pump (technical)/Archive 129#DISPLAYTITLE warning. MediaWiki now complains if a page has more than one {{DISPLAYTITLE:}} even if one of them is part of a template's code, like {{infobox album}}, {{infobox book}} or {{infobox film}}. --Redrose64 (talk) 13:23, 7 August 2014 (UTC)

@Redrose64: Interesting. That explains it all right. Thanks. — Mudwater ^(Talk) 13:27, 7 August 2014 (UTC)

I thought that using |italic title=force with no extra {{DISPLAYTITLE}} would also work, but I was mistaken. GoingBatty (talk) 16:47, 7 August 2014 (UTC)

Is anyone else having issues getting to webcitation.org? I have been trying for most of August 6, to archive some sites, and I have not been able to. It says the website is down. I also tried to access already archived links to no avail either. I know there was talk a while back that it was going to be shut down, due to lack of funding, so I hope this is not the case. If so, that is very disconcerting. - Favre1fan93 (talk) 03:52, 7 August 2014 (UTC)

Yes, I'm seeing it down as well. I wouldn't worry yet, as this does happen from time to time, usually for maintenance. Interestingly, Archive.org is down for maintenance as well. — Huntster (t @ c) 03:56, 7 August 2014 (UTC)

It looks like it is failing on host resolution, could imply infrastructure issues. downforeveryone reports it's down for all. Last I checked the cite, the issue wasn't continuing the site but just not accepting any new cites if they didn't have the funding, so I doubt it's down and out for good. --MASEM (t) 04:00, 7 August 2014 (UTC)

You can see log messages by searching for the log message type, e.g. Special:Log/massmessage or Special:Log/import. If you search for log entries by log action, these two log entries will show up. For example, if someone sends a mass message, the log entry will still show up at Special:Log/massmessage, even if it says "log action removed". It seems that deleted content accidentally is exposed to users this way. Is it really supposed to be like this?

I discovered this because I saw the log action quoted below when I was looking at "Special:Log/someaction" at metawiki. I won't tell which log action I was looking at to avoid revealing unnecessary private information.

• 18:01, 10 June 2014 Barras (talk | contribs) (log action removed) (per enwp arb request)

Stefan2 (talk) 12:53, 7 August 2014 (UTC)

Is there a way to get a merged feed for unregistered users over an IP range? Let's say you're @congressedits (which I'm not), and that Congress upgrades to a IPv6 system. Would the only way to search a standard subnet array be to search 2^64 (in other terms, 18446744073709551616) different usernames to cover the system? On a smaller scale, I've tried crawling a IPv6 '0/16' network, which takes more than five hours and a whole lot of resources on both of our ends.

It seems like there should be an easier way to do this, either to query for active usernames over an IP range or to combine RSS feeds over a range without accessing them individually. Is there? What am I missing? — Preceding unsigned comment added by Joecover (talk • contribs) 19:55, 7 August 2014 (UTC)

There's a gadget that queries the contributions for an IP range: it's title begins with "Allow /16, /24 and /27 – /32 CIDR ranges ...". Here's its JavaScript code. Graham87 07:19, 8 August 2014 (UTC)

MariaDB [enwiki_p]> SHOW DATABASES LIKE "p5%\_p";
+----------------------------+
| Database (p5%\_p)          |
+----------------------------+
| p50380g50592__interwikis_p |
| p50380g50921__ghel_p       |
| p50380g50921__wma_p        |
+----------------------------+
3 rows in set (0.05 sec)

Labs projects are far less open with data than their Toolserver counterparts. Is there anything (I've already contacted some authors) we can do? Maybe a less fucked up naming system? (http://tools.wmflabs.org/50592 is returning a blank page)? Should we forking non-open data projects before User:Silke WMDE deletes the Toolserver backups? — Dispenser 21:13, 8 August 2014 (UTC)

I've recently become involved in editing Template:Iraqi insurgency detailed map. The opening syntax for the template is
{{#invoke:location map|top |Iraq |AlternativeMap=Iraq location map2.svg |float=left |width=1800|caption=y}}
My question is how to make it so the image, File:Iraq location map2.svg is rendered unclickable, so as to leave the icons representing various areas of Iraq as the only clickable pieces on the map? As it is now, the map is clickable, which, for those with Twinkle, ends up loading infoboxes over important information when the mouse hovers over it. Basically, it's a minor nuisance with (hopefully) an easy solution. Normally, I would have added a blank |alt= command to make an image non-clickable, but this doesn't seem to be working and I don't understand this advanced coding to know what {{#invoke:... means. Any help? -- Veggies (talk) 19:20, 8 August 2014 (UTC)

The two <div> have nothing to do with it, so I've removed them above. The #invoke: tells us that Lua is going on, which is not normal template code, which makes it more difficult to trace through. The next two words are location map which tells me that the underlying code is in Module:Location map. This, apparently, recognises a |link= parameter, which we should be able to utilise in order to do what you want, but I can't make it de-link the image. Jackmcbarn (talk · contribs) may know how. --Redrose64 (talk) 20:51, 8 August 2014 (UTC)

Making the image unclickable would be a violation of its license. Jackmcbarn (talk) 20:53, 8 August 2014 (UTC)

Could you say more, please? The image is CC-3.0. Does that mandate clickability back to the file page or just the author's name in the caption? -- Veggies (talk) 20:59, 8 August 2014 (UTC)

From a legal point of view, when we display a CC-BY-SA image, we need to do two things: first, provide attribution to the copyright holder, and second, make it clear that the image is under a CC-BY-SA licence. We normally do these two things via a link to the file description page, which is why Jackmcbarn says that making the image unclickable would be a violation of the licence. Technically we could make the image unclickable if we provided these two things another way, such as in an image caption, but on many pages that isn't desirable, and just linking to the file page is neater. — Mr. Stradivarius ^{♪ talk ♪} 04:00, 9 August 2014 (UTC)

In templates using <imagemap> syntax, the background image is unlinked and there is a   icon at the top right of the caption that links to the image file page. That could be made an option for Module:Location map too. If that's not possible a simple link like "(background file)" could also just be added to the caption. SiBr₄ (talk) 09:30, 9 August 2014 (UTC)

@Veggies: I added the magnify icon to the module, and the new parameter maplink allows control over the link parameter of the image. Jackmcbarn (talk) 16:27, 9 August 2014 (UTC)

Yikes... clicking the icon makes Media Viewer go into a fit. -- [[User:Edokter]] {{talk}} 17:22, 9 August 2014 (UTC)

@Edokter: Fixed for now by disabling MediaViewer for fake thumbnails. I plan to write a proper fix for MediaViewer itself at some point. See bugzilla:69353. Jackmcbarn (talk) 19:05, 9 August 2014 (UTC)

As a logged out ip, I was trying to make a very rapid fix to a typo/misspelling (replacing "the later" with "the latter") I happened to spot in Joseph Kosma#Biography. I have been unable to make this edit. Apparently, An automated filter has identified this edit as potentially unconstructive, and it has been disallowed. I have also been unable to to report the error, as requested, because the page I was directed to seems to be protected from ip contributions.

In this experience, a simple fix -- in the spirit of Wikipedia -- appears unwelcome.

(Note: Please do not tell me to get an account or log in; there are various reasons why individual users may actively prefer to contribute as an ip.)
86.157.144.73 (talk) 12:17, 10 August 2014 (UTC)

It's protected because it's not exactly the page at which you're supposed to make the report. Click the "Click here to report a false positive" link to go to the right page (it's a subpage), or if you view the source of the main page, you get a big warning that says that you need to go to the other page. Don't worry about doing it this time, since I've filed a report for you and noted that this is definitely a false positive; I can't comment on the technical side of things, since I don't understand them. Nyttend (talk) 13:28, 10 August 2014 (UTC)

Thank you very much for doing that Nyttend. I see the link to the subpage now, and I'll go through the hoops perhaps when I have time. From a broader perspective, I think it's worth bearing in mind that some new contributors may be encountering this stuff as their first editing experience :-/ 86.157.144.73 (talk) 14:21, 10 August 2014 (UTC)

After some work on this issue, I would like to announce the new XAgent of XTools gadget. Currently it is work in progress, but ready to use. If you stumble over a bug or if you have further suggestions, feel free to report.

• XTools gadget
• Bugs/Feedback: Bugzilla (preferably)   GitHub .

Enjoy. --Hedonil (talk) 16:30, 10 August 2014 (UTC)

Thanks Hedonil. This great gadget keeps getting better! --NeilN ^{talk to me} 18:17, 10 August 2014 (UTC)

The URL

http://en.wikipedia.org/wiki/Option_symbol

displays only the following text...

<link rel="stylesheet" href="//bits.wikimedia.org/en.wikipedia.org/load.php?debug=false&lang=en&modules=ext.gadget.DRN-wizard%2CReferenceTooltips%2Ccharinsert%2CrefToolbar%2Cteahouse%7Cext.rtlcite%2Cwikihiero%7Cext.uls.nojs%7Cext.visualEditor.viewPageTarget.noscript%7Cmediawiki.legacy.commonPrint%2Cshared%7Cmediawiki.skinning.interface%7Cmediawiki.ui.button%7Cskins.vector.styles%7Cwikibase.client.init%2Cnolanglinks&

No Wikipedia page appears.

I tried to submit this via Bugzilla, but it hung while loading. — Preceding unsigned comment added by 165.121.80.236 (talk) 22:18, 5 August 2014 (UTC)

I purged the page, which should have fixed this. If it still is broken, then you should try to bypass your browser's cache. —TheDJ (talk • contribs) 09:21, 6 August 2014 (UTC)

The block "<link rel=…" text in your comment is breaking the layout on my monitor and sticking out to the right. Could you enclose it in <pre style="overflow:auto"> </pre> tags? benzband (talk) 14:22, 10 August 2014 (UTC)

In an article the templates are too many, so the last of them are not appear. Ok, the easy solution is to remove some of them. Is there any other solution? Xaris333 (talk) 02:50, 8 August 2014 (UTC)

@Xaris333: Could you please let us know which article? Thanks! GoingBatty (talk) 03:24, 8 August 2014 (UTC)

It is at Greek wiki. el:Πορεία των κυπριακών ομάδων στα ευρωπαϊκά κύπελλα ποδοσφαίρου Xaris333 (talk) 04:08, 8 August 2014 (UTC)

It looks fine now. But if you come across this in the future, one of the things you can do is Subst: some of the simpler templates from before the parser error (everything at and after cannot be evaluated to subst in the template result) in order to reduce the expansion size of the page. VanIsaac_WS^cont 04:37, 8 August 2014 (UTC)

Its not fine. Look at the end. You can see Template:cite web and {{references}} (παραπομπές). Both are not working. Xaris333 (talk) 04:48, 8 August 2014 (UTC)

Xaris333, there are not too many templates and that is not the issue. You can remove half the article and it still has problems. As this is on the Greek Wikipedia, this is probably best handled by a Greek speaking person. Calling Magioladitis. Bgwhite (talk) 07:01, 8 August 2014 (UTC)

Ok, for future reference, this is what it looks like when you have too many templates on a page (scroll to the bottom). If you aren't getting red error messages saying the node count has been exceeded, your problem is something else. VanIsaac_WS^cont 07:53, 8 August 2014 (UTC)

• Look at the page source code. It tells me:

<!-- 
NewPP limit report
Parsed by mw1057
CPU time usage: 40.799 seconds
Real time usage: 41.401 seconds
Preprocessor visited node count: 303126/1000000
Preprocessor generated node count: 150774/1500000
Post‐expand include size: 2048000/2048000 bytes
Template argument size: 829659/2048000 bytes
Highest expansion depth: 17/40
Expensive parser function count: 0/500
-->

CPU time is very high, and post-expand include size maxed out. The latter probably is the reason for the problem. My guess would be that it's caused by too many "cite web" and "harvnb" templates. If those can be subst'ed, try that. Lupo 10:43, 8 August 2014 (UTC)

Ahh, excellent. So it looks like it's not that there are too many templates (node count is 1/3 of max), but that the page content is just too large. Looks like the article just plain needs to be split up. VanIsaac_WS^cont 05:50, 10 August 2014 (UTC)

Yes, $wgMaxArticleSize is set to 2000kB at WMF wikis: [39]. Lupo 10:38, 11 August 2014 (UTC)

Is there an easy way to generate a list of editors whose only edits are in their own userspace, so that it's easier to locate (manually) editors who are using Wikipedia (innocently mostly) as a webhost? Skittle (talk) 09:39, 8 August 2014 (UTC)

I wonder if the number of false positives of editors working on their first sandbox drafts might not be the overwhelming majority - thus making it a rather inefficient abuse detection tool? Roger (Dodger67) (talk) 10:29, 8 August 2014 (UTC)

I've wondered that too, but if there was a relatively easy way to do it I would probably still consider it worth investigating. I mean, ideally you'd also want to be able to filter by age of account and things like that, but that seems less likely to be achievable without extra effort. Skittle (talk) 11:22, 8 August 2014 (UTC)

Interesting idea. I may prototype something like that and see what the results looks like. Chillum 20:54, 11 August 2014 (UTC)

The sizing on the template Bo-textonly appears to have been adjusted to work with the Microsoft Himalaya font (default Tibetan font on MS Windows) which renders Tibetan text at a very small size. This template fixes that - but results in Tibetan text when displayed on other operating systems, or with other Tibetan fonts, being rendered too large and this can mess up line spacing. There is no "standard" size for Tibetan fonts - so one scaling size does not fit all - in fact some Tibetan fonts don't need any enlargement at all. Is there a way of fixing this so the re-sizing is based on the default Tibetan font being used on the client system?

Meanwhile I've put the scaling size on this template back to 130% where it was before Great Brightstar increased it. This is not ideal for all systems - Tibetan text will still be too big on many systems and maybe a little small on Windows - but it seems to be about the best compromise based on the different systems I've tried it on.

I haven't yet checked to see if this problem is found in other templates for Tibetan script.

Chris Fynn (talk) 06:08, 10 August 2014 (UTC)

I have made a test in Chinese Wikipedia's Sandbox. My computer uses Windows 8.1, it have a built-in font named "Microsoft Himalaya". Some Latin alphabets as same as Times New Roman in this font. In my test I found this font can be alignment with Times New Roman if I resize to 150%. Here is my result.--Great Brightstar (talk) 09:29, 10 August 2014 (UTC)

@Great Brightstar:That's exactly the problem. When you made the change to 150% you seem to have tested it only on your Windows system with the Microsoft Himalaya font which renders at a much smaller size than other Tibetan fonts. The default Tibetan fonts on Mac OSX (Kailash or Kokonor) don't need scaling - and if do you make them 150% then they are way to big. Similarly with DDC Uchen, Jomolhari Font on Linux or Windows. Not everyone uses Microsoft Windows - and even on Windows they may have installed a different Tibetan font. So you need to test these things on a variety of systems, with a variety of common fonts and in a variety of common browsers. Don't assume that what works on Windows with a particular font and a particular browser will work everywhere else. While the Microsoft Himalaya font needs 150% to look good, this is way too big on other systems and causes problems with line spacing - other fonts on other systems look good with no scaling at all (100%). So, unless we can somehow modify the template to make the scaling dependent on the system and font the client is using, then we need use a compromise scaling — say 130% or 125%. This will be a little small on Windows systems and a little big on Mac systems - but at least it is not too bad on either. Regards. Chris Fynn (talk) 10:22, 10 August 2014 (UTC)

Oh~I haven't consider it when I made my test.--Great Brightstar (talk) 08:16, 11 August 2014 (UTC)

Is there a way to make the "You are editing an out-of-date revision of this page" warning more prominent, e.g. by making the text red instead of black? The black text never gets my attention. I use Monobook skin and IE11. Thanks. DH85868993 (talk) 10:37, 10 August 2014 (UTC)

The message concerned is MediaWiki:Editingold, which is already in a big pink #FFDBDB   box. Most Wikipedias have their own ways of showing the message: for example, Welsh; German; Spanish; French; or Dutch - but in all cases, it's either coloured text on light background, or black text on coloured background - or even black on light. Red text on pink would probably fail WCAG unless the contrast ratio is as high as it is in my signature - where the red #a80000   is quite dark and the pink #ffeeee   is quite weak. --Redrose64 (talk) 08:30, 11 August 2014 (UTC)

@DH85868993: Above, I was considering the general case for all readers. If you want it changed on a personal basis, you can do this with some CSS. The current settings are essentially:

table#editingold {
  background-color: #FFDBDB;
  border-color: #BB7070;
  color: #000000;
}

Paste that into Special:MyPage/common.css, adjust the colours as you wish, and save. --Redrose64 (talk) 09:06, 11 August 2014 (UTC)

Thanks for the replies, @Redrose64:. However, I don't see a big pink box when I edit an old version - I see something like this:

Editing User:DH85868993/sandbox

From Wikipedia, the free encyclopedia

Revision as of 19:10, August 1, 2014 by DH85868993 (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Warning: You are editing an out-of-date revision of this page. If you save it, any changes made since this revision will be lost.

Edit window

The warning is in regular-sized (albeit bold) black text on a white background, "hidden" among the usual text above the edit box, which is why it doesn't grab my attention. So I gather I'm not seeing MediaWiki:Editingold for some reason? (BTW, I tried pasting that code into Special:MyPage/common.css (and clearing the cache) but it didn't seem to have any effect - but that's not surprising if I'm not seeing the Editingold message in the first place). I also tried changing to different skins, but again that didn't have any effect. DH85868993 (talk) 09:41, 11 August 2014 (UTC)

I'm guessing that your language is not set to default English then, probably to en-GB or en-CA - in which case you will be seeing MediaWiki:Editingold/en-GB or MediaWiki:Editingold/en-CA instead. We normally advise people not to use those two language codes, primarily because the language code affects only the system messages, and normally only the messages for default English are kept up to date. --Redrose64 (talk) 12:31, 11 August 2014 (UTC)

Yep, that's it - my language was set to en-GB; I changed it to default English and hey presto, I get a nice big pink box. Thanks for your help. DH85868993 (talk) 13:18, 11 August 2014 (UTC)

FYI: You can check if the contrast is acceptable using Template:Color contrast conformance. Helder 13:47, 11 August 2014 (UTC)

I posted this at WP:HELPDESK yesterday, but I didn't really get a response. I figured it may be a little too technical for that board, so I copied it here. If there is a better place to ask, please let me know.

Is there any way to enable a user script across all language wikipedias? Like common.js applies to all skins, but I want even more "common" than that... I can't find any mention of that, so I suspect it is not possible, but I just wanted to check in case I missed something. I have a script that will work on various different language wikipedias, but it has to be installed on each language first. On most non-en wikis I don't have autoconfirmed (or whatever the relevant group is) rights, so I can't create a js page for myself on those. That aside, it's a bit annoying to have to edit 50 different pages which are all connected to a global login anyway. Anyone know of something that could help?--Dudemanfellabra (talk) 05:41, 11 August 2014 (UTC)

Simple answer is no, not yet. However, if you want to use the same scripts over multiple wikis, you can do what I've done at User:Mdann52(alt)/common.js. However, you generally don't (AFAIK) have to be autoconfirmed to create pages (I made my js page on SEW before I was ac. --Mdann52talk to me! 06:11, 11 August 2014 (UTC)

I do note that mw:Extension:GlobalCssJs is being worked on. But in the mean time, Mdann52's method is what you need. Anomie⚔ 08:50, 11 August 2014 (UTC)

The deployment of mw:Extension:GlobalCssJs to WMF wikis is tracked on bugzilla:57891. Helder 14:37, 11 August 2014 (UTC)

07:43, 11 August 2014 (UTC)

I am no longer able to alter the functions in Vector skin. I don't want to change skin, but I'm annoyed that, with automatic suggestions disabled, anything I search leads to search results instead of exact target. Is there a way to bring these buttons back to Vector skin? I don't like Help:Go either. --George Ho (talk) 09:52, 11 August 2014 (UTC)

A user script could be made by someone capable to write a few lines of JS. —TheDJ (talk • contribs) 14:05, 11 August 2014 (UTC)

Formerly wikiviewstats used a 23:00 to 22:59 (UTC) time range while stats.grok.se used the 00:00 to 23:59 (UTC) time range. You can tell this by observing that hourly totals are available between 35 and 50 minutes after the hour ends about 90% of the time. Thus, you can usually see the hourly totals for the final hour of the day (labelled 23:00) at between 23:35 and 23:50, meaning that they are for some time period ending before 23:35 and assuming they are from a time period that ends on the hour at best they are from the 22:00 to 22:59 (UTC). This means that the hour reported as the first hour of the day is really from 23:00 to 23:59 (UTC). Formerly, stats.grok.se included the 23:00 to 23:59 (UTC) time period in the proper calendar date totals. Now, if you monitor days in which the 23:00 to 23:59 (UTC) hour has a huge spike or dip in page views from the prior day, you can see that stats.grok.se is using the same incorrect time of day range as wikiviewstats. Note dates with these spike/dip events are common among DYK candidates. When did stats.grok.se join in the misreporting of daily totals?--TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 12:15, 10 August 2014 (UTC)

I should have pinged Henrik here.--TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 04:11, 12 August 2014 (UTC)

Note that I have revised WP:DYKSTATS and WP:TFASTATS to explain this oddity, but don't see where to make a similar comment at WP:TFLSTATS.--TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 04:21, 12 August 2014 (UTC)

Has there been some change that affects infobox image display? I made a change to East Lindsey which was not infobox related, but after saving got a script error as follows.

Lua error: bad argument #1 to 'sub' (string expected, got nil).

Backtrace:

    [C]: in function "v"
    mw.ustring.lua:61: in function "sub"
    Module:InfoboxImage:106: in function "IsPlaceholder"
    Module:InfoboxImage:134: in function "chunk"
    mw.lua:518: ?
    [C]: in function "getExpandedArgument"
    mw.lua:162: ?
    Module:Infobox:321: in function "preprocessArgs"
    Module:Infobox:374: in function "chunk"
    mw.lua:518: ?

Any clues? Keith D (talk) 20:49, 11 August 2014 (UTC)

@Keith D: I don't see an error now. Jackmcbarn (talk) 21:04, 11 August 2014 (UTC)

Reloaded the page but still getting the error. Keith D (talk) 21:08, 11 August 2014 (UTC)

Try purging. -- [[User:Edokter]] {{talk}} 22:00, 11 August 2014 (UTC)

Thanks - that seems to have fixed it. Keith D (talk) 22:45, 11 August 2014 (UTC)

The GeoGroup template appears to not be working today, or is it just me? Example 130.88.141.34 (talk) 08:05, 12 August 2014 (UTC)

The kmlexport tool on toolslab that this template depends on indeed seems to have an issue right now. I informed the operator of that specific tool by sending him an email. —TheDJ (talk • contribs) 09:02, 12 August 2014 (UTC)

Thank you for the help. 130.88.141.34 (talk) 09:16, 12 August 2014 (UTC)

I've been away on Wikibreak. I have noticed as I start to return that while I was gone there has been a change to the css that controls the display of <code>...</code>, which, as you can see is wrapped in pretty little boxes. I suppose that it looks ok for short little things; not so good when the wrapped text spans multiple lines or when the new css disrupts previous formatting. For example, Citation Style 1 error messages used to look something like this (font size is controlled by {{reflist}}):

|accessdate= requires |url=

(this error message uses <span style="font-family:monospace,Courier">...</span>)

But, the same error message now looks like this:

|accessdate= requires |url=

In Module:Citation/CS1/Configuration I can replace <code>...</code> with <tt>...</tt>:

|accessdate= requires |url=

But, while not supported by HTML5, <tt>...</tt> is still supported by some Wikipedia css somewhere. I can see where it is part of a <link rel="stylesheet" href="... very long link..." /> but I haven't been able to find the matching (human readable) css source file – anyone know where it is? Can I trust that <tt>...</tt> will continue to be supported? If this change to <code>...</code> was necessary (I don't think it is) then there needs to be a way to display code-like text without all the radiused borders.

In Module:Citation/CS1/Configuration, error messages are wrapped in <span class="error citation-comment>...</span>. Anyone know where that class is defined? Perhaps it can be modified to override the <code>...</code> styling.

—Trappist the monk (talk) 22:42, 9 August 2014 (UTC)

@Trappist the monk: It's from skins/common/commonElements.css. Jackmcbarn (talk) 22:53, 9 August 2014 (UTC)

Don't use the deprecated tag <tt>. Use the appropriated replacement (check WP:HTML5). Helder 23:11, 9 August 2014 (UTC)

Ah, thank you. WP:HTML5 would seem to suggest that <kdb>...</kdb> is the proper replacement for <code>...</code> in these error messages. Yes? Wouldn't it also suggest that <code>...</code> is the wrong markup for commonly used templates such as {{tlx}}, {{para}}, etc.?

Anyone know where <span class="error citation-comment>...</span> used in Module:Citation/CS1/Configuration is defined?

—Trappist the monk (talk) 23:45, 9 August 2014 (UTC)

@Trappist the monk: .error is styled in skins/common/shared.css. I don't think .citation-comment is styled anywhere. Jackmcbarn (talk) 02:46, 10 August 2014 (UTC)

Thank you. What we have here is a Doh! slap my forehead moment. .citation-comment is defined at Help:CS1_errors and is used to either show or hide all CS1 error messages.

—Trappist the monk (talk) 12:57, 10 August 2014 (UTC)

Please don't use <kbd>...</kbd> (n.b. not <kdb>...</kdb>) as a general replacement for either <code>...</code> or <tt>...</tt>, see Wikipedia:Village pump (technical)/Archive 129#Styling of code element. In many cases, one of <pre>...</pre>, <samp>...</samp> or <var>...</var> may be the semantically better choice. --Redrose64 (talk) 00:24, 11 August 2014 (UTC)

Hadn't intended to use <kbd>...</kbd> as a general replacement for <code>...</code>. But, in the specific cases I'm thinking of (CS1 error messages) <kbd>...</kbd> would wrap user input to the CS1 template. That's semantically correct, is it not?

—Trappist the monk (talk) 00:46, 11 August 2014 (UTC)

You should be able to use <code style="border: 0;">...</code> to override the site style while maintaining the semantics. I finally could not stand it and added it to my personal CSS. --  Gadget850 ^talk 01:01, 11 August 2014 (UTC)

True, but is that semantically correct? And that was Editor Redrose64's point.

—Trappist the monk (talk) 12:41, 11 August 2014 (UTC)

Not quite. The thing is, the code element is somewhat general-purpose (it "represents a fragment of computer code"), so is semantically good, but unfortunately nowadays looks like this with the enforced extra padding, border and black text that some consider undesirable. To avoid these three new effects, but keep the monospace font, you have three choices: (i) use a non-obsolete element like samp, which "represents (sample) output from a program or computing system" (and looks like this) and kbd, which "represents user input" (and looks like this); (ii) style up a <span>, which won't indicate semantics; or (iii) use the obsolete tt element (which I do not wish to encourage, and not just because it also won't indicate semantics). Regarding choice (ii), any styling is possible, but it's probably best to use something approximating the old appearance for code. Until recently, the code element essentially had two style declarations, one of which was in a rule that was shared with some other elements like kbd, the other was in a rule specific to code:

pre,
code,
tt,
kbd,
samp,
.mw-code {
  font-family: monospace,Courier;
}
code {
  background-color: #F9F9F9;
}

so we can style a span thus: <span style="font-family: monospace,Courier; background-color: #F9F9F9;">which looks like this</span> →which looks like this. However, this doesn't indicate semantics, so it's probably better to start off with <code> and work back towards the appearance that it formerly had. On or before 31 July, a few more declarations were added to that second rule, and it is now:

code {
  color: #000;
  background-color: #F9F9F9;
  border: 1px solid #DDD;
  border-radius: 2px;
  padding: 1px 4px;
}

We can thus emulate the old appearance by nullifying the new properties: <code style="color:inherit; border:inherit; padding:inherit;">Example</code> →Example; so we can have

|accessdate= requires |url=

If you want that behaviour for all code elements, add

code {
  color: inherit;
  border: inherit;
  padding: inherit;
}

to Special:MyPage/common.css --Redrose64 (talk) 14:52, 11 August 2014 (UTC)

Ignoring the style aspects for the time being, doesn't the semantic attribute specified by W3C for <kbd>...</kbd> make <kbd>...</kbd> the correct HTML element for the CS1 parameters listed in the CS1 error messages emitted by Module:Citation/CS1? <samp>...</samp> seems inappropriate because CS1 doesn't output parameters and <code>...</code> is for code snippets which these error messages are not.

—Trappist the monk (talk) 11:57, 12 August 2014 (UTC)

Well... Both "|accessdate=" and "|url=" are snippets of Wiki-text code. Helder 13:32, 12 August 2014 (UTC)

Aye, they are; and therein lies the problem. We have text that is either generic code or user input. Since we lack clearly identifiable semantics, I'm beginning to think that we shouldn't bother with semantics at all and simply replace the <code>...</code> with <span style="font-family: monospace,Courier;">...</span> and call it good though part of me would rather use <kbd>...</kbd> because it's cleaner.

—Trappist the monk (talk) 16:36, 12 August 2014 (UTC)

Hello. Is there a way to change my language preferences to one language for all wikipedia by once? I mean not to have to choose english on every wikipedia I visit... Xaris333 (talk) 00:44, 12 August 2014 (UTC)

Unfortunately, no. First we have to get through mw:SUL finalisation (early 2015?). After that, we might be able to get cross-wiki prefs, which everyone wants and needs. Whatamidoing (WMF) (talk) 06:43, 12 August 2014 (UTC)

Or wait for the deployment of GlobalCssJs extension to WMF wikis and then add a small snippet of code to your global.js page. Helder 13:38, 12 August 2014 (UTC)

  Done Just copying Wikipedia:Administrators'_noticeboard#Calling_edit-filter_managers across to here in case it attracts the attention of someone with edit-filter knowledge. Black Kite (talk) 12:02, 12 August 2014 (UTC)

See AN discussion, update applied. — xaosflux ^Talk 12:21, 12 August 2014 (UTC)

I've noticed that articles I go to by clicking "Random Article" aren't recorded in my browser history (Safari). At least, not after the first one. Is that intentional? Howunusual (talk) 16:46, 12 August 2014 (UTC)

It is a peculiarity of Safari. It has always been that way. —TheDJ (talk • contribs) 21:34, 12 August 2014 (UTC)

Please see Wikipedia:Village pump (policy)#CatVisor and User:Paradoctor/CatVisor#Planned features if you are willing and able to assist this innovative WP project move along it would be greatly appreciated. Thank you, IZAK (talk) 23:31, 12 August 2014 (UTC)

I have always found the Search & Replace tool to the far right on the edit strip on the Edit Page awkward to use, in that the box (a) either sits over some of the text and I'm not sure if it is hiding some of the words highlighted for manual search & replace as the page scrolls down, or (b) if I move the box to left-hand column outside the edit area, the box disappears upwards as subsequent finds are highlighted as the page scrolls down - in other words, the box does not "hover". I have looked at it again today, and now, after the first highlight, it won't highlight the subsequent finds. Is the tool malfunctioning, or there something wrong at my end? The tool does not appear in the edit strip using IE11, but it does using Firefox with Vector skin. Can you help, please? --P123ct1 (talk) 13:56, 12 August 2014 (UTC)

@P123ct1: when I search for "hi" in the code of this section, using Firefox 31 or Chrome 36, it highlights all occurrences. Helder 17:45, 12 August 2014 (UTC)

I have Firefox 31. It is highlighting now, but the page won't move down automatically, and when I scroll it down manually, the search box disappears upwards. --P123ct1 (talk) 18:01, 12 August 2014 (UTC)

There are about 18 open tickets on this tool (most of any part of WikiEditor). But unfortunately not many people care to work on it. I have made a few patches on WikiEditor in the last few months (perhaps you have noticed a change or two), but have concerned myself with more widely used parts and a bit with performance. —TheDJ (talk • contribs) 07:16, 13 August 2014 (UTC)

I have Firefox 31.0, and have unchecked WikEd because some conflict in the edit window exists between the two. There is a serious lag in opening an editing screen while my browser freezes and says "not responding", during which I can neither shut down my browser nor cancel out the activity in process - same thing with "preview". Doing a "copy and paste" on the most minor things produces the same phenomenon, but can be in that limbo for several minutes. Whatever it is, I am concerned the combo of Fiirefox 31.0 and WikEd will accidentally shut down my computer. Consequently, I make do with the "Search and replace" icon on the right hand side that is not part of the WikEd enabled toolbar. — Maile (talk) 13:53, 13 August 2014 (UTC)

Maile66: mw:Extension:WikiEditor provides the "Enhanced edit toolbar", and is not the same as the gadget WP:WikEd. Helder 14:46, 13 August 2014 (UTC)

Helder.wiki, Right,I know. What you are calling the enhanced edit toolbar is what I use without enabling WikEd. However, when WikEd is enabled, there is a whole lot more on the toolbar, including an additional Search and Replace tool. I figure I can live without those WikEd additions as long as Firefox 31.0 conflicts. — Maile (talk) 15:00, 13 August 2014 (UTC)

Why does

https://en.wikipedia.org/w/index.php?title=Special%3ARecentChanges&from=20140811000000

not give me the log of changes starting from yesterday? I'm sure this used to work. SpinningSpark 14:59, 12 August 2014 (UTC)

This query doesn't specify the "limit" parameter, which is only 50 by default, so you get the 50 most recent edits - the last minute or so. To see the "from" parameter working, try restricting the query to an obscure namespace. This query returns about 30 edits to the "Portal talk" namespace; it obeys the "from" parameter and doesn't go back any further than 11 August. -- John of Reading (talk) 15:09, 12 August 2014 (UTC)

Not really a "from" parameter then.

Ok, let me try a different question. How do I view the logs for yesterday without setting limit= to an astronomical number (in any case, anything higher than 5000 is ignored so wouldn't get back "to" the date specified in any case). I seem to remember when I did this in the past edit ID numbers were required, but can't remember the format properly. SpinningSpark 15:24, 12 August 2014 (UTC)

I don't recall "from"—I think it should be "offset". The following shows the history of this page starting with edits just before the beginning of 20 April 2014:

https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28technical%29&action=history&offset=20140420

However, I suspect RecentChanges is different because there is unlikely to be a permanent history of RecentChanges—it probably only maintains a rolling list with new items added at one end and old items removed at the other. In other words, offset is not going to work and I don't think you can see RecentChanges at an older time except by clicking the buttons to show 500 changes in the last 30 days (or doing the same in the URL, up to limit 5000). There is no "older 50" in the GUI for RecentChanges, and there is no URL to achieve that (I think). Johnuniq (talk) 00:02, 13 August 2014 (UTC)

I recall doing things like finding the first edit of a new year, which obviously requires going through the whole database, not just an individual page log. But perhaps I am misremembering how I did it. That particular task could be achieved by laboriously entering single page IDs in a [Binary search algorithm|binary search]]. SpinningSpark 11:22, 13 August 2014 (UTC)

The edits can be found by using the API (this query for the timestamp used above; it works for anything up to 30 days) but I can't see anything in Special:Recentchanges that would allow those parameters to be specified - is there anything (maybe a script) that would produce that result with links to the edits? Peter James (talk) 14:02, 13 August 2014 (UTC)

According to mw:Help:Recent changes there are no parameters that allow a jump-in point to be specified. --Redrose64 (talk) 14:36, 13 August 2014 (UTC)

When I look at the revision history for an article, the year includes a comma, such as "2,014." In the history of this very page it says "Wikipedia:Village pump (technical): Revision history View logs for this page Browse history From year (and earlier): 2,014" Is there any country on earth where years are stated thus? This just looks peculiar. How hard would it be to format the display so years are displayed as they are everywhere else? Edison (talk) 00:28, 7 August 2014 (UTC)

Because the specific version of the specific browser that you're using, which you did not provide here forcing everyone to guess, has a bug that makes it format numeric input fields with commas in some languages. See T71059 (marked as INVALID) for details. Matma Rex talk 00:35, 7 August 2014 (UTC)

Your snottyness in the comment "forcing everyone to guess" is uncalled for, but thanks for linking to the bug report. . It would have been more appropriate to just ask what browser produced the anomaly, or to mention that you use a certain browser and don't see the problem. It is not obvious to the average user that it is a browser issue rather than an issue of how Wikipedia is coded to display. The commas in the year show up in Safari Version 5.0.6 (5533.22.3). on a MacBook Pro.I checked on my PC and the year displays without a comma in Internet Explorer and in Firefox. Edison (talk) 18:56, 8 August 2014 (UTC)

@Matma Rex. The user asked a perfectly normal question. You could have conveyed the same information in your response without being snarky. Such a display of unprompted rudeness indicates a real lack of judgment. I hope you were just having a bad day. Jason Quinn (talk) 00:02, 10 August 2014 (UTC)

Wow, nice hostility guys. If I knew that these ten words are going to cause so much hate, I wouldn't have replied. I'll bear your comments in mind in the future. Matma Rex talk 02:24, 10 August 2014 (UTC)

;YOU were the first person to be snotty/snarky/demeaning. You received appropriate criticism, not "hate.' Please avoid anything but a helpful and informative answer. Edison (talk) 23:30, 13 August 2014 (UTC)

Hello! There seems to be a problem with following wikilinks with certain punctuation (such as the ? character) when on the mobile site. For example, when I try to follow R U Mine? from both my Kindle Fire and my phone, it takes me to https://en.m.wikipedia.org/wiki/R_U_Mine%253F instead of https://en.m.wikipedia.org/wiki/R_U_Mine%3F and I get a 'bad title' error. It seems to be a problem with percent encoding... %25 is the percent code for %, so by sending me to https://en.m.wikipedia.org/wiki/R_U_Mine%253F the site seems to be trying to double percent-encode or something. Any help would be appreciated! Cheers, cymru.lass (talk • contribs) 17:31, 11 August 2014 (UTC)

Yeah, that's odd. U+253F is a box drawing element, so it's not that. It definitely seems to be applying percent encoding one step too far, ie ? -> %3F -> %253F. VanIsaac_WS^cont 21:38, 11 August 2014 (UTC)

Just realized this should probably have been a bug report and not a post here. Here's the link to the newly-submitted bugzilla report, if anyone's interested. cymru.lass (talk • contribs) 18:18, 13 August 2014 (UTC)

For several weeks I tried to figure out how someone gets the warning about WP:BLP to appear when editing a biographical article. It finally appeared today but I don't know how since I didn't see anything in the history that would change that. Specifically, Disappearance of Erica Parsons.— Vchimpanzee • talk • contributions • 20:30, 13 August 2014 (UTC)

This edit placed the article in Category:Living people. According to the documentation at Template:BLP editintro, some behind-the-scenes JavaScript looks for that category and modifies the "Edit" links so that this template is shown. -- John of Reading (talk) 20:55, 13 August 2014 (UTC)

Okay, thanks. I knew someone had redone the categories, but it didn't happen then.— Vchimpanzee • talk • contributions • 21:03, 13 August 2014 (UTC)

If anyone's curious about the technicals, this specific feature is governed by MediaWiki:Common.js. Search for "Magic editintros". There's one for BLPs and one for disambiguation pages. All other edit intros are explained at Wikipedia:Editnotice. —Designate (talk) 23:42, 13 August 2014 (UTC)

That's pretty spiffy. --j⚛e decker^talk 00:51, 14 August 2014 (UTC)

Following is the output from http://dispenser.homenet.org/~dispenser/cgi-bin/dablinks.py?page=Female_genital_mutilation

No disambiguation links on Female genital mutilation.

Female genital mutilation links to 1 redirect which point back.

• FGM (redirect page)
  • Female genital mutilation

I can't see anything in the article which links to FGM. I copied the article and intended to omit parts of the copy to locate the problem, but the copy does not show any problems. Following is the output from http://dispenser.homenet.org/~dispenser/cgi-bin/dablinks.py?page=User:Johnuniq/sandbox4

No disambiguation links on User:Johnuniq/sandbox4.

Comparison of the two pages: [51]. I don't think dablinks caches results. Any ideas on the discrepancy? Johnuniq (talk) 10:11, 10 August 2014 (UTC)

@Johnuniq: I can reproduce the issue. I suggest you post on User talk:Dispenser/Dablinks to see if Dispenser can help you. Good luck! GoingBatty (talk) 13:55, 10 August 2014 (UTC)

@Johnuniq: It shows up as both a link and a transclusion in Special:WhatLinksHere/FGM, so it's in the MediaWiki link tables and is nothing to do with reflinks. The Female genital mutilation page has {{redirect|FGM}}, and that template was recently Lua-ised, so the answer probably lies buried within Module:Redirect hatnote and therefore Mr. Stradivarius (talk · contribs) is the best person to answer this. From what I can observe, the module contains code to determine if the redir (in this case FGM) exists or not, and if it doesn't, categorises the main page in Category:Missing redirects; I hope that this doesn't work like {{exists}} (see my comments at Template talk:Exists#Efficiency) - but otherwise, why is a transclusion necessary? I also suspect that this code creates an invisible link back to the redirect. I can't be 100% sure, because I can't test it: in the old days, I would change {{redirect|FGM}} to {{subst:redirect|FGM}} and go for Show changes, and see what Wikicode was being pulled in. This does not work for modules. --Redrose64 (talk) 08:10, 11 August 2014 (UTC)

Thanks, that's it. Skimming Module:Redirect hatnote suggests it executes mw.title.new('FGM') for which the doc says "This function is expensive ... The title referenced will be counted as linked from the current page." It uses that function to test if the target of the redirect exists (if not, it outputs Category:Missing redirects). I guess any page in the main namespace which uses {{redirect}} will be counted in "what links here" for the target. Bit unfortunate. Groan. I see you already said all that. Johnuniq (talk) 10:28, 11 August 2014 (UTC)

Yes this is because of Module:Redirect hatnote. Specifically, it is because of the Lua equivalent of {{#ifexist:{{{1}}}||{{main other|[[Category:Missing redirects]]}}}} in the old Template:Redirect. The link table entry is caused by using mw.title.new to create a Lua title object for the first parameter passed to the template, which is a necessary step for checking page existence in Lua. The issue isn't specific to Lua though: according to the docs for #ifexist, "If a page checks a target using #ifexist:, then that page will appear in the Special:WhatLinksHere list for the target page". So the previous template should have also caused the same link table entry as well. — Mr. Stradivarius ^{♪ talk ♪} 12:22, 11 August 2014 (UTC)

@Mr. Stradivarius: It's listed as a link, yes, I understand that; but why does it also show as a transclusion? --Redrose64 (talk) 12:41, 11 August 2014 (UTC)

@Redrose64: That's because of the code for the new tracking category, Category:Invalid redirects (see this thread for its rationale). If the first positional parameter is an existing page title, Module:Redirect hatnote uses Module:Redirect to check if the page is a redirect, and to check if the redirect target is the current page. To do this it grabs the entire unparsed page contents with title:getContent, which counts as a transclusion. — Mr. Stradivarius ^{♪ talk ♪} 12:53, 11 August 2014 (UTC)

Sounds expensive. --Redrose64 (talk) 12:56, 11 August 2014 (UTC)

Usually it means one extra expensive parser function call. If the redirect target is not the current page (i.e. the cases where Category:Invalid redirects is populated), it's two more. Those are from creating the Scribunto title objects for the pages involved. — Mr. Stradivarius ^{♪ talk ♪} 01:41, 14 August 2014 (UTC)

I've got a script, let's call it Script A. When Script A finishes running its relatively lengthy function (takes about 500 ms on large pages like WP:ANI), I want it to notify Script B (in another file) that it is done running.

What's the best way to do this?

If this were a normal JS environment that I had full control over, then I might use something like jQuery promises, but I don't know if that's an option here? Gary (talk · scripts) 06:39, 8 August 2014 (UTC)

Are both running at the same time, or does one trigger the other? Chillum 06:42, 8 August 2014 (UTC)

Script A is run on Wikipedia through my monobook.js, and Script B is actually run through Greasemonkey, which is an addon for Firefox. But it has access to variables from Wikipedia scripts; the only problem is that I can't fine-tune which script runs first, so the script that runs first is different each time at the moment. Gary (talk · scripts) 18:16, 8 August 2014 (UTC)

You con use jQuery promises, the entire library is always loaded already. Matma Rex talk 11:42, 8 August 2014 (UTC)

Yeah, but see above. Script B is run through Greasemonkey at the moment. But if necessary, I may be forced to move the GM scripts back to Wikipedia then. Gary (talk · scripts) 18:16, 8 August 2014 (UTC)

@Gary: There are a variety of ways that you could do this. You effectively want asynchronous message passing using a shared memory location. The shared memory space is the DOM. One example would be to have Script A place an empty <span>...</span> with a specific ID in the DOM as its last action. When Script B runs, it checks for the existence of the <span>...</span> with that ID. If it exists, then do your Script B processing. If it does not exist, then set a timed callback and retest for the span. You probably also should count the number of times/accumulated time waiting and issue an error if the span is not found within some period. — Makyen (talk) 15:42, 10 August 2014 (UTC)

That's exactly the solution I was thinking of using. I'm thinking creating a node at the end of the page, before the </body>, like <div id="script-a-done"></div> (with a more descriptive name), then in Script B, checking for its existence every 250 ms or so. And loop that for about ten times (so 2.5 seconds total), before giving up. Seems reasonable to me. Normally it would only run once. Gary (talk · scripts) 16:16, 10 August 2014 (UTC)

@Gary: Script B has access to variables from Wikipedia scripts, so you shouldn't need to use the DOM, just set a global variable when A is ready and check for that from B with if (window.myVar) --V111P (talk) 05:21, 11 August 2014 (UTC)

Yeah I also realized that, so I can just loop the script, similar to my method of using the DOM for this. Gary (talk · scripts) 17:01, 11 August 2014 (UTC)

Using an actual variable which is shared between the two contexts for the flag is certainly preferred. Given that this appears to be for your own use, you do not need to make sure that it works across multiple browsers (your use of Greasemonkey implies this). The generic solution is using the DOM which should be shared across almost any JS context (as potential DOM manipulation is usually a goal for JS environments). Using the contents of the title of an empty <span>...</span> with a specific id is similar to the method used by COinS. Without testing, I would not want to guarantee that both scripts share the same live copy of any particular variables other than the DOM. While I have not actually done any work with Greasemonkey, my understanding was that such scripts were specifically placed in a separate sandbox for security reasons. — Makyen (talk) 17:59, 11 August 2014 (UTC)

Greasemonkey no longer has a sandbox unless it is explicitly indicated. However, the problem is that Greasemonkey scripts sometimes run before Wikipedia scripts, and sometimes run after, because they are essentially running in parallel (from my understanding). So that's why the setTimeout loop is necessary, which I will cancel after 10 or so failed attempts at finding the necessary empty DOM element or variable. Gary (talk · scripts) 20:24, 11 August 2014 (UTC)

Maybe you can use mw.hook for this? Helder 13:40, 11 August 2014 (UTC)

Thanks I'll check that out. Gary (talk · scripts) 17:01, 11 August 2014 (UTC)

@Helder.wiki: Do you know if there is a list of hooks that are available to use? Gary (talk · scripts) 05:03, 14 August 2014 (UTC)

@Gary: I don't know, but this search on GitHub should give you an idea of what exists on core. There are others defined on extensions, and you can also define your own hooks (see e.g. commons:MediaWiki:Gadget-libAPI.js). Helder 15:55, 14 August 2014 (UTC)

Recently, there was a discussion about how best to arrange some tables into two columns on the Help:IPA pages. Originally, they were using a <table> element to achieve the layout, but recently switched to <div>s and inline CSS.

Unfortunately, with the current markup (examples: here, here, here, here, and here), the layout breaks when viewed from a mobile device (according to the Chrome DevTools).

Here are some options I thought of:

1. Changing the tables into a single column layout.

• Pro: Usable for all devices.
• Con: Desktop users (the majority) can't see the tables in compact view.

2. Using flexbox in the CSS. There's an example here where flexbox converts to single column when the screen is smaller.

• Pro: Usable for almost all devices; desktop users get a better experience; gracefully degrades into single column when the browser doesn't support flexbox.
• Con: A lot of vendor prefixes to keep track of in the inline CSS.

3. Ask a developer to add a class with Media Queries to the Wikipedia CSS code.

• Pro: Easier for editors to use; usable for all devices; desktop users get a better experience.
• Con: Such a specific problem isn't worth modifying the Wikipedia code base! (Plus it would take a while to convince everybody)

There might be probably is a better way that I'm not thinking of. Does anyone have any thoughts?

- Quidmore (talk) 01:03, 12 August 2014 (UTC)

@Quidmore: I don't like 1 just because it looks so bad on desktops. Regarding 2 and 3, we can edit MediaWiki:Common.css to add a new class ourselves (and accomplish either of those more easily), without bothering any developers. Jackmcbarn (talk) 01:10, 12 August 2014 (UTC)

Have you considered {{div col}}/{{div col end}}? You can see them in action at Wikipedia:Meetup/UK#London. --Redrose64 (talk) 10:09, 12 August 2014 (UTC)

As long as columns play nice with tables. Make sure to use the .nocolbreak class in the tables. -- [[User:Edokter]] {{talk}} 17:37, 12 August 2014 (UTC)

Very good catch! I didn't realize there was a way to keep the tables from breaking. That was the reason I didn't include CSS multi column layout (which is what the {{div col}} template appears to use) in my original list.

I like the idea of using this template, but is there a way to make one column wider than the other? On several of my original examples, the table on the left is wider than the table on the right. I'm not sure how important it is, though. Quidmore (talk) 20:55, 12 August 2014 (UTC)

To be fair; I just created that class because it could be usefull. Just experiment with it in the sandbox. Some older browsers may not support the nocolbreak CSS, but those borwser tend not to support columns in the first place.

Multi column layout always produce equal widht columns. -- [[User:Edokter]] {{talk}} 21:50, 12 August 2014 (UTC)

Okay, I'm trying to use it in my sandbox, but I'm running into a problem. The table (with the .nocolbreak class) is breaking. Using DevTools, I find that the .nocolbreak needs to be placed in the <tbody> element instead of on the table itself (and a quick look at Help:Table does not reveal any easy way to add it to that element either). Am I doing something wrong? I'm using Chrome 36, if that helps. Quidmore (talk) 04:36, 13 August 2014 (UTC)

You're doing everything right. Chrome seems to have a bug; when I disable and re-enable the -webkit-column-break-inside: avoid; property in Chrome's web inspector, it kicks everything into place. the CSS also works in Opera, and Firefox seems to not break tables regardless. -- [[User:Edokter]] {{talk}} 21:31, 13 August 2014 (UTC)

I suspected it was a bug. It seemed that whenever I triggered a layout recalculation (by resizing the screen, etc.), it would fix the problem. My earlier comment about the class needing to be applied to the <tbody> is probably incorrect. I now believe the change just triggered a layout recalculation that fixed it.

It appears too unpredictably to figure out a solution. If it's a bug, it will probably go away soon. Quidmore (talk) 23:00, 13 August 2014 (UTC)

Hopefully. You may want to check Chrome's Bugzilla. Chrome's handling of multi-column layout has always been slightly problematic. -- [[User:Edokter]] {{talk}} 11:40, 14 August 2014 (UTC)

I've been trying [52][53] to insert a new Research directions section at the conclusion of the Esophageal cancer article, immediately above the list of References. For some reason, the new section seems to encroach on the Reference section [54]. Not sure why...
Any help would be much appreciated. 86.157.144.73 (talk) 12:57, 12 August 2014 (UTC)

  fixed The last ref was <ref name=Lagergren-2013> but should have been <ref name=Lagergren-2013 /> - note the slash. --Redrose64 (talk) 13:03, 12 August 2014 (UTC)

Ah, silly me... I'm always overlooking that sort of thing. Thank you very much Redrose64 for fixing the train so quickly! 86.157.144.73 (talk) 13:09, 12 August 2014 (UTC)

We used to get an error but the automatic reference list causes it to no longer show. --  Gadget850 ^talk 13:32, 14 August 2014 (UTC)

On most pages, when I load the page, the WP:Twinkle tools appear at the top of the page along with the normal Wikipedia tools ("Edit", "History", "Watch", etc). But on some pages (see Ahospitiality Club), the tools are missing. Any ideas? WikiDan61^ChatMe!_ReadMe!! 14:38, 14 August 2014 (UTC)

Has Wikipedia changed something about how templates appear? The boxes surrounding them have vanished for me... This has resulted in serious page clutter. Templates on top, on the side and on the bottom of pages are affected equally. Has anyone else seen this problem? I can try for a screenshot if necessary. Paris1127 (talk) 22:57, 14 August 2014 (UTC)

Infobox screenshot

Bottom screenshot

Paris1127 (talk) 23:06, 14 August 2014 (UTC)

Those pages look fine to me. Try a different web browser, clear your cache, purge or null edit the page, or even restart your computer. If it's still happening for you on one web browser, you might have to ask at the Help Desk. – Jonesey95 (talk) 23:27, 14 August 2014 (UTC)

This is what they should look like (from a different browser):

Infobox screenshot

Bottom screenshot

I think Chrome is having issues with Wikipedia... Paris1127 (talk) 23:54, 14 August 2014 (UTC)

It looks like a cache problem. Click here to refresh that page. If that doesn't work, clear Chrome's cache (Tools > Clear browsing data...); it has been known to choke when its cache has filled up. -- [[User:Edokter]] {{talk}} 09:43, 15 August 2014 (UTC)

Clearing Chrome's cache did it. Thank you so much! Paris1127 (talk) 13:44, 15 August 2014 (UTC)

I just did this manual undo because this undo "could not be undone due to conflicting intermediate edits; if you wish to undo the change, it must be done manually." However, I looked at the history, and while Help:Undo#Undo says it "will fail if undoing the edit would conflict with later edits." it seems to me (ISTM) that this edit would not have done so. (I'm not surprised by undo failing in such cases.) If I'm not mistaken, this diff shows that there were no differences between the line as it existed right after the edit I wanted to undo and the line as it existed right before undo failed and I had to do it manually. Has undo always been this weak? ISTM that where there are no differences between a line as it existed right after the edit one wants to undo and the line as it existed right before an undo attempt, the undo should not fail. Yet that was the case, and it did fail. Therefore, undo seems to be broken. --{{U|Elvey}} ^(t•c) 16:11, 8 August 2014 (UTC)

Am I missing something?--{{U|Elvey}} ^(t•c) 03:50, 16 August 2014 (UTC)

I've noticed that redirects to subsections have been not quite hitting their targets for some time. A particulary bad example is WP:NGRIDIRON which finds the badminton section instead of American football. Any ideas? It seems to be limited to Firefox, I tried two other browsers there was no problem. The results weren't the same in Vector and Monobook, they went to different wrong sections. SpinningSpark 09:50, 15 August 2014 (UTC)

Yes, I noticed this in Firefox too. WP:NCRIC doesn't quite get there, but does in IE. Lugnuts ^{Dick Laurent is dead} 11:26, 15 August 2014 (UTC)

It does if you hit F6-enter to "reload" the page (which doesn't actually reload anything except position). Perhaps it has something to do with Firefox positioning you before something loads. --NE2 11:34, 15 August 2014 (UTC)

I think this has come up on this page before. IIRC, Firefox positions the screen while collapsible elements set to "collapsed" (in this case, the FAQ at the top of the page) are still expanded, so when they are automatically collapsed content below them is pushed upwards. SiBr₄ (talk) 12:04, 15 August 2014 (UTC)

Wikipedia:Village pump (technical)/Archive 121#Faulty redirect mentions the same issue. SiBr₄ (talk) 12:13, 15 August 2014 (UTC)

Also Wikipedia:Village pump (technical)/Archive 126#Redirect not working right --Redrose64 (talk) 14:21, 15 August 2014 (UTC)

Note the difference between

• https://en.wikipedia.org/wiki/Wikipedia:NGRIDIRON#American_football.2FCanadian_football
• https://en.wikipedia.org/wiki/Wikipedia:NGRIDIRON

The former works but the latter does not. Also, the direct url or wikilink

• https://en.wikipedia.org/wiki/Wikipedia:Notability_(sports)#American_football.2FCanadian_football
• Wikipedia:Notability (sports)#American football/Canadian football

also works. So apparently there is only a problem when the anchor link is within a redirect. SpinningSpark 15:00, 15 August 2014 (UTC)

Obvious solution: don't hide FAQs inside a collapsebox. --NE2 15:08, 15 August 2014 (UTC)

That's a solution? SpinningSpark 15:10, 15 August 2014 (UTC)

That's one solution. We can also automatically hide content and unhide it with Javascript, but that's a bit unkind for people without Javascript and for screenreader users. A third solution is to petition Firefox, but i'm guessing they will redirect u to solution 1 and 2. The fourth solution requires a bit more complicated javascript, that sends an event when it is done collapsing, and we hook other javascript in there to reposition the page after the content is collapsed. But that would be a rather big change... —TheDJ (talk • contribs) 17:15, 15 August 2014 (UTC)

I didn't hide anything, I was just trying to read the page. I don't think going round uncollapsing everything is going to fly, this is not the only page affected. As for petitioning Firefox, I already have. What I'd like to understand is what it is about our redirects that are causing Firefox a problem. As I said above, if the anchor is directly in the url it seems to work fine. SpinningSpark 19:23, 15 August 2014 (UTC)

It is certainly something to do with Firefox; in the change from FF 28 to FF 29 redirected links to sections started behaving differently, as noted at Wikipedia:Village pump (technical)/Archive 126#Redirect not working right (which I linked earlier). --Redrose64 (talk) 20:01, 15 August 2014 (UTC)

Much to my surprise, it looks like Mozilla might actually do something about this. SpinningSpark 00:37, 16 August 2014 (UTC)

Hello, I'm looking for a Template:8TeamBracket-with third-fifth-seventh. It's something like this ...