Wikipedia:Village pump (technical)

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, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213

WikiProject notifications for sister-site activity

If a WikiProject wanted to monitor activity on sister-sites, is there a way to do that through a bot? For example, the Community bot posted a message on Talk:Chicago Freedom Movement stating an image has been nominated for deletion. Is there a bot or some other way for Wikipedia:WikiProject Civil Rights Movement to be notified? Mitchumch (talk) 02:52, 2 April 2019 (UTC)[reply]

This task is done for Wikipedia in general not for specific WikiProjects. If any article associated with Wikipedia:WikiProject Civil Rights Movement has a file on Commons which happens to be nominated for deletion, the talkpage of the article will receive notification. I think this is also only done for files on Commons not for any other sister projects. – Ammarpad (talk) 14:00, 2 April 2019 (UTC)[reply]

I understand your point. I'm trying to find a way for the WikiProject to be notified of this delete nomination. The project uses a variety of notification bots or services, but none of them registered the delete nomination. If there is a bot that performs this task, then I'm not aware of it. I was wondering if such a thing exists. Mitchumch (talk) 23:53, 2 April 2019 (UTC)[reply]

@MaxSem (WMF): Would this be a reasonable feature to add to Community Tech bot? {{3x|p}}ery (talk) 23:55, 2 April 2019 (UTC)[reply]

@Mitchumch: You should ask Headbomb for that. I think Alertbot does something like that. – Ammarpad (talk) 17:26, 9 April 2019 (UTC)[reply]

The place to raise it would be at WP:AALERTS/FR, and Hellknowz can let you know what's possible there. However, would be very challenging to implement. There was a highly endorsed proposal on the Community Wishlist in 2017 related to this, but the dev team gave up on things. Headbomb {t · c · p · b} 17:30, 9 April 2019 (UTC)[reply]

Going to ping TBolliger (WMF), Ryan Kaldari (WMF) and DannyH (WMF) here to see what can be done to revive this project, or know who we need to lobby/petition to get the WMF to dedicate resources to this. Headbomb {t · c · p · b} 17:36, 9 April 2019 (UTC)[reply]

(Trevor quit a few weeks ago, and Kaldari and DannyH are stuck in endless meetings about planning. mw:User:JMatazzoni (WMF) is probably the best contact for the Community Wishlist until the new fiscal year starts in July.) Whatamidoing (WMF) (talk) 16:47, 12 April 2019 (UTC)[reply]

Editing issues in mobile view

Tracked in Phabricator
Task T200969

Tracked in Phabricator
Task T191706

Hi all,

I had a look through the bug reports for wikipedia, but I'm not sure if this has been discussed (I'm sure it must have done), and I'm hoping someone could help me with how editing works on Android.

When searching through recent edits on the android chrome watchlist, clicking the link to the edit in question brings up the diff (as expected). However, if you wanted to edit the article yourself, clicking the article name brings up the indivdual edit of the page, and so attempting to edit the page only allows a view source, rather than editing. The only way to solve this is to click any blue links that occour on the page before (usually only shows when someone edits a particular section of an article/talk), or to go to the previous edit, and then the latest edit, which brings up the page itself.

Is this designed to work this way? I quite often check for updates to articles on my phone, and also make small edits this way. However, it's quite a faff to do the solution listed above to sort this out.

There's also no way to revert an edit on chrome. Is this also intentional, or am I missing a simple way to do so?

Many thanks for your time Best Wishes, Lee Vilenski ^{(talk • contribs)} 13:42, 29 March 2019 (UTC)[reply]

Seems like you asked at the right time. Phab:T200969 will hopefully address all the issues you listed. – Ammarpad (talk) 19:25, 2 April 2019 (UTC)[reply]

Doee Wikipedia:Village pump (technical)/Archive 172#What has happened to mobile viewing? help? Look for "Reader view". --Redrose64 🌹 (talk) 20:26, 2 April 2019 (UTC)[reply]

The above doesn't seem to be relevant. The tracked conversation above seems to cover it almost exactly Best Wishes, Lee Vilenski ^{(talk • contribs)} 08:03, 3 April 2019 (UTC)[reply]

Undo for mobile view is also being worked on, see phab:T191706.

For those who want undo ability in mobile view right now, there's a user script, see phab:T191706#4808483 (but I haven't tried it). --Pipetricker (talk) 19:39, 11 April 2019 (UTC)[reply]

Image format in PDF output

From this discussion it is my understanding that Incnis Mrsi is proposing to change $wgPdfOutputExtension configuration variable at this wiki to set the images output format to png in PDF output files. This results in higher quality images. Without this, the output is rendered very poorly and is difficult to read or share. Do we have consensus for such a change? --Gryllida (talk) 23:18, 2 April 2019 (UTC)[reply]

Images which aren't suitable for PNG... shouldn't be formatted as such. --Izno (talk) 00:25, 3 April 2019 (UTC)[reply]

Which ones are that? Gryllida (talk) 18:00, 3 April 2019 (UTC)[reply]

Anything which wasn't created to be a graphic. Most photography is more correctly JPGs than PNG, if we're talking a lossy format. --Izno (talk) 20:51, 3 April 2019 (UTC)[reply]

On the contrary, I think that if you compare the rendering in 'this discussion' linked above, you will see low quality jpeg rendering. Gryllida (talk) 19:52, 6 April 2019 (UTC)[reply]

@Gryllida: en.Wikipedian people don’t easily get the meaning of “PDF” in this context (not surprisingly, given that its presence in Wikipedia articles is marginal) and confuse it with PNG. Here’s not Phabricator nor even Wikimedia Commons; be careful next time, please, to check that your vis-à-vis gets what do you tell properly. 18:24, 10 April 2019 (UTC) — Preceding unsigned comment added by Incnis Mrsi (talk • contribs) [reply]

URL shortener for the Wikimedia projects will be available on April 11th

Hello all,

Having a service providing short links exclusively for the Wikimedia projects is a community request that came up regularly on Phabricator or in community discussions.

After a common work of developers from the Wikimedia Foundation and Wikimedia Germany, we are now able to provide such a feature, it will be enabled on April 11th on Meta.

What is the URL Shortener doing?

The Wikimedia URL Shortener is a feature that allows you to create short URLs for any page on projects hosted by the Wikimedia Foundation, in order to reuse them elsewhere, for example on social networks or on wikis.

The feature can be accessed from Meta wiki on the special page m:Special:URLShortener. (will be enabled on April 11th). On this page, you will be able to enter any web address from a service hosted by the Wikimedia Foundation, to generate a short URL, and to copy it and reuse it anywhere.

The format of the URL is w.wiki/ followed by a string of letters and numbers. You can already test an example: w.wiki/3 redirects to wikimedia.org.

What are the limitations and security measures?

In order to assure the security of the links, and to avoid shortlinks pointing to external or dangerous websites, the URL shortener is restricted to services hosted by the Wikimedia Foundation. This includes for example: all Wikimedia projects, Meta, Mediawiki, the Wikidata Query Service, Phabricator. (see the full list here)

In order to avoid abuse of the tool, there is a rate limit: logged-in users can create up to 50 links every 2 minutes, and the IPs are limited to 10 creations per 2 minutes.

The maximum permitted URL length is 2,000 characters. — Preceding unsigned comment added by CennoxX (talk • contribs) 08:18, 12 April 2019 (UTC)[reply]

Where will this feature be available?

In order to enforce the rate limit described above, the page Special:URLShortener will only be enabled on Meta. You can of course create links or redirects to this page from your home wiki.

The next step we’re working on is to integrate the feature directly in the interface of the Wikidata Query Service, where bit.ly is currently used to generate short links for the results of the queries. For now, you will have to copy and paste the link of your query in the Meta page.

Documentation and requests

If you have any question or requests, feel free to leave a comment under this Phabricator task
The user documentation is available here: please help us to translate it in your language!
See also the technical documentation of the extension

Thanks a lot to all the developers and volunteers who helped moving forward with this feature, and making it available today for everyone in the Wikimedia projects! Lea Lacroix (WMDE) (talk) 11:54, 3 April 2019 (UTC)[reply]

Lea Lacroix (WMDE), really cool feature and nice to see something that has been on the wishlist for so long finally becoming available ! Thx to everyone who worked on it ! —TheDJ (talk • contribs) 20:30, 4 April 2019 (UTC)[reply]

@Lea Lacroix (WMDE): The feature is up and running, and I created some short links. However, I'm having trouble making the mediawiki software recognize them as links. Putting them as plaintext, external links, or internal wikilinks all fail to generate a working link - see User:DannyS712/sandbox#Short links. Any chance you can help? --DannyS712 (talk) 17:47, 11 April 2019 (UTC)[reply]

@DannyS712: there is no wiki-magic going on here, this is just a URL shortener, they w.wiki/A is the same type of link and text handling as something like bit.ly/A - you still have to use a protocol identifier. — xaosflux ^Talk 17:51, 11 April 2019 (UTC)[reply]

@Xaosflux: oh, thanks. Is there any chance that wikilink syntax ([[]]) can be extended to work with the short links too? --DannyS712 (talk) 17:54, 11 April 2019 (UTC)[reply]

@DannyS712: Not too likely for it to be extended as such. But you can link one via Special:UrlRedirector right now (like Special:UrlRedirector/U3), or you could try to get an appropriate prefix added to m:Interwiki map to link it as an interwiki link (like that link to the "Interwiki map" page on Meta). Anomie ⚔ 18:56, 11 April 2019 (UTC)[reply]

@Anomie: okay, thanks --DannyS712 (talk) 18:57, 11 April 2019 (UTC)[reply]

Thanks @DannyS712: for raising this issue, indeed the URL shortener is not providing the https:// prefix. I added a mention in the documentation to make clearer the fact that on wikis, one has to add the https. Lea Lacroix (WMDE) (talk) 07:06, 12 April 2019 (UTC)[reply]

@Lea Lacroix (WMDE): Thanks. I made {{Short url}} to make it easier (example) --DannyS712 (talk) 07:09, 12 April 2019 (UTC)[reply]

@Lea Lacroix (WMDE): Thanks! However, shouldn't the URLShortener output the URL with https:// in front of it so people can easily paste it? I'm pretty sure people will find it problematic to just paste something like "w.wiki/tS" (link to this discussion) because many applications might not detect that this is a valid URL. Also, can you maybe try to get some more .wiki-domains like en.wiki, de.wiki etc.? That way, links could be customized to reflect the language/project. Regards So Why 07:23, 12 April 2019 (UTC)[reply]

@DannyS712: Awesome, thanks! I'm going to add it in the doc as well, so other projects can create a similar template if they want to.

@SoWhy: Thanks for your feedback. The idea of directly including the prefix is mentioned in this ticket.

As for adding more domain, I'm not sure that it's part of the purpose of the tool. The URL shortener is cross-projects, it links to Wikipedias but also Commons, Wiktionaries, Phabricator, Mediawiki, the Wikidata Query Service, etc. So structuring it for language versions of Wikipedias is a bit too restrictive. Lea Lacroix (WMDE) (talk) 08:58, 12 April 2019 (UTC)[reply]

One does not preclude the other. The tool can be cross-project but still output different domains that allows people to immediately see which project the link will lead them to. For example, w.wiki/tS links here but when I mistakenly typed w.wiki/Ts, it took me to ru-wikibooks. If the domain had been ru.wiki/..., I would have known not to use that link. Also, xx-wiki is a common abbreviation used, so if not for the URL shortener, those URLs could be used as alternatives, e.g. people could type https://en.wiki/Germany instead of https://en.wikipedia.org/wiki/Germany. Just something that you guys and gals might want to consider. Regards So Why 09:10, 12 April 2019 (UTC)[reply]

Maintenance of templatetransclusioncheck and DYK QPQ check

I would like to know whether taking up the tools DyK notices (mentioned here) and TemplateTransclusionCheck (mentioned here) as a maintainer will benefit for someone here. Adithyak1997 (talk) 15:27, 4 April 2019 (UTC)[reply]

Even though User:Δ is currently blocked on this wiki, they fixed the DYK tool. --Pipetricker (talk) 15:33, 12 April 2019 (UTC)[reply]

