Wikipedia:Village pump (technical): Difference between revisions

Browse history interactively

← Previous edit Next edit →

Content deleted Content added

VisualWikitext

Inline

Revision as of 22:43, 10 October 2019

Table of contents
First discussion
End of page
New post

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. If you want to report a JavaScript error, please follow this guideline. Questions about MediaWiki in general should be posted at the MediaWiki support desk.

view · edit

Frequently asked questions (see also: Wikipedia:FAQ/Technical)

Click "[show]" next to each point to see more details.

If something looks wrong, purge the server's cache, then bypass your browser's cache.
This tends to solve most issues, including improper display of images, user-preferences not loading, and old versions of pages being shown.

No, we will not use JavaScript to set focus on the search box.
This would interfere with usability, accessibility, keyboard navigation and standard forms. See task 3864. There is an `accesskey` property on it (default to `accesskey="f"` in English). Logged-in users can enable the "Focus the cursor in the search bar on loading the Main Page" gadget in their preferences.

No, we will not add a spell-checker, or spell-checking bot.
You can use a web browser such as Firefox, which has a spell checker.

If you have problems making your fancy signature work, check Help:How to fix your signature.

If you changed to another skin and cannot change back, use this link.
Alternatively, you can press Tab until the "Save" button is highlighted, and press Enter. Using Mozilla Firefox also seems to solve the problem.

If an image thumbnail is not showing, try purging its image description page.
If the image is from Wikimedia Commons, you might have to purge there too. If it doesn't work, try again before doing anything else. Some ad blockers, proxies, or firewalls block URLs containing /ad/ or ending in common executable suffixes. This can cause some images or articles to not appear.

For server or network status, please see Wikimedia Status. If you cannot reach Wikipedia services, see Reporting a connectivity issue.

« Archives, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215, 216

Alarming "only a preview message"

Tracked in Phabricator
Task T232414

I use the MonoBook skin. Yesterday, when editing, I started to see a large pink box with an orange border:

This is only a preview; your changes have not yet been saved! → Go to editing area

I think the warning was there before, but it was not so jarring. Any ideas on how to tone it down? Aymatth2 (talk) 13:45, 20 September 2019 (UTC)[reply]

@Aymatth2: looks like that is getting its markups from the warningbox class, and from bolding at MediaWiki:Previewnote. That entire box is a div, class "previewnote" so you could just suppress it in your personal skin. Do you have a specific suggestion for what you think it should be changed to? — xaosflux ^Talk 14:00, 20 September 2019 (UTC)[reply]

It was changed to use standard warningbox class at phab:T232414. I also think the new style is too garish. – Ammarpad (talk) 14:14, 20 September 2019 (UTC)[reply]

Surely we should be encouraging the use of preview (to reduce typos, formatting errors, etc) rather than disconcerting those of us who do use it? DuncanHill (talk) 14:26, 20 September 2019 (UTC)[reply]

@DuncanHill: In my opinion "I think" it's too garish. I am not asking for it to be changed, but I'll change it for my account when I want. So I am not disconcerting anybody. Thanks. – Ammarpad (talk) 15:06, 20 September 2019 (UTC)[reply]

I wasn't suggesting that you were disconcerting anyone. I was suggesting that the message is disconcerting and perhaps counterproductive. DuncanHill (talk) 15:11, 20 September 2019 (UTC)[reply]

Ping to User:Volker E. (WMF) - the WMF staffer that drove that change. Volker, any options to soften this that would fit in with the rest of the UX? — xaosflux ^Talk 14:28, 20 September 2019 (UTC)[reply]

Thanks for pinging me, User talk:Xaosflux. That's correct, we've amended the message box to follow all standard warnings across pages and products. phab:T232414 was just the latest. This has been changed to provide users consistent system message appearances. While we do understand that this might be unusual for users knowing the before state, it's meant to make orientation for all users simpler. As I've seen there are already ways described below for dealing with the change for people who would like to have a toned-down warning instead. Volker E. (WMF) (talk) 05:10, 21 September 2019 (UTC)[reply]

Yet another unwanted "improvement" that no one asked for, and yet again you suggest that it's all right and users should invent workarounds on their own. — Mike Novikoff 06:35, 21 September 2019 (UTC)[reply]

@Volker E. (WMF): - could you let us know the following: how many editors stated they wanted a more consistent style; why no warning, or at least an FYI, wasn't given here, if you think workarounds are beneficial, why not create a meta page explaining/summarising how? Nosebagbear (talk) 09:40, 21 September 2019 (UTC)[reply]

I've removed the bolding of the text, as it is now in a call out box. — xaosflux ^Talk 14:31, 20 September 2019 (UTC)[reply]

The message appears just under a large "Preview" header, so it is obvious that it is a preview. I would prefer to just drop the pink box and leave the message, unbolded:

Preview

This is only a preview; your changes have not yet been saved! → Go to editing area

Aymatth2 (talk) 14:33, 20 September 2019 (UTC)[reply]

It is possible to remove that h2 label, but the hl will still be there (in MediaWiki:Preview). — xaosflux ^Talk 14:39, 20 September 2019 (UTC)[reply]

@Xaosflux:, why does MediaWiki:Preview display a deletion log entry when there is a page that exists there, with the source being 'Preview'? Headbomb {t · c · p · b} 15:16, 20 September 2019 (UTC)[reply]

It's a Mediawiki "message" so it's reflecting the default from the source. When you add content it overrides the source message. The content was deleted because it's the same as the source. – Ammarpad (talk) 15:28, 20 September 2019 (UTC)[reply]

You could add this to your CSS:

.previewnote .warningbox {border: none; background-color: white;}

That reminds me, I have been thinking about creating a page for tips on reverting unwanted interface changes. There could be general tips (like clear your cache, update your browser, try removing broken user scripts), and a list of specific instructions for specific changes, but also a list of some things which cannot be reverted. It might be called Wikipedia:Take me back. Good idea? PrimeHunter (talk) 14:43, 20 September 2019 (UTC)[reply]

Seems like a great idea to me User:PrimeHunter. Jdlrobson (talk) 18:40, 26 September 2019 (UTC)[reply]

I made a similar suggestion for someone who wanted to move the third column for Timeless down the way; making it a subpage of WP:Skin or WP:Customization would be great. --Izno (talk) 20:00, 26 September 2019 (UTC)[reply]

One of the very jarring thing about the warning is its non-standard size. It should be {{fmbox}} or {{ombox}} size. Something like

This is only a preview; your changes have not yet been saved! Go to the editing area to save them with Publish changes.

or

This is only a preview; your changes have not yet been saved! Go to the editing area to save them with Publish changes.

would be much better IMO. Headbomb {t · c · p · b} 14:58, 20 September 2019 (UTC)[reply]

I added

.previewnote .warningbox {border: none; padding: 0; margin: 0; background-color: white;}

and that put it back the way it was, I think. Maybe it should be a preferences option. Aymatth2 (talk) 15:08, 20 September 2019 (UTC)[reply]

Agreed. I thought it was some bug from last night, but it's still there now. At least there's a workaround. Thanks again to all the tech coders out there! Lugnuts ^{Fire Walk with Me} 17:01, 20 September 2019 (UTC)[reply]

My personal choice here would be {display:none}, as usual.

Unfortunately, all these {display:none}'s don't bring back the lost performance, especially with this case that turned my 1Ghz CPU into a toaster. It's a real pity that MW becomes a bloatware, and worse yet, that the devs just won't listen. — Mike Novikoff 21:21, 22 September 2019 (UTC)[reply]

Above discussed change does not negatively affect the performance at all. It has actually reduced CSS code sent to all users by using the standard warning box and not a specific override for solely the previewnote – regardless if the users are editing the page or not. Volker E. (WMF) (talk) 06:46, 3 October 2019 (UTC)[reply]

But my 1Ghz CPU is already a toaster when it comes to a page history or user contributions. You know, I have an indigestion every time I even hear of Phab since the last time I've cried in despair and had got nothing but a warning (isn't that an ad hominem?). Everything else just confirms the pattern. — Mike Novikoff 13:07, 4 October 2019 (UTC)[reply]

Tech News: 2019-40

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

Problems

Last week's Tech News had delivery problems. Some did not get the newsletter. Some got it more than one time. The problem where some pages got it three times should now be fixed. [1]

Changes later this week

The new version of MediaWiki will be on test wikis and MediaWiki.org from 1 October. It will be on non-Wikipedia wikis and some Wikipedias from 2 October. It will be on all wikis from 3 October (calendar).

Meetings

You can join the technical advice meeting on IRC. During the meeting, volunteer developers can ask for advice. The meeting will be on 2 October at 15:00 (UTC). See how to join.

Future changes

The Wikimedia Foundation Community Tech team is working on a watchlist expiry feature. This means you can put things on your watchlist for a period of time instead of forever. They are looking for feedback on the questions they have.
Special:Contributions will get the standard OOUI look. This makes it easier to use on mobile and makes it look like other Special: pages. There is a script you can use to make the form smaller if you want to. [2]

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

16:49, 30 September 2019 (UTC)

Quick heads up: It appears that on WP:THURSDAY there might be some CSS that needs tweaking. People who understand CSS might be able to divine the situation by looking at this edit. You can test this at MediaWiki.org now, as it's already Thursday there. ;-) Whatamidoing (WMF) (talk) 20:59, 2 October 2019 (UTC)[reply]

Weird ref, citation, white space interaction bug

Without the line feed the citation is messed up.

^[1]

^[2]

AManWithNoPlan (talk) 23:22, 30 September 2019 (UTC)[reply]

