Jump to content

Wikipedia:Village pump (technical)

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Whatamidoing (WMF) (talk | contribs) at 20:10, 8 December 2014 (→‎Mass message like extension to help renaming or deleting categories: Bug T77903). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

 Policy Technical Proposals Idea lab WMF Miscellaneous 
Shortcuts
The technical section of the village pump is used to discuss technical issues about Wikipedia. Bugs and feature requests should be made in Phabricator (see how to report a bug). Bugs with security implications should be reported differently (see how to report security bugs).

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


So...

Any plans by the WMF to make their toolserver as reliable as the German one they "upgraded" from? Or are regular outages for tools like edit counter and page stats the new normal? --NeilN talk to me 01:36, 11 November 2014 (UTC)[reply]

@NeilN: I've had the same issue of those 2 tools working for a few days, and then being down or extremely slow the next couple of days. I'm not exactly sure if their toolserver will be upgraded; it would be a nice upgrade, though ;) -Fimatic (talk | contribs) 01:39, 11 November 2014 (UTC)[reply]
@Fimatic: I would suggest going back to the German toolserver would be an upgrade but that might be seen as churlish :-j --NeilN talk to me 01:49, 11 November 2014 (UTC)[reply]
@NeilN: So, it would kind of be like a cross-wiki tool server (hosted on another but used here)? -Fimatic (talk | contribs) 01:51, 11 November 2014 (UTC)[reply]
@Fimatic: Ah, you're new here. Welcome. Many tools, including the two specifically listed, used to run on a server in Germany, outside the direct control of the WMF: Wikipedia:Toolserver. The WMF, in its wisdom, declined to fund its continuing operation and in summer 2014 set up a new architecture in-house. The results have been less than stellar... --NeilN talk to me 02:09, 11 November 2014 (UTC)[reply]
"Edit count" in user contributions and "Revision history statistics" in page histories are both among the Xtools. Xtools have been on and off for a month. They are hosted at Tool Labs but made by volunteer editors. I don't know the cause of the down periods but many other tools at https://tools.wmflabs.org are currently working. One of the Xtools authors User:Cyberpower678 said at Wikipedia:Village pump (technical)/Archive 131#Xtools / edit counter that GitHub is the best place to report bugs. That means https://github.com/x-Tools/xtools/issues. PrimeHunter (talk) 02:13, 11 November 2014 (UTC)[reply]
What PrimeHunter said. If Xtools are not working but other tools on Tool Labs are, then it's probably something to do with Xtools' configuration rather than a problem with Tool Labs itself. But we will have to wait for someone to investigate before we can find out for sure what's happening. — Mr. Stradivarius ♪ talk ♪ 02:54, 11 November 2014 (UTC)[reply]
@NeilN: I'm newer than some people, but not exactly. My first edit with an IP was around 2 years ago (although I've only made a few with my IP), and I've had a past account here which was registered in early August. -Fimatic (talk | contribs) 03:43, 11 November 2014 (UTC)[reply]
  • There are no current outage of Tool Labs as a whole, though there was a brief (~4h) outage last week caused by a hardware fault; but my understanding is that the tool's maintainer, Cyberpower678, is currently away from the projects. I took the liberty of restarting the xtools's webservice – which appears to have hung for some reason – but I'm not in a position to debug the setup to diagnose the problem more precisely. — MPelletier (WMF) (talk) 20:51, 11 November 2014 (UTC)[reply]
NeilN this looks like typical nostalgia: first of all, closing toolserver was not a decision of wikimedia - it was a decision of the german chapter. as far as i remember, the maintainer of toolserver announce that the current setup (hw, hosting, infrastructure) was EOL, and the foundation decided not to pay for an upgrade (i did not see the projected budget/cost, but it wan an expensive setup). my guess is that the residual cost of wmflabs, being a par of much larger setup, is significantly lower. regarding "how great life was with toolserver" - this is not what i remember. even before the last days, when the setup was crumbling and outages were a daily occurrence, i do not remember toolserver as especially reliable, and it had many outages. it also had this annoying behavior of shutting down accounts of users who did not log in for 6 months, so tools written by people who became inactive would stop working at unpredictable times, and we had to hunt for the editor and beg them to login to their toolserver account, which gave us a "fix" for the next 6 months... (amusing anecdote: iirc, at one point some tools in Brion's account were shut down because he did not login to the toolserver for 6 months...). קיפודנחש (aka kipod) (talk) 21:32, 11 November 2014 (UTC)[reply]
"EOL" = "end of life". --Anthonyhcole (talk · contribs · email) 08:23, 24 November 2014 (UTC)[reply]

I'll tag along here rather than make a new section...something over a year ago, i noticed a couple of days worth of edits disappeared from the records; i put it down to Toolserver going away. The same thing happened a few days ago (27 October, to be precise), and about 80+ of my edits were (and are) no longer showing in either Xtools or others which presumably access the same data. While it's a bit annoying, a new question arises from it: How, if there are gaps in the database, is there a proper attribution record of everyone who has contributed? Isn't that potential lack of a record contrary to the terms of the licence? Cheers, LindsayHello 12:27, 12 November 2014 (UTC)[reply]

The page history on the "View history" tab is where the license should be satisfied. Holes in external tools don't seem like a license problem to me. Such tools could shut down completely at any time without affecting the attribution required by the license. It's possible that some reusers use an external tool for attribution and don't link to the wiki page or its page history. Stable external tools could reduce this problem slightly, but the number of reusers which give no attribution at all is far larger. PrimeHunter (talk) 12:46, 12 November 2014 (UTC)[reply]
Oh, i see. So, the assorted tools get their data from a different location than the history page does? Fair enough. I wasn't really worried about it, more curious, and you have satisfied that; thank you. Cheers, LindsayHello 23:32, 12 November 2014 (UTC)[reply]
Last night the edit counter told me it was running 900+ minutes behind, so my edit count for the previous 24 hours was zero. Today (Philippines, UTC+8) edit stats says it is 1500+ minutes late, so my edit count is still zero. Seems like it has got stuck somewhere. Unbuttered parsnip (talk) mytime= Thu 08:49, wikitime= 00:49, 13 November 2014 (UTC)[reply]

...so they seem to be working right now. Woohoo! This is irritating beyond belief. We're doing volunteer work here, unpaid labor, and somewhere is a bankaccount where all these donations are coming in, out of which someone should pay someone smart so we can do this work decently. Seriously. SERIOUSLY. I don't care about chapters or organization or whatever. If folks used to do this for free, I thank them from the bottom of my heart. But someone in San Francisco needs to take an executive decision and make this work consistently and well. Drmies (talk) 18:15, 15 November 2014 (UTC)[reply]

...and it's not working again. Narutolovehinata5 tccsdnew 14:15, 17 November 2014 (UTC)[reply]
... but keep those donations rolling in, folks! Even if they don't contribute directly to the content of Wikipedia, or provide the improvements its contributors have come to rely on. -- llywrch (talk) 00:42, 18 November 2014 (UTC)[reply]

Tools

Do you think that the communities would appreciate the WMF taking over something that's popular, like X! Tools, or would this be perceived as the WMF encroaching on the volunteers' territory and disrespecting them? What if the WMF decides to re-write it (as volunteers periodically do), but you don't like the new version as well? Would you be able to live with that, in return for (possibly) more reliable maintenance (I say "possibly" because some volunteer devs and tool maintainers have been providing top-quality support for years, so in that case you can't really expect an improvement). What do you think? Whatamidoing (WMF) (talk) 01:13, 18 November 2014 (UTC)[reply]
I'd rather see the WMF just make Toollabs a more stable platform to host on, and let the tool creators maintain their tools. KonveyorBelt 03:19, 18 November 2014 (UTC)[reply]
@Konveyor Belt: The bug is probably in Xtools, not Tool Labs itself. The solution to this is for someone to find out whatever is making Xtools fail sporadically and fix it, and once it's fixed it will stay fixed. Tool Labs is actually showing itself to be a pretty reliable platform by not failing every time Xtools does. (And if anyone here likes debugging php/js, the code is on Github.) — Mr. Stradivarius ♪ talk ♪ 10:57, 18 November 2014 (UTC)[reply]
@Whatamidoing (WMF): I don't know which is more discouraging to think about: that donations to the Foundation do not directly help the volunteers create an encyclopedia & other reference sources, or that many volunteers don't trust the Foundation to actually help them achieve these goals. I would happily ignore the Foundation & its silliness, were it not for the fact it raises millions of dollars which it fritters away on badly-designed & unwanted projects it imposes on unwilling communities, while volunteers like me have to fund the research needed to write & improve content from our own pockets -- which is what the end users come to Wikipedia for, not K-RAD K3WL bells & whistles. -- llywrch (talk) 07:16, 18 November 2014 (UTC)[reply]
I haven't spent much time looking at the budget, but I've got the impression that most of it is indeed helping volunteers fulfill educational goals—just not specifically helping established, first-world editors (like you and me) add content to the world's largest reference source. In addition to spending several million dollars just on basic operations (their "internet bill" is a couple million each year by itself), projects like Wikipedia Zero are not free, and they make a few million dollars in grants each year, with an emphasis on the Global South and developing countries. I believe that all of the "engineering and product" expenses amount to less than half the total expenses each year, and some of that work is definitely wanted by very willing communities. This year, they are spending more than a million dollars on making the sites run faster, and I haven't seen anyone complain about that. Note, too, that some projects are not paid for by donations, but by specific grants. The first years of VisualEditor's development were paid for by a grant, even though producing a rich-text editor was one of the top priorities identified by editors at strategy.wiki, and so you might have thought that spending money on it would mean spending money on what editors wanted. (As a side note: VisualEditor's popularity varies significantly by language. About half the editors at the Portuguese Wikipedia are using it on any given day, but it's only a quarter of users at some other languages. I wish that I knew why.)
You are, however, correct that the WMF never pays for content.
I asked this question because some WMF staff know that there are some great tools (or tools that could be great, with a re-write) in a few of the larger projects. Most of them aren't available at smaller projects. One conversation has been whether it would be desirable, from the perspective of the volunteers, to incorporate one or more of those tools into MediaWiki and for the WMF to provide support for it. HotCat has been mentioned as an example. It occurs to me that some users might get more value out of having one or more of the X! Tools supported. But it also occurs to me that if writing and maintaining a tool like that were what I did for fun, then I might not appreciate the WMF taking it over, and, as you say, providing a "revision history search" isn't exactly "directly help[ing] the volunteers create an encyclopedia", so maybe you would see that as just money "fritter[ed] away on…K3WL bells & whistles".
Anyway, if anything's going to happen with this idea, then there will be an opportunity for people to talk about which tools they think are most important, and I'll make sure to post a note here at VPT about it. Whatamidoing (WMF) (talk) 18:59, 18 November 2014 (UTC)[reply]

My guess is xtools has some sort of memory leak that eventually leads to timeouts. Supercount just a little bit less so, eventually giving a response. Judging by what MPelletier (WMF) and Cyberpower678 are saying, a restart seems to fix the problem? Whatamidoing (WMF) if an occasional restart is all that's needed, I wouldn't think the developers would be that offended, especially since they are trying to take an intentional break from the project. Anything beyond that may require a larger discussion on whether the WMF can takeover tools should the loss of the service be a detriment to the project. — MusikAnimal talk 06:19, 18 November 2014 (UTC)[reply]

Given the history in the foundations deployment of software, and how well it's been received, echo, flow, the loss of the OBoD, I would be opposed to having the foundation take over xTools. Anyone is free to suggest patches on GitHub, to help fix memory leaks, if any. I think there might be too much load on xTools, given the restrictions imposed by tool labs, is causing the load times to increase, and some people try to refresh mid load, increasing memory usage, and eventually crashing the web service. xTools is a highly used tool. I think it's time for it to move to its own instance. As for super count, something I wrote on my own, I don't see memory leaks being an issue, but slow DBs do cause slow load times, which leads to refreshed mid-load, etc. I will do some thorough looking into next week to see what the culprit is.—cyberpower ChatAbsent 14:27, 18 November 2014 (UTC)[reply]
Supercount, albeit slow, is an adequate substitute for the regular edit counter, at least so long as there is an expectation that the regular edit counter will be fixed and back up to speed soon. But is there a alternate tool or tools for "Revision history statistics"? I've looked and can't find one. Also, I'm not a coder or database maven so what I'm about to ask may be roll-your-eyes stupid to those of you who are, but would it be possible to write a simple tool which, in the interim, restarts the Xtools every couple of hours? Regards, TransporterMan (TALK) 15:27, 18 November 2014 (UTC)[reply]
Hedonil wrote a gadget for the web service, called web watcher, which monitors the service of xtools, and did a pretty bang up job, until we all switched to Big Brother, another Labs concoction, that doesn't seem to be reliable. All tools are slow as long as the DB takes forever to deliver the results. Lately, the database has been working slowly and not been keeping up with replication. The WMF Labs staff in charge of those DBs really don't seem inclined to do anything about it, meaning you can expect slow results for a while longer. Supercount and xtools will operate faster if the DB responds as fast as it used to when replication was first introduced to labs. ATM, I wish I was on tool server. At least that seemed to be more stable.—cyberpower ChatAbsent 15:50, 18 November 2014 (UTC)[reply]

supercount has pretty large security holes in it. I wouldn't advise anyone to use it. Legoktm (talk) 01:34, 19 November 2014 (UTC)[reply]

What do you meany by 'security holes' - apologies if I've missed something somewhere, genuinely curious! Reticulated Spline (t • c) 01:58, 19 November 2014 (UTC)[reply]
Cross-site scripting ones specifically that were reported to the maintainer nearly a month ago that still haven't been patched. Legoktm (talk) 02:36, 19 November 2014 (UTC)[reply]
If you haven't noticed, I haven't been very active. But even so, grabbing a the OAuth session cookie of a user OAuthed into the tool, will not get very far, because they need the secret key to get it to work, and the cookie does not save that. That made no sense actually since my tool reads the cookie and all a user has to do is replace their own with the stolen cookie. I advise not using OAuth on the tool for the time being and logging out if you're logged in, per Legoktm.—cyberpower ChatAbsent 13:14, 19 November 2014 (UTC)[reply]

Valuable tools should be turned into MediaWiki core features or MediaWiki extensions. In my opinion, relying on Wikimedia Labs is a bad idea for the same reason that relying on the Toolserver was a bad idea. It's great for quick scripts and demos and proofs-of-concept, but it simply doesn't have the same quality control and consequently the same level of uptime and performance as the production cluster. --MZMcBride (talk) 05:22, 19 November 2014 (UTC)[reply]

