Wikipedia:Village pump (technical)

From Wikipedia, the free encyclopedia
  (Redirected from Village pump (technical))
Jump to: navigation, search
  Policy   Technical   Proposals   Idea lab   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.

« Older discussions, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132
Centralized discussion
Proposals: policy other Discussions Ideas

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


So...[edit]

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)

@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)
@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)
@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)
@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)
"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)
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)
@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)
  • 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)
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)
"EOL" = "end of life". --Anthonyhcole (talk · contribs · email) 08:23, 24 November 2014 (UTC)

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)

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

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

...and it's not working again. Narutolovehinata5 tccsdnew 14:15, 17 November 2014 (UTC)
... 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)

Tools[edit]

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

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)

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

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

What do you meany by 'security holes' - apologies if I've missed something somewhere, genuinely curious! Reticulated Spline (tc) 01:58, 19 November 2014 (UTC)
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)
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)

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)

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

Proposal: enable opt-in two-factor authentication[edit]

Two-factor authentication has become popular in the last few years as a number of big online service providers like Google, Facebook, Evernote, Dropbox and Apple's iCloud have enabled it to increase the security of user accounts. It makes it so that when you login you have to type in a one-time password that is generated, usually by an application installed on a mobile device. There are two extensions for MediaWiki available: OATHAuth and TwoFactorAuthentication that could provide two-factor authentication for users of Wikimedia wikis including Wikipedia.

I propose something like this: to increase user account security (especially for administrators, functionaries and others with elevated user rights), we ask the Wikimedia Foundation to consider installing an optional TOTP-based two-factor authentication solution on English Wikipedia (and other Wikimedia Foundation wikis subject to further community consultation) if an implementation can be found that passes reasonable security auditing and user testing and integrates reasonably with CentralAuth. Users would not be required to use two-factor authentication, and a reasonable recovery process should be instituted.

  • Support as proposer. —Tom Morris (talk) 14:58, 17 November 2014 (UTC)
  • Support. It would be nice if it had Google Authenticator support, though I don't know how the backend verification works on that, and if you have to query Google servers in order to verify the time-based token, I wouldn't use it. 0x0077BE (talk · contrib) 15:01, 17 November 2014 (UTC)
    0x0077BE: Google Authenticator is a popular implementation of TOTP, but Google Authenticator does not (as far as I know) contact Google's servers when you authenticate (only way to be sure would be to use it and monitor traffic from the device to see). You can use it when your device is offline. I personally use Authy on iPhone but there are a variety of implementations including Red Hat's open source FreeOTP. There's a whole list of implementations on this article: Time-based One-time Password Algorithm. There may be broken (intentionally or not) implementations of TOTP, but it is up to the user which TOTP client they use. —Tom Morris (talk) 15:07, 17 November 2014 (UTC)
Yeah, I know that the Authenticator doesn't contact the servers, but I don't really know much about the back-end on the server side. If Wikipedia can generate Authenticator-compatible tokens on their own servers, then I'd be in favor of that, but if Wikipedia has to contact Google to get a token, I wouldn't use it. I imagine that no contact to Google will be necessary, since that would presumably significantly complicate the security by adding unnecessary connections that need to be secured. If Authenticator is just an implementation of a specific protocol (I had always thought of TOTP as referring to the class of time-based token generators, not a specific algorithm, but I never looked into it), then obviously it would be possible to have Authenticator support with no Google involvement. 0x0077BE (talk · contrib) 15:18, 17 November 2014 (UTC)
0x0077BE: Nope, the WMF wouldn't have to contact Google's servers (or anybody else's) to generate the keys. —Tom Morris (talk) 15:26, 17 November 2014 (UTC)
  • Oppose for now. I like the idea, but my experience with OATHAuth on wikitech has been less than ideal. I've gotten locked out of my account more than once and I fear others will accidentally do the same. I'd like to see improvements to these extensions before using them wider. ^demon[omg plz] 15:24, 17 November 2014 (UTC)
    @^demon: Do you remember what led to you being locked out? Jackmcbarn (talk) 03:36, 18 November 2014 (UTC)
    Wiped my phone, got a new phone. Had lost my recovery key thingie. ^demon[omg plz] 18:58, 18 November 2014 (UTC)
    Yeah, it should probably provide more recovery options (SMS, email, etc.), and the UI of both extensions aren't exactly user-friendly IMO. Zhaofeng Li [talk... contribs...] 22:41, 18 November 2014 (UTC)
  • Support in principle depending on sufficient and positive technical and user review of any implementation. -- KTC (talk) 15:57, 17 November 2014 (UTC)
  • Oppose: Both of these extensions seem to be at an early stage in development. Also, there is another much more serious reason not to enable them. That reason is that OATHauth will not work on wikipedia, as wikipedia does use MariaDB, and OATHauth only has support for MySQL, as can be seen in bugzilla:65658. I would not be surprised if the same applies to TwoFactorAuthentication as it is based on the former.--Snaevar (talk) 16:07, 17 November 2014 (UTC)
    Uhh, MariaDB is basically MySQL. Legoktm (talk) 17:04, 17 November 2014 (UTC)
    What Legoktm said. The bug referred to an issue with running on Postgresql. Postgres is very different from MySQL. MariaDB is not. —Tom Morris (talk) 17:10, 17 November 2014 (UTC)
  • Question: I would like the proposer to provide an explanation in a reliable source of the benefits of two-factor authentication. In particular, since this is to be an opt-in and most who opt-in will probably be using good security practices, how will this benefit the user who uses an encrypted connection, does not use the same password on all his/her accounts, and doesn't keep the password posted on a bulletin board next to the computer? Jc3s5h (talk) 17:15, 17 November 2014 (UTC)
Using two-factor authentication is part of good security practices, and I don't think it's true that someone who otherwise uses good security will be immune to attacks. I imagine many people who would enable this do not disable Javascript and other scripting by default, making them immune to many zero-day attacks which could secretly harvest passwords. Additionally they may not be sufficiently careful about not logging in from potentially compromised terminals (or indeed they wish to be able to log in from potentially compromised terminals without allowing replay attacks) - both of which are attacks that could be mitigated by a TOTP or other two-factor authentication system. 0x0077BE (talk · contrib) 17:47, 17 November 2014 (UTC)
Basically what 0x0077BE said. TOTP-based two-factor auth is a tool that a security-conscious user can add to their arsenal. You can't use it for every website, because not every website has it deployed. But it is worth enabling on key security assets—that is, accounts where you need enhanced security. We like to pretend that adminship is no big deal, but the ability to hand out blocks and the ability to view deleted content are important things that are entrusted to administrators. To me, anyway, though I've made some mistakes in the past, I try hard to go about doing my admin tasks in a trustworthy and responsible way. Having the ability to make my Wikipedia account as secure as, say, my Facebook account would be quite nice. —Tom Morris (talk) 21:48, 17 November 2014 (UTC)
  • Support The WMF uses this now on Wikitech, so we know there's no big problems. Jackmcbarn (talk) 03:35, 18 November 2014 (UTC)
  • Support. Security wise, i see this as a great idea. In fact until I saw it here I was going to propose it myself. LorChat 00:25, 25 November 2014 (UTC)
  • Support but no external services and smart phones are not secure devices. People who want to opt in can upload their PGP public key and the system can challenge them to decrypt a single use key when they log in. With public/private key encryption trusting a 3rd party defeats the purpose. Chillum 00:29, 25 November 2014 (UTC)

Chrome vs. Firefox Wikipedia rendering[edit]

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)

  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)