@AManWithNoPlan: Shouldn't it be:

^[3]

I was under the impression we shouldn't be using wikimarkup inside CS1 parameters. --RexxS (talk) 23:56, 30 September 2019 (UTC)[reply]

Something is going wrong. People expect to be able to have quote marks and apostrophes . AManWithNoPlan (talk) 00:12, 1 October 2019 (UTC)[reply]

You have unbalanced markup. The parser doesn't know that you want an actual apostrophe. Use {{'}} for the apostrophe whenever you are writing the possessive of an italicized name, like this:^[4] – Jonesey95 (talk) 01:53, 1 October 2019 (UTC)[reply]

Jonesey is correct here. The other way to do it of course is to take the lone apostrophe and use the reference value for it instead. --Izno (talk) 02:05, 1 October 2019 (UTC)[reply]

Alas, Editor Jonesey95 is not correct here. The template {{'}} renders as this:

<span class="nowrap" style="padding-left:0.1em;">&#39;</span>

All of that styling is why that template is marked as not safe for COinS.

—Trappist the monk (talk) 12:11, 1 October 2019 (UTC)[reply]

Rexx, generally. Some wikimarkup is supported in certain parameters. --Izno (talk) 02:06, 1 October 2019 (UTC)[reply]

Still odd that a line feed mattered. AManWithNoPlan (talk) 02:20, 1 October 2019 (UTC)[reply]

Just to prove that this isn't some artifact produced by Module:Citation/CS1, this <ref>''30 Rock'''s.</ref>^[5] gives the same result. Here is the html from this page:

<li id="cite_note-5"><span class="mw-cite-backlink">'<i><a href="#cite_ref-5">^</a><b></b></i></span><i><b> <span class="reference-text"></span></b></i><b>30 Rock</b>s.</li>

And using ' <ref>''30 Rock'''s.</ref>^[6] and its html:

<li id="cite_note-6"><span class="mw-cite-backlink"><b><a href="#cite_ref-6">^</a></b></span> <span class="reference-text"><i>30 Rock</i>&#39;s.</span></li>

—Trappist the monk (talk) 12:11, 1 October 2019 (UTC)[reply]

The reason the newline matters is because the Cite extension displays the reference wikitext by substituting it into MediaWiki:Cite references link one. The resulting wikitext resembles '''foo''' ''bar'''s that happens to be interpreted in an unexpected manner. Including the newline puts a newline in that wikitext, and since apostrophe markup only works within a single line there's no ambiguity. Fixes might include replacing the ''' in MediaWiki:Cite references link one with ... or ... or formatting the citation with ... to avoid the misinterpretation of apostrophe-wikitext. In the former case MediaWiki:Cite references link many format might also want a similar edit. Anomie ⚔ 12:32, 1 October 2019 (UTC)[reply]

So, ref-tags don’t work perfectly, but how to fix them is the question with some suggesting adapting cite templates to work around the bug In most cases. AManWithNoPlan (talk) 02:17, 7 October 2019 (UTC)[reply]

References

'^ "30 Rocks".
^ "30 Rock's".
^ "30 Rock's".
^ "30 Rock's".
'^ 30 Rocks.
^ 30 Rock's.

Special:Blocklist

Tracked in Phabricator
Task T56458

[3]

This link goes to Special:Blocklist with "Hide temporary blocks" and "Hide account blocks" ticked, while "Hide indefinite blocks", "Hide single IP blocks", and "Hide range blocks" are not ticked. Based on "hide account blocks", I would assume that the results would be restricted to individual IPs and IP rangeblocks. So why are some accounts showing up? User:Jstxanothrxstory, User:Clumsybrunnette05, and User:Sam sung are three of the accounts showing up here. Nyttend (talk) 03:39, 1 October 2019 (UTC)[reply]

It looks like they were all blocked between 17:23 and 20:26, on 11 July 2006, and they were all re-blocked by MZMcBride on 15 November 2008 with the message "per previous block; correcting database entry" ([4]). So there's probably something weird going on in the database there. MZMcBride, can you enlighten us? rchard2scout (talk) 11:27, 1 October 2019 (UTC)[reply]

Hi! I don't remember these blocks. I imagine if you query the database directly and look at the output, there might be a hint as to why these accounts are showing up when "Hide account blocks" is enabled. --MZMcBride (talk) 01:01, 3 October 2019 (UTC)[reply]

sandbox issue

Hello, Really like the sandbox and use it a lot. I cleared out an article I had posted and started a new one. Started a fresh page and new infox box using a template cut and pasted directly from the help pages. When I previewed it, just a straight line of all the text I had entered displayed but no actual inbox. Tried with different templates, still no real infobox, just a line of of the text I had entered. Cleaned my caches, ran anti-malware. Then went through all the how to fix it steps listed in the infobox help article, it still would not display correctly. Then cleaned my computer caches, registries etc, even reloaded the browser. Then purged the sandbox as per help page. Put up a test template in, saved it, it still will not display, nada, not even the line of text entered in the test infobox, which it did before. The editing area is there but when I preview it there is nothing but a box to the right that says "my name/sandbox." I use the firefox browser. Help pages said ad blocker could be the cause. I use ublock origin and have it turned off on Wiki. Have never had a problem with the same setup before. Just reloaded both. Still have the issue with same configuration that I had no problem with until now.

Would appreciate some help with this. Have spent a lot of time on it and do not understand why it is not working. Thank you. Ogmany (talk) 13:10, 1 October 2019 (UTC)[reply]

Hi @Ogmany: - I assume you're referring to User:Ogmany/sandbox? It looks like you've added an Infobox artist, but haven't filled it out with any data. Could you make and save the edit you previewed that was displaying your text in a straight line? It's hard to help further without knowing more about the edit you were trying to make. Sam Walton (talk) 13:13, 1 October 2019 (UTC)[reply]

Hello Sam Walton,

Yes, User:Ogmany/sandbox. Since I purged the sandbox the infobox preview displaying the text (I entered in the infobox template) as only a straight line of text, each info box separated by |, don't show up anymore. It looked like "name entered | birth place entered | each section I entered | etc |" as I recall. I did add Infobox artist, and filled out a test name and website. The editing area is there, can see that, but when I preview it there is no preview box even, no text I had entered, nothing but a small box to the right with "ogmany/sandbox" in it. Would show you a photo but will have to do that later today. Ogmany (talk) 13:40, 1 October 2019 (UTC)[reply]

Check your Preferences → Editing, under preview as there's an option to display the preview at the bottommost area. Also please upload screenshot. – Ammarpad (talk) 13:48, 1 October 2019 (UTC)[reply]

@Ogmany: In [5] you added the name and website inside . Those indicate source comments for editors viewing the source. Anything inside them are ignored when the page is rendered. See more at Help:Wikitext#Invisible text (comments). If a page displays your template code like it looks in the source then it's usually due to unclosed tags. Maybe a starting {{ is missing the ending }}, or a [[ is missing a ]] in one of the parameters. PrimeHunter (talk) 13:56, 1 October 2019 (UTC)[reply]

Sam Walton and PrimeHunter Very helpful. Adding the name inside the code was the problem. Small and obvious detail that I totally missed. Yikes! Appreciate the help and thank you.Ogmany (talk) 15:09, 2 October 2019 (UTC)[reply]

creating a rankings page from a website

Hello! I've been putting it off for quite a while, but I feel I need to find a way to do this soon. Here's what I'd like to do:

Currently, there are a few different ranking lists for pool players, such as the WPA and Eurotour rankings. There is a similar list for snooker players such as at Snooker world rankings 2019/2020.

What I'd like is to be able to have a way to update infoboxes (such as Template:Infobox pool player/rankings, similar to how Template:Infobox snooker player/rankings works. However, these are updated with a quick copy/paste for the snooker version, which doesn't seem possible with the above ranking lists. I'd also like to be able to update a potential article for each ranking list for the rankings after each event. The main issue (other than importing), seems to be the sheer amount of article names that are different from the name given. They tend to use lastname, firstname, rather than how our articles work.

I'd really like a reasonably quick and clean way to update the lists. Is there a way to go about doing this, or should I work around an existing solution? Please let me know if I need to provide more information. Best Wishes, Lee Vilenski ^{(talk • contribs)} 16:13, 1 October 2019 (UTC)[reply]

For reference, I've written Draft:Euro Tour rankings from excel2wiki to this version, and put together a script (with a lot of help) to fix the names. I'd really like to have some help in fixing the look of this table, and the infobox issues. Thank you in advance. Best Wishes, Lee Vilenski ^{(talk • contribs)} 18:58, 2 October 2019 (UTC)[reply]

Webcitation

Webcitation is one of the main recommended in the Help:Archiving a source for archiving links. But now a lot (all?) of pages with non-Latin text are shown with a Specials (Unicode block)#Replacement character. For example [6] . Is the site is finally dying аnd no longer reliable? Can someone contact them to fix it? --Sunpriat (talk) 00:43, 2 October 2019 (UTC)[reply]

As of July 14, 2019 this WebCite does not accept any new archive requests; historically archived pages can still be accessed but this service cannot be used to make any new archives. AManWithNoPlan (talk) 21:14, 5 October 2019 (UTC)[reply]

Possible interaction of spam blacklist and citation archival-url

Moved from MediaWiki talk:Spam-blacklist § adult-mag.com

Note: see prior discussion for additional context, about an url recently added to the WP:BLACKLIST.

Note: a parallel discussion is taking place at Help talk:Citation Style 1 about aspects relating more to the citation template aspects of this. Mathglot (talk) 02:48, 5 October 2019 (UTC)[reply]

JzG, I'm going through them, fixing them up. The fixes to the ones in citations are going smoothly. However, I triggered the filter, attempting to change the External link in Juliet Escoria from its current value, to the following value:

[https://web.archive.org/web/20160501095135/http://adult-mag.com/interview-juliet-escoria-katherine-faw-morris/ Interview with Catherine Faw Morris at ''Adult Magazine'']

Maybe the filter could be adjusted to excuse examples where it's embedded in a web archive url? Or should I code this valid archive link differently, so it can be saved? Mathglot (talk) 03:16, 3 October 2019 (UTC)[reply]

Hm, this time (at Azar Swan) I couldn't save the page after marking url-status usurped and adding this archive url:

|archive-url=https://web.archive.org/web/20160219163119/http://adult-mag.com/mornings-after-zohra-atash-azar-swan/

I ended up putting the archive-url in hidden text in order to be able to save it (rev 919328779), and it went through okay. The problem now, is that there is a live, blacklisted url in Citation 8 (this link is safe to click) in this article. This seems to be two problems, possibly interacting with each other:

not sure how this got past the filter
shouldn't |url-status=usurped have blocked display of this url, irrespective whether it is a spammy url or not?

Adding user Trappist the monk (talk · contribs) for comments on question 2 above. Mathglot (talk) 03:39, 3 October 2019 (UTC)[reply]

Aha, they are interacting. The doc for url-status says: "url-status: this optional parameter is ignored if archive-url is not set." SInce I had to put it in hidden text to successfully save because of the edit filter, that disables the effect of url-status. Now what? How do I fix this? Mathglot (talk) 03:47, 3 October 2019 (UTC)[reply]

I can envisage several possible solutions:

Move the url value out of the archive-url field and directly into the url field, but that might require some explanation in hidden text or something to prevent well-meaning editors from attempting to move it back to the archive-url field.
Leave the value in the archive-url field, and use the required url field to point to something else; perhaps the entry in the WP:BLACKLIST that covers it, or the discussion on the talk page about it. This seems more like a work-around, though.
Allow usurped for citation parameter url-status to block display of the spammy url in the url field, even with no archive-url
Add a new value for url-status that would block display, even with no archive-url.

Thoughts? Whatever the solution turns out to be, we should document it somewhere for users bumping up against this. Mathglot (talk) 04:14, 3 October 2019 (UTC)[reply]

Discussion moved here from prior location because it possibly affects more than one area. Mathglot (talk) 04:24, 3 October 2019 (UTC)[reply]

I've fixed it in this case by url-encoding the archive url: Diff/919328779/919369896. That's probably the correct option in most cases, but I do think that if url-status is usurped or unfit, the original url should be hidden, whether archive-url is set or not. rchard2scout (talk) 10:38, 3 October 2019 (UTC)[reply]

|url-status= and its predecessor |dead-url= both require |archive-url=. It is a misuse of a template to set one and not the other. --Izno (talk) 15:09, 3 October 2019 (UTC)[reply]

Not quite true, I think. While Module:Citation/CS1 ignores |url-status= when |archive-url= is omitted or empty, that is not the same as a requirement; were it a requirement, then we'd have to invent a new error message for that case. As it is, a stand-alone |url-status= is just clutter which is a different kind of problem ...

I have been experimenting in Module:Citation/CS1/sandbox (not saved yet) looking at how to handle the various cases of a blacklisted url by percent-encoding the url in the archive-url as Editor Rchard2scout did with the example discussed here. I will discuss this at Help talk:Citation Style 1 when I have something to say.

—Trappist the monk (talk) 15:47, 3 October 2019 (UTC)[reply]

@Rchard2scout:, In a technical WP:TPO violation, I've reversed the order of the revisions in your diff above. Previously, it showed your revision, still the latest/current, on the left side of the diff, and the earlier revision on the right. I assume this was not your intention. If it was, feel free to revert, but in that case, please add an explanatory note to make this clear. Thanks, Mathglot (talk) 22:29, 3 October 2019 (UTC)[reply]

Trappist the monk: Archive URLs are not exempt for spam blacklists. In fact it's a requirement archive URLs have the full target URL so that the spam blacklist can pick them up. Circumventing this process is a no-no. We've had RfCs about this before. There is also a MediaWiki policy about not using url-shortening services which is essentially what this becomes when hiding the real URL from the filters, because url-shortening allows spammers and malicious actors to insert bad things into Wikipedia. I've seen this many times using WaybackMedic, people use archive URLs to add stuff they shouldn't be. -- GreenC 19:09, 3 October 2019 (UTC)[reply]

I don't doubt you but, point me to an RFC that discusses this?

If archive-urls are required to hold the complete original url, shouldn't cs1|2 be checking that and be emitting an error message? Is this requirement publicly documented anywhere? Certainly, this requirement, if it is a requirement should be documented wherever |archive-url= is documented, shouldn't it?

—Trappist the monk (talk) 19:18, 3 October 2019 (UTC)[reply]

Wikipedia_talk:Using_archive.is#RfC:_Should_we_use_short_or_long_format_URLs? -- IAbot and WaybackMedic have been expanding to long form for years (where possible). IABot in particular is relentless and will get to all archive URLs eventually. CS1|2 could add a warning. Wayaback has no short-form option and WebCite is no longer taking new archives and all their URLs are long-form already (presumably). The providers with known short-form are webcite, archive.today, perma.cc, freezepage, National Archives UK. Data at WP:WEBARCHIVES. -- GreenC 19:40, 3 October 2019 (UTC)[reply]

I don't read that RFC closure as a 'requirement' but the shortening point is taken, though I see this more as a possible masking than a shortening. I have rolled back the edit. Because there are bots that routinely lengthen short archive urls, and because editors at the RFC did not like the idea of an automated tool admonishing editors to use the long-form archive urls, I do not foresee adding that kind of error checking.

—Trappist the monk (talk) 22:40, 3 October 2019 (UTC)[reply]

Can we back up and take a 40,000 foot view for a second, to get some perspective about the locus of the problem? I think this may help inform the discussion. I see what's going on here, as a conflict between two desirable features:

Support Verifiability, by exposing to readers the url of a source that supports an assertion in an article.
Prevent the user from being exposed to ill effects, by clicking on an url that may contain malware.

I think the statement of the issue we are facing here is, how do we do both of these at the same time, when an url used to support the article (and maybe still does, in an archived version) but has been usurped by malware? A couple of corollary questions to consider:

Is it okay to reduce verifiaibility a little bit in this case, by suppressing display of the url (and archive url, if any) completely? I assume that the answer here is no, but perhaps not everyone agrees.
Is it okay to display the spammy url, if it is not hyperlinked? I tend to think not, as it still seems to violate the spirit of the spam filter, even if it is unclickable.

Are there other functional aspects we haven't considered? Airing out what ought to happen, and getting agreement here first, will help keep the discussion about how to find a solution more on track. When discussing functionality, are there other stakeholders who ought to be looped in, here? Adding xaosflux. Mathglot (talk) 23:10, 3 October 2019 (UTC)[reply]

If all sites on the blacklist were indeed malware, there would be no issue; but most are merely spammy sites, while some have been blacklisted for other reasons. Link removal involves not just the loss of verifiability, but potentially the permanent loss of the information cited, contrary to our mission. What ought to happen is that each instance is checked, and either replaced or whitelisted. Doing so requires knowledge of the subject and the original link. Hawkeye7 (discuss) 23:29, 3 October 2019 (UTC)[reply]

@Hawkeye7:, That would seem to imply that we need to retain the information somewhere, of what kind of nasty the items on the blacklist actually are, so that they could possibly be handled differently. Is that what you meant? (At least, in an ideal world; whether it's practical/feasible/priority is a separate issue.) Mathglot (talk) 23:36, 3 October 2019 (UTC)[reply]

Yes, that is what I mean. It should be recorded somewhere. Hawkeye7 (discuss) 03:26, 4 October 2019 (UTC)[reply]

A solution is remove the offending URL but retain a {{citation}}. Blacklists don't prevent citing only linking. However if something is blacklisted it would be advisable to find an alternative source. -- GreenC 00:33, 4 October 2019 (UTC)[reply]

If a citation provides other means to verify the material, the simplest approach is not to include the url. The problem appears when online verification is the only available option. Again, the simpler approach would be for the editor to find a non-blacklisted mirror. If there no such mirrors, and the editor believes that the material can not be verified otherwise, then the pre-infected archive copy could be used, after some procedure as below:

1. Filtering should alert the editor that the url is blacklisted

2. The citation editor could submit the "clean" archived url for whitelisting, to whoever maintains such lists

3. The option |url-status=whitelisted should be inserted in the template to inform other editors that the particular archived url has been vetted, even if the current version is unsuitable.

It is a cumbersome approach, but I believe it is viable. 72.43.99.138 (talk) 13:19, 4 October 2019 (UTC)[reply]

Hmm.. but we would still be providing a link to a blacklisted website (even if via an archive version). Sites are blacklisted for many reasons, vetting a URL can be a matter of opinion if it is safe/appropriate/clean etc.. requiring community consensus which gets messy to maintain. If the only concern is V, perhaps there can be an admin-maintained list that is not visible to non-admins and if a user wants to verify a URL they can contact an admin who can discretely provide the URL for V purposes only. There would be note in the citation where to request the URL. It might require the requesting user have a working email contact so not posted in the clear. -- GreenC 14:48, 4 October 2019 (UTC)[reply]

I don't think that such burden of verification should be placed on readers. A better option may be for the citing editor to re-archive the material @ Wikisource? An explanation of the material's origin, without any offensive links, could be included at Wikisource, not at the citation which would now be considered sanitized. 98.0.246.242 (talk) 17:06, 4 October 2019 (UTC)[reply]

The burden is always on the reader to verify. This burden is actually less then going to the library and checking out a book. Wikisource is for previously published public domain documents, like books and speeches. Also copyright restrictions. -- GreenC 17:16, 4 October 2019 (UTC)[reply]

Just a heads-up that there is a parallel discussion taking place at Help talk:Citation Style 1 about aspects relating primarily to the citation template aspects of this, which may overlap in part some of the discussion above. Mathglot (talk) 02:52, 5 October 2019 (UTC)[reply]

There seems to be an issue that the values usurped and unfit for param |url-status are not well-defined; at least, not everyone appears to agree what they mean. As part of settling how to handle the part of the problem related to the spam blacklist as raised here, it seems to me that the definitions of usurped, unfit, and possibly other values need to be agreed upon as a prerequisite. If we're not all talking about the same thing, then discussions of edge cases like this one concerning the blacklist will get hopelessly tangled.

Probably the discussion of those definitions should be handled at the Help CS1 discussion; wider input and more eyeballs would be helpful there for this case, and even for the broader question of what those param values mean, exclusive of any blacklist complications. In particular: if you see a citation, including an url-status that says it is usurped, what do you think that means? What should the citation do with that? Please jump in at that discussion, if you feel you can help. Thanks, Mathglot (talk) 23:55, 9 October 2019 (UTC)[reply]

User contributions changes

I see some recent changes to Special:Contributions which make it much less useful for me. The search form is now hidden under a "Search for contributions" toggle, which means an extra click for me to change search settings, but I can live with that. However, when I use a CIDR range (needs to be enabled in Preferences/Gadgets), which I do many times a day to find edits by related IPs after I encounter anon vandalism (e.g. I search for 1.2.0.0/16), the list of IP addresses with edits loads above the list of recent edits. The list of addresses is often very large, and takes many seconds to load, and during this time if I scroll down to the list of recent edits (limited only to the most 50 recent edits by default), the loading list above keeps jumping the screen so I can't do anything useful. Until a couple of days ago, the list of recent edits was above the list of IP addresses, so I could ignore the loading of the latter. Is there a way to toggle off the list of IP addresses? There is a "toggle all" option, but that's not what I want; it shows edits sorted by IP address, but I want edits for the range of IP addresses sorted by date, as already appears at the bottom of the window. Alternatively, can I force the list of IP addresses to be a fixed size, rather than expanding as new addresses are found.-gadfium 20:53, 3 October 2019 (UTC)[reply]

WP:ITSTHURSDAY and the latest round of OOUI "improvements"..... but the gadget stuff comes from MediaWiki:Gadget-contribsrange.js which hasn't really been maintained in a while. This should be able to get pushed down if someone wants to dig in to it. — xaosflux ^Talk 21:32, 3 October 2019 (UTC)[reply]

Isn't the search by IP range gadget entirely obsolete now? * Pppery * _{it has begun...} 21:45, 3 October 2019 (UTC)[reply]

@Pppery: the No per-IP sorting or date headings, or any bells and whistles. note on the top of that task description says it isn't really a full-replacement. — xaosflux ^Talk 22:23, 3 October 2019 (UTC)[reply]

But it does appear to offer what Gadfium was asking for, by simply not displaying any list of IP addresses. * Pppery * _{it has begun...} 22:25, 3 October 2019 (UTC)[reply]

Thanks, turning off the gadget gives me exactly what I want. Thanks Pppery.-gadfium 22:33, 3 October 2019 (UTC)[reply]

By the way, you can force the search interface to be shown by inserting this into Special:MyPage/common.css:

/* Quick hack to force the Search tab on [[Special:Contribs]] open. Credit: Volker E. (WMF) & Stwalkerster - [[m:Special:Permalink/19434096#Reverting the new "collapsed search interface" on Special:Contribs|Tech]] */ 
.mw-special-Contributions .oo-ui-fieldsetLayout-group.mw-collapsible-content { display: block !important; }
.mw-special-Contributions .oo-ui-fieldsetLayout-header { display: none !important; }

— regards, Revi 00:35, 4 October 2019 (UTC)[reply]

Thanks, that works for me, avoiding that extra click.

I'm most impressed with the speed and quality of the technical help I've been given here!-gadfium 03:05, 4 October 2019 (UTC)[reply]

So we're currently looking into additional changes from the feedback given here. One is implementing a “pin” to let the form stay expanded phab:T234569 (edited link; making above CSS hack obsolete), the second is a technical error, that affected the user autocomplete phab:T234510. Volker E. (WMF) (talk) 04:24, 4 October 2019 (UTC)[reply]

@Volker E. (WMF): That first ticket is unrelated. Can you double check your links? --Izno (talk) 11:30, 4 October 2019 (UTC)[reply]

I think he meant phab:T234569. – Ammarpad (talk) 11:40, 4 October 2019 (UTC)[reply]

Edited and fixed above, thanks @Izno: and @Ammarpad: Volker E. (WMF) (talk) 17:40, 4 October 2019 (UTC)[reply]

I have another bug related to these changes: at least on my system (Chrome 77.0.3865.90, Windows 10 v.who-knows) the shortened User: box is not long enough to display a full IPv6 address, which makes it very difficult to use. Can it be restored to its original length? Ivanvector (^Talk/_Edits) 14:07, 4 October 2019 (UTC)[reply]
@Ivanvector: I've tried on monobook, vector, and timeless - for each a ipv6 address (38 characters) is only taking up about half the box for me - what skin are you using, and how may characters are you fitting in the input box? — xaosflux ^Talk 17:30, 4 October 2019 (UTC)[reply]
I'm using vector, and was viewing the contributions page by clicking on an IP address so the box was pre-filled. When I click on this, I see "2601:681:8400:26A0:CD73:" and then the rest is cut off. Ivanvector (^Talk/_Edits) 18:10, 4 October 2019 (UTC)[reply]

Oh also my Windows display settings were set to zoom 125%. If I set that back to 100%, I see ... the same thing, but smaller. Ivanvector (^Talk/_Edits) 18:13, 4 October 2019 (UTC)[reply]
@Ivanvector: can you try in safemode to see if you still have this problem? I'm not having the problem as seen here: File:20191004-ooui-contrib-page.JPG. — xaosflux ^Talk 18:52, 4 October 2019 (UTC)[reply]
@Xaosflux: yep, that worked, I see the same as you with safemode on. If I remove the &safemode=1 I get the short box again. Ivanvector (^Talk/_Edits) 18:59, 4 October 2019 (UTC)[reply]
@Ivanvector: hmm - possibly one of your scripts or gadgets is in conflict, try turning off your manual implementation of MediaWiki:Gadget-markblocked.js in User:Ivanvector/vector.js? — xaosflux ^Talk 19:03, 4 October 2019 (UTC)[reply]
It appears this is actually due to Enterprisey's delsort.js (imported under his previous username) ~ Amory (u • t • c) 23:24, 4 October 2019 (UTC)[reply]
Hmm. I don't have delsort installed but I still see that behavior. I'll look into it. Enterprisey (talk!) 05:42, 5 October 2019 (UTC)[reply]
Enterprisey, it seems like the causative factor is mw.loader.load( 'mediawiki.ui.input'), specifically the input. ~ Amory (u • t • c) 10:44, 5 October 2019 (UTC)[reply]
@Enterprisey:, the rule .mw-ui-input-inline { display: inline-block; } added by User:Enterprisey/mw-ui-input.css (being used in cv-revdel and unblock-review scripts) is the culprit. SD0001 (talk) 11:12, 5 October 2019 (UTC)[reply]

And yeah, mw.loader.load('mediawiki.ui.input') is also causing the same issue. Bizarre, since this one is WMF-sponsored. Ping Volker E. (WMF). SD0001 (talk) 11:25, 5 October 2019 (UTC)[reply]
Ah. Fun. Well, Ivanvector, body.mw-special-Contributions .mw-ui-input-inline { display: block; } in your common.css should work. Enterprisey (talk!) 01:44, 6 October 2019 (UTC)[reply]
@SD0001: With the fix of phab:T234510 not only the autocomplete works again, the issues with user scripts should actually also disappear, as we've removed a leftover .mw-ui-input-inline class from this specific input. Rolling out this week, should be live on enwiki by Thursday. Volker E. (WMF) (talk) 01:40, 8 October 2019 (UTC)[reply]

I filed a task for this one at phab:T234733. --Izno (talk) 22:10, 5 October 2019 (UTC)[reply]
I dislike the new change but anyway the pin thing would help a lot - No one wants to have to click to expand the box every time they want to search a users contribs, Would prefer if it was expanded by default tbh. –Davey2010^Talk 17:23, 4 October 2019 (UTC)[reply]
Depends how you edit. Nearly every time I load Special:Contributions, it's from a user-specific link, so I rarely use the box and thus love the space gains. ~ Amory (u • t • c) 23:27, 4 October 2019 (UTC)[reply]

Wikidata-fueled graphs not visible?

When checking whether this recent change was an improvement or vandalism (it looks to be an improvement), I came across List of the busiest airports in France, which starts of with two graphs, which are Wikidata-fueled. Ignoring whether this is wanted or not for now, my problem is that they simply don't seem to work. Firefox 69.0.2 on Windows, all I get is a small placeholder image. Other articles like List of the busiest airports in Germany also use this kind of graph, but through a template: in this case I don't even get the placeholder image but solely an empty section.

Is this a problem on my side, or a general problem with these graphs? Fram (talk) 12:44, 4 October 2019 (UTC)[reply]

According to Phab:T226250 this has been broken for some time, so we probably want to replace those graphs for now. Sam Walton (talk) 12:47, 4 October 2019 (UTC)[reply]

Thanks. Perhaps best to remove these for now then, has been broken for more than three months now. I'll remove them from a few pages where I can easily find them, but these may well be used by other articles and templates as well of course. Fram (talk) 12:59, 4 October 2019 (UTC)[reply]

Notices vs Alerts

Why do we have distinct Alerts and Notices menus on the top line? They're both just, "things that need your attention", with no logical distinction that I can see of which things go in which menu. I'd rather save the screen real-estate and have them in a single menu. Perhaps there's a way to configure that which I haven't found yet?

Other minor point: is it just me, or does the Notices icon look more like a USB-B connector than a mailbox? -- RoySmith (talk) 15:33, 4 October 2019 (UTC)[reply]

What goes where is explained at Help:Notifications#Triggering_events. Basically, talk page messages, emails, mentions, and rights changes are alerts while thanks, reviews, and cross-wiki are notices. ~ Amory (u • t • c) 16:34, 4 October 2019 (UTC)[reply]

I personally see a distinction. Alerts are for communication, or things that directly affect your work (such as when your edit was reverted, user rights changes, etc.). Notices are editors thanking you, adding links to pages you created -- things that are interesting but don't necessarily need any follow-up. I'm not aware of a way to configure what types of notifications go where, but you can disable some of them at Special:Preferences#mw-prefsection-echo. — MusikAnimal ^talk 17:11, 4 October 2019 (UTC)[reply]

I've had a user script on the back burner for ages that combines the two. It's a bit tricky. (To everyone) feel free to poke me in a month or so if you really want this, since I'm a bit busy at the moment. Enterprisey (talk!) 06:23, 7 October 2019 (UTC)[reply]

does the Notices icon look more like a USB-B connector than a mailbox? lol, was that ever intended to look like a mailbox? SD0001 (talk) 18:19, 7 October 2019 (UTC)[reply]

It's an inbox, like people (used to?) have on their desks. ~ Amory (u • t • c) 21:39, 7 October 2019 (UTC)[reply]

Um, yeah, I wrote mailbox but meant inbox. In any case, I still think it looks like a USB-B connector. It's amazing how we're using representations of physical objects that haven't existing in decades to represent things in user interfaces. An icon of a floppy disk for save? When's the last time anybody saw a real floppy disk? -- RoySmith (talk) 22:56, 8 October 2019 (UTC)[reply]

Today, in my desk drawer. Anyway, it's not a USB connector, it's a TV set. --Redrose64 🌹 (talk) 23:12, 8 October 2019 (UTC)[reply]

RoySmith, Off-topic for sure, but hilariously this weekend a family member needed to get photos off of a CD. It took 3 calls to find someone with an optical drive. Growing up we used audio tape cassettes in the C64 for data storage. I feel old now. SQL ^{Query me!} 23:17, 8 October 2019 (UTC)[reply]

Yup. I had a TRS-80, with audio tape storage. And, I do still have a CD drive. I use it every once in a while to rip tracks off some old CDs to load up into iTunes. The kids at the gym are listening to who-knows-what, but I'm rocking to The Dead and CCR. -- RoySmith (talk) 23:47, 8 October 2019 (UTC)[reply]

Tacky color scheme for old revisions

Take a look at the top of any old revision - think this was a WP:THURSDAY interface improvement - anyone else think the pink in yellow is tacky looking though? — xaosflux ^Talk 23:46, 4 October 2019 (UTC)[reply]

phab:T232415. The yellow is due to (now) using .warningbox while the red is because we use {{fmbox}} at MediaWiki:Revision-info. ~ Amory (u • t • c) 00:09, 5 October 2019 (UTC)[reply]

We should remove the fmbox now. It would look better. – Ammarpad (talk) 00:15, 5 October 2019 (UTC)[reply]

Done by JJMC89. Still doesn't look great. I feel that the background colour ought to be red to draw attention to the fact that this isn't the current version of the page. SD0001 (talk) 11:29, 5 October 2019 (UTC)[reply]

MediaWiki:Revision-info-current also need attention.--Lam-ang (talk) 15:09, 5 October 2019 (UTC)[reply]

Did you mean Mediawiki:editingold? — xaosflux ^Talk 15:32, 5 October 2019 (UTC)[reply]

No. I took care of the one Lam-ang mentioned. Editingold doesn't currently cause me problems, but I'm using WTE2017. That said, it may in the future be one ofthe targets. --Izno (talk) 15:40, 5 October 2019 (UTC)[reply]

@Izno: this also gives pink-in-orange, however in visual editor the pink seems to be the only coloring (else it is just plain text on plain background) so it may be worth keeping - or perhaps changing to the same coloring as the orange.. — xaosflux ^Talk 15:44, 5 October 2019 (UTC)[reply]

Probably just means that VE hasn't been updated. Let's go ahead and remove editingold also. --Izno (talk) 15:49, 5 October 2019 (UTC)[reply]

I don't use VE but the pink isn't dark enough to get a person's attention.— Vchimpanzee • talk • contributions • 15:46, 7 October 2019 (UTC)[reply]

Changes for 2020 (upcoming) Community Wishlist Survey

The Wikimedia Foundation recently announced two major changes to this year's Community Wishlist Survey. I haven't seen it spread widely on-wiki, so I'm posting it here. The Community Tech team will only work on the 5 most popular requests, not the top 10. They will also not consider any proposals from Wikipedia projects. The announcement was on wikitech-l and other mailing lists. You can find more information at meta:Community Wishlist Survey 2020 and discuss the changes at meta:Talk:Community Wishlist Survey 2020. --AntiCompositeNumber (talk) 02:30, 5 October 2019 (UTC)[reply]

Cursor position wrong at Special:Search on Google Chrome

Tracked in Phabricator
Task T234170

Based on this post at wp:AN, the cursor position on Special:Search is weird. To reproduce, type some text in the box, then try to click in the box, and see the cursor is several characters to the right of where you clicked. I am using Chrome, Windows 10. User:Nixinova reported IE and Edge working as expected. Chris857 (talk) 04:48, 5 October 2019 (UTC)[reply]

There's phab:T234170, given in the AN thread. – Ammarpad (talk) 14:30, 5 October 2019 (UTC)[reply]

Page categorisation

Is there a problem with page categorisations as I have had no entries on my watchlist for the last couple of days yet there are new/removed entries in the category Category:CS1 errors: dates that should have appeared? Keith D (talk) 10:17, 5 October 2019 (UTC)[reply]

It works for me. Is "Hide categorization of pages" disabled at Special:Preferences#mw-prefsection-watchlist? Is Category:CS1 errors: dates on your watchlist? You have to watch the category page and not just the articles. PrimeHunter (talk) 12:17, 5 October 2019 (UTC)[reply]

No it is not disabled and the category is on the watchlist. It is also not hidden on the selection screen for the watchlist. It was OK until about Thursday when it stopped giving the category changes. Keith D (talk) 18:19, 5 October 2019 (UTC)[reply]

I'm not sure what you mean by "not disabled" but the option "Hide categorization of pages" should be disabled, i.e. have no check mark. It's enabled by default. PrimeHunter (talk) 19:40, 5 October 2019 (UTC)[reply]

There is no check mark in the box. Keith D (talk) 20:25, 5 October 2019 (UTC)[reply]

Do you see categorizations at [7]? I see many when watching Category:CS1 errors: dates. Try to remove and readd the category to the watchlist. Do other categories like Category:Candidates for speedy deletion‎ fail to produce results? PrimeHunter (talk) 09:05, 6 October 2019 (UTC)[reply]

Yes I can see the categorisations using the link that you specified. It is all categorisations that I am missing from my normal watchlist entries such as Category:Start-Class Yorkshire articles‎. Keith D (talk) 18:31, 6 October 2019 (UTC)[reply]

Many thanks for the help I have just spotted what the problem is with the link you gave. I appear to have only got the (Main) namespace selected, for some reason, rather than All which it usually is. Back to normal now. Keith D (talk) 18:58, 6 October 2019 (UTC)[reply]

Global watchlist - Update 1

Updates associated with DannyS712's Global watchlist script:

General announcements

Management has migrated to phabricator; to report a bug or request a feature, please create a new task with the script's tag
Message translation has been reduced; for common messages that are already translated in mediawiki core, the system translations are used, in order to reduce duplication of efforts

Recent additions

New pages are shown at the start of a site's feed
Log entries are shown at the end of a site's feed
Basic validation has been added to user settings, applied before saving
Site validation has also been added; a site (excluding unique projects like wikidata, meta, commons, etc.) is considered to be valid if it is the form of "language.project", where both the language code and project name are valid. It does not, however, check that the actual site is valid; only that it could be. In other words, even though sco.wiktionary refers to a site that doesn't exist, it is considered valid, because sco is a valid language code (sco.wikipedia is a working site) and wiktionary is a valid project.

Announcements

BREAKING CHANGE: Backwards compatibility supporting the use of sites as *.*.org (like 'en.wikipedia.org' or 'meta.wikimedia.org'), deprecated in version 1.7.5, will be removed soon; all sites should now be saved as *.* (like 'de.wikinews' or 'fr.wikisource')
BREAKING CHANGE: Storing user sites as window.GlobalWatchlistSites, deprecated in version version 1.11.11, will be removed soon; all settings should be stored in the window.GlobalWatchlistConfig object
Both of these breaking changes will be implemented alongside version 4.0; until then, any use of the config page (m:Special:BlankPage/GlobalWatchlistConfig) will result in saving settings in the newest format

Next release

Version 4.0 should be released in around a week. It will include the new features mentioned above, as well as removal of backwards compatibility for settings and sites.

I've sent this first message to users that participated in the discussion at m:Community Wishlist Survey 2019/Watchlists/Revive Crosswatch tool or otherwise shown interest in the script. To subscribe or unsubscribe from future updates, see the distribution list.

Thanks, --DannyS712 (talk) 16:03, 5 October 2019 (UTC)[reply]

Global watchlist user script: About • Updates • Code

Deletion of file

I have uploaded a file, that is not fit for the intended use, and I want to delete it, but I don't know how. (Man, that was a long sentence – and please understand, that English isn't my first language.)

Anyways, I'd like to ask, if someone could help me deleting the file. https://en.wikipedia.org/wiki/File:Logo_for_the_2019_snooker_Champion_of_Champions.png

Cheers, Mrloop (talk) 17:40, 5 October 2019 (UTC)[reply]

Mrloop, I have requested speedy deletion for you per criteria G7. --Trialpears (talk) 17:45, 5 October 2019 (UTC)[reply]

Thanks :-) Mrloop (talk) 17:54, 5 October 2019 (UTC)[reply]

Deleted — xaosflux ^Talk 18:01, 5 October 2019 (UTC)[reply]

Thanks 👍 Mrloop (talk) 21:01, 5 October 2019 (UTC)[reply]

span data-segmentid="59" class="cx-segment"???

In Draft:Jaime Macías Alarcón, there's some very strange markup with every paragraph wrapped in . My two guesses are some weird Visual Editor bug, or (more likely) somebody copy-pasted this from somewhere and the HTML markup came along for the ride. Earwig doesn't show any copyvio matches, and googling for bits of text from the draft draws a blank as well. Anybody seen this before? -- RoySmith (talk) 22:09, 5 October 2019 (UTC)[reply]

@RoySmith: got a feeling it is a remnant from a translation tool. — xaosflux ^Talk 23:01, 5 October 2019 (UTC)[reply]

And looks like that user has been doing various things related to translation. — xaosflux ^Talk 23:03, 5 October 2019 (UTC)[reply]

And have been trying over and over in different ways. — xaosflux ^Talk 23:05, 5 October 2019 (UTC)[reply]

(edit conflict) It was caused by mw:CX when attempting to restore translation. The problem was fixed sometimes ago (after that draft's creation date). – Ammarpad (talk) 23:13, 5 October 2019 (UTC)[reply]

OK, thanks everybody. I think I'm going to copy the source to my unix box and clean it up with some emacs magic. -- RoySmith (talk) 23:25, 5 October 2019 (UTC)[reply]

Possibly related: T218420, T213258, T111000, T90202. – Jonesey95 (talk) 00:26, 6 October 2019 (UTC)[reply]

Transclusion count

I'm sure it's been asked before, but I can't find it: is there an easier way to count the transclusions of a template than using the "what links here" page and counting how many pages? Circéus (talk) 02:05, 6 October 2019 (UTC)[reply]

There is a "Transclusion count" link in the "External tools" section of Special:WhatLinksHere when given a template as an argument. * Pppery * _{it has begun...} 02:19, 6 October 2019 (UTC)[reply]

You can also add this script mw.loader.load('//www.wikidata.org/w/index.php?title=MediaWiki:Linkscount.js&action=raw&ctype=text/javascript'); which lets you count without leaving "what links here" page and is more flexible with namespaces, etc. SD0001 (talk) 05:14, 6 October 2019 (UTC)[reply]

You can also use Help:Searching#hastemplate: and see the reported number of search results. It can be combined with other search strings and search options, e.g. the namespace (only mainspace by default). PrimeHunter (talk) 08:47, 6 October 2019 (UTC)[reply]

Such searches are particularly useful because you can search for uses of the template with a particular parameter (e.g. here. Jts1882 | talk 09:28, 6 October 2019 (UTC)[reply]

(You don't need to place the spaces internal to the metacharacters you have; this is also correct. --Izno (talk) 13:57, 6 October 2019 (UTC))[reply]

For templates with over 2,000 transclusions, there are weekly lists generated at Special:PrefixIndex/Module:Transclusion_count/data/. --Ahecht (TALK
PAGE) 18:04, 6 October 2019 (UTC)[reply]

Codebox

Please see the idea discussed at Template talk:CodeBox#External links. I *think* it's about code, and then giving an external link to show what it does, but I'm not entirely sure. This might be good, or there might be an even better way to accomplish the desired goal. WhatamIdoing (talk) 00:01, 7 October 2019 (UTC)[reply]

I think the issue here is more about policy. Runnable code snippets are popular on many Q&A, how-to and programming sites; but Wikipedia is not a how-to website. Also when you combine that with the external link issues, for instance questions about the site itself (https://tio.run), and the fact that this will have to be embedded in the middle of articles; it will become clear this is something unlikely to be allowed on Wikipedia. But creating the template is one thing; starting to use on articles (with or without consensus) is another thing. Currently its only use on mainspace is on Lua (programming language) and it was added by the author. – Ammarpad (talk) 06:06, 7 October 2019 (UTC)[reply]

I've reverted my change, due to general consensus appearing to be against it, and potentially it being against some rule I haven't heard of/noticed yet (Would appreciate pointers to what I violated, I realise now that I violated WP:NOTHOWTO and WP:ELNO. MoonyTheDwarf (Braden N.) (talk) 12:47, 7 October 2019 (UTC)[reply]

VE cut & paste

Tracked in Phabricator
Task T234489

doesn't see to be working. Is this affecting anyone else? ——SerialNumber54129 11:57, 7 October 2019 (UTC)[reply]

It's a part of many issues: phab:T234489. – Ammarpad (talk) 12:15, 7 October 2019 (UTC)[reply]

Ah, thanks very much Ammarpad, well that's too rich for me. Any idea, though, how long that kind of thing takes to sort out? (It's just that I've read the phab ticket but I'd have more luck with Cantonese!) Thanks again, ——SerialNumber54129 12:22, 7 October 2019 (UTC)[reply]

@Serial Number 54129: The short version is it looks like a fix was uploaded yesterday by @DChan (WMF): that's currently awaiting review. Hopefully they can shine some light on how long these things usually take to go live. Sam Walton (talk) 12:30, 7 October 2019 (UTC)[reply]

The task was triaged with the highest priority tag, so one can assume it will not take long to get fixed, all other things being equal. – Ammarpad (talk) 12:38, 7 October 2019 (UTC)[reply]

Thanks very much Sam Walton and Ammarpad, for the update, and a big Thank You to all the technical folk on this board who enable content creation by doing what they do and also take the time to explain things to plebs like me! Cheers! :) ——SerialNumber54129 12:44, 7 October 2019 (UTC)[reply]

Is this the same issue that messes up the ref numbering in VE? When I test-edit articles in VE, almost all of them have the refs in the ref section with a higher number than in the article, making it hard to see which ref belongs with which number of course... Here the refs in the ref section are numbered 17 to 27, here 4 to 10, here 4 to 15, here 5 to 89; here the only reference is numbered "6"! Fram (talk) 12:45, 7 October 2019 (UTC)[reply]

I don't believe so, that looks to be T95176. Sam Walton (talk) 12:50, 7 October 2019 (UTC)[reply]

Thanks. Ouch, that's a task from 2015... Fram (talk) 14:04, 7 October 2019 (UTC)[reply]

Resolved

{coord} location doesn't match Google Map location

This may be a known problem or a non-problem but, having noticed it, I thought I would mention it here.

Compare this Google Maps location with the 5°08′33″N 125°58′35″E / 5.1424303°N 125.9764215°E / 5.1424303; 125.9764215 location from {{coord}} and GeoHack->Google Maps. Maybe it's a rounding error or a cockpit problem on my part. Wtmitchell (talk) (earlier Boracay Bill) 14:23, 7 October 2019 (UTC)[reply]

@Wtmitchell: in your first example you seem to be using a "named location" on google.com ("Miangas") not only the geo-coordinates like this - does that give you the result you are looking for? — xaosflux ^Talk 14:58, 7 October 2019 (UTC)[reply]

Specifying the named location appears to drop a pin on the named location while centering the map on the coordinates (at least approximately). For a more extreme example, try 125.1424303,125.9764215, which uses the named location of "Miangas" but coordinates much farther away. The coordinates of Miangas appear to be closer to 5°33′19″N 126°35′07″E / 5.5554°N 126.5854°E. – Jonesey95 (talk) 16:05, 7 October 2019 (UTC)[reply]

@Xaosflux: it's not odd, it's expected: consider that a URL goes into the value of a href="..." attribute of an <a> tag, any unencoded quotes will terminate that value. Try percent-encoding it, like this, where %C2%B0→°, %27→' and %22→". --Redrose64 🌹 (talk) 20:43, 7 October 2019 (UTC)[reply]

@Redrose64: yea not really 'odd' but it is phab:T17661. — xaosflux ^Talk 20:55, 7 October 2019 (UTC)[reply]

Tech News: 2019-41

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

The abuse filter function now has a faster parser. This is to shorten the waiting time when you save an edit. [8]

Problems

There is a problem in the visual editor when you copy or delete text with footnotes. It will be fixed soon. [9]

Changes later this week

The new version of MediaWiki will be on test wikis and MediaWiki.org from 8 October. It will be on non-Wikipedia wikis and some Wikipedias from 9 October. It will be on all wikis from 10 October (calendar).

Meetings

You can join the technical advice meeting on IRC. During the meeting, volunteer developers can ask for advice. The meeting will be on 9 October at 15:00 (UTC). See how to join.

Future changes

The Community Wishlist Survey has a new format. It will focus on wikis that typically get less support. It will probably go back to the normal format next year. It is not decided exactly how it will work this year. You can leave feedback.
The URL of the Wikimedia wiki main pages could be changed. This is because the current URLs cause several problems. For example https://www.wikidata.org/wiki/Wikidata:Main_Page would be https://www.wikidata.org/ instead. You can tell the developers if this would cause problems for your wiki.
There is a new technical community newsletter. You can read more about the work of Wikimedia's technical community. Subscribe to get the information in the future.
Outreachy is an internship program for groups who are underrepresented in free and open-source software. There are seven Wikimedia projects about coding, documentation and quality assurance in the next round. Persons who fit the criteria can apply. The last day to apply is 5 November.

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

15:34, 7 October 2019 (UTC)

Search function has a URL with "cirrus"

Is this explained anywhere? — Vchimpanzee • talk • contributions • 15:44, 7 October 2019 (UTC)[reply]

@Vchimpanzee: see more at mw:Help:CirrusSearch. — xaosflux ^Talk 15:58, 7 October 2019 (UTC)[reply]

Thanks.— Vchimpanzee • talk • contributions • 16:02, 7 October 2019 (UTC)[reply]

Page views data prior to February 2008

I am working on a research project related to the traffic of Wikipedia platform. Could you please help me to find the page views data of the early days of Wikipedia? Ideally, I would like to find 2001-February 2008. I understand that the metrics were different from the current metrics. — Preceding unsigned comment added by Vika-Wiki (talk • contribs) 03:59, 8 October 2019 (UTC)[reply]

@Vika-Wiki: These dumps go back to December 2007, but there was not much pageview data before then. I believe there was page view data in the early days of Wikipedia but I have no idea how to get at it without maybe downloading old database dumps. Graham87 05:18, 9 October 2019 (UTC)[reply]

Reply link script

I am having problems with Enterprisey's reply link script. Please see Wikipedia:Help_desk#Reply_link_script and User talk:Þjarkur/sandbox for more info about the problem. I tried reaching to Enterprisey, but he didn't get back to me. It doesn't seem to work on some Wikipedia forums such as the WP:HD and WP:ANI and also my talk page. I get the error message "There was an error while replying! Please leave a note at the script's talk page with any errors in the browser console, if possible.". I tried replying at this page and I have no issues replying there. I am currently using a modified script at User:Þjarkur/reply-link.js Can you figure out what is going on there and how to fix these errors so that the script works on every Wikipedia page? Interstellarity (talk) 18:02, 8 October 2019 (UTC)[reply]

(edit conflict) For an explanation, Interstellarity is having some problems with reply-link but only with replying to certain posts. I could identify one error where it was not possible to reply to me due to the Unicode character in my username which was giving a "Failed to find a matching comment in the Parsoid DOM". Interstellarity says they still get an error from reply-link, but only on some pages including WP:ANI. My guess is that Parsoid has changed the markup it returns a little bit. Interstellarity, can you verify that the error you get is the same Parsoid DOM error as before? – Thjarkur (talk) 18:01, 8 October 2019 (UTC)[reply]

I just got an edit conflict. I have provided more info. Do you any more info regarding this post? Interstellarity (talk) 18:06, 8 October 2019 (UTC)[reply]

Yes, do you still get the same Parsoid DOM error or is there another console error message? – Thjarkur (talk) 18:08, 8 October 2019 (UTC)[reply]

Þjarkur, I got it to work at WP:VPT and WP:HD, but not my user talk page. Yes, I do get the error message you are talking about. Interstellarity (talk) 18:11, 8 October 2019 (UTC)[reply]

Any help would be appreciated. Interstellarity (talk) 19:58, 8 October 2019 (UTC)[reply]

Most people are frequently experiencing errors with reply-link, not just you. Alas, for now the only option is to manually edit the page whenever it doesn't work. It's an extremely complicated script and would need quite a bit of coding and testing by Enterprisey (or someone else) to run reliably across all pages. SD0001 (talk) 06:25, 9 October 2019 (UTC)[reply]

For me, it seems to work at both [ANI and at HD. Any specific comments you tried replying to where it didn't work? SD0001 (talk) 06:59, 9 October 2019 (UTC)[reply]

SD0001, Replying in both of those places worked for me too. It doesn't seem to work when replying to someone on my talk page. Interstellarity (talk) 10:50, 9 October 2019 (UTC)[reply]

One thing that I've noticed is that the generated edit summary sometimes implies that a user is replying to themselves (example). --Redrose64 🌹 (talk) 13:29, 9 October 2019 (UTC)[reply]

Redrose64, The edit summary isn't the problem. It is the functionality of the script that's the problem. Interstellarity (talk) 21:50, 9 October 2019 (UTC)[reply]

The website disappears for seconds then appears whenever I enter a page or refresh a page

So when I refresh or enter any Wikipedia page. The page appears then suddenly everything disappear for few seconds and then it appears. Anyone having the same issue? I am using mobile version.--SharabSalam (talk) 19:48, 8 October 2019 (UTC)[reply]

This is actually very annoying in large articles or pages like this.--SharabSalam (talk) 19:50, 8 October 2019 (UTC)[reply]

what mobile device and browser? My iPhone safari seems slightly problematic with newest OS. AManWithNoPlan (talk) 22:44, 8 October 2019 (UTC)[reply]

It happens in my laptop as well, when I switch to mobile version. I am using google chrome in both my mobile and my laptop.--SharabSalam (talk) 03:30, 9 October 2019 (UTC)[reply]

Remove the merge template

Please remove the Merger notice on {{Infobox Company}}. It is irritating to see it appearing on top of articles. If it cannot be removed, then please put a noinclude around it. Users need to read the caution notice before slapping notices on highly visible templates.

180.151.92.126 (talk) 10:07, 9 October 2019 (UTC)[reply]

This is not a technical issue, please follow up at Template talk:Infobox company. — xaosflux ^Talk 10:31, 9 October 2019 (UTC)[reply]

I really feel {{template for discussion}} should be wrapped in {{if preview}}. These notices are fairly confusing and sit prominently at the top of articles. – Thjarkur (talk) 10:45, 9 October 2019 (UTC)[reply]

TFD notices are generally reasonable. I've not really understood the complaints yet. --Izno (talk) 00:11, 10 October 2019 (UTC)[reply]

Wikipedia talk:Tags#Editor privacy

Unresolved

– Phabricator ticket opened by xaosflux (thank you!). –xeno^talk 15:58, 9 October 2019 (UTC)[reply]

Tracked in Phabricator
Task T235107

I'm concerned that some of the tags added to edits (presumably for debugging reasons) are violating the privacy of editors by disclosing the type or software characteristics of devices they are using to contribute. Please see Wikipedia talk:Tags#Editor privacy. –xeno^talk 13:35, 9 October 2019 (UTC)[reply]

I'm unhappy with this practice too. Thanks for raising this, xeno. ↠Pine (✉) 18:54, 9 October 2019 (UTC)[reply]

Is there a way to force a purge of PAGESINCATEGORY ?

{{PAGESINCATEGORY:Articles with redirect hatnotes needing review|pages}} is showing a higher count (6) than the actual number of pages in the category. Is there a way to force a purge of this counter to get it synched with the actual count again? wbm1058 (talk) 18:56, 9 October 2019 (UTC)[reply]

Pretty sure there are archived threads on this, also phab tickets. It's why the word "approximately" was added to the message "The following 200 pages are in this category, out of approximately 9,999 total". In short: it's a bug, they know, they've not fixed it yet. --Redrose64 🌹 (talk) 19:20, 9 October 2019 (UTC)[reply]

Oh, I see: Wikipedia:Village pump (technical)/Archive 46 § Incorrect counts from PAGESINCATEGORY function. (September 2008) – wbm1058 (talk) 19:42, 9 October 2019 (UTC)[reply]

But T15683, {{PAGESINCATEGORY}} sometimes returns a negative number, was closed in May 2008 after r34870, "if the number of pages (or subcats or media files) is negative on initialization, we just do a recount."

More recently, T16237, PAGESINCATEGORY should differentiate between pages and subcategories, was closed in 2012 after this update.

Added PAGESINCATEGORY: magic word in April 2008.

My phabricator search isn't finding any open bug report for the issue reported on Village Pump in September 2008. Is it possible that a formal bug report was never submitted for this? wbm1058 (talk) 11:26, 10 October 2019 (UTC)[reply]

@Wbm1058: to your specific question, it looks like phab:T85696, for the general problem it appears to have all rolled up in to phab:T221795. — xaosflux ^Talk 11:43, 10 October 2019 (UTC)[reply]

Newly deprecated cite parameters used by reFill

A previous message was left at User talk:Zhaofeng Li/reFill, but Zhaofeng Li does not appear to have been active on WP since July.

So |deadurl= and |dead-url= have been deprecated in {{cite web}} and its variants, in favor of |url-status=. However, I notice reFill 2, and probably regular reFill, are still generating |dead-url=, which in turn now generates an error message and adds the page to the maintenance category Category:CS1_errors: deprecated parameters. The operators of InternetArchiveBot and GreenC bot have made the fix there, is there anyone who can update reFill accordingly?. The particulars of the cite template update that applies here are listed at the maintenance category page (and also at Template:Cite_web#What's_new), but note that the "yes" or "no" values also need to be changed to "live", "dead", "unfit", or "usurped", as necessary. Thanks.— TAnthony^Talk 19:56, 9 October 2019 (UTC)[reply]

@TAnthony: This was reported at GitHub 3 days ago [10]. A look through User talk:Zhaofeng Li/reFill suggests bug reports to reFill have gone unresolved for at least the past 6 months, and many reports prior going back years unresolved. Zhaofeng Li reports they are "semi-retired" from Wikipedia as of July. It might be the tool lacks a maintainer and is running without an operator. If this is the case it might be reported to Wikipedia:Bots/Noticeboard and see what they say. It's a little different since it is a user-triggered tool with full oversight of edits by end user and might not be under the same rules as a bot, but IMO it should be. -- GreenC 21:16, 9 October 2019 (UTC)[reply]

Hi GreenC. You are correct in your observations about refill. On the other hand it should be noted that the tool was updated to "refill 2" sometime earlier this year. Also two or three days ago it was down for several hours and since it came back it is running much slower than it was previously. This makes me think someone is tinkering with it somewhere but I have no idea how to find out who or where this is happening. Is there any chance that something being done at another wiki is affecting things here? If anyone else knows what is going on please add that info here to help us understand what is happening. MarnetteD|Talk 21:44, 9 October 2019 (UTC)[reply]

MarnetteD, I'm looking through the source files on Toolforge where it runs (both versions) and see timestamps to a few files from around February 2019, most much older. Not unusual for outages due to hosting problems on Toolforge. I found a source file where |deadurl= is mentioned, looks like an easy fix, but can't modify it due to file permissions. For the record it is Toolforge: /data/project/refill/versions/stable/src/Reflinks/CitationGenerators/CiteTemplateGenerator.php -- GreenC 23:46, 9 October 2019 (UTC)[reply]

Thanks for the info GreenC. February sounds right for the change to "2". MarnetteD|Talk 01:00, 10 October 2019 (UTC)[reply]

Extreme difficulty loading pages

I'm using YouTube and Google no problems in Taipei, Taiwan. But when I try to load Wikimedia project pages, the page loads partially and then stops. If I refresh the page five to fifteen times, I can eventually make the full page load up. What is happening here? I can't get Phabricator to send a confirmation email to my email inbox, otherwise I wouldn't be asking here. Geographyinitiative (talk) 00:15, 10 October 2019 (UTC)[reply]

This problem has been going on since yesterday night (Oct 9 my time). Also, when I just made an edit, I got the message "Some parts of the edit form did not reach the servers; double-check that your edits are intact and try again." What is happening here? So bizarre! Geographyinitiative (talk) 00:31, 10 October 2019 (UTC)[reply]

The problem is ongoing. Again, I can use other websites normally, but Wikipedia pages require several refreshes. As I am writing this, the page is not fully displayed. Geographyinitiative (talk) 03:36, 10 October 2019 (UTC)[reply]

I'm not sure about having the same problem, but in my case it was browser dependent. IE had a problem and Chrome had not. FredTC (talk) 03:48, 10 October 2019 (UTC)[reply]

Good advice. I switched between browsers and the problem is basically gone (or at least greatly reduced). Geographyinitiative (talk) 04:00, 10 October 2019 (UTC)[reply]

I may have spoken too soon- the problem is still there in the second browser, but not as bad. What could explain this? ([11]). --Geographyinitiative (talk) 04:18, 10 October 2019 (UTC)])Geographyinitiative (talk) 04:14, 10 October 2019 (UTC)[reply]

Well, back at my laptop, I experience no more problems. So I think I had a different problem that occured at the same time your problems started. I guess at wikimedia they were experimenting with browser dependent code. --FredTC (talk) 07:26, 10 October 2019 (UTC)[reply]

Preserving my anonymity when not logged in

I have a question about how best to preserve my anonymity when not logged in. I have one solution in mind that would require IA help. But before I try WP:IANB, I thought I'd air the issue here first, to see if there may be a better/easier solution.

My goal is to avoid inavertently making changes when when not logged in, so I don't out my IP if I save something with a recognizable pattern. I imagine that one approach, is to somehow warn myself before hitting "Publish". I've taken a sort of mirror-image approach to this, via a change to my common.css, which turns my "Publish" button green when logged in, as suggested at the Help Desk in 2012. This doesn't warn me when I'm not logged in, but it (hopefully) will get me used to a green Publish button, so that when I'm not logged in and don't see it, my spidey sense will tingle. Only, I have a crappy spidey sense, so I don't think that will work. (At that same discussion, someone pointed to a "MediaWiki: Prevent anon editing script" that apparently works with Firefox—not my habitual browser—but in any case, that link is now dead.)

The idea I had for the solution, is to copy the code I have in my common.css, to [[User:<my-actual-ip-address>/common.css]], and change the color of the Publish button to red (and maybe also add a CSS ::before selector to generate added text "Are you sure?" right before the button as well). So, I was going to request an IA to add the common.css for me (after passing the IP via email, and checking with a CU, if necessary, to verify it's me). But that's rather costly in limited human resources, and it occurs to me that there might be an easier or better way. Is there? Mathglot (talk) 01:16, 10 October 2019 (UTC)[reply]

Not an answer to your specific question, but you might be interested in m:IP Editing: Privacy Enhancement and Abuse Mitigation. -- RoySmith (talk) 01:21, 10 October 2019 (UTC)[reply]

Being able to run scripts for the next user of any IP address you use would be a disaster waiting to happen. For this reason you need to be logged in to run customisations in your userspace on Wikipedia. The solution would be to host the CSS in your browser - there are probably many extensions/plugins/browsers capable of doing that. I personally use the green button thing, as well as some other UI changes when I'm logged in, and I find it actually kinda works. -- zzuuzz ^(talk) 01:22, 10 October 2019 (UTC)[reply]

This. Assuming you usually use the same browser, you can do tons of stuff, the page source has information such as the logged in user information - if it is not there you could just remove the button with local javascript. — xaosflux ^Talk 01:36, 10 October 2019 (UTC)[reply]

Custom JS and CSS are loaded only for logged-in editors. Any code in the js/css subpage of an IP address won't work. The solution to your problem, as mentioned above, is to deploy custom JS/CSS through your browser. SD0001 (talk) 07:01, 10 October 2019 (UTC)[reply]

@Mathglot: Your mirror-image approach is the "right" way to do this. It's what I do and while it might take a little bit, once you adjust, seeing a different color will be quite jarring. There are other things you can tweak too, for an even greater difference, and that's not even counting using a different skin or noticing your gadgets aren't loading. ~ Amory (u • t • c) 09:56, 10 October 2019 (UTC)[reply]

The dead script link is mirrored at https://userscripts-mirror.org/scripts/show/7209 with source code at https://userscripts-mirror.org/scripts/review/7209. You can ask for help at Wikipedia:Reference desk/Computing if you name your browser. PrimeHunter (talk) 12:10, 10 October 2019 (UTC)[reply]

Template "Whos Who" not working

Template:Who's Who has stopped generating the correct links, at least when the type = was is selected, returning a 404 error. DuncanHill (talk) 20:25, 10 October 2019 (UTC)[reply]

I have fixed it by simply ignoring type = was.[12] I couldn't make any save of the template, not even a null edit, until I removed transclusion of the documentation. All attempts failed with "Syntax error in JSON (help)". I never learned TemplateData syntax so I'm not trying to fix Template:Who's Who/doc. PrimeHunter (talk) 22:22, 10 October 2019 (UTC)[reply]

Thanks, the template hadn't been changed since it was working. DuncanHill (talk) 22:32, 10 October 2019 (UTC)[reply]

Page file size graph

Is there a tool that graphs the change to a page's file size over time? ―Mandruss ☎ 21:35, 10 October 2019 (UTC)[reply]

Read only maintenance window planned for ENWP at 14th Nov 05:00 AM UTC

See https://lists.wikimedia.org/pipermail/wikitech-l/2019-October/092653.html. ↠Pine (✉) 22:43, 10 October 2019 (UTC)[reply]

[1] '^ "30 Rocks".

[2] "30 Rock's".

[3] "30 Rock's".

[4] "30 Rock's".

[5] '^ 30 Rocks.

[6] 30 Rock's.

[1]

[2]

[3]

[4]

[5]

[6]

@@ Line 571: / Line 571: @@
 Is there a tool that graphs the change to a page's file size over time? &#8213;[[User:Mandruss|<span style="color:#775C57;">'''''Mandruss'''''</span>]]&nbsp;[[User talk:Mandruss|<span style="color:#888;">&#9742;</span>]] 21:35, 10 October 2019 (UTC)
+== Read only maintenance window planned for ENWP at 14th Nov 05:00 AM UTC ==
+See https://lists.wikimedia.org/pipermail/wikitech-l/2019-October/092653.html. [[User:Pine|<span style="text-shadow:#01796f 0.1em 0.1em 1.5em;color:#01796f">↠Pine]] </span>[[User talk:Pine|<font color="DeepSkyBlue"><b>(</b><span style="color:#FFD700;text-shadow:#FFD700 0.1em 0.1em 1.5em">✉</span><b>)</b></font>]] 22:43, 10 October 2019 (UTC)