MZMcBride, or anyone else who's interested:
If you made a list of the "valuable tools" that should be turned into MediaWiki core features or MediaWiki extensions, what would be on the list? My own list would unfortunately look a bit too much like "the couple of tools I use", so I'd love to hear suggestions from people with broader experience, or tools that are only in use at other projects. Please let me know—post here, send me e-mail, add lists on my talk page, send singing telegrams to the office, whatever works best for you. Whatamidoing (WMF) (talk) 21:25, 25 November 2014 (UTC)[reply]
Whatamidoing (WMF), why wait for a complete list? Start with XTools which is the one causing the most aggravation judging by the mentions here and elsewhere. --NeilN talk to me 14:31, 26 November 2014 (UTC)[reply]
I would argue that page and user statistics, similar to those provided at 'Revision history statistics' and 'Edit count', should be a standard service provided by Wikipedia (MediaWiki) and it should guarantee a minimum service level regarding up-time and performance.--Wolbo (talk) 21:39, 4 December 2014 (UTC)[reply]
Whatamidoing (WMF), I need the range block calculator, which has not been operational for at least a month. Thanks, -- Diannaa (talk) 04:26, 6 December 2014 (UTC)[reply]

Survey

Whatamidoing (WMF) (and others), I noticed the link to the new Tools survey on top of my watchlist and thought, "Great! Some progress in this area!" Then I actually took the survey. My thoughts are here. Warning - they're not pretty. --NeilN talk to me 23:29, 4 December 2014 (UTC)[reply]

Chrome vs. Firefox Wikipedia rendering

Chrome vs. Firefox Wikipedia rendering

I don't know if it's a MediaWiki bug or just Wikipedia, but it's time to code same appearance for major browsers like Firefox, Chrome and Internet Explorer. There are some bugs:

  • different font sizes
  • white-space break doesn't work in Chrome in Infobox

--Rezonansowy (talk | contribs) 13:11, 18 November 2014 (UTC)[reply]

  1. Actually, it's a different font; Firefox seems to use Verdana as default sans-serif; browser setting.
  2. The wider infobox is caused by the URL at the bottom of the infobox; Firefox handles this better.
Different browsers will always handle stuff slightly differently. -- [[User:Edokter]] {{talk}} 14:36, 18 November 2014 (UTC)[reply]
You could add "word-break: break-word;" to either the infobox table cell containing links, or to the Module:URL. —TheDJ (talk • contribs) 16:56, 18 November 2014 (UTC)[reply]
That will get you ugly breaks like "pd<break>f_links". How about a descriptive link instead? -- [[User:Edokter]] {{talk}} 19:46, 18 November 2014 (UTC)[reply]
And we should also set default font for Wikipedia (it could be changed via common.css). Please support me, Chrome users should see the same thing as the others. --Rezonansowy (talk | contribs) 17:12, 18 November 2014 (UTC)[reply]
Remember Typography refresh? We tried setting a font... it did not go to well. As far as I can see, Chrome uses the same fonts as the "other" browsers (on Windows at least). -- [[User:Edokter]] {{talk}} 19:46, 18 November 2014 (UTC)[reply]
I'm reminded of <http://dowebsitesneedtolookexactlythesameineverybrowser.com/>. :-) --MZMcBride (talk) 05:25, 19 November 2014 (UTC)[reply]
Just fix this word-break bug and will be ok. --Rezonansowy (talk | contribs) 12:15, 19 November 2014 (UTC)[reply]
Hi. Is it possible to tweak Module:URL to emit zero-width non-joiner after ".", "/" and "_"? Best regards, Codename Lisa (talk) 01:55, 21 November 2014 (UTC)[reply]
Is no one willing to comment on this suggestion? May I take this instance of silence as consensus and implement it? Redrose64, I thought you said you were watching this discussion. Can I have your opinion on this please? Codename Lisa (talk) 02:36, 23 November 2014 (UTC)[reply]
As I remarked at Template talk:Infobox#Rendering issue, I have indeed been watching this discussion, but as I also noted there, I see no clear indication of a solution which will not break other uses. I need to see at the very least a firm proposal for a change, and a demonstration of that change (see WP:TESTCASES). If part or all of the proposed solution involves a change to a module (whether that be Module:URL, Module:Infobox or another), I'm not going to implement it: I very rarely edit modules, mainly because as an experienced computer programmer, I know well enough not to alter code that I do not understand. --Redrose64 (talk) 14:39, 24 November 2014 (UTC)[reply]
Village pump (technical)
Websitehttps://www.adobe.com/devnet/pdf/pdf_reference_archive.html
@Redrose64: Very well, I have a firm proposition. HTML5 has adopted <wbr />, which have had widespread browsers support long before standardization. I propose changing Module:URL to insert one such tag after ".", "/" and "_". It is standard, supported, tested and working.
Best regards,
Codename Lisa (talk) 04:19, 26 November 2014 (UTC)[reply]
A soft hyphen has better support. -- [[User:Edokter]] {{talk}} 09:37, 26 November 2014 (UTC)[reply]
I am tempted to ask "what constitutes better support?" but I am afraid soft hyphen leaves a visible hyphen. That's extremely dangerous because links may contain hyphens themselves. Therefore, soft hyphen nullifies the print utility of the bare link. So, as long as there is nothing wrong with <wbr />, I am going with a firm "No". Best regards, Codename Lisa (talk) 11:52, 26 November 2014 (UTC)[reply]
The <wbr /> idea has been proposed before, see Wikipedia:Village pump (technical)/Archive 117#nowrap vs please-wrap-here option? and Wikipedia:Village pump (technical)/Archive 129#"Word wrapping" very long words. But where has the current proposal been sandboxed and tested? --Redrose64 (talk) 12:47, 26 November 2014 (UTC)[reply]
So practically, you are saying "I like it! Let's do it. But first implement one in sandbox." Only I seem to have misinterpretted your message as opposition. Well... Best regards, Codename Lisa (talk) 15:26, 27 November 2014 (UTC)[reply]
Better support means more browsers support it, as <wbr /> is HTML5 only. Soft hyphens have existed much longer and enjoy universal support. It may show a hyphen at the break point, but such would not be part of the string, so copy/paste is safe. And printed links can't be clicked anyway. -- [[User:Edokter]] {{talk}} 20:10, 27 November 2014 (UTC)[reply]
You couldn't be more wrong. You could try; you will fail. Chrome and Firefox supported WBR since v1.0. Safari since v4.0. Opera since 11.7. IE since v5.5. Printed URLs are typed in; with soft hyphen, users must figure out which hyphen is part of the URL and which is not. Best regards, Codename Lisa (talk) 20:44, 27 November 2014 (UTC)[reply]
I don't know where you get your info... <wbr /> is new in HTML5. Firefox does have support since 3.0, and IE dropped support since 8.0. -- [[User:Edokter]] {{talk}} 21:17, 27 November 2014 (UTC)[reply]
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/wbr
Codename Lisa (talk) 21:25, 27 November 2014 (UTC)[reply]
Testcase at User:Codename Lisa/sandbox proves this tag has full support in IE 8, 9, 10 and 11. I must get my hands on 7 somehow. Best regards, Codename Lisa (talk) 21:29, 27 November 2014 (UTC)[reply]
IE6 passed the test. Codename Lisa (talk) 22:03, 27 November 2014 (UTC)[reply]
IE7 passed the test. Codename Lisa (talk) 23:02, 27 November 2014 (UTC)[reply]
Mobile browsers seem to lack support; somewhere where this is most needed. So apart from someone typing a printed link... what is the major problem with &shy; again? -- [[User:Edokter]] {{talk}} 22:40, 27 November 2014 (UTC)[reply]
Mobile testing results are coming through, but so far, they look good. Still, you'll have to wait. Screenshooting all I want takes some times.
Did you say "Apart from?" Print-friendliness is the only purpose of {{URL}} and as long as a problem that defeats its very purpose exists, there is no "apart from". It's a blocking issue. Best regards, Codename Lisa (talk) 23:25, 27 November 2014 (UTC)[reply]
From mobile - fails to wrap anything before first / after domain with userAgent="Mozilla/5.0 (X11; Linux x86_64; rv:33.0) Gecko/20100101 Firefox/33.0". — {{U|Technical 13}} (e • t • c) 00:49, 28 November 2014 (UTC)[reply]
Screen spec please. Best regards, Codename Lisa (talk) 02:42, 28 November 2014 (UTC)[reply]
P.S. In case things are made worse than the original, I am going to need a screenshot. Best regards, Codename Lisa (talk) 02:45, 28 November 2014 (UTC)[reply]
  • I can't do screenshots on that device. It uses Android OS 4.1.2 and the built in screenshot feature doesn't work correctly most of the timethe old version of the Android OS (v3.x) that doesn't have it built in and none of the apps that are suppose to do it seem to work that I've tried (they all lock up the phone and I have to pop the battery to restart it). I can tell you that whatismyscreenresolution.com tells me it is a 320x533px screen. Any other information I can provide that may help, I'd be happy to. — {{U|Technical 13}} (e • t • c) 02:41, 29 November 2014 (UTC)[reply]
@Technical 13: Your screenshot shows the wrong portion. The "Encoded URL" portion is where you must look. Also it says "Linux x86_64" in the User-Agent. This is no standard Firefox user-agent. Something is not right. What device is it? Best regards, Codename Lisa (talk) 03:33, 29 November 2014 (UTC)[reply]
Strange! Samsung Galaxy Axiom runs on an ARM-based CPU called Krait. Your phone is allegedly running an x86-64 version of Firefox. Also Axiom runs Android v4.0.4, not 4.1.2. You know, I am growing anxious to see the missing screenshot. Best regards, Codename Lisa (talk) 05:54, 29 November 2014 (UTC)[reply]

Actually... My phone is running 4.1.2 since I keep making sure it's updated at least once a month. I have the screenshot, and emailed it to myself. Will upload it to commons tomorrow. — {{U|Technical 13}} (e • t • c) 06:05, 29 November 2014 (UTC)[reply]

@Technical 13: Why does your table entry say "Word break+Overflow"? I am seeing a slight overflow but not a word break. Also, other stuff in your screenshot doesn't look like anything I see in other screenshots. Looks like something on your smartphone is broken. Are you sure you opened en.m.wikipedia.org/wiki/User:Codename_Lisa/sandbox? Fleet Command (talk) 04:11, 30 November 2014 (UTC)[reply]
@Technical 13: X11... You must be kidding me. It's a useragent from the desktop Firefox. Zhaofeng Li [talk... contribs...] 06:50, 30 November 2014 (UTC)[reply]
Looks like you have "Request Desktop Site" selected. Wasn't aware Firefox spoofs the user agent string like this. Uncheck that and see if anything changes. Zhaofeng Li [talk... contribs...] 08:11, 30 November 2014 (UTC)[reply]
Zhaofeng Li, my userAgent changes to Mozilla/5.0 (Android; Mobile; rv:33) Gecko/33.0 Firefox/33.0 when I uncheck that. — {{U|Technical 13}} (e • t • c) 15:29, 30 November 2014 (UTC)[reply]
File:FF33 on Android OS 4.1.2 (3).png && File:FF33 on Android OS 4.1.2 (4).png show it makes no difference. — {{U|Technical 13}} (e • t • c) 15:56, 30 November 2014 (UTC)[reply]
@Technical 13: I order to conclusively resolve all doubts, I believe we need a screenshot from http://en.m.wikipedia.org/w/index.php?title=User:Codename_Lisa/sandbox&oldid=636147649, which contains no new code. For your convenience, I've added this link to en.m.wikipedia.org/wiki/User:Codename%20Lisa/sandbox. Best regards, Codename Lisa (talk) 09:40, 1 December 2014 (UTC)[reply]
P.S. Thanks in advance for all your troubles. Best regards, Codename Lisa (talk) 03:28, 2 December 2014 (UTC)[reply]

Test results

  • Presenting test results, with screenshots:
Browser Without WBR With WBR User-agent
Screenshot
Chrome 38 (Windows) Overflow Okay Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/38.0.2125.111 Safari/537.36 [1]
Chrome 39 on Android 4.3 (ASUS Padfone A11) Word break Okay Mozilla/5.0 (Linux; Android 3.4; PadFone T00C Build/JSS15Q) AppleWebKit/537.36 (KHTML, like Gecko) Chrome 39.0.2171.59 Mobile Safari/537.36 [2]
Chrome 34 on Android 4.4.2 (LG G2) Word break Okay Mozilla/5.0 (Linux; Android 4.4.2; LG-D802 Build/KOT49I.D80220c) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.114 Mobile Safari/537.36 [3]
"Internet" on Android 4.4.2 (LG G2) Word break Okay Mozilla/5.0 (Linux; U; Android 4.4.2; en-us; LG-D802 Build/KOT49I.D80220c) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/30.0.1599.103 Mobile Safari/537.36 [4]
Chrome 38 on Android 4.0 (emulator/Sony Xperia) Word break Okay Mozilla/5.0 (Linux; U; Android 4.0; en-us; LT28at Build/6.1.C.1.111) AppleWebKit/534.30 (KHTML, like Gecko) Version/4.0 Mobile Safari/534.30 [5]
Chrome 38 on Android 4.0 (emulator/iPhone 4) Word break Okay Mozilla/5.0 (iPhone; U; CPU iPhone OS 4_2_1 like Mac OS X; en-us) AppleWebKit/533.17.9 (KHTML, like Gecko) Version/5.0.2 Mobile/8C148 Safari/6533.18.5 [6]] [7]
Firefox 3 (Windows) Okay Okay Mozilla/5.0 (Windows; U; Windows NT 6.2; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0 [8]
Firefox 33 (Windows) Okay Okay Mozilla/5.0 (Windows NT 6.3; rv:33.0) Gecko/20100101 Firefox/33.0 [9]
Firefox 33 on Android 4.4.2 (LG G2) Okay Okay Mozilla/5.0 (Android; Mobile; rv:33.0) Gecko/33.0 Firefox/33.0 [10]
Firefox Mobile (emulator) Okay Okay Mozilla/5.0 (Mobile; rv:32.0) Gecko/20100101 Firefox/32.0 [11] [12]
Internet Explorer 11 (Windows) Overflow Okay Mozilla/5.0 (Windows NT 6.1; Win64; x64; Trident/7.0; rv:11.0) like Gecko [13]
Internet Explorer 8 (Windows) Overflow Okay Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0) [14]
Internet Explorer 7 (Windows) Overflow Okay Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) [15]
Internet Explorer 6 (Windows) Boundry violation Technically, okay Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) [16]
Opera Mobile 12 (Nokia N79) Okay Okay Opera/9.80 (S60; SymbOS; Opera Mobi/SYB-1204232255; U; en-GB) Presto/2.10.254 Version/12.00 [17] [18]
Best regards,
Codename Lisa (talk) 01:53, 29 November 2014 (UTC)[reply]
Browser Without WBR With WBR User-agent
Screenshot
Firefox 33 (in desktop mode)
Android 4.1.2 (Samsung Galaxy Axiom)		 Window clipping Windows clipping Mozilla/5.0 (X11; Linux x86_64; rv:33.0) Gecko/20100101 Firefox/33.0 Raw wbr
Firefox 33 (in mobile mode)
Android 4.1.2 (Samsung Galaxy Axiom)		 Window clipping Window clipping Mozilla/5.0 (Android; Mobile; rv:33) Gecko/33.0 Firefox/33.0 Raw wbr
Fleet Command (talk) 03:54, 30 November 2014 (UTC)[reply]

