Jump to content

Wikipedia:Village pump (technical)

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by 47.138.165.200 (talk) at 00:05, 23 October 2016 (→Fundraising banner). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

 Policy Technical Proposals Idea lab WMF Miscellaneous 
Shortcuts
The technical section of the village pump is used to discuss technical issues about Wikipedia. Bug reports 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.


Gadget CSS order

Watchlist bolding

Since today, all entries in my watchlist are bolded. I have the " Display pages on your watchlist that have changed since your last visit in bold (see customizing watchlists for more options)" unchecked (like it used to be), but it bolds them anyway. If this is the new WMF standardn can the option in preferences please be turned into the opposite? I hate pages with that much shouting. Fram (talk) 06:52, 7 October 2016 (UTC)[reply]

Bold IS the default, it's English wikipedia that is divergent. A change was rolled out to how gadget's etc load, and it seems that for some reason our overrides are no longer overriding, we probably need to rework that gadgets slightly. This used to be Edokter's cup of tea :( —TheDJ (talk • contribs) 07:53, 7 October 2016 (UTC)[reply]
I've been having the same problem today. Someguy1221 (talk) 07:52, 7 October 2016 (UTC)[reply]
Came here to complain as well - surely someone knows what software has been altered in the last 24 hours? - Arjayay (talk) 08:16, 7 October 2016 (UTC)[reply]
Well, yesterday was Thursday - the normal day that breaking changes go live. --Redrose64 (talk) 08:35, 7 October 2016 (UTC)[reply]
Of course someone knows... that doesn't mean such knowledge works like fairy dust to fix problems. —TheDJ (talk • contribs) 08:40, 7 October 2016 (UTC)[reply]

Right. Style loading has changed slightly for Gadgets (phab:T42284). As a side effect, gadget ( specifically style only modules) no longer have dependencies/order I believe. That means that to immediately correct this, someone has to raise the specificity of style rules in MediaWiki:Gadget-WatchlistBase.css, with one level, and the specificity of style rules in MediaWiki:Gadget-WatchlistGreenIndicators.css, MediaWiki:Gadget-WatchlistGreenIndicatorsMono.css and MediaWiki:Gadget-WatchlistChangesBold.css with at least two levels. —TheDJ (talk • contribs) 08:40, 7 October 2016 (UTC)[reply]

Oh, horrors. --Redrose64 (talk) 08:45, 7 October 2016 (UTC)[reply]

Hopefully it will be "back to normal" and not so irritating at some point, and to the tech or editor who can do that, many virtual baked goods. Randy Kryn 12:06, 7 October 2016 (UTC)[reply]

Chiming in. For me it started yesterday in the late afternoon my time. I didn't post anything because I was foolishly hoping some overworked developer who no doubt inadvertently caused it would realize their error and fix it by today. Apparently not.--Bbb23 (talk) 12:52, 7 October 2016 (UTC)[reply]
Someone can also set type=general in the definition to revert to the old (still inefficient) behavior. —TheDJ (talk • contribs) 11:39, 10 October 2016 (UTC)[reply]
  • I posted something about it on the VP yesterday or the day before, but I can't find it. The bolding is horrible and totally unnecessary. Another whim of a WMFer who thinks he knows best and probably never edited a Wikipedia to any extent. Kudpung กุดผึ้ง (talk) 23:00, 10 October 2016 (UTC)[reply]
    • Your comment about the people involved is unfair, and I think you should strike it. If you look at the bug linked above (three days before your comment), the patch was written by someone who's an admin on two wikis and who has made more than 50,000 edits as a volunteer. The patch was written to resolve a real technical problem that was reported by a volunteer, User:He7d3r, who is an admin at two wikis and has made more edits than you. Describing this as merely some "whim of a WMFer who thinks he knows best and probably never edited a Wikipedia to any extent" is rude and wrong. Whatamidoing (WMF) (talk) 06:32, 11 October 2016 (UTC)[reply]
      Whatamidoing (WMF), in most cases my comments about the WMF are perfectly correct. I won't say publicly what I think about your comments over the years. Patches to MediaWiki software should NEVER have to be repaired by unpaid volunteers. Kudpung กุดผึ้ง (talk) 07:01, 11 October 2016 (UTC)[reply]
      I can agree that it's annoying when a favorite script stops working, especially when you have no idea how to fix it. However, it's quite the other way around: all local user scripts (gadgets are merely local user scripts that you can enable with the click of a button) are required to adapt to the global MediaWiki software. It is neither typically practical to find out which of the many thousands of user scripts on the hundreds of WMF wikis might be affected by any given change, nor reasonable to refuse to solve a known technical problem merely because it would require an update or a correction to a local user script. Whatamidoing (WMF) (talk) 07:49, 11 October 2016 (UTC)[reply]
      • But they could at least be aware of the type of problems their fix might cause, and give some indication when a solution might happen once they have been made aware of the problem. (And of course, equating one of the few general gadgets on enwiki with "the many thousands of user scripts on the hundreds of WMF wikis" is quite an easy cop-out). Fram (talk) 08:29, 11 October 2016 (UTC)[reply]
  • Please note: All entries aren't bold. Only the entries that were last edited by someone other than yourself. That's the purpose of the bolding -- to let you easily see where other editors have changed something. If you made the last change, the entry isn't bold. Softlavender (talk) 06:59, 11 October 2016 (UTC)[reply]
    • We know that, we aren't stupid. That doesn't mean this is the best way to do this. In the past, we had the opposite as default, and a gadget if you wanted this version. Now, we have this as the default, and no way (except by editing your css, which is not really a userfriendly way of doing this) to get the reverse. Fram (talk) 08:29, 11 October 2016 (UTC)[reply]
      • Fram, why would you need your own edits to be bolded? We already know about our own edits. What we need to know about are other people's edits -- that's why they are bolded, to accentuate them. And why does your OP say "all edits" if you don't mean "all edits"? Softlavender (talk) 22:11, 13 October 2016 (UTC)[reply]
        • You're right, I didn't explain that correctly. My watchlist (and the watchlist for everyone on enwiki who hadn't checked the gadget) showed no bolding at all so not "the opposite" of the current situation). Unviewed edits could be seen by the colour of the circle in fornt of the edits (blue or green). As to your second point, I do mean "all edits" as I have "hide my edits" checked by default (why would I want to see my edits on my watchlist?). So for me, all entries were bolded, with a few select ones later unbolded after I visited the page. 95% or more are bolded at any one time. Fram (talk) 10:03, 14 October 2016 (UTC)[reply]
    • Some of us are stupid, so thanks Softlavender. Some of us are just technophobes. Some of us may be newbies. Some of us are (getting more) forgetful. So thanks, Softlavender, for reminding us of what may be obvious to some. Martinevans123 (talk) 10:31, 11 October 2016 (UTC)[reply]

I note that I have given two possible solutions/workarounds already in this section, yet no community member has chosen to act on either. This is just an indication of how underrepresented technical skilled editors are amongst the sysops. We need WMF'ers to do everything for the English Wikipedia these days ? —TheDJ (talk • contribs) 09:11, 11 October 2016 (UTC)[reply]

Any word on when this bolding in the Watchlist will be fixed? I had to laugh, was in my "Gadgets" tab today and, bless my little peapicking Preferences' heart... there still sits the artifact line of "Display pages on your watchlist that have changed since your last visit in bold (see customizing watchlists for more options)" with its unchecked box. Thanks, Shearonink (talk) 12:27, 22 October 2016 (UTC)[reply]

Display problem, MonoBook, black background gadget

Tracked in Phabricator
Task T147667
Partial screenshot illustrating the problem

I use the MonoBook skin, and the black background with green text gadget. Since yesterday evening (British Summer Time) it has not been displaying properly. The left hand column with the search box, help, recent changes links etc. is displaying in blue text on white, and a phantom Wikipedia globe is present to the right of where it should be, overlaying some of the links at the top of the page. I have uploaded a screenshot to Img Safe here. DuncanHill (talk) 13:08, 7 October 2016 (UTC)[reply]

I see you import MediaWiki:Gadget-Blackskin.css in User:DuncanHill/common.css, but I get the same result as you when I choose MonoBook and enable the gadget in preferences (only an option in MonoBook). It works for me when it's loaded in this way: https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)?useskin=monobook&withCSS=MediaWiki:Gadget-Blackskin.css. That's not a practical solution but just an observation. PrimeHunter (talk) 20:08, 7 October 2016 (UTC)[reply]
I'd forgotten I had it in css. I also had it clicked in gadgets. I've removed it from my css. DuncanHill (talk) 20:18, 7 October 2016 (UTC)[reply]

Dark Skin Gadget Use a black background with green text on the Monobook skin is not fully working properly

Hello,

There is an issue with the following gadget: 'Use a black background with green text on the Monobook skin'. The issue is that the page MediaWiki:Gadget-Blackskin.css is not updated to work properly with wikipedia's design.

Basically, the gadget is outdated at this time, causing breakage of appearance. For instance, 1) the sidebar remains blue-text-on-white, 2) the background remains white, and 3) the table of contents remains blue-on-white.