You could add "word-break: break-word;" to either the infobox table cell containing links, or to the Module:URL. —TheDJ (talkcontribs) 16:56, 18 November 2014 (UTC)
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)
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)
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)
I'm reminded of <http://dowebsitesneedtolookexactlythesameineverybrowser.com/>. :-) --MZMcBride (talk) 05:25, 19 November 2014 (UTC)
Just fix this word-break bug and will be ok. --Rezonansowy (talk | contribs) 12:15, 19 November 2014 (UTC)
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)
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)
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)
Village pump (technical)
Website https://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)
A soft hyphen has better support. -- [[User:Edokter]] {{talk}} 09:37, 26 November 2014 (UTC)
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)
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)
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)
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)
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)
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)
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/wbr
Codename Lisa (talk) 21:25, 27 November 2014 (UTC)
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)
IE6 passed the test. Codename Lisa (talk) 22:03, 27 November 2014 (UTC)
IE7 passed the test. Codename Lisa (talk) 23:02, 27 November 2014 (UTC)
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)
────────────────────────────────────────────────────────────────────────────────────────────────────
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)
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}} (etc) 00:49, 28 November 2014 (UTC)
Screen spec please. Best regards, Codename Lisa (talk) 02:42, 28 November 2014 (UTC)
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)
I've implemented the first test. It is an alpha version, so you can find it at User:Codename Lisa/sandbox. Module is implemented at Module:Sandbox/Codename Lisa/wbr test. Let me know what you think while I familiarize myself with Lua. Best regards, Codename Lisa (talk) 19:53, 27 November 2014 (UTC)

Weird user page view stats[edit]

There are a number of user pages (all?) getting anomalous view stats in the last few days. [1][2][3][4][5][6]. I could be wrong, but the size of the spike seems to corrolate with the number of page watchers or maybe edit count. No big deal. Just curious if anyone knows what's going on. --Anthonyhcole (talk · contribs · email) 13:17, 19 November 2014 (UTC)

Not sure if this is related to the bug that was discussed back in June. That one still seems unresolved; I'm seeing huge spikes from October for some articles.[7][8][9] User:Ironholds might be able to give us an update on the issue. --Paul_012 (talk) 15:15, 24 November 2014 (UTC)
It's unresolved in the sense that there's no mechanism to prevent it, sure; we know, however, what happened. These spikes are comparatively tiny and probably not worth investigating, though. Ironholds (talk) 17:54, 24 November 2014 (UTC)
Can you tell us what happened without stepping on beans? — HHHIPPO 20:09, 24 November 2014 (UTC)

Reference wrapping to the next line[edit]

Depending on how a screen is set, a reference may wrap to the next line, which looks awkward and strange. See Reference 41 from the end of the paragraph in this screenshot File:Screenshot_showing_ref_wrap.jpg from Philae (spacecraft). There is no space between "November." and the start of the reference. Is there a way to keep this from happening? Bubba73 You talkin' to me? 01:23, 20 November 2014 (UTC)

@Bubba73: What browser are you using? For me, In Firefox and IE9 on Win7, the reference always appeared on the same line as the preceding word and full stop. — Mr. Stradivarius ♪ talk ♪ 01:55, 20 November 2014 (UTC)
I'm using IE11 on Windows 8.1. Bubba73 You talkin' to me? 02:57, 20 November 2014 (UTC)
Couldn't help but chime after trying to reproduce the same effect using the same Philae (spacecraft) article earlier with no luck and now see we happen to have the same setup. Fiddled with the basic IE11 font families & browser widths but no matter what I tried, the point where it decided to wrap was never after the period and opening bracket of the ref [like in the pic above] but seemed to always happen between the word "at" and the 00:36 time stamp that followed.