Deleted pages in a category (as listed by AWB)

Resolved

I was making a list (Wikipedia:WikiProject Chemistry/Lists of pages/Chemistry articles with AWB from Category:WikiProject Chemistry articles and saw on list that it included the deleted article Janet Kreizman which was delted 6 March 2019. There is 5-6 deleted articles on that list (SensoLyte was deleted February 2018). Why ? (or known issue) Christian75 (talk) 18:32, 4 April 2019 (UTC)[reply]

Did you mean "API and categories" or "AWB and categories"? --Pipetricker (talk) 17:39, 12 April 2019 (UTC)[reply]

@Pipetricker: Sorry, I should have removed this post. I have a local copy of the chemistry-project. I guess that I used that with AWB, because the day after I got a list without any deleted pages. (I used AWB, and AWB uses the API to get the categories...) Christian75 (talk) 17:44, 12 April 2019 (UTC)[reply]

Ok. Feel free to remove this topic then Christian75 (but hurry before anyone else makes a comment ...). --Pipetricker (talk) 17:52, 12 April 2019 (UTC)[reply]

how to disable the annoying "your edit was saved" pop up

Today I started getting an annoying pop up at the top of my screen every time I edit an article. I don't need a notification to interrupt me and grab my attention to make me aware that I'm doing what I know I'm doing. Does anybody please know how to disable this clever "feature"? Thanks very much! Dr. Vogel (talk) 23:35, 5 April 2019 (UTC)[reply]

Try this in your CSS:

.postedit {display:none;}

PrimeHunter (talk) 23:53, 5 April 2019 (UTC)[reply]

Hi, thanks very much, I'll have a go. This looks like a hack, but if it works, it will at least remove the pointless distraction. I would be interested in hearing one good reason why somebody thought it'd be a good idea to create a notification that gets your attention and interrupts you to tell you that you're doing what you're doing, and there isn't even an option to disable it. Dr. Vogel (talk) 23:58, 5 April 2019 (UTC)[reply]

It made folks ornery when it was introduced back in the day, but it made a major difference to new editors. A little css won't hurt. ~ Amory (u • t • c) 01:13, 6 April 2019 (UTC)[reply]

A p-value of 0.052 is not exactly significant or a major difference :) Also what about the people it annoys? But thanks for sharing that, it's consistent with what I felt was probably the case! Dr. Vogel (talk) 01:28, 6 April 2019 (UTC)[reply]

@PrimeHunter and Amorymeltzer: And more than that, Wikipedia needs to modernize with time. The popup in the top-center was good way back in 2012, but now with sophisticated Snackbars/Toasts (such as Google or this) existing in 2019, Wikipedia should move over to them. There is a huge problem with Wikipedia using old and outdated design styles. 125.63.105.110 (talk) 14:59, 9 April 2019 (UTC)[reply]

I wasn't thrilled about it when it was new, but since there, there have been a few times when I've been grateful for it. "Yup, worked" vs "Nope, time to file a bug" isn't always as clear as it should be. Whatamidoing (WMF) (talk) 17:18, 12 April 2019 (UTC)[reply]

Hideous history page

Tracked in Phabricator
Task T107069

How do I get rid of this new ridiculous box that takes up half the history page? Natureium (talk) 20:16, 8 April 2019 (UTC)[reply]

@Natureium: what page are you looking at? --DannyS712 (talk) 20:19, 8 April 2019 (UTC)[reply]

Oh nevermind its all of them - let me see if I can make a user script --DannyS712 (talk) 20:21, 8 April 2019 (UTC)[reply]

@Natureium: You could add this to your Special:Mypage/common.css to shrink it, but really the interface should be modified so it doesn't put each element on its own line.#mw-history-searchform { font-size: 0.8em; } Bradv🍁 20:25, 8 April 2019 (UTC)[reply]
- Thanks! Natureium (talk) 20:27, 8 April 2019 (UTC)[reply]

For some context, this is phab:T107069. Changes were done today rather than last Thursday as they were blocked (see email). ~ Amory (u • t • c) 20:33, 8 April 2019 (UTC)[reply]

Is there someone we can bribe to re-block this? Natureium (talk) 00:09, 9 April 2019 (UTC)[reply]

Agree this is hideous, takes up about 1/3 of my vertical screen as well. The prior incarnation (shown IN the phab ticket description) had the selectors laid out side by side, @Bradv: is right, restoring that layout alone would greatly improve this. Anyone got a hack for just that? — xaosflux ^Talk 21:09, 8 April 2019 (UTC)[reply]
Unambiguously terrible, just like the rest of the oo-ui disaster. This mitigates it a little, but it's fragile, and still ugly, just not unusably ginormous. (The #histlegend rule is unrelated.) —Cryptic 00:41, 9 April 2019 (UTC)[reply]
@Cryptic: anyone who wants to easily import Cryptic's hack can use script-installer to add User:DannyS712/history.js (pseudocode: if looking at history, add the CSS) --DannyS712 (talk) 00:53, 9 April 2019 (UTC)[reply]
Loading css through JS creates a annoying content jump so it is better to add
@import url("//en.wikipedia.org/w/index.php?title=User:DannyS712/history.css&action=raw&ctype=text/css");
at the top of your common.css. Galobtter (pingó mió) 09:01, 9 April 2019 (UTC)[reply]
Agreed. Is this a bug? That is, were the elements supposed to be on one line, but something went wrong? If so, then let's not pile on with the anti-WMF snark just yet. Shit happens. But if this intentional, I'd really like an explanation. Suffusion of Yellow (talk) 01:00, 9 April 2019 (UTC)[reply]
My hack: Move it to the bottom of the page. See User:Suffusion of Yellow/history-search-at-bottom.js. If you don't want an annoying page jump after the script loads, you'll also need to hide it using your common.css. Also probably fragile, but it works for me. Suffusion of Yellow (talk) 03:10, 9 April 2019 (UTC)[reply]

Def. needs to be hidden/reverted back! Lugnuts ^{Fire Walk with Me} 06:42, 9 April 2019 (UTC)[reply]

It adds an extra click for every page, which is an unacceptable waste of the editors' time. Needs to be reverted back or made collapsible or made opt-in/opt-out.--Ymblanter (talk) 08:18, 9 April 2019 (UTC)[reply]

Clarification: For me, it takes more than 1/2 of the screen, pushing the first edit in the history off the first screen.--Ymblanter (talk) 08:23, 9 April 2019 (UTC)[reply]

@Ymblanter: With feedback here, we've made the form collapsible and collapsed by default. You can already try out the change on Beta Cluster. For completion, corresponding task is phab:T220555 Volker E. (WMF) (talk) 21:03, 11 April 2019 (UTC)[reply]

Great, thanks.--Ymblanter (talk) 21:06, 11 April 2019 (UTC)[reply]

Can somebody please translate the above tech stuff for a Luddite like me? How do I get rid of this and go back to how it was before? Glad I'm not the only one that's pissed off with it... Giant Snowman 12:07, 9 April 2019 (UTC)[reply]

GiantSnowman, copying @import url("//en.wikipedia.org/w/index.php?title=User:DannyS712/history.css&action=raw&ctype=text/css"); to User:GiantSnowman/common.css should do the trick. I think I might just zap it with my adblocker for the next few months though. Alpha3031 (t • c) 12:29, 9 April 2019 (UTC)[reply]

@Alpha3031: thanks but that hasn't worked, even after purging... Giant Snowman 12:38, 9 April 2019 (UTC)[reply]

@GiantSnowman: to be clear, adding an @import to your css/js pages means that it will also copy whatever the current contents of that other page are in to your running session, keep in mind - anything they change in the future (purposefully, or if their account is compromised) will also be loaded to you. Admins should take extra caution when importing from other users. You can always go to that page and just copy/paste the code to your page if you want a point-in-time version. (Think of the @import like a template transclusion). — xaosflux ^Talk 12:48, 9 April 2019 (UTC)[reply]

@Xaosflux: thanks for clarifying - I have removed and will leave it as it is until somebody comes up with a workaround for plebs like me! Giant Snowman 12:50, 9 April 2019 (UTC)[reply]

Thanks for those who've been involved in the code for the common.css page - much appreicated. Lugnuts ^{Fire Walk with Me} 13:37, 9 April 2019 (UTC)[reply]

The workaround is to copy-paste the contents of that page to your CSS page. --Izno (talk) 13:51, 9 April 2019 (UTC)[reply]

@Izno: lovely, thanks! Giant Snowman 14:02, 9 April 2019 (UTC)[reply]

Hi everybody, Volker E. (WMF) here, one of the folks behind the original change. After looking through feedback here, the comments on phab:T107069 and talking to other long-term contributors, we've merged a patch to Beta Cluster by my colleague Jon Robson to collapse form by default and make it expandable. As the overwhelming majority of use case seems NOT to involve interacting with the form at all.

With the patch we're focussing on three sides:

if functionality is rarely used, it's useful to have it hidden by default,
if vertical space is main issue – collapsing is providing more vertical space than before OOUI transformation without
introducing technical/user experience debt by inlining form elements unlike other OOUIfied forms.

The change can already be tried out on Beta Cluster and we could SWAT it 24h of now to all wikis, depending on feedback either on the tracking Phabricator task or here from you volunteer contributors…

Thanks for your patience and your feedback, Volker E. (WMF) (talk) 23:52, 9 April 2019 (UTC)[reply]

"OOUI", "technical/user experience debt", "SWAT". --Pipetricker (talk) 10:08, 10 April 2019 (UTC)[reply]

What I'd like is a way to opt out of this completely, not a way to get round it. I don't want to change my css or use JavaScript to hide it; I have, for now, but I want to opt out. Please. BlackcurrantTea (talk) 04:04, 10 April 2019 (UTC)[reply]

Complete opt-out and keeping the old code would be the best solution for me too. The new one takes a noticeable additional time to load, and this is irritating. Tricks that diminish or hide the box are rather trivial, I can even implement them myself, but they don't bring back the lost performance. — Mike Novikoff 10:04, 10 April 2019 (UTC)[reply]

Is there a way to go the old history page toolbox back, perhaps using the Gadget menu? I get that this is simpler and more intuitive but it's also slower because it's JS heavy. I found the old one much faster, especially since the things I wanted were often only one or two clicks away. For example if I wanted to go back to the year 2007 I'd just select the year box, type "2007" and press enter, while now I have to make six clicks. Daß Wölf 00:21, 10 April 2019 (UTC)[reply]
Daß Wölf, when you say slow, you mean 'slow to operate' ? In my opinion, it would help if the date widget would be able to autocomplete based on what I type. It's rather 'mouse'-heavy, I either need to type out the full date, or part of the date and then select the day by mouse. —TheDJ (talk • contribs) 12:32, 10 April 2019 (UTC)[reply]
@TheDJ: slow to operate, and also slow to load, although the latter is probably unavoidable given the ubiquitous CSS and JS heavy design choices that WP seems to be adopting. <rant>A little annoying that my internet connection is 1000 times as fast as ten years ago, yet websites take longer to render.</rant> I would also appreciate an autocomplete feature. For example, it would be nice if it could autocomplete e.g. 2017 or 17 to 2017-12-31. Daß Wölf 20:59, 10 April 2019 (UTC)[reply]

Volker E. (WMF), having read the comments on the Phabricator task and yours above, both of which state that the form (or similar functions) isn't used much (the overwhelming majority of use case seems NOT to involve interacting with the form at all), I'm wondering why the response to this unpopular change is if functionality is rarely used, it's useful to have it hidden by default rather than 'if functionality is rarely used, it's useful to have it off by default'.

Why is this something we have to work to get rid of, rather than an option? I understand that it's meant to help users on mobile devices. Why not make it part of the mobile interface – preferably one that users can turn off if they don't like it – and an option for desktop editors? BlackcurrantTea (talk) 02:29, 11 April 2019 (UTC)[reply]