You can test by enabling the gadget yourself, and the issues should appear on any computer. As this gadget provides a high-contrast theme for users, I'd like to request that the gadget be updated to fix these issues. X.A.N.A. the Evil Virus (talk) 04:55, 18 October 2016 (UTC)[reply]

Watchlist bold type

I see the bold type has mysteriously returned to the watchlist. How does one turn this unsightly mess off? - I can't find where too do in my preferences. --Kudpung กุดผึ้ง (talk) 13:05, 8 October 2016 (UTC)[reply]

Ugly isn't it? See earlier section above.--Bbb23 (talk) 13:08, 8 October 2016 (UTC)[reply]
.mw-special-Watchlist .mw-changeslist-line-watched .mw-title { font-weight: normal; } in your common.css should get rid of it. - NQ (talk) 14:39, 8 October 2016 (UTC)[reply]
@NQ: I commented out the code. First, it moved my edit button back to the left, which I hate. Second, it didn't help the watchlist. I'm putting it back the way it was.--Bbb23 (talk) 15:26, 8 October 2016 (UTC)[reply]
@Bbb23: No I meant you have to copy this code - .mw-special-Watchlist .mw-changeslist-line-watched .mw-title { font-weight: normal; } and add it to your common.css :) - NQ (talk) 15:34, 8 October 2016 (UTC)[reply]
@NQ: Thank god you're patient with me. Everything now good. Thanks!--Bbb23 (talk) 15:41, 8 October 2016 (UTC)[reply]
+1 - I've had it since yesterday and assumed someone somewhere had cocked something up .... Then again I wouldn't be surprised if someone somewhere thought "Hmm lets improve the project ..... by making the watchlist bold" ....., I dislike the watchlist being bold full stop - It looks bloody awful and isn't an improvement (atleast not too me anyway). –Davey2010Talk 14:52, 8 October 2016 (UTC)[reply]
FWIW I really like bold on the watchlist; when it's turned off I find it significantly harder to see what's changed. Sam Walton (talk) 15:33, 8 October 2016 (UTC)[reply]
Instead of per-user hacks, how about the fixes get put in to MediaWiki:Gadget-WatchlistChangesBold.css that everyone can already toggle via gadgets? If we've given up up having this gadget be used for this purpose, a replacement to unbold could be put out - and this one can be deleted. — xaosflux Talk 16:00, 8 October 2016 (UTC)[reply]
Is anyone doing something to fix this site-wide? I'm wary of such per-user hacks. This bold is incredibly ugly. I can't believe any experienced designer made deliberate choice for that to be the default. older ≠ wiser 16:13, 8 October 2016 (UTC)[reply]
Are you running Microsoft Windows? In the past, the common denominator for people who found bold ugly/fuzzy/difficult to read (as opposed to just disliking it) was having Microsoft Windows, which apparently tries to be helpful with bold fonts, but doesn't necessarily succeed. Whatamidoing (WMF) (talk) 06:37, 11 October 2016 (UTC)[reply]
Yes. I also edit on a Kindle where the bolding is a little less hideous, though still objectionable (although the biggest gripe about editing on kindle or or on my phone is that the size of the type changes when I click on something in my watchlist with the result I often end up clicking on something else as the entire line has shifted).older ≠ wiser 10:03, 11 October 2016 (UTC)[reply]

Search box width

I've noticed over the last few days that the "Widen the search box in the Vector skin" gadget in preferences no longer seems to be working. Is this intentional? Is there a workaround? Thanks. --Tryptofish (talk) 23:38, 9 October 2016 (UTC)[reply]

Looks like an admin needs to change MediaWiki:Gadget-widensearch.css to div#simpleSearch { width: 20em !important; }. For now you can add this to your common.css or your vector.css. -- The Voidwalker Whispers 00:01, 10 October 2016 (UTC)[reply]
 Done ~Oshwah~(talk) (contribs) 00:12, 10 October 2016 (UTC)[reply]
@The Voidwalker and Oshwah: The !important annotation is a cop-out. Normally it's better to increase the specificity of the selector. --Redrose64 (talk) 07:29, 10 October 2016 (UTC)[reply]
By doing what exactly? I'm not exactly an expert, and !important was the first thing which came to mind. -- The Voidwalker Whispers 17:18, 10 October 2016 (UTC)[reply]
Nevermind, we may have implemented the wrong fix. It seems that the devs changed div#simpleSearch to have the attribute max-width, thus if one overwrites the max-width value, we can actually set a width value greater than it. Although, it appears that the max value is already at 20em. We need only use div#simpleSearch {max-width:20em; width:20em;} if the max-width value is what needs changing. We should check to see that a fix like that is needed. I don't want to be changing things where they don't need to be changed. -- The Voidwalker Whispers 17:50, 10 October 2016 (UTC)[reply]
Okay, I'm going to do everyone a favor and not touch it anymore. :-) ~Oshwah~(talk) (contribs) 21:19, 10 October 2016 (UTC)[reply]
In the above CSS rule, the part inside the pair of braces is the declaration list, and the part which precedes the opening brace is the selector list. There is only one selector here, it is div#simpleSearch which is specific to any <div>...</div> element that has the attribute id=simpleSearch - if this selector had been #simpleSearch it would have been specific to any elements that have the the attribute id=simpleSearch. #simpleSearch has lower specificity than div#simpleSearch (and the div selector has even lower specificity since it applies to any <div>...</div> element, whatever attributes that element has). What we need to do is raise the specificity of div#simpleSearch still further, perhaps by using a type or class selector for the enclosing element. In this way we can avoid the use of !important - which is a last resort because it is so difficult to override: there is no !veryimportant annotation. --Redrose64 (talk) 16:53, 11 October 2016 (UTC)[reply]
For me, it's now back to working properly. Thanks. --Tryptofish (talk) 20:01, 10 October 2016 (UTC)[reply]
Well, that's what's important, let's not touch it again for as long as possible.... -- The Voidwalker Whispers 21:55, 10 October 2016 (UTC)[reply]