Seems like a css thing to me but I'm not up on the latest dealing with inline elements & no-break-before attributes to be honest. -- George Orwell III (talk) 03:38, 20 November 2014 (UTC)

For me the problem goes away if I make the text larger or smaller. But then it might happen somewhere else. I think I've seen it elsewhere. I think I have my Windows font size set at 125%, if that could matter. Bubba73 You talkin' to me? 03:57, 20 November 2014 (UTC)
This is one of those things that has come up previously; there's something in the archives of this page (such as Wikipedia:Village pump (technical)/Archive 125#Superscript numbers are going onto the next line of text). The point at which wrapping occurs (and the decision to wrap) varies a great deal. Factors that influence it (some of which were mantioned above) include: physical screen resolution; operating system; installed fonts; browser; window sizing; zoom level; style sheets; page layout. The only ones we can exercise any control over are the last two; and trying to get it "right" for one user may well get it "wrong" for others. We try to satisfy the majority, but can never achieve universal success. --Redrose64 (talk) 11:35, 20 November 2014 (UTC)
Help:Reference display customization has two methods for resolving this. Looks like IE 8+ should support the before pseudo-element.[10] --  Gadget850 talk 13:22, 20 November 2014 (UTC)
It seems to me that a simple rule "if there is no space, don't break" would be an easy solution. Bubba73 You talkin' to me? 18:16, 20 November 2014 (UTC)
I wonder what would happen then, if you had a long string of refs—one so long that it was wider than your screen? (That's not difficult to do for someone who has a smartphone.) WhatamIdoing (talk) 21:43, 25 November 2014 (UTC)
  • Would {{zwj}}, something I found recently, be a red herring here..? Sardanaphalus (talk) 17:42, 21 November 2014 (UTC)
  • {{Zwj}} is as good as anything for a workround. I have used {{Nowrap}} on the article to stop "15 November" from being broken. I don't think we can insert zero-width-joiners between every "." and "<ref>", so the general solution will rely on making the bug reproducible and raising a bug. All the best: Rich Farmbrough22:16, 22 November 2014 (UTC).
  • Now it is wrapping after "hard as ice" for me, highlighted in blue in File:Ref wrap problem 2.jpg. Bubba73 You talkin' to me? 00:22, 23 November 2014 (UTC)
  • Note that in the two screenshots, the references with the problem are #41, but they are now different references. The problem couldn't have anything to do with the number 41, could it? Bubba73 You talkin' to me? 03:14, 23 November 2014 (UTC)
  • I'm no expert, but I doubt it. Per Redrose64 above, this looks like one of those "Varies according to the browser, its version, the phase of the Moon..." Sardanaphalus (talk) 09:52, 23 November 2014 (UTC)

Extra tab for merge pages[edit]

I would like to add a tab (in Monobook skin) for the merge page (the url would be https://en.wikipedia.org/w/index.php?title=Special:MergeHistory&target={{urlencode:{{FULLPAGENAME}}}}) before the Twinkle tabs. How can I do it? (I assume it would be some relatively simple javascript, but I don't know.) עוד מישהו Od Mishehu 14:22, 20 November 2014 (UTC)

@Od Mishehu:
mw.util.addPortletLink('p-cactions', mw.config.get('wgScriptPath') + '/index.php?title=Special:MergeHistory&target=' + encodeURIComponent(mw.config.get('wgRelevantPageName')), 'Merge history');
Jackmcbarn (talk) 16:35, 20 November 2014 (UTC)
I tried, but it didn't work. עוד מישהו Od Mishehu 19:14, 20 November 2014 (UTC)
@Od Mishehu: It works for me (in Monobook). Does the link not appear at all, or does it appear but not work? Jackmcbarn (talk) 01:42, 21 November 2014 (UTC)
No merge tab.png
It doesn't appear at all. עוד מישהו Od Mishehu 04:48, 21 November 2014 (UTC)
Try putting JSconfig.keys['HotCatMinorSingleChanges'] = true; at the end of the file. It seems to prevent lots of other links from showing too. Cenarium (talk) 09:44, 21 November 2014 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────Thank you, Cenarium, the tab is there now. How do I put it before the Twinkle tabs? עוד מישהו Od Mishehu 12:15, 21 November 2014 (UTC)

I don't know. I'm not using TW, I'd like it only for user talk warnings. Cenarium (talk) 13:47, 21 November 2014 (UTC)

Cirrus search[edit]

I am having a lot of trouble with searching:

An error has occurred while searching: Search is currently too busy. Please try again later.

Maybe this needs to be backed out? All the best: Rich Farmbrough22:10, 20 November 2014 (UTC).

I am seeing the pool queue getting a little filled with traffic. The nice thing about these errors is that they're transient and tend to only come in waves...you can always try again shortly as the message says. All that being said, the error's not nice and we can probably adjust the queue size further (fwiw, this used to happen with MWSearch too, I'm surprised you haven't seen it before considering how common it is/was). BZ/Phabricator are down right now for migration but I'll get a task filed Monday for looking at this further. ^demon[omg plz] 17:40, 21 November 2014 (UTC)
I had a look at this as well just now. The good news is that the problem comes in waves and the wave you saw was the worst one. The bad news is that its happening at all. I see a spike in load right before you posted this message but nothing interesting in the logs. The load spike was long enough ago that I've lost precision on how long it was but if I had to guess it'd coincide with us serving these errors from 22:06 to 22:09 UTC. I don't _think_ this is a rollback thing because we're used to seeing these from the old system as well. Admittedly the old search produced a constant chatter of these while the new one is silent and save for a few complaints and one *huge* spike right before you reported this. The current plan is to segment the prefix searches from the full text searches sometime early next week. When this happens next this'll let us figure out if the spike is caused by one particular flavor of search and it'll preserve the other flavors in the process. NEverett (WMF) (talk) 18:23, 21 November 2014 (UTC)
Oooh! I just tracked the spike that you saw down to a super duper troll search. I'll see if I can setup some more defences for it. You'd be amazed at what people try and search for.... NEverett (WMF) (talk) 18:27, 21 November 2014 (UTC)
When was Cirrus implemented? I had some other search bugs that I didn't log, but I might be able to recreate if I have reason to think they are relevant to the current search engine. All the best: Rich Farmbrough22:21, 22 November 2014 (UTC).
It's been under active development for the last year and a half; it was deployed as the default for English Wikipedia just the other day on the 19th. The old search engine is still accessible by appending &srbackend=LuceneSearch to your Special:Search or API queries (great for comparing to see if bugs still exist or have been added :)) ^demon[omg plz] 01:49, 23 November 2014 (UTC)

Wikimedia technology blog[edit]

So, I was just reading the Wikimedia technology blog, and it struck me that it would be good to have a bot or something post a note here on VPT when there is a new post written. It seems to me that a lot of the editors that read this page would be interested in what the technology blog has to say, but at the moment I don't imagine that many are aware of it, and that even less remember to check back for updates. Is there an easy way that we can get notifications of new posts here? — Mr. Stradivarius ♪ talk ♪ 15:11, 22 November 2014 (UTC)

👍 Like A bot that periodically makes a note of new posts here in batches will work. Alternatively, we can integrate it into the weekly Tech News. Zhaofeng Li [talk... contribs...] 04:13, 23 November 2014 (UTC)
Tech News already features them (but if someone has time, please feel free to double-check if links are there and add them if they're not!). --Elitre (WMF) (talk) 10:25, 26 November 2014 (UTC)

Proposal to add "report technical issue" to Wikipedia:Contact us[edit]

Does Wikipedia have a place for users to report bugs? (eg, a WMF email address?) Having so would seem like a commensense move to let readers report issues they are having. I was surprised that this is not present on Wikipedia:Contact us. If there's an email address, can another user point it out? Otherwise I think it would be quite useful to have one. --Tom (LT) (talk) 21:00, 22 November 2014 (UTC)

You can report Wikipedia bugs on this page (if the issue is specific to our templates, modules, etc.), or at Phabricator (if it is related to the server software). If unsure, the best place to post is this page - if the bug report should have been placed in Phabricator, someone else will point you in the right direction (or even do it for you).
Note that, as I write this, Phabricator is down for maintenance; it will most likely be restored on Monday.
I would support adding a brief sentence or two relating to technical issues to the "Readers" section of WP:Contact us; seems like a sensible idea. — This, that and the other (talk) 04:34, 23 November 2014 (UTC)
Note that the top of this page mentions where to put "Bugs and feature requests". --AKlapper (WMF) (talk) 18:00, 23 November 2014 (UTC)
There really isn't a good place for non-technical non-editors to report technical issues. Most of the email addresses on the Contact Us page go to one of the info-en OTRS queues and there is a tech-issues queue. But unless it's a really easy answer they tend to sit around for a long time (weeks, sometimes) with no response or they're referred elsewhere (here, mailing lists). From what I understand, Phabricator won't be any more layperson-friendly than Bugzilla (probably worse), so that's probably not the best place to refer readers. This page is probably easier to figure out than Phabricator and more likely to get a response than OTRS. But for a non-editor, it may still be difficult. Mr.Z-man 17:53, 23 November 2014 (UTC)
Compared to Bugzilla, Phabricator will improve the situation in some areas. The most common complaints I've heard about Bugzilla apart from its user interface were the separate login and the fact that email addresses were exposed. Both is not the case anymore with Phabricator. Also see mw:Phabricator/versus_Bugzilla for a list of improvements and known issues. Personally I'd say that I'm still waiting for that perfect bugtracker fitting everybody's needs and tech-savvyness levels and I'm convinced that I'll still be waiting in 50 years - it's always a compromise/trade-off. Plus it can be really hard to define or find out where a bug starts and where "strange but intended behavior" or user support questions end, as expectations are something subjective. :-/ --AKlapper (WMF) (talk) 18:00, 23 November 2014 (UTC)

Login page on iPad 1[edit]

I can no longer check "Keep me logged in" on my iPad 1. The checkbox doesn't function. Is this a known problem? Thanks -- Jo3sampl (talk) 03:33, 23 November 2014 (UTC)

But you can successfully log in? Which browser is this about? --AKlapper (WMF) (talk) 18:03, 23 November 2014 (UTC)

Thanks -- I can log in -- it's just the control next to "Keep me logged in" that doesn't work. The browser is Safari (native for the iPad). I'm having trouble finding a version ID, but the version corresponds to IOS 5.1.1, the last operating system update for iPad 1. I think I'll have to accept the idea that I'm (pretty much) the last WP editor using iPad 1. Christmas is coming . . . Thanks again -- Jo3sampl (talk) 23:29, 23 November 2014 (UTC)

Reported in the ticketing system. —TheDJ (talkcontribs) 13:21, 24 November 2014 (UTC)

Edit counts (again)[edit]

Last time I looked (often I can't even reach the page) it said 1500 minutes behind. It's got stuck again and needs a kick.

I imagine the original provider wasn't expecting a delay of more than a few minutes, so didn't bother to parse it into hours (and days!)

Unbuttered parsnip (talk) mytime= Sun 20:25, wikitime= 12:25, 23 November 2014 (UTC)

You should contact the maintainer of the tool about this (also note you do not need to interwiki link your signature!) --Mdann52talk to me! 13:32, 23 November 2014 (UTC)
i all I know is it's a button at the bottom of my "User contributions" page. How am I supposed to know who maintains it, and why should I care?
ii it's supposed to stop redlinks when I write on other wiki pages. Doesn't seem to work with commons though. What difference does it make to anybody? --Unbuttered parsnip (talk) mytime= Sun 22:48, wikitime= 14:48, 23 November 2014 (UTC)
Issues with Xtools can be reported to the maintainers at https://github.com/x-Tools/xtools/issues. There are tools looking for internal wikilinks in page sources. [[:en:User:Unbuttered Parsnip]] is formatted like an interwiki link to another wiki and may confuse some tools. It can also confuse readers looking at the page source. I'm not sure what your redlink comment means but a red link is a wikilink to a non-existing page at the same wiki. You have not created a Commons user page at commons:User:Unbuttered Parsnip so a wikilink to that page from another Commons page will be red. PrimeHunter (talk) 15:33, 23 November 2014 (UTC)
Last time I looked, the signature you define at enwiki will have no effect at another wiki. I guess you mean you just copy/paste the identical wikitext for use on other wikis? You should omit the ":en:" from your signature here. Johnuniq (talk) 00:19, 24 November 2014 (UTC)

Undo|thank[edit]

I am feeling somehat hard-done by. On the Revision History page for this article, I am the only editor who does not have (undo|thank) by their username. It is the same on a related page, where many usernames don't have (undo|thank) by their name. Why is this? ~ P123ct1 (talk) 17:10, 23 November 2014 (UTC)

You cannot thank yourself. Others see a thank link at your edits. Edits by bots and IP's don't have a thank link. Islamic State of Iraq and the Levant is semi-protected so there are no IP edits. PrimeHunter (talk) 17:17, 23 November 2014 (UTC)
Why didn't I think of this? About the bots and IPs I might just have guessed. ~ P123ct1 (talk) 17:58, 23 November 2014 (UTC)

SUL tool returns: 404 - Not Found[edit]

I've noticed, while trying to process requests for accounts, that our Toollabs:quentinv57-tools/tools/sulinfo.php has been returning "404 - Not Found" for at least a few days now. This is a fairly critical tool to the assessment of whether or not request for usernames that are similar to existing usernames should be accepted as the existing name has been ACTIVE or not. If someone could look into this, that would be great. — {{U|Technical 13}} (etc) 18:45, 23 November 2014 (UTC)

Now that centralAuth shows unattached accounts is the tool still necessary? –xenotalk 18:58, 23 November 2014 (UTC)
  • The SUL tools does offer a little more information than CA, including more accurate registration dates (all accounts in CA created before April of 2013 show as April 2013). IIRC, SUL tool also offers a date for last activity that CA does not. — {{U|Technical 13}} (etc) 19:09, 23 November 2014 (UTC)
  • Thanks. Yes it would be nice to have this tool back. –xenotalk 18:11, 24 November 2014 (UTC)
Quite a few of the tools are returning 404 at the moment it seems - at least that's what I've been experiencing, and a brief scatter-shot test just now did nothing to convince me otherwise! Reticulated Spline (tc) 19:02, 23 November 2014 (UTC)
Resolved
per User_talk:Cyberpower678#SUL_info. Thanks Cyberpower. — {{U|Technical 13}} (etc) 17:26, 25 November 2014 (UTC)

So (again)...[edit]

MPelletier (WMF), what's the haps? The tools are down again? I see that Whatamidoing (WMF) also weighed in, above, but I didn't understand what they were saying; I only got the sarcasm. Look, I really don't care who runs what and in what way. I want a working edit count and article creation count, and I want the WMF to make that happen. Please. Drmies (talk) 02:31, 24 November 2014 (UTC)

Hey Drmies, perhaps I can help talk about this. Please note that I'm not an engineer nor a lawyer :)
The tools that run on labs, just like the tools that ran on toolserver, are the responsibility of the tool owner. Perhaps you can recall when X!'s tools went down on toolserver before TParis and others helped take over maintenance? It's the same problem. On-wiki, the same thing happens when gadgets break. The owner has to fix them. Well, gadgets are better, because anyone can fix the code as long as they can edit it :)
The question of the Wikimedia Foundation taking over and hosting edit tools is...tricky. Sure, it's easy to do. The question is of the ethics and local community sentiment. The privacy policy makes it quite clear the the WMF itself holds very little in regards to access logs, and those findings expire. This follows what even volunteers with advanced tools can access, like CheckUser.
Every edit and action people take is logged by the wiki software. This is inherent to both the wiki-philosophy of personal accountability as well as licensing terms. Histories must be kept. However, what data mining is done by analyzing said histories gets on very, very shaky ground. Many communities are uncomfortable with edit counters, and in some places the use of one might violate the law.
So in the end, I think the better question is: what can be done to help duplicate the tools and leave them in the hands of volunteers? All the tools on labs are open source, it should be trivial to fork a service or two if it's vital to a local community. Are there any developers with labs accounts willing to take on this role? Keegan (WMF) (talk) 07:45, 24 November 2014 (UTC)
  • Keegan (WMF), I appreciate your translation into human English (previous answers all took for granted that the reader a. knew the history of the matter and b. understood various technicalities). I think I understand some of the intricacies now. I guess I don't understand why such gadgets keep breaking down, but I'll take your word for it. Anyway, I need these tools to evaluate an editor for RfA; it's very hard to do so without. Thanks again, Drmies (talk) 13:52, 24 November 2014 (UTC)
Just a thought, may be an inappropriate place to state this, but the money spent on creating unneeded stuff like the "media viewer", "visual editor", etc. should instead be spent on keeping essential features like the editing tools/bots running. It is really frustrating to see so much effort being wasted on features no one really like, while the core features break down every other month, and are only fixed after several weeks. FunkMonk (talk) 18:10, 24 November 2014 (UTC)
See above under "So..." for an answer to that. Then again, whom would you trust more to maintain our software tools: your average Wikipedia volunteer, or the people who worked on stuff like MV & VE? -- llywrch (talk) 21:08, 25 November 2014 (UTC)

Time zone settings[edit]

When I was trying to update my time zone ("Time offset") settings, I realized that Asia/Beijing was not an option. While I was able to change my time zone to Asia/Hong Kong to achieve the same effect, I think that Asia/Beijing should be added to the list because it is a capital city of a country (and a significant one, too). It is also listed in the timezone options for most major operating systems (Windows, Mac OS, many distros of Linux). I understand that there are other cities in the same time zone, but there are already many cities listed for any given time zone. For example, America/Toronto, America/Montreal, America/New York, America/Bogota. and America/Lima are all in the -05:00 time zone yet they are all individually listed due to their significance.

In short: I would like to request that Asia/Beijing be included in the list of time offsets under Preferences -> Appearance.

Thanks. Tony Tan98 · talk 04:26, 24 November 2014 (UTC)

@Tony Tan 98: This is a feature of the MediaWiki software, so we can't fix it locally from the English Wikipedia. I've filed a bug report in our (new!) bug tracking system so that the MediaWiki developers will see your request. — Mr. Stradivarius ♪ talk ♪ 04:50, 24 November 2014 (UTC)
@Mr. Stradivarius: I see. Thank you for filing the report! Best, Tony Tan98 · talk 04:54, 24 November 2014 (UTC)
MediaWiki is written in PHP which like many others uses the tz database. List of tz database time zones does not have a time zone identifier called Asia/Beijing so that's a red link. Beijing is covered by Asia/Shanghai. Asia/Hong Kong also works for just setting your Wikipedia preferences but officially only covers Hong Kong. See also Time in China#IANA time zone database. PrimeHunter (talk) 11:54, 24 November 2014 (UTC)
  • Tony, I understand your frustration. I have to use "America:New York" instead of "America:Boston" (which is available in most OS and other program settings as Boston is the capital city of Massachusetts which is kind of a central hub for New England of which New York is not part of). I also have done some research in this, and until it is added to the tz database, there isn't much the software developers can reasonably do. Happy editing! — {{U|Technical 13}} (etc) 15:04, 24 November 2014 (UTC)
There is one thing they could do: Add other major cities to the right of some of the tz identifiers, maybe in a smaller font. PrimeHunter (talk) 15:46, 24 November 2014 (UTC)

Page Transitions[edit]

All of a sudden, as I move backwards and forwards (using IE10 Back and Forward navigation buttons) between pages, there's a "transition" whereby one page sort of 'slides' into the other, rather than a crisp instant refresh. Have the tech guys changed something, or is this caused by some aspect of my IE settings? It's happened once before, a few months ago, then suddenly stopped. Thanks, 141.6.11.14 (talk) 12:29, 24 November 2014 (UTC)

My guess would be IE; This is nothing to do with Wikipedia. --Mdann52talk to me! 13:31, 26 November 2014 (UTC)

Request for edit to Template:Infobox holiday[edit]

This template categorises the page according to the field "frequency", e.g. "annual" puts the page in Category:Holidays and observances by frequency (annual). The trouble is that a capital A on Annual puts the page into a duplicate category, Category:Holidays and observances by frequency (Annual). Please edit the code in the template to use a lowercase version of the frequency in the category name. – Fayenatic London 14:51, 24 November 2014 (UTC)

Fixed using the {{lc:}} magic word. The duration and scheduling fields may need the same changes. SiBr4 (talk) 15:05, 24 November 2014 (UTC)
@SiBr4: Thanks! We'd better avoid this magic word on scheduling, as one in Category:Holidays and observances by scheduling begins with "Christmas". It should be safe to use on duration, though. – Fayenatic London 23:56, 25 November 2014 (UTC)

Search bar not responsive sometimes[edit]

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)

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

Tech News: 2014-48[edit]

19:31, 24 November 2014 (UTC)

visual editor revisited[edit]

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)

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

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)

