Jump to content

Wikipedia:Village pump (technical): Difference between revisions

From Wikipedia, the free encyclopedia
Content deleted Content added
Line 482: Line 482:
21:22, 26 April 2021 (UTC)
21:22, 26 April 2021 (UTC)
<!-- Message sent by User:Johan (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&oldid=21391118 -->
<!-- Message sent by User:Johan (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&oldid=21391118 -->

== Template:verify quote ==

In [https://en.wikipedia.org/w/index.php?title=Operation_Sandblast&diff=1020052269&oldid=1020031815 this edit], I just used [[:Template:verify quote]] for the first time. As suggested on that page, I used a <tt>text=</tt> parameter to indicate what the perceived problem was. But viewing the page in Firefox, I do not see ''any'' text displayed when mousing over the spot. I usually have JavaScript disabled in Firefox, but enabling it for both wikipedia.org and wikimedia.org made no difference.

Huh? --[[Special:Contributions/184.147.181.129|184.147.181.129]] ([[User talk:184.147.181.129|talk]]) 22:26, 26 April 2021 (UTC)

Revision as of 22:26, 26 April 2021

 Policy Technical Proposals Idea lab WMF Miscellaneous 
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. Discussions are automatically archived after remaining inactive for five days.


Proposal for finding longstanding bad articles

"width=" parameter of Infobox broken

Hello, I added a personalised infobox to my user talk page learning to do it from Wikipedia:Thinking outside the infobox. I added it on 27 December 2020‎, with the "width=" parameter. It worked fine then.

But sometime between 27 December 2020 & 28 March 2021, the "width=" parameter got broken and this parameter does not respond. The problem is in all of Wikipedia and can be seen in Wikipedia:Thinking outside the infobox itself where infoboxes like the ones with "width=200px" and "width=245px" show up with the same width.

This parameter is broken even in the older revisions of my user talk page, when it used to work fine. Can someone fix it? Thanks. Cheers! CX Zoom (talk) 15:42, 19 April 2021 (UTC)[reply]

@CX Zoom: a workaround seems to be to replace width=245px with style="width:245px;", but it should be fixed. Peter coxhead (talk) 15:59, 19 April 2021 (UTC)[reply]
The simple infoboxes on that page will soon not work or will be removed (for certain values of soon). You will need to use {{infobox}} to make an infobox.
Do not use "width=Xpx" in general. It is obsolete HTML and is not guaranteed to work in the future, notwithstanding any issues with MediaWiki. Coxhead's suggested fix should be preferred regardless.
width=Xpx does not work because that is also invalid HTML3.X even if it were not obsoleted in our current version of HTML. Either you must use a simple number width=X or you must wrap the measure (px) in quotation marks along with the X value: width="Xpx", I believe. Izno (talk) 16:33, 19 April 2021 (UTC)[reply]
@Izno: I don't think it's quite so simple. width works with table syntax and class="wikitable":
Example with class="wikitable" width=500px
but not with class="infobox":
Example with class="infobox" width=500px
Peter coxhead (talk) 19:09, 19 April 2021 (UTC)[reply]
Shrug. You provided the correct solution. I'm not going to try to fix the incorrect solution any more than I already have. Izno (talk) 19:21, 19 April 2021 (UTC)[reply]
The infobox class has an explicit width of 22em. As a deprecated attribute, the table width attribute is only the very very last fallback value that will be used. Wikitable class does not have any other explicit width defined, so it works, infobox has 22em and thus the width attribute is ignored. —TheDJ (talkcontribs) 08:51, 20 April 2021 (UTC)[reply]
Ideally, width= would be treated as a parameter, as in a normal template, that replaces the default width given in the CSS. This avoids editors having to provide CSS style information, which they shouldn't need to understand just to change the width of a box. Peter coxhead (talk) 09:04, 20 April 2021 (UTC)[reply]
@Peter coxhead: Thank you for fixing my infobox by using the work-around solution. CX Zoom (talk) 10:00, 20 April 2021 (UTC)[reply]
@CX Zoom: In markup like {| class=infobox width=500px or {| class=infobox style="width:500px;", the two characters {| start a table as you know - they yield the HTML <table> tag; everything after those two characters comprise the attributes (n.b. not parameters) of that tag. So the first instance here emits <table class=infobox width=500px> and the second emits <table class=infobox style="width:500px;">, each with two attributes. The class= and style= attributes have been valid on all HTML elements since HTML 4.0 way back in 1997 and are still supported by all major browsers, they'll probably remain for some decades more. The width= attribute was part of the table element in HTML 3.2 and HTML 4.01, but was declared obsolete in HTML5 (this means that browsers need not support it, so you shouldn't rely on it functioning as it used to do), with the recommendation to use CSS instead. This is provided directly by the style= attribute and indirectly by the class= attribute. In CSS, the width: property has been valid right from the start in 1996; one thing about CSS is that they (almost?) never mark something as obsolete, so if the declaration width:500px has ever been valid (which it has), then it may safely be assumed that it always will be valid. It's also a matter of precedence: Wikipedia's style sheets have the declaration width: 22em; for the infobox class, and essentially, the class= attribute has higher precedence than the width= attribute but lower precedence than the style= attribute. --Redrose64 🌹 (talk) 13:14, 20 April 2021 (UTC)[reply]
@Redrose64: Tbh I as an amateur in coding— didn't know that parameter and attribute were two different things. Moreover, I was unaware that certain attributes in HTML may become obsolete. I thought of it as some bug. But now I know why the infobox wasn't showing up as intended. Thanks! CX Zoom (talk) 19:41, 21 April 2021 (UTC)[reply]

Proposal for a dark-mode gadget addition (before Earth Day 22 April?)

Hi all,
I'd like to propose a new gadget addition to the “appearance” specific gadgets for Vector (legacy & modern) and MinervaNeue skin: Dark mode.

The user script has been already around for more than a year. It's the outcome of my personal work (I'm also employee of the Wikimedia Foundation and the scripts are under my Foundation account, but I've mainly worked on it in my free time) and the work of my colleagues and or peers in the Wikimedia Design team Alexander Hollender, MusikAnimal and furthermore Carolyn Li-Madeo, Jon Robson or Joe Matazzoni and was first discussed at Phabricator task T221425. Since April 2020 it has been tested by a number of different people and requested to be made further available. I'd like to offer it as gadget for users to simply switch it on and gather more feedback on possible edge cases. In general from testing and browsing over days with it there have been very few issues discovered due to the simple modern browser rendering approach. Try it out by adding mw.loader.load( 'https://en.wikipedia.org/w/index.php?title=User:Volker_E._(WMF)/dark-mode.js&action=raw' ); // Backlink: User:Volker E. (WMF)/dark-mode.js, per VPT discussion to your common JavaScript. Note that this implementation has a lil flash issue due to the CSS being triggered by JS and gadget JS being loaded late. The gadget solution at https://en.wikipedia.org/wiki/User:Volker_E._(WMF)/MediaWiki:Gadget-dark-mode.css as CSS only should be free of this flash! Compare Blackskin gadget, thanks @MusikAnimal: for the hint.

Why Earth Day? On some monitor types, specifically OLEDs there should be a (small) power saving by using dark mode. This has been discussed at length in several places, I'll put just one link to iFixit.

Please let me know your questions and thoughts and thanks for considering it. –Volker E. (WMF) (talk) 21:48, 20 April 2021 (UTC)[reply]

  • Support The CSS has already undergone extensive testing. If there aren't any objections, I would love to see this promoted to gadget status come Earth Day. MusikAnimal talk 22:08, 20 April 2021 (UTC)[reply]
  • Fixed the code to be based on importScript, hope you don't mind - I also support assuming I don't identify any issues in the script now that I've personally added it to my css. -bɜ:ʳkənhɪmez (User/say hi!) 22:12, 20 April 2021 (UTC)[reply]
    • Update - not sure if this is fixable or not, but the script automatically enables dark mode for me on every page I go to, instead of being toggleable - which would mean that any user would have to enable/disable/re-enable this gadget any time they wanted to switch. IMO this is not acceptable - dark mode should be toggleable, and while I agree that it should be built-in and easy to use, forcing users to edit their css pages when they want to enable/disable the feature is too much imo. That being said, I still support it being a gadget so that any user who wants permanent dark mode can do so. -bɜ:ʳkənhɪmez (User/say hi!) 22:15, 20 April 2021 (UTC)[reply]
      Toggleable is a bizarre requirement in the general. None of the other skins today are like that. You can change the URL or you can change the skin in preferences, but the first isn't permanent without a script of its own and the second is functionally equivalent to, er, turning the skin off and on. Using the word "acceptable" is clearly and simply wrong. Izno (talk) 22:23, 20 April 2021 (UTC)[reply]
      @Berchanhimez This is explained above. If we have a toggling mechanism, we have to use JavaScript to first check your setting and then apply the dark mode. So if you have dark mode toggled on, there will be a brief "flash" before it gets applied. Try enabling the old dark-mode script to see what we mean. Then compare how the "Use a black background with green text" gadget behaves. It doesn't have any flashes, because the CSS is behind mw:ResourceLoader. Unfortunately we cannot have both a toggle link and no flashes without a native MediaWiki solution, which is not going to happen anytime soon. MusikAnimal talk 22:27, 20 April 2021 (UTC)[reply]
      To both - acceptable was not intended to mean that this can't be implemented as a gadget in its current state. I agree that it should be a native solution to enable more "toggleability" - but until such I do still support it being enabled as a gadget. That's the only issue I identified and figured I'd point it out here for consideration by others. I appreciate the work done on this script and think it is a good step. -bɜ:ʳkənhɪmez (User/say hi!) 23:36, 20 April 2021 (UTC)[reply]
      Is it possible to have a user script that adds a widget to every page to toggle the dark mode gadget? isaacl (talk) 15:36, 21 April 2021 (UTC)[reply]
      That is possible! The toggle would probably have to force the user to refresh the page, though. MusikAnimal talk 19:48, 21 April 2021 (UTC)[reply]
       Done User:SD0001/dark-mode-toggle.js @MusikAnimal maybe make this also a gadget? – SD0001 (talk) 03:19, 22 April 2021 (UTC)[reply]
      @SD0001 Thank you! Yes, we can put it in with the same gadget definition. However I was thinking of moving the toggle link in #p-personal like Volker's script and Nightpedia do it, along with sun/moon icon. Since there's no CSS class added to the body element anymore, we'd have to use JavaScript to determine which icon to show, adding a CSS class to the element or something. Also we'd prefer a peer gadget to prevent "jumping" (just like we do with Twinkle) within the personal toolbar, but we don't know whether the link is going to say "Dark mode" or "Light mode" upfront... So all things considered I guess adding the link to #p-cactions like you've done is maybe the better way. Hmm. MusikAnimal talk 19:03, 22 April 2021 (UTC)[reply]
      I think I'm missing something in my understanding: doesn't the toggle widget have to come in another script or gadget, because when the dark mode gadget isn't enabled, it won't be able to change the user interface? isaacl (talk) 21:10, 22 April 2021 (UTC)[reply]
      Yes of course! Sorry, so obviously it can't be the same gadget definition. Here's what I'm thinking: we make dark-mode a hidden gadget, and make @SD0001's dark-mode-toggle a default-off gadget. By enabling dark-mode-toggle on, it surfaces your toggle link, which you can easily use from then on forward until you turn off the dark-mode-toggle gadget. Ideally when we first turn on the dark-mode-toggle gadget, it would go ahead and enable dark-mode, but it might be tricky to do something only on the "first run", if you know what I mean (maybe use a hidden preference?). I bet one of you can come up with a solution!
      The other route is to make dark-mode-toggle a default-on gadget, but that would likely require an RfC and maybe some designer input since it would be visible to all registered users. I'd say only 'registered users' because I'm pretty sure we can't selectively enable/disable gadgets for logged-out users, and moreover there's the conflict with Varnish full-page caching which registered users bypass. MusikAnimal talk 03:55, 23 April 2021 (UTC)[reply]
      @MusikAnimal unfortunately hidden gadgets can't be enabled/disabled (they can only be depended on by other gadgets), so I think we will need to have two non-hidden gadgets, maybe with descriptions:
      •   Dark mode – can be toggled on/off.
      •   [Internal] Dark mode – this is switched on/off by the dark mode toggle gadget above. Avoid enabling/disabling this directly.
      Ideally when we first turn on the dark-mode-toggle gadget, it would go ahead and enable dark-mode Can be done but it would look hacky – when the user enables the gadget, dark mode can't kick in immediately (since gadgets aren't allowed to run on Special:Preferences), but only when the user navigates to another page – which too will first appear in light mode, before it automatically reloads and becomes dark. – SD0001 (talk) 10:50, 23 April 2021 (UTC)[reply]
    Berchanhimez importScript is deprecated and mw.loader should be used instead. Volker E. (WMF) (talk) 08:19, 23 April 2021 (UTC)[reply]
    Volker E. (WMF), apologies - my main goal was to add the comment so that people who added it would know where to find the doc/more information - I was unaware that importScript was fully deprecated and shouldn't be used anymore - I find it much easier than the new "url format" but c'est la vie. -bɜ:ʳkənhɪmez (User/say hi!) 13:58, 23 April 2021 (UTC)[reply]
  • Flash free dark mode! Has Christmas come early or what! Support of course! My one issue yet is that my left sidebar (or whatever the term is) has the normal color. This could of course be a problem with one of my user scripts that add links there. --Trialpears (talk) 22:44, 20 April 2021 (UTC)[reply]
  • Support -FASTILY 05:35, 21 April 2021 (UTC)[reply]
  • Support I see that flash-free dark mode can be tested even before it becomes a gadget by putting @import 'https://en.wikipedia.org/w/index.php?title=User:Volker_E._(WMF)/MediaWiki:Gadget-dark-mode.css&action=raw&ctype=text/css'; in Special:mypage/common.css.
    @Volker E. (WMF) Have you folks considered making a browser extension instead? That would make it possible to avoid the flash but at same time allow toggleability.
    Also, I think this is a bit too black.Instead of filter: invert( 1 ) an invert of 0.9 or something looks more natural to me. – SD0001 (talk) 13:01, 21 April 2021 (UTC)[reply]
    SD0001, this would, if I'm not mistaken, eliminate the Earth Day connection as the power savings will only occur if pixels are completely black. OLED screens do not use power to display pixels that are completely back - pixels that are not completely black will still be "turned on" and I'm not sure that OLED technology has advanced to the point that an "on but almost black" pixel is different from any other on pixel. -bɜ:ʳkənhɪmez (User/say hi!) 18:51, 21 April 2021 (UTC)[reply]
    SD0001 Thanks, we've considered to add such mode to Wikimedia Foundation developed skins in previous attempts, but needed to dial back for several technical reasons, performance and skin-architecture related. A specifically difficult issue would be to enable such for anonymous users and longer-term maintenance reasons. A browser extension would be just another take that's to me personally a last resort. Note, that this gadget would widen the user base for Wikimedia Design's approach to dark mode and with that provide us helpful insights (some of those already shared above) on the acceptance, flawlessness and popularity. Note that there are some general web dark mode browser extensions already out there last time I've looked. Those enable a comparable experience without probably being as fine-tuned to our look and feel as this from Wikimedia designers.
    To the second question on dark mode background. We could extend the ability of this further in the future. For now it's an acceptable starting point with the Earth-Day-supporting black on mobile to me. Thanks for the support –Volker E. (WMF) (talk) 19:09, 21 April 2021 (UTC)[reply]
  • Support, for sure. @Volker E. (WMF): I'm seeing an issue, though, and I presume I'm the only one since nobody else has mentioned it--the HTML body background is still white in Vector, and still that white-with-a-top-gradient-pattern thing in Monobook. Not sure what that's about; I tried removing all other custom CSS and user scripts (though not gadgets), and the issue persisted. I ultimately fixed it by adding html body{ background:#000;} to the CSS, but again, if I'm the only one seeing it for whatever reason, not sure if that's actually something that needs to be added to the gadget itself. Writ Keeper  20:19, 21 April 2021 (UTC)[reply]
    I also experienced this. --Trialpears (talk) 20:44, 21 April 2021 (UTC)[reply]
    @Writ Keeper: The "top-gradient-pattern" thing is this image. It's intended to be an end-view of the spine of a hardback bound book. Wikipedia in other languages normally use the same image (Vietnamese uses a yellow version), or a plain background (e.g. Arabic), or occasionally something more decorative. --Redrose64 🌹 (talk) 13:39, 22 April 2021 (UTC)[reply]
  • I've moved the CSS to MediaWiki:Gadget-dark-mode.css so anyone can try it now by adding ?withCSS=MediaWiki:Gadget-dark-mode.css to a URL, such as https://en.wikipedia.org/wiki/Main_Page?withCSS=MediaWiki:Gadget-dark-mode.css. You can also enable the test gadget, see the very last item on the list of gadgets. Indeed, @Volker E. (WMF) it seems the background isn't black in Firefox, only in Chromium-based browsers. I believe this is the same issue reported at User talk:MusikAnimal/nightpedia. This very same CSS used to work in both browsers... MusikAnimal talk 01:27, 22 April 2021 (UTC)[reply]
    Writ Keeper's solution to add html body{ background:#000;} fixes it for Firefox, but breaks it for Chromium (because there's an invert filter on html). MusikAnimal talk 01:39, 22 April 2021 (UTC)[reply]
    Yep, saw that on my mobile device after I had posted. Wrapping the body rule in its own media query seemed to have fixed it across both browsers, although I'm not sure exactly how hacky that media query is. Writ Keeper  13:35, 22 April 2021 (UTC)[reply]
    Implemented! Thanks for the workaround. I think it is a bit hacky, but I'm not aware of any alternatives. MusikAnimal talk 18:41, 22 April 2021 (UTC)[reply]

Thanks everyone for the support! Happy for all your feedback so far and yet to come. –Volker E. (WMF) (talk) 18:47, 22 April 2021 (UTC) Enable it under Preferences > Gadgets > Dark mode (currently at bottom of page.[reply]
We've fixed the Firefox issue with Witt Kipper's workaround and also enabled it for mobile (thanks again MusikAnimal).

It looks like MediaViewer is busted on Firefox in monobook skin. No image preview is shown at all! Problem goes away on disabling dark mode. – SD0001 (talk) 10:54, 23 April 2021 (UTC)[reply]
  • Volker, thanks for all the hard work. I'd echo what was said above – it feels a little too black (still fine for me, but maybe not sustainable for hours and hours), so maybe a charcoal will be nice. Trying to open an image on Chrome is not great though: it gives me a horrifying colour negative! Sdrqaz (talk) 13:24, 24 April 2021 (UTC)[reply]
    I figured out that the real oh-my-god-my-eyes-are-bleeding-from-the-contrast kind of darkness comes from larger screens (such as a desktop), a laptop is just fine for the 'black' mode. But I second Sdrqaz, a charcoal would be better. MEisSCAMMERtalkcontribs 13:33, 25 April 2021 (UTC)[reply]
    Also, there's some kind of little white box with rounded corners near-ish to the top of the page (on Firefox, doesn't seem to be there on Edge). Also it doesn't even work on IE. (Then again IE will be IE, but still...) MEisSCAMMERtalkcontribs 13:36, 25 April 2021 (UTC)[reply]
  • Support Sorely needed. Other major platforms have had them for a while. ~ HAL333 21:35, 26 April 2021 (UTC)[reply]

Transclusions containing named references

The article Lists of killings by law enforcement officers in the United States produces the error: "Cite error: The named reference Esposito Lee Edwards PNAS 2019 was invoked but never defined."

The error occurs because a section is transcluded from Police use of deadly force in the United States, using this template: "section:Police use of deadly force in the United States|lack of data," which contains the named reference: "[1]."

Unfortunately, the named reference is not in the section being trancluded. I would like some advice, before I start messing with this unusual condition.

One way to fix this might be to replace the named reference in the transcluded section with an unnamed reference. That would leave the reference defined twice in the same article.

Another way would be to move the named reference into the transcluded section, and hope that someone does not transclude the other section.

My main concern is maintainability. I don't want to leave a trap for another editor to fall into. Comfr (talk) 03:38, 21 April 2021 (UTC)[reply]

References

  1. ^ Cite error: The named reference Esposito Lee Edwards PNAS 2019 was invoked but never defined (see the help page).
I don't think it makes sense to transclude sections of articles into other articles in this way. Here are some useful instructions.Jonesey95 (talk) 04:58, 21 April 2021 (UTC)[reply]
I agree. Placing Refs within transcluded material, usually within WP:Templates transcluded by multiple articles, often leads to later article maintenance issues, omitting the Refs leads to WP:V issues, and I don't think any good solution has found wide general use. I proposed one inelegant scheme some time back (I would need to search to find the details), but was not able to generate any support. AFAIK, the currently accepted approach of dealing with content used by more than one article is as described in WP:CWW. Wtmitchell (talk) (earlier Boracay Bill) 08:11, 21 April 2021 (UTC)[reply]
I agree that at present, refs should not be placed in transcluded material.
It would be good to have a solution to this problem – in the biology areas in which I usually edit, there are regularly templates with material that requires references, but doesn't have them because of this problem. There are also taxonomy templates that contain references which could usefully be shown in the articles whose taxobox uses the taxonomy templates, but again they can't be shown without causing reference problems. Maybe there just isn't a solution, given the difficulty of determining whether two citations are to the same source (unless {{Cite Q}} becomes standard, but it has its own serious problems). Peter coxhead (talk) 08:42, 21 April 2021 (UTC)[reply]
It was actually caused by {{#section-h:Police use of deadly force in the United States|Frequency}}. I have moved the reference definition to the transcluded section and made a source comment about it. Section tranclusion is rare so there is low risk that the other uses of a named reference will be transcluded. Click "What links here" and "Hide links" to see current transclusions of a page. There is only one here, apart from the article transcluding itself due to a technicality in citation templates. PrimeHunter (talk) 10:00, 21 April 2021 (UTC)[reply]
Thanks for fixing the problem and documenting the solution. Comfr (talk) 18:12, 21 April 2021 (UTC)[reply]
We had a horrible time of it trying to fix ref errors caused by a template here. People need to stop trying to be clever. DuncanHill (talk) 21:30, 21 April 2021 (UTC)[reply]

Job hard to complete

Category:Latest stable software release templates have a lot of versions to update... What can be done to simplify the work? I think to transfer to Wikidata, it is very simple to manage the release versions on Wikidata. You can check this source code. On the Italian Wikipedia, the template Software have the Stable release parameter with empty value, the value come from Wikidata. Maybe on the Infobox software template could be use {{#property:P348}} template for call version value from Wikidata. --2001:B07:6442:8903:6119:96EF:62D5:C1D8 (talk) 07:54, 21 April 2021 (UTC)[reply]

If there is no release information locally, then you may fetch it from Wikidata, per Wikipedia:Requests for comment/Wikidata Phase 2. However these software release templates allready have information locally, so in that case, because the community decided against it, you can not replace that with wikidata. You could try to get an new consensus on WP:RFC if that is too inconvenient. Technically, it would be possible to get the date when the templates where last updated and comparing that with wikidata, then showing whichever is the latest one, its just that, again, it is not permitted per policy.--Snaevar (talk) 10:23, 26 April 2021 (UTC)[reply]

No office protected pages?

Hi, I just looked at Category:Wikipedia Office-protected pages and saw no results. However, MediaWiki:Wikimedia-copyrightwarning says that the page is office-protected. Confusing! Also, when I viewed protection level of the page is saying that the page has not been protected with "Edit=Allow all users" and "Move=Allow all users." I know that pages in ns8 are auto-protected by the software. Is office protection manually choosing "Action=Allow only WMF staff" with action being the attempted action, or is it protected by adding the category or with an editnotice? 54nd60x (talk) 11:48, 21 April 2021 (UTC)[reply]

The third box at Category:Wikipedia Office-protected pages says:
The templates currently have no uses. Pages in the MediaWiki namespace are usually displayed automatically (not via normal transclusion) somewhere in the interface and we don't pollute them with things like message boxes, icons and categories. I doubt noinclude tags would work. In some cases we could make a page name test to only display something on the MediaWiki page itself but it wouldn't work for all messages and we don't do it. The message seen on "View source" or "Edit" at MediaWiki:Wikimedia-copyrightwarning is Template:Editnotices/Page/MediaWiki:Wikimedia-copyrightwarning. Office protection is not a software feature but just a designation of certain pages which can only be edited by administrators but shouldn't be without Wikimedia permission. PrimeHunter (talk) 12:22, 21 April 2021 (UTC)[reply]

Picture of the Year coordinator needed!

Picture of the Year is one of the most visible annual events on Wikimedia projects, and right now its future is in limbo. We need someone with some technical know-how to step in as a coordinator, and [perhaps an additional person to] create documentation for the future. Please leave comments in this thread on the Commons Village Pump: commons:Village Pump#Picture of the Year coordinator needed!. Posting here because there are a lot more people with technical know-how watching this page, and it may be of interest. — Rhododendrites talk \\ 13:08, 21 April 2021 (UTC)[reply]

Following up on this, I wonder if there may be an opportunity for a WMF Rapid Grant to run this and/or create documentation for the future. At this point, nobody has stepped forward and I fear POTY this year (and beyond) is uncertain. — Rhododendrites talk \\ 20:09, 25 April 2021 (UTC)[reply]

Switch table chronology

Is there an easy way e.g. a tool that switches tables that are reverse-chronological (i.e. newest at top) to chronological (i.e. newest at bottom)? I want to make List of association footballers who died during their careers chronological, but it's way to much effort to manually move every row so it's in chronological order. Joseph2302 (talk) 17:34, 21 April 2021 (UTC)[reply]

@Joseph2302: I am completely not understanding what you are trying to do. The table is sortable, so to change it from newest-at-top to newest-at-bottom, just click the arrow at the top of the year column. Please explain the actual problem you are trying to solve. RudolfRed (talk) 17:52, 21 April 2021 (UTC)[reply]
The default view for tables is that they should be in chronological order, but this one isn't. I want to change it in the article text so it's in chronological order by default, but was hoping there's a quicker way than just changing every line of the table. Joseph2302 (talk) 17:59, 21 April 2021 (UTC)[reply]
But that table is already in the chronological order by default - recent deaths at the top, by the year? What chronology do you have in mind? By exact date of death?
This may help, but you would need probably to reorder the entire table anyway for initial page load. MarMi wiki (talk) 18:16, 22 April 2021 (UTC)[reply]
Oh, I understand now - you just want to reverse the initial order of the table.
If you want to replace the order and save it in the article, don't do it. Or at least discuss this on Village pump. And why not? Most edits will be probably of those who died recently, so scrolling to the bottom would make updates a little harder. Scrolling to the bottom requires more work for editors than resorting the table for readers (unless most readers actually are interested in the older entries).
If you want to do it for your own purposes, then you can do it relatively easy by using regex (ex. regex101.com) and javascript from browser dev console (regex to replace linebreaks into tabulators and " into \" [or ' into \']; javascript for split, reverse, join). Or you can use those to turn the table into a database table (Comma-separated_values). MarMi wiki (talk) 20:15, 22 April 2021 (UTC)[reply]
Without some specific reason otherwise, lists should be standardized to oldest to newest. See WP:SALORDER. -- GreenC 20:43, 22 April 2021 (UTC)[reply]
I agree. Mobile doesn't have sortable tables and that's 70% of views on that list. We don't know how many desktop readers use sorting or even know it exists. Tables should have the preferred order before sorting. The long table should have a year index similar to Lists of box office number-one films#Lists. Then it's easy for readers to get to 2021 even if it's at the end. PrimeHunter (talk) 21:52, 22 April 2021 (UTC)[reply]
@Joseph2302: Unfortunately, there isn't really a good way to sort a table. There are still ways to do it though, they're described at Help:Sorting § Maintaining tables sorted alphabetically or by rank. AntiCompositeNumber (talk) 03:41, 22 April 2021 (UTC)[reply]
@Joseph2302: My method (assuming I had consensus for the change) would be to (1) enable Visual Editor (which I don't ordinarily use), then (2) open the page for editing, (3) copy the entire table (CTRL-C or equivalent), (4) paste (CTRL-V or similar) the contents into a spreadsheet application (I use OpenOffice Calc, and I know other products will work, possibly even Microsoft Excel), (4) resort the table to suit my needs, (5) copy the table from the spreadsheet and (6) paste it into Visual Editor (possibly start with a new table there, and paste into the upper-left-most cell provided), then (7) preview, check, fix whatever went wrong (and optionally delete the original table, if a new one was added) and finally, (8) deactivate Visual Editor.
This process is tricky (i.e., doesn't bloody work) when the table has colspans or rowspans, so my usual procedure includes merging such cells before copying from V-E and trying to remember how to split them again before I publish. The particular table you've linked to has no such spans so it should be straightforward for you. — JohnFromPinckney (talk) 06:23, 22 April 2021 (UTC)[reply]

Very weird page views

I asked this question at WP Astronomy and nobody had an idea what's going on, but somebody suggested I take it here. The page Skathi (moon) is a wildly unimportant page that, according to the page views tool, has gotten an absolutely ridiculous number of views since December -- last month this random rock that orbits Saturn got something like 1 view for every 20,000 that went to enwiki, and its views are growing every day. There's simply no media event that could explain this, since a) this moon is just a lump of rock and the only references to it anywhere are a handful of obscure catalogs and conference papers, and b) this level of page views goes way beyond surges that we see from even the biggest news events, both in its scale and especially in its duration (I edit a lot of politics-related articles and usually peaks from things like a US presidential election are much smaller and last for 2-3 days, they don't grow consistently for months). It doesn't have the usual signs of a false positive, like a split between mobile and desktop views, and if it is an automated process it's doing a very good job of mimicking the way that real pageviews ebb and flow during the week. Could this be a sustained and clever automated bombardment by someone who .. what, just wants to screw with Wikipedia's measurement of the popularity of its astronomy articles? Could it be a false measurement induced somehow by the page view tool? Thanks! - Astrophobe (talk) 18:09, 21 April 2021 (UTC)[reply]

This sounds similar to https://phabricator.wikimedia.org/T273741 in which an app used a Commons image on its splash screen. Perhaps someone has an app now which tests its internet connection by pinging this article. I would suggest taking this to Phabricator and letting them deal with it - options discussed last time included blocking the connection although they were able to resolve it amicably in the end. User:GKFXtalk 18:25, 21 April 2021 (UTC)[reply]
If you do file a task, use the Pageviews Anomaly tag. MusikAnimal talk 19:43, 21 April 2021 (UTC)[reply]
Thanks to both of you for the suggestions. I've just filed a task, and added that tag. - Astrophobe (talk) 19:45, 21 April 2021 (UTC)[reply]
The huge views are split around evenly between the desktop and mobile version. Views for the mobile app look fairly normal.[1] It has increased from around 2 to 6 monthly views so it is a tripling but still tiny and could be a single reader coming back. App views are typically around 2% of total views. It was 1% before December 2020 for this article. The last month it is 0.0007% (8 out of 1,068,935). This eliminates any chance that the hits are from readers. PrimeHunter (talk) 21:02, 21 April 2021 (UTC)[reply]
I think the app idea suggested by @GKFX makes sense and is worth investigating (and I suspect is the case here). @PrimeHunter the reason being that if it is an app, depending on the User agent string used it would actually be categorized by our traffic data pipeline as desktop or mobile web. The category "mobile app" is strictly for official Wikipedia apps for Android/iOS/KaiOS, and does not refer to mobile apps in general.
For anyone curious: in the pipeline, this is the query that refines web requests and this is the code (used by that query) that determines the access method – namely appAgentPattern and getAccessMethod(). MPopov (WMF) (talk) 17:08, 22 April 2021 (UTC)[reply]

TOP of category

In regard to Category:Surnames I answered a question here, and to fix that problem I top-sorted the template with this edit. Everything worked well, the Surname template was taken out of the "S" section of the category and placed on the first page at the TOP. This still works well in other categories, such as Category:Redirects from surnames where {{R from surname}} is still at the TOP of that category, but I recently did a double check and {{Surname}} has disappeared from the TOP of Category:Surnames (along with three other entries that were there before but have now disappeared). Scratching my head on this one, as it makes me think the ol' Sundowners is setting in to my brain. Anybody know why the template is no longer in the category at the TOP of the first page? P.I. Ellsworth  ed. put'r there 19:11, 21 April 2021 (UTC)[reply]

Paine Ellsworth, you didn't just top sort the template but every page using the template. It is technically topsorted here, but you can't see it among the mess of others. The ones that haven't become top sorted yet is because of the cache not having caught up. Categorization of templates themselves should always happen through the documentation page which I've done now. I'm not sure if it should be there though per WP:CAT#T since Category:Surnames is a content category. --Trialpears (talk) 19:21, 21 April 2021 (UTC)[reply]
(edit conflict) The category is set via Template:Surname/doc, and is currently top sorted to Category:Surname, not Category:Surnames. — xaosflux Talk 19:22, 21 April 2021 (UTC)[reply]
Whoops, I placed it in the wrong category. --Trialpears (talk) 19:24, 21 April 2021 (UTC)[reply]
I see I've messed it up so I'm glad I brought it here. Deeply apologetic for what I did; I guess Sundowners might be setting in after all. I'll be more careful in the future. P.I. Ellsworth  ed. put'r there 19:27, 21 April 2021 (UTC)[reply]
Does sound like the category link in {{Surname}} needs to be "includeonly'd" to keep it out of the category, though. P.I. Ellsworth  ed. put'r there 20:00, 21 April 2021 (UTC)[reply]
It's not necessary if the category is added in the documentation. A page can only be listed once in a category. If a category is added more than once then the last sort key counts, in this case the one transcluded from the documentation. PrimeHunter (talk) 23:19, 21 April 2021 (UTC)[reply]
To editor PrimeHunter: excellent! thank you, that's good to know. P.I. Ellsworth  ed. put'r there 13:37, 22 April 2021 (UTC)[reply]

Mongolization

I have a problem with the article Mongolization. Please help me put it back into its origional form.--Dthomsen8 (talk) 01:13, 22 April 2021 (UTC)[reply]

@Dthomsen8: you can go to the article's history using this link, then click on any old version you want to view, to restore that version click on edit, then publish. See Help:Reverting for more about reverting changes. — xaosflux Talk 13:30, 22 April 2021 (UTC)[reply]
Your edits were technically erroneous, which is way they were reverted by Izno. --Leyo 14:06, 22 April 2021 (UTC)[reply]

Daily Digest Feed of Page Changes

Is there any tool or script that produces a daily digest feed (atom or rss) of changes to a page? The atom feed link on the sidebar produces a feed of every change, and I know I can get a daily (and weekly) digest via email, but I really wanted a feed. Is that available somewhere? Guarapiranga (talk) 03:48, 22 April 2021 (UTC)[reply]

@Guarapiranga: see Wikipedia:Syndication - you can query RSS for a single page - is that what you wanted? — xaosflux Talk 13:28, 22 April 2021 (UTC)[reply]
Yeah, I looked there, but all I found were feeds in which each change (to a page or set of pages) is an entry. I was wondering whether anyone had the idea (or the need) to produce daily digest feeds summarising all changes to a page or set of pages in a day (or week). Something like: Time, Article, Bytes added, Bytes removed, Editors, etc. Maybe a chart of recent daily changes... Guarapiranga (talk) 22:19, 22 April 2021 (UTC)[reply]

Ordered lists that don't start with "1. ..."

There seems to be something different (since a few days or so) in how code for ordered lists that don't start with "1. ..." is parsed. In other words, the method explained in the third example at Help:List#Specifying a starting value seems to yield unexpected results in some instances. Example, List of compositions by Fanny Mendelssohn#Nos. 2, 3 and 12 in Felix Mendelssohn's Op. 8 (and many other sections on that page). Does anyone know the background to this (may be a browser issue?), and what to do about it (I mean: in a systematic way – I know that the problem doesn't present itself when converting to {{ordered list}}, so can anything else be done about this other than manually converting hundreds of such lists – as here and here)? Also, shouldn't documentation, such as on the aforementioned help page, be updated? --Francis Schonken (talk) 08:45, 22 April 2021 (UTC)[reply]

What "unexpected results"? I just see 2, 3, and 12 in the link you provided, which seems the way it's intended. What do you see, and what browser are you using? Nardog (talk) 09:08, 22 April 2021 (UTC)[reply]
I see:
  1.
  2. Das Heimweh.[8][9]
  3.
  3. Italien.[10][11]
  4.
12. Suleika und Hatem.[12][13]
As said, I don't exclude this is a browser issue (Firefox, which I'm using, had some recent updates). --Francis Schonken (talk) 09:17, 22 April 2021 (UTC)[reply]
My mobile phone (Android) does not have the problem. --Francis Schonken (talk) 09:24, 22 April 2021 (UTC)[reply]
The issue seems to be that CSS loaded on desktop [2] doesn't contain the rule to hide the first item, which is suppose to be .mw-hide-empty-elt .mw-parser-output .mw-empty-elt{display:none} BrandonXLF (talk) 09:35, 22 April 2021 (UTC)[reply]
Furthermore, it seems to be a server-side cache issue since the URL [3] has the expected CSS and the only difference is the addition of a bogus query parameter. BrandonXLF (talk) 09:38, 22 April 2021 (UTC)[reply]
Any strategy for addressing this? Ask someone to purge the server-side cache? Does anyone know whom to ask this? --Francis Schonken (talk) 10:31, 22 April 2021 (UTC)[reply]
To clear the server cache add ?action=purge to the end of the adress bar in your browser on the problematic page and press enter. If that does not work, then press Ctrl+F5 (on Windows) to clear your own cache on that page (it will also reload the page).--Snaevar (talk) 15:56, 22 April 2021 (UTC)[reply]
Neither had any effect whatsoever. Is there a manner of contacting a WMF technical person to take a look at this? Tx. --Francis Schonken (talk) 19:30, 22 April 2021 (UTC)[reply]
The method is to raise a WP:Phabricator ticket (which won't actually get serious attention unless it's a sky-is-falling issue) but this problem is likely to be some ephemeral weirdness that will disappear soon. Since others see the list correctly, it's possibly due to a problem on a particular server that holds the display sent to where you are. I suggest editing the list to something standard (remove the li value stuff in the first problem list). Save the page and observe that it displays properly as 1/2/3. Then edit it again and paste back the wikitext removed in the first step. See what happens on saving. Johnuniq (talk) 00:58, 23 April 2021 (UTC)[reply]
Also no relief with this new recommended method, see [4] followed by [5]. Pinging Volker E. (WMF) and MPopov (WMF), both of whom have been contributing to this VP talk page, to see whether they can inform about a way forward on getting this sorted. For clarity, this is, afaics from the above discussion, not "my" problem, but a problem that needs sorting nonetheless. I seek a middle way between doing nothing ('some ephemeral weirdness that will disappear soon' – apparently it doesn't) and moving elsewhere for a procedure that is likely too convoluted for this issue ('raise a WP:Phabricator ticket' – not my cup of tea). --Francis Schonken (talk) 09:03, 23 April 2021 (UTC)[reply]

Accessing Wikidata references as plain text

I would like to access the properties stated in and/or reference URL as a string. The intent is to use this type of references as a switch in Template:Chembox CASNo/format to decide whether the CAS number is linked to the CAS Common Chemistry database. Not all CAS numbers have an entry in that database. --Leyo 11:12, 22 April 2021 (UTC)[reply]

@RexxS, Pppery, and Thayts: Could you possibly help in this matter? --Leyo 19:15, 25 April 2021 (UTC)[reply]

Suggested Values

Timur Vorkul (WMDE) 14:08, 22 April 2021 (UTC)[reply]

So if a user page has no "Email this user" ...

While I've contributed to Wikipedia for a long time, I'm not always up on all of the latest changes & I encounter surprises from time to time. Such as finding I could not email another editor thru their user page. When I attempted to do just this, I could not find the link "Email this user" in the list of options at the side of the page under "Tools" .

Was this dropped in the latest revision of that part of the web interface? (I know some things were changed.) Baffled, I checked my own user page: yes, between "Block user" (I do have that bit) & "Mute user", I found that link. Then I verified with the user page of another editor whom I have emailed in the past: it was there too. This led me to the hypothesis that if someone does not enter a value for "email address" in their preferences, this link does not appear on their user page.

So is my hypothesis correct? Has it always been this way? (I created my account so long ago I don't remember what information I gave at the time.) And -- which I consider most important -- is this explained on any page a new or established user can find easily? Knowing that this option will not appear unless populated would gently encourage Wikipedians to include an email address, & which would facilitate private communications. -- llywrch (talk) 15:24, 22 April 2021 (UTC)[reply]

If an user page has no "email user" then that user has disabled the option to email him, in the preferences.--Snaevar (talk) 16:00, 22 April 2021 (UTC)[reply]
Or did not enter an email address. Izno (talk) 17:16, 22 April 2021 (UTC)[reply]
It's actually possible to distinguish these cases. Go to Special:EmailUser and submit the user's name You'll either see "This user has chosen not to receive email from other users." or "This user has not specified a valid email address." Suffusion of Yellow (talk) 17:24, 22 April 2021 (UTC)[reply]
And is any of this documented where an average user who is not familiar with Mediawiki software can find it? -- llywrch (talk) 18:06, 22 April 2021 (UTC)[reply]
WP:EMAIL, where you would expect. :D Izno (talk) 18:45, 22 April 2021 (UTC)[reply]
It actually does not. I read the entire page carefully, & nowhere is that information clearly stated. If one reads between the lines, maybe one can deduce the correlation that if no email address configured, then no link, especially if one already knows the answer -- but in that case why would they consult WP:EMAIL at all? Consider this: people who come to Help pages for information aren't in the right mind to read between the lines. Often they have burned thru all of their patience. They want things set forth clearly, sometimes even the simple things. (Even the most tech-savvy people get annoyed when the documentation is written by people who assume you know what they are talking about. Especially when it's late at night, they've spent hours trying to get everything just right so that they can fix a problem with the "few simple keystrokes", but the documentation is written so vaguely one has to resort to trial-&-error to figure out the solution. Not that I've had to struggle with this kind of situation.) A simple sentence, say "The 'Email this user' will not appear if you don't enter an email address in your preferences, or limit its use as follows", might save someone a lot of aggravation. -- llywrch (talk) 23:31, 22 April 2021 (UTC)[reply]
@Llywrch: sounds fine, be bold and update the Help :) — xaosflux Talk 00:18, 23 April 2021 (UTC)[reply]
I did that very thing; faster than posting here about it, even. Writ Keeper  00:22, 23 April 2021 (UTC)[reply]
Oh woops, did a fast skim and saw things mentioned there but nothing explicit about the impact on the interface. Izno (talk) 01:05, 23 April 2021 (UTC)[reply]

Moving articles

Moving articles without updating title in lead, infobox and Wikidata should be bannable. Has anyone ever tried to fix this problem? Eurohunter (talk) 21:23, 22 April 2021 (UTC)[reply]

Wikidata is automatically updated after moves. Many infoboxes automatically display the article title. The lead often mentions the new title already after the old title. I don't think this is a major issue. PrimeHunter (talk) 22:01, 22 April 2021 (UTC)[reply]
@PrimeHunter: I have never seen updates on Wikidata. It shouldn't be done automatically anyway. Outdated names stay there for years same as outdated names in infoboxes and leads on ENWP. Eurohunter (talk) 22:18, 22 April 2021 (UTC)[reply]
If you see a move without an automatic Wikidata update then report it. Example of automatic update: [6][7]. I don't know why you say a fix shouldn't happen right after you asked for it. MediaWiki:Movepagetext includes: "Please read Wikipedia:Moving a page for more detailed instructions." You can suggest more at MediaWiki talk:Movepagetext, e.g. mention of Wikipedia:Moving a page#Post-move cleanup. PrimeHunter (talk) 22:40, 22 April 2021 (UTC)[reply]
If you mean "update the Wikidata label", I have previously proposed somewhere (I can't find on phab) that Wikidata should auto-update the label if it matches the original page name to the new page's name. You may have better luck finding it. Regardless, it is not our fundamental problem if the label does not match the page, so you should consider pushing for a Wikidata change.
The other problem cannot be resolved by technology, period. While I understand your frustration, 'banning' is not the appropriate response regardless. If you find a page with the issue, fix it yourself; if you see someone else do it in real-ish time, please remind them to fix up the page behind themselves. Izno (talk) 01:02, 23 April 2021 (UTC)[reply]
If somebody moves a page and fails to update the article lead, it's nothing that can't be fixed by simple editing, all of which is covered by WP:POSTMOVE. This is not a VPT matter, and definitely not a disciplinary matter - unless attempts to carry out WP:POSTMOVE cleanup are repeatedly reverted by the same person. --Redrose64 🌹 (talk) 07:52, 23 April 2021 (UTC)[reply]

Graph Broken

Talk:Trans Jayapura, pageview graph template in this article is broken. Any idea why and how to fix this? Thanks Nyanardsan (talk) 21:52, 22 April 2021 (UTC)[reply]

Trans Jayapura was moved to that title 21 February 2021 but there are page views from a former version on 19 August 2020.[8] The used interpolation method deals poorly with that. See mw:Template talk:Graph:PageViews#Reverse curve. You can start the graph on 21 February 2021 with {{Annual readership|days={{min|365|{{Age in days|2021|2|21}}}}}}. This automatically changes to 365 days when a year has passed. PrimeHunter (talk) 23:02, 22 April 2021 (UTC)[reply]

Preview warnings and hatnote TemplateStyles

Pages watchers may be interested in MediaWiki talk:Common.css § Preview warning and hatnotes moving to TemplateStyles. Izno (talk) 01:08, 23 April 2021 (UTC)[reply]

Anyone willing to help at Template:Authority control?

Recently, an RfC to change the look of Template:Authority control closed successfully[9]. A mock-up has been created, at User:Fram/Sandbox 2 Complete, which has been improved upon by a few editors, and has been discussed at Template talk:Authority control#Discussion example of the new look after the RfC.

Now this needs to be implemented in the template (and mainly in the module), but I'm no template editor, and this is a very widely used template so the change needs to be error-free if possible. All volunteers to create this new version are welcome at the template, and further input about the mockup and final look as well of course (though if possible please don't restart the RfC discussion but build upon that conclusion). Fram (talk) 09:07, 23 April 2021 (UTC)[reply]

I've now done this. * Pppery * it has begun... 16:21, 23 April 2021 (UTC)[reply]

Searching for tags

Hi there! How can I search for all pages that contain a specific HTML tag? Sadly, < and > are ignored by search so I get mostly erroneous/useless results. --TheSandDoctor Talk 18:48, 23 April 2021 (UTC)[reply]

Try searching for insource:"foo" insource:/\<foo[^\>]*\>/ (replace "foo" with the tag name). Nardog (talk) 18:58, 23 April 2021 (UTC)[reply]
TheSandDoctor, what Nardog said, for more info: mw:Help:CirrusSearch#Regular expression searches. — Alexis Jazz (talk or ping me) 19:12, 23 April 2021 (UTC)[reply]
@Alexis Jazz and Nardog: That worked! Thank you so much TheSandDoctor Talk 20:22, 23 April 2021 (UTC)[reply]

Template:Flagbig

I would like to adjust the flag dimensions in Template:Flagbig. The current situation seems unbalanced. Some icons are huge, some are small. Compare the official version in the first row and my sandbox idea in the second row. What do you think about it?

using
{{Flagbig}}

Nepal

Switzerland

Vatican City

Niger

Monaco

Denmark

DR Congo

France

Russia

United States

Great Britain

Qatar
using
{{Flagbig/sandbox}}

Nepal

Switzerland

Vatican City

Niger

Monaco

Denmark

DR Congo

France

Russia

United States

Great Britain

Qatar

Maiō T. (talk) 19:19, 23 April 2021 (UTC)[reply]

They look the same to me? — xaosflux Talk 19:31, 23 April 2021 (UTC)[reply]
The flags in the second row are specified as 33x24px instead of 30x27px, which is probably why they looked the same to xaosflux; the difference is barely discernible, and was not visible to me at first glance. One problem with the sandbox is that you are changing the aspect ratio of some of the flags in a way that distorts just as the current template does. Take the flag of DR Congo, for example: the file has an aspect ratio of 12:8 (4:2.667). The live template distorts that to 30:23 (4:3.067), and the sandbox shows the flag at 32:24 (4:3). A better fix would be to display the flags in a way that preserved the aspect ratio. – Jonesey95 (talk) 20:09, 23 April 2021 (UTC)[reply]
Ah OK, even at 300% zoom I'm barely seeing any difference, and with the notes about the ratio change I'm not seeing why this is a net positive either? — xaosflux Talk 20:14, 23 April 2021 (UTC)[reply]
Agree with Jonesey. Is it not possible to specify only the height (and let the width manage itself)? — JohnFromPinckney (talk) 08:16, 24 April 2021 (UTC)[reply]
@Jonesey95: You are writing about a different flag. The official flag of DR Congo is this one: File:Flag of the Democratic Republic of the Congo.svg with dimensions of 800x600 pixels (4:3). All flags are displayed with the correct aspect ratio. Maiō T. (talk) 15:30, 24 April 2021 (UTC)[reply]
@JohnFromPinckney: No, it's not possible because the flag of Qatar would be as large as 2.5 of the flag of Switzerland. (And also to xaosflux:) We need to find a compromise between those squarish and extremely wide flags in order to achieve approximately the same area. And I think I did it pretty good in the second row. Maiō T. (talk) 15:30, 24 April 2021 (UTC)[reply]
Hmm, strange. When I expanded the templates yesterday, I'm pretty sure they pointed me to the DR Congo flag I linked above. In any event, I still don't see a big problem with the live template, but the sandbox does look slightly better. I have no objections. – Jonesey95 (talk) 17:02, 24 April 2021 (UTC)[reply]
It's not possible (in MediaWiki markup) to stretch or squeeze an image in order to alter its aspect ratio. A pair of image dimensions represent a maximum width and maximum height, which must both be honoured with the aspect ratio preserved. If you specify the width alone, as in 33px, the height is derived from that value multiplied by the original height and divided by the original width. Similarly, if you specify the height alone, as in x24px, the width is derived from that value multiplied by the original width and divided by the original height. If you specify both dimensions, as in 33x24px then both calculations are performed, and whichever yields the smaller image is the one that gets used. So for an image like this with dimensions that are "nominally 900 × 600 pixels" which is displayed at a specified size of 33x24px we get
  • 33*600/900 = 22
    so 33px is treated as 33x22px
  • 24*900/600 = 36
    so x24px is treated as 36x24px
The smaller of these is the first one, so the specified width is observed but the specified height, being greater than the calculated height, is ignored. --Redrose64 🌹 (talk) 19:32, 24 April 2021 (UTC)[reply]

Line breaking for templates with IP-talk

I just merged the newly-created Template:Welcome-anon-belated back into Template:Welcome-belated (to try to avoid forking) by having {{Welcome-belated}} include an extra paragraph when used on an IP talk page. However, {{IP-talk}} seems to trim out the line breaks at either the beginning or the end unless I fool it by using {{void}}, which isn't ideal since it'd stick around in the wikitext on the recipient page. Is there any better way to do this? {{u|Sdkb}}talk 21:08, 23 April 2021 (UTC)[reply]

Why is this special page giving a 410 error? Whenever you go to this page, you get:

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 $1 via cp5007 cp5007, Varnish XID 640156818 Upstream caches: cp5007 int Error: 410, Gone at Sat, 24 Apr 2021 03:07:29 GMT

Note: $1 would be replaced by the IP address a user was using at the moment. Also see phab:T230991. 54nd60x (talk) 03:12, 24 April 2021 (UTC)[reply]

It was an old piece of code that was deprecated or something. See phab:T89258: "The code for Special:BannerRandom was thought to be essentially dead and is fully deprecated on WMF production. This happened in November, 2014", and "Quick update here: we're preparing a simple patch to just return a 410 from the Special:BannerRandom endpoint. That should be guaranteed to not break anything else. (The patch for fully removing the code is more complicated and needs more careful checking before deployment.)" Kleinpecan (talk) 10:26, 24 April 2021 (UTC)[reply]

'Add to calendar' template

Do we have a template which generates "add to calendar" links for events such as editathons? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:50, 24 April 2021 (UTC)[reply]

Meta has m:Template:Multi Calendar, but I don't think there's any similar template here. the wub "?!" 11:05, 24 April 2021 (UTC)[reply]

I have recently come across a situation where (in nearly real time) I think a redlink was created at 22:35 UTC, replaced by a bluelink (from a different editor within the same portal discussion group) at 23:44 UTC ([[Alfreton and South Normanton station]]), respectively diff #1 and diff#2.

Would I be right to think this does not show in the permalink for diff1 as an initial redlink? I had expected to find this. So, to summarise, the bluelink is retroactively shown into earlier versions. Thank you.--Rocknrollmancer (talk) 13:40, 24 April 2021 (UTC)[reply]

When you view an old version of a page, the red/blue colour of links indicates whether a page now exists or not. Similarly templates on old versions also reflect the current version of the template. – SD0001 (talk) 13:45, 24 April 2021 (UTC)[reply]
(edit conflict) Everything in an old version is shown as it would appear now with the same code. That applies to link colors, template content, magic words including those for time, and so on. It means you know what you get if you revert to that version. For some other purposes it can be annoying. There is no feature to see how it rendered at the time. PrimeHunter (talk) 13:49, 24 April 2021 (UTC)[reply]
Thanks.--Rocknrollmancer (talk) 23:44, 24 April 2021 (UTC)[reply]

Searching for recent changes without reverted tag

Is it possible to filter reverted edits out of Special:RecentChanges? — Alexis Jazz (talk or ping me) 16:33, 24 April 2021 (UTC)[reply]

You could highlight that filter with a colour and just ignore them when you see that colour. Sdrqaz (talk) 17:16, 24 April 2021 (UTC)[reply]
Sdrqaz, adding the "latest revision" filter seems more practical as it prevents excessive scrolling. Only problem, this misses bad edits that aren't the latest revision. — Alexis Jazz (talk or ping me) 17:23, 24 April 2021 (UTC)[reply]
Negative filters for tags is not supported today. It's phab:T174349. Izno (talk) 18:03, 24 April 2021 (UTC)[reply]
Put .mw-changeslist-line.mw-tag-mw-reverted { display: none } in your CSS. —Cryptic 18:07, 24 April 2021 (UTC)[reply]

Searching contributions

Can you search through a specific user's contributions to see if they ever typed a certain word? Like, whether I ever typed "Auburn" in an edit? Drmies (talk) 20:53, 24 April 2021 (UTC)[reply]

I'm only aware of an edit summary search tool. Sdrqaz (talk) 20:56, 24 April 2021 (UTC)[reply]

Drmies, I don't believe that's possible. However, see Help:Searching#Searching for a specific person's contributions. -- RoySmith (talk) 21:00, 24 April 2021 (UTC)[reply]

@Drmies: if it is for revisions of one specific page, there are a few ways - if you want something to pull up a diff of every edit someone has ever made and do a text search on those you are likely going to have to use the dumps. If there is a user with a very low number of contributions some other hacks could be possible. — xaosflux Talk 16:24, 25 April 2021 (UTC)[reply]
User:Xaosflux, no I was looking for someone's edits anywhere on Wikipedia. I think I know what you mean with "dumps", and that's well above my level of comprehension. RoySmith's hint made me browse around a bit and indeed I found one edit that I was looking for. Thanks, to both of you, Drmies (talk) 20:40, 25 April 2021 (UTC)[reply]

Update/shameless plug of WP:UPSD, a script to detect unreliable sources

It's been about 14 months since this script was created, and since its inception it became one of the most imported scripts (currently #54, with 286+ adopters).

Since last year, it's been significantly expanded to cover more bad sources, and is more useful than ever, so I figured it would be a good time to bring up the script up again. This way others who might not know about it can take a look and try it for themselves. I would highly recommend that anyone doing citation work, who writes/expands articles, or does bad-sourcing/BLP cleanup work installs the script.

The idea is that it takes something like

  • John Smith "Article of things" Deprecated.com. Accessed 2020-02-14. (John Smith "[https://www.deprecated.com/article Article of things]" ''Deprecated.com''. Accessed 2020-02-14.)

and turns it into something like

It will work on a variety of links, including those from {{cite web}}, {{cite journal}} and {{doi}}.

Details and instructions are available at User:Headbomb/unreliable. Questions, comments and requests can be made at User talk:Headbomb/unreliable. Headbomb {t · c · p · b} 13:08, 25 April 2021 (UTC)[reply]

Why does Wikipedia display fake dates?

Not a January view

Why does wikipedia display "1 January" when you click on files without a precise date? This is really misleading, see for instance the first illustration at Kleine Scheidegg railway station. Zach (Talk) 14:13, 25 April 2021 (UTC)[reply]

It's done by Media Viewer and also happens at Commons.[10] phab:T58794 from 2013 says it was fixed in 2019 so it appears to be a regression. PrimeHunter (talk) 15:20, 25 April 2021 (UTC)[reply]
Wwell it's using the browser, so then the implementation in browsers changed. In itself this is not unexpected. It might come as a surprise, but date formatting is actually one of the hardest things there is. Only since 2019 there is a standard which allows to express partial dates and uncertainty. And that part hasn't even made it into browsers. —TheDJ (talkcontribs) 18:58, 25 April 2021 (UTC)[reply]

Point a footnote to a specific notelist

Hello all, I am having an issue with an article with multiple {{notelist}} templates. On Daenerys Targaryen, I have a {{efn}} note located within the "Appearance and personality" section. I would like that note to be located within the "notes" section at the end of the article however it is appearing within the "notes" section of the transcluded {{Family tree of Maekar Targaryen}}. I have another efn template that is correctly located within the "notes" section. Is it possible to point that first note to the specific footnote section? -- LuK3 (Talk) 15:00, 25 April 2021 (UTC)[reply]

Either use another efn style e.g. {{efn-ua}} to render the notes in uppercase or use the |group= in {{efn}} to make them all part of the same group - a group which doesn't include the transcluded notes. Nthep (talk) 15:56, 25 April 2021 (UTC)[reply]
Nthep, thanks for the fast reply. The {{efn-ua}} seemed to work. -- LuK3 (Talk) 17:53, 25 April 2021 (UTC)[reply]

When I dismissed "The Signpost" watchlist notice, it kept showing up. Is this a mediawiki issue?Catchpoke (talk) 19:23, 25 April 2021 (UTC)[reply]

@Catchpoke: you will need to enable scripting (js/css) and also localstorage for wikipedia.org for that to work. — xaosflux Talk 21:06, 25 April 2021 (UTC)[reply]
I am actually not sure what you are saying: does this have something to do with the "Gadgets" tab or the "Watchlist" section in the "Banners" tab in "Preferences"?Catchpoke (talk) 21:28, 25 April 2021 (UTC)[reply]
(@Xaosflux: Update): I dismissed the "The Signpost" notice for this month, logged out and then logged back in, and noticed that the notice is gone; is there something in the preferences that I can select to prevent those messages from showing up in the future?Catchpoke (talk) 21:44, 25 April 2021 (UTC)[reply]
@Catchpoke In Preferences on the Gadgets tab, under the "Watchlist" heading, you can disable "Geonotice: display notices on your watchlist about events in your region" and "Display watchlist notices". the wub "?!" 22:01, 25 April 2021 (UTC)[reply]
Keep in mind, we usually limit watchlist notices to things that are fairly useful, so you may miss out on announcements if you use the gadget to avoid these. You could manually watchlist MediaWiki:Watchlist-messages to see updates on the watchlist without a notice if you want though. — xaosflux Talk 23:53, 25 April 2021 (UTC)[reply]

Why does New York Chinese Scholar's Garden have parens?

In {{Protected areas of New York City}}, in Other / Botanical gardens, "New York Chinese Scholar's Garden" shows inside parentheses. I can't see anything in the markup (or, indeed, the generated HTML) that causes this. ELIF? -- RoySmith (talk) 19:47, 25 April 2021 (UTC)[reply]

I think they are generated in MediaWiki:Common.css, in the section headed "Add parentheses around nested lists". – Jonesey95 (talk) 20:47, 25 April 2021 (UTC)[reply]
hlist, which is the norm in navboxes, flattens each list, adds the bullets between list items, and adds parentheses around sublist items. Jonesey has identified the location of interest. Izno (talk) 21:26, 25 April 2021 (UTC)[reply]

File cache

I am using a wiki and I uploaded the third version of the file. The image appearing on the pages that use this file is the old one. I՚ve had this happen to me multiple times. Please help me resolve the problem. Thanks. Kolikojerokoko (talk) 01:30, 26 April 2021 (UTC)[reply]

@Kolikojerokoko: It's probably cached. Try a hard refresh by following the instructions at Wikipedia:Bypass your cache. Vahurzpu (talk) 04:26, 26 April 2021 (UTC)[reply]
If it is an SVG, it might be a different problem, but purging is a good starting point.
Clearing files is a bit different than pages. Admittedly, this should probably be in the wikipedia page, but it is not. As an example, lets take your only commons file, although I know that is not the file you have an issue with.
  1. Go to the file page
  2. Click on the image again so only the image itself is shown
  3. Add /thumb and "resolution-Filename?RandomNumber" to the adress bar like so (marked with green): (200px becomes whatever resolution of the file the pages are using)

https://upload.wikimedia.org/wikipedia/commons/e/e6/TonsuringofRadoslavLuki%C4%87.jpg becomes

https://upload.wikimedia.org/wikipedia/commons/thumb/e/e6/TonsuringofRadoslavLuki%C4%87.jpg/200px-TonsuringofRadoslavLuki%C4%87.jpg?12345

4. Go back to the filepage and add ?action=purge to the end of the url and hit enter.
5. Either wait or also do ?action=purge on all the affected pages.--Snaevar (talk) 10:05, 26 April 2021 (UTC)[reply]

Edit summaries when editing by section

I'm not sure whether the suggested edit summaries that pop up when editing the "Summary" box, are a function of my browser (W10 + Edge) or Wikipedia, but I find them very useful. A few days ago, they stopped popping up when editing by section, but are still appearing when editing the whole page, or after deleting the /*section title*/ that auto-fills the beginning of the box.
Is this the result of a Wikipedia change? If so, can it be reverted, or worked around? - Thanks - Arjayay (talk) 12:07, 26 April 2021 (UTC)[reply]

@Arjayay: this sounds like an auto-fill feature on your browser. Are the suggestions something generic, or things you have typed in before? — xaosflux Talk 13:46, 26 April 2021 (UTC)[reply]
The suggestions are all things I have typed before, and until a few days ago they came up with the six most common edit summaries I had used in those particular sections and would only show the relevant summaries if I added more text e.g. user talk warnings - each month I had to start again so I edited an April 2021 section and it gave me /* April 2021 */ so I added say Vandal 2 warning, or Unsourced 3 warning, etc. which then popped up again when editing another April 2021 section. When there were more than six summaries it showed the most popular, which could be refined. By typing say V it would give me Vandal 1 warning, Vandal 2 warning ... etc and not show the summaries not beginning with V. As stated above, the suggestions still appear when editing the whole page, but not the suggestions for a section even if I type in the /* title */ - Arjayay (talk) 14:52, 26 April 2021 (UTC)[reply]
There is an option "Add two new dropdown boxes below the edit summary box with some useful default summaries" at Special:Preferences#mw-prefsection-gadgets. It creates a drop-down and not a popup so I guess you do refer to a browser feature. It only works when you use the same browser on the same computer. Such a feature will typically suggest previously entered strings which start with what is already in the field including the default summary. For common section names like "See also" and "External links" it's likely to remember past summaries. For rare or unique summaries like /* Edit summaries when editing by section */ there is usually only a chance of a match if you have edited the same section before. PrimeHunter (talk) 13:58, 26 April 2021 (UTC)[reply]
I'm afraid the dropdown boxes are remarkably useless. Yes. it is a pop-up, which I still get when editing the whole page, but they suddenly stopped working for sections, - OK so its a Microsoft issue - shame, because it really saved a lot of time, and simplified complex summaries with wikilinks to policies and guidelines and quotations from them . Thanks for trying to help anyway - Arjayay (talk) 14:52, 26 April 2021 (UTC)[reply]
So, there are two ways for these dropdowns to show up that are "native" (i.e. not from the gadget that PH has pointed out). One is the one that xaosflux pointed out, and applies to the 2006/2010 WTEs. The summary generator for the 2017 WTE and VE uses your 50ish most recent edits and is generated by VE. It does not look like you are using VE, so this is probably a browser issue. (It is possible that the WMF has screwed that up while they've been working on Desktop Improvements, but I don't know of an "easy" way to make that screwup happen.) Izno (talk) 14:26, 26 April 2021 (UTC)[reply]
I'm certainly not using VE, and there are literally thousands of summaries stored, for editing the whole page, which I can still find by "drilling down" - I may have to avoid editing by section, or get used to typing a lot more repetitive summaries - Thanks anyway - Arjayay (talk) 14:52, 26 April 2021 (UTC)[reply]
It may not have been intentional on Microsoft's part. You can try filing a bug with them -- I don't know how, but there is that. Izno (talk) 15:04, 26 April 2021 (UTC)[reply]
I have this "saved summary" feature in Firefox, and it also lost the ability (a year or two ago?) to pop up saved summaries when the section heading is pre-populated. My workaround is to select all (Cmd-A), delete the section heading, and type part of my saved summary. That works great and is fast. – Jonesey95 (talk) 15:40, 26 April 2021 (UTC)[reply]

class to show an element to mobile devices only

Good morning. Is there a class to show an element to mobile devices only, avoiding it from appearing in the desktop version? If anyone knows how, could you tell me below with an explanatory example? Thanks in advance for your reply --Fierodelveneto (talk) 16:11, 26 April 2021 (UTC)[reply]

No such class exists, though I can think of a few ways to do it, and there might even be a template hiding around these days.
In the general case, if you want to show something to mobile and not to desktop, the design you are entertaining is a bad design. You should reconsider what you are trying to do. Izno (talk) 17:08, 26 April 2021 (UTC)[reply]
(edit conflict) I'd like to know this too, and if there isn't a way then I think there ought to be. I also disagree with the idea that showing something on mobile and not on desktop is entertaining bad design. Responsive web design is often essential to ensure useability, and there are many aspects of WP where (conversely) things that are visible on desktop are not visible on mobile. I recently made some minor edits to the ANI header because links to the archives are only visible on desktop. It would be good to only show the links I added when viewed on mobile. nagualdesign 17:33, 26 April 2021 (UTC)[reply]
The point of responsive web design is in fact to display things regardless of form factor. Secondly, websites are penalized by Google when they provide inconsistent desktop and mobile views. (And by inconsistent I mean "displays one thing in one view and not in the other", not "stuff moves around".) Now, Google also penalizes people for slow websites, which is why you can't see navboxes on mobile today. We take the associated penalty in PageRank for particularly navboxes missing because their links are valuable to search spiders if not people in the general case. Izno (talk) 17:46, 26 April 2021 (UTC)[reply]
Fair point, but sometimes the only way to "move things around" is to have mobile-only content and desktop-only content on the same page. The {{If mobile}} template is a very useful tool to achieve that. nagualdesign 17:57, 26 April 2021 (UTC)[reply]
Thanks GhostInTheMachine, but the template doesn't seem to work on my phone. The examples in the doc do not show up. nagualdesign 17:38, 26 April 2021 (UTC)[reply]
Scratch that. It works fine. Cheers. nagualdesign 17:43, 26 April 2021 (UTC)[reply]

Re: The article Fixed Income Analysis: I added 7 citations. Oddly, those cites showed up as numbered footnotes under External Links. I'm used to seeing them listed in a References section, which usually appears automatically. Any ideas on why this happened and how it could be fixed? The article had no references/citations when I made my first edit to it. Cordially, BuzzWeiser196 (talk) 20:35, 26 April 2021 (UTC)[reply]

Hello BuzzWeiser196. You need a reference section header and template for them to show up properly. Without them the default is to place them at the bottom of a page. I have added them with this edit. Best regards. MarnetteD|Talk 20:40, 26 April 2021 (UTC)[reply]
Thank you MarnetteD. My best to you, BuzzWeiser196 (talk) 20:50, 26 April 2021 (UTC)[reply]

21:22, 26 April 2021 (UTC)

Template:verify quote

In this edit, I just used Template:verify quote for the first time. As suggested on that page, I used a text= parameter to indicate what the perceived problem was. But viewing the page in Firefox, I do not see any text displayed when mousing over the spot. I usually have JavaScript disabled in Firefox, but enabling it for both wikipedia.org and wikimedia.org made no difference.

Huh? --184.147.181.129 (talk) 22:26, 26 April 2021 (UTC)[reply]