Barnstars!

Again, many thanks! Great work.

The Technical Barnstar
For everyone who helped to fix this this issue. Rezonansowy (talk | contribs) 11:51, 7 December 2014 (UTC)_[reply]

Rezonansowy (talk | contribs) 11:51, 7 December 2014 (UTC)[reply]

Search bar not responsive sometimes

Demonstrating a problem with the search bar function in English Wikipedia.

I used an updated version of google Chrome and after waiting many seconds for the search bar list to offer me new results, it didn't. Instead of narrowing down the previous options because I input new letters, the results under the search bar are not helpful. I took a screenshot to demonstrate. Is this a tracked bug? What's going on here? This is a recurrent issue for me. Thanks. Biosthmors (talk) pls notify me (i.e. {{U}}) while signing a reply, thx 19:23, 24 November 2014 (UTC)[reply]

I recently started having an issue with my searches, also. I don't have to wait for the list to appear, but whenever I type in just "User talk:", the first and only item that appears in the suggestion area below the search bar is "User talk:Friendly AIDS". What's that? I'm getting tired of this and would appreciate it if someone could fix it. If I put one letter after "User talk:", then it works fine. CorinneSD (talk) 22:57, 24 November 2014 (UTC)[reply]
That is weird, and I can confirm that it's doing it here too. (user:Friendly Aids was blocked in 2005 and had made no edits). I don't get any search bar suggestions when only typing "User:" or "Wikipedia:" or "Wikipedia talk:", but the search bar does suggest Talk:High Blast Explosive (and nothing else) when I type "Talk:" ... never had noticed this before either. ---Sluzzelin talk 23:10, 24 November 2014 (UTC)[reply]
User talk:­Friendly AIDS and Talk:️High Blast Explosive both have a non-displayed character (not the same) after the colon. I guess you are not supposed to get any suggestions when you only write namespace and colon, but certain special characters can apparently fool that. PrimeHunter (talk) 23:31, 24 November 2014 (UTC)[reply]
I have tested all namespaces and the only other cases were User talk: (a user with only undisplayed characters), and for File: where the maximum ten suggestions are listed, so there may be more which didn't make the list. All ten have an undisplayed character after the colon. One of the ten is File:‌Baharestan New Town Iran.jpg which is tricky because it goes to a page with no undisplayed character and no redirect message at Wikipedia, but the file was moved at Commons where commons:File:‌Baharestan New Town Iran.jpg shows the redirect from the bad title. PrimeHunter (talk) 01:28, 26 November 2014 (UTC)[reply]
I've filed this as T76350. I imagine it is related to the undisplayed characters but I'll have to dig into it some more.NEverett (WMF) (talk) 15:35, 1 December 2014 (UTC)[reply]
And proposed a patch. If all goes well this'll disappear from wikipedias sometime December 11th. Thanks again, PrimeHunter. NEverett (WMF) (talk) 15:08, 2 December 2014 (UTC)[reply]
I can replicate this bug in Chrome (the updated 39.0.2171.71 m version), but it does not occur for me with Firefox. I can type "Bio", then wait several seconds, and new letters, such as "sen", do not help narrow the original Bio search results in Chrome. Ping to User:AKlapper (WMF). Might this be logged/tracked? I bet you're busy with rolling over to Phabricator from Bugzilla but thought I'd notify just in case. Thanks. Biosthmors (talk) pls notify me (i.e. {{U}}) while signing a reply, thx 23:04, 28 November 2014 (UTC)[reply]
NEverett (WMF) should know the best as he's into the search, pinging him here. --AKlapper (WMF) (talk) 00:41, 29 November 2014 (UTC)[reply]
Thanks. Biosthmors (talk) pls notify me (i.e. {{U}}) while signing a reply, thx 18:41, 29 November 2014 (UTC)[reply]
Thanks bringing this up, Biosthmors and AKlapper (WMF). I'll have a look into this more closely soon. Does it _feel like_ the not narrowing down issue comes close together? Like, if you try again in 20 minutes is it gone? Or is it all the time but only with Chrome? I'm unable to replicate in the Chromium version I have installed (Version 39.0.2171.65 Ubuntu 14.04 (64-bit)) so it could be a narrow thing. Or something even more fun. NEverett (WMF) (talk) 15:35, 1 December 2014 (UTC)[reply]
Hello NEverett (WMF), and sorry for the delay. For me this always happens in Chrome. I also run anti-keylogging software, so I suppose that might play a factor. But for some reason Firefox never has trouble updating results, just Chrome. Biosthmors (talk) pls notify me (i.e. {{U}}) while signing a reply, thx 00:03, 6 December 2014 (UTC)[reply]

visual editor revisited

i would like to make a proposal, but before i do, i'd like to hear what the distinguished wikipedians frequenting this page think, and hopefully refine the proposal based on feedback.

some background: when VE was initially enabled on enwiki, the VE team was not quick to response to real problems and issue reports, and even worse, responded dismissively, basically creating the impression they do not really care what the community thinks, and confident in their ability to steamroll enwiki community and force their view that "VE is good enough". the community revolted, and it seems, at least this once, that the community was more powerful than the devs, and we turned VE off by default for enwiki.

since then, the VE team have constantly worked and improved the tool. as far as i know, it is "on" by default on most wikimedia wikis, and the results are largely positive. the tool have improved a lot: e.g., loading times, which was prohibitive long, seem to be much better now (opening a large article like Paris - ~190K, took me about 8 seconds. it takes about 5 seconds to open it with the wikitext editor).

some features of VE are just not available anywhere - try to edit a table with VE - either edit its content or add a new row or column - it's pure pleasure compared with doing *anything* with tables without it.

there are other little delights: e.g., when you want to add an internal link to the page, VE actually uses the same "suggestions" as the search box (so after entering "mar" you can select Martinique and never have to worry about spelling - same for harder links, like 2014 World Indoor Athletics Championships), and if the IL you chose happens to be redirect or disambiguation page, VE will let you know. there are more goodies that will help even veteran editors, but i'll stop here.

i'd like to propose an experiment: let's turn VE on for a controlled subset of new editors (e.g., all those whose hashed username modulo 7 is 3 or something), and use some metrics to compare those users with a control group for whom VE will remain off by default, and look at the results within a couple of months.

if your initial reaction is "hell no", then i guess it's based on one of the following:

  1. hell no! VE will never be "on" on enwiki! wikitext editor was good enough for my grandmother, it was good enough for my mother, it's good enough for me, and it will be good enough for my daughter!
  2. we might turn on VE on enwiki at some date in the future, but it's not time yet: not until (X and Y) or until VE will (A and B and C)

if it's #1, i guess there's little to discuss. however, if it's #2, i'd like to hear what should improve before we can run the proposed experiment.

my intention is to open a WP:VPR proposal for this, but before i do, i'd like to hear what wp:vpt thinks about it.

peace - קיפודנחש (aka kipod) (talk) 00:22, 25 November 2014 (UTC)[reply]

I've been thinking for a while that we should made VE the default. I think it's improved enough now that the community should be much more receptive to it. Also, I think new editors might already be asked if they want to enable VE as a part of mw:Onboarding new Wikipedians? I'd have to check the details on that, though. — Mr. Stradivarius ♪ talk ♪ 01:11, 25 November 2014 (UTC)[reply]
Until VE supports table editing, I will not support making it the default. Adding columns is incredibly tedious in wikicode and could be made much easier by a working visual editor, but without it, visual editor is far more restrictive than the normal wikitext editor in terms of what it can do, and it prevents people from editing important areas of articles. StringTheory11 (t • c) 04:50, 25 November 2014 (UTC)[reply]
@StringTheory11: Table editing was recently deployed. It may not work for tables that are entirely generated from templates (which quite a few of them are, unfortunately), but for basic tables or tables that partially contain templates, operations like inserting/deleting rows/columns or even creating colspan/rowspan rules should work now. Try it e.g. on this article (without saving) or in the VE sandbox.--Erik Moeller (WMF) (talk) 05:25, 25 November 2014 (UTC)[reply]
Erik Moeller (WMF) me and some other work on fixing tables all around Wikipedia. This will make VE's work much easier. At least we don't have any tables directly written in html anymore. Now we work on removing deprecated parameters and close all unclosed tables. (Very few left). There is still some things to be done though. -- Magioladitis (talk) 08:50, 25 November 2014 (UTC)[reply]
Slightly meandering thought: Is there merit in the idea of having a "strict" parser function that when present on a page catches illformed wikitext (like unclosed tables) and HTML, and refuses to save? Martijn Hoekstra (talk) 09:23, 25 November 2014 (UTC)[reply]

Why would we make VE the default when it isn't even the editor of choice on wiki-versions where it has been the default for more than a year? I wanted to test table editing, random article opened Francis Schmidt, went to the "head coaching record" templates, tried to open these (no, not a table, but needs to be edited anyway), and got

"Een script op deze pagina is bezig, of het reageert niet meer. U kunt het script nu stoppen, de scriptdebugger openen, of het script laten doorgaan. Script: https://bits.wikimedia.org/en.wikipedia.org/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20141124T040933Z:4"

I choose to stop the script, and now VE hangs on that page and nothing works (cancel, browser back and forth, ...). VE has improved a lot (not too difficult if you start from a really terrible thing and spend a lot of resources which could have been used to improve wikitext editing instead), but any attempt to make this the default editor is again a push to justify the WMF-wastes of resources without any solid argument for it. Table editing? I did another random article search, and got to Oh Kwang-soo. You can open and edit the tables. You can't add a header row (a row spanning the table, like there is now). The table editing "works", but is cumbersome to say the least. I add a row, enter some text,but it is left-justified, while all the cells above have centered text. Worse, the table doesn't even look the same in VE as it does in standard view. The "final" row is moved to the left for no apparent reason.

Or take Parallel adoption, go to the tables, add a new column at the end. Background color of the header cell is copied, noce! Now I add text in it. Oh, he formats it as a content cell, not a header cell. No problem, I can change that in the dropdown at the top! But if I do that, I lose the background colour of that new header cell... This supposedly works? This has been tested? As much as is usually the case, probably...

As usual, a new "tool" is deployed where only the most basic functionalities work, and all the rest is still very buggy... @Erik Moeller (WMF):, you above point to Yuji Nariyama as one that works, but even there, try to create such a table in VE, or to add a subtotal or other country or anything beyond the most basic rows... It simply doesn't work. Claiming that "table editing" works is similar to claiming that the WMF is known for succesful software releases.

Oppose any change to the status of VE, support immediate end to all paid development of VE and transferring of those funds and some of the people to development of wikitext editing, the editor of choice of all environments where VE has been made the default over a year ago anyway. Fram (talk) 10:54, 25 November 2014 (UTC)[reply]