@BlackcurrantTea: If I understand you correctly, you're asking why can't it be visible for desktop users and hidden for mobile users? And a collapse/expand functionality is left out of the question. It's important to say that there is not one homogenous group of users. There might be a majority of users that don't interact with that page any different than to look up recent changes for a specific page and never touch the form. It doesn't matter for the main use case if they are on mobile or desktop, any form is in their way. There might be a minority of users that want to limit the revisions shown to a certain date. It doesn't matter for where to access the filter functionality as long as it's accessible, no matter what device they are on. There might be a minority of newcomer users that have no idea yet, what a tag filter is. But later on they are curious and try the functionality and instead of hiding it away in a setting, that needs to be explained in complete different context (settings page) and maintained and kept working for years, it's in a minimal interface on the place where it is meant to be without confusing to the first group. With these examples I'd like to share that no matter what solution it should please the main use case user while not excluding other use case users independently of the device. Volker E. (WMF) (talk) 03:11, 11 April 2019 (UTC)[reply]

@BlackcurrantTea: ^^^ --DannyS712 (talk) 03:18, 11 April 2019 (UTC)[reply]

Thank you for your quick response, Volker E. (WMF). No, I'm asking the opposite (let it default to 'on' for mobile users, 'off' for desktop), based on the suggestion at Phabricator that this is supposed to help mobile users. What I want as a user is a way to turn it off. I belong to the group of users that don't interact with that page any different than to look up recent changes for a specific page and never touch the form. It doesn't matter for the main use case if they are on mobile or desktop, any form is in their way. I want to remove it from my screen entirely. Not hide it nor collapse it: I want to turn it off. Can you make that possible, please? BlackcurrantTea (talk) 03:52, 11 April 2019 (UTC)[reply]

@BlackcurrantTea: For such, you'd only need to add

 /* Hide Edit revision history page's form */
 .action-history #mw-content-text > .mw-htmlform-ooui-wrapper:first-child {
   display: none;
 }

to your common.css. Volker E. (WMF) (talk) 20:36, 11 April 2019 (UTC)[reply]

Volker E. (WMF), whilst I appreciate the help and suggestions from you and others here, I feel strongly that we shouldn't have to fight the software. As I said, I don't want to change my css or use JavaScript to hide it; I have, for now, but I want to opt out. and I want to remove it from my screen entirely. Not hide it nor collapse it. By 'it', I mean this new version that has been imposed on us. The old version was fine. It worked. It didn't take up an inordinate amount of my screen.

The new version should be optional, and something anyone can turn on or off with preferences. Not something that requires mucking about with css or JavaScript to get rid of it or to get a semblance of the old version back. BlackcurrantTea (talk) 00:32, 12 April 2019 (UTC)[reply]

Volker E. (WMF), you must be kidding. Are we supposed to teach the developer what {display:none} is and how it differs from turning the bloat off? Ok, I'll do: it's always the last resort when nothing else could be done, it's practiced by users when developers are out of reach, source code is unavailable, insufficient knowledge to modify it, etc. But it's you who can really change the underlying code, and that's what we ask of you. Let me repeat that magic word: 'please'! — Mike Novikoff 18:00, 12 April 2019 (UTC)[reply]

At the very least, reduce the width of the "Tag filter:" box - I don't see why it has to be full width, when Special:Contributions has one that is about 15em wide, and has sideways scrolling so will accept more input. That way you can put everything (labels, input items and checkboxes) on one line. --Redrose64 🌹 (talk) 08:15, 11 April 2019 (UTC)[reply]

Shhh! Don't talk about the form at the top of Special:Contributions, lest the WMF decide to do their shit (read OOUI-fication) on that too. SD0001 (talk) 09:04, 11 April 2019 (UTC)[reply]

Completely concur with Redrose64. All elements inside <form id="mw-history-searchform">...</form> could easily be shown in one line (or at least as inline-blocks). Nardog (talk) 09:14, 11 April 2019 (UTC)[reply]

Does anyone have the HTML code of the box before the OOUI-fication, so that we can make a script to restore the old version? SD0001 (talk) 09:23, 11 April 2019 (UTC)[reply]

In Vector skin, it was

<form action="/w/index.php" method="get" id="mw-history-searchform">
  <fieldset id="mw-history-search">
    <legend>Search for revisions</legend>
    <input type="hidden" value="Events" name="title">
    <input type="hidden" value="history" name="action">
    <label for="year">From year (and earlier):</label>
    <input id="year" maxlength="4" size="7" type="number" value="2019" name="year">
    <label for="month">From month (and earlier):</label>
    <select name="month" id="month" class="mw-month-selector">
      <option value="-1">all</option>
      <option value="1">January</option>
      <option value="2">February</option>
      <option value="3">March</option>
      <option value="4">April</option>
      <option value="5">May</option>
      <option value="6">June</option>
      <option value="7">July</option>
      <option value="8">August</option>
      <option value="9">September</option>
      <option value="10">October</option>
      <option value="11">November</option>
      <option value="12">December</option>
    </select>&nbsp;<label for="tagfilter"><a href="/wiki/Special:Tags" title="Special:Tags">Tag</a> filter:</label>&nbsp;<input name="tagfilter" size="20" value="" class="mw-tagfilter-input mw-ui-input mw-ui-input-inline" id="tagfilter">&nbsp;<input type="submit" value="Show">
  </fieldset>
</form>

That is from wmuk: which is several MediaWiki versions behind. --Redrose64 🌹 (talk) 09:51, 11 April 2019 (UTC)[reply]

Excellent! Those who want to revert back to the old version: Add importScript('User:SD0001/oldSearchHistory.js'); to your js page, and @import url("//en.wikipedia.org/w/index.php?title=User:SD0001/oldSearchHistory.css&action=raw&ctype=text/css"); to your css page. The latter (css) is optional but prevents the new version of the box from flashing momentarily. SD0001 (talk) 13:57, 11 April 2019 (UTC)[reply]

I move to make that userscript a gadget, preferably one that is enabled by default. * Pppery * _{fades away} 00:53, 12 April 2019 (UTC)[reply]

I would also much appreciate having this as a gadget or in general as a preference that lets user not waste time by rendering/loading both the old and the new search box into memory - especially since the CSS hack doesn't seem to be working for me (the new box still displays for 1-2 seconds). Daß Wölf 20:45, 14 April 2019 (UTC)[reply]

Not only does this look hideous, it doesn't work

Tracked in Phabricator
Task T220781

Go to the history of any given page, let's say this page, i.e. [1]. Select a date, let's say 31 December 2018, and click "Show revisions". You are led to this page. Now click "older 50". You are led to this page, which shows you the exact same things as the previous page. This time, click "newer 50". This one works. But click "newer 50" again. You are led to here, which shows you the exact same things as the previous one. Tested on Chrome & Firefox. What is going on here? In the meantime, the previous version, as much as you can't choose a specific date, still works. Nardog (talk) 22:02, 11 April 2019 (UTC)[reply]

What happened is that the cook mixed in grasshoppers and live maggots in all editors' food even so he knew that only a few might enjoy it and on top he didn't even check for mold before forcing it down our throat. Same business as usual here. (Yes, I like to point out shortcomings due to missing professional oversight and authority on Wikipedia).--TMCk (talk) 20:19, 12 April 2019 (UTC)[reply]

This has been fixed as of today and is already visible on Beta Cluster. Going to roll-out to all Wikimedia Foundation wikis next week. Volker E. (WMF) (talk) 22:35, 12 April 2019 (UTC)[reply]

Bug in history when I use date

There were so many pages in the history of Notre-Dame de Paris fire that I took advantage of the date feature at the top. When I did, clicking on "older 50" gave me the same list of edits.— Vchimpanzee • talk • contributions • 15:14, 16 April 2019 (UTC)[reply]

Just for a confirmation. Did you check the time mentioned when you click the "older 50" button each time? Adithyak1997 (talk) 15:17, 16 April 2019 (UTC)[reply]

I don't see anything about selecting a time.— Vchimpanzee • talk • contributions • 15:19, 16 April 2019 (UTC)[reply]

Actually, that specific page has undergone a minimum of 1300+ edits on 16th. So, when you click on the "Older 50" button, I guess you will experience a repetition. Just click on the number 500 present near to "older 50" and then just click on the "older 500" link two times and check if your getting any changes in the date. Adithyak1997 (talk) 15:23, 16 April 2019 (UTC)[reply]

This has been brought up above, see #Not only does this look hideous, it doesn't work. Per the phab task it's been fixed, so it'll be deployed here on Thursday. – Ammarpad (talk)

Sorry. I misunderstood. Adithyak1997 (talk) 15:41, 16 April 2019 (UTC)[reply]

I was looking for just edits on the 15th and I kept seeing the same ones.— Vchimpanzee • talk • contributions • 15:46, 16 April 2019 (UTC)[reply]

I don't suppose it's possible to see the edit that removed the wording I had a problem with. The problem language was gone by 23:59 on April 15 and, of course, the article was started on the 15th but then, that's the date I complained.— Vchimpanzee • talk • contributions • 15:50, 16 April 2019 (UTC)[reply]

Changes to template triggering excessive link notifications

