Hello, on the Desktop Improvements/Vector 2022 talk page on mediawiki.org, there's sort of a "bug report", but we at the WMF can't fix it. It's about something that's totally up to the local communities - in this case, the English Wikipedia community.

It's about coordinates. As you can see on this screenshot, these are too close to the FA and page protection icons. @Jdlrobson has shared two ways of fixing the issue. I think we can say now that we strongly recommend using the indicator tag, so Jon's Option 1. It requires changes to Module:Coordinates.

@TheDJ, Sdkb, and Xaosflux: FYI.

Thank you! SGrabarczuk (WMF) (talk) 22:59, 20 July 2022 (UTC)[reply]

@SGrabarczuk (WMF) Here is an example of a live overlapping page. Note, this template is used on over 1 million pages - so changes will need to be carefully considered and tested. Also, I think we'll need some editor to decide from a presentation viewpoint how this should be best laid out for our readers (assuming there certainly would be push back of "get that big language thing off of the top, it just sends readers away from our project!"). I actually sort of like coordinates where it is there - it is "content" after all; maybe the meta-indicators could move (perhaps to the left of the language bar??). — xaosflux ^Talk 23:44, 20 July 2022 (UTC)[reply]

I replied on Phabricator, but I'll say again here that, as I've advocated elsewhere, I think the best place for the good/featured article icons is directly after the title, as that will make it far more prominent, which is needed for information literacy.

For the protection icons, I think that should be associated with the edit button, since the main question for most people related to protection is "can I, with my current permissions, edit this page"? Minerva Neue handles this quite well, where if you can edit the page, you get an edit button, and if not, it's grayed out or locked or something and explains why. There's a bit of value also for just letting readers know the protection level so that they can understand how vulnerable the article they're reading may be to vandalism, but that's secondary and I don't think requires a very prominent notifier. {{u|Sdkb}} ^talk 01:28, 21 July 2022 (UTC)[reply]

Having core handle icons for protection is phab:T12347. Izno (talk) 02:54, 21 July 2022 (UTC)[reply]

Authored By bzimport Jun 23 2007, 5:24 PM. Ugh. Will there ever be any technical issue where we don't spend 20× as much energy flagging it as it'd take to actually solve? {{u|Sdkb}} ^talk 04:40, 21 July 2022 (UTC)[reply]

One option to consider is making coordinates a first class citizen in skins. @TheDJ: I made this POC to demonstrate one option which could be enabled on a skin basis. You could display:none the current coordinates in that skin to buy more time. Let me know if you feel this approach has any legs and is worth pursuing further: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/GeoData/+/816009 Jdlrobson (talk) 16:11, 21 July 2022 (UTC)[reply]

@Sdkb thanks for these points. I agree regarding the protection icons. Seems like we've got a clear way forward there. Regarding placing the good/featured article icons directly after the title: firstly I agree that it would make them more prominent. The main question that comes up for me is: what kind of research/testing can we do to figure out how people interpret these icons? I think they have a lot of potential to help people understand the article quality, which could benefit the reading experience. But there is also a lack of standardization across wikis, and also possible confusion with other icons on the page (e.g. the Watchstar vs. the featured article star), which makes me curious to learn more about user experience before increasing the prominence. Interestingly a couple of years ago some folks at the foundation partnered with the HCI department at Carnegie Melon to do some related research, which you can read here: https://drive.google.com/file/d/1UCdW37reywLLc4r50pJHSQl3JfYxRHLU/view?usp=sharing.

In summary, I support the goal of learning more about how people understand the good/featured article icons which I think will enable us to find the appropriate location for them. This research could also give us useful insight into the design of the icons themselves. AHollender (WMF) (talk) 16:02, 28 July 2022 (UTC)[reply]

@AHollender (WMF), thanks for engaging on this! I skimmed that CMU article, and it's quite interesting, although the evaluation tools it envisions sound technically very advanced. I'm not an expert in creating research/testing plans, but here are my thoughts.

Overall, our goal is to help readers be able to better judge quickly and easily how trustworthy the content they read is, so that they can decide how best to make use of it. To do that on a design level, we want to highlight factors that help with this decision enough to encourage readers to pay attention to them.

The first step is figuring out what those factors are. To answer that, you'd want to convene a focus group of experts in judging trustworthiness of information on Wikipedia and present them with articles to rapidly evaluate. Experienced Wikipedians, librarians or other researchers, and information scholars all might have relevant input. In a sense, you've already got a focus group of sorts of Wikipedians here; we can tell you that GA/FA stars are extremely important indicators when we're judging an article at a glance (other factors include presence of maintenance tags; references, sometimes aided by tools like Cite Unseen; and talk page activity).

Next, you'd want to convene a focus group of average readers and give them the same task. See if they use the same factors or different ones. If they completely ignore the GA/FA icons that the experts thought were crucial, you've established through testing the need to make them more prominent.

The last step would be figuring out the best way to do so. Danish Wikipedia already has GA/FA icons after the article title, e.g. here, so you could collect survey data from that. If the reader focus group is prompted to consider the icons, they'd probably also have thoughts. I agree with you that the current design of the icons is potentially an impediment to them being understood well.

Does all that help speak to your question? Cheers, {{u|Sdkb}} ^talk 05:13, 29 July 2022 (UTC)[reply]

This is in progress, but it's hard when very long standing conventions have to be adapted. There are all kinds of hacks and overrides in place and multiple variants of templates that get affected once we start messing with the coordinates id (of which Module:Coordinates is the most prominent and most visible user) AND we have to keep into account all the skins, not just the one. Because of that, everyone is just afraid to break things and that causes stagnation in making progress in implementing the solution.

Last but no least of all, even if we turn it into an indicator (which we really should), that doesn't mean the position and layout of the options makes sense to people. This has been conveniently ignored by the team so far, delegating the making of a new design to the communities, but the old design and positioning was a VERY old convention and is deeply settled in people's customs. Convincing people of a new layout in such a situation is challenging. —TheDJ (talk • contribs) 09:38, 21 July 2022 (UTC)[reply]

The "layout" question is something to deal with indeed. SGrabarczuk (WMF) and maybe @OVasileva (WMF): - how much of this reading layout is going to be driven hard centrally, and how much is it lassie-faire for communities? Seems like we're already in the what tech changes to make stage - but the UX/UI layout regarding presentation of page meta-content isn't stable yet? I suppose the hard-line from mediawiki software side is: it works fine, stop putting these things on pages if you don't want them to break -- but our editors have found that this sort of content is well received with our readers. — xaosflux ^Talk 14:05, 21 July 2022 (UTC)[reply]

@Xaosflux, I don't quite understand the last sentence. Could you rephrase? SGrabarczuk (WMF) (talk) 14:31, 21 July 2022 (UTC)[reply]

@SGrabarczuk (WMF) in addition to the traditional "content" seen on pages, especially in encyclopedia articles, we have found it useful to inform readers and potential editors about meta-content, such as if we consider a page a quality page (FA, GA, etc), if we have applied restrictions to editing (protection status). In the most commons layouts (monobook, then vector). As there wasn't a designed section in mediawiki software for this meta-content display - we decided to place it above the content area. With the new vector-2022, the location we would use this for is now consumed with a new UI element (the language selector). Before we go about trying to make a "local" workaround for this, I'm asking if there is any design work from the reading team or other in the new skin team about how to present such indicators/meta-content in general for any project using mediawiki - and if so so, how firm current choices are — xaosflux ^Talk 14:44, 21 July 2022 (UTC)[reply]

p.s. things like 'coordinates' are actual factual information about the subject of an article, so I don't really see them as 'meta-content'. — xaosflux ^Talk 14:45, 21 July 2022 (UTC)[reply]

OK, ok. I've written a few GA's myself, so I totally understand the underlying issue. But then again, using the indicator tag for the coordinates wouldn't be local and wouldn't be a workaround. It'd be an application of the MediaWiki standard. As for the design work you mention, we did take a look, but that would be beyond Desktop Improvements 1.0, so we didn't pursue that path. SGrabarczuk (WMF) (talk) 14:56, 21 July 2022 (UTC)[reply]