Agree with Fram, funds should be used for keeping essential tools running, per my older comment here.[19] It's not about being "against" the VE, there are just other more urgent things that need to work properly, as a minimum requirement fr editing efficiently. FunkMonk (talk) 11:26, 25 November 2014 (UTC)[reply]
Oppose, due to this community's hostility towards the developers creating too much friction and noise for it to be beneficial to the larger goals of our software development processes. —TheDJ (talk • contribs) 13:41, 25 November 2014 (UTC)[reply]
@Fram: I presume you are in Kipod's category 1, then? :) I admit that it would be better if the templates on Francis Schmidt loaded before Firefox popped up its "this script may not be responding" dialogue. But it does work if you let the script continue running. (Perhaps it would be faster if we added TemplateData to the templates?) On Oh Kwang-soo I managed to get a header row without too much trouble. Here are the steps: 1) click on one of the existing header cells, 2) click on the row arrow on the left hand side of the table, 3) click "insert below" from the menu that pops up, 4) select all the cells in the new header row, 5) go to the table menu at the top and click "merge cells". I couldn't make it the same colour as the other existing header row, but for newbies this has to be easier than raw wikitable syntax. — Mr. Stradivarius ♪ talk ♪ 14:12, 25 November 2014 (UTC)[reply]
I fixed the wikitext of Parallel adoption and Oh Kwang-soo —TheDJ (talk • contribs) 14:24, 25 November 2014 (UTC)[reply]
Thanks, but they didn't need fixing, they rendered perfectly. That VE can't handle them is VE's problem (and VE still can't handle them, although some cases have been solved now). Fram (talk) 14:36, 25 November 2014 (UTC)[reply]
That did need fixing, they were broken wikitext syntax. Just because something renders, doesn't make it valid. If I stumble over a bucket of white paint and the floor ends up painted white, then that might be just what you want, but not what you intended. —TheDJ (talk • contribs) 14:50, 25 November 2014 (UTC)[reply]
But to add colour, or center the text in a new row at the bottom, or... they still need to know and edit the wikisyntax anyway. So with VE, you need to know VE tricks (like the way you used to add a real header row) and wikitext editing (see also: template editing in VE; see also the lack of a preview button and the wikitext in "review your changes"). The list of things lacking or deficient in VE is way too long, even after all this time. You may consider as being in Kipod's category 2, but where "not until "X and Y"" include some rather serious X and Y. Take e.g. a look at Oh Kwang-soo, where the table (which showed up differently in VE) has been "fixed" by theDJ (isn't it strange that the code, which renders perfectly allright for readers and for wikitext editors, needs fixing in VE?): if I now add a new row at the bottom, I still can't do a lot of basic layout things with it, and I can't even edit the bottom right cell! But the basic problem I have is the choice to spend all this effort on a tool not used by most editors anyway (based on other language versions), and with unclear if any results for editor attraction and retention, instead of seriously improving the main editing tool (e.g. some of the things developed for VE could be useful as a gadget in Wikitext editing, e.g. a file selector or template editor: but I still haven't seen any sign that anyone at the WMF (apart from perhaps Tretikov) is interested in improving the main tool that has created Wikipedia and that will be used for years to come). This gives a very strong impression that the WMF (or the few people directly responsible for VE and similar misfortunes) only cares about developing new fancy software, and not about what is actually needed by the editors (and would be a great improvement for new editors as well, making file and template handling easier in wikitext editing would benefit everyone!). If they are not interested in what we need, why would I support their ambitions to make VE the default editor? The default editor needs to be the best of the options in most cases, not the best for some very simple tasks, somewhat usable for other tasks, and useless for the rest. Fram (talk) 14:36, 25 November 2014 (UTC)[reply]
User:Fram asked above: "Why would we make VE the default when it isn't even the editor of choice on wiki-versions where it has been the default for more than a year?"
i thought i made it clear in my original post, but please be patient and let me iterate the relevant points:
  1. i did not suggest to make VE the default. i suggested to re-start an experiment that will allow us to measure what effect it has on contribution of new users. personally, i think that objecting vehemently to conducting such experiment/measurement, hints that the protester maybe suspects the measurement will have conclusions they won't like.
  2. i tried to explain the point about "where it has been the default for more than a year": i happen to agree that it was a mistake to turn it on at the time it was turned on - IMO it was not ready, and turning it on was premature (if Fram is correct claiming it's "not the editor of choice" in wikis where it's the default, it supports the view it was wrong to turn it on at the time it was done). i also mentioned that VE made great improvements in recent releases, so data about "where it's been the default for over a year" may not be relevant. all i suggested was to try and measure its effect on new editor's ability to contribute.
as a side, i'd like to ask anyone, including Fram, to report any bug they encounter with VE, rather than "hoard" it and use it as ammo for the holy battle to kill VE. if you do not want to log-in to phabricator, you can report any VE issue here: Wikipedia:VisualEditor/Feedback. peace - קיפודנחש (aka kipod) (talk) 17:39, 25 November 2014 (UTC)[reply]
The stats on use by logged-in editors are generally divided into two groups: people who started editing with wikitext and people who started editing after VisualEditor was offered by default (NB that "offered by default", which is what's done at about half the Wikipedias, is not the same thing as "the default editor". "The default editor" is the editor you get when you don't have any choice, e.g., the editor that is used when you WP:UNDO an edit. VisualEditor has never been the true default editor anywhere).
I believe that the latest global stats are that about 35% of the editors who created their accounts after VisualEditor was offered by default are using VisualEditor (although not necessarily using only VisualEditor), compared to only about 5% of people who started editing with wikitext. It varies significantly by language. One thing that's a bit weird about the English Wikipedia is that in most projects, IPs have an editing pattern similar to brand-new accounts, but here at en.wp, the adoption rates by IPs mirrored that of experienced editors (during July 2013). So at, say, the French Wikipedia, if you have 25% of brand-new registered editors using VisualEditor, but only 5% of old hands using it, then you'll have about 25% of IPs using it. But here, it was 10% for old hands and 10% for IPs, and (if memory serves) a bit more than double that for the newly registered editors.
On the question of how new editors respond to VisualEditor, there was a little bit of research attempted at the end of June 2013, but there were some problems with it (including a very short time period, due partly to a technical problem that killed the first several days' work—I'm not sure any longer, but that also might be the study that had some event logging problems, like more people allegedly saving pages than allegedly opened pages in VisualEditor, which is impossible) and a very limited experience in VisualEditor, which could only barely add references or templates at that time). If the analytics team weren't so overloaded, it might be possible to re-create that study here, only over a more useful timeframe and with more time to get all the details tested beforehand. For example, we could offer VisualEditor to a certain percentage of brand-new accounts for a month or two, and see whether people using VisualEditor were more likely to get blocked (or whatever other outcome you want to measure).
Fram has provided a lot of practical support for VisualEditor during the last year and a half, especially with reporting bugs that appear in Firefox. Whatamidoing (WMF) (talk) 21:48, 25 November 2014 (UTC)[reply]
i guess i owe User:Fram an apology for implying that he(?) is only collecting bugs as amo for the battle to nuke VE, rather than reporting them. sorry about that. peace - קיפודנחש (aka kipod) (talk) 22:37, 25 November 2014 (UTC)[reply]
  • Week oppose while VE has got a lot better, there is still one show-stopper for me, the adding of <nowiki> tags. Looking at nowiki added tag VE is still adding a good number of nowiki's where they are not needed for instance [20]. Until it can produce clean edits its not ready for prime time yet.--Salix alba (talk): 21:24, 25 November 2014 (UTC)[reply]
    @Salix alba: That particular edit looks like user error rather than a VE problem. The user probably typed in [[nanoparticles]] character for character, not realising that it wouldn't be interpreted as wikitext. It is correct for VE to add nowiki tags in this case, as what you type into the edit window of VE should be interpreted visually, not as wikitext. — Mr. Stradivarius ♪ talk ♪ 22:10, 25 November 2014 (UTC)[reply]
    it's still a VE bug: VE should do something more intelligent when the editor enters [‏‎[<something> than simply surround it with "nowiki". i suggested one way to deal with it more than a year ago (Phabricator:T53897). there are other ways, but the current behavior, even if nominally it's "user error", should still be considered VE bug. however, if the community can commit to "once this issue is fixed, enwiki will agree to re-run the experiment Whatamidoing mentioned, it may give VE team some extra motivation to do something about it. i think User:Salix alba gave an excellent answer to the question in my original post ("option #2"). peace - קיפודנחש (aka kipod) (talk) 22:37, 25 November 2014 (UTC)[reply]
    I believe that the product manager calls that behavior a feature rather than a bug. Whatamidoing (WMF) (talk) 07:27, 26 November 2014 (UTC)[reply]
    @Whatamidoing (WMF): i think your comment was made tongue-in-cheek, but actually, this is sadly true. this unfortunate attitude of the product manager is (IMO) the main reason VE is now disabled on enwiki. if the product manager would have respected the community and listened to it a year and a half ago, when the community tried to explain, loud and clear, that this is indeed a bug (and a very disruptive one, at that), we would have VE enabled on enwiki by now. peace - קיפודנחש (aka kipod) (talk) 17:29, 26 November 2014 (UTC)[reply]
  • Strong oppose The proposal seems to be that 30% of new users will have one editor, and 70% will have another- at random. So when I am training a group of nervous new users, some will have an editor that I know and the others will have a bit of beta eye-candy. So before I start, to teach them the basics I have to explain how they edit their preferences! ................. No. -- Clem Rutter (talk) 22:51, 25 November 2014 (UTC)[reply]
    actually, my proposal was for 14%, not 30%, but this, of course, is immaterial. however, i am not sure we are talking about the same thing here: the proposal was to *enable* ve by default for the test group. an editor for whom VE is enabled still has full access to wikitext editor (under the "edit source" menu item), so they can choose which editor to use. the other editors ("control group") do not have a choice and are limited to wikitext editor. in a training situation, you can tell the trainees to use "edit source", or you can simply tell them to disable VE altogether - it takes less than 8 seconds (prefernces => Beta => VisualEditor => disable => save. 5 clicks in all). better yet - you can tell all the others to *enable* VE in their preferences, and train them using VE... either way, i do not see how this can be considered rational reason to oppose an experiment. peace - קיפודנחש (aka kipod) (talk) 23:08, 25 November 2014 (UTC)[reply]
    VisualEditor is getting pretty good reviews from new editors in Wikipedia workshops these days, but which one is best depends on what you're doing (if you want to edit blockquotes or make tables rainbow-colored, then you need to use wikitext still). However, if you wanted to have a wikitext-based class, then there would never be a need to edit their preferences. You would just say, "Who sees both 'Edit' and 'Edit source' on their computer screens? Okay, I want all of you to always click on 'Edit source' so you can see the wikitext source itself. If it looks like a regular word processing program, then you clicked the wrong one. If you only see 'Edit', then that will automatically take you to the wikitext editor." Whatamidoing (WMF) (talk) 07:23, 26 November 2014 (UTC)[reply]

I know this is the place for Technical discussion, but something that was dramatically wrong last time round with VE should still be mentioned - Change management. It was a complete disaster on that front. I cannot remember all the details of the process editors were confronted with, but the impression I have (and impressions are critical) was one where the developers declared "It's ready. You will have it." Is this an equivalent process being proposed now? The mere fact that Change management hasn't even been mentioned suggests that it's still being ignored. HiLo48 (talk) 07:44, 26 November 2014 (UTC)[reply]

Oppose as per User:Fram. For a small fraction of the effort that has gone into VE, we could have beefed up the WikiEditor into an awesome state and still had funds leftover to tackle some Mediawiki bugs and do some stuff at Wikimedia Labs. VE has gotten better — that's true — but for all but fairly simple editing, it is often more confusing to use than editing the source. Mediawiki was designed around text editing and unfortunately it doesn't seem that a modern GUI interface is easily retro-fitted onto it. Jason Quinn (talk) 17:40, 26 November 2014 (UTC)[reply]

Oppose To be fair, a lot of issues have been fixed. Necessary functions, that should have been implemented right from the start, have been added. But there are still too many open issues, most of them minor, but also persistent complex bugs in fundamental areas like referencing, template editing and certainly in the new table functions. When all basic functions are working with no significant problems, VE can be switched to default. PS: Developers need to go back to traditional methods (like having a finished concept before starting development), the current approach to release an unfinished alpha-version and to finish it "along the way" was a major disaster. GermanJoe (talk) 08:06, 28 November 2014 (UTC)[reply]

"nowiki" issue fixed in latest version

