Wikipedia:Village pump (technical): Difference between revisions - Wikipedia

When viewing the following table in the mobile version of the site, some text from the first column spills over into the adjacent cell of the second column.

Anyone got an idea what's causing this and/or how to solve this. Tvx1 22:24, 28 February 2015 (UTC)[reply]

I don't have a mobile device and it looks right for me in both desktop and https://en.m.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&mobileaction=toggle_view_mobile. The table has a coding error in {{nowrap|{{nowrap|Mercedes PU106B Hybrid}} which should only have one {{nowrap}}. Does it help to remove that:

Does it help to remove all nowrap (may be controversial in an article), or for simplicity replace them by {{identity}} as here:

PrimeHunter (talk) 04:56, 1 March 2015 (UTC)[reply]

Thanks for mentioning that coding error. That didn't cause the problem however. Actually it did not do any harm at all. If you click on the link to the mobile view and then reduce the width of your browser screen to the minimum you will see the text from the first column spilling over. Using the identity template doesn't solve it. Tvx1 05:38, 1 March 2015 (UTC)[reply]

I already tried the minimum width on mobile and it works for me. I get a horizontal scroll bar and no overlap. I will stop guessing. It's too hard when I don't have the problem. PrimeHunter (talk) 05:51, 1 March 2015 (UTC)[reply]

Since I'm not able to explain the issue with text, I have made a screenshot:

As you can see, content from the first column is spilling over into the second. Tvx1 21:20, 16 March 2015 (UTC)[reply]

It doesn't spill over for me. Based on the amount of spillover in your screenshot, maybe your browser doesn't reserve space for the flag icon when the column width is calculated. PrimeHunter (talk) 00:05, 20 March 2015 (UTC)[reply]

Multiple user have reported this to me though, regardless of which browser they use. Tvx1 06:54, 21 March 2015 (UTC)[reply]

I think you're spot on there. Either the flag icon isn't taken into account, either it's just counted as a 1px character. Is there a way to solve this? Tvx1 19:07, 26 March 2015 (UTC)[reply]

Does it change anything if the size of the image is increased, or removed altogether? Googol30 (talk) 04:06, 27 March 2015 (UTC)[reply]

Well, cells without flagicons don't spill over into other, no matter how wide they are. But we want to have them in that table. Tvx1 10:13, 28 March 2015 (UTC)[reply]

And does making the icons larger make the problem worse? What I'm trying to determine is how the browser is interpreting what it's given and why it isn't making the cells large enough. If the browser isn't making sufficient space for all of the elements the cell contains, should we worry about that, since it's then the fault of the browser, or find a workaround and try to fix the problem on our end, even if the mobile browser isn't working as expected? I didn't seem to catch what your mobile browser even is. If I could replicate the problem on my end, I could attempt to fix it, but the desktop version of Chrome I'm running handles element widths as expected. Let me add a table with the changes I'm thinking of for illustration:

Of course, this is an extreme size change, but it's to troubleshoot things here. Does this make the problem worse, fix it, or make no difference whatsoever? Googol30 (talk) 23:42, 28 March 2015 (UTC)[reply]

Googol30, that makes the problem much worse. Here is a screenshot:

In case I hadn't made it clear yet, this is an issue that only occurs on the mobile version of the site. The only mobile browser I have thus far identified not to be affected by this issue is Firefox. All other mobile browser have this problem. I mostly use mobile Safari, but as said other mobile browsers are affected as well. Tvx1 00:37, 29 March 2015 (UTC)[reply]

Googol30, does my above reply hold any value for you regarding this issue? Tvx1 13:25, 30 April 2015 (UTC)[reply]

@Tvx1: yes, and I've done some research into the problem, finding that this is actually intended behavior of the nowrap attribute. Sadly, I do not have enough technical knowledge of its use within MediaWiki or on Wikipedia to properly fix this issue, so I regret to inform you that although (I think) I know what is causing the problem, I cannot properly fix it without potentially causing more problems elsewhere. Googol30 (talk) 11:04, 4 May 2015 (UTC)[reply]

And do you know anyone who could be able to fix it, or do you think it would be better to file a bug report over on Phabricator? Tvx1 15:55, 4 May 2015 (UTC)[reply]

I'd say, if you haven't already, to file a report on Phabricator, possibly linking to there from here to give anyone looking for the problem here a place to continue searching.Googol30 (talk) 20:09, 10 May 2015 (UTC)[reply]

 Done Tvx1 13:08, 16 May 2015 (UTC)[reply]

First encountered this last night, in the middle of sifting thru articles needing to be rated. One minute, the links to tools.wmflabs.org worked as expected, the next I encountered an error page. I thought it was some manifestation of transient weirdness, so I let it slide until this morning only to verify it's no longer working.

Steps to reproduce

• Go to an article assessment overview table, where statistics for article class & importance are displayed.
• Click on any of the numbers in the grid (say Importance "???", & Quality "Unaccessed")
• Expected result: be directed to a page with a list of articles matching those features

• Actual results: Tool server error page with the heading "No web service". See image file to right.

(Adding a screen shot for a bug report is an effing pain. It would be much easier if there was a licensing rationale "bug report" instead of having to go thru several tedious steps explain why I want to upload a file at en.wikipedia & not to commons, & IDGAF what license it appears under. As if anyone else would want to use the file.)

So is there a software defect here, or is some database borked? -- llywrch (talk) 04:58, 6 June 2015 (UTC)[reply]

No idea on your substantive problem, but Special:Upload still lets you upload images without 95% of the red tape. —Cryptic 05:40, 6 June 2015 (UTC)[reply]

You don't have to choose a license for your file on phabricator. Adding the direct link to the failing tool, would have been simpler than a treasure hunt through wikipedia to find the link. And that error page tells you that the people owning this tool are Theopolism and Hedonil.. Have you considered contacting them ? —TheDJ (talk • contribs) 06:53, 6 June 2015 (UTC)[reply]

@Llywrch: For uploading Wikipedia/etc. screenshots for use in a Wikipedia discussion, see WP:WPSHOT - there are only two license templates that you need to consider - they differ only in whether or not the puzzleball logo (or equivalent) is included in the screenshot. --Redrose64 (talk) 13:38, 6 June 2015 (UTC)[reply]

Much thanks for the tips on uploading screenshots, but anyone else seen this malfunction, or have a clue what's going on? Having these links work helps to speed up clearing up the backlog of unassessed & ungraded articles. -- llywrch (talk) 15:35, 6 June 2015 (UTC)[reply]

Thanks for this note. I've e-mailed User:Coren, who usually knows what's going on with Tool Labs, but I don't know how soon you might expect a response/if he's around this weekend. Whatamidoing (WMF) (talk) 05:57, 7 June 2015 (UTC)[reply]

• As far as I can tell, at this time, the enwp10 tool is functionning properly. If the issue is still live, could someone provide me with a link to the broken page? — Coren ^(talk) 15:40, 8 June 2015 (UTC)[reply]