This edit by InternetArchiveBot to 2008 Geelong Football Club season triggered a notification that informed me Paul Hood (coach) had been linked from the page in the edit, though this was not the case. This has happened several times: (e.g. Geelong best and fairest (AFL Women's), 2006 Geelong Football Club season). The cause appears to be recent changes to Template:Geelong Football Club which have added a link to Hood's article. Why do I receive multiple notifications for links from many articles rather than one notification for a link from the template? Is this intentional or accidental? – Teratix ₵ 02:30, 9 April 2019 (UTC)[reply]

Why are you surprised? The articles were really linked. Whether this was achieved by modifying a template or directly the article is irrelevant. Ruslik_Zero 19:05, 9 April 2019 (UTC)[reply]

I think it's a fair complaint. Adding the template to an article should give a notification but here the link was added to the template between two unrelated article edits. I don't know how it's supposed to work but it would seem reasonable if the job queue updates link tables after the template edit without causing link notifications for articles using the template. When the article is edited next time, the link was there right before the edit so a notification can be omitted. Updates of link tables after template edits are often very delayed. Is it supposed to work like I say but failed because the link table was never updated before the article edit? Or is the next article edit always meant to cause a notification? PrimeHunter (talk) 21:13, 9 April 2019 (UTC)[reply]

@Ruslik0: it's not a huge issue, I agree, but imagine if you wrote an article that was then linked from a high-transclusion template with many linked articles (e.g. Template:United States topics) and received a notification every time the other articles were next edited, rather than one notification for the link from the template. – Teratix ₵ 01:46, 10 April 2019 (UTC)[reply]

I am not sure that the parser cares about templates. There is one link table per article, which includes all links including those from templates. On other hand if includeonly tag is used, the link may not be present in the template's link table at all. Ruslik_Zero 08:34, 10 April 2019 (UTC)[reply]

imagemaps

Tracked in Phabricator
Task T217087

hi all.

extension imagemap was updated recently (i believe it was recent. TBH, i don't know when exactly - could have been months). one of the consequences is that it became more feisty with regard to its input, and in particular, the "coordinates" (the number passed to "poly" in particular). we found and fixed some occurrences in hewiki, and there's still quite a few in enwiki. two of the problems we found were

-1 as one of the numbers. before the update, imagemap could handle it. no more. (i assume -1000 would be just as bad - we had -1's)
comma as separator between the coordinates. before the update, worked fine with 1, 2, 3, 4. no more.

unfortunately, this extension does not attach tracking categories to pages with issues, but it _does_ display a big, red, ugly message instead of the image when it feels slighted.

search pages in article namespace with these issues: Special:Search/"Error: Invalid coordinate at line"

example of the "can't stand -1" issue: Template:Nevada area codes image map.

peace קיפודנחש (aka kipod) (talk) 21:25, 9 April 2019 (UTC)[reply]

קיפודנחש, just to be clear, this input was invalid before as well, it just didn't produce error messages, giving you potential incorrect results. This was phab:T217087. —TheDJ (talk • contribs) 08:49, 10 April 2019 (UTC)[reply]

I've looked through them real quick, and it looks like they're all either German places, which use {{Infobox German location}}, which in turn uses one of the "Imagemap Germany district" ([2]) templates; or they're London postcodes, which all use {{Postcode area imagemap}}. rchard2scout (talk) 14:04, 10 April 2019 (UTC)[reply]

@TheDJ: - we may be splitting hair here, but i beg to differ. "invalid" is in the eye of the beholder. there is nothing i could find in W3 documentation stipulating that all vertices of a polygon in "area" element within a map element must reside inside the map's borders (there is a case to be made why vertices outside the border may be useful). all browsers can deal with polygons with some vertices outside. so from html POV, these were not "invalid". the imagemap extension was happy to accept such polygons until some time ago, and as far as i could find, never mentioned such a constraint in its documentation. so i am not sure in what sense these maps were "invalid" before the change to the extension. twisi, imagemap extension introduced, perhaps unwittingly, a breaking change (to add insult to injury, this was never mentioned on any of the biweekly "tech news"). this is of course just lawyering - the point of my message was that something that used to work stopped working due to software change, and if we want to make it "working" again, we need to do something. and, while i have your ear, i think we should lobby MW to add some tracking category to imagemap errors (see 4yo phabricator:T106075).

as to phab:T217087: this one talks about "non-numerical" values. it's somewhat hard to argue that "-1" is "non-numerical". much easier to guess that the programmer applied stricter rules to "numerical" than was warranted. i reopened it. peace - קיפודנחש (aka kipod) (talk) 15:52, 10 April 2019 (UTC)[reply]

It looks like the bug fix has been deployed. The only one I haven't been able to figure out is Template:Divisions of Bangladesh Image Map. – Jonesey95 (talk) 09:35, 13 April 2019 (UTC)[reply]

watchlist articles not being marked as read after having been seen/visited

Tracked in Phabricator
Task T218511

I hate to be a broken record but is there anyone working on fixing the issue where you go view pages on your watchlist, you have the filter for "unseen changes" on, and yet when you reload your watchlist, the fact that you've already viewed a page (or pages) isn't recorded immediately? This is extremely problematic if you are a frequent editor with a long watchlist and depend on the watchlist to accurately represent what changes you have and haven't seen. This seems like very core Wikipedia functionality and I'm really surprised issues with it not functioning properly have lingered well over a week. —Joeyconnick (talk) 23:02, 9 April 2019 (UTC)[reply]

Do you use live updates? They usually work fine for me, although I was tinkering with it a couple days ago and after a page refresh managed to get one of my own edits displayed in bold. I'm not sure exactly what I did to cause that, though... Daß Wölf 00:26, 10 April 2019 (UTC)[reply]

Nope, don't have Live Changes on and don't plan to turn it on. I'm not a fan of pages changing without any action on my part. I tolerate the little notification thing that pops up at the top of the list as that still requires my input before it loads the new changes. I just want the displayed "unseen changes" to actually be accurate, like they have been for years until this recent change. I'm all for updating stuff but not if it breaks essential functionality. —Joeyconnick (talk) 01:35, 10 April 2019 (UTC)[reply]

I had the same issue recurrently last week (never longer than half an hour). No idea where does it come from, or even of which side this is.--Ymblanter (talk) 09:01, 10 April 2019 (UTC)[reply]

I've seen this, too (Monobook, no live changes/updates, JavaScript usually off). I thought whatever was causing it had been fixed after the last time this was reported, until yesterday when a page stayed bold ('unread') on my watchlist after I looked at it twice. 14 hours or so later, it still appeared unread. After I looked at it again, it finally changed to plain text ('read'), and I haven't had the problem again today. BlackcurrantTea (talk) 11:12, 10 April 2019 (UTC)[reply]

This has happened to me as well since a couple weeks ago (no live/JS). I even see my own edit marked as unread from time to time, especially if I close the tab immediately after saving it. It also seems that viewing the diff no longer makes the edit read. Nardog (talk) 18:19, 10 April 2019 (UTC)[reply]

Happening right now to me, both on the English Wikipedia and on Commons.--Ymblanter (talk) 18:30, 11 April 2019 (UTC)[reply]

For the record, I use vector.--Ymblanter (talk) 10:44, 12 April 2019 (UTC)[reply]

It happened again just now. I looked at the two new diffs since I'd last checked the page, went back to my watchlist, and it was still marked as unread. I looked at the most recent diff (the latter of the two I'd already seen), still unread. Cleared my cache and waited several minutes, and it's still showing up as new. BlackcurrantTea (talk) 01:52, 12 April 2019 (UTC)[reply]

And now it's marked as read, without my having visited the page or looked at the diffs a third time. It would be helpful if this were fixed. BlackcurrantTea (talk) 02:16, 12 April 2019 (UTC)[reply]

Happening to me right now. Hi someone—please fix this! —Joeyconnick (talk) 03:07, 12 April 2019 (UTC)[reply]

I'm still having the opposite issue that I mentioned before: diffs being marked as read even though they weren't, but on occasion I also see the issue that everyone else is complaining about regarding diffs that have been read. isaacl (talk) 03:32, 12 April 2019 (UTC)[reply]

Is there a way to get the rendered size of page?

I'm looking for a tool that would let bots, scripts, and users know that Quark cost roughly 525 kB of data to download. The cached version would be fine for this purposes. It's not in accessible through &action=info, so I'm wondering if there's another way to get this. Headbomb {t · c · p · b} 03:39, 10 April 2019 (UTC)[reply]

Not really, since it depends on which image formats and compression formats the user-agent supports. I will also change every time the software is updated and/or styling or Javascript is changed for the wiki in question. —TheDJ (talk • contribs) 12:49, 10 April 2019 (UTC)[reply]

@TheDJ: Well, that's why I wondered about the cached size. Surely that's not something browser-dependent. More interested in a ballpark figure than an exact size for this purpose. Headbomb {t · c · p · b} 14:26, 10 April 2019 (UTC)[reply]

Template:Infobox presidential administration

Hi, the infobox in Second presidency of Carlos Andrés Pérez contains square brackets and duplicated links. I had a quick play but could not see how to fix, can someone take a look ? Thanks GrahamHardy (talk) 12:32, 10 April 2019 (UTC)[reply]

Further to the above it looks to be an issue with the Infobox template itself rather than this particular use of it...GrahamHardy (talk) 12:33, 10 April 2019 (UTC)[reply]

Template:Infobox presidential administration looks to be the one... GrahamHardy (talk) 12:35, 10 April 2019 (UTC)[reply]

You can't wikilink a wikilink. The infobox creates a wikilink [[Presidency of ...|...]] for both predecessor and successor. This suggests that there should already be articles: Presidency of Jaime Lusinchi and Presidency of Octavio Lepage. There is not for the latter so you might want to create a redirect from Presidency of Octavio Lepage → Octavio Lepage and cleanup the |predecessor= and |successor= parameters in the infobox.

—Trappist the monk (talk) 12:48, 10 April 2019 (UTC)[reply]

{{Infobox presidential administration}} was previously a redirect to {{Infobox administration}} which just displays the predecessor and successor parameters. The redirect was changed [3] to {{Infobox presidency}} which assumes the parameters are plain names and can be used to link articles about their presidency. Either the change should be reverted or many articles should be updated to fit the new parameter expectation or call {{Infobox administration}}. PrimeHunter (talk) 14:57, 10 April 2019 (UTC)[reply]

See Special:WhatLinksHere/Template:Infobox presidential administration for affected articles.

Pinging users who have edited Template:Infobox presidential administration: 1,2,3. --Pipetricker (talk) 13:23, 11 April 2019 (UTC)[reply]

@PrimeHunter and Pipetricker: Nominated {{Infobox presidency}} and {{Infobox premiership}} for deletion. Neveselbert (talk · contribs · email) 12:22, 15 April 2019 (UTC)[reply]

Changing the case of a template

In the template Template:Country data AUS, I would like to know the place where I can change the case of starting letter of the word 'Country' in the template name. Please do note that I am not going to make any changes here. Adithyak1997 (talk) 18:32, 10 April 2019 (UTC)[reply]

What exactly do you mean? Do you mean you want to use {{country data AUS}} instead of {{Country data AUS}}? Because it doesn't make any difference. Pages are not case sensitive for the first character. Headbomb {t · c · p · b} 18:36, 10 April 2019 (UTC)[reply]

Moved from User talk:Headbomb

I have recently posted a question in Wikipedia:Village Pump (Technical) with the section heading "Changing the case of a template". I actually know from [this] that capitalisation is done by Mediawiki. The problem lies in this page in the bottom most section. I haven't asked this in Community Portal in Incubator is that I have not got any results for the questions posted 4 days ago. Adithyak1997 (talk) 19:07, 10 April 2019 (UTC)[reply]

@Adithyak1997: I'm afraid I can't make much sense of that page, given I don't speak...Urdu? But if you tell us what exactly you're expecting, or what exactly you're trying to do, maybe we can help. Headbomb {t · c · p · b} 19:12, 10 April 2019 (UTC)[reply]

@Headbomb: Actually, I also doesn't know Urdu. I am just working on templates as well as on modules. What I need to achieve is that the word 'country' needs to start with upper case in the text "Template:Wp/khw/country data WIN". Adithyak1997 (talk) 19:20, 10 April 2019 (UTC)[reply]

Move the page to 'Template:Wp/khw/Country data WIN'? Headbomb {t · c · p · b} 19:29, 10 April 2019 (UTC)[reply]

As you have been told, this cannot be done with the structure of the pages/template as they are now. Nor is it that important. Why do you want to do this? --Izno (talk) 19:42, 10 April 2019 (UTC)[reply]

You have not explained what you are trying to do and the text "Template:Wp/khw/country data WIN" does not occur in the linked page. You are making us waste time trying to guess what your problem is before we can attempt a solution. Maybe you want country data templates to be named "Template:Wp/khw/Country data ..." with upper case C, and still work without having to create redirects at "Template:Wp/khw/country data ..." with lower case c. If this is what you want then the templates have to always be called with an upper case C. Here is a search showing some templates which currently call with lower case c. PrimeHunter (talk) 21:03, 10 April 2019 (UTC)[reply]

VisualEditor creating bad ref names

Tracked in Phabricator
Task T52568

I don't know if this is the right place to post this. If not, please point me in the right direction.
When you click the "Re-use" button in the "Add a citation" screen in VisualEditor, it changes <ref> in the chosen citation to <ref name=":0"> (see here). This breaks all the rules of WP:REFNAME: it is purely numeric, it has no "semantic value", and it has quote marks where no quote marks are required. Why can it not use something like name=Autogenerated1, name=Reference1 or, if you're fond of quote marks, name="Reference 1"?— Preceding unsigned comment added by Scolaire (talk • contribs) 18:42, 10 April 2019 (UTC)[reply]

This is a well-known VE bug. See the linked phab task. – Ammarpad (talk) 19:02, 10 April 2019 (UTC)[reply]

(edit conflict) Please sign your talk page posts using four tildes (~). As for your question, Visual Editor is still very much in beta, with many bugs yet to be resolved. Here are a few that I found related to the referencing naming that you have noticed: T215867, T92432 (a four-year-old bug), T212609, T169841, T94712. Be careful out there. – Jonesey95 (talk) 19:08, 10 April 2019 (UTC)[reply]

@Scolaire: It's not purely numeric - there is a colon before the zero. The presence of that colon not only makes it non-numeric, it also makes the quote marks mandatory. However, you're right that it has no "semantic value" - but Visual Editor isn't intelligent enough to pick a ref name that does have semantic value. --Redrose64 🌹 (talk) 19:28, 10 April 2019 (UTC)[reply]

Sorry about not signing – a mistake I rarely make. I take it there's no prospect of this being fixed in the near future, then? @Redrose64: quotation marks are optional if the only characters used are letters, digits, and symbols including the colon. Scolaire (talk) 19:34, 10 April 2019 (UTC)[reply]

Cite error: The <ref> tag name cannot be a simple integer (see the help page).

^[1]

Testing ~. No, it is incorrect to say it is all numeric, as Redrose remarks. As it happens, the requirement here is not a soft requirement but a hard one: the software will fail to process an all-numeric reference name. I do not know why the software has this basic requirement, but there it is. --Izno (talk) 19:44, 10 April 2019 (UTC)[reply]

As for "why cannot it use a certain text", the "certain texts" would need to be localized. The developers thought it would be easier to include the notation they did because a) it skips that problem and b) eventually you see enough ":1" and you know it was created by VisualEditor. The Phabricator tasks above are of interest of course. --Izno (talk) 19:48, 10 April 2019 (UTC)[reply]

References

^ DEF

Attribute values need not be quoted if they consist only of digits, letters (of either case) the hyphen-minus character and the full stop character. If any characters other than those 64 are used (such as a colon), the quotes are mandatory. --Redrose64 🌹 (talk) 20:04, 10 April 2019 (UTC)[reply]

For the longest time I used to wonder why people were using a shocked emoticon as a ref name... Daß Wölf 21:05, 10 April 2019 (UTC)[reply]

Okay, that explains it. Thank you all for your help. Scolaire (talk) 09:11, 11 April 2019 (UTC)[reply]

css help request: hiding help link in watchlist and contributions (mw-helplink?)

Resolved

What have I done wrong here? Special:Diff/891848066 –xeno^talk 19:21, 10 April 2019 (UTC)[reply]

You've added the selector .mw-helplink to the selector-list of a rule that has a declaration-list containling only the declaration display: none;. What were you trying to do, why do you think it's wrong? --Redrose64 🌹 (talk) 19:34, 10 April 2019 (UTC)[reply]

@Redrose64: Hide the “Help?” link on watchlist and contribution pages. Yet it still shows up. –xeno^talk 20:14, 10 April 2019 (UTC)[reply]

display: none !important; or a more specific selector is required. It also hides other help links. Do you want to hide all of them or only on watchlist and contributions? PrimeHunter (talk) 20:18, 10 April 2019 (UTC)[reply]

(edit conflict) I don't like !important, it's a cop-out. You could whack the specificity right up with the selector

div#mw-indicator-mw-helplink.mw-indicator a.mw-helplink

If that doesn't do it, something funny's going on. --Redrose64 🌹 (talk) 21:07, 10 April 2019 (UTC)[reply]

I think it’s gone! Thank you @Redrose64, PrimeHunter, and Mike Novikoff: for your input. –xeno^talk 22:41, 10 April 2019 (UTC)[reply]

This one works fine for me. Hides only the ugly icon, yet retains any text links. — Mike Novikoff 21:05, 10 April 2019 (UTC)[reply]

Navbox issue

On my sandbox, I have a Navbox template copied from Chinese Wikipedia. Since I don't know how to translate several of the template parameters into English, it's full of error messages. Is there some sort of discrepancy between the way Navbox templates work on the Chinese and English Wikipedias? Woshiyiweizhongguoren (🇨🇳) 13:13, 11 April 2019 (UTC)[reply]

You have used the template {{to}} without supplying the parameter which it requires. Read the documentation at Template:to. --David Biddulph (talk) 13:21, 11 April 2019 (UTC)[reply]

@David Biddulph: Since they say they have copied from Chinese Wikipedia, I went over there and checked out their {{to}}. Their template {{to}} is different from ours. The Chinese one is used to show an arrow pointing right like this →180.151.77.75 13:37, 11 April 2019 (UTC)[reply]

You copied it from zh:Template:老北京城 without changing anything. Each Wikipedia language has its own templates, often with their own parameters. The Chinese zh:Template:Navbox appears similar to ours. Some of the parameter values in your example call the Chinese zh:Template:to which does something different here. This is not a difference in how zh:Template:Navbox works. PrimeHunter (talk) 13:54, 11 April 2019 (UTC)[reply]

Vector "Page" tab is missing the Move option

I am trying to move File:R-5110781-1410470676-2995.jpeg.jpg to File:Ademuz (album).jpg, but the move option under the page tab is missing. - FlightTime (open channel) 16:09, 11 April 2019 (UTC)[reply]

@FlightTime: Are you a file mover? Renaming files requires a different right - see Special:UserGroupRights. Only admins and file movers have the needed movefile right. --DannyS712 (talk) 16:57, 11 April 2019 (UTC)[reply]

@DannyS712: Special:ListUsers/FlightTime says yes, he is.

@FlightTime: Does going directly to Special:MovePage/File:R-5110781-1410470676-2995.jpeg.jpg work? That is, are you actually prevented from moving the file, or is it just a display issue? —Cryptic 17:05, 11 April 2019 (UTC)[reply]

@Cryptic: Yest it worked, but there are still issues with the dropdown, Thanks, - FlightTime (open channel) 18:26, 11 April 2019 (UTC)[reply]

@FlightTime: Does going to this link make it work for you? You have a lot in your common.js that could be colliding. — xaosflux ^Talk 17:11, 11 April 2019 (UTC)[reply]

I wonder if this is related to the title blacklist entry now visible at the File:R-5110781-1410470676-2995.jpeg.jpg redlink. Though, as a pagemover, FlightTime should have been unaffected. —Cryptic 18:42, 11 April 2019 (UTC)[reply]

I do believe the file string ending triggered the blacklist, correct, that should have bee overlooked even though the new target was not dup strings. - FlightTime (open channel) 19:08, 11 April 2019 (UTC)[reply]

History search

I was interested in knowing when and by whom RFA was modified to reflect the following wording:

"In December 2015 the community determined that in general, RfAs that finish between 65 and 75%..."

When I did a search, I was surprised to find that it was added in a 2005 edit.

That's obviously wrong. I'm guessing there is a transclusion throwing off the search results. how can I figure out when, and more importantly, by whom, that wording was added?S Philbrick (Talk) 18:59, 11 April 2019 (UTC)[reply]

I believe you're looking for this edit and/or the one immediately after. —Cryptic 19:08, 11 April 2019 (UTC)[reply]

(edit conflict) @Sphilbrick: You were close, that content is on Wikipedia:Requests for adminship/Header, and it looks like it was added here: Special:Diff/697363992. — xaosflux ^Talk 19:11, 11 April 2019 (UTC)[reply]

(ec) It was added to the template: [4]--Ymblanter (talk) 19:12, 11 April 2019 (UTC)[reply]

Feel free to buy us all a round due to all the edit conflicts :D — xaosflux ^Talk 19:13, 11 April 2019 (UTC)[reply]

Xaosflux, Thanks to all for the prompt responses. I'll buy you all a round. S Philbrick (Talk) 19:27, 11 April 2019 (UTC)[reply]

User:Js/watchlist.js needs an update

Before, this user script used to put a small 'x' next to articles your watchlist.

17:49 (x) Inter City Firm‎ (diff | hist) .. (+26‎) .. 86.143.111.143 (talk) [rollback] (Tags: Mobile edit, Mobile web edit)

Now it shoves it at

17:49 Inter City Firm‎ (diff | (x) hist) .. (+26‎) .. 86.143.111.143 (talk) [rollback] (Tags: Mobile edit, Mobile web edit)

Could someone fix that? Headbomb {t · c · p · b} 20:54, 11 April 2019 (UTC)[reply]

@Headbomb: you can use Special:Preferences#mw-prefsection-watchlist instead - "Add direct unwatch/watch markers (×/+) to watched pages with changes". As for actually fixing the problem, TheDJ is likely the most familiar with the code. --DannyS712 (talk) 21:03, 11 April 2019 (UTC)[reply]

It works, but it seems to introduce a very large gap between the X and the item. It's workable, although ugly. Is there a general page for gadget tweaks? There's a few of them that could use a bit of love. Headbomb {t · c · p · b} 21:07, 11 April 2019 (UTC)[reply]

Technical advice needed; Thanks

I have poor and declining vision; needing to enlarge the size of text (significantly) for accessibility. Although some infoboxs do not present the following concern, many to perhaps most of the one's being used stretch horizontally in concert with the font's increase in size. Their presence, then, quickly dominates everything else (consuming the page's width) and it does become quite distracting.

It is my belief that every infobox template should be prevented (by default) from stretching beyond half of the page's width; with all of the excess stretching the IB vertically or, perhaps, by scrolling the horizontal overflow. My questions are: 1.) Is this thing worth fixing? 2.) If it is worth fixing, what recourse is available (from BOLD to an RfC)? 3.) What causes this problem and what will fix it (if not by changing the default coding for IB templates, perhaps by a script)? Thank you.--John Cline (talk) 02:09, 12 April 2019 (UTC)[reply]

Sorry to hear about your vision. I expect that there are other WP editors here who have similar challenges and can help you. How big a font size are you choosing? In Firefox, if I choose 28-point font in the Preferences (I normally read and edit using 14-point), I basically get three equal columns at, for example, John McPhee: one on the left with Main page etc., one column of content, and one column for the infobox. That doesn't seem too bad. YMMV with the size and resolution of your monitor. You might try a different browser, a different screen resolution, or if possible, a larger monitor. – Jonesey95 (talk) 04:26, 12 April 2019 (UTC)[reply]

I enlarge the text by pressing ctrl/shift/+ and take it to %240.--John Cline (talk) 05:08, 12 April 2019 (UTC)[reply]

John Cline, I'm sorry to hear of your vision problem. As an interim measure, you might try the MinervaNeue skin. I looked at the different skins with the page size increased, and at 300% (according to Firefox, article title ~1.25 cm (0.49 in) tall) using MinervaNeue, the infobox took up 1/3 of the page width, or 1/4 if I widened the browser window to full screen. BlackcurrantTea (talk) 05:34, 12 April 2019 (UTC)[reply]

Try adjusting the font size in your web browser settings instead of just enlarging everything. It might help. – Jonesey95 (talk) 07:44, 12 April 2019 (UTC)[reply]

John, I've also had good success with changing the default font size in the browser. In Safari, it's under Preferences > Advanced. In Chrome, it's Preferences, then scroll down to Appearances and select the Large or Very Large font size. In Firefox, go to Preferences or type about:preferences in the URL bar, and scroll down to set a font size that works better for you. The main advantage to this is that it will then work on all webpages, not just here. Whatamidoing (WMF) (talk) 18:49, 12 April 2019 (UTC)[reply]

I've dropped a note at Wikipedia talk:WikiProject Accessibility#Technical advice needed; Thanks. --Redrose64 🌹 (talk) 11:31, 12 April 2019 (UTC)[reply]

My rollback doesn't work

My Rollback seems to not be working. I've tried it several times on different pages, nothing happens. --Thegooduser Life Begins With a Smile :) 🍁 03:04, 12 April 2019 (UTC)[reply]

@Thegooduser: what skin are you using? I don't see anything in your common.js or vector.js that pops out as the culprit. --DannyS712 (talk) 03:10, 12 April 2019 (UTC)[reply]

Vector skin. (Default one) --Thegooduser Life Begins With a Smile :) 🍁 03:10, 12 April 2019 (UTC)[reply]

DannyS712 Rollback still does not work, tried to revert edit in my talk page, nothing. --Thegooduser Life Begins With a Smile :) 🍁 03:14, 12 April 2019 (UTC)[reply]

