Jump to content

Wikipedia:Village pump (technical)/Archive 111

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

Transliteration in searching

Hello, the search engine doesn't know to associate characters with their diacritics. For example if your search word has an "a", it won't suggest the same word that contains "á" instead of "a".

On Romanian Wikipedia, when I search for Carol Popp de Szatmary it shows only 3 results, and it won't include the ro:Carol Popp de Szathmári article, which is almost the same with the text I was searching. You can check that for yourself: [1] or search Szatmary

Another example: search for „Agri” and the result doesn't include ro:Ağrı.

I already reported the bug here: Help talk:Searching#Transliteration in searching - Help talk:Searching/Archive 4#Transliteration in searching. If the auto-suggest drop-down list doesn't know to make those associations - fine (even though 2013 sounds like a lot). But the search engine should definitely know how to make such associations, in my opinion. Thanks. —  Ark25  (talk) 06:04, 26 April 2013 (UTC)

Well, I made an error, I haven't noticed the extra "h" in the "Szathmári" word. However, the "Ağrı" example is valid. I think the search engine should associate "ğ" with "g". —  Ark25  (talk) 08:32, 26 April 2013 (UTC)
As far as I can tell, the problem character in your other example is not ğ but ı (lower case dotless I). A search on agrı does find ro:Ağrı, but it doesn't find ro:Agri. The character is treated oddly. If it's the first character in a wikilink then it automatically works as i, for example in ı or ıce. If it's not the first character then it makes a redlink, for example kıte. If you enter ı in the search box and there is a title match with i instead of ı then it goes there, for example "kıte" goes to kite (with no redirect). But a search on kıte finds nothing. ı and i appear identical to the "Go" feature of the search box, but they aren't associated at all in searches. PrimeHunter (talk) 10:26, 26 April 2013 (UTC)
You are right. Also it jumps directly if ı it's the last character: typing in the searchbox "Ağri" and pressing enter - will jump directly to Ağrı, just like in the ıce case (and I think it should not jump there, it should just show the article on the top of the search result list). But if you search for "Ağri" the Ağrı article will not show in the search result list. —  Ark25  (talk) 10:43, 26 April 2013 (UTC)
That ıce = Ice = ice is undoubtedly due to the fact that the uppercase mapping of ı, as defined in the Unicode standard, is I.[2]—Emil J. 11:43, 26 April 2013 (UTC)
In fact, this probably also explains why “kıte” goes to kite from the search box: the “Go” feature appears to fold all letters to uppercase before attempting a match—if you type in “kItE”, it also goes to the same article.—Emil J. 11:54, 26 April 2013 (UTC)
Ah yes, {{uc:ı}} returns I, the normal upper case letter. This means that {{lc:{{uc:ı}}}} returns i, the normal lower case letter and not the one you started with. bugzilla:33643 is related. I don't know whether there is a bugzilla entry for i and ı not being associated in searches. PrimeHunter (talk) 13:23, 26 April 2013 (UTC)

Section title "AD" disappears

I type: 

Above section header
===AD===
Below section header

And I see rendered:

Above section header

Below section header

AD is the prefix of some old vacuum tubes. I can't jump there from the table of contents, either. I had to insert a blank between A and D as a workaround.

Is that some misguided spam filter? --Mkratz (talk) 16:27, 26 April 2013 (UTC)

Oh, I just found out. It's the AdBlock Plus extension in Firefox. Lots of people have that installed. Now what? --Mkratz (talk) 16:40, 26 April 2013 (UTC)
I don't have any problems seeing it with AdBlock enabled (though I usually have it disabled on en.wikipedia.org). It will surely depend on which filters you use in AdBlock. — HHHIPPO 17:21, 26 April 2013 (UTC)
Right. Seems I've neglected to choose the filter, so AdBlock defaulted to FanBoy's. No problems anymore with EasyList.
Yet, I guess I better leave the workaround in place. --Mkratz (talk) 18:14, 26 April 2013 (UTC)
Indeed, FanBoy's filter is blocking the word "ad". I wonder if that makes sense. How about this workaround: ===AD&nbsp;=== ? That looks basically the same, but tricks the filter. — HHHIPPO 20:51, 26 April 2013 (UTC)
Is FanBoy contactable? Could he be asked to correct his filters to not cause the false match? – PartTimeGnome (talk | contribs) 21:07, 26 April 2013 (UTC)
Might trick FanBoy, but there are lots of others. Better steer clear from the treshold. --Mkratz (talk) 22:18, 26 April 2013 (UTC)

Skin issues

I'm trying to replicate the appearance of the Classic skin within Vector, and would appreciate some guidance in customizing my (already-heavily-modified) css and js files. I was getting some help on meta:Tech, but that seems to have dried up for now. Note that I didn't write these modifications; other people very generously wrote them for me. Current issues include:

  • I'd like a "my contributions" link on all pages.
  • I'd like a "Watchlist" link on all pages.
  • I'd like a "current version" link on pages where I compare two diffs.
  • I'd like the "new messages" notifier to be at the very top of the page, rather than at the top of the article. Note that I already have modifications to remove the orange bar, because the orange bar is hideously ugly.
  • The vertical separator bar is an ugly shade of light blue. I'd like it to be a pleasant gray (RGB: 128, 128, 128). I know how to change most of the font colors already (and am actively doing it because the colors that Vector uses are ugly), but not the separator bar colors.
  • On a related point, the vertical separator bar goes too far down. It should stop just past the first four lines of the article (or equivalent). And no horizontal separator bar at the very bottom of the page, thank you.
  • The relative font sizes of the various elements are wrong. Currently, the font size of article text is (X), but the font size of text in the edit window is (Y). I would like these to be inverted. I would also like the text in the sidebar to be (X) rather than (Y).
  • I would like the sidebar to be somewhat narrower - like how it was in Classic.
  • I would like to completely eliminate all use of the "star" icon as it pertains to the "watch page" function.
  • There's an unsightly empty space at the top of the page (see File:Classic vs heavily-modified Vector (skin comparison) 1.jpg, File:Classic vs heavily-modified Vector (skin comparison) 2.jpg, and File:Classic vs heavily-modified Vector (skin comparison) 3.jpg -- but it's present in unmodified Vector too, just smaller). I'd like it refilled with the links shown in the comparison jpgs.

Thank you in advance for any advice or suggestions you can provide. DS (talk) 02:23, 27 April 2013 (UTC)

H.264 support

Tracked in Phabricator
Task T41869

Developments since Google reneged on dropping H.264 two years ago, possibly due to acquiring Motorola patents:

  • Wikimedia rolls out TimedMediaHandler supporting H.264 transcoding
  • WMF releases iPad app without Ogg or WebM support
  • Mozilla will support H.264 when the underlying platform supports it
  • Debian 7.0 "Wheezy" will decode H.264 media out of the box

Now that every modern platform supports it, so we're too late to pressure anyone into switching. So I suggest three transition phases: 1) Allow H.264 files masquerading as ogv/webm, 2) Allow uploading of H.264 and .mp4 extensions, 3) Enable transcoding to H.264. — Dispenser 05:38, 19 April 2013 (UTC)

This was never about pressuring anyone into switching. It's about Free and open information systems and not opening up ourselves to potential lawsuits by big techonlogy owners. Note that unlike for Mozilla for instance, we ARE part of those underlying systems (esp when it comes to transcoding), so there is quite a different risk assessment. —TheDJ (talk • contribs) 10:34, 19 April 2013 (UTC)
My post was to inform that all major platforms support H.264 video decoding, even Firefox on Debian the corner stop FOSS. H.264 is a "free" and open video codec, but patented (just like GIF). For the US, not even the oldest codec MPEG-1 (1992) is not patent free, and only more patent landmines have been laid. And even when Google purchases license from MPEG LA for everyone, it still doesn't the stop lawsuits. — Dispenser 23:03, 24 April 2013 (UTC)
Beyond the issues with proprietary formats, allowing "masqueraded" mime types seems very unwise. I have categorized those to be converted (some already have been), and filed bugzilla:47709 about those even making it to the site. Finally, GIF has never been free and open. Superm401 - Talk 08:06, 26 April 2013 (UTC)
Hasn't GIF been "free" since the patents expired in 2006? Anomie⚔ 21:27, 27 April 2013 (UTC)

Temporarily disabling WikiLove on English Wikipedia

Per T49457 and the discussion above, I'm going to temporarily disable the WikiLove extension until the underlying issues with mw.loader are resolved. Sorry for the inconvenience. If you need to spread WikiLove in the meantime, please reacquaint yourself with Category:WikiLove templates :) Kaldari (talk) 00:34, 26 April 2013 (UTC)

Technical editors

Dear tech people:

Does Wikipedia have volunteer technical editors (for creating the scripts, tools, templates, etc.)? If so, where is the best place to inquire about becoming one of them? I have substantial, although somewhat outdated, experience in this area. —Anne Delong (talk) 14:45, 26 April 2013 (UTC)

What do you need? mabdul 16:10, 26 April 2013 (UTC)

I don't need anything in particular right now myself, I just enjoy coding, and wondered if this was a way I could help. If that's not allowed, just say so. — Preceding unsigned comment added by Anne Delong (talk • contribs) 19:47, 26 April 2013 (UTC)

Yes, there are ways for volunteer coders to contribute. The easiest (least sophisticated) way is through writing templates, which are just bits of specialized wikitext in the Template namespace. We also have Gadgets (written in Javascript), Modules (written in Lua), Skins (written with CSS). For more sophisticated programmers, one can also volunteer as a Mediawiki hacker (using PHP). With a bit more guidance about what you are looking for, perhaps we can point you in a more specific direction. Dragons flight (talk) 19:59, 26 April 2013 (UTC)
If you are able to edit the required page then you can just go ahead. Creating and editing templates, Lua modules or user scripts is like editing articles. There is no application process or official teams or leaders assigning tasks. PrimeHunter (talk) 23:17, 26 April 2013 (UTC)
Watchlisting this page would be a good start. People come here a lot to seek help from people such as yourself. Also, #mediawiki connect and #wikimedia-tech connect have lots of your types. :) Killiondude (talk) 01:08, 27 April 2013 (UTC)
Thank you. I would like to help out, but I know that errors can have more serious repercussions than when editing a regular text page. Are there standards and procedures essays that I should read before I make any changes? Or is everything usually located on the talk pages attached to the object? I am familiar with Javascript and PHP, but I would rather start out small. —Anne Delong (talk) 14:44, 27 April 2013 (UTC)

How can a page exist without any history

The page MediaWiki:Common.css/User:Paladox2014 exists (in that it's got an "edit this page" link not a "create this page" link), but it has no history. How can that happen? --Redrose64 (talk) 19:44, 27 April 2013 (UTC)

The same thing happens for all subpages of MediaWiki:Common.css. Assuming it's just a placeholder built into mediawiki. —Theopolisme (talk) 19:49, 27 April 2013 (UTC)
"MediaWiki:Common.css/User:Paladox2014" means the interface message "common.css" in the language with code "User:Paladox2014", just as "MediaWiki:Common.css/de" means the interface message "common.css" in German (code "de", from ISO 639). Of course, no language has code "User:Paladox2014", so it falls back to the default English message distributed with MediaWiki.
Since the interface message "common.css" does exist in MediaWiki, the software displays an edit link rather than a create page link. Anomie⚔ 21:43, 27 April 2013 (UTC)
As a little curio, non-existing languages cannot be chosen in preferences, but they can actually be chosen with uselang= in the url. For example, the page MediaWiki:Uploadtext/en-screenshot exists although "en-screenshot" is not intended as a language code. But if you replace http://en.wikipedia.org/wiki/Special:Upload with http://en.wikipedia.org/wiki/Special:Upload?uselang=en-screenshot then the software thinks you want to display Special:Upload in a language called en-screenshot, so you see MediaWiki:Uploadtext/en-screenshot. PrimeHunter (talk) 21:59, 27 April 2013 (UTC)
OK. Does anybody know why on earth Paladox2014 (talk · contribs) might need to create that page (see MediaWiki talk:Common.css/User:Paladox2014), or indeed what they're up to? The user account was created only yesterday, but from their edits so far (the very first was to create MediaWiki talk:Common.css/Wikipedia:Main Page/sandbox), I get the distinct impression that they want to jump right in with something hideously complicated - a redesign of the main page (without discussing it with others) is just one possibility. I might have formed entirely the wrong impression though. --Redrose64 (talk) 22:59, 27 April 2013 (UTC)
At the page you linked above, xe said "but how can I create for example Mediawiki:Common.css/User:Paladox2014/Main Page"...which makes it look like this was a failed attempt at that. WP:CLUE could be an issue. —Theopolisme (talk) 23:07, 27 April 2013 (UTC)

Removing the "Secure your account" information from the login screen

Hi. I've started a discussion at MediaWiki talk:Loginend#Future of this message about whether we want to continue including the "Secure your account" information on the login screen. Please discuss at the link provided. --MZMcBride (talk) 21:43, 27 April 2013 (UTC)

<Imagemap>

I recently created a clickable image for the infobox in Paris using Extension:ImageMap. However, this has added a couple of extra lines around the image, so is there a way for the infobox to look like it does in this revision but still to be clickable?--Gilderien Chat|List of good deeds 22:17, 27 April 2013 (UTC)

Done.[3] PrimeHunter (talk) 22:33, 27 April 2013 (UTC)
Thank you very much :) --Gilderien Chat|List of good deeds 22:38, 27 April 2013 (UTC)

Please say yes or no to this Afc proposal.

Dear editors: Last week I posted a proposal for an addition to the Afc submission process at my user page User:Anne Delong/AfcBox and asked the reviewers on the Afc talk page to respond at User talk:Anne Delong/AfcBox. After several of the reviewers showed interest, and with support from FoCuSandLeArN and some input from mabdul I asked for a technical assessment at Wikipedia:Village pump (proposals) and also at Village pump (technical).

Since then there has been a lot of discussion on all three talk pages about various ways to improve the Afc submission process, but aside from TheDJ, who indicated that my proposal was technically feasible, and Ypnypn , who agreed that PHP shouldn't be needed, all of the discussion has centred around alternative and more complicated ideas using bots, javascript, etc. These are likely good ideas, but don't provide feedback on my original simpler proposal.

Please will someone let me know if this simple proposal (rather than the other alternative ideas) is worth pursuing, or what's wrong with it if not, by posting your opinions at User talk:Anne Delong/AfcBox. If no one likes the idea, and people instead want to go in a different direction, I will delete it. If people agree that the proposal has merit. Petrb has agreed to set it up. I am posting this on all three talk pages hoping to get a decision one way or the other. Thanks for your time. —Anne Delong (talk) 22:56, 27 April 2013 (UTC)

Updating portal box images

I am looking to update the image displayed for the Portal:Coffee portal box (the box that's used in the See also sections of articles). I know that there's a page to update the image, but I just cannot find it at this time. I'm looking to update the generic portal puzzle image with File:A small cup of coffee.JPG. Northamerica1000(talk) 03:17, 28 April 2013 (UTC)

See Template:Portal#Image Nanonic (talk) 04:20, 28 April 2013 (UTC)

 Resolved. Thanks very much Nanonic. Cheers, Northamerica1000(talk) 05:07, 28 April 2013 (UTC)

Edit protect request to highly-visible template stalled?

Hi all! About a week ago, the Wikipedia:Route diagram template (RDT) project pushed out two edit requests to modify two highly-visible templates:

However, it seems to me that these two requests were not addressed like other editrequests were, even after I wrote on WP:AN to ask to clear the backlog. May I know is there any special procedure to ask for large-scale modification to protected templates? Also can any administrator with the technical background to take a look on it? Thanks.

The background of this large-scale modification is at WT:RDT#Edit protected request 2013-04-17. — Peterwhy 16:42, 24 April 2013 (UTC)

Oh, I'm aware of it, just as I'm aware of all the other backlogged items at Category:Wikipedia protected edit requests, but I no longer touch anything that isn't 100% clear-cut cast-iron copper-bottomed uncontroversial; and in the case of templates (which these are) tested to destruction. This is because of the criticism that I have received when I fulfilled some requests that hadn't been discussed to death first. See also this discussion, if you have the patience. --Redrose64 (talk) 18:56, 24 April 2013 (UTC)
Hi Redrose, thank you for your response. I agree the original discussion has been quite limited to within WT:RDT, so I would like to know, what we should actually do to gain wider acceptance to this modification? And to eventually get the modification done? — Peterwhy 01:34, 25 April 2013 (UTC)
Admins unfamiliar with what a template does or how it works shouldn't carry out a proposed change without being certain that the change is beneficial, especially when the template is highly-visible. So, at the very least, I (and probably others) would like to see some WP:TESTCASES which both prove that these changes do what they're supposed to do, and also demonstrate that existing usage is not compromised.
I see that the proposed change to {{BSpx}} has been put into {{BSpx/sandbox}}, and that's great; but the proposed change to {{BS-overlap}} is not in {{BS-overlap/sandbox}}. Apparently it's in {{BS-overlap/sandbox2}} but that's more difficult to check since it doesn't have automatic links from the box at the bottom of Template:BS-overlap/doc nor from the {{editprotected}} box at Template talk:BS-overlap#Edit protected request 2013-04-19. The text after that states, rather vaguely, "we will have to modify some more unprotected templates afterwards" without detailing which ones nor in what way. I therefore cannot carry out any tests myself, which again means that testcases are needed.
As a frequent user of RDTs, I know what the overall suite is supposed to do, and for me there is one huge unanswered question: by changing the image size specifier from a height to a width, what will this do to those RDTs (such as this one) which use non-square icons? There are plenty of half-width icons such as   (exdKHST-Ra); there are also some double-width icons such as   (bvWSL-BS2+lr) (and even a few quarter-width icons like   (cSTRq)); these have had a constant height because {{BSpx}} contains x20px and not 20px - testcases will go a long way toward showing that these still work. --Redrose64 (talk) 06:37, 25 April 2013 (UTC)
{{BS-map
|title = Double/half/quarter/3-quarter
|legend=no
|map = 
{{BS/sandbox|bvvWSLg+lr}}
{{BS3/sandbox|dSTR|d|dSTR|O3=dBHF|L3=Station||Station}}
{{BS3/sandbox|SPLa|dBS2+l|dBS2+r}}
{{BS3/sandbox|v-STR|O1=vENDEa-|SPLe|vSTR-|O3=v-ENDEa}}
{{BS3/sandbox|SPLe|STR|SPLe}}
{{BS3/sandbox|bvvWSLgr|CONTf|bvvWSLgl}}
{{BS3/sandbox|STRl|b|STRr}}
}}
Yes, I see I have to address your concerns before getting things changed.
Let me know if you have any other concerns. — Peterwhy 13:53, 25 April 2013 (UTC)
Additional note for the last point: we did not change "the image specifier from a height to a width", we change that from size to height. So this does not conflict with the original intention to add that x to {{BSpx}}. — Peterwhy 15:16, 25 April 2013 (UTC)
  • Route maps 3x faster by {BS-overlap} update: Today, at 09:12, 28 April 2013‎, the route-map formatter Template:BS-overlap was updated (for the first time in 3 years) to use quick icon-overlay by {Template:Superimpose5} and omit {BS-alt} which was setting alt-text for each pictogram. Those changes have allowed many route-map diagrams to reformat about 3x faster, such as former 12-second maps now 4 sec. Unfortunately, the update also dropped the image-links (to each pictogram image-description page), which is likely improper handling of artwork-attribution links. Anyway, that update allows testing to confirm how the route diagrams can be edit-previewed 3x times faster now, and further updates can be discussed at WT:Route_diagram_template. Part of the problem had the fully-protected {BS-overlap}, and so there were several pent-up improvements which were delayed during the past 3 years. I have created a spike-solution variation to allow fuller testing of the complex features, and to format the pictogram alt-text much faster. However, the image-attribution links probably need to be re-added soon in Template:BS-overlap. -Wikid77 (talk) 10:25, 28 April 2013 (UTC)

Anyone willing and able to fix User:GregU/dashes.js?

User:GregU seems to have become inactive, and I've discovered a bug in this widely-used script (it has been incorporated in AutoEd, and is a js gadget).

The bug is pretty simple: it will modify the dashes and hyphens in section headers, and this breaks any wikilinks from redirects or other articles that link directly to the section. All it takes to fix it is to place {{anchor|original section header}} as the first line in the modified header whenever the tool modifies a section header. That way, people that worry about the appearance of dashes vs. hyphens stay satisfied and the incoming wikilinks and redirects stay working.

Anyone comfortable enough with Javascript editing of Wikipedia articles to take on the fix?—Kww(talk) 22:40, 26 April 2013 (UTC)

/me points to User:Writ Keeper. —Theopolisme (talk) 22:57, 26 April 2013 (UTC)
  • No one in the real world cares to force hyphens as dashes: Every so often we need people to come up for air, and learn that the world has stopped caring about the hyphen/dash issues. However, months ago someone had misled me into thinking the prestigious journal Nature had somehow advocated a style to use dashes between two-term expressions; however, after days of closer inspection, I discovered the truth is that Nature allowed the authors to use whichever dash/hyphen styles they preferred, even to mix hyphens and dashes in conflicting styles, such as page ranges "2-5" and "2–6" in the same peer-reviewed article. The 19th-century term "hyphenated Americans" states exactly what punctuation to use. Also, I learned, with the Michelson-Morley Experiment, even those two scientists spelled their Experiment with a hyphen (not a dash). Perhaps more confusing, the Adobe Reader will search with hyphen to match any dash or hyphen in the PDF-format text. Changing hyphens to dashes is just not as important as imagined some years ago, and has become viewed as balderdash. The world decided it did not care, and even hyphens have been removed from formerly hyphenated terms during the past 40 years. Spread the word down to the wiki-mines underground. -Wikid77 (talk) 22:17, 28 April 2013 (UTC)

Does anyone have a list of retired namespaces?

Due to the nature of this question, I believe that this is the correct forum for it. As an editor who did not become really involved in Wikipedia until 2012, but did look at Wikipedia from time to time from 2004 and onward, I thought I remembered seeing other name spaces on Wikipedia than the ones that exist today such as (article), Wikipedia:, Help:, MediaWiki:, Template:, etc. Essentially, I'm trying to build a proposal for a new namespace, but I want/need to make sure that what I'm trying to propose doesn't take the Wikipedia project backwards in time. So, does anyone have a list of any retired namespaces, or could someone either direct me to a page in Wikipedia where this list can be found? Steel1943 (talk) 23:57, 27 April 2013 (UTC)

Wikipedia:Namespace lists all of them, if I'm not mistaken. What exactly are you trying to propose? —Theopolisme (talk) 00:19, 28 April 2013 (UTC)
Thanks for that link Theopolisme, but that article only lists currently active namespaces; I'm looking for retired ones. And for your second question: basically, look at my user page for the answer to that one: I'm not trying to bring too much attention to that proposal since I have no idea yet if I would be taking steps backwards in the progress of this Wikipedia. Knowing about any retired name spaces could help with my latter concern. Steel1943 (talk) 00:42, 28 April 2013 (UTC)
An aside: I don't think that "stepping backwards" is always a bad thing. But in looking at your proposal and doing a bit of searching, I don't think that a specific Draft space has ever existed on Wikipedia. —Theopolisme (talk) 01:14, 28 April 2013 (UTC)
I am pretty confident that no namespaces have ever been "retired". — This, that and the other (talk) 01:53, 28 April 2013 (UTC)
indeed, no namespaces have ever been discontinued here. Graham87 04:49, 28 April 2013 (UTC)
We have switched the default names for certain namespaces ("image" has mostly been switched to "file"), but the same namespace still exists (and the old names\links still work). Could this be what you're thinking of? Andrew Gray (talk) 22:45, 28 April 2013 (UTC)

Score !!

Tracked in Phabricator
Task T2189
Resolved
Tracked in Phabricator
Task T49534

After many years, one of the most voted and oldest feature requests has been solved. As of today, Wikipedia finally has a renderer for music notation. See Mark's sandbox for an example. Congrats to the original filer xmlizer ! And a thank you to all who helped write the various generations of the extension and those that reviewed the code. —TheDJ (talk • contribs) 08:35, 23 April 2013 (UTC)

More at Help:Wiki markup#Musical notation. --Redrose64 (talk) 10:18, 23 April 2013 (UTC)
There is also a Wikibook in French which could be translated and added to English Wikibooks: b:fr:Introduction à LilyPond. Helder 13:13, 24 April 2013 (UTC)

Is this working? I tried adding the following code to Première rhapsodie: 

<score raw=1>
\version "2.11.63"

\score {
  <<
    \new Staff="clar" \relative c'' {
      \clef treble
      \numericTimeSignature
      \time 4/4
      \key aes \major
      
      \mark \markup {\bold \small "Reveusement lent"} 
      R1 | r4 g\p_\markup {\italic \small "doux et expressif"}( bes c)
    }
    
    \new PianoStaff {
      <<
        \new Staff="one" \relative c'' {
          \clef treble
          \key ges \major 
          \numericTimeSignature
          \time 4/4
          
          r4\pp
          << { f2( f'4~) | f1 } \\
             { f,2.~ | f1 } \\
             { s2. | \times 2/3 { e'8\>( ees c~) } c2.\! } >>
        }
        
        \new Staff="two" \relative c' {
          \clef treble
          \key ges \major
          \numericTimeSignature
          \time 4/4
          
          << { f1--~ | f1 } \\
             { s1 | \times 2/3 { e8\>( ees c~) } c2.\! } >>
        }
      >>
    }
  >>
}
</score>

but it failed with the error 

Processing `/tmp/MWLP.926c7a5f74a89391d70986be99418a50/file.ly'
Parsing...
Interpreting music... 
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
Layout output to `file.ps'...
Converting to PNG...GS exited with status: 9ERROR: In procedure delete-file:
ERROR: No such file or directory

Or is raw=1 not supported here? --SarekOfVulcan (talk) 16:16, 24 April 2013 (UTC)

raw is supported.—Emil J. 16:47, 24 April 2013 (UTC)
[[here says that raw would be used with lang="lilypond". But is estrange that no mark what error is here get an error after put a r8 and I don't know why. Is possible that have a bug in extension? --88.8.254.79 (talk) 16:11, 29 April 2013 (UTC)
lang="lilypond" is the default, it is not necessary to specify it explicitly. A simple test with raw=1 works fine:
<score raw="1">
\version "2.14.2"
\header { tagline = "" }
\score { \relative c' { c d e f } \layout { } \midi { } }
</score>
\version "2.14.2" \header { tagline = "" } \score { \relative c' { c d e f } \layout { } \midi { } }
The error messages in both your and SOV’s examples suggest that the music was laid out all right, but the final conversion of the output from PostScript to PNG failed. This could indicate a problem with ghostscript rather than with lilypond proper.—Emil J. 16:31, 29 April 2013 (UTC)
FWIW, Ghostscript’s exit status 9 is invalid file access. There may be a problem with paths or file permissions. This should be reported to bugzilla, but I think it would be helpful if someone knowledgeable with lilypond syntax could make a simplified minimal example triggering the bug.—Emil J. 16:59, 29 April 2013 (UTC)

Hanging userpages

Tracked in Phabricator
Task T49457

I'm getting an odd effect when trying to access pages in userspace (doesn't affect any other namespace). The pages load, then appear to attempt to refresh, but do so unsuccessfully, leaving the browser hanging. Stoping the page load and hitting the Back button takes me to the correct page. I'm running Firefox 5.0.1. Anyone else spotted this, or know of a solution to it? Yunshui 雲‍水 08:01, 24 April 2013 (UTC)

Seems like the same issue as on Commons. It's reported, will take some time before it's actionable I think. —TheDJ (talk • contribs) 08:26, 24 April 2013 (UTC)
One fix on commons was to disable the wikilove option in prefs and another was right-click and open new window (not tab).--Canoe1967 (talk) 08:29, 24 April 2013 (UTC)
Wikimedia developers are working on this and trying to find the culprit, but haven't succeeded so far. See the bug report that was linked by TheDJ. --AKlapper (WMF) (talk) 10:12, 24 April 2013 (UTC)
While logged in with Firefox 20.0.1 it is not possible for me to open User:TheDJ and User:AKlapper (WMF) in new tabs on English Wikipedia. I can open User:Yunshui and User:Canoe1967 in new tabs. These are users commenting in this thread. I can open them all in the same tab without problems. (Note for techs working on this: I am using https and not http).
The Commons discussion is here: Commons:Village pump#April 21.
The problem is solved when i uncheck "Enable showing appreciation for other users with the WikiLove tab" in my preferences here: Special:Preferences#mw-prefsection-misc. --Timeshifter (talk) 13:12, 24 April 2013 (UTC)
  • I believe this is the hanging resolvable by hitting the back button on my browser that I came here to report. I haven't noticed its being restricted to userspace pages, though. (Good that it's been reported, since I found it impossible to figure out what versions of my OS and browser I'm using - Win7 and Firefox something something). Yngvadottir (talk) 18:06, 24 April 2013 (UTC)

Cannot edit user talk pages - but fine elsewhere

At first I thought this was a browser issue, but seeing as my issue is limited to user talk pages only, it may not be...basically, I cannot edit user talk pages. I cannot even access them. As soon as I click on them I get half-a-second of normal display, before the screen goes blank. Mainspace? Fine. Other talk pages? Fine. User talk pages? No chance. Very odd. Help appreciated. GiantSnowman 13:08, 24 April 2013 (UTC)

See #Hanging userpages, above. If you have Wikilove enabled, try turning that off. -- John of Reading (talk) 13:21, 24 April 2013 (UTC)
Perfect, thanks. GiantSnowman 13:47, 24 April 2013 (UTC)

Unable to view user talk pages in firefox (problem with bits.wikimedia.org?)

Today I am unable to view most pages in the user talk namespace (other than my own talk page) - I get a brief flash of then page and then just a blank page while it apparently tries to "Read bits.wikimedia.org" according to the status bar, but the page never completes loading.

This is only happening in Firefox (20.0 on Xubuntu linux) and works fine in Konqueror and Links (the only other browsers I have access to) and is a new problem since last night when it was working fine (e.g. I was able to leave a message at User talk:CACook7).

I do run the NoScript extension but wikipedia.org and wikimedia.org are whitelisted, the script shows no blocked elements and temporarily disabling it does not make a difference. I am able to load the bits.wikimedia.org page (which redirects to www.wikimedia.org) without any issues. Thryduulf (talk) 15:16, 24 April 2013 (UTC)

Look up two or three sections for other reports of this. If you have Wikilove enabled, try disabling it. -- John of Reading (talk) 15:26, 24 April 2013 (UTC)
Thanks, disabling wikilove appears to have solved the problem. Thryduulf (talk) 15:30, 24 April 2013 (UTC)
#Hanging userpages -- You can be happy that you are an en.wp user. Obviously en.wp is more important than Commons. After AKlapper found the posts here, he changed the bugs relating to highest prio. This is the usual attitude towards Commons users. We get their test software first and if we find issues they are not important until they appear here. -- Rillke (talk) 15:32, 24 April 2013 (UTC)

I haven't been able to view lots of user talk pages today, but it is perfectly possible to edit the same pages (by manually adding "?action=edit" at the end of the URL). The wikilove icon is present on the edit page too, so why is the edit form still working? --Stefan2 (talk) 22:30, 24 April 2013 (UTC)

It's not just Firefox - I'm having the same problem with some user talk pages with IE9. Mine seems to be fine, as is User talk:Okeyes (WMF) and User talk:Rillke. However, I see the problem on User talk:Thryduulf and User talk:John of Reading. GoingBatty (talk) 23:55, 24 April 2013 (UTC)
Confirmed that disabling the WikiLove extension fixes the issue. GoingBatty (talk) 00:01, 25 April 2013 (UTC)
Worked for me too - thanks to all the above for identifying disabling WikiLove as a temp fix. -- stillnotelf is invisible 15:19, 25 April 2013 (UTC)

Thanks for the explanation. Is there any way to sign for a notification of when this problem is solved so that WikiLove can be reenabled? I find it very helpful in building a collegial, friendly atmosphere. --Piotr Konieczny aka Prokonsul Piotrus| reply here 03:51, 25 April 2013 (UTC)

You could add your email address to the bug's cc list. That will send you an email every time there is a change to that bug, including a new comment, which is isn't quite what you are after. The only other thing I can think of is that I can try to remember to put a note on your talkpage when I see it's been fixed, but I can't promise to remember or to be online when it happens. Thryduulf (talk) 09:26, 25 April 2013 (UTC)

Fixed

We have deployed a change that should fix this problem, and have re-enabled WikiLove. If you see any more problems along these lines, please reply here, or at T49457, or at #wikimedia-tech connect. Thanks. BJorsch (WMF) (talk) 23:22, 29 April 2013 (UTC)

User talk pages not loading with Firefox

Tracked in Phabricator
Task T49457

I can't get user talk pages to load today using Firefox. Other pages are fine, but user talk pages won't load as diffs or when I try to edit them. It's only happening with Firefox. SlimVirgin (talk) 21:21, 25 April 2013 (UTC)

Amusingly this is happening to me with user pages and some diffs. It has improved a bit during the day but not that much. Now it takes me a few tries. Snowolf How can I help? 21:23, 25 April 2013 (UTC)
There are a few threads about this up above from yesterday; try disabling the WikiLove tab (in Special:Preferences, on the "Misc." tab) and see if that helps. Writ Keeper ⚇♔ 21:24, 25 April 2013 (UTC)

I started seeing this too today. In Firebug Net tab, it says these URLs are loading endlessly:

http://commons.wikimedia.org/enwiki/w/index.php?title=MediaWiki:Gadget-HotCat.js&action=raw&ctype=text/javascript
http://en.wikipedia.org/enwiki/w/index.php?action=raw&ctype=text/css&title=MediaWiki:Gadget-navpop.css
http://en.wikipedia.org/enwiki/w/index.php?action=raw&ctype=text/javascript&title=MediaWiki:Gadget-popups.js

If I interrupt loading quickly enough, it doesn't get stuck like that and I see the page normally. Really annoying, though. --Joy [shallot] (talk) 21:51, 25 April 2013 (UTC)

  • I disabled WikiLove as Writ Keeper suggested, and the talk pages loaded again. I re-enabled it, and then they wouldn't load. So that seems to be the culprit. Thanks, WK. SlimVirgin (talk) 21:57, 25 April 2013 (UTC)
In the meantime I found bug 47457 (esp. comment #28). Ditto. --Joy [shallot] (talk) 22:15, 25 April 2013 (UTC)
This is handled in bugzilla:47457 and being worked on. Sorry for the inconvenience. Also see "Temporarily disabling WikiLove on English Wikipedia" below. --AKlapper (WMF) (talk) 10:03, 29 April 2013 (UTC)

Cat Scan

Is there a way i can find the articles of a category in english wikipedia that have an article in italian wikipedia? Xaris333 (talk) 11:47, 28 April 2013 (UTC)

Sounds like something you might want to ask the Wikidata folks. —Theopolisme (talk) 12:45, 28 April 2013 (UTC)

Done! Xaris333 (talk) 01:03, 30 April 2013 (UTC)

Wrong version of Edit tools

Resolved

Hi. Two or three days ago, the version of the Edit Tools that I get changed from the click-to-insert version depicted at MediaWiki:Edittools to the much more clunky copy-to-paste version. I haven't touched my preferences (and can't even see which preference would affect this). MSIE8 with active scripting enabled; Vector skin. Thanks for any help. --Stfg (talk) 13:21, 28 April 2013 (UTC)

Sounds like js in general might be failing somewhere - do other things still work, such as the search dropdown options, collapsible navigation, etc? -— Isarra ༆ 17:25, 28 April 2013 (UTC)
(edit conflict) what you describe is not what editTools supposed to do, and it's not what it does for me, so i think the problem is not general, but somehow specific to you. the first thing i'd do is try to see if it's related to your browser/computer or to your user account. the simplest way to test it is to log out, and try it again: edittools is on by default (too lazy to check, but i think it's a default gadget, rather than something added by Mediawiki:common.js ). if it has to do with your account, you probably want to go over your vector.js and common.js, and comment out one line at a time until you find the culprit, and discuss it with the owner of the imported script. if it happens when logged out also, please come back here and report - with as many details as you can (browser precise version, OS, which edittool is it that behaves this way, maybe even in which article did it happen, and any other detail you can think of). peace - קיפודנחש (aka kipod) (talk) 17:27, 28 April 2013 (UTC)
Search dropdown and collapsible navboxes work fine. Problem goes away when I log out. I've completely cleared my vector.js, common.js and, for good measure, vecrtor.css also (and remembered to clear the cache ) None of this removes the problem when logged in. By the way, I get the desired click-to-insert edit tool when editing these three files -- but only these three; editing anything else -- mainspace article, page in my user space, template -- still has the problem. I haven't done anything to my account for ages. I have Win XP (home) with SP3, fully patched. Browser version is MSIE 8.0.6001.18702. Thanks again for looking at this. --Stfg (talk) 19:26, 28 April 2013 (UTC)

I've bypassed the problem by removing one of the scripts from my vector.js and have started a discussion with the designer. Please don't invest any more of your time in it, and thanks for the help so far. --Stfg (talk) 16:36, 29 April 2013 (UTC)

Manipulating categories

Resolved

Is there a way (a Special page similar to Special:ComparePages, perhaps) to see an automatically generated list of all the members of e.g. , , etc.? It Is Me Here t / c 15:03, 28 April 2013 (UTC)

Yep, Wikipedia:CatScan seems like exactly what you're looking for. —Theopolisme (talk) 15:08, 28 April 2013 (UTC)
Thank you It Is Me Here t / c 09:27, 29 April 2013 (UTC)

Parser function question

{{User:Peterwhy/sandbox|

example.png

}}

I notice that the #if: function would trim line breaks from parameters 2 and 3, as shown above with User:Peterwhy/sandbox. I would like to know if this is an intended effect? Thanks. — Peterwhy 18:37, 28 April 2013 (UTC)

It's a known and long-established feature of the MediaWiki template parser that leading and trailing whitespace is significant around positional parameters, but not around named parameters. It's unlikely to change. Parser functions such as {{#if:}} strip surrounding whitespace from their output. --Redrose64 (talk) 20:04, 28 April 2013 (UTC)
  • Use the space-sensitive if-templates: There are some special templates which allow a space-sensitive result, with newline linebreaks, in conditional expressions. For example, using Template:ifeq or Template:ifexpr:
  • "{{ifeq|{{{it|xx}}}|xx| It is xx. }}" → "{{ifeq|{{{it|xx}}}|xx| It is xx. }}"
  • "{{ifexpr|{{{| {{{age|19}}} >= 18}}} | Over 18 }}" → "{{ifexpr|{{{| {{{age|19}}} >= 18}}} | Over 18 }}"
Those templates are extremely fast, so could be used hundreds of times with no significant delay. When the data contains an equals sign ("="), then pass the data inside a null-named parameter {{{|____}}}. -Wikid77 (talk) 23:05, 28 April 2013 (UTC)
Wikid77, please stop confusing the issue. There is no need for such complicated techniques; moreover, Peterwhy does not want to preserve the whitespace, because that breaks the image linking. What is needed is to trim the whitespace, and the construct that Peterwhy has already used (see the example that he began this thread with, his sandbox also this edit), i.e. {{#if:1|{{{paramname|}}} }} works perfectly well, and since it uses a single parser function, which is built in to the MediaWiki software, is bound to be faster than any template-based alternative. --Redrose64 (talk) 08:45, 29 April 2013 (UTC)

Problem editing a table

Today on List of vegans, when I added a name to the sortable table and previewed, it wasn't formatted as a table, but as lines of text:

|- !scope="row" | John Salley |Retired professional basketball player, actor and talk show host |United States |[1][2][3] - !scope="row" | Chad Ackerman |Singer, songwriter |United States |[4]

But when I saved, it was properly formatted. This problem only started today. It's happening repeatedly, with more than one browser, and with an account with different preferences. Can anyone think what the problem might be? SlimVirgin (talk) 21:20, 28 April 2013 (UTC)

Let me guess... it began happening after you had saved this edit. What you did there was to split the table into editable sections; as a result, when you edit any of the sections that occur after the start of the table, the table start code won't be present when you preview, but it will be there once saved. --Redrose64 (talk) 21:53, 28 April 2013 (UTC)
I noticed it today at 17:42, 28 April 2013‎; I think it was okay after the sections were first added, but I'm not sure. We need the subsections because loading the whole table is very slow and hard to edit with; it also leads to edit conflicts. But we also need the code to be present on preview, because people will think they've messed it up and won't save. So it's not just a nuisance factor, it will stop people from editing. What can be done, do you think? SlimVirgin (talk) 22:50, 28 April 2013 (UTC)
  • Split into subarticles by alpha group: The only way to edit-preview part of a sortable table, with table headers, is to create transcluded sub-articles, where each page shows a part of the total list, but the overall list shows all subarticles transcluded together. For example, with letters A-F, create subarticle "List of vegans A-F" as if being a template, to allow edit-preview with table headers. Each subarticle page would be structured in the following manner:
         <noinclude>
         This is part of the '''[[List of vegans]], names A-F''' as a shorter
         section of the whole list.
         {| class="wikitable sortable plainrowheaders"
         |-
         ! scope="col" style="width:8em;"|Name
         ! scope="col" style="width:35em;"|Occupation
         ! scope="col" style="width:6em;"|Birthplace
         ! scope="col" class="unsortable" style="width:5em;"|Source
         </noinclude>
         |-
         person 1
         |- 
         person 2
         <noinclude>
         |}
         ==References==
         {{Reflist}}
         [[Category:...]]
         </noinclude>
Then, once separated into subarticles as the partial lists, each would be transcluded into the full "List of vegans" by treating each subarticle as if being a template file, trancluded by: {{List of vegans A-F}} in doubled curly braces. As the list grows, perhaps each subarticle would be sub-divided more, to span just 4 letters of the alphabet, rather than 6 letters A-F. So, plan now for how many letters in each subarticle. Note that each subarticle is truly a WP article (not a template), with lede paragraph and References, plus categories. However, that gives readers the option to view each subarticle if looking for vegans with names under just those letters. -Wikid77 (talk) 23:47, 28 April 2013 (UTC)
Thanks, Wikid. That sounds a bit complicated, and would it be confusing for new editors? I'm wondering whether it makes more sense just to have regular subsections (A-F, etc); that is, multiple tables. SlimVirgin (talk) 01:19, 29 April 2013 (UTC)
As a screen reader user, I'd prefer to just have multiple tables. The table does work with my screen reader JAWS, but it interprets the headings as part of the table header, meaning that I hear "A–F" along with the edit link when I navigate horizontally through the table; not a showstopper, but quite annoying. A big long table without headings shouldn't lead to edit conflicts, though, unless two users are trying to add people at the same point in the alphabet. Graham87 07:11, 29 April 2013 (UTC)
Personally I'd go with separate tables for each group, as we have done on pages like List of closed railway stations in Britain: D-F. But to return to the original matter; there is a simple technique, but it must be done carefully. When editing a section within the big long table, make your edit, and then go to the top of the edit window and insert one line immediately after the section header: 
{|
and then go for Show preview Having verified the intended edit, make sure that you remove that {| before clicking Save page, because if you don't, you'll create a table-within-a-table, and almost certainly screw up the page formatting. --Redrose64 (talk) 09:10, 29 April 2013 (UTC)
In general, adding more complexity in order to create a solution to a complex problem is often not the best idea. Go with separate lists. —TheDJ (talk • contribs) 10:01, 29 April 2013 (UTC)
Many thanks to everyone for the input. Separate tables/sections seems to be the simplest solution. Thanks again. SlimVirgin (talk) 17:41, 29 April 2013 (UTC)

Pictures from Maps+ iPad app

Just a quick question: I have a couple of pictures taken from the Maps+ app on my iPad mini. Is it against any regulations to use them as pictures, and if it was permissible, under what licenses would they be put under. Also, I use a Safari browser on my iPad mini. --JB82 (talk) 23:02, 28 April 2013 (UTC)

That sounds like they would be copyrighted violations in most cases. The design of the app is owned by IZE, Ltd and the map imagery is owned by Google and it's map providers. There is some information on this topic in our WP:SCREENSHOT page. —TheDJ (talk • contribs) 07:39, 29 April 2013 (UTC)

Body font size

I am a beginner in CSS. Sorry if it sounds dumb to ask or if this is posted on a wrong page. I want to know how I can increase the body font size so that browsing on ipad could be a little easier. I tried messing with the CSS code but ended up with larger texts in all he toolboxes but not the article itself. — Preceding unsigned comment added by Lauivan (talk • contribs) 09:55, 29 April 2013 (UTC)

Open all articles of a category

Is there a way to open all articles of a catecory (not by click one by one)? With firefox for example? Xaris333 (talk) 18:22, 29 April 2013 (UTC)

WP:LINKY should do what you want in Firefox. jcgoble3 (talk) 19:29, 29 April 2013 (UTC)

Thx. Very useful. Xaris333 (talk) 22:21, 29 April 2013 (UTC)

Caterogies

Is there a way i can find all tha categories i have created? Xaris333 (talk) 19:09, 29 April 2013 (UTC)

Follow this link and hope the toolserver is in good mood... It seems the only hit is Category:Nea Salamina Famagusta managers. — HHHIPPO 19:22, 29 April 2013 (UTC)

Thx. Very useful. Xaris333 (talk) 22:21, 29 April 2013 (UTC)

Toolserver tools dysfunctional?

It appears that something strange has happened with the Toolserver. I was reviewing a AfC submission (Wikipedia talk:Articles for creation/Marc Danzeisen) and clicked the link (in the AFC template) to do WP:REFLINKS. To my astonishment I got a series of errors, eventually ending up at toolserver saying that the page doesn't exisist as a wiki. To verify I'm not going crazy I also checked Citation bot to see if something was up. It's been 10 minutes and Citation Bot has yet to finish. I do not think this is a web browser problem based on the fact that these links worked not 5 minutes before this oddity. Status Dashboard shows no issues. Hasteur (talk) 19:10, 29 April 2013 (UTC)

You're lucky that you got a message at all... I often get a blank screen, that's if it doesn't hang or timeout. If you look at past threads on this page, you'll realise that Toolserver has been having problems for months now. --Redrose64 (talk) 20:12, 29 April 2013 (UTC)

Dear tech people:

When I am reviewing articles at the Afc, I sometimes come across copyright violations. When I decline a submission for this reason, the dialogue box asks for the URL that has been copied. There's a box to type or paste it in, but it's very small. It's hard to tell if the URL has been entered correctly. Could the box be made wider so that more of the URL would show on the screen? —Anne Delong (talk) 00:30, 21 April 2013 (UTC)

I guess this is about MediaWiki:Gadget-afchelper.js. You can post to Wikipedia:WikiProject Articles for creation/Helper script/Development page#Feedback. PrimeHunter (talk) 00:39, 21 April 2013 (UTC)
With URLs I usually right click and open in new tab from the edit preview to see if the link goes to the correct site page.--Canoe1967 (talk) 01:24, 21 April 2013 (UTC)
I am not sure what you mean. Do you first decline the copyright infringement, and then right click on the URL in the resulting notice? If so, I would prefer to catch the error at an earlier stage. —Anne Delong (talk) 12:30, 21 April 2013 (UTC)
I have left a message as suggested. —Anne Delong (talk) 12:39, 21 April 2013 (UTC)
I have never seen the decline/accept edit screen. I was referring to when I do a regular edit and want to check wikilinks and urls. They can be right-clicked from the preview of the edit section.--Canoe1967 (talk) 13:39, 23 April 2013 (UTC)
Unfortunately, when working in the Afc script there is no preview. Back to my original question, can the entry box for the copyright violation URL be made longer? There's plenty of space in the pop-up box. If no one here knows, can you direct me where to ask? —Anne Delong (talk) 14:34, 27 April 2013 (UTC)

MY WISH HAS BEEN GRANTED! Thanks to whomever took care of it. —Anne Delong (talk) 03:58, 30 April 2013 (UTC)

That was mabdul in response to [4] at Wikipedia:WikiProject Articles for creation/Helper script/Development page. PrimeHunter (talk) 10:22, 30 April 2013 (UTC)

Test the new login and account creation page designs

Hi all,

After many weeks of testing, We (the editor engagement experiments team) are is getting close to enabling redesigns of the account creation and login pages. (There's more background about how we got here and why ‎our blog post.)

Right now are trying to identify any final bugs before we enable new defaults. This is where we really need your help: for now, we don't want to disrupt these critical functions if there are outstanding bugs or mistranslated interface messages. So for about a week, the new designs are opt-in only for testing purposes, and it would be wonderful if you could give them a try. Here's how:

If you have questions about how to test this or why something might be the way it is, I'd definitely check out our step-by-step testing guide and the general documentation.

Many thanks, Steven Walling (WMF) • talk 22:39, 25 April 2013 (UTC)

Will Special:PasswordReset be updated to reflect this new design as well? —Theopolisme (talk) 01:38, 26 April 2013 (UTC)
No, though if you think it should be, it should be simple enough. Steven Walling (WMF) • talk 04:59, 26 April 2013 (UTC)
I've taken the liberty of making the test links protocol-relative (i.e. they go to the HTTPS site if the user is on the secure server, otherwise they go to the HTTP site). Graham87 06:29, 26 April 2013 (UTC)
Thanks Graham. One of the nicer parts of the new login form IMO is that it includes a default link to the HTTPS connection, if you're not already on it. Steven Walling (WMF) • talk 06:32, 26 April 2013 (UTC)
The gray text used for the form field labels (e.g. "Username", "Password") is too light: it is difficult to read, and moreover, it is not compliant with WCAG accessibility guidelines. Please consider darkening the text colour a bit. — This, that and the other (talk) 06:41, 26 April 2013 (UTC)
Agree. How many times has this happened before ? Don't the designers have this on their checklist by now ? —TheDJ (talk • contribs) 10:29, 26 April 2013 (UTC)
The lighter color is very much intentional, and in several rounds of usability tests (here's a few who gave us permission to share), we've seen pretty much all users be able to read fields contents with this color. It's explanatory content, and is thus lower priority than the actual field titles. Making all text the same style reduces usability for the majority of users. Steven Walling (WMF) • talk 20:43, 26 April 2013 (UTC)
I don't object to using gray text, I think it looks good, but aren't you bothered by the rather low contrast level in terms of accessibility? It is absolutely crucial that our login form is as accessible to as many people as possible. — This, that and the other (talk) 01:02, 27 April 2013 (UTC)
And how many people in that group of testers had a severe form of colorblindness ? Just because nobody in the testgroup complains about the lack of a level floor in a new building doesn't mean much until you bring someone with a wheelchair. I don't blame people for NOT taking this into account when testing. I didn't even notice myself until TtatO brought it up and usually i'm one of the first to complain about these issues. There are WCAG checklists for a reason, namely the fact that many of those points are hard to notice for people that don't have disabilities. That's why you build a checklist. Not to cross off every point like a machine, but to make your mind actively consider the step (Ask airline pilots). —TheDJ (talk • contribs) 08:06, 27 April 2013 (UTC)
Actually, one of my team members is color blind. I agree we could consider readability enhancements, which are filed as bug 47777 if you'd like to add 2 cents there. Steven Walling (WMF) • talk 19:11, 30 April 2013 (UTC)
In general, like. I thought you guys were adding inline validation as well btw ? Or is that for a later phase ? If you take away the security advise etc from the interface, and don't give people tooltip advise, I'm sure some ppl will start wanting the headers with advice back. Also, slightly related: How about changing the "email (optional)" into "email (advisable/recommended)" ? —TheDJ (talk • contribs) 10:26, 26 April 2013 (UTC)
Also, AFAICS, there is no opportunity to add extra footer text: see [5] and [6]. Obviously it looks a lot better without footer text, but sometimes there may be a need for the community to add various timely messages to this part of the screen. — This, that and the other (talk) 10:41, 26 April 2013 (UTC)
I agree with "Email (recommended)" over (optional) as that would encourage people to provide their email address and they'd be able to get all the future benefits of Echo, Flow etc. Thehelpfulone 16:20, 26 April 2013 (UTC)
TheDJ: yeah, we deferred inline validation until another release. We'll either refactor using the validation HTMLForm already provides, or rebuild the backend of the form on top of the API (which supports CAPTCHA delivery now, thanks to Brion). Regarding the email label: remember that most users don't expect email to be optional, it's actually kind of unusual compared to the other popular sites on the Web. If we want to recommend email strongly, we could consider doing something like adding a suggestion to provide it, if people skip the field before submitting (this would require client-side validation, of course). An interim compromise could be "(Optional, but recommended)" which is clear but slightly wordy. Thoughts? Steven Walling (WMF) • talk 21:00, 26 April 2013 (UTC)

Error trying to restore an image

I had deleted Image:Gracyn Shinyei 2013.jpg earlier today as lacking permission. The uploader informed me that he had sent a letter of permission to OTRS and sent me a copy of it, which looked sufficient, so I went to restore the image and tag it as OTRS pending. However, when I did it, I got this error:

Error undeleting page

Errors were encountered while undeleting the file:
  • The file "mwstore://local-multiwrite/local-deleted/j/e/e/jee6sxsgsg19i1ji6jalr2k07hv4mcq.jpg" is in an inconsistent state within the internal storage backends
  • The file "mwstore://local-multiwrite/local-public/c/ce/Gracyn_Shinyei_2013.jpg" is in an inconsistent state within the internal storage backends

Then, I realized that I could view the deleted image, save it, and try to re-upload it myself, but I got this error:

The file "mwstore://local-multiwrite/local-public/c/ce/Gracyn_Shinyei_2013.jpg" is in an inconsistent state within the internal storage backends

Any thoughts other than move it to a different filename?

--B (talk) 21:26, 29 April 2013 (UTC)

Thanks for taking the time to report this! The problem you are reporting sounds like a potential issue in the code of the servers. If the problem is reproducible, it would be nice if somebody who has this issue could send the software bug to the 'Bugzilla' bug tracker under the product "Wikimedia" and component "File management" by following the instructions How to report a bug. This is to make developers of the software aware of the issue. If you have done so, please paste the number of the bug report (or the link) here, so others can also inform themselves about the bug's status. Thanks in advance! --AKlapper (WMF) (talk) 11:41, 30 April 2013 (UTC)
People were having the exact same problem with certain files about a year ago or so. If I remember correctly, the problem was that some files had wrong file access permissions on the servers where they were stored, with the result that the files couldn't be deleted, undeleted or moved. There were discussions about this on Commons at that time, and people were troubled about not being able to delete certain copyright violations. --Stefan2 (talk) 11:48, 30 April 2013 (UTC)

Need help removing the background sound from an audio

Hello,

Can anyone here please remove the background noises from this video please - [7]. I really require it, as I'm trying to get it translated into its article, and there is too much noise to understand it clearly.

Thanks, TheOriginalSoni (talk) 01:25, 30 April 2013 (UTC)

It is a tough problem, for sure. I combined the left and right channels into mono, which helped lower the noise floor somewhat, and greatly increased the signal level, but I was unable to pull the voices out of the static. The big problem is that the noise is in the same frequency range as the voices. Anyway, the resulting file I have is uncompressed WAV audio with a size of 16.4 MB. Let me know if you want to hear it. Binksternet (talk) 02:58, 30 April 2013 (UTC)
Of course I want to hear it :) Do upload it and link it to me. [Though for upload purposes compressing into mp3 will be better]
Also, the persion doing the tranlation says its most unclear near the beginning and end. So if you can do something about it, that will be good. TheOriginalSoni (talk) 04:10, 30 April 2013 (UTC)
Thanks for volunteering to help! (I'm the user doing the translation.) Actually, it's the first ~60 seconds that are giving me the most trouble because they are so quiet. The part at the end became more intelligible after I listened to it a few times. Tempodivalse [talk] 04:38, 30 April 2013 (UTC)
I share audio files all the time with people who know my real name, but I am not so familiar with using an anonymous account. Please see if you are able to get the audio from this shared folder: https://sites.google.com/site/audiobink/. It is a mono mp3 file which is slightly smaller than 4 MB. Best of luck! Binksternet (talk) 13:42, 30 April 2013 (UTC)
Binksternet, I can't see it, unfortunately. All I get is a blank page. Perhaps you could try another file sharing service? Tempodivalse [talk] 16:48, 30 April 2013 (UTC)
Or email? (Once you've exchanged emails, so you can email directly, not via the WP interface.) Rd232 talk 17:28, 30 April 2013 (UTC)
One more try before I start emailing people... Try this link. Binksternet (talk) 21:47, 30 April 2013 (UTC)
Link works find for me. Lets hope its clear enough for Tempodivalse. TheOriginalSoni (talk) 22:50, 30 April 2013 (UTC)
Download worked. The noise floor is more manageable now, although it will still be a challenge to decipher the individual words. I think I can catch most of the conversation if I listen long enough. Tempodivalse [talk] 03:41, 1 May 2013 (UTC)

Lines not wrapping in edit box

I am using IE10 on my laptop with Windows 7. The text in my edit window does not wrap, which is most inconvenient. Is there a setting somewhere that will correct this? • • • Peter (Southwood) (talk): 07:00, 30 April 2013 (UTC)

Replication lag

Anyone know what it's so high (14 hours)? Beyond My Ken (talk) 09:22, 30 April 2013 (UTC)

Toolserver has been having problems for months. --Redrose64 (talk) 09:36, 30 April 2013 (UTC)
  • Cluster s1 had 0h replag, but s2/s5 have 14h: The enwiki wp:REPLAG has been showing zero hours for the s1 cluster, for many days during the past 2 weeks. I am not sure which wikis are on s2 and s5, with the 14-hour replag. However, I have advised the enwiki Lua-cite editors (for wp:CS1 cites) to avoid changing Lua-cite Module:Citation/CS1, as reduced to perhaps once per week or once per 2 weeks, to stop reformatting the 2 million CS1-cite pages "everyday" as before. Meanwhile, the category links still tend to be slow to reset within enwiki itself, even after changing a template used in just a few articles, and must null-edit those few dependent articles to force category-link updates. Also, many of the other-language wikipedias have caught the epidemic navboxaholism, and so a change to their main navbox or infobox templates might cause zillions of cache pages to become out-of-sync and increase the replag. -Wikid77 11:05, 30 April 2013 (UTC)

Can "×" be made interchangeable with "x" for searching?

Tracked in Phabricator
Task T49881

A new user pointed out that "This question has to do with all plants on wikipedia that are hybrids, and therefore can contain a special symbol called a cross (×) as part of their binomial name. While it's correct to have the special character '×' in the binomial name of a hybrid, it's neither consistent across all plants on Wikipedia, nor is it terribly useful for users trying to find a certain plant when Wikipedia gives a 404 if I put an 'x' instead of an '×'."

His example was Rubus × loganobaccus with this special character (×) (http://en.wikipedia.org/wiki/Rubus_%C3%97_loganobaccus), which did not work with 'x' (http://en.wikipedia.org/wiki/Rubus_x_loganobaccus).

This has since been handled by redirect, but it is not so easy to redirect them all, because (surprise surprise!) searching for × in the standard form gets you "An error has occurred while searching: The search backend returned an error:" (without giving an error). It can actually go to × if you type it in the go/search box and hit enter, though.

Is it possible to fix the search so that either:

a) any search with × that delivers either an error or no results is reattempted with x, and any search or URL with "x" delivering no results is reattempted with × (hmmm, that is a lot)

or at least

b) A search with × returns all article names containing it?

Wnt (talk) 14:30, 30 April 2013 (UTC)

I've filed a request on bugzilla as T49881. Andrew Gray (talk) 14:55, 30 April 2013 (UTC)

Echo

When is Echo coming around? -- Ypnypn (talk) 17:22, 30 April 2013 (UTC)

Deployment is between 11-1pm today Pacific time, and thus is should begin appearing after that assuming no hiccups. Steven Walling (WMF) • talk 17:49, 30 April 2013 (UTC)
Notifications, or Echo, has now been released! You should start seeing things now: let us know on the talkpage if you see any bugs or have any feedback :) Thanks, Okeyes (WMF) (talk) 20:04, 30 April 2013 (UTC)

Bot

If someone have patient and time to help me creating a bot, pls answer me in my talk page. Xaris333 (talk) 19:34, 30 April 2013 (UTC)

Suggestion

Gadget suggestion, suppress the annoying "Your edit has been saved" bubble on every page save. Werieth (talk) 20:53, 30 April 2013 (UTC)

if you dig in WP:VPT archives, i think there's a CSS one-liner that will do that for you. peace - קיפודנחש (aka kipod) (talk) 21:03, 30 April 2013 (UTC)
This should do it:
.postedit { display: none; }
There isn't a gadget or preference to hide this because it's a system message, just like the notification bubble for watching/unwatching something. Steven Walling (WMF) • talk 21:14, 30 April 2013 (UTC)
I've corrected your CSS to include the braces, which I believe are required. – PartTimeGnome (talk | contribs) 22:29, 30 April 2013 (UTC)
They are, I was just in a hurry. Thanks for the fix. Steven Walling (WMF) • talk 22:31, 30 April 2013 (UTC)

CAPTCHA and Safari

Thrice over the past few weeks I've had new users in the IRC help channel say that they couldn't get past the CAPTCHA at the Article Wizard while using Safari; entering one CAPTCHA apparently simply brings up the next in an endless loop. I don't have Safari myself and thus can't test the effect myself, not even verify it exists, but someone else may want to take a look. Huon (talk) 22:25, 30 April 2013 (UTC)

I can help test this, but do you mean unregistered or registered folks? And by CAPTCHA I assume you mean a CAPTCHA on page creation? (It would help to know these things for someone to replicate.) Steven Walling (WMF) • talk 22:29, 30 April 2013 (UTC)
The way I understand it, registered but not yet autoconfirmed users writing their first draft via the Article Wizard. Today's example was Special:Contributions/LKK343 who apparently was successful after I advised them to use some other browser; they said they'd use Chrome. I've invited LKK343 to comment here and correct me if I got it wrong. Huon (talk) 22:45, 30 April 2013 (UTC)
Curious. I had a similar problem when (several years ago) I tried to register: one captcha lead to another. I think I was using Firefox at the time. Don't recall how I eventually got past it. ~ J. Johnson (JJ) (talk) 02:20, 1 May 2013 )UTC)

TorBlock problems

Tracked in Phabricator
Task T49626

It's been the third time this week I've received an unblock request on WP:UTRS from an established user who was running a Tor node which was not an exit node, but merely a relay node, and it was blocked by mw:Extension:TorBlock. This appears to be a systematic problem. I've filed a bugzilla request, but it hasn't yet been addressed. What should we do in the meantime? -- King of ♥ ♦ ♣ ♠ 02:53, 28 April 2013 (UTC)

Thanks for filing the bug report! It was filed four days ago and there was a weekend in-between, so I'd be a bit more patient. Andrew Garrett is CC'ed on the bug report, and as far as I know he'd be a good person to contact about it. --AKlapper (WMF) (talk) 10:06, 29 April 2013 (UTC)
OK, thank you. -- King of ♥ ♦ ♣ ♠ 07:37, 1 May 2013 (UTC)

Range viewing with IPv6

I use the CIDR range notation tool sometimes when viewing IP editing history (so I can find /24 addresses, for instance)... is there a similar tool for IPv6 addresses? Or is there a way to make it work with IPv6? Shadowjams (talk) 14:37, 28 April 2013 (UTC)

If you look at the gadget source you can see that only /27 to /32 actually do a CIDR range lookups (the ucuser parameter is limited to 50 simultaneous values, so 2^(32-27) = 32 is the most that can be done at once). /24 and /16 are special cases that do a ucuserprefix search instead. These behave functionally the same as an asterisk suffixed; Eg: 1.2.3.4/16 == 1.2.*. For some reason, the mw:API can't do ucuserprefix on IPv6 addresses. Compare: Splark 92.12 2001:9d8:2005 (2001:9d8:2005:12::3 has edits). If it did, then simply using 2001:9d8:2005* should work. Possibly someone should open a WP:BUG (Product: MediaWiki. Component: API). --Splarka (rant) 21:47, 1 May 2013 (UTC)
It works if you use correct capitalization: 2001:9D8:2005 Anomie⚔ 00:24, 2 May 2013 (UTC)
Interesting. Requiring uppercase seems to violate RFC 5952 and "The hexadecimal digits are case-insensitive, but IETF recommendations suggest the use of lower case letters." It even contradicts the format of the capitalization of IPv6 addresses in Recent Changes and article histories. Though it does agree with the API internal format (and IPv6 users' talk page titles). The API could possibly be modified to detect IPv6 fragments and ignore the case in a prefix search, as could the gadget, but neither solution is very elegant. --Splarka (rant) 01:17, 2 May 2013 (UTC)
The problem with that is how does it decide something is an "IPv6 fragment" rather than a username that happens to consist of numbers and letters a-f? Anomie⚔ 01:34, 2 May 2013 (UTC)

Unwanted global account(s)

I contribute to eight language-specific Wikipedias (CY, DE, EN, ES, FR, GA, NL, SV), with accounts at each, mostly under different user names in each case.

Lately, after logging in to (at least) my CY, NL, and SV accounts I am also being logged in (without being asked, as far as I can see) into

  • meta.wikimedia.org
  • wiktionary.org
  • wikibooks.org
  • wikiquote.org
  • wikisource.org
  • commons.wikimedia.org
  • wikinews.org
  • wikiversity.org
  • mediawiki.org
  • wikidata.org
  • species.wikimedia.org
  • incubator.wikimedia.org
  • wikivoyage.org

That might be harmless enough, I suppose, except that now whenever I switch from cy.wikipedia, nl.wikipedia, or sv.wikipedia to one of my other accounts I find myself logged in there under the name I used at the wikipedia I have just been visiting, and have to log out and in again under my "real" username for that language -- which is, to put it at its mildest, bloody annoying!

Can anyone tell me, please, if this situation is reversible. I suspect there may be some connection between what is happening here and the "global account" concept (which, as I say, I have never knowingly signed up to). -- Picapica (talk) 11:27, 29 April 2013 (UTC)

This is one of the "benefits" brought by WP:SUL. My login was created after its introduction, so I'm used to the idea that I only need to log in once and I'm automatically logged in to all the others (although it does have its hiccups). Before we had Wikidata, it was a great boon when fixing interlanguage links (try some of the links at User:Redrose64#Non-English editing). But although I do very little on other Wikipedias now, it's still a benefit for editing on Commons, Meta and Wikidata. --Redrose64 (talk) 12:37, 29 April 2013 (UTC)
The only way to reverse this "problem" is to use one account. Whether that means you ask local bureaucrats to rename the account where it is not a part of the SUL, or abandon the old accounts, is up to you. I would personally just abandon the old accounts and ask for a bureaucrat or bureaucrat-analog to move the rights from old accounts to whichever you standardize on. --Izno (talk) 12:43, 29 April 2013 (UTC)
Also, this feature has been in place for a while. It surprises me that you are just discovering it now. --Izno (talk) 12:45, 29 April 2013 (UTC)
For "a while" read "almost five years". May 27, 2008 is almost a year before my account was created (5 May 2009) but four years after yours. --Redrose64 (talk) 12:59, 29 April 2013 (UTC)
Try the links on WP:SUL you may be able to unify them yourself. - X201 (talk) 13:01, 29 April 2013 (UTC)

Thanks for the answers, folks. The thing is, though: I don't want to unify my accounts; I want to UNunify them!

Izno, this problem has (re)surfaced only today. Checking back, I see that I first got rid of it around four and a half years ago (see paragraphs below). I have a strong suspicion that its re-appearance could be connected to my use (for the first time) today of the relatively new "Edit links" feature for updating interwikis, which I did from the Dutch-language nlwiki.

Here is a copy of a previous exchange on this subject from 2008. (I hope the solution offered there will work again!):

I very much regret falling for the invitation to go for a unified login. I have Wikipedia accounts in eight languages, mostly with different usernames. Now when I switch between different language Wps I frequently have to log out and log in each time in order to use these accounts. I don't wish to rename these accounts even if I could (new accounts using my main, English-language name have been set up without my asking for them).
Is there any way I can undo the unified login process so that I can be returned to the happy state I was in before I ever heard of unified login? If not, let this be a reminder to others of the value of the advice "If it ain't broke, don't fix it". :{ -- Picapica 11:24, 5 September 2008 (UTC)
Yes, You can, please request it here, also make sure to have a valid, confirmed email in Your special:preferences for Your own safety, thanks, --birdy geimfyglið (:> )=| 11:26, 5 September 2008 (UTC)
The global account for Picapica was deleted in 2008 as you say [8] after a request at meta:Steward requests/SUL requests. It hasn't been recreated so I guess you refer to one or more other usernames at CY, NL, and SV. What are the usernames? PrimeHunter (talk) 15:49, 29 April 2013 (UTC)

Those usernames are CY Jac-y-do, NL Torenkraai, SV Femten. It would make life a lot easier for me if none of these was a global account!

Does editing interwikis via the new procedure have anything at all to do with this? Or did I just click on a wrong button somewhare?

(My other usernames BTW -- I've now remembered a couple more -- are: BR Arvran, DE Picapica, ES La voz del oyente, FI Picapica, FR Le choucas, GA Picapica, NO Picapica) -- Picapica (talk) 16:23, 29 April 2013 (UTC)

Yes, that is what caused the problem. There's simply no (permanent) fix for it other than using one account and one account only, or never editing Wikidata again, which is frankly not going to be an option when phase 2 is in full swing.... --Izno (talk) 21:13, 29 April 2013 (UTC)
Which is the whole reason behind unified global accounts to begin with. One person, one username across the entire set of projects. It's the ideal - no need to forget (or remember) other userid's. (✉→BWilkins←✎) 21:20, 29 April 2013 (UTC)
Also see the announcement about enforcing single sign-on here: http://lists.wikimedia.org/pipermail/wikitech-l/2013-April/068937.html --AKlapper (WMF) (talk) 11:39, 30 April 2013 (UTC)
Wow. Am I reading that right? If an en.wp user has the same account name as anybody who ever SULed on any project, he gets it pushed to some long and unwieldy substitute? That seems like a really, really drastic change from before when you could only co-opt a nearly unused username. And how would you arrange the tracking of all those contributions? And they'd have to log in that way - I'd think half the users affected are going to think they forgot their password. And then they're all going to want to do renames, which they'll need assistance for ... sounds like a class 5 foulup waiting to happen. Wnt (talk) 16:33, 30 April 2013 (UTC)
See meta:Single User Login finalisation announcement; you may want to comment on its talk page. — Scott • talk 11:51, 1 May 2013 (UTC)
I would turn it around. If you are one of the few people who after a (in my opinion, grace period of) 6 years still didn't voluntarily created a global account, then now one will be created for you. If a global account with your name is no longer available, you will get a postfix attached to that global account and that is what you will have to use. There will only be one place for account renames. The talk page says, that they are looking at automatically redirecting users to their SUL account when they login with their old name and apparently people will be individually contacted as well. —TheDJ (talk • contribs) 18:47, 1 May 2013 (UTC)
To the OP: the weird thing is that it seems like whenever I enable scripts in Firefox (which I only do for Lua programming) I have to manually log in whenever I go to a page on a different project, despite having a SUL. But it works normally the 99% of the time when they're disabled. Wnt (talk) 16:33, 30 April 2013 (UTC)
That's because of how you are now protected by browsers from crossing domains with credentials. The technique we used over the past couple of years has actually stopped working in quite a few browsers (SUL2 is now being developed to properly solve this). The newest versions of Chrome, Safari and Firefox will only allow you to take your credentials to domains that you visited before. So if you regularly visit the sisterprojects, then it will work most of the time, if you don't then you might have to log in once in a while on a sisterproject. —TheDJ (talk • contribs) 19:11, 1 May 2013 (UTC)

My thanks for the replies and apologies for being slow to get back here to read them. Ho hum: looks like this is another case of the techies solving a problem I never had, while creating a new one for me in the process. I guess I'll just have to live with logging-out/logging-in on every occasion, until such time (it seems) as things get still worse. Such is Wp-life... :( -- Picapica (talk) 05:10, 9 May 2013 (UTC)

Prosesize JavaScript

I've been trying to get the JavaScript at User:Dr pda/prosesize to work for me. I've followed the installation instructions (including clearing my cache), but it still doesn't work. Would anyone have any suggestions for what I should do? Alphius (talk) 22:05, 29 April 2013 (UTC)

(I commented at the Help Desk, as the thread about it there is already active.) --Stfg (talk) 08:42, 1 May 2013 (UTC)

Announcing the release of the the Wikimedia Commons app for iOS and Android

The Wikimedia Foundation mobile features team is proud to announce the release of the official Commons app for iOS and Android! This mobile application allows users to log in with their Wikimedia account and view, upload, and share their Commons uploads with the image sharing sites of their choice. On Android, you can also batch upload and add categories to your images. We'll be working to expand the features on both versions of the app so that, in the future, you’ll also be able to participate in events like Wiki Loves Monuments and other focused uploading campaigns directly from this app. To let more Wikimedians with compatible mobile devices know about these apps, we'll be running banners on Commons and English Wikipedia to logged in users this week.

Those who are interested in uploading images via mobile on non-iOS/Android (e.g., using BlackBerry devices, running Firefox browsers) can still upload to Commons on the Wikimedia mobile web. Just visit the mobile site of your home wiki, log in, and go to the Uploads page in the left navigation menu.

If you have questions or feedback, please let us know! In addition to Bugzilla, we have a mailing list (mobile-l@lists.wikimedia.org) and an IRC channel, ##wikimedia-mobile connect, where we would be happy to hear from you. Maryana (WMF) (talk) 19:09, 29 April 2013 (UTC)

Aren't we opening ourselves up to an even bigger torrent of copyvio uploads from users who find images on the net, save them to their camera roll and upload them using the new app? --ukexpat (talk) 17:16, 30 April 2013 (UTC)
There are some checks that can be done that the photo was generated by the mobile device... not sure what is done, it would be good to know. See also lengthy related discussion on Commons about Mobile Web uploads, leading to disabling mobile web uploads for new users. Rd232 talk 17:26, 30 April 2013 (UTC)
Looking at the deletion rates for the various mobile upload methods on the mobile dashboard that does not seem to be happening :) YuviPanda (talk) 06:09, 3 May 2013 (UTC)

SUL account not attached to my account

Resolved

Can somebody explain me, why my account at nl.wikitionary wasn't corectly attached to my SUL account, although it was automatically created (as stated in the log)? I know that I visited the page logged in a few months ago and sadly there is no email set in the preferences. mabdul 16:04, 30 April 2013 (UTC)

It might be the same problem that I had with Urdu Wikipedia. --Redrose64 (talk) 16:48, 30 April 2013 (UTC)
I had a similar problem on Meta. I could see my account in Special:ListUsers, but couldn't log in to it. Meta didn't show on my Special:CentralAuth. Thankfully, I had an e-mail address set, so a password reset followed by Special:MergeAccount fixed it (hence Meta shows as "confirmed by password" in my Special:CentralAuth). The Meta account was "created automatically" on 1 August 2011, but only attached to my SUL account on 29 September 2011 (when I used Special:MergeAccount). Though I fixed my issue, I am still very curious to know what caused it.
If you don't have an e-mail address set, I suspect this can only be solved by a steward or a developer. – PartTimeGnome (talk | contribs) 22:48, 30 April 2013 (UTC)
Or ask a bureaucrat to rename the existing account and see if it works better next time the account is created. PrimeHunter (talk) 23:08, 30 April 2013 (UTC)
I simply will wait until the unification of all accounts to SUL; the other account will be moved and then I will have a completed SUL. Doesn't matter, I don't speak Dutch (although I might be able to read it) and I'm not active there. mabdul 20:17, 2 May 2013 (UTC)
 Fixed. The account was auto-created by CentralAuth, but due to a (now, to my knowledge, solved) bug it was created unattached and without password or e-mail set (making it impossible to log in and re-attach). I've imported the e-mail address from the attached account on en.wikipedia.org for User:Mabdul into the empty e-mail record for nl:wikt:User:Mabdul. Please use the "Password reset" feature and attach it with nl:wikt:Special:MergeAccount. Krinkle (talk) 22:09, 2 May 2013 (UTC)
Great. Thanks. mabdul 06:35, 3 May 2013 (UTC)

References Section

This new article version http://en.wikipedia.org/enwiki/w/index.php?title=Wikipedia_talk:Articles_for_creation/Irvine_historical_society&oldid=552773930 failed to show the AfC submission box - I tracked it down to the use of <references> instead of <references /> - it just causes the rest of the page to blank and shows no error. I wonder how many articles could be in Wikipedia with such a simple error...?  Ronhjones  (Talk) 23:56, 30 April 2013 (UTC)

Probably a lot fewer than unclosed <ref> tags, which also eats the following text. If I ever find a way to detect the first, then we can do the same for this one. --  Gadget850 talk 16:09, 1 May 2013 (UTC)
"Detect" via what sort of process? A bot that watches recentchanges? An edit-filter? Periodic offline scanning of the database dump? Couple of regex approaches come to mind for either the wikisource or the screenscraped result. DMacks (talk) 05:33, 2 May 2013 (UTC)
A database dump is probably the easiest. Just find articles with "<references>" but no accompanying "</references>". Legoktm (talk) 21:41, 2 May 2013 (UTC)
Maybe a more general idea (to catch a whole bunch of related mistakes) is to fire up weblint on the database dump. Could catch "open-with-no-close" in general, of which these are two examples. And also <s> and <center> and... DMacks (talk) 01:04, 3 May 2013 (UTC)

VisualEditor fortnightly update - 2013-04-29 (MW 1.22wmf3)

Hey all,

Here is a copy of the regular (every fortnight) update for the VisualEditor project, so that you all know what is happening (and make sure you have as much opportunity to tell us when we're wrong, as well as help guide the priorities for development and improvement):

VisualEditor was updated as part of the wider MediaWiki 1.22wmf3 branch deployment on Monday 29 April. In the two weeks since 1.22wmf2, the team have worked on deploying the VisualEditor opt-in alpha to more wikis, and on the new features for VisualEditor's wider launch as the default way users will edit our wikis: Categories, Templates, References and Images.

Fixed a number of bugs and regressions, including the 'bold' button not allowing you to un-bold some text (47680), fixing the link inspector throwing out "undefined" in some cases and other issues (47413), cleaning up the deployment including making the feedback link language-variable and having VE allow users preferences on non-deployed wikis (42936), avoiding a Firefox bug where shift-right caused characters to be deleted (47711), fixing a failure to let users convert between paragraphs and headings when next to an inline node (41203), and changing the integration so that the VisualEditor is now the editor behind the "Edit" tab (47396).

Additionally, we adjusted our code that faces mw:Parsoid to adapt to changes there and not fail when editing non-current pages (47434), fixed a problem of blank paragraphs getting inserted in some cases (46800), worked around a bug in jQuery that meant that references and other tags were getting corrupted (47417 and later 47737), avoided leaving trailing paragraphs when inserting content at the start or end of a paragraph (46799), made some speed improvements in the editing surface and the back-end (47343), and informed the user when a failure happens on serialisation (47581).

In experimental code that is not live on the Wikimedia servers yet, on images (37870) we added initial support for displaying and editing inline and thumbnail images, resizing of images, selection of images and other generated content with cursor keys (38129), and drag-and-drop relocation of images and other nodes. For references (39599) we added some infrastructure support for references. For templates (39598) we ensured that templates re-serialise to their original HTML if unchanged (47394).

A complete list of individual code commits is available in the 1.22/wmf3 changelog, and all Bugzilla bugs closed in this period on Bugzilla's list.

Per the MediaWiki deployment roadmap, this should be deployed here on Monday 6 May.

Hope this is helpful! As always, feedback gratefully received, either here or on the enwiki-specific feedback page.

Jdforrester (WMF) (talk) 04:00, 1 May 2013 (UTC)

Why is this being made a default instead of having two edit tabs side by side or a dropdown menu? – Allen4names (IPv6 contributions) 04:40, 2 May 2013 (UTC)
The idea is to have two edit tabs side by side at least for the short-to-medium-term as people get used to it, with "Edit" going to VisualEditor and "Edit source" to the wikitext editor - this second function will generally be more for "power users" and so it's appropriate for the longer, more precise and slightly 'scarier' labelling to apply to that one.
In the longer term, we imagine that the "Edit source" button will go "below the fold" on the Vector skin - i.e., to move to the drop-down menu - for pages where there will be VisualEditor available (which will not cover all of them - for example, the MediaWiki: namespace would be very hard to make work visually given that it's about editing fragments of wikitext, and the Template: namespace does the same to a smaller extent and, more importantly, includes a very large amount of highly-complex ParserFunction calls that would be a mess to edit.
I hope this answers your question! Jdforrester (WMF) (talk) 05:41, 2 May 2013 (UTC)
Will VisualEditor not have a button (like CodeEditor does) to toggle between "visual" and wikitext views? Although the CodeEditor button could use some UI love, it's not at all obvious that's what it does. Anomie⚔ 11:20, 2 May 2013 (UTC)
Potentially in the longer-term, as this requires a bunch of messiness in terms of juggling wikitext that isn't stored in the databases through the Parsoid service. It's do-able but not a priority. Jdforrester (WMF) (talk) 21:40, 2 May 2013 (UTC)
Please, please, please can we have an option somewhere to disable vised completely and to revert to the "old" raw edit mode for users who want to. I have tried vised, but I prefer "the old ways". Thanks.--ukexpat (talk) 17:41, 2 May 2013 (UTC)
second. mabdul 20:04, 2 May 2013 (UTC).  
You will be able to use the "Edit source" button to edit in wikitext rather than using VisualEditor for the foreseeable future; I can't make an absolute guarantee, but there are certainly no plans to change it in the next few years. Jdforrester (WMF) (talk) 21:40, 2 May 2013 (UTC)

Linking to foreign Wikipedia pages

An idea just came to my mind. If a page not yet exists on the English Wikipedia, but the page exists in on Wikipedia in a foreign language, I think it will be great if there is link to that or those foreign Wikipedia page(s) somewhere while searching for the article. For instance; the page "Edwin Evers" don't exist on the en.wikipedia.org, but it exist on nl.wikipedia.org. I think it will be nice if there is a link to (in this case) the Dutch page or a link to the matching Wikidata page, on the search results page or on the non-existing page. Sander.v.Ginkel (talk) 08:43, 1 May 2013 (UTC)

I agree, a link that performs the search on Wikidata at the top of the search results page would be helpful, especially for person articles. --JFH (talk) 20:22, 2 May 2013 (UTC)

Distribution of number of references by article?

Is there an easy way to get the distribution of the number of references in articles? I need it for a rather minor point, but I can imagine that the data might be otherwise useful. In my specific case, I would like to know who many of the 4 million articles have four or fewer references. --SPhilbrick(Talk) 22:29, 1 May 2013 (UTC)

I would ping database reports as my first stop for such a question. --Izno (talk) 22:38, 1 May 2013 (UTC)
Probably better to scan a database dump looking for ref tags, I'd have thought. Or did you want to include bibliographies? - Jarry1250 [Vacation needed] 23:10, 1 May 2013 (UTC)
If you scan articles looking for <ref>...</ref> tags, you might not get articles like NBR 224 and 420 Classes, and you won't pick up Actuary at all. But neither of these is in any way unreferenced. --Redrose64 (talk) 06:33, 2 May 2013 (UTC)
You might be interested that 1.9 million article have at least one Citation Style 1 template. Of course that leaves two million articles that either have included citations in some other way (e.g. manually, rarer templates, bare urls) or have no citations at all. Dragons flight (talk) 05:05, 2 May 2013 (UTC)

I recently asked a similar question after finding the interesting list at Wikipedia:Articles with the most references (Wow! A lot of references per article...  :-) I am looking for a stat/ report/ study about the growth of references in enWP in total, for the last year or something similar.

  • On german Wikipedia, users goiken and Svebert looked at the growth of "<ref" in article name space between 10. April 2011, 29. Oktober 2011 and 13. April 2012 (based on dumps, reported here: [9], [10], [11]). They found a growth of references of 36,4 % (from 2,6 to 3,6 million), while the number of german WP articles grew 13,5 %. The average number of references per article was 2,1 in 2011 and 2,5 in 2012.
  • I found some very old stats from enWP of 2008/2009: User:Dr_pda/Article_referencing_statistics and User:WolterBot/Cleanup_statistics. "the average number of citations per paragraph was 2.07 for FA, 2.06 for GA, 0.87 for A class, 0.51 for B, 0.26 for Start, 0.14 for Stub and 0.15 for Unassessed articles. This was out of a total of 2,251,862 articles (disambig pages and obvious lists excluded); 1,625,072 (72%) had no refs" [12].

It would be great to have some recent stats! --Atlasowa (talk) 08:00, 2 May 2013 (UTC)

Thanks for all the information supplied. For my specific question, the answers suffice. However, given the critical nature that references play, I'm a little surprised we don't have more formal studies. Like Atlasowa, I'd be interested in more recent (and more complete) stats. --SPhilbrick(Talk) 13:10, 2 May 2013 (UTC)

Category intersection - today

Hi - input and ideas welcome for a new idea for category intersection:

This leverages the catscan tool, but provides users an easy way to get to it. proposed as a sort of interim solution until wikidata is fully up and running, to tackle gender/ethnic divisions in our categorization tree. --Obi-Wan Kenobi (talk) 08:04, 2 May 2013 (UTC)

Unwanted additional space

in Usage_share_of_web_browsers#Summary_table there is unwanted space between "9.07" and "%" - note that in other cells there is no space before percentage sign. It seems to be caused by overuse of autoformatting templates and I have no idea how to fix this (except converting this template orgy into proper table). Problem seems to not be browser dependent. 89.74.119.184 (talk) 10:35, 2 May 2013 (UTC)

The source simply had a space. I removed it.[13] Another place in the section said 9.07% without a space. Maybe you were looking at that. PrimeHunter (talk) 10:50, 2 May 2013 (UTC)
Ops and thanks (I checked 9.07% without a space). Now I feel stupid 89.74.119.184 (talk) 12:32, 2 May 2013 (UTC)
We all make mistakes, and this one wouldn't crack my top ten :) --SPhilbrick(Talk) 13:17, 2 May 2013 (UTC)

Glossary templates

Hi, I am have a difficult problem with templates (difficult for me that is) and am hoping someone here can help. I am using {{term}} and {{defn}} to structure this glossaary. I have created myself the templates {{subterm}} and {{subdefn}} which merely add some extra left margin and then call term and defn respectively. They both work fine. I have also created {{glossback}} to provide backlinks back to where the reader jumped from in the article. This also works fine. However, there is a strange problem that I can't solve when they are both used in the same glossary. After subdefn is used, every line that uses glossback subsequent to the subdefn call has a huge amount of whitespace inserted between the backlink and the term it is linked to. Please take a look. Thanks, SpinningSpark 14:43, 2 May 2013 (UTC)

When {{{4|}}} etc. were not specified, a blank line was output. The easiest fix is to hide the linebreaks. --Redrose64 (talk) 18:15, 2 May 2013 (UTC)
Thanks very much for fixing. But I don't understand why the glossary was not broken as well before the first call to subdefn. The entries using glossback were ok where the previous line called defn instead of subdefn. SpinningSpark 19:23, 2 May 2013 (UTC)

Issue with Main Page on mobile, viz. it hasn't changed since Tuesday

Tracked in Phabricator
Task T50062

Pull up the mobile site en.m.wikipedia.org/wiki/Main_Page. You'll find that Adrian Boult is still the Featured Article, the Icelandic election is the top news story, and the ITN picture is still the unfortunate minaret (rather than the new King of the Netherlands). Why, and how can this be fixed? Lockesdonkey (talk) 00:16, 3 May 2013 (UTC)

How about now? I logged in on the mobile site and purged the page. Looks fine to me now. jcgoble3 (talk) 01:08, 3 May 2013 (UTC)
I purged my whole cache. No dice. Also, this is happening on two devices in two browsers: one on a MacBook Pro running Chrome (OS: OS X Lion) and on an iPhone 4 running Safari (iOS 6.1.3). Lockesdonkey (talk) 02:13, 3 May 2013 (UTC)
I can confirm that this problem exists for me viewing [14] in Firefox 23 on Windows 7, something I've never done. Definitely a server-side problem.  — TORTOISEWRATH 02:22, 3 May 2013 (UTC)
Firefox 20.0.1 on Windows 8 here, and after going back to the page now, it's back to the old version again. But if I log in, it shows me the current version. Sounds like bugzilla:44391 has now manifested itself on the mobile site (also see the discussion from the original version of this bug). jcgoble3 (talk) 03:17, 3 May 2013 (UTC)
Indeed.  — TORTOISEWRATH 03:47, 3 May 2013 (UTC)
Thanks for reporting this! The problem sounds like an issue in the MediaWiki server configuration. It would be nice if somebody who has this issue could send the software bug to the 'Bugzilla' bug tracker by following the instructions How to report a bug. This is to make developers of the software aware of the issue. If you have done so, please paste the number of the bug report (or the link) here, so others can also inform themselves about the bug's status. Thanks in advance! --AKlapper (WMF) (talk) 12:17, 3 May 2013 (UTC)
Reported as bugzilla:48062.  — TORTOISEWRATH 01:26, 4 May 2013 (UTC)

Where is the audit trail for all actions on an article under pending changes?

Resolved
 – It is called the review log. Orange Suede Sofa (talk) 19:36, 3 May 2013 (UTC)

On List of countries by GDP (PPP), I noticed that another reviewer had accepted a change that shouldn't have been accepted. I unaccepted the change and then rejected it myself. I want to notify the other reviewer of what I did and why, but the other reviewer's acceptance disappeared from the normal page history (after I unaccepted & rejected the change) and I can't find a record of the fact that the other reviewer touched the page at all. It doesn't show up in the other reviewer's contribs. Where can I find that record? Regards, Orange Suede Sofa (talk) 19:05, 3 May 2013 (UTC)

Um. The Pending changes log is at (curiously) Special:Log/stable; input the article name in the "Target (title or User:username for user):" window, like this. However, I don't think that's what you're after. --Redrose64 (talk) 19:22, 3 May 2013 (UTC)
My bad. I've updated the section title accordingly. What I'm after is an audit trail of the pending changes and their acceptances/rejections, so that I can find a complete record of the situation I described above. Regards, Orange Suede Sofa (talk) 19:29, 3 May 2013 (UTC)
(edit conflict) Worked it out. You want the "Review log", Special:Log/review. Near upper right of the article you should see a little box showing "Accepted (latest)" with a down arrow after it. Hover over that arrow and a further box appears; click the word "accepted". --Redrose64 (talk) 19:32, 3 May 2013 (UTC)
That's exactly it. Thank you! Orange Suede Sofa (talk) 19:36, 3 May 2013 (UTC)

Searching for string literals containing non-alphanumeric characters

Are there any tools that can be used to perform a full-text search for a string containing non-alphanumeric characters. Say, hypothetically, I wanted a list of all pages in mainspace containing the string !!. Doing this doesn't work, for understandable reasons; grep only searches page titles. This would be equivalent to the pseudo-SQL SELECT * FROM `pages` WHERE `namespace`="(Article)" AND (`body` LIKE "%!!%" OR `title` LIKE "%!!%"), but performing direct SQL queries on the Wikimedia servers is something I predict only Jimbo is allowed to do.  — TORTOISEWRATH 03:43, 4 May 2013 (UTC)

The only method I know of is to download your own copy of Wikipedia's text and then to scan it with the AWB Database scanner. Alternatively, drop a note on my talk page and I could run a search for you in my copy (a snapshot from 4th April). -- John of Reading (talk) 05:50, 4 May 2013 (UTC)

Hiding the BLP editnotice

Can someone help me figure out how to hide the BLP editnotice? As I edit pages using a magnified page view, it really takes up a disproportionate percentage of my screen. It should be possible to hide it using either CSS or JS (I think), but I can't quite figure out how to do either. Thanks! – Philosopher Let us reason together. 19:51, 3 May 2013 (UTC)

For reference, the editnotice template is at Template:BLP editintro and is placed on the edit screen by MediaWiki:Common.js. – Philosopher Let us reason together. 19:54, 3 May 2013 (UTC)
Yep, putting .editnotice_BLP_editintro{display:none;} into your CSS page should do the trick. Writ Keeper ⚇♔ 19:58, 3 May 2013 (UTC)
Your name seems to keep showing up on my userscript pages. Thanks again! – Philosopher Let us reason together. 20:09, 3 May 2013 (UTC)
Generally speaking, if you know where the message comes from - and you've already worked out that it's Template:BLP editintro - look inside that for a class=value that encompasses the whole message; in this case we have <div class="editnotice_BLP_editintro">. The CSS to use is the name of the class, minus any quotes, preceded by a period and followed by {display:none;} which gives 
.editnotice_BLP_editintro { display:none; }
Some messages have an id=value instead of a class=value and for these, the technique is almost the same, except that you begin with a hash # instead of a period . --Redrose64 (talk) 20:32, 3 May 2013 (UTC)
I look at the html source of the rendered page to find such things. That can also work when you don't know where it comes from. Indeed, the html source says <div class="editnotice_BLP_editintro">. PrimeHunter (talk) 20:41, 3 May 2013 (UTC)
Yeah, that's what I do (and did above). Right-click on it and select "inspect element" (if you're in Chrome; I use Firefox, so I get a similar thing through the Firebug extension). Writ Keeper ⚇♔ 20:43, 3 May 2013 (UTC)
I often use a magnified page view too. My User:Bgwhite/vector.css has options to remove alot of the "distractions" to give me more room. There are comments to say what each option does. I also use User:PleaseStand/hide-vector-sidebar.js in my vector.js file to remove the left sidebar. A tab option is placed at the top so you can access the sidebar when needed. Bgwhite (talk) 21:36, 3 May 2013 (UTC)
Thanks, everyone! I did find the class element, but wasn't sure what to do with it. Now I've got a (semi-permanent) reminder on my page in this script. Awesome!
@BGwhite: I'll take a look at those, thanks for pointing them out! – Philosopher Let us reason together. 22:23, 3 May 2013 (UTC)
...and now my User:Philosopher/common.css and User:Philosopher/common.js are both longer and the 'pedia is more easily editable. – Philosopher Let us reason together. 22:58, 3 May 2013 (UTC)
Firefox has an inbuilt element inspector, which is IMO the best out there. Right-click and "Inspect element" or Alt+Q.  — TORTOISEWRATH —Preceding undated comment added 01:39, 4 May 2013 (UTC)
Yeah, but in the change from v19 to v20 certain aspects of it were altered and sometimes it's more difficult to find what you want. The worst is that the pane on the lower left (where the "source" is displayed) sometimes doesn't show the line being inspected, but the very top of the page - the <html> tag, <head>...</head> element and <body> tag, followed by some <div>...</div>s. Other negative changes include the pane which shows how the styles were determined: it used to be full-height, now it's crammed into the corner and a lot of scrolling is needed. The only positive I've found so far is the "box model" tab.
I didn't mention the "inspect element" feature before, because not all browsers have it, and for those that do, it varies widely. I perhaps should have mentioned "View source", since all major browsers have it; but it can be daunting for somebody unused to HTML. --Redrose64 (talk) 07:54, 4 May 2013 (UTC)
I completely agree; I noticed these negative changes, too, but I forgot about them since v20 (I'm on the nightly channel, so it's been a few months for me since the change). I still think it's the best one available, just not as good as it used to be. It's a shame that nobody seems to have made an extension to get the v19 one back.  — TORTOISEWRATH 00:38, 5 May 2013 (UTC)

Wikidata items on article

Hello. In greek wikipedia we can enable (at preferences) to show items from Wikidata, under the title of a page. How can Ι enable this in english WP? I can't find it. Thx. Xaris333 (talk) 01:30, 4 May 2013 (UTC)

You can enable that by adding the following code to your common.js, or request to add the tool as an gadget. As far as I know, it is not enabled as an gadget on enwiki.
// [[d:User:Yair rand/WikidataInfo.js]]
importScriptURI("//www.wikidata.org/enwiki/w/index.php?title=User:Yair rand/WikidataInfo.js&action=raw&ctype=text/javascript");

--Snaevar (talk) 01:41, 4 May 2013 (UTC)

Couldn't do it. Can you help? My commons.js in my page. Xaris333 (talk) 13:07, 4 May 2013 (UTC)

Yes, I can help. The code needs to be at the bottom of your common.js file, below the bracket and semicolon - };, not above it like you did. So, the bottom of your common.js should look like so:
    'listOfUnavailablePagesOn': 'List of not available pages on'
};

// [[d:User:Yair rand/WikidataInfo.js]]
importScriptURI("//www.wikidata.org/enwiki/w/index.php?title=User:Yair rand/WikidataInfo.js&action=raw&ctype=text/javascript");

--Snaevar (talk) 18:26, 4 May 2013 (UTC)

Thx! Xaris333 (talk) 18:57, 4 May 2013 (UTC)

Watch tab star

Hi - since switching to Vector recently, I've noticed there seems to be no rhyme or reason to the watch/unwatch tab at the top of the page. Sometimes it's written in text, sometimes as a filled or hollow star. It doesn't seem to be namespace specific, nor (as I first suspected) is it browser dependent (a lot of my browsing is done on a clapped out IE7 PC which I can't upgrade). Does everyone get this? Is there any reason for the inconsistency, and is there any css/js tweak I can do to make it appear the same way? An optimist on the run!   06:58, 4 May 2013 (UTC)

In your vector.js you have a script $('#ca-watch').removeClass('icon'); to remove the icon. However, it can only do this after the page has fully loaded, which can take a while. That explains the inconsistent result you are observing. —TheDJ (talk • contribs) 07:06, 4 May 2013 (UTC)
I should have thought of that - thanks. An optimist on the run!   07:58, 4 May 2013 (UTC)
I only get the star, never text. I'm using Firefox 23 on Windows 7.  — TORTOISEWRATH 17:03, 4 May 2013 (UTC)

Move page

I made an error when i moved a page from User:Edinburgh Wanderer/2013–14 Partick Thistle F.C. season and ended up at Edinburgh Wanderer/2013–14 Partick Thistle F.C. season. I then tried to move it to the correct page 2013–14 Partick Thistle F.C. season and got a database error. The database error created 2013–14 Partick Thistle F.C. season but as a redirect to Edinburgh Wanderer/2013–14 Partick Thistle F.C. season i.e not moving the page. Need an admin to fix it and not sure what caused the database error.Blethering Scot 22:34, 4 May 2013 (UTC)

Fixed. PrimeHunter (talk) 22:43, 4 May 2013 (UTC)

climate table at Homer, Alaska

I've just removed a rather nice table at this article because it was causing a serious formatting error that generated massive whitespace in the article. This is the second time this has been added, the second time it has broken the article, and the second time I have spoken to the person who added it about it but they seemed uninterested in doing anything to rectify the situation. It's a nice table and I'd like to have it in the article, but not if it is going to ruin the formatting. Anyone know how to fix it? Beeblebrox (talk) 19:34, 4 May 2013 (UTC)

It's fairly easy to fix - the problem is that the weather table has to be a particular width, and it "collides" with the infobox and the images on the right, causing it to be shoved down until after the images - hence the whitespace.
I've moved the images below the box for now (it may still have some whitespace on wider screens due to the infobox); the other solution would be to move the weather table much further down the page. Andrew Gray (talk) 20:34, 4 May 2013 (UTC)
That works for me, thank you. Beeblebrox (talk) 22:34, 5 May 2013 (UTC)

Generating a JS library for cleanup scripts

While I was fixing some bugs at our WP:AFC helper script (WP:AFCH) I was realizing that there are many scripts trying to archive many kind of cleanup the same way and reinventing the wheel. I want that these developers work together (more?) and generate a library for cleanup uncontroversial stuff like converting HTML markup to wiki markup, fixing common spelling errors, removing unnecessary HTML comments (the AFC project is generating many of them) and doing similar stuff.

Potianial script for such a library (I know of) would be:

and additional this also could be added to Twinkle as a general cleanup while tagging pages.

Would anybody experienced with JavaScript and/or Regex would help me adding as many as possible uncontroversial cleanup lines to this library and improving Wikipedia by crowed developing? :-)

mabdul 22:13, 4 May 2013 (UTC)

My experience with both is limited, but I would be happy to contribute where I can. Technical 13 (talk) 22:55, 4 May 2013 (UTC)
Is it a case of 'reinventing the wheel, or is it simply 'many hands make light work'? I run several scripts. Each script has a unique scope with some minimal overlap. Of those, my formatting script does things similar to AWB general fixes, and it is possibly the one you would target as being of the most general in cleaning up function. The scripts all employ regexes, so copying them over per your thoughts should be relatively simple. Maybe some others can chip in about the collaboration model: for security reasons, scripts are currently protected and tied to the user. -- Ohconfucius ping / poke 01:11, 5 May 2013 (UTC)
One possible solution for using the central depository might be to call up script functions from another. This can be done so long as it's imported into the driver script, in the same manner as importing into vector or monobook. Tony1 achieves a 'one-touch' facility by installing my control script – a composite I wrote for that purpose. -- Ohconfucius ping / poke 02:09, 5 May 2013 (UTC)
You probably should start with AutoEd. It is a javascript program that calls other javascript modules. There is a module to convert HTML markup to wiki code, some others to correct formatting.
Typos project is used by AWB, WikEd and WPCleaner for spelling mistakes. Bgwhite (talk) 08:36, 5 May 2013 (UTC)

Thumbnail generation issue

I just uploaded this file for use here; the thumbnail in the page where it is used is displayed fine, but the server is refusing to generate previews of the image for use on the image page or non-full-resolution links therefrom. What is causing this; is it related to the database lockdown an hour or so ago?  — TORTOISEWRATH 01:37, 4 May 2013 (UTC)

Seems to work for me (thumbnail is displayed). If a specific thumbnail size does not display for you, please provide the size(s). --AKlapper (WMF) (talk) 12:51, 6 May 2013 (UTC)

Adding new content (with reference)

While moving pictures and copyediting in the Home Front (World War II) article, I forgot to add: 'New material to the "Britain" ' section, on 4 May 2013. Trying three or four times, both yesterday and today, for some reason, it will not accept my input when I press 'Save' (it's only on this page). But the new content is there; I've looked. RASAM (talk) 12:20, 5 May 2013 (UTC)

Are you trying to change the edit summary without changing content? --  Gadget850 talk 12:29, 6 May 2013 (UTC)
Looks likely that that's it. A way round it is to delete your new material, and then save, followed by re-adding it with the edit summary. Or easiest, just don't worry about it. If you're not planning to stand for an admin job in the near future, just leave it. No-one's going to block you or shout at you for missing one summary. I don't think summaries without content will go into the record. Peridon (talk) 15:09, 6 May 2013 (UTC)
Hang on - you did it at Home front during World War II not Home Front. You moved pics and left an edit summary there all right on that day. Perhaps that's the trouble... Peridon (talk) 15:15, 6 May 2013 (UTC)
Sorted. Peridon (talk) 08:58, 7 May 2013 (UTC)

Toolserver problems

Referring back to Toolserver funkiness from April 21, it's still crap. Don't know how much I've tried since then. But the message that keeps coming up today when I tried to access "Contributors" from an article's history page is,

Bad Gateway
An error occurred while communicating with another application or an upstream server.
There may be more information about this error in the server's error logs.

It only has to do with the Contributors, all other options under history have always worked fine. If I go into the Firefox "Page Info" or "Page Source", it had exactly that same message, nothing else. — Maile (talk) 14:59, 5 May 2013 (UTC)

I've been having random problems for the past couple days whenever I try to use anything on Toolserver. I'm getting "Bad Gateway," "Gateway Time-out," "Page not found," "en.wikipedia.org is not a valid wiki," whatever it feels like giving me. What's gone wrong this time?  — TORTOISEWRATH 01:43, 6 May 2013 (UTC)
I got it to give me X!'s Edit Counter this time, but the replication lag is terrible right now. Is this related to the database lock a couple days ago, perchance?  — TORTOISEWRATH 01:48, 6 May 2013 (UTC)
I began noticing this weeks before I first posted about it on April 21. It comes. It goes. And just when you need it, it malfunctions. Since I posted above today, I went over to toolserver and tried tools I knew about. More than half the time, I got that "Bad Gateway" message. Right now, it's working. But later, it won't. Very unreliable. — Maile (talk) 02:01, 6 May 2013 (UTC)
I've gotten nothing but "Page not found" errors at least since yesterday. Anybody here in contact with anyone over there? Rivertorch (talk) 05:08, 8 May 2013 (UTC)

Preferences date/time-setting

I changed the format and TZ of date/time in Preferences, but the software still shows the UTC time. Should be CEST since I'm in Italy. Please give me a valid reason for this behavior. All 4 other great Wikipediae do it right, only the English is different. The number format (.=>,) as well, but I can accept this as a geek :-), Kind regards from Tuscany,  Klaas|Z4␟V:  15:35, 5 May 2013 (UTC)

It works for me. What exactly does "Server time", "Local time" and "Time zone" say at Special:Preferences#mw-prefsection-datetime? Do you see the UTC time in page histories and user contributions like Special:Contributions/ZeaForUs? Signatures and other content based on wiki source is not affected by the setting (but a gadget can affect it). PrimeHunter (talk) 18:17, 5 May 2013 (UTC)
Browser info (name and version) also welcome. --AKlapper (WMF) (talk) 12:55, 6 May 2013 (UTC)

Patrolling new pages

I used to be able to patrol new pages (allthough I never did). Some time ago, however, I lost the ability. I can't mark a page as patrolled anywhere (as I can see), and the red and green circles to the right which used to be there when I looked at new pages don't show anymore. Suggestions? Regards, Iselilja (talk) 19:32, 5 May 2013 (UTC)

That has happened to me as well, and I did used to patrol them.--Gilderien Chat|List of good deeds 22:51, 5 May 2013 (UTC)
    • Have either of you disabled JavaScript? I believe that the badge that pops up when I mark a page as patrolled (there's a tiny link at the bottom of the page) is a JavaScript thingie, so possibly the entire thin is. But wait a minute... 1) did you know there's a link at the bottom of the page? and 2) are you using Page Curation? In which case what I just said may have no bearing. Hope this helps. Ignatzmice•talk 22:55, 5 May 2013 (UTC)
@Gilderien, Iselilja: When you visit Special:NewPagesFeed and review a specific page, is there a "Curate this page" link in the toolbox section on the lefthand side? If so, clicking that link should make the toolbar that you can use to review pages re-appear.--Eloquence* 01:08, 6 May 2013 (UTC)
  • Thanks for input. No, I cannot see a "Curate this page" link. And I don't get this "Mark this page as patrolled" link at unreviewed pages anymore. (Maybe I should mention that my skin is Cologne Blue, but this has been so all the time). I believe I have the JavaScript installed as I am able to use my internet bank. Regards, Iselilja (talk) 05:15, 6 May 2013 (UTC)*
  • Eloquence, Ignatz, Gilderien. NOW, I found it: A "curate this page" link, and after I clicked it the right side bar is showing up again. Thank you, very much, Iselilja (talk) 22:22, 6 May 2013 (UTC)

Hidden categories text size

I'm trying to find a way to make the hidden categories have a smaller font size than the main categories. Surely there's some CSS hack I'm not aware of. I've found &lt;div id="mw-hidden-catlinks" class="mw-hidden-catlinks mw-hidden-cats-user-shown"&gt; in the HTML code, if that helps. FallingGravity (talk) 05:58, 6 May 2013 (UTC)

Judging by this edit, try 
div#mw-hidden-catlinks { font-size: 88%; }
which works for me. I put it in Special:Mypage/skin.css but I don't see why it couldn't go in Special:Mypage/common.css --Redrose64 (talk) 09:33, 6 May 2013 (UTC)
That worked, thanks! FallingGravity (talk) 18:53, 6 May 2013 (UTC)

Email notification

Hi, is the email notification system working? I don't seem to be receiving items although my email appears to be working, so I don't think it's a problem on my own emails. SagaciousPhil - Chat 09:51, 6 May 2013 (UTC)

Have you checked your notification preferences? Also, has your email adress been confirmed? — Edokter (talk) — 10:33, 6 May 2013 (UTC)
Yes, I've re-checked preferences and notifications and everything is set correctly. It was working fine yesterday evening but just stopped and there is still nothing coming through - for instance, I didn't receive notification of your response, just picked it up by checking my watch list. SagaciousPhil - Chat 10:53, 6 May 2013 (UTC)
All of a sudden in the last few minutes, email notifications have started to arrive. SagaciousPhil - Chat 16:45, 6 May 2013 (UTC)
Resolved

Skip to TOC - Skip to Bottom

Skip to TOC - Skip to Bottom appears at the top of any of my user space pages (i.e. sandboxes etc.). The problem is, it lays itself right across the Edit link for the lead, making it impossible for me to click on that. This has only started happening recently, but I'd like to know how to get rid of it. Only on user space pages. I've changed skins to see if it will at least appear at a different place on different skins. Nope, that thing totally covers up my Edit link for the lead section. Zooming in or out with my browser does not change the position. I have absolutely no need for this "Skip to..." message, and it just hinders my editing ability on my own pages. Please tell me how to turn it off. — Maile (talk) 11:54, 6 May 2013 (UTC)

And...it's not on all my user space pages. It's just hit and miss as to which one it appears on. No pattern I can see what makes it appear on one user space page and not another. Has nothing to do with whether or not there is a lead section. And it has nothing to do with whether or not there even is a TOC on the page. This is strange. — Maile (talk) 12:17, 6 May 2013 (UTC)
Added nostb for you. — Bility (talk) 18:14, 6 May 2013 (UTC)
Thank you very much. That worked. — Maile (talk) 18:20, 6 May 2013 (UTC)
Well, it worked on my main user page. It did not work on This One. So, I'm wondering what I did in setting up this particular page that triggered it. — Maile (talk) 18:27, 6 May 2013 (UTC)
OK. Well, I see that something in the navboxes was triggering it. So, I removed the navboxes. End of problem. — Maile (talk) 18:29, 6 May 2013 (UTC)
There was already an instance of {{Noticeboard links}} on the page, so adding another one with |nostb=yes didn't do anything. Just needed to add the parameter to the template that was already on there. Cheers, — Bility (talk) 18:31, 6 May 2013 (UTC)

Invalid Search redirect to C2.org

Typing Wiki:SOFIXIT (okay I forgot what the proper link for shortcut, it should be WP:SOFIXIT) into the search bar on FF or the search bar on wikipedia itself links to C2.org instead of a page saying no link exists. ηoian ‡orever ηew ‡rontiers 19:53, 6 May 2013 (UTC)

It's a feature. Typing wiki:anything you like will always go to http://c2.com/cgi/wiki - it's one of the prefixes listed at m:Interwiki map. Same goes for wikilinks like wiki:anything. --Redrose64 (talk) 20:13, 6 May 2013 (UTC)
Indeed. But here's a slightly confusing detail: if you type <known interwiki prefix>:<any text> and press search rather than go, our search results page tells you "There is a page named "xx:yyy" on Wikipedia". This is wrong in two ways: (1) the page might or might not exist, it's only the prefix that exists for sure; (2) the page will not necessarily be on a site called Wikipedia.
It's obvious where this comes from, since the prefix is known the whole thing is a valid link from Wikipedia's point of view, so the search engine claims we have that page. But the phrasing is not quite right in the case of interwiki links. — HHHIPPO 20:28, 6 May 2013 (UTC)
The default Vector skin doesn't have search and go buttons. The search button in other skins corresponds to "containing..." in the drop-down box. ηoian is far from the first to be confused by wiki: going to c2.com. There is a suggestion to remove this prefix at meta:Talk:Interwiki map#Wiki. The discussion could actually use some technical expertise. Anyone have a method to determine the number of uses in Wikimedia wikis? If the prefix is removed then presumably a bot should change the uses at all wikis to one of the three other prefixes for c2.com. Can the uses be identified? PrimeHunter (talk) 22:45, 6 May 2013 (UTC)

https://

Resolved
 – Back up since circa 14:00, 7 May 2013 (UTC)

The https:// version of the site is inaccessible. Is this happening to anyone else?--Gilderien Chat|List of good deeds 19:54, 6 May 2013 (UTC)

tracert
 5    35 ms    42 ms    29 ms  r1fra1.core.init7.net [80.81.192.67]
 6    30 ms    48 ms    38 ms  r1fra3.core.init7.net [77.109.128.222]
 7    42 ms    43 ms    43 ms  r1fra2.core.init7.net [77.109.128.245]
 8    56 ms    48 ms    46 ms  r1ams2.core.init7.net [77.109.128.201]
 9    48 ms    45 ms    47 ms  gw-wikimedia.init7.net [77.109.134.114]
10    45 ms    42 ms    42 ms  wikipedia-lb.esams.wikimedia.org [91.198.174.225]

reverting single edit (not last one)

When someone does something obnoxious like this 8 Feb edit, which removed all ref tags, and some other code, I know one can restore to the version prior to the edit, but that will wipe out the couple dozen subsequent edits. Is there a solution which undoes that one edit without disturbing the subsequent edits? I'm fairly sure the answer is no, but want to ask, just in case.--SPhilbrick(Talk) 22:20, 6 May 2013 (UTC)

You can sometimes undo the edit, as long as there is no conflict with any of the following edits. However, it doesn't look like that will work in this case. --Bongwarrior (talk) 23:55, 6 May 2013 (UTC)
Yeah, I tried that, but it failed. Oh well.--SPhilbrick(Talk) 00:44, 7 May 2013 (UTC)
Resolved
by doing it manually.--SPhilbrick(Talk) 12:45, 8 May 2013 (UTC)

Template:Commons category multi

Could someone take a look at Template:Commons category multi? When there are 2 categories listed, the box is not "clearing right". It's aligned right, but it floats to the left of other right-aligned boxes. See Category:Horticulture and gardening, it should be under the "infobox catalog", not to the left of it. Thanks, --Funandtrvl (talk) 00:06, 7 May 2013 (UTC)

I think I took care of it. --Izno (talk) 00:24, 7 May 2013 (UTC)
Yes, I think that worked. Thanks! --Funandtrvl (talk) 00:28, 7 May 2013 (UTC)

Custom CSS - color change

Using: Firefox, latest version

What I want is to make the background display the color I choose. My CSS code so far (within "body { }brackets): 

   font-family: DejaVu, serif;
   font-size: 125%;
   color: #FFD6AD;
   background-color: #FFD6AD;
   content: #FFD6AD;

This turns everything my chosen color except the background of the article itself -- that's still white. What am I missing? --Bluejay Young (talk) 02:27, 7 May 2013 (UTC)

Try this outside body brackets:
#content { background : #FFD6AD !important; }
PrimeHunter (talk) 03:19, 7 May 2013 (UTC)
You should also remove the 
content: #FFD6AD;
from its present position. The content: property can't control colour, and so it isn't expecting a colour value. Another point: if you have settings like
    color: #FFD6AD;
    background-color: #FFD6AD;
what you're asking for is text of this colour on a background of this colour which looks like this and that has serious WP:CONTRAST issues, even if you have 20/20 vision. --Redrose64 (talk) 09:49, 7 May 2013 (UTC)
Yikes, no, that wasn't what I had in mind. I'm trying to make Wikipedia display everything in my Irlen color (or something close to it). What about the very top area, where (at least in Vector) your "talk," "sandbox," "preferences," "watchlist" etc. links & your searchbox are? What is that called/how would I change it from white to my color? Thanks! --Bluejay Young (talk) 13:17, 16 May 2013 (UTC)
I've replied on your talk page. – PartTimeGnome (talk | contribs) 21:10, 16 May 2013 (UTC)

Template: Conjugate

Could someone of HTML/CSS experts review my template {{conjugate}}? You can see the actual use in composition algebra. When you helped me with possible shortcomings, I would back-port the style to {{sqrt}} and {{radic}} which suffer from (e√þ same) √disease as {{overline}}. Incnis Mrsi (talk) 07:24, 7 May 2013 (UTC)

I would advice against the packport. Both implementations may show better results on one, and worse result on other poeple's computers. It all depends on what fonts are used on the user's display. They actually look very similair to me. — Edokter (talk) — 23:46, 7 May 2013 (UTC)
Thanks, but does any reliable mean to control the gap between the top of glyphs and the overline exist? Or any calculation for upper border departs from some fixed line such as cap height and hence, a uniform solution for uppercase and lowercase letters is not possible? Edokter, please, watch your spelling. Making three typos in a short reply is awful. Incnis Mrsi (talk) 09:32, 8 May 2013 (UTC)
There is no 100% failproof way to position the overline. You can play with line-height, but that also varies with the used font. — Edokter (talk) — 10:15, 8 May 2013 (UTC)
Line-height has no effect either. Padding is already zero. If your goal is to make the line lower, then there is no way. — Edokter (talk) — 10:20, 8 May 2013 (UTC)
On my screen, {{overline}} looks actually slightly better in composition algebra then {{conjugate}}; the overline is slightly closer and scales better with font-size. — Edokter (talk) — 10:37, 8 May 2013 (UTC)

Universal account

Where can I discuss my situation regarding my accounts on other Wikimedia projects? Simply south...... eating shoes for just 7 years 10:02, 7 May 2013 (UTC)

There was some related discussion at Wikipedia:Village pump (technical)/Archive 111#Unwanted global account(s), which may contain helpful links. --Redrose64 (talk) 10:42, 7 May 2013 (UTC)
Thanks although mine is a different situation. I have now expanded a little and left a note at WT:Unified login/Finalisation if you want to reply there. Simply south...... eating shoes for just 7 years 10:53, 7 May 2013 (UTC)

Mass removal of old indefinite rangblocks under controlled conditions

Hello,
There is currently an ongoing proposal at Village Pump (proposals) to review and remove most old indefinite rangeblocks on IPs, and to have their edits monitored for an interim period of time. The proposal has received nearly unanimous support from about a dozen editors, but there has not been any discussion so far on how it could be possibly implemented. Anyone with any technical know-how is welcome to comment on the proposal as well as to discuss on how to implement it, should it pass.
Thank you,
TheOriginalSoni (talk) 10:02, 7 May 2013 (UTC)
[Please comment on that discussion only]

Twinkle D-batch

See User talk:MZMcBride#Advice. I can't seem to get the D-batch function to work on Category:Candidates for speedy deletion or any other page for that matter. There's a bunch of G8 speedies for broken redirects that I wanted to batch delete. How to get D-batch to work, or other methods of batch-deleting? INeverCry 19:30, 7 May 2013 (UTC)

Create a new "trusted user" permission group.

See this discussion. The proposal is to create a new group which bundles a few miscellaneous rights that don't fit in any of the existing groups. User:PinkAmpersand suggests "Suppressredirect, move-subpages, markbotedits, unwatchedpages, maybe tboverride." The reason I'm requesting this is that I'd like to be granted "move-subpages" permissions, but it isn't currently granted for any groups but admins. In the discussion linked to, I proposed adding it to Filemover, but that didn't fly. Klortho (talk) 12:55, 8 May 2013 (UTC)

Require IP/anon edits to enter an edit summary

Just wondering if the Wiki software was capable of enforcing the entry of edit summaries when users are not logged in (i.e. IP/anonymous users)? Registered users would be unaffected; they could continue to leave blank edit summaries based on their judgement (and lack of criticism from other editors). One notorious problem is that IPs will change information on articles (vital stats or facts) without explanation - often it is introduction of errors; sometimes it is choosing data from conflicting and/or unreliable sources; occasionally a valid point is being made, but the editor is not indicating that. The countervandalism and edit review process would be expedited if IPs had to enter an edit summary, ideally with a prompt which explains the need for reliable sourcing and the value of edit summaries. Or we could keep the status quo and continue to waste a lot of collective time attempting to read minds when dealing with most IP edits. Dl2000 (talk) 21:21, 8 May 2013 (UTC)

You can't force a useful summary...so why force a summary? --Onorem♠Dil 21:25, 8 May 2013 (UTC)
agree with Onorem. we currently get a lot of the "often it is introduction of errors; sometimes it is choosing data from conflicting and/or unreliable sources; " that ARE accompanied by edit summaries. And those summaries are rarely "I am adding bad information". -- TRPoD aka The Red Pen of Doom 21:29, 8 May 2013 (UTC)
Example. This is in fact useful, because there is a lot of unsourced WP:CRYSTAL being added to articles about British heritage railways - and although the IP address changes at least once a day, the edit summary is normally "Update!!" --Redrose64 (talk) 21:35, 8 May 2013 (UTC)

Echo

Modern skin and Echo

I made some local CSS changes to the Modern skin, so that these users get a bit better Echo experience. If ppl report issues with Modern skin not relating to Echo in the coming hours, this might be a candidate for reverting. —TheDJ (talk • contribs) 22:35, 1 May 2013 (UTC)

Orange message bar

Where did the orange message bar go? All I get now is this little blue number in the upper right corner. Prettier, certainly, but far less effective. The orange bar was ugly as sin, but there's no way a new editor could claim he didn't know he had a message.—Kww(talk) 06:08, 2 May 2013 (UTC)

Just found Wikipedia talk:Notifications. I really don't understand how things like this just show up one day. How could anyone think making it difficult for a new editor to realize he's about to be blocked was a good idea?—Kww(talk) 06:20, 2 May 2013 (UTC)
It's gone. Choyoołʼįįhí:Seb az86556 > haneʼ 06:21, 2 May 2013 (UTC)
  • 👍 LikeI actually quite like the powerful new functionality. Now a message on our talk page will give rise to a notification, ditto if someone reverts a change we make somewhere, and if you are mentioned on the talk page of another. There may be others which I have not yet discivered, but what's there is good. The little red blob with a number on it is discrete yet instantly noticeable, and will be more so once we get used to it. -- Ohconfucius ping / poke 06:31, 2 May 2013 (UTC)
I'll chime in with general support. Unfortunately, one of my first notifications was a revert, by an IP, of a recent edit. Embarrassingly, a good revert, but while it was on my watch list, my watch list is out of control, and I might not have seen it otherwise. Not opposed to restoring the orange bar, though.--SPhilbrick(Talk) 13:14, 2 May 2013 (UTC)
This appears to be a case of registered editors' preferences being put first, when there were very good reasons for not doing so. I'm certain that a comfortable majority of established editors would like to use the new implementation, indeed I would myself. But communication between all types of editor is essential, and the orange bar is without question easiest way of making sure that someone receives a message in good time (assuming they're logged in, of course). This is particularly true of newly registered and IP editors, but doesn't exclusively apply to them. In my experience established editors like to get rid of the orange bar as quickly as possible, and I doubt the same will apply to the relatively discrete number in the top corner. —WFC— FL wishlist 05:47, 3 May 2013 (UTC)

There is a new gadget (basically a copy-paste of Writ Keeper's script, except for a bit saying to get familiar with Notifications and a link to the doc page that has instructions to turn it off) has been created. Being a gadget, it is fully opt-out-able. The script can be reviewed at MediaWiki:Gadget-OBoD.js. It was ON by default, so new users would see it, but Edokter raised concerns about that. Should it be default-on? Comment at WT:Notifications#Pseudo OBOD Gadget is live. Ignatzmice•talk 19:50, 4 May 2013 (UTC)

There are far too many discussions going on in far too many places at this point. Can we just create a separate page to talk about the Orange Bar and related RFCs? Surely we can copy/paste all the current text to that and point links in all these pages / threads to that page. Now we have two gadgets for this, as well? (This is my understanding.) Killiondude (talk) 20:29, 4 May 2013 (UTC)
  • Comment The 'official' discussion is at Wikipedia talk:Notifications (and THEY do seem to be listening to us), but the briefly turned on replacement has been slated for review here. Someone decided that a 107 to 19 consensus wasn't enough, or that the gadget was untested and needed reviewing over here. Peridon (talk) 20:55, 4 May 2013 (UTC)
    • I am not disputing the outcome of the RFC; just the way the code is deployed. Gadgets are subject to review, especially if they are going to be turned on be default. I could find no technical review, do I disabled the [default]. — Edokter (talk) — 21:06, 4 May 2013 (UTC)
    • It is urgent to restore a means of communicating with newbies. The WMF refuse to restore the "proper" orange bar, and are talking of the week after next for their solution. Please let us not start another discussion here: comment at WT:Notifications#On by default? JohnCD (talk) 21:17, 4 May 2013 (UTC)
I just got a message about vandalism on a library computer before signing in. So all is well, apparently.— Vchimpanzee · talk · contributions · 20:09, 8 May 2013 (UTC)

Notifications gadget's z-index

Tracked in Phabricator
Task T50078

Notifications gadget doesn't appear properly because z-index is same like the editor toolbar - 100. --Rezonansowy (talk) 12:01, 6 May 2013 (UTC)

I suspect you use the Visual Editor toolbar. I have already file a bug. — Edokter (talk) — 12:16, 6 May 2013 (UTC)

Gadget review please

I'd like some technical review for Mediawiki:Gadget-Notification.js and Mediawiki:Gadget-Notification.css for the potential event that it may be enabled by default. It's basically two lines of JavaScript, so I don't expect any problems. This may put a stop to a very large discussion at Wikipedia talk:Notifications. The gadget is intended to be active until the WMF team has decided on a solution for a new message indicator discussed at Wikipedia:Notifications/New message indicator‎. — Edokter (talk) — 15:11, 6 May 2013 (UTC)

Note: Screenshot here, if anyone cares to know. Ignatzmice•talk 15:15, 6 May 2013 (UTC)

Temporary notification system

I am going to enable a default gadget that will pop up when you receive a notification. I do this because there is a valid concern new editors may not notice the standard red blip on top of the screen. While there is consensus that some form of notification alert is needed, the current discussion at Wikipedia talk:Notifications/New message indicator is going downhill fast.

For more information, see Wikipedia:Notifications/Popup documentation. — Edokter (talk) — 00:30, 7 May 2013 (UTC)

Hi @Edokter: now that this gadget is being served to all new editors, and they're seeing it almost immediately after signup due to the welcome notification, I wanted to run a quick remote usability test to see if there are any glaring successes or problems we should investigate further. (The WMF has a usertesting.com account which we use for this sort of thing regularly.) I ran just two initial tests to make sure our test instructions made sense, and here are the relevant clips regarding the popup...
  • Clip A
  • Clip B
As you can tell, the good news is that the popup helped them see that they had notifications, and after that they successfully clicked the number indicator and opened their notifications. The bad news is that they both were confused by the red in the popup, and thought it indicated there was an error or problem, rather than a neutral notification. I think this supports the suggestion I made earlier, which was removing the red background. Of course Fabrice's team or someone still needs to run a larger experiment to get an objective look at clickthrough rates for various options on the table, but this is why we also do usability tests: more clicks are not always better, if new editors end up confused or irritated.
If you'd be interested in running another pair of usability tests to see if users react differently, let me know. Last but not least: the testers pick us, we don't pick them individually, but the person in Clip A said he had several thousand edits prior to the test, which is slightly unusual for usertesting as a site. Steven Walling (WMF) • talk 05:38, 7 May 2013 (UTC)
That is good feedback. I may test another design, it will have some red, as it matches the badge. User A expected orange, which only experienced editor would. I may also file a bug report on how to improve mw.notify, as it is quite inflexible; there is an option to make it persistent, but I can't set a custom timeout. — Edokter (talk) — 09:51, 7 May 2013 (UTC)
Toned it down for now. I have to go out for a few hours, will complete it tonight. — Edokter (talk) — 10:18, 7 May 2013 (UTC)
The relevant bug on mw.notify is 40307. Agreed about orange, that's why I pointed out he was an experienced editor. Steven Walling (WMF) • talk 19:20, 7 May 2013 (UTC)

You have new messages

I didn't see the orange bar that says I have new messages. I did happen to see a 1 that I had never seen before to the right of my name at the top of the page. I clicked and was told I have new messages. I like the old way better.— Vchimpanzee · talk · contributions · 19:56, 7 May 2013 (UTC)

Well, if you really want the OBoD in all its glory back, I made a script when this was first released to restore it: you can install the script by going to your common.js page and pasting in the following line: 
importScript("User:Writ Keeper/Scripts/orangeBar.js");
. Thanks to a change Kaldari made yesterday (and forgot to tell me about, coincidentally; I had to stumble across it myself earlier today), it should be nearly identical to the way it was before; it just takes slightly longer to appear than it used to. Writ Keeper ⚇♔ 20:32, 7 May 2013 (UTC)
Thank you. I got worried when I couldn't find my question but see others have been concerned about the same thing.— Vchimpanzee · talk · contributions · 20:47, 7 May 2013 (UTC)
And I just found what I needed in the Help Desk archives. If I had been a little more patient ...— Vchimpanzee · talk · contributions · 21:18, 7 May 2013 (UTC)

Notifications popups

Hi, where was the consensus for this, and most especially for enabling it by default? -— Isarra ༆ 18:08, 8 May 2013 (UTC)

It was done at the Foundation level, not through any community based process. Beeblebrox (talk) 18:48, 8 May 2013 (UTC)
No, I don't think it was; I think that was User:Edokter doin' his thing. Not sure where he claimed consensus, though it may (or may not) have been an IAR-type thing to bridge the gap before the WMF response. Writ Keeper ⚇♔ 18:51, 8 May 2013 (UTC)
That was Edokter (and me, and a couple other people maybe) just trying to get something together in light of all the concerns raised about newbies not noticing the small little box. I don't think IAR was ever specifically cited, but that was the general mindset. It's meant to be temporary, until the WMF comes out with something better. Ignatzmice•talk 18:54, 8 May 2013 (UTC)
(ec) If anything, I claimed a complete lack of consensus between the community and the WMF. Recognizing the immediate concern raised by the community, I stepped in and made the popup as a temporary measure. Haven't had complaints so far. — Edokter (talk) — 18:56, 8 May 2013 (UTC)
Consider this a complaint, then. Such things require consensus, and your change attempts to resolve poor design in one regard - a lack of noticeability or indication what the number actually is - with even worse in another - a very annoying popup that does not stay gone when dismissed, that still does not do anything to say what the notification is (or even what a 'notification' is in general), and that has little affordance to connect it to what it is even referring to due to its visual and spacial separation from the p-personal toolbar. This is not a good change, and indeed a good example of why we operate on a consensus- and review-based model, so please revert this at once if it is still live. -— Isarra ༆ 22:14, 8 May 2013 (UTC)
Why should it stay gone when dismissed? The whole point is to let editors (new editors especially) know that something important has happened. If people don't want it, there's a link there do the documentation page explaining how to turn it off. Ignatzmice•talk 22:28, 8 May 2013 (UTC)
Actually, there was an overwhelming consensus to reinstate the orange bar, but that proved problematic in that the proposed solution was untested. So I created one that was based on an existing framework thus not prone to bugs. I also reiterate that it is a temporary solution. I just came from IRC on a collaborative meeting where we agreed on a new notification system that will hopefully meet the approval of the community. Until then, the red popup only takes one click in your prefereces to disable. — Edokter (talk) — 22:30, 8 May 2013 (UTC)

Hey Edokter. I appreciate the work you've been doing trying to design something to meet community requests, but considering that there are now gadgets being tested to meet this need, can we consider turning off the red popup as default? (I don't mean removing it entirely.) The new gadgets by Kaldari still need design work I'm sure, but they already do more advanced behavior like only appear on Talk messages, so they work as orange bar replacements for editors that want them. I am also asking because in about an hour, my team is launching a controlled test of a new version of Wikipedia:GettingStarted, and the red popup is likely to have a negative effect on our test results. This is because it fires immediately after you sign up, due to the welcome notification. Steven Walling (WMF) • talk 19:02, 9 May 2013 (UTC)

Hi Steven. That does create the situation that prompted the red popup in the first place, namely that new editors don't immediately see that they have messages. Would it be OK to have the F2 gadget replace it as a default gadget? — Edokter (talk) — 19:08, 9 May 2013 (UTC)
Can't wait for a reply now. I'll check back in 45 minutes. — Edokter (talk) — 19:28, 9 May 2013 (UTC)
As a side question: is there a list of vars like mw.echo.overlay.notificationCount that allow my to filter talk page messages? — Edokter (talk) — 19:17, 9 May 2013 (UTC)
@Edokter: I think the F2 gadget as default would be fine, as an interim solution. Steven Walling (WMF) • talk 19:37, 9 May 2013 (UTC)
I don't know about ones that tie into Echo or mention a notification count, but if you're just looking for whether there's a new talk page message or not, Kaldari put in a new variable called "wgUserNewMsgRevisionId" that has the revid of the earliest unread edit on one's talk page, or null if there aren't any, which is cleared once a user goes to their talk page. I've already switched my OBoD script over to using it (which, as a consequence, no longer uses any API calls and is now quite simple and compatible with any browser/skin, I believe). Writ Keeper ⚇♔ 19:42, 9 May 2013 (UTC)
Okay, until we figure this out and pending some other small todos my team has, we're just going to hold off on launching our A/B test of the new GettingStarted. That will give us a week to let everyone figure out what's the state of notifications. Steven Walling (WMF) • talk 20:14, 9 May 2013 (UTC)
@Steven (WMF): I'm OK with switching to F2. That will give us a chance to measure the community reaction. — Edokter (talk) — 20:24, 9 May 2013 (UTC)
If folks want to un-default the Notifications gadgets and make F2 on by default, I'm fine with that. I went ahead and disabled the animation for now, since it's a bit janky and still needs some work. The gadget definition is 'toolbaralert2|toolbaralert2.js|toolbaralert2.css'. MediaWiki:Gadget-toolbaralert2 will need to be updated. Kaldari (talk) 20:52, 9 May 2013 (UTC)
Also, I should mention that it currently doesn't localize, i.e. it only displays the alert in English. Kaldari (talk) 20:55, 9 May 2013 (UTC)
It has been done. I don't know if the gadget should be moved to the Appearance section. Feel free to do so. — Edokter (talk) — 21:35, 9 May 2013 (UTC)

Notifications flag

How do I get rid of that Notifications tag at the top of my screen? I've disabled everything I know to within my preferences, but it's still showing up. My talk page is on my watch list, so I don't need that thing. Thank you! ←Baseball Bugs What's up, Doc? carrots→ 21:07, 8 May 2013 (UTC)

You can't. --Onorem♠Dil 21:08, 8 May 2013 (UTC)
Wikipedia talk:Notifications is the place to discuss it I guess, but it's not going away. --Onorem♠Dil 21:09, 8 May 2013 (UTC)
Was this done in place of that orange message bar that was there for years? ←Baseball Bugs What's up, Doc? carrots→ 21:16, 8 May 2013 (UTC)
This should get rid of the little number (e.g. "(0)") at the top of the page (not fully tested):
li#pt-notifications { display: none; }
However, do not use the above unless you have some other talk notification gadget or user script enabled! You need an immediate notification of talk page messages of some sort; it looks really bad if you continue editing after someone sends you a message asking you to stop and discuss. (I doubt you look at your watchlist between every edit.) – PartTimeGnome (talk | contribs) 20:04, 9 May 2013 (UTC)

Edit-window bar blocks notification popup

Tracked in Phabricator
Task T50078

Sorry to contribute to the fun but when I click the notifications tag in edit mode, the top bar of the edit window (with "Advanced", "Special characters", "Help" and "Cite") blocks part of the notifications popup (which, FWIW, I like now :-)). My skin is Vector. Thanks and all the best, Miniapolis 21:05, 9 May 2013 (UTC)

Are you using the Visual Editor? If so, this is bug 48078. – PartTimeGnome (talk | contribs) 21:15, 9 May 2013 (UTC)

Add 'move-subpages' permission to the filemover group

I already suggested this under Proposals, but got no response -- perhaps this is the right place instead. It's a pretty trivial request, and I can't imagine there would be opposition. Perhaps the reason no one responded there was that it is too trivial, and really, implementing it is just a technical issue. The following is a slightly modified version of what I wrote there.

Filemovers have been vetted to ensure that they can be trusted to move images, for example. I would think they should also be trusted to move subpages. Use case: Right now I am trying to help clean up categories and pages in the GLAM area, and we are renaming several project pages to use the full name of the institutions. This is extremely tedious because some of them have many subpages, and they have to be moved one-by-one.

I was just granted 'filemover' rights, but that doesn't allow me the ability to move subpages.

Klortho (talk) 14:06, 2 May 2013 (UTC)

  • Support I see no reason not to. -- King of ♥ ♦ ♣ ♠ 07:49, 3 May 2013 (UTC)
  • Comment This initially seems like a fine idea, even though the two rights aren't terribly connected. I'm just a tiny bit worried that this would lead to filemover being assigned solely for the move-subpages right, though. Perhaps add this to rollback instead? I think the use of this right should be (generally) easy to undo, as with rolled back edits, so that would seem like a better fit to me. – Philosopher Let us reason together. 19:41, 3 May 2013 (UTC)
Either one would be fine. Please tell me -- where does this go from here? I've never suggested a change here before, and I'd like to know what is the procedure for actually getting it done. Do we need a quorum of "support" votes? Klortho (talk) 03:01, 4 May 2013 (UTC)
To be clear, I would support either version, but greatly prefer the rollback one. As for next steps, it'll wait a few days. If nothing happens, you can bump a (preferably) uninvolved experienced user or admin who posts on this board to judge the existing consensus and try to get it moved to the next step. I think the next step is filing a bug on Bugzilla, but I'm not quite sure. Hope this helps. – Philosopher Let us reason together. 02:14, 6 May 2013 (UTC)
  • Oppose "filemover" has a clear purpose: moving files. Why screw that up by making it "file and subpage mover"?

    But the proposal in the comments to add it to "rollback" is even worse, as that has absolutely nothing to do with file moving, and I strongly oppose that. If you want to create a "slightly more trusted than the average user, but not enough to go through RfA" group, propose that (after reading WP:PEREN#Hierarchical structures) instead of trying to add rights piecemeal to rollback. Anomie⚔ 20:28, 6 May 2013 (UTC)

    • Really, we should just have a rights group with some of the obscurer admin rights that occasionally come in handy. Suppressredirect, move-subpages, markbotedits, unwatchedpages, maybe tboverride. Basically that category of rights that have too high an abuse risk to be bundled with anything else, but require nowhere near as much trust as the core admin tools. — PinkAmpers&(Je vous invite à me parler) 23:11, 6 May 2013 (UTC)
  • Oppose Moving subpages is a different thing. Create a "subpagemover" user group instead if this is needed. --Stefan2 (talk) 21:22, 6 May 2013 (UTC)
    • Creating a usergroup for something that trivial seems quite silly to me - there's no need to keep expanding the number of usergroups we have for each function that is made more widely available. When proposing that it be included with rolback, I wasn't considering function but level of generic trust, which should be the relevant criterion, I think. But perhaps ... what did you think of PinkAmpersand's idea? – Philosopher Let us reason together. 04:31, 8 May 2013 (UTC)
  • Sigh It really shouldn't be this difficult for me to get this right. I have no interest in applying for adminship, but this particular right would let me work more effectively, which would benefit WP. Move-subpages, IMO, should be the default behavior: how often do you want to move a page, but leave all the subpages in place? So, I don't think there's a huge potential for abuse. Most people who get filemover probably wouldn't even notice that they had this new right. So, what is the problem, other than the aesthetic issue that it doesn't "fit" with filemover? Philosopher wrote: "I'm just a tiny bit worried that this would lead to filemover being assigned solely for the move-subpages right, though." -- Yes, that's what happened with me: in hopes of this proposal being accepted, I requested filemover, and got it. So what? I'm technically competent and trustworthy, and I'm not going to abuse filemover, and it might come in handy in the future. On the other hand, I agree with Philosopher that creating a "subpagemover" group for this is silly -- the whole point of having groups is to bundle rights, to keep things from getting too complicated.
Okay, I'll propose PinkAmpersand's idea of "trusted user". Klortho (talk) 12:49, 8 May 2013 (UTC)
  • I think just adding this to rollback makes much more sense. This is not a common enough issue to warrant an entire new userright and it doesn't make a great deal of sense to merge it with filemover. Beeblebrox (talk) 18:44, 8 May 2013 (UTC)
  • Support Beeblebrox' idea. This userright is meant for mainspace, as is rollbacker, and unlike filemover, and we don't need a new usergroup. Nyttend (talk) 23:17, 9 May 2013 (UTC)

Computer problems

1. The 'radio' buttons on all 'Revision history' pages always revert to the top two, after looking at any version - which makes a systematic trawl from the older edits to the most recent article page rather difficult. I've got a new computer with Windows 8 and Internet Explorer 10; the old one with Windows XP and IE 7 did not have this problem.

2. "Internet Explorer is not working correctly" is constantly being displayed. Sometimes it means that I lose eveything I have done. Again, I did not have this situation with the old computer. Anyone got any idea why and what I might do about it?


RASAM (talk) 21:30, 6 May 2013 (UTC)

As a start, do you experience the same problems with a different browser? --AKlapper (WMF) (talk) 08:49, 7 May 2013 (UTC)
They do mention this didn't happen using IE 7 on Windows XP, so I'd guess not.
Regarding the first point, you might find the "← Previous edit" and "Next edit →" links at the top of diff pages useful for tracing through history one edit at a time. Also, on a history page you can click the "prev" link next to an edit to quickly compare it with the previous edit without touching the radio buttons. (I appreciate that these tips aren't so useful if you want to compare edits in groups rather than one at a time.) – PartTimeGnome (talk | contribs) 20:23, 9 May 2013 (UTC)

File move strangeness

Can anyone figure out what's going on with File:Detail from Alfons Maria Mucha's "The Slavs in Their Original Homeland".jpg? I moved it to that title from File:Deatail from Alfons Maria Mucha's "The Slavs in Their Original Homeland".jpg, but now the image information page also displays as a redirect. I just can't figure it out. Thanks.--ukexpat (talk) 15:36, 7 May 2013 (UTC)

The redirect from the original location to the new location, was also on the new pointing to itself. - X201 (talk) 16:08, 7 May 2013 (UTC)
File:Detail from Alfons Maria Mucha's "The Slavs in Their Original Homeland".jpg (edit | talk | history | links | watch | logs)
Somehow you managed to do the move twice: first, moving the file page from the bad name to the good name, and then moving the redirect page on top of the file page. This needs an admin, I think, to recover the lost file page with its permission templates and such like. -- John of Reading (talk) 17:03, 7 May 2013 (UTC)
Jeez, so I did. I have no idea how or why I did that. Would a friendly admin in the neighbourhood please stop by and try to fix? Thanks.--ukexpat (talk) 17:42, 7 May 2013 (UTC)
I'm not entirely clear what the problem is. Is it that a redirect is listed at File:Detail from Alfons Maria Mucha's "The Slavs in Their Original Homeland".jpg#File usage? I don't think that's necessarily wrong: I recently moved File:Lewisham train crash 1857.jpg to File:St Johns train crash 1898.jpg and the old name is listed as a redirect at File:St Johns train crash 1898.jpg#File usage. --Redrose64 (talk) 18:34, 7 May 2013 (UTC)
It's more subtle than that. After the first move, at 13:04:34, there was a redirect at the wrong name and a proper file page at the right name. Eleven seconds later, the second move copied the redirect over the file page. The file was originally uploaded in November 2012, but the file page created then has been lost. Is it possible for an admin to recover it? -- John of Reading (talk) 19:13, 7 May 2013 (UTC)
There's very little in the logs for the old name, and nothing in the logs for the new name. There's nothing at the deletion archive, for either file. I rather think that it's beyond the powers of a WP:ADMIN, you need a specialist with direct SQL access. --Redrose64 (talk) 20:36, 7 May 2013 (UTC)
Can anyone recover the lost page from a database dump? This needs someone with a database dump and some Perl skills; I have the dump but not the skills. -- John of Reading (talk) 07:47, 8 May 2013 (UTC)
But that sounds like a bunch of work; wouldn't it be easier to put together a new page? We still have the image with its watermark, so we know its origin; this page says that it was published in 1912, so it's PD-US, and its Czech copyright status will depend on his 1939 death date. Meanwhile, a little confirmation on the unavailability of this data for admins: Special:Contributions/Chocolatemedia (the uploader) shows nothing around the time of upload except this, to add the new image to Mucha's article. Special:DeletedContributions/Chocolatemedia shows six edits, all of which are to Aslyoga, "an organiation that provides free yoga classes for the Deaf and Hard of Hearing communities". Nyttend (talk) 22:02, 9 May 2013 (UTC)

Namespace numbers

Wikipedia data structure
Namespaces
Subject namespaces Talk namespaces
0 (Main/Article) Talk 1
2 User User talk 3
4 Wikipedia Wikipedia talk 5
6 File File talk 7
8 MediaWiki MediaWiki talk 9
10 Template Template talk 11
12 Help Help talk 13
14 Category Category talk 15
100 Portal Portal talk 101
118 Draft Draft talk 119
126 MOS MOS talk 127
710 TimedText TimedText talk 711
828 Module Module talk 829
Former namespaces
108 Book Book talk 109
442 Course Course talk 443
444 Institution Institution talk 445
446 Education Program Education Program talk 447
2300 Gadget Gadget talk 2301
2302 Gadget definition Gadget definition talk 2303
2600 Topic 2601
Virtual namespaces
-1 Special
-2 Media
Current list

Who came up with these numbers? I guess the first few were created in chronological order, and the virtual namespaces in negative chronological order, but who decided that modules should be 828? -- Ypnypn (talk) 00:21, 8 May 2013 (UTC)

Its partially because it includes all Wiki's and their namespaces including some that have been deleted and some that were created and never launched. For example Wiktionary and Wikispecies both have some that Wikipedia doesn't have. I hope that helps. Kumioko (talk) 00:34, 8 May 2013 (UTC)
So there are a total of at least 414 namespaces, across all wikis across all time? -- Ypnypn (talk) 01:23, 8 May 2013 (UTC)
mw:Namespace_registration refers, but its list is far from comprehensive. LeadSongDog come howl! 04:34, 8 May 2013 (UTC)
150 is clearly what we as a community are lacking. ~ Amory (u • t • c) 06:09, 8 May 2013 (UTC)
Extensions are able to pick any namespace ID they'd like that's not already in use. I believe 828/829 wasn't chosen for any particular reason other than it's unlikely to conflict with any other numbers chosen. In practice, these numbers should matter very little to most users. ^demon[omg plz] 12:55, 8 May 2013 (UTC)
I'm guessing that they're numbered in the first place to transcend language difficulties — if they program the system to treat namespace 3 in one way, namespace 75 in another way, etc., they don't need to worry about the names of the namespaces, while they'd need to worry about it if they told the system to treat namespace Benutzer Diskussion: in one way and namespace Anexo: in another. Nyttend (talk) 13:29, 9 May 2013 (UTC)
Well yes, that's how namespaces work internally. ^demon[omg plz] 15:36, 9 May 2013 (UTC)

Errors...

It seems MediaWiki is choking this morning - been getting a few of the "Error" pages, and CSS styles(?) are pretty much borked on pages right now - all the text is displaying with absolutely zero formatting... - The Bushranger One ping only 13:41, 8 May 2013 (UTC)

At least, in Monobook - Vector seems to be OK, and oddly, most of the edit window seems to be OK, but the actual pages are wholly unformatted. - The Bushranger One ping only 13:45, 8 May 2013 (UTC)
  • (edit conflict) Yeah, I've been getting that too. Sometimes the page doesn't load; sometimes the page loads w/o CSS. JavaScript (e.g. Twinkle, suggestions in the searchbar, right-click to edit sections) also seems to be gone (and I haven't messed around with my common.js that recently...) P.S. I'm in Monobook too. Ignatzmice•talk 13:48, 8 May 2013 (UTC)
I am seeing it too -- the hamsters need a rest or replacement.--ukexpat (talk) 13:51, 8 May 2013 (UTC)
Ditto. Using Vector, some pages take upwards of 30 seconds to load (although eventually of all them do). All Wikimedia sites are causing the same problem (at least WP, Meta, and MW). Sometimes the CSS doesn't load. I remember a similar thing happening a few months ago. -- Ypnypn (talk) 13:54, 8 May 2013 (UTC)
Seems to be fixed now... Ignatzmice•talk 14:05, 8 May 2013 (UTC)
This sounds a lot like the outage on Wednesday, 13:30 - 14:00 UTC, due to a memcached server going offline. "As usual this caused all kinds of cascading failures on other clusters such as Squid/Varnish. When not overloaded, these clusters would only serve cached pages at that point." Should be fixed now. Sorry for the problems. --AKlapper (WMF) (talk) 01:32, 10 May 2013 (UTC)

Gadgets in the Slovene Wikipedia

Tracked in Phabricator
Task T50278

Hi, my apologies for bringing this up at the English Wikipedia, however this page seems to be the best place to get an answer. In the last days I've spotted that all the gadgets have disappeared in the Slovene Wikipedia (sl:) (HotCat doesn't work, PopUps don't work etc., the 'Gadgets' tab in the Preferences has disappeared). Any idea what's the reason for this and what to do? --Eleassar my talk 10:38, 9 May 2013 (UTC)

This is weird. sl:Special:Gadgets is supposed to show a list of all gadgets available on the wiki, but it is blank. sl:MediaWiki:Gadgets-definition has not been modified since March. Based on this, it looks as if there is some internal problem with the Gadgets extension on slwiki. I suggest you either file a bug in bugzilla:, get on IRC #wikimedia-tech connect, or contact Duesentrieb (email). — This, that and the other (talk) 11:10, 9 May 2013 (UTC)
Ok, thank you. --Eleassar my talk 11:55, 9 May 2013 (UTC)
A null edit to MediaWiki:Gadgets-definition on slwiki will fix the problem. See also bugzilla:37228. Issue has been known about for a while, and was caused due to the partial outage that occured yesterday. Reedy (talk) 12:27, 9 May 2013 (UTC)
It has worked. Thank you. --Eleassar my talk 12:47, 9 May 2013 (UTC)

Preferred format for pronunciations

I'm doing Commons:Commons:Bots/Requests/Smallbot_9 where ~6.5k pronunciations will be uploaded to the commons. What is the preferred format for pronunciations: .ogg or .webm?Smallman12q (talk) 17:46, 9 May 2013 (UTC)

.ogg --Edgars2007 (talk/contribs) 17:49, 9 May 2013 (UTC)

User questioning if they've been hacked

Please advise if I should report this to anyone. On May 6, 2013, I made This revert, and posted a standard Warning template on the IP address talk page. Today, I received Spurious posting? inquiry on my talk page. I think the IP is used by many users, but thought I should mention this if there's anything that needs to be addressed. — Maile (talk) 18:17, 9 May 2013 (UTC)

It looks as if the user just didn’t notice that she is logged out.—Emil J. 18:28, 9 May 2013 (UTC)
That would be my guess. Besides which, the user doesn't seem to know exactly what their user account name is. — Maile (talk) 18:30, 9 May 2013 (UTC)

Relinking Google for SSL https

List of pages: wp:Google https links. -Wikid77 14:21, 8 May 2013 (UTC)
Note: #Confirmed stats.grok pageviews omit https. -Wikid77 10:38, 10 May 2013 (UTC)

There are still articles linked in Google with secure-server SSL prefix "https:" (rather than "http:"), and the pageviews in stats.grok.se have been down to 75% lower for some of those pages. To unlink and relink article "Parabola" now I have, step 1, renamed it as typical "Parabola (mathematics)" (which Google has indexed with "http:" prefix), while "Parabola" remains a redirect. The plan is to rename "Parabola (mathematics)" back again, and see if that resets and relinks the original title "Parabola" as simple http protocol. Then we can check the pageviews to see if they rise back near 2,500 pageviews/day from the recent 600/day. Questions:

  • Should we wait a whole week before renaming back to "Parabola" to relink?
  • What has caused some articles to relink as secure https in Google?
  • Even if relinked as http protocol, will Google later return to https links?

If we can get confirmation, where "Parabola" can be relinked and return to nearly 4x times higher pageviews, then I would conclude that Google's secure-server https links are hindering users from reading pages. Meanwhile, I am considering to rename back within a few hours, unless someone knows it typically takes several days to reset an https link in Google. -Wikid77 (talk) 11:05, 25 April 2013 (UTC)

What the... ? I've undone this move (which broke the hatnote, by the way): we do not randomly move pages around based on our own personal theories as to how Google works, and I can't even comprehend the problem statement. If you want to experiment, you've got a sandbox to do so. Chris Cunningham (user:thumperward) (talk) 12:20, 25 April 2013 (UTC)
Other editors have been discussing Google's https article-links for some weeks now, but it is a very complex problem which will be difficult for many people to comprehend without weeks of study. Fortunately, this is a wiki, and there are other people to help handle complex issues. -Wikid77 13:22, 25 April 2013 (UTC)
  • Double-renaming did not relink article as http protocol: After a period of 2 hours, the article was re-renamed from new http-protocol title "Parabola (mathematics)" back to "Parabola" but that did not immediately reset the Google https link as being http protocol, as would be expected if the old name were deleted, then the rename performed later. -Wikid77 13:22, 25 April 2013 (UTC)
    • File a bugreport in bugzilla with wmf site-requests. They have some contacts in Google. Will probably take long, but it can help. I doubt however that it really does matter a lot in traffic if Google found it primarily by https or by http. I wonder however if perhaps there is an issue with non-canonical duplicates of this page somewhere, which might affect it's page rank. If there are canonical issues, then that could also explain why google becomes confused and moves it to https as primary protocol. —TheDJ (talk • contribs) 14:02, 25 April 2013 (UTC)
I would be interested in knowing why we think (or more specificly how it happens) that google pointing people to https has a negative correlation with page views? Bawolff (talk) 16:31, 25 April 2013 (UTC)
  • Several major articles with Google https links have lower pageviews: There is very strong evidence of articles with Google https links having relatively low pageviews in April 2013:
Because the term "parabola" is 5x more common in Google hits, the pageviews should be higher, not 50% lower, than for the rare term "hyperbola". Similarly, the article "Gone with the Wind (film)" (as an American cultural icon from 1939) should have higher pageviews than "Lawrence of Arabia (film)" (1962), rather than 33% lower. In general, highly popular articles should have much higher pageviews, compared to similar but less-popular topics. The renaming of page "Parabola" as "Parabola (mathematics)" was intended to delink "Parabola" in Google, to allow deletion of the redirect, and then re-renaming back to "Parabola". However, the deletion might have required a multi-day period with no redirect named "parabola" (as wp:SALTed to prevent re-creation), and that would likely have caused more debates. All of this is compounded by re-indexing a page in Google without revealing the complex trade secrets of how Google's PageRank algorithm operates. Hence, the re-indexing of https-link pages in Google might be better if handled as a discrete wp:OFFICE action, without a lot of public discussion about Google's company-proprietary PageRank methods. -Wikid77 (talk) 03:50, 27 April 2013 (UTC)
the article "Gone with the Wind (film)" (as an American cultural icon from 1939) should have higher pageviews than "Lawrence of Arabia (film)" (1962), rather than 33% lower. Sorry man, but that's completely bogus. — Scott • talk 12:26, 27 April 2013 (UTC)
May be so many people talking about it is an indication few people need to check out the article on parabola, but many need to check out the term hyperbola to find out what it is. Nil Einne (talk) 09:38, 1 May 2013 (UTC)
When many people talk about a topic, the article pageviews usually run higher, not 4x lower. Compare the higher pageviews for "Parabola" in prior months: prior year stats-201204 (1,927/day), prior month stats-201303 (2,490/day), versus April 2013 stats-201304 (620/day). -Wikid77 13:04, 6 May 2013 (UTC)

Now Hyperbola https drops pageviews 66%

In March, article "Parabola" had an https-link in Google, to drop pageviews 75%, while "Hyperbola" remained with "http:" link and held unchanged pageview levels. However, on 27 April 2013, the pageviews of "Hyperbola" dropped an average 66% each day, and now it is linked in Google by https secure-server protocol (just like Parabola). That is clear evidence that the https-links in Google are deterring people from reading those article pages, probably due to browsers which ask multiple security certificate alerts before the page can be viewed. The pageview stats from April 2013 averaged a 75% drop in pageviews for "Parabola" while the stats from May 2013 show a 66% drop in "Hyperbola" pageviews, when comparing:

There were no edits to Hyperbola (edit | talk | history | protect | delete | links | watch | logs | views) between April 14-29, so the switch from "http:" prefix, to https link circa 27 April 2013, is not directly tied to an edit during the 12 prior days. -Wikid77 13:04, 6 May, 05:42, 7 May 2013 (UTC)

I'm just now following this discussion about the https pageview drop. How do we know we are deterring human views instead of perhaps eliminating a large number of automated views from unknown sources? In our work on the WP:TOP25 charts, we have learned that certain articles have high ongoing viewcounts that do not appear to be caused by human views, e.g., Cat anatomy - it is regularly among the most viewed weekly articles in the raw stats produced at WP:5000, but its far too popular to be caused by human views, so we have excluded it from the WP:TOP25 chart. I am interested to know if there is evidence (anecdotal or otherwise) that we are deterring human views.--Milowent • hasspoken 14:32, 6 May 2013 (UTC)
It's all my friends who keep looking at Cat anatomy. Quite a turn-on! Thincat (talk) 14:51, 6 May 2013 (UTC)
  • Lowered views of GWTW film poster and lower weekends indicate human viewers: Although it is an interesting possibility that 3,000 bots (or automated views) were reading "Gone with the Wind (film)" (GWTW) from Google every day, and have stopped due to the Google https-prefix link, the related 33%-reduced pageviews of the film poster strongly indicate the reduction is with human viewers. While pageviews of the GWTW film article have fallen over 62% per day, from average 4,900 in February/March to 1880/day in April/May, the pageviews of the GWTW film poster have also fallen, meanwhile, 33% from 112 to 75 pageviews per day (see: GWTW poster pageviews-201303, 201304). So, even if 3,000 bots per day were formerly reading the film article, I do not believe those bots were viewing the film-poster description page as 33% of prior pageviews. Instead, the reduced readers are humans, also inhibited to view the poster less (when not seeing the film article).
    Then, in comparing weekend pageviews, the article "Parabola" maintained its same 2-to-1, weekday-versus-weekend pageview ratio, when the pageviews dropped from range 3,150-1,650 on Sundays in March 2013, to 780-400 on Sundays in April 2013 (see: pageviews-201303, 201304). It is unlikely that automated pageviews would "take the weekend off" at the same rate as human viewers. Instead, a broad sample of human readers would be as likely to have reduced viewing on weekdays and lower weekends, at the same proportional rates, when all pageviews dropped over 60% lower. For those reasons, I strongly believe the reduced pageviews represent thousands of human readers who do not view pages, as often, with secure-server, https-prefix links. -Wikid77 (talk) 05:42, 7 May 2013 (UTC)
  • Now 300 major articles have Google https: I created "wp:Google https links" as an essay/list of Wikipedia pages with Google "https:" protocol links. The results show more than 300 major articles now requiring secure-server access if clicked from Google Search. Perhaps the https links are related to fixes on the mobile website, where pages, with domain "en.m.wikipedia.org" were set to link as "canonical" but with https prefix to enwiki. In many cases, the daily pageviews have dropped nearly 60%-75% during March/April 2013. The https links include many common terms and major articles in various fields of study:
As noted, over 300 of the articles cover major topics in each field of study. Although many users can still gain access to pages by "https:" protocol (or retype as typical "http:" prefix), the reduced pageviews, for each major article, have skewed the measurements of reader interest in each topic, giving the false impression that those major articles no longer have a strong base of viewers. Several major articles even give the illusion of leaving the Top 1,000 most-viewed ("Cancer" or "Oxygen" or "DNA" in March), or "Nikola Tesla" or "Mark Twain" or "Shakira" or "Lady Gaga" in late April 2013, as if their daily pageviews were actually below 6,200 per day, rather than 7,000-12,000 or higher. -Wikid77 (talk) 14:21, 8 May 2013 (UTC)

Page view stats declining from 22 April

See: "wp:Village_pump_(technical)/Archive_110#Sudden drop in pageviews" and
see: "wp:Village_pump_(technical)#Relinking Google for SSL https". -Wikid77 17:59, 7 May 2013 (UTC)

Hi. I asked at VPM but no one could shed any light. The Page view stats at Depression (mood) began declining precipitously on about 22 April in a weird way. Other, but not all, articles have been similarly affected. Any Ideas? --Anthonyhcole (talk · contribs · email) 03:49, 1 May 2013 (UTC)

Possibly this is related to the fact that the mobile website was causing duplicate content in Google. bugzilla:35233 —TheDJ (talk • contribs) 19:14, 1 May 2013 (UTC)
I didn't understand that. I'd like to know if the actual traffic to this and other pages has dropped by two-thirds overnight, or of this is an artifact of our data-collection. If the number of visitors to some of our more important health pages such as Schizophrenia, Cancer and Depression has actually dropped to a third overnight, we should get to the bottom of it, don't you think? Does anyone else think this needs to be clarified?
It matters to me because I'm trying to get professional medical societies to review some of our medical articles, and that task will be made easier if I can show them reliable statistics.
If no one here knows what's going on, can you tell me who would/might know? --Anthonyhcole (talk · contribs · email) 06:11, 5 May 2013 (UTC)
  • Google https links to Schizophrenia, Cancer and Depression (mood): As discussed about other pages since early April 2013, those articles (such as "Depression (mood)") have also changed in Google to have secure-server, https-prefix links, rather than typical "http:" prefix, as happened to several other articles in March 2013 ("Parabola" or "List of best-selling books" etc.). Although developers think the https-protocol requests have been properly logged, for pageview counts, some people think the pageview counts are still not correct (as perhaps undercounting the https transactions in those log files), while other people think that https security certificate alerts, in some browsers (such as MSIE not Firefox), have deterred people from viewing those articles, once their browsers ask about the secure-server access, and hence think the 66%-lower pageviews indicate actual reduction in readers viewing those pages. The reduced pageviews are shown by both stats.grok.se and the German Wiki-tech displays of pageview counts (such as for one-month "&Zeitraum=1M"). -Wikid77 (talk) 17:59, 7 May 2013 (UTC)
Heya, this is Diederik from the Analytics Team @ WMF. We are looking into this issue and I will report back once I have a satisfactory explanation. Drdee (talk) 20:29, 9 May 2013 (UTC)
Thanks, I have confirmed the https pages are omitted by stats.grok (see below). -Wikid77 10:38, 10 May 2013 (UTC)
Hi,
As promised, I would come back with an explatation regarding the pageview drop for https traffic. As mentioned before, we turned off the https/ip6 webrequest logging stream to webstatscollector back in March because we inaccurately concluded that we were double counting those pageviews. But in fact, by switching of that stream, we stopped counting of all https/ip6 traffic. Our apologies for this mistake.
We took the following steps to correct the situation:
1) As of May 14, 18:44 we re-enabled the https/ip6 stream to webstatscollector (see https://wikitech.wikimedia.org/wiki/Server_admin_log). Within the next hour or two, the pageview counts for articles that Google has indexed using the https protocol, should rebound to similar levels as they were before we switched off this stream.
2) One of the reasons we switched of this stream, was that the https/ip6 stream has a non-functional implementation of adding sequence numbers. Because these sequence numbers are off, our packetloss monitoring is incorrect. We fixed this situation by submitting patchset: https://gerrit.wikimedia.org/r/#/c/63220/
Please let me know if there are still lower than expected pageview counts in a couple of hours from now. Drdee (talk) 18:59, 14 May 2013 (UTC)
  • Thanks for fixing the https/ip6 stream to webstatscollector: That was a fast fix, as I had expected to wait another 2 weeks to fit some update schedule. I can appreciate trying to handle the other packetloss problems at the same time, and the https pageviews would not have mattered so much if there were not other software problems which caused the http/https protocols to store 3 separate copies of pages/images in the Google Search index. Meanwhile, we had admins being rude, even snarky, about attempts re-index Google around the https-related bugs. So, not only were you quick to fix the stream to webstatscollector, you were also very polite about it at the same time, as they say, "a gentleman and a scholar" both. Thanks again. -Wikid77 (talk) 05:21, 15 May 2013 (UTC)

Confirmed stats.grok pageviews omit https

As feared, due to some major articles showing 75% drop in pageviews with Google https-protocol, I have confirmed the stats.grok.se omits the https-protocol pageviews. In tests run during 12 hours on 9 May 2013, over 60 https-prefix pageviews of a Space Shuttle mission-patch image file were ignored, while "http:" views were counted:

Both mission-patch images ("http" for STS-98 and "https" for STS-99) were viewed within minutes of each other, repeatedly over 65 times, during the day-long testing of pageviews. The stats.grok.se website has counted only the "http" pageviews and omitted all https-protocol pageviews. Based on prior pageviews of major articles (see list: wp:Google https links), it is suspected that other pageview tools also omit the https-protocol page requests in the counts. -Wikid77 10:38, 10 May 2013 (UTC)

Huh

Why do people care about page views? I thought we were here to write an encyclopedia. — Scott • talk 17:37, 11 May 2013 (UTC)

  • Comparing pageview counts helps to prioritize which articles to revise first: Although it would be great if all articles could be updated instantly, the reality, after more than 11 years, is that many major topic areas of Wikipedia are still maintained, or expanded, by "skeleton crews" of a relatively few people who cannot update all articles fast enough. Hence, by comparing pageview counts, then the editors can see which articles are read almost to the minute, versus some articles read only a few times per week. By updating the frequently-read pages sooner, and waiting to update the less-read pages, then even a handful of people can provide current, or recent, data at almost "magical" levels of response. So, when a news event occurs, or a scientific expedition publishes a report, then editors can use pageview counts to see which articles to update sooner. For example, with the "Costa Concordia disaster" in Italy, the pageviews revealed how, on some days, over 2x more readers were viewing the ship article ("Costa Concordia") rather than the "~disaster" subarticle, and so the ship article became a priority in posting some summarized data, as read by more people than the subarticle. Similarly, the pageview counts can reveal when a crime suspect's article is read many times more often than the original crime-event article, and so effort can be prioritized to update the suspect's article sooner, for summarized updates, rather than divert hours to update the crime-event article, while also writing or updating other articles in a timely manner. As a rule, "If it aint read often, then update other pages first". Eventually, some editors can become quite adept at prioritizing which pages to update sooner, and add crucial information, and allow more free time outside Wikipedia. It can be quite a relief when realizing some "important" articles are just not read enough, or templates used enough, to update today, or even this week. Relax, do something else, and reconsider later. It can wait. -Wikid77 (talk) 23:31, 11 May 2013 (UTC)
Thanks for the detailed reply. I work for the long term, so this approach is foreign to me. — Scott • talk 12:32, 12 May 2013 (UTC)

Internet Explorer

Tracked in Phabricator
Task T42998

Can anyone verify that IE is actually prompting users when visiting the https version of Wikipedia, and if so, what the exact warnings are? I'm unable to reproduce this using a variety of different settings. — RockMFR 01:56, 13 May 2013 (UTC)

Verified that they do exist, uploading and posting screenie with how I got it now. Tazerdadog (talk) 03:27, 14 May 2013 (UTC)

Scary message is here:

I got this by literally typing in the address shown in the address bar of the screenshot. (https://www.wikipedia.com/Hyperbola) Note the .com, this was an accidental oversight, but wikipedia is a .org site. I can provide more details, but I don't know where to look... Tazerdadog (talk) 03:41, 14 May 2013 (UTC)

That was caused by typing in .com instead of .org. Wikipedia's security certificate is only valid for the .org domain, so an attempt to access the .com address through HTTPS will always return a security certificate warning. Firefox gives me a similar warning if I click your link. Solution: type in .org instead. jcgoble3 (talk) 03:45, 14 May 2013 (UTC)
Ok, it fixes it for me if that change is made, so that is almost certainly not the problem. Tazerdadog (talk) 03:52, 14 May 2013 (UTC)
This is a known issue with the wikipedia.com domain (which only does redirects btw). I linked the bug tracking issue. —TheDJ (talk • contribs) 06:15, 14 May 2013 (UTC)
Some people assume that all internet URLs end with ".com", possibly the same ones that assume that they all begin with "www." Just last week, I had two different people complaining that they couldn't get to the desired website - one was inserting "www." where none existed, and the other couldn't believe that ".gov.uk" was a valid TLD. --Redrose64 (talk) 12:31, 14 May 2013 (UTC)

Talk to Google

I believe his is altogether the wrong way of going around things. We should ask Google to have a facility to refer to the pages on the domain using http: always like they have the facility to always refer to them with www. or not according to the web owners preference. This would get rid of anything like this and probably help people elsewhere too. Sites can always use canonical for ones which don't follow the standard. I think our messing trying to flush the caches by renaming is a waste of our time.

Thinking about it more Google would really like such a facility I believe as it would improve their statistics. They would probably also like the option of sites saying they can support https even though they marked everything as normally http so logged in users could have an option to automatically use https as often as possible when using google. Dmcq (talk) 14:15, 14 May 2013 (UTC)

Did I read correctly above that the mobile views were accessing articles with canonical set to https urls? What on earth is the sense in that? Dmcq (talk) 14:50, 14 May 2013 (UTC)

Anyway I do support having rel=canonical on all our pages to get the domain and http right whatever about being able to tell Google about the general situation. Might even catch out some of the mirrors before they figure out they should change that when copying Wikipedia :) Dmcq (talk) 16:01, 14 May 2013 (UTC)

In fact we should probably use HTTP headers instead of sticking the link into the head of the html. This will ensure even the images get a canonical url. Pity this won't catch out the mirrors but that's life. Dmcq (talk) 16:18, 14 May 2013 (UTC) Dmcq (talk) 16:18, 14 May 2013 (UTC)

CAPTCHA and .js subpages

I logged in to User:IPLRecordsUpdateBot (the bot which I will operate) in order to create a subpage with some of its source code (which ends in .js, and such pages can only be edited by the user itself). On saving it I was prompted to enter a CAPTCHA for using an external link, but in .js subpages there are no external links. Why was I prompted to enter a CAPTCHA?

Possible reasons could be:

  • The text contains something like <a href="..., which may have been detected as an external link, but a tags are currently escaped by MediaWiki.
  • MediaWiki may have something to detect JavaScript which inserts external links into pages, and this one does insert links, but not anywhere on Wikipedia.
  • The square brackets used in regular expressions (e.g. /[a-zA-Z0-9]/) or for accessing/creating arrays (e.g. var a = [ 1, 2, 3]; a[1] = 'foo';) may have been taken as external links.

Similar reasons may apply for .css subpages as well. jfd34 (talk) 17:03, 6 May 2013 (UTC)

Although wikitext isn't rendered as such on js and css pages, the page is still parsed as if it were in order to pick up categories, wikilinks (for Special:WhatLinksHere), and so on. Which also means that ConfirmEdit picks up on any external links being added. ConfirmEdit can also look for certain other things, among which is the "<a href" that it probably saw in your script. Anomie⚔ 20:53, 6 May 2013 (UTC)
I don't think "<a href" has anything to do with it. If you save or preview the content of User:IPLRecordsUpdateBot/Source/IPLRecordsUpdateBot UI.js in a normal (not .js) pagename then this line produces an external link as seen here:
statusMsg.innerHTML = statusMsg.innerHTML.replace(/Committing edit\.\.\./, 'Edit successful (<a href="https://en.wikipedia.org/enwiki/w/index.php?diff=' + revisionIDs[2] + '&oldid=' + revisionIDs[1] + '" target="_blank">diff</a>)');
By the way, I was surprised to see that diff going to the latest Main page edit. https://en.wikipedia.org/enwiki/w/index.php?diff=0 goes to the same edit so a missing number is apparently taken as a 0. https://en.wikipedia.org/enwiki/w/index.php?diff=1 has a more expected result 26 January 2002. PrimeHunter (talk) 23:09, 6 May 2013 (UTC)
"External" links to other WMF sites are whitelisted for ConfirmEdit's captchas. Check out the settings of $wgCaptchaWhitelist and $wgCaptchaRegexes in CommonSettings.php. Anomie⚔ 10:56, 10 May 2013 (UTC)

British English / American English converter?

As many people have already seen, the difference of word/spelling variation between British and American English (mainly) has been an issue. I've seen rejected proposals of trying to establish a new "American English" wikipedia. Then I thought, why not learn from the Chinese Wikipedia? You can convert articles to Mainland Simplified Chinese, Hong Kong Traditional Chinese, Macau TC, Singaporean-Malaysian SC and Taiwan TC, whenever you like. They are only different versions of the same article, but not separated wikis. The method to do so is to define what words to change when you alter the version. For example, for an article of football/soccer, you can define which word to use in different versions. Here is an example of the code, imitating the Chinese Wikipedia:

{{noteTA
|T=en-am:soccer; en-gb:football;
|1=en-am:soccer; en-gb:football;
}}
"en-am" would be American English, while "en-gb" would be British English. T means the title and 1 means the first word to define its variety in the article.

What do you think? I'm not sure if anyone have suggested before but please express your views. -- Zamoeux (talk) 12:45, 9 May 2013 (UTC)

To be frank I think resources can be put to better use. Relatively speaking the differences between AmEng, BrEng (and let's not forget SAEng, AusEng and NZEng) are minimal compared to the differences between the various versions of Chinese, at least as I understand them from my colleagues in those Chinese-speaking countries.--ukexpat (talk) 16:16, 9 May 2013 (UTC)
Since Cantonese is my native language, I knew the variations of "Chinese" quite well. It's mostly with the Traditional and Simplified characters, some word variation and translations. Maybe you're right with the difference comparison. But I think the main issue would be the significant vocabulary and spelling difference, which can be confusing for non-native speakers. I know there is a Simple English Wikipedia but I don't think it's a waste to do so. It doesn't uses a lot of resources since a list of universal word conversion list which could be used by all articles. -- Zamoeux (talk) 16:50, 9 May 2013 (UTC)
So your 'universal word conversion list' would translate any occurrence of the word 'football' in a British-English article into 'soccer' in an American English version? That simply won't work. Think what would happen with "The boys were kicking a football around in the park...". To 'translate' one variety of English to another you have to understand it. Look at the mess machine translation usually makes, and ask yourself if that would be acceptable in Wikipedia articles. AndyTheGrump (talk) 17:03, 9 May 2013 (UTC)
Yep. Imagine a British royal visiting the U.S. and attending the Superbowl, and her article says it was a soccer game. There are so many potential exceptions that we'd be perpetually running around unconverting the conversions. Rivertorch (talk) 17:36, 9 May 2013 (UTC)
And it is easy to come up with many other scenarios where this would make things less clear. I can't speak to how well it works in Chinese, but machine translation of any kind is not a good way to generate coherent content in English. Beeblebrox (talk) 18:44, 9 May 2013 (UTC)
The thing is that Chinese simply uses different writing styles; it's possible to map simplified characters onto traditional characters. We could use this proposal to cause "centre" to appear as "center" to US English readers, and it would be a benefit. The reason we shouldn't adopt it is that it would take a ton of work for very few benefits. Nyttend (talk) 23:08, 9 May 2013 (UTC)
Yes, it could work for simple spelling difference such as color/colour and -ize/-ise. But it would not where the words are completely different, such as soccer/football, pants/trousers.--ukexpat (talk) 12:41, 10 May 2013 (UTC)
And it would work even less well when the same word has different meanings, eg table/table. --Carnildo (talk) 00:37, 11 May 2013 (UTC)
Yeah. My dog pants when I take him for a walk on a warm day. HiLo48 (talk) 01:29, 11 May 2013 (UTC)
And to add even more work to the template/functionality, you would have to consider Canadian English, which uses rules from both. We would standardize the colour of pennants flying from the walls of the shopping centre. Even in simple "translation", everything would have to be done in triplicate, at least. Resolute 00:42, 11 May 2013 (UTC)

Then there is Canoe English. I make up new words and spellings. USA and UK editors think they are correct on the other side of the pond and Canadian editors and me just giggle to themselves at the inside joke.--Canoe1967 (talk) 01:13, 11 May 2013 (UTC)

You are so vaverlocious! Just assume that it's a word here.  :-) North8000 (talk) 01:49, 11 May 2013 (UTC)
There was an interesting discussion on a cricket page recently where an American editor insisted that a description of cricket could be created for an American audience familiar with baseball, using the American concepts of attack/offence(/offense?) and defence. (Or should that be defense?) Anyone who knows both games will know that just ain't gunna work. In baseball the batters do the attacking. In cricket the bowlers make up the attack, and the batsmen both attack and defend. HiLo48 (talk) 01:29, 11 May 2013 (UTC)
I have little patience for people who willfully choose to be ignorant, so I am rather glad I didn't see that discussion.  ;) Resolute 02:00, 11 May 2013 (UTC)
Tomato/tomato --Redrose64 (talk) 13:36, 11 May 2013 (UTC)
Is there any dialect conversion tool other than those that do so for comedic effect? There are several language converters all of which have various issues. If someone has not developed a dialect converter, then I really do not expect to do so by use of templates. And this needs to be added to perennial, as it keeps coming up. --  Gadget850 talk 14:01, 11 May 2013 (UTC)
User:Ohconfucius/EngvarB. πr2 (t • c) 16:52, 11 May 2013 (UTC)

Hello! As the guy from Slovene Wikipedia few lines above said "this page seems to be the best place to get an answer" :) We at Latvian Wikipedia got our edit link appearance (similar to current one, but with small letters) written in the common.js page (after the row "//Kods rediģēšanas saišu novietošanai uzreiz aiz virsraksta"), but now after the global change of them we have the global version of them. And I think that almost everyone @lv wiki would be glad, if the old (Latvian Wikipedia style) would be used. Any suggestions, what to write in some js/css page? --Edgars2007 (talk/contribs) 16:01, 9 May 2013 (UTC)

If I were you, I would delete the old "Kods rediģēšanas ..." section of code from common.js, and go and add the following code to common.css:
.mw-editsection { font-size: x-small; }
If that is too small, try using font-size: small instead. — This, that and the other (talk) 06:23, 10 May 2013 (UTC)
For the record, the best place to ask this question would be the discussion of the meta page: meta:Talk:Change to section edit links. Matma Rex talk 15:25, 11 May 2013 (UTC)

Is the Job Queue out of whack again?

On :00.48 (UTC) on May 8, I linked 4 existing articles to a Template, and have been waiting for "What Links Here" on those 4 articles to populate with the other links on the template, as would be normal. However, as I write this, the only additions that show up on their "What Links Here" are the 4 added articles and the template itself, not the other links on the template. It's been 46 hours. I checked the Job Queue, and it doesn't seem backlogged. However, something else looks odd about it. Those exact same "jobs" figures have been there since two days ago. If I repeatedly refresh my browser, the numbers 5,434 and 8,752 show up as "jobs=", plus a couple of other numbers sometimes. But 5,434 and 8,752 have been showing up for two days. Is there something wrong with the Job Queue? — Maile (talk) 22:40, 9 May 2013 (UTC)

The graph at http://ganglia.wikimedia.org/latest/graph_all_periods.php?c=Miscellaneous%20pmtpa&h=www.wikimedia.org&r=hour&z=default&jr=&js=&st=1368034432&v=1516493&m=Global_JobQueue_length&z=large looks now fine to me, but there was an outage on Wednesday, 13:30 - 14:00 UTC, due to a memcached server going offline. Would be good to know if this is still a problem for recent changes. --AKlapper (WMF) (talk) 10:57, 10 May 2013 (UTC)
Yeah, I've still got the same issue, and I can't figure it out. But let me elaborate. See above Template I mentioned. If you click on any blue Wikipedia internal link that is listed prior to 2012, and go to "What Links Here", all the other links on that template - including the 2012 additions - have populated on the individual "What Links Here". However, the 2012 links were added May 8, 2013. If you click on any of those links, the template itself shows up under "What Links Here", as do the other 2012 links - but none of the pre-2012 links have populated under "What Links Here" for the individual 2012 articles. It's kind of strange. — Maile (talk) 11:22, 10 May 2013 (UTC)
  • WhatLinksHere can take 5 days to update after articles show new template: Even though the other 40 articles display the new revision of Template:Hawaiian Music Hall of Fame, the cross-wikilinks are not yet updated between all of them. In particular, the navbox-link article "Alfred Apaka" shows the new-revision template, but it is not yet indexed in WhatLinksHere for the new navbox-link articles. However, I ran a wp:NULLEDIT of two articles, "Benny Kalama" and "Ray Kinney" to force the wikilinks, and now they are listed in Special:WhatLinksHere/Hawaii_Ponoi (which should have 45 links when fully indexed). If not re-indexed by 14 May (5 days), then running 30 null-edits for the other 30 articles in the navbox would re-index the cross-wikilinks. -Wikid77 (talk) 15:33, 10 May 2013 (UTC)
Thanks for your help. — Maile (talk) 16:00, 10 May 2013 (UTC)

Delayed update on Special:WhatLinksHere

Special:WhatLinksHere/A Raisin in the Sun (film) and Special:WhatLinksHere/Titans (TV series) still list articles that have no links to specific targets after I changed links in templates and files. I wonder if there is delay on them. --George Ho (talk) 04:42, 10 May 2013 (UTC)

This might be related to #Is the Job Queue out of whack again? above. The Anonymouse (talk | contribs) 04:49, 10 May 2013 (UTC)

Talk page formatting anomaly

Could someone less clumsy with wikimarkup than I am please take a look at Talk:Kurdish people, where the formatting of the last two sections is all screwed up? I've tried various fixes, but none of them work, if Preview is to be believed. Rivertorch (talk) 22:47, 9 May 2013 (UTC)

That is strange. I can't fix it, either. It looks fine in "Preview", but when I "Save page", the text scrawls in tiny font, in a straight line off the right-hand side of the page. — Maile (talk) 22:55, 9 May 2013 (UTC)
It's just the same for me, except that I couldn't even fix it in Preview. I probably could find the issue if I had an hour or so to spend going through it line by line, but I don't. :( Maybe tomorrow, if no one else has any success in the meantime. Thanks for trying, anyway! Rivertorch (talk) 23:13, 9 May 2013 (UTC)
I got it! The problem was caused by the section above those two. The editor who posted there had some coding that I think was copied out of an Infobox, and there were no closing brackets, so the coding carried right on down the rest of the page. — Maile (talk) 23:24, 9 May 2013 (UTC)
Nice job! Thank you. Rivertorch (talk) 06:08, 10 May 2013 (UTC)
There was no need for closing braces, since the comment didn't include opening braces. The problem was actually unclosed <div> and <small> tags. Maile66's fix wrapped the whole thing in a table; this worked because tags opened in a table don't affect content outside the table. I've removed this fix and added the missing </div> and </small>. – PartTimeGnome (talk | contribs) 22:32, 10 May 2013 (UTC)
Interesting. I ran a search and counted various opening and closing tags, but I must have missed that one. All's well that ends well. Rivertorch (talk) 20:18, 11 May 2013 (UTC)

Watchlist past a month?

I need to see a few things on my watchlist that are a few days over a month old. Does anyone here know how I can do that or does anyone here have the power to see that?

Checking everything on my watchlist is out of the question because there are over 400 articles on my watchlist. --TheShadowCrow (talk) 23:09, 9 May 2013 (UTC)

You can't. Maybe break up your watchlist into something more manageable? Killiondude (talk) 04:46, 10 May 2013 (UTC)
The watchlist is limited by the recentchanges database table which only stores up to 1 month. Legoktm (talk) 04:48, 10 May 2013 (UTC)
You can view an alphabetical list of all pages on your watchlist that also includes their last modified dates via m.wikipedia.org (watchlist linked). Theopolisme (talk) 14:24, 11 May 2013 (UTC)

Other pageview tools

I want to test https-protocol pageview counts with other tools (see above: "#Confirmed stats.grok pageviews omit https"). Does anyone remember the other pageview tools besides stats.grok.se? -Wikid77 10:47, 10 May 2013 (UTC)

Don't know if this is the grok source, but there's http://dumps.wikimedia.org/other/pagecounts-raw/ — Maile (talk) 11:38, 10 May 2013 (UTC)

Wayback Machine snapshots

I draft an article in my userspace where I have some citations using citation templates. I filled in the archiveurl parameters with Wayback Machine urls as the parameters. The archive links on Wayback have the form http://web.archive.org/liveweb/http://www.finanznachrichten.de/. Does the liveweb in the url mean that those are not snapshots on Internet Archive servers but just redirects to the live resource on the web? Does WbM actually have snapshots of those urls or not? See here for my draft. -- Toshio Yamaguchi 13:13, 10 May 2013 (UTC)

Smallman12q (talk) 21:28, 10 May 2013 (UTC)

File replacement

How long does it take for a file to be updated? I uploaded a new version of File:ParisMontage1.jpg about an hour ago, but it still shows the old version in Paris. I have tried purging all the caches etc.--Gilderien Chat|List of good deeds 19:28, 10 May 2013 (UTC)

I can't easily see the difference between the current image and the one before. One of those two shows for me when I load the article. Secretlondon (talk) 19:32, 10 May 2013 (UTC)
The new one has a different, lighter top image, but it still doesn't load for me. It also shows the old one in the file page history table.--Gilderien Chat|List of good deeds 20:23, 10 May 2013 (UTC)
The previous version, timed 17:36 UTC is bit-for-bit identical to the current one, timed 17:38 UTC. --Redrose64 (talk) 20:31, 10 May 2013 (UTC)
You need to give a source for the top skyline image, by the way. Secretlondon (talk) 21:50, 10 May 2013 (UTC)
Yes, the file thumbnail didn't update, so I thought I had re-uploaded the old version. I think I have provided a source on commons, I just cropped the image shown at the bottom of the data.--Gilderien Chat|List of good deeds 22:01, 10 May 2013 (UTC)

Educational assignment template

Could somebody who's proficient at template syntax take a look at {{Educational assignment}}? The template has a problem with future/past tense depending on when the assignment ends. A discussion about this was started a year ago but it still doesn't work properly. The template somewhat unfortunately uses either "date" exclusive or "day", "month", "year" as parameters. It'd be good too if there's a test that gives an "incorrect usage" message if both are used. Jason Quinn (talk) 20:17, 10 May 2013 (UTC)

Show parent categories for articles

Right now, the tree structure of categories hides the fact that articles are also categorized under the parents of the categories they are in. This makes for confusion as shown by Category talk:American novelists. If we showed the parent categories for pages, this would prevent this confusion. Also this would fix the problem of people constantly adding parent categories to pages that are already under a child category. Transcendence (talk) 01:13, 11 May 2013 (UTC)

This would also cause issues for parent categories that are not content categories. It would also result in oddities such as AMBO pipeline being shown as being in Category:Seas of the Atlantic Ocean. Anomie⚔ 14:46, 11 May 2013 (UTC)
A solution would be to distinguish "this is an item in a cat" from "this is a subcat of a cat". Another solution is to scrap all the subsubsubcats and intersection-cats, and instead use lots of cats and then use a WP:CatScan-like tool to find the intersections one wants. DMacks (talk) 07:12, 12 May 2013 (UTC)

Category suggestions when using HotCat are gone

Resolved

Up until recently, when I added a category to an article using the + sign at the bottom of an article with HotCat, when entering something into the text box I would receive category suggestions. Has this functionality been removed? I no longer get suggestions when entering something into the field. -- Toshio Yamaguchi 09:31, 11 May 2013 (UTC)

There have been no recent changes in HotCat, so the problem must be somewhere else. Lupo 10:11, 11 May 2013 (UTC)
It works again. Thanks for the response. -- Toshio Yamaguchi 10:49, 11 May 2013 (UTC)

userspace page found by Google

I received an email in the last few days from Google Alerts telling me about http://en.wikipedia.org/wiki/User:Nick_Levinson/Eva_Moskowitz_former_article (referring to the current revision, which is indirectly represented by http://en.wikipedia.org/enwiki/w/index.php?title=User:Nick_Levinson/Eva_Moskowitz_former_article&oldid=554154449). That implies the page can be found in a Web search through Google by my name alone. In this case there was no harm but I don't think the visibility to an external search engine of a userspace page is your intention. Maybe something needs fixing or maybe it was just a fluke. Nick Levinson (talk) 16:50, 11 May 2013 (UTC)

Yep. That's what Google does. You can tell them not to do that by adding the magic word __NOINDEX__ to the page concerned; or, as seen top of User:Redrose64, you could add {{userpage|noindex=yes}} which does the same but wrapped in an explanatory box. --Redrose64 (talk) 19:27, 11 May 2013 (UTC)
(ec) User pages are not being excluded from indexing by default, but user talk pages are. — Edokter (talk) — 19:29, 11 May 2013 (UTC)

In case you are unaware, see meta:Change_to_section_edit_links. Section edit links will no longer appear floated on the right side of the page; instead they will be aligned left, after the section heading text.

This looks like a great change to improve the visibility of section edit links, and it has been proven to bring in more edits to page sections. Obviously it will raise the ire of some long-time editors, but we can always gadgetise the old CSS code if people want it that badly. — This, that and the other (talk) 11:38, 2 May 2013 (UTC)

There is a gadget "Move edit links next to the section headers" to move it as proposed, presumable that should be reversed when the change is implemented. Keith D (talk) 11:54, 2 May 2013 (UTC)
I had that option turned on. Wondered if there would be a conflict, and there doesn't appear to be, but for the sake of clean-up, it probably makes sense to remove it. --SPhilbrick(Talk) 13:20, 2 May 2013 (UTC)
This was "announced" at VPM (Wikipedia:VPM#.5Ben.5D Change to section edit links), but seriously, who reads VPM? Perhaps we need to change the page where we get our automated global messages. — This, that and the other (talk) 12:09, 2 May 2013 (UTC)
It says "Ideas to do this all the way to 2009 at least. It is often difficult to track which of several potential section edit links on the far right is associated with the correct section"; I remember how in 2009 we had a problem where a stack of box-type objects on the right (including images) could force the section edit links down the page, sometimes known as "bunching" (bugzilla:26449). I have seen as many as six section edit links bunched together; but that's not been a problem for almost two years now (mw:MediaWiki 1.17), so it seems as if we're been given a workaround for a problem which no longer exists. --Redrose64 (talk) 18:05, 2 May 2013 (UTC)
Those two issues are not really related. The bunching issue was a (comparatively) rare issue. This is basically about the ability of the human brain to travel and refocus from the left of your screen and find and later connect a widget all the way to the right of your window to this context at the left (guided by a horizontal line, but apparently that's only helping a bit). It's a rare vertical positioning problem vs a consistent and omnipresent horizontal positioning problem. —TheDJ (talk • contribs) 21:56, 2 May 2013 (UTC)

They've put the change live in the last half-hour or so. It can be fixed with this edit, but whether you do that or not, the edittop ("Add an [edit] link for the lead section of a page") feature is lost completely. --Redrose64 (talk) 18:33, 6 May 2013 (UTC)

Could you give instructions on how to do that, where to put it and so on in a slightly simpler form? I take it that that float right line gets added somewhere - but where? (I want my [edit]s where they're easy to hit quickly, not wandering around the page vaguely...) Peridon (talk) 18:46, 6 May 2013 (UTC)
Sure, just copy this line: span.mw-editsection { float:right; } and paste it into your common.css page. Writ Keeper ⚇♔ 18:49, 6 May 2013 (UTC)
Edittop works fine for me. However, the [edit] link is as large as the page title, which I don't like. Clarification: I'm using the Vector skin. Ian01 (talk) 00:06, 7 May 2013 (UTC)
I fixed it and I moved it to the right because I didn't like it being next to the title. Here's my code:
span.mw-editsection { font-size:small; } /* make edit links small */
the above is not necessary; see below
#firstHeading span.mw-editsection { float:right; } /* move edittop to the right */
Ian01 (talk) 00:49, 7 May 2013 (UTC)
Ian, the edittop link should be just as large as any other editsection link on the page. If it is in fact larger, then that's a bug and I'd like to see a screenshot. :) Matma Rex talk 13:52, 7 May 2013 (UTC)
Matma Rex, I disabled my CSS to take a screenshot, and it looks fine now. The brackets are still the same color as the title, though (title color being caused by the metadata gadget). Ian01 (talk) 21:42, 7 May 2013 (UTC)
(ec) Thanks. That's much easier than that diff. As I've commented further down the page, couldn't this have been done by a default tick in the box in Gadgets - Appearance so it would be easier to undo? I want those buttons where I can hit then quickly - I have no trouble going to the right hand side, but I do have trouble scanning across to find a wandering button. Looks neater over at the right, too. Peridon (talk) 18:57, 6 May 2013 (UTC)

The edittop feature is not lost; I have already personally submitted a {{editprotected}} request on its talk page, which has been as of right now completely ignored (MediaWiki talk:Gadget-edittop.js). There's no "they" here (in fact "they" have went as far as to fix your broken gadgets), it's your admins who are not helping. Matma Rex talk 19:00, 6 May 2013 (UTC)

Until it's fixed locally, you can add 
mw.loader.load( '//commons.wikimedia.org/enwiki/w/index.php?title=MediaWiki:Gadget-edittop.js&action=raw&ctype=text/javascript' );
to your .js file. The Anonymouse (talk | contribs) 19:02, 6 May 2013 (UTC)
Okay, thanks you two. Sorry to be so touchy. Ignatzmice•talk 19:04, 6 May 2013 (UTC)
I've actioned MediaWiki talk:Gadget-edittop.js#Fixes for m:Change to section edit links now, and yes, I was ignoring it - partly because it's javascript, and partly because of all the sh*t that I get when I involve myself in many {{editprotected}} requests. --Redrose64 (talk) 19:22, 6 May 2013 (UTC)

Just a heads up, I found that the right-click to edit sections option in Preferences>Editing is a good alternative, and you can edit section 0 by right-clicking the article title. The double-click to edit option seems to go to full page editing no matter where you double-click, whether it be on a section title or even somewhere random on the page (Firefox 19.0). The problem for me with edit links right next to the title is it makes reading the article more difficult as large links are scattered throughout. When they were on the right I didn't notice them as much. The right-click to edit option is even nicer, I wish I had tried it sooner. Cheers, — Bility (talk) 20:09, 6 May 2013 (UTC)

  • Comment Obviously I'm too late, but having the edit link on the right side made it predictable and easy for people who click edit links often. Now instead of knowing that I need to move the cursor to the right, first I have to visually identify the end of the section header, then click edit. It's kind of annoying. Oh well. --IP98 (talk) 11:36, 7 May 2013 (UTC)

I've just noticed that local description pages for Commons images now have section-edit links (e.g. File:BtCPicture 008.jpg), which I don't remember ever seeing before. Is this new, or am I forgetting? Seems like a great idea to me. Nyttend (talk) 02:47, 5 May 2013 (UTC)

This is new, a side-effect of meta:Change to section edit links. Possibly an unintended side-effect, since the page doesn't mention it. -- John of Reading (talk) 07:15, 5 May 2013 (UTC)
This is indeed unintended, but it looks like a positive change to me (that said, I'm looking into why they are shown now and why they weren't in the first place). The links are currently displaying a little funnily, but this should fix itself when the change is deployed here tomorrow. Matma Rex talk 12:06, 5 May 2013 (UTC)
My diagnosis is that there is nothing that would have prevented those section edit links from being shown. I guess that the change simply resulted in their being more noticeable, which is precisely what it was intended to accomplish. :) Matma Rex talk 12:24, 5 May 2013 (UTC)
Reading the Meta page, I'm confused, because I've noticed this very thing in action at de:wp for a long time; for example, de:National Historic Landmark has Auszug aus dem Verzeichnis [Bearbeiten] , Alabama [Bearbeiten] , Alaska [Bearbeiten] , etc., and they have for quite a while. Has it been implemented there already (calling into question the up-to-dateness of the Meta page), or do they do it some other way? Nyttend (talk) 20:02, 5 May 2013 (UTC)
Out of the top ten linked on http://wikipedia.org/, this has been already been implemented on German, French, Italian, Polish, and Japanese Wikipedias (and likely more; one I remember off the top of my head is the Farsi one) with ugly JavaScript hacks, and slightly different ones on each wiki. This will simply replace those with a clean native solution. Matma Rex talk 21:03, 5 May 2013 (UTC)

[edit] moved

I think this has happened before, but I can't remember how to stop it. The little [edit] button on every section has moved from the far right to just right of the section heading. This is annoying, and I'd like to put it back where it belongs. I've not been messing with preferences, or anything else. I've looked in there to see if I can find a remedy, but can't. I'm in Firefox 20.0.1, on XP Classic view and Monobook. Peridon (talk) 18:38, 6 May 2013 (UTC)

See "Section edit links are migrating westwards" above. Steven Walling (WMF) • talk 18:39, 6 May 2013 (UTC)
Thanks. Good to see there's a way round it up there, if I could understand it. Why couldn't there just be a default tick in the box already in prefs (found it) so those of us that are less technical could just untick it again? Or is that too simple a solution? Peridon (talk) 18:49, 6 May 2013 (UTC)
Assuming that you mean Preferences → Gadgets "MediaWiki:Gadget-lefteditlinks", that installs several dozen lines of javascript. If the same effect can be achieved in one line of CSS - specifically by adding 
span.mw-editsection { float:right; }
to Special:Mypage/common.css - I very much prefer the CSS method. --Redrose64 (talk) 19:40, 6 May 2013 (UTC)
Which worked very nicely, thank you. --  Gadget850 talk 19:52, 6 May 2013 (UTC)
For people who know coding - yes, it's easy. For someone who can look through a list of tick boxes and alter one that is clearly labelled, no, it isn't easier to use CSS (whatever that is...). Peridon (talk) 21:23, 6 May 2013 (UTC)
You literally just have to copy and paste, and click on three things: Copy the above code. Click Special:Mypage/common.css. Click to start the page. Paste the code in. Type an edit summary and click save. That's it. Also, about not knowing what CSS is… Ian01 (talk) 00:28, 7 May 2013 (UTC)

This his has been mentioned at WP:VPM a week ago, which is where en.wp has apparently decided to receive important global notifications, with a link to more info at Meta: m:Change to section edit links. Matma Rex talk 18:58, 6 May 2013 (UTC)

Thanks. I've commented there. Peridon (talk) 19:17, 6 May 2013 (UTC)
If you want your edit buttons back on the right side, put
span.mw-editsection { float:right; }

in your Special:MyPage/common.css file. Peridon (talk) 21:10, 6 May 2013 (UTC)

  • Put it back please. There's no reason at all given for this change, and it makes no sense at all. The edit link is lost where it is now, is much more difficult to find, and is creating a net negative user experience. Nobody complained about it being in a nice consistent place on each line before. Change for the sake of change is offensive. Risker (talk) 23:21, 6 May 2013 (UTC)
Standard response: We tested something different but sort of like it a long time ago with a completely different and very small group of users for a different purpose, and now we've decided to apply it everywhere without having done recent testing on users who actually use those tabs. You know as well as I do that all of the data from those tests was flawed. More importantly, it's so outdated given all the changes in the interim, that it is meaningless. Put it back please. Risker (talk) 23:41, 6 May 2013 (UTC)
Sorry, but I can't just "put it back". It's not my call. I'm just helping advertise the change, and it was actually made by a conglomeration of volunteers and staff, with the primary committer being a volunteer. Steven Walling (WMF) • talk 23:43, 6 May 2013 (UTC)
Local projects can undo the change with an edit to their global .css fine. MBisanz talk 23:49, 6 May 2013 (UTC)
Why not first do those changes on one of the smaller wikis, to see a better feedback before putting it live on one of the top 10 worldwide websites? I just checked other languages Wikipedia's. Still the orange bar, no echo, no moved edit link. (mind you, of the three I do like echo) Garion96 (talk) 23:51, 6 May 2013 (UTC)
It was done on smaller wikis first. That's how every bi-weekly MediaWiki deployment goes. Steven Walling (WMF) • talk 00:01, 7 May 2013 (UTC)
Ok, I checked some smaller wiki's but saw they didn't had the changes. Guess it was done on the other ones. Garion96 (talk) 00:30, 7 May 2013 (UTC)
Actually, the current deployment cycle shows that it goes Meta/test/test2 then non-wikipedia wikis, then English Wikipedia, and only after that is it other Wikipedias. Risker (talk) 01:36, 7 May 2013 (UTC)
That's exactly what I meant. General MediaWiki releases don't go on to English Wikipedia first. They're on other wikis for a week before they hit here. Steven Walling (WMF) • talk 01:50, 7 May 2013 (UTC)
Hmm. Still doesn't explain why Enwp goes before all the other wikipedias; that's counterintuitive. And we know there's a very serious push for this to change in the near future, so there'd only be 3 days between.[16] Risker (talk) 03:34, 7 May 2013 (UTC)

Getting back to my point about the extremely limited research that has gone into this decision, it appears this was based on the 2009 Usability and Experience study[17], which involved a grand total of (wait for it) 15 people, using a different skin, with four years of intervening changes. Four-year-old research should not be the basis of any changes being made to MediaWiki or Wikimedia projects, and I'm flabbergasted that anyone would think a 15-person sample would be sufficient for recommending major changes in the first place. Risker (talk) 02:29, 7 May 2013 (UTC)

Well, looking even further at the Usability wiki, it looks like this was a recommendation that was never tested, actually. The study seems to point out that new editors had a hard time finding the (correct) edit button. Nothing I can find there suggests that they actually tested this solution to see if it changed the outcome. Risker (talk) 03:30, 7 May 2013 (UTC)
Good lord. Facepalm Facepalm . I understand that site design elements should not be held hostage to community consensus, but you guys at the foundation could at least make the effort to pretend the community matters when deciding what changes to make. The irony of this change being based on a usability study is that the most important link on the entire website was suddenly moved to a position that has a high likelihood of confusing longstanding editors. This change was counterproductive in many ways, and once again it was left to the community to build a fix for it. With that said, thanks to the editors above who posted the css code to put the button back where it belongs. Resolute 03:40, 7 May 2013 (UTC)
Three things:
  1. The Foundation didn't make this change, a volunteer developer and Wikipedian did, with code review from both staff engineers and other volunteers. Myself and others helped him announce it because it's a big deal, and he did the hard work to clean up the previously screwed-up way that MediaWiki was generating the HTML for section edit links. Not every technical change comes from the Foundation, as MediaWiki is a functioning open source project with lots patches and extensions by people who don't work for the WMF.
  2. There was not just a 15 person usability test. Trevor later ran a proper randomized A/B test with thousands of registered and unregistered editors. That's what's mentioned in the Meta page, though I think the A/B test is under-documented.
  3. Even if you don't like the way the change was announced, the technical work done by volunteers on this means that overall things are better for Wikipedia, in all its languages... Previously about half of the top ten Wikipedias were using local JavaScript to move the section edit links to the left. Now, because of this patch, you no longer need a script to move the links to left or right, you just need one line of CSS. This means literally millions of our readers and editors will have a little bit less hack-y JavaScript to load on their browsers, every time they view a page with section edit links.
Steven Walling (WMF) • talk 04:13, 7 May 2013 (UTC)
Steven, you're now telling us about research that isn't even mentioned at the MediaWiki page, to which you pointed us for an explanation. Where's Trevor's research? It absolutely is NOT mentioned on the Mediawiki page. Everything that is documented and available to the user basically says "we asked 15 people, and they had a hard time finding section edit links, and a couple of wikis like it over there, so we're going to move everyone's over here because we think it looks better." This keeps happening over and over: we're handed one explanation for something then another then another, and none of it adds up. That some wikis like it in one place and others like it elsewhere seems pretty obvious. So how about we allow this project to put it where it makes sense to us? Risker (talk) 04:43, 7 May 2013 (UTC)
"So how about we allow this project to put it where it makes sense to us?" There is not only nothing stopping the project from doing that if that's the consensus, it's actually easier because of this change to MediaWiki core, as I just said above.
As for the rest... This isn't a Foundation patch. We're supposed to document experimental work from years ago (that I didn't do), review someone else's code and design, test their code, deploy their code to more than 800 wikis, help announce the change, and manage the response of people across the wikis? You can see why maybe I think you're being a tad demanding. I'm sitting here at 9 o'clock at night to try and explain a volunteer's work to another volunteer when I have a metric ton of my own work to do, so can you maybe assume a little more good faith? I'm just the messenger, so don't shoot me. Steven Walling (WMF) • talk 05:14, 7 May 2013 (UTC)
Thanks for the clarification. Given that this isn't a WMF initiative (and the decision of where to display the "edit" link continues to rest with individual wikis), it seems sensible to restore the longstanding format locally until consensus to change it is established. (I believe that it would make more sense to retain the original default and allow projects to optionally shift the link to the left via the improved method, but that's a matter to be raised elsewhere.) —David Levy 05:35, 7 May 2013 (UTC)

Bug

The edit-0 button is now broken in the Modern skin - it previously used white text, allowing it to show up against the blue background of the header in that skin, but along with the move seems to have changed color, making it effectively invisible. I see brackets around where the button should be, but can't see the button itself. Nikkimaria (talk) 20:26, 6 May 2013 (UTC)

Should be fixed now. — Edokter (talk) — 00:05, 7 May 2013 (UTC)

What it says on the tin. Is this related in some way to all these other changes? If so, please cut it out, putting it on the far right works, and it's never ever ever been a subject of complaint before from anyone. Putting it at the end of the words in a header doesn't make any sense, because of widely varying header lengths; it's getting lost there. If this is NOT related, tell me who's responsible for it. Someone ought to be owning up. Risker (talk) 23:03, 6 May 2013 (UTC)

I'll see it, but I do not want another bit of javascript anywhere. We shouldn't have to keep adding all this javascript (much of which starts to internally conflict) just to have a decent user experience. Risker (talk) 23:18, 6 May 2013 (UTC)
The move is not done or undone via JavaScript. Steven Walling (WMF) • talk 23:22, 6 May 2013 (UTC)
I don't mind the move, but to a lay person like me, javascript and stylesheets both fall into the "incomprehensible code" category. MBisanz talk 23:27, 6 May 2013 (UTC)
Thanks Okeyes and everyone else. That the two are occurring simultaneously is frustrating, but not unrealistic. Steven, allow me to explain the problem here. In order to fix something that your team broke without a logical reason, I would have to add MORE CSS and/or JSS to my setup. Every time I log onto a page, my load is slowed noticeably, and that's with a decent computer and high speed internet. Just imagine what it would be like for the editors using older technology and dial-up. Those scripts don't all get along well, and they can mess things up. There's no good reason for that link to be anywhere other than the same consistent place on each section. If the only way I can have those section edit links where they belong is to add scripts or gadgets, then your team has messed up, because they all depend on CSS and JS. Risker (talk) 23:35, 6 May 2013 (UTC)

Haha, funny to see you here, Risker! Yeah, this is one thing everyone can agree on. I think it's easier to have the edit link on the far right--that way everybody always can predict where it is going to be, and not need to scour the page for it. I know, lame, but that is how it happened for me =/ Red Slash 23:54, 6 May 2013 (UTC)

Edit link next to the section head is better for newcomers, as more likely to be spotted and more inviting. For experienced users, it's generally better on the right (closer to the scroll bar), except when images cause edit links of small sections to overlap confusingly. Anyway, there it is; I'm just disappointed the CSS above hasn't worked for me. Rd232 talk 00:01, 7 May 2013 (UTC)
Calling a post in VP-TEch "an announcement" doesn't cut it. And requiring coding to undo WMF's fuck ups is UNSAT. PumpkinSky talk 01:39, 7 May 2013 (UTC)
Risker is absolutely right to complain about implementing possibly unwelcome changes without flagging them up in a highly visible manner. It looks to me like too many developers are taking lessons from Douglas Adams and deciding that that it's ok to inform folks by the wiki equivalent of "on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying 'Beware of the Leopard'." It's not ok. --RexxS (talk) 02:31, 7 May 2013 (UTC)
lesson?? Adams' line was satire! >:( Rd232 talk 12:38, 7 May 2013 (UTC)

Just thought I'd chime in and say that I think the section edit link should be put back on the far right. Another reason: We sometimes sort of forget that a large number of people come to Wikipedia to read, but not edit, the articles. Having the edit link immediately following the section headers is distracting, and therefore detracts from the reading experience. — Mudwater (Talk) 04:12, 7 May 2013 (UTC)

I have basically given up hope that either the Foundation or the developers listen to the core community on matters like this, but I have to agree 100% with Mudwater and Risker. NW (Talk) 05:44, 7 May 2013 (UTC)
Hey, I'm as mad as anyone about the Orange Bar issue (and this edit link issue shows how that mess has needlessly damaged WMF goodwill), but this change is basically a code improvement. If we want the edit link back where it was by default, we can do that with a line in MediaWiki:Common.css. WP:VPR is that way, if you want to propose it. Rd232 talk 12:36, 7 May 2013 (UTC)
The code improvement is fine, but we should not have to go to VPP to restore a change that is obviously quite opposed. The positioning of the link should be returned to its original place, and those who favour the change in placement should be the ones seeking consensus. Resolute 13:27, 7 May 2013 (UTC)
Pointless change. Worthless change. I understand that hacky code must be replaced, but keep the edit tab to the right. One should not have to look for it in various places, depending how long the section heading is. "Right" does not equal "hacky code", and left (sort of) does not equal "good code". When 99% of existing editors have added the .css code, will you still claim the change was good? HandsomeFella (talk) 18:00, 8 May 2013 (UTC)
Actually I find it would be harder to find the edit tab when it is on the right than at the section header. I often have to search around for the link when it gets moved around because of pictures or the like on the right. When its right next to the section header I know its going to always be right next to the section header. You don't have to look around more just because a header might be slightly longer. -DJSasso (talk) 18:24, 8 May 2013 (UTC)

Change it site wide

Per m:Change to section edit links#If you don't like this change, adding: 

.ltr .mw-editsection {
  float: right;
}
.rtl .mw-editsection {
  float: left;
}

to MediaWiki:Common.css will restore the old-fashioned link site wide. Just sayin' -- Avi (talk) 07:36, 7 May 2013 (UTC)

'Fixing' what isn't broke or a problem

Whose idea was it to move the 'Edit' link for the sections over next to the section title? Was this discussed first? Isn't this link better left to where it has been after all these years? As it is, it clutters and crowds the section title. -- Gwillhickers (talk) 16:54, 7 May 2013 (UTC)

It is mentioned above at #.5Bedit.5D_moved. There has been a popular preference option to move them to the left for years, so some editors surely prefer it there, but the main benefit is increased awareness of the "edit" option for non-registered users to encourage readers to become editors. ~ Amory (u • t • c) 17:04, 7 May 2013 (UTC)
I don't like it either. I was having a hard time finding it today.— Vchimpanzee · talk · contributions · 19:56, 7 May 2013 (UTC)
Edits from non registered users is an ongoing problem. Virtually all vandalism is committed by non registered users, while others too often do not discuss major edits and rarely leave edit summaries. It only takes a minute to register. IMO, we should of course allow all others to join Wikipedia, but editing should be a privilege that is earned, save talk page suggestions. This policy is used for Featured Articles. If such a policy was in place overall virtually all vandalism would disappear and registered and responsible editors wouldn't have to stand guard over articles near as much. Sticking the edit option in the face of potential nonregistered users only encourages them to, uh, 'edit', whenever they get the urge. If potential users feel their edit(s) are important and needed, they will take the minute to register. 'Free and open access to anyone' is one of the main reasons Wikipedia is not considered a reliable source in the academic world. i.e.'Anyone' can edit at 'any' time. In fact, WP is blocked on high school computers here in California, and no doubt elsewhere, because it can't be trusted. If we aren't building an encyclopedia that is respected and not subject to random changes from anonymous users then what are we doing besides entertaining ourselves? The new in your face edit link location only throws gasoline on this particular fire and encourages others to do the same. -- Gwillhickers (talk) 17:26, 8 May 2013 (UTC)
Every time it has been looked at systematically, the contributions of unregistered contributors were judged to be on balance positive. The result I recall from a few years ago was 75% good edits and 25% unacceptable good faith edits / vandalism. I suspect you'd disagree, but the community has generally been willing to tolerate the bad edits IPs create for the sake of the good edits they also make. In addition, there is a general fear that erecting new barriers to new user participation will cause the active user numbers fall even more quickly than they have been. Dragons flight (talk) 17:45, 8 May 2013 (UTC)
Dragons flight, what you say might be true, but it still doesn't counterdict what Gwillhickers said. Most IP's don't vandalize (per your claim), but that does not mean that most vandalism comes from registered users. That goes without saying. HandsomeFella (talk) 19:06, 8 May 2013 (UTC)
"...editing should be a privilege that is earned, save talk page suggestions. This policy is used for Featured Articles." - no, no it's not. FAs are conceptually as open to edits as any other pages are. (The daily FA is sometimes restricted for that day, but that's a specific case and mostly due to volume) Andrew Gray (talk) 18:54, 8 May 2013 (UTC)
conceptually yes, but in practice; not. A shrill cabal won't allow that; the policy described is - sadly - de facto, if not de jure. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:09, 14 May 2013 (UTC)

Would the real [edit] button to [edit] please stand up [edit] [edit]

My first reaction was to wonder what was the topic about "problem [edit]" and then I noticed that all the header lines were about "[edit]" but the word "[edit]" did not seem to fit the logic of every header title. Be careful what you wish for, when discovering the original situation was better. I guess if the edit button were spaced further with lead-spacing, beyond the header title, it could be less confusing. But then, the placement of the header edit-button was the only thing which still worked correctly in all older browsers, so its days were numbered: "If it aint broke, then fix it so it will be." Yet another wiki-trainwreck. Just too funny. -Wikid77 (talk) 14:54, 8 May 2013 (UTC)

With all these changes to make us look more like Google and facebook I am waiting to see what happens with the site name. Maybe something like Wikibook or Facepedia? Kumioko (talk) 14:57, 8 May 2013 (UTC)
Wikid and I have had our differences, but in this case, I agree with him to the fullest. HandsomeFella (talk) 15:22, 8 May 2013 (UTC)
From a graphic design standpoint, the new location looks cluttered and unbalanced. One of the things the developers got right early on with Wikipedia was the clean, functional section header appearance, and this messes it all up. Rivertorch (talk) 18:21, 8 May 2013 (UTC)

Individual section edit buttons

Is there a way to shift the buttons for editing each section, and the lead, back to the right of the screen, rather than being variably located depending on the length of the header? Thanks, CMD (talk) 11:41, 8 May 2013 (UTC)

There really should be a gadget to put the links on the right; since there used to be a gadget to put the links on the left, where they now are by default, and I don't think it needs a lot of discussion. Rd232 talk 13:05, 8 May 2013 (UTC)

  • Okay, then, if a passing admin wants to do it:
  1. Create MediaWIki:Gadget-righteditlinks.css with the content span.mw-editsection { float:right; }, as well as the header-text at WP:Gadget#Header
  2. Create MediaWiki:Gadget-righteditlinks with the content "Move section [edit] links to the right side of the screen" or similar
  3. Edit MediaWiki:Gadgets-definition to include the line * righteditlinks|righteditlinks.css (the lefteditlinks was placed under Appearance between MenuTabsToggle and PrettyLog)
  4. Update WP:Gadget#Currently installed gadgets.
Ignatzmice•talk 13:18, 8 May 2013 (UTC)
Added. — Edokter (talk) — 19:14, 8 May 2013 (UTC)
Thank you!! Rivertorch (talk) 06:12, 9 May 2013 (UTC)

Who moved my cheese: latest editsection change broke many scripts

So, i do not mind that the devs changed the page design and moved the "edit section" link to the left: i think it's a good change, and will make casual editors more aware of the "edit section" link.

However, while doing so, the devs also changed the CSS class name for the edit section link from "editsection" to "mw-editsection". this broke many scripts: basically, any script that did something to the edit section link and found it by its class name, needs to change. as far as i saw, there was no announcement to this change, and we had to find it by users reporting script breakages.

Not only was this change unannounced, but it's also pointless and unjustified. i can accept that mw-XXXX is a more appropriate name than XXXX for a CSS class, but this is true only up until the point this class is used for the first time: once it's there, you should have a Really Really Really Good Reason™ to change it and break backward compatibility. as far as i could see, the "really really really good reason" in this case was something like "someone likes this name better". a software package that's deployed in tens (if not hundreds) of thousands of installations, can't (or at least shouldn't) be so blasé about breaking backward compatibility.

So for all of you script owners out there: scan your scripts and make sure to change every "editsection" to "mw-editsection".

peace - קיפודנחש (aka kipod) (talk) 21:10, 9 May 2013 (UTC)

I and a few others have replied at meta:Talk:Change_to_section_edit_links#sneaky_parasitic_change_-_broke_many_scripts., as you posted that comment there as well. It would have been fair of you to copy those replies here or at least add a notification, instead of creating the false impression that no one cares about your comments. Matma Rex talk 15:23, 11 May 2013 (UTC)
clarification: i posted it _there_ to "protest" the perceived blasé attitude towards backward compatibility. several people answered, and at least _some_ of the answers actually strengthen my impression that not all developers hold backward compatibility at the high regard i think it deserves.
what i wrote _here_, was meant mainly for other script developers, that maybe did not notice that the change could have broken some of the scripts.
i did not try to create the impression that "no one cares", and if i did create such impression, i am sorry.
as a person who developed several scripts over the years, i noticed that i, personally, do not use the majority of the scripts i wrote. the main reason is that many of those scripts were written per specific requests from other users, but i am not really interested in using the functionality those scripts provide.
the WMF upgrade cycle is 2 weeks now, which i think is great. however, it is completely unreasonable to expect every script developer to run full regression tests for every single script they ever wrote and someone still uses every two weeks.
so i think that whenever an upgrade contains some breaking changes, more effort should be made to identify the affected community (e.g., when touching a hook, scan all the extension to find who uses this hook. when changing CSS class name, make a clear note before the upgrade to notify scripters).
and BTW, this last upgrade brought with it several other breaking changes: one is a jquery regression (to be fair, the developers probably couldn't really know about this regression), and another is some other html+CSS changes that were completely unannounced (class name "mw-watched" changed to "mw-changeslist-line-watched". like in editsection case, this change also relates to some html changes).
peace - קיפודנחש (aka kipod) (talk) 16:29, 12 May 2013 (UTC)

I wrote some CSS to restyle the section edit links as buttons to make them stand out more. (Which also increases the temptation to click them and do something!) If you'd like to as well, the code is here. — Scott • talk 13:03, 10 May 2013 (UTC)

Thanks. I like the button look a lot better. jcgoble3 (talk) 06:28, 12 May 2013 (UTC)

Headings "in the air" after I fixed the float of the [edit] tab to the right

After I created User:HandsomeFella/common.css to float the [edit] tabs to the right, there is a significant distcance between the section name and the line under it.

Did I do something wrong with the .css file?

HandsomeFella (talk) 14:02, 8 May 2013 (UTC)

Looks fine to me. Maybe it's something to do with site-wide funny business (see directly above)? Ignatzmice•talk 14:05, 8 May 2013 (UTC)
It's still a problem. However, when I edit a page (in preview mode, like now), the single section heading looks normal, with normal distance to the line – but then again, there's now edit tab present in preview mode. HandsomeFella (talk) 14:23, 8 May 2013 (UTC)
Instead of relying on your own CSS page, why not go to Special:Preferences? There's a gadget to put the link back where it was before this update. Nyttend (talk) 22:12, 9 May 2013 (UTC)
One reason could be that this change was applied to all WMF projects more or less simultaneously. Not all of them have gadgets to restore the old behavior yet. So it may be more convenient to just put the necessary CSS into one's own common.css instead of first searching the (possibly missing) gadget on every site one is active on.
Nevertheless the initial question is still valid: Is there a possibility to realign the [Edit] button's baseline with the section headings baseline? The way it looks now is quite ugly and not satisfactory: When changing such a fundamental design element at least a real possibility to correctly restore the old design should be provided. Not just a half-hearted cobble job like the current CSS that only somehow aligns the link on the right. --Patrick87 (talk) 23:22, 9 May 2013 (UTC)
The baselines are aligned; please check the facts before throwing accusations. Also, most of the projects were already using this look, en.wp was one of the outliers. Matma Rex talk 16:23, 11 May 2013 (UTC)
They are not (at least if where talking about the same thing). I accidentally assumed that this section was about edit-links "in the air", headings are actually fine for me. And where talking about edit-links moved to the end of the line by using .mw-editsection{ float: right; }.
So again for clarification: The edit-link's baseline is not aligned with the heading's baseline when restoring the old style with the proposed CSS. This should be fixed somehow. --Patrick87 (talk) 17:12, 11 May 2013 (UTC)
Ah, when using the float hack – you're right, apparently they aren't – but were they ever? This is caused by the line-height: 1em rule the CSS for new section edit links includes, necessary to avoid breaking the layout when the links use the same height as the headings they belong to. This works differently with floated links, though; as far as I can tell it's impossible to get them to align in the same way as non-hacked ones, but adding the line-height: inherit; rule should make them look better. But this should be done by local admins in the gadget anyway, and I can't do that. Matma Rex talk 18:05, 11 May 2013 (UTC)
I ammended the gadget, so the edit links should be more aligned. — Edokter (talk) — 19:30, 11 May 2013 (UTC)
Thanks for the change. This doesn't really fix the issue though. The bigger the heading the higher (relative to the baseline of the heading) the edit-link is displayed. Isn't there a a way to correctly align the links without manual tuning of position in CSS? --Patrick87 (talk) 21:35, 11 May 2013 (UTC)
Afraid not. I don't know what browser you have, but they do show fine for me in all four major browsers. They're se to inline-block which means they should align to the baseline. — Edokter (talk) — 23:53, 11 May 2013 (UTC)
I'm using Firefox 20.0.1. If you look really close or zoom the page you'll notice that the baselines are definitely not aligned to each other. --Patrick87 (talk) 05:37, 12 May 2013 (UTC)

IRC Office Hours Regarding Flow

On Thursday, May 09, 2013, there will be an office hours from 18:00 UTC until 19:00 UTC (11:00 am to noon pst) about the upcoming Flow project. Flow involves replacing user talk pages. We will be looking at an interactive prototype and discussing, well, everything. You really want to attend this. Please join us on Freenode, channel #wikimedia-office --Jorm (WMF) (talk) 00:28, 5 May 2013 (UTC)

Ugh, change.  — TORTOISEWRATH 00:44, 5 May 2013 (UTC)
Any chance for a repeat session for non-Americans? MER-C 09:42, 6 May 2013 (UTC)
Above session is not for Americans only. If you meant to refer to specific timezones though, it might be helpful to state which one(s) you have in mind. --AKlapper (WMF) (talk) 12:54, 6 May 2013 (UTC)
Right. I'm perfectly willing to do as many as need be, for as many time zones as need be. Just let me know when good times are?--Jorm (WMF) (talk) 19:53, 6 May 2013 (UTC)
Something suitable for Asian regions (say 12pm UTC) would be great. MER-C 03:16, 7 May 2013 (UTC)
Ugh, 12PM UTC is five a.m. for me. I'll find something, though.--Jorm (WMF) (talk) 20:03, 12 May 2013 (UTC)
Why does this have to be discussed on IRC? How many Wikipedia regulars whom this will impact actually use IRC? I certainly don't - and why should I have to?--ukexpat (talk) 18:27, 6 May 2013 (UTC)
IRC is the fastest way to get as many people involved in a conversation as possible, allowing for context and rapid response. There will be other types of conversations happening too - not just on IRC.--Jorm (WMF) (talk) 19:53, 6 May 2013 (UTC)
Meeting log available. Sumana Harihareswara, Wikimedia Foundation Engineering Community Manager (talk) 19:14, 9 May 2013 (UTC)

OpenDyslexic font

Wikipedia might make the OpenDyslexic font available to its readers.

—Wavelength (talk) 22:50, 7 May 2013 (UTC)

This can be accomplished by adding to Special:MyPage/common.css:
@font-face {font-family:OpenDyslexic;src:url('https://github.com/antijingoist/open-dyslexic/raw/master/otf/OpenDyslexic-Regular.otf');font-weight:normal;font-style:normal;}
@font-face {font-family:OpenDyslexic;src:url('https://github.com/antijingoist/open-dyslexic/raw/master/otf/OpenDyslexic-Bold.otf');font-weight:bold;font-style:normal;}
@font-face {font-family:OpenDyslexic;src:url('https://github.com/antijingoist/open-dyslexic/raw/master/otf/OpenDyslexic-Italic.otf');font-weight:normal;font-style:italic;}
@font-face {font-family:OpenDyslexic;src:url('https://github.com/antijingoist/open-dyslexic/raw/master/otf/OpenDyslexic-BoldItalic.otf');font-weight:bold;font-style:italic;}
*{font-family:OpenDyslexic;}
 — TORTOISEWRATH 23:36, 7 May 2013 (UTC)
Thank you. I previewed that subpage with the code added, and it works.
—Wavelength (talk) 00:35, 8 May 2013 (UTC)
I have started the page "Wikipedia:Dyslexic readers".
—Wavelength (talk) 00:49, 8 May 2013 (UTC)
I took the liberty of reformatting your CSS using <syntaxhighlight>. This isn't working for me, but I may have a conflict with one of my other scripts. Regardless, if useful, then this should be added as a Gadget. --  Gadget850 talk 10:09, 8 May 2013 (UTC)
This doesn't work for me on Firefox, only Chrome. I'm not sure why; Fx supports OTF embedding...  — TORTOISEWRATH 21:34, 10 May 2013 (UTC)
It might have to do with GitHub servers not sending the right CORS headers to allow such use. --SoledadKabocha (talk) 22:24, 14 May 2013 (UTC)
  • Scrambled word order might also be common for dyslexia: Or perhaps as a related problem, people should beware "putting the cart before horse the" where adjacent words get scrambled, or omitted. So, while an improved font could help, I still think, "There is no substitute for proofreading" as when people realize they tend to transpose or jumble words. A technique could be to move a thumb over the text and reveal each word, in order, to check the sequencing of words or commas, etc. -Wikid77 (talk) 09:23, 8 May 2013 (UTC)
Other fonts for dyslexics: I have now discovered that Dyslexia interventions#Classroom accommodations (version of 22:15, 5 May 2013) mentions other fonts designed for dyslexics.
  • Using appropriate font type and size. It is suggested[by whom?] that Sassoon and Comic Sans may be the easiest to read; Times New Roman may be one of the most difficult to read. The font should not be too small. There are several fonts and typefaces designed for dyslexia including Gill Dyslexic,[1] Read Regular,[2] Lexia Readable, Sylexiad,[3] OpenDyslexic,[4] and Dyslexie.[5] (Alphabet writing systems only)
Maybe similar code is available for the other fonts.
—Wavelength (talk) 16:34, 8 May 2013 (UTC)

Extension UniversalLanguageSelector allows to set OpenDyslexic as the default font for English text and other langauges. We spoke about making it available in Wikimedia wikis within a month or two in yesterday's Wikimedia Language Engineering team's Office hour. It also contains links to test environments. Siebrand (talk) 08:15, 9 May 2013 (UTC)

References

  1. ^ Gill Dyslexic
  2. ^ Read Regular typeface
  3. ^ Sylexiad
  4. ^ OpenDyslexic
  5. ^ Dyslexie font

Improved upload form on Special:Upload

Hi all,

I wanted to ask what you think about an improved Special:Upload upload form here on the English Wikipedia. Besides preloading the edit box with the {{Information}} template, a preview option before actually uploading proved very handy.

What I have in mind is something like either

  1. the basic version of the ImprovedUploadForm as it can be seen on Commons:Special:Upload?uploadformstyle=basic or
  2. the very similar upload form of the German Wikipedia, which only needs a few lines of JavaScript which can be found on de:MediaWiki:Onlyifuploading.js.

Tell me what you think about my proposal, your feedback is most welcome. --Patrick87 (talk) 23:47, 7 May 2013 (UTC)

I adopted the code from German Wikipedia and installed it as a user script. You can find the script on User:Patrick87/UploadForm.js, it's loaded from Common.js using the following code:
// Add preview button to upload form and preload with information template
if (mw.config.get( 'wgCanonicalSpecialPageName' ) === 'Upload') {
    importScript("User:Patrick87/UploadForm.js");
}
As stated above this script adds preview functionality to the basic upload form and preloads it wit the default file information template. --Patrick87 (talk) 20:38, 8 May 2013 (UTC)
Is no one using the basic upload form or are do those people actually using it never use preview functionality? --Patrick87 (talk) 21:58, 12 May 2013 (UTC)
FWIW: I can't recall when I uploaded to WP, as I usually upload to Commons. There I use the basic upload, and preview, as I find the upload "wizard" quite annoying. ~ J. Johnson (JJ) (talk) 22:09, 12 May 2013 (UTC)
I've used the basic upload form once or twice (not very often; I don't do much with images). I've had to go without preview since the form doesn't have the option. I use the basic upload form because the fancy upload wizard is dependent on JavaScript. Your script isn't much use to me for the same reason... It is a good idea, though. – PartTimeGnome (talk | contribs) 22:27, 12 May 2013 (UTC)

Does anyone know how to track and gather stats for usage of links to Wiktionary? Something similar to the stats.grok.se article traffic stats? Thanks! Dohn joe (talk) 21:47, 8 May 2013 (UTC)

(read the documentation), which says ".d" for Wiktionary, e.g.:
I'm wondering if the OP meant tracking links on enwiki pointing to enwikt. If so, there's some sort of links table database that a TS (or Wikimedia Labs™) person would have to run a query on. Killiondude (talk) 22:22, 13 May 2013 (UTC)
Yes, that's it exactly. How would I get in contact with a TS or Wikimedia Labs person? Dohn joe (talk) 22:30, 13 May 2013 (UTC)
Well, based on this edit, it seems you want to know how many visitors from the English Wikipedia click on a link to get to the English Wiktionary (or any?). Henrik wouldn't know since he just uses information given out at dumps.wikimedia.org (actual URL). You probably want to ask user:domas who maintains these things to some degree. I previously thought you wanted to know the number of links on Wikipedia that pointed toward Wiktionary. Killiondude (talk) 23:36, 13 May 2013 (UTC)
Yes, that is what I'm looking for, although the number of links would be interesting to know as well. I'll try asking User:Domas. Thanks for the help - it's much appreciated. Dohn joe (talk) 23:54, 13 May 2013 (UTC)
From the navigation panel at the left-hand side of a page, select "Special pages". From the section "Redirecting special pages", select "External links search". Enter http://en.wiktionary.org and see the results.
—Wavelength (talk) 00:02, 14 May 2013 (UTC)
Special:LinkSearch only finds urls like http://en.wiktionary.org/wiki/example and not interwiki links like wiktionary:example. PrimeHunter (talk) 00:18, 14 May 2013 (UTC)

editpage-specialchar: misuse warning

It is a bar in the edit form between the <textarea> (text editing window) and submit buttons and checkboxes, available even to IP editors. It is certainly a useful thing, and I do not see anything wrong with making symbols – — ° ≈ ≠ ≤ ≥ ± − × ÷ ← → · § so easily accessible. But easy accessibility of ″ ′ prompts dumb click-and-clickers and crackpots to use them as quotation marks (I know several cases), if not to promulgate the use of prime in “original” transcription systems (this instance had some consequences). IMHO primes should be moved, at least in English Wikipedia, from the default [Insert ▼] group to the [Symbols ▼] group, where they would be less prominent and prone to misuse by click-and-clickers. Incnis Mrsi (talk) 09:01, 9 May 2013 (UTC)

You are probably right, and I have wondered why so many editors use the curly quotation marks. So the insert-text box has listed them in the standard symbols, after the infinity sign: # ∞ ‘ ’ “ ” « » ¤ etc. I tend to agree, and it would probably reduce cleanup immensely, if the insert-text box showed, instead: 'x'   "x" as being examples for using single and double quotation marks. Talk about a really significant, but simple, change to improve the editing of articles. -Wikid77 (talk) 13:14, 9 May 2013 (UTC)
Please, do not divert the thread from the initial question so far. I raised the question only about the disturbing accessibility of primes. Curly quotes, although discouraged by MOS:QUOTEMARKS, do not constitute a blatant misuse if used as a quotes. We can eventually cope with curly quotes fully automatically by bots (or even more advanced means), but not with misused primes: the difference is that there are (few) completely legitimate uses of ″ ′ which are hard to distinguish formally from the crap. The only relevance of curly quotes to my question is an apparent reason behind primes and double primes produced by ignorant click-and-clickers: they mistakenly think that insert a curly quote while it is really an unrelated prime character. Incnis Mrsi (talk) 16:31, 9 May 2013 (UTC)
This is a vicious loop of changes that this symbol feature goes trough. Some people want to make symbols accessible for speciality areas (think IPA math etc) others (MoS people) then think that symbols that are not used in common english should not be accessible to users and that speciality users should copy paste from elsewhere. We remove stuff, we put stuff back and then 2 years later someone removes them again and a year later they are back. So good luck :D These particular ones are probably in there for DMS notation of angles and you can propose changes on MediaWiki_talk:Edittools. —TheDJ (talk • contribs) 17:18, 12 May 2013 (UTC)

VisualEditor inserting pawns into articles

Tracked in Phabricator
Task T50346

You may want to hold off on using the VisualEditor for a few days. It seems to be inserting chess pieces into article text. This is a common problem with software that reaches a certain level of sophistication, so I'm sure the developers will have a fix for it soon :) Kaldari (talk) 06:19, 11 May 2013 (UTC)

This was already fixed when reported, but won't be deployed here until 20 May, I'm afraid. Jdforrester (WMF) (talk) 02:23, 14 May 2013 (UTC)
Of course, a pawn is not a chess piece, although it is a chess man. --Trovatore (talk) 02:29, 14 May 2013 (UTC)
Tracked in Phabricator
Task T50389

Whenever I try to add an interwiki link by following the "Add link" link in the "Languages" section, the following error message pops up: "You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature." However, if I visit Wikidata it seems I am already logged in there with my global login. This problem occurs not just with English Wikipedia but with other Wikipedias. Is this a known issue? Regardless, this error message is supremely unhelpful; it doesn't provide any indication as to what the "central data repository" is or how to log in there. —Psychonaut (talk) 17:43, 11 May 2013 (UTC)

I have reported this for you at bugzilla:48389. We will look into it. --Lydia Pintscher (WMDE) (talk) 20:23, 12 May 2013 (UTC)
Psychonaut, could you please let me know which browser you used while encountering the above issue? Without that information I can only guess what the issue might be. - Hoo man (talk) 20:29, 12 May 2013 (UTC)

Feature request: my todo list in Wikipedia:Notifications

Well, section title says it: can the new Wikipedia:Notifications feature give me the option to maintain a "todo"-list? I figure it could work like this: On a wiki page, I can add (click somehow) "todo", and add my note ("I should check thing x"). Whether my notifico-todo-listo is public or private is a discussion to be, of course, todo'ed. -DePiep (talk) 18:34, 11 May 2013 (UTC)

What's the connection to notifications? Sounds more like an annotated watchlist to me. Interesting idea though — HHHIPPO 18:57, 11 May 2013 (UTC)
I thought: WP:Notifications covers similar things. Indeed an annotated watchlist covers it too (can I filter it on "my todo-marked pages"?). If that can provide the function, fine with me. -DePiep (talk) 19:05, 11 May 2013 (UTC)
Well, WP:Notifications covers notifications. I'm not sure what kind of notifications you would expect from a todo-list, other than those provided by a watchlist. What functions an annotated watchlist would have is hard to answer, since it's a hypothetical feature anyway. Having a filtered watchlist (or equivalently, several watchlists) would also be nice indeed. If you don't mind all that being public you can make it manually though: just create a page in your user space, add links to all the pages you want to watch (and the talk pages), and add annotations as you like. Then use "Related changes" to use it as a watchlist. — HHHIPPO 19:48, 11 May 2013 (UTC)
Currently, I sometimes make elaborate notes on my Userpage: [18]. There, I cannot "click done". I requires full edits. But hey, If you think it an interesting idea though, why not elaborate on that?
Consider it Just My Association (Running Away with Me) -DePiep (talk) 20:14, 11 May 2013 (UTC)
Yeah, nice try ;-) I meant interesting to have, not "I'd be interested in coding it". — HHHIPPO 20:56, 11 May 2013 (UTC)
I meant to say: if you get it, support it. Technical problems we can do. -DePiep (talk) 21:03, 11 May 2013 (UTC)

I think I just got your original proposal: you'd like a way to manually add entries to your list of notifications, which will then stay there reminding you of things to be done until you mark them as done? That sounds like a nice feature. Maybe not for a long-term todo-list (for which I use a local file) but for things to remember within one editing session (where I keep all pages needing attention open in multiple browser tabs). So yes, support. But I'm afraid it's only one out of many items on the devs' todo-list. — HHHIPPO 22:01, 11 May 2013 (UTC)

Yeah, priority may be low. As with most of my thoughts ;-) -DePiep (talk) 10:29, 15 May 2013 (UTC)
I just imported from hewiki a short and sweet script that lets you define any number of "todo" lists, and add to the "hidden menu" (the one that houses the "move" button) one button per each todo list. pressing the button will add the current page to this list. see documentation. peace - קיפודנחש (aka kipod) (talk) 22:49, 11 May 2013 (UTC)
Thanks, sounds promising. Will take a further look. have put it on my -current- todo list. -DePiep (talk) 10:29, 15 May 2013 (UTC)

Finding typos

Hi, I'm trying to create an easy entry-point for an editor to make their first edit. The Getting Started tour is excellent for that, but I'm also looking into simple typo-fixing using commonly misspelled non-language-variant words, such as "recieved". I'm finding that if I search for these words using the search box, or the contains option of the search box that I cannot find persistent typos. Either they have already been fixed, or they are spelling redirects. Does anyone have an idea for how to find typos in Wikipedia articles that need fixing? This is a great exercise in breaking the 'fourth-wall' for editors and showing them an easy way to contribute with little difficulty. Thanks and cheers! Ocaasi t | c 21:32, 11 May 2013 (UTC)

Wikipedia:Lists of common misspellings
Wikipedia:WikiProject Fix common mistakes Bgwhite (talk) 21:54, 11 May 2013 (UTC)
Plus Wikipedia:Database reports/Linked misspellings -GoingBatty (talk) 21:59, 11 May 2013 (UTC)
Also see Wikipedia:Typo Team and Wikipedia:WikiProject TypoScan. – PartTimeGnome (talk | contribs) 16:39, 12 May 2013 (UTC)
Thanks for all of these tips! Ocaasi t | c 02:57, 13 May 2013 (UTC)

Performance considerations regarding custom CSS an JavaScript (globally used)

Hi all,

I'm recently experimenting with global CSS and JS files which I'm storing centrally on my home Wiki and which I can easily load from all Wikimedia projects I'm active on. Right now I have a global.css and a global.js on German Wikipedia and I load them from common.css or common.js respectively using 

/* ########## load global.css from dewiki for cross wiki usage ########## */
@import "//de.wikipedia.org/enwiki/w/index.php?title=User:Patrick87/global.css&action=raw&ctype=text/css";

and 

// ########## load global.js from dewiki for cross wiki usage ##########
mw.loader.load('//de.wikipedia.org/enwiki/w/index.php?title=User:Patrick87/global.js&action=raw&ctype=text/javascript');


I'm now wondering how well this works performance-wise. That means how fast those files are loaded on a fresh page load and if they are correctly cached for subsequent page loads. Does anyone have an idea or even some numbers on how well my current approach performs?

For example I could omit the common.css at all and just put an additional mw.loader.load("//de.wikipedia.org/enwiki/w/index.php?title=User:Patrick87/global.css", "text/css"); into my common.js.

Furthermore I'm wondering whether it matters were the global code files are stored? Is it OK to have them in the user space of my home Wiki or should I transfer them to another Wikimedia project? Is it useful to have them on a Wikimedia server at all or should I even try to put them on the fastest server I'm able to find?

I hope some of the geeks can shed some light on all this, since I'm neither familiar with such performance considerations in general nor with the MediaWiki related specialties.

Regards, --Patrick87 (talk) 14:23, 12 May 2013 (UTC)

Since all js scripts and css files are processed on the client side, the performance will mainly depend on the browser/OS/computer that you use. Ruslik_Zero 16:37, 12 May 2013 (UTC)
Actually, there might be server-side differences in performance because the global CSS/JS files are not being loaded through ResourceLoader. However, unless you have problems related to performance, don't worry about it. – PartTimeGnome (talk | contribs) 17:14, 12 May 2013 (UTC)
Well, I notice some small delays now and then. However it's hard to tell If they stem from the additional loading of global code files or from loading of scripts themselves. Probably both, but since it's a noticable delay I'd like to optimize loading times as much as possible without loosing the convenience of global code files. — Preceding unsigned comment added by Patrick87 (talk • contribs) 18:16, 12 May 2013 (UTC)
As this is very browser dependent, it would probably help if you reported which browser you are using. Additional DNS lookups might introduce a delay for instance, but then Chrome pre loads dns lookups right away, so it should only affect you very shortly on the first pageview session. Other browsers (or versions of other browsers) might not be so agile. —TheDJ (talk • contribs) 13:20, 13 May 2013 (UTC)
I'm using Firefox (currently version 20.0.1) on Windows 7. --Patrick87 (talk) 14:33, 13 May 2013 (UTC)

Audio Pronunciation Modification Suggestion

Hello!

I am currently a medical student and almost all my classmates and I (as well as health care professional students across the country) use Wikipedia to supplement some of the basic science information regarding the various topics we are studying. Currently we are in pharmacology and I've found myself constantly looking extra information about various pharmaceutical drugs up on Wikipedia only to have to look at secondary sites to look up pronunciation. I know that there is a way to make an audio pronunciation for words (e.g. - https://en.wikipedia.org/wiki/Onomatopoeia) and I've started tagging the tougher words so it shows up on https://en.wikipedia.org/wiki/Category:Requests_for_audio_pronunciation_%28English%29 and will hopefully get added, but when the audio clip is functioning properly it opens up a new window - which in my opinion is a big detractor. The other secondary sites that I am regularly using to look up pronunciations are forvo.com and howjsay.com - both of which are able to play the audio without having to load a new browser. That said, it is very frustrating to keep going back and forth between the two tabs and I feel like this feature could be a great improvement for Wikipedia.

I spoke via email with a Wikipedia representative (Luke Faraone) about this and he suggested that I post here because it would require a modification to the WikiMedia software. Would this be possible?

Thank you for your time and consideration. Let me know if you have any more questions.

Sincerely, Michael Tudeen — Preceding unsigned comment added by Mtudeen (talk • contribs) 16:13, 12 May 2013 (UTC)

Providing an explicit example, webbrowser information (name and version) plus steps to reproduce the problem are highly welcome. --AKlapper (WMF) (talk) 09:11, 13 May 2013 (UTC)
Since I do understand what Mtudeen is writing about I am going to start with explaining what (s)he is talking about and following that by mentioning the next steps. In a nutshell this is an template issue.
Mtudeen is talking about the template Audio - shown as pronunciation (US)ⓘ in the article Onomatopoeia. Mtudden dislikes that when (s)he clicks the link, then (s)he goes away from the page to a different page where the audio is played. This can easily be replicated by clicking the "pronunciation (US)" link above. Now, what Mtudden wants is that the audio should be played on the Onomatopeia page itself. That can be done with an template like Template:Listen - shown as
Onomatopoeia
Problems playing this file? See media help.

.

Now for the second part of my comment. While the template listen could in theory be used instead of template audio in the lead section of the page, I know that some users would dislike that for aesthetic reasons. So, I do think that this issue needs more discussion than it allready has and even some thought when it comes to design.--Snaevar (talk) 14:24, 13 May 2013 (UTC)

So is there be a way to implement the template listen function in a modified format that is more aesthetically pleasing? Instead of the current image, for example, just showing a small gif that looks like a speaker with sound waves coming out of it and clicking on it (or the word immediately following it) would allow you to hear the sound on the webpage you are currently on?--Mtudeen (talk) 20:20, 15 May 2013 (UTC)

Almost everything is possible, but it's open source software, so you need to find someone to actually create it and submit the patches. It's a question of time, effort and resources. —TheDJ (talk • contribs) 20:52, 15 May 2013 (UTC)

missing localized text in the Edit form

Resolved

Hello! When editing a page, there's a <cite-section-label> and a <cite-template-list> texts that should probably be changed to something more meaningful. However, I can't find where they are coming from (I couldn't find them in Special:AllMessages). Any idea? -- Luk talk 17:56, 12 May 2013 (UTC)

I don't know what you refer to with <cite-section-label> and <cite-template-list>. Does it literally say that? Where do you see it? Does it happen when you are logged out? If it only happens when you are logged in then what is your skin and language at Special:Preferences? What is your browser? PrimeHunter (talk) 21:00, 12 May 2013 (UTC)
Like PrimeHunter, I can't see this text either. MediaWiki uses angle brackets around message names to indicate that no translation can be found for that message, not even in MediaWiki defaults. Hence, for the examples given the messages are MediaWiki:cite-section-label and MediaWiki:cite-template-list. Since others can't see this, please check if these messages are from a user script or gadget. If so, contact the script author. If the messages come from MediaWiki itself, please file a bug; MediaWiki should not be outputting non-existent messages. – PartTimeGnome (talk | contribs) 21:41, 12 May 2013 (UTC)
It's the fourth text button in (modern) WikiEditor, which normally says "Cite" and allows to insert citation templates. I saw it sporadically, too, today. It might be a timing issue since it's not always displayed and often fixed after a page reload. --Patrick87 (talk) 21:53, 12 May 2013 (UTC)
It's apparently from MediaWiki:RefToolbar.js. I can get it to say <cite-section-label> by changing language, for example http://en.wikipedia.org/enwiki/w/index.php?title=Wikipedia:Sandbox&action=edit&uselang=fr. PrimeHunter (talk) 22:09, 12 May 2013 (UTC)
I got this once while editing the sandbox logged out in IE 10. However, I was unable to reproduce it in Firefox or Chrome, and upon logging in with IE, it worked correctly, and now I can't reproduce it in IE even after logging out and clearing the entire cache. Language set to the default of en the entire time. I also can't reproduce it with the fr link that PrimeHunter provided in any of these three browsers. Sounds like it happens completely at random, which is the worst kind of bug. jcgoble3 (talk) 04:56, 13 May 2013 (UTC)
I get it more or less consistently when using PrimeHunter's link (FF20.0, Ubuntu, MonoBook). Whenever I change the uselang= parameter, the message names appear. After reloading the page without changing uselang, the actual messages are displayed, but always in english. The only exception I found is uselang=de, where I get the German messages right away. Hope that helps. — HHHIPPO 06:49, 13 May 2013 (UTC)
I assume that this is the culprit. I can't reproduce the problem any more, but I'm also on a different PC. — HHHIPPO 07:27, 13 May 2013 (UTC)
Probably, it seems OK now. -- Luk talk 09:42, 13 May 2013 (UTC)

Is this a bug or a feature?

If I edit a protected page, it gives me a large multi line warning and all the edit window is in red. After editing, the page is still protected - all OK. However if I create a previously salted page, the warning is not so obvious, the edit window has a white background like an unprotected page, and after pressing "save", the article is unprotected and the protection log show no evidence of protection being removed - check my test at http://en.wikipedia.org/enwiki/w/index.php?title=Special:Log&page=User%3ARonhjones%2FSandbox4 - the last entry is fully protected and the page is currently unprotected.  Ronhjones  (Talk) 18:08, 12 May 2013 (UTC)

You have two issues here:
  1. The mw-textarea-protected class is not applied to the textarea in the edit form for create-protected pages.
  2. Create protection is automatically and silently removed when the page is created.
The first is certainly a bug; please file a bug report for it.
I don't know about the second, since it mirrors the automatic and silent removing of edit protection when the page is deleted. The "automatic" part certainly makes sense, as the change in state means the old protection no longer applies. I'm not entirely sure about the "silent" part, but it should be changed in both cases if it's changed in either. You can file a bug for that one too if you want, or you could wait for more opinions on whether it's actually a bug or not. Anomie⚔ 19:20, 12 May 2013 (UTC)
I've lumped it all together at Bug 48411.  Ronhjones  (Talk) 19:05, 13 May 2013 (UTC)
Tracked in Phabricator
Task T50402
See related about renames: #Relinking Google for SSL https.

When editing via https, secure-server protocol, I do not see rel="canonical" inside the generated HTML markup. For example with "https:../Catenary" then I was expecting to look inside the HTML and see a line as:

So, anyway, when I edit those pages linked by Google with https-protocol, they do not re-index in Google (even after days), as compared to typical http-prefix pages in Google which re-index within minutes of an edit-save. Meanwhile, more articles are falling into Google's https-prefix abyss (such as recent page "Hyperbola" and now this week "Catenary" have Google https), where the https-protocol views are not counted by stats.grok.se, and any edits to those Google https-prefix pages no longer update the Google search-results blurbs. There are more than 600 Wikipedia pages/images linked in Google by https-protocol links (see essay: "wp:Google https links"). Anyway, since I cannot insert the canonical link-tag directly, as <link rel="canonical" href="http://en.wikipedia.org/wiki/Catenary">, does anyone know a template or parser function which can set a link as rel="canonical" so I can edit-save the page to connect the https and http versions within Google? -Wikid77 (talk) 19:51, 12 May 2013 (UTC)

Hmm, this is weird. I don't think we ever did it like this. Perhaps the google implementation changed ? They do list this as a requirement it seems. Canonicalness should be defined in MediaWiki core, so I filed a ticket, there is no and should be no user option for this. —TheDJ (talk • contribs) 13:16, 13 May 2013 (UTC)
  • Link-tags for "canonical" are inside en.m.wikipedia HTML pages: Thanks for checking this issue, as I had seen such link-tags (with rel="canonical") inside each mobile-site page's generated HTML markup (such as inside the HTML for https://en.m.wikipedia.org/wiki/Catenary). Hence, I expected any "https:" article's HTML markup to directly contain the link-tag, but if Google spiders can read the "canonical" setting from the MediaWiki core, then perhaps that should work. At this point, I have been able to rename pages to drop the https-protocol links in Google, but if the "canonical" setting can be directly applied, then Google should reset each "https:" to "http:" within a few days. -Wikid77 (talk) 05:36, 14 May 2013 (UTC)

Huggle Issues

Firstly, I know the disclaimer on Huggle, that is to say, every edit I make I am equally responsible for as if I had typed it into the edit window, etc. With that in mind, what the hell happened here? I instructed Huggle to make a normal revert-and-warn, and onlly found out this had happened when echo told me Lugia2453 had reverted me. Secondly, has this been reported in the past? I checked the HG feedback page, but it seems kind of inactive.--Gilderien Chat|List of good deeds 21:11, 12 May 2013 (UTC)

Editing Bar: Citation Templates not working

I keep clicking on any of the Cite templates in the editing bar ("cite web", "cite newspaper", etc.), but nothing at all happens. All of the other editing-bar buttons are working but the Cite Templates are not working at all.

Google Chrome 26 (also IE8); Win 7

Softlavender (talk) 03:40, 13 May 2013 (UTC)

Works fine here. Firefox 20.0.1, Windows 8. Are you getting any JavaScript errors (see WP:JSERROR)? jcgoble3 (talk) 04:01, 13 May 2013 (UTC)
No. Softlavender (talk) 04:34, 13 May 2013 (UTC)
Also works for me in Chrome 26.0.1410.64 m and IE 10. I don't know what the problem could be. jcgoble3 (talk) 04:42, 13 May 2013 (UTC)
I already replied to this person who requested help using the {{help}} template. They were given the option of also using the {{cite web}} and {{cite news}} templates manually but they didn't seem interested in that response or the idea that it was likely a problem on their localized computer. Mkdwtalk 04:52, 13 May 2013 (UTC)
Mkdw, my question was not how to use the {{cite web}} and {{cite news}} templates manually. I already know how to do that. My problem is that the templates don't appear when I click them on the Cite Templates drop-down menu of the editing bar. Softlavender (talk)
Yes I was fully aware of that. I never offered you advice about that. I informed you that while trying to use the tool bar in your browser that it was working for a number of people so asking for help on it was likely an issue with your computer and not Wikipedia. I suggested you reinstall your browser. Mkdwtalk 05:01, 13 May 2013 (UTC)
Jcgoble3, I looked at the page you linked and it doesn't make any sense to me. Plus I am not using any gadgets, I'm just using the Wikipedia editing bar; it doesn't give any error messages -- the templates just don't appear when I click the names for them. Softlavender (talk) 04:53, 13 May 2013 (UTC)

Despite your really rude response to me when I was trying to help you, I still want to if you're willing to politely discuss this further. I know it's frustrating but an unwillingness to talk it out with those helping is not going to help.

This is what happens for me when I click it btw. Mkdwtalk 04:56, 13 May 2013 (UTC)

File:Insert ref toolbar example.png
My editing bar is a completely different layout than your image -- different look, different buttons, nothing like that. Softlavender (talk) 05:14, 13 May 2013 (UTC)
It's just a different skin. The function works the same. Does yours look like the one below? Mkdwtalk 05:15, 13 May 2013 (UTC)
It's not just a different skin. The top image is the Advanced editing bar (which works fine for me). The bottom image is the standard editing bar. I could not get the standard editing bar's citation templates to work when I clicked on their names in the Cite Template drop-down menu. Nothing happened. Although now that I selected Advanced edit bar in my preferences, and then went back and unselected it, the standard toolbar's Citation Templates work again, but it has a completely different interface than it did before, and no longer has a drop-down menu for the citation templates (as in your bottom image), but rather radio buttons instead. In any case, unselecting and then re-selecting seems to have updated and fixed it. Softlavender (talk) 05:39, 13 May 2013 (UTC)

This is likely my fault. I made some changes recently that appear to have broken something. I have reverted them. I can't reproduce the problem on my end so I'm not sure why it occurs. By clearing your browser's cache and it should work again. Jason Quinn (talk) 06:53, 13 May 2013 (UTC)

The thing under question is called the WP:Reftoolbar. There are actually 3 different version depending on your preferences. My changes ought to only have affected Reftoolbar 2.0b (the one with dialogs). Jason Quinn (talk) 07:05, 13 May 2013 (UTC)
As I mentioned above, it's working OK from me now, at least on Google Chrome. The standard editing bar is still not working however on IE8 -- I click the Citation icon and nothing at all happens. Clearing cache doesn't change anything -- that's the first thing I tried. Also, why does the so-called "Advanced" editing bar have much fewer options on the citation templates than the standard edit bar does? The standard edit bar lets one preview a citation, add the title of a newspaper, and so forth. The standard edit bar is much more advanced than the "Advanced" edit bar. Softlavender (talk) 07:26, 13 May 2013 (UTC)
There was another person that reported an issue on my talk page, so you weren't the only one that experienced problems. I figure it's best to revert until I know exactly what's going on. It still may have just been a cache issue: clearing the cache is always a quirky thing and sometimes it just doesn't seem to do it until it finally does. Some browsers are better at it than others. The "advanced" toolbar is actually WikiEditor. The Reftoolbar is actually a misnomer: it should be called something like "CiteButton" because it just adds a button, not a toolbar. The Reftoolbar 1.0 (the "old" or legacy version) is still quite nice; it just looks "web 1.0". The 2.0 versions (the "enhanced" versions) are about equivalent in function. They just look a bit cooler. There are minor pros and cons to each version. I think of 2.0b (the dialog based one) as the most important because it's the default for new users. I've been curious how many people actually use each version. I agree with you that the whole thing is somewhat confusing. Jason Quinn (talk) 08:09, 13 May 2013 (UTC)

Message notification anomaly

Tracked in Phabricator
Task T49912

The new user talk page message notification is buggy. When a new message is placed on my talk page a red number '1' appears in a tiny box after my username at the top of the given page I am visiting or working on. After I go to my talk page to view the new message, the red '1' appears again when I go to a new page, and again and again, in some cases. This doesn't always happen, but it happens often. What was wrong with the old message notification using an orange colored banner? It couldn't be overlooked and it worked like a charm. Doesn't anyone do beta testing before they try to re-invent a new 'mouse trap' for WP? Would someone kindly bring this to the attention to the individual(s) responsible and maybe advise them to not re-invent (or "improve" on) things unless there is a real need to do so? -- Gwillhickers (talk) 03:52, 13 May 2013 (UTC)

If you click on the red box, it should show details about the notification (and a list of old notifications), and should then disappear. Inkbug (talk) 07:40, 13 May 2013 (UTC)
Known issue, I added the relevant bugreport on this for you. —TheDJ (talk • contribs) 12:37, 13 May 2013 (UTC)
  • Inkbug, I have also clicked on the red box and still experience the same problem. As with the original message notification, it should simply stop appearing by going to your user talk page. I am still experiencing this problem as I write. -- Gwillhickers (talk) 18:07, 13 May 2013 (UTC)
But you can only see it if Preferences → Pending changes → Enable tracking bugs on Bugzilla using the {{tracked}} template --  Gadget850 talk 01:40, 14 May 2013 (UTC)
@Gadget850: Everyone can see the floating box with the raw bug number. The gadget to which you refer only replaces the bug number with the title and status of the bug. jcgoble3 (talk) 01:48, 14 May 2013 (UTC)
What are the chances of bringing back the original message notification w/ the orange banner? Again, it was impossible to overlook, as I have done with this tiny red box. We don't need to see a list of messages (last msg, first) as they appear in that order at the bottom of our talk page -- and there is edit history. Seems like someone is going through a lot of trouble to reinvent the wheel. -- A fifth wheel no less. -- Gwillhickers (talk) 02:53, 14 May 2013 (UTC)

red box message indicator

I see they have added a small orange banner next to the tiny red box that appears when a new message is added to your talk page, and when you go there the orange banner no longer is displayed when you exit and go to other pages. However, that red box still appears until you click on it too. And clicking on it doesn't take you to your talk page. You now have to select a message from a list. Btw, I tried logging in at bugzilla to report this, but apparently your normal username/password won't work. -- Gwillhickers (talk) 23:07, 14 May 2013 (UTC)

Another little annoying quirk of Vector I've noticed since the demise of Classic skin: external links all seem to have a little icon after them (a small box with an arrow pointing NE). Is there a css tweak I can use to disable this? An optimist on the run!   07:56, 13 May 2013 (UTC)

It's not specific to Vector, but was already in Monobook at least a year before Vector was deployed. The icon is injected by site-wide Javascript, but the following in Special:Mypage/common.css or Special:Mypage/skin.css should suppress it:
a.external {
  background:none !important;
  padding: 0px !important;
}
Alternatively, it may be switched off for all users on a per-link basis by applying class=plainlinks as in <span class=plainlinks>[http://www.example.com/ Example]</span> → Example --Redrose64 (talk) 08:40, 13 May 2013 (UTC)
Thanks. An optimist on the run!   09:18, 13 May 2013 (UTC)
Appropriately documented at Help:External link icons. --  Gadget850 talk 01:28, 14 May 2013 (UTC)
The plainlinks class is indeed documented at Help:External link icons#Classes, but the advice at Help:External link icons#Custom link icons, if followed, only removes one specific type of icon - in the example given it's the padlock shown against anything beginning https:// - and when so doing it leaves a blank space where the icon would have been. My suggestion is not specific to one type of link; it eliminates that gap; and is shorter. It could be shorter still; per CSS 2.1 syntax, para 2 "After a zero length, the unit identifier is optional.", so on the third line I could have put 0 instead of 0px. --Redrose64 (talk) 08:43, 14 May 2013 (UTC)

Wikipedia:Articles for deletion

Is there any good reason why May 4 page is not currently shown on this page? Both May 3 and May 5 are shown, and May 4 has open nominations at the time I am writing this.--Ymblanter (talk) 08:02, 13 May 2013 (UTC)

Wikipedia:Articles for deletion/Log/2013 May 4 has open AFDs, but isn't appearing in Wikipedia:Articles for deletion/Old. This subpage is normally maintained by Mathbot (talk · contribs); unfortunately, that bot needs Toolserver to run correctly. --Redrose64 (talk) 08:16, 13 May 2013 (UTC)
I see, thanks. Can it be done manually? I would do it, but I am afraid to break smth.--Ymblanter (talk) 08:34, 13 May 2013 (UTC)
 Done I looked at how the 5 May entry was laid out, then did a manual construction of the missing entry. --Redrose64 (talk) 08:56, 13 May 2013 (UTC)
Thank you.--Ymblanter (talk) 09:14, 13 May 2013 (UTC)

VisualEditor fortnightly update - 2013-05-13 (MW 1.22wmf4)

Hey all,

Here is a copy of the regular (every fortnight) update for the VisualEditor project, so that you all know what is happening (and make sure you have as much opportunity to tell us when we're wrong, as well as help guide the priorities for development and improvement):

VisualEditor was updated as part of the wider MediaWiki 1.22wmf4 branch deployment on Monday 13 May. In the two weeks since 1.22wmf3, the team have worked on the new features for VisualEditor's beta launch as the default way users will edit our wikis: Categories, Templates, References and Images.

The VisualEditor now lets users edit the contents of <div> blocks (47907) as if they were normal mark-up - though not the blocks themselves, such as setting arbitrary CSS, which will come later. Work on enabling the editing of categories is almost finished with the addition of a way of setting {{DEFAULTSORT}} in the interface (46465), and support for moving, altering and inserting new images and references is also improving rapidly. Progress on template editing is at an earlier stage, with core back-end support mostly finished at this point.

We made quite a few changes to the MediaWiki integration layer. Most obviously, we now use SVGs rather than PNGs for the graphical elements of the interface, so it scales nicely for users who zoom in (48148). The "Edit source" tab now appropriate becomes active when it is being used (47452), appears on all pages, not just view (47776), and the "Edit" (VE) tab now points to the newly-updated page once you've made an edit (47420). The Vector drop-down menu's change behaviour no longer hides it behind the VisualEditor toolbar (48078)

We improved some issues with the Opera browser (47772) and now warn logged-out users appropriately about the consequences of their editing (47842). Pre-save diffs now give a more reasonable message when there are no changes to be made (43754), and now work when the diff is aborted and restarted (44446). Pages that are not wikitext content (such as user CSS or JS items) will now not trigger VisualEditor (47456). We added a new access key for accessing VisualEditor - Ctrl+Alt+v/Ctrl+⌥ Option+v - restoring the regular edit access key to the wikitext editor (48107).

We also made a number of fixes for RTL environments. First, the link inspector now works for RTL environments, but allows LTR content for Web links (47717). For multi-script variant wikis, content displayed with one variant whilst the user's interface is in a second now works correctly (33175). Un-editable blocks ("aliens") now appear in RTL environments correctly (47746). Finally, the "Edit" (VE) tab now appears down-tab rather than up-tab of the "Edit Source" tab (48017).

On the integration with Parsoid, we cleaned up a number of items of code including removing change markers (45061), and fixed some problems with trailing whitespace on paragraphs and table cells being dropped (47712). Content with different names for the same annotation now serialises to the same wikitext (48110), and serialisation of data with DOM elements is now fixed (47948).

Finally, we fixed a number of other bugs, including ugly issues with pawn characters being created in list and paragraph editing (48287, 48286, 47817, and 48346), with indenting and outdenting of multiple list items (48390), and with splitting list items (48386). Categories that appear in sub-sub-pages don't get corrupted when the page is being edited (48408), and in Firefox, we fixed editing a page causing the entire editor to go blank (47834) and non-character keys being interpreted as real ones (48022). Trying to set a link covering the first character of the document no longer causes VisualEditor to crash (47623), and links now don't wrongly appear to extend when you type after them (48171 and 48114).

A complete list of individual code commits is available in the 1.22/wmf4 changelog, and all Bugzilla bugs closed in this period on Bugzilla's list.

Per the MediaWiki deployment roadmap, this should be deployed here on Monday 20 May.

Hope this is helpful! As always, feedback gratefully received, either here or on the enwiki-specific feedback page.

Jdforrester (WMF) (talk) 02:40, 14 May 2013 (UTC)

Transwiki process

Hi there. Way back in October I nominated A leopard doesn't change its spots for deletion, and the result of the discussion was transwiki to Wiktionary. The problem is that the transwiki tag (This page will be copied to Wiktionary using the automated transwiki process) has been on the article ever since, and no transwiki has taken place. Is the automated transwiki still yet to happen, or has there been an error? I'm afraid I don't really know anything about transwiki. Thanks! — Richard BB 08:10, 14 May 2013 (UTC)

Transwikis are not automatic: the article can only be imported by Wiktionary admins. Also, there is already an article wikt:a leopard cannot change its spots. You should ask over there for further information. Darkdadaah (talk) 08:39, 14 May 2013 (UTC)
Oh right, thanks. The tag threw me as it said it was an automated process. Thanks for your help. — Richard BB 08:46, 14 May 2013 (UTC)
That is misleading, yes. The importation of the page and its history from one project to another is automated (thanks to the import feature), but the process has to be executed by someone on the target wiki. I deleted automated from the template. Darkdadaah (talk) 13:50, 14 May 2013 (UTC)

Is it possible to pass {{N/a}} from a template?

I'm trying to develop a template to automate the calculations on the page List of minimum wages by country. One of the calculations I do requires knowing the exchange rate between that country's currency and US Dollars, which is not always available. I'd like to display N/A in the table when this is the case, but I'm having difficulties. I boiled the problem down to this: it seems passing {{N/a}} through an intermediate template to the article's main table corrupts the formatting. See Debugging nested N/A for a simplified example. Is there any way to allow this kind of template passing, or will I have to get the "outer template" to recognize when it needs an N/A and send it directly? I'd like to avoid this second case if possible because it will clutter the high-level template with a bunch of ugly and confusing implementation details. --Greenbreen (talk) 14:40, 14 May 2013 (UTC)

This minimal example is really minimalistic (actually I'm not quite sure if I understand correctly what it should do) . However I did a small change to User:Greenbreen/TemplateInner (remove the line breaks) which at least fixes the table in User:Greenbreen/Sandbox. Tell me if this was the problem you were talking about and if my changes fixed it. --Patrick87 (talk) 15:32, 14 May 2013 (UTC)
That did it! Thanks very much for your help. --Greenbreen (talk) 16:01, 14 May 2013 (UTC)

Echo / Orange bar of doom status update

As of today, the Echo notification extension includes it's own talk page message alert. You should see this as an orange highlight around the Talk page link which changes to say "Talk: You have new messages" whenever a change has been made to your talk page. If you want to turn this alert off, go to your notification preferences and uncheck the box at the bottom. If you want to enable an alert similar to the old "Orange bar of doom", go to the gadget preferences and turn on the "Display a floating alert when I have new talk page messages" option there. There are also a few user scripts, such as User:Writ Keeper/Scripts/orangeBar.js, that do similar things. If you would like to discuss these features, or any other aspects of the notification system, please come to Wikipedia talk:Notifications. Kaldari (talk) 20:26, 14 May 2013 (UTC)

THANK YOU +1+1+1+1+1+1+infinity SarahStierch (talk) 21:33, 14 May 2013 (UTC)
This is still arse-about-face; the opportunity for experienced editors to configure their settings is welcome, but the old-style orange bar should not have been replaced (and should have been be restored) until there is something equally prominent to allow us to grab the attention of new editors. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:05, 14 May 2013 (UTC)
Thanks Kaldari! Nicely done. Ocaasi t | c 01:33, 15 May 2013 (UTC)
I like it! Notifications-Message-Indicator-OptionF2-Toolbar-Alert-Orange-Screenshot-Closeup-05-08-2013 --Atlasowa (talk) 20:41, 16 May 2013 (UTC)

Complex categories

Is there a way to see, in a single view, the hierarchy organization of a specific category and its subcategories? There is a category that needs order, but going from main category to subcategories, to sub-subcategories and back, it's easy to get lost, and I may end up making things even more complicated than if I had the full picture at sight. Cambalachero (talk) 12:02, 15 May 2013 (UTC)

Try {{Category tree}}. -- John of Reading (talk) 12:13, 15 May 2013 (UTC)
Any category page which has subcats will list these at the top, and to the left of each one there should be a grey or blue triangle. These indicate whether the subcategory has subcats of its own: grey means no, blue means yes; and the blue ones are clickable. When you see a blue triangle pointing right, click it: the triangle turns to point down, and the subcat expands to show its members, which are also marked with grey or blue triangles. You can take this ad infinitum. --Redrose64 (talk) 13:41, 15 May 2013 (UTC)
Thanks, this template will help. Cambalachero (talk) 02:10, 16 May 2013 (UTC)

Help:Job queue page up for deletion

Help:Job queue has been nominated for deletion by a new IP 151.230.23.170. — Maile (talk) 13:10, 15 May 2013 (UTC)

They didn't make a page or give a reason. I've just reverted as vandalism. Secretlondon (talk) 13:14, 15 May 2013 (UTC)
That IP has a history of vandalism and blocks. — Maile (talk) 13:25, 15 May 2013 (UTC)

extending template:unicode

Could someone please integrate the development at User:ChristTrekker/UnicodeSymbol into template:unicode? (This requires additions to mediawiki:common.css too.) The work's been done for several months, and it's been discussed about as much as I think it's going to be. Consensus seems to be that it's a good idea. It's just languishing now. ⇔ ChristTrekker 15:56, 15 May 2013 (UTC)

Announcing the English Wikipedia Flow Portal

Hello!

As many of you know, the Wikimedia Foundation is now actively engaged in designing a next-generation discussion and workflow system called Flow, initially slated to replace user talk pages. Flow is an ambitious project (on par with the VisualEditor) and will touch nearly every aspect of the Wikimedia experience.

We need your help and input. We have started a portal for information and discussion. You can find it at WP:Flow on the English Wikipedia and at Flow Portal on mediawiki.org (we'll also be opening a discussion on meta as well). At the Flow portal, you can read about what we're doing and why, as well as play around with an interactive prototype.

We're desperately interested in your feedback and thoughts. There are things that we know, and things that we know that we don't know. But there are also things that we don't know that we don't know. And we want to reduce that lack of knowledge.

We will also be conducting additional office hours for a variety of timezones - as many as we need to - and will also be open to having conversations via Google hangouts and/or Skype as need be. I am always around on irc (freenode, username "jorm") and am willing to answer any questions you may have.--Jorm (WMF) (talk) 20:15, 15 May 2013 (UTC)

I'd like to give a huge thumbs up to the entire WMF dev team for their fantastic work and effort to listen to the finicky community that they develop for. We're a difficult bunch, and breaking the third wall is no easy task. Keep it up! Theopolisme (talk) 22:13, 15 May 2013 (UTC)
Thanks! Looking forward to hearing your thoughts.--Jorm (WMF) (talk) 22:16, 15 May 2013 (UTC)

Bar graph for rainfall data

RESOLVED: Data numbers cannot have reftags. -Wikid77 06:09, 16 May 2013 (UTC)

Here's the text of {{Bar graph}} that I tried to use for 2012 Pacific Northwest snowstorm#Rainfall but that generated a punctuation error when I showed a preview of my changes to the page. I'd like to have the data points in decreasing order.

Template text
{{Bar chart
| title       = Precipitation amount ([[inch]]es) at select Pacific Northwest locations, January 18–20
| label_type  = Place
| data_type   = Precipitation
| bar_width   = 35
| width_units = em
| data_max    = 6
| label1   = [[Salem, Oregon]]<ref name=ncdc/>
| data1    = 5.25<ref name=ncdc/>
| label2   = [[Eugene, Oregon]]
| data2    = 4.34<ref name=ncdc/>
| label3   = [[Astoria, Oregon]]
| data3    = 4.10<ref name=ncdc/>
| label4   = [[Portland, Oregon]]
| data4    = 3.50<ref name=ncdc/>
| label5   = [[Olympia, Washington]]
| data5    = 3.05<ref name=ncdc/>
| label6   = [[Tofino|Tofino, British Columbia]]
| data6    = 2.31<ref>{{cite web|url=http://climate.weatheroffice.gc.ca/climateData/dailydata_e.html?timeframe=2&Prov=BC&StationID=277&dlyRange=1942-07-01%7C2013-05-12&Year=2012&Month=1&Day=01|title=Daily Data Report for January 2012: Tofino A, British Columbia|work=National Climate Data and Information Archive|publisher=Environment Canada|accessdate=May 15, 2013}}</ref>
| label7   = [[Seattle|Seattle, Washington]]
| data7    = 1.91<ref name=ncdc/>
| label8   = [[Medford, Oregon]]
| data8    = 1.74<ref name=ncdc/>
| label9   = [[Quillayute Airport]] (Washington)
| data9   = 1.37<ref name=ncdc/>
| label10 = [[Victoria, British Columbia]]
| data10 = 0.94<ref>{{cite web|url=http://climate.weatheroffice.gc.ca/climateData/dailydata_e.html?timeframe=2&Prov=BC&StationID=118&dlyRange=1940-07-01%7C2013-05-13&Year=2012&Month=1&Day=01|title=Daily Data Report for January 2012: Victoria Int'l A, British Columbia|work=National Climate Data and Information Archive|publisher=Environment Canada|accessdate=May 15, 2013}}</ref>
| label11 = [[Klamath Falls, Oregon]]
| data11  = 0.83<ref name=ncdc/>
| label12 = [[Vancouver|Vancouver, British Columbia]]
| data12  = 0.72<ref>{{cite web|url=http://climate.weatheroffice.gc.ca/climateData/dailydata_e.html?timeframe=2&Prov=BC&StationID=889&dlyRange=1937-01-01%7C2013-05-13&Year=2012&Month=1&Day=01|title=Daily Data Report for January 2012: Vancouver Int'l A, British Columbia|work=National Climate Data and Information Archive|publisher=Environment Canada|accessdate=May 15, 2013}}</ref>
| label13  = [[Redmond, Oregon]]
| data13  = 0.25<ref name=ncdc/>
}}

Would anyone know how to format this correctly to show a bar graph of the data? Thanks. Jsayre64 (talk) 02:16, 16 May 2013 (UTC)

  • Move footnote reftags to labels, not data parameters: The reftags at the numbers will cause "Expression error" and so, move the footnotes to the labels, such as label1 = [[Salem, Oregon]]<ref name=ncdc/>. Then the barchart will display fine. -Wikid77 06:09, 16 May 2013 (UTC)
  • The data fields are parsed by {{bar chart/bar}}, which formats them with formatnum. Anything other than a number will generate Expression error: Unrecognized punctuation. Adding help pages to the math error messages is on my todo list. You can place the references in the label fields, add a caption at the bottom with the references or update the template to add a reference field for each data field. --  Gadget850 talk 11:17, 16 May 2013 (UTC)
See: "Wikipedia:Village pump (technical)/Archive_111#Relinking Google for SSL https"
See essay: "wp:Google https links"

This is a continuation of discussions, after archiving earlier threads to /Archive_111, about the pageview counts, such as with stats.grok.se, which have been restored (at 18:44, 14 May 2013) to re-enable the https/ip6 stream to webstatscollector, where Google https-protocol links, for over 300 major articles, had been a problem during late March, April and early May. The typical pageview counts, from March 2013, have resumed in pageviews during 15 May 2013. -Wikid77 (talk) 04:25, 16 May 2013 (UTC)

Confirmed https pageviews resumed 14 May 2013

I have run tests (on 15 May 2013) to verify exact pageview counts for either http or https-protocol, pages or images, on both enwiki and dewiki (German WP also fixed). The pageview data logs, such as for stats.grok.se, have been fixed (at 18:44, 14 May 2013) to re-enable the https/ip6 stream to webstatscollector, where Google https-protocol links, for over 300 major enwiki articles (see stats: 201305/Email or 201305/Parabola or 201305/Shakira, and thousands of wikilinked pages), had been 55%-80% under-reported during late March, April and early May (see essay: wp:Google https links). The typical pageview counts, from March 2013, have resumed in pageviews, as 2x-3.5x times higher for https-prefix pages/images, during 15 May 2013. German WP pageviews were also fixed for different pages (see stats: /de/201305/Euklidischer Raum "Euclidean Space" or /de/201305/Oval). All https page requests had been omitted during 26 March 2013 to 18:44, 14 May 2013, and so there will be permanent low spots in the pageview stats of some pages during those 50 days (~7 weeks), for various articles, images, talk-pages, templates or categories which were viewed mostly via https-protocol links on some of those 50 days. Many thousands of pages/images were not affected, and those pageviews will seem relatively stable during that 50-day period. As of 15 May 2013, the http/https pageviews have been re-confirmed to log exactly "to the penny" and so, if a page/image was viewed 12x times during a day, it will show a total of exactly 12 pageviews for that day. -Wikid77 05:36, 16 May 2013 (UTC)

What's wrong with this template?

{{Italy-painter-17thC-stub}} --Frze (talk) 06:34, 16 May 2013 (UTC)

Stub icon

This article about an Italian painter born in the 17th century is a stub. You can help Wikipedia by expanding it.

 Donehttp://en.wikipedia.org/enwiki/w/index.php?title=Template:Italy-painter-17thC-stub&action=history --Frze (talk) 06:43, 16 May 2013 (UTC)

shortcut icon

Has anyone else noticed the the shortcut icon for wikipedia seems to have changed to <link rel="shortcut icon" href="/enwiki//bits.wikimedia.org/favicon/wmf.ico" />? Technical 13 (talk) 19:09, 16 May 2013 (UTC)

The favicon seems to have gone strange. At some point in the last hour, it's changed from this to something that looks like this although without the words. --Redrose64 (talk) 19:11, 16 May 2013 (UTC)
Ctrl-F5 has switched my tab header icons back to the "W" icon. -- John of Reading (talk) 19:13, 16 May 2013 (UTC)
(edit conflict)(edit conflict)What's even weirder, is that as soon as I submitted this question, the icon changed back to <link rel="shortcut icon" href="/enwiki//bits.wikimedia.org/favicon/wikipedia.ico" /> Technical 13 (talk) 19:14, 16 May 2013 (UTC)
Mine's changed back now, but before posting above, I did try Ctrl+F5 three times to no effect. --Redrose64 (talk) 19:43, 16 May 2013 (UTC)

"coordinates" as a heading doesn't work

=== coordinates ===

why does this section not have a heading? (hint look at the top right corner of the page) Frietjes (talk) 23:31, 16 May 2013 (UTC)

To help others, Coordinates with a leading capital letter works as expected. Chris857 (talk) 00:03, 17 May 2013 (UTC)
MediaWiki generates a span with id="coordinates" because that's what it does with headings, then uses CSS to place it in the top right because that's what it does with things that have the id "coordinates". The devs should probably change the id they use. - Jarry1250 [Vacation needed] 00:27, 17 May 2013 (UTC)
or use a class, instead of an id to place it. Frietjes (talk) 00:29, 17 May 2013 (UTC)
(edit conflict) So the table of contents link and other potential section links will work correctly, I've re-titled this section. You can see what Frietjes is referring to on an old revision of this page.
MediaWiki generates <span id="..."> HTML code for section headings to allow incoming links to the section. The CSS that causes this to be put in the top-right is not part of MediaWiki, but is in our local CSS (e.g. in MediaWiki:Monobook.css and MediaWiki:Vector.css). This CSS is intended for the {{coord}} template, but also applies to this heading because of the matching ID.
{{coord}} calls Module:Coordinates, which includes <span id="coordinates"> in its output. Since this is to do with our templates and site CSS, our own admins can change the ID (either to something less likely to be used as a heading, or into a class).
Using a capital C will fix this in most web browsers, but not Internet Explorer. See also the related discussions about using "Content" as a section header: Wikipedia:Village pump (technical)/Archive 109#.C2.ADContent and Wikipedia:Village pump (technical)/Archive 110#"Content" as section header. There are some other suggested workarounds that are rather hacky, such as inserting hidden characters in the heading. – PartTimeGnome (talk | contribs) 00:57, 17 May 2013 (UTC)

Missing Edit Conflict notifications on talk pages

Had a few examples mentioned by people of talk page conflicts where there weren't correctly notified when trying to save talk pages recently and as a result comments were deleted - anyone else noticed a similar problem that can maybe pin down what is going wrong and why no warning appears? --nonsense ferret 17:13, 16 May 2013 (UTC)

err - as noted in the directly following discussion ;) --nonsense ferret 17:27, 16 May 2013 (UTC)

Edit conflicts

Dear tech people:

I have been taking part in a discussion which is happening partly at Wikipedia talk:WikiProject Articles for creation and partly at Wikipedia_talk:Criteria_for_speedy_deletion#G11_and_AFCs. At least three people involved in this discussion have reported problems with unannounced edit conflicts and therefore missing messages. I see one message that has five edit conflict messages attached, but no other messages. Could this be a technical glitch? Some tempers were flaring... —Anne Delong (talk) 17:20, 16 May 2013 (UTC)

  • I get annoyed when I hit save and get edit conflicts four or five times in a row, but it is what it is... I've never "not gotten" an edit conflict as best as I can tell. Technical 13 (talk) 21:21, 16 May 2013 (UTC)
    • The problem you are reporting sounds like a potential issue in the code of the MediaWiki software or the server configuration. If the problem is reproducible, it would be nice if somebody who has this issue could send the software bug to the 'Bugzilla' bug tracker by following the instructions How to report a bug and providing specific examples where this happened. This is to make developers of the software aware of the issue. If you have done so, please paste the number of the bug report (or the link) here, so others can also inform themselves about the bug's status. Thanks in advance! --AKlapper (WMF) (talk) 09:58, 17 May 2013 (UTC)

(p. s. - I like the [edit] on the right where it doesn't distract from the reading of the article) —Anne Delong (talk) 17:20, 16 May 2013 (UTC)

p. s. - There's a gadget to move the [edit] links to the right, although this shouldn't be the cause of edit conflicts. FallingGravity (talk) 18:15, 16 May 2013 (UTC)
Sorry, I shouldn't have talked about two topics in one post, but since I have, what I meant is that I would like other people to see my articles without the word [edit] next to every title. —Anne Delong (talk) 21:14, 16 May 2013 (UTC)
I moved mine back as soon as I figured out what MWF did to move it in the first place, as I personally find the edit link easier to find all lined up nice and neat out of the way on the edge of the screen. Technical 13 (talk) 21:21, 16 May 2013 (UTC)
BTW. They are not YOUR articles. —TheDJ (talk • contribs) 21:57, 16 May 2013 (UTC)

Help required to auto-update the news from wikinews

Hi, Anyone can fix the issue i faced?
I tried to auto-update news from wikinews in Portal:India. I followed the methodology used in Portal:United States. But it does not work for me.

Link to Wikinews India portal is working fine in the portal page. But the last 5 news items are not appearing in the portal page. Please help me! Thanks in advance! Selvasivagurunathan m (talk) 18:58, 16 May 2013 (UTC)
This seems to be working now; the Wikinews Importer Bot (talk · contribs) has copied the news items. -- John of Reading (talk) 20:53, 17 May 2013 (UTC)

Fixed navbar in Monobook

Hey all (especially people like Edokter and 930913)—I'm using CSS to "fix" the personal-links section on the top of the page, as described at VPPR. In Vector, the bar at the top stretches across ~1/3 of my screen; more than it strictly needs to, but it's fine. In Monobook, the bar stretches across the entire top of the screen, which means it blocks out (for example) section headings when I click on a link in the table of contents. The Monobook and Vector HTML sources aren't exactly the same (which is surprising to me, as I thought the skins were just different CSS sheets, but whatever), but in both skins the links are included in a div id="p-personal"—so why is it different, and shouldn't there be some CSS fix? Any ideas? (And yes, I know this is a preliminary mockup. But it's still annoying.) Ignatzmice•talk 04:22, 17 May 2013 (UTC)

the difference between different skins is not just CSS - there are significant differences in HTML. as to the top menu - this comes from the "p-cactions" part, aka "the hidden menu" (in vector), i.e. the stuff under the inverted triangle. if you are a sysop/admin, you have 3 or 4 more options under this menu. such as delete and change protection, and if you run some scripts or gadgets, such as twinkle, there will be more stuff. there are some tricks that help squeeze this menu a bit, such as rephrasing some of the longer links ("edit" instead of "edit this page", or "+" instead of "add section" etc.
peace - קיפודנחש (aka kipod) (talk) 05:25, 17 May 2013 (UTC)
@Ignatzmice: I made it for vector (as that is what I'm using) and got another editor to test in monobook, who reported what you described. That's why I said vector.css and not common.css at the VPPR ;) If anyone could have a stab at monobook before I find time to, it'd be appreciated 930913(Congratulate) 09:13, 17 May 2013 (UTC)
@קיפודנחש and A930913: Okay, so is there any way I can edit my HTML? Probably not, right? Seems that would be the best way to do it—I tried doing a little CSS using the Monobook-specific IDs, but didn't have much luck. I could try again... Ignatzmice•talk 12:59, 17 May 2013 (UTC)
you can create a small script in your Special:MyPage/common.js that will replace the strings you want to change. in order for this to be effective, you have to have a list of the "element id" and the new text. the "item id" can be obtained by looking at the html code. for instance, the element id for "new section" is "ca-addsection", and the element id for "view history" is "ca-history" (you can't just "guess" - you really have to look. if you use chrome it's extremely easy to find out - you right-click the item and select "inspect element"). so let's say yo want to change the text of "add section" to "+" and "view history" to "hist". the code looks like so:
window.menuNames = {
'ca-addsection': '+',
'ca-history': 'hist'
}

$(function() {
    var key;
    for (key in window.menuNames) 
        $('#' + key + ' a').text(window.menuNames[key]);
})
add as many of those replacements as you want to the "menuName" object, in the form of id : value,, where "id" is the element id you detect and value is the new legend you want for this item. remember to add a comma after every one of them except the last (having a comma after the last annoys IE). some elements might not have an id - especially elements which are added by scripts. changing those is a slightly more challenging task. HTH, peace - קיפודנחש (aka kipod) (talk) 17:52, 17 May 2013 (UTC)

Got it! Thanks, קיפודנחש (aka kipod), but I would actually be wanting to change the div IDs themselves, not the text they contain. But I did it with CSS! After looking at this, I figured out to add: 

width: 34%; //this works for me, YMMV
left: auto; right: 0px; //otherwise it justifies left

All is now awesome! Ignatzmice•talk 03:59, 18 May 2013 (UTC)

  • Oh, right. In order to accommodate the "new messages" bar, the navbar has to be 44% wide (for me, with a full-width browser window). I tried writing a bit of JavaScript to change the width only if needed, but it didn't work out. Ah well. Ignatzmice•talk 04:18, 18 May 2013 (UTC)

Article moved, talk page stuck where it was

I recently moved Noahide laws to Seven Laws of Noah. The mainspace half of the move went through fine, with no problems. The talk page for the article, however, is still stuck at Talk:Noahide Laws, and Talk:Seven Laws of Noah (which is where Talk:Noahide laws should have ended up due to the move) is still a redirect. I'm pretty sure this whole thing isn't my fault, but I haven't been able to pin down an exact cause for it either. The destination talk page's article history doesn't show anything out of the ordinary, as far as I can tell. In fact, it was never anything but a redirect, so I'm a little puzzled as to why the move failed. Evanh2008 (talk|contribs) 06:40, 17 May 2013 (UTC)

 Done Now moved, as are the archive subpages. Although Talk:Seven Laws of Noah was a redirect, it had more than one entry in its history: the second (and only other) edit was the fix of a double redirect. This prevents anyone without the WP:ADMIN right from moving over that that redirect. --Redrose64 (talk) 08:34, 17 May 2013 (UTC)
Thanks! I had guessed it was something like that, but I wasn't sure. Evanh2008 (talk|contribs) 19:18, 17 May 2013 (UTC)

Image preparation advice forum

Do we have a forum which specialises in the technical aspects of preparing an image for upload? I'm getting out of my depth at Help talk:Visual file markup#Avoiding aliasing and TBH I'm at a loss as to how I stumbled on that thread in the first place. User has been seeking a satisfactory response for over a year; the page has only 17 watchers; nine months ago (five months after raising the thread) they were advised to ask at VPT but I can't find any evidence that it was ever done. --Redrose64 (talk) 19:39, 17 May 2013 (UTC)

Wikipedia:Graphics Lab may have editors who can help.--SPhilbrick(Talk) 01:23, 18 May 2013 (UTC)

Embedding musical notation?

I am trying to replace the image at Time signature with the following <score>: <score> { \key c \major \time 3/4 \relative c'' { a f c \bar "|" \hideNotes a \unHideNotes \bar "" } } </score>. However, I cannot get it to embed properly in the Frame; is there markup for this, so that the text around it still appear in the same place, etc.? Thanks. It Is Me Here t / c 16:46, 15 May 2013 (UTC)

What do you mean by frame? --  Gadget850 talk 17:45, 15 May 2013 (UTC)
{ \key c \major \time 3/4 \relative c'' { a f c \bar "|" \hideNotes a \unHideNotes \bar "" } }
  • Avoid using score-tag for common examples: Try to retain typical images for common examples of musical notation, with the alt-text set for sight-impaired (or music-impaired) readers. Currently, the suggested score-tag (see image at right) gives alt=" { \key c \major \time 3/4 \relative c'' { a f c \bar "|" \hideNotes a \unHideNotes \bar "" } } " as the alt-text explanation for the example of printed music. Instead, the image should have "alt=Printed music staff with treble-clef symbol, 3/4 time signature, and 3 quarter notes: A, F, and middle C" or similar. Also, we recently had severe problems with caching of generated images for math-tag formulas, which ran a horrific 105x times slower than showing simple math symbols. Try to "Keep it simple" when writing articles and avoid using templates, math-tags or score-tags when there is a 10x-simpler alternative. Thanks for helping. -Wikid77 (talk) 17:23, 15 May 2013 (UTC)
{ \key c \major \time 3/4 \relative c'' { a f c \bar "|" \hideNotes a \unHideNotes \bar "" } }
Caption comes here.

can contain links, other templates,

newlines etc.
i do not think the advice given by Wikid77 is a good one. we should use tags "score" and "math" wherever it makes sense to use them, and the developers should (and will) solve performance-related issues. as to the OP: i think what you are looking for is template {{Image frame}}, like so:
{{Image frame
|align=right
|content=
<score> 
{ \key c \major \time 3/4 \relative c'' { a f c \bar "|" \hideNotes a \unHideNotes \bar "" } }
</score>
|caption=
   Caption comes here.<br />
   can contain links, <br />
   other templates, newlines etc.
}}

peace - קיפודנחש (aka kipod) (talk) 18:47, 15 May 2013 (UTC)

OK, I have put it in. Regarding the |width= parameter, is there any way (through a template, ParserFunctions or whatever) to measure the width of the PNG generated by a piece of <math> or <score>, so as to be more accurate with these things? Thanks, It Is Me Here t / c 16:50, 18 May 2013 (UTC)

Edit Count on Toolserver

Is there something wrong with the edit count tool on Toolserver? It took a while for it to come up for me, and then said "Alphius does not exist," or something like that (which obviously isn't true). Alphius (talk) 04:09, 17 May 2013 (UTC)

The Toolserver is dying a slow, painful, and agonizing death. See #FYI: Toolserver web tools and bots down. Killiondude (talk) 04:44, 17 May 2013 (UTC)
Well it's not dying yet, there is just a lot of technical problems at the moment. The Toolserver should still be there until 2014, and the tools will have migrated by then to the (hopefully) more stable Tool Labs project. Darkdadaah (talk) 08:37, 17 May 2013 (UTC)
Don't rely on anything on Toolserver working, or even producing accurate results if the tool actually generates output. This bot edit obtains its data from the same source as used by X!'s Edit Counter, yet if it is to believed, my edit count for yesterday - including deleted edits - was negative. --Redrose64 (talk) 10:28, 17 May 2013 (UTC)
  • Also saw category page counts drop 500 then rise 600 in days: The various counts from the Toolserver are also suspicious for pages-in-category counts, where some of the Lua-cite tracking categories showed page-count numbers drop over 500 pages in a few days, then rebound 600 pages higher a few days later, as highly unlikely to be accurate category-count values. For a while in March/April 2013 (not May), the Lua Module:Citation/CS1 (hist) was being changed every few days, to trigger reformatting of 2 million pages (including almost all major articles) which use the wp:CS1 Lua-based cites, and I think that would fry the Toolserver to attempt to mirror the reformat-status or caches of those 2 million pages. However, look for other mega-templates being changed, in May now, to overwhelm the Toolserver with millions of out-of-sync cache pages. Also, remember the live WP database(s) are known to have garbled corrupted data, where the "oldest" revision of some pages will link backward to several future(!) revisions. Perhaps the "poster child" of enwiki database screwups is 1st revision (26 January 2002) of page User:Jimbo_Wales, which links backward to 15 Nov 2004, almost 3 years in the future. So, part of the live enwiki data is garbage, and remember the old adage, "Garbage in, garbage out". In fact, the garbled enwiki storage might indicate the #1 issue of "Top 10 New useful features" as perhaps, "Run a rebuild of the enwiki database(s) to fix revision sequences". -Wikid77 04:59, 18 May 2013 (UTC)
  • And if we were to rebuild the enwiki database so that the revisions were all in chronological order, we'd break every single existing link to old revisions, for a start. And since the rev_id field is the primary key, we'd probably cause all sorts of other problems by changing its value all over the Wikipedia database. Graham87 09:20, 18 May 2013 (UTC)

Notification box in nav bar obscured in IE 9

Tracked in Phabricator
Task T49932

When using the Modern skin through IE9 on Windows 7, if I click my notification square next to my username on the far left of the bar, I can see about 2/3 of the right part of the flyout, and the other 1/3 is nonexistent, trapped in off-window limbo. My first impulse was to try to drag it over, but that doesn't seem to be possible. I do not have this problem through Chrome. I am guessing there is a bug, but I just couldn't find it. Is there a fix? Thanks! Rschwieb (talk) 16:48, 17 May 2013 (UTC)

Known problem. I linked the bugzilla ticket to the right. —TheDJ (talk • contribs) 18:18, 17 May 2013 (UTC)
Thank you! Rschwieb (talk) 12:50, 18 May 2013 (UTC)

Request to add a field to citation templates

Since nobody answered my post at Template_talk:Cite_journal#How_to_give_author_names_in_different_scripts.3F for 3 weeks, I am reposting the problem here: the cite templates should have fields for authors and publisher/publication names in native languages. This is particularly an issue for works using Asian scripts, and may also be of help when dealing with Cyrillic and others. --Piotr Konieczny aka Prokonsul Piotrus| reply here 10:32, 18 May 2013 (UTC)

  • The wp:CS1 cites allow any text in author, title or publisher parameters: Feel free to show other-language text, along with English wp:COMMONNAME text, in those parameters of the wp:CS1-style cites. However, the title data can be placed into dual parameters, as "title=" for original and "trans_title=" for the English equivalent (or also "chapter=" with "trans_chapter="), but the author names can be combined "author2=Jonxxx Doeyvichfu (John Doe)" with the option "ref=Doe1998" to set author-year links by any spelling of the author names. Yet, there has been a design flaw where the trans_title is also linked to the URL, causing wikilinks to be rejected in the trans_title text, and so it should no longer be in the external link [http:...] to "url=" addresses. In general, people have tried to avoid too many new parameter names, which would tend to confuse new users, and also slows the template processing. In fact, the rapid markup Template:Cite_quick (which handles only 50-60 major cite parameters) sometimes runs slightly faster, and allows more templates (omitting COinS metadata), than some of the Lua-based wp:CS1 templates, when numerous parameters are passed into citations. The slowdown seems to be related to the MediaWiki parser having exponentially-slower processing to pass additional parameters, and templates can run faster with data combined into fewer parameters. It is a complex problem, where passing the 99th parameter, seems to require re-processing the first 98 parameters, or such, perhaps to check reuse of prior parameter names, as accumulated slowdown. So, a template with 4,000 parameters runs much slower (4x?) than 2 templates of 2,000 parameters each, such as selecting among lists of thousands of entries. Even changing a template of 200 parameters, into 2 of 100-parameters-each, can run 30% faster by calling 2 rather than 1 template! Anyway, feel free to put multiple-language data into the various current cite parameters. -Wikid77 14:01, 16:15, 18 May 2013 (UTC)

"Arts" Peer reviews transferred to "General" peer reviews?

I noticed that "Arts" section of WP:peer review is blank and that "General" section catches those that intended to be "Arts". I wonder if there was a consensus or a bug on the {{subst:peer review}}. --George Ho (talk) 13:34, 18 May 2013 (UTC)

It was this edit, notice that on the second changed line the word arts has been removed. I don't know whether the other changes have broken other PR topics in the same way. --Redrose64 (talk) 17:02, 18 May 2013 (UTC)

Reminder: use new-section to add new thread

To add a new PUMPTECH thread, below, click: "new section" as otherwise editing the bottom thread, to add another, can cause edit-conflict with replies. I just predicted edit-conflict (which happened) against a new thread, when editing the prior final thread of this page, so I have added this reminder. We need to get Edit-conflict fixed (soon) to handle new bottom threads. -Wikid77 14:01, 18 May 2013 (UTC)

Hiring Community Liaisons

Cross-posting here:

"For the last 18 months, the Engineering & Product Development department has been experimenting with the role of “Community Liaison, Product Development” - a staff member embedded in the Product team and tasked with factoring community concerns into our software development process, keeping editors informed about what we’re doing, and maintaining a dialogue between those who write code and those who write articles.

While there is always room for improvement, I think this role has shown a lot of promise. We have a number of large projects coming down the pipeline (e.g., visual editor, discussion systems) and we need more help reaching out to our contributor communities, especially our non-English speaking projects, as our outreach there has traditionally been challenged. We’d like to recruit a small number of English-speaking or multilingual editors to do the Community Liaison job with different development teams and focuses.

In particular we’re looking for people with a strong history of contributions to our projects who can provide sound and reasoned judgment and are trusted to do so by their community. Speaking other languages in addition to English is a major plus, as one of the objectives here is to ensure we can properly interact with and support non-English projects. I’ve included the full job description below."

Our immediate need is for help with the Visual Editor. We’d like to hire a few community liaisons to help inform different Wikipedia language communities of the upcoming launch, create spaces for feedback and discussion, synthesize feedback for the Visual Editor team, and other activities required to support the Visual Editor launch later this year. If this is a role that would interest you, please e-mail Philippe Beaudette at pbeaudette@wikimedia.org, and if you know someone else who might fit the role, let them know about it :-). We’re provisionally interested in hiring 2-3 liaisons, at an hourly rate commensurate with experience. This can be a part-time role, but we’ll need at least 15 hours/week for the length of the engagement (minimum 3 months). Please do apply if you think it’s a role that suits you, and if you find places we haven’t notified, spread the word! Thanks, Okeyes (WMF) (talk) 16:04, 18 May 2013 (UTC)

The job description:

Background The Wikimedia Foundation’s Engineering & Product Development Department is looking at ways to more effectively incorporate broad community perspectives in decisions and hold dialogues with our editors about the scope, pace and features of upcoming changes to Wikimedia projects. As part of this, it is hiring additional Community Liaisons from our volunteer community.

Scope of Work Support and improve our ongoing software development projects, in particular:

  1. Building up a network of volunteers from both English language and non-English language wikis, increasing the number of projects we can interact with;
  2. Engaging the community in the software development process, by acting as a conduit for community questions, bugs and and feature requests, talking to editors about our work and how they can participate in it effectively, and recruiting them for workgroups and studies;
  3. Being available from time to time to provide expertise and knowledge about our projects, including but not limited to training externally-sourced staff in the way our projects work, answering their questions, and providing expert advice on an ad-hoc basis;
  4. Ensuring that our community is represented in the decision-making process and that our planned software adequately reflects user needs;
  5. Monitoring Wikimedia projects, with the assistance of a network of volunteers, for emerging issues that have an impact on Engineering programmes; and
  6. Other duties as needed

Requirements Effective Community Liaisons will be:

  1. Experienced users of Wikimedia projects, capable of representing our community within the Foundation and vice-versa.
  2. Strong communicators (both verbally and with the written word), able to explain our products to different groups of users with different levels of technical understanding.
  3. Able to focus on the larger picture, understanding which concerns and views are widespread and which are marginal or individual.
  4. Approachable, as both users and product developers must be able to trust these people for the relationship to function.
  5. Self-motivated - they will be given important projects and expected to execute with little to no supervision.
  6. Strongly empathetic - they excel at understanding the perspectives of others and bridging the gap between different approaches to the world.
  7. Willing and able to remain resilient in the face of frustration from our users, in order to get the job done.

Pluses

Other positive attributes or areas of knowledge include:

  1. Diverse language skills. While the Wikimedia Foundation communicates internally in English, we aim to be able to talk to our different communities natively.
  2. Experience with the software development process. You will be thrown into teams that are actively working on new features; having a background that reduces the slope of your learning curve is a plus.
  3. Familiarity with multiple Wikimedia projects is a major plus; we are about more than just Wikipedia.

Wikipedia icon

In IE10 (Win7) I used to see this icon next to Wikipedia pages that I've added to "Favourites". Now I see this icon. However, the IE address bar still shows the former icon. This does not bother me, but I was just curious to know whether Wikipedia operation has changed in this respect or if it's something local to my PC? 86.156.22.226 (talk) 20:28, 18 May 2013 (UTC)

See #shortcut icon above and clear all your cache and cookies. Technical 13 (talk) 21:13, 18 May 2013 (UTC)

Implementing the French slide show template on En

French Wikipedia as the template fr:Modèle:Animation which uses code available to all users in fr:MediaWiki:Common.js (under "diaporama"). Would it be technically feasible to implement the template on en? Brycehughes (talk) 22:54, 18 May 2013 (UTC)

Search and replace regular expression option

I've been experimenting with the regular expression option in the advanced drop down of the edit window and I keep bumping into problems. When I try to do a lookaround I can match the thing I'm looking for but I can't seem to replace it.

For example, in here I can track the placings from 1st to 3rd with "\d (?=\w)", but replace does nothing (even though it tells me 123 replacements are done!). I get a quantifier error when trying to use lookbehind (?<!X) too.

I might just be completely noobing it (I've only just started playing with regex patterns), but I'm a bit lost. Why isn't this working? And, more importantly, why is there no documentation for this tool? SFB 17:45, 15 May 2013 (UTC)

this tool is powered by javascript, and unfortunately, JS regex has a few shortcomings. specifically, it does not support "lookbehind", and is not likely to overcome this anytime soon. peace - קיפודנחש (aka kipod) (talk) 21:31, 15 May 2013 (UTC)
Fair enough, but why does the replace function fail when using a lookahead? SFB 18:22, 16 May 2013 (UTC)
if you are certain the regex you entered is "kosher" and "search and replace" did not execute it correctly, you should probably open a bug in Bugzilla:. make sure the regex you try to execute is correct, e.g. by pasting the article into regex-capable editor, and testing your regex there. קיפודנחש (aka kipod) (talk) 05:35, 19 May 2013 (UTC)
Cool. I'll do just that. Replacing with that regex works here (another Javascript editor) so I guess it's a bug. SFB 10:43, 19 May 2013 (UTC)
Bug reported SFB 11:04, 19 May 2013 (UTC)

Have list: Top 10 New useful features

I have been trying to find ways for people to focus on valuable new features for Wikipedia, to help with real problems. Perhaps if we maintained a list, as a reminder, "Top 10 New useful features" then that list could be used to focus efforts on important things to do. For example, pages need a {Setfooter:} to show a bottom message, such as a reminder ending a talk-page:

  • {{setfooter: End of talk-page — click "New section" to add at bottom.}}

By having a valuable new feature, such as a {setfooter} to display a message at page bottom, then Wikipedia could be improved to help new users know what to do next, when seeing the bottom of various pages. We need to focus on valuable new features for Wikipedia. Add to list below. -Wikid77 (talk) 09:03, 17 May 2013 (UTC)

Top 10 New useful features

The following list contains valuable features which could greatly improve Wikipedia operations.

  1. Have an Edit-merge dialog to autocorrect Edit-conflict and retro-insert new text. -Wikid77 09:03, 17 May 2013 (UTC)
  2. Have a {setfooter} to show a wikilinked message at page bottom, such as more instructions. -Wikid77 09:03, 17 May 2013 (UTC)
  3. Have an option to list categories with page-size after each page title. -Wikid77 09:03, 17 May 2013 (UTC)
  4. Have an option to sort categories by date-edited, after each page title. -Wikid77 09:03, 17 May 2013 (UTC)
  5. New parser function {set:x|7} to store values, such as global options between templates/modules or incremental counters. -Wikid77 13:49, 17 May 2013 (UTC)
  6. Increase template wp:expansion depth limit from 40/41 to 60/61. -Wikid77 13:49, 17 May 2013 (UTC)
  7. New magic-word variable {setsize:3000kb} to raise post-expand include-size limit beyond 2000kb as special request inside larger pages. -Wikid77 13:49, 17 May 2013 (UTC)
  8. Unbundle the admin toolkit Kumioko (talk) 12:58, 17 May 2013 (UTC)
  9. Replace the RFA process Kumioko (talk) 12:58, 17 May 2013 (UTC)
  10. Have an option to view the talk page after the article name when looking at the articles in categories like the one User:Equazion made here. Kumioko (talk) 12:58, 17 May 2013 (UTC)
  11. Improve the new pages feed tool to allow all namespaces to be viewed.Kumioko (talk) 12:58, 17 May 2013 (UTC)
  12. Improve the new pages feed tool to allow group selection of multiple articles at once Kumioko (talk) 12:58, 17 May 2013 (UTC)
  13. Implement some kind of Admin review committee to look into abuse of the admin tools and admin behavior. Kumioko (talk) 12:58, 17 May 2013 (UTC)
  14. Show a category with edit-buttons at each title in list. -Wikid77 13:49, 17 May 2013 (UTC)
  15. Fix the layout when viewing the site from a mobile device in desktop mode so that all of the sites functionality isn't broken by the oversized search box and the globe logo. (screenshot upon request) Technical 13 (talk) 17:06, 17 May 2013 (UTC)
  16. Fix the application so that editors with more than 30, 000 edits can be renamed.Kumioko (talk) 13:06, 19 May 2013 (UTC)
  17. Create a global watchlist so we don't have to go into every single project to check our watchlistKumioko (talk) 13:06, 19 May 2013 (UTC)
  18. Allow users the option of switching their watchlist to a subpage, or a group of subpages instead of a hidden server only location.Kumioko (talk) 13:06, 19 May 2013 (UTC)

(Add more major features to the list above). The list can be expected to grow beyond 10 items, but then prioritize to move the top-10 most-valuable new features up to the top of the list. I will put a copy of this at wp:VPIL Idea Lab to also get suggestions there. -Wikid77 09:03, 17 May 2013 (UTC)

For specific enhancement requests that are considered useful by a number of people it would be nice if somebody could send a feature request to the 'Bugzilla' bug tracker by following the instructions How to report a bug (please try to check first if a request does not already exist in Bugzilla). This is to make developers of the software aware of the idea. Thanks in advance! --AKlapper (WMF) (talk) 10:01, 17 May 2013 (UTC)
I added a few but not all are technical solutions. Also a couple have been brought up before but I will submit them anyway. Kumioko (talk) 12:58, 17 May 2013 (UTC)
What about some new buttons at top of a page? Should there be another option when viewing history-log pages? -Wikid77 13:49, 17 May 2013 (UTC)
i do not understand what is the point of this list (this is not meant to assert there is no point - just that i do not understand it). note that some of the items may not be good changes according to consensus: for instance, i think several of the proposed changes are actually bad. some are not clear (what is meant by "Improve the Recent changes tool to allow all namespaces to be viewed"? i can see all namespaces in recent changes). so each individual proposal needs discussion, clarification, and some way to say "support", or "object". isn't this exactly what wp:vpr is all about? so how is this list productive? peace - קיפודנחש (aka kipod) (talk) 19:43, 17 May 2013 (UTC)
For the new pages tool see here. If you click on Set filters you can see where it only allows editors to select User and Artice. It would be very helpful to be able to see the other namespaces like Book, Category, Template, Project, etc. Kumioko (talk) 20:58, 17 May 2013 (UTC)
I think you meant to put "new pages feed" rather than "recent changes" in your numbered point above. — This, that and the other (talk) 00:52, 18 May 2013 (UTC)
Your right, good catch. Kumioko (talk) 00:57, 18 May 2013 (UTC)
This list is nice, but it would be more useful if it only contained easily actionable technical improvements. Putting "fix RFA" on this list is not really germane to VPT, and the devs can't do much to fix this problem, sadly. — This, that and the other (talk) 00:52, 18 May 2013 (UTC)

Category not updating

Anyone know why Category:Wikipedia semi-protected edit requests hasn't been updated in many hours? It's listing as open requests that were closed many hours ago. I don't think it's me: I purged the page, cleared my cache, and even dumped all my Wikimedia cookies. Rivertorch (talk) 06:11, 19 May 2013 (UTC)

I assume you mean the chart? The category membership itself seems fine to me. The chart is updated by a bot (cf. this page history). It looks like the bot may be broken. Try contacting its maintainer? --MZMcBride (talk) 07:47, 19 May 2013 (UTC)
Duh, I neglected to look at the bottom of the page. I've grown so used to relying on the chart that I'd forgotten there's a regular old category underneath. It looks as if someone already left a message in the right place. Rivertorch (talk) 09:22, 19 May 2013 (UTC)

Wikimirrors, how do they work?

I've been thinking about the problem (in my view, at least) of WikiMirrors mirroring AfC content (e.g. [19]), often very quickly. It would be lovely, but I suspect impossible, to figure out how to delay reporting AfC stuff externally. I presume the mirrors are either scraping Wikipedia (in which case we can't prevent this without blanking our page, which is not going to happen in general), or retrieving the information via the API (in which case not publishing content would make that content unreachable by bots, undesirable because bots do things like copyright checks on the submissions). Still, if anyone has a clever technical solution to this, something that would delay out-of-WP publication of AfCs for a few days until the worst of it had a chance to be vetted for copyrights and attacks, well, that might be worth talking about more. --j⚛e deckertalk 16:59, 19 May 2013 (UTC)

Current method I'm using to remove redlink entries in a set of lists - need faster method

RESOLVED: Use #ifexist to omit 400 redlink lines from a list in 1 second. -Wikid77 07:07, 20 May 2013 (UTC)

I'm removing superfluous redlinks from country outlines.

To remove the redlinks of "Political scandals of foo" (where foo is a country name) from each country outline, I take a list of country outlines (on a user subpage) and replace "Outline of" with "Political scandals of". That list now shows which links are red.

Then I use AWB's listmaker to make a list of all the redlinks on that page, and I paste them back in to the same page and linkify them. Now there's only redlinks on that page.

Next I change "Political scandals of" back to "Outline of". The list is now all the country outlines that contain the "Political scandals of" redlink in them.

I make a list in AWB from that, and then do a regex search/replace with AWB to get rid of the entry in each of those outlines.

Unfortunately, I have to do this whole procedure over again for each redlink I wish to nuke (so as not to nuke the blue links too), and this approach only works with sets of links that share the "of foo" nomenclature. Because AWB has no way to search/replace strings based on redlink status (as far as I know).

If you know of a easier/faster way to do this, please let me know...

Please post replies to Wikipedia:Bot requests/Archive 55#Current method I'm using to remove redlink entries in a set of lists - need faster method. Thank you. The Transhumanist 06:26, 19 May 2013 (UTC)

  • Just use rapid #ifexist for those redlinks or show all links as blue: Although the parser limits the use of #ifexist to 500 conditions, it can be used to choose to show non-wikilinked text at redlinks:
  • {{#ifexist:boguspage|[[boguspage]]|boguspage}} → boguspage
Then, when eventually someone writes the missing page, then the wikilink "magically" returns as a blue-link text. However, another method is to force the link-display text to appear blue, so redlinks look blue but still click to create the new page. Example:
  • [[boguspage|{{color|#1144FF|boguspage}}]] → boguspage
Use a regex editor to update all, or the most-likely wikilinks, to use those methods. Either way, the page will have wikilinks to those pages, once they are created, or to create them when someone clicks a blue-toned redlink. -Wikid77 (talk) 14:09, 19 May 2013 (UTC)
Don't use the second of Editor Wikid77's options because that can confuse reader expectation. Readers are trained to expect that blue links will take them to another article or location. Don't break that training. Better to have redlinks or non-linking text than to have redlinks masquerading as a blue links.
—Trappist the monk (talk) 14:29, 19 May 2013 (UTC)
  • Red text has many meanings now and users can underline wikilinks: Many pages use red text to indicate error conditions (some use "orange" text), and that does not mean the error-page text does not exist. Also, some usernames have the signature set to show red text, often identical to redlink text, or map labels shown in blue when not wikilinked, but editors have learned the red/blue coloring is not mandatory. In the case of a page with many to-be-created subarticles, several editors have complained how the redlinks can be quite distracting, and so the links could be made less distracting by putting blue-links with red-underline (as option "Underline links" in Special:Preferences). As a practical, technical consideration, most readers do not click the wikilinks, and so the red/blue distinction does not even matter that much for page functionality. Also, there have been brown-colored links for small-size pages, and so perhaps the redlinks could be shown as bluish-brown to indicate a difference compared to non-redlinked text. All these options are technical topics, as opposed to debating the "don't use" rules of wp:VPP policy considerations. -Wikid77 (talk) 15:58, 19 May 2013 (UTC)
Yep, pretty much all of that is true. But we're not discussing what colors are used for error messages, nor signatures, nor map labels, nor distractions, nor small pages. Yep, what you've described is a technical possibility but such technical possibilities must be tempered with everyday accessibility requirements and reader-expectations of the articles in main space. Individual editors can make links that they see be anything they like. But, that is not a good reason to allow them, or even recommend to them, that they can or should start making changes contrary to accepted conventions without having first sought and obtained a consensus to do so. You know better and should have so stated when you made that second suggestion.
—Trappist the monk (talk) 16:34, 19 May 2013 (UTC)
  • Compromise as blue-green-colored redlinks or red-underline: I focus more on "how" rather than "do/don't" because I have seen too many thousands of cases of "exceptions to the rule", such as people wanting to link many wannabe new pages, but the whole page shows too much redness. As a compromise, perhaps we can show redlink titles as blue-green links with red-underlining. Example:
  • {{#ifexist:boguspage|[[boguspage]] |[[boguspage|{{color|#1177DD|boguspage}}]]}}
      boguspage
Then, even with many redlink articles, the overall page would show mostly as blue-green-linked text, with just the minor red-underlines in the text for users with Special:Preferences set for option "Underline links". Once each linked title has been created, then the link color would shift from blue-green to typical blue wikilinks. -Wikid77 19:34, 19 May 2013 (UTC)
Per WP:Easter egg: "Keep piped links as intuitive as possible". Changing the link colors has nothing to to with the original request, and it is a bad idea. --  Gadget850 talk 22:45, 19 May 2013 (UTC)
Showing redlink titles as blue-links with red-underlines is just a variation, rather than omitting them. -Wikid77 07:07, 20 May 2013 (UTC)
I doubt WP:AWB identifies redlinks by the color of their font. It probably tests for existence of a page, or checks a redlink flag or something. Where would I find documentation on this stuff? The Transhumanist 00:19, 20 May 2013 (UTC)
AWB doesn't know whether a link references a valid page or not. -- John of Reading (talk) 06:53, 20 May 2013 (UTC)

Deleted edit

This is a very basic question but I've never asked so I don't know. What is a deleted edit and why would any of my edits be deleted? Would it necessarily be because I have done something wrong? Thanks Cls14 (talk) 08:20, 20 May 2013 (UTC)

It means that you edited a page that was later deleted. Your edits were probably fine - only an admin can see them, so I can't comment. In particular, if you've ever tagged a page for deletion, then those edits will be part of your count of deleted edits. -- John of Reading (talk) 08:35, 20 May 2013 (UTC)
Of the 360 or so deleted edits that are credited to you, almost two-thirds are for files. Quite a few of the files that you've uploaded have been moved to commons:, such as File:Frank Nagington Stand New Bucks Head.jpg. These no longer exist on English Wikipedia, so will count towards the deleted edits. --Redrose64 (talk) 11:25, 20 May 2013 (UTC)
Thanks for the information, I am very impressed how fast the community has got back to me about this. I have been meaning for a while to sign up for a Commons account. I think it needs to be done :-) Cls14 (talk) 14:43, 20 May 2013 (UTC)
Deleted edits are not a badge of shame, just saying. On that note, through unified login, you should already have an account on commons... Technical 13 (talk) 15:04, 20 May 2013 (UTC)
Cls14 has an old account and has never unified it.[20] The user name is taken at Commons but based on for example [21] and [22] I strongly assume it's the same user. If you have a working password to the Commons account then you can unify the accounts at Special:Mergeaccount. PrimeHunter (talk) 15:24, 20 May 2013 (UTC)

Job queue question

Hi everyone. Can someone who knows about the job queue chime in on this question about the {{db-c1}} template? I'm not sure if I have all the details correct. Thanks — Mr. Stradivarius ♪ talk ♪ 09:03, 20 May 2013 (UTC)

Applying custom user common.css to mobile site (m.wikipedia.org)

I created a custom user common.css (http://en.wikipedia.org/wiki/User:Vbksdvbkuyvb/common.css).

It works on the normal wikipedia.org site, but not on the m.wikipedia.org mobile site.

What must I do to get this to work on the mobile site?

Thanks.

Vbksdvbkuyvb (talk) 10:57, 20 May 2013 (UTC)

You can try copying the CSS to User:Vbksdvbkuyvb/mobile.css, but I'm not sure the MobileFrontend extension will even look at that file. (It does ignore the sites and users Common.css.) — Edokter (talk) — 10:46, 20 May 2013 (UTC)

Thanks for the suggestion, but I already tried that and it didn't work. (I should have mentioned that in my initial post)

I also tried using the @media handheld CSS directive, but that didn't work, either.

Any other ideas?

Thanks again.

Vbksdvbkuyvb (talk) 10:57, 20 May 2013 (UTC)

Not possible right now. The mobile team is very reluctant in adding 'custom' styling and are working on finding better core solutions to avoid it whereever possible. —TheDJ (talk • contribs) 15:12, 20 May 2013 (UTC)

Thanks for the answer.

My custom CSS is only used to change the color scheme (mainly dark backgrounds with light text, as the white background is too bright for me).

Unless they offer a color scheme preference page, I don't see how they would offer the same functionality as allowing me to write custom CSS.

Creating a color preference page would take much more work on their end than just loading custom CSS if it exists for my user.

From my uninitiated perspective, I don't see why allowing users to implement custom CSS would be that bad.

If I enter my own CSS, it shouldn't bother any other user; I'd know what the CSS is and that I've enabled it, so I'd be left to my own devices to make it work.

Where should I request that custom CSS be allowed for the mobile site?

Thanks again.

Vbksdvbkuyvb (talk) 18:26, 20 May 2013 (UTC)

Labeled section transclusion

Help:Labeled section transclusion has been started. --  Gadget850 talk 17:36, 20 May 2013 (UTC)

That looks hugely powerful, thanks! ~ Amory (u • t • c) 21:09, 20 May 2013 (UTC)

Something's wrong again

Resolved

The dropdown menus aren't working, Twinkle isn't showing up and some of the edit interface is missing as well (and I already tried bypassing my cache). AutomaticStrikeout  ?  18:16, 20 May 2013 (UTC)

I'm having the same technical problem too. Wesley♦Mouse 18:19, 20 May 2013 (UTC)
Javascript is broken somewhere: Uncaught TypeError: Object #<Object> has no method 'hook', somewhere in http://bits.wikimedia.org/en.wikipedia.org/load.php?debug=false&lang=en&modules=ext.centralNotice.bannerController%7Cext.postEdit%7Cext.wikimediaShopLink.core%7Cjquery.client%2Ccookie%2CmwExtension%7Cmediawiki.action.view.postEdit%7Cmediawiki.cldr%2CjqueryMsg%2Clanguage%2Cnotify%2Cutil%7Cmediawiki.language.data%2Cinit%7Cmediawiki.legacy.ajax%2Cwikibits%7Cmediawiki.libs.pluralruleparser%7Cmediawiki.page.startup&skin=vector&version=20130520T181903Z&*. Of course, it does work in debug mode... — Edokter (talk) — 18:23, 20 May 2013 (UTC)

(ec) I'm getting a console JavaScript error "Uncaught TypeError: Object #<Object> has no method 'hook'". This seems to come from a piece of code "mw.hook('wikipage.content').fire(util.$content);". I haven't yet been able to figure out where that code is coming from. When I append ?debug=true to the URL, the error disappears and everything works fine. Ucucha (talk) 18:28, 20 May 2013 (UTC)

    • I think you're right that it's Vector, switching to Monobook appears to have fixed the problems I was seeing (no clock-purge widget, no RefTools "cite" button, etc.) --j⚛e deckertalk 18:32, 20 May 2013 (UTC)

It is being looked at now by devs. During deploy, a user was able to hit a mixed state, which then got cached. —TheDJ (talk • contribs) 18:40, 20 May 2013 (UTC)

Seems to be fixed now. — Edokter (talk) — 18:45, 20 May 2013 (UTC)
Yes. If you're still having problems, you may need to clear your cache. Ucucha (talk) 18:46, 20 May 2013 (UTC)
JavaScript is "mostly" working but seems to be running on some kind of fallback because I've noticed some of the icons being used aren't the same as was there half an hour ago. Anyways, fallback is fine for me! Technical 13 (talk) 18:50, 20 May 2013 (UTC)
Should be fixed for everyone shortly, thanks to Krinkle. If you're still seeing brokenness, clear your cache like Ucucha says. Steven Walling (WMF) • talk 18:51, 20 May 2013 (UTC)

Formatting toolbar not appearing

Formatting toolbar is not appearing (checked from two browsers)! --Tito Dutta (contact) 18:35, 20 May 2013 (UTC)

Vector appears to be broken, see "Something's wrong again" above. --j⚛e deckertalk 18:37, 20 May 2013 (UTC)
apparently it's not broke in debugging mode (aka Heisenberg bug), so as a workaround you can add "&debug=1" to the address line after you hit "edit" to regain the toolbar. this is very poor replacement, and specifically i do not think you can use it once you hit "preview" or "show changes", but in some cases it might be better than nothing... peace - קיפודנחש (aka kipod) (talk) 18:43, 20 May 2013 (UTC)

General Cleanup Service for Bots

Problem

There are lots of "minor" things wrong in articles. These include things like too much/little whitespace, things in the wrong place, and incorrect use of wiki markup.
These "minor" fixes do not warrant an edit of their own (unlike "major" fixes), so they accumulate until somebody comes along looking for them, and happens to find another "major" fix to do at the same time.

The Proposed Solution

  1. Make a service (probably with an HTTP API) that takes in wiki markup, cleans it up and returns it.
  2. Make it ridiculously easy for bot operators to add
  3. Convince mainspace bot operators to use the service.

Why Would it Work?

  • Whenever a bot makes an edit to an article, it would be fixing a load of problems within the article.
  • We would have a central base for these fixes, rather than the fragmented efforts we have at the moment.

Well Why Haven't You Made it Yet?

I can't do this on my own, this needs a framework for collaboration.

What needs to be done?

  • We need to build a service that would take in the wiki markup and pass it around to a medium number of modules in an efficient manner, returning the cleaned version within a number of seconds.
  • We need efficient modules that take the wiki markup, run a particular minor fix and pass it back/on.
  • We need some way of letting people make modules and submit them for approval. Socially approved via BAG? Even if so, still need technical collaboration on modules.
  • We need to run it somewhere. The labs perhaps?
  • We need bot operators to be willing to use this service.
I can help!

Excellent! What can you help with?

930913(Congratulate) 18:42, 20 May 2013 (UTC)

Discussion

Technical Discussion

How could we make it?


This Sounds Awesome!

Please encourage us


This will Never Work

Please elaborate on your critique.

See the recent history of my talk page; a user edited while logged out, and the diffs were oversighted for privacy purposes. As a result, we can't click on some of the radio buttons, but it's still possible to reach redacted versions of diffs by going to older or newer diffs and clicking (prev) or (next). For example, this is unreachable directly from the history page. It's always been this way in my memory, but why? Why can't the link be displayed and simply give us the "You cannot view this diff because one or both of the revisions has been suppressed" message? Nyttend (talk) 18:59, 20 May 2013 (UTC)

That is what the link is giving me. — Edokter (talk) — 19:09, 20 May 2013 (UTC)
No, that's not what I mean; sorry. On the history page, you get something reading
(prev)
Why can't it instead say
(prev)
instead? Why can't we have 13:27, 20 May 2013 instead of 13:27, 20 May 2013 It's not a big deal, but it would seem to me to help navigation without causing problems. Nyttend (talk) 19:39, 20 May 2013 (UTC)

FYI: Toolserver web tools and bots down

Our friendly toolserver admins/roots are aware (see mailing list). In the meantime, migrate to Labs! Theopolisme (talk) 01:12, 12 May 2013 (UTC)

That depends on how much the WMF is willing to pay me. They have a spectacular record of pushing ahead with bad ideas and then ditching them. Not worth the opportunity cost of developing something else for the community. And there's some comfort knowing the WM-DE can run Wikipedia if another image filter debacle comes up. — Dispenser 03:01, 12 May 2013 (UTC)
To put the above in a wider context, Toolserver users (of which I am one) have invested hundreds (if not thousands) of voluntary hours building useful tools to aid in the writing and maintainance of Wikimedia projects like Wikipedia. Differences between the way Labs and the Toolserver work mean that it'll take quite a bit more voluntary effort to move things over. Many (most?) Toolserver users are struggling to justify putting in this work until there's an expectation that Labs will offer some advantage to our tools. - TB (talk) 11:22, 12 May 2013 (UTC)
This worries me greatly. Every system this important should have a backup. What, exactly, would it take to make a backup toolserver that would keep running if the main one went down for an extended period? If funds are required, we can raise our own, independently of Wikipedia. bd2412 T 12:59, 12 May 2013 (UTC)
Let's see ... bare minimum, three server boxes, rack space + pipe, 0.5 FTE admin and a data feed from Wikimedia ... $60k + $60k/year. Realistically, around double these figures to run a useful equivalent as a backup. - TB (talk) 17:06, 13 May 2013 (UTC)
You could run it for way less than that using cloud services like EC2, rackspace cloud, hp cloud, etc.. I recommend using rackspace/hp or one of the other OpenStack based clouds for compatibility with Labs. If you'd like to have independence from WMF, we don't discourage it. Everything we're doing is open source and in Gerrit. I've been building Labs with forkability specifically in mind. I believe our current database replication strategy should make it easier for us to define non-labs replication targets if the community finds it necessary.--Ryan Lane (WMF) (talk) 01:01, 15 May 2013 (UTC)
That's good to know thanks. Not sure how the plan is progressing - are things in a position yet to give and easy estimate of the bandwidth required to accept a feed of the binlogs from PreLabsDBDBS? - TB (talk) 18:34, 15 May 2013 (UTC)
Sorry, no bandwidth estimate at this time. I do have an update on (legal) requirements for this, though. It'll require an NDA for anyone with direct access to the replication and the servers must be located in the US.--Ryan Lane (WMF) (talk) 18:25, 21 May 2013 (UTC)
Far as I know, independence is the underlying problem. German Wikimedia Chapter run Toolserver and don't have enough money. WMF don't want to give them the money and instead will replace Toolserver with something much better, in-house. Someday. Jim.henderson (talk) 13:08, 12 May 2013 (UTC)
Then how can we either support the German Wikimedians in their efforts, or begin our own. We absolutely must have tools that are independent of such "political" concerns. Important repairs can not be done, and are falling behind. bd2412 T 13:22, 12 May 2013 (UTC)
The 2013 WM-DE budget is 5 million € and includes Wikidata development. It is the uncertainty of running a service that is largely dependent on WMF not threatening to cut off the database feed. That feed makes the Toolserver different from other chapter run servers.
The WMF attitude of throwing away and redoing what works deters and detracts programmers ("Why should I make it if its going to be thrown out anyway?") and leads to when announcements are made that work in the area stops. They also internally price volunteer effort at zero dollar; which is why they have so many reader focused initiatives (and helps brings in donations to boot). — Dispenser 14:39, 12 May 2013 (UTC)
I wouldn't worry too much about Labs being ditched. It's an integrated part of WMF's development and testing process (the deployment-prep project) as well as a development and demo location for hackathons and such. It also greatly reduces the load on the operations team as it allows our staff and volunteer developers to make infrastructure changes (and the project is run by the operations team).--Ryan Lane (WMF) (talk) 01:10, 15 May 2013 (UTC)
  • Comment My understanding is that Wikimedia Labs is replacing the toolserver. The WMF planned to stop supporting the toolserver at the end of 2013 in favor of Labs. That caused WMDE to remove their funding, which is 90% plus of the operating costs. From what I've read, the tentative plan is to decommission the toolserver at the end of 2014 and give away the servers. Meaning there will be no toolserver 2 years from now. This is all tentative, but I have not seen any other plans to keep the toolserver running at this point. As far as I know, WMDE will decide what happens on May 25th, 2013 when they get together, but there is something of a Toolserver vs. Labs controversy (see here and here), so who knows what will happen. 64.40.54.26 (talk) 14:54, 12 May 2013 (UTC)
For more information there is https://meta.wikimedia.org/wiki/Future_of_Toolserver but I don't know how up-to-date that is. --AKlapper (WMF) (talk) 09:08, 13 May 2013 (UTC)
That document is rather outdated, as it represents the picture last September while many things were still rather uncertain. I don't think we currently have a clean overview document of the current status, although the current TODO list gives a good idea of the current completion. In practice, any tool that does not need direct access to the replicated database can be hosted in the Tool Labs already (and many already are. — MPelletier (WMF) (talk) 01:40, 15 May 2013 (UTC)
Hi all! WMDE has several reasons to discontinue the toolserver. This is not only about WMF's database dumps or about funding but the whole project is complicated to run the way we've been doing it: The toolserver has grown to become an infrastructure of ~25 servers, that has been taken care of by only two part-time/volunteer admins. (They will be three from now on to improve the situation.) It has become an essential part of community development for Wikimedia projects: Such an infrastructure requires more planning of capacities and a good documentation of the setup. We do not want a project that completely depends on very few individuals. (For example, it should be possible for an admin to leave without the whole project collapsing.) For us, there is a physical barrier, too: The toolserver is in a data center in the Netherlands to which WMDE doesn't have access (WMF has, but nobody is on-site or very close to it permanently). So the process to replace hardware there is always tedious. So the toolserver now has a size and importance that would greatly benefit from a more professional surrounding in organizational matters and we think that WMF can offer this with a bigger ops team (consisting of paid staff and volunteers) and the cloud-based concept that is integrated into a larger setup. As to the most recent status documentation, here are some links: Roadmap for the migration, Overview of features needed in Tool Labs, WMF database plan (for the db replication issue), List of tools running in Tool Labs: http://tools.wmflabs.org/, First draft of FAQ (tbc) That said, WMDE will continue to run the toolserver until Tool Labs is ready and volunteers have had a reasonable amount of time to migrate (one year as you can see on the roadmap). Silke WMDE (talk) 10:29, 15 May 2013 (UTC)

tools:~dispenser

Not sure if this is related to the above post .....but we have some links (as seen below) that are on hundreds of page (mostly project and help pages) that are not working. Will they be returning or should we get a bot to go around and remove the tools?Moxy (talk) 06:21, 12 May 2013 (UTC) tools:~dispenser....like

Yes, it's the same problem. Sounds like Dispenser is refusing to migrate to Labs, which might make things a bit difficult for these tools down the track. In the short term, though, I would expect that they will start working again before long. — This, that and the other (talk) 06:51, 12 May 2013 (UTC)

Also intermittent problems when clicking on geographical co-ordinates on any Wikipedia article, as this also uses toolserver. Getting "Bad Gateway", time-outs and so on. In the meantime I've taken to manually copying and pasting the co-ordinates from the articles directly in to Google maps. Also issues with other tools I use such as GLAMorous - indeed it appears like it is all to do with the same underlying issue. Rept0n1x (talk) 07:39, 12 May 2013 (UTC)

So, now it's a second day without these services. Will it be another two weeks before a decision is made? And perhaps months for something actually to go live? Ought relevant templates such as "coord" be hidden until then? Jim.henderson (talk) 11:44, 13 May 2013 (UTC)
So, an hour later, Geohack etc are working. I hope something steadier can be established soon. Jim.henderson (talk) 12:47, 13 May 2013 (UTC)

DYK tools

This also affects Did You Know, since all nominations there have to be checked for copyvio and close paraphrasing. The tools that I'm aware of affected by this are:

— Maile (talk) 11:58, 13 May 2013 (UTC)

The Duplication Detector now resides at https://tools.wmflabs.org/dupdet/ . MER-C 12:59, 13 May 2013 (UTC)
Thank you! — Maile (talk) 13:11, 13 May 2013 (UTC)

WP:AFC tools

{{AFC submission}} links two of the tools, Webreflinks http://toolserver.org/~dispenser/cgi-bin/webreflinks.py and CitationBot http://toolserver.org/~verisimilus/Bot/citation-bot/doibot.php - both passing the name of the proposed article as a parameter. This appears on the several hundred articles currently backlogged at Category:Pending AfC submissions as a means of cleaning up bare references on newly-submitted pages. These were down but seem to be back up at the moment; will there be more issues with these in the future? K7L (talk) 16:26, 13 May 2013 (UTC)

Year with comma

Tracked in Phabricator
Task T50692

I know - I'm a pedant. I wouldn't do a lot of the WP task I do if I wasn't. But one thing rankles me every time I look at a contribs page, and there must surely be an easy fix to it. Go to your "user contribs" page, and in the box at the top you will find "From year (and earlier): 2,013". Is there some way the comma can be suppressed to make the year numbers right and stop the strange itching I get whenever I see it? It also strikes me as odd that you can check all contributions from, say, 1890 and earlier - but that's an even more minor problem... Grutness...wha? 01:54, 12 May 2013 (UTC)

I don't see a comma. It says 2013 for me. —Designate (talk) 02:07, 12 May 2013 (UTC)
Perhaps it's a problem with the MonoBook skin I'm using - here's a screenshot of how it appears for me. Grutness...wha? 11:22, 12 May 2013 (UTC)
Nope, monobook is fine for me. It could be your browser - are you using Safari on Mac? -- King of ♥ ♦ ♣ ♠ 11:33, 12 May 2013 (UTC)
(edit conflict)Let me guess... you're using a very modern browser? Chrome or Safari, maybe? Your browser is seeing that the year field is described as containing a "number", and so it is kindly providing you with thousand separators and a nice little up/down spinner. However, the separators shouldn't be seen for year values. I wonder if there a way around this in the HTML5 specification... — This, that and the other (talk) 11:40, 12 May 2013 (UTC)
Another possibility could be user scripts. One of those might be interfering. I've not looked at specifics, but I notice that User:Grutness/common.js is lacking a "); from the right-hand end of its single line. --Redrose64 (talk) 11:51, 12 May 2013 (UTC)
Using the Vector skin, I see the comma in Safari (iPad) but not in Firefox. JohnCD (talk) 12:07, 12 May 2013 (UTC)
That's Safari showing the year as a pretty number. The field has type "number", so there is no indication that it is even a year. Ideally, the type should be "month" to combine both fields, but IE and Firefox do not support this type. — Edokter (talk) — 12:35, 12 May 2013 (UTC)
It's curious that the <input>...</input> element allows type=month as an attribute - which is actually a year/month combination - but has no type for year alone. --Redrose64 (talk) 13:23, 12 May 2013 (UTC)
Is there a bug report for this already ? —TheDJ (talk • contribs) 17:04, 12 May 2013 (UTC)
Perhaps https://bugs.webkit.org/show_bug.cgi?id=62939? Although that indicates the bug has been fixed for some time now, and I see correct behavior (no comma, but spinner controls) in Chromium 26. But when Apple will update Safari, I have no idea. They don't seem to make their bug reports public. Anomie⚔ 18:27, 12 May 2013 (UTC)

Sorry I didn't get back to this sooner, yes it's Safari I'm using, but not a very recent one - 5.1.7. Grutness...wha? 02:16, 16 May 2013 (UTC)

Yes that would explain. I don't see a good way to fix this, without javascript trickery (or dropping support of the new HTML5 field validation), which seems a bit over the top to me. I think we better let this one be. I did add it to the tracker, in case others encounter the problem. —TheDJ (talk • contribs) 19:44, 21 May 2013 (UTC)

Special:Nearby lets you see all the Wikipedia articles around you

Hi folks,

Wanted to let you know that there's a neat new feature out on Wikipedia – articles nearby! Anyone on a compatible device (mobile or laptop/desktop device that supports JavaScript and location data) can visit Special:Nearby and see a list of the Wikipedia articles that are near them. This feature relies on the GeoData extension and API, so if you know of an article around you that doesn't show up on the list, consider adding {{Coord}} to it :)

Nearby was originally built for the mobile site, since users on camera phones are able to take a picture of things near them that are missing lead images (designated by the little blue camera icon) and upload to Commons + add a thumbnail to the top of the article in one easy step via the Wikipedia mobile site. But we figured it would be useful for non-mobile users, too :) There's currently one known bug (clicking the search box after loading the page causes some mobile code to leak in and disrupt the experience a bit) but we've got a fix and should have that taken care of soon. Take a look and let us know what you think! Maryana (WMF) (talk) 19:17, 15 May 2013 (UTC)

It's great to finally see this truly integrated. Points to the mobile team for building our very own geo database. —TheDJ (talk • contribs) 19:34, 15 May 2013 (UTC)
Very neat, indeed. It even showed something just a few minutes away by car as the top choice. ♫ Melodia Chaconne ♫ (talk) 22:20, 15 May 2013 (UTC)
An option to display distances in miles would be nice. Killiondude (talk) 22:38, 15 May 2013 (UTC)
Now that Wikipedia knows my location to within 10 metres, do we need an update to the privacy policy? Is this information retained anywhere? -- John of Reading (talk) 06:40, 16 May 2013 (UTC)
Maybe we need something like "Wikipedia is not Grindr". --Redrose64 (talk) 08:21, 16 May 2013 (UTC)
There are two parts. Geolocation, this is done either trough your browser (you gave explicit permission), or trough the geoiplookup api (which also serves geo notices). For the geosearch part, it's interesting. I'm not sure if those are treated separately in the statistics collection process. This statistics are anonimized as much as always, but i'm not sure if extra steps would be required for the geosearch api. We should probably ask the analytics team. —TheDJ (talk • contribs) 09:20, 16 May 2013 (UTC)
John of Reading: No, we are not collecting, storing, or looking at user location data in any way. "Wikipedia" doesn't actually know where you are – your browser does, and if you give it permission, the extension simply locates Wikipedia articles tagged with geo-coordinates close to yours. Maryana (WMF) (talk) 17:17, 16 May 2013 (UTC)
How does this work? My browser must now all coordinates stored on Wikipedia then. Otherwise it has to submit at least some rough location data to the Wikimedia server. --Patrick87 (talk) 09:20, 17 May 2013 (UTC)
I believe the browser is querying Wikipedia for articles near to a given location, which so happens to be your location. When Wikipedia receives this query, it doesn't know this is where you are because the same API can be used to make queries for any arbitrary position (example). – PartTimeGnome (talk | contribs) 21:34, 21 May 2013 (UTC)
Very neat ~ y'all are so clever. Several articles within a couple of hundred metres needing pictures, if i can just work out how to upload them... :) One question, though, not entirely a WP:WP one, just a simple one from a know-nothing: Just how does my browser know where i am? Cheers, LindsayHello 10:25, 17 May 2013 (UTC)
@LindsayH:Here's the explanation from the Firefox people: [23]. Roughly: when Google Street View took a picture of your street, they also remembered the names of all the wireless networks they found. -- John of Reading (talk) 10:52, 17 May 2013 (UTC)
So if my connection is, and always has been, through copper wires, they don't know about me, right? --Redrose64 (talk) 12:12, 17 May 2013 (UTC)
I don't know. They can still geolocate your IP address and read all the hints you've placed on your user page. -- John of Reading (talk) 12:24, 17 May 2013 (UTC)
If you're using a computer that has Wi-Fi capability you don't use, your browser can use your neighbours' Wi-Fi to locate you. Turning off your Wi-Fi radio stops this, of course. (Or you can just decline permission for geolocation when your browser asks.) – PartTimeGnome (talk | contribs) 21:34, 21 May 2013 (UTC)
When I signed up for broadband, they sent me a free WiFi router which also had four network sockets and one network patch cable. Since my computer has no WiFi, I connected using that cable. Almost as soon as I got it going, I turned off the WiFi - if I wasn't going to use it, I didn't want my neighbours getting a free connection. It was probably switched on for about three minutes. --Redrose64 (talk) 23:02, 21 May 2013 (UTC)
Let me get this clear, this special page only "knows" about pages in article that have the {{coord|...}} template attached to them? Just making sure that it doesn't work in WT: or User( talk): drafts. Technical 13 (talk) 10:44, 17 May 2013 (UTC)
Technically, it's any page that uses the {{#coordinates}} parser function, either directly or through a template like {{coord}}. I don't know of any other templates using this parser function. As for draft pages, I know that GeoData tracks these pages (e.g. [24] gives two user pages at present), but I don't know whether Special:Nearby filters them out. I suspect it does filter them, since the GeoData query I linked earlier wouldn't return non-articles until I added &gsnamespace=2 to the URL.
This is pretty cool. I noticed one curiosity in my results. Nearly all of the results were within 2.2 km, but the last entry was for Colorado College, which was correctly described as about 2235 km away. How did that outlier entry sneak onto the list over the innumerable other articles on subjects that are closer than that? older ≠ wiser 12:47, 17 May 2013 (UTC)
I may have found the answer to my question. Seems that until April 19, the article contained incorrect coordinates that placed it in my vicinity. So the function seems to use some stale/stable collection of geodata from the articles to generate a first pass listing, but then also uses more current geodata in the articles to calculate the distance. older ≠ wiser 12:56, 17 May 2013 (UTC)
It would be nice if this feature let me enter an arbitrary location to find articles near to it (as is possible using Marble). Not only would this be useful, but it could eliminate the dependency on JavaScript (automatic geolocation by the browser requires the JS, but users without JS could still use the option to enter a location). – PartTimeGnome (talk | contribs) 21:34, 21 May 2013 (UTC)
Retrieved from "https://en.wikipedia.org/enwiki/w/index.php?title=Wikipedia:Village_pump_(technical)/Archive_111&oldid=1175955034"