The problem seems to have fixed itself; no sign of the issue when I followed the links earlier today. Apparently someone was doing something in the Wikimedia labs (not the toolserver, my confusion), decided the change wasn't what they wanted, & stopped doing that something -- thus the enwp10 tool is now working properly. (This is one of the drawbacks of abstraction in software: change something on one level, & it can cause failures in an interface on a higher level you didn't think was related.) -- llywrch (talk) 07:16, 9 June 2015 (UTC)[reply]

During my ventures on the French Wikipedia, I have noticed a new tool for translation that has been introduced. It is more or less in a state of uselessness, as it can't even translate French yet, but I am interested, what plans are there to introduce this tool onto enwiki? ^{My name is}not^dave (talk/contribs) 20:31, 6 June 2015 (UTC)[reply]

The correct link is fr:Special:ContentTranslation. You have to enable "Traduction du contenu" ("Content Translation") at the bottom of fr:Special:Preferences#mw-prefsection-betafeatures to use it. It's made by mw:Extension:ContentTranslation which is installed at the French Wikipedia but not the English. I don't know the functionality or plans. PrimeHunter (talk) 22:32, 6 June 2015 (UTC)[reply]

Yo, a ContentTranslation developer here.

My name is not dave, thanks for your interest. As a matter of fact, ContentTranslation (a.k.a. CX) was used to create more than 500 articles in the French Wikipedia, so while my opinion about ContentTranslation is certainly biased, I'm pretty sure it's not useless :)

It currently works for translation from English. There's a plan to enable it as a beta feature in the English Wikipedia in June. There will be a proper announcement about this very soon.

In the meantime, you are welcome to peek at the FAQ.

Cheers! --Amir E. Aharoni (talk) 11:43, 7 June 2015 (UTC)[reply]

Recently (not sure when it started, maybe about 3-6 days ago), whenever somebody posts on my talk page, the notifications says "...posted on your talk page in "footer"...". I don't have a section called "footer" on my talk page. Weird. —DangerousJXD (talk) 02:35, 7 June 2015 (UTC)[reply]

Yes, it is known problem. --Edgars2007 (talk/contribs) 06:30, 7 June 2015 (UTC)[reply]

phab:T99989 reports a patch in the works. They're shifting the deployment schedule right now, so I'm not sure when to expect it. Assuming that it isn't considered urgent enough for a special deployment, then this might reach us as early as Thursday of this week, or as late as next Wednesday. Whatamidoing (WMF) (talk) 06:27, 8 June 2015 (UTC)[reply]

Continued from Template talk:Gallery#Reference bug

This^{[a 1]} and that.^{[a 3]}

Currently, we have a phantom reference appearing twice in the reference list, but not visible in the article. Can we have the backend software fix this problem? Frietjes (talk) 14:50, 7 June 2015 (UTC)[reply]