@Thegooduser: you have various settings in your global js. Try this link. Do you get the rollback links? Do they work? — xaosflux ^Talk 03:16, 12 April 2019 (UTC)[reply]

User:Xaosflux It works now, thank you. And can you block the Ip that keeps vandalizing my talk page? --Thegooduser Life Begins With a Smile :) 🍁 03:18, 12 April 2019 (UTC)[reply]

@Thegooduser: that was not a permanent fix, just a test. You probably have something conflicting in your many .js files or a gadget. You can start disabling some to find out which one. If you have an immediate vandal problem please post at WP:AIV or WP:AN/I. — xaosflux ^Talk 03:19, 12 April 2019 (UTC)[reply]

User:Xaosflux Can you remove my rollback, and add it back, I want to see if that fixes the problem. Thegooduser Life Begins With a Smile :) 🍁 03:20, 12 April 2019 (UTC)[reply]

@Thegooduser:

Done (that really shouldn't be the fix though). — xaosflux ^Talk 03:22, 12 April 2019 (UTC)[reply]

Resolved

Disabled confirmation prompt for rollback that was featured on the Admin's Newsletter. Thegooduser Life Begins With a Smile :) 🍁 19:37, 13 April 2019 (UTC)[reply]

It still remains to figure out which of your user scripts or other setting conflicted with the confirmation prompt function. --Pipetricker (talk) 13:44, 14 April 2019 (UTC)[reply]

I disabled the confirmation for rollback link Thegooduser Life Begins With a Smile :) 🍁 20:05, 14 April 2019 (UTC)[reply]

