Jump to content

Wikipedia:Village pump (technical)/Archive 124

Add links
From Wikipedia, the free encyclopedia
Village pump (technical) archive  

This page contains discussions that have been archived from Village pump (technical). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.

< Older discussions · Archives: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR, AS, AT, AU, AV, AW, AX · 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215, 216

Gremlins?

In the last two weeks, I've had two users new of my script enquiring about loading problems. They describe a sequence of events that seem improbable, given that my script has been well tested and any fatal bugs rapidly patched, and I cannot replicate the loading problems within my own userspace. The script seems to behave inconsistently between vector.js and monobook.js environments. First was this. The script didn't work in vector but was eventually made to work in monobook. I never thought the syntax – importScript('PATHNAME.js'); or importScript("PATHNAME.js"); – mattered, as I have both single quotes and double quotes inside my vector file and there are no problems with script importations.

Then, earlier today, another user reported that the script apparently loads, and the sidebar buttons appear, but clicking on it only results only in a new edit summary. Now given that the function that inserts the edit summary of my MOSNUM script is the last to execute, yet earlier-placed functions do not execute on a given article as well; the instruction (i.e. doaction('diff');) that follows the edit summary insertion is not executed, it seems highly illogical behaviour. Any idea what could be the source of the problem? -- Ohc ¡digame! 00:26, 23 February 2014 (UTC)

Maybe related - I use the gadget (User:Pyrospirit/metadata.js) which hasnt changed since 2011. It shows the assessment from the talk page on the top of the article, and has a "show button" to display the name of the projects too. But the "show" button disappeareda a few weeks ago. (I use monobook, and its gone in chrome (windows/linux), firefox and iceweasel. Christian75 (talk) 19:57, 27 February 2014 (UTC)

Difference between revisions pages comment truncation

When editing a Wikipedia article, the user can enter up to 255 characters in the Edit summary. When a reviewer is performing an edit review on a Difference between revisions page, the comment field accepts a comment of up to 255 characters, but only about 85 are accepted; the rest are thrown away without warning. In this edit of February 4 I entered

supplied reference is dead link. Please omit "th" in dates; just "August 11" not "August 11th".

which was truncated to

supplied reference is dead link. Please omit "th" in dates; just "August 11" not "August

which is 88 characters; the full edit summary is

Reverted 2 pending edits by Carissaryy to revision 596521603 by Filedelinkerbot: supplied reference is dead link. Please omit "th" in dates; just "August 11" not "August

which is 169 characters.

In this edit of Troye Sivan I entered

unexplained removal of add superbowl"; added entries are listed with plural instead

(or possibly something longer), which was truncated to

unexplained removal of add superbowl"; added entries are listed with plural instea

which is 82 characters; the full edit summary is

Reverted 2 pending edits by 108.87.26.62 to revision 594895290 by Materialscientist: unexplained removal of add superbowl"; added entries are listed with plural instea

which is 167 characters.

In this edit of War on Women I entered

OK, but still no basis for saying that Democrats have criticized concept or phrase "War on Women"

which was truncated to

OK, but still no basis for saying that Democrats have criticized concept or phrase "Wa

which is 86 characters; the full edit summary is

Reverted 1 pending edit by 2.102.186.164 to revision 595394124 by Anomalocaris: OK, but still no basis for saying that Democrats have criticized concept or phrase "Wa

which is 166 characters.

So I don't know what is the true limiting factor on truncating an edit review comment into an Edit summary, but the limit seems to be effectively about 85 characters.

It is wrong for Wikipedia to accept up to 255 characters and truncate without warning at about 85 characters. —Anomalocaris (talk) 10:09, 24 February 2014 (UTC)

It's not 255 displayed characters, it's 255 bytes of markup. Taking your first example: the actual edit summary was
Reverted 2 pending edits by Carissaryy to revision 596521603 by Filedelinkerbot: supplied reference is dead link. Please omit "th" in dates; just "August 11" not "August
the markup for which is
[[Help:Reverting|Reverted]] 2 [[Wikipedia:Pending changes|pending]] edits by [[Special:Contributions/Carissaryy|Carissaryy]] to revision 596521603 by Filedelinkerbot: supplied reference is dead link. Please omit "th" in dates; just "August 11" not "August
which is exactly 255 bytes. I haven't checked the other two, but I'm sure that the same applies to those. On a minor point: it's not 255 characters but 255 bytes - the difference becomes apparent when you use Unicode characters - an en-dash takes up three times as much space in an edit summary as a hyphen-minus. --Redrose64 (talk) 11:49, 24 February 2014 (UTC)
I've created the subsection Help:Edit summary#The 250 character limit which is perhaps on the technical side, but it's tucked away near the bottom; to avoid confusion I've not altered the earlier mentions of 250 characters on that page, other than to link the first mention to that new subsection. It should suffice for other curious people. --Redrose64 (talk) 14:46, 24 February 2014 (UTC)
this used to be a very serious issue for non-latin-script wikis (such as hewiki), esp. the distinction between "255 characters" and "255 bytes". truncated edit summaries were a matter of routine before it was fixed several years ago with the introduction of a special mw JS function ( $.byteLength() ), so now, the summary input will not let the editor overflow the summary. unfortunately, this functionality depends on JS (the summary input always had maxlength=255 attribute, but this does not help much when byte count differs from char count, because it limits characters and not bytes). i am not sure if VE is smart enough to use it, and if these reverts/edits were done using some script, then the script author needs to check the "byteLength" of the summary, and truncate it in a way that makes sense. for JS-less editors, the summary input is still limited to 255 characters (no character is *less* than 1 byte...) but this is of little help for non-latin-script languages. peace - קיפודנחש (aka kipod) (talk) 18:26, 24 February 2014 (UTC)
ok, i tested, and VE also safeguards against truncation, and will not let you create summaries longer than 255 bytes. this edit must have been done through some script of bot. please talk with eh script/bot developer about limiting edit summary length to 255 bytes. if it's a tool written in JS, they can use the $.byteLength() function - otherwise they'll have to create their own. peace - קיפודנחש (aka kipod) (talk) 19:25, 24 February 2014 (UTC)
Thank you for the explanation, RedRose64. I did not consider the markup bytes. However, I recommend you re-edit Help:Edit summary#The 250 character limit in light of this edit in my sandbox, which shows that the less than and greater than signs take up one byte each. Also, we still need to fix the problem that reviewer's reversion comments (where 255 characters are accepted) are truncated without warning at about 85 characters. — Preceding unsigned comment added by Anomalocaris (talk • contribs) 20:46, 24 February 2014 (UTC)‎
OK, removed. I can't remember where I got the idea that < was stored as &lt; - certainly that's how it's served in the HTML, but then you'd expect it to be. --Redrose64 (talk) 21:14, 24 February 2014 (UTC)
@Anomalocaris: do you remember if you did these edits manually or via some script? also, do you have JS enabled? peace - קיפודנחש (aka kipod) (talk) 21:50, 24 February 2014 (UTC)
@קיפודנחש:, as far as I can tell, you are not an administrator or a reviewer, so you cannot see what I see. I do everything manually. I start on Special:PendingChanges. I right-click a review link and open in a new tab. The new tab is a "Difference between revisions" page. If you are logged in as an administrator or reviewer, below the line that says "From Wikipedia, the free encyclopedia" there is a boxed section with heading "Review this revision". Inside the box it says
Please review the pending revision below.
You can advertise yourself as reviewing these changes to other users.
Comment: [                                                                             ]     [  Accept revision  ] [  Revert revision  ] (show pending changes protection log)
On the line that begins "Comment:" is a one-line character entry field, two buttons and a blue link I've shown as underlined words.
(below that, the page continues the same as it would appear for a "normal" user.)
After determining if I want to "Accept revision" or "Revert changes", I enter my reason in the comment field, just by typing it in normally. The comment field will accept 255 characters, but (for reasons I understand now) only about 85 of them will go to the edit summary if I click "Revert changes".
Javascript is enabled in my browser, but in Preferences, on the Appearance tab, in the "Skin" box, "Custom JavaScript" appears as a redlink five times, and my skin choice is MonoBook. —Anomalocaris (talk) 01:01, 25 February 2014 (UTC)
@Anomalocaris: thanks. i think the problem stems from MediaWiki:Revreview-reject-summary-cur. this is the "template" for revert summaries, and the template itself is already pretty long: here it is in its entirety:
[[Help:Reverting|Reverted]] {{PLURAL:$1|1 [[Wikipedia:Pending changes|pending]] edit|$1 [[Wikipedia:Pending changes|pending]] edits}} by $2 to revision $3 by $4
(it looks longer than it really is, because of the use of "plural" magic word, but it's still pretty long) once all the substitutions are made (i.e., replacing the $X with appropriate values), it becomes even longer. the "revert" operation creates the summary programatically, by taking this summary, filling in the macros ($X's), and then concatenating your hand-entered summary. the software should alert you to the fact that the total summary is too long and your comment will be truncated, and it's a real bug that it doesn't, but until this bug is fixed, we can alleviate the issue by making this "System message" significantly shorter. IMO it's more important to avoid truncating the hand-written summary than it is to give links to the help and wp pages explaining the review system in the summary. personally, i would replace this fancy message with:
Reverted $1 pending {{PLURAL:$1|edit|edits}} by $2 to revision $3 by $4
this will allow about 50 or so more bytes for your hand-written comment, which is way more important and informative than having the links to help and policy pages from the edit summary. things still may get truncated - not alerting the editor about it is a real bug, but practically speaking, this will solve 78.235% of the cases where summaries get truncated. in enwiki, only sysops can edit system messages, so you'll have to ask one of them to do that... peace - קיפודנחש (aka kipod) (talk) 16:28, 26 February 2014 (UTC)
If the links are desired, the same effect as the current version can e obtained using shortcuts:
[[H:REV|Reverted]] $1 [[WP:PC|pending]] {{PLURAL:$1|edit|edits}} by $2 to revision $3 by $4
This includes the links at a cost of 20 bytes. That is a savings of 29 bytes over the current version with the same functionality. But, do we really need a link to Help:Reverting from "Reverted"? The word is not being used in any special way or with any special meaning, and it is not linked in other similar default edit summaries. So, we could just use:
Reverted $1 [[WP:PC|pending]] {{PLURAL:$1|edit|edits}} by $2 to revision $3 by $4
Which costs 10 bytes out of a current 49 bytes used for links and looses no real information content (39 bytes saved, or an 80% savings of bytes used for links).
I note, however, that these examples do not include the link to [[Special:Contributions/Example|Example]] which was stated in an earlier post as existing in the edit summary. Special:Contributions does not appear to have a shortcut. We really should have a shortcut for Special:Contributions. It is quite long and regularly used in edit summaries where space is strictly limited. SP:CONT or SP:C would save quite a bit in many edit summaries. — Makyen (talk) 20:22, 26 February 2014 (UTC)
I've submitted requests to have some links changed to shorter redirects, which adds 27 characters to the usable size a custom message can be. The new messages are similar to what was offered above, but with Help:RV used instead of H:REV in case the latter is ever deleted (since there has been fuss over that kind of redirect lately). I anticipate we may decide to unlink some of the links, but this will be an interim solution until we gain consensus for that. Jackmcbarn (talk) 20:35, 26 February 2014 (UTC)
  • Jack, I hope you don't mind I've tacked on to your EP requests... Your change is an 47 character improvement, I modified it again for an additional 18 characters saving a total of 65 characters. — {{U|Technical 13}} (t • e • c) 21:08, 26 February 2014 (UTC)
@Technical 13: Not quite. See why in the requests. Jackmcbarn (talk) 21:09, 26 February 2014 (UTC)
The short form of Special:Contributions is Special:Contribs. Legoktm (talk) 20:43, 26 February 2014 (UTC)
Yes, it's not good to truncate at all, but any increase in the current effective limit of about 85 is helpful. I left a message at User talk:Cenarium, the author of and only contributor to MediaWiki:Revreview-reject-summary-cur. —Anomalocaris (talk) 20:52, 26 February 2014 (UTC)
(edit conflict) @Makyen: the link to special:contribution/username is supplied by the software, and the $2 macro in the message is replaced by it. i do not think we can change that - our only option is to simply not include $2 in the message, and i do not think this would be a good thing. personally, i don't see why links to the help page or the policy page should be part of the summary - their usefulness there is marginal at best. as to your idea to create a shortcut to "Special:Contribution": i do not think this can work - shortcut are redirects, not templates, and you can't simply concatenate the user name to a shortcut (that is, you can't create a shortcut to "Special:Contribution/Username" and then pass the username as parameter to the shortcut - redirects do not accept parameters...) peace - קיפודנחש (aka kipod) (talk) 21:06, 26 February 2014 (UTC)
@קיפודנחש: When making the suggestion of having a shorter version for Special:Contribution/username, I was aware that it was not as simple as making a redirect, or I would have just done so. It was clear the link was provided automatically by the software and that changes in the MediaWiki software would be required in order to support much shorter versions of names for that page and other special pages. My mentioning it was intended to highlight that it is an item that consumes a proportionately large amount of a very limited resource. Given how often links to that page are used in a location that is strictly limited in the number of bytes available, it should have a very short name. What that short name should be, in particular any namespace alias, is not something that can be chosen without considerable discussion and investigation into the appropriateness of any candidate names. Given that such changes require changes to the MediaWiki software any such discussion should be at a different venue. — Makyen (talk) 21:40, 26 February 2014 (UTC)

I'm preparing a patch for MediaWiki right now that will make it use Special:Contribs instead of Special:Contributions. Best case, it makes it here on the 6th. Jackmcbarn (talk) 21:42, 26 February 2014 (UTC)

I've submitted gerrit:115696 and gerrit:115806. Once both are merged and deployed, Special:Contribs will be used instead of Special:Contributions. Jackmcbarn (talk) 22:26, 26 February 2014 (UTC)
@Jackmcbarn: your patch can be dangerous and might be harmful to wikis that use non-latin script, b/c it might calculate "shortest" based on character length rather than byte length. these are not the same for non-latin-script wikis, and might not find the shortest. specifically for contribs, in hewiki the "shortest" is "תרומות" of length 6 (characters) vs. "Contribs" - 8. however, "תרומות" weighs 12 bytes vs. "Contribs" - 8. i'm not a php guru, but according to [1], strlen() normally returns the byte length so it should work fine, but the problem is it can be overloaded to return character-length. it is safer to use mb_strlen($string, '8bit');, which is "guaranteed" to return byte length. also, as far as i can see, it does not choose the shorted alias for the namespace itself - this will also be helpful (e.g., "Special" weighs less than "מיוחד"). peace - קיפודנחש (aka kipod) (talk) 23:06, 26 February 2014 (UTC)

Move over a redirect?

Exertional Rhabdomyolysis should be at Exertional rhabdomyolysis. There's only one edit in the history or the properly capitalized page (the creation of the redirect). But I can't move it. Did WP:MOR go away when I wasn't looking, or is there something else going on here? WhatamIdoing (talk) 22:07, 26 February 2014 (UTC)

Page A can only be moved to Page B if Page B is a redirect to Page A with only one edit in its history. In this case, Page B is a redirect to Page C. So you need an admin. It looks like there's some dispute about this article (currently prod'ed) but regardless, the history should be at the proper capitalization, even if it eventually ends up a redirect again. --Floquenbeam (talk) 22:14, 26 February 2014 (UTC)
Actually, I have no idea about the proper capitalization, but I'll take your word for it and move it; it can always be moved back if others disagree. --Floquenbeam (talk) 22:16, 26 February 2014 (UTC)
 Done --Floquenbeam (talk) 22:18, 26 February 2014 (UTC)
Thank you. I'll have to remember that MOR is on the long list of Things That Are More Complicated Than That. WhatamIdoing (talk) 22:58, 26 February 2014 (UTC)
No problem. It's probably easier to keep track of the shorter List Of Things That Are Actually As Simple As They Seem. --Floquenbeam (talk) 23:39, 26 February 2014 (UTC)

Locking the entire wiki against public editing with a single command

At one time, someone with the sysop password was capable of locking the entire wiki against public editing with a single command, in case anonymous vandalism became rampant for a time — see nost:Wiki Administrators. Of course admins can't do this anymore, but is there another userrights package that includes it (e.g. steward), or is it possible only if you're one of the server operators? Someone at WP:ANI is wondering about the risks of vandalbots that do random things while operating on extra-dynamic IP addresses; I'm curious whether this semiprotect-the-whole-website could be done if we got to a really extreme point. Nyttend (talk) 02:06, 27 February 2014 (UTC)

The sysadmins can lock the database, keeping absolutely everyone (including admins and stewards) from doing anything. There's no good on-wiki way to do anything like that, though. The abuse filter wouldn't work at all, because it turns off any filters that trip too much. I suppose, in an emergency, .* <autoconfirmed|noedit> could be added to the titleblacklist, which would keep anyone non-autoconfirmed from editing anything, but this would probably be a bad idea even in an emergency. Jackmcbarn (talk) 02:21, 27 February 2014 (UTC)
Actually, there's a chance that a steward could grant the steward usergroup the siteadmin right, and use that to lock the databases, but I don't think file permissions are set up on WMF servers for that to work. Jackmcbarn (talk) 02:24, 27 February 2014 (UTC)
There is no feature specifically intended for this but an admin with the right know-how could prevent non-admins from editing. If it was done without consensus then it would probably quickly be reverted by another admin, and the first one might soon be an ex-admin. See also Wikipedia:Village stocks for some actions with unintended consequences. PrimeHunter (talk) 03:35, 27 February 2014 (UTC)
Actually I was aware of Village Stocks; that's specifically why I said "only if you're one of the server operators", since I remembered reading the bit about the server being told to refuse traffic from the whole world, and I remembered reading about Ed Poor completely preventing vandalism for several minutes. Good idea or not, I wasn't going to attempt to implement anything, of course (surely that would be an instant arbitration case!), although I had no idea that the titleblacklist thing would be relevant. Nyttend (talk) 07:34, 27 February 2014 (UTC)

Suppressing paragraph numbering in the Table of Contents solely at the third level

G'day Guys My exceedingly long list needs improved presentation: List_of_Australian_radio_broadcast_transmission_characteristics I have floated the table of contents right, as suggested by Ariconte in the Teahouse, which is great. But the paragraph numbering at the third level takes away from the readability of the TOC rather than adding to it, since the section headings (radio station callsigns) are sufficent in themselves. Is there a way to suppress the paragraph numbering solely at the 3rd level? TIA Samuel.dellit (talk) 02:57, 27 February 2014 (UTC)

with {{TOC limit}}. You can adjust the numbering if I misunderstood you. ~HueSatLum 03:47, 27 February 2014 (UTC)
Thanks, but this does not solve my problem. {{TOC limit}} just eliminates the third level entirely from the TOC. I want to retain the third level section names in the TOC but not the associated paragraph numbering. Can this be done? Samuel.dellit (talk) 04:30, 27 February 2014 (UTC)
No, if I understand you correctly, I'm afraid that can't be done without manually making a TOC, which would be a terrible idea. ~HueSatLum 04:54, 27 February 2014 (UTC)
By the way, regarding the article you may want to read WP:LC; the article is quite long at the moment. ~HueSatLum 04:58, 27 February 2014 (UTC)
I guess one man's listcruft is another man's priceless resource, the list has had more than 6,000 hits in 2 months since inception and is regularly in the first few recommended websites for historical information about Australian AM radio both on Google and our National Library of Australia. But yes, I do accept that the list is becoming too long. Once the data fields are well populated, perhaps a transition to WikiBooks would be in order. Thanks for your help, though I would have thought my TOC requirement was not all that unusual and someone would have already written their own TOC template. Samuel.dellit (talk) 07:59, 27 February 2014 (UTC)
{{TOC limit}} is left-aligned and doesn't float. To float right, use {{TOC right|limit=n}} where n is an integer in the range 2-5 (|limit=1 is ignored; |limit=6 is pointless). I suggest {{TOC right|limit=3}} for List of Australian radio broadcast transmission characteristics. --Redrose64 (talk) 10:18, 27 February 2014 (UTC)
Thanks very much also, but as I said earlier in this post, I only want to suppress the paragraph numbering at the third level, I still want the third level section names to appear in the TOC. For example, instead of 4.1.85 3BA Ballarat in the TOC, I just want 3BA Ballarat to appear. It shouldn't be that difficult for a seasoned wiki editor, but it certainly is beyond me Samuel.dellit (talk) 11:21, 27 February 2014 (UTC)
No, it isn't possible to do this by editing wikitext on the page. It is, however, how the TOC behaves if you turn on the "typography refresh" beta feature in the "Beta" menu accessed from the top of the page (although that behaviour is subject to change without notice). I also assume it could be done by altering your common.css page, but I haven't investigated what code exactly would be necessary. Of course, turning on the beta feature and altering your user common.css page would only change the TOC's appearance for you, not for other users. — Mr. Stradivarius ♪ talk ♪ 12:51, 27 February 2014 (UTC)
493 TOC lines is also far too many. I have to scroll down 12 pages from start to end of the TOC. This is what {{TOC limit}} is for. PrimeHunter (talk) 13:51, 27 February 2014 (UTC)

I have no issue with how many lines you have to scroll down in a TOC if you use {{Fancy TOC}} which puts the TOC in a fully customizable scrollbox so the TOC no longer effects the length of the page. You may also be interested in T6127, which requests a token to suppress table of contents autonumbering; T8453, which requests for a way to allow labelling certain sections with letters instead of numbers (displayed in the ToC); and/or T45494, which request to allow us a way to make table of contents numbering scheme and style localisable. While none of those bugs directly requests what you are asking for here, it could be a part of a couple of them if someone was to so comment and ask for it. Alternatively, you could always start a new bug ticket on Bugzilla to request this feature. — {{U|Technical 13}} (t • e • c) 14:00, 27 February 2014 (UTC)

actually, suppressing TOC numbering is already available in enwiki, through the "nonumtoc" class defined in MediaWiki:Common.css. i do not know of a nice template that uses it, but you can do it directly, like so:
<div class="nonumtoc">__TOC__</div>
once you package your TOC inside a div, you can add some more behaviors (e.g., float to left, float right, or center the TOC, limit the height with optional scrollbar if TOC is too high, etc.). unfortunately, i do not think it's currently possible to remove the numbering from *some* TOC levels but not all, as the OP requested (it's possible to do so via CSS rules, but those are not currently defined in enwiki). also note that the "typography refresh" beta feature gets rid of TOC numbering altogether, and if (or when?) it will become standard, this whole issue may become moot. peace - קיפודנחש (aka kipod) (talk) 16:32, 27 February 2014 (UTC)
Eh, I think this is a very bad idea. Legibility, usability and predictability would seriously be compromised by so much content and TOC techniques like these. If you want to read this article on mobile then good luck.. This is a clear indication of too big —TheDJ (talk • contribs) 18:21, 27 February 2014 (UTC)

There's a more fundamental issue: Is the article too big and should thus be split? Or can the information be presented in a more informative fashion? Fixing the TOC to display in a certain fashion does not fix what I see as the underlying issue, that the presentation of the information is just really bad. --Izno (talk) 16:33, 27 February 2014 (UTC)

Padleft hack still in use?

It seems that {{substring}} is still using the so-called "padleft hack" which is basically a disgusting anti-pattern predating the introduction of Lua. Is there any good reason for this, or was it simply missed during the conversion efforts? It does appear to have quite a few transclusions. --NYKevin 16:27, 27 February 2014 (UTC)

@NYKevin: this template has 0 transcusions from Article namespace (aka namspace 0), which is wnat counts' IMO. this template is not protected, and if you think it's important, you can probably modernize it yourself. peace - קיפודנחש (aka kipod) (talk) 16:37, 27 February 2014 (UTC)
Taken care of. Jackmcbarn (talk) 17:42, 27 February 2014 (UTC)

Sortable columns

Template:Floruit/doc#Parameters claims that {{fl.|n}} will sort correctly in tables, whereas {{fl.}} n won't. But, unless I'm missing something, both Col 1 and Col 2 in that table sort incorrectly (i.e. 1066, 1956, 1510), if you click on the arrows next to the column names. Has something gone wrong with either {{fl.}} or Wiki-tables? It Is Me Here t / c 13:18, 25 February 2014 (UTC)

In [2] code was copied without updating the documentation. The parameter sortable=yes is in the dcumentation for {{circa}}. PrimeHunter (talk) 13:06, 26 February 2014 (UTC)
OK, template documentation fixed. It Is Me Here t / c 14:19, 28 February 2014 (UTC)
Actually, sorry, I have another question. Does {{Marriage}} work in the same way? It Is Me Here t / c 01:01, 1 March 2014 (UTC)
No, {{Marriage}} has no sortable option. Are there situations where this would be useful? It sounds inappropriate to me to make a sortable table of somebody's marriages, almost like you make fun of how many they have. Just list them in chronological order. PrimeHunter (talk) 03:20, 1 March 2014 (UTC)

New editing interface

I hate the new editing interface. It becomes impossible to edit templates. Is there any way I can turn it off. ~EDDY (talk/contribs)~ 02:12, 27 February 2014 (UTC)

Like I literally cannot add File:US Navy 111111-N-OK922-242 Michigan State University center Adreian Payne scores against the University of North Carolina during the Quicken Loans.jpg to Adreian Payne because I can't edit the Infobox. ~EDDY (talk/contribs)~ 02:35, 27 February 2014 (UTC)
What new editing interface are you referring to? WP:VE or something else? Jackmcbarn (talk) 02:36, 27 February 2014 (UTC)
No, because I would have had to set my preferences to Visual Editor. Maybe it's the iPad. The interface makes brown boxes around templates, and the contents of the template do not actually show up on the screen, just the fact there is one. If I click, sometimes I can edit the template, but most of the time it cannot be done. ~EDDY (talk/contribs)~ 03:34, 27 February 2014 (UTC)
Does it happen if you log out? PrimeHunter (talk) 04:07, 27 February 2014 (UTC)
It doesn't happen if I'm logged out, if that's what your asking. It only happens when I'm logged on. Every time I go to edit something with a template, the old {{ formatting goes on for about 2 seconds before reverting to the new TEMPL box. ~EDDY (talk/contribs)~ 23:08, 27 February 2014 (UTC)
I don't know what this "new TEMPL box" is ... do you think that you could please provide a screenshot? See WP:WPSHOT for how. --Redrose64 (talk) 23:23, 27 February 2014 (UTC)
If it doesn't happen when you are logged out then it sounds like something in your account. User:Editorofthewiki/monobook.js imports many scripts. Is your skin MonoBook? Does it happen in Vector, for example in https://wiki.riteme.site/w/index.php?title=Adreian_Payne&action=edit&editintro=Template:BLP_editintro&useskin=vector? PrimeHunter (talk) 00:08, 28 February 2014 (UTC)
Alright I played around with my preferences and it went away. It must have been something that was added automatically to my account. ~EDDY (talk/contribs)~ 01:31, 28 February 2014 (UTC)

Videos only play in line if over 800px wide

At 320px wide, this video plays in a pop out player.

Play the video on the right and a video player pops up. If I set the video thumbnail to an unreasonable 801px, the video will play in line. Why is this? No other video embeds on any other website behaves like this. - hahnchen 02:47, 27 February 2014 (UTC)

Video playback breaks depending on video placement

Goto Dustforce and view the same video. Not only will a pop up player appear, it will appear wrongly sized. On Firefox, the video still plays, on Chrome it does not. - hahnchen 02:53, 27 February 2014 (UTC)

Well, we are not like other websites. You can file a bugreport with this information in bugzilla, if the behavior is undesireable. Keep into account though, that other uses might have other usecases and needs, so perhaps there is a reason it works like that.. The problem on Dustforce article, i cannot reproduce, it might have something to do with your skin, gadgets or userscripts. Try playing it while being logged out. —TheDJ (talk • contribs) 18:30, 27 February 2014 (UTC)
I initially saw the problem too. A purge fixed the problem on Dustforce. — Edokter (talk) — 19:23, 27 February 2014 (UTC)
Null edits do fix the issue. I just fixed this on Bobby Bumps. It's still broken in Milan Cabrnoch. Does this need to be raised as a bug? Is it a parsing issue or playback issue? - hahnchen 21:25, 27 February 2014 (UTC)
A purge is not the same as a null edit, they have different effects. A purge cause the page to rebuild and update the server cache. A null edit may trigger a rebuild, but not update the cache. This issue is purely caused by the cache not being updated after an edit. — Edokter (talk) — 23:41, 27 February 2014 (UTC)
A null edit does everything a purge does plus some other stuff. A purge updates the cache, and a null edit updates the cache and the links/categories/etc. tables. Jackmcbarn (talk) 02:04, 28 February 2014 (UTC)

Misplaced signature

I've noticed some problematic that I think I can reproduce. If I compose some text in an external editor, paste that text into a talk page, then click on the icon to add a signature, it sometimes out the sig at the beginning rather than the end, even though the blinking cursor is at the end of the pasted text.

With some experimentation at User:Sphilbrick/sandbox I see that if I just paste the text, the sig goes in the right place, but if I type a colon or two, then paste, then click on the icon, it places the sig in the wrong place. (Mozilla Firefox)

Has anyone else observed this? Any suggestions?--S Philbrick(Talk) 21:48, 27 February 2014 (UTC)

Addendum; just tried in Chrome and it did not happen, so it may be browser related.--S Philbrick(Talk) 21:50, 27 February 2014 (UTC)
The signature button always inserts the sig at current cursor position. If the cursor is at some position other than the end, the sig will not be added at the end. In Windows browsers, use Ctrl+End to position the cursor at the very end of a lengthy edit window. --Redrose64 (talk) 22:22, 27 February 2014 (UTC)
I understand. However, I can clearly see the cursor blinking at the end of the inserted text, while the sig goes at the beginning. I was going to offer to provide a screen shot, but the two options I have for taking screenshots do not show the placement of the cursor. I just tried this in IE, but it did not happen in IE. It isn't a lengthy edit window, my example has only three words. I note it does not happen if I include the spacing colons in the copied text, but I often compose my message, then open the edit window to determine how many colons I need, add them, then paste the text and then click on the sig symbol. I suppose I can change my habits, but that won't be easy.--S Philbrick(Talk) 22:35, 27 February 2014 (UTC)
If it helps, the problem is not specific to the signature icon. If I open the edit window, type a couple colons, paste some text, and then click on bold, it places the bold markup at the beginning. The same thing happens if I try the italic button, or try to add a link. The cursor is blinking at the end of the inserted text, but the link is add at the beginning of the entire section, before the section headings.--S Philbrick(Talk) 22:49, 27 February 2014 (UTC)
I have wikEd enabled, but I'm not using VE.--S Philbrick(Talk) 00:15, 28 February 2014 (UTC)
Good question. I turned off wikED, and the problem did not happen. I turned it back on, and it did. So very likely wikEd related.--S Philbrick(Talk) 00:23, 28 February 2014 (UTC)
I can now reproduce it regularly. You have to manually type the colon, paste some text, then click the icon in Firefox, with wikEd enabled. If the colon is part of the copied text it won't happen. If you type in the text, it won't happen. If you move the cursor someplace, then back, it won't happen. For some time, I was frustrated, because it happened some times, and not others, but I was able to reproduce it 20 times today.--S Philbrick(Talk) 03:07, 28 February 2014 (UTC)

Server-side code for getting user options

I'm was updating documentation on User talk:Howcheng/quickimgdelete.js, and I noticed that my script installation instructions are specific to the Monobook skin, which is no longer default. What I wanted to do was put the user's skin in the link instead (i.e., something like [[Special:Mypage/{{#useroptions:skin}}]]), but I don't know how to get at the user options using server-side code (it's part of mw.user.options in Javascript). Anyone know how to do this? Thanks. —howcheng {chat} 11:16, 28 February 2014 (UTC)

I don't think there's any way to do what you want, since it would fragment the cache. Why not just reference Special:MyPage/common.js? Or enwiki has a script to make Special:MyPage/skin.js go to the right place. Anomie⚔ 11:33, 28 February 2014 (UTC)
Perfect, that's what I was looking for. —howcheng {chat} 16:56, 28 February 2014 (UTC)

Blocking problem

Tracked in Phabricator
Task T63942

I just went to block a user for spam username. I always use the 'Block user' facility in the sidebar. I clicked on indefinite - OK. I then went to 'Reason' and instead of the full list, I was offered seven 'Common block reasons', none of which was spam username'. The 'Warn' feature on the top toolbar worked fine - full list available. Is this a glitch, or has someone somewhere decided that we must now type in our reasons instead of having a full pulldown list as well as having the option to customise individual cases? Peridon (talk) 12:14, 28 February 2014 (UTC)

This is weird. All the reasons are there in 'Edit block reasons', but when I click on the pulldown reasons box, I get seven reasons only. I've made no changes to anything recently, and other than editing the reasons in 'Edit block reasons', I can't find a way of changing the display. I'm on XP Pro, Firefox 20, and Monobook. I've restarted the browser (which automatically deletes history). I haven't tried standing on one leg and whistling Rule Britannia yet... Peridon (talk) 14:05, 28 February 2014 (UTC)
  • This is a regression in 1.23wmf15, tracked in T63942. The fix was backported to 1.23wmf16 last night (early morning UTC), but it wasn't realized this existed in 1.23wmf15 as well. I plan to deploy the fix to 1.23wmf15 in a few minutes. BJorsch (WMF) (talk) 14:13, 28 February 2014 (UTC)
I wish I knew what that meant, but grateful thanks for it.... Peridon (talk) 14:16, 28 February 2014 (UTC)
It pulls the block reason from your interface language preference instead of enwiki's (which are assume are both English, though), and it seems the two sets of reasons don't match, hence the discrepancy. ☺ · Salvidrim! · ✉ 14:18, 28 February 2014 (UTC)
Back almost to normal now. (It opens to the bottom of the list, not the top. Fine for me - I use that end more anyway...) I'd just looked at the bug link and worked out that it might have something to do with me being on Brit English. Peridon (talk) 14:24, 28 February 2014 (UTC)
Thanks to you, I just realized there are actually three English user preference options (en, en-CA and en-GB). I didn't know that! I'm kind of afraid of changing to en-CA though, despite being Canadian... not sure what exactly would be different. But at least now we know the en-GB default block reasons are different from enwiki's standard ones for some unfathomable reason. ☺ · Salvidrim! · ✉ 14:50, 28 February 2014 (UTC)
Try it. You can always come back out as I did while investigating this. (Went into Vector to see if it was a glitch in Monobook. Came back out quick again feeling cold. I suppose Vector might look better in a California summer, but in a GB winter, no thanks...) Peridon (talk) 15:03, 28 February 2014 (UTC)
Vector suits my Canadian Winter perfectly. I'll give en-CA a shot! ☺ · Salvidrim! · ✉ 15:30, 28 February 2014 (UTC)
There are indeed three language variants, but when the "normal" (en - English) messages are updated, the British-English and Canadian-English messages are not usually updated to suit. I'm British, and I find it easiest to use "en - English". After all, the language setting does not affect variants like colour/color in article text. --Redrose64 (talk) 16:05, 28 February 2014 (UTC)
Is the user-language-dependent data editable in MediaWiki space like wiki-language-dependant data is? ☺ · Salvidrim! · ✉ 16:47, 28 February 2014 (UTC)
I don't know if the en variants all use the same one, but the en-gb one I get is editable. Judging by the edit history, I'd say it's all one and the same. I think French might have two variants - fr and fr-ca - but don't quote me... Peridon (talk) 20:44, 28 February 2014 (UTC)
Each en variant is treated as if it were a separate language. Users who select en-GB or en-CA won't see messages that were only customised in en. Admins can edit the messages for non-default languages by adding a slash followed by a language code to the relevant MediaWiki-namespace page title. – PartTimeGnome (talk | contribs) 23:37, 28 February 2014 (UTC)
Before this bug occurred, the block reasons were always in the wiki language, regardless of the blocking admin's language. There was never any point in customising the block reasons for other languages, so it wasn't done. That, and as Redrose64 pointed out, admins tend not to edit the messages for non-default languages anyway. – PartTimeGnome (talk | contribs) 23:37, 28 February 2014 (UTC)
  • Peridon above said: "It opens to the bottom of the list, not the top. Fine for me - I use that end more anyway." I'm glad Peridon's happy, but I'm not. Not only don't I like it, but, more important, it's not normal behavior for a drop-down. Is it going to be fixed (sorry Peridon)?--Bbb23 (talk) 16:17, 2 March 2014 (UTC)

Kings of Wales family trees

Can someone sort out why the chart at Kings of Wales family trees does not display properly? Thanks. Ghmyrtle (talk) 15:06, 28 February 2014 (UTC)

What's wrong with it? --Redrose64 (talk) 16:06, 28 February 2014 (UTC)
The question was originally asked at WT:WALES. I looked at the page and have the same problem - the text is mostly squashed up at the top and bottom of the screen, overlaps with other text, and bears no relationship to the boxes in which the text should fit. I'm on Google Chrome. To a non-techie like me, there seemed no obvious way to fix it. Ghmyrtle (talk) 16:31, 28 February 2014 (UTC)
PS: Just checked on Internet Explorer - it seems to work fine on that. Ghmyrtle (talk) 16:34, 28 February 2014 (UTC)
Looks fine on Firefox 20 - apart from the last two baronets not being connected to anything. Could be a Chrome problem. Peridon (talk) 16:55, 28 February 2014 (UTC)
Looks OK to me too on Firefox 27.0.1. I also connected the last row of baronets based on the family relationships in the linked articles.
Do other articles that use the family tree template look OK to you on Chrome, or are they all broken? That would help narrow down the problem. Take a look at Coppola family tree, {{Family tree}}, {{Walton family tree}}, Roosevelt family. – Jonesey95 (talk) 19:49, 28 February 2014 (UTC)
They all have the same problem for me on Chrome, but in a less extreme form as the trees are much smaller. Ghmyrtle (talk) 20:00, 28 February 2014 (UTC)
Gordon Bennett! That's a mess. All the above trees look fine to me in Firefox 20. I haven't got Chrome except on one mobile. Peridon (talk) 20:39, 28 February 2014 (UTC)
I get the same issues with the trees linked above by User:Jonesey95, although on a smaller scale for obvious reasons. ☺ · Salvidrim! · ✉ 22:58, 28 February 2014 (UTC)
This is a Chrome bug, this was previously discussed on Template talk:Familytree#Rendering issue. Matma Rex talk 23:14, 28 February 2014 (UTC)
Giving the collpased table row a height (even 1px) will force Chrome to display those rows properly. — Edokter (talk) — 23:27, 28 February 2014 (UTC)

Firefox check(ed)

Can someone with Firefox check here to see if the headers are grey in the middle? Trying to rule out my PC. If others see it too, then I discovered a major bug in Firefox involving linear gradients with transparent stops. — Edokter (talk) — 15:18, 28 February 2014 (UTC)

All the headers seem fine to me. Honestly though, I prefer the tables. Supernerd11 :D Firemind ^_^ Pokedex 15:29, 28 February 2014 (UTC)
You tested with Firefox, right? (Which version?) To be clear, the headers are not supposed to be grey in the middle. I actually found a bug report here. — Edokter (talk) — 15:46, 28 February 2014 (UTC)
27.0.1, the most up to date one. The headers are just the usual black on the gray lines, the text itself is the same as anywhere else on the Wiki. Supernerd11 :D Firemind ^_^ Pokedex 16:08, 28 February 2014 (UTC)
With Firefox 27.0.1 I see white at left, grey in the middle, and transparent at right. In Chrome 33, Opera 12.16 and Safari 5.1.7, it's a gradual fade from white to transparent, no grey. In IE8, it's the same colour all the way across - the background colour for the box. --Redrose64 (talk) 16:18, 28 February 2014 (UTC)
That is what I thought; the grey is not supposed to happen. I found a workaround though, but it's still a serious bug; can't use transparent in gradients. — Edokter (talk) — 16:47, 28 February 2014 (UTC)
In Firefox 20, I'm getting black text on a coloured ground deepening left to right. Looks fine. Peridon (talk) 17:00, 28 February 2014 (UTC)
Does it maybe have something to do with what you're on (tablet/PC/whatever)? I'm on a Windows 8 tablet and, much as it sucks, I'm getting the same as Peridon. Supernerd11 :D Firemind ^_^ Pokedex 17:07, 28 February 2014 (UTC)
"coloured ground" doesn't tell me much. I have implemented a workaround, so you should see the headers on a background that fades from white on the left to the background color on the right (with no grey in between). It is a rendering bug in Firefox; the original reporter uses Ubuntu. — Edokter (talk) — 17:51, 28 February 2014 (UTC)
For reference: User:Edokter/gradient shows the bug quite clearly. — Edokter (talk) — 17:53, 28 February 2014 (UTC)
That's very clear. I get gray all over the middle in Firefox 27 and no gray at all in Safari 6.1.1, both on Mac OS 10.8.5. Whatamidoing (WMF) (talk) 18:37, 28 February 2014 (UTC)
A ground is, in heraldry and other art work, a background. A coloured ground is what's under the black text I see in those headers. At the left, they're white or near white. At the right, they're the colour of the ground of the box below them on the page, grading deeper as you go right. In Firefox 20, I get no grey. I've no idea what colouration is normal for the main page as I never go there. (Sorry to all those who work on it - I just don't need to go to it...) Peridon (talk) 19:10, 28 February 2014 (UTC)
It appears your test link no longer shows the bug, since you've changed your CSS to work around it. User:Edokter/gradient does though.
Your analysis on User:Edokter/gradient#Cause isn't quite correct, BTW: the problem isn't that Firefox is supposed to somehow be using the color from an adjacent stop, it's that Firefox is doing the gradient in non-premultiplied RGBA rather than premultiplied RGBA. See Example 23 at http://dev.w3.org/csswg/css-images-3/ for images and details. Anomie⚔ 23:32, 28 February 2014 (UTC)
Yes, I did mention twice I fixed it. Nice find on that page though; I will link to it. — Edokter (talk) — 11:31, 1 March 2014 (UTC)

Call for project ideas: funding is available for community experiments

I apologize if this message is not in your language. Please help translate it.

Do you have an idea for a project that could improve your community? Individual Engagement Grants from the Wikimedia Foundation help support individuals and small teams to organize experiments for 6 months. You can get funding to try out your idea for online community organizing, outreach, tool-building, or research to help make Wikipedia better. In March, we’re looking for new project proposals.

Examples of past Individual Engagement Grant projects:

Proposals are due by 31 March 2014. There are a number of ways to get involved!

Hope to have your participation,

--Siko Bouterse, Head of Individual Engagement Grants, Wikimedia Foundation 19:44, 28 February 2014 (UTC)

My Notifications menu used to show a link to a diff when someone thanked me for an edit. Right now, it looks like:

"Username" thanked you for your edit on Foobar
69 minutes ago

The username is linked. The article name is not linked.

I believe that the article name used to be linked and that there used to be a "show edit" link after the "XX minutes ago" statement.

Sometimes people thank me for an edit that I made a while ago, and I want to be able to see the edit. Now I have to manually type the article name or search my edit history instead of clicking a helpful link. That's not helpful.

Am I remembering this correctly? Is it just me? How can I get this useful link back? – Jonesey95 (talk) 21:23, 28 February 2014 (UTC)

Such a link did indeed exist, and now is no longer there. However, you do not have to search your edit history or the article name. There still is a link to the edit in question, it's just invisible. If you click on the message at any place except the linked username, you get taken to the diff. AddWittyNameHere (talk) 21:51, 28 February 2014 (UTC)
Thanks for the tip. How are people supposed to know about this invisible feature? I'm a pretty clever person who has been using the web for 20 years, and I didn't figure that out. Isn't it better UI etiquette to just put a link where a link should be? Or, to phrase my question in a more confrontational and WP-traditional way that often makes me sigh, was there a consensus discussion that resulted in this change? – Jonesey95 (talk) 00:47, 1 March 2014 (UTC)
You're welcome, by accident (at least, that's how I figured it out), yes it would be, no clue if there was any discussion or consensus. AddWittyNameHere (talk) 02:49, 1 March 2014 (UTC)
For me, the links to both "your edit" (the diff) and page name still exist. This is for all such notifications which are on my notification page (i.e. both recent, 1 hour ago, and past). The entire notification changes color on hover, but is not linked. Now we just need to figure out what the difference in configuration is. I like those links as they currently are. I would not want to see them go away. Off the top of my head, I do not think of anything special I am doing to get the links. I am using the vector skin.
Ahhh... I would bet you two are using MonoBook, or other non-vector skin. In Vector the notifications are only a complete separate page which includes those links. In MonoBook the primary access appears to be a popup (activated by left-click) which does not have these links. In MonoBook, the notifications page can be opened in a new tab/new window (context menu, middle click, or select "All notifications" link at the bottom of the pop-up) which does include the links. — NOPE, not correct.
Ok, that is interesting. When I changed back to using Vector the behavior changed such that it was similar to what I experienced in MonoBook (i.e. the popup window is now the result of a left click on the notification icon). Thus, this appears to be an "enhancement" which had not updated for me until I changed skins. They have not removed the links, just not (yet?) implemented them on the new popup. We look at it as a removal of the links because the popup provides an interface that looks very similar to what we are used to seeing. Thus, we have not recognized that the popup is the new thing.
So, for the moment, the easiest way to get to the desired links is to either click on the entire notification in the popup or bring up the full notifications page. — Makyen (talk) 03:38, 1 March 2014 (UTC)
"In MonoBook the primary access appears to be a popup " eh no, that is the primary access method in ALL skins. If the popup doesn't show for you, then likely you have broken javascripts in User:Makyen/vector.js. —TheDJ (talk • contribs) 11:50, 1 March 2014 (UTC)
You appear to have missed my statement that the popup became primary for me in Vector upon changing back to Vector after testing MonoBook. For a time it was possible for me to see the two different behaviors simultaneously in Vector depending on if a tab had been reloaded after testing MonoBook. Given that my User:Makyen/vector.js page did not change, this implies that my not seeing it in Vector until after switching back from MonoBook was a caching issue wrt. the source of the JavaScript enabling the popup, not an issue with my User:Makyen/vector.js page. Further, a brief check of that page, to which you linked, would have shown that it is completely blank and that the only time it has ever had any content was for 12 minutes on December 11, 2013. Currently, all of my user JavaScript customizations are in common.js specifically so they are common across the various skins. — Makyen (talk) 20:48, 1 March 2014 (UTC)
For what it's worth (not completely understandins some of the stuff above...), I get a full window on Monobook (en-gb), with a normal link to the page, and a little link after the time ago counter to the actual diff. Peridon (talk) 09:57, 2 March 2014 (UTC)

OCSP checking on wiki.riteme.site fails

If "When an OCSP server connection fails, treat the certificate as invalid" is checked at the Firefox options menu, Wikipedia is not reachable. 87.78.121.142 (talk) 01:20, 1 March 2014 (UTC)

Well, presumably your browser is having trouble reaching the OCSP server, which is not Wikipedia's fault. There's a good chance other HTTPS-only sites like Facebook would also be inaccessible while this error is occurring. — This, that and the other (talk) 08:55, 1 March 2014 (UTC)

Scroller in location map

Can someone help me with the large location map at List of power stations in Sri Lanka? I want that image to be half the height, with a scroller on the image part (excluding the caption). I tried {{Tall image}} and <div> stuff; I can't seem to be getting it right... Rehman 08:06, 1 March 2014 (UTC)

Scrollers are bad. They don't really work in print for instance. Suggest to think of another position for this image inside the article. —TheDJ (talk • contribs) 11:45, 1 March 2014 (UTC)
Yeah, you're right. It also doesn't work well on mobile. Didn't think of those. Just for knowledge though, is there a way to do that? Rehman 14:12, 1 March 2014 (UTC)
What's the purpose of this map? The measure of "major" seems inconsistent: the map shows Mampuri Wind Farm (30MW) and Udawalawe Dam (6MW) but not Embilipitiya (100MW) or Colombo Port (60MW). If you're just trying to give a general impression, the map can be smaller and doesn't need the location names. It's difficult to distinguish the marker colors even on a large map. You could use letters instead, e.g. copies of File:NYCS-bull-trans-C.svg, File:NYCS-bull-trans-G.svg, File:NYCS-bull-trans-H.svg, File:NYCS-bull-trans-S.svg, File:NYCS-bull-trans-W.svg customized with relevant colors. Or perhaps you could size the existing markers in proportion to the plant capacity, in which case you really should include all plants above a minimum capacity. That would certainly make the map more meaningful. - Pointillist (talk) 15:07, 1 March 2014 (UTC)
The map isn't complete, that's why it's missing some power stations. (I'm adding them as I verify the plant itself, I have a feeling some are greatly different to the capacity stated). The marker size is a nice idea, but it wouldn't go well near the Laxapana area (would be too crowded). But I agree markers need changing; will work on it soon... Right now, the map just shows the types of power stations and their locations over relief detail. Rehman 15:34, 1 March 2014 (UTC)
Maybe semi-transparent tinted SVG circles, sized by capacity, would look good. Then the overlaps would be more intensely colored. - Pointillist (talk) 15:56, 1 March 2014 (UTC)
Whether SVG or not, overlapping a semi-transparent coloured area on another doesn't intensify colours - if anything, it makes them more muddy. This is because the saturation is decreased. --Redrose64 (talk) 11:07, 2 March 2014 (UTC)
Overlapping partially opaque filled shapes
Well, what I had in mind was an increase in saturation, like the image on the right. This is assuming the overlapping shapes are the same color and that SVG rendering is being done in the browser, which is not Wikipedia's way. So it's not going to work unless it is prepared offline, which eliminates the advantages of map co-ordinates. Even if it had worked it would also have required you to lay down all the circles once in opaque white and then again in semi-opaque color. So it was a rotten approach [sorry] though muddy colors were the least of its problems! - Pointillist (talk) 15:42, 2 March 2014 (UTC)
It intensifies in your demo because all four circles are exactly the same fill colour -   #F0E. Muddiness in the overlap happens when the hues are different; the Sri Lanka map uses pushpin markers of five different hues. Try your demo again, but with each circle a different hue, retaining opacity="0.4" - try it also with the circles layered in different orders. The overlap area will vary. --Redrose64 (talk) 16:43, 2 March 2014 (UTC)
Mmm, as I said, it assumes the overlapping shapes are the same color. In the current context I think the main problem would be the low capacity Mampuri Wind Farm immediately adjacent to the large Lakvijaya Power Station. I expect all the plants around Laxapana are hydro-electric so would have had the same color. But this is flogging a decomposing carcase.... - Pointillist (talk) 17:09, 2 March 2014 (UTC)

Template:Documentation

When using the |content= parameter with Template:Documentation, it is breaking up the green background area on the template page in Firefox 27.0.1. See as an example: Template:Template link templates, down at the bottom. The /doc portion is very strange. Funandtrvl (talk) 20:55, 1 March 2014 (UTC)

  • Template:Template link templates doesn't look like much of a template to me, what is its purpose? Other than that, I can spot by viewing the source of your example that apparently when using |content= the {{{content}}} <p>...</p> section is being added in between the outer div and footer sections but it is being created in a different way causing the top and bottom section to close and the {{{content}}} <p>...</p> section is showing up not in the main div. I'll look at Module:Documentation and see if I can isolate the issue and I have a pretty good idea where to look on this one (I think). — {{U|Technical 13}} (t • e • c) 21:17, 1 March 2014 (UTC)
  • The {{documentation}} template was being called on a line starting with an asterisk, meaning that until the first line break in the module output it was interpreted as being part of a bulleted list. We could start the module with a line break to prevent this, but that might introduce unwanted white space on other pages. At any rate, I've fixed the template link templates page. — Mr. Stradivarius on tour ♪ talk ♪ 23:34, 1 March 2014 (UTC)

Searchbox is broken & Search is overloaded

When I enter anything into the Searchbox, the searchpage comes up instead of bringing me to the page in question, this happens whether I enter a page name, a redirect name, or a shortcut name (yes, I have spelled it properly. It's also become case sensitive, saying the page I entered doesn't exist if I use a different case (say all lower case when the shortcut is all upcaps) - 76.65.129.222 (talk) 07:29, 14 February 2014 (UTC)

Also, I suspect as a result of this bug ("feature") it appears that the search engine is now extremely bogged down. In the wee hours of the day, searchbox keeps failing by saying it is overloaded. -- 76.65.129.222 (talk) 07:37, 14 February 2014 (UTC)
Exact error message welcome, plus browser information (for the first part). --AKlapper (WMF) (talk) 13:46, 14 February 2014 (UTC)
(My IP has rolled over). Today, it doesn't seem overloaded, but there's a persistent error. If I enter WP:USA into the searchbox, it will return:
An error has occurred while searching: The search backend returned an error:
And anything I type into the searchbox whatsoever always goes to the searchpage. If I enter WP:VPT into the searchbox I get
There is a page named "Wikipedia:VPT" on Wikipedia
with a list of results
I am using Firefox 27 (versions newer than this version appear to be incompatible with other software I have, but this behaviour of Wikipedia did not occur before I posted this message, it worked fine in FF27 previoiusly) -- 70.50.151.11 (talk) 23:34, 14 February 2014 (UTC)
This is also happening with WaterFox 18 and PaleMoon 24 -- 70.50.151.11 (talk) 08:51, 15 February 2014 (UTC)

Is this some issue that Wikipedia is now requiring JavaScript? (it does not work even with JS on) -- 70.50.151.11 (talk) 05:07, 20 February 2014 (UTC)

The 'action' of search without Javascript is always full search yes. If it were 'go', then it would not be possible to reach the 'full text' search. —TheDJ (talk • contribs) 12:17, 20 February 2014 (UTC)
Why? It was previously possible - if an article exactly matched, then you were taken there, otherwise you were taken to the search page. If you wanted full text search where an article matched, you clicked on the magnifying glass, then searched. 192.12.81.1 (talk) 15:32, 20 February 2014 (UTC)
Also, typing a tilde ('~') in front of a search forces a full text search instead of jumping straight to an article title. (I normally search from the browser address bar, where this function still works.) – PartTimeGnome (talk | contribs) 22:23, 20 February 2014 (UTC)
You are incorrect. The action of "search" was to "go" to the page you typed in (without JS on). The change is very recent, in worked the day before I filed this, and the day I filed this, it broke. I suspect the search engine overload is caused by this change. A prominent (search for other uses) should instead be included as a top link (similar in appearance to what you get when you follow a redirect) to lower the server loading, so that when you go somewhere you're not wanting, you get to go to the searchpage that way. The overloaded searchpage is annoying as well, having to reload search several times to get results is not a good thing. If the searchbox were restored to just "go" to the page you want, it would take up less server resources than listing all the possible pages you might want.
Also, even with JavaScript on, it isn't working. -- 70.50.151.11 (talk) 01:50, 21 February 2014 (UTC)

Article wizard also broken

Resolved

Any idea what change from Wikipedia brought this about? I notice that the styling for Wikipedia:Article_wizard is also broken across multiple browsers. The buttons for "Write an article now (for new users)", "Request an article be written on a topic", "Create something else (for advanced users)" are invisible. I assume this has occurred at the same time the searchbox broke. -- 70.50.151.11 (talk) 11:39, 18 February 2014 (UTC)

Indeed, I see the same thing on the article wizard. The links are using white-on-white text, though I can't see where that text colour is being set. Since I know where to click, I can still click the links though they aren't visible. You can reveal the links by pressing Ctrl+A to highlight the whole page. I've linked to this discussion from the article wizard's talk page. – PartTimeGnome (talk | contribs) 23:00, 18 February 2014 (UTC)
Any solution should work with JavsScript off. I don't see why embedded styling into the template wouldn't work... -- 70.50.151.11 (talk) 06:43, 19 February 2014 (UTC)
@PartTimeGnome: What browser/OS are you using? When I test Article Wizard on my machine (Firefox and Chrome on OSX) as well as Firefox and IE7 on Windows, I still see the full blue buttons. Steven Walling (WMF) • talk 00:06, 19 February 2014 (UTC)
Opera 12.16 on openSUSE Linux. Others below have now identified that the button styling relied on JavaScript, which I have also disabled. – PartTimeGnome (talk | contribs) 22:11, 20 February 2014 (UTC)
I confirm this, Firefox 23.0.1, Win 7, javascript off. Enabling scripts from wikimedia.org makes the button background appear. 192.12.81.1 (talk) 15:07, 19 February 2014 (UTC)
JavaScript is required, otherwise, you end up with a white 'button' (just a span really) with white text. The better course is to use {{clickable button 2}} directly instead of {{blue button}}, as it constructs the link differetly and handles the font color better (as seen above). — Edokter (talk) — 15:57, 19 February 2014 (UTC)
Yes, if JS is turned off that's your issue, since we're conditionally loading the style with JavaScript. There are alternatives if that's causing many people problems, so we can find a different solution. Steven Walling (WMF) • talk 22:09, 19 February 2014 (UTC)
Yes, alternatives are needed. User experience should degrade gracefully if JavaScript is disabled. White-on-white text is not graceful... (If it's essential for performance reasons to reduce the CSS that is sent to browsers, perhaps the parser could detect markup in the pages that indicates additional resource loader modules to load with the page?) – PartTimeGnome (talk | contribs) 22:11, 20 February 2014 (UTC)
@Edokter, Technical 13, and Steven (WMF):, for now I suggest rolling back Steven's change to {{blue button}}, since it doesn't play well without JavaScript (without JS you get the white coloring without the blue background). That will fix the immediate issue. However, I agree that {{clickable button 2}} works better. With that, the button is on the inside, which means it overrides the link's coloring. No explicit #FFF is needed. Without JavaScript, it simply looks like a link. So if that's okay (link appearance with no JS), Article Wizard can use {{clickable button 2}}. See my test version of {{Article wizard/button wizard}} at [3].
{{blue button}} could also be rewritten to behave like {{clickable button 2}}, or even call it when a link is specified. Superm401 - Talk 22:22, 19 February 2014 (UTC)
 Done self-reverted for now. Steven Walling (WMF) • talk 22:26, 19 February 2014 (UTC)
I'm not sure if it was T13's changes or Steven's revert, but the buttons now appear fine for me, both logged in and logged out. – PartTimeGnome (talk | contribs) 22:11, 20 February 2014 (UTC)

Search algorithm and search engine issues

I'll note that the search algorithm seems faulty. franklin underwood does not show Franklin Underwood as a result in the first page of results. However, previously, the go to page function that used to work would directly bring up the "Franklin Underwood" article, now you'd have to click past the first page of results to even know it exists (and would probably assume that it doesn't exist, since it didn't show up at the top of the results) ; the WPUSA error can be seen with [4] -- 70.50.151.11 (talk) 03:49, 21 February 2014 (UTC)

Franklin Underwood was created yesterday and has not been indexed by the search engine yet. See Help:Searching#Delay in updating the search index. The go to page function doesn't use the search index. It works for me and goes to Franklin Underwood when I enter franklin underwood in the search box at the top right below Log in/out. The second search box at Special:Search has different functionality. It adds &fulltext=Search to the url. This prevents the go function and is intentional. Which search box are you using? The top right box has a drop-down box saying "containing..." (at least in my browser). If that is activated then &fulltext=1 is added and this also disables the go function. I don't know whether there is any difference between &fulltext=Search and &fulltext=1. It appears &fulltext=x for almost any x (other than 0) disables go. PrimeHunter (talk) 04:25, 21 February 2014 (UTC)
The WP:USA error happens when I enter it into the searchbox (the box thing underneath log-in) and it happens if I use the search page. The resultant result page is the same regardless of whether I access the search page or use the search box. Indeed, for the last week, anything entered into the searchbox underneath "log-in" is exactly the same as using the search page. I assume a Wikipedia update changed the behaviour of the searchbox to be identical to the searchpage. -- 70.50.151.11 (talk) 07:32, 21 February 2014 (UTC)
PrimeHunter, re-read some of the earlier discussion above. Like me, 70.50 has JavaScript disabled in their browser, so they do not see the "containing..." pop-up. Previously, searching with the box under "Log in" with JS disabled could immediately go to an article with a matching title. 70.50 is reporting that this recently changed such that a search is always a full text search if JS is disabled, and there is no option for the normal "go" behaviour. This is using the default Vector skin. I'm using Monobook where the search still defaults to "go" as previously. – PartTimeGnome (talk | contribs) 17:45, 22 February 2014 (UTC)
OK, I also get no "go" in Firefox and Vector when JavaScript is disabled. I don't know how it has behaved previously. There is apparently disagreement about that so maybe it depended on something else. Franklin Underwood has now been indexed by search so the article is the first search result on franklin underwood. The below search box has a Go button which works for me with JavaScript disabled, but that isn't very helpful when the normal Vector search box works differently. PrimeHunter (talk) 19:38, 22 February 2014 (UTC)

 
Yup, that's more like the Monobook search box, which also has separate "Go" and "Search" buttons. – PartTimeGnome (talk | contribs) 20:14, 22 February 2014 (UTC)

To clear up some confusion:

  • Behavior of the Vector search box is not related to the behavior of the search backend
  • Behavior of the Vector search box is also not related to the behavior of the search box above, nor any other search box anywhere else on any page

Vector's search box uses 'Go' mode by default when the user has JavaScript enabled and a browser capable of rendering the search suggestions; otherwise it uses the fulltext search mode. This is intended and a caused by a recent change: https://gerrit.wikimedia.org/r/#/c/82100/ – previously it always used 'Go' mode.

This behavior was discussed fervently on the changeset I linked above; in the end I was convinced that this is a better solution. The change was also announced in the second-to-last (I think) tech news posted here. If you disagree, please file a bug. Matma Rex talk 20:22, 22 February 2014 (UTC)

Wikipedia:Village pump (technical)/Archive 123#Tech News: 2014-07 says: "The Vector search box was changed to fix old display and accessibility issues; for example, you can now use full-text search even if you have disabled JavaScript." To me, that formulation sounds like it was about giving a search choice like if you have JavaScript, and not about replacing the existing 'Go' mode. PrimeHunter (talk) 21:45, 22 February 2014 (UTC)
That's a horrid change. It's probably contributing to overloading the search engine as well. Instead the change should have just added a line like when you follow a redirect and it says redirected from X, to have an option of a fulltext search. Or you could add separate search and go buttons to Vector. What's more it doesn't work per my WP:USA search example that breaks the search engine. -- 70.50.151.11 (talk) 08:10, 23 February 2014 (UTC)
I also think it's an annoying change, but many users didn't know how to make a full-text search when there is a pagename match. The current WP:USA error is general for full-text searches. You encounter the error due to the change, but it isn't caused by the change. With JavaScript enabled I get "An error has occurred while searching: The search backend returned an error:", whether I select "containing..." or use Special:Search or click "Search" in the above box, or click https://wiki.riteme.site/w/index.php?title=Special%3A&search=WP%3AUSA&fulltext=Search. It also happens for all other tested namespace:USA searches, for example talk:USA, portal:USA, category:USA. In past periods I have gotten that error message for a lot of searches, but it varies. PrimeHunter (talk) 14:04, 23 February 2014 (UTC)
Except now I, and people like me, will never find out if such a page exists, because the search engine is broken. It effectively ceases to exist, since no results occur. All such pages disappear from existence to all users who end up at the searchpage. So the new "feature" is a bug, since it makes finding some pages impossible. If the change were instead instituted as a pair of buttons on Vector, one for search and one for go, then this problem wouldn't be a problem. And acessing fulltext search could be expressed in a different manner, as I suggested, it could look like following a redirect, where small text indicates you followed a redirect, instead small text would indicate "To search for alternate topics, click here" or somesuch. -- 70.50.151.11 (talk) 04:50, 24 February 2014 (UTC)
The current error message on full-text search of WP:USA is a bug, but normally you are told of a pagename match in bold above the search results. For example, WP:VPT gives me: There is a page named "Wikipedia:VPT" on Wikipedia. This feature is case sensitive after the first letter but if you searched on another letter case then the first search result should normally be the page when it has been indexed by search – usually within a day. I also think there should be a Go option somewhere users can find. Here is one they wouldn't find but you can bookmark it: https://wiki.riteme.site/wiki/Wikipedia:Your_first_article#Title_for_your_new_article. You can also add ?useskin=monobook to any page, for example https://wiki.riteme.site/wiki/Special:BlankPage?useskin=monobook. PrimeHunter (talk) 14:07, 24 February 2014 (UTC)
It looks like you are aware of a similar problem, but here's my experience: I entered "Outside a Small Circle of Friends" into the search box. It doesn't exist, so I should make it a redirect to Outside of a Small Circle of Friends. But I can't, because it says "An error has occurred while searching: The search backend returned an error: ". It happens on three different browsers on three different computers (Windows 8 and XP), but only when logged in. Art LaPella (talk) 19:21, 27 February 2014 (UTC)
I get the same error on any tested search containing "small", including a full-text search of small alone. Whether logged in or out, it only happens when searching more than mainspace, for example Multimedia: https://wiki.riteme.site/w/index.php?title=Special:Search&search=small&fulltext=Search&profile=images&redirs=1. I guess you have more than Article at Special:Preferences#mw-prefsection-searchoptions. There are several workarounds to create a page, for example making a red link Outside a Small Circle of Friends. PrimeHunter (talk) 12:45, 28 February 2014 (UTC)
Yup, thank you.  Done Art LaPella (talk) 16:03, 28 February 2014 (UTC)

Tech News: 2014-10

Latest tech news from the Wikimedia technical community. Please inform other users about these changes. Not all changes will affect you. Translations are available.

Recent software changes

  • The latest version of MediaWiki (1.23wmf16) was added to test wikis and MediaWiki.org on February 27. It will be added to non-Wikipedia wikis on March 4, and all Wikipedia wikis on March 6 (calendar).
  • When users enable web fonts by default, Universal Language Selector will now log if they don't have fonts to display pages correctly. This information will be used by developers to improve font support in the future. Read more about missing fonts. [5]
  • You can now use Guided tours on the Czech and Japanese Wikipedia. If you want this tool on your wiki, you need to translate it and ask in Bugzilla. [6] [7]
  • You can now use information from Wikidata in all Wikisource wikis. [8]
  • The multimedia team is now posting weekly updates on their mailing list. [9]

VisualEditor news

  • You can now change image size to default for your wiki. If you add new images to pages, they will also be default size. [10] [11] [12]
  • If you switch from VisualEditor to wikitext editing, your edit will now be tagged. [13]
  • Template parameters now have a bigger, auto-sizing input box for easier editing. [14]
  • VisualEditor now has Arabic, Finnish and Kölsch icons for text styling. If you want icons for your language, ask in Bugzilla. [15] [16] [17]

Future software changes

Problems

  • For about an hour on February 23, there were problems with page loading due to a MediaWiki bug. [25]

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

09:30, 3 March 2014 (UTC)

A New Browser Based Framework for Tools

For my dissertation, I've been making a framework to make tools in the browser. It's still in development, but I'd like to start encouraging some participation in the development of Vada and its plugins/tools/apps/hacks.

A quick overview, it's written entirely in synchronous javascript (which makes it much easier to develop with), comes with a number of GUI elements with underlying code, such as a queue, a queue builder and predefined buttons (revert & warn, template user, thank user, etc.) and abstracts the API into objects with a tailored caching mechanism.

Currently on this wiki, there is an anti vandal plugin "app" that you can test, which demonstrates some of the features Vada provides.

I would appreciate thoughts, ideas and suggestions to make this framework as useful as possible.

930913(Congratulate) 18:09, 3 March 2014 (UTC)

What's going on with Pollinator?

Tracked in Phabricator
Task T48014

On the page Pollinator, a piped link to taxonomic rank is somehow interrupted mid-word with "Heading 1" in heading form. Step right up and take a look before this freakish problem is fixed! What's going on? ± Lenoxus (" *** ") — Preceding undated comment added 21:26, 3 March 2014 (UTC)

Upon further investigation, it looks like a bug (appropriately enough) in the bot that undid the testing-vandalism edit. I'm guessing that if someone edited and saved it with zero changes, the problem would go away, but I could be wrong, and I sort of don't want to disturb the bug while it remains active. ± Lenoxus (" *** ") 21:31, 3 March 2014 (UTC)

FYI, Lenoxus is not crazy, it really was doing something irrational. But I made a null edit to the article (an actual null edit, not a 1-character edit), and cleared the cache, and now it looks fine. Lenoxus, if it doesn't look OK for you now, then do the same. As for what actually caused that, Lenoxus knows more than me (and sorry if I messed up your example of the bug for other people to see). --Floquenbeam (talk) 21:35, 3 March 2014 (UTC)
It's all good! The page is now fixed but the weird issue is still there in history. Compare this historical page (which contains "Heading 1" and doesn't contain the complete word "subfamily") to the way it looks in edit mode (which is the other way around: it has "subfamily" but not "Heading 1"). ± Lenoxus (" *** ") 21:53, 3 March 2014 (UTC)
We've seen this a couple of times now; see bug 46014. The last report on VPT was in December. The bug is not in the bot, but in MediaWiki; there should not be a way for a bot to prevent the cache being updated when it edits a page. This problem crops up whenever a revert follows fast on the heels of the edit being reverted. Every case reported so far has involved ClueBot NG, simply because it is so fast at reverting vandalism. – PartTimeGnome (talk | contribs) 22:25, 3 March 2014 (UTC)

Re "Download as PDF" function

I have continually experienced problems when trying to use the service "download as PDF".

Firstly, the process is totally incapable of dealing with template:cite journal etc. Even when only using raw text (i.e. no templates at all) as references, I just tried again now to convert a page into a PDF, and the pdf has 50 references when the original page it has been rendered from has 52. References disappear, and I cannot see any reason for this.

Who can I ask about this issue please?

Many thanks for your attention in this matter, Lesion (talk) 15:19, 1 March 2014 (UTC)

I found what was wrong, and I am surprised that this leads to the reference not being rendered.
The first instance of a named reference must be the full reference (i.e. <ref name=blahblah2009>blahblah</ref>), and the subsequent instances of the ref may be shortened <ref name=blahblah2009 />
BUT, if the first instance of a named ref is shortened, then even if one of the later instances has the full ref, none of the references will be rendered in the PDF.
Strange, no?
This is not an issue on Wikipedia articles, since if you place a shortened ref before the full reference they all will still appear normally in the reflist, but it seems to cause this bug on the PDF function for some reason.
I have seen bots correct such sequential errors on wikipedia articles, but never paid much attention to this task until now. It seems that I need to use one of those bots to correct any future pages that I want to convert to PDF.
So my new Q is: does anyone know which bots perform the task of putting the full reference before the shortened references in an article? Many thanks, Lesion (talk) 15:34, 1 March 2014 (UTC)
The pdf creator uses its own wikitext parser different from that used to generate HTML visible on the screen. (See mw:Extension:Collection) And this parser has many issues: see Help:Books/Feedback. Ruslik_Zero 18:55, 1 March 2014 (UTC)
Also, the PDF rendering backend is in the process of being replaced. See mw:PDF rendering. Anomie⚔ 00:30, 2 March 2014 (UTC)

Thanks for background... but for the time being does anyone know what bot would carry out this task:

Before: 

Lorem ipsum dolor sit amet,<ref name=ref1 /> consectetur adipisicing elit.<ref name=ref1>Ref 1</ref>

After: 

Lorem ipsum dolor sit amet,<ref name=ref1>Ref 1</ref> consectetur adipisicing elit.<ref name=ref1 />

I am sure I have seen bots do this, but I don't usually pay them attention. Any ideas? Thanks, Lesion (talk) 00:38, 2 March 2014 (UTC)

I suspect this is T48115 - Template expansion via API fails . --  Gadget850 talk 03:00, 4 March 2014 (UTC)

WMF Labs problem

Is there some problem with the WMF Labs servers, I have been trying to use the Category Tree Intersection tool at http://tools.wmflabs.org/catscan2/quick_intersection.php?lang=en&project=wikipedia and keep getting the error message

Warning: mysqli::mysqli(): (HY000/2003): Can't connect to MySQL server on 'enwiki.labsdb' (110) in /data/project/magnustools/public_html/php/common.php on line 88 Fatal error: Call to a member function real_escape_string() on a non-object in /data/project/magnustools/public_html/php/common.php on line 101

Keith D (talk) 21:46, 3 March 2014 (UTC)

See "Internal Server Error" thread above. --AKlapper (WMF) (talk) 12:04, 4 March 2014 (UTC)

Question about the unsubst: module

I recently moved Template:Necessary? to Template:Overly detailed-inline and, while going over the code, noticed the unsubstitution code uses parameter |$N=Template name.

The module Module:Unsubst is only a year old (or something similar), I think, and I'm not too familiar with Lua. Following renaming of templates, is it a requirement to update the parameter name, or can the system handle it?

First time posting here btw. meteor_sandwich_yum (talk) 23:46, 3 March 2014 (UTC)

Short answer: yes, changing it was a good idea. Long answer: if a template using Module:Unsubst is transcluded, this setting doesn't have any effect. However, if it is substituted, then the |$N= parameter is the template used for the template invocation generated by the module. For example, if you had the template invocation {{subst:overly detailed-inline|one|two|foo=bar}}, and the |$N= parameter in Template:Overly detailed-inline was set to "baz", then Module:Unsubst would output the template invocation {{baz|one|two|foo=bar}}. If you hadn't updated the |$N= parameter, the template would have produced a template call to {{necessary?}} rather than to {{overly detailed-inline}}. That wouldn't really have been a problem as the former is a redirect to the latter, but it is probably best to use the current template name to avoid things being unnecessarily confusing. — Mr. Stradivarius ♪ talk ♪ 01:11, 4 March 2014 (UTC)
Now that I think of it, gerrit:99797 should let us get rid of that $N parameter. @Mr. Stradivarius, care to have a look at Module:Unsubst/sandbox (diff)? Anomie⚔ 01:54, 4 March 2014 (UTC)
Good thinking. :) I would keep the check for the $N parameter in there (like this) until the |$N= code is removed from all the transclusions. If we remove the check, and someone substitutes a template that uses Module:Unsubst before we update that transclusion, the module would include code like |$N=foo in the template invocation it generates. I'll have another look and see if I spot anything, but that's all I've got for now. — Mr. Stradivarius ♪ talk ♪ 06:22, 4 March 2014 (UTC)
Found another issue - for templates, the module was outputting invocations like {{Template:Foo}} instead of just {{Foo}}. That's fixed in the sandbox now. — Mr. Stradivarius ♪ talk ♪ 07:02, 4 March 2014 (UTC)
See, this is why I asked for review ;) Thanks Anomie⚔ 16:09, 4 March 2014 (UTC)

Page creator tool

The page creator tool is still down, any idea what is up with it? GiantSnowman 18:41, 23 February 2014 (UTC)

Cyberpower678 would know. πr2 (t • c) 17:35, 24 February 2014 (UTC)
@C678:, any clue at all please? GiantSnowman 18:43, 27 February 2014 (UTC)
It was working yesterday. I have absolutely no idea why that is happening. I'll have to take a look later today.—cyberpower ChatAbsent 20:49, 27 February 2014 (UTC)
This tool seems to be working now, but toollabs:xtools/pages has some warnings on it ("Notice: Undefined index: lang in /data/project/xtools/public_html/pages/i18n.php"). I assume you also know that pcount shows an error. In a somewhat-related piece of (future) news, Special:Contribs (and API list=usercontribs) will soon have an option to show only page creations (thanks to request by Scott), although excluding redirects will not be possible. πr2 (t • c) 05:35, 2 March 2014 (UTC)

FYI @C678:, @PiRSquared17: this is still not loading for me. Could it because I have created nearly 4,000 articles and it is therefore too big to load? GiantSnowman 12:29, 5 March 2014 (UTC)

Possibly. I'm drawing up design plans for an all new edit counter which will have the articles created count in it. I plan to work on it with the upcoming spring break.—cyberpower ChatAbsent 14:22, 5 March 2014 (UTC)

API question

Hi, I've been trying to query the API for a list of new pages in the mainspace. I've been attempting to add the &redirect= parameter so that redirects don't show up in my query, but they don't seem to get resolved. Is there another way I can do this? Thanks, --Jakob (talk) 02:35, 1 March 2014 (UTC)

Perhaps the &rcshow=!redirect is what you are looking for... Special:ApiSandbox#action=query&list=recentchanges&format=json&rcnamespace=0&rcshow=!redirect&rclimit=10&rctype=new?
There are more possible things you could mean, which is why I asked you to post your current query if you were going to ping us for further assistance... — {{U|Technical 13}} (t • e • c) 16:38, 5 March 2014 (UTC)

Kite

Hi, when I was searching for kite, I saw that on the search results page for kite, there were two links to kite article page (I think so), 1 bold and one that is not bold, I would like someone to deal with this issue on Special:Search by typing in kite and checking it out, if the pages are not the same, maybe delete it under CSD A10 (if possible). Thanks for checking out the problem in advance. (Safari) -- Yutah Andrei Marzan Ogawa123|UPage|☺★ (talk) 09:30, 4 March 2014 (UTC)

Well, the word that you type in is in a regular face in the search box, while any bold items are actual pages or redirects that match the search term. VanIsaacWScont 10:15, 4 March 2014 (UTC)
Yes, the suggestions that appear below the type in box have what you typed in bold. kite in the box and Kite in the pop-down list are the same article. If you type kite t in the box, the top suggestion will be Kite types. Peridon (talk) 12:44, 4 March 2014 (UTC)
This is not broken with Cirrus: [26]. πr2 (t • c) 12:45, 4 March 2014 (UTC)

I've tried it and got the same result. On the search page for "kite" (not the search box, the actual page Special:Search), the top two results both link to the article Kite, one bolded and one not. Also, while the dates of last modification are the same for both results, the unbolded page is 113 bytes bigger (though again, they link to the same article). SiBr4 (talk) 13:43, 4 March 2014 (UTC)

By the way, I'm using Firefox 27.0.1. SiBr4 (talk) 13:46, 4 March 2014 (UTC)
I've been here nearly six years and never used that. (If I can't get it the search box, I Google with 'wiki'.) Hmmm - odd. Exactly the same article. The difference in size of 113 words is puzzling. I can't see an easy way of getting to that amount of difference without going back over a week - possibly even a month. Peridon (talk) 14:13, 4 March 2014 (UTC)
Please note: the 113 is words not bits or bytes. Peridon (talk) 14:14, 4 March 2014 (UTC)
Yeah, I agree it's strange, but we won't be using Lucene search by the end of this month. It seems fine with Cirrus. πr2 (t • c) 15:59, 4 March 2014 (UTC)
I see the problem. Two results for Kite, one not bold and second Bold. There's also a size difference although the date of modification is the same. This seem to definitely be exposing some sort of bug. A bug report should be filed. Hopefully somebody clever enough can figure out more detail of what's occurring. Jason Quinn (talk) 15:50, 5 March 2014 (UTC)

addOnloadHook deprecated for ResourceLoader?

I haven't been keeping updated with the latest code changes on Wikipedia. So I heard addOnloadHook is being deprecated with ResourceLoader? I usually use jQuery's $(document).ready() anyway, so it's not a big deal, but for some of my scripts I still use addOnloadHook because it runs the code after all $(document).ready()'s have been run.

So what would be the equivalent when written with ResourceLoader?

Thanks Gary (talk · scripts) 18:36, 4 March 2014 (UTC)

  • Check your console... ""MWDeprecationWarning: Use of "addOnloadHook" property is deprecated. Use jQuery instead"" suggests to me that it is already deprecated... There's actually a bunch of other deprecated stuff too that should be fixed. ""MWDeprecationWarning: Use of "insertTags" property is deprecated. Use mw.toolbar.insertTags instead"", ""MWDeprecationWarning: Use of "wikiGetlink" property is deprecated. Use mw.util.getUrl instead."", and ""MWDeprecationWarning: Use of "mwCustomEditButtons" property is deprecated. Use mw.toolbar instead"". — {{U|Technical 13}} (t • e • c) 19:52, 4 March 2014 (UTC)
@Gary: all the deprecated functions with their RL/jQuery equivalents is at: mw:ResourceLoader/JavaScript Deprecations. Legoktm (talk) 20:26, 4 March 2014 (UTC)
Okay thanks, I guess it just switched to jQuery. So most of my scripts are fine already. I find addOnloadHook is still useful for scripts that need to be run last, though, such as when they depend on another script (and the order of script-loading is unspecified). Gary (talk · scripts) 17:04, 5 March 2014 (UTC)
@Gary: addOnloadHook(…) is mostly equivalent to $(window).on('load', …), with the caveat that the latter won't fire if you call it after the page has already been loaded – this only matters if you're doing weird things with loading scripts on-demand or when developing and testing code in the browser's console.
It is also worth noting that you can explicitly specify the dependencies of your script (and thus the load order) if the dependencies are ResourceLoader-enabled gadgets instead of random scripts (using mw.loader.using(['ext.gadget.<name>', …], function(){…}))), which is one very big pro of caring about RL :) Matma Rex talk 19:24, 5 March 2014 (UTC)
"ResourceLoader-enabled gadgets", so they have to be in the MediaWiki namespace with the "Gadget-" prefix etc., so only admins can create those? Gary (talk · scripts) 03:51, 6 March 2014 (UTC)
Yep, and there is also bugzilla:34958. Helder.wiki 11:28, 6 March 2014 (UTC)

Turning off Javascript

Is it possible to disable JavaScript on Wikipedia, through Wikipedia? I noticed that Wikipedia works a lot slower for me when I'm logged onto my account than when I'm logged off. Is there any way to fix this? (with turning off JavaScript being one possibility) All Hallow's Wraith (talk) 01:40, 5 March 2014 (UTC)

The difference in speed you are noticing may be due to caching. For anonymous users viewing articles, the entire page is cached, which speeds up load times considerably. If you are logged in, MediaWiki needs to generate the links to your user page etc. at the top of the page, so it can't cache the whole page. There are a few other caching layers that work for logged-in users, though, so it depends what you are doing. When you are logged in, do you notice slower loading times for history view or edit view? Those aren't cached in the same way that read view is. Also, there isn't any way to turn off JavaScript from within Wikipedia, but you could try disabling some of your gadgets from your preferences. (I see you have already cleared your common.js page.) — Mr. Stradivarius ♪ talk ♪ 02:12, 5 March 2014 (UTC)
"When you are logged in, do you notice slower loading times for history view or edit view?" Yes, I definitely do. All Hallow's Wraith (talk) 02:34, 5 March 2014 (UTC)
P.S., how do I turn off all the MediaWiki stuff you are talking about? All Hallow's Wraith (talk) 02:39, 5 March 2014 (UTC)
If you are noticing different loading times on history and edit views as well, then caching probably isn't the issue. And you can't turn it off, anyway. (Not that you would want to, as it makes things faster.) Have you tried disabling your JavaScript gadgets? Go to Preferences > Gadgets and try removing all of them. (Also, try and remember which ones you had turned on so that you can turn the necessary ones back on later - some of them are really useful.) Let me know if that works or not. — Mr. Stradivarius ♪ talk ♪ 05:05, 5 March 2014 (UTC)
"Not that you would want to, as it makes things faster" - I would definitely want to. In my previous browser, I could turn off JavaScript, and Wikipedia was unquestionably faster without it. It doesn't add anything to my Wikipedia experience. As for gadgets, I have all of them turned off. It doesn't make it any faster... All Hallow's Wraith (talk) 05:25, 5 March 2014 (UTC)
@All Hallow's Wraith: I believe that misunderstood Mr. Stradivarius' comment. He said that you would not want to turn off caching, that statement was not talking about JavaScript. As to JavaScript, you may be able to turn off JavaScript within your browser. At least for Firefox, the NoScript extension allows you to disable scripts based on various criteria, particularly the domain from which they are hosted. For Google Chrome there appear to be a few, but I have not tried any of them and the reviews are such that I hesitate to point you at a specific one. You did not specify your current browser, so it is hard for anyone to make recommendations on that end. — Makyen (talk) 06:17, 5 March 2014 (UTC)
Oh, sorry, the browser is internet explorer 11. All Hallow's Wraith (talk) 12:44, 5 March 2014 (UTC)
On the Security tab of Internet Explorer's options, you can add sites to the "Restricted Sites" zone, which will disable JavaScript for those sites. You can customise the options for that zone for more control over what is enabled and disabled. Turning off "Active scripting" is the important bit to turn off JavaScript. – PartTimeGnome (talk | contribs) 00:00, 6 March 2014 (UTC)
As soon as I added Wikipedia to "Restricted Sites", I was logged out and could no longer log back in. I pressed "Enable" on every single security feature, and it still wouldn't let me log in, until I took the site off the restricted list (and then re-set the settings). All Hallow's Wraith (talk) 02:12, 6 March 2014 (UTC)
...However, I then disabled both Active Scripting and JavaScript for the entirety of the internet, and that seems to work! Thanks! Do you know which other parts of that I should disable to make things go even faster? There have to be ones other than just those two as well. All Hallow's Wraith (talk) 02:16, 6 March 2014 (UTC)

Something is clearly wrong with the Tic Price article and I'm not sure how to fix it. Northern Antarctica (talk) 04:26, 5 March 2014 (UTC)

The combination of templates on the page was creating an unclosed wikitable. I've fixed the immediate problem with this edit, but someone who knows the correct statistics should replace the |} code that I added with {{CBB yearly record end}}. — Mr. Stradivarius ♪ talk ♪ 04:45, 5 March 2014 (UTC)

Freeze Panes - Top Row in Tables

Could we implement an option where the top row in a table (the one with labels) would scroll along with the broswer window when viewing long tables? Microsoft Excel has a similar feature called "Freeze Panes." It's rather annoying to have to scroll back up to recognize what a column means and we have many pages of long tables where I think such an enhancement would greatly aid the user experience. For example Assembly of the International Space Station --Rwheimle (talk) 10:57, 5 March 2014 (UTC)

The technology for this does exist; but see MOS:SCROLL. --Redrose64 (talk) 12:21, 5 March 2014 (UTC)
T42763. Matma Rex talk 12:29, 5 March 2014 (UTC)

Bug report: Search settings in Preferences

Tracked in Phabricator
Task T64268

Seems like checkboxes in "Search" section of the "Preferences" are broken, here are more details.

My settings included a selection of namespaces to be searched, and when I accessed this "Preferences" section yesterday, all checkboxes were displayed as empty, what's the first issue. After selecting a few namespaces (other than "Search in all namespaces") and submitting the form, all checkboxes are displayed back as cleared. The only thing that seems to be working is the "Search in all namespaces" checkbox; when selected and submitted/saved, this checkbox displays back as expected. That's the second issue.

Tested yesterday and today on English Wikipedia and Wikimedia Commons, and they behave the same; browsers used were Firefox 24 and 27. Obviously a bug – any chances, please, for fixing it? — Dsimic (talk | contribs) 17:33, 5 March 2014 (UTC)

This seems to be related to gerrit:110610 by 01tonythomas (mw:User:01tonythomas). Helder.wiki 19:01, 5 March 2014 (UTC)
*sigh* yep... Anomie, Matma Rex — {{U|Technical 13}} (t • e • c) 19:06, 5 March 2014 (UTC)
No, not related to that patch. Anomie⚔ 20:26, 5 March 2014 (UTC)
That patch isn't deployed here yet – on https://gerrit.wikimedia.org/r/#/c/110610/, click "Included in" – only branches are master and 1.23wmf16. The English Wikipedia is at 1.23wmf15 right now (see Special:Version). I can reproduce the bug (fascinating), but the cause must be different. Matma Rex talk 19:13, 5 March 2014 (UTC)
Right, on English Wikipedia ticking "Search in all namespaces" doesn't enable/disable other checkboxes, what's the case on Wikimedia Commons which currently runs on 1.23wmf16. — Dsimic (talk | contribs) 21:09, 5 March 2014 (UTC)
I've poked around a bit in Firebug, and it seems that the JavaScript portion of code is Ok, the integer values representing ticked checkboxes are correctly submitted to the PHP backend. Where can I see the PHP code handling the submitted data, please? I'd bet I can help with debugging. :) — Dsimic (talk | contribs) 21:25, 5 March 2014 (UTC)
@Dsimic: mw:Download, or probably mw:Download from git. The interesting files are probably includes/Preferences.php, includes/specials/SpecialPreferences.php and includes/User.php, the preferences code is unfortunately rather spread out all over :/ Matma Rex talk 21:39, 5 March 2014 (UTC)
@Dsimic: Anomie has actually already submitted a patch for this issue, see the bug :) Matma Rex talk 21:41, 5 March 2014 (UTC)
Awesome, thank you for fixing it so quickly! Changes are looking good to someone (me :) reviewing them with no usable knowledge od MediaWiki's internals. :) Such issues are reflecting the beauty of PHP's typeless nature, which brings such surprises all the time.
Btw, Redrose64, I know about WP:LISTGAP and apply that in articles, but I tend to place those blank lines on talk pages – that makes long threads editable and their sources readable. Also, I doubt that many blind or visually impaired people are reading such complex talk pages. — Dsimic (talk | contribs) 22:04, 5 March 2014 (UTC)
@Dsimic: I'm sure Graham87 would disagree ;) Matma Rex talk 22:28, 5 March 2014 (UTC)
Oh, I'm sorry. I also have bad vision, so I tend to speak more openly when it comes to visual impairment. — Dsimic (talk | contribs) 22:36, 5 March 2014 (UTC)
Btw, Matma Rex and Anomie, just a small suggestion based on the patchset...
I'm wondering why aren't you using array_key_exists() instead of in_array()? The latter is much slower as it requires a linear search through the array, while former is faster as it utilizes the associative array's internal hash. As I can see, in_array() is used over the same array multiple times, so introducing the associative array might provide some performance benefits – and they just add up with millions of requests. Also, using isset() instead of array_key_exists() is even faster a few times, but that should be tested first as it depends on the PHP's version.
Just my $0.02. :) — Dsimic (talk | contribs) 22:19, 5 March 2014 (UTC)
Since that code isn't on a critical path, it probably doesn't matter much. Anomie⚔ 22:26, 5 March 2014 (UTC)
Ok, makes sense, thanks for the clarification. — Dsimic (talk | contribs) 22:36, 5 March 2014 (UTC)
FYI, the fix has been deployed now. If you saved your preferences while the bug was occurring, it will have saved the "no options checked" state so you'll have to reset the pref. BJorsch (WMF) (talk) 00:10, 6 March 2014 (UTC)
Thanks for the update. Strangely, I've saved the preferences while the bug was in effect, and now the checkboxes show up as saved back then. Seems like the issue was only with displaying back the state of checkboxes, while they were correctly processed during the submit/save phase? Btw, now I've set my search preferences to "Search in all namespaces". — Dsimic (talk | contribs) 06:15, 6 March 2014 (UTC)
Yes, the issue was only with displaying. Anomie⚔ 11:52, 6 March 2014 (UTC)

Bug report: Appearance settings in Preferences

On Wikimedia Commons, "Thumbnail size" label in the "Appearance" section is displayed in Greek language (I guess) instead of being displayed in English. No other labels are affected by this issue, and they're all displayed in English as expected. Also, English Wikipedia isn't experiencing this issue.

Obviously a bug – any chances, please, for fixing it? — Dsimic (talk | contribs) 17:38, 5 March 2014 (UTC)

Trout Commons:User:Badseed for this edit. Anomie⚔ 19:31, 5 March 2014 (UTC)
 Fixed. Trijnsteltalk 20:08, 5 March 2014 (UTC)
Great, thank you for fixing it so quickly! — Dsimic (talk | contribs) 20:38, 5 March 2014 (UTC)

MediaWiki:Edittools?

It seems like "Edittools" has disappeared from under the Edit summary on pages that I'm editing. The one that usually can display "Wiki markup" tools, like inserting a defaultsort, etc. Funandtrvl (talk) 19:47, 5 March 2014 (UTC)

It's there as I type this. There is discussion at MediaWiki talk:Edittools and User talk:Edokter, possibly elsewhere. --Redrose64 (talk) 19:53, 5 March 2014 (UTC)
Funandtrvl, have you tried clearing your cache? Helder.wiki 20:00, 5 March 2014 (UTC)
(ec) Please check if "CharInsert" is still enabled in your gadget preferences. — Edokter (talk) — 20:03, 5 March 2014 (UTC)
Yes, I cleared my cache and reset all my preferences. It was working yesterday, but not today on Firefox 27.0.1. Funandtrvl (talk) 20:04, 5 March 2014 (UTC)
Works on my end. Do you perhaps have javascript turned off? (Happens to me all the time.) — Edokter (talk) — 20:09, 5 March 2014 (UTC)
Now it's working! Funandtrvl (talk) 20:13, 5 March 2014 (UTC)
Edittools work fine with JavaScript off, though they work a little differently. I have JS off, and I can see them fine beneath the edit box. Without JS, one must copy and paste symbols to insert them rather than clicking them, though. – PartTimeGnome (talk | contribs) 00:07, 6 March 2014 (UTC)

RFC: Should we hide template and image deletion notices from users not logged in?

Moved to the policy village pump.

Timestamp for archive purposes. –xenotalk 02:39, 6 March 2014 (UTC)

Preview now jumps directly to edit window

When I preview an edit, I'm now taken directly to the edit window (ironically, from the edit window) instead of the the top (preview, with the red "This is only a preview...") section. Trouble is, I don't know if I need to continue editing until after I've read the preview and it's inconvenient to have to keep scrolling up. I checked my preferences, and couldn't find any gadgets or other stuff that would cause this. I use XP (stop laughing) and FF 27.0.1. Is it a bug, or is it me? Thanks for any help and all the best, Miniapolis 16:54, 5 March 2014 (UTC)

I cannot reproduce this effect with Firefox 27.0.1 on Windows 8, under skins Modern and Monobook, preferences: Editing Preview:
[ ] Show preview on first edit
[x] Show preview before edit box
[ ] Use live preview (experimental). I've disabled Gadget wikEd, and enabled wikEdDiff, and disabled all Beta Features. Also tried with and without "Show edit toolbar" under Editor preferences. -84user (talk) 18:41, 5 March 2014 (UTC)
  • This is a wikEd thing (may be part of something else too). When you say you "disabled" do you mean you unchecked all wikEd boxes on the gadget page or clicked the icon in the top right corner to disable? Cacycle may be able to help with this question... — {{U|Technical 13}} (t • e • c) 18:53, 5 March 2014 (UTC)
I use Vector, but don't think something like this is skin-dependent. "Show preview before edit box" is checked; it's there, but now I have to scroll up from the edit window to read it. Oddly, though, I can't seem to disable wikEd (I don't have wikEdDiff checked); when I uncheck wikEd on the gadgets-editing menu, save, shift-reload to purge the cache and return to it, it's checked again (and my original problem persists)! Thanks for the help and all the best, Miniapolis 20:45, 5 March 2014 (UTC)
Finally disabled wikEd, but since the problem persists I'm going to re-enable it. Miniapolis 20:57, 5 March 2014 (UTC)
...But when I really disable wikEd (not through Preferences/Gadgets/Editing/Save, but by clicking the icon at the top right of the page), the problem goes away; Technical 13, I think you're on to something. Damn, I really like wikEd; maybe I can learn to live with this :-). Miniapolis 21:13, 5 March 2014 (UTC)
I have not tried them with wikiEd, but there are at least a couple of user scripts which might ease the pain:
  • Floater – Adds a floating toolbar at the top of the window with commonly used items from the toolbar at the top of the page, includes a "Top" link that moves you to the top of the page in one click.
  • goToTop – Adds a link at the bottom left of the window to go to the top of the page in one click.
Another option would be to have the preview display below the edit box (user preferences). That way you just scroll down through it. Also, there are a number of keyboard shortcuts, some of which will move you around the page. Examples of these are the "Search box" shortcut key will jump you to the top of the page in Vector, and any skin that has the search box at the top of the page; and the "Edit box" shortcut key to jump to the edit box. — Makyen (talk) 06:48, 6 March 2014 (UTC)
Thanks for all the advice, although I try not to overuse scripts. Think I can live with this, or get used to life without WikEd :-). All the best, Miniapolis 19:04, 6 March 2014 (UTC)
  • I actually leave wikEd in a "disabled" state because it doesn't get along with code editor and creating new user talk pages with WikiLove (just an annoyance, not an actual bug), and then turn it on only when I want to use features. Just a thought, and I've thought about writing a little snippit of code to move the icon in the page's top corner to a static/fixed position in the lower right corner of my screen with a z-index of ∞ or some such ungodly high number when &action=(edit|submit) and then if you turn it on to edit, clicking save will shut it off again until you want it the next time or something... I'll let you know when I do that as it will make it stupid simple to leave turned off and only activate when it is wanted... — {{U|Technical 13}} (t • e • c) 19:37, 6 March 2014 (UTC)

Underlines versus fractions

{{resolved}} - discussion continued, so let it go :-) . OP is answered. -DePiep (talk) 21:37, 6 March 2014 (UTC)
I am creating a link like this: 4 ft 8+1⁄2 in. Is it possible and advisable to interrupt the underlines at the fraction (denominator)? I found that class="nounderlines" doesn't seem to work on parts of a wikilink. -DePiep (talk) 18:34, 5 March 2014 (UTC)

There is no such class, but even with an inline styling (text-decoration: none;) it does not seem to work. — Edokter (talk) — 20:05, 5 March 2014 (UTC)
@DePiep and Edokter: Yes, it's not possible to "undo" a text-decoration rule (used internally by the browser for underlines, strike-throughs and some more exotic things), unlike, say font-weight or text-transform. That's because it's not applied to the individual characters, but to an entire text "box" (which can in fact be seen in the original example here). My explanation is probably not very clear, but consider the difference between 1⁄2 (where the entire "box" is striken) and 1⁄2 (where every character is striken separately). Matma Rex talk 20:47, 5 March 2014 (UTC)
OK, not possible then. For Edokter: Main page and Main page. -DePiep (talk) 20:55, 5 March 2014 (UTC)
You lost me here. — Edokter (talk) — 21:08, 5 March 2014 (UTC)
Using FF 27.0.1, the second link is not underlined on hover. — HHHIPPO 21:13, 5 March 2014 (UTC)
(edit conflict) why not use 4 ft 8½ in ? (the " ½ " can be found under "symbols" in "special characters" in toolbar). it will not help for +22⁄7, but (almost) everything with denominator of 2, 3, 4 and 8 is there (½ ⅓ ⅔ ¼ ¾ ⅛ ⅜ ⅝ ⅞). peace - קיפודנחש (aka kipod) (talk) 21:17, 5 March 2014 (UTC)
Please don't use ½ etc, see MOS:FRAC. --Redrose64 (talk) 21:53, 5 March 2014 (UTC)
@Redrose64: i looked at MOS:FRAC, and did not see recomendation not to use those. what i *did* notice, though, is that {{fraction}} uses ½ etc., so for the OP, just replacing {{frac}} with {{fraction}} would solve the issue (i.e., instead of [[standard gauge|4 ft {{frac|8|1|2}} in]], use [[standard gauge|4 ft {{fraction|8|1|2}} in]], resulting in 4 ft 8+1⁄2 in ), as long as the fraction is one of those (or 1⁄6, 1⁄9 or 1⁄10 ). peace - קיפודנחש (aka kipod) (talk) 14:32, 6 March 2014 (UTC)
MOS:FRAC states "The use of the few Unicode symbols available for fractions (such as ½) is discouraged entirely, for accessibility reasons among others." Also, your examples of {{fraction|1|9}} → 1⁄9 or {{fraction|1|10}} → 1⁄10 show as boxed hex codes for me, which is an accessibility problem for a sighted reader. --Redrose64 (talk) 14:41, 6 March 2014 (UTC)
@Redrose64: i missed the "unicode" line, but this makes MOS:FRAC inconsistent, because the 2nd bullet says
  • Correct: A History of the World in 101⁄2 Chapters is a novel by Julian Barnes.
which renders as ½. regarding 1/9 and 1/10, which, as you note, are missing from some character sets (i see them in google chrome on one machine, and see the "unknown char" square with chrome on another computer, like you indicate) - maybe we should remove them from {{fraction}}... regarding accessibility - i thought that {{fraction}} uses abbreviation to improve accessibility, no? peace - קיפודנחש (aka kipod) (talk) 16:01, 6 March 2014 (UTC)
I raised some concerns with {{fraction}} well over a year ago, but there was no firm conclusion. The discussion is archived at Wikipedia talk:WikiProject Accessibility/Archive 3#Template:Fraction but some comments went to Template talk:Frac#Template:Fraction and accessibility instead, despite WP:MULTI. Please bear in mind that the template has been heavily modified since then, and so my comments (such as those about one-seventh etc.) should be read in the context of the template as it stood at the time.
Personally I never use {{fraction}} but use {{frac}} instead, which I am informed is somewhat more accessibility-compliant. --Redrose64 (talk) 16:26, 6 March 2014 (UTC)
{{Fraction}} has been deprecated since, and should no longer be used for that very reason. — Edokter (talk) — 19:12, 6 March 2014 (UTC)
Yes, that's how I read it. No problem, clear to me. Edokter also said: "There is no such class" (about "nounderlines"). With my Ff27, the second of the two Mainpage links who uses that class, does not have an underline, while it is blue & clickable. Also: found "nounderlines" in MediaWiki:Common.css. That class is used in {{Punctuation}} btw, with intended effect for me. But this is all I can tell. -DePiep (talk) 21:32, 5 March 2014 (UTC)
So it is... completely overlooked that. — Edokter (talk) — 21:50, 5 March 2014 (UTC)
  • Another venue is {{smallfrac}}, which does not sink below some line (bottom of x letter). So {{smallfrac|8|1|2}} → 8 1⁄2. From the OP issue example: 4 ft 8 1⁄2 in. Looks somewhat better but shifted to me. The code is a bit an (interesting) construction. I would not use it in a 10k template. -DePiep (talk) 21:37, 6 March 2014 (UTC)
Agree. -DePiep (talk) 22:52, 6 March 2014 (UTC)

Template syntax

Dear almighty technical people, I have stumbled across a relic of a time long-ago when wiki-pages and templates were manually formatted, and their meaning could only be divined by those already gifted by 'the sight'. Consequently I'd be very grateful for any help unpicking this template: Template:Infobox muscle, I want to add a section using the 'below' parameter that is bold and italic and reads: Anatomical terms of bone . --LT910001 (talk) 08:39, 6 March 2014 (UTC)

I'm not sure if it's exactly what you're after, but I've had a go at answering your request at Template:Infobox muscle/sandbox. — Mr. Stradivarius ♪ talk ♪ 09:03, 6 March 2014 (UTC)
Thank you! That's exactly what I was looking for. To implement this change, do I just copy and paste the code into the original infobox? --LT910001 (talk) 09:18, 6 March 2014 (UTC)
That's right. But don't you want Anatomical terms of muscle, rather than Anatomical terms of bone? This is Template:Infobox muscle, not Template:Infobox bone, so adding an article about bone anatomy seems like a mistake to me. — Mr. Stradivarius ♪ talk ♪ 09:50, 6 March 2014 (UTC)
Thanks, Anatomical terms of muscle is indeed what I was looking for. --LT910001 (talk) 21:08, 6 March 2014 (UTC)
Ok, I've added it to the main template. — Mr. Stradivarius ♪ talk ♪ 23:26, 6 March 2014 (UTC)

Weird

If one goes to the article Dawes (band), at the very lower left of the browser appears the phrases in very strange manner:

WebRep
currentVote
noRating
noWeight

If you hover the cursor over it, it goes away. But when you reload the page, it will come back. I notice the source for the glitch is likely the band's official website, which has the identical phrasing at the same place.[27] How is this website glitch getting onto our page? Is this the new face of spam? Is it only on Safari? What is up with this, as I have never seen anything like this before? Doc talk 16:42, 6 March 2014 (UTC)

  • (ec) I don't see it, nor can I find any chages that may have caused this. What you see may be caused by your browser. Do you have any web browser extension/plugin installed that asks you to evaluate websites or something? — Edokter (talk) — 17:02, 6 March 2014 (UTC)
  • It sometimes takes a few scrollings before it appears - and it is at the very bottom left corner, just like the band's website. It just happened again when I tested it. I'm on Safari 7.0.2; but I have never seen a browser error like this. Doc talk 17:08, 6 March 2014 (UTC)
    Kindly disregard - it's not likely something wrong here. Thanks. Doc talk 17:18, 6 March 2014 (UTC)
(edit conflict) I see it neither at us nor the band's site. The first result of the Google search webrep currentVote noRating noWeight says "WebRep is an Avast! anti-virus browser plugin". I guess you have that installed. PrimeHunter (talk) 17:22, 6 March 2014 (UTC)
I do: thanks for finding that! It "bled over" to more than one window. I will deal with it now. Thanks again :) Doc talk 17:29, 6 March 2014 (UTC)

Strange manual archiving

Might not be the place this should be posted, but has anyone noticed an IP Special:Contributions/10.4.1.126 is going through a whole slew of pages and manually archiving large chunks at random? Does anyone know if this is some Wikimedia person doing this? — Maile (talk) 02:31, 6 March 2014 (UTC)

it's lowercase sigmabot, logged out. See Wikipedia:Administrators' noticeboard/Archive260#Possible bot malfunctioning?. –xenotalk 02:38, 6 March 2014 (UTC)
Are you sure it's Lowercase sigmabot III, Xeno? I know that Legobot also does archiving... — {{U|Technical 13}} (t • e • c) 02:46, 6 March 2014 (UTC)
Legobot does archive indexing, not archiving. Graham87 07:17, 6 March 2014 (UTC)
Legobot has only made one archive indexing run in the last 11 months. However, it does have many other tasks which are active. — Makyen (talk) 09:28, 6 March 2014 (UTC)
@Technical 13: Once it became clear that the MiszaBot family were down permanently (their last edits were on 2-3 October 2013), Legobot did do some archiving of pages marked with {{User:MiszaBot/config}}, but Legoktm only ran it as a special on three or four occasions (these included 22 October 2013 and 16 November 2013) - AFAIK it was started manually, and not put into the cron. After Lowercase sigmabot III went through BRFA and was authorised to carry out archiving, Legobot did not need to do any more archiving, and so Legoktm has not started any further archiving runs for that bot.
@Graham87: the archive indexing function of Legobot has not functioned correctly (if at all) for about a year now: there are several threads about this at User talk:Legobot/2013. --Redrose64 (talk) 10:34, 6 March 2014 (UTC)

Notification bug

Hi. I received a notification (screenshot) that said Joe Graham was linked from [No page] (not sure how to properly format that link). There are a couple of issues with this. I don't appear to be watching Joe Graham and the second link is obviously bad. Killiondude (talk) 20:12, 8 March 2014 (UTC)

  • @Killiondude: The [No page] link probably means that the page was deleted and oversighted (unless there is some other bug going on). Due to the nature of how the Echo notifications work (in a queuing system outside the database), the notification itself can't be recalled, but the reference to the page can be scrubbed on display. Sorry it's so confusing. Kaldari (talk) 20:48, 8 March 2014 (UTC)
  • Yes, but it may require a bit of extra hackery as I'm not sure how difficult it will be to make it have a different page title from the destination. It's probably trivial, but if the feature works by just passing a single page title param through a hook, it may be slightly more complicated. I haven't looked at the code in a while though, so I'm not sure. Kaldari (talk) 21:12, 8 March 2014 (UTC)
  • Kaldari, thank you for the explanation. That makes sense as a possible reason. If it could link to a page that T13 listed that would probably be a better use of a link. At the very least this should probably be documented on a help page somewhere. Thanks again to both of you. Killiondude (talk) 03:03, 9 March 2014 (UTC)

Strangeness in the Add citation thingy

Since yesterday I've been having problems with the "Insert Citation" functionality (you know, "Cite" on my javascript toolbar). The citation templates fill in properly, but when I click "Add citation" I get kicked back to the editing window (which is normal) but without the citation being added. I found that if I do "Preview citation" first (and then I double-click so at least I save the plain text), and then click again to the proper place in the edit window, and then click "Add citation", that it works properly. But this is real irritating. Drmies (talk) 15:34, 8 March 2014 (UTC)

No help on your issue, but I notice the same is true for disabimg tools - you have to preview first. I seem to recall there being a reason for this. Maury Markowitz (talk) 16:43, 8 March 2014 (UTC)
You're not the only one; I don't do the preview thing, but I have noticed that if you don't click, after composing the citation, where it's supposed to go, it goes poof when you click add - I assume it's somehow trying to add it inside the citation-building box, 'since that's where the cursor is'. - The Bushranger One ping only 06:54, 9 March 2014 (UTC)
Just to be sure, you have the option "Enable enhanced editing toolbar" turned off on your preferences, right? If so, it is probably a problem to be fixed at MediaWiki:RefToolbarLegacy.js, which BTW still uses deprecated code:
  • The old global mwCustomEditButtons should be migrated to mw.toolbar.addButton(s)
  • The global insertTags should be replaced by mw.toolbar.insertTags
And since these functions are defined on module mediawiki.action.edit, this dependency needs to be loaded first (when in edit mode), with mw.loader.using.
Helder.wiki 19:10, 10 March 2014 (UTC)

Collecting statistics on PROD

Looking over the many articles posted to PROD, I find that a large minority, perhaps as high as 50%, are questionable, and a smaller subset, perhaps 20%, clearly fail the criterion. This is supposed to be backed up by a "last chance save" by the deleting admin, but there appears to be no statistics on whether or not this actually occurs.

Given that there doesn't seem to be any closing requirement other than deleting, and that the PROD can be removed by anyone at any time with a similar lack of record keeping, I'm wondering if anyone might suggest ways to collect statistics on this? Theoretically the search would be something to the effect of "how many articles have had a PROD tag applied, how many of those were ultimately deleted, how many were not". My concern is that the last, perhaps most important, part may be difficult to collect - how would one find edits that remove PROD tags specifically?

Maury Markowitz (talk) 16:41, 8 March 2014 (UTC)

DumbBOT, run by User:Tizio is going through the PRODed articles every six hours. I guess it should be possible to modify that bot such that it collects some statistics: count how many articles are entering and leaving the list, and for the leaving ones, check if the article still exists. This will miss articles that are unPRODed or deleted before the bot sees them, and getting historical data is a completely different task involving serious database digging, but it could be a start. — HHHIPPO 17:45, 8 March 2014 (UTC)
Actually, that seems like a reasonable solution. I'll talk to Tizio. Maury Markowitz (talk) 18:43, 8 March 2014 (UTC)
What criterion is there for PROD to fail? Anyone can PROD an article for any reason, unless it's been PROD'd or AfD'd before. Jackmcbarn (talk) 19:36, 8 March 2014 (UTC)
Well, in theory, you are required to "have a valid reason for deletion" and to believe that the deletion would be "uncontroversial". WhatamIdoing (talk) 21:40, 9 March 2014 (UTC)

Quick template needed

Can someone here make up the template {{R from Merger}} which would do exactly as {{R from Merge}} now does (so they could basically be interchangeable)? This would help us mergists—who often do merge and redirects quickly and on the fly—and who really, really hate going back to fix such a minor issue. Thanks, GenQuest "Talk to Me" 20:36, 8 March 2014 (UTC)

You created a double redirect which didn't work. I have fixed {{R from Merger}} to redirect to {{R from merge}}. This means {{R from Merger}} and {{R from Merge}} have identical code and behaviour as requested. PrimeHunter (talk) 21:04, 8 March 2014 (UTC)
That's all that was needed. Thanks folks! GenQuest "Talk to Me" 22:45, 8 March 2014 (UTC)
While we're on the subject: Thanks for merging pages. The biggest source of the merge backlog is not a lack of discussion or consensus, but a lack of people who are willing to bother with the sometimes complicated "merge the articles" step. WhatamIdoing (talk) 21:42, 9 March 2014 (UTC)

When I click on my Reflinks link, I am getting a page not found message from toolserver. It was working fine yesterday. Anybody know if the url has changed or if it has been taken down for maintenance? The link I use (installed in my browser toolbar is "javascript:location='//toolserver.org/~dispenser/cgi-bin/webreflinks.py/'+(typeof wgPageName!='undefined'?wgContentLanguage+':'+wgPageName:)+'?client=bookmark&citeweb=on&overwrite=simple&limit=20';"). Thanks danno_uk 21:54, 8 March 2014 (UTC)

Same here. Except I have bookmarklets for Checklinks, Reflinks, Dablinks, Commonfixes, Altviewer, & Page Watchers, and all of them are giving me a 404. Perhaps down for maintenance? meteor_sandwich_yum (talk) 22:29, 8 March 2014 (UTC)
I should probably note it was working for me roughly an hour ago, it just stopped suddenly. But I have no idea what caused it. meteor_sandwich_yum (talk) 22:32, 8 March 2014 (UTC)
Same here, it doesn't work. Any insights, please? — Dsimic (talk | contribs) 23:07, 8 March 2014 (UTC)
3 hours later & still the same, Any idea on the cause?.... →Davey2010→→Talk to me!→ 01:31, 9 March 2014 (UTC)
Toolserver is down for scheduled maintenaince that apparently is taking longer than expected. --Tim Landscheidt (talk) 01:44, 9 March 2014 (UTC)
"Solaris user land boxes"? — Dsimic (talk | contribs) 01:50, 9 March 2014 (UTC)
a) You're right. b) roots are unpredictable :-). Join #wikimedia-toolserver connect if you want to ask them yourself. --Tim Landscheidt (talk) 01:57, 9 March 2014 (UTC)
Hehe, used to be a sysadmin for more than a few years, so I know very well how things easily can go wrong. :) — Dsimic (talk | contribs) 02:16, 9 March 2014 (UTC)
I like "Solaris user land boxes" and pledge to use it in an edit summary within the next seven days. That should cause some consternation in the Recent Changes queue. danno_uk 03:54, 9 March 2014 (UTC)
BTW that script will break on many pages, because it doesn't url encode wgPagename. Should be + encodeURIComponent(wgPagename) + —TheDJ (talk • contribs) 09:49, 9 March 2014 (UTC)

Admin dashboard

I have the Admin dashboard on my User:Peridon/links page. Normally, when I open the page, the dashboard opens with it. Today, it's just coming up as a blue link to Template:Admin dashboard which I have to click. Not a big deal, but puzzling. No-one's done anything to the /links page or the template since last year, and I've not changed any settings on my computer or altered my preferences here. (Monobook, XP Pro in Classic mode, Firefox 20) Peridon (talk) 12:58, 9 March 2014 (UTC)

Just the same in Vector... Peridon (talk) 13:01, 9 March 2014 (UTC)
That is because the template has become too large to be transcluded. Werieth (talk) 13:01, 9 March 2014 (UTC)
That I don't understand... No-one's edited it since December. Peridon (talk) 13:04, 9 March 2014 (UTC)
The template itself doesnt need to be edited, as the size comes from all of the different pages that get transcluded together. When the total size of the different pages being transcluded gets above a specific size mediawiki wont transclude it. Werieth (talk) 13:07, 9 March 2014 (UTC)
See Wikipedia:Template_limits#Post-expand_include_size Werieth (talk) 13:17, 9 March 2014 (UTC)
(edit conflict) Yep, User:Peridon/links is currently in Category:Pages where template include size is exceeded, and after checking in my sandbox I can confirm that the post-expand include size is also exceeded when {{admin dashboard}} is the only thing on the page. Not sure what the cause of that is, though. I don't see any smoking gun edits from the list of transcluded templates. — Mr. Stradivarius ♪ talk ♪ 13:11, 9 March 2014 (UTC)
Looking at the code, the admin dashboard transcludes seven subpages of WP:PERM, which must be quite a big hit to the post-expand include size. Is there a summary generated anywhere that can be used instead? — Mr. Stradivarius ♪ talk ♪ 13:24, 9 March 2014 (UTC)
The real killer is {{rfplinks}}, since there is one on every single permission request. Either that should be simplified, or the delay between closure of a request and its archiving should be shortened. --Redrose64 (talk) 13:34, 9 March 2014 (UTC)
  • The real killer is the navboxes, they always are. I've already added a parameter to {{Admin dashboard}} to not transclude the "new administrator" navbox unless |newadmin=yes is exclusively set. I'll add some other customizing parameters to the template so that it will be customizable as to showing the various WP:PERM sections. It will work such as the perm page won't show in the template unless there has been an edit to that page in "x" amount of time unless the admin says they don't want to see any perm requests at all by setting |showperm=no. Otherwise the showperm parameter will accept a numeric value in the number of seconds (or perhaps more flexible, not sure yet) since last edit. I'll add full documentation when I'm done. The "new admin" turning off should fix the immediate issue, I hope. — {{U|Technical 13}} (t • e • c) 15:08, 9 March 2014 (UTC)

Thanks, everyone. And it's back to normal now. Peridon (talk) 18:17, 9 March 2014 (UTC)

  • Pretty much. Please do check out Template:Admin dashboard and read the documentation. I've added some options to be able to have sections not transclude if inactive for a shorter period of time than normal archiving allows or disable sections all together. Please let me know if you want me to add more customizability in other sections and I would be happy to. For example, if you never bother with PERM requests, you can get rid of that section, or if you only want to see if there has been activity in the last 3 days for "Template Editor" requests, you can set that section to 3 days. I'm now realizing I need to tweak the code a hair more, as right now it is set that showperm overrides the specific parameters, but showperm is hard defined in the template (which calls the sub-template) so the individual ones won't currently work... Fixing now. — {{U|Technical 13}} (t • e • c) 19:37, 9 March 2014 (UTC)
Err, RfA seems to have gone, and the admin counts too. Peridon (talk) 21:06, 9 March 2014 (UTC)
  • I'm still working on trimming various parts... Everything will be back by default (unless you opt-out of sections) when I'm done. No worries.. I just trimmed about 230 bytes from rfp links... More to come... I agree that the current archiving on some of the RFP pages is too slow. The major one seems to be Wikipedia:Requests for permissions/Confirmed. Archival after three days there would seem appropriate and take a HUGE chunk out of the inclusion size. I don't see a archival bot template on the page, so I'm assuming we need to ping the bot's operator to make a hardcoded change someplace? — {{U|Technical 13}} (t • e • c) 22:27, 9 March 2014 (UTC)
Archiving on Wikipedia:Requests for permissions/Confirmed appears to be performed manually. This appears to be the case on multiple pages in the Wikipedia:Requests for permissions hierarchy. Most recently, @Armbrust: appears to be the one that does it.
It appears that upon archiving, the requests are split into different pages based on if they are approved or denied. Those archive pages are further named based on the month and year and put under the Wikipedia:Requests for permissions page. While ClueBot III could, probably, be configured to split the archiving based on approval status, doing so would require using two instances of the bot template each with different values for |archivenow=, |archiveprefix= and |key=. Such configuration would not allow the dwell time on the page after approval/denial to be specified. The bot would just archive any with the specified text (e.g. {{Already done}}, {{done}} and {{not done}}) the next time it ran on the page. This is probably preferable to someone having to manually archive on a continuous basis. Because the archives would not be under the originating page, a |key= would need to be generated prior to enabling the archiving or the bot will put the archives in its default location ({{FULLPAGENAME}}/Archives/). — Makyen (talk) 23:46, 9 March 2014 (UTC)
User:KingpinBot used to archive the Confirmed page. GB fan 00:44, 10 March 2014 (UTC)

Talk page

Can someone fix my talk page? Whenever I check it, it comes up almost blank. I think it has something to do with the templates on it. I also need to archive it, but that is another matter entirely. :) ~EDDY (talk/contribs)~ 18:26, 9 March 2014 (UTC)

It looks normal to me. Can you post a screenshot of what the problem is? Jackmcbarn (talk) 18:55, 9 March 2014 (UTC)
The section "The Signpost: 01 October 2012", which is the only one prior to Articles you might like to edit, from SuggestBot was hidden behind all those boxes at the top. You could just see some of the text peeping through the gaps between; some of it was concealing part of the TOC as well. I fixed it by removing two </div>, which suggests that User:Editorofthewiki/Navigation and User talk:Editorofthewiki/Header might contain some malformed HTML. --Redrose64 (talk) 20:06, 9 March 2014 (UTC)
You fixed the problem, thank you. ~EDDY (talk/contribs)~ 00:45, 10 March 2014 (UTC)

Template transclusion counter

The transclusion counter at http://toolserver.org/~jarry/templatecount/index.php?lang=en&name=Boys_Night_Out&namespace=10 seems to be out of service. --Jax 0677 (talk) 18:42, 9 March 2014 (UTC)

Yeah, well, it is on Toolserver. Have you informed Jarry1250 (talk · contribs)? --Redrose64 (talk) 20:12, 9 March 2014 (UTC)
Seems to be working now. I'll have to migrate it shortly, I guess ([28]). - Jarry1250 [Vacation needed] 23:13, 9 March 2014 (UTC)
Reply - Now https://toolserver.org/~dispenser/cgi-bin/rdcheck.py/Template:Collapsible_option is not working to check for redirects to Template:Collapsible_option. --Jax 0677 (talk) 07:30, 10 March 2014 (UTC)

First-time sort-click problem in table

In the table at Malaysia Airlines Flight 370#Passengers and crew, when clicking on the sorting button for the "Nationality" column for the first time, nothing happens because the nationalities are already listed in alphabetical order by default. Is it possible to make it so that it instead sorts in reverse alphabetical order the first time you click on the sorting button? Heymid (contribs) 19:09, 9 March 2014 (UTC)

@Heymid: Nope. Bug 15403 is a request for that feature. Matma Rex talk 19:50, 9 March 2014 (UTC)

AFC -> Wikidata

The AFC tool could be used to start Wikidata entries. Please see Wikipedia talk:WikiProject Articles for creation/2014 6#Wikidata for more. Help from a coder would be appreciated. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:41, 9 March 2014 (UTC)

transcluded_changes tool

I have started getting Error 404 reported when trying to run transcluded_changes.py. The url I have been using is https://toolserver.org/~dispenser/cgi-bin/transcluded_changes.py?page=Template:WikiProject_Caves. Has the tool moved or been withdraw? Thanks. Langcliffe (talk) 22:12, 9 March 2014 (UTC)

Panic over - it's come back. Langcliffe (talk) 13:01, 10 March 2014 (UTC)

Tech News: 2014-11

Latest tech news from the Wikimedia technical community. Please inform other users about these changes. Not all changes will affect you. Translations are available.

Recent software changes

  • The latest version of MediaWiki (1.23wmf17) was added to test wikis and MediaWiki.org on March 6. It will be added to non-Wikipedia wikis on March 11, and all Wikipedia wikis on March 13 (calendar).
  • You can now use the new search tool (CirrusSearch) on all Wikiquote projects. You can now enable it in your Beta options. [29] [30]

VisualEditor news

  • It is now easier to edit templates. Complex tools are now in the "advanced" mode. [31] [32]
  • It is also easier to edit images. You now have more options and they are explained better. [33]
  • VisualEditor adds fake blank lines so you can put your cursor there. They are now smaller and animated to be different from actual blank lines. [34]
  • We have improved the tool to add special characters. The buttons are now larger. More changes are coming. [35]
  • You can now use new keyboard shortcuts to undo the last action, clear formatting, and show the shortcut help window. [36] [37] [38]

Future software changes

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

09:10, 10 March 2014 (UTC)

I've been trying to get onto Reflinks but every time, whether I use the link on WP or the direct web address, it comes up with a 502 bad gateway error message. What is wrong? The C of E God Save the Queen! (talk) 09:43, 10 March 2014 (UTC)

Its something at their end, not yours. Its going to be a sit and wait job. - X201 (talk) 09:48, 10 March 2014 (UTC)

Project page not transcluding large template properly

Hi all, I am trying to add User:Mr.Z-man's excellent new "Popular pages" list to the WikiProject Palestine front page, but I can't get it to work. As soon as I swap it in the page doesn't work any more.

Perhaps because the list is too big? Just wondering if you have any idea how I can fix it. I didn't realise there was a limit on these things.

Oncenawhile (talk) 10:41, 10 March 2014 (UTC)

Yes, Wikipedia:WikiProject Palestine/Popular pages is too large. Due to 1500 transclusions of {{class}} and {{importance}} it couldn't even render to the end on its own page so it was in Category:Pages where template include size is exceeded. As a test I have replaced its source by the result of using Special:ExpandTemplates on that source. It can now display fully at Wikipedia:WikiProject Palestine/Popular pages, but it can still not be transcluded at Wikipedia:WikiProject Palestine when it's passed as a parameter to a template there. Template include size grows when content is passed around. Wikipedia:WikiProject Lebanon/Popular pages and Wikipedia:WikiProject Syria/Popular pages have the same problem and fail on their own page. PrimeHunter (talk) 13:08, 10 March 2014 (UTC)

Maintenance category for articles with circular references?

As per WP:CIRCULAR, Wikipedia should never be used to cite itself. Is it technically possible to have a maintenance category populated with articles that have circular references? This seems like a good idea. It would be populated with articles that contain references like

<ref>{{cite web|url=https://wiki.riteme.site/wiki/Sepultura}}</ref>

or

<ref>https://wiki.riteme.site/wiki/Fluffernutter</ref>

or

<ref>[[Dragonslayer]]</ref>

among other possible scenarios. There is a inline template about circular references (see {{Circular-ref}} but I don't see its point and just started a conversation on its talk page about that. Jason Quinn (talk) 03:49, 11 March 2014 (UTC)

I suggest asking at Module_talk:Citation/CS1. —TheDJ (talk • contribs) 11:10, 11 March 2014 (UTC)
I was going to suggest the same. We can add Wikipedia link detection to CS1 templates. I can't see any way to detect such a link in <ref> tags not using a template unless Cite is changed. --  Gadget850 talk 12:35, 11 March 2014 (UTC)
Do note there are rare cases where a citation to Wikipedia is appropriate, for example reference #6 in Deletionism and inclusionism in Wikipedia. I'd expect you can find more examples looking through Category:Wikipedia and its subcats. Anomie⚔ 14:21, 11 March 2014 (UTC)
Also, most refs contain wikilinks along with other text. Differentiating <ref>Source: Wikipedia article on [[Dragonslayer]].</ref> from an explanatory footnote or a citation to a real source that happens to link to an article is basically impossible. WhatamIdoing (talk) 17:05, 11 March 2014 (UTC)
This is true, which is why such a category could only contain candidates for improvement, which is the case with basically all the maintenance categories. (As a side note, I've started to really dislike explanatory footnotes mixed in with actual references and have started to prefer them in seperated into their own named group, especially when there's a large number of references.) Jason Quinn (talk) 18:07, 11 March 2014 (UTC)

Flcikr/creative commons photo SOLVED

Hello, I would like to get this photo:http://www.flickr.com/photos/idfonline/12966001753/in/set-72157641943868053 into the infobox on this page KLOS C. The photo has creativecommons permissions, as I have seen often used here on Wikipedia via Flickr but I am unclear on how to move a photo from there. Any help would be greatly appreciated. Juneau Mike (talk) 17:18, 11 March 2014 (UTC)

I am sorry to say it, but as per Wikipedia:Non-free content criteria the image in question is not usable on Wikipedia. The issue is that the image in question is available under a CC-BY-NC license. Creative Commons licenses are not all alike. The one used for this image does not allow for commercial reuse. The restriction on commercial reuse makes the image non-free from a Wikipedia perspective and, as it is (theoretically) possible for someone else to take a picture of this ship, Wikipedia:Non-free content criteria#Policy does not allow the image to be uploaded under a fair use provision. --Allen3 talk 18:13, 11 March 2014 (UTC)

Issue finding simple change in large blocks

A single character change in a large block of text such as this diff can often be tedious to locate. In this case a comma was removed after "waxy" in a 2,700 character paragraph. Is there a way of making such a change more visible? I do a large amount of RCP and often quit in exasperation attempting to find such changes. Thank you Jim1138 (talk) 20:54, 11 March 2014 (UTC)

The use of the wikEdDiff gadget can make finding this type of change much easier. A button is added below the normal diff view. When clicked, the diff is displayed in an additional, alternate style which makes finding such changes much easier. You can enable the gadget from the gadget page in your preferences. At least for me, the use of this gadget makes the change in the diff you mentioned immediately visible. — Makyen (talk) 21:29, 11 March 2014 (UTC)
I added the following to my user css a long time ago to make the difference more obvious:
td.diff-deletedline .diffchange,
td.diff-addedline .diffchange {
    /* Maybe my display contrast is bad, but I can hardly see the highlight. */
    background:#f88;
}
You could copy it into your common.css if you want. Anomie⚔ 23:34, 11 March 2014 (UTC)
Should I add it to the WP:RCP page? I would think this useful to others as well. Jim1138 (talk) 01:27, 12 March 2014 (UTC)

Internal Server Error

I have been consistently getting a Internal Server Error when trying to use count lately. Anyone else? What can be done about it? Thanks in advance, XOttawahitech (talk) 15:25, 3 March 2014 (UTC)

This is referring to pcount, one of X!'s tools. @Cyberpower678: can you fix it? πr2 (t • c) 16:54, 3 March 2014 (UTC)
Everytime I look. It works for me.—cyberpower ChatAbsent 20:35, 3 March 2014 (UTC)
Doesn't work for me either - and edit creator tool still won't load. GiantSnowman 20:39, 3 March 2014 (UTC)
It seems to go back and forth for me. One moment it works, then it serves me a 500 Internal Server Error again. Sometimes it works again within a minute or two, other times it takes a while before it starts working again. Currently working for me, but wasn't approx. 20 minutes ago. Since the past few days (26th or 27th of February, I think), I've been getting "500 - Internal Server Error" approximately 20-25% of the times I attempted to use it, not counting the refreshes within a few minutes that also led to the same error. Sometimes, they're all pretty close in a row, where the tool pretty much alternates between "error" and "working" for an hour or two (in one case, it served me an error, worked again two minutes later and served me an error again another minute later). Other times, it works fairly well for most of an editing session (2-4 hours, usually), with just one or two errors in between. AddWittyNameHere (talk) 21:07, 3 March 2014 (UTC)
And now it's giving me the following error:
click "show" for the full error
Warning: mysql_connect(): Can't connect to MySQL server on 'enwiki.labsdb' (4) in /data/project/xtools/public_html/counter_commons/Database.php on line 62 Warning: mysql_select_db() expects parameter 2 to be resource, boolean given in /data/project/xtools/public_html/counter_commons/Database.php on line 63 Warning: mysql_real_escape_string() expects parameter 2 to be resource, boolean given in /data/project/xtools/public_html/counter_commons/Database.php on line 117 Warning: mysql_query() expects parameter 2 to be resource, boolean given in /data/project/xtools/public_html/counter_commons/Database.php on line 83 Warning: mysql_errno() expects parameter 1 to be resource, boolean given in /data/project/xtools/public_html/counter_commons/Database.php on line 85 Warning: mysql_error() expects parameter 1 to be resource, boolean given in /data/project/xtools/public_html/counter_commons/Database.php on line 100 Warning: mysql_fetch_assoc() expects parameter 1 to be resource, boolean given in /data/project/xtools/public_html/counter_commons/Database.php on line 129 Warning: mysql_real_escape_string() expects parameter 2 to be resource, boolean given in /data/project/xtools/public_html/counter_commons/Database.php on line 117 Warning: mysql_query() expects parameter 2 to be resource, boolean given in /data/project/xtools/public_html/counter_commons/Database.php on line 83 Warning: mysql_errno() expects parameter 1 to be resource, boolean given in /data/project/xtools/public_html/counter_commons/Database.php on line 85 Warning: mysql_error() expects parameter 1 to be resource, boolean given in /data/project/xtools/public_html/counter_commons/Database.php on line 100 Warning: mysql_fetch_assoc() expects parameter 1 to be resource, boolean given in /data/project/xtools/public_html/counter_commons/Database.php on line 129 Notice: Undefined offset: 0 in /data/project/xtools/public_html/pcount/counter.php on line 104 Warning: mysql_real_escape_string() expects parameter 2 to be resource, boolean given in /data/project/xtools/public_html/counter_commons/Database.php on line 117 Warning: mysql_query() expects parameter 2 to be resource, boolean given in /data/project/xtools/public_html/counter_commons/Database.php on line 83 Warning: mysql_errno() expects parameter 1 to be resource, boolean given in /data/project/xtools/public_html/counter_commons/Database.php on line 85 Warning: mysql_error() expects parameter 1 to be resource, boolean given in /data/project/xtools/public_html/counter_commons/Database.php on line 100 Warning: mysql_fetch_assoc() expects parameter 1 to be resource, boolean given in /data/project/xtools/public_html/counter_commons/Database.php on line 129 Notice: Undefined offset: 0 in /data/project/xtools/public_html/pcount/counter.php on line 119 Warning: mysql_real_escape_string() expects parameter 2 to be resource, boolean given in /data/project/xtools/public_html/counter_commons/Database.php on line 117 Warning: mysql_query() expects parameter 2 to be resource, boolean given in /data/project/xtools/public_html/counter_commons/Database.php on line 83 Warning: mysql_errno() expects parameter 1 to be resource, boolean given in /data/project/xtools/public_html/counter_commons/Database.php on line 85 Warning: mysql_error() expects parameter 1 to be resource, boolean given in /data/project/xtools/public_html/counter_commons/Database.php on line 100 Warning: mysql_fetch_assoc() expects parameter 1 to be resource, boolean given in /data/project/xtools/public_html/pcount/counter.php on line 198

and tried to tell me AddWittyNameHere does not exist. Existential crisis here! I apparently do not exist! AddWittyNameHere (talk) 22:42, 3 March 2014 (UTC)

If this is still an issue, the best place to bring this up might be https://lists.wikimedia.org/mailman/listinfo/labs-l --AKlapper (WMF) (talk) 12:04, 4 March 2014 (UTC)
Will do if it starts doing so again. Right now, it works. AddWittyNameHere (talk) 14:20, 4 March 2014 (UTC)

Unfortunately, I don't see what is being mentioned here, making it impossible for me to look into.—cyberpower ChatAbsent 16:37, 4 March 2014 (UTC)

It has already been resolved. You might grep the #wikimedia-labs logs from yesterday for "labsdb" if you want more info. πr2 (t • c) 17:38, 4 March 2014 (UTC)
Not resolved for me. It's been on and off, but mostly off, since I first posted. XOttawahitech (talk) 13:37, 8 March 2014 (UTC)

Not resolved for me, not sure about others. It's been on and off, but mostly off, since I first posted on 3 March 2014. XOttawahitech (talk) 19:22, 12 March 2014 (UTC)

What sorcery is this? Mischeviously broken file red links.

Someone's been messing with the code again; links such as File:New Jersey Dry Town Listing.pdf do not currently lead to a page where I can click to see the deletion history. This breaks things and needs to be fixed. --Elvey (talk) 00:30, 7 March 2014 (UTC)

I'm pretty sure that is how it has been for quite some time now and that is why I threw together User:Technical 13/Scripts/fileRedlinks.js which you can use by adding:
importScript( 'User:Technical 13/Scripts/fileRedlinks.js' );// [[User:Technical 13/Scripts/fileRedlinks]] makes image redlinks work like page redlinks.
to your common.js. — {{U|Technical 13}} (t • e • c) 00:46, 7 March 2014 (UTC)
Thanks for the reply, workaround and dupe fix. Any idea where the code sorcery that is responsible for this can be found? --Elvey (talk)
I think you're mistaken; things have gotten worse or are more complicated; see here - While File:New Jersey Dry Town Listing.pdf takes me to Wikipedia:File Upload Wizard, File:CBB-layout-problem.gif does take me to to a page where I can see the deletion history. WHY!?! Why is this deletion history being hidden from editors? --Elvey (talk) 01:03, 7 March 2014 (UTC)
This search indicates that this is a recurring problem that needs to be fixed! But it didn't help me find the code that is responsible for this. Please help me. I'd like to get a better handle on the thinking behind it before filing a bug over it.--Elvey (talk) 02:51, 7 March 2014 (UTC)
It's possible to bypass this bug: To view the deletion history of File:New Jersey Dry Town Listing.pdf, instead of clicking on the red link, paste the file name into the search box. Then, click on the red link (where it says "You may create the page "File:New Jersey Dry Town Listing.pdf", but consider checking the search results below to see whether the topic is already covered.") This works even if I am logged out. -- Diannaa (talk) 03:19, 7 March 2014 (UTC)
Per mw:Manual:$wgUploadMissingFileUrl, if http://noc.wikimedia.org/conf/highlight.php?file=InitialiseSettings.php under 'wgUploadMissingFileUrl' added 'enwiki' => '//wiki.riteme.site/wiki/Special:Upload' then I think File:New Jersey Dry Town Listing.pdf would go to [44] instead of [45]. So the upload wizard would be replaced by the default upload form, and the latter displays the deletion log (and actually places the file name in the upload form). PrimeHunter (talk) 03:32, 7 March 2014 (UTC)
I use the script described at User:Equazcion/SkipFileWizard (without the "Option"). This means that if I click either of the file redlinks File:New Jersey Dry Town Listing.pdf or File:CBB-layout-problem.gif, they both behave the same: I get a page headed "Creating File:whatever", with two pink boxes: one beginning "Wikipedia does not have a File page with this exact title", the other beginning "A page with this title has previously been deleted", and the deletion log is in that second pink box. --Redrose64 (talk) 09:49, 7 March 2014 (UTC)
Redrose64@ Thanks but Technical 13 already provided a workaround, and that's NOT what's needed. This search indicates that this is a recurring problem that needs to be fixed! Thanks, PrimeHunter@! Wow, that file gets edited a lot. I have to look up Bug 42263 but have to run right now. --Elvey (talk) 03:30, 8 March 2014 (UTC)
We are discussing red file links which are controlled by mw:Manual:$wgUploadMissingFileUrl. mw:Manual:$wgUploadNavigationUrl controls where "Upload file" in the sidebar goes. PrimeHunter (talk) 21:25, 8 March 2014 (UTC)
It seems that T8909 was recreated when Special:Upload replaced Wikipedia:File_Upload_Wizard. I'm considering whether it's appropriate to simply reopen 6909, and I welcome guidance / suggestions someone taking other action. I guess the fix to that by @Raymond:, and/or Raymond himself could be of help here.--Elvey (talk) 02:10, 9 March 2014 (UTC)
Thanks for the ping :-) But sadly I cannot help to fix this bug in the UploadWizard. I like the UploadWizard but it is widly written in JavaScript which I do not like. Raymond (talk) 11:51, 9 March 2014 (UTC)
(Yeah, T44263 is tangential; I followed blame tools onto a wrong path to figuring this out.) --Elvey (talk) 23:52, 8 March 2014 (UTC)
What the …? This is no longer true! Yesterday, I wrote that "While File:New Jersey Dry Town Listing.pdf takes me to Wikipedia:File Upload Wizard, File:CBB-layout-problem.gif does take me to to a page where I can see the deletion history." but today, that's not true. Both take me to the upload wizard. WTF? (In the interim, I enabled and reverted the workaround; I suppose it's possible caching or memory problems are to blame.)--Elvey (talk) 23:52, 8 March 2014 (UTC)
Both have taken me to the upload wizard the whole time. Did you earlier click a link at Wikipedia talk:File Upload Wizard/Archive 3#Reader feedback: why is this a crummy upload ... with a colon in front like File:CBB-layout-problem.gif? That behaves differently. If the file exists then it goes to the file page instead of displaying the file, for example File:Example.jpg. PrimeHunter (talk) 01:11, 9 March 2014 (UTC)
Yes, I have noticed that the : in front produces the behavior more like what I think people want - like the fix to T8909 provided for a time. Not as I recall, but as I said, I suppose it's possible caching or memory problems are to blame. But perhaps the best solution is to revert the default to Special:Upload from Wikipedia:File_Upload_Wizard, as you suggested. There's a so much content that is policy compliant but can't be uploaded properly with the wizard. It's more hindrance than help in my experience. Wonder if there were any metrics compiled pre vs post rollout to evidence a net positive impact of the change.--Elvey (talk) 02:27, 9 March 2014 (UTC)
@PrimeHunter: So someone needs to submit a patch to take advantage of this ehancement which allows us to set the default to Special:Upload for redlinks, instead of inheriting the default from $wgUploadNavigationUrl, as you suggested, for review? I guess that's the next step. I see the discussions here and here indicate consensus that Special:Upload is where red links should go. I'm willing to figure out how to do it. --Elvey (talk) 19:04, 10 March 2014 (UTC)

Discrepancy in page size calculation

I've just noticed that this edit by John of Reading (talk · contribs) shows as (-12) in the watchlist, but (-13) in the page history and the user's contribs. What might cause this discrepancy? --Redrose64 (talk) 11:35, 9 March 2014 (UTC) amended Redrose64 (talk) 13:29, 9 March 2014 (UTC)

Hmm. I reproduced the discrepancy. No idea. But at least it's not you.
Ah, wait. May or may not be relevant, but watchlists use different schemes:
Could that be it, maybe? The &curid=21438123 piece? I'm just guessing here... meteor_sandwich_yum (talk) 12:11, 9 March 2014 (UTC)
Totally different possibility: The carriage return in the second edit John of Reading reverted: [46]
Maybe it's a heuristical calculation? I mean, WikiMarkup treats two ↵ Enter strokes as a line break (2 bytes), but if it was stored in UTF-8 maybe it was progammed in as the single &#13; character (1 byte)? meteor_sandwich_yum (talk) 12:21, 9 March 2014 (UTC)
I just thought to check the user contribs: it tallies with page history. A visual check of the edit shows that 11 visible characters were removed: "<ref me h" is nine, and "me" is two. The newline that was also removed should count as one, since MediaWiki stores newlines using the UNIX convention of a 0x0A linefeed, no carriage return. A hex dump of the previous version 
1FD0  65 72 65 64 2E 0A 0A 3C-72 65 66 20 6D 65 20 68   ered...<ref me h
1FE0  0A 3D 3D 3D 41 72 74 69-63 6C 65 20 74 61 6C 6B   .===Article talk
1FF0  3D 3D 3D 0A 2A 6D 65 20-7B 7B 74 6C 7C 74 6D 66   ===.*me {{tl|tmf
2000  72 6F 6D 7D 7D 2C 20 7B-7B 74 6C 7C 74 6D 74 6F   rom}}, {{tl|tmto
2010  7D 7D 0A 0A 3D 3D 3D 55-73 65 72 20 74 61 6C 6B   }}..===User talk
reveals no control characters other than the linefeeds. So my impression is that the watchlist is correct in showing a reduction of 12 bytes, but the history and contribs are wrong. --Redrose64 (talk) 13:29, 9 March 2014 (UTC)
@Redrose64: Don't mean to be a bother, but how do you do a hex dump? Can anybody, or does it require special privileges? meteor_sandwich_yum (talk) 07:31, 11 March 2014 (UTC)
I have Windows XP and do a lot of work through the command prompt (because I go way back to MS-DOS 3.3 which worked all the time unlike some modern software). I used debug to get the actual hex dump, but first the data needs to be obtained and prepared.
Extended content
I obtained the raw source of the previous and current revisions of the page using 
wget "http://wiki.riteme.site/w/index.php?action=raw&ctype=text/plain&title=Wikipedia:Substitution&oldid=598811368"
wget "http://wiki.riteme.site/w/index.php?action=raw&ctype=text/plain&title=Wikipedia:Substitution&oldid=598811544"
wget is a utility for retrieving web pages without letting your browser loose on them. action=raw&ctype=text/plain tells MediaWiki that you want the actual Wikitext, not the rendered HTML. I renamed the retrieved pages using 
ren "index.php@action=raw&ctype=text%2Fplain&title=Wikipedia%3ASubstitution&oldid=598811368" wps_prev.txt
ren "index.php@action=raw&ctype=text%2Fplain&title=Wikipedia%3ASubstitution&oldid=598811544" wps_cur.txt
to make their names less unwieldy, and because debug expects filenames to be in the old 8.3 format. Next we need to locate the first byte that differs: 
fc /b wps_prev.txt wps_cur.txt | head -n 1
head is a UNIX utility that can be obtained for MS-DOS. The line returned from that is 00001ED7: 3C 3D so the discrepancy begins at offset 0x1ED7. However, debug expects that the file being loaded is a COM file, where the entry point is always CS:0100 - so it loads it there, thus all of the byte offsets (including those that I gave on 9 March) are reported 0x0100 higher than their real positions. We therefore need to inspect beginning at CS:1FD7, but for convenience I always start on a 16-byte boundary - easily produced by altering the last digit to zero: 
debug wps_prev.txt
d1FD0
q
debug wps_cur.txt
d1FD0
q
The d command dumps 128 bytes beginning at an offset; the q command exits the program. This should now show 
C:\wikipedia>debug wps_prev.txt
-d1FD0
14F5:1FD0  65 72 65 64 2E 0A 0A 3C-72 65 66 20 6D 65 20 68   ered...<ref me h
14F5:1FE0  0A 3D 3D 3D 41 72 74 69-63 6C 65 20 74 61 6C 6B   .===Article talk
14F5:1FF0  3D 3D 3D 0A 2A 6D 65 20-7B 7B 74 6C 7C 74 6D 66   ===.*me {{tl|tmf
14F5:2000  72 6F 6D 7D 7D 2C 20 7B-7B 74 6C 7C 74 6D 74 6F   rom}}, {{tl|tmto
14F5:2010  7D 7D 0A 0A 3D 3D 3D 55-73 65 72 20 74 61 6C 6B   }}..===User talk
14F5:2020  20 6E 61 6D 65 73 70 61-63 65 3D 3D 3D 0A 41 6C    namespace===.Al
14F5:2030  6C 20 6F 66 20 74 68 65-20 74 65 6D 70 6C 61 74   l of the templat
14F5:2040  65 73 20 6C 69 73 74 65-64 20 69 6E 20 5B 5B 3A   es listed in [[:
-q

C:\wikipedia>debug wps_cur.txt
-d1FD0
14F5:1FD0  65 72 65 64 2E 0A 0A 3D-3D 3D 41 72 74 69 63 6C   ered...===Articl
14F5:1FE0  65 20 74 61 6C 6B 3D 3D-3D 0A 2A 20 7B 7B 74 6C   e talk===.* {{tl
14F5:1FF0  7C 74 6D 66 72 6F 6D 7D-7D 2C 20 7B 7B 74 6C 7C   |tmfrom}}, {{tl|
14F5:2000  74 6D 74 6F 7D 7D 0A 0A-3D 3D 3D 55 73 65 72 20   tmto}}..===User
14F5:2010  74 61 6C 6B 20 6E 61 6D-65 73 70 61 63 65 3D 3D   talk namespace==
14F5:2020  3D 0A 41 6C 6C 20 6F 66-20 74 68 65 20 74 65 6D   =.All of the tem
14F5:2030  70 6C 61 74 65 73 20 6C-69 73 74 65 64 20 69 6E   plates listed in
14F5:2040  20 5B 5B 3A 43 61 74 65-67 6F 72 79 3A 55 73 65    [[:Category:Use
-q
I just trimmed that down a bit. --Redrose64 (talk) 09:33, 11 March 2014 (UTC)
Wow. Thanks! That's really cool!
Can. only. speak. in. mon. o. syl. la. bles. Too. amazed. This. thread. awesome. Meteor sandwich yum (talk) 00:06, 14 March 2014 (UTC)
I mean, VPT is. And Wikipedia. It's like I finally found a place where people know as much as, (dare I say more?) than me. Meteor sandwich yum (talk) 00:09, 14 March 2014 (UTC)

Can't display web page after clicking 'Save page'

It's happening over and over to me that I create or answer a proposal and as soon as I click 'Save page', the Internet Explorer 9 browser can't display the web page and I would like that problem fixed. After that problem, I then have to click 'Read' then click 'Leave page' to see my proposal. That problem doen't seem to be happening much in articles or talk pages. My proposals don't get lost from losing an internet connection but I still don't like it. Blackbombchu (talk) 02:53, 11 March 2014 (UTC)

What do you mean by "proposal" exactly? Asking as it's unclear to me how to reproduce the problem. --AKlapper (WMF) (talk) 08:57, 11 March 2014 (UTC)
It seemed to me that most of the time if I made any edit at all in the 'Proposals' section, it would not display the web page after I clicked 'Save page.' That problem did not happen to me when I made another proposal today. Maybe you have a better internet server or internet browser that makes you unable to reproduce the problem I was experiencing a lot. If you're not using wireless, you could try unplugging the internet cord while you're on the edit page then click 'Save page.' Blackbombchu (talk) 20:27, 11 March 2014 (UTC)
"Maybe you have a better ... internet browser" Almost assuredly. Please try something like Firefox or Chrome. --Golbez (talk) 17:36, 12 March 2014 (UTC)

Unresolved bot requests

Two of my recent requests (Infoboxes not using parent template, Remove link tracking) at WP:BOTREQ (I'll post a pointer to this discussion there) have recently been archived: the former unanswered, the latter after someone said they'd do the work, then pulled out. I've had each of these happen previously. (aside Wikipedia:Bots/Requests for approval/Theo's Little Bot 25 is still waiting, months after an RfC approved the work).

I appreciate that bot operators are volunteers, and am grateful for what they do do, but what can we do to increase the takeup rate? Should we keep a list of such requests, separate from the archives (which also include declined and satisfied requests), so that new or returning operators can more easily find them? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:52, 12 March 2014 (UTC)

Part of it is the sub-glacial speed at which the Bot Approval Group responds to requests (even ones that are deliberatly designed to flag down their attention). The other half is Bot Operators that are either embroiled in issues or not interested in doing the work. You could always try to develop the functionality on your own... Hasteur (talk) 19:49, 12 March 2014 (UTC)
Infoboxes not using parent template looks to me like you need a database dump, Remove link tracking needs someone with AWB access and a bot flag - no database dump needed as AWB will just skip the ones with no changes, Wikipedia:Bots/Requests for approval/Theo's Little Bot 25 fails WP:COSMETICBOT I believe, which never seemed to be brought up in the RfC - I would hold a new discussion and see if there is still consensus as that RfC is over a year old and no-one thought to disclose that the task was against an established policy, which kind of renders the RfC invalid in my opinion. — {{U|Technical 13}} (t • e • c) 20:00, 12 March 2014 (UTC)
Remember that with Toolserver on the point of collapse, any bot operator who still has their bots operating there and not on Labs will be busy ensuring that it will work once it has been ported across, and so will have little time for new bot tasks. --Redrose64 (talk) 20:17, 12 March 2014 (UTC)
Perhaps there should be a prominent and semi-permanent header at BOTREQ, explaining that issue? care to address the question I asked? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:05, 13 March 2014 (UTC)
As I said, Theo's Little Bot 25 was an aside; but the edits are not merely cosmetic, as has been discussed. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:05, 13 March 2014 (UTC)

Placing userboxes into a scroll box

Hey! I want to place some userboxes into a scroll box with a title in each scroll box on my userpage, however I don't know how. Also I want another scroll box to be right beside it so it could be parallel to each other. Any suggestions? --///EuroCarGT 18:37, 12 March 2014 (UTC)

@Technical 13: Yeah, but with a title header on each scroll box, and multiple scroll boxes beside each other. --///EuroCarGT 19:10, 12 March 2014 (UTC)
  • Just put them in a simple wikitable...
About me What I like What I've done

Boxes about you. Boxes about you. Boxes about you. Boxes about you. Boxes about you. Boxes about you. Boxes about you. Boxes about you. Boxes about you. Boxes about you. Boxes about you. Boxes about you. Boxes about you. Boxes about you. Boxes about you. Boxes about you. Boxes about you. Boxes about you. Boxes about you. Boxes about you.

Boxes about what you like. Boxes about what you like. Boxes about what you like. Boxes about what you like. Boxes about what you like. Boxes about what you like. Boxes about what you like. Boxes about what you like. Boxes about what you like. Boxes about what you like. Boxes about what you like. Boxes about what you like. Boxes about what you like. Boxes about what you like. Boxes about what you like. Boxes about what you like. Boxes about what you like. Boxes about what you like. Boxes about what you like. Boxes about what you like.

Boxes about what you've done. Boxes about what you've done. Boxes about what you've done. Boxes about what you've done. Boxes about what you've done. Boxes about what you've done. Boxes about what you've done. Boxes about what you've done. Boxes about what you've done. Boxes about what you've done. Boxes about what you've done. Boxes about what you've done. Boxes about what you've done. Boxes about what you've done. Boxes about what you've done. Boxes about what you've done. Boxes about what you've done. Boxes about what you've done. Boxes about what you've done. Boxes about what you've done.

like so... — {{U|Technical 13}} (t • e • c) 19:26, 12 March 2014 (UTC)
Cool! I should have known that from the start. Well thanks! ///EuroCarGT 19:34, 12 March 2014 (UTC)

Script problems with Chrome

Hi all - I use Google Chrome (latest version), and lately (perhaps a week or so) I've noticed that the Twinkle script and other gadgets sometimes fail to load. This also causes diffs and even simple editing and saving to fail. I thought it was a Twinkle issue, but I just checked the Chrome error log and this is what I see: Blocked script execution in 'https://wiki.riteme.site/wiki/Special:Watchlist' because the document's frame is sandboxed and the 'allow-scripts' permission is not set.. Any idea what could be causing this? Mozilla (latest) and IE 11 don't exhibit this issue at all. The only loosely related thing I found was this, but it seems to be related to apps within Google, and Wikipedia is not an app. I only have three extensions enabled (AdBlock, GoogleDocs and a tabs-related one) so I don't think that might be the issue. Also, it seems to be intermittent, not permanent. Any help or pointers will be greatly appreciated. §FreeRangeFrogcroak 03:47, 13 March 2014 (UTC)

" I only have three extensions enabled, so I don't think that might be the issue." That's like saying, "My car is responding strangely, I only put 3 spoilers on the car, so i don't think that might be an issue". :D —TheDJ (talk • contribs) 10:39, 13 March 2014 (UTC)
I think what TheDJ is trying to say; your issues are most certainly caused by AdBlock. It needs to be set to allow scripts from wikimedia.org to run. — Edokter (talk) — 11:23, 13 March 2014 (UTC)
Hi The DJ and Edokter - thanks but that doesn't seem to be the cause. First I disabled AdBlock on the Wikipedia domain, and nothing. Then I disabled the extension completely, and no joy. What I did notice though is that this seems to be related to the watchlist. The scripts fail to run only when I click on a link on my watchlist - if I copy the URL, close the tab, open a new tab and paste the URL, everything works perfectly. It's really weird :\ §FreeRangeFrogcroak 19:03, 13 March 2014 (UTC)

Proposed optional changes to Terms of Use amendment

Hello all, in response to some community comments in the discussion on the amendment to the Terms of Use on undisclosed paid editing, we have prepared two optional changes. Please read about these optional changes on Meta wiki and share your comments. If you can (and this is a non english project), please translate this announcement. Thanks! Slaporte (WMF) 21:55, 13 March 2014 (UTC)
Should this be under "proposals", "policy", or "miscellaneous"? Surely not technical. πr2 (t • c) 21:58, 13 March 2014 (UTC)

Javascript to warn you about various things when editing

When I edit a page, like I do now, it would be very nice to have a Javascript to show some warnings like:

  • This page contains the text "Text1"
  • This page does not contain the text "Text2"

And probably some other kind of warnings that editors might consider useful. Of course, the program should allow me to define "Text1", "Text2", etc, somewhere in it's preferences. For example, at this moment I am editing a lot of articoles for adding DEFAULTSORT. When I edit a page, I would like to know if it contains a certain template, which has to be removed - in case it exists in that page. It's a waste of time to try with CTRL + F on every page I edit, especially when I have to remove more than one template or text. I need the program to warn me about it automatically. Is it possible to create such a script? Or there might be some browser addons for that? Probably such a task it's doable with GreaseMonkey. —  Ark25  (talk) 19:35, 8 March 2014 (UTC)

You could use pt:WP:APC ("Automatic Page Corrector") to define a list of find/replace rules (e.g. finding a few templates and replacing them by the empty string), but that script doesn't have automatic warnings. Helder.wiki 18:24, 10 March 2014 (UTC)
I solved with a short GreaseMonkey script. Thanks anyways. —  Ark25  (talk) 18:06, 14 March 2014 (UTC)
Ark25, is the code publicly available? Helder.wiki 18:29, 14 March 2014 (UTC)
Helder.wiki - Yes, I saved it to User:Ark25/WikiSearch. I would be glad if it will be useful to anyone else than me. If you have any questions or if you need any improvements, ask me. —  Ark25  (talk) 04:13, 15 March 2014 (UTC)

CIDR range contributions broken?

Resolved
See also: MediaWiki talk:Gadget-contribsrange.js § Protected edit request on 28 February 2014

If I enter a range into Special:Contributions, it only finds a single result, and then stops. This is on both /16 and /24 ranges. Examples;

searching for 109.157.154.0/24 returns only 109.157.154.90; there are IPs with contributions scattered across that range (109.157.154.104, 109.157.154.114, etc.)
searching for 197.132.0.0/16 returns only 197.132.99.7 (there are many more that should be shown).

When this worked, it used to show the results in reverse "alphabetical" order (i.e. X.X.X.99, X.X.X.98, etc.) So it looks like its finding them all, but then only showing the "first" in its list. Tested in Firefox 27 & IE10, Windows 7. Black Kite (talk) 23:51, 10 March 2014 (UTC)

  • Note:Can someone have a look at this or should I enter it as a bug? It's quite a major issue for admins who are looking at possible collateral damage when considering a rangeblock. Black Kite (talk) 20:41, 11 March 2014 (UTC)
  • I'll look at this after I get out of class... This is actually a gadget, so it will need to be handled on wiki and the developers would WONTFIX any Bugzilla report for a gadget. — {{U|Technical 13}} (t • e • c) 21:04, 11 March 2014 (UTC)

Preferences on Windows 8.1

Firefox 27.0.1, Windows 8.1 Modern skin I am transitioning from Windows XP. Much WP Preferences that I take for granted on XP are non-existant on 8.1, Request Page Protection is gone, Purge the page is gone, my little tab to fix dashes with a script, etc. And, in fact, the only thing that appears at the top of the article is "Article", "Talk, "Edit This Page", "History", "Move" and "Unwatch" Even more inconvenient on my own main user page, there is no longer the User tab with the drop down menu to tell me where my subpages are, the sandboxes, the .js pages, the .css pages. I suspect my scripts are gone, because I have nothing extra in "Tools" In the search bar, I no longer get a pop suggestion when I type in an article name. Inconvenient. Any solutions? — Maile (talk) 17:20, 12 March 2014 (UTC)

At #Discrepancy in page size calculation above, there should be a box headed "Extended content". Is that box collapsed into a single line, or not? If it is collapsed, is there a "[show]" link at the right-hand end? --Redrose64 (talk) 17:35, 12 March 2014 (UTC)
I see the box with a green top on the box, but it displays as one continuous text, not a collapsible box. And perhaps related is that if I go into my Preferences, they no longer show as tabbed choices. It's one long page. Another thing is that I cannot use HotCat or WikiEd. I have no toolbar in the Edit window. — Maile (talk) 17:54, 12 March 2014 (UTC)

Proposed change to portal image module system

I've proposed a change to the way we structure the system of portal images for the {{portal}} template over at Template talk:Portal#New image database proposal. Please comment there if you are interested. — Mr. Stradivarius ♪ talk ♪ 03:39, 14 March 2014 (UTC)

Email

I've recently changed my email address. But as of yet it hasn't confirmed it. It says its sent me a confirmation email and I've received nothing.♦ Dr. Blofeld 07:57, 14 March 2014 (UTC)

You're right @Dr. Blofeld:. When I enter your username on Special:EmailUser and try to e-mail you, it says "This user has not specified a valid email address." -TheGeneralUser (talk) 13:00, 14 March 2014 (UTC)
Can an administrator validate it manually for me?♦ Dr. Blofeld 13:10, 14 March 2014 (UTC)
Admins don't have that ability. And if the confirmation mail doesn't arrive then there is probably a big risk other mails wouldn't arrive either. Does Help:Email confirmation#Known issues help? PrimeHunter (talk) 13:32, 14 March 2014 (UTC)

Looking for Google Summer of Code candidates

We are looking for students willing to work on Wikimedia technical projects in the context of Google Summer of Code. There is still time to become a strong GSoC candidate for Wikimedia (but no much, the deadline for submissions is March 21). See mw:Google Summer of Code 2014 and this post. Your help spreading this call is welcome: Facebook, Twitter i Google+. Thank you.--Qgil (talk) 05:45, 15 March 2014 (UTC)

{Main cat only}

I have created {{Main cat only}}. Used in a template, it categorises the article (mainspace), but in other spaces just gives feedback text, using the colon [[:Category:...]]. A major advantage is that, when the hosting template tests OK, no code change is needed (no removal of |demospace=main or the draft colon). This by simple template code. It is also named {{Article cat only}} by redirect, which may be more inviting for draft editors.

One issue arises. When the template expands into feedback text, that can happen in an infobox (as maintenance categorization goes). That will disrupt the box layout & structure. Is there a possibility to present the feedback text otherwise? (css title text? Wikitext near bottom of page?). Except for the obvious edits, pls use the sandbox. -DePiep (talk) 14:05, 13 March 2014 (UTC)

Isn't that redundant to {{category handler}} and/or {{main other}}? Jackmcbarn (talk) 15:30, 13 March 2014 (UTC)
I'm afraid I can't be any more clear than in the post and /doc. I'd repeat feedback and ease of use (especially for the template editor). -DePiep (talk) 18:46, 13 March 2014 (UTC)
Most of the namespace templates have been updated to use Module:Namespace detect. --  Gadget850 talk 21:55, 14 March 2014 (UTC)
More than ns detection, trivial by now, the point of the template is 1. how to categorize when in mainspace (smart & easy), and 2. what & how to report when not in main (smart & easy). -DePiep (talk) 21:33, 16 March 2014 (UTC)

Search issues (with search term "one-on-one")

Starting this afternoon (~1:30PM Eastern time, it's almost 8:30PM now), I haven't been able to use the Search function; instead, I just get this message: "An error has occurred while searching: HTTP request timed out." I'm using Firefox 27.0.1 on two different internet connections but the same device (I don't have access to anything else right now). Any ideas? Supernerd11 :D Firemind ^_^ Pokedex 00:24, 14 March 2014 (UTC)

What were you searching for? πr2 (t • c) 00:29, 14 March 2014 (UTC)
Going back and testing a lot of random search terms gives me the usual lists of results, except for "one-on-one", which still gives me the error. The others (Theros, Commander, and Deck were a few that I remember) work fine now. Supernerd11 :D Firemind ^_^ Pokedex 00:46, 14 March 2014 (UTC)
Freaky. I get the same error when searching for one-on-one. Searching for "frisbee" or "lincoln" or "one-trick-pony" or "one on one" (without quotation marks) works just fine. I also get the error when searching for one-on one but not "one-on" or "one-on-two". That is strange. (Also using Firefox 27, FWIW). – Jonesey95 (talk) 04:29, 14 March 2014 (UTC)
Strange, it works for me. I'm not sure if this is an operations issue or a search issue, but I'd guess search. Do either of these work for you: Lucene, Cirrus? If the issue persists, you may want to file a bug on bugzilla. πr2 (t • c) 04:50, 14 March 2014 (UTC)
The Lucene link gives me the error. The Cirrus one works. – Jonesey95 (talk) 05:07, 14 March 2014 (UTC)
I'm having the same search results as Jonesey95, I'll head on over to Bugzilla. Thanks for all the help. Supernerd11 :D Firemind ^_^ Pokedex 12:56, 14 March 2014 (UTC)
Could you please link to the Bugzilla ticket after you report it? Thanks. πr2 (t • c) 13:49, 14 March 2014 (UTC)
Alright, it's submitted. (Sorry about the delay, school was busy for most of today.)(Also, I'm not ignoring you, ^demon, I just figured I should report the exact bug anyway.) Supernerd11 :D Firemind ^_^ Pokedex 19:46, 14 March 2014 (UTC)
Hi! Sorry for the problems with the old search engine. This timeout has been happening from time to time (more frequently I believe) and there's not really any easy fixes for it. As it's been pointed out we're working on replacing MWSearch with Cirrus and the new search shouldn't have these problems. We're rolling it out as quickly as we can for many users--enabling it in your Beta Features preferences will let you opt-in on enwiki (we welcome the feedback!). Thanks for your patience as we try to move forward on this. ^demon[omg plz] 16:46, 14 March 2014 (UTC)

Another data point: I consistently found a similar problem when searching for "A-b testing" (no quotes). (I wanted A/B testing.) Message was "An error has occurred while searching: The search backend returned an error: ". Certes (talk) 01:31, 16 March 2014 (UTC)

Developer Log

Hello. Back in the early days of Wikipedia (before 2003) user right changes (including administrator promotions) and many other things were done by the developers. I wanted to know if it's still technically possible for a developer today to change user rights of an account, delete or protect pages, block other user from editing, change usernames, lock/unlock user accounts, etc. ? And even if that's possible, In the interest of transparency, is there any way to check and see all the developer actions that have ever been made on the English Wikipedia ? Thank you. -TheGeneralUser (talk) 12:21, 14 March 2014 (UTC)

It's still technically possible for sysadmins with certain access to perform admin actions. I do not know of any log for what you asked. If they really wanted, I guess they could just perform the actions on the database directly and hide their trail, but I would assume they would log it normally. πr2 (t • c) 13:52, 14 March 2014 (UTC)
I would say.. Read up on mr. Snowden. Sysadmins are what makes the modern world go round. They have direct access to the databases (handy, because you know, when they do crash, you might want to get them fixed) and thus can do pretty much anything they like. They all have been entrusted with that kind of access. Possibly there is some audit log of commands entered by sysadmins, something like that is not uncommon. But it's a bit like giving someone all the keys and hoping they won't use one of those keys to open up the door of the camera surveillance booth :D Anyway, the majority of our sysadmins are people who have been around for a very long time.
I presume the actual procedures are on a need to know basis, because knowing the procedures means knowing what to circumvent/delete if you have ill intent. What could be done is to partition the group with such amount of access even further, but that also creates a whole lot more of bureaucracy and limits the usefulness of those outside the group. Anyway, the amount of access this people have, makes public logs at the high level that you desire sort of impossible and at the very least expensive. —TheDJ (talk • contribs) 15:07, 14 March 2014 (UTC)
Yes, sysadmins (formerly called developers) can do all those things. No, there's no on-wiki way of seeing them. In general, they tend not to do any of those, instead leaving them for stewards or local admins. Jackmcbarn (talk) 15:51, 14 March 2014 (UTC)

Can anyone tell me if this template uses CSS?

I'm trying to clean up hacky code concerning a two-column numbered list.

On the page Pokémon#Films (permalink), I came across this code: 

{{col-begin}}
{{col-2}}
# ''[[Pokémon: The First Movie|Pokémon: The First Movie—Mewtwo Strikes Back]]'' (1998)
# ''[[Pokémon: The Movie 2000|Pokémon: The Movie 2000—The Power of One]]'' (1999)
# ''[[Pokémon 3: The Movie|Pokémon 3: The Movie—Spell of the Unown]]'' (2000)
# ''[[Pokémon 4Ever|Pokémon 4Ever—Celebi: Voice of the Forest]]'' (2001)
# ''[[Pokémon Heroes]]'' (2002)
# ''[[Pokémon: Jirachi Wish Maker]]'' (2003)
# ''[[Pokémon: Destiny Deoxys]]'' (2004)
# ''[[Pokémon: Lucario and the Mystery of Mew]]'' (2005){{col-2}}
<ol start="9">
<li>''[[Pokémon Ranger and the Temple of the Sea]]'' (2006)</li>
<li>''[[Pokémon: The Rise of Darkrai]]'' (2007)</li>
<li>''[[Pokémon: Giratina and the Sky Warrior]]'' (2008)</li>
<li>''[[Pokémon: Arceus and the Jewel of Life]]'' (2009)</li>
<li>''[[Pokémon: Zoroark: Master of Illusions]]'' (2010)</li>
<li>''[[Pokémon the Movie: Black—Victini and Reshiram and White—Victini and Zekrom|Pokémon the Movie: Black—Victini and Reshiram and <br> Pokémon the Movie: White—Victini and Zekrom]]'' (2011)</li>
<li>''[[Pokémon the Movie: Kyurem vs. the Sword of Justice]]'' (2012)</li>
<li>''[[Pokémon the Movie: Genesect and the Legend Awakened]]'' (2013)</li>
</ol>
{{col-2}}
{{col-end}}

Which is pretty messy. It begins with wikimarkup (hashes to stand for numbers), switches over to HTML <ol> and <li> elements, and throws in {{col-begin}}, {{col-2}}, and {{col-end}} into the mix!

An elegant solution would be to remove all HTML begin with {{div col}} and end with {{div col end}}. I did want to support CSS-incompatible browsers such as IE9 and former, so was considering Template:Multi-column numbered list(edit talk links history). Can anybody tell me if this uses CSS in a way that would prevent proper rendering of columns in old browsers? If this template works I might want to use it on pages where it might actually make a difference.

Open to suggestions or opinions. Meteor sandwich yum (talk) 06:09, 16 March 2014 (UTC)

It switches to HTML half-way through in order to restart the list numbering at 9 (instead of 1) when the second list is introduced, just after the second {{col-2}}. It's possible to amend this so that it's almost entirely Wiki markup with just a tiny amount (only one tag) of HTML. Consider the middle part - this could be altered to 
# ''[[Pokémon: Lucario and the Mystery of Mew]]'' (2005){{col-2}}
#<li value=9> ''[[Pokémon Ranger and the Temple of the Sea]]'' (2006)
# ''[[Pokémon: The Rise of Darkrai]]'' (2007)
The remaining lines would also be altered similarly - note that the <li value=> is only necessary on one of them. Finally remove the </ol>.
However, splitting like this has accessibility issues, so {{div col}}/{{div col end}} should definitely be the way to go. --Redrose64 (talk) 08:06, 16 March 2014 (UTC)
Noted. But does the template use CSS? I'm also wanting to be sure that 
{| valign="top"
|-
| valign="top" | <ul><ol start="{{{1|1}}}"  style="list-style-type:{{{lst|decimal}}}"><li>{{{2}}}</ol></ul>
| valign="top" | <ul><ol start="{{#expr:{{{1|1}}}+{{{3|1}}}}}"  style="list-style-type:{{{lst|decimal}}}">{{{4}}}</ol></ul>
{{#if:{{{5|}}}|{{!}} valign="top" {{!}} <ul><ol start="{{#expr:{{{1|1}}}+{{{3|1}}}+{{{5|1}}}}}"  style="list-style-type:{{{lst|decimal}}}">{{{6}}}</ol></ul>}}
|}
has nothing CSS3, only HTML. I suppose I should probably read up more on this. Meteor sandwich yum (talk) 08:41, 16 March 2014 (UTC)
  • Template:Autocol turns numbers off/on: For auto-numbered columns which display on any browser, and avoid CSS classes, the Template:Autocol (2012) can activate the numbers by setting "num=y" but also allows specifying several names per line in the markup.
{{autocol | n=9 |ncols=3 |num=y|wrap=y|colgap=7
|a |b |c |d |e |f
|g |h |i |}} 
{{autocol | n=9 |ncols=3 |num=y|wrap=y|colgap=7

|a |b |c |d |e |f

|g|h|i|}}

Again, a major advantage of {{autocol}} is specifying multiple entries on one line, such as several towns per line among dozens, and then auto-numbering them by "num=y" (and "wrap=y" to wrap each row) or else show them without numbers, if you change your mind later. Just insert more names anywhere, on the same lines, or insert a new line of names. -Wikid77 (talk) 09:09, 16 March 2014 (UTC)
Thanks, both of you. Meteor sandwich yum (talk) 09:22, 16 March 2014 (UTC)
Wherever a HTML tag uses the style= attribute, it always has CSS, because that is the sole purpose of style=. Wherever a HTML tag uses the class= attribute, it probably has CSS, but the class= attribute can also be used to create a label, for instance the COinS metadata emitted by e.g. {{cite book}} is labelled with class="Z3988". Wherever a HTML tag uses the id= attribute, which is primarily used to create a label, it might have CSS as well: for instance, the little red square which tells you that you have notifications is the element <li id="pt-notifications">...</li> and there is some CSS that is specific to that id=. These three attributes may be found on any HTML element that is permitted within the body of a HTML document, including on the <body> tag itself.
Anyway, regarding the list-style-type: CSS property. That goes right back to CSS 1, so is recognised by most versions of Chrome, Firefox, Opera, Safari also IE 4 and later. The permitted values have been enhanced in the meantime: see CSS 2, . Further enhancements are proposed for CSS 3 but that document is still at the Working Draft stage - it's not yet a W3C Recommendation, so some browsers may not yet support these features. --Redrose64 (talk) 09:31, 16 March 2014 (UTC)
That's just what I was looking for. Thank you for the clarification. I guess—not yet familiar with CSS (just HTML)—my post sounding confusing. I didn't realize that about class= attributes. And I see what you mean now! Thank you so much! Gives me a bunch of ideas on how to proceed. I think I'll stick with {{div col}}/{{div col end}} for this one. Meteor sandwich yum (talk) 22:59, 16 March 2014 (UTC)

Block log searching

Is there a way to search the block log, other than loading 500-page chunks and using Ctrl+F on each one? I'd like to find recent WP:NLT blocks without running "find" requests on each page of 500 blocks. In addition to that, is there a way to exclude one or more admins from the results? The recent log is full of blocks by User:ProcseeBot of open proxies; I'd like to look at the log without Procseebot results. Nyttend (talk) 17:35, 16 March 2014 (UTC)

You could load 5000-page chunks. Although it's not shown as a clickable option, the &limit= field allows any integer value between 1 and 5000. --Redrose64 (talk) 20:48, 16 March 2014 (UTC)

Inaccurate pending changes error message

Got "Internal error": "Cannot reject these changes because someone already accepted some (or all) of the edits." when rejecting a pending change that was reverted by someone else. Wording should be changed. Mark Schierbecker (talk) 21:33, 16 March 2014 (UTC)

The technical reason you're seeing that message is that they accepted a later edit (which happened to be their revert), so it's technically correct, if slightly confusing. Jackmcbarn (talk) 22:13, 16 March 2014 (UTC)
Good theory, Jackmcbarn, but no. I should have linked to the change. Said edit was on Axl Rose. Mark Schierbecker (talk) 22:21, 16 March 2014 (UTC)
No, that's what happened. Qwfp accepted his own edit, and the revert button doesn't work if an edit after the one you're trying to revert has already been accepted. Jackmcbarn (talk) 22:26, 16 March 2014 (UTC)
Got it. As you said, "confusing." Mark Schierbecker (talk) 23:15, 16 March 2014 (UTC)

Tech News: 2014-12

Latest tech news from the Wikimedia technical community. Please inform other users about these changes. Not all changes will affect you. Translations are available.

Recent software changes

  • The latest version of MediaWiki (1.23wmf18) was added to test wikis and MediaWiki.org on March 13. It will be added to non-Wikipedia wikis on March 18, and all Wikipedia wikis on March 20 (calendar).
  • You can now view smaller versions of PNG images bigger than 20 megapixels. [47]
  • You can now use the new search tool (CirrusSearch) on all small wikis. You can now enable it in your Beta options. [48] [49]
  • You can read a summary of the Wikimedia technical report for February 2014. [50]

VisualEditor news

  • Searching for template parameters in now case-insensitive. [51] [52]
  • Required template parameters now have an asterisk (*) next to their edit boxes. [53]
  • Several template dialogs are now smaller, and their insert buttons have changed wording. [54]

Future software changes

Problems

  • VisualEditor was slow to load on March 13 because of an API issue. [58]

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

07:14, 17 March 2014 (UTC)

Need to fix double redirect bots

FYI, the double redirect bots are working extremely slowly today. --Jax 0677 (talk) 00:35, 15 March 2014 (UTC)

Sinhala script size and Template:Lang

Has anyone else noticed that recently the Sinhala script has started to appear much larger than other scripts when used with Template:Lang and Template:Lang-si? It's OK when the template isn't used.

Sinhala English
Template:Lang ශ්‍රී ලංකාව Sri Lanka
Template:Lang-si Sinhala: ශ්‍රී ලංකාව Sinhala: Sri Lanka
Template:Lang-en English: ශ්‍රී ලංකාව English: Sri Lanka
Without template ශ්‍රී ලංකාව Sri Lanka

I've tried it with three different browsers (Firefox, Chrome and Safari) and they all show Sinhala script to be larger when the templates are used.--obi2canibetalk contr 20:42, 15 March 2014 (UTC)

It may be the fonts that you have installed on your computer. What I see above are four groups (split 4 & 5) of boxes containing hex codes like 0DC1 0DCA 0DBB 0DD3 etc. which means that I don't have a suitable font. --Redrose64 (talk) 20:48, 15 March 2014 (UTC)
I don't think it's the fonts on my computer because it looks OK without the template. And this is recent phenomena, I've had my computer for three years.--obi2canibetalk contr 21:03, 15 March 2014 (UTC)
For the first two rows, {{lang}} and {{lang-si}} have the same effect on your examples: they enclose the text in the HTML markup <span xml:lang="si" lang="si">ශ්‍රී ලංකාව</span>. On the third row, {{lang-en}} doesn't actually do anything, the rendered HTML is just the same as the row "Without template". What this suggests is that there is some special processing being done for <span xml:lang="si" lang="si"> --Redrose64 (talk) 21:18, 15 March 2014 (UTC)
I seem to recall UniversalLanguageSelector can do special processing based on lang attributes. This might depend on whether its web fonts option has been turned on. – PartTimeGnome (talk | contribs) 20:34, 16 March 2014 (UTC)
What you posted in the box above is all the same size for me. Whatamidoing (WMF) (talk) 16:12, 17 March 2014 (UTC)

Open source code for 'read only'. By option?

Is it possible to open a page for read only, by option? More specific: I have TE right (no admin right). When developing code I work in a template /sandbox. To prevent accidental edit saving the (protected) live template code, I'd like to open that one in 'read only' mode by choice, maybe in an url link. Possible? -DePiep (talk) 09:54, 17 March 2014 (UTC)

There's probably a user script for that floating around somewhere, but there's no option built in to MediaWiki to do it. Jackmcbarn (talk) 11:50, 17 March 2014 (UTC)
The preference setting "Prompt me when entering a blank edit summary" (on the "Editing" tab) can act as a defensive against accidental edits. -- John of Reading (talk) 12:25, 17 March 2014 (UTC)
I started using User:Anomie/nosubmitsummary.js a few weeks ago. It stops you from being able to submit an edit by hitting "enter" in the edit summary window, and I've found it helps to prevent accidental edits. Another option (in Firefox, at least) is to right-click on the edit link and click "Open Link in New Private Window", which will make that window act as if you are logged out. — Mr. Stradivarius ♪ talk ♪ 12:33, 17 March 2014 (UTC)
One thing that you could do is to hide the "Save page" button. 
input#wpSave { display: none; }
in Special:MyPage/common.css will do it. In combination with User:Anomie/nosubmitsummary.js, this means that to save a page when you really want to, you need to use the appropriate keyboard shortcut - Alt+⇧ Shift+S in Firefox; ⇧ Shift+EscS in Opera; etc. --Redrose64 (talk) 17:31, 17 March 2014 (UTC)
Thanks all. Useful options. -19:46, 18 March 2014 (UTC) — Preceding unsigned comment added by DePiep (talk • contribs)

"protect" what

Tracked in Phabricator
Task T64722

Today, I was researching some of the ArbCom disputes when I saw a log entry from Phoenix7777 (talk · contribs) (see log entries) showing simply the word "protect" without reference to any target article. For reference the first instance was I believed targeted to the Senkaku Islands dispute, see Senkaku Islands log for this. I notice also that the page was previously fully protected from moves due to the warring happening there, and that Phoenix is not a sysop so he has no ability commit any sort of logged administrative actions.

  1. How many other editors have experienced this?
  2. Is this a bug and should I file a bugzilla ticket for it?

TeleComNasSprVen (talk • contribs) 10:07, 17 March 2014 (UTC)

Actually did a little more digging and I believe the culprit is AFTv5, as shown in this diff which has the same timestamp as the "protect" log entry. TeleComNasSprVen (talk • contribs) 10:13, 17 March 2014 (UTC)
All of the AFT5 log entries look odd now that AFT5 has been removed. Jackmcbarn (talk) 11:54, 17 March 2014 (UTC)
The html for the log entry says:
<li class="mw-logline-articlefeedbackv5"><input name="ids[54663738]" type="checkbox" value="1" /> 11:47, 6 February 2014 <a href="/wiki/User:Phoenix7777" title="User:Phoenix7777" class="mw-userlink">Phoenix7777</a> <span class="mw-usertoollinks">(<a href="/wiki/User_talk:Phoenix7777" title="User talk:Phoenix7777">talk</a> | <a href="/wiki/Special:Contributions/Phoenix7777" title="Special:Contributions/Phoenix7777">contribs</a> | <a href="/wiki/Special:Block/Phoenix7777" title="Special:Block/Phoenix7777">block</a>)</span> protect </li>
I suppose we could do something with mw-logline-articlefeedbackv5 but I'm not sure it's worth it. The article is not revealed. ids[54663738] is an id for the log entry. PrimeHunter (talk) 12:31, 17 March 2014 (UTC)

I'm alerting Fabrice Florin, the product manager who handled the Article Feedback tool and its recent removal from this wiki, to this issue. --Dan Garry, Wikimedia Foundation (talk) 18:57, 17 March 2014 (UTC)

lolwut, edit from 8.8.8.8

Can someone explain this? It's an edit purporting to be from IP address 8.8.8.8, which is a Google public DNS server address, advising someone on a technical aspect of Wikipedia editing. Most explanations I can think of aren't persuasive. Maybe I'm missing something. 70.36.142.114 (talk) 14:33, 17 March 2014 (UTC)

That is indeed strange. No edits from 8.8.4.4, 2001:4860:4860::8888, 2001:4860:4860::8884, or even 4.2.2.2. I cannot think of any reasonable explanation. πr2 (t • c) 16:24, 17 March 2014 (UTC)
There are a few things. A mess up in the setup of ulsfo datacenter (last year we had entries under 10.something with eqiad center if i remember correctly), or something with XFF. But its so long ago, that ops doesn't really think they can still figure it out anymore. —TheDJ (talk • contribs) 23:19, 17 March 2014 (UTC)

Broken template somewhere, help?

Taking a look at Category:Pages with missing references list (usually populated by 20-100 mostly-article pages, now at 6k+ mostly-not-article ones), it's obvious that some kind of widely-transcluded something (template? module?) has been broken recently, resulting in ref errors being thrown at thousands of Portal- and Wikipedia-space pages. I've had no luck tracking down the broken transclusion with my usual methods; can I get some more eyes trying to figure out what happened? A fluffernutter is a sandwich! (talk) 15:37, 17 March 2014 (UTC)

Discussion at Help talk:Cite errors#Categorisation of reference errors. (this is also the talk page for the category) --  Gadget850 talk 15:56, 17 March 2014 (UTC)
That seems to be discussing labels used to categorize the errors for different namespaces, but doesn't address why 6000 pages are suddenly and (relatively? I've been away for the better part of a month) newly broken. Did some code somewhere change in a way that no longer works with reflists or something? A fluffernutter is a sandwich! (talk) 16:12, 17 March 2014 (UTC)
  • My understanding of the situation is this, those pages have had broken refs for quite some time but were exempt from being categorized for whatever reason. That exemption was decided to have been a bad idea and they are now categorized. Since there are so many of them however, I'm wondering if there is a better way to deal with them? They should not be all dumped in one big polluted category. — {{U|Technical 13}} (t • e • c) 16:24, 17 March 2014 (UTC)
  • Well, if they're genuinely pages with broken refs (as opposed to pages that ended up there because a template that the pages used is the page that's broken, which is what I had been assuming), it's not unreasonable for them to be in the category. It's a big backlog, but I and the handful of other people (and the bot - we still have a bot, I think) who work the category can chip away at adding reflists, the same as we usually do with articles. It's no more optimal for archives, drafts, and project pages to be throwing refs than it is for articles to be - we archive pages because we expect they might be of some reference use some day, and they're less useful when they're not displaying refs properly. And since the category is sorted by namespace, with "article" on top, we can still easily give articlespace the priority. A fluffernutter is a sandwich! (talk) 16:36, 17 March 2014 (UTC)
Portal pages don't normally include references - check out the featured portals linked from the top right of the Main page. So rather than adding reflists to portal pages, it would be better to remove the references. -- John of Reading (talk) 16:52, 17 March 2014 (UTC)
  • @Fluffernutter: I agree that they should be categorized, just not that they should all be dumped in one big category. I would think it better to create sub-cats per namespace.
@John of Reading: remove or convert from references using tags to hard coded references? I would prefer see them as hardcoded in most cases I think. — {{U|Technical 13}} (t • e • c) 17:09, 17 March 2014 (UTC)
@Technical 13: Remove. As on the Main page, readers should be able to verify the information by following the "Read more" link, or similar, from the portal page into the main encyclopedia. -- John of Reading (talk) 17:29, 17 March 2014 (UTC)
@John of Reading: (edit conflict) Yeah, it looks like the portal pages are generally angry because they include transcluded templates/blurbs that use references. I'm not particularly up on portal guidelines - is it considered optimal to have portal frontpages just not use refs at all? The other option would be to consider using local or template reflists to display what were apparently intended, way back when, to be displayed references. A fluffernutter is a sandwich! (talk) 17:30, 17 March 2014 (UTC)

cite doi automatic completion broken?

I created an article (Laricobius osakensis) with a couple of cite doi templates. Usually there is a delay in the bot filling in the citation. But it has been many hours and when I click on "jump the queue" I am taken to an error page. Is this a known problem? Abductive (reasoning) 17:01, 17 March 2014 (UTC)

I get the same errors. It was working yesterday. Smith609 is the operator of this bot and might know more. – Jonesey95 (talk) 20:26, 17 March 2014 (UTC)
This may be a broader problem. It recently was moved to http://tools.wmflabs.org/citations but that page, like many others on that server, now returns a 404 error. LeadSongDog come howl! 17:14, 18 March 2014 (UTC)
That it because you forgot the ending /. Then it gives a 503. I'm guessing this is due to the recent eqiad and lighttpd migration. *checks toollabs:?status tools-webgrid-01* Yep, there is no lighttpd-citations job. This means the maintainer (Mattsenate) should ssh to tools-login-eqiad, become his tool account, and run `webservice start' (assuming eqiad migration is already completed correctly; see eqiad migration). I had the same problem with my account. Feel free to go to #wikimedia-labs connect if you have any questions. Regards, πr2 (t • c) 17:43, 18 March 2014 (UTC)
Thank you. Will give the op a heads-up. |||| — Preceding unsigned comment added by LeadSongDog (talk • contribs) 18:08, 18 March 2014 (UTC)

How to search edit summaries?

Is there a way to search the text of edit summaries, either (1) within a single article or (2) across all Wikipedia articles?

If there isn't, can such a function be added? Dezastru (talk) 21:57, 17 March 2014 (UTC)

There used to be a tool, but it seems it's unmaintained atm and not working —TheDJ (talk • contribs) 22:34, 17 March 2014 (UTC)
This one seems to work, http://toolserver.org/~snottywong/commentsearch.html GB fan 22:51, 17 March 2014 (UTC)
Note that that tool looks for edits under one user, and there's no option to restrict it to a single article. You can do that manually, by picking the history tab for an article, listing as many edits as possible (500 limit), and using Control F to search. If there are more than 500 edits you will need to step through them 500 at a time and repeat the search each time (although most of the time I find what I want in the most recent 500 edits). StuRat (talk) 23:01, 17 March 2014 (UTC)
The tool by Sigma (found at the bottom of a contribs page as Edit summary search) is maintained - I know because I occasionally file bugs which later get fixed, see e.g. User talk:Σ/Archive/2013/December#summary.py is broken or User talk:Σ/Archive/2014/March#summary.py doesn't find all edits. It was working a few days ago, so we should assume that it's just temporarily down. Oh, and the limit for page history is 5000, not 500 - see my comment at #Block log searching. --Redrose64 (talk) 23:35, 17 March 2014 (UTC)
I'm guessing this is due to the recent eqiad migration. *checks toollabs:?status tools-webgrid-01* Yep, there is no lighttpd-sigma job. This means Sigma should ssh to tools-login-eqiad, become his tool account, and run `webservice start'. I had the same problem with my account. πr2 (t • c) 16:52, 18 March 2014 (UTC)
In browsers on Windows and Linux-based computers, the typical shortcut key for find-in-page is Ctrl+F. Also, rather than stepping through edits 500 at a time, you can edit the URL to add &limit=5000, which displays up to 5000 history entries on a single page. There are very few pages with more revisions than this, so stepping to a second page would be rare with 5000-per-page. – PartTimeGnome (talk | contribs) 23:39, 17 March 2014 (UTC)
  • Unless you are looking through the contributions of a specific user, in which case there can be pages upon pages (I have just over 20K edits myself) of results even at 5000 a pop. Also, I've noticed that some history pages still only show 500 results even if &limit=5000 is specified. I don't remember the details, but it is stupid annoying. — {{U|Technical 13}} (t • e • c) 01:21, 18 March 2014 (UTC)
Well, I was only referring to page histories rather than user contribs. I'm not sure why limit=5000 doesn't always work. There might be something else that can restrict the number of revisions shown. – PartTimeGnome (talk | contribs) 21:40, 18 March 2014 (UTC)

Thanks for the replies, everyone. I'll keep an eye on the page for that tool from Sigma, in particular, to see when it's running again. Dezastru (talk) 02:51, 18 March 2014 (UTC)

My virus program detected malware at one of Wikipedia's tools

I was checking the links on WP:Tools, and came across http://www.keybreeze.com/lettercommands.htm. I have McAfee Internet Security Suite, which blocked it as a malware site and marked it "red".

I wanted a couple more tests, so I checked virustotal and submitted the website to Anubis (Anubis.iseclab.org/). Virustotal said it was "suspicious" but inconclusive; Anubis (I think) confirms my suspicion.

I want to remove it, just to be safe. All it did was give hotkeys, anyway, which accesskeys and various other Internet programs can replace.

This may sound like a dumb question, but: will anybody be dumb enough to re-instate the link (assuming it wasn't a false positive report)—a WP:RANDY editor perhaps? I can never really tell. Meteor sandwich yum (talk) 22:43, 16 March 2014 (UTC)

Neither VirusTotal nor Anubis says it's suspicious. I'm pretty sure McAfee just had a false positive (that's common with hotkey programs). I don't think there's anything unsafe about it. Jackmcbarn (talk) 22:51, 16 March 2014 (UTC)
Yeah, I guess I'll re-instate it. Meteor sandwich yum (talk) 06:54, 19 March 2014 (UTC)

When a link in a citation has been cyber-squatted, how should we deal with it? It would be best to stop it being clickable, in case it now hosts porn, malware or other undesirable content. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:23, 18 March 2014 (UTC)

A specific example would help. Can you recover it via archive? Can you find an alternative source? Does it need to be linked— other than a web only source, a link is a convenience. --  Gadget850 talk 14:28, 18 March 2014 (UTC)
Well, the question was general, so the solution for a specific example might not suit all cases; I was thinking of writng a page odf guidance, if none already exists. That said, the example that sparked my interest is walkofstars-co-uk, in various citations on Birmingham Walk of Stars. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:17, 18 March 2014 (UTC)
Both WP:DEADREF and WP:EL have a little information that might be useful to you. WhatamIdoing (talk) 17:22, 18 March 2014 (UTC)
I have added the following table of bookmarklets to WP:DEADREF. I created these bookmarklets to make it easier and faster to find archives of a page which is no longer available (for whatever reason). All of these land on a page from which you can select different archive dates for the page, if multiple archives of the page exist. Doing so permits selecting an archive version that is as close as possible to the version of the page cited on |accessdate=. The WebCite and archive.is bookmarklets have only been minimally tested as I usually only have to check archive.org.
Bookmarklets to check common archive sites for archives of the current page
(all open in a new tab or window)
Archive site Bookmarklet
Archive.org javascript:void(window.open('https://web.archive.org/web/*/'+location.href))
WebCite javascript:void(window.open('http://www.webcitation.org/query.php?url='+location.href))
Mementos interface javascript:void(window.open('http://www.webarchive.org.uk/mementos/search/'+encodeURIComponent(location.href)+'?referrer='+encodeURIComponent(document.referrer)))
Archive.is javascript:void(window.open('http://www.archive.is/search/?q='+location.href))
— Makyen (talk) 21:32, 18 March 2014 (UTC) removed archive.is per WP:Archive.is RFC — Makyen (talk) 05:55, 19 March 2014 (UTC); restored archive.is, but struck-out — Makyen (talk) 10:05, 19 March 2014 (UTC); added Mementos interface to table — Makyen (talk) 11:17, 20 March 2014 (UTC)
Makyen: Thanks for adding that.
It looks like the site is now http://www.broadstreetbirmingham.com/broad-street-business-improvement-district/walk-of-stars/. I did not do a deep search to see if the pages in question are still available.
I did find an archive for the second citation at http://archive.is/CqQaw, but it was by Googling, as searching Archive.is did not return it.
And my initial advice stands. --  Gadget850 talk 23:16, 18 March 2014 (UTC)
@Makyen: I've removed the archive.is entry from the table you added. Per WP:Archive.is RFC, no links to archive.is should be used on Wikipedia. Jackmcbarn (talk) 00:07, 19 March 2014 (UTC)
@Jackmcbarn: Thank you for the pointer to WP:Archive.is RFC. I have removed the bookmarklet from my post above and the other page on which I placed it (in addition to the one you removed). I also removed an associated bookmarklet to create an archive instead of search for one (as with the above it was a set of three with archive.org and WebCite). Obviously, this is the first I have heard about this issue. Fortunately from my point of view, my use of archive.is has been decidedly tertiary with archive.org and WebCite being far more prominent. The only times I recall having used archive.is is when a needed archive has not been available at either of the other two.
So far, I have only read the closure and actual RfC, then skimmed parts of the responses. The behavior described is strange from someone purporting to be the owner of archive.is. More importantly, the RfC closure leaves enwiki in a strange situation where editors, such as myself, will unknowingly add links to archive.is which may be the only, or just easiest, place to find an archive of a particular page. I'm still reading through all the associated links. A pseudo-ban is not the appropriate place to leave the situation. However, this is not the proper place to open discussion as to where it should go from here. — Makyen (talk) 05:55, 19 March 2014 (UTC)
Just FYI: I had earlier amended my signature (above) attached to the original post of the table with bookmarklets. In doing so, I appended an additional timestamp using 5 tildes, as is the recommended guideline at WP:REDACT. If it should have a full signature, I am happy to use one in such an instance. I don't care either way. If a full signature should be used, then the guideline should be changed.
In retrospect, I should have used <del>...</del> on the line instead of completely removing it. I have restored the line, but left it struck-out. Chalk the deletion up to being a bit over-zealous about rectifying my non-compliance with an RfC about which I was previously unaware. However, for talk page continuity, it should remain. — Makyen (talk) 10:05, 19 March 2014 (UTC)
For what it's worth, I was the one who changed your signature from five tildes to four because I thought it was a mistake; I didn't know about that guideline. Thanks for letting me know; I'll keep it in mind in the future. Graham87 06:04, 20 March 2014 (UTC)
@Graham87: Absolutely not a problem. I appreciate it when someone fixes a signature of mine. I just thought I had misunderstood what I should be doing in such situations.
I have just found out about the Momentos interface. It looks like it will be useful, but the webpage interface has the limitation that it strips the query string from the URL for which you are attempting to find archives. This appears to be because the manual entry does not encode any of the URL special characters. While this is fine for many URLs, it significantly limits the pages for which archives can be searched for using their manual interface. When using manual entry on their webpage, simply changing the "?" to "%3F" in your search-for URL will be sufficient for it to work most, but not all, of the time.
I have updated the table (above) to include a bookmarklet for the Monentos interface. The bookmarklet properly encodes the URL such that the Mementos interface will function with more complex URLs. The bookmarklet is based on the one provided on their page. However, it does not use the deprecated "escape" function and opens in a new tab/window. — Makyen (talk) 11:17, 20 March 2014 (UTC)

Revision history, Edits by user is 503

A very useful tool Edits by user at the top of every articles' Revision history is currently Missing In Action. When will this tool be available again? It was formerly found on the 4th line from the top of Revision history, for example, at https://wiki.riteme.site/w/index.php?title=Talk:Sense_and_reference&action=history, the fourth external tool link, when counted from the left. Instead of the tool, you get The URI you have requested, http://tools.wmflabs.org/?503, is not currently serviced. --Ancheta Wis   (talk | contribs) 20:24, 19 March 2014 (UTC)

Scottywong needs to ssh to tools-login (now eqiad), become his tool account, and then run `webservice start' and start any other jobs which may have been lost. Feel free to hop into #wikimedia-labs connect if you have any questions. πr2 (t • c) 23:43, 19 March 2014 (UTC)
Just did that, and it didn't make a difference. Is it naive to believe that once you get your code working on Labs, it will continue working indefinitely if you don't touch it? If not, then I might need to transfer ownership of some of these tools, because I don't check on them routinely. ‑Scottywong| yak _ 23:49, 19 March 2014 (UTC)
Scottywong, Thank you for taking ownership of that tool. Now I get another kind of message: No web service. ... If you maintain this tool, You have not enabled a web service for your tool, or it has stopped working because of a fatal error. You may wish to check your logs or common causes for errors in the help documentation. --Ancheta Wis   (talk | contribs) 00:15, 20 March 2014 (UTC)
For what it's worth, and I am not trying to be troublesome, here is the status of the External tools on the Talk page:
  1. Revision history statistics · not working. it is hung
  2. Revision history search · working DE wiki
  3. Contributors · working toolserver.org
  4. Edits by user · MIA
  5. Number of watchers · working info#mw-pageinfo-watchers
  6. Page view statistics - working SE wiki
Perhaps it may be worthwhile for me to ask advice?? The other External tools appear to have different servers. --Ancheta Wis   (talk | contribs) 03:11, 20 March 2014 (UTC)
Scottywong: the webservice has not started (cf. toollabs:?status, search for "lighttpd-usersearch"). Are you sure you ran "become usersearch" before running "webservice start"? πr2 (t • c) 00:23, 20 March 2014 (UTC)
It started but failed. Hedonil says (verbatim) you should create a .lighttpd.conf file and add debug.log-request-handling = "enable" for a more verbose error log. Docs: wikitech:Nova_Resource:Tools/Help/NewWeb. πr2 (t • c) 00:41, 20 March 2014 (UTC)

Ugh. I don't have time to figure this crap out right now. I definitely did a "become usersearch" before running "webservice start". I have a feeling I'm going to go through the trouble of creating a .lighttpd.conf file (whatever the hell that is) and add debug.log-request-handling = "enable" (whatever the hell that is), and the result is that I'm going to get an archaic error log that doesn't tell me anything.

The tools have worked for months and I haven't made any changes to them whatsoever, I haven't even logged in to the Labs server for months. If someone wants to take over these tools, just say the word and they're yours. And tell me how to give you access to them. They're all written in Python. User:Σ has taken over some of my other tools, maybe he'll be interested in taking over more. It may be a week or longer before I have time to figure out why they're not working. The whole Tool Labs thing is way too complicated, obtuse, and poorly documented. ‑Scottywong| chatter _ 04:41, 20 March 2014 (UTC)

I don't object to annexing these tools into my account, but there is always the option of adding a few Pythoneers as maintainers. This is one of the main features of Labs that sets it apart from Toolserver.
On a side note, I just figured out how to set up the bare minimum to make them work under the new configuration. You can steal the conf file from /data/project/sigma/.lighttpd.conf and change the path to the Python interpreter. →Σσς. (Sigma) 07:25, 20 March 2014 (UTC)

Please accept my apologies for the trouble, Scottywong. While necessary, I am aware that the requirement to migrate from one datacenter to another did cause work and some inconvenience to volunteers. That said, I recommend strongly that you (and all Labs users) subscribe to the labs-l mailing list where advance warning and instructions are posted for any upcoming change; this way you'll get enough advance notice to schedule any intervention on your own schedule.

For the immediate issue, would you like me to add Sigma (or anyone else) as a maintainer to your tool if you don't have the opportunity to do so yourself? — MPelletier (WMF) (talk) 13:41, 20 March 2014 (UTC)

Sure, please add Sigma to all of my tools, thanks. If there are any other interested "Pythoneers", let me know. ‑Scottywong| prattle _ 13:52, 20 March 2014 (UTC)
 Done, I've added Σ. — MPelletier (WMF) (talk) 14:10, 20 March 2014 (UTC)

Problems with citation template

The last few times I've tried to add a reference using the Citation template I have finished filling out the boxes and when I go to Add Citation it refreshes as if its been added but when it returns to the edit text screen the citation is not there and what I'd added has been lost. I edit using iPad and when I originally started editing with this I recalled I needed some help to get citation to work in the first place. Hope someone can assist. Eldumpo (talk) 07:47, 16 March 2014 (UTC)

Wikipedia:Village pump (technical)/Archive 124#Strangeness in the Add citation thingy may be related. --Redrose64 (talk) 07:56, 16 March 2014 (UTC)
  • Eldumpo, Redrose64, in that thread The Bushranger hit the nail on the head: after filling out the template you need to move back to the editing screen and click to move your cursor to the main text where you want to insert the citation. (I just lost another one cause I forgot.) It's totally infuriating, but that's what it is. Drmies (talk) 14:25, 21 March 2014 (UTC)

Autofixing cite URLs with bar/pipe

I have expanded the autofixing of Lua wp:CS1 cite templates to begin rebuilding a URL which contains a vertical bar/pipe "|" and was parsed as an extra parameter at the bar. Does anyone know of common source websites which tend to have internal bars "|" in the URL? (it already handles "nl.newsbank.com") For multiple bars, there is the danger that Lua script could get the portions parsed in reverse order, unsure which portion to append into the URL first. I have an essay discussion at:

Reply either here or in that essay talk-page, as preferred. No hurry. Thanks. -Wikid77 12:22, 17 March 2014 (UTC)

I found a common case for bar/pipe in a URL is using Google Translate in a typical web link to translate a non-English source webpage, where "&langpair=it|en" will contain a bar/pipe between the 2 language codes, such as with "it|en" for Italian-to-English. -Wikid77 15:39, 21 March 2014 (UTC)

What happened to Duplication Detector at Labs?

Duplication Detector on Labs is vital to reviewing nominations at Did you know. It's link is on every template of every nomination. As of yesterday, I began getting a message that "No webservice. The URI you have requested, http://tools.wmflabs.org/dupdet/, is not currently serviced." It has been maintained by Dcoetzee who has not edited since Feb 2, 2014. Anybody know what is going on? — Maile (talk) 17:49, 20 March 2014 (UTC)

See any of several sections above re the need to restart services on wmflabs. You might pop him a wiki-email. LeadSongDog come howl! 21:36, 20 March 2014 (UTC)
In the meantime you can use the version on Toolserver: http://toolserver.org/~dcoetzee/duplicationdetector/ -- Diannaa (talk) 21:38, 20 March 2014 (UTC)
  • Actually, earwig's copyvios tool is incapable of checking an article against an actual source, so it's effectively useless for DYK purposes. Good to know that the duplication detector is still available on toolserver. Thanks, Diannaa. BlueMoonset (talk) 12:51, 21 March 2014 (UTC)

G7 not working anywhere in usertalkspace?

Look at User talk:Robertgreer/to do/dance2 as of this edit. Why does the template throw up the big warning? Did we want it to do this for every page in user talk space? Unlike a primary talk page (e.g. User talk:Robertgreer), this is simply the talk page for a userspace page, so it can be deleted like any other page. Nyttend (talk) 21:25, 20 March 2014 (UTC)

It's been a requirement for several years (specifically, since 20 July 2008‎) that {{db-author}} requires a |rationale= parameter when used on user talk pages. --Redrose64 (talk) 22:02, 20 March 2014 (UTC)
On primary talk pages, yes, but this is a subpage; why isn't it treated differently? I understand that someone might try sneakily to get a talk archive deleted this way, but one could simply move a talk archive to User: space and get it deleted easily. Nyttend (talk) 22:55, 20 March 2014 (UTC)
That is a question to raise at WT:CSD (perhaps WP:VPP), not here - it's not a technical matter but a policy matter. --Redrose64 (talk) 23:35, 20 March 2014 (UTC)
The user did try to give a reason but wrote {{db-author|1=cleanup}} instead of {{db-author|rationale=cleanup}} which would have avoided the warning. I have updated [59] the template to point to the right section Wikipedia:User pages#Deletion of user talk pages which I think allows deletion here considering it isn't the main user talk page or an archive of it, and the talk page has no purpose now. PrimeHunter (talk) 11:55, 21 March 2014 (UTC)

Stats for audio/ video

What stats can we see, about how many times an audio or video file, such as File:Benedict cumberbatch in front row b00wqfnd-crop.flac, has been played; and from which pages it was launched? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:04, 20 March 2014 (UTC)

In short: almost certainly none. — This, that and the other (talk) 08:39, 22 March 2014 (UTC)

Special:Contributions and education program

What MediaWiki message is responsible for the "X is a student in Y (Z)" layout that I'm currently seeing at the top of a lot of contributions pages? I've tried CTRL+F through Special:AllMessages to no avail. TeleComNasSprVen (talk • contribs) 18:42, 21 March 2014 (UTC)

Do you have an example? — Edokter (talk) — 18:50, 21 March 2014 (UTC)
TCNSV, you can find the name of messages by appending ?uselang=qqx or &uselang=qqx to the end of the query string in the URL. This is almost certainly from MediaWiki:Ep-user-roles-message-main-student (edit | talk | history | links | watch | logs), which is from mw:Extension:EducationProgram. It was added to SpecialContributions interface in gerrit:98183. Cheers, πr2 (t • c) 18:58, 21 March 2014 (UTC)

Edit notice for Commons-based files

When a user attempts to create or edit the file description page for a file hosted on Wikimedia Commons, the following message is displayed above the editing window:

This file is from Wikimedia Commons and may be used by other projects. Maybe you want to edit the description on its file description page there.

Just out of interest, how is this heading created? Is there a template somewhere, such as an edit notice (like Template:Editnotices/Namespace/File talk), which generates it? A MediaWiki page? SuperMarioMan ( talk ) 19:12, 21 March 2014 (UTC)

This is from MediaWiki:Sharedupload-desc-create or MediaWiki:Sharedupload-desc-edit. In general, when you do not know where a message comes from, try adding &uselang=qqx or ?uselang=qqx to the end of the URL. Regards, πr2 (t • c) 19:17, 21 March 2014 (UTC)

Search box behavior changed

For it seems like at least two weeks, I no longer have the choice between "Search" and "Go" in the search box in the upper right hand corner.  I thought this might be discussed on this page, but I see nothing.  When I automatically display images, there is now a shape that looks like a "Q" on the right edge of the search box, possibly intended as a symbol for a magnifying glass.  A mouse hover over the box displays, "Search Wikipedia [f]".  My main question is how do I go directly to a Wikipedia page when I know the title?  I'm finding that in some cases, it is easier to open Google and search from there.  Unscintillating (talk) 22:20, 15 March 2014 (UTC)

I think it only happens if you don't have JavaScript. There is a previous discussion at Wikipedia:Village pump (technical)/Archive 124#Searchbox is broken & Search is overloaded. I wrote: "I also think there should be a Go option somewhere users can find. Here is one they wouldn't find but you can bookmark it: https://wiki.riteme.site/wiki/Wikipedia:Your_first_article#Title_for_your_new_article." PrimeHunter (talk) 22:46, 15 March 2014 (UTC)
  • Toggling Javascript doesn't seem to change anything.  I never have the option of "Go", except that you have now shown me a bookmark that has the feature.  I don't know if this helps, but when the problem first started, I still had both the "Go" and the "Search" buttons, but the buttons had been swapped.  I use Firefox 2.0.0.20, if that is a factor.  Unscintillating (talk) 00:10, 16 March 2014 (UTC)
Do you mean you had buttons labelled "Go" and "Search" at the top right? I only know those buttons from other skins but there they are to the left for me: https://wiki.riteme.site/wiki/Example?useskin=monobook, https://wiki.riteme.site/wiki/Example?useskin=modern, https://wiki.riteme.site/wiki/Example?useskin=cologneblue. Have you changed skin at Special:Preferences#mw-prefsection-rendering? The default Vector skin has the magnifying glass icon and no labelled buttons. PrimeHunter (talk) 00:29, 16 March 2014 (UTC)
I didn't pay much attention to the "Go" and "Search" buttons, but I'm pretty sure that they were where the magnifying glass is now, which is at the right margin of the display window.  I checked to be sure, but I only use Vector skin and have never changed it.  I clicked on the checkbox, "Widen the search box in the Vector skin.", but after I saved my preferences, nothing changed.  I normally run with Javascript disabled, turning it on as needed.  Unscintillating (talk) 01:09, 16 March 2014 (UTC)
Have you tried to first enable JavaScript and then completely clear the cache? Firefox 2.0.0.20 is from 2008. Maybe it's not compatible with the search changes made a month ago. But if you prefer to use Wikipedia without JavaScript then I don't know whether there is a way for anyone to get Go functionality in Vector, other than visiting a page with a Go button like Wikipedia:Your first article#Title for your new article or below (that code could be copied to your user page for easier access). PrimeHunter (talk) 11:01, 16 March 2014 (UTC)

 

@Unscintillating: What skin are you currently using? Have you changed your skin any time in the past two months? What is your browser and operating system? This should help us diagnose the problem. --Dan Garry, Wikimedia Foundation (talk) 18:13, 17 March 2014 (UTC)

Most of the questions you've asked the answers appear above.  I use Windows 98.  As for the Javascript potential change, my biggest problem is that the behavior with Javascript off has changed, in that I no longer have a "Go" functionality.  I've not seen anything change from toggling Javascript, although I have not tested turning Javascript on and then rebooting.  Also, toggling Javascript before the problem started, did not affect the Go button.  Unscintillating (talk) 23:05, 17 March 2014 (UTC)
Yes. As I mentioned, this patch changed the behaviour of the search box when Javascript is disabled. The patch was not actually written by a person at the Wikimedia Foundation, so I know as much about it as you do. You may have more luck speaking to MatmaRex, the developer who wrote the patch. --Dan Garry, Wikimedia Foundation (talk) 23:32, 17 March 2014 (UTC)
I think I should clarify that it is not a key point that the functionality of the search box has changed from "Go" to "Search".  If I still had both the "Go" and the "Search" buttons, I could and would adapt.  Unscintillating (talk) 17:57, 22 March 2014 (UTC)

"Double" bold

Hi, when a table column heading is made bold

like this

I see a kind of "double bold" formatting that is heavier than ordinary bold. What actually is this formatting? And is it intentional, or is it a random side-effect of something that one is not supposed to do? 86.129.17.138 (talk) 02:36, 21 March 2014 (UTC)

I notice that works in Firefox but not Chrome. I'd say it's definitely something that one is not supposed to do. Jackmcbarn (talk) 02:49, 21 March 2014 (UTC)
I suspect it has to do with the styling of the <th> tag and the <b> tag. I checked default styling for Webkit, which seems to use "bolder" for b and "bold" for th. I'm not sure how Gecko does this, and cannot reproduce this problem in Firefox using monobook. πr2 (t • c) 03:02, 21 March 2014 (UTC)
In the browser I am using, "bolder" seems to display just the same as "bold" (bold text, bolder text), so I don't think it can be exactly that. I'm not sure whether it should be considered a "problem" or not. After all, if something is already bold, and you specify bold again, then making it "double bold" is not unreasonable. On the other hand, you could argue that applying bold formatting again should turn bold off. Really my question is prompted as much by curiosity as anything, but on a practical note I do come across this from time to time, as here, and I'm never quite sure if I should just remove it or if it's there for a reason. 86.129.17.138 (talk) 03:25, 21 March 2014 (UTC)
Remove it. Just about the only place I've seen it is in the context of tables (either the table caption [<caption>] or a table header [<caption>]), which are already bolded in the default CSS (without the need for a <b>) for the CSS skins in question. These are probably there because people don't know that they don't need to have them, or that the bold+caption was added before wikitable was the normal class. It's only now that some browsers (at least Firefox) have implemented double bolding that we're noticing it for the first time. --Izno (talk) 01:03, 22 March 2014 (UTC)
Just checked it: Firefox uses a bolded font variant for table headers (e.g. "Arial Bold"). When additionally using bolding on the header Firefox changes this to "Arial Black", the even bolder variant of Arial. This seems to be a very special case though and does not work in all cases (e.g. "Times New Roman" has only one bold style, therefore "double bolding" is not possible and the normal bold font is used in both cases). --Patrick87 (talk) 06:09, 21 March 2014 (UTC)

The CSS specification allows one to use up to 9 bolding levels, but currently only a few fonts and a few browsers support that. If you "nest" bolding, it is going to get bolder sometimes. :) Below are examples of the 9 styles in order from the lightest to the boldest for the curious. Matma Rex talk 08:35, 21 March 2014 (UTC)

The quick brown fox jumps over the lazy dog.
The quick brown fox jumps over the lazy dog.
The quick brown fox jumps over the lazy dog.
The quick brown fox jumps over the lazy dog. (this is the default, 'normal' font weight)
The quick brown fox jumps over the lazy dog.
The quick brown fox jumps over the lazy dog.
The quick brown fox jumps over the lazy dog. (this is the 'bold' font weight)
The quick brown fox jumps over the lazy dog.
The quick brown fox jumps over the lazy dog.
I wish I could find the relevant line in the specifications... Would be nice to be able to point to that. --Izno (talk) 01:03, 22 March 2014 (UTC)
On my setup, there are only three visibly different styles in the nine lines above: normal, bold, and what looks like the same "Arial Black" font that I see in the "double bold" table header, as identified above by Patrick. The last of these is used for both the "800" and "900" weights. It looks as if my system has no concept of different gradations of bold, but just switches to a different font for super-bold, at least for Arial text. 86.160.86.31 (talk) 03:49, 22 March 2014 (UTC)
See Font boldness: the 'font-weight' property in CSS 2.1 - particularly the sentences "There is no accepted, universal meaning to these weight names. Their primary role is to distinguish faces of differing darkness within a single font family." and "The association of other weights within a family to the numerical weight values is intended only to preserve the ordering of darkness within that family" The equivalent doc in CSS 3, which is currently at the Candidate Recommendation stage, doesn't really expand on that. --Redrose64 (talk) 08:42, 22 March 2014 (UTC)
Further to this, on my system Firefox displays three different levels as well, but the three levels are different: everything before "normal" is displayed using DejaVu Sans ExtraLight, normal and level-500 are displayed with DejaVu Sans, and the higher levels with DejaVu Sans Bold. Soon enough, Vector will start using only two levels (Arimo and Arimo Bold) on my system. Anomie⚔ 13:36, 22 March 2014 (UTC)

Issue viewing multimedia objects with Multicol in Safari

I can't figure out how to fix this. Can anybody have a look at Template talk:Multicol#Proposed Edit and see if they can fix this? Meteor sandwich yum (talk) 05:00, 21 March 2014 (UTC)

  • The Template:Multicol should not be used: There are numerous multiple-column templates which create problems on various browsers, and should not be used. Instead just use a plain wp:wikitable "{|...|}" with multiple columns ("|valign=top|"), and any right-side images will cause the column entries to neatly wrap beside images on various browsers. Also, Template:Autocol can be used to wrap around images since it is based on typical "<table>" tag elements. The one restriction with wikitables (or <table>) is to avoid empty columns containing "&nbsp;" as being trouble for screenreaders. -Wikid77 (talk) 16:14, 21 March 2014 (UTC)
Thanks. Meteor sandwich yum (talk) 21:53, 23 March 2014 (UTC)

vanished tool

I used for a long time a tool: tools:~verisimilus/Bot/DOI_bot/. This migrated to somewhere and it is not clear to where or how to operate it. The list given somewhere on the page gives another citation tool, but this leads to a guy how wants to help with some migration.

I was never interested in programming nor do I want to follow all talks about all server and computer and software movements, but is there a possibility to get the information what hapend and why in a place close to the user?

--Stone (talk) 21:26, 21 March 2014 (UTC)

See #cite doi automatic completion broken? above. πr2 (t • c) 22:00, 21 March 2014 (UTC)
You can add this tool to your left sidebar, in the Tools section. Go to Special:Preferences#mw-prefsection-gadgets and select "Citation Expander", then Save your preferences. You should see "Expand citations" under the Tools menu on the left sidebar on any page. Go to any article and click Expand citations.
I apologize if this is not the tool you were looking for. – Jonesey95 (talk) 06:33, 22 March 2014 (UTC)
THANKS!! The best would make this thing a recomendation in a point where you get when you try to use it. --Stone (talk) 21:21, 22 March 2014 (UTC)

UTRS has fallen over

I'm getting a 502 error at the usual http://utrs.wmflabs.org/ address, and have been for a couple of hours - anyone know what's going on there? Feel free to point me at the place where this has undoubtedly already been discussed; I'm rarely the first to spot these things... Yunshui 雲‍水 23:52, 21 March 2014 (UTC)

Andrewbogott added himself to the admins list (see here), so maybe he is trying to fix it. πr2 (t • c) 23:56, 21 March 2014 (UTC)
This project has been shut down as part of the labs datacenter migration. During the weeks leading up to the migration no one has offered to take responsibility for this project, so I deemed it abandoned. If anyone would like to step up and take ownership, I'm happy to revive it in the new datacenter. A bit of context: http://lists.wikimedia.org/pipermail/labs-l/2014-February/002152.html Andrewbogott (talk) 00:11, 22 March 2014 (UTC)
A team of highly trained monkey's have been dispatched to find out the issue...you know the rest. -- DQ (ʞlɐʇ) 16:07, 23 March 2014 (UTC)

Image glitch at Line of succession to the British throne

At 180px
At 220px
At 300px

At Line of succession to the British throne#Line of succession there is an image link to File:Prince Charles.jpg, but rather than displaying that image, the page is displaying an image of what appears to be a wedding cake. The page appears the same after purging and after a null edit, so I'm guessing that some kind of database glitch is responsible, rather than image vandalism. Do others see the same thing, and does anyone know how it can be fixed? — Mr. Stradivarius ♪ talk ♪ 09:02, 22 March 2014 (UTC)

Not for me. Try clearing the cache at your end. --Redrose64 (talk) 09:11, 22 March 2014 (UTC)
Hmm. Clearing the cache didn't work. However, the proper image appears when I'm logged out. This prompted me to blank my .js and .css pages, disable all of my beta features, and then clear my cache again, but I still get the cake image while logged in. Here's a screenshot. — Mr. Stradivarius ♪ talk ♪ 11:33, 22 March 2014 (UTC)
I also just tried the same thing after disabling all of my gadgets, but Line of succession to the British throne is still a cake-only experience. — Mr. Stradivarius ♪ talk ♪ 11:46, 22 March 2014 (UTC)
I guess you have set thumbnail size to 180 or 300 at Special:Preferences#mw-prefsection-rendering. I see Prince Charles at https://upload.wikimedia.org/wikipedia/commons/thumb/2/2e/Prince_Charles.jpg/220px-Prince_Charles.jpg which is what IP's and users with default thumbnail size get. I see the wedding cake at https://upload.wikimedia.org/wikipedia/commons/thumb/2/2e/Prince_Charles.jpg/180px-Prince_Charles.jpg and https://upload.wikimedia.org/wikipedia/commons/thumb/2/2e/Prince_Charles.jpg/300px-Prince_Charles.jpg, although at another height-width ratio than your screenshot because Line of succession to the British throne#Line of succession generates code to display it at the Prince Charles ratio. I have added the image at 180px, 220px and 300px here. I see cake, Charles, cake, all at Charles' ratio. I haven't tried to purge the images in case others want to investigate. PrimeHunter (talk) 12:35, 22 March 2014 (UTC)
The cake was moved from that name. [60] shows "18 November 2010 Diego Grez (talk | contribs) moved page commons:File:Prince Charles.jpg to commons:File:Prince Charles wedding cake (1981).jpg". The current Charles image was uploaded 18 July 2012. Maybe some of the sizes have been cached since before then. PrimeHunter (talk) 12:40, 22 March 2014 (UTC)
I had my thumbnail size preference set at 180px, and when I checked this thread 10 minutes ago I saw cakes in the 180px thumbnail and the normal image in the other two. Then I changed my thumbnail size preference to 220px and cleared my cache, and then all three images on this page displayed as Prince Charles the human rather than Prince Charles the cake. I then changed my thumbnail size preference back to 180px, cleared my cache again, and all three images were still of Prince Charles the human. So this appears to be fixed now for me. I imagine that it would be worth filing a bug to make sure this is fixed for other users in my situation as well. — Mr. Stradivarius ♪ talk ♪ 13:47, 22 March 2014 (UTC)
The cakes are also gone for me now. Maybe somebody purged the image. PrimeHunter (talk) 13:14, 22 March 2014 (UTC)
I still see cake-Charles-cake on this page, after purging the image and this page and clearing my browser (Safari) cache.--JohnBlackburnewordsdeeds 14:48, 22 March 2014 (UTC)
And now it's Charles all down, though I've done nothing here.--JohnBlackburnewordsdeeds 18:30, 22 March 2014 (UTC)
This type of issue (thumbnails being out-of-date at certain sizes) is often regional in nature, hence some people see it while others don't. On the rare occasions I see it, I find the three steps at commons:Help:Purge#Advanced manual thumbnail purging can fix it.
Technical explanation: When an image is uploaded, moved or purged, a message is sent to the caches in all Wikimedia data centres to remove the old image at all sizes known to have been generated. This message sometimes gets lost, causing old thumbnails to persist at some sizes at some data centres. Subsequent purges do not fix the problem because MediaWiki only purges thumbnail sizes it believes to exist, and it thought it already got rid of those old thumbnails. Re-generating the thumbnail at the problematic size(s) allows MediaWiki to know the thumbnail exists at that size, so the next purge purges it correctly. – PartTimeGnome (talk | contribs) 23:55, 22 March 2014 (UTC)
I'm still unsure how it could happen in this case. mw:Manual:$wgThumbnailEpoch says: "If rendered thumbnail files are older than this timestamp, they will be rerendered on demand as if the file didn't already exist." https://noc.wikimedia.org/conf/highlight.php?file=CommonSettings.php says $wgThumbnailEpoch = '20130101000000';. The file page history [61] shows the cake image was moved in 2010 so the thumbnails at the old title were presumably made before that and long before 2013. PrimeHunter (talk) 02:12, 23 March 2014 (UTC)
I'm not sure how that setting interacts with the caches. Since MediaWiki thought it had already told the caches to remove the thumbnails, it's possible the epoch setting wasn't able to properly purge the cache either. (I'm guessing here.) – PartTimeGnome (talk | contribs) 23:15, 23 March 2014 (UTC)

Bug fix needed at {{oldid}}

Could someone with templating chops please look at my bug fix request at Template talk:Oldid#Bug: use with .7Coldid.3D_adds .7Ctitle.3DMain Page? It should be a quick one. Thanks. — Scott • talk 13:34, 22 March 2014 (UTC)

I also responded on the template's talk page. I am posting this here so multiple people don't go looking for a problem in the template code which does not exist, per se.
The template is functioning as designed. The parameters which were provided to the template are invalid per the template documentation. For what was desired, use {{oldid2}} not {{oldid}}. The {{oldid}} template requires that a page name be provided. If no page name is provided it defaults to the Main Page.
Personally, I find that the requirement for a page name makes {{oldid}} effectively useless. I always use {{oldid2}}. {{oldid}} has been this way for years.
Multiple templates in the group which provides information similar to {{oldid}} have various versions which use parameters in somewhat different configurations. For instance, compare: {{contribs}} vs. {{contribs2}} vs. {{contribs3}} and {{history}} vs. {{history2}} vs. {{history3}}, and {{diff}} vs. {{diff2}}.
It looks like there might end up being a discussion about changing/merging {{oldid}} and {{oldid2}} on Template talk:Oldid if anyone wants to participate. — Makyen (talk) 14:51, 22 March 2014 (UTC)

template:Chart - borked?

as you can see (or at least, as i can see), this template appears to be broken.

if you can't see the problem, let me describe what i see: in the tempalte page, you'll notice, in the demo, that the 3rd generation appears to be squashed: the boxes around

My brother Joe
Me!
My little sister

collapse to a single fat line, that slashes the text in the middle. you can see the effect, e.g., in Template:Genealogy of the Olympians in Greek mythology - nothing special about this one, i chose it at random from the "what links here" of Template:Chart. for your convenience, i'm transcluding it here:

Extended content

is this a known issue? does someone have a solution?

Background: long time ago, we imported the grandfather of Template:Chart, namely Template:Family tree into hewiki. the imported template is borked now, and when looking for a solution i noticed that the original is now deprecated. i thought we'll have to re-import the updated one (not a pleasant task - this template code is so complicated that one can go blind if one stares at it for too long), but then i realized that the not-deprecated template is also borked...

peace - קיפודנחש (aka kipod) (talk) 15:46, 22 March 2014 (UTC)

Known issue in Chrome, see Template_talk:Family_tree#Rendering_issue and Template_talk:Chart#Lone_boxes_collapsing. Matma Rex talk 15:57, 22 March 2014 (UTC)
any idea what can be done here? is there some CSS trick that will fix it? or maybe some lua dirty trick that will do it? e.g., create Module:straighten-tables, and use it to package the chart and add the missing TDs? (if i understand correctly, chrome will be happy if we can slap extra TD elements on some of the rows such that all rows will have the same number of cells - maybe i misunderstood here...) peace - קיפודנחש (aka kipod) (talk) 16:35, 22 March 2014 (UTC)
There is a trick, but I can't remember where I posted it. The table row needs an explicit height (like 1px); that will force Chrome to display all cells with proper height. — Edokter (talk) — 22:01, 22 March 2014 (UTC)
I think that Wikipedia:Village pump (technical)/Archive 124#Kings of Wales family trees may also be related. --Redrose64 (talk) 00:05, 23 March 2014 (UTC)
that was super helpful. also, a happy accident, this template is editable by mere mortal. the link contains very clear instructions how to fix it, and i fixed Template:Chart - now it displays correctly with chrome, too (if you use chrome, open the collapsed section above and note that the chart displays properly. on other pages "purge" might be needed for a while). not sure what emoticon is appropriate here - super thanks! peace - קיפודנחש (aka kipod) (talk) 01:40, 23 March 2014 (UTC)

Page not transcluding correctly?

At WP:PHYS, on the right column is a link to "Wikipedia:WikiProject Physics/Current activity". This should be transcluded, but I can't find the reason for why it's not. The code on the WP:PHYS page is 

<div style="float:right; width:39%"> <!-- This adjusts the margins for the boxes aligned on the "right" -->
{{Portal:Physics/box-header|Current activity|Wikipedia:WikiProject Physics/Current activity}}
{{/Current activity}}
{{Portal:Physics/box-footer|}}
</div>

which should transclude Wikipedia:WikiProject Physics/Current activity. What gives? Headbomb {talk / contribs / physics / books} 16:50, 22 March 2014 (UTC)

The clue is at the very bottom of WP:PHYS, "Category:Pages where template include size is exceeded". See Wikipedia:Template limits. -- John of Reading (talk) 16:55, 22 March 2014 (UTC)
Ah I see, thanks. I fixed it now. Headbomb {talk / contribs / physics / books} 17:18, 22 March 2014 (UTC)

Getting a namespace's index from its alias

I see from Help:Magic words that {{ns:Χ}} will get you the alias of a namespace from its index. How can one do the reverse? — Scott • talk 20:17, 23 March 2014 (UTC)

mw:Help:Magic words#Namespaces shows {{NAMESPACENUMBER}} which can take a page name as parameter. It cannot take a namespace alone as parameter so it seems you must make an arbitrary page name after the namespace, for example "A" in {{NAMESPACENUMBER:X:A}}. It returns 0 (mainspace) if X is not a namespace. PrimeHunter (talk) 22:07, 23 March 2014 (UTC)
Test: "4" Ha! You're right. Nice workaround, thanks. — Scott • talk 00:04, 24 March 2014 (UTC)

What's causing this whitespace?

Could someone take a look at {{What links here}}, which I just rebuilt, and zap whatever's causing the extra space that's appearing after the page title here? I can't put my finger on it.

Thanks in advance! — Scott • talk 01:36, 24 March 2014 (UTC)

Fixed -- just a regular space. :D Theopolisme (talk) 01:40, 24 March 2014 (UTC)
Thank you :) Losing the ability to read code correctly is usually a damn good sign that it's time to go to bed. So I shall. — Scott • talk 01:44, 24 March 2014 (UTC)

server problems?

Wikipedia seems incredibly slow for me right now -- is it just me, or are other people noticing anything? —Steve Summit (talk) 03:34, 4 March 2014 (UTC)

I had been noticing this, but it seems to have cleared up by now:Jay8g [V•T•E] 04:26, 4 March 2014 (UTC)
Yup. —Steve Summit (talk) 06:34, 4 March 2014 (UTC)
I've found it getting slower through the day, but a reload of the browser speeds things up again. Probably irrelevant... Peridon (talk) 12:47, 4 March 2014 (UTC)
I was having a lot of problems yesterday evening New York time also. Reloading the browser didn't help. Robert McClenon (talk) 15:32, 4 March 2014 (UTC)
Between slow and painfully slow for me yesterday and today. I have reloaded a few times and given up on a few pages but it deteriorates quickly. Donner60 (talk) 02:56, 6 March 2014 (UTC)
It's been working fine in the mornings and afternoons EST but seems to slow to a crawl during evenings and makes WP nearly unusable during those hours.... Cloudchased (talk) 02:59, 6 March 2014 (UTC)
Where are you located? At a guess this sounds like a load-balancing problem in one of the Wikimedia data centres, and location is important when troubleshooting things like that. For what it's worth, I'm not having any problems at the moment. (I'm in Sapporo, Japan.) — Mr. Stradivarius ♪ talk ♪ 03:37, 6 March 2014 (UTC)
I agree with Cloudchased. It has been murder for the last 3 days at around 22:00 EST (US East Coast, or 03:00 UTC) and maybe an hour or two before and after that. Near Philadelphia. Chris the speller yack 03:58, 6 March 2014 (UTC)
U.S. East Coast. Donner60 (talk) 04:09, 6 March 2014 (UTC)
Now the 4th night in a row. Noticeably slower at 20:44 EST (US East Coast). Chris the speller yack 01:47, 7 March 2014 (UTC)
Me in NYC, OK so far, for once. Jim.henderson (talk) 02:02, 7 March 2014 (UTC)
Spoke too soon. Been intermittently balky, though not as bad as previous 3 evenings, for half an hour. Jim.henderson (talk) 02:46, 7 March 2014 (UTC)
Glad I found this thread, I thought it was just me. I've had problems the last 4 nights (East Coast US, approx. 0100-0400 UTC 3/4-3/7); occasionally I'd get a page served up, after a much-longer-than-normal wait, but it would more often just hang on me, giving me the first 1/3 of a page but never the rest. Not saying it was this bad all 3 hours, because after a couple of tried I'd give up and try later. No problems any other time of day, and no problems during this timeframe with any other website besides en.wiki. --Floquenbeam (talk) 20:57, 7 March 2014 (UTC)
At around 00:45 UTC on 6 March I tried to edit two long pages; the save attempts timed out after a minute with an error like this. After this happened five times for each page I gave up. Eight hours later I tried again, and both went through first time, and it took only a few seconds to save. Here they are: User:The Anome/Railway station list; Book:Stations Test. --Redrose64 (talk) 21:26, 7 March 2014 (UTC)
Now it's about the 6th straight evening partially wasted. Is any investigation proceeding? Chris the speller yack 01:37, 10 March 2014 (UTC)
I have been having these slowdowns again this evening, approximately 2200 EDT / 0200 GMT, in Washington, DC. I first above reported the problem on 4 March. I don't remember specifically whether it has been all seven evenings, but it has been close to that. I and other editors are reporting the problem on the US East Coast in the evening, on multiple evenings. Robert McClenon (talk) 02:06, 10 March 2014 (UTC)
FYI, I'm over on the East Coast, also near Philly, and these problems show up every single evening. Cloudchased (talk) 02:10, 10 March 2014 (UTC)
OP here. I'm in Boston. Very bad for me again last night (2014-03-09 20:15 EDT); fine this morning (2014-03-10 07:30 EDT). —Steve Summit (talk) 18:10, 10 March 2014 (UTC)
Very slow again for me tonight. It has been almost a week of problems. Real time changes is hanging up constantly as well. Almost impossible to counter vandalism with these problems. Donner60 (talk) 02:26, 11 March 2014 (UTC)
Slow again for me now (2230 EDT). My Reference Desk archiving bot (scsbot) is essentially useless.
See also this newer thread below. —Steve Summit (talk) 02:40, 11 March 2014 (UTC)
Me too. I'm wondering if it could be browser related? I use Firefox. Turned off a couple add-ons but that didn't seem to help. Carolmooredc (Talkie-Talkie) 00:36, 12 March 2014 (UTC)
I don't think it's browser-related. For me, the impact is greatest on my bot, which does not run in a browser at all. —Steve Summit (talk) 15:36, 12 March 2014 (UTC)
  • I have been having this problem for at least a week on two windows 7 laptops, one in NYC and one in NJ near Phila, using three different browsers, and not at all with other websites. The responses I got asking about this at the help desk a week ago were nothing, and at the computing ref desk today mocking from an IP sock in Europe and an established editor. The slowness ran tonight from about 630PM to 1130PM and in both cases I used a 'VERIZON DSL connection.μηδείς (talk) 05:41, 12 March 2014 (UTC)
I'm using Verizon DSL too. Haven't been on much last couple days so not sure how it's working now. Later: Take it back. It's still having periods of extreme slowness, especially on long pages. Carolmooredc (Talkie-Talkie) 22:46, 13 March 2014 (UTC)

Recurrent Server Problems, Evening on US East Coast

[this refers to this thread above]

We have regional consensus, then, that there is a problem with server performance every evening on the US East Coast. Is there a problem in the late afternoon on the US West Coast? Is there a problem in the small hours of the morning in the UK? Is there a problem in the morning in East Asia and Oceania? If so, then the problem is strictly time-dependent. If the problem is, as suggested, localized to the region and the time, then it does have something to do with load-balancing in the data centers. Robert McClenon (talk) 02:19, 10 March 2014 (UTC)

I have experienced similar issues in Texas. Not the US East Coast, but close enough that it could still be a regional issue. --Allen3 talk 01:44, 11 March 2014 (UTC)
I have had the same problems again this evening at about 2130 EDT / 0130 GMT in Washington, DC. That is, there has been a problem every evening for more than a week. As Allen3 says, it may be regional, if users in Texas are going through servers in Florida and users elsewhere are going through servers in California. Robert McClenon (talk) 01:54, 11 March 2014 (UTC)
I continue to have problems with slow loading and complete hangups on real time changes. It is very difficult to monitor and counter vandalism when this happens, not to mention discouraging. Donner60 (talk) 02:44, 11 March 2014 (UTC)
Another round of problems this evening. Interesting note is that I was having no problems editing at 23:56 but 10 to 15 minutes later it was taking 2 or 3 attempts to reload my watchlist and I was unable to load any of the talk pages I had just been working with. --Allen3 talk 00:47, 12 March 2014 (UTC)
Tonight was as bad as any during the last week, maybe even worse. Is anyone doing anything about this? If not, where do we go to get some action taken to correct it? Chris the speller yack 05:05, 12 March 2014 (UTC)
I agree. Very slow loading and complete hangups on real time changes. Seemed like some pages were not going to come up at all when diffs clicked on real time changes. Donner60 (talk) 05:16, 12 March 2014 (UTC)
Same in New York City, as discussed above in #server problems?. I've been watching more prime-time television instead. Jim.henderson (talk) 05:25, 12 March 2014 (UTC)
  • This has been going on for me in NYC and SJ area near Philly for a good ten days. See my questions at Help Desk which was ignored and at Computer Ref Desk which has been met with mockery. Occurs between 6p and Midnight, slowdowns to the point of total freeze but without crash on two windows 7 laptops whether I use Sfarai, IE, or Firefox. Suspect this may be a Verizon reaction to the recent net neutrality ruling. μηδείς (talk) 05:46, 12 March 2014 (UTC)
I'm almost certainly going through servers on the West Coast. I have not noticed any issue remotely as pervasive as the one described on any of the last several days. Other issues (e.g. Firefox crashing much more than normal for the last couple/few weeks), but not the ones described here, or the similar issues in the other thread(s?). I have experienced other slowdowns in the somewhat recent past, but those appeared to coincide with other issues reported here which were resolved.
Have any of you tried setting up a VPN to a site on the West Coast, or anywhere else, during the time you experience the problem on the East Coast. Or call a friend elsewhere who might try it at the same time you are experiencing the problem. Doing either of those could provide some useful information, particularly if you could have two machines up at once with one VPN'ed elsewhere and one routed normally. If one of you could set that up it would be able to 100% demonstrate the problem did not occur in X location while it was definitely happening at Y. Without something similar, we are all just guessing as to if any "I didn't see it" is actually at a time when the problem was being seen on the East Coast.
As we humans are, people rarely notice the times when things happen normally. Thus, it is difficult to say "Yes, I was actually trying to save a page, or look at my Watchlist, at exactly that time and had no problem." — Makyen (talk) 07:29, 12 March 2014 (UTC)
Well, user Medeis (μηδείς) may have something there with the Verizon angle. That's also my ISP. Is that true for all the folks who are seeing this problem? Chris the speller yack 14:18, 12 March 2014 (UTC)
Yes, it's on a Verizon DSL line that I observe the problem. I'll try the VPN experiment tonight. —Steve Summit (talk) 16:14, 12 March 2014 (UTC)
Setting up a VPN to an East Coast site would tell us (if it ran well) that it's not the region, but the ISP, right? Chris the speller yack 16:38, 12 March 2014 (UTC)
You are exactly right.
And... I just performed back-to-back tests, and I got terrible performance on the Verizon DSL connection and then, moments later, decent performance when I switched over to the VPN. I don't have time to post full details now, but it looks like Verizon just may be the problem. —Steve Summit (talk) 03:22, 13 March 2014 (UTC)
I am on Verizon FIOS (not DSL) and use Firefox. Problems are persistent, yesterday and today. I need to try IE but I suspect it will not differ. Donner60 (talk) 01:02, 14 March 2014 (UTC)
To answer a question that hasn't yet been asked, I am using Verizon DSL. I had the problems between about 1900 EDT and 2300 EDT on 11 March, 12 March, and 13 March again (that is, about 2300 GMT - 0300 GMT, 11-12, 12-13, and 13-14 March. Has anyone on the US East Coast who has the problem been using Comcast, or is it all Verizon? Robert McClenon (talk) 01:04, 15 March 2014 (UTC)
I had normal service and normal speeds earlier today, until about 2100 UTC. Now the pages open very slowly and won't fully load. It is looking like it is a Verizon issue. Verizon constantly puts up an ad about increasing internet speed (for an increased price, of course) when I activate my DVR. I suspect this could be another way of telling Wikipedia users, and perhaps users in general, that they might be better off paying for more service than they have needed to date than trying to get normal service in the evening/early night. Donner60 (talk) 02:13, 15 March 2014 (UTC)
Well, I am to the point where I think this needs to go on ITN and Wikimedia needs to take action. I am using Verizon now, and while today before 6PM EST in the US pages were loading almost instantaneously, as of 8PM EST they are taking 15 seconds at a minimum, if not just freezing up entirely. This is independent of browser, and only on WP and Wiktionary, no other sites. I feel like my own ISP is using stuxnet against me, and I pay the emm-effers outrageously for service 25X slower than their competitor's twice as expensive advertised rate. Can anyone point to an RS that would allow me to nominate this for an ITN listing on the front page? μηδείς (talk) 02:33, 15 March 2014 (UTC)
Have you called your ISP to let them know that you're having a problem? It's possible that they might not know about the problem, or might be able to tell you what's wrong. WhatamIdoing (talk) 04:12, 15 March 2014 (UTC)

I'm on Verizon in Central New Jersey and have been having the Wikipedia (Commons as well) slowness like others as well (including right now, 9:00 PM EDT). Last year, Verizon was throttling Youtube and I used the tricks in this blog post to block a range of IPs to get around their throttling. It generally worked though a couple of times Youtube was going just as slow as prior to the modification. Is there a similar IP address range for Wikipedia that can be blocked to get around this? —Mr. Matté (Talk/Contrib) 01:02, 17 March 2014 (UTC)

I see a lot of people reporting problems, but I don't see anyone confirming that Foundation staff has been informed in a proper way. If so many people are having such a problem, that might seem like a good idea. bugzilla. Since everyone is on east coast verizon apparently, it might be a peering issue. —TheDJ (talk • contribs) 01:49, 17 March 2014 (UTC)
I sent e-mail to ops over the weekend. Whatamidoing (WMF) (talk) 16:10, 17 March 2014 (UTC)
For what it's worth, I had an online chat with Verizon support tonight. They said that their techs had noticed the problem, and that I would not experience the problem tomorrow night, or ever again. Time will tell. I'll post tomorrow night how things are going around 9 to 10 p.m. Chris the speller yack 04:09, 17 March 2014 (UTC)
Thanks, Chris! (Worth a lot, I'd say.) I'll anxiously await tonight's developments. —Steve Summit (talk) 10:33, 17 March 2014 (UTC)
I add my thanks. Tonight is just about as bad as the past nights. I read Chris's post to mean the problem will be fixed by tomorrow night. We'll see. We also will see whether they just fix it for Chris or fix it in general. (I am not well informed enough to know whether than is possible.) Donner60 (talk) 01:38, 18 March 2014 (UTC)
Verizon did not fix the problem (as they promised), and they have been no help. Their techs only know how to monkey with the customer's computer. They want to mess with my wireless router's signal strength and take over my screen and keyboard. I told them "no way". I pinged Wikipedia, and it sent a 32-byte packet, and no packets got lost, so Verizon claims their network is fine. I can't get them to go to Wikipedia and retrieve a large page. I can't do much to help Wikipedia at this rate. Chris the speller yack 02:21, 18 March 2014 (UTC)
Still slow again for me tonight as well. I'll give it a try with Verizon Customer Support myself. —Steve Summit (talk) 03:20, 18 March 2014 (UTC)

I switched from Time Warner (100 over 50) to Verizon Fios (500 over 100) today (in NY), and when using Wikipedia and Commons it's much slower than the Time Warner service.-Godot13 (talk) 02:37, 18 March 2014 (UTC)

Hi folks, I'm Faidon from WMF's technical operations. Thanks for all of your reports and for identifying that Verizon is the common factor between all of you, this has been extremely helpful. The issues you're experiencing are most likely caused by network congestion, but our transit links with our ISPs are not congested, so it's likely something internal to the upstream ISP we use to reach Verizon (GTT, a tier-1 network) or something specific between Verizon and them. We've already mailed Verizon's NOC but we've had no reply so far. We were hoping that the promises made to their customers about the issue being fixed today would be true, but unfortunately apparently they didn't alleviate the issue.

I've just special-cased Verizon and redirected traffic to Verizon using another upstream ISP of ours (NTT America), so please do let us know if you're still experiencing problems today. We will continue the investigation and raise the issue with our upstream as well, in case there is something on their side. Thanks for your patience! Faidon Liambotis (WMF) (talk) 15:01, 18 March 2014 (UTC)

Update: Verizon hasn't responded to my repeated queries to both their operations & peering contact points. GTT confirmed the diagnosis of network saturation between them & Verizon during the evenings but informed us that it's not an operations issue they can tackle but rather a "policy" issue that they are in the process of addressing (as Level3 recently put it, a game of chicken. The workaround I placed earlier this week to go via NTT is still in place and will be in the considerable future, as we do not participate in these games. Faidon Liambotis (WMF) (talk) 17:56, 23 March 2014 (UTC)
Thanks, Faidon, things seem much better tonight, for the first time in two weeks. Actually, I'm getting lightning-fast response. I give you credit for fixing it. I only wish we had started you working on it sooner. Many, many thanks! Chris the speller yack 01:38, 19 March 2014 (UTC)
I am getting good response now at approximately 2150 EDT. Thank you. Robert McClenon (talk) 01:52, 19 March 2014 (UTC)
I also have gotten good response for almost three hours now - for the first time in the evening and early night hours for about two weeks, as well. Thanks to Faidon Liambotis (WMF) as well as to Chris and Steve for their help in working this out. Donner60 (talk) 03:59, 19 March 2014 (UTC)
I also got better performance last night. Can't say whether it was back to normal or not, but definitely much better. Thanks, Faidon. —Steve Summit (talk) 14:00, 19 March 2014 (UTC)
@Faidon Liambotis (WMF): I'd say this warrants a WMF blogpost about net neutrality, and the sending of a bill to the party in question for wasting staff hours (donor money) trying to figure out this problem. —TheDJ (talk • contribs) 18:32, 23 March 2014 (UTC)
Contrary to Netflix's PR claims, this has nothing to do with net neutrality. This (and Netflix/Cogent/Comcast's deals) are private agreements between large ISPs, sometimes even tier-1 ISPs like in this case, with no discrimination for the traffic that flows on top of these links (hence e.g. Wikipedia was affected, not just streaming video). This is nothing new: peering agreements that include traffic levels & ratios have been in place for decades now — Netflix's success and hence traffic incease is just aggravating the siutation and shedding more media lights into it. That being said, extortion practices of letting customers (on both sides: Verizon users, Wikimedia) suffer as means to negotiate a contract (the "chicken game") are bad business practices in my opinion, and will be definitely be taken under consideration the next time we renegotiate our contracts. Faidon Liambotis (WMF) (talk) 10:00, 25 March 2014 (UTC)

Running network diagnostics

Although it may seem like it's just Wikipedia that's slow, due to the network structure that ISPs use, it can still sometimes be a wider problem caused by a failure on the ISP's end. In order to help the engineers in ops determine where the problem is, it would be helpful if people who are experiencing this slowness could perform a network diagnostic using something like traceroute to the English Wikipedia and save the results to a text file.

Instructions:

  • On Unix-like systems, such as Mac OS X and Linux, run traceroute wiki.riteme.site.
  • On Windows open a command prompt and type in tracert wiki.riteme.site. If you're on Windows, you could also run PathPing by typing pathping wiki.riteme.site which provides more detailed results.

Be patient when running these commands, as they can sometimes take a long time to execute. Save the entire result of whichever command you run to a text file. You could run these commands when you're not having the problems as well, to act as a control. The people in ops should greatly appreciate having this information.

Disclaimer: I'm not in ops, I'm just a person who's had to diagnose these sorts of problems before.

--Dan Garry, Wikimedia Foundation (talk) 17:49, 17 March 2014 (UTC)

Category listing delay?

Recently I created {{old talk on redirect}}, which populates Category:Talk pages of pages converted to redirects. Except, when you look there, it doesn't. But if you look at pages where it's used (e.g. Wikipedia talk:De-adminship), the category does appear. Is this due to some delay in category listings being updated? — Scott • talk 12:24, 17 March 2014 (UTC)

Yes, it's a known delay for categories depending on changes in transcluded templates. A null edit of Wikipedia talk:De-adminship would force the category page to be updated with the page, but only with that page. PrimeHunter (talk) 12:36, 17 March 2014 (UTC)
Where a template is used to categorise pages, amending that template will not immediately recategorise all the pages that transclude that template, but instead it will create a job queue request. Until about nine months ago such template amendments would be processed in an hour or two; since then it's been much slower, and may take up to two weeks before all pages are properly recategorised. --Redrose64 (talk) 17:17, 17 March 2014 (UTC)
Coming back a little late on this one - thank you both. I see that there are various graphs available of the job queue length and processing rate, but is there anywhere that gives an indication of the expected delay (e.g. the up to two weeks to which you refer) without requiring any mental math? — Scott • talk 19:58, 23 March 2014 (UTC)
We don't know the expected delay, it's not predictable. In theory, it should take minutes. In practice, it doesn't. The only measurement that you can make is after the event; i.e. take a look at Category:Talk pages of pages converted to redirects at regular intervals, and see how long it takes to stabilise at the expected level of population. --Redrose64 (talk) 00:13, 24 March 2014 (UTC)
Example: this morning I found that Category:WikiProject banners with formatting errors had over 1500 members - it should be empty, but when it does have members, those should all be Template: pages. Checking, I found that most of the pages in the cat were Talk/Wikipedia talk/Template talk/Category talk - only two were actually in Template: space (Template:WikiProject Latin America and Template:WikiProject Latin America/testcases). Suspecting that the first of those was the culprit, I made this edit, and also WP:NULLEDITed the testcases, which caused the membership to drop by two, but nothing else happened to the cat over the next two hours. When I checked a few minutes ago, the cat was clear, so it all happened in less than five hours. --Redrose64 (talk) 12:42, 24 March 2014 (UTC)
Hmm, I guess you're right, it's more complex than I thought. Thanks for the explanation. — Scott • talk 13:16, 24 March 2014 (UTC)

I don't know if it's the same effect, but some changes to templates that result in recategorization of articles can take months to apply new categories to the articles. See the tracking at Help_talk:Citation_Style_1/Archive_4#Update_to_the_live_CS1_module_week_of_2013-11-03 for an example; it took 70 days for the new category to be applied to all affected articles. This number is not an outlier, either; articles are still being recategorized based on the most recent updates to the CS1 citation module, which were applied on 15 February, 37 days ago. – Jonesey95 (talk) 04:22, 25 March 2014 (UTC)

State of MathJax

The MediaWiki installed version of MathJax is v2.3. Nageh's script is v2.2, but has the added feature of automatically using your local STIX fonts. Does MW's v2.3 has an JS option to use my local fonts? — Edokter (talk) — 22:47, 21 March 2014 (UTC)

@Edokter: See gerrit:64527 and bugzilla:35498 —TheDJ (talk • contribs) 13:17, 24 March 2014 (UTC)
That is an abandoned change to make it selectable. v2.3 should automatically choose the local STIX fonts, but that has been removed or disabled in the current installation. Should I file a new bug report for that? — Edokter (talk) — 13:58, 24 March 2014 (UTC)
It started out like that, but then people started discussing and I really didn't want to get into that. So someone can make a decision in the bug ticket and submit a patch for that, and then I can approve, but i'm not going to do discussion in a review like we had inside that abandoned commit. —TheDJ (talk • contribs) 16:15, 24 March 2014 (UTC)
I don't see much of a discussion. The point is, we should not disable default functionality for MathJax; it should work as out-of-the-box: That is, local STIX font preferred, TeX webfont fallback. I will open a bug; I cannot submit a patch because I don't have a local repository for math. — Edokter (talk) — 16:41, 24 March 2014 (UTC)
bugzilla:63016. — Edokter (talk) — 16:55, 24 March 2014 (UTC)

Text align

v2.3 also changed its text-align to center (This is a change to MathJax config itself). There an RFC about this about having this changed back, but where is it? (A single line of CSS can fix this.) — Edokter (talk) — 22:47, 21 March 2014 (UTC)

No one? Who do I speak to? — Edokter (talk) — 09:11, 24 March 2014 (UTC)
Wikipedia_talk:WikiProject_Mathematics#Should_display_equations_be_centered.3F —TheDJ (talk • contribs) 13:17, 24 March 2014 (UTC)
In dire need of a close. — Edokter (talk) — 13:58, 24 March 2014 (UTC)

Scripts not loading

Is there a problem over scripts not loading. Since yesterday the loading of pages seems to be very slow and hangs once it gets to loading in user scripts, such as the date conversion script, called from the monobook.js file. Keith D (talk) 16:43, 23 March 2014 (UTC)

Firefox, Chrome (and probably other browsers) provide a network analysis tool under the "Developer Tools" so you could check which specific scripts or parts take a long time. --AKlapper (WMF) (talk) 10:16, 24 March 2014 (UTC)

css to uncollapse?

Is there some css I can put in my personal css space to show all "collapsed" things as uncollapsed when a page loads? NE Ent 21:34, 23 March 2014 (UTC)

Some time back, I had to disable Java and learned that it was necessary for the collapse thing to work. Perhaps you could write something so that the browser forgets Java when it comes to a convert template? Nyttend (talk) 02:57, 24 March 2014 (UTC)
You meant Javascript, not Java. --AKlapper (WMF) (talk) 10:13, 24 March 2014 (UTC)

No minor edit check box on mobile Wikipedia.

How come there is no"minor edit" check box on the mobile Wikipedia? -- Kndimov (talk) 22:19, 23 March 2014 (UTC)

Reply - I have noticed the same thing, but I do not have an answer for you. I also notice that the double redirect bots are running extremely slowly lately. --Jax 0677 (talk) 19:34, 24 March 2014 (UTC)
Probably because for the majority of users, it's not really that useful, yet takes up precious screen real-estate. Personally, i've always found the concept of 'minor edit' rather stupid actually and I notice that I've been checking it less and less (laziness wins). With regard to double redirects.. please don't drag non related topics into other topics. —TheDJ (talk • contribs) 19:54, 24 March 2014 (UTC)

JavaScript coders needed to deal with edit requests

Are there any JavaScript coders out there that can help to deal with the backlog at Category:Wikipedia protected edit requests? There are five requests in the category, all of them for JavaScript pages, and the oldest one is from 12 March. You don't have to be an admin to help, either. The main thing is the code is reviewed to make sure that it works and that it doesn't introduce any security risks, so reviewing it and noting your findings on the request page is just as helpful as making the edit yourself. If non-admins review the code, then an admin will see that review and can make the edit for you. — Mr. Stradivarius ♪ talk ♪ 03:56, 24 March 2014 (UTC)

I dealt with the obvious, but the others indicate some past problems and I don't have time right now to review them. —TheDJ (talk • contribs) 06:09, 24 March 2014 (UTC)

WikiTrust - Not Working? How do I get it to work? Who do I ask?

http://i.imgur.com/GOWiuks.png and https://wiki.riteme.site/wiki/Wikipedia:User_scripts | Under "Inline" and such. It's not working. Ging287 (talk) 19:54, 25 March 2014 (UTC)

I'm not sure it is supported anymore. I just tried the Firefox add on and it does not work either. --  Gadget850 talk 20:13, 25 March 2014 (UTC)
Could one of you put a note on the user script page saying such? So other editors don't have the same problems/questions as me? Ging287 (talk) 20:17, 25 March 2014 (UTC)
The end of WikiTrust was announced in early September 2013, ref this email thread from wiki-research-l. While it was suggested that others could take over the project, it looks like nobody stepped forward to do so. Regards, Nettrom (talk) 20:30, 25 March 2014 (UTC)
I don't know what it would take to make it work, but if anyone's interested, then s/he'll want to know that we've received a couple of reports that turning on WikiTrust makes VisualEditor disappear. I assume that this means that there may be more than one problem with the script. Whatamidoing (WMF) (talk) 21:24, 25 March 2014 (UTC)

Special:MovePage contains a useless double redirect caveat

WP:2R says that humans should not bother with fixing of double redirects, so I think that the following text above the page move form should be removed: Be sure to check for double or broken redirects. You are responsible for making sure that links continue to point where they are supposed to go. — Petr Matas 19:20, 23 March 2014 (UTC)

i think you are confusing between "we have machines that can fix it, so you don't have to bother fixing it yourself", and "we have machines to fix it. so you can carelessly create this error whenever you feel like it". the former clearly does not imply the latter. not bothering to fix such errors is one things, being careful not to *create* the error when moving pages is something else - i think the warning message should be there when moving a page. peace - קיפודנחש (aka kipod) (talk) 20:20, 23 March 2014 (UTC)
In that case it would be nice if the move form contained the following check box: Fix double redirects for me. — Petr Matas 16:37, 24 March 2014 (UTC)
That's not how it works. The MediaWiki server doesn't fix double-redirects; bots do. Bots don't do it because someone asks them to, they do it because they are programmed to. The checkbox would be meaningless. Anyway, the warning is still useful because bots can't fix all redirect errors; for example, sometimes people leave a page redirecting to itself, or to a page that redirects back to it. --R'n'B (call me Russ) 16:46, 24 March 2014 (UTC)
I see, but consider this: What prevents the MediaWiki server from keeping a list of recent moves, for which the checkbox was checked? A bot run every 15 minutes could use it then. I also think that cyclic and interrupted redirects cannot arise from page moves. The user's view is this: Hey, I don't want to spend my time fixing every single redirect to a page I just moved. You are the programmer, it's your job to find a solution. — Petr Matas 17:10, 24 March 2014 (UTC)
Reply - FYI, the double redirect bots are working EXTREMELY slowly these days. I think that only User:Xqbot is fixing all of the double redirects. --Jax 0677 (talk) 18:17, 24 March 2014 (UTC)
Actually, MediaWiki has this feature. It was enabled here for a while before being disabled. The checkbox read "Update any redirects that point to the original title". Tim Starling explained the feature a bit more on the mailing list. I'm not sure why it was disabled; I think it had something to do with making page move vandalism harder to clean up. – PartTimeGnome (talk | contribs) 23:26, 24 March 2014 (UTC)
Thanks to your information, I found Bug 15622, which says that MediaWiki is able to handle longer redirect chains now and suggests increasing $wgMaxRedirects as a solution, instead of fixing double redirects immediately. — Petr Matas 16:09, 25 March 2014 (UTC)
I would like to continue this discussion at Wikipedia talk:Double redirects#Proposal to increase $wgMaxRedirects. — Petr Matas 22:11, 25 March 2014 (UTC)

Problems with conditional table rows

I've been working on {{Drum corps show summary}} recently, and I've run into this problem: it can only have a finite number of rows hard-coded into it, so for a workaround, I added a parameter that outputs the same code without the headings or the ending brackets, effectively extending the limit on how many rows the template will allow. But when I split some of the cells in a row in half, and the last parameter in these split cells is left undefined (not when it's empty, though when it is that creates a different problem), the rows added after that using the template with no header do not display correctly. Here is an example. Gamma Metroid (talk) 21:35, 25 March 2014 (UTC)

Your sandbox currently transcludes {{Drum corps show summary}} inside itself, causing the second template to be part of the {{{place9}}} parameter. To solve this, you can add another parameter to omit the ending "|}" of the first table and then place two templates after each other. SiBr4 (talk) 22:00, 25 March 2014 (UTC)
I see Redrose64 is trying something else to make the template work. SiBr4 (talk) 22:01, 25 March 2014 (UTC)
Try it now. --Redrose64 (talk) 22:13, 25 March 2014 (UTC)
Yes, that's exactly what I wanted. Thank you! Gamma Metroid (talk) 02:08, 26 March 2014 (UTC)

Has GeoHack been migrated to Labs?

Does anyone know if the functionality hosted at http://toolserver.org/~dispenser/ghct has been migrated to labs? If so, MediaWiki:GeoHack.js may need to be updated as it references the toolserver link. 28bytes (talk) 22:03, 25 March 2014 (UTC)

I would conjecture that Dispenser himself might know. Matma Rex talk 22:14, 25 March 2014 (UTC)
Yes, it is on Labs now. Example. Note that the link in {{coord}} points there already. In the future, you can check if a tool is listed on the tool account list. πr2 (t • c) 22:19, 25 March 2014 (UTC)
@28bytes: seems I missed something. I didn't realize you were asking about the click track thingy. Sorry! ghct may not actually be on Labs, according to this post from Magnus Manske. πr2 (t • c) 17:34, 26 March 2014 (UTC)

Edit won't display

At the bottom of the page Talk:Macular degeneration, the last I can see displayed (on two different computers, one with Internet Explorer and the other with Chrome) is "Help needed ... [etc]", ending with "... increased risk of AMD." I looked at "View history" thinking to insert the editor and date info, but edit mode shows that this section is indeed signed properly, and is followed by a new non-displaying section, "Primary sources". This last section also does not display in the TOC. One thing that I thought was strange is that the OP's reply 5 minutes later to his original 13 January 2014 post was also signed properly with 4 tildes, but in edit mode these still show as tildes rather than being wiki-translated to name and date.

I'm not seeing anything that looks wrong to me in the formatting of this "Primary sources" section, much less why the signature in the previous section would also have been wiped out, when it did display properly before. If anyone can fix the problem, I'd be very curious to know how this happened. Thanks for any help. Milkunderwood (talk) 23:10, 25 March 2014 (UTC)

Hm. The problem appears to come from 1archie99 not properly closing his ref - but my trial fix isn't working. Milkunderwood (talk) 23:18, 25 March 2014 (UTC)
(edit conflict) I've fixed it. There was a <ref> tag missing its closing angle bracket, so the rest of the page got eaten up as part of the reference. I've simply commented out the reference, since it is a named ref, but there isn't a corresponding ref with that name with the ref's content. – PartTimeGnome (talk | contribs) 23:23, 25 March 2014 (UTC)
Thanks very much. Milkunderwood (talk) 23:26, 25 March 2014 (UTC)

Mass message not sending

Hi, I'm trying to send a mass message using this list: Wikipedia:MED/med250. It's not delivering though and nothing is queued. Am I doing something wrong? Thanks, Jake Ocaasi t | c 12:26, 26 March 2014 (UTC)

Moving protection settings

Do protection settings automatically move with a page with some sort of protection, even if moved by a non-sysop? Provided there are no sysop-only protections in effect? Lieutenant of Melkor (talk) 16:32, 26 March 2014 (UTC)

Prot settings move with the page, and are also copied to the newly-created redirect; but the prot log entries stay on the original page. --Redrose64 (talk) 17:31, 26 March 2014 (UTC)
I also updated Wikipedia:Moving a page#How to move a page (item 4, bulleted line). --Redrose64 (talk) 17:44, 26 March 2014 (UTC)

Tech News: 2014-13

Latest tech news from the Wikimedia technical community. Please inform other users about these changes. Not all changes will affect you. Translations are available.

Recent software changes

  • The latest version of MediaWiki (1.23wmf19) was added to test wikis and MediaWiki.org on March 20. It will be added to non-Wikipedia wikis on March 25, and all Wikipedia wikis on March 27 (calendar).

VisualEditor news

  • You can now double-click or press the ↲ Enter key on an image or template to change its settings. [62] [63]
  • Pages that don't exist will now show as red links in the edit mode. [64]
  • You will no longer be able to try to use VisualEditor on pages translated using the Translate extension, and you will see a warning if you try to edit pages marked for translation. [65]
  • You will now see a full warning, including the most recent log entry, when you try to edit protected pages with VisualEditor. [66]

Future software changes

  • Typography Refresh will be enabled for test wiki and MediaWiki.org users who use the Vector skin on March 27. For users on non-Wikipedia wikis, it will be enabled on April 1, and for Wikipedia users on April 3. If you don't use Vector as your skin, you will not be affected.
  • You will be able to use the Hovercards tool as a beta feature on all wikis from March 26.
  • You will soon be able to include the Whatlinkshere special page in other pages. [67] [68]

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

18:56, 24 March 2014 (UTC)

Blockquotes

It appears that Typography Refresh will be applied to Vector skin users on April 3. With the new VectorBeta CSS, the blockquote font size will change and the quote will be enclosed in fat quotes. See for example mw:Template:Quote. --  Gadget850 talk 01:03, 25 March 2014 (UTC)

This is not true as far as I'm aware. Those changes are in the Beta, but that doesn't mean they will be deployed. Steven Walling in the past has assured me that only these changes will be deployed and specifically Block quote changes will NOT be deployed. —TheDJ (talk • contribs) 09:15, 25 March 2014 (UTC)
So the beta that demonstrates the changes is not what is going to be deployed? What CSS is being applied? --  Gadget850 talk 11:08, 25 March 2014 (UTC)
Only CSS related to fonts will be deployed. — Edokter (talk) — 11:54, 25 March 2014 (UTC)
Yes, we're not going to include the following changes that (for now) appear in the beta:
  1. Blockquote style
  2. Thumbnail style
  3. TOC style
  4. Simpler external link style
These are potentially very good changes but they need work. The core of what we're shooting for is related to text readability and consistency across devices/operating systems, so it's tertiary to our goals. More information is coming soon in the form of a Signpost op-ed, watchlist notice, and blog post. Steven Walling (WMF) • talk 21:32, 25 March 2014 (UTC)
  • So why not fix these other things and then release it all in one shot as a working product instead of releasing half of it when it can then have developers loosing interest and having the community having to deal with a hack job half conceptualized idea? I think the community would prefer you have a fully working feature before releasing it... — {{U|Technical 13}} (t • e • c) 22:08, 25 March 2014 (UTC)
    (edit conflict) Indeed, the Typography Refresh beta has become a bit of a mish-mash of various experiments; it is not a single feature. The font changes that will be going live are a working feature. – PartTimeGnome (talk | contribs) 23:10, 25 March 2014 (UTC)
Actually there was so much discussion about the "creepy" features that were too prominently and too numerous that the point of typography refresh – typography – was not perceived sufficiently and therefore not discussed in all necessary depth. I think that although we had at least three iterations of this beta feature, typography was lost somewhere in between, not tested thoroughly by the community and therefore the result is probably still far from the optimum. Let's hope this will not again result in bad blood when this is now forced on everybody using vector skin.
@WMF team: Please restrict beta features to only one feature in future!
  • Make one change at a time.
  • Iterate with this one change and optimize together with the community until it really is ready for deployment.
  • Then deploy and see how the rest of the community reacts.
  • If there are problems back to iterating
  • Only if everything is working really stable continue with the next change.
Thanks, --Patrick87 (talk) 00:10, 26 March 2014 (UTC)

I'm not sure that's a fair assessment. If you look at the two Talk archives for the beta feature, you'll see many comments about the core typography changes. Font choice was hotly debated and analyzed in-depth with a qualitative scoring system, and there was a large amount of off-wiki debate on the public community developer mailing list, Wikitech-l. We went through three major iterations where we served different primary font stacks for the body copy and headings, experimenting with putting different font-families first. The version that's being released is very much the result of feedback from the community. Steven Walling (WMF) • talk 16:53, 26 March 2014 (UTC)

I didn't want to say that there was no discussions going on regarding typography, but I believe they got mixed up with other features a lot substantially reducing the overall efficiency of the beta feature process. I think that if typography and the other UI changes would have been separate beta features from the start we would have deployable code for both now, with higher quality than we have now, with altogether less discussion needed. I don't want to suggest that the result of typography refresh is an overall failure, but I think that the whole process was very inefficient, creating unnecessary workload for a suboptimal result. --Patrick87 (talk) 18:15, 26 March 2014 (UTC)
"I believe they got mixed up with other features a lot substantially reducing the overall efficiency of the beta feature process". Yes, this is a good point and something to correct next time. We need to avoid scope creep like that in the future, even if beta features are meant to be experimental. Steven Walling (WMF) • talk 19:41, 26 March 2014 (UTC)
It makes it damn hard to evaluate when you don't know what features are under actual consideration. --  Gadget850 talk 13:27, 27 March 2014 (UTC)

Wait a minute... The new blockquote styling is enabled now. Enable typography refresh and take a look. --  Gadget850 talk 15:29, 27 March 2014 (UTC)

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

--  Gadget850 talk 15:29, 27 March 2014 (UTC)

That is enabled in the beta feature only. The code that is rolled out only deals with the fonts. (And the other features will probably disappear from the beta.) — Edokter (talk) — 16:02, 27 March 2014 (UTC)
So what has been demonstrated is that due to creeping featurism the Typography Refresh has never had an actual beta test? Then why is the Typography Refresh being rolled out? The entire point of a beta test is to test the actual changes that are going to be made prior to rolling them out on a large scale. Nothing like this should be rolled out without actually testing it in a beta that has the actual features which are proposed to be rolled out. — Makyen (talk) 21:50, 27 March 2014 (UTC)
It is not unusual for beta programs to test out several features at once, then roll out those that satisfy demand while trowing out the rest. In this case, it ended up with the same feature set that it originally started out with: just the typography. — Edokter (talk) — 22:15, 27 March 2014 (UTC)
For a quick look at what's likely to change, first turn off the Beta Feature here at en.wp, and then look at the current style versus the expected style. (Don't forget to re-enable the Beta Feature if you want to follow the other changes.) WhatamIdoing (talk) 22:22, 27 March 2014 (UTC)
Edokter For many things, I can understand cutting out features from the beta in what is being deployed and deploying it based on testing which included features not in the generally deployed version. However, I have a few problems in this specific instance.
The first is that UI issues are often a gestalt from which it is difficult for many users to separate out specific issues. If they do so, then it is usually to select the one or two most significant issues to them. For UIs, issues are often things which take people time using the interface to generate good feedback. Often, if they are generating immediate feedback it is because there are significant problems for them in specific areas where they are immediately using the UI under test.
Second, the other issues introduced by the creeping featurism so significantly overshadowed any issues that might exist in what is being rolled out so as to make it such that the changes actually being made have had little consideration by those very few users who have used the beta. For me personally, I turned the beta on briefly to look at it. In doing so, I found that the TOC and blockquote changes were so wrong for me, that I just immediately turned it off and went to try the Monoblock skin to make sure I had a alternative if it was actually deployed. Yeah, for me those issues (and the max 715px width restriction, no longer in the beta) were so bad it just wasn't usable. I then went to look at the talk page and found that those items were going to be taken out due to others already objecting. I had assumed that there would be some amount of time in beta that would actually reflect what was being proposed for deployment. Obviously, I was wrong in that assumption.
Third, the present beta, as currently available days away from the change being deployed across Wikipedia still includes features which greatly distract from the ability to get reasonable feedback about the changes actually being made. As an example of this, note that the title of this subsection is "Blockquotes", a feature which is still enabled in the beta, but not going to be deployed.
It just feels that this is being pushed out to meet some schedule rather than being adequately tested. My feeling is that general deployment across Wikipedia should be delayed until there has been a beta that includes just the features intended to be deployed and allowing some reasonable time for users to try it and provide feedback. I note that the project has started to get some reasonable feedback specific to the fonts at Typography Refresh.
Frankly, I am not really for, or against, the Typography Refresh as I still, as of this date, have not had the ability to try using it over time in a live situation. — Makyen (talk) 04:53, 28 March 2014 (UTC)
Makyen, first off, thank you for the thoughtful feedback. I fully agree with you about points regarding mixing in features, and the way that most users always assess something as a whole. However, we really did get a lot of specific feedback that didn't have anything to do with the blockquotes, TOC, etc. The primary body content and header styles really were hotly discussed, both in many of the 100+ threads on mw:Talk:Typography refresh and in venues like some our largest public mailing lists (specifically Design-l and Wikitech-l, if you follow those). The fundamental font styles went through several releases with different settings tried out, and we moved forward with the current settings based on community feedback. Steven Walling (WMF) • talk 23:20, 28 March 2014 (UTC)

New image thumb design

Image thumbnail designs

I just discovered this under Preferences --> Gadgets --> Testing and development. It makes images look so much nicer, without the extra lines around them. Thank you to the people who developed it! SlimVirgin (talk) 03:49, 25 March 2014 (UTC)

The files are MediaWiki:Gadget-NewImageThumb, MediaWiki:Gadget-NewImageThumb.js and MediaWiki:Gadget-NewImageThumb.css; all were created by Edokter (talk · contribs). --Redrose64 (talk) 07:53, 25 March 2014 (UTC)
It is a testing gadget, part of my wish to create a new CSS framework, which has been delayed a bit. — Edokter (talk) — 10:30, 25 March 2014 (UTC)
I've added a thumbnail of the 3 variants that I'm aware of. (1) The Default. (2) Edokter's gadget. (3) The WMF Design Team's design, as seen in a few iterations of the Typography refresh; (pinging Steven and Jared).
I like both the alternatives, and would like to see any other options that have been previously discussed, or can be brainstormed. HTH. –Quiddity (talk) 00:36, 27 March 2014 (UTC)
I like the version of Edokter and liked his previous version with a stronger drop shadow even more. The Typography Refresh version without any border at all doesn't work out in my opinion – it's just too unstructured. --Patrick87 (talk) 00:59, 27 March 2014 (UTC)
Thanks for the feedback, this portion of the typography beta feature isn't graduating at this time so we have time time to iterate on it. Jared Zimmerman (talk) 01:13, 27 March 2014 (UTC)
Redrose64, thanks for the information. Edokter, I really love what you've done, so thanks again. The images are really popping off the page. Quiddity, thanks for posting those. I like the third option too, but Edokter's seems to lift the image more. SlimVirgin (talk) 01:29, 27 March 2014 (UTC)
You may notice the TOC and category boxes have been given the same border effect. — Edokter (talk) — 10:18, 27 March 2014 (UTC)
I see that now too. It looks good. SlimVirgin (talk) 19:18, 27 March 2014 (UTC)

Change in column functionality

Why have col-begin/col-break/col-end started behaving differently all of a sudden? BMK (talk) 19:40, 25 March 2014 (UTC)

Please provide details and an example. --  Gadget850 talk 19:47, 25 March 2014 (UTC)
Maybe it is related to Template talk:Multicol#Proposed Edit? Helder.wiki 19:52, 25 March 2014 (UTC)
AFAIK we didn't change any of the code in those templates: this was the only edit made as a consequence of that discussion. No other pages should have been affected. --Redrose64 (talk) 19:59, 25 March 2014 (UTC)
We have a nice thing called history pages... They work. But those 2 changes should not affect the rendering of the page. But yeah "different" isn't really a problem description that makes it easier to figure out what the problem is. —TheDJ (talk • contribs) 23:57, 25 March 2014 (UTC)
I was aware of the two recent changes to {{col-begin}}. What I was hoping to convey was that any recent changes to that template were not made as a consequence of Template talk:Multicol#Proposed Edit, which concerns {{multicol}} and {{div col}}. --Redrose64 (talk) 10:36, 26 March 2014 (UTC)

Sorry, I was hoping someone would just recognize what had happened without my having to describe it in detail. OK, up until a day or so ago, the following code: 

{{col-begin}}{{col-break}}
*List element 1
*List element 2
*List element 3
*List element 4
{{col-break|gap=4em}}
*List element 5
*List element 6
List element 7
{{col-end}}

Would result in a list such as this: 

List element 1          List element 5
List element 2          List element 6
List element 3          List element 7
List element 4

Now, it results in a list like this: 

List element 1                                                                 List element 5
List element 2                                                                 List element 6
List element 3                                                                 List element 7
List element 4

So the ability to control the separation of one part of the list from the other (using the "gap=" parameter) seems to have disappeared, and both parts of the list are presented at what seems to be a standard distance apart. Thus lists that fit in nicely to the left of an infobox, for instance, are now forced down to below the infobox, leave a whopping big block of whitespace. (Ironically, since the columnization of the list was done in order to reduce the whitespace in the article caused by a single column list).

Is that sufficient to help identify the problem? BMK (talk) 01:55, 26 March 2014 (UTC)

Yes. "{{col-begin}}{{col-break}}" creates invalid HTML. Because of this, the last part of col-begin gets stripped off. Before the last part was "width:100%". Now the last part is "role=presentation". So effectively for you width:100% is getting added all of a sudden. I do not consider this a bug, it's an incorrect usage leading to side effects. —TheDJ (talk • contribs) 08:21, 26 March 2014 (UTC)
Whether that's the case or not, the "incorrect usage" created the desired result, now it does not, so the large number of articles in which this is used are now badly formatted -- so "fixing" the problem did not help Wikipedia, it hurt it.

That aside, how can I best get the result I used to obtain? BMK (talk) 17:06, 26 March 2014 (UTC)

Why are the {{col-begin}}{{col-break}} on the same line? If you put a newline between them, does that fix it? --Redrose64 (talk) 17:59, 26 March 2014 (UTC)
They're on the same line because that was how I found I could control the spacing between the columns. And, no, putting them on separate lines does nothing, it was the first fix I tried when this came up. BMK (talk) 22:26, 26 March 2014 (UTC)
You mention a |gap= parameter, which I see is coded into {{col-break}} but is not mentioned in the documentation for that template. But I'm afraid that I can't work out what is being attempted here, since the above examples are not real-world. Please give an example (two or three would be better) of an actual article which uses {{col-begin}}{{col-break}} and {{col-break|gap=4em}} in the manner shown above, and where the intended appearance has changed. --Redrose64 (talk) 23:53, 26 March 2014 (UTC)
I'm not sure what you mean by my examples not being "real world", since they simulate as exactly as possible what happens on my screen using the code I referred to. I can point you to an article that uses the coding, and you would see the same result as my second example, but it is not possible for me to point to an article that showed what used to happen, because it doesn't happen anymore, due to some change in the functionality of the code.

In any event, take a look at the article Without Pity, in which the cast list uses the above code and, on my screen, with my resolution, used to live nicely to the left of the infobox. Now (with no change in the code, on my screen, at my resolution), the gap between the two columns of the list is very large, and is therefore pushed down to below the infobox.

I hope that's clear. BMK (talk) 02:29, 27 March 2014 (UTC)

When you used "List element 1", "List element 2", "List element 3" etc. for a list, that is an example which is clearly contrived for the purposes of demonstration. A real-world example would be a copypaste from an antual article where the problem occurs, or better still, a link to such an article. The presence of that infobox to the right of the list is significant, and means that now I have made this change, I can look at Without Pity and honestly state that I see a change; is that now back to how it was before? --Redrose64 (talk) 16:45, 27 March 2014 (UTC)
Hallalujah! Yes, indeed, that is what it used to do. Many thanks for tracking that down and fixnig it, it is much appreciated. BMK (talk) 19:11, 27 March 2014 (UTC)
@Beyond My Ken:, regardless of wether this now 'works' again, I cannot stress enough that using {{col-begin}}{{col-break}} like this is a BROKEN and incorrect methodology and you can thus NOT rely on it to be working in the future. Col-break needs to go on a new line anything else is simply not valid. What you want is the to either specify the width of the column, or at the very least, you want to change the width of the block. {{col-float}} might be an option for instance. —TheDJ (talk • contribs) 19:23, 27 March 2014 (UTC)
Thanks. I am not planting my boots in the mud or my head in the sand on this (choose your metaphor), once I understand a valid way to get the same result as I got before, I'll change the columnization of articles I've worked on as I come across them. I was simply happy that all those articles are not now displaying poorly because of the functionality change. I'll certainly take a look at col-float. BMK (talk) 01:42, 28 March 2014 (UTC)

Account creation block

I'm seeking confirmation that "Block account creation stops the user from creating a new account for 24 hours after the block is made" as described at Wikipedia:New admin/Blocking#User blocks.2Funblocks only disables that feature for 24 hours even if you're blocking the account indefinitely. This is the only place where it seems to state this, as at WP:HARDBLOCK (which is only for IP's but the only place that mentions account creation block but not how the mechanism works) it does not mention it and thus implies the account creation block lasts the duration of the time of the block (for example an indefinite block with that setting ticked would disable account creation indefinitely as well). Thanks! Mkdwtalk 18:26, 26 March 2014 (UTC)

HARDBLOCK applies when blocking IP addresses, when blocking a user AUTOBLOCK would be closest. Werieth (talk) 18:40, 26 March 2014 (UTC)
AUTOBLOCK is for IP addresses as well so not really closer. My initial question is not about that anyway but about the timer on the setting "block account creation" and conflicting information. I will probably need a sysop to answer my question but thanks for pointing that detail out. Mkdwtalk 21:54, 26 March 2014 (UTC)
There are two types of account creation blocks. The type you are referring to is caused by the autoblock functionality of mediawiki. When an account is blocked their are two boxes that are checked by default. Prevent account creation and Automatically block the last IP address used by this user, and any subsequent IP addresses they try to edit from. In some cases (spam, COI username) an account can be blocked and instruct the user to create a new account. In those cases the the admin would uncheck the Prevent account creation box, which would enable the user to create a new account after their existing account is blocked. It has the same effect as autoblock with a limited duration (24 hours). When making the same settings on an IP block it prevents account create for the duration of the block period. @Mkdw: hope that helps. Werieth (talk) 00:43, 27 March 2014 (UTC)
You can actually see this behaviour at the blocklist. If you were to select the "Autoblock any IP addresses used" setting while blocking an account the blocklist would state "Autoblocked because your IP address was recently used by (Username)". This block is always 24 hours and the target is always "Autoblock #(Number)" (The actual block is placed on one or more IP addresses, but since that information may not be shown publicly the autoblock entry is used to hide this).
If you were to block an IP address directly you could select the setting "Block account creation". This setting will prevent account creation for the entire duration of the block. In other words: If you select this setting and block the IP address for a week, account creation would also be blocked for a week from this address. Excirial (Contact me,Contribs) 12:01, 27 March 2014 (UTC)

Article creation by editor (Page creator tool)

Does anyone know the current link to check how many articles an editor has created? I would like to check my own creation stats. I seem to have lost the link for that, but I believe it was once on Toolserver and then Labs, tools.wmflabs.org/xtools/pcount/, but this one does not seem to be active. — Maile (talk) 13:04, 27 March 2014 (UTC)

Oh, I see. It was addressed here at the Pump on March 5, but still seems to be non-functional. — Maile (talk) 13:36, 27 March 2014 (UTC)
The user associated with the link you gave is locked. You can use Special:Contributions Alternatively, check out some of the stuff listed here:

Hope this helps. Feel free to visit my talk page. Jay Dubya (talk) 17:49, 27 March 2014 (UTC)

toollabs:xtools/pcount has been replaced by toollabs:supercount. It is still possible to list created pages using toollabs:sigma/created.py. The new Only show edits that are page creations option on Special:Contributions also has this functionality, but does not filter redirects, etc. Special:NewPages only works for creations since $wgRCMaxAge, whereas the list using created.py or Special:Contributions goes all the way back. toollabs:xtools/pages/ seems down too. πr2 (t • c) 19:05, 27 March 2014 (UTC)

Using wikipedia.org domain spelling bastardizations for phishing

So, I was a bit quick to the draw in my browser the other day and found myself going to wikipeda.org (2 i's instead of 3). What I found was a portal that looks to pseudo-randomly refer traffic to spamming and phishing affiliate pages, for example allclktrk.com which plays an audio file and attempts to phish users into downloading a fake "update" for adobe. I haven't had enough time to check and see if the audio file was part of an overflow attempt. I'd be really surprised if it wasn't. Sometimes if you're lucky you get looped through a couple of extra affiliates and end up somewhere like a landing page on intuit's (real) web page.

They forward subdomains using a wildcard, for en.wikipeda works but also stuff that we wouldn't cover like cn.wikipeda.org or isuck.wikipeda.org. The domain is registered by Jasper Developments Pty Ltd, a web design firm in Australia. (note: I am not affiliated with them, and in fact I've never heard of them) http://reports.internic.net/cgi/whois?whois_nic=wikipeda.org&type=domain

I have some additional data and would be happy to provide more. There are strong and easy remedies to deal with domains outside of the foundation's control but that are preying on Wikipedia users in this manner. I am happy to discuss further so we can figure out how to best protect users that may not be technically proficient. While I have a significant amount of professional experience in network security, Im not interested in selling my services; just trying to protect other users. Thanks. Jay Dubya (talk) 18:06, 27 March 2014 (UTC)

You can send a mail with details to legal-tm-vio at wikimedia.org and maybe the legal team can file a case to do something about it. Technical information that might help protect users can be reported to security at wikimedia.org —TheDJ (talk • contribs) 19:40, 27 March 2014 (UTC)

Downloading to PDF

I'm working with a group of students who want to download their sandboxes in PDF form, using the link in the sidebar. However, even after trying this on multiple computers/setups, we've found that some of the references do not appear in the PDF version, even when they are part of the article body (ie. not in any template that should be excluded from download). For example, User:CodyG123/sandbox has 10 references, but when downloaded has nine, and two of those are part of the sandbox template. Anyone know what the problem is? Nikkimaria (talk) 01:36, 30 March 2014 (UTC)

My testing of your example shows that the PDF fails to include the three named references which are first used in the lead but defined later. If their definition is moved to the first use then they are included. I don't know whether this is a general error in PDF's. The sandbox "references" are caused by url's in {{User sandbox}} and can be avoided by removing the template. PrimeHunter (talk) 02:55, 30 March 2014 (UTC)
Your talk page mentions another example of missing PDF references apparently at User:Yangtana Li/sandbox. I got none of the 23 references. I kept simplifying the page but didn't get any reference until I removed the citation template from it.[69] It's annoying to test this when you can only download saved pages and not previews. I stop now. PrimeHunter (talk) 03:42, 30 March 2014 (UTC)
It's a known problem, and has come up on this page several times in the past, the most recent being Wikipedia:Village pump (technical)/Archive 124#Re "Download as PDF" function. --Redrose64 (talk) 08:33, 30 March 2014 (UTC)

Template "E" goes to redirect page

If you visit Template:US Judiciaries (or any page that contains this template) and hit the "E" on the top left (part of the V·T·E), you are taken to the edit page of Template:USJudiciaries. I assume this is a mistake, some bug when moving templates. Choor monster (talk) 12:09, 30 March 2014 (UTC)

 Done You're right, the name parameter was wrong, so the edit link didn't work correctly. I fixed it. VanIsaacWScont 12:28, 30 March 2014 (UTC)

Template:Columns-list and "="

In this edit, I've added Template:Columns-list to a list. This required editing in not only the two places expected (opening the template at the start, closing it at the end) but also replacing an "=" with "&#61;". Without this additional fix, the entire list would display as just the single character "2".

It wasn't that hard for me to locate the problematic character as I dimly recalled that "=" had caused trouble with some other template a while back.

I'm pretty much ignorant of template processing, so shan't tinker with the template. -- Hoary (talk) 12:38, 30 March 2014 (UTC)

Passing an "=" to any unnamed template parameter always requires a little care. The easiest way to handle this is to start the parameter with |1= (or |2=, depending on which parameter is used), or use {{=}} instead of a regular "=". Or you may use {{div col}} directly so you dont have to use parameters. — Edokter (talk) — 13:23, 30 March 2014 (UTC)
Aha, "{{=}}". I'd forgotten about that, if I ever knew of it. It takes no fewer keystrokes than "&#61;"; but it doesn't seem to call for a <!-- hidden comment explaining it --> whereas "&#61;" does, so its use seems a good idea. Thank you! -- Hoary (talk) 00:24, 31 March 2014 (UTC)

User talk page kinda broken

I am trying to notify @Thardin12: that I placed a GAN of theirs on hold but when I went to edit their page I noticed several delivered messages that were not showing up when the page was loaded. Can someone take a look at this? LazyBastardGuy 19:33, 30 March 2014 (UTC)

been wondering about this too. i get notifications all the time and they never show up. Thardin12 (talk) 19:35, 30 March 2014 (UTC)
Can you please be more specific? What are the exact steps to notice this error? πr2 (t • c) 19:38, 30 March 2014 (UTC)
Could it be a Cache issue? Werieth (talk) 19:40, 30 March 2014 (UTC)
 Done - it was a broken HTML comment, now fixed.--JohnBlackburnewordsdeeds 19:41, 30 March 2014 (UTC)
(ec) Imporperly closed HTML comment ("--!>"). Fixed now. — Edokter (talk) — 19:42, 30 March 2014 (UTC)
Thank you. LazyBastardGuy 19:43, 30 March 2014 (UTC)
thanks a ton! Thardin12 (talk) 19:46, 30 March 2014 (UTC)

Automatically prompt editors before saving common mistakes

Tracked in Phabricator
Task T7984
Tracked in Phabricator
Task T23798
Tracked in Phabricator
Task T56906

There are certain common errors that editors make that are often missed when saving before previewing a page, for example, adding a reference without including a closing </ref> link, adding reference links with out a {{reflist}} tag, or creating a link to a disambiguation page. I propose that, in the same way that an editor will be prompted if they attempt to save certain templates that must be substed, an editor attempting to make a save that would introduce an error of these types should get a notice before saving, saying something to the effect of "This edit will add a <ref> tag without including a closing </ref> tag. Do you wish to continue?", or "This edit will add a link to the disambiguation page, Phoenix. Do you wish to continue?" The editor would then be given the option to go ahead and save despite the error, or to return to editing in order to fix it.

I believe that such a system would help prevent a lot of maintenance fixes from being required in the first place, particularly with respect to disambiguation links, which most editors can not tell are ambiguous without clicking on the link. Cheers! bd2412 T 17:36, 24 March 2014 (UTC)

I imagine this would be quite the technical feat and would slow down the save page time considerably as every save would need to be run against the list of errors. –xenotalk 17:58, 24 March 2014 (UTC)
  • Sounds like something that an edit filter could do. I don't foresee it as too big of a deal to code a couple up, but I'm not sure it would be supported by the community. It may overly frustrate new editors is my biggest concern. Worth discussing though. — {{U|Technical 13}} (t • e • c) 19:30, 24 March 2014 (UTC)
    • @xeno, we are apparently already doing this, or something like it, when we cause this kind of alert to be issued for certain unsubsted templates, and for that matter for a fairly enormous list of blacklisted websites. For the latter, the page just won't save at all while the link is on the page. @Technical 13, I thought about this, but I think that by the time a user gets around to using reference tags, they probably know their way around enough that they won't be put off by an alert. With respect to disambiguation pages, it's just such an enormous problem, I think it's worth it to educate people early and often that they should avoid linking to these. Perhaps a warning could be tailored to specify a handful of most frequently linked disambiguation pages, like heavy metal, rock, English, Spanish, Amazon, etc. I asked about doing something like this through an edit filter once and heard nothing back. bd2412 T 23:38, 24 March 2014 (UTC)
      • Well, I'm no expert, but I doubt the edit filter could handle things like this without running into performance/condition limit issues. Things like dablink detection would be impractical, as the edit filter has no way to tell whether a link is to a dab page or not; it would have to check against a predefined list of pages, which is fairly unmaintainable. Writ Keeper ⚇♔ 23:50, 24 March 2014 (UTC)
      Blacklisted websites are a special case that use the Spam-blacklist rather than the edit filter. I don't think the edit filter could cope with the large number of sites that are on the spam blacklist. – PartTimeGnome (talk | contribs) 23:56, 24 March 2014 (UTC)
      • @User:Writ Keeper, I don't see why a predefined list of disambiguation pages would be at all difficult to maintain. I have been fixing dabs for nine years now, and have a very clearly defined list of a few dozen pages to which links are persistently made, generally names of major language/nationality groups (e.g., German, Swedish, Japanese), names of music genres having competing meanings in other fields (rock, pop, swing), and a few other usual suspects (Phoenix, Georgia). bd2412 T 01:14, 25 March 2014 (UTC)
I may support the edit filter idea for simple things like ref syntax. For DABs, a userscript may be better, though you would need to opt in to gain benefit. We already have a couple userscripts for detecting DABs on a page. One could probably be modified to detect them while editing a page. —PC-XT+ 05:37, 27 March 2014 (UTC)
  • Many/most people ignore warnings and save text: A wikitext syntax checker for WP should be an extra button "[Check_format]" near "[Show_changes]" but we know, absolutely, how the red-error messages are often ignored, as with the wp:CS1 Lua-based cite templates, with messages issued in March/April 2013, but most errors were still left in thousands of semi-major articles all year. Plus, some pages were edited over 150 times, and get this: by experienced editors who also left the cite errors, with glaring red messages in those pages all year. The pattern is quite clear: the people who edit most Wikipedia pages do not proofread those pages, or care enough about other issues. Instead, the user-scripts with JavaScript seem to be the best tool for users who actually proofread (part) of the text. For everyone else, several Bot-assisted tools should be used, while edit-filter warnings might make people cancel the edit. However, a "[Check_format]" button will likely be offered about 10-20 years from now, when most wp:edit-conflicts are also auto-merged in last-in-first-out (LIFO) order, perhaps with simple weave merge to retro-fit changes to moved paragraphs. The power users have made it abundantly clear, they are unlikely to use the extravagant, cumbersome VisualEditor, which most newcomers have also disliked, in favor of the wikitext source editor, and hence, a wikitext syntax checker, with a user exit to detect common dab pages, will be implemented when the developers run out of distractions. -Wikid77 (talk) 07:27, 27 March 2014 (UTC)
The citation errors are a bad example and a poor comparison. The significant majority of red error messages generated for citations only show up within the references section. Such errors show nothing while editing a section of an article, even when previewing the changes made. If one wants to see if any errors were caused, the editor has to specifically add a dummy {{reflist}} to the end of the section and then preview. Once any errors are taken care of, the dummy {{reflist}} must then be deleted. If editors were actually informed of these errors while editing, or previewing, then many more editors would fix the errors. In this case, the issue is not that editors don't care, it is that the errors are not presented to the editors in a manner that is effective. If the resulting references were easily available for editors to see while in the edit-preview-edit-preview-save cycle it would at least enable editors to have the possibility to know about any error to be able to fix it. I care about citations, but I have to put specific extra effort into going and looking for such errors while editing a page. There is a huge difference between prominently showing the editor a warning that there is a problem and asking for confirmation to continue vs. the indications of problems currently displayed by the citation templates. Frankly, I don't consider the two situations comparable. I don't believe it is reasonable to draw any conclusions about editor apathy from a lack of fixing errors which are displayed in an manner such that they are can only seen by editors if the editor puts out significant extra effort to look for the errors. If we want editors to fix errors, the editor needs to know that the error exists. — Makyen (talk) 13:23, 27 March 2014 (UTC)
I would really like an extra <references/> at the end of the section in preview mode. I don't think it would matter if it was blank, so detection may not even be needed. It shouldn't be used for the whole page, though, since that actually needs a reflist tag to show one. The appended tag could be separated, somehow, to avoid confusion. —PC-XT+ 19:06, 27 March 2014 (UTC)
I would also like to have the references displayed when previewing the edit of an article section. Personally, it would same me quite a bit of effort. From an overall Wikipedia point of view, I think that having such would cut down significantly the number of referencing errors and save considerable effort for editors both in initial entry of references and in having to go through an clean them up later. — Makyen (talk) 22:05, 27 March 2014 (UTC)
User:Kaldari will know more about what's possible here than I do. The link tool in WP:VisualEditor now sorts pages according to whether they are dabs or redirects, but I'm not sure whether it's possible to do something similar for wikitext. Whatamidoing (WMF) (talk) 19:09, 31 March 2014 (UTC)
Actually, such a feature already exists in the wikitext editor, but only if you use the link tool in the toolbar (which no one does). It would also be possible to add functionality to the AbuseFilter extension to allow it to check for links to disambiguation pages and show a warning (or extend the Disambiguator extension to do the same) when an editor clicks Save. There would likely be a performance hit on save, but I'm not sure how bad it would be. Kaldari (talk) 19:20, 31 March 2014 (UTC)
  • You could use {{Reflistp}} for seeing the references in a section (which is hidden and categorized if you accidentally save and leave it there) and follow the tracked bugs for the fixes for many of these things on Bugzilla... — {{U|Technical 13}} (t • e • c) 21:15, 31 March 2014 (UTC)
  • There's already a sort of way to do this for Lua scripts or templates: just make your script return a dead blacklisted link to, say, Encyclopedia Dramatica (www.encyclopediadramatica.com) in its error message. The edit filter will refuse to save whenever this message is displayed. Then you can add an override parameter to your script to suppress the link from being displayed if you really want to save with the error. Wnt (talk) 21:29, 1 April 2014 (UTC)

Parser function calls on List of PlayStation 3 games

I was first alerted to this problem through an edit request, specifically to "fix the script error in the line for Resident Evil 5". The error message reads "Lua error: Too many calls to mw.language:formatDate()." I'm guessing this has to do with the date formatting done by {{vgrtbl}} used to format the release dates. What, if anything, can be done about this? Some searching reveals that similar problems have been brought up before. Anon126 (talk - contribs) 01:05, 25 March 2014 (UTC)

@Anon126: Some optimization no doubt can be done (use fewer and less complex templates), but when you build a jenga tower as high of the roof, expect it to collapse. I suggest building multiple towers, or choosing a different technology (not wikitext, but wikidata for instance) to build your tower. But consider replacing dts template with data-sort-type and data-sort-value attributes for instance. Should remove a bit of the complexity already. —TheDJ (talk • contribs) 09:56, 25 March 2014 (UTC)
Don't split the page or mess with the module for now. I have a fix in gerrit that will address this the right way. Jackmcbarn (talk) 22:10, 27 March 2014 (UTC)
@Jackmcbarn: That reminds me, ping me on IRC on Wednesday if it doesn't get merged before then, so it can make it into 1.23wmf21. Anomie⚔ 13:11, 1 April 2014 (UTC)
@User:Anomie: Great. Can you close bugzilla:47887 while you are at it? That bug is about the exact same thing as jackmcbarn's patch.--Snaevar (talk) 02:12, 3 April 2014 (UTC)

Font format messed up in common template

{{Val}} has started forcing numbers to display in a monospace font, contrary to other templates such as {{gaps}} and making it an eyesore in our articles (especially when tables randomly display different numbers in different sizes). But I can't find the dependent template where the change was made. Can anyone help? — kwami (talk) 04:47, 28 March 2014 (UTC)

While I was looking, it seems to have been fixed. —PC-XT+ 06:49, 28 March 2014 (UTC)
I still don't know what caused it. Some CSS change? No relevant templates were edited during this time, that I can find. (I checked Special:RecentChanges back to midnight UTC.) —PC-XT+ 07:08, 28 March 2014 (UTC)
No, it's still messed up. I just tried it out to make sure it wasn't a caching problem, and it still forces a monospace font. — kwami (talk) 08:24, 28 March 2014 (UTC)
How about an example? The following seem to use the standard font for me:
  • {{val|21563.252564425}} → 21563.252564425
  • {{val|1.234|+0.005|-0.006}} → 1.234+0.005
    −0.006
Johnuniq (talk) 08:47, 28 March 2014 (UTC)
The two don't match. At left is my browser font, at right the one forced by the template. The digits on the right are twice the size of the ones on the left.
This should be what I see one the left. I don't know which font I'm seeing on the right, but maybe it's the same for both of us:
  • {{val|21563.252564425}} → 21563.252564425
— kwami (talk) 10:12, 28 March 2014 (UTC)
I think I know what you see (but not certain); There is CSS in place (for a few weeks now) that forces digits in {{val}} to display as tabular, lining numerals as opposed to proportinal non-lining numerals. They behave as monospace, but they are showing in your default font, just in the lining variant. This is done because val is often used in tables and scientific notations where non-lining, proportional numerals were detrimental to formatting. Fonts like Candara and Georgie use old-style (non-lining) numerals by default. Below example shows what effect this CSS has:
  • 21563.252564425 vs. 21563.252564425 (Candara)
  • 21563.252564425 vs. 21563.252564425 (Georgia)
This is done by use of the digits class in Common.css. Hope this helps. — Edokter (talk) — 11:18, 28 March 2014 (UTC)
I see. In other words, it's like {{Allcaps}} for numbers. This still needs to be reversed, or at least made optional, because it screws up the formatting: Graphically, it does not match numbers that aren't formatted with Val, nor does it match Gaps, Convert, or other number templates. Using Val for everything is not a solution, because Val can't handle everything. It would be fine to have this as an option, say in a table where all numbers are formatted the same, but not as the default for text or info boxes where it's mixed with other formatting.
One example of the problem is that we recommend Val at the MOS to get certain formatting effects, but now Val does not produce the recommended formatting. — kwami (talk) 00:41, 29 March 2014 (UTC)
Which MOS are we talking about? I am aware there are many more templates that may benefit from this; all you need to do is add the .digits class to the template, or even the table. Note that this was done specifically to counter formatting issues caused by fonts with old-style numerals. Candara and Georgia are the most notable. Not many other sans serif fonts even have these; you just happened to pick a font that does. Try using Calibri instead, and you will notice all digits are the same again. If you want to keep Candara, I can give some CSS to counter it. — Edokter (talk) — 01:11, 29 March 2014 (UTC)
MOS:NUM. BTW, although they use Val in their examples, they've enclosed it in further formatting (the brown and green) that reverts the effect of .digits class.
Why should we force browsers to display a certain way when it's unnecessary, or make users pick a font they don't like? I edit here, but most of our readers do not, and are not going to start adding to their CSS just for when they're on WP. Most of the time it's not important to have tabular figures, and where it is important, we could have an option for it. The whole reason I chose Candara as my default font is that I DON'T WANT NUMBERS DISPLAYED IN ALL CAPS LIKE THIS. IMO they look bad, and they're more difficult to read. — kwami (talk) 01:40, 29 March 2014 (UTC)
The {{xt}} templates do not cancel out the .digits class (otherwise, you would not complain). I have to say, you are probably one in a million to have such a default font. I was thinking about applying the same to example text, as I despise how Georgia uses old style numerals; I truly believe it hurts readability. Never the less, I can try disabling the lining (caps) while maintaining tabular display and see how that works out. — Edokter (talk) — 02:09, 29 March 2014 (UTC)
As it turns out, Georgia (the font used for examples) does not support tabular display unless lining is also enabled. That means examples using {val} have non-aligned numbers. I'll leave that be for now, as {val} in example text rarely needs alligned (sub/sup) numbers. — Edokter (talk) — 02:29, 29 March 2014 (UTC)
Thank you, that looks so much better! For me, old-style digits are more legible because you can recognize numbers by their shapes, as you do words, without having to look at each digit individually. That's what makes text like this more legible than all-caps. But the reason it was an eyesore was the random mixture of old-style and tabular in text and tables. Since we're never going to template all numbers in our articles (and given the limitations of the templates, we can't template them all), that would be an eternal problem. — kwami (talk) 03:40, 29 March 2014 (UTC)
I'm confused by the mentions of "all caps" in relation to numbers. Letters have two main forms: uppercase (also known as capital letters - "ABCD") and lowercase (or small letters) - "abcd". Numbers have only one form - "0123" (if I type ⇧ Shift+4 I don't get a variant on the figure 4, I get the dollar sign $) and so the concept of "capital numbers" is surely meaningless. --Redrose64 (talk) 10:19, 29 March 2014 (UTC)
Redrose64, see Text figures. Kwami, I cannot guarantee the current situation will remain. If situations come up with the {{xt}} templates that involve text figures messing up the display, I may have to re-enambe the lining. Also, there is a chance that the font used for example may be changed to Times, which does not have text figures (meaning they only have 'upper case' numbers). — Edokter (talk) — 13:45, 29 March 2014 (UTC)
Why not add a lining option, then? It seems overkill to change the entire project because of the rare instances that may need it. — kwami (talk) 13:59, 29 March 2014 (UTC)
It is not as rare as you think, just look at Template talk:Val. I can move the digits class to just the {su} part. But in order to Fix Georgia, I will have to re-enable lining again. — Edokter (talk) — 14:41, 29 March 2014 (UTC)
From my reading of Text figures, it seems that it's not really a capitals/lowercase issue, but a variation of the font family which causes use or non-use of ascenders and descenders. In a few of the examples above, I see variation in font family: in that provided by kwami at 10:12, 28 March 2014, the right-hand side is normal, the left-hand side is different. In the case of the examples by Edokter at 11:18, 28 March 2014, the fonts on left and right are the same, but differ from the rest of the page. In all other cases, I see the same font on the right as the one on the left, and it's the same as normal text. I presume that whatever font is intended, my computer hasn't actually got it and so my browser is falling back on something that it does have, per Basic Font Properties. --Redrose64 (talk) 15:26, 29 March 2014 (UTC)
The above example no longer shows the difference becuase I limited the use of the digits class. If you have Windows, you should have both font used there: Candara and Georgia. Here they are hardcoded:
  • 21563.252564425 vs. 21563.252564425 (Candara)
  • 21563.252564425 vs. 21563.252564425 (Georgia)
— Edokter (talk) — 15:41, 29 March 2014 (UTC)

Aargh! You just added .digits to {su}, didn't you? Now we're back to the situation that created the last, huge argument, where assymmetrical uncertainties like 123+456
−789 is screwed up (cf. 123+456
−789). Literally half of all instances of this on Wikipedia (I've counted) are due to my edits, and last time I reverted them all so that our tables and infoboxes wouldn't look horrible. We debated how to handle this for weeks, and finally came to consensus. Could you just allow that hard-won agreement to stand, and revert this edit? — kwami (talk) 23:17, 29 March 2014 (UTC)

I see absolutely no difference between 123+456
−789 and 123+456
−789. Moreover, their fonts are just the same as the rest of the page. --Redrose64 (talk) 23:22, 29 March 2014 (UTC)
Depends on which font you're using. To me, in the first case the super- and sub-scripts look like they've been enclosed in < code > formatting. We debated this for a month. The resulting consensus shouldn't be unilaterally changed like this. — kwami (talk) 23:24, 29 March 2014 (UTC)
Kwami, I must say this, but 99.9% of our readers are not using a font with old-style numerals like you do. Are you telling me that whole discussion was a result of you using a non-standard and non-common font? And have you been reverting stuff based on what you see on your screen as opposed as to what the other 99.9% see? If that is so, please stop. Practically every participant in that discussion is using regular font with lining numerals, and their main problem was that they did not line up horizontally, which is why they were using monospace fonts in the first place. I fixed that by disabling the kerning, so that the assymmetrical uncertainties would show in at least in the same font. However, I found that did not fix Georgia, which is our main font used in example text. So I found a ways to make Georgia behave as well, but it invloves forcing numerals to show in 'upper case'.
The only way I can help you is to provide some CSS so that Candara wil use old-style numerals while maintaining horizontal alignment (which is not possible in Georgia). I will need to know your browser and skin. — Edokter (talk) — 23:45, 29 March 2014 (UTC)
I don't know what you mean by a "non-standard font". Candara is a default font in Windows (or at least MS Office, I forget which), so it is extremely common. I don't know what %age of people have the same problem I do, but it looks like you're just making numbers up.
If the specific font formatting of our examples is the problem, can't we fix it in the examples, rather than forcing that solution on the whole encyclopedia?
And looking at Candara vs. Georgia, it appears that adding digits class does not fix the problem in Georgia anyway:
  • 21563 +1111
    −9999     vs. 21563 +1111
    −9999     (default font)
  • 21563 +1111
    −9999     vs. 21563 +1111
    −9999     (Candara)
  • 21563 +1111
    −9999     vs. 21563 +1111
    −9999     (Georgia)
Georgia looks identical with and without the class, so I'm confused as to what it resolves. — kwami (talk) 00:18, 30 March 2014 (UTC)
Kwami, Candara may be installed by default in Windows, but no browser has ever used it as a default sans-serif font. You made that change, but you cannot expect that enyone else has. I am not making anything up; I consider myself quite knowledgable when it come to web typography. The fact is, I am not forcing anything to the encyclopedia, other then making numerals line up. For the 99.9% that means they see the digits as they have always seen them, but with the same width (as most standard sans-serif fonts used by web browsers do not use old-style numerals). Those 0.1% that do use a font with old style numerals will see lining numerals instead. I have changed the examples to demonstrate the problem more clearly. Georgia should show lining (upper case) numerals with the class.
April 3rd will see the introduction of the new typography, which may startle you, as it will probably force Arial as the default font on your PC. Now everything is fixable, I just need to know what browser and skin you are using. — Edokter (talk) — 00:39, 30 March 2014 (UTC)
Firefox, default skin.
Unless you've actually done a survey of who has the same issue as I do, you made up the figure of 99.9%. You can't make stuff up and then take issue when I object that you're making stuff up.
"Georgia should show lining (upper case) numerals with the class". No, it doesn't: Your change to ones and nines makes it all the more obvious that the digits do not line up on either side of the "vs". So, again, since your fix doesn't actually fix anything that you've shown, but does interfere with the reader's ability to choose how their browser displays, what's the point?
Also, what's the advantage of moving digit class to the {su} part only? Wouldn't it be better to have the whole number display the same way? — kwami (talk) 05:21, 30 March 2014 (UTC)
This is what I see
If you don't see a difference in the above example, then you should definitely not even see any difference in {val} either, and you are just complaining about absolutely nothing. Are you trying to trip me over or something? OK, last time... do you see any difference now in the top line? (the rest may see a difference in spacing). — Edokter (talk) — 12:46, 30 March 2014 (UTC)
Of course I see a difference! But the difference is in Candara. I don't see a difference in Georgia. So, from my POV, you've messed up my browser defaults, but you haven't done anything to resolve the issue you're trying to fix.
What you see for Candara is exactly what I see. However, what you see for Georgia is not what I see. What I see is Old Style on both sides: The "fixed" digits on the right look exactly like the unfixed digits on the left. So you changed the Candara from Old Style to tabular, but had no effect on the Georgia, which is still Old Style. It would appear that your fix isn't going to work for many people. It's not like FF on Win7 is an unusual combination.
Just to be clear, let's number the examples like this: .    For (2), (3), and (5), I see what you see. But (6) looks just like (3). If anything, the discrepancy in width I see between the ones and the nines is a bit greater, even in supposedly "tabular" form: The Georgia nines are 11% wider than the ones in your screen shot, but 22% wider on my display. That's true on both the left and the right.
[Also, (1) and (4) look like (2) and (5), given that's my default font.]
Since Georgia is so difficult to work with, maybe the solution is to choose a different font for our examples, and let people *choose* whether they want an Old Style font? — kwami (talk) 19:54, 30 March 2014 (UTC)
Well that is new, and makes no sense. What is you default serif font? And in what font do you see example text? If you see that in Georgia, you should not see uppercase numbers in example text... yet that is exactly what you complain about in MOS:NUM(!) So forgive me for being so confused... I want to help anyone, but I have spent way too much time on this alreaady, given your default font is rather exceptional. You know what? I am going to give you some custom CSS that should simply cancel the lining numerals that you find so distracting. That should hopefully put this to rest. — Edokter (talk) — 20:25, 30 March 2014 (UTC)
And regarding a different font for examples, I have proposed changing it to Times New Roman, but that font has no old style numerals, so you'd end up with the same problem. — Edokter (talk) — 20:29, 30 March 2014 (UTC)

My default serif font is Palatino Linotype. Yes, your example appears to be Georgia, and correct, the examples at MOS:NUM are old style digits. However, we don't use Val at MOS:NUM, so what you're doing here has no effect there.

Break

I don't understand. Since you know that the examples at MOS:NUM do not display tabular digits and do not line up, why have you set Val for tabular digits? That screws up Candara, but has no effect on Georgia, and has no effect on the MOS. And why set Val for tabular digits only some of the time, so that different parts of a number conflict?

I also don't understand about TNR. If it doesn't have OS digits, wouldn't that be exactly what you want, since it would avoid the problem?

As for your adjustment of my CSS, now Candara displays tabular Old Style digits, which is a good result. Georgia, however, is still messed up. So, (1) wouldn't that CSS fix be good to add to the WP default CSS, so that everyone gets the benefit, and (2) how does any of this address the supposed problem, that Georgia does not have tabular digits?

Here are the previous examples, but using the Val template (this after you installed my CSS, which allows lining/tabular spacing, but keeps OS forms):

  • 21563+1111
    −9999     vs. 21563+1111
    −9999     (Candara)
  • 21563+1111
    −9999     vs. 21563+1111
    −9999     (Georgia)

The digits class makes no difference in Georgia. In Candara, the digits class makes no difference to the {su} part, of course, but does affect the width of the one in the main part. In Georgia, it makes no difference at all. Also, in Candara, the super- and sub-scripts are tabular Old Style digits. In Georgia, they are non-tabular Old Style digits, the same as they were before you adjusted my CSS, and the same as they are (and were) at MOS:NUM. So, with all this work, you've corrected the display for a single person (me), but haven't addressed the fact that the digits don't line up in Georgia, which was supposed to be the reason for the fix, nor that you've made Val to screw up the display of assymmetrical uncertainties for everyone who's chosen a font with Old Style numbers, apart for Georgian, which has thwarted your fix. — kwami (talk) 21:29, 30 March 2014 (UTC)

{val} uses the .digits class only on the numbers passed to {su} for asymmetrical uncertainties. I did that in response to your your Aargh! comment above. I don't know what you have been editing/reverting based on that complaint, but rest ashured, you should not see any lining digits in {su} or {val} anymore. — Edokter (talk) — 21:19, 30 March 2014 (UTC)
No, just the opposite: My "Aargh!" comment was in response to your change of the digits class to only the {su} part. Val displayed fine before; that was the edit that messed it up.
I see tabular OS in the {su} part of Val, and non-tabular OS in the other part. But that's just because you fixed my personal CSS. For other people, the {su} part is still messed up.
You did not fix Georgia, which still have non-tabular OS digits everywhere. So, what is the point of your edit? It doesn't fix anything, AFAICT, but it does screw up the display for our readers, depending on what they've chosen as their default font. If it breaks things but doesn't fix anything, you should just revert it. — kwami (talk) 21:37, 30 March 2014 (UTC)
I did fix Georgia, as you can see from my screenshot. I did not apply your custom CSS site wide becuase it breaks Georgia for me as well, so I had to apply both lining and tabular. I have no idea why this fix does not seem to work on your PC. I suspect you copy of Georgia may be outdated or corrupt (I have version 5.51). — Edokter (talk) — 22:09, 30 March 2014 (UTC)
I have whichever version of Georgia came with my OS, which I suspect is what 99.99% of our readers have (not my version, but whichever version came preloaded on their OS's). So you did not fix the problem for our readership, you fixed it for yourself and people like you. That's not a good reason to change a widely-used template. You also said the change was for my benefit, but I didn't want it. If it was just to placate me, could you revert it? — kwami (talk) 06:13, 31 March 2014 (UTC)
Then we need to set up a poll to find out who is affected. For now, I have tested four PCs ranging from XP to Windows 7 with Georgia installed and they all work on my end. — Edokter (talk) — 10:35, 31 March 2014 (UTC)
Also, which change are you referring to? — Edokter (talk) — 11:36, 31 March 2014 (UTC)
When you moved the digit class to just {su}. — kwami (talk) 02:12, 1 April 2014 (UTC)
  • This is Georgia with lining numerals: 0123456789. Do you see it now? If so, your Georgia copy does not support lnum/tnum combination
  • This is Times New Roman with old-style numerals: 0123456789. Works only with proportional numbers.

OpenType font settings are a strange beast. For me, the lining/tabular feature combination work on Candara, Georgia and most other fonts with defualt old-style numerals. The Time New Roman example was to see if it contains old-style numerals; it does, but they only work whn not using tabular display, so tabular would automatically force lining numerals. — Edokter (talk) — 11:23, 31 March 2014 (UTC)

Not sure what I'm supposed to be seeing. The Georgia digits are Old Style. They are not equal width. The TNR digits are full height ('caps') and equal width. So both appear to me as the opposite of how you describe them. From what I see, TNR would be better of the examples, because there would be no alignment problem, and no inconsistency between character height between the main part of the number and the {su} part. — kwami (talk) 02:12, 1 April 2014 (UTC)
You see both in the opposite of what you're supposed to see. I'm more then happy to use Times as example font (instead of Georgia), but I though you didn't want any lining digits? — Edokter (talk) — 10:21, 1 April 2014 (UTC)
No, I don't mind lining digits, I just object to mixing them in haphazardly. So if one number in a table is OS, and the next is lining, to me that's an eyesore, and in any case is distracting. It would be like typesetting a few random countries in a list in all caps. Also, if a base number is in OS, but its uncertainty is in lining, that is also an eyesore/distracting. I don't care if the examples at MOS:NUM are lining or Old Style, as long as they're all the same. But again, your edit here had no effect on MOS:NUM, so why do you keep referring to it? As for WP articles, the reader should get to decide for themself which they use, just as they get to decide whether to use a serif or sans serif font, or to have links display with an underscore. — kwami (talk) 05:23, 2 April 2014 (UTC)
Because you brought it up first: One example of the problem is that we recommend Val at the MOS to get certain formatting effects... You also said you preferred old-style numerals in general. But I'll move the digits class back oto val. — Edokter (talk) — 10:18, 2 April 2014 (UTC)
The problem was that, with your edit, Val no longer produced the formatting seen at MOS:NUM. This had been a problem earlier, so I added a warning to the MOS that Val wouldn't actually produce what we recommend. Then we agreed to adjust Val, and I was able to remove the warning from the MOS. With your latest edit, we would have needed a warning again. The font we use at MOS:NUM is not important, but mixing lining and old style is like using camel case in a word that's not supposed to have it.
However, whatever you just did, you didn't just revert yourself. You are now forcing the display in all transclusions of Val, perhaps because of one of your changes at MediaWiki:Common.css? Using a set format for examples is one thing, overriding everyone's format choices across WP is another. Please stop messing with the formatting until there's a consensus to change. Until we can figure out how to handle the extremely minor issue this is intended to address, I'm removing the digits class, so that Val can accommodate user preferences as Gaps, SU, E, and other number templates do.
Here's my suggestion for a solution I hope everyone can be happy with:
Change
<span class="nowrap">
to
<span class="{{#ifeq: {{{lining|}}} | yes | digits}} nowrap">
Does that do what we need it to? — kwami (talk) 20:32, 2 April 2014 (UTC)
FWIW the right column of the three examples works for me on Windows 7 with Chrome, the left side for the default sans-serif font (should be Tahoma on my box) is also okay, but the left sides for Candara and Georgia are ugly. Chrome's "inspect element" function reports that these fonts (sans-serif, Candara, Georgia) actually arrived at their intended places. My Georgia version is 5.00. –Be..anyone (talk) 18:53, 31 March 2014 (UTC)

Discussion moving back to the template talk page. — kwami (talk) 07:44, 3 April 2014 (UTC)

MW SVG to PNG conversion issue

This SVG looks fine, has valid code (I checked), and yet is displaying very poorly on the page. Not sure how to fix this. It's a shame that we can't have SVGs be SVGs because some people still use IE8. Any ideas as to what's causing this, or is it just a bug in MW? ▫ JohnnyMrNinja 17:07, 28 March 2014 (UTC)

It looks okay to me… http://i.imgur.com/a0PNxN1.png Matma Rex talk 18:28, 28 March 2014 (UTC)
250px looks fine, but 230px does not. Even at 300px it's weird. πr2 (t • c) 18:30, 28 March 2014 (UTC)
This is weird... I purged the image, now all PNG copies have white letters. I suspect a regression in libsvg (or was it libpng?) — Edokter (talk) — 18:36, 28 March 2014 (UTC)
Just tested, something seems wrong with librsvg (specifically I tested rsvg-convert). Maybe it's a bug. πr2 (t • c) 18:43, 28 March 2014 (UTC)
The problem may be with Wikimedia's patched version though. πr2 (t • c) 19:15, 28 March 2014 (UTC)
Does Wikimedia have a patched version of librsvg? I'd love to look at the diff. --AKlapper (WMF) (talk) 10:23, 31 March 2014 (UTC)
@AKlapper (WMF): Since you've been the bug wrangler for WMF and have worked with GNOME, you probably are the best person to look into this issue. There's librsvg.git, but I'm not sure what the exact differences are. rsvg-convert --version on Labs gives me the result rsvg-convert version 2.36.1 (Wikimedia). πr2 (t • c) 15:24, 31 March 2014 (UTC)
I was refering to the statement "Wikimedia's patched version" specifically - do you know that there *are* differences, or did you assume? I'm just curious. --AKlapper (WMF) (talk) 19:31, 31 March 2014 (UTC)
@AKlapper (WMF): Yes, see here are the patches (not as much as I expected). I don't see anything significant there, so I guess this is an upstream librsvg bug. Can you confirm? πr2 (t • c) 20:26, 31 March 2014 (UTC)

Animated article history revisions

On IRC a few days ago, someone asked, "Does anybody know a tool that can automatically "play" all the diffs or the versions of an article? To show how it grew over time?"

We used to have a few that worked (listed at Wikipedia:Tools#Visualization and elsewhere) but I can't find anything that works currently.

(I checked the "AniWiki"[1] and "Wikipedia Animate"[2] greasemonkey scripts, as mentioned in The Signpost in 2005, but neither worked anymore.)

  1. http://ejohn.org/projects/aniwiki/ eg. screenshot
  2. https://userscripts.org/scripts/show/1418 (which still worked in 2008) eg. screenshot

Does anyone here know of a working tool? (or where else to ask?) Thanks. –Quiddity (talk) 18:36, 30 March 2014 (UTC)

Quiddity, Wiki Replay was funded by an Individual Engagement Grant about a year ago and seems to currently be functional. Theopolisme (talk) 19:32, 30 March 2014 (UTC)
Neat, thanks! See also m:Grants:IEG/Replay Edits and wm2014:Submissions/Replay Edits for more details.
Anything else? –Quiddity (talk) 21:25, 30 March 2014 (UTC)
wikichanges?
See also my little collection at de:Benutzer:Atlasowa/edit history visualization (includes tools that are no longer online).
I really love de:Benutzer:Schnark/js/artikel-statistik on german Wikipedia (for articles with a not-so-huge article history) - is it possible to get this working on english wikipedia too? --Atlasowa (talk) 12:34, 3 April 2014 (UTC)
Atlasowa, please file a bug for that script in bugzilla, I'd like to keep track of it (cc me please). --Nemo 06:58, 4 April 2014 (UTC)

Page preview with template?

Resolved

When I edit in template space, I see a box below the editbox that says Preview page with this template Page title: <inputbox> Show preview (button). I have no idea what it does. Can someone link to some documentation or background page for this one? -DePiep (talk) 06:45, 31 March 2014 (UTC)

That's mw:Extension:TemplateSandbox. It lets you preview how any page would look with the template text that is currently in the edit window. For example, say you edit Template:High-risk, and in the edit window you replace all the existing text with the text "Foo", without saving the page. Then you type in "Template:Hatnote/doc" to the input box you mentioned, and click the "show preview" button. You will then see the Template:Hatnote/doc page, except instead of the big orange banner saying "This template is used on 320,000+ pages", you will just see the text "Foo". (Be careful you don't save the page while testing, though - for serious testing, the /sandbox page is still best.) It also works with Lua modules, and you can preview more than one template at once by using a prefix in your userspace. For that last one, see the extension page for documentation. — Mr. Stradivarius ♪ talk ♪ 07:35, 31 March 2014 (UTC)
Thanks 'gan. So it is a transclude-preview. (We need an internet convention sign that says "just the link to start with please, then I'll do some research myself first"). -DePiep (talk) 10:44, 31 March 2014 (UTC)

Broken HTML lists: an indicator of a deeper problem?

I noticed that {{Nutshell}} displayed broken HTML lists (i.e. three lists of one item instead of a list of three items) when more than one unnamed parameter was passed to it, contrary to guidelines about gaps between list items, at Wikipedia:Don't bludgeon the process). I fixed this by converting the list from wiki-markup to HTML, but was that the most elegant method? I couldn't find anything in the previous code that should have broken the HTML lists, and I don't know Lua so I can't tell whether Module:Message box (which is ultimately called by the nutshell template) had anything to do with the problem. Graham87 07:05, 31 March 2014 (UTC)

This is because of the {{nutshell}} invocation on Wikipedia:Don't bludgeon the process:
{{Nutshell
|It is not necessary or desirable to reply to every comment in a discussion.
|The more often you use the same reason in a given discussion, the weaker it becomes.
|Everyone has the same right to be heard in any discussion.
}}
Because these are positional parameters, whitespace is not trimmed, and the line break at the end of each of the parameters is passed through to the template. You could fix this in the invocation by doing this:
{{Nutshell
|1=It is not necessary or desirable to reply to every comment in a discussion.
|2=The more often you use the same reason in a given discussion, the weaker it becomes.
|3=Everyone has the same right to be heard in any discussion.
}}
But it might be better to trim whitespace in the template itself. I'll have a look to see how best to do it. — Mr. Stradivarius ♪ talk ♪ 07:54, 31 March 2014 (UTC)
I've converted it to use {{unordered list}} - that seemed the neatest way of doing things. — Mr. Stradivarius ♪ talk ♪ 08:18, 31 March 2014 (UTC)
Thanks very much! Sounds good to me. Graham87 06:28, 1 April 2014 (UTC)

Tech News: 2014-14

Latest tech news from the Wikimedia technical community. Please inform other users about these changes. Not all changes will affect you. Translations are available.

Recent software changes

  • The latest version of MediaWiki (1.23wmf20) was added to test wikis and MediaWiki.org on March 27. It will be added to non-Wikipedia wikis on April 1, and all Wikipedia wikis on April 3 (calendar).
  • Typography Refresh was added to test wikis and MediaWiki.org on March 27. You'll only see it if you use the Vector skin. For users on non-Wikipedia wikis, it will be enabled on April 1, and for Wikipedia users on April 3.
  • CirrusSearch, the new search tool, was enabled as a beta feature on over 30 new wikis on March 27. [70] [71]

VisualEditor news

  • Blocked users now see the same messages in VisualEditor as in the wikitext editor. [72] [73]
  • The search box for re-using a reference in VisualEditor is now cleared after each use. [74]
  • New links on sub-pages no longer point to the wrong location in VisualEditor. [75]
  • VisualEditor's media dialog no longer breaks when opening some types of images. [76]

Future software changes

  • You will not be able to use the Wikitech wiki for a short period around 16:00 UTC on April 1 due to a server change. [77]
  • CirrusSearch will become the main search engine for all non-Wikipedia wikis except Commons, Meta and Incubator on April 2.
  • You will soon be able to use a new special page listing duplicate files. [78]
  • Deleting a version of a file or a version of its description page will soon be shown differently in the logs. [79]

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

09:20, 31 March 2014 (UTC)

Who is maintaining the gadget?

Preferences > Gadgets > Editing > "Add two new dropdown boxes below the edit summary box with some useful default summaries"

There's no link to a page about the gadget. Where is it? Who is maintaining it? Whatamidoing (WMF) (talk) 19:58, 31 March 2014 (UTC)

If you look at MediaWiki:Gadgets-definition, you'll see the row 
defaultsummaries|defaultsummaries.js
The files are therefore MediaWiki:Gadget-defaultsummaries and MediaWiki:Gadget-defaultsummaries.js; if you look at the editing history for those it should indicate who maintains it. MediaWiki talk:Gadget-defaultsummaries.js is probably the best place to discuss the gadget. --Redrose64 (talk) 20:04, 31 March 2014 (UTC)
Thanks! I'll leave a note there. Whatamidoing (WMF) (talk) 20:32, 31 March 2014 (UTC)
It's easier to find the files from Special:Gadgets. PrimeHunter (talk) 20:40, 31 March 2014 (UTC)
[off-topic] See also bugzilla:60142 ("Output links to the JS and CSS pages of each gadget listed at MediaWiki:Gadgets-definition"). Helder.wiki 17:19, 1 April 2014 (UTC)

Changes to the default site typography coming soon

This week, the typography on Wikimedia sites will be updated for all readers and editors who use the default "Vector" skin. This change will involve new serif fonts for some headings, small tweaks to body content fonts, text size, text color, and spacing between elements. The schedule is:

  • April 1st: non-Wikipedia projects will see this change live
  • April 3rd: Wikipedias will see this change live

This change is very similar to the "Typography Update" Beta Feature that has been available on Wikimedia projects since November 2013. After several rounds of testing and with feedback from the community, this Beta Feature will be disabled and successful aspects enabled in the default site appearance. Users who are logged in may still choose to use another skin, or alter their personal CSS, if they prefer a different appearance. Local common CSS styles will also apply as normal, for issues with local styles and scripts that impact all users.

For more information:

-- Steven Walling (Product Manager) on behalf of the Wikimedia Foundation's User Experience Design team

This was also in the latest edition of the The Signpost, for those follow it. Steven Walling (WMF) • talk 23:13, 31 March 2014 (UTC)

The requested page or revision cannot be found

User:Σ shows error message "The requested page or revision cannot be found" etc. I wonder if this is due to a bug or something. - Synsepalum2013 (talk) 14:04, 1 April 2014 (UTC)

It's an April Fools joke. See User:Σ/Userpage/1 April. ~huesatlum 14:55, 1 April 2014 (UTC)
Haha, well played. Thanks for the tipping off. - Synsepalum2013 (talk) 15:29, 1 April 2014 (UTC)
Is it just me, or when viewing the source for the page, copying the text "PleaseDontEdit/" (surrounded by curly braces) and pasting it somewhere produces "/tidEtnoDesaelP"? K6ka (talk | contribs) 19:34, 1 April 2014 (UTC)
Right-to-left mark. --  Gadget850 talk 20:11, 1 April 2014 (UTC)
So that's the secret. I don't know whether I am the only one who almost went crazy trying to understand how the fake warning from User:Σ/Userpage/1 April could get transcluded on Sigma's user page, though that was probably exactly the joke ("Hmm, Template:PleaseDontEdit/ doesn't exist, maybe there's some magic word called "PleaseDontEdit/" or something?"). SiBr4 (talk) 20:32, 1 April 2014 (UTC)
But how is it showing up on User:Σ? — Edokter (talk) — 20:25, 1 April 2014 (UTC)
The RLM makes the page show up as {{PleaseDontEdit/}} when viewing the source but is read by MediaWiki as {{/tidEtnoDesaelP}} and thus transcludes User:Σ/tidEtnoDesaelP. SiBr4 (talk) 20:32, 1 April 2014 (UTC)
At least that's my guess now I know there's some tricks with inverted wikicode going on... SiBr4 (talk) 20:33, 1 April 2014 (UTC)
I see it now, the link in /tidEtnoDesaelP is obsfucated with comments. — Edokter (talk) — 20:40, 1 April 2014 (UTC)
The same trick is used in the /tidEtnoDesaelP subpage as well. After copying the subpage's code to Notepad and Ctrl-H-ing away all comments, it turns out it actually just transcludes User:Σ/Userpage, which in turn shows the warning on 1 April and the "normal" userpage on other dates. SiBr4 (talk) 20:51, 1 April 2014 (UTC)
Oh man, I'll be having a looooot of fun with Wikitext! Jaws will drop like hailstones! K6ka (talk | contribs) 22:36, 1 April 2014 (UTC)
Actually it's not a right to left mark; that's &#x200f; , but this is &#x202e; (U+202d to terminate). ‮(For example) ‭ See Bi-directional text. As you can see from the example, I'm still a little hazy on how to control where the RTL text turns up. Wnt (talk) 15:15, 2 April 2014 (UTC)

Page not found watchlist-contributions sporadic issue

  • There's something funky going on, not because of April 1, and not for the first time. I just created Template:Did_you_know_nominations/Snow_in_Louisiana. I can transclude it with no problem. I can open it from Template Talk: Did You Know. And I can otherwise insert it as a blue link. But if I try to pull it up from my Watchlist or my Contributions, I get "File not found". After an hour or so, that problem will disappear. I know, because it's happened before. Something delayed in how a new file shows on the Watchlist or Contributions before it can actually be accessed. Strange stuff, but it's not a new happening.— Maile (talk) 21:16, 1 April 2014 (UTC) And true to what I just said, it has now cleared itself and is pulling up fine. — Maile (talk) 21:19, 1 April 2014 (UTC)
    If it's not a fake error for April Fools' Day too, that error is unrelated to the one on Σ's user page and should be moved to a separate section. SiBr4 (talk) 21:25, 1 April 2014 (UTC)

Search is broken (due to ongoing C___ rollout?)

"An error has occurred while searching: The search backend returned an error:" here every time I try to search. --Elvey (talk) 21:17, 1 April 2014 (UTC)

Cirrus seems to handle the search fine so you can use that while this is happening. Add &srbackend=CirrusSearch to the results page (every time it loads) or switch on the BetaFeature. In the mean time I'll look into the error. NEverett (WMF) (talk) 21:30, 1 April 2014 (UTC)
And I can't reproduce it anymore. It was broken about 30 seconds ago and now it works..... To the logs! NEverett (WMF) (talk) 21:31, 1 April 2014 (UTC)
I was just reproducing it at that time, at least ten times with various permutations of the words. I got it down to "to two of individual" with the same error message, and "to two of" with error "An error has occurred while searching: HTTP request timed out." All the errors take longer than a normal search, so I think this is timing out based on very general search terms. (If I had to take a wild guess I'd suspect the generic error happens when a subset of the search comes back with an HTTP request timed out error and then it tries to add another word to those results???) Wnt (talk) 21:38, 1 April 2014 (UTC)
Got it back. Looks like I turned on Cirrus and that "fixed" it for me. I found the log for it but it isn't helpful in diagnosing it other then to tell me that it happens every few seconds mostly on enwiki. It seems to be "confined" to searches outside the MAIN namespace. NEverett (WMF) (talk) 21:57, 1 April 2014 (UTC)
@NEverett (WMF): So this is just another example of LuceneSearch throwing these errors randomly, and not actually an issue with CirrusSearch? --Dan Garry, Wikimedia Foundation (talk) 22:24, 1 April 2014 (UTC)
I mean, it has a cause. The error is in custom code on top of Lucene that I've not delved into too much that does extra in memory caching of stuff like the article length. I took that as a hint and tried restarting the effected nodes. I waited "a while" between the two node but it still caused the rest of the system to become overloaded, dropping a bunch of requests presumably until caches warmed up enough that requests could be serviced in a timely manor. It also didn't fix the problem. I traced it down to one image's search record (File:American_dead_buna_beach.png) being corrupt (or something) so I did a null edit on the image. I'm not sure if that was required the old search system rebuilds the entire index every few days and doesn't react to edits at all. But I did it just in case something was busted about the revision. Given that my tinkering already caused a brownout across all namespaces, I'm inclined to wait until the index is rebuilt on its own, probably in a day or two. If that doesn't fix it then maybe more surgery. Or maybe make Cirrus the default for searches outside the main namespace. That'd be a bit drastic at this point but at least it doesn't crash and my tools for debugging it are infinitely better.NEverett (WMF) (talk) 14:21, 2 April 2014 (UTC)

I started a thread "Use interwiki links instead of HTML anchors?" at MediaWiki:Wikimedia-copyright that may interest some of you. Jason Quinn (talk) 03:45, 2 April 2014 (UTC)

Archiving pages

Is there an easy to find page with instructions on specifically what to copy to a talk page to get automatic archiving started? Am extremely confused and can't find a clear answer. Hopeful thanks in advance! --LT910001 (talk) 10:20, 2 April 2014 (UTC)

I think the first (left-hand) example code at Help:Archiving a talk page#Automated archival is simplest. -- John of Reading (talk) 11:00, 2 April 2014 (UTC)
  • The easiest way is to tell us exactly how you want your talk page archived, and someone I'm sure would happily give you a snippit of code to use (or do it for you). So, some questions:
    1. How do you want it archived?
      1. Archive sections that are marked as {{Resolved}} or {{Done}}?
      2. At some interval of time after the last post to the section?
        1. After a year?
        2. After three months?
        3. After a month?
    2. Where do you want them archived to?
      1. In a plain boring sub-page to your userspace?
        1. "/archive 1" — "/archive ∞"
      2. Time delimited?
        1. "/YYYY"
        2. "/YYYY/Quarter 1" — "/YYYY/Quarter 4"
        3. "/YYYY/MMM"
        4. "/YYYY/MM"
Or do you want it done in some other way I haven't mentioned (the options are near limitless).  :) — {{U|Technical 13}} (t • e • c) 13:33, 2 April 2014 (UTC)
Thanks, the link to WP:ARCHIVE was very useful, although the buffet of options is quite daunting! Have selected the most basic, by time. Cheers, --LT910001 (talk) 22:37, 2 April 2014 (UTC)

Table - formatting problem

Would someone be kind to look into the Valls Cabinet article and see what's wrong with the formatting since "References" pops up in the middle of a table instead of at the bottom where it as customary is inserted. Regards, Iselilja (talk) 11:05, 2 April 2014 (UTC)

Done. Blackfish (talk) 11:37, 2 April 2014 (UTC)
Thank you! Regards, Iselilja (talk) 11:57, 2 April 2014 (UTC)

Warning users who copy material from Wikipedia

Would it be possible/desirable to create a gadget which would detect if a user opens a page (in edit mode), copies its contents and then closes the edit window? In this situation it could remind the user that he should give credits to the authors if he uses the copied material in some other place. It is relatively common to see users copying e.g. English Wikipedia's templates to other wikis, or translating articles, etc... without linking to the original pages. Helder.wiki 15:19, 2 April 2014 (UTC)

I'd say it's not desirable to add code for all users (an opt-in gadget wouldn't apply) for such a narrow case. Pestering users won't change enough to be worthwhile. We aren't about to solve the problem of people plagiarizing Wikipedia, and it's obvious enough when people are copying, especially if it's to another MediaWiki-based wiki where the edit history is visible. If you see an unattributed use of your own template code or article text, feel free to make your own complaints or even your own DMCA letters—if they're not following the license, you're well within your rights to do so. If it's not your own content, then just pointing out how easy it is to satisfy the license is often enough to encourage compliance—I've done that myself a couple of times. {{Nihiltres|talk|edits}} 15:34, 2 April 2014 (UTC)
Our only defense against the NSA making records of what users are doing is not to collect information in the first place. This kind of stuff that the user thinks of as his own private affair (hitting control/command-C) should stay that way, if we have anything to say about it. Wnt (talk) 20:35, 2 April 2014 (UTC)
Indeed. A good example of this is that we don't log what users search at all. A real example of the consequences of this is that CirrusSearch in MediaWiki will never be as rich in features as Google; for example, adding a "popular searches" feature was on the table, but then we realised we'd have to log what people are searching and we're not happy with that. We're okay with that tradeoff if it's being made to safeguard the privacy of our users. The feature proposed here has similar concerns as it's essentially a keylogger, which makes the proposal untenable. --Dan Garry, Wikimedia Foundation (talk) 21:10, 2 April 2014 (UTC)
Wait—How's the Signpost get their weekly list of the most popular articles then? Supernerd11 :D Firemind ^_^ Pokedex 02:21, 3 April 2014 (UTC)
The Foundation retains some information on pages visited, but not on searches performed. Small but significant difference. Someguy1221 (talk) 02:48, 3 April 2014 (UTC)
Ah, okay. Supernerd11 :D Firemind ^_^ Pokedex 03:03, 3 April 2014 (UTC)
If it's client-side (JS) and the data is never sent anywhere, what's the problem? I agree it should not be added, but I do not understand your reasoning. πr2 (t • c) 02:32, 3 April 2014 (UTC)
I usually leave Javascript off, so it wouldn't work then; and I have to say, the nag notice about leaving a page while editing it is already a nuisance. Adding another if you copy text... would be worse. And I'd worry that somehow the information could still end up becoming available over the internet, for instance if the notice affected the nature or timing of any subsequent upload(s)/download(s) from the server. Wnt (talk) 17:02, 3 April 2014 (UTC)

Category:HDS different on Wikidata

There are currently 340 articles in Category:HDS different on Wikidata, which doesn't exist. If anyone knows of an easy way to determine where it is generated, and whether it is useful in any way, then we can see whether it needs creation (and hiding) or removal. And a small trout for the editor adding some maintenance category to a template without creating it. Fram (talk) 07:20, 3 April 2014 (UTC)

I copied Aadorf into Special:ExpandTemplates and looked for the category name in the output. That identified {{HDS}} as the culprit. -- John of Reading (talk) 07:31, 3 April 2014 (UTC)
Thanks. Seems to be the work of User:Docu. The proliferation of tracking categories, even hidden, is something that probably needs to be looked at. What's the point of this category? Our article on Aadorf has 5 different HDS because it covers sub-municipalities sa well; other languages do this differently. Is this a problem? Still, it isn't as silly probably as Category:Commons category with page title same as on Wikidata, a category hidden on 4,500 subcategories and 71,000 pages to tell us that nothing is wrong and, like the category states, nothing needs to be done for these articles. Then why track it? Created by User:Legoktm, should probably be deleted as a waste of resources. Could be wores, we could also have Category:Commons category with local link same as on Wikidata, which would have some 180,000 subcategories and 160,000 pages. Oh, wait... Fram (talk) 08:20, 3 April 2014 (UTC)
Issue seems solved, specific questions can and should be directed at users in question. —TheDJ (talk • contribs) 09:36, 3 April 2014 (UTC)

Page move from article space to the new Draft space should not create redirect

Move creates redirects automatically even when they're illegal, like moving an article to the draft namespace. If should notice this and not create them. Otherwise you end up with the situation like Sara shahmohammadi. Stuartyeates (talk) 09:15, 3 April 2014 (UTC)

All page moves create redirects, unless you're an administrator and deselect "Leave a redirect behind". Why is moving a page from article space to Draft: space illegal? --Redrose64 (talk) 09:46, 3 April 2014 (UTC)
Moving the page isn't illegal, the resulting redirect is (well, not "illegal" of course, but unwanted). Fram (talk) 09:54, 3 April 2014 (UTC)
Yeah, it's not ideal. Having said that, you can just tag the redirect with {{db-r2}} and an admin will come along and delete it shortly. Black Kite (talk) 10:08, 3 April 2014 (UTC)
Draft is not special. Any non-admin move from mainspace to another namespace will leave a redirect, and I think it should continue to do so. It would be very odd if a single move namespace combination main-draft would omit the redirect. The redirect is helpful to spot and track bad moves including vandalism. A move without leaving a redirect is not added to the page history (since the page is deleted). It's added to the log and seen when you click a red link, but if a new page is created at the same title then you have to click "View logs for this page" in the page history to discover the move. Most users expect they only have to view the page history, and some move vandals would probably learn to take advantage of this. PrimeHunter (talk) 12:46, 3 April 2014 (UTC)
Do you mean that it should leave a redirect until an admin can check and delete it (which is fine by me), or forever? The usual meaning of a move to Draft (or user space or the like) is that the article is, for some reason, not ready for the mainspace. Leaving the redirect removes this, a slinks from other articles to this page will lead people from the mainspace to the draft space without them even noticing this probably. If we consider a page not to be readu to be in the mainspace, we shouldn't link it as if it is still a part of it. Yes, this will make it slightly harder to spot bad moves, but we shuold ase our policies on normal usage, not on incorrect uses. Fram (talk) 14:05, 3 April 2014 (UTC)
I mean the redirect should be checked and deleted by an admin. We could consider better procedures to detect and report such redirects if it's a common problem. I don't know whether existing tools at Wikipedia:Cross-namespace redirects#See also are practical. PrimeHunter (talk) 14:40, 3 April 2014 (UTC)
I agree with Prime and we do need to consider deliberate malpractice. There is a risk to any cross-namespace move in that it can be (and sometimes is) used to "vanish" an article. Although the redirect leaves a record that this has happened, the perpetrator can request deletion of the cross-namespace redirect and a careless admin can perform the deletion leaving very slight trace of the missing article. Not having a redirect in the first place adds to this risk. Thincat (talk) 14:15, 3 April 2014 (UTC)
I think it's good to keep these redirects. It tells future editors that the article already exists (if someone were to try to create a new one on the same subject; duplicates happen all the time at AFC), it keeps any pre-move template/messages working, and it makes sure that anyone who'd seen it originally in the draft space has an easy way to find it again. I think they're especially important when the move to the mainspace results in a slightly different name (e.g., not plural or different capitalization). WhatamIdoing (talk) 17:31, 3 April 2014 (UTC)
@WhatamIdoing: We're talking about redirects from the main to the draft namespace, not the other way around. Graham87 07:46, 4 April 2014 (UTC)

Does anyone know of a Wikipedia CSS class that...

...approximates this styling?:

font-size:110%;line-height:1.4em;text-align:center;white-space:normal;padding-bottom:0.2em;

...or perhaps one for its crucial elements...?:

text-align:center;white-space:normal;

If so, please divulge!

Thanks, Sardanaphalus (talk) 14:42, 3 April 2014 (UTC)

No such class exists I'm afraid. — Edokter (talk) — 15:09, 3 April 2014 (UTC)

The "Help" link in the "Interaction" section of the left sidebar is broken; instead of jumping to a Wikipedia help page, it sends you off to a Mediawiki page. The corresponding link at Commons, "Help portal", is also broken. -- John of Reading (talk) 20:59, 3 April 2014 (UTC)

How is that broken? Jackmcbarn (talk) 21:13, 3 April 2014 (UTC)
It points Here. It used to point to the Wikipedia help desk page, not Media Wiki. Same with Commons Help Portal,it points to that Media Wiki link, not the Commons help page. — Maile (talk) 21:41, 3 April 2014 (UTC)
I cannot see what has been changed in the configuration to cause this. I believe it could be fixed either by editing MediaWiki:Sidebar or by creating MediaWiki:Helppage. Cheers, Bovlb (talk) 21:45, 3 April 2014 (UTC)
The actual link is now mw:Special:MyLanguage/Help:Contents it used to be Help:Contents. One is local; the other isn't. The average very-newbie is going to be totally confused by being sent off to a page that has the same look and feel as Wikipedia but which is a completely different website. They might notice the yellow daisy instead of the puzzleball, but they'll probably think that it's still Wikipedia, and be unable to find the article that they're after. --Redrose64 (talk) 21:46, 3 April 2014 (UTC)
(edit conflict) I have fixed it on English Wikipedia, needed to add the link at MediaWiki:Helppage. the wub "?!" 21:47, 3 April 2014 (UTC)
Actually, Help:Contents/Browse is where that link should point to. The other one pulls up threads relating to what is in put, but not actually to the help site.— Maile (talk) 21:51, 3 April 2014 (UTC)
No, Help:Contents is the main help page. I should know, I worked on it for about 6 months :) the wub "?!" 22:00, 3 April 2014 (UTC)
Right. That's Help's main page. It used to automatically go there. So you're saying it should no longer go there? I think it's easier for me to just bookmark the Help main page for myself.— Maile (talk) 22:07, 3 April 2014 (UTC)
I'm confused, why did you bring up Help:Contents/Browse then? I have already fixed the sidebar link to point to Help:Contents. If you're not seeing it, perhaps you need to bypass your cache. the wub "?!" 22:14, 3 April 2014 (UTC)
I mis-read what you said. Got it. Never mind this. I prefer the Browse page, but that's not what you meant. — Maile (talk) 22:48, 3 April 2014 (UTC)
On a side note - Help:Contents/Directory is the page I link to for new editors as it actually explains the links. -- Moxy (talk) 23:48, 3 April 2014 (UTC)
I never knew the Directory existed. This is great. Thanks for mentioning here. — Maile (talk) 11:55, 4 April 2014 (UTC)

Please restore the previous font size.

Duplicate discussion. Please see Wikipedia:Village pump (technical)/Archive 125#Font size and style. --Dan Garry, Wikimedia Foundation (talk) 00:02, 4 April 2014 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

The previous font size was perfectly fine as it was. Now, the new one is uncomfortable to read.

If it ain't broke, don't break it. Please restore the previous font size, or at least make an easily visible font resizer button. — Preceding unsigned comment added by 50.136.248.192 (talk) 23:13, 3 April 2014 (UTC)

Different situations at different PC's. If it ain't broke, don't break it. At one it made the body very difficult to read, a narrow font. For anybody who is on the edge, this makes it unreadable. North8000 (talk) 23:49, 3 April 2014 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Extra scrolling

Is it just me, or is Wikipedia extra scrolly lately? I don't know if it's because of the new font or the fact that I'm temporarily stuck on IE 10, but now, whenever I scroll down to the bottom, I get an extra ~2 screen heights of blankness at the bottom. Any ideas? Supernerd11 :D Firemind ^_^ Pokedex 00:14, 4 April 2014 (UTC)

Could be a bug or hidden feature of the typography refresh. What skin do you use? KonveyorBelt 04:46, 4 April 2014 (UTC)
I use Vector, but the problem's gone now. Supernerd11 :D Firemind ^_^ Pokedex 23:23, 4 April 2014 (UTC)

A perplexing puzzle

There may be some technical explanation for this, but I don't know what it could be.

A few weeks ago, Deepak Chopra tweeted about a death threat in the Ralph Abraham article.[80] Responses to the tweet seem to acknowledge the vandalism, with one person posting a screenshot.[81] Someone else did a blog post about it.[82]

However, the only contemporaneous edits to the article were some vandalism by 71.119.92.56 four days prior to Chopra's tweet, which was immediately reverted by ClueBot.[83] Ah, but that just means the death threat was suppressed, right? That's what I had thought. However admins have told me that there are no suppressed edits in the Ralph Abraham article. I also know that 71.119.92.56's edits are in fact the death threats in question.

Now we shift to seemingly less probable explanations. Chopra was complaining about a non-vandalized article? And other people were too? The screenshots didn't have have the "old revision" tag on them, so people were using the latter part of an old diff to create screenshots? Well maybe, I guess, but here comes the monkey wrench: one screenshot was of the Google Knowledge Graph![84] You know, the thing that appears on the right when you type "Ralph Abraham" into Google.[85] Since ClueBot reverted the vandalism immediately, how the heck did Google pick it up? Just astoundingly unlucky timing? Perhaps there is a caching bug somewhere?

Resorting to other presumably less probable explanations: the vandal, having a freshly vandalized page, took the screenshots? The screenshots were faked? Multiple admins are lying about the page having no suppressed edits? There is an extra secret level of uber suppression that non-uber admins cannot see? I am somewhat kidding, but I'm still perplexed. vzaak 05:04, 4 April 2014 (UTC)

You wrote "However admins have told me that there are no suppressed edits in the Ralph Abraham article." Which admins told you that, and where? Because that's not true. In the page history, there are 2 suppressed edits by User:71.119.92.56 from March 8, 2014. —Lowellian (reply) 06:28, 4 April 2014 (UTC)
Those are revdeleted, not suppressed, edits. vzaak 07:48, 4 April 2014 (UTC)
If you want to split hairs about the differences between revdeletion and suppression, okay, then there's also your answer as to why some admins told you were there were no suppressed edits (because they weren't suppressed, they were revdeleted). In any case, you asked what happened to the vandalizing edits. They were revdeleted. Before they were revdeleted, the edits were cached, hence the screenshots. There's not much of a mystery here. —Lowellian (reply) 09:30, 4 April 2014 (UTC)
I appreciate that you are trying to help, but the distinction between suppression and revdeletion is a necessary one in my original post. Since the revdeleted edits were reverted immediately by ClueBot, and since people were complaining about vandalism four days after the vandalism was removed, I presumed there were suppressed edits that were invisible to me. It turns out it was a caching glitch instead. vzaak 15:06, 4 April 2014 (UTC)
It was just incredibly unlucky timing, and the vandalized version probably sat around in the cache of the Wikipedia servers for a few days. Unregistered users always get the cached versions of pages where available. Graham87 07:33, 4 April 2014 (UTC)
But articles are vandalized often. If the text in Google Knowledge Graph is updated as infrequently as every four days or more, then surely this problem would have been manifested, vociferously complained about, and fixed, by now? (I'm almost certain I've seen it update much much sooner; I suppose I can test it.) Another reason I was reluctant to accept the "incredibly unlucky" hypothesis is that it means the person taking the screenshot seems to be deceptive in apparently passing it off as the current screenshot. Though I agree the "incredibly unlucky" scenario seems to be more likely now. vzaak 07:48, 4 April 2014 (UTC)
It's a deficiency in our caching system and not "incredibly unlucky". Google Knowledge Graph showed what IP's must have seen at Wikipedia for a long time. IP's often report seeing vandalized versions that were reverted within minutes long ago. Wikipedia's own caching does not happen at random times. Pages are usually cached right after an edit but some edits don't cause caching (I don't know why, limited resources are usually blamed for such things), so the probability of an IP seeing a vandalized version is not necessarily low just because the version was quickly fixed. PrimeHunter (talk) 10:20, 4 April 2014 (UTC)
Thanks for the explanation, I've wonderd why I see loads of OTRS tickets about vandalism that were fixed on Wiki hours before the ticket - now I know. Nthep (talk) 13:28, 4 April 2014 (UTC)
@PrimeHunter and Nthep: That sounds like T48014. Something that should fix it will be deployed here on April 10; if you see the problem occurring with revisions after we get 1.23wmf21 here (see Special:Version to check the version of MediaWiki that is being used), please do comment on that bug. Anomie⚔ 14:25, 4 April 2014 (UTC)
Thanks, the caching glitch explanation is the only one I've seen that is consonant with all the evidence. vzaak 15:06, 4 April 2014 (UTC)

Citation Excel File

Hello. I look here but I didn't find it. I want to make a citation for an excel file (is online), for a specific sheet. Is there any specific way? Xaris333 (talk) 05:18, 4 April 2014 (UTC)

{{cite web}} should work fine. Use |title= for a prose description of the file, |at= to indicate the sheet name, and |url= for the web address, including the http://. – Jonesey95 (talk) 06:31, 4 April 2014 (UTC)
|format=XLS may be useful, too. —PC-XT+ 09:38, 4 April 2014 (UTC)
If the information is on a particular row, column or cells, you can also use |at= for that - e.g. |at=Sheet 1, cells J20:L39 --Redrose64 (talk) 09:57, 4 April 2014 (UTC)

{{TODAY}} not substituted

Hi.

It is amazing just how many search results came up before I started this topic, not one of them relevant. (I still might have missed something.)

Contrary to what the documentation of Template:TODAY says, Subst in this code snippet does not work, at least for me: 

<ref>{{cite web |accessdate={{subst:TODAY}} |title=Languages |work=Apache HTTP Server |agency=Ohloh |publisher= Black Duck Software |url=https://www.ohloh.net/p/apache/analyses/latest/languages_summary}}</ref>
{{Reflist}}

Result:

[1]
  1. ^ "Languages". Apache HTTP Server. Black Duck Software. Ohloh. Retrieved {{subst:TODAY}}. {{cite web}}: Check date values in: |accessdate= (help)

Screenshot:

Why is that? — Preceding unsigned comment added by Codename Lisa (talk • contribs) 06:59, 4 April 2014 (UTC)

{{subst:}} is known to not work inside <ref>...</ref>; see: Help:Substitution#Limitation. —C.P. (talk) 08:09, 4 April 2014 (UTC)
There is a bugzilla for this T4700 (and patches have been written for years). All the best, Rich Farmbrough, 14:01, 4 April 2014 (UTC).
Use #tag:ref for reftag: Use #tag:ref when subst'ing templates inside a reftag, so add another extra {{__}} outside as follows:
  • {{#tag:ref|{{cite web |accessdate={{Subst:TODAY}} ...}} }}
Then {{Subst:TODAY}} will insert the current date as hard-coded text. -Wikid77 15:49, 4 April 2014 (UTC)
Or the more intuitive {{refn}}. --  Gadget850 talk 15:51, 4 April 2014 (UTC)
... and never use it with VisualEditor. Thanks guys. Best regards, Codename Lisa (talk) 05:02, 5 April 2014 (UTC)

Font change causes malfunction

When they did the font change, on (only) one of my PC's (all use Firefox browser) all of the body font went to "narrow" and is very hard to read. Is the is known problem / Is there a known fix for this? North8000 (talk) 15:32, 4 April 2014 (UTC)

See the #Font size and style section above. -- Jokes Free4Me (talk) 16:52, 4 April 2014 (UTC)
Yes, I knew that they messed it up overall, but thought that this particular problem might be a bug rather than deliberate. Especially since it only shows up on certain PC's. Sincerely, North8000 (talk) 18:17, 4 April 2014 (UTC)

I've just noticed today that when using the search box (Vector, top right of the screen) the predicted-text dropdown is suddenly thrown over to the left - it has the same vertical position and width, but is now somewhere just to the right of the "talk" tab. If I resize the browser window, it moves around accordingly, but doesn't snap into the correct place. Purging doesn't help, nor does being logged out. (I'm using Chromium 31.0.1650.63, but I get more or less the same on Firefox 26 - perhaps a little further left.)

The weird thing... it only happens on this page, only on VP:T. It doesn't occur, as far as I can tell, on any other page; it doesn't happen in the edit window. I assume there's some kind of weird CSS rendering in one of the examples above that's causing it, but goodness knows where. Anyone else seeing this, or is it Just Broken For Me (tm)? Andrew Gray (talk) 20:39, 4 April 2014 (UTC)

@Andrew Gray: I see the issue too. Mac OS X Mavericks and Chrome 33. I've pinged the search engineers, although as you note it's probably a CSS issue and not one with search itself. I'll let you know if we find anything. --Dan Garry, Wikimedia Foundation (talk) 21:01, 4 April 2014 (UTC)
It's because of the overflow (horizontal scrollbar). Not a new bug, just rarely noticed. (no time to hunt for bug #, but I'm pretty sure there is one). –Quiddity (talk) 21:44, 4 April 2014 (UTC)
Aha - so not this page but any page which is forced too wide. That makes sense. Had a quick skim around Bugzilla but couldn't see anything, though I may have been using the wrong keywords. Andrew Gray (talk) 08:48, 5 April 2014 (UTC)

Shared accounts

The Wikipedia documentation prohibits registration of shared accounts. Please provide your input here (to help me, please try to separate thoughts and create subsections for verbose discussion). Thanks. Gryllida (talk) 03:26, 5 April 2014 (UTC)

Commons doesn't count for global contributions?

I made some edits on Commons, but when I use the "Global contributions" link at the bottom of my English WP contributions page, no edits for Commons are listed. Does Commons not count towards global contributions? Lyryn talk 04:46, 5 April 2014 (UTC)

Never mind, Commons isn't showing up on the global contributions link from my Commons page either. Where do I report that? Lyryn talk 04:48, 5 April 2014 (UTC)
There is sometimes a delay of a few hours or so. My commons edits show up first on the list. —PC-XT+ 07:42, 5 April 2014 (UTC)
Retrieved from "https://wiki.riteme.site/w/index.php?title=Wikipedia:Village_pump_(technical)/Archive_124&oldid=1251587913"