Agree with Fram, funds should be used for keeping essential tools running, per my older comment here.[18] 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)
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 (talkcontribs) 13:41, 25 November 2014 (UTC)
@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)
I fixed the wikitext of Parallel adoption and Oh Kwang-sooTheDJ (talkcontribs) 14:24, 25 November 2014 (UTC)
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)
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 (talkcontribs) 14:50, 25 November 2014 (UTC)
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)
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)
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)
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)
  • 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 [19]. Until it can produce clean edits its not ready for prime time yet.--Salix alba (talk): 21:24, 25 November 2014 (UTC)
    @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)
    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)
    I believe that the product manager calls that behavior a feature rather than a bug. Whatamidoing (WMF) (talk) 07:27, 26 November 2014 (UTC)
    @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)
  • 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)
    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)
    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)

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)

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)

Popups[edit]

I'm I the only one who has lost navigation popups in the last 12 hours? It makes SPI cases, already backlogged, tedious to investigate.--Jezebel's Ponyobons mots 16:54, 25 November 2014 (UTC)

Apparently not. Best, --Elitre (WMF) (talk) 17:03, 25 November 2014 (UTC)
Thank you. According to that thread, and my own experience, popups have...popped back up. --Jezebel's Ponyobons mots 18:35, 25 November 2014 (UTC)