Template errors being shown on page when they should be "shown only in preview"

Tracked in Phabricator
Task T220854

This is currently displaying on Bill Shorten (at the top in red: Warning: Page using Template:Infobox officeholder with unknown parameter "religion" (this message is shown only in preview). – it seems that this shouldn't be displaying on the article itself? (The same is happening on Prabowo Subianto.) Mélencron (talk) 13:00, 12 April 2019 (UTC)[reply]

I saw similar yesterday (Thursday); null edit fixed it.

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

FWIW, I just purged Prabowo Subianto and it worked. Nardog (talk) 18:22, 12 April 2019 (UTC)[reply]

now seeing this in 2011 Singaporean general election :( Frietjes (talk) 18:23, 12 April 2019 (UTC)[reply]

Special:Search/"shown only in preview" currently returns ~900 articles. Nardog (talk) 18:30, 12 April 2019 (UTC)[reply]

The revisionid hack that Module:Check_for_unknown_parameters is using must have been broken. Every time a page gets edited - incrementing the revisionid - (but not a null edit) causes more and more pages to show the warning. Galobtter (pingó mió) 18:28, 12 April 2019 (UTC)[reply]

This must have something to do with the change described in #Tech News: 2019-15 above. Nardog (talk) 18:31, 12 April 2019 (UTC)[reply]

The one time I miss reading tech news.. Galobtter (pingó mió) 18:37, 12 April 2019 (UTC)[reply]

I've reported at phab: phab:T137900#5107898. From what I see, a purge works, but only until the next edit.. Galobtter (pingó mió) 18:58, 12 April 2019 (UTC)[reply]

The revisionid breakage is intentional. Coders of the modules in question should use mw.addWarning instead of revisionid. Mw.addWarning will only show up in preview anyway.--Snaevar (talk) 19:11, 12 April 2019 (UTC)[reply]

Krinkle appears to think that the module should work properly as written, if I am reading the phab ticket correctly. – Jonesey95 (talk) 20:17, 12 April 2019 (UTC)[reply]

The issue we see here is indeed a bug in the software and we are now working to fix it. Having said that, specifically for a Lua module that wants to show a warning at the top of previews, mw.addWarning is a perfect fit that would be better in general, and also happens to not be affected by today's bug. --Krinkle (talk) 21:13, 12 April 2019 (UTC)[reply]

For cs1|2, the philosophy of error-message-at-the-top of a preview is a non-starter. What is wanted is a function returning a boolean that indicates that 'this' rendering is live vs 'this' rendering which is preview. cs1|2 takes the position that error messages should be rendered where they occur. At cs1|2 the 'preview' detection is used to show malformed archive url links in preview mode so that an editor can use that information to repair the url; if not in preview, malformed archive urls are not rendered.

You would have us use mw.addWarning() but that won't work for us because (at least according to the documentation) it doesn't provide a return value so cannot be used to control how the calling module acts. Until there is a function that will return a boolean indicating the rendering mode, the {{REVISIONID}} hack will have to suffice (give us a proper function to call and we won't have to use a hack). The facility must already exist else how does mw.addWarning() know when to render the warning message? Expose that facility.

There is a problem with error messages like this one:

Warning: Barack Obama is calling Template:Cite web with more than one value for the "publisher" parameter. Only the last value provided will be used. (Help)

Barack Obama has 140-ish {{cite web}} templates. Which one(s) is/are the offender(s)? MediaWiki knows which is/are the offender(s) so it can put the message right there (various other error messages related to citations end up in the right place). Yeah, there are tools that editors have developed to assist in fixing these errors but those tools would be a lot less necessary if the error message is rendered adjacent to the template that has the problem.

Ok, I'm done ranting.

—Trappist the monk (talk) 22:41, 12 April 2019 (UTC)[reply]

You are generally correct in that mw.addWarning() won't serve your use case if your use case requires that the warning appear inline in the page rather than at the top of the preview. Your middle paragraph has things backwards, though: mw.addWarning() doesn't actually know whether the page is being rendered in preview mode or not, all it does is add a warning to the list of warnings. The preview page shows that list of warnings, when the normal article view does not.

A better justification for the fact that it should be possible to add something that returns a boolean for preview mode is that {{REVISIONID}} itself is already doing that. That was suggested in code review of the patch making the change, but there's also a good argument to be made that rendering differently in preview versus non-preview mode somewhat defeats the point of doing a preview, so we wound up preserving the current hack without officially condoning it by creating a non-hacky way to do it.

Perhaps the thing to do would be to consider ways to make mw.addWarning() work. For example, would it work to have mw.addWarning() return a token that produces  in the HTML (for both preview and non-preview mode), and have some JavaScript on the preview page that used that to associate the top-of-page warning with the location in the wikitext? Or have the token produce <span id="W123"></span> in the HTML (again for both preview and non-preview) so no JS is necessary? Anomie ⚔ 13:31, 13 April 2019 (UTC)[reply]

Backwards? More like wrong because, as I noted, the documentation does not say how mw.addWarning() works so readers like me are left to wonder just what is going on ... so we draw incorrect conclusions.

Your 'suggested in code review' link goes to a 404 page.

I don't know about js and and css as possible solutions to the page calling template with more than one ... message. Can css distinguish live from preview? Can js?

—Trappist the monk (talk) 13:59, 13 April 2019 (UTC)[reply]

Hmm. Our Gerrit installation has two UIs, and apparently it still defaults to the old one (there's a link at the bottom to set a cookie or something for the new UI). The link works for the new UI. It doesn't seem possible to link to a specific comment in the old UI, but gerrit:294774 will get you to the change.

Yes, both CSS and JS can affect preview renderings specifically. I suppose the CSS would have to consider both the normal preview and VisualEditor, I'm not very familiar with the latter. Anomie ⚔ 22:51, 13 April 2019 (UTC)[reply]

That bit about ve is concerning; (it is an abomination that I won't touch) but if it requires something special then what I am about to write may not be worth the time it takes me to write it.

cs1|2 wants to inspect archive urls and if they are flawed in certain ways not render them. Instead of the {{REVISIONID}} hack we might render archive links, dates, and static text wrapped in a <span>...</span> tag. When the archive links, dates, and static text may be displayed cs1|2 does not add a class. When errors of the kind that should cause cs1|2 to hide archive links, dates, and static text, cs1|2 adds class="cs1-archive-error" attribute where cs1-archive-error is defined in Module:Citation/CS1/styles.css. I don't really know how to write css selectors but each rendered html page has one of these:

<body class="mediawiki ltr sitedir-ltr mw-hide-empty-elt ns-0 ns-subject mw-editable page-Barack_Obama rootpage-Barack_Obama skin-vector action-view">

– live

<body class="mediawiki ltr sitedir-ltr mw-hide-empty-elt ns-0 ns-subject mw-editable page-Barack_Obama rootpage-Barack_Obama skin-vector action-submit">

– preview

We might then write something like this (recalling that I know nothing about writing css selectors)

body.action-view .cs1-archive-error {display: none;}

I haven't looked at cs1|2 yet to see how difficult this might be to implement there.

—Trappist the monk (talk) 00:50, 15 April 2019 (UTC)[reply]

Yesterday's deployment caused a bug in the handling of {{REVISIONID}}. Users Mélencron and Galobtter reported an issue with the Bill Shorten article, where a warning was displayed at the top of the page. I referenced addWarning() because it happens to be very good at doing that. Alas, it turned out that the bug in question actually affected both of these mechanisms, so it wouldn't have worked after all...

The {{REVISIONID}} magic word is still the supported and only way to detect preview mode for the purposes of producing different content within a page. The addWarning() function intentionally does not allow this, and actually internally stores its warnings separate from the page content. As optimisation for the subset of cases where the top of the page is your goal, this allows the parser result to be saved and re-used.

As of 21 minutes ago, this bug has been squashed. --Krinkle (talk) 00:53, 13 April 2019 (UTC)[reply]

Per Krinkle's post, this might be moot but I'm posting my understanding of the issue to save time for others (and to invite corrections).

MediaWiki has an edit stashing feature whereby (given certain normal conditions) previewing an edit causes the rendered result to be temporarily saved (stashed). If the edit is saved without changes, the stashed copy is used to display the page.
That is a significant performance boost because saving a previewed edit does not require much extra processing.
Modules need a way to show a prominent message when a page with an error is previewed, and a different result when it is saved.
Using mw.addWarning to show a warning at the top of the page when there might be 100 templates that could have caused the problem is hopeless (the warning usually needs to be next to the problem).
Displaying the same result for preview and save is very unhelpful when templates with an error are involved.

To illustrate the last point, {{convert|12|m|abbr=off}} is a normal {{convert}}, while {{convert|12|m|abbr=of}} has a typo. For the typo, convert displays an in-your-face error message when previewing, but a discreet asterisk when saved.

A prominent error message during preview is required to help the editor notice the problem.
A prominent error message when saved would unnecessarily degrade the article, so only an asterisk and error-tracking category are added.

Only a very small number of articles ever have a convert error so there is no performance problem from the fact that convert shows two different kinds of messages. I monitor Category:Convert errors and it is usually empty, with perhaps four problems per day. The situation is different for other cases where, for example, an infobox might have a typo that persists for a long time. That is a different situation which might need a different solution. Johnuniq (talk) 01:40, 13 April 2019 (UTC)[reply]

A large subset of the articles found by Special:Search/"shown only in preview" still need to be purged. --Pipetricker (talk) 12:43, 14 April 2019 (UTC)[reply]

Null edits Done. – Jonesey95 (talk) 18:44, 14 April 2019 (UTC)[reply]

How to become a MediaWiki hacker

Some of you might be interested in the upcoming presentation described at mw:Tech talks#Upcoming tech talks 2019 season. Srishti is going to give a general talk about how developers and their allies (designers, documentation writers, testers, etc.) can contribute to MediaWiki and related software. If you are (a) a dev-type person yourself or (b) hang out at this page, then you might find this useful.

Time: April 24, 2019 at 18:00 UTC (11:00 a.m. PDT), for about 45 minutes

Place: https://www.youtube.com/watch?v=SXyeRujCrAs

If you're online during the talk, then there will probably be an opportunity to ask questions (maybe on m:IRC?). These talks are normally recorded, so you can watch it later. Whatamidoing (WMF) (talk) 16:02, 12 April 2019 (UTC)[reply]

Whatamidoing (WMF), looks like "Wikimedia" is spelled wrong in the title of that YouTube page. (Didn't know who else to ping, sorry!) Enterprisey (talk!) 06:49, 15 April 2019 (UTC)[reply]

Removal of braces for talk and contribs

Tracked in Phabricator
Task T220767

Please do visit the page [Users]. I would like to know the reason why the braces for talks and contribs present in that specific page is removed. I guess this has been done in all wiki projects. Adithyak1997 (talk) 14:07, 13 April 2019 (UTC)[reply]

@Adithyak1997: appears to to be a WP:ITSTHURSDAY bug, I've opened phab:T220885. — xaosflux ^Talk 15:33, 13 April 2019 (UTC)[reply]

@Xaosflux: Thanks for reporting in phab and replying. Please confirm whether there is any typo with the word 'preset' used by you in phab. You can remove this message once you confirm it. Adithyak1997 (talk) 15:38, 13 April 2019 (UTC)[reply]

@Adithyak1997: Thanks, tweaked. Note this has been merged to larger ticket phab:T220767. — xaosflux ^Talk 15:45, 13 April 2019 (UTC)[reply]

Ok. Adithyak1997 (talk) 15:45, 13 April 2019 (UTC)[reply]

@Xaosflux: Looks like gerrit:499364 broke it by changing a method (Linker::userToolLinksRedContribs()) used by more than just the one special page that patch was trying to change. I'm not at liberty to copy that into Phabricator at the moment, if you could do so that might help. You might also CC the people involved with that change. Anomie ⚔ 23:13, 13 April 2019 (UTC)[reply]

@Anomie: thanks and copied in to phab. — xaosflux ^Talk 23:41, 13 April 2019 (UTC)[reply]

Xi Jinping

Ah, Great. Now I can't get Twinkle's rollback function to work for this page. --Thegooduser Life Begins With a Smile :) 🍁 20:06, 13 April 2019 (UTC)[reply]

What goes wrong? The page has pending changes protection so maybe a Twinkle feature doesn't work as normally. PrimeHunter (talk) 20:48, 13 April 2019 (UTC)[reply]

I can't 'ROLLBACK (VANDAL)' like I can do on other pending change protected pages. --Thegooduser Life Begins With a Smile :) 🍁 20:51, 13 April 2019 (UTC)[reply]

The two latest edits are by a user who reverted their own edit. Rollback reverts all consecutive edits by the latest editor. This currently means there is nothing to roll back. PrimeHunter (talk) 20:57, 13 April 2019 (UTC)[reply]

Watchlist for WikiProjects

Is there a way to set-up a WikiProject based Watchlist? Mitchumch (talk) 20:08, 13 April 2019 (UTC)[reply]

User:MusikAnimal/customWatchlists --Thegooduser Life Begins With a Smile :) 🍁 20:10, 13 April 2019 (UTC)[reply]

Is this something I can add to a WikiProject or is this only added to a users "Preferences" tab? Mitchumch (talk) 22:59, 13 April 2019 (UTC)[reply]

@Mitchumch: Help:Public watchlist – Finnusertop (talk ⋅ contribs) 00:38, 14 April 2019 (UTC)[reply]

@Mitchumch: Good description in Help:Public watchlist. WP:WikiProject Chemistry has this box: Template:Recent changes in Chemistry. The list was made with WP:AWB and an external editor to create the wikilinks. Christian75 (talk) 15:48, 16 April 2019 (UTC)[reply]

It could be really nice if Special:RecentChangesLinked had the option to show both the page and the talk page for a given page. Then all the "Category:WikiProject X articles" (e.g. Special:RecentChangesLinked/Category:WikiProject Chemistry articles) could be used as a "watchlist" for the WikiProjects. Is this request in phab:? Christian75 (talk) 16:52, 16 April 2019 (UTC)[reply]

To editor Christian75: See phab:T14889. – Ammarpad (talk) 17:10, 16 April 2019 (UTC)[reply]

Template:Orphan no longer invisible?

Resolved

– I was the dumbass all along. ♠PMC♠ (talk) 05:19, 14 April 2019 (UTC)[reply]

{{Orphan}} used to become invisible after a month or two, but as of late (not exactly sure when) it seems to have become permanently visible, and I don't see any changes in the template's history. Does anyone know what caused that, and how it can be reverted back to the previous behavior? ♠PMC♠ (talk) 04:49, 14 April 2019 (UTC)[reply]

Where can an example be seen? Openlaw has orphan at the top and it is not visible, although there is a hidden category. Johnuniq (talk) 05:13, 14 April 2019 (UTC)[reply]

@Premeditated Chaos: my script (which you just started using) always shows Orphan templates --DannyS712 (talk) 05:16, 14 April 2019 (UTC)[reply]

Facepalm x2 combo. Thanks, lol. ♠PMC♠ (talk) 05:19, 14 April 2019 (UTC)[reply]

Edit summary drop-down

I'm glad to see that visual editor edit summary box will now show past summaries in a drop-down box ([5], mentioned in the weekly update above) but I don't like that the first one is automatically selected, so I can't use the ctrl+enter shortcut to submit it. Is there a way to change this functionality? Reywas92^Talk 06:08, 14 April 2019 (UTC)[reply]

I and Whatamidoing (WMF) both left a comment on the task that you linked therein. You don't need to support it any further, just subscribe to the task and either it will change there or on a task linked from there. --Izno (talk) 23:35, 14 April 2019 (UTC)[reply]

Press the Escape key if you need to make it not-select the wrong edit summary. Whatamidoing (WMF) (talk) 18:29, 15 April 2019 (UTC)[reply]

URLs in Wikidata Templates

Many Infobox templates (e.g. {{Infobox person/Wikidata}} {{Infobox software}}) are capable of using URL from Wikidata, but the result of rendering tends to be terrible with URLs that are even slightly longer than usual -- they just stretch the entire infobox with them. This happens with the website (P856 or P1581) field of Infobox person as well as P1324 for Infobox software. I figured the solution should take something like Module:URL or wdib.url2, but failed to make it work for infobox person around all the {{if empty}} magic and stuff. Would someone else please take a look into this and find the correct way to wrap these things?

Things I have tried for infobox person:

Wrapping the entire if empty in URL: Wikidata edit button explodes in my face
Wrapping the entire thing in wdib.url2: Field is gone
Wrapping the two getValues separately in wdib.url2: Field is gone
Using wdib.getWebsite for P856 and forgetting about P1851 for now: Field is gone

--Artoria 2e5 🌉 20:49, 14 April 2019 (UTC)[reply]

Missing link

Is the word "StumbleUpon" not rendering for anyone else on https://en.wikipedia.org/w/index.php?title=Folksonomy&oldid=891701937#Examples? Oddly enough, if I edit it to [[Stumbleupon]] and click "show preview" it renders as it should, but if I revert back to CamelCase and preview, it again shows only " • : content discovery engine". Daß Wölf 21:14, 14 April 2019 (UTC)[reply]

@Daß Wölf: I can still see it. --DannyS712 (talk) 21:19, 14 April 2019 (UTC)[reply]

@Daß Wölf: I think something like this was reported five or six years back - have you looked in the VPT archives? --Redrose64 🌹 (talk) 22:58, 14 April 2019 (UTC)[reply]

Sorry, false alarm. I forgot to look it up in View selection source and Inspect element. The link shows up normally in HTML, but has special CSS formatting in Inspect element, so it's something in my browser, most likely the adblock. Daß Wölf 23:20, 14 April 2019 (UTC)[reply]

Template import issue

I've imported {{Coord}}, including sub-templates and modules, from this project to Wikispecies. However the page at species:Repositories/Wikidata is giving "Lua error: callParserFunction: function "#coordinates" was not found." errors. what's missing? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:17, 15 April 2019 (UTC)[reply]

#coordinates is apparently a parser function that does not exist on wikispecies. It looks like it is part of the GeoData extension. See https://www.mediawiki.org/wiki/Extension:GeoData#Parser_function for more details. See Special:Version here on en.WP compared to Special:Version on en.Wikispecies. – Jonesey95 (talk) 16:47, 15 April 2019 (UTC)[reply]

Tech News: 2019-16

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

All wikis now have the TemplateWizard for the wikitext editor.

Changes later this week

The new version of MediaWiki will be on test wikis and MediaWiki.org from 16 April. It will be on non-Wikipedia wikis and some Wikipedias from 17 April. It will be on all wikis from 18 April (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 17 April at 15:00 (UTC). See how to join.

Future changes

Wikidata will get a new constraint status called suggestion. This will change how the WikibaseQualityConstraints constraint checking API works. [6][7]
You can test the depicts property for structured data on Commons.

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

23:00, 15 April 2019 (UTC)

The first item above may result in a greater need for the Template Data programming code that is stored in template documentation pages. Those of you who understand and are interested in the esoterica of adding Template Data may want to give some attention to the templates listed at Wikipedia:TemplateData. – Jonesey95 (talk) 06:16, 16 April 2019 (UTC)[reply]

Wikipedia:Vorlagenfehler/Vorlage:TemplateData

Resolved

This revision to the TemplateData code block in a template's documentation appears to have resulted in that template's documentation page being added to Category:Wikipedia:Vorlagenfehler/Vorlage:TemplateData. Based on web translation, that looks like a category used for pages with TemplateData errors. Why is it in German? How can we activate an English-language version of this category here on en.WP? It would be useful to have such a category to catch TemplateData errors. – Jonesey95 (talk) 06:04, 16 April 2019 (UTC)[reply]

It comes from {{Format TemplateData}} which was imported from de:Vorlage:TemplateData by Xaosflux. PrimeHunter (talk) 09:06, 16 April 2019 (UTC)[reply]

Thanks. For some reason, I didn't think to search for the category name in Template space. Silly me. I have translated the template's error message and category into English and created the maintenance category. – Jonesey95 (talk) 10:08, 16 April 2019 (UTC)[reply]

Moving files

How I can move files? There is no button "move" like in the articles. Eurohunter (talk) 13:59, 16 April 2019 (UTC)[reply]

You cannot move files because only users with (movefile) userright can do so. You should use {{Rename media}} template to request renaming of files. – Ammarpad (talk) 14:24, 16 April 2019 (UTC)[reply]

@Ammarpad: Thanks. Eurohunter (talk) 14:42, 16 April 2019 (UTC)[reply]

Solving an issue stated in Community Portal

Please do check if somebody can help me out for the problem stated in Incubator. Adithyak1997 (talk) 14:06, 16 April 2019 (UTC)[reply]

Servers under maintenance

Just for documentation.

Error Our servers are currently under maintenance or experiencing a technical problem. Please try again in a few minutes. See the error message at the bottom of this page for more information. If you report this error to the Wikimedia System Administrators, please include the details below. Request from 98.21.227.217 via cp1085 cp1085, Varnish XID 371130561 Error: 503, Backend fetch failed at Tue, 16 Apr 2019 18:36:41 GMT

— Vchimpanzee • talk • contributions • 18:43, 16 April 2019 (UTC)[reply]

I saw a few as well, looks like there's been quite a few since 18:14 UTC. (30.5K/min peak at 19:03) rchard2scout (talk) 19:09, 16 April 2019 (UTC)[reply]

It's been at less than 10/min since about 19:20, so it seems to be fixed for now. I saw some WMF Operations people in IRC trying to find the root cause, it doesn't seem like there's anything us mere ~~mortals~~ volunteers can do right now but wait for the incident report. rchard2scout (talk) 20:02, 16 April 2019 (UTC)[reply]

System message

Resolved

Where can I find the system message that replaced MediaWiki:Movepage-summary? - FlightTime (open channel) 20:59, 16 April 2019 (UTC)[reply]

@FlightTime: perhaps MediaWiki:Movepagetext-noredirectfixer? — xaosflux ^Talk 22:01, 16 April 2019 (UTC)[reply]

@Xaosflux: No, I found that one earlier. I was thinking we might be running MessageCommons, but we're not. I've been actioning file rename request and the page header where you enter the new filename needs some link target updates. I'll get a screenshot in a few and post a link here. Thanx for your reply. - FlightTime (open channel) 22:37, 16 April 2019 (UTC)[reply]

@FlightTime: that page includes MediaWiki:Movepagetext, which has some conditional for file namespace - if that's not it, link a screen shot and I'll try to help! — xaosflux ^Talk 22:56, 16 April 2019 (UTC)[reply]

@Xaosflux: It's displayed just below the message you linked to (had to upload the screenshot to my wiki) here. It's no big deal, I just wanted to update the lime green link targets. - FlightTime (open channel) 22:59, 16 April 2019 (UTC)[reply]

@FlightTime: those are in MediaWiki:Movepagetext view source just open an edit request on that page's talk and we can process for you. — xaosflux ^Talk 23:14, 16 April 2019 (UTC)[reply]

Ok :P, Thanx. - FlightTime (open channel) 23:17, 16 April 2019 (UTC)[reply]

Back to Top

Is it possible to have a "back to top" link added to the footer, of automatically appear at end of page, say, after categories, or even in the categories box. I mostly read, and often edit, via iPad, and getting back up to select watchlist or search or some other option is creating callouses on pages like this ClubOranje^T 08:18, 17 April 2019 (UTC)[reply]

@ClubOranje: Try User:Danski454/goToTop.js --DannyS712 (talk) 08:21, 17 April 2019 (UTC)[reply]

Thanks @DannyS712:, works fine. I do still think it would be worth adding it into page coding so it appears automatically for everyone without having to install a script. Not everyone knows how or has the confidence to. ClubOranje^T 09:10, 17 April 2019 (UTC)[reply]

ClubOranje, in minerva (default mobile skin), if you enable Beta features, you have a back to top button. —TheDJ (talk • contribs) 09:14, 17 April 2019 (UTC)[reply]

@ClubOranje: See this blog post - I think Safari on iPad supports this depending on your version. — xaosflux ^Talk 13:09, 17 April 2019 (UTC)[reply]

As noted at Wikipedia:Village pump (technical)/Archive 172#Is it possible to have a floating 'sidebar' that follows you up?, there is {{Skip to top and bottom}} and other templates mentioned in its doc. --Redrose64 🌹 (talk) 13:40, 17 April 2019 (UTC)[reply]

Nested refs error?

Tracked in Phabricator
Task T22707

Can't someone figure out why English phonology#Onset is throwing up the error Cite error: A list-defined reference named "FOOTNOTEMcColl Millar200763-64" is not used in the content (see the help page).? It has multiple instances of {{sfnp}}, inside {{efn}} inside {{notelist|refs=}}, and for some reason only one of them is resulting in an error. Upon toying with the code on Special:ExpandTemplates, it seems MediaWiki is parsing nested <ref>...</ref> tags in a peculiar way. Nardog (talk) 13:37, 17 April 2019 (UTC)[reply]

I'm pretty sure it's been pointed out before that WP:LDR does not coexist happily with either {{efn}} or {{sfnp}}. It may be in the archives of Wikipedia talk:Citing sources or a similar page. Trappist the monk may remember. --Redrose64 🌹 (talk) 13:46, 17 April 2019 (UTC)[reply]

@Nardog: Aha, I've found Template talk:Efn#This template goes crazy when things get long and phab:T22707 but I'm pretty sure that there are other threads on this matter elsewhere. In short: don't do it. --Redrose64 🌹 (talk) 14:07, 17 April 2019 (UTC)[reply]

@Redrose64: Thanks. I wonder, then, what is the best way to offer an in-article list of footnotes. I've seen various ways, from {{ref}}/{{note}} to simply superscript numerals and an ordered list. <ref group="xxx">...</ref> seems most straightforward but the long superscript links ("^{[xxx 1]}") can be annoying and disrupting the flow of the text. Nardog (talk) 14:44, 17 April 2019 (UTC)[reply]

Just use {{efn}} in the documented way (With lower-alpha labels), but put the {{notelist}} in the section of prose rather than in a section at the bottom. --Redrose64 🌹 (talk) 15:07, 17 April 2019 (UTC)[reply]

Ah, obvs. That wouldn't work if the article already uses {{efn}} for a footnotes section for the entire article, but such an article structure would probably be stylistically objectionable. Nardog (talk) 15:36, 17 April 2019 (UTC)[reply]

You could use different groups, each of which has its own templates, see Template:Efn#Template use by reference group type. --Redrose64 🌹 (talk) 18:50, 17 April 2019 (UTC)[reply]

Sorry, I have no special knowledge of this problem. I know it exists and I know that its a right pain, but beyond that, nothing.

—Trappist the monk (talk) 19:28, 17 April 2019 (UTC)[reply]

Administrators

How to find administrators which recently did any action? Eurohunter (talk) 14:48, 17 April 2019 (UTC)[reply]

toollabs:apersonbot/recently-active –xeno^talk 14:53, 17 April 2019 (UTC)[reply]

Special:Log/block is effective (or Special:Log/delete or Special:Log/protect). Johnuniq (talk) 00:50, 18 April 2019 (UTC)[reply]

@Xeno: @Johnuniq: Thanks Eurohunter (talk) 10:21, 18 April 2019 (UTC)[reply]

Duplicate wikilink scrubber

Do we have any good tools for scouring away duplicate wikilinks from sections like Mahesh Bhatt#Filmography? Years ago I remember seeing some javascript tools. I tried two of them, but they didn't work consistently. Seems like the things that it would need to do are:

Spot duplicates
Be able to convert piped wikilinks to text. (Ex: [[Om Prakash (cinematographer)|Om Prakash]] → Om Prakash)
Leave the first instance of a link, or a number of links the user specifies. "Keep the first _2_ links"
I don't know that running it on an entire article would always be the best way to go. If there was some way to limit it to when you click Edit on a section, that might be ideal, unless it could process each section uniquely.
Sometimes sections (like a film soundtrack) have introductory text that may intuitively have wikilinks that are duplicated in a secondary area like a soundtrack table. Maybe some flexibility would be helpful there.

Thoughts on this? It's a massive headache to clean up WP:OVERLINKing, and sometimes I run into people who are here solely for that purpose.[8][9][10]. Thanks, Cyphoidbomb (talk) 14:52, 17 April 2019 (UTC)[reply]

WP:AWB will let you hack on duplicate wikilinks. --Izno (talk) 15:49, 17 April 2019 (UTC)[reply]

Nonsense dates

Nonsense dates appear on the screen tables for running the app for "Page statistics" from the edit history page of many if not most articles, in the fields for "First date" and "Last date". The two that I have just run are Herman Melville here [11], and the film article for The Favourite. Could someone look at this? CodexJustin (talk) 14:54, 17 April 2019 (UTC)[reply]

@CodexJustin: I see what you mean. For those who haven't found them, they are in the Top editors section, in both the "First edit" and "Latest edit" columns, where dates like "2013-55-29 18:" and "2018-11-9 17:" are displayed. These are linked to diffs, from which I see that these two dates should have been displayed as "2013-11-29 18:55" and "2018-03-09 17:11" respectively. Something is dropping the true month value, and moving the minutes value to the position intended for the month; it might be a simple matter of "MM"/"mm" confusion in a date formatting string. It's definitely one for the tool maintainer, you should file a Phabricator ticket. --Redrose64 🌹 (talk) 22:09, 17 April 2019 (UTC)[reply]

Probably introduced here. I'll create a pull request tonight (as in, somewhere between 17:00 and 21:00 UTC) if MusikAnimal doesn't fix it first. rchard2scout (talk) 10:54, 18 April 2019 (UTC)[reply]

Thanks for the ping, and the offer to create a PR! :) I went ahead and deployed a fix. — MusikAnimal ^talk 14:04, 18 April 2019 (UTC)[reply]

Dark mode / prefers-color-scheme

With Media Queries Level 5 (and in particular, prefers-color-scheme) getting moved into Google Chrome and Mozilla Firefox (67) (Safari has supported this since "dark mode" was added to MacOS Mojave), I'm wondering if it's not time to start including support for this within the various skins available here? Windows also has a "dark mode" toggle, and it appears this system value is used by both Chrome and Firefox to set the value within the browser (so websites can adapt to the mode selected by the user). IIRC, Microsoft is going to switch to using Chrome for Edge at some point, so that would cover all the major browsers for support. —Locke Cole • t • c 06:33, 18 April 2019 (UTC)[reply]

Locke Cole https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/skins/Vector/ ;) —TheDJ (talk • contribs) 08:01, 18 April 2019 (UTC)[reply]

@Locke Cole: As far as I know the WMF Community Tech team has plans to start investigating meta:Community Wishlist Survey 2019/Reading/Night mode soon in phab:tag/night-mode (hence that project planning workboard in Phabricator is still quite empty). --AKlapper (WMF) (talk) 08:03, 18 April 2019 (UTC)[reply]

No tools

Why I have no tools while editing? I remember I changed something. Eurohunter (talk) 08:30, 18 April 2019 (UTC)[reply]

@Eurohunter: There are different tools depending on settings. Maybe you disabled "Enable the editing toolbar" at Special:Preferences#mw-prefsection-editing. If this doesn't help then say whether you have the wanted tool when you are logged out, and briefly describe the tool. PrimeHunter (talk) 08:49, 18 April 2019 (UTC)[reply]

@PrimeHunter: Yes I had it disabled. This is new toolbar. How I can enable old one? Eurohunter (talk) 08:54, 18 April 2019 (UTC)[reply]

@Eurohunter: Special:Preferences#mw-prefsection-gadgets has "Enable the legacy (2006) editing toolbar". PrimeHunter (talk) 08:58, 18 April 2019 (UTC)[reply]

@PrimeHunter: Thanks. Eurohunter (talk) 10:20, 18 April 2019 (UTC)[reply]

Double notifications

Tracked in Phabricator
Task T203893

Per User talk:Iridescent#Double notification, is there any way we can disable the double-notification when a username is linked in both the text and the edit summary? I was aware this was an issue when "ping from edit summary" was first introduced (example), but thought it had been fixed months ago. Given the habit many editors have of copying the first line of their comment (which is also where the @whoever ping is most likely to be) to use as the edit summary, this is a bug that's going to keep on annoying people. ‑ Iridescent 09:04, 18 April 2019 (UTC)[reply]

This is phab:T203893 with no apparent work. PrimeHunter (talk) 09:28, 18 April 2019 (UTC)[reply]

MediaWiki internal error

Tracked in Phabricator
Task T221347

Anyone else getting this error white trying to edit? I've had it happen intermittently three times around the past half hour while either trying to view changes or submit changes. Here's a sample of the output, where it's throwing a ConfigException. Opencooper (talk) 10:42, 18 April 2019 (UTC)[reply]

I have also seen something like this. It may be to do with the PHP7 beta feature. Has anybody not using PHP7 seen this error? BethNaught (talk) 10:56, 18 April 2019 (UTC)[reply]

Filed phab:T221358. — regards, Revi 11:54, 18 April 2019 (UTC)[reply]

Looks like phab:T221347 already exists for this problem. Anomie ⚔ 11:58, 18 April 2019 (UTC)[reply]

Definitely something to do with PHP7, I'm getting this every few minutes too. Gangster8192 12:17, 18 April 2019 (UTC)[reply]

FYI, it seems to have been resolved as of 12:20:39 UTC, although the root cause has not yet been determined. Watch the Phabricator task for further details. BJorsch (WMF) (talk) 12:57, 18 April 2019 (UTC)[reply]

Required property "paramOrder[4]" not found.

Having incorrectly edited {{Colorbull}} with the intention of adding a description option, I am unable correct this edit (in which I mistakenly included <span title=n> inside <span style=n>) without being greeted by this error message: Required property "paramOrder[4]" not found. I have tried reverting my edit but to no avail. Please help, thanks. Neveselbert (talk · contribs · email) 10:57, 18 April 2019 (UTC)[reply]

I also got the error message on all attempts to save an edit, including a null edit. It's from MediaWiki:Templatedata-invalid-missing. I noticed you had edited Template:Colorbull/doc afterwards [12] so I reverted those edits. Then I could edit {{Colorbull}} without problems. I don't work with TemplateData so I don't know what was wrong with it. I'm surprised it could prevent the template from being edited. PrimeHunter (talk) 21:37, 18 April 2019 (UTC)[reply]

Special:Nuke inconsistently working

For the past few months I've noticed Special:Nuke is very inconsistent. Maybe 1/3 to 1/2 of the time it loads for 20/30 seconds, then sends it to a WMF error screen. When it does work it's still extremely slow to load the list of pages, even (I tested) when it's 2, 1, or 0 pages, but once I'm there and press delete it very quickly deletes everybody without trouble. Anyone else notice this, and is this a concern? The Blade of the Northern Lights (話して下さい) 16:45, 18 April 2019 (UTC)[reply]

I would guess this is phab:T197940. --Izno (talk) 17:00, 18 April 2019 (UTC)[reply]

Ah. At least someone said something about it, then. The Blade of the Northern Lights (話して下さい) 17:11, 18 April 2019 (UTC)[reply]

AutoEd

Wikipedia:AutoEd doesn't works? I tried it on few articles but it never did anything. Eurohunter (talk) 20:41, 18 April 2019 (UTC)[reply]

I went to [13] and then ran importScript('Wikipedia:AutoEd/complete.js'); which yielded jQuery.Deferred exception: autoEdUnicodify is not defined. Looking at Wikipedia:AutoEd/complete.js, it's easy to see why. It's yet another case of someone trying to "structure" their code by splitting it up across different pages and then loading those pages with importScript or mw.loader.load. Needless to say, that has never worked and never will. importScript and mw.loader.load are both async and neither allow for a callback to be ran when they have finished fetching a script. This means that they cannot be used to fetch something that is needed for other code to work. They are only fine to use when loading completely unrelated and contained scripts. Nirmos (talk) 01:33, 19 April 2019 (UTC)[reply]

[:4-1] DEF

[1]