@SGrabarczuk (WMF) thanks, can you point to any "indicators" design layout/documentation pages that were updated for vector-2022? (Is mw:Help:Page status indicators the most current?) That page doesn't have any vector-2022 updates on it, but does use the "outside of the main content" design guide. — xaosflux ^Talk 15:03, 21 July 2022 (UTC)[reply]

Because while this thread started with asking about "coordinates" - it seems like our design collision is that now our meta-indicators are inside the content area in vector-2022, I'd think moving them would be more of a priority. — xaosflux ^Talk 15:07, 21 July 2022 (UTC)[reply]

But it is a change from the current design. You force us to make a change and then say "well we didn't think about how it should be done, you figure it out". Now suddenly that makes the template editor the fixer, the designer and the wall for ppl to shout at because they don't like it. Can you see why that doesn't make it the highest thing on my and others 'lets relax with some wikipedia editing' evening ? ;) —TheDJ (talk • contribs) 15:03, 21 July 2022 (UTC)[reply]

@SGrabarczuk (WMF) / @Jdlrobson - follow up on question about using "indicator" as suggested, it seems that the indicator design is also now "inside the content area" in vector 2022; compare the icon in the top right on vector vs vector-2022 on testwiki; which doesn't follow the notes at mw:Help:Page status indicators. Is there a vector-2022 "outside the content area" indicator section still? — xaosflux ^Talk 12:28, 22 July 2022 (UTC)[reply]

Just a note that i still consider this to be outside the content area. As in: "if i just write text in a wikitext page, this is not a position that that text could normally end up at." —TheDJ (talk • contribs) 20:24, 28 July 2022 (UTC)[reply]

@TheDJ, you write "There are all kinds of hacks and overrides in place and multiple variants of templates that get affected" - and would this all be true if the indicator tag was used? Could you give some examples perhaps? SGrabarczuk (WMF) (talk) 14:43, 21 July 2022 (UTC)[reply]

Template:Sky reused the coordinates id until recently, but also Module:Attached KML does (and probably a few more). These need to be dealt with as well. Then there is Template:Coordinates itself, which' output gets read by other modules (this is the infamous coordinsert hack). Then all the skins, which have different positioning and we need to put CSS in place that can work with both the before and after situation. All this requires hours of work and review and testing and moving slowly. And even if you can find a few hours to work on this it's not the most fun and once you are done, you might have to deal with the fallout (ppl yelling at you). —TheDJ (talk • contribs) 14:59, 21 July 2022 (UTC)[reply]

I removed the instances Special:Search found last night (query, removals are from 19:56 EDT, 23:56 UTC?). None of them should have been using #coordinates besides Attached KML and Sky.

Otherwise, I agree totally with TheDJ in his commentary here, especially when the research for moving ULS is as specious as it is. "We moved something above the fold, will it increase attention?" Gosh, IDK, will it? The question asked should have included "what lives in this space and will that decrease that attention". Izno (talk) 15:21, 21 July 2022 (UTC)[reply]

As for the design work you mention, we did take a look, but that would be beyond Desktop Improvements 1.0, so we didn't pursue that path. @SGrabarczuk (WMF), I'll quote from my comment at VPR, which I understand you intend to reply to at some point: "I don't understand that — you consider it in scope to push them out but not to care about where they're pushed to?" {{u|Sdkb}} ^talk 15:46, 21 July 2022 (UTC)[reply]

Regarding the positioning of coordinates and page indicators: we have created a design spec that we hope can provide guidance (and eventually result in consistency across our projects).

Here are four examples of how coordinates and page indicators would look if we followed the design spec:

• 
  Coordinates and indicators in Vector 2022 (Russian Wikipedia
• 
  Coordinates and indicators in Vector 2022 (French Wikipedia)
• 
  Coordinates and indicators in Vector 2022 (English Wikipedia)
• 
  Coordinates and indicators in Vector 2022 (Japanese Wikipedia)

One issue that has been raised in the past is the blank space on wikis that don't display the From Wikipedia... tagline. At first we thought that it could make sense to shift the coordinates and indicators over in this case, to fill that space. However after further consideration we think that consistent placement of these elements across various wikis is more important to prioritize. (I do wonder if some of these wikis will decide to turn on the tagline in order to balance that area out a bit more)

We hope that this design spec helps us move towards a more organized and consistent top-of-page experience in Vector 2022. Please let us know what you think. Thanks. AHollender (WMF) (talk) 21:21, 27 July 2022 (UTC)[reply]

As I noted in the phab ticket, I don't think that "coordinates" are "meta data", it is not information "about the page" - it is user generated content about the subject. That this happens to be "coordinates" is also very odd that a software design would call it out there, any project could have any other sort of content there - perhaps a dictionary would want to have some sort of "source of origin", perhaps the magic the gathering wiki would want to have the "mana colors" there, etc. — xaosflux ^Talk 22:16, 27 July 2022 (UTC)[reply]

Also just noted this in the phab task, but in case some people aren't reading that I'll add it here too: I think it's okay to separate this somewhat new discussion of "should coordinates be considered metadata, and if not where should they be displayed?" from the initial discussion in this task about resolving the issues where coordinates and indicators are overlapping other contents. I realize it might seem silly to move coordinates twice, but I think it might simplify things to first move coordinates just below the page titlebar underline, into the page toolbar (which is like a ~10px move), and then start a separate discussion if people think there might be value in moving them even more.

(Hopefully not contradicting myself too much here by adding a note about the second discussion, which again I think can happen in a separate task — I think we should keep in mind that coordinates are, at least in most cases, redundant. They are shown at the top of the article, and within the Infobox. I think in order to have a good discussion about where to put them we should first collect data regarding clicks to the two different coordinates links). AHollender (WMF) (talk) 15:07, 29 July 2022 (UTC)[reply]

@AHollender (WMF) long debates have resulting in our current style guidelines that the inclusion, or exclusion, of infoboxes in articles is optional, for example here is a page with coordinates, w/o an infobox: One Bangkok. I think this discussion is getting very fragmented across multiple on- and off-wiki pages right now as well. — xaosflux ^Talk 15:17, 29 July 2022 (UTC)[reply]

• We've had a lot of good initial conversation, but we need to get our to our community the main question of: "Where on our articles do we want to present this information to our readers?". Being able to have some technical mock-ups for decision making may be useful. — xaosflux ^Talk 20:06, 28 July 2022 (UTC)[reply]

  +1 on this, and on the metadata comment right above. {{u|Sdkb}} ^talk 05:25, 29 July 2022 (UTC)[reply]

Updates for technical blocker list to make any progress whatsoever on this topic are detailed ate Module_talk:Coordinates#Outstanding_problems_for_indicators —TheDJ (talk • contribs) 20:21, 28 July 2022 (UTC)[reply]

Well friends, I'm stumped again – isn't the first time and won't be the last. Seems that a recent change automated the application of {{Documentation subpage}} to not just template /doc pages but also to all the redirects to those pages. An example is Module:Infobox3cols/doc, which targets its associated template /doc page. My own humble opinion is that the doc header shouldn't be on redirects, it should only go on actual template documentation pages. Placing the doc header on all subpages named "/doc" gives an incorrect transclusion number for the "Documentation subpage" template. I think the interface page that transcludes the template is MediaWiki:Scribunto-doc-page-header, however I'm not certain of that. Just wondered if any of youse-much-more-savvy-than-I technical minds can figure a way to remove the doc header from all the /doc page redirects? P.I. Ellsworth , ed. ^put'r there 12:12, 21 July 2022 (UTC)[reply]

The only think I can think of is to use a module for checking whether a page is a redirect or not. Module:Redirect should work (using its isRedirect feature). Then, we can put a test on the MediaWiki page to see if the page is a redirect, and hide the header if it is. --ais523 12:55, 21 July 2022 (UTC)[reply]

Thank you! that's what I was thinking, too. I just want to be sure we have the correct MW page before we put an edit request on its talk page. I'm not too strong when it comes to modules, so I'd need help with adding the isRedirect feature to the interface page. P.I. Ellsworth , ed. ^put'r there 13:07, 21 July 2022 (UTC)[reply]

Talkpage redirects

Here is another with auto-generated text, this time it asks editors to discuss the sandbox page. And of course redirects are not the place for discussion, not even talk-page redirects. I don't think these are being tested so as to eliminate usage on certain pages. They're just being "hopefully applied". I can identify with that; however, these messages on redirects should be erased. P.I. Ellsworth , ed. ^put'r there 19:45, 21 July 2022 (UTC)[reply]

@Paine Ellsworth: I've now created {{redirect other}}, which (assuming that it works in MediaWiki:-space; I think it will, but MediaWiki:-space is weird sometimes) should make it easy to implement a change like this. (Note that the template will need to be fully-protected in order to be usable as part of the site interface.) --ais523 23:14, 21 July 2022 (UTC)[reply]

So, does anyone know with relative certainty which pages in the MediaWiki namespace apply the Doc subpage and the talk page templates in question? I'd like to place edit requests to remove those templates from redirects where they should not be. P.I. Ellsworth , ed. ^put'r there 14:24, 26 July 2022 (UTC)[reply]

@Paine Ellsworth MediaWiki:Scribunto-doc-page-header and MediaWiki:Watchlist-messages seem to be the only pages that use it unconditionally (the latter because it's a template used in MediaWiki:-space which has a documentation subpage of its own, in MediaWiki talkspace – it doesn't show up when looking at the watchlist, only when looking at the page directly). I've been trying to construct a search for conditional uses, but haven't found one that works yet. I suggest putting in an edit request for MediaWiki:Scribunto-doc-page-header first, and then we can check if there are still problems elsewhere. --ais523 12:04, 30 July 2022 (UTC)[reply]

Thank you, editor ais523! An edit request has been opened at MediaWiki talk:Scribunto-doc-page-header, which suggests the use of your {{Redirect other}} template. Haven't been able to find a page in MediaWiki namespace that applies the invitation to start a discussion incorrectly to talkpage redirects, so that one might need a bug report to fix. P.I. Ellsworth , ed. ^put'r there 20:14, 30 July 2022 (UTC)[reply]

Okay, the challenge of removing the doc subpage template has been met and fixed with this edit. Still looking for help and guidance as pertains to the automatically placed invitation to discuss found on all talkpage redirects, such as found here. Don't know if there is a similar page in the MediaWiki namespace, where I can place a fully-protected edit request, or if this is something the devs need to fix directly. P.I. Ellsworth , ed. ^put'r there 22:57, 30 July 2022 (UTC)[reply]

Seems to be more than one Phab page that discusses something similar, such as T270323, so it does appear that this is up to the devs to fix. Talkpage redirects especially do not need the new talkpage tool that suggests that editors begin a discussion directly on the redirect talkpage. P.I. Ellsworth , ed. ^put'r there 23:25, 30 July 2022 (UTC)[reply]

Here is an example of an uncreated talk page of a redirect that has the invitation to create the talk page on it. That notice must also be removed from those, as we don't really want to stimulate new editors to create a talk page and discussion that virtually nobody will read. That new discussion should be opened on the subject page redirect's target's talk page, where involved editors will read it. P.I. Ellsworth , ed. ^put'r there 16:29, 31 July 2022 (UTC)[reply]

A third case was found at Phab. It's the case when a redirect has already been created and is not itself a redirect, such as at Talk:Erase (song). That page went to AfD and was then bot-tagged with this edit. That also happens frequently, and as can be seen, the talk page also has the invitation to start a discussion about the subject-page redirect. I've suggested at Phab that the invitation should be removed from those pages as well, because we don't want new editors to think that such a page is watched enough to ensure a response. P.I. Ellsworth , ed. ^put'r there 02:21, 1 August 2022 (UTC)[reply]

Would it be possible to change MediaWiki:Logentry-pagetriage-copyvio-insert (edit | talk | history | links | watch | logs) so that parameter $4 is changed into a link to Special:Permalink/$4 (I don't recall, but if you can reuse the numbered parameter, it might even work as a param to e.g. Special:Diff/$4 so we could have a permalink and a diff right from the log)? Currently the log entries just contain a raw revision ID that is not clickable. See Special:Log/pagetriage-copyvio for examples. —Locke Cole • t • c 01:24, 27 July 2022 (UTC)[reply]

It's probably possible (it's hard to tell what will work in a specific MediaWiki message without trying it), but do we really want a log of links to potentially illegal content? PrimeHunter (talk) 02:39, 27 July 2022 (UTC)[reply]

Shouldn't matter, in the long run if it is a copyvio, it'll be WP:REVDEL'd anyways, so the links won't work unless you have the correct permissions. The current setup makes it more difficult than it needs to be to quickly check something and act on it though. —Locke Cole • t • c 02:51, 27 July 2022 (UTC)[reply]

Feel free to open an edit request at MediaWiki talk:Logentry-pagetriage-copyvio-insert , this message is fairly backstage so I'm not too worried about trying it, maybe something like [[Special:Permalink/$4|$4]] would work there. I don't think we have that set up on testwiki to try there. — xaosflux ^Talk 12:59, 27 July 2022 (UTC)[reply]

Hello! There are viewing a warning note in every subpages of javascript. For example: see this one . How can I solve it?--Abdullah☆ (Talk) 09:10, 27 July 2022 (UTC)[reply]

It's a permanent warning intended to educate you and cannot be removed or solved. It says "if you don't understand what you are doing, then this can potentially hurt your account". —TheDJ (talk • contribs) 10:08, 27 July 2022 (UTC)[reply]

It can be removed by hiding it with this in your CSS:

#jswarning {display:none;}

It doesn't "solve" anything but just hides it from display. PrimeHunter (talk) 12:10, 27 July 2022 (UTC)[reply]

@PrimeHunter thanks. I have added the code and successfully removed.--Abdullah☆ (Talk) 12:32, 27 July 2022 (UTC)[reply]

So, I was editing a page, and when I clicked the "Show preview" button, a warning text was displayed:

 Script warning: One or more {{cite web}} templates have maintenance messages; messages may be hidden (help).
 Script warning: One or more {{cite news}} templates have maintenance messages; messages may be hidden (help).

The "help" links were to Help:CS1 errors § Controlling error message display, which advises the user to include some code in "your common CSS page or your specific skin's CSS page (common.css and skin.css respectively)".

I was able to accomplish this task, but didn't see the maintenance messages before purging the page, which required another non-trivial step.

I suggest that this procedure is too complicated for the average editor, and should be automated.

If there's a warning concerning maintenance messages when previewing a page, there could be a simple button or slider that would toggle between showing and not showing the maintenance messages. Perhaps clicking the button or sliding the slider would also include the purge step, so that the user would not be stumped?

I started a discussion about this on the talk page of the template, and I've linked from there to the present section. I suggest discussion on this suggestion be continued here, not on the talk page.

On that talk page, user Trappist the monk has replied to my suggestion with the following: "It is not possible to automate the procedure because only you or those few editors with interface editing privileges can edit your .css page(s). Apparently you figured it out. If you can think of a better way to describe what needs to be done, edit the current description to make it better."

Perhaps it's not possible for most others to edit my .css page, but that just means that the procedure I suggest should not have to rely on the user's CSS. I'm not familiar with the details of coding the underlying system, but surely it should not be very difficult to toggle between displaying and not displaying these maintenance messages? Teemu Leisti (talk) 15:28, 27 July 2022 (UTC)[reply]

It seems that what you suggest is way beyond the scope of any single group of user-developed modules.

It is true that this is too complicated for the average editor. This is so because it involves above-average editing. 50.75.226.250 (talk) 16:09, 27 July 2022 (UTC)[reply]

It is in fact something that cannot be simplified. There are alternatives as complicated as the way provided, and those ways are more complicated for the maintainers of the systems of interest, so this is the way that is recommended. Izno (talk) 16:20, 27 July 2022 (UTC)[reply]

I'm not sure what can be "automated", but other additional error messages (like User:Trappist the monk/HarvErrors.js) can be enabled by technically less competent editors (I find reading Latin easier than reading CSS) via the gadget User:Enterprisey/script-installer. Is it possible to write a userscript that makes this easy without changing the underlying CSS method? —Kusma (talk) 16:28, 27 July 2022 (UTC)[reply]

How about a gadget "Display hidden maintenance messages (help)"? The help link would go to a page listing which types of mesages are displayed (e.g. Wikipedia:As of#Article maintenance) and how to control them individually with user CSS instead of the gadget. I don't think we should make a gadget only for the CS1 messages discussed here. Several gadgets for different types of messages would clutter up Special:Preferences#mw-prefsection-gadgets where we try to limit the number of gadgets. Scripts which add messages instead of just unhiding existing messages wouldn't be covered by the suggested gadget. PrimeHunter (talk) 16:45, 27 July 2022 (UTC)[reply]

A withCSS link (and a Mediawiki css pages containing the CSS) might work. ― Qwerfjkltalk 19:47, 27 July 2022 (UTC)[reply]

I don't know whether withCSS can be used in previews but it should at least work in a link to the saved version of the page. PrimeHunter (talk) 23:15, 27 July 2022 (UTC)[reply]

OK, so it doesn't look like there's great enthusiasm for my suggestion, and it's not really super important anyway. So never mind, I guess. Teemu Leisti (talk) 00:12, 31 July 2022 (UTC)[reply]

Looks like there's a minor glitch with how the {{unblock-spamun}} template displays. On several occasions, I have noticed users requesting an unblock with this template, but preceded with an indent (colon). When doing this, the border and background color that normally surrounds the text instead appears as a thin one-line box above it (sample diff). Removing the indent fixes the display issue (sample diff). Otherwise, the template still functions normally and the unblock request appears normally in CAT:UNB. I don't know if any other templates are affected by this issue. --Drm310 🍁 (talk) 15:27, 27 July 2022 (UTC)[reply]

The only way to fix this is removal of the colon, indeed. Izno (talk) 16:22, 27 July 2022 (UTC)[reply]

A number of box-type templates will break if indented - this typically shows as some (or all) of the text being ejected outside the box. The easiest fix is not to indent them. --Redrose64 🌹 (talk) 20:49, 27 July 2022 (UTC)[reply]

{{Get short description}} transcludes the target page to find the short description, but it also seems to transclude the categories and short description. Trying wrapping it in <nowiki>...</nowiki>, or using {{#invoke:Page|getContent|expand}} doesn't seem to work either. (Reposted due to a lack of response). ― Qwerfjkltalk 20:15, 27 July 2022 (UTC)[reply]

Moved from Wikipedia:Interface administrators' noticeboard

Some time in the last half hour or so, the interface starting doing a bizarre thing: I am logged in and start making an edit. When I try to preview or save, it says I am not logged in. If I try to log in it saves the page, but NOT THE CHANGES I was making and says I am logged in. Then it repeats the cycle and says I'm not logged in again when I try to edit. Goin' home now folks. I should note that I'm using the source editor. MaryMO (AR) (talk) 00:03, 28 July 2022 (UTC)[reply]

@MaryMO (AR): moved this here to VPT, a better forum forum for this issue. — xaosflux ^Talk 00:34, 28 July 2022 (UTC)[reply]

Hello . I want to install User:Þjarkur/Restorer.js in all wiki except bnwiki. Which code I should use in my global.js?--Abdullah☆ (Talk) 09:40, 28 July 2022 (UTC)[reply]

@MdaNoman see mw:Help:Extension:GlobalCssJs#To_exclude_a_wiki. — xaosflux ^Talk 13:45, 28 July 2022 (UTC)[reply]

After seeing the edit summary here, I looked at File:General-Shigenori-Kuroda.png; that navigated to File:IJA Japanese Major wearing an M98 tropical uniform.png. Wtmitchell (talk) (earlier Boracay Bill) 11:49, 28 July 2022 (UTC)[reply]

I'm not sure what your question is. The file was moved on Commons and left behind a redirect. It is confusing that Commons shows the "(Redirected from File:General-Shigenori-Kuroda.png)", while on enwiki, the redirect target is shown, the "Redirected from" is not shown, and the URL is not updated. I've found T127418 from six years ago. --rchard2scout (talk) 12:04, 28 July 2022 (UTC)[reply]

Hi all, carrying on this question from the help desk. Wikipedia has a number of index pages that show all the pages in a given top-level category in an A-Z format, for example Sociology. However, for the ones that I am interested in they are produced manually and often require a significant amount of work to make sure all the pages are included/ makes it difficult to keep up-to-date as new pages are created.

I was wondering if anyone knew of any wikicode, template, or other functionality that might allow for all the pages to be displayed on a page alphabetically based on a specific parent category. Essentially, to display all the pages located within "Sociology", but instead of something like a category tree, it would show all the individual pages nested within that category A-Z.

Thank you for any help you can give, and if I need to ask this elsewhere do let me know. If this is indeed a new kind of feature request, please do let me know where best to ask for this feature to be created. Jamzze (talk) 14:01, 28 July 2022 (UTC)[reply]

@Jamzze would Special:CategoryTree work for you? — xaosflux ^Talk 14:15, 28 July 2022 (UTC)[reply]

If so there are lots of things you can do with it, see mw:Extension:CategoryTree for documentation. — xaosflux ^Talk 14:17, 28 July 2022 (UTC)[reply]

Thanks for sharing this. From what I can read, this function does not present the pages alphabetically, but via their categories - unless I am reading it wrong? If so, this would not work out for an index. Jamzze (talk) 14:57, 28 July 2022 (UTC)[reply]

Sorting for the output of category tree is included in the 10+ year old task phab:T32753. Pages in categories are sorted on the category pages themselves(c.f. Category:Sociology). Keep in mind that categories are not a tree-hierarchy, but more of a spiderweb-hierarchy and may contain loops, forks, and deadends - which can make this difficult. For example on the "index" for "Sociology" would you want the article on Uniform Map, because if you transverse the category tree you will eventually get there. If so, it sounds like you want an enhancement request to mw:Extension:CategoryTree and you could start asking about it on mw:Extension talk:CategoryTree. — xaosflux ^Talk 15:44, 28 July 2022 (UTC)[reply]

Can't {{categorytree}}'s output be regexed with Lua, Xaosflux? — Guarapiranga ☎ 01:32, 29 July 2022 (UTC)[reply]

At the time Lua sees it, it's inside a strip marker. Izno (talk) 02:06, 29 July 2022 (UTC)[reply]

Can't it be {{unstrip}}'d? — Guarapiranga ☎ 03:32, 29 July 2022 (UTC)[reply]

The only unstripping Lua can do is the nowiki marker, which is what {{unstrip}} does. A nowiki strip marker is only one kind of strip marker. Izno (talk) 03:40, 29 July 2022 (UTC)[reply]

Right! Got it. Thanks. — Guarapiranga ☎ 03:42, 29 July 2022 (UTC)[reply]

Thanks @Xaosflux @Guarapiranga @Izno for all your inputs - some of this is far beyond my knowledge, so will link this to the pages Xaosflux suggested! Jamzze (talk) 12:03, 30 July 2022 (UTC)[reply]

I think it is an two step process. For an external list you could use petscan. You need to use the settings in order to sort the results, it does not do that by default. If this would be automated it would probably done with bots, pywikipediabot and AWB both can make lists, but do not do what you want out of the box, so some coding is needed.--Snævar (talk) 16:58, 28 July 2022 (UTC)[reply]

Thanks! Jamzze (talk) 12:03, 30 July 2022 (UTC)[reply]

Something strange is happening when using the desktop version of Wikipedia on mobile. For one, when moving to a new page on Wikipedia, the page is zoomed in quite a bit on the top-left side of the page where the Wikipedia logo/link is located. In addition, the search bar on the top right of the page is considerably smaller than it used to be ... like less than half its previous size. I have confirmed this issue exists on multiple browsers (Safari [I'm using an iPhone] and Firefox) and persisted after I cleared my browsers' cache and cookies. This problem occurs while using either the "Vector legacy (2010)" or the "Vector (2022)" skin. Steel1943 (talk) 20:32, 28 July 2022 (UTC)[reply]

Happening with Chrome too. Annoying! Neiltonks (talk) 22:01, 28 July 2022 (UTC)[reply]

Happening to me too. Came here to post but this was already here. Please revert the changes. —pythoncoder (talk | contribs) 22:00, 28 July 2022 (UTC)[reply]

This has been the case on all other wikis for some two days. Only now also on enwiki. I posted on Commons when it first started there: c:Commons:Village pump/Technical#Weird observations.Jonteemil (talk) 22:54, 28 July 2022 (UTC)[reply]

The "Edit source" button on SVG files, for example File:FK Mladost GAT logo.svg, also became messed up at the same time the other problems arose. @TheDJ: 1. Can you reproduce this? 2. Is this also because of phab:T311795? Edit: I could only reproduce this using the "Vector legacy (2010)" skin. Jonteemil (talk) 19:59, 29 July 2022 (UTC)[reply]

Anyone know what to do on Phabricator to hopefully get this resolved? Apparently, putting comments on a ticket in "RESOLVED" status goes nowhere. Steel1943 (talk) 11:36, 30 July 2022 (UTC)[reply]

I reopened the ticket linked above. Not sure if I’m “supposed” to do that but this needs to get fixed. —pythoncoder (talk | contribs) 20:39, 31 July 2022 (UTC)[reply]

Chrome mobile issue

For some reason within the last few hours when I load a Wikipedia page using Chrome on my mobile device, the page appears bigger than my screen. I can easily zoom it back down, but I didn't have to do this before. I don't think I changed any settings. Any ideas? 331dot (talk) 00:28, 29 July 2022 (UTC)[reply]

@331dot: Duplicate of #Search box and default zoom messed up while using desktop on mobile?Jonteemil (talk) 01:05, 29 July 2022 (UTC)[reply]

I'm assuming this is a side effect of phab:T311795, which was needed because of phab:T306910. —TheDJ (talk • contribs) 08:35, 29 July 2022 (UTC)[reply]

Same issue experienced by me too, on MS Edge on Android. —CX Zoom[he/him] ^{(let's talk • {C•X})} 09:40, 29 July 2022 (UTC)[reply]

I'm seeing this afternoon an issue with Twinkle warnings. They are writing up and duplicating the sets of == in the section titles, so instead of "July 2022" it's showing as "== July 2022 ==".

Is this occurring for others? This is one example, another is the one I left at the bottom of my own talk page (as a test) if you need visual examples.

If this is not the correct place to report a Twinkle issue, how and where would I go about getting this reported/fixed? Thanks, Zinnober9 (talk) 20:34, 28 July 2022 (UTC)[reply]

It's been reported to WT:Twinkle#Bug report: malformed headers. Note that it's Thursday, so that may be a factor.  MANdARAX  XAЯAbИAM  20:55, 28 July 2022 (UTC)[reply]

Ah, thank you! Zinnober9 (talk) 21:00, 28 July 2022 (UTC)[reply]

With reference to Wikipedia:Mobile communication bugs, we've also got a serious problem communicating with IPv6 users. I'm not sure where any centralized discussion of this may have been held recently.

Since IPv6 works differently than v4, not many of us understand it very well. One of its fundamental principles is the 64-bit Interface Identifier. In practice, every consumer who is assigned an IPv6 address receives 64 bits worth of space to play with. Therefore the first 64 bits may remain quite stable to identify a single customer and the last 64 bits may change at the drop of a hat!

Therefore, almost every IPv6 user is also an IP-hopper, whether we like it or not. Every IPv6 user has potentially 18,446,744,073,709,551,616 user talk pages! Every IPv6 user who edits over a long period of time is going to rack up talk pages and disparate contributions like the most prolific socking IP-hopping vandal we've ever seen.

So the net result is that we cannot know the history of an IPv6 user's warnings and communications. We can look back through their /64's contributions and see which addresses they've used, but the process of reviewing each talk page (and looking into its history for deleted warnings) is daunting, laborious, and ... ain't nobody got time for dat. If I drop a warning or a friendly message to an IPv6, by the time I'm done writing it they've already moved on to greener pastures, and will never ever see those talk messages again. MediaWiki naively believes they don't belong together, but they do. No IPv6 user can ever enjoy a meaningful body of communication with other editors over any period of time.

So, I don't know what the WMF has in store for anonymization. Perhaps this is all moot when they remove IP-based identification from the Wiki as I suppose is in the works? Will this particular issue become obsolete at that point?

How far off is that future? Is there any mitigation for it until then? Elizium23 (talk) 04:15, 29 July 2022 (UTC)[reply]

Perhaps this is all moot when they remove IP-based identification from the Wiki Yes, this issue will be fixed due to the method selected as a replacement for tracking an unregistered contributor ("session-based"). Izno (talk) 04:24, 29 July 2022 (UTC)[reply]

• This appears to be getting discussed in phab:T112325. — xaosflux ^Talk 14:30, 29 July 2022 (UTC)[reply]

Otherwise known as Fabricator bug # T311119.

After absence of a few days, I opened a page on Wikipedia to find the font sizes were suddenly very small. Since I reported this bug, I have gotten a bit more skilled with managing features on my iPad, & found I could easily adjust the font sizes in Wikipedia -- which was not the case up to a few days ago. (The log in Fabricator claims the bug was fixed over a month ago, but until today I never saw any improvement.

In other words, something happened to fix this bug, & while I don't claim to know what was changed, feel duty bound to pass this information along. (Maybe my bug was not the one reported in Fabricator? Or maybe there was a caching issue that caused a delay in my seeing the fix?) -- llywrch (talk) 04:39, 29 July 2022 (UTC)[reply]

You probably also experienced phab:T311795, which was fixed this week. —TheDJ (talk • contribs) 08:26, 29 July 2022 (UTC)[reply]

Hi, for some reason the photo montage is pushed to the side and From left to right caption sticking out at the top. Can somebody move the "From left to right" to underneath the photos so the images neatly span the width of the infobox? Looks ugly sticking out like that!♦ Dr. Blofeld 11:53, 29 July 2022 (UTC)[reply]

@Dr. Blofeld, it displays fine for me (on a tablet in portrait mode). ― Qwerfjkltalk 12:03, 29 July 2022 (UTC)[reply]

I'm on PC at the moment. Mumbai looks fine, Delhi montage is bunched to the left with a big white gap down the right due to the caption.. See screenshot Qwerfjkl♦ Dr. Blofeld 12:11, 29 July 2022 (UTC)[reply]

Weird, when I change the {{multiple image}}'s width down to 100, I also see the caption beside the images. But, this time the caption is to the left of images. At the current width (250), my screen shows infobox as expected. Noting that reducing Mumbai's width down to 100 doesn't change the position of image caption. —CX Zoom[he/him] ^{(let's talk • {C•X})} 13:07, 29 July 2022 (UTC)[reply]

The floating alignment is the problem. Now centered —TheDJ (talk • contribs) 14:30, 29 July 2022 (UTC)[reply]

Gracias TheDJ!♦ Dr. Blofeld 15:58, 31 July 2022 (UTC)[reply]

Hello. I am asking this for Marathi Wikipedia (mrwiki). A similar question was asked a few years ago by user:अभय नातू at Wikipedia talk:Red link/Archive 6, but the discussion didn't give out any results.

In short: there are around 90k articles on Marathi Wikipedia, and tons of orphan articles, and redlinks (often incorrect spellings). Is there any way to find/create a list of articles containing redlinks? Regards, —usernamekiran (talk) 13:52, 29 July 2022 (UTC)[reply]

@Usernamekiran not exactly what you are asking, but if their goal is to go through their redlinks, Special:Wantedpages will list them in order of how many times each redlink is called. — xaosflux ^Talk 14:04, 29 July 2022 (UTC)[reply]

@Xaosflux: yup, found it at mr:विशेष:हवे असलेले लेख. Thanks a lot for your help. —usernamekiran (talk) 14:15, 29 July 2022 (UTC)[reply]

Just now I was going through UAA, and I noticed on my dropdown menu the Block option was in much bigger text than anything else. It's so large it's displacing the options immediately around it. I'm on an iPhone in desktop mode, using the default skin, and I have a few scripts that show up on the dropdown menu in addition to the standard delete and block options. Anyone else noticing something similar? The Blade of the Northern Lights (話して下さい) 14:31, 29 July 2022 (UTC)[reply]

@The Blade of the Northern Lights can you be a bit more specific? For example, here is your userpage, in vector, in safemode: https://en.wikipedia.org/wiki/User:The_Blade_of_the_Northern_Lights?useskin=vector&safemode=1 "Block" isn't in a "drop down menu", it is on the left sidebar. — xaosflux ^Talk 14:42, 29 July 2022 (UTC)[reply]

Sorry for the confusion. It's under the "more" tab between the watchlist star and the Twinkle dropdown. I'm sure there's a proper term for it, I just don't know. The Blade of the Northern Lights (話して下さい) 14:46, 29 July 2022 (UTC)[reply]

@The Blade of the Northern Lights ah ok, it looks like that is a personal userscript you are importing, User:Animum/easyblock.js. The maintainer for that script hasn't really been active since 2015, you may want to stop using that one. If someone has a fix to propose, they can try dropping an edit request at User talk:Animum/easyblock.js. — xaosflux ^Talk 14:53, 29 July 2022 (UTC)[reply]

Makes sense. Not sure why it started acting up today of all days, but no reason to keep something that dated. Thanks! (Also, if anyone knows any maintained scripts that do something similar, I'd give one of those a try) The Blade of the Northern Lights (話して下さい) 15:10, 29 July 2022 (UTC)[reply]

My external links under Vector 2010 are now displaying as the indicator. Anyone know where's this change is coming from and why and where the discussion would be? Jason Quinn (talk) 14:44, 29 July 2022 (UTC)[reply]

@Jason Quinn: the technical answer to your question is: see phab:T261391. — xaosflux ^Talk 14:48, 29 July 2022 (UTC)[reply]

Great. Thank you. Rather than an image, I wonder if a UNICODE character like ⧉ or 🔗 would satisfy the web design guidelines they are following. Jason Quinn (talk) 16:06, 29 July 2022 (UTC)[reply]

This is also under discussion at WP:VPPRO#RfC: Should we use the longstanding external links icon or the new one?, but the change has been reverted for the moment. Izno (talk) 16:10, 29 July 2022 (UTC)[reply]

Is there any sort of script that exists or other implementation that is able to show when editing a section if there are redirect pages currently targeted to that section? I know one can go to the "What links here" and select only redirects for any page to see this, but I didn't know if there was the ability to see this while editing or previewing a page. I'm thinking it as a way to know what is linking to a section in question, in the event the heading needs to be altered or the section gets moved elsewhere to a more relevant page (if applicable), to know if anchors need to be added, or at the very least to be aware of such pages to help fix redirect locations without leaving them potentially broken. Thanks. (Also apologies if this isn't the correct location to inquire about such a thing.) - Favre1fan93 (talk) 15:31, 29 July 2022 (UTC)[reply]

I had a question about what to do to fix the openstreetmap-based map that I am trying to put into this one page. On the Ahmedabad-Dholera Expressway page, you can see that I have added the source code but something is still wrong. I have added all the source code but the base map does not show up in the infobox as it should. A correct example of this is on the page Bundelkhand Expressway where the expressway is outlined in red and shows up in the info box. I know that you have to get the wiki data tag and put that into the source code in order for it to work and I did do that. But it still seems to not be working and I was wondering if someone could guide me so that I can see what I am doing wrong in adding these maps. Any help would be appreciated. Thanks, - User:Yellow alligator 18:02, 29 July 2022 (UTC)[reply]

Bundelkhand Expressway gets its map data from its Wikidata item (wikidata:Q48730051). This data most likely comes from it's Google Knowledge Graph ID (/g/11f2wbm55j). This knowledge graph already has a map which is simply copied on Wikipedia. Now, Ahmedabad–Dholera Expressway's knowledge graph ID (/g/11j8kw9dpj) doesn't contain a map. There is no source from which we can extract a map. That's why a map isn't visible. If you can manually recreate the route online, Wikipedia:Creating route maps from OpenStreetMap data may guide you through the process to add a new map yourself. —CX Zoom[he/him] ^{(let's talk • {C•X})} 23:59, 30 July 2022 (UTC)[reply]

@Yellow alligator: ping. —CX Zoom[he/him] ^{(let's talk • {C•X})} 07:01, 31 July 2022 (UTC)[reply]

Thanks. I just noticed this A-D-Expressway is still under construction. I think we should wait till it gets completed. Infrastructure projects may never even get completed. Venkat TL (talk) 07:04, 31 July 2022 (UTC)[reply]

I do a fair amount of anthroponymy work, and have gotten to wondering where there might be gaps in our coverage of common given names. To that end, I'm curious as to whether it would be possible to generate a list of number of articles in Wikipedia by first whole word (e.g., how many articles start with "Albert" or "Gerry" or "Zane" as a word, followed by a space, followed by another word). I would want to exclude redirects, and I think it would be reasonable to cut it off (for a first run) at words that have more than 50 articles starting with that word.

If such a list already exists, please point me to it. Cheers! BD2412 T 18:23, 29 July 2022 (UTC)[reply]

If "exclude redirects" isn't that important you can download the list of all article titles here and then just do some datamining on it. — xaosflux ^Talk 18:36, 29 July 2022 (UTC)[reply]

Suppose you could "minus out" from the list of redirects file — xaosflux ^Talk 18:39, 29 July 2022 (UTC)[reply]

I don't particularly have the kung fu to do that kind of data mining. I'm just looking for the assist. BD2412 T 18:49, 29 July 2022 (UTC)[reply]

@BD2412: The following SQL query should do it:

SELECT COUNT(*) AS total, SUBSTRING_INDEX(page_title, "_", 1) AS first_word
FROM page
WHERE page_is_redirect = 0 AND page_namespace = 0
GROUP BY first_word
HAVING total >= 50;

I went ahead and ran it for you at quarry:query/66345. Unsurprisingly, the top words are "List" and "The", but then you start to get names such as John, William, James, Robert, David, George, THomas, Charles, etc. --Ahecht (TALK
PAGE) 19:08, 31 July 2022 (UTC)[reply]

@Ahecht: Fascinating. Thanks, this is perfect. BD2412 T 19:55, 31 July 2022 (UTC)[reply]

@BD2412: I developed the query a little further to limit it to people and to exclude names which already have (or redirect to) an article, here. Most results are still false positives. "List" has gone, but "The" still hangs in there due to The Weeknd, etc. and there are a few other non-names such as Sir. Names like Jesús redirect to a dab with a name article as one entry; eliminating such cases in SQL would be way too slow. (The query is already ridiculously complex because the SQL implementation fails to use an index on page_title when given a prefix, insisting on one single exact title.) Certes (talk) 00:44, 1 August 2022 (UTC)[reply]

Eliminating the numerical and organizational prefixes is a help, thanks. BD2412 T 00:46, 1 August 2022 (UTC)[reply]

Can someone explain to me why this article displays an italic title, and how to change it. I see no {{italic title}} in the article, and {{Infobox news event}} doesn't seem to carry automatic italics either. StAnselm (talk) 18:48, 29 July 2022 (UTC)[reply]

@StAnselm: just by brute force previewing, it was something in the "Music" section. I have split that out into a separate article on the album, which has resolved the problem. BD2412 T 18:55, 29 July 2022 (UTC)[reply]

Oh, of course - the album infobox. Thanks. StAnselm (talk) 19:04, 29 July 2022 (UTC)[reply]

Unwanted italics in the title are nearly always from an infobox somewhere in the page. {{Infobox album}} supports |italic_title=no. PrimeHunter (talk) 00:11, 30 July 2022 (UTC)[reply]

I want to generate a list of 'list articles' (List of United States Presidents, List of medieval composers etc.) by page views, but trying to do so on pageviews.wmcloud.org has (inevitably) been too large of a request to load. Does anyone know of an better way, or can do so for me? Looking for say, top 50 list articles. Aza24 (talk) 07:19, 30 July 2022 (UTC)[reply]

For example, doing mass page views on this category of 139,979+ articles does not work on my computer. Aza24 (talk) 18:44, 30 July 2022 (UTC)[reply]

Like a... list of lists? — Guarapiranga ☎ 01:28, 1 August 2022 (UTC)[reply]

Not really Guarapiranga, I'm trying to see what the most viewed lists are (order them by page views), to get ideas of what to work on. Aza24 (talk) 04:00, 1 August 2022 (UTC)[reply]

I see... Somewhat like that? — Guarapiranga ☎ 04:20, 1 August 2022 (UTC)[reply]

How about looking at what lists have been edited recently (and which haven't), as a proxy (presumably, lists popular with readers are also popular with editors)? — Guarapiranga ☎ 04:32, 1 August 2022 (UTC)[reply]

The top 73 "List of..." articles appear on User:HostBot/Top 1000 report (along with hundreds of non-list articles). Certes (talk) 09:07, 1 August 2022 (UTC)[reply]

I am sure that in the past when I deleted list cites a bot came round and fixed the cites. But that has not happened yet at European emission standards. I cannot remember the name of the bot Chidgk1 (talk) 11:43, 30 July 2022 (UTC)[reply]

There's an easy way to fix this: revert your edit that removed references, and edit the article instead of doing fly-by deletions that may contravene policy. If you actually edit an article you will be able to tell which references are necessary. It is a lot of work, of the most uninspiring sort, and you will not be rewarded. So that's it. Another option (a fairly common one) is to come at VP and complain about this thing or another. 68.132.154.35 (talk) 15:52, 30 July 2022 (UTC)[reply]

(edit conflict) If you're thinking of AnomieBOT (which you probably are), it doesn't handle refs defined by screwy templates like {{r}}. Anomie⚔ 15:54, 30 July 2022 (UTC)[reply]

Why is {{r}} "screwy"? 68.132.154.35 (talk) 15:56, 30 July 2022 (UTC)[reply]

@Chidgk1: this is a really bad approach to editing live pages. You are knowingly removing refs that you know are likely in-use. That's a detriment to readers and bumps up against WP:V policy up until the time they get re-added. It might be transient (but now you know it might not be), but even if so, it's better to have unused refs (no obvious harm). DMacks (talk) 16:08, 30 July 2022 (UTC)[reply]

Thanks for explaining - for this particular article manually editing to remove unused refs will likely not be too time consuming for someone (probably not me as they are not doing much harm). For the previous 2 - where the bot worked very well thanks - there were far too many used and unused old-style refs to edit manually. Chidgk1 (talk) 06:13, 31 July 2022 (UTC)[reply]

"Flagging unused list-defined references" seems like a well-defined feature-request. That help-page notes "All references in reference list must be referenced in the content, otherwise an error message will be shown." and Help:Cite errors/Cite error references missing group says this error message should be easily visible. At least for mainspace and default ref-group, it explicitly says which ref-name is unused. For example, the version prior to your edit at European emission standards said (links omitted):

So if there are lot of them, you have to spend a moment finding each in the list, but it's mindless and easy. And it also doesn't seem to work in all namespaces (does in main, not in user), so that's an annoyance for out-of-mainspace article development and discussion. DMacks (talk) 21:52, 31 July 2022 (UTC)[reply]

@Chidgk1 this is clearly a "bad edit", and I've reverted it. You should never assume that any future edit will ever be made. — xaosflux ^Talk 16:09, 30 July 2022 (UTC)[reply]

I very strongly dislike seeing this on redlinked talk pages. Never liked it to begin with and am fed up with it now. I would rather it just take me to a blank editing window like old times. Sometimes I'm making redirects or disambig pages that need talk pages in a hurry (some redirect pages meet the criteria for having talk pages, e.g. song title redirects to album pages which is what I work on sometimes). It would be a lot quicker and less annoying to be able to cut straight to the chase and skip this banner, like before — in fact, like earlier just this year. Is there any way to disable this, or do we really need it for any group of users? Zeke, the Mad Horrorist ^{(Speak quickly)} _{(Follow my trail)} 07:13, 31 July 2022 (UTC)[reply]

You may be able to change this behaviour in Special:Preferences#mw-prefsection-editing, section Discussion pages, item When I visit a discussion page that hasn't been created yet:. Certes (talk) 10:46, 31 July 2022 (UTC)[reply]

That certainly seems to have worked. The only place I can see it may not have taken effect is on talk pages for user subpages (e.g. any uncreated archives for my talk page will result in the same type of message, and in their case it seems unskippable), but I don't care since I obviously won't be working in user subpages with any frequency at all. For those interested, this is what you do — go to Preferences, Editing, and scroll down until you see:

When I visit a discussion page that hasn't been created yet:

• Offer to add new topic
• Open the wikitext editor

"Offer to add new topic" is the default. Switch to "Open the wikitext editor".

Many thanks for your help! Zeke, the Mad Horrorist ^{(Speak quickly)} _{(Follow my trail)} 17:02, 31 July 2022 (UTC)[reply]

How do I pass parameters to interface messages in an API parse request? {{MediaWiki:Protectedpagetext|editprotected|add rubbish to}} doesn't work, that outputs "This page is currently semi-protected so that only established, registered users can $2 it." (when it should say fully protected and "$2" should be "add rubbish to") — Alexis Jazz (talk or ping me) 18:46, 31 July 2022 (UTC)[reply]

@Alexis Jazz: The wikitext method is to use {{int:}} at mw:Help:Magic words#Localization: {{int:Protectedpagetext|editprotected|add rubbish to}}. I guess that works for your purpose. If you are logged in then it uses the message in your language setting at Special:Preferences. We usually only customize en messages. PrimeHunter (talk) 18:55, 31 July 2022 (UTC)[reply]

PrimeHunter, that works indeed. Makes sense, I hadn't realized int: would affect this. Thanks! — Alexis Jazz (talk or ping me) 19:23, 31 July 2022 (UTC)[reply]

Is there an efficient way to search through the deletion log by reason, e.g., XfD closures/expired PROD/specific CSD criteria? If there isn't a script or tool available for this, would it be technically possible to implement in a similar manner to searching/sorting the log by user? User:Pppery and I were having a short discussion about this at Wikipedia talk:Criteria for speedy deletion#Adding to Non-criteria list section, as such a feature could be very helpful to those who may be interested in reviewing deletions. ^Complex/_Rational 01:46, 1 August 2022 (UTC)[reply]

Hi, On my talkpage I'm now greeted with a rather patronizing message: "Welcome to your talk page People on Wikipedia can use this talk page to post a public message for you and you will be notified when they do." and I'm now greeted with similar messages on other peoples tps

Is there any way this can be disabled as I think by now I know what a talkpage is and the purpose of it!. Thanks, –Davey2010^Talk 12:56, 1 August 2022 (UTC)[reply]

@Davey2010: Special:Preferences#mw-prefsection-editing, uncheck "Enable quick topic adding". --Ahecht (TALK
PAGE) 13:05, 1 August 2022 (UTC)[reply]

@Ahecht that doesn't fix the problem that "others" are seeing this where it doesn't seem to make sense. For example, open Dave2010's user talk in a private browser. — xaosflux ^Talk 13:10, 1 August 2022 (UTC)[reply]

I suppose if you wanted to prevent "new topic" from running on specific pages (for others) another feature request could be added (mirror that of phab:T249293 that is looking for a way to disable reply-tool on certain pages). — xaosflux ^Talk 13:16, 1 August 2022 (UTC)[reply]

Hmmm, seems like you are getting MediaWiki:discussiontools-emptystate-title-user. Are you only seeing this on talk pages that have no sections? — xaosflux ^Talk 13:09, 1 August 2022 (UTC)[reply]

Yes, I see them too when there are no sections, and I see it on Davey2010's talk page. I see this at User talk:Sandbox too. Special:Permalink/1093717911 is the latest revision as of now, and shows this message. Special:Permalink/1092296292 is an old version with the same exact source code, but does not show the message. —CX Zoom[he/him] ^{(let's talk • {C•X})} 13:16, 1 August 2022 (UTC)[reply]

• I created a template, {{No discussion tools empty state}} that can suppress this for others on a per-page basis, such as if you want to build a page workflow that never uses that. See example at User talk:Xaosflux/Sanbox 12. As far as that message goes, if you don't want to see it on other-people's pages, but do want to use discussion tools - perhaps you can suppress it in your usercss. — xaosflux ^Talk 13:50, 1 August 2022 (UTC)[reply]
• @Davey2010: try putting the code below in Special:MyPage/common.css

.ext-discussiontools-emptystate {
	display:none;
}

That Should hide that dialog "for just you" on all pages. — xaosflux ^Talk 13:56, 1 August 2022 (UTC)[reply]

Hi Xaosflux, Ahecht and CX Zoom - Many thanks for your help and special thanks to Xaosflux for the workaround greatly appreciate everyones help here, I do apologise for not mentioning earlier that I'm using the discussion tools feature I had completely forgot I was even using it (or that it was a beta feature still), Anyway thanks Xaosflux for your help and workaround greatly appreciated,

I've added the No discussion tools empty state template to my talkpage however it now says on my talkpage toc "Invisible section to prevent the discussiontools-emptystate-title tool from running on select pages with no sections" - Not sure if that's meant to be included in my TOC but I'd rather have that then the patronizing message! :), Added the other codding and can confirm it removes the message for myself on others talkpages so yeah I'm happy now and once again thanks Xaosflux and everyone else shelp today I greatly appreciate it, Many thanks, Warm Regards, –Davey2010^Talk 17:21, 1 August 2022 (UTC)[reply]

@Davey2010 Hmm, I made it shorter. It is not really the best fix for this, that would require a magic word, I'll see about creating a phab task. — xaosflux ^Talk 17:34, 1 August 2022 (UTC)[reply]

It will still work on a page that has a special sort of workflow, as they won't normally show a TOC. — xaosflux ^Talk 17:35, 1 August 2022 (UTC)[reply]

One workaround would be to use a level 6 invisible heading instead of level 2 like {{No discussion tools empty state}} currently does. And then also using {{TOC limit}} at level 5 or lower header. —CX Zoom[he/him] ^{(let's talk • {C•X})} 17:34, 1 August 2022 (UTC)[reply]

What causes multiple red messages "Lua error in Module:Citation/CS1 at line 1392" here? I suspect this has something to do with introduced Template:Harvard citation no brackets, but can't find the error in wikimarkup. Thanks. Brandmeister^talk 13:08, 1 August 2022 (UTC)[reply]

The citation templates are broken right now. There is nothing you can do about it. AManWithNoPlan (talk) 13:10, 1 August 2022 (UTC)[reply]

Ok, will wait, as per another complaint below. Any word about time of fixing? Brandmeister^talk 13:13, 1 August 2022 (UTC)[reply]

Issue has been resolved now Kpddg ^(talk) 13:18, 1 August 2022 (UTC)[reply]

Looks good now, whew! SandyGeorgia (Talk) 13:22, 1 August 2022 (UTC)[reply]

Help needed fixing Lua errors

The Clarence Campbell article has multiple Lua errors. Does anyone know where to ask for help, or could be a hero and fix the problems? Flibirigit (talk) 13:08, 1 August 2022 (UTC)[reply]

The citation templates are broken right now. There is nothing you can do about it. AManWithNoPlan (talk) 13:09, 1 August 2022 (UTC)[reply]

Where is the place for updates? Help talk:Citation Style 1 is not the place. Bluerasberry (talk) 13:11, 1 August 2022 (UTC)[reply]

Is it related to this edit ('bump pmc')? I lack the WP:Boldness to mess with modules :) Dsp13 (talk) 13:11, 1 August 2022 (UTC)[reply]

How on earth did this get rolled out without testing it fully first?! Citations broken all over the encyclopedia! MeegsC (talk) 13:12, 1 August 2022 (UTC)[reply]

Seems to be everywhere,. I get it on all my citation efforts today. Also, a thread at Wikipedia:Administrators' noticeboard/Incidents#CS1 going haywire. — Maile (talk) 13:13, 1 August 2022 (UTC)[reply]

@Maile66: You can fix the problem, as you're an admin, by undoing the edit Dsp13 linked to above. * Pppery * _{it has begun...} 13:14, 1 August 2022 (UTC)[reply]

User who did it inactive 20 minutes since edit User_talk:Trappist_the_monk#Lua_errors_everywhere Only admin can undo Bluerasberry (talk) 13:15, 1 August 2022 (UTC)[reply]

Looks like Trappist the monk has fixed it now. If you're still seeing errors, you may need to do a WP:PURGE on articles with the errors. --Ahecht (TALK
PAGE) 13:18, 1 August 2022 (UTC)[reply]

I don't think it's fixed. It's still happening. — Maile (talk) 13:24, 1 August 2022 (UTC)[reply]

OK, it's fine now. — Maile (talk) 13:28, 1 August 2022 (UTC)[reply]

• Hello. Same error is happening on the article page references Wild Rift. ✍A.WagnerC (talk) 13:21, 1 August 2022 (UTC)[reply]

Clive Stephen - refs replaced with Lua error

I also was going fine with Clive Stephen but now I seem to have lost all references - most are replaced by "Lua error in Module:Citation/CS1 at line 1392: bad argument #1 to 'pairs' (table expected, got nil)." I've tried reverting to earlier versions, but without result . Thank you for any help. Jamesmcardle^(talk) 13:16, 1 August 2022 (UTC)[reply]

See the above thread. * Pppery * _{it has begun...} 13:19, 1 August 2022 (UTC)[reply]

"Lua error in module citation"

I have noticed that the references I've added suddenly have the Lua error in module citation... I do not know anything about what this means, and I do not know if this is the correct venue to report it, but I'd be glad if I knew how to prevent such events. At this version of today the sources appear alright, in this one a few hours later and after only introducing a wikilink, Kurdish Theatre in Turkey has the Lua error. Paradise Chronicle (talk) 13:23, 1 August 2022 (UTC)[reply]

@Paradise Chronicle: The issue has been resolved. You may need to do a WP:PURGE on any pages still showing the error. --Ahecht (TALK
PAGE) 13:25, 1 August 2022 (UTC)[reply]

Oh, it appears I am not the first to report the Lua errors... Paradise Chronicle (talk) 13:43, 1 August 2022 (UTC)[reply]

Thank you all Paradise Chronicle (talk) 13:47, 1 August 2022 (UTC)[reply]