How do I suppress the pending changes banner in my watchlist?[edit]

I'd like to make the salmon-colored "There are currently pending revisions" banner on my watchlist go away; it is both alarming and redundant, as the individual pages in my watchlist that need attention are already marked. I don't see a preference for this and I tried chipping away at it with CSS but no luck. Any ideas? Regards, Orange Suede Sofa (talk) 20:18, 25 November 2014 (UTC)

The trick is to get the selector specific without being too specific.
div#mw-fr-watchlist-pending-notice {
  display: none;
}
should be placed in Special:MyPage/common.css - tested in MonoBook and Vector. --Redrose64 (talk) 20:37, 25 November 2014 (UTC)
Thank you! Orange Suede Sofa (talk) 20:45, 25 November 2014 (UTC)

Search in Mobile Version of Wikipedia No Longer Works[edit]

For about the last month or two (possibly since the new search was implemented), the search function on the main page of Wikipedia on the web browser of my mobile phone has not been working. I am using a Samsung Intercept with Android 2.2.2 and the standard web browser and the web URL "http://en.m.wikipedia.org/wiki/Main_Page".

When the page first appears, the search box at the top of the page has three menu bars and says "Search Wikipedia". If I touch "Search Wikipedia" once, the words go away but the menu bars remain. If I touch where the words had been a second time, the menu bars are replaced by an "X" and the cursor is positioned after it. As soon as I start typing in a search word, a smaller "x" within a gray circle appears at the other end of the line and suggested search words begin appearing below.