I think the parser adds it once as the caption (which won't display, but it doesn't know that at this step yet, and once as the alt attributes (from which it will get sanitized, but it doesn't know about that either at this stage. I'm not sure if that is fixable... You should probably file a bug report in phabricator however. —TheDJ (talk • contribs) 15:08, 7 June 2015 (UTC)[reply]

User:TheDJ, I have added hacks to template:wide image, template:image array, and template:gallery to use the 'unstrip' lua function. not sure how to file the bug or how many articles/templates/modules are impacted. per the discussion at template talk:gallery this may be recently introduced bug/feature. Frietjes (talk) 16:16, 7 June 2015 (UTC)[reply]

It's another symptom of phab:T101390 I suspect. This seems to be NEW behavior. (grah, i see in the discussion that Jack was already on this.. (and the cause of it)) —TheDJ (talk • contribs) 17:24, 7 June 2015 (UTC)[reply]

The changes causing this will be rolled back for now. Another attempt might follow at a later time. —TheDJ (talk • contribs) 18:31, 8 June 2015 (UTC)[reply]

Sorry! We could not process your edit due to a loss of session data. Please try again. If it still does not work, try logging out and logging back in.

For months, I guess, I've been getting this on about one in ten saves. The second attempt always works, so it's not a serious hindrance, but it's definitely annoying, distracting, and a bit nerve-rattling, especially in addition to the other weird editing glitches we've seen lately.

A look at this page's archives shows other users having the problem, going back years, but I don't see a clear resolution there.

I have Firefox 38.0.1 on Windows 7. I'm using the NoScript 2.6.9.26 Firefox extension, but these WP-related sites are whitelisted: wikipedia.org, wikimedia.org, wmflabs.org, wmfusercontent.org. I also have the Adblock Plus 2.6.9.1 extension.

A resolution would be worth a demonstration of WikiLove, if you're into that sort of thing. ―Mandruss ☎ 06:02, 8 June 2015 (UTC)[reply]

I don't get them nearly as often as you but this happened to me twice today. Firefox. --NeilN ^{talk to me} 06:14, 8 June 2015 (UTC)[reply]

(edit conflict) A few times today already, I'll get the loss of session data error after taking a mere five seconds to make a correction to an article when I used to have to wait at least a few minutes with the edit window open before saving for that to happen. Luckily, I just need to press save again to fix the problem. Dustin (talk) 06:15, 8 June 2015 (UTC)[reply]

Also, this is on Google Chrome. Dustin (talk) 06:15, 8 June 2015 (UTC)[reply]

If someone could say that they have the problem without one or both of the Firefox extensions (or the Chrome version), that would rule them out as the culprit. ―Mandruss ☎ 06:23, 8 June 2015 (UTC)[reply]

This happens to me, and I have both of these extensions installed (but disabled for these domains). However, it doesn't happen to me nearly as often. Usually, I have to have an editing window open for ≥15 minutes to get this error. WhatamIdoing (talk) 06:28, 8 June 2015 (UTC)[reply]

It's possible it's far less than one in ten for me. I of course notice when the error happens, but I'm not aware of how many saves have worked since the previous error; I'm not paying attention to that. I could start keeping a record, but I don't know that a more accurate number would help identify the problem. ―Mandruss ☎ 08:55, 8 June 2015 (UTC)[reply]

I don't have either of these extensions. --NeilN ^{talk to me} 06:32, 8 June 2015 (UTC)[reply]

I think I see it more for edits that have been open for awhile, but I'm certain it happens sometimes after a ~30-second edit session. ―Mandruss ☎ 06:59, 8 June 2015 (UTC)[reply]

"Please try again" suggests that the developers anticipated the possibility of "loss of session data", and were unable to come up with a way to prevent that possibility. The career software developers among us can attest that such situations are possible, although rare. Some aspects of the software environment are beyond our control, and the rare nut is uncrackable. But it would be nice to have the developers look at the problem and say whether that is the case here. If it is, that would be a good thing to know going forward. ―Mandruss ☎ 07:52, 8 June 2015 (UTC)[reply]

Firefox 38.0.5 and some earlier versions. I don't have eother NoScript or AdBlock. I've not counted the rate at which the "Loss of session data" error occurs, but it's more likely for a longer interval between "edit" and "save page". But it has happened for a simple sub-10-second typo fix on more than one occasion. --Redrose64 (talk) 08:14, 8 June 2015 (UTC)[reply]

It suddenly became far more frequent about 10 days ago - and most of my edits are just typos (Windows 7, IE11, Vector & no fancy add-ons) - Arjayay (talk) 09:04, 8 June 2015 (UTC)[reply]

This edit took no more than ten seconds from clicking "[edit]" to Save page, during which time I did not navigate off the page, switch windows or do anything other than type - yet it still threw "Sorry! We could not process your edit due to a loss of session data." Ridiculous. --Redrose64 (talk) 12:48, 10 June 2015 (UTC)[reply]

I have strong suspicions that this is related to #Post_not_showing_up_immediately. I suspect the same change that is causing that problem (still not tracked down btw), is also causing this problem. Possibly because outdated tokens or timestamps are included in edit pages or something. —TheDJ (talk • contribs) 12:58, 10 June 2015 (UTC)[reply]

For me, the "session data" issue pre-dated the other by at least months — maybe many months, I can't recall. ―Mandruss ☎ 16:59, 11 June 2015 (UTC)[reply]

• Is this related? When these errors start happening, I typically also get "token" errors when I use the Upload Wizard. (If my memory is correct, the message is "token not recognized".) In this case, all my work is completely lost, and I have to restart the upload from scratch. Browser back buttons work just fine with loss of session data, but not with these token failures. I presume this is simply because Uploading doesn't come with a Preview button, so my browser when I upload never has a record of what I just did. I also presume I could avoid problems if I got in the habit of right-clicking the Upload button. I also presume that the simplest temporary fix would be that when the Upload button is activated, the page as it is also added to the browser history. Choor monster (talk) 13:08, 10 June 2015 (UTC)[reply]

Loss of Session Data

About once a day, I try to make an edit, and get the error message that my edit could not be made due to a loss of session data. It tells me to try again, and says that if that does not work, I should log out and log back in. I press the Save button again, and it works. (I don't have to log out and log in.) Should I just ignore it, or can I do something to minimize the frequency of these glitches? Robert McClenon (talk) 15:23, 10 June 2015 (UTC)[reply]

I am using Google Chrome 43.0.2357.124 and Windows 7. Robert McClenon (talk) 15:25, 10 June 2015 (UTC)[reply]

I'm occasionally getting these too. It seems that this message is most likely to occur when I start editing an article and keep it open in the edit mode for a long time (over an hour). For me, too, the message goes away after pressing Save. I'd also be interested in knowing the cause of this message and whether it can be prevented. (I'm using Firefox 22.0 on Win7).—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); June 10, 2015; 15:29 (UTC)

It happens for me when I haven't been editing very long. Since we are using different web browsers, they might be different issues. Robert McClenon (talk) 15:53, 11 June 2015 (UTC)[reply]

It happens for a variety of browsers. It also happens for very short editing sessions. --Redrose64 (talk) 16:34, 11 June 2015 (UTC)[reply]

Have the exact same issue and configuration as Robert McClenon.--Wolbo (talk) 17:04, 11 June 2015 (UTC)[reply]

• I was coming here to complain myself. I'm getting this 70% of the time now. It's becoming more than just an annoyance. Also some pages when edited load out of date and need to be refreshed. There are some weird glitches going on right now.—^cyberpower_Chat:Online 18:25, 11 June 2015 (UTC)[reply]

Why are the chunks of code I put inside of code tags broken on Wikipedia_talk:WikiProject_Orphanage#Orphan_template_behavior? I thought that code was suppose to be an inline element? 3gg5amp1e (talk) 13:09, 8 June 2015 (UTC)[reply]

Never mind, I read the documentation for the quote template and figured out that I needed nowiki(?) tags and also that quote isn't an inline template so I needed to use Tq instead. 3gg5amp1e (talk) 13:15, 8 June 2015 (UTC)[reply]

@3gg5amp1e: It wasn't a problem with either the <code>...</code> tags or the {{quote}} template, it was the bare pipes - you can't use these in the parameter of any template, since it terminates the parameter and starts another. You could have fixed it by using either of these methods:

the {{para|att}} parameter

or

the <code>{{!}}att=</code> parameter

Personally I favour the first. --Redrose64 (talk) 14:20, 8 June 2015 (UTC)[reply]

Oh, so like

the |att= parameter

or

Error: No text given for quotation (or equals sign used in the actual argument to an unnamed parameter)

? 3gg5amp1e (talk) 14:22, 8 June 2015 (UTC)[reply]

First one yes; second one, you also need to explicitly number the parameter because of that equals:

the |att= parameter

--Redrose64 (talk) 14:30, 8 June 2015 (UTC)[reply]

What do you mean explicitly number? If the = is a problem, can't I just do something like

the |att= parameter

? 3gg5amp1e (talk) 14:43, 8 June 2015 (UTC)[reply]

You could use {{=}} but you'd need to do it for each instance. By "explicitly number" I mean to put 1= right at the start - and you only need that once per {{quote}}. Without that, everything up to the first bare equals is taken to be a parameter name, and everything after that as the value for that strangely-named parameter. --Redrose64 (talk) 14:54, 8 June 2015 (UTC)[reply]

Please see Wikipedia:Administrators' noticeboard#New Twinkle block module! for the official announcement and where to give feedback. Thank you! — MusikAnimal ^talk 17:44, 8 June 2015 (UTC)[reply]

18:18, 8 June 2015 (UTC)

There are a number of user scripts and gadgets that might fixing when the continuation mode is changing. See a search for query-continue. When people are doing that, they might also want to add formatversion=2 to the api requests. —TheDJ (talk • contribs) 18:37, 8 June 2015 (UTC)[reply]

Minor clarification for another item: "The title of dialogs is now easier to see when it is near long buttons" refers specifically to VisualEditor. (Also, that problem doesn't seem to appear if your account is set to display in English.) Whatamidoing (WMF) (talk) 01:21, 9 June 2015 (UTC)[reply]

It should be possible to transclude or substitute an old version of a template, as well as to redirect to an old version of a page and to display old versions of images. GeoffreyT2000 (talk) 04:31, 8 June 2015 (UTC)[reply]

Hidden in the link at the end of today's Tech News is a bit of a bombshell. For people who didn't notice, most of our bots are going to stop working on 2 July if their code isn't updated.

According to the announcement, the following bots need to be fixed. (I've restricted the list to bots active on this wiki.)

We are reliant on quite a few of those bots for the smooth functioning of our wiki, so it's very important that they are fixed. Also, as TheDJ says above, there are also a number of user scripts that need fixing as well.

I've started a list of users to notify about this at User:Mr. Stradivarius/API continuation/users to notify, and a message to send to them at User:Mr. Stradivarius/API continuation/message. It would be very helpful if people could help me to expand the list to include user scripts, and to help copy edit the message. Once that's done, we can send it out using Special:MassMessage. Hopefully that will prevent wiki-meltdown on 2 July. — Mr. Stradivarius ^{♪ talk ♪} 00:53, 9 June 2015 (UTC)[reply]

This was also announced at WP:BOTN, with the complete list of bots that are known to be at risk. If you have know bot owners who don't frequent BOTN here (especially people at other projects), then please reach out to them. (Also, someday we need to create a template for major issues like this—maybe something like {{warning|All your bots are going to break}}. This only seems to happen once or twice a year, but I worry that people won't notice these messages in time.) Whatamidoing (WMF) (talk) 01:29, 9 June 2015 (UTC)[reply]

Is there a full list of affected bots? The announcement only names those with over 10,000 deprecation warnings over the course of a week. Some bots operate at a lower frequency but are equally as important — MusikAnimal ^talk 01:49, 9 June 2015 (UTC)[reply]

CBNG and CBIII have had a source code change that Damian will push to live soon - Rich^T|C|E-Mail 08:51, 9 June 2015 (UTC)[reply]

Anomie is checking with Legal if they can release all the account names: "I already have the list of *accounts* affected: there are 510 with between 1000 and 10000 hits. Of those, 454 do not contain "bot" (case insensitively)" https://lists.wikimedia.org/pipermail/wikitech-l/2015-June/081953.html --Sitic (talk) 19:24, 9 June 2015 (UTC)[reply]

I'm guessing that the non-bot users will mostly be people using Huggle, Twinkle, AWB, STiki, and other similar tools. I'm not sure which of the tools is affected, though. — Mr. Stradivarius ^{♪ talk ♪} 22:08, 9 June 2015 (UTC)[reply]

@Mr. Stradivarius: there is now a list for all the bots which where not mentioned in the original mail: https://lists.wikimedia.org/pipermail/wikitech-l/2015-June/082037.html --Sitic (talk) 16:15, 11 June 2015 (UTC)[reply]

You can find some info here: Wikisource:Scriptorium#Pywikibot_compat_will_no_longer_be_supported_-_Please_migrate_to_pywikibot_core. --Mpaa (talk) 12:19, 9 June 2015 (UTC)[reply]

I don't know if it's just my cellphone (an iPhone 5), but I cannot edit on the Mobile setting. I can press "Edit" and get the markup language screen to appear, but whenever I try to edit text, the cursor zips back up to the top of the paragraph. Is anyone else having trouble with Mobile editing?OnBeyondZebrax • TALK 02:07, 9 June 2015 (UTC)[reply]

The mobile version has always been crappy for me, iPhone 5 as well. I've been using the desktop version on my phone for years now.—^cyberpower_{Chat:Limited Access} 20:23, 9 June 2015 (UTC)[reply]

User:Melamrawy (WMF) might know whether this has been reported before. Whatamidoing (WMF) (talk) 07:32, 10 June 2015 (UTC)[reply]

Greetings, Sorry if I'm doing something wrong but even after doing the purge option, the updated title refuses to change. Help please... The template is at Template:Vatican City topics. Note: I had to go back to the template's creation to find the Title line as it disappeared at the next update. Regards, JoeHebda (talk) 20:30, 9 June 2015 (UTC)[reply]

That's because {{Country topics}} doesn't take a |title= argument. You can't change the wording. Alakzi (talk) 20:37, 9 June 2015 (UTC)[reply]

Thanks, I missed that. Just wondering how or where is the linkage that connects the word topics with the correct article? I looked thru the docs & can't find anything that shows. JoeHebda (talk) 20:51, 9 June 2015 (UTC)[reply]

{{Country topics}} simply places the country name (which is provided by |country=) inside "[[List of <country name here>-related topics|topics]]" to generate the link. This is called string interpolation, if you're interested. Alakzi (talk) 21:20, 9 June 2015 (UTC)[reply]

Yikes, sort of like stuffing a variable into a string of characters (as in good-old BASIC programming). Thanks for the answer. Unfortunately there is now a Redirect from the List of xxxx -related topics to another article name instead. Is there any way of overriding this? Or maybe a different template? JoeHebda (talk) 22:58, 9 June 2015 (UTC)[reply]

I wouldn't worry about it; redirects are not a big deal. So long as the link takes you to the right place... Alakzi (talk) 23:17, 9 June 2015 (UTC)[reply]

The redirect goes to an Outline article (Outline of Vatican City) instead of the previous List article, so it is on topic, just a different format. Guess that's okay. Thanks for your help. JoeHebda (talk) 00:56, 10 June 2015 (UTC)[reply]

I am trying to edit a list of references, but I can not figure it out. I was trying to remove an unneeded reference, and I was using VisualEditor. I tried editing the source, but I saw a reflist template. Help? ThatKongregateGuy (talk) 20:46, 9 June 2015 (UTC) — Preceding unsigned comment added by ThatKongregateGuy (talk • contribs) 20:39, 9 June 2015 (UTC)[reply]

@ThatKongregateGuy: Unless list-defined references are used in the article (which is rare), the References section does not actually contain the references. They are in the body, and the software collects them and displays them where the {{reflist}} template is located. So, to remove a reference from the reflist, you locate it in the body and remove it there. ―Mandruss ☎ 20:44, 9 June 2015 (UTC)[reply]

OK, I removed it from the article so I must have already done it, Thanks.ThatKongregateGuy (talk) 20:46, 9 June 2015 (UTC)[reply]

@ThatKongregateGuy: You might find WP:CITEBEGIN useful. --Redrose64 (talk) 20:47, 9 June 2015 (UTC)[reply]

@ThatKongregateGuy: For future reference (no pun), this page is for suspected Wikipedia-related technical problems. Use the Teahouse or the Help Desk for how-to questions. ―Mandruss ☎ 20:54, 9 June 2015 (UTC)[reply]

@Mandruss: OK, sorry about that. ThatKongregateGuy (talk) 17:21, 10 June 2015 (UTC)[reply]

See Wikipedia:Administrators'_noticeboard/Incidents#False_information_about_Larry_Silverstein. Have a look at the Wikipedia App screenshot. Wikidata is not well patrolled. I'll say no more. Black Kite (talk) 20:42, 9 June 2015 (UTC)[reply]

Agreed. An edit from a while ago sitting for that long.—^cyberpower_{Chat:Limited Access} 20:50, 9 June 2015 (UTC)[reply]

An edit which would have been completely invisible were it not for the App ... Black Kite (talk) 20:57, 9 June 2015 (UTC)[reply]

Wow, I didn't realise how long that had been there. Sam Walton (talk) 21:02, 9 June 2015 (UTC)[reply]

Perhaps time to make Wikidata changes visible as a default on our watchlists? Alakzi (talk) 21:13, 9 June 2015 (UTC)[reply]

No. I don't want to watch Wikidata. My suggestion is since the term "any can edit" doesn't apply to Wikidata, that only registered users should be allowed to touch Wikidata, and only then when they are autoconfirmed. Before that they can only submit changes through talk page requests. The potential for damage is extraordinary in this case.—^cyberpower_{Chat:Limited Access} 21:19, 9 June 2015 (UTC)[reply]

Even that's not good enough. There are hundreds of thousands of BLPs out there. The App needs to stop picking up Wikidata information. Black Kite (talk) 21:24, 9 June 2015 (UTC)[reply]

So do the search engines. :/—^cyberpower_{Chat:Limited Access} 21:25, 9 June 2015 (UTC)[reply]

If you watch Wikidata - which I did for about two days - your watchlist fills up with crud like some bot adding or removing a property that is only of relevance to the French/German/Hindi/Italian/Japanese-language Wikipedias. I mean, how is this of relevance to me here on En.wp? That's what happens if Template:S-start is watchlisted and you go for Show Wikidata. --Redrose64 (talk) 22:20, 9 June 2015 (UTC)[reply]

Which is why I suggested that Wikidata should only be touchable by auto-confirmed users. Wikidata is not Wikipedia, and shouldn't be treated as such. It's a data platform for managing interwiki connections, and vandalizing it can have global consequences, as evidenced here.—^cyberpower_{Chat:Limited Access} 05:56, 10 June 2015 (UTC)[reply]

IIRC, the devs are working on making the watchlist be able to filter out the less relevant edits. --Yair rand (talk) 12:29, 11 June 2015 (UTC)[reply]

I've come across an empty category, Category:LGBT politicians from the Maldives, which was formerly not empty (among other proofs, it's existed since 2011 and was created by a user who knows very well not to create empty categories) — so what I need to do is to locate who used to be in the category, so that I can properly determine whether its emptying was appropriate or out-of-process.

I know there's a way to run this check, as I previously encountered a similar situation earlier this year (see this discussion) which was successfully resolved. The solution involved scanning for the category in an older database dump; as was true the last time, I've already tried Wayback Machine with no luck. So I wanted to ask if anybody could help out with this matter as well.

At the same time, I also need to run a check on Category:LGBT people from the Maldives, which currently contains only the first empty subcategory — that might have always been the case even before the first category was emptied, but I can't let it go without verifying that.

Thanks for any help that anybody can provide. Bearcat (talk) 21:25, 9 June 2015 (UTC)[reply]

If I wonder about the context of an edit then I often examine other edits at the time by the same editor. In this case [8] shows the categories were created after [9]. The article history shows what happened to the LGBT claim and category which was sourced to [10]. I haven't investigated beyond that. PrimeHunter (talk) 22:49, 9 June 2015 (UTC)[reply]

@Bearcat: Another data point: I scanned the 20141208 dump for articles containing "LGBT politicians from the Maldives" and found only Abdulla Hameed, and for articles containing "LGBT people from the Maldives" and found none. -- John of Reading (talk) 07:40, 10 June 2015 (UTC)[reply]

Okay, thanks. Going back to look at the history on that article, it looks like the category was created and added on the basis of an allegation about Hameed's sexuality by a person who may have had a POV agenda — and not, as required by WP:BLP, any indication that he had ever actually come out in his own words. So I'm not going to repopulate it, as it looks like the removal was actually proper and correct. Bearcat (talk) 16:29, 10 June 2015 (UTC)[reply]

We have an alias called [[tools:]] (tools:) and it goes to a dead site. toolserver.org has moved to tools.wmflabs.org .. is it possible to update the alias? It won't break anything since the alias is currently broken. -- GreenC 00:39, 10 June 2015 (UTC)[reply]

Not sure where to post so also posted at Wikipedia_talk:Namespace#Tools_alias_.28tools:.29 -- GreenC 00:41, 10 June 2015 (UTC)[reply]

There's a new prefix, toollabs:. Presumably, the reason it's not just "tools" is that they were both used during the migration from Toolserver to Labs; you might want to suggest that the "tools" prefix is retargeted on meta. See meta:Interwiki map for the full list of prefixes. Alakzi (talk) 00:43, 10 June 2015 (UTC)[reply]

@Green Cardamom: First, commenting on your post to Wikipedia talk:Namespace#Tools alias (tools:), "tools:" isn't a namespace, it's an Interwikimedia link (or if you prefer, an interwiki prefix, although this term is also used for interlanguage links). Second, toolserver.org didn't move to tools.wmflabs.org - they are two totally separate systems operated and funded by different organisations. If toolserver.org had been moved somewhere (anywhere) it would have made a lot of things so much easier, but it wasn't - it simply had the funding cut and the plug was finally pulled at the start of July 2014. Tool operators were given something like two years notice that this would happen.

To return to the problem. Interwikimedia links are not maintained locally, there's a central table, it's done that way to ensure that each prefix has exactly the same meaning regardless of which wiki it's being used on. I doubt if they will be willing to repurpose the tools: prefix, for several reasons: it's less than a year since toolserver.org went down; the paths (and hence the URLs) on tools.wmflabs.org are all different from toolserver.org (there isn't a one-to-one mapping either); not all of the toolserver.org tools were migrated to tools.wmflabs.org (and some will never be). --Redrose64 (talk) 09:41, 10 June 2015 (UTC)[reply]

Changing tools: wouldn't fix links but break them. If a tool on the old toolserver has a replacement somewhere then there is often a redirect so old links still work. The url structures are different so if tools: pointed to https://tools.wmflabs.org/ then those links wouldn't work. PrimeHunter (talk) 10:50, 10 June 2015 (UTC)[reply]

I stand corrected. Alakzi (talk) 23:13, 10 June 2015 (UTC)[reply]

I have a new user script to share...: Actual Live Preview. With this script, if your window is wider then 1200px, it will split it in half and show you your edit surface on the left and a 'update while you type' content preview on the right. The only requirement is that you enable "Live preview" in your preferences. Enjoy. —TheDJ (talk • contribs) 07:55, 10 June 2015 (UTC)[reply]

Like--ukexpat (talk) 15:38, 10 June 2015 (UTC)[reply]

Very nice. :-) Alakzi (talk) 23:14, 10 June 2015 (UTC)[reply]

Like Jc86035 (talk • contribs) Use {{re|Jc86035}} to reply to me 13:11, 11 June 2015 (UTC)[reply]

I love it for section-editing. Fabulous! 1 problem: It has a scrolling issue for editing large whole pages, where the edit surface scrolls out of view when I scroll the page. See https://i.imgur.com/em0K4FV.png and https://i.imgur.com/2Daf0YS.png (Firefox, Linux). HTH. Quiddity (talk) 21:48, 12 June 2015 (UTC)[reply]

I think the wikipedia app is not working properly: the capitalism, history, business and economics portals are not updating at all. I checked someone's Iphone, it seems to be working ok there. Lbertolotti (talk) 19:12, 3 June 2015 (UTC)[reply]

If this is about the official Wikipedia App, see mw:Wikimedia mobile engineering#Contact us. --AKlapper (WMF) (talk) 08:32, 4 June 2015 (UTC)[reply]

@AKlapper (WMF) The IRC channel is empty.Lbertolotti (talk) 17:24, 4 June 2015 (UTC)[reply]

For the sake of posterity, I'm noting here that this appears to be Phab:T101845. --Dan Garry, Wikimedia Foundation (talk) 15:07, 10 June 2015 (UTC)[reply]

@Dan Garry, Wikimedia Foundation Yeah well, with "pull to refresh" you can update portal pages, but I still think this should happen automatically. Lbertolotti (talk) 16:04, 10 June 2015 (UTC)[reply]

Yes, it should happen automatically. That is why I filed that task, to make sure that the app is changed to do so. --Dan Garry, Wikimedia Foundation (talk) 16:13, 10 June 2015 (UTC)[reply]

See Drugbox:#IUPHAR_ligand_links_update.

It appears that wikidata people actually write: We need ..., We have to ..., You can do that manually [for 7500 facts?]. While really the (institutional) editor offers to add facts to wikipedia. Sic transit whatever gloria wikidata. -DePiep (talk) 01:20, 11 June 2015 (UTC)[reply]

If you are looking for meaning in words, you will find it. WP:AGF —TheDJ (talk • contribs) 06:27, 11 June 2015 (UTC)[reply]

By Jimbo, a "wiki" is a website with open editing, where anyone can edit. Four years on, and wikidata still is not a wiki. -DePiep (talk) 11:17, 12 June 2015 (UTC)[reply]

Neither is Wikipedia anymore if I'm very honest. It's all about perspective. —TheDJ (talk • contribs) 13:04, 12 June 2015 (UTC)[reply]

Wikidata, after hosting the iw's nicely, is a broken wiki. It does not serve. Nothing perspective, it does not function. -DePiep (talk) 21:14, 12 June 2015 (UTC)[reply]

I created two articles: 1st Missile Squadron and 2nd Missile Squadron. The German Wikipedia has one article that covers both units: de:Flugkörpergeschwader. The languages editor allowed me to link the first article, but when I try to link the second I get a message that I can only link one article. How do I fix this? --21lima (talk) 11:52, 11 June 2015 (UTC)[reply]

Merge the two articles? Bazj (talk) 11:58, 11 June 2015 (UTC)[reply]

This is pretty much the issue discussed at Help talk:Interlanguage links#The New System Is Flawed. --Redrose64 (talk) 12:15, 11 June 2015 (UTC)[reply]

Yeah, this is called the "Bonnie and Clyde problem" on Wikidata. Since, at the moment, the German Wikipedia doesn't have articles (or even redirects) that correspond directly to either of the English articles, manual interwikis are the way to go for now. --Yair rand (talk) 12:19, 11 June 2015 (UTC)[reply]

Thanks. That is the way it was done the last time I was active here, but I was trying to use this new-fangled way. I don't know why the German Wikipedia has one article on two separate units— I will have to contact one of my German Air Force friends. --21lima (talk) 12:24, 11 June 2015 (UTC)[reply]

This morning, I was edit conflicted while making an edit to this section. I'd edited just that section by clicking on the 'edit' link to the right of the section title. When I attempted to save, I was edit conflicted. Yet, in the new edit window given to me, there was no additional comment in that section. So, I re-wrote what I said and saved it. This inadvertently removed a comment from the person with whom I edit conflicted...IN A DIFFERENT SECTION [11]. Thankfully someone else picked up on it and restored it [12]. I never noticed. Anyone want to opine as to what is happening here? --Hammersoft (talk) 14:20, 11 June 2015 (UTC)[reply]

Yes, there was something really sluggish about the wiki this morning. User talk:Vanjagenije#Ertanguven, Bazj (talk) 14:44, 11 June 2015 (UTC)[reply]

How can I find out how many contributions I have made to Wikipedia? Bevo (talk) 20:38, 11 June 2015 (UTC)[reply]

The simplest way is via your own Special:Preferences, it will show your number of edits as well as other account information on the User Profile tab. There are also links at the bottom of everyone's user contribution page (yours is at Special:Contributions/Bevo) linking to various tools to see Edit Count and Global contributions and associated statistics. Nanonic (talk) 20:44, 11 June 2015 (UTC)[reply]

I have found User:PleaseStand/User info useful for this. If you go to someone's user page, it shows their edit count, gender, user rights, and block status, along with handy links to further information. — Mr. Stradivarius ^{♪ talk ♪} 23:33, 11 June 2015 (UTC)[reply]

For about a month now, I've been unable to perform searches on the mobile site's search box from my Blackberry Bold 9900, due to a big, black bar that covers the entire thing. What gives? lavender|^{(formerly HMSSolent)}|lambast 23:54, 11 June 2015 (UTC)[reply]

Ugly bug. It should be fixed now (as of ~90 minutes ago). Whatamidoing (WMF) (talk) 01:28, 12 June 2015 (UTC)[reply]

Just tested it with this page - it's working now. lavender|^{(formerly HMSSolent)}|lambast 03:13, 12 June 2015 (UTC)[reply]

BTW. This looked like a very small thing and I'm sure all reporters were like: "Why don't you 'just fix it' already"... Just to bring some perspective: This issue seems to have required multiple debug sessions over multiple weeks by multiple people, was not always reproducible and in the end changed changed 8 files... Simple things often aren't simple :) —TheDJ (talk • contribs) 10:02, 12 June 2015 (UTC)[reply]

It's been reported here before, Wikipedia:Village pump (technical)/Archive 137#Search Field on Wikipedia's Mobile Homepage. --Redrose64 (talk) 10:38, 12 June 2015 (UTC)[reply]

At some point between 07:38 and 10:00, 12 June 2015 (UTC), the user preference "Always use a secure connection when logged in" lost its effect, and regardless of its setting, Wikipedia became HTTPS only. Why was this done, and how can it be undone? Some users are unable to use HTTPS connections. --Redrose64 (talk) 10:33, 12 June 2015 (UTC)[reply]

Having the same problem, which for me means I will be making very terse edit summaries until this is fixed. Windows uploaded and installed updates yesterday, so it may have something to do with that. I get forced into the secure server even before logging on, and no amount of "s" deletion (https^h) takes me off the secure server. I checked the Favorites properties and it still just has "http", so something's rotten in IE methinks. – Paine  11:12, 12 June 2015 (UTC)[reply]

Same here. Firefox.--EchetusXe 11:55, 12 June 2015 (UTC)[reply]

Hi. Yes, this is not a local problem for you. See Wikipedia:Village pump (technical)#HTTPS by default below. I'll try to answer any questions regarding this. /Johan (WMF) (talk) 12:46, 12 June 2015 (UTC)[reply]

@Paine Ellsworth: Are you referring to phab:T55636? Which version of IE are you using? As for the Firefox issue (EchetusXe), I note that autocompletion of edit summaries works very well for me in Firefox (latest version) with HTTPS. Perhaps you need to check browser or add-on settings. — This, that and the other (talk) 13:10, 12 June 2015 (UTC)[reply]

To editor This, that and the other: – Yes re. phab:T55636. I've known for a long time that my IE-10 in Win8 would not work with WP as it concerns the edit summary autofil challenge. My workaround was to simply not check the HTTPS box in prefs. This, however, is a new problem that doesn't even allow me access to the Wikipedia non-secure server, HTTP, when I'm not logged in. I open the browser, I click the Fave link (HTTP only) and then am whisked away to the HTTPS Wikipedia server. Even if I delete the S in HTTPS up in the URL field, the moment I hit ENTER or GO, the S reappears. Apparently, the WMF has found a way to make it so even non-registered users must use the HTTPS, which is a total drag all around! – Paine  14:07, 12 June 2015 (UTC)[reply]

I feel your pain, paine, this also means users from China can NO LONGER access the English wikipedia (this virus is currently limited to enwiki) since https is BLOCKED there, and also, the developers have enforced this without discussion and as per our community first policy and thus we must now vote on removing this..this is the 2nd time this has happened, btw, there is no longer a "forcedhttps" cookie as i have been told by the developer on IRC that the "Always use a secure connection when logged in" option is now well 'utterly useless'....--Stemoc 14:28, 12 June 2015 (UTC)[reply]

I'm pretty sure China and Iran are geographically exempted from this. — This, that and the other (talk) 14:41, 12 June 2015 (UTC)[reply]

Wikimedia devs, you know those people we pay to mess up the site decided our input doesn't matter even though Jimmy explicitly said that we will NOT force IP users into HTTPS during the last Wikimania..--Stemoc 13:53, 12 June 2015 (UTC)[reply]

GreaseMonkey scripts

It seems that for some people Greasemonkey scripts don't work anymore on https. I'm not entirely sure how and why, but I have figured out that if you add explicit @grant's to the script that they DO work. I'm a little dumbfounded that we didn't get more reports about such failures over the past 2 years... I guess it proves that greasemonkey users don't really understand what they are using. :) —TheDJ (talk • contribs) 19:20, 12 June 2015 (UTC)[reply]

Hi everyone.

Over the last few years, the Wikimedia Foundation has been working towards enabling HTTPS by default for all users, including anonymous ones, for better privacy and security for both readers and editors. This has taken a long time, as there have been different aspects to take into account. Our servers haven’t been ready to handle it. The Wikimedia Foundation has had to balance sometimes conflicting goals, having to both give access to as many as possible while caring for the security of everyone who reads Wikipedia. This has finally been implemented on English Wikipedia, and you can read more about it [link-to-blog-post here] here.

Most of you shouldn’t be affected at all. If you edit as registered user, you’ve already had to log in through HTTPS. We’ll keep an eye on this to make sure everything is working as it should. Do get in touch with us if you have any problems logging in or editing Wikipedia after this change or contact me if you have any other questions. /Johan (WMF) (talk) 12:43, 12 June 2015 (UTC)[reply]

There's a blog post at the Wikimedia Foundation blog now. /Johan (WMF) (talk) 13:09, 12 June 2015 (UTC)[reply]

To editor Johan (WMF): – You have to know what a real drag this is. Not only do I want a CHOICE in the matter, and would continue to choose HTTP as long as the edit summary field's autofil function does not work when I'm on the HTTPS server, you should also consider what Redrose64 said above, that some users are unable to use HTTPS connections. The part in the blog post about "all logged in users have been accessing via HTTPS by default since 2013" is just not true, either. We've been given a choice up until now, and I for one do not want to give that up. I want to be able to CHOOSE whether or not I'm on the HTTP server or the HTTPS server. – Paine  14:21, 12 June 2015 (UTC)[reply]

Yes, we do know. The answer I was given when I asked about this is that any form of opt-out would also leave potential security risks in our implementation which make it difficult to safeguard those who do not opt-out. Because of this, we’ve made implementation decisions that preclude any option to disable HTTPS, whether logged in or not. This renders the current opt-out option ineffective, and the option will be removed at a later date after we’ve completed the transition process. /Johan (WMF) (talk) 14:27, 12 June 2015 (UTC)[reply]

You have had to use HTTPS to access the site when logging in as it's been used for the login process, though. /Johan (WMF) (talk) 14:30, 12 June 2015 (UTC)[reply]

It's evidently a weighty issue. And I do realize that I don't edit WP in a vacuum, that I must eventually accept this situation for the good of all. And frankly, I don't have a problem with having to stay on HTTPS as pertains to the "big picture". My problem is very basic and concerns the fact that I no longer have a drop-down list from which to pick my edit summaries, because that function is thwarted by my IE-10 when I am on any HTTPS server. If that little quirk could be fixed, I'd be a happy camper whether I'm on a secure server or not. – Paine  15:47, 12 June 2015 (UTC)[reply]

I'm not very familiar with IE myself, but I'll ask around and see if anyone knows a simple fix. /Johan (WMF) (talk) 16:12, 12 June 2015 (UTC)[reply]

@Johan (WMF): IE10 won't enable autocomplete on HTTPS pages when the "Cache-Control: no-cache" HTTP header is set (which Wikipedia does). Changing it from "no-cache" to "must-revalidate, private" would allow autocomplete, but may have other unintended consequences. --Ahecht (TALK
PAGE) 16:34, 12 June 2015 (UTC)[reply]

I also see I am struck with using HTTPS, which is nuisance and a bother as I longer have a drop-down list from which to pick my edit summaries. How can a drop-down list be re-implemented? It was the only degree of automated help we had in what is otherwise an unfriendly article editing environment. Hmains (talk) 17:44, 12 June 2015 (UTC)[reply]

So how do I use the website in http then? I do not want extra security to protect me. I don't need protecting. This is a nonsense. Why am I being forced to use https even though I don't want to use it? There was an opt out. The opt out has been removed despite the fact that those using the opt out very clearly want to opt out. — Preceding unsigned comment added by 86.18.92.129 (talk) 19:46, 12 June 2015 (UTC)[reply]

Hi, the reason explanation I've been given is that any form of opt-out would also leave potential security risks in our implementation which make it difficult to safeguard those who do not opt-out. /Johan (WMF) (talk) 19:53, 12 June 2015 (UTC)[reply]

I'll try to figure out if there is a solution to that, Hmains. /Johan (WMF) (talk) 19:53, 12 June 2015 (UTC)[reply]

Johan (WMF), Re: "the reason explanation I've been given is that any form of opt-out would also leave potential security risks in our implementation which make it difficult to safeguard those who do not opt-out", would you be so kind as to ask for a one-paragraph explanation as to why they believe this to be true and post it here? Not a dumbed-down or simplified explanation, but a brief, fully technical explanation for those of us who are engineers? Thanks! --Guy Macon (talk) 20:49, 12 June 2015 (UTC)[reply]

Sure. Just so you know, they're getting a lot of questions at the moment, as well as handling the switch for the hundreds of Wikimedia wikis that aren't on HTTPS yet, but I'm passing on all questions I get that I can't answer myself. /Johan (WMF) (talk) 21:18, 12 June 2015 (UTC)[reply]

The engineering-level explanation is that in order to help prevent protocol downgrade attacks, in addition to the basic HTTPS redirect, we're also turning on HSTS headers (gradually). The tradeoff for HSTS's increased protections is that there's no good way to only partially-enforce it for a given domainname. Any browser that has ever seen it from us would enforce it for the covered domains regardless of anonymous, logged-in, logged-out, which user, etc. Once you've gone HSTS, opt-out just isn't a viable option. /BBlack (WMF) (talk) 21:56, 12 June 2015 (UTC)[reply]

It's worth giving some background here to understand the need for security. One of last year's revelations was that Wikipedia editors were being targeted by the NSA. So if you weren't using HTTPS (and probably even if you were), you were likely helping to build a database profile on your reading habits. But worse, your e-mail and other communications were probably also targeted for follow-up simply because you edit Wikipedia. What difference does it make? Nobody in the general public knows! The collected information is used in secret fashion in secret ways by undisclosed people. But there are real dangers to you. Supposedly, the information is being used only for national security related to terrorism. That's not true, however, because it is known from the same leaks that it is being used for more than that, for instance, in the war on drugs. And, it is also known that collected information is sometimes abused by those who have access to it for personal reasons. The use could also include (and probably is) helping to decide whether you get security clearance for future dream job. it could potentially even be used to sabotage a hopeful's political career or in general help silence people with oppositional points of view. In other words, this information has the potential to be used by people now or in the future to negatively affect your life and destiny without you even knowing. The WMF has decided (and rightfully so) that there's a need to protect users from dangers that they might not even be aware of. When it comes to this, many people say things like "I'm not doing anything wrong" or "I've got nothing to hide" but the problem is that you can't say you're doing nothing wrong because it's third parties who determine that, not you. And you do have stuff to hide even if you are completely a law-abiding citizen. This issue that affects you even if you think it doesn't. People are talking above about certain countries that do not allow HTTPS and how IP users there should be not be forced to use HTTPS because Wikipedia would be blocked for them. Well, those are great examples where governments being able to see what you are reading could get you arrested, imprisoned, or worse. The use of HTTPS is only a minor step in combating the abuse of government-level surveillance but it's a step in the right direction. @Johan (WMF), it'd be interesting to know why the implementation cannot safely handle an opt-out because naively I don't see why the one should affect the other. Maybe this exposes a flaw in the implementation. Jason Quinn (talk) 21:17, 12 June 2015 (UTC)[reply]

Hi Jason Quinn, thanks. I'm passing on the question to someone better suited to answer it than I am. /Johan (WMF) (talk) 21:20, 12 June 2015 (UTC)[reply]

On January 12, 2016, Windows 7 users will be required to install Internet Explorer 11 and Windows 8 users will be required to update to Windows 8.1 anyway, so you don't need to worry about the autocomplete problem in IE10. That problem doesn't occur in IE11. GeoffreyT2000 (talk) 21:26, 12 June 2015 (UTC)[reply]

Wikipedians were NEVER targeted by the NSA, why would they be? I don't know where you people are getting your information from and if some wikipedia came along and said that he was being targeted, the s/he was either being paranoid (like 90% of americans) or s/he is doing soemthing "illiegal" so its the best interest of wikipedia to report that person to NSA, not ENFORCE this stupid idea....Again Wikipedia is an INTERNATIONAL website, its NOT only for AMERICA....why should the rest of the world have to pay for the fears of a few paranoid psychopaths that are better off in jail..oh and BTW, HTTPS has and will NEVER be secure, the "s" in https never stood for secure...@Jimbo Wales:, Why would you allow this?--Stemoc 21:43, 12 June 2015 (UTC)[reply]

Template:Tracks Wikidata is a new template I've recently created. It generates a box with a list of Wikidata properties, with Module:Uses Wikidata allowing for unlimited parameters, and pulling the labels for the properties from Wikidata – or the text "NO LABEL" if it can't find a label (usually because the property has been deleted, or has not yet been created). While the template works in the /testcases page, in my sandbox, and Template:Commons category/doc, it is not working for Template:Coord/doc (shows NO LABEL for P625 instead of coordinate location). The Parser profiling data at the bottom of the edit window for Template:Coord/doc doesn't show anything out of range:

• CPU time usage 0.480 seconds
• Real time usage 0.588 seconds
• Preprocessor visited node count 3347/1000000
• Preprocessor generated node count 0/1500000
• Post-expand include size 95745/2097152 bytes
• Template argument size 4020/2097152 bytes
• Highest expansion depth 10/40
• Expensive parser function count 1/500
• Lua time usage 0.141/10.000 seconds
• Lua memory usage 3.96 MB/50 MB

Any idea on what's gone wrong – and why for some pages but not others? - Evad37 [talk] 15:09, 12 June 2015 (UTC)[reply]

There was a non-displayed character U+200E (LEFT-TO-RIGHT MARK) at Template:Commons category/doc. I have removed it but it's hard to see what happens in the diff. PrimeHunter (talk) 15:49, 12 June 2015 (UTC)[reply]

There seem to be two problems with Graphs. The new template {{GraphChart}} has a number of examples on its documentation page, Template:GraphChart/doc. But none of them appear on the main template page despite being transcluded. Setting up a test at User:JohnBlackburne/GraphTest to try and reproduce this I noticed another problem. That transcludes fine but the animation where e.g. the colours change as you mouse over the chart or part of it only work in preview, not after the page is saved. This is the case on both pages, including where one is transcluded. I tried disabling navigation popups in case that was causing it but it made no difference. I'm using the latest version of Safari in Mac.--JohnBlackburne^words_deeds 19:02, 12 June 2015 (UTC)[reply]

The first, I'm not sure why that is. But the latter is intentional. In preview it uses Javascript (also with future live editing in mind for instance), but in content, you only get the image representation (because the JS is slow and adds a lot of bytes to the pages). —TheDJ (talk • contribs) 19:10, 12 June 2015 (UTC)[reply]

Renders the JS rather pointless then, if it's only seen when editing. I can see why it would be a performance problem, but could it be made an option? I won't be the last to notice this and wonder why it’s not working.--JohnBlackburne^words_deeds 19:16, 12 June 2015 (UTC)[reply]

Ah, purging didn't fix the transclusion but a null edit did; very odd. And the second issue seems to be a will not fix one so this is now resolved.--JohnBlackburne^words_deeds 19:24, 12 June 2015 (UTC)[reply]