basically, hitting [ or { twice, now opens the appropriate dialog instead of adding them to the page "as is" and wrapping the result in "nowiki" tags. please try it and see if there's any problems with this solution. @Salix:: is this enough to change your "weak oppose" to "support" ? peace - קיפודנחש (aka kipod) (talk) 19:38, 4 December 2014 (UTC)[reply]

Give rate limited move-subpages and supressredirect-new-self to autoconfirmed users

I suggest to give to all autoconfirmed users the move-subpages userright, but rate limited, meaning the moved subpages are included in the rate limit for moves, which is 8 per minute here. So autoconfirmed users could not move more than 7 subpages. I think this should be modified in mediawiki core (not just for en.wp). Administrators and bots having no rate limits, they could still move up to 100 subpages. (As a side note, this would also apply to account creators, but the solution here should be to give them noratelimit-account instead, as with T76050.) I also suggest to allow all autoconfirmed users to move a page without creating a redirect when it has been recently created and they are the unique contributor. This could also be modified in mediawiki core. Comments ? Cenarium (talk) 12:58, 26 November 2014 (UTC)[reply]

Please, explain for what purpose an average autoconfirmed you may need move-subpages userright? Ruslik_Zero 11:49, 27 November 2014 (UTC)[reply]
For moving templates, with their doc and other subpages, and pages with talk archives. Some other projects may have more specific uses. This will save them the clicks and time without any additional risk since the rate limit is respected, so I just don't feel that restricting this is necessary in any way. Cenarium (talk) 12:16, 27 November 2014 (UTC)[reply]
I couldn't comment specifically on the need on enwiki as I have never found the need to move a subpage, but as a core feature it would certainly help Wikibooks where all books are structured as subpages under a main page. Therefore when a book title is changed it is necessary to move lots of pages one by one... QuiteUnusual (talk) 17:05, 27 November 2014 (UTC)[reply]
It sure would be useful there, and if the rate limit of eight per minute is too restrictive, it could be increased a bit, and set even higher for reviewers. I've suggested using the rate limit for this reason too, easy to vary it depending on usergroup. Cenarium (talk) 20:18, 27 November 2014 (UTC)[reply]
Proposed at Wikibooks:Wikibooks:Reading_room/General#Give_rate_limited_move-subpages_.28and_supressredirect-new-self.29_to_autoconfirmed_users. Cenarium (talk) 10:41, 28 November 2014 (UTC)[reply]

Both ideas sound good to me. Callanecc (talk • contribs • logs) 06:32, 4 December 2014 (UTC)[reply]

Mass message like extension to help renaming or deleting categories

Tracked in Phabricator
Task T77903

Until such a time as we have category tables (T15326), I was thinking that it would be useful to have an extension that allows a user with the appropriate permission to request on a special page that a bot makes all the necessary changes to directly categorized pages (in the [[Category:Foo]] format), either updating for a rename or removing for a deletion. This would work similarly as mass message, we could grant the rename permission to a "category renamer" usergroup, maybe with a limit on the number of pages in the category, and grant the unlimited rename and remove permissions to admins. Users would have to move the category beforehand when renaming (there should be a warning message if the category to rename to doesn't exist), and admins would have to delete it afterwards for deletion. This would significantly simplify CFD procedures and implementations. Cenarium (talk) 15:10, 28 November 2014 (UTC)[reply]

Isn't there a bot that does that? Sfan00 IMG (talk) 15:19, 28 November 2014 (UTC)[reply]
Yes there is, three bots in fact, but it is exceedingly complicated to operate, see Wikipedia:Categories for discussion/Working. This would make everything smoothly in one click for directly included categories. Cenarium (talk) 15:26, 28 November 2014 (UTC)[reply]
The current process is not "exceedingly complicated": uncontroversial requests are listed at WP:CFD/S and processed after 48 hours if no one objects. Controversial requests are more complicated because they require a full nomination and discussion, but there is good reason that they should not be left to the discretion of individual users with a particular user right. -- Black Falcon (talk) 20:09, 28 November 2014 (UTC)[reply]
They wouldn't be granted the userright if they weren't active and experienced in this area, as with file mover, and it wouldn't be left to their discretion, there would still be discussions. There is a general long term need to offload some of the admin workload to trusted established users, and that's totally the kind of things that could be done with minimal issues. After all, the category move userright didn't create as many problems as anticipated, and it's granted to all autoconfirmed users. But it can be restricted to admins, if necessary, this would still save lots of time and allow more admins to help in this area due to the much easier implementation, as I mention below. Cenarium (talk) 20:28, 28 November 2014 (UTC)[reply]
WP:AWB has that function. --Glaisher (talk) 15:40, 28 November 2014 (UTC)[reply]
The problem is that it clogs up user contributions. And while having bots do this is complicated but feasible on wikipedia, it's not on other projects where there isn't the technical expertise, so an extension would help them even more. Cenarium (talk) 15:54, 28 November 2014 (UTC)[reply]
  • I don't really consider "clogging up contribs" as it's not hard to make AWB or a script mark all the edits as minor or as bot (for bot accounts) which makes them easy to filter out of contribs. — {{U|Technical 13}} (e • t • c) 17:03, 28 November 2014 (UTC)[reply]
  • Well, I presume the closing admins don't do this because it is too much of a hassle or takes too much time (even more than using the bots). There's a reason most admins stay far away from WP:CFD, me included, not only the possible outcomes and criteria used in discussions are exceptionally obscure even by WP standards, but the implementation of closures is excessively complex, so it's constantly backlogged. A simple, fast and effective way of repopulating or depopulating categories would go a long away in improving the situation. (As a note, I should mention that the special page should allow to merge multiple categories into one - just an example.) Cenarium (talk) 20:06, 28 November 2014 (UTC)[reply]

A simple way for an admin to do this without without clogging his/her edits is to create an alternate AWB account (and declare it publicly, to be sure not to have SOCK issues); autherize that account to use AWB (at Wikipedia:AutoWikiBrowser/CheckPage - mention that the account is yours in the edit summary); and use it for CFD implementations. עוד מישהו Od Mishehu 19:32, 29 November 2014 (UTC)[reply]

Well nobody has ever shown me how to do Mass-deletes or Mass-moves using AWB and, as an Admin elsewhere, the lack of such built-in, Special: pages to do either of those tasks (like Nuke does) has pissed me off to no end.

The best that I could find was just for mass deletes and was lifted from Wikimedia Incubator awhile back (see s:MediaWiki:Gadget-massdelete.js; needs delete rights). Its not exactly "perfect" rendering wise and is probably in need of a refresh given the deprecated .js/json stuff since its last re-write but it works reliably. I'm sure a similar script to do mass-moves can be gleamed from it as well but stuff like that is beyond my skill-set. Still, if anyone takes a stab at [re]doing either, I sure would appreciate a heads-up on any progress or suggested changes. -- George Orwell III (talk) 21:47, 29 November 2014 (UTC)[reply]

  • I'm thinking one of us is missing something. We are talking about moving categories from say Category:Bar to Category:Foo for example, right? If so, then there is only one page being moved, the actual category page itself. All of the members are moved by editing each one of them individually and replacing [[Category:Bar]] with [[Category:Foo]]. This is just a series of edits, which should be simple to do. — {{U|Technical 13}} (e • t • c) 03:16, 30 November 2014 (UTC)[reply]
    • The edits are simple but it's not the issue. The issue is that the vast majority of users are not well versed in semi-automated editing, there are 2361 WP:AWB non-admin users, not all active, compared to 130000+ active users. Even among admins, I'm pretty sure more than 90% of them have never used a semi-automated tool for maintenance like AWB. It's not going to change, it's just too much of an investment to learn semi-automated editing when personally you don't have a great need for it, so an easy to use software addition would be worthwhile. Mass messaging users can also be made easily with a semi-automated tool, but only for those experienced in using them, so having a mass message extension makes it much more accessible, same with categories. Cenarium (talk) 12:14, 30 November 2014 (UTC)[reply]
      • Not at all what I was suggesting. What I'm saying is that a userscript can be written in JavaScript so that if the user is on Special:MovePage and mw.config.get('wgRelevantPageName') starts with "Category:" then the script would modify the DOM to add a button on the Special Move page or if it is on a category page that doesn't exist but has members, add a link in the sidebar, next to move in the toolbar up to, or whereever people want to move the contents of the category to another category either based on the move log or what the editor defines. — {{U|Technical 13}} (e • t • c) 15:00, 30 November 2014 (UTC)[reply]

This sounds like the kind of idea that's been proposed before (because it's been a source of pain for years). Does anyone know if it ever made it into an official feature request? If not, I can file one. Whatamidoing (WMF) (talk) 14:33, 3 December 2014 (UTC)[reply]

@Whatamidoing (WMF): I didn't see anything at phabricator, and I was planing on making a request but please go ahead. I feel like I've filed enough of those recently and I'm sure you'll know how to get more attention for it. Cenarium (talk) 15:09, 3 December 2014 (UTC)[reply]

Detect whether any <ref>erences on page..?

Is there a way for a page to detect whether it includes any <ref>...</ref>s..?

Curiously, {{str len|{{reflist}}}} yielded "111" here; perhaps that always occurs..? (It explains, though, why {{#ifeq:{{reflist}}| |... |...}} doesn't work.)

Sardanaphalus (talk) 11:32, 29 November 2014 (UTC)[reply]

{{str len|{{reflist}}}} gives 111 because the template outputs 111 characters (the HTML). You cannot query the length of any wikitags like <references /> because they are generated outside the page context. Only JavaScript could do what you want, but why? -- [[User:Edokter]] {{talk}} 13:21, 29 November 2014 (UTC)[reply]
  • Thanks for the explanation; it hadn't occurred to me that it'd be length of {{reflist}}'s code when converted to HTML. As to why, I could divulge the reason, but then I'd have to (etc). Regards, Sardanaphalus (talk) 14:30, 29 November 2014 (UTC)[reply]
    This sort of thing in general will never be possible to do within the parser. The reason is that changing one part of a page (such as by adding a reference) shouldn't be able to affect how other parts of the page are preprocessed. Jackmcbarn (talk) 18:15, 29 November 2014 (UTC)[reply]
I'm going to take a SWAG that Template:Bug might be of interest. --  Gadget850 talk 21:35, 29 November 2014 (UTC)[reply]
  • Sardanaphalus, depending on how you need to retrieve this information (for a template? for a userscript? for some other purpose?) it can be retrieved. If you are using it for a javascript userscript, you can get the wikitext of a template and search for the tag in some fashion. An example of using the API to get the wikitext of a page is this example. — {{U|Technical 13}} (e • t • c) 06:12, 4 December 2014 (UTC)[reply]
    Thanks for suggesting; I was wondering whether it'd be possible within wikicode/HTML (i.e. without relying on the installation of a script, etc) in order to guide action taken by a template. Regards, Sardanaphalus (talk) 09:26, 4 December 2014 (UTC)[reply]
There was some discussion on IRC about this. To answer some questions there, there's no way to get the final parsed HTML from Lua, and there's no way to detect whether a page uses references. For various reasons that have been discussed at length before, neither of these features can be added. However, depending on the use case for them, it may be possible to integrate the desired functionality into mw:Extension:Cite directly. @Sardanaphalus: Can you please describe the use case? Jackmcbarn (talk) 16:05, 4 December 2014 (UTC)[reply]

XTools and Supercount

Right now, accessing it gives this error: "No webservice The URI you have requested, [URL you tried to request] is not currently serviced." Meanwhile, Supercount gives this error: "Fatal error: Allowed memory size of 524288000 bytes exhausted (tried to allocate 64 bytes) in /data/project/supercount/public_html/core.php on line 513 Call Stack: 0.0058 1304128 1. {main}() /data/project/supercount/public_html/index.php:0 0.6314 2665736 2. API->get_stats() /data/project/supercount/public_html/index.php:145" The people maintaining these tools have been rather inactive lately. Now what? Narutolovehinata5 tccsdnew 00:56, 1 December 2014 (UTC)[reply]

Confirmed. I know that there have been problems with XTools lately, but I haven't heard anything about Supercount. APerson (talk!) 03:00, 1 December 2014 (UTC)[reply]
@C678: When I try X! Edit Counter, I get "Notice: Again issues with Tool Labs databases after db maintenance. Some wiki's won't work. Sorry about that!". Your continued assistance would be appreciated. GoingBatty (talk) 19:18, 1 December 2014 (UTC)[reply]
That's a site notice. If it works, ignore it. If you notice high execution times being printed on the page, that's what it's talking about. In any event tool lab users have no control over that. They can just helplessly stand by and wait.—cyberpower OfflineMerry Christmas 20:42, 1 December 2014 (UTC)[reply]
@C678: Still not working for me. I still get the "No webservice: The URI you have requested, /xtools/ec/?user=K6ka&project=en.wikipedia.org, is not currently serviced." message. --I am k6ka Talk to me! See what I have done 22:10, 2 December 2014 (UTC)[reply]
I asked about it on IRC, and the webservice has been restarted by Yuvipanda. Zhaofeng Li [talk... contribs...] 08:56, 3 December 2014 (UTC)[reply]

Edit notices @ VE

Has anybody thought what to do with editnotices, when people are editing using VisualEditor? If somebody doesn't know, then - if you are editing with VisualEditor, then you don't see any editnotices. --Edgars2007 (talk/contribs) 07:07, 1 December 2014 (UTC)[reply]

Edit notices work just fine with VisualEditor. —TheDJ (talk • contribs) 09:12, 1 December 2014 (UTC)[reply]
Yes, sorry. I just picked some random BLP and saw that BLP notice isn't showing. Then everything is fine :) --Edgars2007 (talk/contribs) 11:55, 1 December 2014 (UTC)[reply]
Not entirely fine in fact, since indeed the notices added by mediawiki:common.js, i.e. the BLP editnotice and disambiguation editnotice (or editintros to be accurate) do not show there, this should be fixed at some point. Cenarium (talk) 12:15, 1 December 2014 (UTC)[reply]
I believe you're talking about this known request. Best, --Elitre (WMF) (talk) 18:14, 1 December 2014 (UTC)[reply]
While we're on the subject, I'd like to get up on my soapbox again and say that we have a problem with the desktop-focused formatting of many editnotices. When you look at things like {{TFA-editnotice}} in a smartphone-wide screen, half of the screen (vertically) may be blank, because the icon is placed in its own column, regardless of how awkward that is on the screen. It would be better if the text wrapped around the image (similar to a drop cap). Whatamidoing (WMF) (talk) 15:21, 3 December 2014 (UTC)[reply]

MediaWiki:Example, Education Program:Example, Topic:Example and their talk pages

For the sake of demonstrating templates such as Template:Tlpad, Template:Tlpad, Template:Tlpad, etc, could these pages be created with the following content, please?:

[...:Example page]: 

{{Namespace example page}}

[[Category:Namespace example pages]]

[accompanying talk page]: 

{{Namespace example page}}

Sardanaphalus (talk) 10:00, 1 December 2014 (UTC)[reply]

Education Program and Topic (Flow) are not normal wiki pages; it would be possible to do this for the MediaWiki space. — xaosflux Talk 13:57, 1 December 2014 (UTC)[reply]

Inability to select on Diacritics(?) in Category:Redirects from Unicode characters

Tracked in Phabricator
Task T76625

When I view Category:Redirects from Unicode characters on the second page, starting 10 entries down on the third column, the entries become unclickable/selectable. This continues onto the third page. These appear to be the ones that run from wiki/%CC%80 to /wiki/%CD%AC which appear to be the diacritics. I'm using Windows 7 SP1 and Chrome 38.0.2125.111. Naraht (talk) 20:40, 1 December 2014 (UTC)[reply]

That's very odd. I get the same problem in Safari 6 on Mac 10.8.5, so it's probably affecting everyone. I'm not sure who the best contact is for something so basic in categories. Perhaps User:AKlapper (WMF) could suggest a dev to contact. Whatamidoing (WMF) (talk) 15:27, 3 December 2014 (UTC)[reply]
Left a message for him. My bet is that the link created has to have something so that the diacritic won't automatically combine with the following character (take a look at that page source)Naraht (talk) 15:39, 3 December 2014 (UTC)[reply]
Naraht: I cannot suggest a dev (mw:Developers/Maintainers provides a list) but you could file a bug report under the "MediaWiki-Categories" project in mw:Phabricator. --AKlapper (WMF) (talk) 15:41, 3 December 2014 (UTC)[reply]
Bug Report filed.Naraht (talk) 18:38, 3 December 2014 (UTC)[reply]
i do not think it's specific to categories: this link to the redirect page will get you to the redirected article with a sub-header " redirected from ̀ ". normally, you can click the sub-header to get to the redirect page, but in this case, it's not clickable. simply placing the grave accent diacritic within square double-braces, like so: ̀ is also not clickable (and sometimes, such as in edit window, it's not even visible). peace - קיפודנחש (aka kipod) (talk) 23:43, 3 December 2014 (UTC)[reply]

Showing both new and unregistered users in recent changes

Is there, as I believe, no way to show both new (non-autoconfirmed registered) users and unregistered users in recent changes or watchlists ? We can show only IPs in RC, and on the other hand we have special:contribs/newbies, but what if one wants both at the same time ? Cenarium (talk) 21:06, 1 December 2014 (UTC)[reply]

It would seem that special:contribs/newbies uses another definition for 'new' than non-autoconfirmed, is it one month old or something like that ? Cenarium (talk) 12:13, 2 December 2014 (UTC)[reply]
I think it's three weeks. --Redrose64 (talk) 13:42, 2 December 2014 (UTC)[reply]
Thanks. I am thinking of requesting a show/hide autoconfirmed users option in recent changes and watchlists. Newbies contribs doesn't look much used, I wonder if it shouldn't be deprecated in favor of this. Cenarium (talk) 15:53, 2 December 2014 (UTC)[reply]
It's "users with user id within 1% of the current maximum user id, excluding users with the 'bot' right".[21] Anomie⚔ 12:44, 3 December 2014 (UTC)[reply]
Thanks for the reference. It makes sense to have a definition adapted to the rate of new registrations at the wiki in question. I've added this at Help:User contributions#Contributions by new users. Cenarium (talk) 13:18, 3 December 2014 (UTC)[reply]

What's the point of div class="usermessage"? The orange banner disappears instantly.

When I try this code

&lt;div class="usermessage plainlinks"&gt;[http://en.wikipedia.org/w/wiki.phtml?title=User_talk:Basemetal&action=edit&section=new To leave a message click here]&lt;/div&gt;

the orange banner containing the link a user is to click to leave me a message disappears instantly. It's like an orange flash and it's gone. So what exactly is the point?

The following of course does work

&lt;div class="plainlinks"&gt;[http://en.wikipedia.org/w/wiki.phtml?title=User_talk:Basemetal&action=edit&section=new To leave a message click here]&lt;/div&gt;

but I'd like to understand why the other piece of code doesn't.

Also where in the WP doc do I find information on the parameters for that div class HTML "thing" (whatever it's called)?

Thanks

Contact Basemetal here 21:16, 2 December 2014 (UTC)[reply] 

$( '.usermessage' ).show();
Happy editing! — {{U|Technical 13}} (e • t • c) 23:30, 2 December 2014 (UTC)[reply]
Thanks guys. It worked. Contact Basemetal here 19:38, 3 December 2014 (UTC)[reply]

Edit Tools

It's been a few weeks since the CharInsert toolbar has vanished from my edit box. At first I thought it may have been just some kind of glitch but it seems not to be. Maybe it has to do with the push to simplify the edit window; simplification is great but not when you're throwing useful stuff out. Perhaps there the idea that it was redundant was floating around; the idea is would be false. It was very useful. It was more comprehensive and less cumbersome than the edit box at the top. Where did it go? Jimp 05:32, 3 December 2014 (UTC)[reply]

See the Wiki mark-ups are missing section above. Zhaofeng Li [talk... contribs...] 08:26, 3 December 2014 (UTC)[reply]
So yeah, you broke it yourself with this change. —TheDJ (talk • contribs) 10:55, 3 December 2014 (UTC)[reply]
Thanks. Jimp 16:40, 6 December 2014 (UTC)[reply]

Edit sections not displaying on portal

See Portal:Christmas Where some subsections include an correctly-formatted "edit" section in the transcluded subpages but others have a malformed "[{{fullurl:{{{2}}}|action=edit}} edit]" I can't figure out why. Can someone help? Thanks. —Justin (koavf)❤T☮C☺M☯ 10:26, 3 December 2014 (UTC)[reply]

Some work was done on {{Random portal component}} which was not fully tested. I reverted for now and the portal should display fine. -- [[User:Edokter]] {{talk}} 10:55, 3 December 2014 (UTC)[reply]
It appears that that template's internal Lua module fails to pass the name of the randomly chosen subpage through to the formatting template Portal:Christmas/box-header. Maybe someone more familiar with Lua than I am could take a look at the module. SiBr4 (talk) 10:58, 3 December 2014 (UTC)[reply]
Pinging Mr. Stradivarius. He wrote the module. -- [[User:Edokter]] {{talk}} 11:04, 3 December 2014 (UTC)[reply]
What's unusual about Portal:Christmas is that the "header" parameters contain equals signs once the {{/Font}} has been expanded. -- John of Reading (talk) 12:43, 3 December 2014 (UTC)[reply]
So is that a fault in the module, or the portal? -- [[User:Edokter]] {{talk}} 13:34, 3 December 2014 (UTC)[reply]
@Edokter: The module. If my hunch is correct, then the line that formats the call to the box-header template should be changed from "%s | %s" to "1=%s | 2=%s". But I've never written or debugged any LUA code. -- John of Reading (talk) 14:04, 3 December 2014 (UTC)[reply]
Hmm, my code from a year ago wasn't the greatest. John of Reading is right - if any parameters containing equals signs are passed to the template invocations in the module, then anything before the equals sign will be interpreted as a parameter name. To fix this, we could prefix the parameters with 1= and 2=, etc., but it would be better to use frame:expandTemplate as it is faster and it deals with equals signs automatically. I'll have a look at the code tomorrow when I have a bit more time. — Mr. Stradivarius ♪ talk ♪ 15:06, 3 December 2014 (UTC)[reply]
I've rewritten the module and restored the template to the Lua version. Portal:Christmas is now displaying fine. Let me know if you spot any other problems. — Mr. Stradivarius ♪ talk ♪ 10:56, 4 December 2014 (UTC)[reply]

Tossed out of login onto a page for Wikipedia fund raising

In the middle of going from one article to another, I was completely thrown out of my login to a Wikipedia fund raising banner. I have "Suppress display of the fundraiser banner" already clicked on my gadget preferences, so I guess this is their way of getting around it. I like to think this was a momentary glitch that won't happen again. — Maile (talk) 21:46, 3 December 2014 (UTC)[reply]

@Maile66: Whenever you retrieve any page anywhere in Wikimedia, whether it be Wikipedia, Commons, Wikidata, etc., your login cookie is sent along with the http or https request. This happens for every page that you visit, even if you are staying within English Wikipedia and merely follow a link to another article. If for some reason that cookie doesn't get through (perhaps it was corrupted en route), you're treated as being logged out until the Wikimedia servers successfully receive your login cookie at a subsequent page request. --Redrose64 (talk) 22:56, 3 December 2014 (UTC)[reply]

Highlight redirects: vector.js

Hello. Is there a code for users vector.js that can highlights the redirects links on a page? Xaris333 (talk) 04:07, 4 December 2014 (UTC)[reply]

You can highlight the links with any style you want. Darkdadaah (talk) 09:44, 4 December 2014 (UTC)[reply]

User:Darkdadaah, many thanks!! Xaris333 (talk) 12:16, 4 December 2014 (UTC)[reply]

Different colour for article text and markup text

Is there an existing gadget or add-on that I can use to display article text in the edit window in a different colour than the references, templates, categories, etc.? (It would make editing long articles a lot simpler, I think.) --Anthonyhcole (talk · contribs · email) 04:24, 4 December 2014 (UTC)[reply]

Yes, just enable the Syntax highlighter gadget (under the Editing section). Zhaofeng Li [talk... contribs...] 04:34, 4 December 2014 (UTC)[reply]
Thank you, Zhaofeng Li! --Anthonyhcole (talk · contribs · email) 13:49, 4 December 2014 (UTC)[reply]

Severe problems with log-in

I am currently having very severe problems with my log-in on both Wikipedia and Wikimedia Commons. It started happening suddenly yesterday afternoon. The exact same thing happened six (correction, three) months ago, and back then this problem went on for at least 2 weeks before it got better by degrees spontaneously. Here is what is happening:

I am on a Mac with OS X Yosemite, version 10.10.1.

I am losing my logged-in status, AND MY PASSWORD VALIDITY, numerous times each hour. Every time I open a new window, go to another site, or even just go away from the computer for 20 minutes and then click back in again, the software drops my log-in. Then my current password no longer works to log me back in, so I have to request a temporary password and then create a NEW PASSWORD, again and again and again every few minutes that I am working here.

This is extremely difficult and extremely time-consuming, but the previous time this happened I couldn't find anyone who had any idea what could be causing this or had any idea how to fix it. I was using Safari yesterday, but I just now switched to Firefox to see if that would make a difference: it didn't.

If you have a concrete suggestion, please reply to me via email as well as here, because using the site is very difficult for me right now. I very much appreciate any insight you might have or any idea as to what to do next, Invertzoo (talk) 12:48, 4 December 2014 (UTC)[reply]

Previous thread was Wikipedia:Village pump (technical)/Archive 130#Problems logging in (three months ago, not six). --Redrose64 (talk) 14:36, 4 December 2014 (UTC)[reply]
Well, do you have any potential solutions to offer? I don't need to reread old discussions! Editing via IP because this website has invalidated my bloody password AGAIN! Invertzoo 104.156.240.157 (talk) 17:39, 4 December 2014 (UTC)[reply]

NOTE: The reply above this was not written by me. I am currently still logged in OK and will not be leaving messages from any IP address. Invertzoo (talk) 22:56, 4 December 2014 (UTC)[reply]

No, I don't have any practical solutions. My addition of a link above was not directed specifically at you, but intended to assist others - those who may be able to help; they might first need to read up on the background to this. It's surely better for one person having found the previous thread to advertise that, than to expect everybody else to conduct their own searches - that's if they are aware that there was a previous discussion on this page. --Redrose64 (talk) 18:16, 4 December 2014 (UTC)[reply]
I am going to go on a limb here and guess you have an failing hard drive. If your hard disk or computer is younger than 10 years old, you should be able to check that quite easily. There are two ways to do that. Firstly, when you go to Applications > Utilities > Disk Utility, click on your drive, what is written next to "S.M.A.R.T. status" at the bottom of the screen? Secondly, have you gotten errors like "S.M.A.R.T has predicted that it will fail" or "S.M.A.R.T Status BAD, Backup and replace" when you have turned on your computer in the past 3 months? --Snaevar (talk) 20:52, 4 December 2014 (UTC)[reply]
It certainly sounds like a problem on your computer and not at Wikipedia. Until you use a temporary password, the old one should continue to be valid. Do you get the message "Incorrect password entered. Please try again." when the login fails? Have you tried the same password on another computer after getting that message? Does it work at least once if you log in at a new Wikimedia wiki, for example es: after the login fails here? Do you have any browser extensions which are enabled in both Safari and Firefox? PrimeHunter (talk) 20:56, 4 December 2014 (UTC)[reply]

The desktop computer I am working on is less than a year old, and so I very much doubt that the hard drive is failing, but I will check as you suggested. And yes, I have tried the same thing on my laptop, and I have the exact same problem there too, which seems to indicate it is not my machine that is at fault. I have not tried logging in on another Wikimedia wiki. I will find out if I have any browser extensions enabled. Thanks for your interest and for your suggestions. Once again, I did not write the rude reply that appeared further up this thread. Invertzoo (talk) 23:02, 4 December 2014 (UTC)[reply]

I've been having the same problem, and couldn't get in at all earlier today. It's been happening on and off for a few weeks. The sequence is this: on the log-in in page I enter my password, then there's a quick processing/refresh/something and the password in the password field disappears. Then there's a lag of up to 30 seconds or longer. Sometimes after the lag, i get logged in. Sometimes I have to try again. Last night, after the lag I kept getting a screen telling me to change my password. But I didn't want to change my password and after the second try noticed the tabs were visible at the top of the page, so clicked watchlist and it appeared without having to change the password. Same thing his morning, but now everything is normal. I'm on a Mac, OS 10.7.5, running Safari 6.1.6. Hope this is helpful. Victoria (tk) 23:36, 4 December 2014 (UTC)[reply]

My problem sounds rather different from yours. Whatever my last or most recent password is, is no longer recognized as being valid. There is no time lag, and I can get in just fine if I click "forget your password?" and get a temporary password and then change my password. Invertzoo (talk) 00:48, 5 December 2014 (UTC)[reply]

UPDATE: Right now I do not have the problem any more. Let's hope it stays that way! Invertzoo (talk) 00:51, 5 December 2014 (UTC)[reply]

It's still OK this morning; let's hope it stays that way! Thanks everyone who tried to help me diagnose the problem. It went away by itself without my doing anything. Invertzoo (talk) 13:10, 5 December 2014 (UTC)[reply]

Alphabetical

I used to have a coding in my script for a browsing option of articles in alphabetical order on wikipedia with an article at the top left and top right at the top of the page with an arrow. So when you visit an article the next one forward and last one in the A-Z index appear. There was a line arrow under each article either side at the top whenever you hit a wiki page for clicking forward or backwards Can somebody remind me of the coding?♦ Dr. Blofeld 17:57, 4 December 2014 (UTC)[reply]

Is this the same q that you asked at User talk:Redrose64#Alpha? --Redrose64 (talk) 19:39, 4 December 2014 (UTC)[reply]
Did somebody steal your brain Redrose? :-)♦ Dr. Blofeld 22:29, 4 December 2014 (UTC)[reply]
  • Thanks for the link to the discussion on your user talk, Redrose64. It certainly looks like it should be User:PleaseStand/prevnext.js which doesn't appear to do anything for me when I try to run it from the console, and I'm guessing it is because it is using methods no longer supported or it is conflicted by one of my other gadgets I have enabled. I have no way of seeing what User:PleaseStand/wikiapi.js because it is deleted, could I get an administrator reading this (perhaps Redrose64) to please restore the contents of that deleted page to User:Technical 13/SandBox/wikiapi.js and then put importScript('User:Technical 13/SandBox/wikiapi.js');//JavaScript redirect on User:PleaseStand/wikiapi.js, so I may see what it was and perhaps improve it to make it useful again? Dr. Blofeld, I could probably repair the issues with the prevnext script if there is interest in having that available. Let me know. Thank you. Input from PleaseStand may be useful here as well. — {{U|Technical 13}} (e • t • c) 22:27, 4 December 2014 (UTC)[reply]
Basically something which allows you to browse Special:AllPages/Aa for instance and when you visit the Aaadonta fuscozonata article at the top of the page the left option with an arrow is Aaadonta constricta and the right one Aaadonta irregularis in alpha browsing.♦ Dr. Blofeld 22:35, 4 December 2014 (UTC)[reply]
@Dr. Blofeld: Fixed. The problem was that the script was using the deprecated hookEvent() function, which now does nothing. It also used a non-protocol-relative URL for the CSS stylesheet.
As for wikiapi.js, it was deleted because it was merged into the prevnext.js script. Now MediaWiki provides a "mediawiki.api" module that does more or less the same thing. PleaseStand (talk) 08:15, 6 December 2014 (UTC)[reply]

Thanks, it works now. Cheers, have a good Christmas all!♦ Dr. Blofeld 10:56, 6 December 2014 (UTC)[reply]

Criteria clarifications...

I need your help in setting the criteria for the script to make it as useful as possible, please see Criteria clarifications... on the WikiProject Orphan talk page. — {{U|Technical 13}} (e • t • c) 18:27, 4 December 2014 (UTC)[reply]

Progress template missing categories

Template:Articles lacking sources progress seems to be malfunctioning. It's supposed to keep track of all the monthly categories of articles without any references, but the counts for October, November, and December are missing. Now it would be great had these categories disappeared due to being cleaned out, but unfortunately that's not the case: combined they still have 6,000+ articles left to fix (sidenote: join WikiProject Unreferenced Articles! We have over 222,000 pages in the backlog!). Can anyone fix the progress template? Thanks, Altamel (talk) 20:55, 4 December 2014 (UTC)[reply]

I see:
October 2014  1,863
November 2014 2,615
December 2014 231
Did you try to purge before posting? This template also has a "(refresh)" link to do it. PrimeHunter (talk) 22:43, 4 December 2014 (UTC)[reply]
Yes, I've tried that and nothing happens. And the categories that missing are from October, November, and December 2006. Altamel (talk) 23:34, 4 December 2014 (UTC)[reply]
The documentation for {{Progress box}}, which all of the 'Articles lacking X progress' templates derive from, states that "[This] template will only list the last seven years backlog" - 2006 is more than 7 years ago, so the links to the 2006 categories won't appear. – Reticulated Spline (t • c) 23:52, 4 December 2014 (UTC)[reply]
Got it, thanks. Altamel (talk) 00:03, 5 December 2014 (UTC)[reply]
Well at least I documented the limitation. I suppose I had better add another year! All the best: Rich Farmbrough, 15:56, 7 December 2014 (UTC).
Ah! User Wbm has extended it to nine years, for which thanks. Let's try an make sure it doesn't need extending again! All the best: Rich Farmbrough, 16:01, 7 December 2014 (UTC).

Wildlife tourism is the sole member of Category:Articles lacking sources from October 2006. Whoever finds a reference for it, let me know and the appropriate barn-star will be awarded! All the best: Rich Farmbrough, 16:43, 7 December 2014 (UTC).

I have added one source. WhatamIdoing (talk) 18:48, 8 December 2014 (UTC)[reply]

Circumventing asynchronous script loading on Mediawiki

I have a script I've written on Commons which a lot of users load into their myskin.js file. It has a global function defined which I would like users to be able to call with their custom script. However, it appears the importScript function loads scripts asynchronously, and as such users are getting an error message: “ReferenceError: (my function) is not defined." (Background)

How can users force their custom script to load only after my script has finished loading? Magog the Ogre (t • c) 03:23, 5 December 2014 (UTC)[reply]

Perhaps the easiest way to do this is if your script triggers a custom event (for instance on the body tag) once it's been loaded. Users can then in their own file, which does the importScriptURI, put code that depends on your script into a handler for that event. In other words, they'd do in their myskin.js:
$('body').on('magogs_script_is_ready', function(e) {
  // Code that depends on your script here
});
importScriptURI('//commons.wikimedia.org/....'); // Wherever your script lives
and your script would do, once it's ready to be used, $('body').trigger('magogs_script_is_ready');. Optionally, you could even pass data with that event. Or perhaps the ResourceLoader's mw.loader.using() could be enhanced to work not only with module names but also with URLs. (Or does it already? I didn't check lately.) Lupo 06:04, 5 December 2014 (UTC)[reply]
  • JavaScript is asynchronous by nature. ResourceLoader has a mechanism to circumvent this using dependencies, but that is not available for scripts loaded throuhg importScript or importScriptURI(which are just aliases for mw.loader.load). The only reliable method to ensure synchronous execution in this case is by using a callback, which is way less clunky then Lupo's suggestion above (no offense intended). -- [[User:Edokter]] {{talk}} 10:03, 5 December 2014 (UTC)[reply]
    Out of curiosity: a callback from what? At least mw.loader.load() doesn't take a callback as far as I see. Lupo 12:06, 5 December 2014 (UTC)[reply]
  • Something else that you can use is MWiki's hook system. mw.hook('gadget.name.subpart').add( callback ) and mw.hook('gadget.name.subpart').fire( params, to, feed, to, callback ) That is a formalized 'MW'-way to trigger events and add callbacks to those events. mw.hook('wikipage.content') for instance is fired whenever wiki content is added to a page (VE, live preview or just initial page load). None of all that are formalized dependencies, those are only available to resource loader and gadgets so far. —TheDJ (talk • contribs) 11:52, 5 December 2014 (UTC)[reply]
an alternative is to use jQuery getScript()[22]. you will need to give your users the full url of the script (including the "ctype" at the end). it should look something like so (this example loads navpop from enwiki and then does something once it finish loading):
var url = '//en.wikipedia.org/w/index.php?title=MediaWiki:Gadget-popups.js&action=raw&ctype=text/javascript';
// assuming myFunc() you want to call once navpop is loaded and executed)
$.getScript(url, myFunc);
// of course, you can place the code directly inside the getScript() call, using anonymous function, like so:
$.getScript(url, function() {
    // do your thing
});
peace - קיפודנחש (aka kipod) (talk) 15:20, 5 December 2014 (UTC)[reply]
I don't recommend using getScript for this because although it works in most browsers, the documentation clearly states that "The callback is fired once the script has been loaded but not necessarily executed" [23] and I've had bugs in some browsers because of that in the past. Also, getScript() disables caching of the script file. You can use $.ajax() with cache: true instead, but that still leaves the first problem. --V111P (talk) 23:47, 5 December 2014 (UTC)[reply]
You generally try to avoid this problem by letting users set some variables before calling importScript() (e.g.: var magogCleanup_fast = true; and var magogCleanupFunctions = [["customFn", function () {/* ... */}, "My custom function"]];) and then when your script loads you read these variables and do whatever is appropriate. --V111P (talk) 00:15, 6 December 2014 (UTC)[reply]
Thank you everyone for your responses. I've gone with TheDJ's answer. Magog the Ogre (t • c) 16:10, 6 December 2014 (UTC)[reply]

How does sthe watchlist work?

This is mostly just curiosity, but what happens when I check my watchlist? Does the server have to call every page on it to see if they've been updated each time I check it? I feel bad about checking it often if large watchlists use up lots of server resources. --Cerebellum (talk) 11:46, 5 December 2014 (UTC)[reply]

Don't worry about it... The database contains a special "recent changes" table, which is automatically updated whenever a page is edited. Your watchlist checks this table to look for changed pages. This is quite an efficient process. -- [[User:Edokter]] {{talk}} 00:22, 6 December 2014 (UTC)[reply]
Watchlists also get handled by a separate DB server, so checking your watchlist won't impact the rest of the site. Bawolff (talk) 19:10, 7 December 2014 (UTC)[reply]

eMail

I am having problems with my personalised eMail account, me@thomassales.com. Wikipedia has stopped sending me eMails for pages on my watchlist that have been edited. I tried sending it to another account (my SCOLA eMail account), which received eMails fine, but when I tried to reset the registered eMail address on here no confirmation eMail was sent. I had similar issues with my previous, Overton Grange School eMail address of sales002k@suttonlea.org on Wikia. I need to hand my laptop to my local computer repairman because of a battery fault so I'll ask him to see if this is an issue at their end, but I want to see if there is a problem here. (If anyone needs to get into it, the log in page is webmail.easyspace.com and the password is the same as my Wikipedia account password.)--Launchballer 11:48, 5 December 2014 (UTC)[reply]

@Launchballer: We don't know your Wikipedia password, and can't find it out even if we wanted to; but we don't want to know what it is either. It's not a good idea to disclose your password - or even to suggest that somebody else use it, see Wikipedia:User account security - if you do, your account could be blocked for ever, per WP:COMPROMISED. --Redrose64 (talk) 13:40, 5 December 2014 (UTC)[reply]
I'm used to surrendering it to computer people. That said, without knowing one, how is one supposed to work out the other?--Launchballer 17:02, 5 December 2014 (UTC)[reply]
@Launchballer: It's probably because your mail provider has a problematic spam filter that is blocking the emails. Accessing your mailbox wouldn't be helpful in this case. You need to contact your mail provider to address this issue. Zhaofeng Li [talk... contribs...] 05:28, 7 December 2014 (UTC)[reply]

Character encoding outgoing links from a template for a target page expecting ISO-8859-1

I have written a template {{Almanacco}} to act as a wrapper for accesses to an external site. Everything is working except the passing of accented characters in one of the parameters. The problem seems to be that the Wikipedia's {{urlencode}} is encoding in UTF-8, and the target page is expecting ISO-8859-1 (the old ISO Latin 1)

Eg: If I want to search the target site for the word "Tragödie", I would invoke the template with

  • {{Almanacco | match=Tragödie}}

The template invokes {{urlencode}} and is given "Trag%C3%B6die" (UTF-8 encoding) which it duly embeds in the outgoing link URL, but the target page only understands "Trag%F6die" (ISO Latin 1). The search on the target page fails, and no matches are found.

The only solution approach that I can think of is to add some hairy programming in the template, specifically to handle each of the accented characters available in ISO Latin 1. This is beyond my skill set.

Can I request someone to code this for me? (or Is there another solution that has escaped me?) Scarabocchio (talk) 13:41, 5 December 2014 (UTC)[reply]

@Scarabocchio: only thing i can think of is to make the urlencode in the template conditional (i.e., add some "no urlencode" parameter to the template, such that when setting this parameter to anything, the template will use the raw link instead of the urlencoded one), and in those cases, handle the encoding manually (like so: Trag%F6die). peace - קיפודנחש (aka kipod) (talk) 16:15, 7 December 2014 (UTC)[reply]
I created a function in the Latin module that might do what is wanted here. For example {{#invoke:Latin|urlencodeISO88591|Tragödie}} yields Trag%F6die.
All the best: Rich Farmbrough, 23:48, 7 December 2014 (UTC).
@Scarabocchio: I installed it in your template, let me know if there are any problems. All the best: Rich Farmbrough, 23:57, 7 December 2014 (UTC).
@Rich Farmbrough: Excellent!! exactly what was needed, many thanks! Scarabocchio (talk) 05:04, 8 December 2014 (UTC)[reply]

Edit Count widget??

I wanted to use Phabricator for this, but I couldn't get my unified log-in stuff squared away......so, any-hoo: At the bottom of each 'User Contributions' page, there is a list of little widgets. One of my long-time favorites has been 'Edit count'......right on schedule, this "breaks" about every two years. I think whoever invented it and put it at Meta forgets about it. I love the pie chart, etc. that it generates!! Can someone please look at it and see if they can get it unconstipated? It's broken again, and just runs and runs and runs but doesn't do anything...... --Bddmagic (talk) 15:32, 5 December 2014 (UTC)[reply]

@Bddmagic: Have a look at the first section on this page. --NeilN talk to me 15:39, 5 December 2014 (UTC)[reply]
OK, well at least that sheds a bit of light on things. I'm not the only one who has noticed! --Bddmagic (talk) 16:20, 5 December 2014 (UTC)[reply]
Should this link be hidden until the counter is fixed? Or should a note be added stating that it's broken, with a link to the appropriate discussion? Thanks! GoingBatty (talk) 01:42, 7 December 2014 (UTC)[reply]

Problem with rendering a book

I have been trying to render my book but it keeps on failing It comes up with this message "Generation of the document file has failed. Status: Rendering process died with non zero code: 1" Heres a link - https://en.wikipedia.org/wiki/User:PerpetuaLux/Books/The_Codex_-_Physics Any help would be appreciated, I run on Ubuntu 14.04 and Mozilla Firefox 34.0 — Preceding unsigned comment added by PerpetuaLux (talk • contribs) 22:28, 5 December 2014 (UTC)[reply]

Both the Letter and A4 variants generated fine for me (Windows 10, Firefox 33; although I doubt that matters as the actual rendering is done server-side). Have you tried using a different browser and/or OS? – Reticulated Spline (t • c) 15:54, 6 December 2014 (UTC)[reply]

Responsive images

"Responsive web design" is based on CSS formatting that automatically resizes content based on the size of the viewport. It may be a good idea to implement responsive design for images only, so that we can display images in full size to fit the width of a container, be that the full page itself or a portion of it. This could be done via inline sytle or using media queries: 

style="max-width:100%;height:auto;"

- Cwobeel (talk) 23:46, 3 December 2014 (UTC)[reply]

To accommodate MSIE 9: 

max-width: 100%; height: auto; width: auto\9 — Preceding unsigned comment added by Cwobeel (talk • contribs) 23:10, 5 December 2014 (UTC)[reply]
Its not that simple. You need to overcome the default image containment by usurping the existing .css values and building your own template to act as an image container.

We've done something like this on Wikisource. See Temp Image Testing over there and (hopefully) you can resize your browser all day long and the images should dynamically resize themselves accordingly. -- George Orwell III (talk) 01:09, 7 December 2014 (UTC)[reply]

Problem with X_(Ed_Sheeran_album) appearing as "x (Ed Sheeran album)"

X_(Ed_Sheeran_album) appears as "x (Ed Sheeran album)" at the top of the page. This is in contradiction to Talk:X (Ed Sheeran album) and Talk:X (Ed Sheeran album)#Requested move. Can the x be capitalised? Gregkaye ✍♪ 08:12, 6 December 2014 (UTC)[reply]

@Gregkaye: It's set by the {{DISPLAYTITLE:''x'' (Ed Sheeran album)|noerror}} that is in the References section. --Redrose64 (talk) 09:23, 6 December 2014 (UTC)[reply]
Thank you that's really helpful! Gregkaye ✍♪ 14:20, 6 December 2014 (UTC)[reply]
@Gregkaye: I didn't realise that what you wanted was to de-lowercase and de-italicise the article title - in other words, to neutralise the effects of both the previously-existing {{DISPLAYTITLE:}} in the References section and the one that is built into {{Infobox album}}. Since this appears to be the case, the proper way, per the box at the top of {{Infobox album}} is to remove the one from the References section and add |Italic title=no to the infobox - like this. --Redrose64 (talk) 10:30, 8 December 2014 (UTC)[reply]
Thank you Redrose64 but to be fair I didn'trealise what I wanted either . It had been a while since I had referred to the RM and had forgotten all the content. gregkaye ✍♪ 11:18, 8 December 2014 (UTC)[reply]

Map template problem

Could someone please take a look at the map on the Cities and towns during the Syrian Civil War article. It is using a template that is some 2.5 times wider than normal page width, requiring a fair bit of scrolling to view it. When viewed on a tablet you get a full page map, with the text so small you almost miss seeing it. EG:-

<!--Transcluding {{Syrian Civil War detailed map}} makes the post-expand include size exceed the 2048000-byte limit. Substitute it instead.--> {{navbar|Module:Syrian Civil War detailed map}}{{#invoke:Location map/multi|load|Module:Syrian Civil War detailed map}} Richard Harvey (talk) 10:51, 6 December 2014 (UTC)[reply]

I removed the navbar template, which was doing nothing useful. I also removed the map on the grounds that it was breaking the page, but it has been restored by an IP. There is disagreement over removing the map, see the talk page. I have made a minor improvement to the map module in the sandbox, which relies (as does much of the module) on the module being used only on that page.
There are several similar maps
Though none of these are used in article space.
There are significant issues in keeping these maps updated and reliably referenced (they are not referenced explicitly, only in the sections relating to the towns, if at all). While these are being raised on the talk page of the article, and no disruption is taking place, most of the issues seem unresolved at a first glance. The general issue has also been raised at the OR noticeboard
I have suggested splitting the map that is used (and the article) by governorate, if that level of detail is needed. That would solve the problems with the size of the map, and the slow loading of the page. It would not, of course, resolve the RS/NPOV/OR... etc. issues.
Pinging @Jackmcbarn: who understands these modules/maps, and can probably help with the tech side.
All the best: Rich Farmbrough, 14:41, 8 December 2014 (UTC).

extra space at bottom which needs to be deleted

International_taxation#Notes 174.3.125.23 (talk) 13:00, 6 December 2014 (UTC)[reply]

The page looks fine to me (on Windows 10, Firefox 33) - could you upload a screenshot of what you see, and let us know what browser you're using? – Reticulated Spline (t • c) 14:56, 6 December 2014 (UTC)[reply]
I could see it using Chrome on my MacBook. Removing the columns in the explanatory notes section has made the white space go away. -- Diannaa (talk) 18:42, 6 December 2014 (UTC)[reply]
This is one of those things that varies between browsers, with Chrome being particularly badly affected (it miscalculates the bottom margin); it's come up a few times before on this page. Generally speaking, columns are almost never necessary when the number of notes is low - in this case there are six; and when columns are used and the notes are so long that all of them wrap to a second line, there are too many columns: in the example screenshot given above, they all wrap, and note 4 is worst at 8 lines. Going to a modest resolution - such as 1280px wide - makes it worse, where note 4 is now ten lines, and even note 1 is three lines. --Redrose64 (talk) 12:41, 8 December 2014 (UTC)[reply]

What Links Here would be less overwhelming for some pages if the results could be separated according to whether an item in what links here is a navbox or not. For example, if a page is linked to from sixty pages but on fifty of them the link is only in a navbox or two, we could focus our attention on the just ten that probably link to the page from inside the body or lead. Technically, I suppose this might be implemented by generating the list by examining the edit fields of pages other than navboxes in the Template namespace, thereby ignoring what's in navboxes, and examining navboxes in the Template namespace separately. In the case of a linking page having a link both in the body and in a navbox, it could be listed both ways. Nick Levinson (talk) 22:13, 6 December 2014 (UTC)[reply]

@Nick Levinson: Please see Wikipedia:Village pump (technical)/Archive 132#Amount of work for "What links here" to distinguish between links from within templates and those that aren't. and the earlier thread linked from there. SiBr4 (talk) 22:17, 6 December 2014 (UTC)[reply]
I really hate this when fixing links to a newly created disambiguation page. But there's nothing we can do about it besides getting rid of those silly boxes.
Actually, would it be reasonable to change the links in navboxes to a 'fake external' link, like is already done for the edit link at the top? The downside would be no bolding of the article you're at. --NE2 22:58, 6 December 2014 (UTC)[reply]
@NE2: - for your use-case, limit the "WLH" to templates first and fix them. Then, if you are in a hurry, null-edit the pages including the nav-boxes with AWB or some other tool. All the best: Rich Farmbrough, 00:07, 8 December 2014 (UTC).
It's a frequently requested feature. Here are some of the requests:
PrimeHunter (talk) 23:59, 6 December 2014 (UTC)[reply]
How about just changing the default results of What Links Here to be the either the article namespace or the current namespace, rather than "all"? — xaosflux Talk 00:26, 7 December 2014 (UTC)[reply]
You're not understanding the problem. You move Oak Hill, Virginia to Oak Hill, Fairfax County, Virginia to disambiguate. Then you go to fix the incoming links, and you find that everything on Template:Fairfax County, Virginia is in what links here (see Special:Whatlinkshere/Oak Hill, Fairfax County, Virginia for what it roughly looks like, though of course you're looking at pages that link to Oak Hill, Virginia). If you change the template, it takes several hours at least to propagate through the articles and reduce what links here to actual links that need to be fixed.
(Note that simply omitting all links generated by templates won't work, since other templates may need to be fixed manually:
US 1 north – Oak Hill.)
--NE2 05:25, 7 December 2014 (UTC)[reply]
Please, see also User:V111P/js/What Links Here link filter. Unfortunately it will also remove pages linking both from the body and a navbar template. --V111P (talk) 05:06, 7 December 2014 (UTC)[reply]

In terms of long-range planning, I wonder if it would be possible to move navboxes entirely out of articles, and place them in some sort of metadata footer? Whatamidoing (WMF) (talk) 19:29, 8 December 2014 (UTC)[reply]

At the bottom of my Talk Page (under == .. =) is certain links that I can not get rid of. I have tried everything. Any ideas how to remove those links? Thanks for the technical help.--Doug Coldwell (talk) 23:05, 6 December 2014 (UTC)[reply]

Do you mean the references now at User talk:Doug Coldwell#New Hamborough 2? They were automatically displayed at the bottom before because there was no {{reflist}} or similar telling where to display them. I added {{Reflist-talk}} PrimeHunter (talk) 23:22, 6 December 2014 (UTC)[reply]

Search results

Is there some problem with the search results that are not updating? I made an edit on 30 November to remove some text yet the text is still showing in the search results today. Also the search results indicate the last change to the page was on 8 November. Could be because in draft space but would not have though that would cause the problem - see Draft:Liam Payne Keith D (talk) 02:55, 7 December 2014 (UTC)[reply]

The edit is [24] This search gives me two results to the same page Draft:Liam Payne:
Draft:Liam Payne
"One Direction Invite You To Remix ‘Steal My Girl’ Read more at http://www.mtv.co.uk/one-direction/news/one-direction-invite-you-to-remix-steal-my
17 KB (1,681 words) - 14:35, 8 November 2014

Draft:Liam Payne
premiere Liam Payne's Big Payno remix of 'You & I'".  "One Direction Invite You To Remix ‘Steal My Girl’".  Rutter, Claire. "Liam Payne goes solo to drop
17 KB (1,659 words) - 23:31, 30 November 2014
Restricting the search to either "(Article)" or "Draft" shows that the November 8 result is registered in "(Article)" while the current version from November 30 is registered in Draft. For a few days in November the Draft namespace was declared a content namespace. See Wikipedia talk:Drafts#Draft namespace added to ContentNamespaces. One of the unfortunate consequences was that drafts were included in search results by default. Phabricator:T75136 shows this was reverted November 8. The Draft result in Article space has not been removed from search for some reason, maybe because the page was edited November 8 in a transition period. PrimeHunter (talk) 04:20, 7 December 2014 (UTC)[reply]

Technical difficulties in Template talk:Did you know?

I see some templates article nominations not transcluding properly. Is there a problem to the server or something? --George Ho (talk) 05:27, 7 December 2014 (UTC)[reply]

@George Ho: The transcluded templates are too long. Actually, the servers leaves a comment besides the omitted templates: <!-- WARNING: template omitted, post-expand include size too large -->. See also #Map template problem above. Zhaofeng Li [talk... contribs...] 05:52, 7 December 2014 (UTC)[reply]

Default editing - minor edits

As a bit of an experiment, I just went as reset my Preferences to all of the default settings, and I went and turned off all of the Gadgets that I had selected. I then went and edited a page (it doesn't matter which one) and noticed this problem: screenshot of bottom toolbar in default editor

Notice that the "minor edit" checkbox is cut off.
Who do we talk to about getting this resolved?
Ohms law (talk) 11:34, 7 December 2014 (UTC)[reply]

The problem originates in your vector.css. There you have set #minoredit_helplink to display: none;. So I think you should talk to yourself... -- [[User:Edokter]] {{talk}} 11:46, 7 December 2014 (UTC)[reply]
doh! Thanks. Ohms law (talk) 11:58, 7 December 2014 (UTC)[reply]

how to tag "not in citation given"?

I've seen it before, but I didn't notice how to make the tag "not in citation given", for when there's a controversial statement, with a citation, but the citation doesn't back the statement. How do you do that? Darx9url (talk) 16:26, 7 December 2014 (UTC)[reply]

Use the {{Failed verification}} tag. Roger (Dodger67) (talk) 16:32, 7 December 2014 (UTC)[reply]
Thanks! Darx9url (talk) 13:52, 8 December 2014 (UTC)[reply]

A bit of template help needed on {{GOCE award/sandbox}}

This is a request for a bit of help with the sandbox of a new template I have created, {{GOCE award/sandbox}}.

I am not a seasoned template creator, so the code is a dog's breakfast, but it works as intended (when substed, which is the intent). My only technical problem with it is that the month name is not substituted properly. It works, but when you subst the template into an editor's talk page, the resulting wikitext shows a bunch of code instead of a simple month name. I am trying to calculate the month name, and it uses substitution, but it does not substitute all the way down.

Any insight and advice you can provide will be welcome. Feel free to modify the sandbox code if you can find other ways to improve it. Thanks. – Jonesey95 (talk) 17:05, 7 December 2014 (UTC)[reply]

There are several parser functions and magic words in the template code that are not recursively substituted using {{{|subst:}}}. The ones I can find are four instances of {{#expr}} and the first of the two usages of {{formatnum}}. SiBr4 (talk) 17:25, 7 December 2014 (UTC)[reply]
Right. Hence my question here. Here's what the rendered code looks like at the moment when I subst it onto my sandbox page:
<!--The boxes below are generated by substition of [[Template:GOCE award]]-->
{| style="border: 2px solid gray; background-color: #fffff0;"
|rowspan="2" valign="middle" | [[Image:Goce silver barnstar.png|75 px]]
|rowspan="2"|
|style="font-size: x-large; padding: 0; vertical-align: middle; height: 1.1em;" | '''Guild of Copy Editors Leaderboard Award: Longest Article, 3rd Place'''
|-
|style="vertical-align: middle; border-top: 1px solid gray;" | This Leaderboard Barnstar is awarded to '''Jonesey95/sandbox''' for copyediting a 50,800-word article during the [[WP:WikiProject Guild of Copy Editors/Backlog elimination drives/{{#if:{{#expr:12-1}} |{{#switch:{{MONTHNUMBER|{{#expr:12-1}} }}|1=January|2=February|3=March|4=April|5=May|6=June|7=July|8=August|9=September|10=October|11=November|12=December|Incorrect required parameter 1=''month''!}}|Missing required parameter 1=''month''!}} 2014|GOCE {{#if:{{#expr:12-1}} |{{#switch:{{MONTHNUMBER|{{#expr:12-1}} }}|1=January|2=February|3=March|4=April|5=May|6=June|7=July|8=August|9=September|10=October|11=November|12=December|Incorrect required parameter 1=''month''!}}|Missing required parameter 1=''month''!}} 2014 Backlog Elimination Drive]]. Congratulations, and thank you for your contributions! – [[User:Jonesey95|Jonesey95]] ([[User talk:Jonesey95|talk]]) 17:59, 7 December 2014 (UTC)
|}
I'm looking for a fix for the unsubstituted code. – Jonesey95 (talk) 18:06, 7 December 2014 (UTC)[reply]
I was referring to the code of the template {{GOCE award/sandbox}}, not the code it results in if substituted. I now see the {{#expr}}s do have the substituting empty parameter {{{|subst:}}}, but it is misplaced: it should be {{{{{|subst:}}}#expr:...}}, not {{#expr:{{{|subst:}}}...}}. SiBr4 (talk) 18:21, 7 December 2014 (UTC)[reply]
I saw it wrong; the #expr functions don't have {{{|subst:}}} in front of them. Adding these should fix it. SiBr4 (talk) 18:26, 7 December 2014 (UTC)[reply]
Much appreciated. However, after all that, the output looks essentially the same to me. Here it is now, when I subst the template:
{{subst:GOCE award/sandbox|award=longest|place=3|number=50800}}
<!--The boxes below are generated by substition of [[Template:GOCE award]]-->
{| style="border: 2px solid gray; background-color: #FFFFF0; vertical-align: middle;"
|rowspan="2" | [[File:Goce silver barnstar.png|75 px]]
|rowspan="2"|
|style="font-size: x-large; padding: 0; vertical-align: middle; height: 1.1em;" | '''Guild of Copy Editors Leaderboard Award: Longest Article, 3rd Place'''
|-
|style="vertical-align: middle; border-top: 1px solid gray;" | This Leaderboard Barnstar is awarded to '''Jonesey95/sandbox''' for copyediting a 50,800-word article during the [[WP:WikiProject Guild of Copy Editors/Backlog elimination drives/{{#if:11 |{{#switch:{{MONTHNUMBER|11 }}|1=January|2=February|3=March|4=April|5=May|6=June|7=July|8=August|9=September|10=October|11=November|12=December|Incorrect required parameter 1=''month''!}}|Missing required parameter 1=''month''!}} 2014|GOCE {{#if:11 |{{#switch:{{MONTHNUMBER|11 }}|1=January|2=February|3=March|4=April|5=May|6=June|7=July|8=August|9=September|10=October|11=November|12=December|Incorrect required parameter 1=''month''!}}|Missing required parameter 1=''month''!}} 2014 Backlog Elimination Drive]]. Congratulations, and thank you for your contributions! – [[User:Jonesey95|Jonesey95]] ([[User talk:Jonesey95|talk]]) 00:06, 8 December 2014 (UTC)
|}
I see that "{{#expr:12-1}}" has been replaced with "11", but I still see all of the if/switch/MONTHNUMBER code. Is it too many recursion levels deep to make it fully substitutable? – Jonesey95 (talk) 00:14, 8 December 2014 (UTC)[reply]

I think I've got it sorted now. Thanks to both of you for your help. I was able to achieve the desired effect (no parser functions in the resulting message on the editor's talk page) by essentially removing one layer of recursion, moving some of the raw code from the "MONTHNAME" function directly into my template. You can see what I changed here. – Jonesey95 (talk) 05:26, 8 December 2014 (UTC)[reply]

Resolved

Magic word for article subject

For a disambiguated article like [[John Doe (example)]], is there a magic word, similar to {{PAGENAME}}, but that will return just "John Doe"? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:53, 7 December 2014 (UTC)[reply]

There is no magic word, but there is a magic word like template : Template:PAGENAMEBASE. Cenarium (talk) 18:58, 7 December 2014 (UTC)[reply]
@Cenarium: Thank you. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:11, 8 December 2014 (UTC)[reply]
Moved to Template talk:USCongDistState § Request help removing incorrect links

Although Special:WhatLinksHere/16 includes Template:USCongDistStateOH and many Ohio congressional district articles, I can't find the link to 16. Could someone please help me with this? Thanks! GoingBatty (talk) 01:13, 8 December 2014 (UTC)[reply]

From some quick testing, the template is just Template:USCongDistState with some terms filled in, including current=16. Changing this value to 15 drops it off of the WhatLinksHere/16 and puts it into WhatLinksHere/15. Illinois, with 18 districts, appears in WhatLinksHere/18. There are multiple ParserFunctions in USCongDistState calling current that I can't unravel. Nanonic (talk) 01:45, 8 December 2014 (UTC)[reply]
@Nanonic: OK, I moved the conversation to that template's talk page - thanks! GoingBatty (talk) 02:53, 8 December 2014 (UTC)[reply]

Proposal: new tool for making redirects

If I want to create a new redirect to an existing page, perhaps for an alternative name or spelling, I have to do the following:

  1. Copy the page name
  2. Type the new name in the search box
  3. Click "Search"
  4. Select the red link
  5. Paste the page name
  6. Select the pasted text
  7. Click the "Redirect" button on the toolbar
  8. Figure out which "Redirect from..." template to use
  9. Type two new lines
  10. Type (or copy and paste, in another tab) the "Redirect from..." template name
  11. Enter an edit summary
  12. Click "Save"

I would like to see a new "make redirect" tool (perhaps a user script, or later a gadget), where I would:

  1. Click the tool (in, say, the "tools" menu)
  2. Type the new name
  3. Select a "Redirect from" template from a drop-down menu
  4. Click "Save"

and the tool would do everything for me, including checking that the new name is not already in use.

Would anyone like to code such a thing? I'd be happy to do testing. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:23, 8 December 2014 (UTC)[reply]

VisualEditor does most of what you want: Edit the page, go to the Page options (three-bar) menu on the left, choose "Page settings", and type in the name that you want. "R from" templates are added via the Insert > Template menu. Whatamidoing (WMF) (talk) 19:34, 8 December 2014 (UTC)[reply]
Steps 8-11 are unnecessary (redirects get auto-edit summaries). 5 and 7 can be reversed, making 6 unnecessary. That's 7 steps, which is probably no more than your proposed tool when you list each click/copy/paste. --NE2 19:45, 8 December 2014 (UTC)[reply]

Tech News: 2014-50

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

Recent software changes

  • All users are now getting pages from servers that run the HHVM tool. HHVM should make pages load faster. [25]
  • You can join a video chat about Phabricator on December 11 at 18:00 (UTC). Phabricator is the new tool to report issues. [26]

Problems

  • There was a problem with Phabricator on November 29. It was due to a network issue. [27]

Software changes this week

  • The new version of MediaWiki (1.25wmf11) has been on test wikis and MediaWiki.org since December 3. It will be on non-Wikipedia wikis from December 9. It will be on all Wikipedias from December 10 (calendar). [28]
  • You can now exit VisualEditor by pressing the "Esc" key. [29]
  • It is now easier to use VisualEditor with IMEs. Typing in Malayalam now works better. [30] [31]
  • The new version of OOjs UI fixed many issues with the size and layout of buttons in dialogs. [32] [33] [34]
  • (Lua) You can no longer use mw.text.unstrip to get the HTML from special page transclusion. You can see a list of scripts to fix. [35] [36]

Future changes

  • Starting next week JavaScript tools won't work if they use jQuery Migrate. [37]

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

17:11, 8 December 2014 (UTC)

Gadgets not working

Some of my gadgets have stopped working (Twinkle, navigation popups, reference tooltips, double clicking to edit page). I'm using the vector skin and Firefox 34.0 (just updated but they weren't working in 33.1 either). Does anyone know what could be causing it or how to fix it? Sarahj2107 (talk) 19:18, 8 December 2014 (UTC)[reply]

The media viewer and visual editor have also stopped working. Looks like a server issue. Cenarium (talk) 19:22, 8 December 2014 (UTC)[reply]
Twinkle is not working for me either. Bummed, because that thing is so useful. — kikichugirl inquire 19:29, 8 December 2014 (UTC)[reply]

It looks like it's working again. Cenarium (talk) 19:33, 8 December 2014 (UTC)[reply]

Not for me. Altered my UI, no Twinkle etc, destroyed my useful pop-ups. WMF, rollback please.  Philg88 ♦talk 19:47, 8 December 2014 (UTC)[reply]
This problem affects all Javascript (intermittently) and is being fixed right now. Some performance improvements were not deployed correctly.
The devs and ops people apologize for their mistake. Whatamidoing (WMF) (talk) 19:54, 8 December 2014 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&oldid=637215733"