If I then try to select one of the search words below, one of two things happens:

1) If I touch a search word and then immediately lift my finger off, or if I touch a search word and leave my finger on it a few seconds, but no "box outline" (to show something as selected) surrounds any of the search words, and then I lift my finger off, the page instantly returns to it's original appearance, with the menu bars, "Search Wikipedia", no "x" within a circle, and no search words.

2) If I touch a search word and leave my finger on it a few seconds and a "box outline" surrounds not only the search word but other whole or partial search words (on different lines, as if it cannot figure out what I am trying to select), a box appears, asking me which of various options (Open, Open in new window, etc.) I would like to perform on a TOTALLY UNRELATED URL AT THE TOP OF THE BOX.

I can no longer get the search function to select and surround only the search word(s) I am trying to select with a "box outline".

I also cannot just type in a search word and have Wikipedia search for it, because there is nothing in the search box like a "?" or "Go" button to start a search; instead there are only "X"s to end one.

If anyone has any thoughts or suggestions on this or could help me out, I would greatly appreciate it. — Preceding unsigned comment added by 66.87.95.204 (talk) 10:32, 26 November 2014‎ (UTC)

Thanks for telling us about this problem, which sounds very annoying. I'll make sure that User:Maryana (WMF) knows about the problem, and I hope that it will be fixed soon. Whatamidoing (WMF) (talk) 23:37, 26 November 2014 (UTC)

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

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)