Watchlist

This has been going on for about two weeks for me...article titles are bold in my watchlist. I don't know if this has any affiliation with this since I only use Twinkle. — JudeccaXIII (talk) 21:55, 17 October 2016 (UTC)[reply]

@JudeccaXIII: That has to do with this section above. -- The Voidwalker Whispers 21:56, 17 October 2016 (UTC)[reply]

Failure of templates applying NOINDEX and probably other __magicwords__

Several templates attempt to apply __NOINDEX__ to hide problem-pages from search engines. It has just been discovered that this doesn't work. The pages don't actually get NOINDEXed. It seems likely that all __magicwords__ are being dropped from transclusion. A WMF staffer is currently looking into this. It will likely get fixed. Alsee (talk) 21:22, 11 October 2016 (UTC)[reply]

P.S. Roan Kattouw is the one looking into this. I'm pinging him here to post any updates. Oh, and "It will likely get fixed" was my assumption of the proper outcome here. Roan didn't say that. Alsee (talk) 21:31, 11 October 2016 (UTC)[reply]

Please post an example page. {{NOINDEX}} is currently working on all pages I examined, also after null edits. PrimeHunter (talk) 21:45, 11 October 2016 (UTC)[reply]
Is there a phab ticket open with more details? — xaosflux Talk 22:52, 11 October 2016 (UTC)[reply]
It looks like it's working just fine to me, from a quick test of a few pages (e.g. talk pages of BLPs are correctly showing it, non-BLP talk pages not showing it). Note that it can potentially take months for a change to be reflected in search engines, and that it's only an advisory request to them (i.e. search engines can ignore it if they want to). Note also that some namespaces have it disabled or forced on. From a quick look at InitialiseSettings.php and CommonSettings.php, it looks like NOINDEX is disabled in the main article and File namespaces, defaults to on in User and User talk, and is forced on in Draft and Draft talk. For other namespaces, it defaults to off and can be enabled on a per page basis. That's for enwiki, other WMF sites have different settings. See mw:Manual:Noindex for details of the MW config variables which control it (i.e. what to look for in those config files). Ideally those configuration settings should not be changed by WMF without first establishing community consensus for any change. I didn't check when the config last changed for them. Murph9000 (talk) 12:02, 12 October 2016 (UTC)[reply]
SOLVED. It has nothing to do with transclusion. NOINDEX is completely blocked in article space. That was where Roan Kattouw and I were testing it. The reason this came up is because there was discussion of having certain templates (like BLP-violation speedy delete) apply NOINDEX to the article. Alsee (talk) 12:46, 12 October 2016 (UTC)[reply]
I and many others could have told you that immediately and saved time investigating if you had just posted an example. One of the instructions in the edit notice here is: "Where did you encounter the problem? Please add links when possible." PrimeHunter (talk) 13:36, 12 October 2016 (UTC)[reply]
Well, that explains things, thanks for pointing that out. I've been a MediaWiki developer for over 9 years, yet I still learn new things about it from time to time, today is one of those days :) --Roan Kattouw (WMF) (talk) 17:23, 12 October 2016 (UTC)[reply]
BTW, the reason that this is the way it is, is to prevent people from easily NOINDEX'ing content, which is a highly non-visible change to a page. It's restricted out fear of abuse. —TheDJ (talk • contribs) 09:39, 14 October 2016 (UTC)[reply]
And when an inappropriate NOINDEX is removed it may take a long time before search engines discover it and start indexing the page. For this reason I would oppose any possibility of NOINDEX in mainspace, also with careful tracking. PrimeHunter (talk) 19:36, 15 October 2016 (UTC)[reply]
Noindex also intentionally does not work on the internal site search engine for similar reasons; it would be possible to hide pages from scrutiny incredibly easily, which has a lot of abuse potential. --Dan Garry, Wikimedia Foundation (talk) 03:22, 19 October 2016 (UTC)[reply]

Editing News #3—2016

Read this in another language • Subscription list for this multilingual newsletter • Subscribe or unsubscribe on the English Wikipedia

Did you know?

Did you know that you can easily re-arrange columns and rows in the visual editor?

Screenshot showing a dropdown menu with options for editing the table structure

Select a cell in the column or row that you want to move. Click the arrow at the start of that row or column to open the dropdown menu (shown). Choose either "Move before" or "Move after" to move the column, or "Move above" or "Move below" to move the row.

You can read and help translate the user guide, which has more information about how to use the visual editor.

Since the last newsletter, the VisualEditor Team has mainly worked on a new wikitext editor. They have also released some small features and the new map editing tool. Their workboard is available in Phabricator. You can find links to the list of work finished each week at mw:VisualEditor/Weekly triage meetings. Their current priorities are fixing bugs, releasing the 2017 wikitext editor as a beta feature, and improving language support.

Recent changes

  • You can now set text as small or big.[1]
  • Invisible templates have been shown as a puzzle icon. Now, the name of the invisible template is displayed next to the puzzle icon.[2] A similar feature will display the first part of hidden HTML comments.[3]
  • Categories are displayed at the bottom of each page. If you click on the categories, the dialog for editing categories will open.[4]
  • At many wikis, you can now add maps to pages. Go to the Insert menu and choose the "Maps" item. The Discovery department are adding more features to this area, like geoshapes. You can read more on MediaWiki.org.[5]
  • The "Save" button now says "Save page" when you create a page, and "Save changes" when you change an existing page.[6] In the future, the "Save page" button will say "Publish page". This will affect both the visual and wikitext editing systems. More information is available on Meta.
  • Image galleries now use a visual mode for editing. You can see thumbnails of the images, add new files, remove unwanted images, rearrange the images by dragging and dropping, and add captions for each image. Use the "Options" tab to set the gallery's display mode, image sizes, and add a title for the gallery.[7]

Future changes

The visual editor will be offered to all editors at the remaining 10 "Phase 6" Wikipedias during the next month. The developers want to know whether typing in your language feels natural in the visual editor. Please post your comments and the language(s) that you tested at the feedback thread on mediawiki.org. This will affect several languages, including Thai, Burmese and Aramaic.

The team is working on a modern wikitext editor. The 2017 wikitext editor will look like the visual editor and be able to use the citoid service and other modern tools. This new editing system may become available as a Beta Feature on desktop devices in October 2016. You can read about this project in a general status update on the Wikimedia mailing list.

Let's work together