Please, explain for what purpose an average autoconfirmed you may need move-subpages userright? Ruslik_Zero 11:49, 27 November 2014 (UTC)
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)
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)
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)

HTTPS certificate change?[edit]

Someone reported on this before Wikipedia:Village_pump_(technical)/Archive_129#What.27s_up_with_Firefox_and_security_certificates.3F with the conclusion that that there was some kind of malicious certificate exchange/MitM attack.

I've recently noticed a change in the certificate when attempting to access https://en.wikipedia.org both at work and at home. Here's what Certificate Patrol tells me - has anyone else seen a similar thing?

Original:
- GTE CyberTrust Global Root
  - DigiCert High Assurance EV Root CA
    - DigiCert High Assurance CA-3
      - *.wikipedia.org

SHA-1 = 87:A6:CC:C9:08:A0:0B:4F:B0:66:31:B2:4B:24:3F:39:82:FA:E0:30
Issued 2012-10-22, 01:00:00, expires 2016-01-20, 12:00:00


New:
- GlobalSign Root CA
  - GlobalSign Organization Validation CA - SHA256 - G2
    - *.wikipedia.org
SHA1 = D1:B3:F4:B9:EF:27:75:07:EE:DD:B5:61:75:15:3F:EA:B9:EF:85:C9
Issued 2014-11-21, 18:06:02, expires 2015-11-22, 18:06:02

— Preceding unsigned comment added by 131.111.102.15 (talk) 13:36, 26 November 2014 (UTC)

I get the new certificate too. --NeilN talk to me 14:07, 26 November 2014 (UTC)
I have the newer SHA-256 certificate as well, everything appears to be in order with the certificate. — xaosflux Talk 14:38, 26 November 2014 (UTC)
OK, thanks - it's not a problem on my end. Now I'm curious as to why the certificate and CA was changed a year before its expiry date.131.111.102.15 (talk) 15:12, 26 November 2014 (UTC)
The old cert was SHA-1, which is being deprecated, now we look good in Shaaaaaaaaaaaaa :D — xaosflux Talk 15:41, 26 November 2014 (UTC)
See phab:T73156, Chrome 41 will warn users if SHA1 certificates are used and expire after January 1, 2016. --Sitic (talk) 13:59, 27 November 2014 (UTC)