Do you teach new editors how to use the visual editor? Did you help set up the Citoid automatic reference feature for your wiki? Have you written or imported TemplateData for your most important citation templates? Would you be willing to help new editors and small communities with the visual editor? Please sign up for the new VisualEditor Community Taskforce.

If you aren't reading this in your preferred language, then please help us with translations! Subscribe to the Translators mailing list or contact us directly, so that we can notify you when the next issue is ready. Thank you! Whatamidoing (WMF) (talk) 18:18, 14 October 2016 (UTC)[reply]

Save => Publish

@Whatamidoing (WMF): This was announced (and rejected by most people here, and by e.g. Wikinews) a few months ago. At the page you link to as "Information is available at Meta"[8] it still says "This change will probably happen during the week of 30 August 2016." Apart from that, that page still makes multiple claims you have been unwilling or unable to substantiate, about "Repeated user research studies", and no indication of any counter-study has been done, i.e. how many people would be confused by the "publish" label for their sandbox, drafts, or in general. Have you made these concerns publicly known to the people at Meta? Fram (talk) 14:12, 17 October 2016 (UTC)[reply]

How does Special:WantedTemplates get updated?

Two questions:

1. How does Special:WantedTemplates get updated?

2. How can I add Special:WantedTemplates to my Watchlist so that I can see when it changes? There is no option to add it with the usual star, and when I try to add it to my Watchlist manually by editing the raw Watchlist, the page does not get added. – Jonesey95 (talk) 22:52, 14 October 2016 (UTC)[reply]

Special pages are generated on request by MediaWiki. They cannot be edited or watched and have no page history. Some of them are based on cached data and some of those are no longer updated. See Help:Special page#Inactive. https://en.wikipedia.org/wiki/Special:WantedTemplates?uselang=qqx shows it displays MediaWiki:Querypage-no-updates, so it is MediaWiki itself which says "Updates for this page are currently disabled". I don't know why it's disabled but I guess you would have to file a request at phab: if you want it to update, or make a request at Wikipedia talk:Database reports if you want an editor to create a wiki page with similar data. PrimeHunter (talk) 23:28, 14 October 2016 (UTC)[reply]
And yet the page was updated on 19 September 2016, so somebody must know how and when it gets updated. Hmm. – Jonesey95 (talk) 00:14, 15 October 2016 (UTC)[reply]
They're updated via cron jobs every $so_often. They're sometimes disabled, sometimes not. It's a fun guessing game! ^demon[omg plz] 20:29, 17 October 2016 (UTC)[reply]

503 errors/possible Twinkle issues

Tracked in Phabricator
Task T146451

Seems to be affecting API calls -- samtar talk or stalk 15:34, 17 October 2016 (UTC)[reply]

And previewing -- samtar talk or stalk 15:35, 17 October 2016 (UTC)[reply]
I can report I get the message: Grabbing data of earlier revisions: error "Service Unavailable" occurred while contacting the API. when trying to use Twinkle. RickinBaltimore (talk) 15:35, 17 October 2016 (UTC)[reply]
I've been getting the same error message as RickinBaltimore when I try to revert someone's edits with Twinkle. Everymorning (talk) 16:26, 17 October 2016 (UTC)[reply]
I'm in the same general boat... "Grabbing data of earlier revisions: error "HTTP/2.0 503" occurred while contacting the API." Shearonink (talk) 16:30, 17 October 2016 (UTC)[reply]
I haven't experienced this myself, but then again, I haven't had a need to use Twinkle yet today. However, it seems to be working now based on reports being made with it over on WP:AIAV. Amaury (talk | contribs) 17:08, 17 October 2016 (UTC)[reply]
I don't know if this is relevant, but I also received a 503 HTTP/2.0 503 error message when I tried to usewp: hotcat. I am not using wp:twinkle. For more see: Wikipedia:Help desk#How can I remove a category from a page?. Ottawahitech (talk) 16:34, 19 October 2016 (UTC)please ping me[reply]

Several of my gadgets are malfunctioning

I'm getting a lot of failures from gadgets. As I write this my live Preview gadget displays nothing but

An error occurred while attempting to preview your changes.
HTTP error: error

My clock gadget that let's me purge a page by simply clicking it gets me a "Purge Failed" error.

My console suggests the root cause is because that https://en.wikipedia.org/w/api.php is returning a 503.—cyberpowerTrick or Treat:Online 15:36, 17 October 2016 (UTC)[reply]

Seems that all API application servers have stopped working.--Antigng (talk) 15:41, 17 October 2016 (UTC)[reply]

Even the simple task of adding a page to my watchlist isn't working right now. Stevie is the man! Talk • Work 15:52, 17 October 2016 (UTC)[reply]

Nothing's working. Almost everything relies on the API. - NQ (talk) 15:54, 17 October 2016 (UTC)[reply]
I am and have been for a couple weeks getting the same error with the clock gadget using Chrome. - Mlpearc (open channel) 15:58, 17 October 2016 (UTC)[reply]
Same here. I can't even revert a WP:BLP violation.- MrX 16:02, 17 October 2016 (UTC)[reply]
I just added something to my watchlist via raw edit for the first time ever.  :) Stevie is the man! Talk • Work 16:04, 17 October 2016 (UTC)[reply]

Failed to fetch notifications

My "notifications" widget is showing that I have 1 new notification, but when I click on it, I get a message stating "Failed to fetch notifications". (Monobook.js skin; Twinkle installed.) WikiDan61ChatMe!ReadMe!! 16:02, 17 October 2016 (UTC)[reply]

mw:notifications relies on API, which fails to work now. --Antigng (talk) 16:05, 17 October 2016 (UTC)[reply]

Tech News: 2016-42

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

Recent changes

Problems

  • Some users got a warning about Wikipedia's security certificate last week. This was because of a problem GlobalSign had. This has now been fixed. Only a small number of users got the warning. [9]
  • Editors couldn't edit semi-protected pages in the Wikipedia app for Android. This has now been fixed in the beta version. [10]

Changes this week

  • There will be no new MediaWiki version this week. [11]

Future changes

  • The Editing Department are working on a new wikitext editor. It will have tools that are in the visual editor but not in the wikitext editor today. You can read more about this. This is an early plan and things can change. The old wikitext editor will still exist.

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

16:42, 17 October 2016 (UTC)

Title blacklist

Hello, folks. If this is not the appropriate place to ask this question, I'll be happy to be re-directed elsewhere.

As a reviewer at Articles for Creation, I tried to accept a submission for publication, but was stopped with the notice that the move was forbidden ("titleblacklist-forbidden-move"). I took a look at both the local and global blacklists over at MediaWiki, but I'm not sure that I actually understood everything that was printed there.

For most of today, my watchlist had a notice that there was some central computer problem -- might this be what is preventing the move from Draft space into article space? Or is the title "There's a Gold Mine in the Sky" really on a black list?

I will greatly appreciate any help that you can provide. NewYorkActuary (talk) 00:02, 18 October 2016 (UTC)[reply]

@NewYorkActuary: Fixed. You should be able to move it now. Jackmcbarn (talk) 00:51, 18 October 2016 (UTC)[reply]
Thank you. NewYorkActuary (talk) 00:59, 18 October 2016 (UTC)[reply]
Woah, that regex is beyond me. How did removing "ſ" actually fix that? Someguy1221 (talk) 01:08, 18 October 2016 (UTC)[reply]
I, too, am lost & want for illumination. --Tagishsimon (talk) 01:17, 18 October 2016 (UTC)[reply]
@Tagishsimon, Someguy1221, and NewYorkActuary: I think the reason that helped is that the ſ character (the long s) is case-folded into an ordinary S character when case-insensitive comparison is used, probably causing this issue. Pppery 01:59, 18 October 2016 (UTC)[reply]
Thanks Pppery; that makes a sort of sense, although it feels more like a sort of unicode to ascii mapping than a case-insensitive issue ... but this is not my area. --Tagishsimon (talk) 03:23, 19 October 2016 (UTC)[reply]

Wishlist update

Hi, last year we had a wishlist process to decide what the WMF Community Tech team should focus on. The latest status report is out now, if you want to keep track of what's happening (and to make sure credit goes where credit should go: it's not just the Community Tech team doing things – other WMF teams, Wikimedia Germany and MediaWiki developers who do this in their spare time have worked on this as well).

The next wishlist process will start in November. /Johan (WMF) (talk) 09:09, 18 October 2016 (UTC)[reply]

Deleted article causing Petscan woe

A petscan report of mine lists Deborah L. Kerr as an extant en.wiki article, but per the redlink here, it does not exist; was deleted some time back. The fact of the undead article in the petscan list seems to break the WiDar tool which enables wikidata items to be created from petscan lists; it hangs. So that's bad. Can anyone throw any light on the problem? thanks --Tagishsimon (talk) 03:18, 19 October 2016 (UTC)[reply]

It should get reported here. But I think I have seen somebody telling about this to Magnus. --Edgars2007 (talk/contribs) 15:49, 19 October 2016 (UTC)[reply]
Thanks Edgars; I may have found a second, but so long as I know the bucket into which to throw them, I'm happy. --Tagishsimon (talk) 15:53, 19 October 2016 (UTC)[reply]

Linking new article to Wikimedia Q ID?

I am so not a tech guy. At the Greek Wikipedia, I stumbled on the Wikimedia Q# for Demetrios Alexatos. Right now I have just parked it at the article, but that's not right, I know. How do I link the new article to his Wikimedia Q ID?--Kintetsubuffalo (talk) 08:43, 19 October 2016 (UTC)[reply]

Visit Wikidata. Search for your man's record. Once found, look for the wikipedia box, hit edit, add en as the language and the article name for the page parameter. Wikidata checks that it has the right values for both (they appear beneath the input field boxes) ... save, done. But I've been there and done that for you, so, err... --Tagishsimon (talk) 08:49, 19 October 2016 (UTC)[reply]

Is there a way to find all article titles matching a particular regex?

There is a discussion going on MediaWiki talk:Titleblacklist to blacklist all titles which contain (or consist exclusively) 10 or more digits as they tend to be created by spammers. Is there a way to find out if there are legit titles which match this pattern? Something asked by MER-C on that talk page. JoJo Eumerus mobile (talk) 09:30, 19 October 2016 (UTC)[reply]

What I can do now is to set up a test abuse filter that checks all newly created pages against an arbitrary regular expression and just log the results. It'll take a week or so to get an idea of the false positive rate. MER-C 10:14, 19 October 2016 (UTC)[reply]
Done: Special:Abusefilter/1. MER-C 10:20, 19 October 2016 (UTC)[reply]
I searched the regular expression \d{10} (10 consecutive digits) at https://tools.wmflabs.org/grep without including redirects. It took around 10 minutes (and the tool has often timed out in the past) but it finally gave the below list. I had already seen four of them in Category:Integers. PrimeHunter (talk) 10:36, 19 October 2016 (UTC)[reply]
Hrm. Six pages with some low potential for others. Is that too many legit articles for a titleblacklist entry? Jo-Jo Eumerus (talk, contributions) 16:00, 19 October 2016 (UTC)[reply]
Can a blacklist have an associated whitelist?--S Philbrick(Talk) 16:39, 19 October 2016 (UTC)[reply]
Yes, MediaWiki:Titlewhitelist overrides MediaWiki:Titleblacklist. Blacklisted titles can be created by administrators and edited by others once they exist so there isn't much reason to add individual pages to a whitelist. Regular expressions are more useful. If many consecutive digits are disallowed by the blacklist then we could use the whitelist to allow titles only consisting of digits, or digits followed by " (number)". PrimeHunter (talk) 17:02, 19 October 2016 (UTC)[reply]