Archives[edit]

I had two sets of archives showing on my Talk page, but they have suddenly disappeared. When I put "User:P123ct1" in the search box, Archive 2 appears, but Archive 1 does not. I cannot see any diffs in Revision History that might explain this. An editor has changed title headings on my Talk page recently, without asking permission. Can you help? ~ P123ct1 (talk) 17:03, 26 November 2014 (UTC)

@P123ct1: You removed it yourself, with this edit. --Redrose64 (talk) 17:25, 26 November 2014 (UTC)
Redrose64: I was trying to remove what looked like a spam message at the top at the time. I didn't see that I had removed Archive 1 at the same time. WP technical stuff baffles me and I seem to waste an awful lot of time on it instead of editing. Thanks. ~ P123ct1 (talk) 18:00, 26 November 2014 (UTC)

Linking to other languages[edit]

It used to be easy to link to a parallel article in another language. Unfortunately, such links are now hidden in both traditional editor and VE. I tried to add a link to a Korean article, but I guess I have forgotten the coding, since it didn't work in the traditional editor and the VE was hopeless. I wanted to add 한국어:탑정저수지 as a link from Tapjeong Reservoir. Kdammers (talk) 09:32, 27 November 2014 (UTC)

Click on "Add links" in the sidebar of either article, enter the language and title of the other article, and a script should automatically create or edit the Wikidata page for the pair of articles. You don't need to actually edit the articles anymore. (The pre-Wikidata method would be adding [[ko:탑정저수지]] to the enWP page and [[en:Tapjeong Reservoir]] to the koWP one.) SiBr4 (talk) 09:44, 27 November 2014 (UTC)
But this requires that you either have a central login for all Wikimedia projects or create a separate account at Wikidata. Otherwise the shortcut to Wikidata won't work. De728631 (talk) 11:16, 27 November 2014 (UTC)
A central login is made automatically. Special:CentralAuth/Kdammers shows Kdammers's account is linked to a Wikidata account. SiBr4 (talk) 11:29, 27 November 2014 (UTC)
On another note, there is no such article ko:한국어:탑정저수지 at the Korean Wikipedia. De728631 (talk) 11:23, 27 November 2014 (UTC)
I think 한국어: was intended as an interwiki prefix (it means "Korean"). The Korean article in question is ko:탑정저수지. SiBr4 (talk) 11:29, 27 November 2014 (UTC)
Ah, that sneaky colon between all the hangul characters had escaped me. :-) De728631 (talk) 11:40, 27 November 2014 (UTC)

Template[edit]

I am working on Template:Navbox subgroup, this template allow 20 subgroups, I have more than 20 entry in subgroups. Is there any other template like this, in which i can insert more than 20 subgroups?Ameen Akbar (talk) 11:07, 27 November 2014 (UTC)

You could use {{Navbox|child instead. -- WOSlinker (talk) 13:09, 27 November 2014 (UTC)

Wiki mark-ups are missing[edit]

Resolved

A couple of days ago I noticed that the wiki mark-ups when editing are completely missing. There were no changes made in my prefs nor PCs (2) or laptop. Does someone know what's going on here? Thanks.TMCk (talk) 18:03, 27 November 2014 (UTC)
More info: Just checked on IE (instead of Chrome) and get the same unless I'm logged out. No problem tho on the German wiki.TMCk (talk) 18:30, 27 November 2014 (UTC)

@The Magnificent Clean-keeper: What are "the wiki mark-ups"? I'm using Firefox 33.1, and have typed in wiki markup here, to make the colon indent, the template at the start of this reply, and my signature; all with no problem. --Redrose64 (talk) 19:40, 27 November 2014 (UTC)
When you edit a page, there is a drop-down-menu (or whatever it is called) near the bottom left named "insert" and mark-ups are one option in the list. I don't get this drop-down-menu when signed in.TMCk (talk) 19:50, 27 November 2014 (UTC)
I figured that is what you meant. Ensure CharInsert is enabled: Preferences → Gadgets → CharInsert, adds a toolbar under the edit window for quickly inserting wiki markup and special characters --  Gadget850 talk 19:55, 27 November 2014 (UTC)
You should also blank User:The Magnificent Clean-keeper/common.js and bypass as that line of text is invalid and may interfere. --  Gadget850 talk 19:57, 27 November 2014 (UTC)
Thanks. it was my code-page that interfered here. All fine now ;) TMCk (talk) 20:15, 27 November 2014 (UTC)

Category:Articles with Old English-language external links[edit]

Non-existing Category:Articles with Old English-language external links, which is appended to some stuff, appears unhidden in Earth and possibly other articles, could someone have a look to fix this? Brandmeistertalk — Preceding undated comment added 23:06, 27 November 2014 (UTC)

@Brandmeister: Yes check.svg Done in these edits by removing instances of {{ang icon}}. GoingBatty (talk) 01:56, 28 November 2014 (UTC)
I had already created Category:Articles with Old English-language external links a minute before it was emptied of the only article Earth in the above edits. Treating Old English as a foreign language like others in Category:Articles with non-English-language external links may appear odd but it's a hidden category, and Category:Articles containing non-English-language text already has the subcategory Category:Articles containing Old English-language text with lots of articles. PrimeHunter (talk) 02:06, 28 November 2014 (UTC)
@PrimeHunter: OK, I reverted my edits to Earth so it's in the category again. GoingBatty (talk) 02:18, 28 November 2014 (UTC)