Usernames with large numbers and their user talk pages appear to be another common false positive (per MER-C's edit filter above), so I'd restrict the blacklist to articles, page creation and new editors to reduce collateral damage. Jo-Jo Eumerus (talk, contributions) 15:17, 20 October 2016 (UTC)[reply]

Articles in a series appear to be deleted

There are articles regarding different years of the California Golden Bears football. Such as 1996 California Golden Bears football team or 1997 California Golden Bears football team. The 1997 article exists and is accessible through a wikipedia search or a google search. The 1996 article is not accessible through a wikipedia search and does not show up on a google search. Through a quick search it appears that the majority of the year articles are either not accessible or deleted. Thank you very much for your help. Rybkovich (talk) 16:10, 19 October 2016 (UTC)[reply]

I see no signs there has ever been an article at 1996 California Golden Bears football team. It is a redirect to California Golden Bears football. Redirects are common. The redirect was created 8 September 2016‎ and the page history [12] shows it has always redirected to the same article. PrimeHunter (talk) 16:35, 19 October 2016 (UTC)[reply]
I don't know why you think there is an article by that name but a redirect causes a blue link, and redirects can be placed in categories but will be shown in italics. See for example Category:California Golden Bears football seasons where 1996 and many earlier years are in italics. PrimeHunter (talk) 16:46, 19 October 2016 (UTC)[reply]
Got it, thank you. What threw me off is that previously the empty article links appeared in red, seems like was intended to indicate that there was no article for that year, and I think it worked. Now that they are redirects they appear in blue. This seems to be confusing. I will contact the editor that created the redirects. Rybkovich (talk) 18:22, 19 October 2016 (UTC)[reply]

Edit filter gone nuts

Edit filter 320, which hadn't been changed for two months, went "nuts" today at exactly 17:30 (UTC) hitting a large number of non-vandal IP edits. Was there some change to the software? And can anyone help resolve it? -- zzuuzz (talk) 18:22, 19 October 2016 (UTC)[reply]

Commented at the edit filter noticeboard. Jo-Jo Eumerus (talk, contributions) 18:24, 19 October 2016 (UTC)[reply]

Request for bot to remove blacklisted web site

I'm not sure where to ask, but it involves a request for action by a bot, so this might be a good place. A Teahouse question did not get a response. Dandelany saw a potentially harmful web site and wanted it blacklisted and hoped a bot could remove it if it was added many places.— Vchimpanzee • talk • contributions • 19:15, 19 October 2016 (UTC)[reply]

Search only finds it on 5 article pages so I've removed them by hand, less spam than a poor way of using foreign language wikipages as references here. Nthep (talk) 19:30, 19 October 2016 (UTC)[reply]
Thanks. So it still needs to be blacklisted, which is not a technical question, I guess.— Vchimpanzee • talk • contributions • 19:42, 19 October 2016 (UTC)[reply]

Mark individual watchlist entry as visited

This minor aspect of watchlists has bugged me for a long time. Why can't there be a way to mark an individual watchlist entry as visited (i.e., unbold it) without having to actually visit the page? I have on-page means to see the diff without actually clicking the link and loading the page. And sometimes I don't even feel the need to look at the diff (like if the edit came from a trusted bot or editor), but just want to tick off that the entry is visited. I searched Phabricator and there doesn't seem to be any requests for this. Being able to mark these entries as visited would seem to save a bunch of wiki-time in accumulation. If there's no interest in changing the wiki software, might there be a script I can use to accomplish this? Stevie is the man! Talk • Work 00:30, 20 October 2016 (UTC)[reply]

This is on my wishlist too. Generally, what I do is visit all the diffs that need visiting, and click "mark all as visited" to tick off the rest. Eman235/talk 00:40, 20 October 2016 (UTC)[reply]
@Stevietheman and Eman235: Hey! This functionality exists within the Mediawiki API, see mw:API:SetNotificationTimestamp. You'll have to talk to Writ Keeper to get this added to the inlinediff scripts. Meanwhile, checkout the listPageOptions gadget which has this incorporated.- NQ (talk) 08:03, 20 October 2016 (UTC)[reply]
Thanks NQ for the info and the gadget! I couldn't find the gadget in en preferences, so I added it to my .js, and after setting some variables to my tastes, it works very well. The only nit I would note is that if I mark an entry as visited, the visited filter doesn't remove it from view unless I reload the page (but this won't keep me from using and loving this gadget). As for Writ Keeper's inline diff, I'm not sure I want that to automatically mark an entry as visited. Stevie is the man! Talk • Work 13:01, 20 October 2016 (UTC)[reply]
I'm pretty sure there's a request on phabricator for this, but I can't find it. --Izno (talk) 11:38, 20 October 2016 (UTC)[reply]

Is User:Zhaofeng_Li/Reflinks.js SAFE ?

Xb2u7Zjzc32 (talk) 02:41, 20 October 2016 (UTC)[reply]

@Xb2u7Zjzc32: I believe that is the code for reFill? You don't have to copy that anywhere. That can be done through a web interface. See WP:refill or for the direct link, toollabs:refill. --Majora (talk) 02:43, 20 October 2016 (UTC)[reply]

uploading to commons.wikimedia.org

After uploading to commons.wikimedia.org, the resulting file is still the old one. One needs to wait some time, and refresh, for the change to the new file. Did I miss a notice about this ? Xb2u7Zjzc32 (talk) 02:56, 20 October 2016 (UTC)[reply]

@Xb2u7Zjzc32: That has been that way for as long as I can remember. The old image is cached by the server. A WP:PURGE fixes it. Whenever I upload a replacement file I always just purge the page when I am done. If you have the clock gadget enabled this is easily done by just clicking the clock. The gadget can be enabled by going to your preferences -> gadgets -> appearance -> Add a clock to the personal toolbar that displayed the current time in UTC and provides a link to purge the current page. The gadget has to be enabled independently on Commons but is actually called "UTCLiveClock". --Majora (talk) 03:35, 20 October 2016 (UTC)[reply]

No edit conflict

Why when two people protect the same article at the same time is no edit conflict given? It's happened before. CambridgeBayWeather, Uqaqtuq (talk), Sunasuttuq 05:21, 20 October 2016 (UTC)[reply]

This looks to me like a bug, please follow the instructions at WP:BUGS. עוד מישהו Od Mishehu 08:12, 20 October 2016 (UTC)[reply]
@CambridgeBayWeather: Short answer: protection changes do not alter the wikicode, therefore there is no actual edit, therefore there can be no edit conflict. --Redrose64 (talk) 10:11, 20 October 2016 (UTC)[reply]
Thanks both. CambridgeBayWeather, Uqaqtuq (talk), Sunasuttuq 10:18, 20 October 2016 (UTC)[reply]

Is there any way to look for incoming links to a specific page from our sister sites, such as other Wikipedias, Wikibooks, the Commons, etc? עוד מישהו Od Mishehu 08:11, 20 October 2016 (UTC)[reply]

phab:T3886 - A cross-wiki "What links here" (aggregate local iwbacklinks from wikis) - NQ (talk) 08:28, 20 October 2016 (UTC)[reply]

Different image - logged in versus not logged in

I am trying to help someone at OTRS with an issue. The issue originally seem to be related to Commons so I was handling it as part of the Commons queue, but I just realized this morning that the problem is in the German Wikipedia. Now I'm quite aware that this is not the German Wikipedia but I'd like to describe the problem and asked if this conceptually could happen in the English Wikipedia or is it something that plausibly could be due to a different configuration of mediawiki for the German Wikipedia.

In short, if you go to this article while logged in:

de:Florian_Streibl

You are likely to see this image (from Commons): File:Florian Streibl 2016.jpg

However, if you go to the article while not logged in:

You are likely to see this image (from Commons): File:8088ri-Florian_Streibl.jpg


I tried this and verified the difference.

I don't know why the software would deliver a different image when logged in versus not logged in. If this is possible in the English Wikipedia, then perhaps someone could tell me what's causing it and how to fix it. If it's not possible in the English Wikipedia then I'll have to direct my question to the German counterpart of VPT.--S Philbrick(Talk) 12:43, 20 October 2016 (UTC)[reply]

@Sphilbrick: Pending changes. Logged in users see the latest revision and logged out users see the last accepted revision from Jan 2016. - NQ (talk) 12:50, 20 October 2016 (UTC)[reply]
Thanks for the prompt answer. So what advice should I give? Do they need to prod someone to accept the latest change, or do I tell them to just wait, and it will be fixed shortly?--S Philbrick(Talk) 12:59, 20 October 2016 (UTC)[reply]
@Sphilbrick: de:Wikipedia:Gesichtete Versionen/Anfragen is where I think requests are to be made. - NQ (talk) 13:12, 20 October 2016 (UTC)[reply]
Thanks--S Philbrick(Talk) 13:22, 20 October 2016 (UTC)[reply]

Template populated redirected categories

Category:Wikipedia non-empty soft redirected categories is currently hosting a lot of category redirects that are populated either by templates or other arrangements that the redirect bot can't handle. Can some editors with the technical skills have a look through them and see if they can get the contents to move over? Thanks in advance. Timrollpickering (talk) 13:21, 20 October 2016 (UTC)[reply]

Move over to where? Jo-Jo Eumerus (talk, contributions) 15:19, 20 October 2016 (UTC)[reply]
The template to edit is Template:Category redirect, btw. — Mr. Stradivarius ♪ talk ♪ 23:11, 20 October 2016 (UTC)[reply]
Please give an example like "X is currently Y but should be Z" another time. I think you want to empty the subcategories of Category:Wikipedia non-empty soft redirected categories. For example, if Category:Foo is emptied then Template:Category redirect should automatically remove it from Category:Wikipedia non-empty soft redirected categories. See MediaWiki talk:Gadget-popups.js#Category:Foo for an explanation of how js pages get into categories and can be removed. Some of the other subcategories are populated in other ways. I guess your "get the contents to move over" means you want pages to move from Category:Foo to its redirect target Category:X1. But in this example the pages should probably just be removed from the category without changing it to another category. PrimeHunter (talk) 10:37, 21 October 2016 (UTC)[reply]

Current examples of three types:

Simply editing to change the former to the latter category doesn't seem to work in these cases and similar. Timrollpickering (talk) 08:49, 22 October 2016 (UTC)[reply]

The constructs {{#babel:en-GB}} and {{#babel:en-gb}} will populate Category:User en-GB and also Category:User en-GB-N. Find where it's used, and alter to {{#babel:en}}. --Redrose64 (talk) 10:03, 22 October 2016 (UTC)[reply]

Archive bot

Does anyone know why this section Wikipedia talk:Editing policy#.22Dodge Tomahawk.22 hasn't been archived yet? It's set to 60 days, and about 150 days after this message, the bot archived some other discussions, but not this. Have I missed something obvious? WhatamIdoing (talk) 16:54, 20 October 2016 (UTC)[reply]

@WhatamIdoing: because there are exactly five discussions on that page. the minthreadsleft parameter is not set there, and by default it's set to 5. Graham87 01:36, 21 October 2016 (UTC)[reply]
Thanks. I'd thought that the default was four. WhatamIdoing (talk) 02:09, 21 October 2016 (UTC)[reply]

Most venues such as WP:AFD, WP:TFD, WP:RFD place new nominations at top. This causes an issue with section edit links. If you try to edit a section and a new discussion has been added to the page since you have opened it, you will end up editing the wrong section as those links refer to sections by their number. I'm not sure what's the best place to discuss a possible change to that, but perhaps something could be done from the technical side, I don't know. nyuszika7h (talk) 22:01, 20 October 2016 (UTC)[reply]

  • The issue doesn't affect AfD as there you get transcluded subpages rather than sections, but otherwise I agree: commenting in RfD and TfD sometimes gets annoying because of that. – Uanfala (talk) 22:20, 20 October 2016 (UTC)[reply]
  • Perhaps developers could section-edit by matching title: Although sections can be titled with numerals, it might be easy for the wp:developers to change section-editing to match a section-header text title when the "&section=" is not a numeral. The edit-merge has matched such section-headers in the past, to the first matching header title. This section-header edit could be added as a suggestion in the "meta:2016 Community Wishlist Survey" during November 7-20, 2016. -Wikid77 (talk) 16:23, 21 October 2016 (UTC)[reply]

Template edit

Hi, could someone please check whether this edit is correctly done, and fix it if necessary. The purpose is to stop a line break being inserted before the bracket, which happens in some browsers. The edit appears not to have worked, but I'm not sure if could be just a propagation delay. I am not familiar with editing templates. Thanks. 86.185.218.185 (talk) 03:12, 21 October 2016 (UTC)[reply]

It looks fine to me. Why do you say that the edit doesn't appear to have worked? — Mr. Stradivarius ♪ talk ♪ 06:41, 21 October 2016 (UTC)[reply]
If it's just a propagation delay then it will work to purge affected pages. If purging doesn't work then name an example page and your browser. PrimeHunter (talk) 09:02, 21 October 2016 (UTC)[reply]
What bracket? I don't see any bracket in that vicinity, and certainly not within the text that you nowrappped. ―Mandruss ☎ 09:09, 21 October 2016 (UTC)[reply]
Template:Nowrap says, "It prevents word wraps (line breaks) within text or inside a link which contains spaces or hyphens ("-")." There are no spaces or hyphens within "language(s)". Unless the Nowrap doc is incorrect, the edit itself seems questionable. ―Mandruss ☎ 09:16, 21 October 2016 (UTC)[reply]
Bracket means parentheses here. The edit looks OK. You could say the Nowrap doc is incomplete because it doesn't list all cases where a browser may wrap text if it doesn't have nowrap code. My Firefox doesn't wrap at parentheses like in "language(s)" but some browsers do, e.g. my IE and Opera. It can be tested by narrowing the window slowly and see whether "(s)" alone wraps to a new line below or "language(s)" always stays together. PrimeHunter (talk) 11:07, 21 October 2016 (UTC)[reply]

language(s) language(s) language(s) language(s) language(s) language(s) language(s) language(s) language(s) language(s) language(s) language(s) language(s) language(s) language(s) language(s) language(s) language(s) language(s) language(s) language(s) language(s) language(s) language(s) language(s) language(s) language(s) language(s) language(s) language(s)

Thanks. My Firefox doesn't wrap it either, not surprisingly. I can't imagine the rationale for wrapping that, but whatever. ―Mandruss ☎ 11:17, 21 October 2016 (UTC)[reply]
I'd put a hidden comment on that to explain the odd use of Nowrap, if that would work there. Otherwise I couldn't expect it to survive long term. Editors naturally tend to remove stuff that they see as unnecessary. ―Mandruss ☎ 11:25, 21 October 2016 (UTC)[reply]
This sounds very much like Wikipedia:Village pump (technical)/Archive 143#Nowrap for references, different type of bracket, but certainly browser-dependent. --Redrose64 (talk) 21:56, 21 October 2016 (UTC)[reply]
  • (OP) Thanks, it seems it was a propagation delay. I tried purging earlier but I think I must have got the syntax wrong. Anyway, I have purged the relevant page correctly now and it is working fine. 86.185.218.12 (talk) 13:59, 21 October 2016 (UTC)[reply]

Time zone issue?

Hi everyone,
I tried to file a copyright violation by the link the template gave me and ended up on a "Permission error" page. Now I was wondering: Is this a login issue only or possibly a time zone issue (Wikipedia possibly still being on October 20 while I am in a time zone where we have Oct. 21 already)?
I did the best I could now and filed it on the Oct. 20 page. --84.190.89.103 (talk) 09:22, 21 October 2016 (UTC)[reply]

No, Wikipedia has been on 21 October for over nine hours now. The problem is merely that people who are not logged in cannot create pages in Wikipedia: namespace. I've created the page now, so you should be able to carry on filing your copyvio. --Redrose64 (talk) 09:30, 21 October 2016 (UTC)[reply]
Oh, I see that you already filed it at Wikipedia:Copyright problems/2016 October 20. I've moved it to Wikipedia:Copyright problems/2016 October 21 for you. --Redrose64 (talk) 09:35, 21 October 2016 (UTC)[reply]
Thanks! --84.190.89.103 (talk) 12:15, 21 October 2016 (UTC)[reply]

Need 2016 sources for Template:Inflation

See: "Template_talk:Inflation#Need to update for 2016 data". Thanks. -Wikid77 (talk) 16:00, 21 October 2016 (UTC)[reply]

Special:Notifications pagewidth

Why is (firefox, mac, vector) Special:Notifications designed to be wider than my screen / designed not to accommodate itself to the screen width? Or, rather, could it be tamed? -- — Preceding unsigned comment added by Tagishsimon (talk • contribs) 17:15, 21 October 2016 (UTC)[reply]

I believe that it is a responsive design, but with a minimum width. User:Quiddity (WMF) could probably tell you more. In the meantime, would you consider posting a WP:Screenshots of Wikipedia or e-mailing one to me or Quiddity? Whatamidoing (WMF) (talk) 17:20, 21 October 2016 (UTC)[reply]
That's a Firefox bug (phab:T147802) if one of the notification excerpts contains a long string, e.g. a URL. Research ongoing (See phab:T147802#2713122 for the TLDR.) Quiddity (WMF) (talk) 17:25, 21 October 2016 (UTC)[reply]
Thanks. On a second look, I found the long URL. I'm happy its in the pipeline; thank you both for that double-fast WMF response; I presume screengrab is now superfluous, but if not let me know and I'll send. --Tagishsimon (talk) 17:29, 21 October 2016 (UTC)[reply]

Background and border color of a table

Hello. Which are the parameter to have a white background and with border of a table. Actually I need to have no color at all. Just to have the background colour of the Wikipedia page. Xaris333 (talk) 18:19, 21 October 2016 (UTC)[reply]

  • Tables are transparent by default; you're probably adding the default styling with class="wikitable"; remove that. If you needed to force it, you'd use background-color: transparent; in the style attribute. For borders, don't use the deprecated border attribute; use border: 1px solid #aaa; or similar in the style attribute instead. In summary: use something more like {| style="background-color: transparent; border: 1px solid #aaa;" instead of {| class="wikitable". {{Nihiltres |talk |edits}} 19:33, 21 October 2016 (UTC)[reply]

User:Nihiltres I still have the outside border. I want also to remove that.

Example1
Example2

Xaris333 (talk) 19:49, 21 October 2016 (UTC)[reply]

@Xaris333: OK, so you don't want any styling at all, then; omit the style="…" text entirely:

Cell 1 Cell 2
Cell 3 Cell 4

Cheers, {{Nihiltres |talk |edits}} 19:55, 21 October 2016 (UTC)[reply]

Thanks! Xaris333 (talk) 20:01, 21 October 2016 (UTC)[reply]

Fundraising banner

I am using Google Chrome, where I saw a small, one-line, and orange fundraising banner. I closed it. But then I saw again the larger banner I'm more used to seeing. Is it a bug for people to see another banner after closing out of the first? Thanks. Biosthmors (talk) pls notify me (i.e. {{U}}) while signing a reply, thx 22:31, 21 October 2016 (UTC)[reply]

@Biosthmors: I don't know for sure. It might be they want to hit you with the big banner to try to sway you if you don't respond to the small one. I believe you aren't supposed to see banners over and over (unless you are blocking or clearing cookies on your end, as a cookie is used to track whether you've seen a banner). The Meta Fundraising talk page is probably a better place to ask, as that is watched by members of the WMF Fundraising team. --47.138.165.200 (talk) 00:05, 23 October 2016 (UTC)[reply]

Template:Dynamic IP has broken hostname/IP links, WMF splinetools is no longer functional

I am not sure how to fix this. Discussion at Template talk:Dynamic IP, please. 80.221.159.67 (talk) 08:37, 22 October 2016 (UTC)[reply]

Mentioned here - commented at talk -- samtar talk or stalk 08:49, 22 October 2016 (UTC)[reply]

Sudden change of editing font

Moved from WP:AN

Template:Weather box errors

In Shanghai#Climate I currently see four errors below the weather box: "The parameter "Year humidity" is not recognized by Template:Weather box". The same goes for "Year sun", "Year precipitation mm" and "Unit precipitation days" parameters. Perhaps something was messed up. Could someone check what's going on? Brandmeistertalk 11:23, 22 October 2016 (UTC)[reply]

@Brandmeister:  Fixed by editing {{Shanghai weatherbox}}. Template parameter names are case-sensitive. -- John of Reading (talk) 13:31, 22 October 2016 (UTC)[reply]

Wikipedia:Templates_for_discussion/Log/2016_October_22#Template:Gallery_sequence

Hi. Appreciate if anyone can have a look at the possibility of fixing this template. Thanks in advance! Rehman 13:06, 22 October 2016 (UTC)[reply]

Script tags in userspace

Hello fellow Wikipedians, I have been working on something on my userpage that displays a different piece of text every day (if you look at my userpage, I'm talking about the dedications at the top of my page), and repeats the display of this text every month. I want to create a link that links to the previous and next day's text (without me having to update it every day). I have figured out a way to do it on my account only by editing my common.js. When I try to put script tags on my userpage they seem to get escaped out, because they don't actually call the code that I put in them, they actually get displayed on the page. Is there a way to add a script to a local page in such a way that all visitors of the page see it? Gluons12 ☢|☕ 15:13, 22 October 2016 (UTC).[reply]

No, <script>...</script> cannot be used on a wikipage. The way you should probably try to do what you are doing is either the Help:Magic words or WP:Lua. I would guess that magic words are sufficient for your use case. --Izno (talk) 15:23, 22 October 2016 (UTC)[reply]
Thanks, the {{#expr:}} magic word worked. Gluons12 ☢|☕ 16:38, 22 October 2016 (UTC).[reply]

Email address revealed in "email a user" function

Hey, have messages sent through "email this user" always revealed the sender's email address? I remember this being masked through the Wikimedia servers, but lately emails I've received have come from "Username <user's real email@a real address.eg> via Wikimedia.org". Was there a switch or am I just ignorant? Ivanvector (Talk/Edits) 17:18, 22 October 2016 (UTC)[reply]

They've certainly always been visible as long as I've been active (10 years or so), otherwise how could anyone reply to emails? You should see a massive "Your email address will be disclosed to the recipient" warning box whenever you click on Special:EmailUser. ‑ Iridescent 17:25, 22 October 2016 (UTC)[reply]
[O]therwise how could anyone reply to emails? There are plenty of websites out there that let you sustain an email exchange without revealing user's email addresses. – Uanfala (talk) 17:36, 22 October 2016 (UTC)[reply]
I suspect you are thinking of things like Facebook Mail or Web forum private messaging, which aren't e-mail at all, but a completely separate internal messaging system implemented in the website. I understand how non-"computer people" just lump them all together, but "under the hood" the mechanics are completely different. The other thing that I think some sites do is set up their own e-mail aliases, where everyone with an account at example.com gets a "username@example.com" address, and e-mails sent to that address are relayed to their "real" e-mail address. --47.138.165.200 (talk) 23:53, 22 October 2016 (UTC)[reply]
This is how it has been for years. If user "Example" sends me an email through Wikipedia, I see his email address (example@example.com). The reverse is not true. At the bottom of the email to me will be the words:
"This email was sent by user "Example" on the English Wikipedia to user "Guy Macon". It has been automatically delivered and the Wikimedia Foundation cannot be held responsible for its contents."
"The sender has not been given the recipient's email address, nor any information about his/her email account; and the recipient has no obligation to reply to this email or take any other action that might disclose his/her identity. If you respond, the sender will know your email address. For further information on privacy, security, and replying, as well as abuse and removal from emailing, see <https://en.wikipedia.org/wiki/Wikipedia:Email>."
--Guy Macon (talk)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&oldid=745732796"