A barnstar for you!

The Admin's Barnstar
For the good work of the administrator SimonPL2000 (talk) 14:14, 5 January 2021 (UTC)[reply]

Linear-gradient and Box-shadow

Hi, it looks like we could use your help in fixing these and these. Thanks! Plastikspork ―Œ(talk) 22:38, 5 January 2021 (UTC)[reply]

@Plastikspork: ... wut. why. Why do Wikipedians do this. Sigh. Yes, one second. --Izno (talk) 22:44, 5 January 2021 (UTC)[reply]
@Plastikspork: Since you're working on it, I've sorted the offending pages. The remaining in Sceptre's user space are job queue fodder, so please feel free to proceed. --Izno (talk) 23:06, 5 January 2021 (UTC)[reply]


When I saw that template columns was suggested for deletion, I didn't care and look (no time), thinking it would be replaced by something rendering the same output. Now - Gerechtigkeitsspirale - I see that it puts the columns too close for my aesthetics, and I don't like the grey background of the table. Is there a way to have it look as before without the template? --

@Gerda Arendt: That was my personal taste :). Marking it up as a wikitable is much cleaner for the headings piece of it. You might consider Template:Column as the replacement if you personally prefer. --Izno (talk) 08:35, 6 January 2021 (UTC)[reply]
I'll take a look. In this case, the headings are only explanations of what kind of translation, and deserve no emphasis. Thank you for explaining! - Wishes for 2021 here. --Gerda Arendt (talk) 08:39, 6 January 2021 (UTC)[reply]
@Gerda Arendt: The emphasis is something I can't control and I generally advise against getting into that side of things. I've tweaked this for the padding and color (just by removing the class for one and adding a little something else for the other). Does that seem reasonable? --Izno (talk) 09:04, 6 January 2021 (UTC)[reply]
That looks great, thank you! - The article was my response to arbitration, DYK? - still grinning that I got it to the Main page ;) --Gerda Arendt (talk) 09:06, 6 January 2021 (UTC)[reply]

A kitten for you!

This is Millionwords from Discord! :D

Tatupiplu'talk 04:58, 14 January 2021 (UTC)[reply]

Examples for video card memory size and hard drive storage size

Hi! I reverted your recent edit that reverted your reversion of my edits at Wikipedia:Manual of Style/Dates and numbers#Quantities of bytes and bits. I left extensive comments on what and why I did. In a field where equipment storage size increases by a geometric rate of between 1.5 and 2 per year, the "long-standing" storage sizes used in the original text have not been common in the last ten years, and can only be found on eBay as used. I think using obsolete equipment characteristics in examples is not a good look. I did not change the form of the examples, only the quantities. The takeaway for the reader is the same, just without the jarring time-warp.

My updates will need to be revisited within three or four years. I really am familiar with the field and its history as a programmer and a user—I do not consider myself an expert. However, I do think my edits are correct and useful. If you disagree, I'd love to discuss—especially on the question of how updated example information in the MoS is a good thing for quickly developing technology. It not in the same bucket as usage for pled vs. pleaded. — Neonorange (Phil) 10:17, 21 January 2021 (UTC)[reply]

I have opened a thread at [[Talk:at Wikipedia:Manual of Style/Dates and numbers' — Neonorange (Phil) 10:32, 21 January 2021 (UTC)[reply]

Page view stats

https://analytics.wikimedia.org/dashboards/vital-signs/#projects=enwiki/metrics=Pageviews displays a chart for me. Do you have Javascript turned off (for that site)? WhatamIdoing (talk) 01:04, 22 January 2021 (UTC)[reply]

@WhatamIdoing: Nope (and I chastise people who turn it off these days on WMF sites who have the choice ;). It looks like uBlock Origin is catching something on review (I really should make that one of the things I care about). It's triggering on the piwik in https://piwik.wikimedia.org/piwik.js and pageviews in https://wikimedia.org/api/rest_v1/metrics/pageviews/aggregate/en.wikipedia.org/all-access/user/daily/2015010100/2021012100. I'll tell it to calm down, but you might want to leave a note on the use notes there on that template. --Izno (talk) 01:10, 22 January 2021 (UTC)[reply]
Or maybe see if the thing can be fixed so it doesn't look like an advertisement or whatever uBlock Origin cares about. User:BDavis (WMF), is this your team? WhatamIdoing (talk) 01:56, 22 January 2021 (UTC)[reply]
I think both of those URLs are reasonable in this context, so I'm not too bothered just to turn it off. --Izno (talk) 02:02, 22 January 2021 (UTC)[reply]
@WhatamIdoing:, both services are projects of the Foundation's Analytics team. Blocking piwik is a reasonable thing for a user with ad blocker technology enabled. Piwik is an Open Source browser metrics collection system. It is used to collect privacy respecting visitor analytics for several non-wiki websites manged by the Wikimedia Foundation. Blocking it should not cause any of the sites using it to malfunction. Blocking only prevents those page views from being counted in that visitor analytics system. The problem of "pageviews" appearing anywhere in a URL triggering some ad blockers is also a known issue that has had some mitigation attempts in the past. There may be some new ad blocker lists that could also be contacted for exceptions if we can figure out which list and who curates it. --BDavis (WMF) (talk) 04:24, 22 January 2021 (UTC)[reply]

"invert mvar-link placement for upcoming tstyles"

Your recent edits suggest that it will no longer be allowed to have links that surround math templates, and that all links to pieces of math formulas or whole formulas should be inside the template. Am I misinterpreting? If that is true, it is going to be a big problem for situations in which we want to link plain text that has math formulas embedded within it, as happens frequently for titles of mathematics references. —David Eppstein (talk) 19:24, 29 January 2021 (UTC)[reply]

@David Eppstein: Uh, lots to unpack.
  1. The issue is something of a bug in the parser (phab:T200704), specifically with the first invocation of each specific TemplateStyles'd template. The workaround for the bug is just to ensure the first invocation of the specific template is not inside a link.
  2. This first cut is to sort out the easy ones where the invocation is just link-template-endlink.
  3. There are actually rather few page-level instances; 194 for mvar (and a few false positives with image syntax) and 178 for math.
    • For comparison, total transclusion numbers: mvar (3.8k) and math (5k)
  4. ((sfrac)) and ((frac)) had fairly few issues show up on the talk page when implemented there. I think this implies the "workaround" is mostly the natural state of things on wiki.
    • Note: I need to go and look to see if there are any in mainspace at issue with that pair of templates.
  5. Given that workaround exists, I think most pages will be no-problem. We will need to look at some long tail of Hard Problems.
    • I will look at the remainder of mvar/math when I am done with the easy math invocations.
  6. I will look to document this on the templates of interest.
--Izno (talk) 19:52, 29 January 2021 (UTC)[reply]
And apparently it's not an issue for external links. See an example of sfrac: 3+2/1. --Izno (talk) 19:55, 29 January 2021 (UTC)[reply]
You realize ((frac)) is forbidden for actual mathematics formulas? So using it as exemplary evidence that everything works well for mathematics formulas is irrelevant at best. —David Eppstein (talk) 20:12, 29 January 2021 (UTC)[reply]
@David Eppstein: You realize that that wasn't what the example was supposed to show, and moreover that it was ((sfrac)) I pointed to, which is not banned? A little less passive-aggression, please. --Izno (talk) 20:17, 29 January 2021 (UTC)[reply]
You listed frac in point 3 of your original reply. —David Eppstein (talk) 20:28, 29 January 2021 (UTC)[reply]
@David Eppstein: Point 4. I also listed sfrac. First. Just to make the subtle indication that you probably care more about the one rather than other. The secondary point is that it was implemented for both, and yet I got all of 2 comments on the talk page for 24.4 thousand combined uses. --Izno (talk) 20:34, 29 January 2021 (UTC)[reply]
@David Eppstein: Since it is related, I will be updating ((math)) such that it will be using TemplateStyles. When I do so, the CS1/2 module will begin to emit errors. This is preceding a change to remove the relevant styles from MediaWiki:Common.css.
Your choice on how you want to replace the template. I'm not going to play the revert game. --Izno (talk) 07:14, 19 February 2021 (UTC)[reply]
Have you even discussed this with the people at MOS:MATH and WT:WPM or are you just planning on breaking math formatting and hoping nobody who cares notices? This "nobody cares about math formatting so let's do what's expedient instead of putting any effort into making it actually work" attitude on the part of developers who don't edit mathematics themselves is a big part of why Wikipedia math formatting has been so bad for so long. But you're making it even worse. Some hints, since you appear to need them: (1) <math> looks really ugly in titles that are linked (because the math isn't shown in the same color as the rest of the title, because the Wikimedia developers have repeatedly blocked efforts to use mathjax which would actually work and instead insist on generating images for formulas and pretending that doing so will help encourage mathml to rise from its grave) so it is essential that alternatives like ((math)) continue to work in that context; (2) ((math)) and <math> don't look the same so they should not be mixed in article text; (3) spacing in mathematics formulas is important for their proper formatting and should be paid attention to; (4) plain-html formatting is ugly, makes it difficult or impossible to distinguish | from 1 from l from I, and should not be used.
In the specific case of Julie Bergner, it would have been possible to work around the issue by using <math> everywhere, because there are currently no linked titles to worry about. You did not do that; instead both of your attempts at changing the article made the formatting inconsistent and ugly. But the workaround for her is not a fix to the more general problem, that you appear to be hell-bent on eliminating the only current way to get some formulas in linked titles to look acceptable. (There are titles with formulas too complicated for ((math)), that are currently impossible to format with links and make look ok, but your change is significantly expanding the set of impossible-to-format-well titles.) —David Eppstein (talk) 07:24, 19 February 2021 (UTC)[reply]
David Eppstein, yes, my plan was to start that discussion Soon, after I had evaluated and set up the required workaround templates for the primary inline issue (which I explicitly separate from the issue of template use in CS1/2 templates), and evaluated which pages would need a workaround. I got around to that last night. Your aggression in previous interactions is in fact part of the reason I did not start that discussion today. Perhaps a little less swearing at my apparent fumbling on a specific page would better indicate a desire to sort things out amicably.... --Izno (talk) 07:43, 19 February 2021 (UTC)[reply]
Perhaps figuring out what all the relevant issues are, having an informed discussion with the affected parties, and working together with those parties to find a solution that actually works, before settling on a single solution that doesn't work, beavering around breaking stuff to make it fit, and declaring unilaterally I will be updating might have led to greater amity? —David Eppstein (talk) 07:51, 19 Februmoary 2021 (UTC)
As I said, I had planned to discuss it. Not least because I don't know how to write about mathematics, and making what would be quantity 100 changes to introduce a new template would have gotten someone looking at me funny. As for "what doesn't work", I deliberately have not passed judgement on what the Group of Interest will think about decisions X, Y, and Z. You don't get to decide that something doesn't work any more than I get to decide what does. There is a lot at play and that discussion will indeed acknowledge the pentagonal box we need to fit into. --Izno (talk) 08:01, 19 February 2021 (UTC)[reply]
The obvious solution to "citation templates can't handle titles that require formatting beyond plain text" is to give up on citation templates and just format our citations manually. Obviously that will continue to work unless you are breaking the math templates even more than I understand you to be breaking them. So my first reaction is that new limitations like this on what the citation templates can handle, compared to what can be formatted manually, is that they indicate deficiencies in the citation template coding. But I also have a lot of pent-up frustration over Wikipedia's continued failure to provide properly-working mathematics formatting, over a decade after the rest of the world started using MathJax (and later KaTeX) and stopped having similar problems. If <math> worked as smoothly as it should, there would be no issue; we'd just use it and the ((math)) templates could fade into a well-deserved oblivion. —David Eppstein (talk) 08:26, 19 February 2021 (UTC)[reply]

Here's a concrete and real example for you to work on:

How do you propose to modify the templates so that (1) whatever actual rendering bug you are trying to avoid doesn't happen for this citation, (2) it can still be described using citation templates instead of manual formatting, (3) the title is linked to the author's web copy of the paper as above, (4) the n in the title is rendered in a proper serif italic math-variable font and not upright or sans-serif, and (5) the n in the title is displayed in the same color as the rest of the title (including both before and after the link has been clicked, which many browsers will indicate with different colors) and linked along with the rest of the title? (We can quibble about whether Series A should be coded as part of the journal name or using a separate |series= parameter, but that's a separate issue.) If you can find a way to do all that with <math>, so much the better, but until that is possible then the math templates are the only workaround I know for making this kind of citation work, so you can imagine my frustration when you tell me that the only workaround for Wikipedia's bad math handling in this context is being taken away. —David Eppstein (talk) 00:30, 22 February 2021 (UTC)[reply]

Showing 1 = 0

I had to undo one of these edits, [1], as it managed to produce the statement 1=∇ • B = 0, which I believe is wrong.

The problem seems to be when the ((math)) tag is like [[Gauss's law for magnetism|((math|1=∇ • '''B''' = 0))]] with a numbered parameter used so a equation with an equals sign can be rendered. The replacement ((math|[[Gauss's law for magnetism|1=∇ • '''B''' = 0]])). causes an extra 1= to appear.

I'm worried that your change might have caused some other similar errors, but there is rather a lot of articles to check. --Salix alba (talk): 06:31, 24 March 2021 (UTC)[reply]

I checked and all the other edits look OK.--Salix alba (talk): 18:29, 25 March 2021 (UTC)[reply]
Good. Sorry, I was going to do that after getting through the watchlist reading etc. Was pretty sure it was a oneoff. Izno (talk) 18:36, 25 March 2021 (UTC)[reply]


Hi Izno -- So just wondering why you moved the citation in front of the quote on the Volkssturm page? In Academia, it is normal for the reverse; namely, we place citations at the end of a quote. Is there a clear Wikipedia policy on this, as that would otherwise contradict academic convention? My understanding is that if a quote is a large extant document, you can place it in front, but otherwise...Your insight would be appreciated. --Obenritter (talk) 16:09, 2 February 2021 (UTC)[reply]

@Obenritter: It follows from the principle of WP:LQ; to wit, that some innocent (not me of course) might mistake the citation as belonging to the thing being quoted, rather than the person who said the thing being quoted. FWIW. --Izno (talk) 16:28, 2 February 2021 (UTC)[reply]
Gotcha. Sad reality but probably true.--Obenritter (talk) 18:07, 2 February 2021 (UTC)[reply]

Clarifying stance at WT:VG#OpenCritic Percentage Recommended Score

Hi Izno, I've requested the above discussion for closure and I wanted to make sure your position was stated clearly. As your comment does not have a bolded support or oppose statement, I didn't want it to get lost in the close. Best, Axem Titanium (talk) 08:26, 7 February 2021 (UTC)[reply]

It should be fine given I wrote a several paragraph indented extension that should be hard to miss accordingly. --Izno (talk) 07:21, 8 February 2021 (UTC)[reply]

Screenreaders and :* markup

"it adds to list complexity" but "not entirely sure about why this would mean anything to sr's" – It affects screen readers because it adds complexity to the list markup; it triggers the screen reader to announce a new kind of list, for no practical purpose. But I guess that might already be implicit enough in "adds to list complexity"; the page already provides examples somewhere of what screenreaders do with all this list markup.

"definitely disagree that this is an issue of emphasis" – Are you sure you caught the specifics of the example? It was only about : lists into which someone interjects something like :* out of the blue, so that only their comment has a bullet. So, yes, it's about emphasis. However, that's a point better saved for the talk page guideline maybe (that one's not an accessibility matter, after all), and it's not one I feel strongly about codifying (though I will generally revert people doing it (well, not really a revert, but I just change it to :: to match the rest of the thread) when I run across it and am already doing LISTGAPS repair on the thread).  — SMcCandlish ¢ 😼  03:50, 8 February 2021 (UTC)[reply]

SMcCandlish, you might consider moving this and the reply to the same thread as Rexx's. I detest discussion about specific edits on my talk page if it is not a trivial response or does not pertain to an administrative action. ;)
it triggers the screen reader to announce a new kind of list SRs are announcing a new list regardless; whether it's a DL or a UL or an OL is kind of immaterial at that point. But I agree, it's a corollary at most to "more complex", so you can maybe reframe it as such if you want.
Are you sure you caught the specifics of the example? Yes, I did. I have never seen this employed as emphasis particularly. I usually see it because that's the editor's preferred way to respond (e.g. that specific character is just their preferred MO). (I suppose I could assume otherwise, so maybe you have identified some editor or another of concern, but that's not a guideline thing.) The more annoying habit I see is not threading correctly almost always for emphasis ('comment, Later Response indented twice, response' form), which I believe is already covered in WP:TPG. --Izno (talk) 03:58, 8 February 2021 (UTC)[reply]
I was thinking of it as a trivial response. I.e., I don't mind the revert, since the one point was potentially redundant and the other was arguably off topic for the ACCESS page. Just wanted to clarify what the thinking was, in light of your edit summary's comments.

I don't know if that other thing you mention is addressed there. I only use this technique when interjecting a trivial comment, most often a joke. Yes, I have occasionally seen people try to use it for thread hijacking. I used to use it occasionally to try to thwart thread hijacking (e.g. EditorA and I were having a conversation, and before I could reply to the latest round, EditorB butted in and ran it off the rails, so I would post above them and indent a level to try to get back to the original discussion with editor A). This turned out to not actually be effective, so I abandoned it a long time ago. There were also other sorts of talk refactoring people used to do back in the day that no one bothers with any longer, because norms have changed and solidified.

One thing you might be thinking of is that several years ago there was an RfC about "interleaving" refactors, where someone breaks an original post apart to reply to pieces of it, and consensus was against that idea (not that people were doing it frequently; I think it was really two editors who kept doing it). I recall arguing that this should be permissible in a case where the post really needed to be split into multiple threads for effective discussion, and as long as the original poster's sig and timestamp were replicated on both post fragments. But no one heard that. The main issue had been someone habitually splitting up everything they were replying to into various chunks to pick apart, and people didn't like it, and didn't want to hear anything about potential exceptions. In the rare case I feel this is really necessary, I'll do it anyway, per WP:REFACTOR + WP:IAR. The last time I remember trying this (other than at my own talk page) was with a new editor who clearly had "an issue" and was very poor at getting their thoughts in order but who was writing a proposal to make major changes to something (some of which were actually good ideas, but not all of them about the same section); their first take at it was producing such a muddle no one would read or understand it. LOL.

As for :* just being someone's habit, their "MO", well, that's also part of what the point was. If someone is habitually, robotically ensuring all their posts start will shiny bullet points even in :-threaded discussions, then they are in fact trying to make their comments seem more important than everyone else's and they need to stop it. I.e., being a jerk habitually is not better than being one occasionally, but is actually worse.  :-) I know I'm not alone in thinking so, since I refactor threads to include cleanup of that as well as list-gaps fixes, very frequently, yet no one ever reverts me on it, and I get occasional thank-pings for doing such cleanup. I don't think the community would make a rule about it, but then again I didn't think they'd make one against interleaving either. Still, it's not something worth doing a proposal about.  — SMcCandlish ¢ 😼  04:49, 8 February 2021 (UTC)[reply]

SMcCandlish, it is 'covered' at Thread your post: with a pointer to what it means to thread a post, but no explicit coverage the one practice should not occur, indeed.
I was sad to see the interleaving RFC go the way it did. I find the practice useful if two editors can manage to make it work (regardless of attachment of signatures), but perhaps that is an IAR situation at that point anyway. But no, that was not what I was thinking of.
Suggesting that the practice of cleaning such posts (either to all bullets or all indents usually) means that the editors making such posts are doing so to be emphatic affirms the consequent, if I read your intent correctly. I do such cleaning routinely as well and am rarely if ever reverted, which is why the conclusion I draw is that the users who do this thing are doing it because they don't care what the little symbol at the beginning of their comment looks like and prefer to use just one. (I might suggest that such thanks is usually because you cared about the accessibility and not because they agree that the aberrant person was being aberrant rather than unwilling or unable to learn rather than the third 'look at me!' option.)
It's all mostly immaterial Soon anyway. We'll have shiny Discussion Tools Soon and we won't need to care about what's under the hood unless we don't know how to preview and need to edit our comment 5 times (like I apparently don't and you mostly don't ;). --Izno (talk) 05:19, 8 February 2021 (UTC)[reply]
I'll be impressed with that stuff, if it actually works properly. They've tried to re-do the talk system so many times before .... I have a concern that they're not going to do jack to fix the underlying invalid markup problem. I've been saying for years and years that they need to have the parser (hopeful everywhere but at very least on on any talk namespace page, or any page like a noticeboard told to be behave as one) decide that if a line starts with : and is not immediately preceded by one that starts with : or ; then it needs to result in a CSS-indented div (and if it's a ; line not immediately followed by a : line or another ; line then it needs to be converted into a boldfaced div). Neither should result in an invalid dl element that does not contain at least one each of dt and dd. Anyway, if it does get totally changed under the hood (maybe to use the HTML 5 article element, which a lot of webboards use for threaded discussion, apparently), I hope we can still dig around in it. People will always need to fix typos, update links, etc. I'll concede your points on the other stuff, other than make clear I don't mean to imply the *-habit is bad faith; rather, it's like a habit of talking too loud to get attention. Being annoying doesn't require that one have a nefarious explicit motive to be annoying. Heh.  — SMcCandlish ¢ 😼  07:22, 8 February 2021 (UTC)[reply]
SMcCandlish, a handful of wikis are now "opt out" of the new Discussion Tool, most other wikis are "opt in", and it's basically just us not using it in some way (besides those volunteers who imported the script to their Javascript). It does work properly already! (It's also not Flow with all its mostly-developer-personality fuckups.) Yes, you can still screw around under the hood if you need/want.
New syntax task is phab:T230683 (where I assume the output will not be dl/dt/dd and friends; hopefully a <div class="indented-thing"> or something, I don't know :). The contributor (you, me, etc.) RFC whenever it gets published is phab:T246960, though I don't know where. You'll note a general obstinancy from the couple of parser folks about that >>> <<< is a terrible syntax for contributors to make multi-line comments, though I never got around to explaining why (was having a hard time in life). (WAID was terribly unhelpful commenting right after. Sorry WAID if you watch this page!) --Izno (talk) 07:34, 8 February 2021 (UTC)[reply]
Thankee for the deets and pointers. I'll try looking into this more. I haven't been very engaged with the dev side in a while. I have been meaning to file a complaint with the Ministry of Time and Attention, but I keep forgetting and ever seem to get around to it. PS: As for <<< \r >>>, it's shorter and easier to type than <!-- \r --><p>...</p>, though just plain ((pb)) works for a lot of cases. But various syntax highlighters are certainly not going to like <<< \r >>>.  — SMcCandlish ¢ 😼  22:08, 8 February 2021 (UTC)[reply]
Yes, it is easier to type, but I do not anticipate people remembering to type the end characters. --Izno (talk) 23:54, 8 February 2021 (UTC)[reply]

Arcade Archives

Dear Izno, I would like to notify you about the user Wtfd's "successor" and its continued disruptive editing by adding unsourced nonsense wishlists on the Arcade Archives page. Two warnings out of three have already been given. Are you able to block this anonomyous editor next time, aren't you?



Any help would be greatly appreciated. With kind regards from Ratengo (talk) 05:59, 10 February 2021 (UTC)[reply]

Ratengo, blocked and warned. --Izno (talk) 12:48, 10 February 2021 (UTC)[reply]

Template:Request edit/request

Hello, you recently added the editrequest class to ((Request edit/request)), is there any need for it to be kept this way or will it be alright if I remove this class? Thanks, Terasail[✉] 10:17, 10 February 2021 (UTC)[reply]

I don't see a reason it should be removed. --Izno (talk) 12:43, 10 February 2021 (UTC)[reply]
It was more the fact that it breaks my userscript, and if the class isn't needed then it would be easier to just remove it rather than fixing the script. Terasail[✉] 13:41, 10 February 2021 (UTC)[reply]
Terasail, my objective is that EPH work with COI edit requests. That's a necessary class for that case. --Izno (talk) 23:41, 10 February 2021 (UTC)[reply]

Follow up

I took your suggestion from Module:Arguments and it worked, but it effectively hardcoded what I'm trying to do and that's not what I'm needing. I understand parserfunctions better than I do Lua, so I will explain how I would do it that way.

(( Infobox module | style = (( Size module | style = (({style))} )) ))

Module:Infobox road/route is the infobox module I'm trying to call Module:Road data/size from. Forgive me if the code in either module is messy; I'm just happy they work.

I'd like to use this in ((Infobox road)) (route marker files are 70px here) and ((Infobox road small)) (40px here), so it doesn't make any sense to me to create two identical modules save two words. Style is the only argument that the size module takes and it can take four values: 'infobox', 'small', 'list', or leave it blank. So by passing style=infobox through the infobox module to the size module, I can get 70px images.

Does that make sense? I'm on #wikipedia-en-roads connect all the time if you think that would be better. Thanks anyway. –Fredddie 06:12, 15 February 2021 (UTC)[reply]

@Fredddie: That's because you hardcoded the style ;). You also seem to have gotten confused about the args you are receiving (args) into route/sandbox and the args you want to send to road data/size, which you probably want to be a totally separate table that you may need to construct from the args that route/sandbox received. I think this is one way to fix it, but please let me know if that doesn't do what you want. --Izno (talk) 06:48, 15 February 2021 (UTC)[reply]

Bold style for infobox medals

Hi there, I have a question about this change to the medals of infobox sportsperson. It currently makes all rows bold, not just the header but also each of the medals in the infobox, see for example the "Example" a bit further down on that page. I was wondering whether that was intended or whether it can be changed so that only some but not all rows are bold as it makes the medals section look rather "busy" when someone has won many medals (e.g., Pieter van den Hoogenband). - Simeon (talk) 15:36, 20 February 2021 (UTC)[reply]

Agree, please undo your change. --Marbe166 (talk) 15:42, 20 February 2021 (UTC)[reply]
Agree and I've adjusted Izno's change rather than fully undo it. -- WOSlinker (talk) 15:54, 20 February 2021 (UTC)[reply]
Simeon, Marbe166, that's bizarre, it should only have affected the "header". WOS's change should have solved the issue. I will look later at the more correct solution. --Izno (talk) 17:11, 20 February 2021 (UTC)[reply]
Thanks, it's looking good now :) - Simeon (talk) 19:13, 20 February 2021 (UTC)[reply]

Centralized discussion/core

I don't understand what your 05:23, 14 February 2021 edit to Template:Centralized discussion/core was intended to fix, but on my user page it caused the bullet-items to be centered rather than left-justified, and the text to be made smaller. Scroll down to see the difference between the current version after your edit and the prior version which I put in the template sandbox. – wbm1058 (talk) 15:41, 21 February 2021 (UTC)[reply]

@Wbm1058: I've changed all things with the vertical-navbox class to sidebar as a part of making ((sidebar)) use WP:TemplateStyles. The styles in TemplateStyles apply to all things with the class sidebar on a page (like with infoboxes and navboxes today, because their CSS is in MediaWiki:Common.css). You have another template on your page which invokes ((sidebar)) (the Signpost). My change to CENT accordingly caused CENT to take the common styles from the sidebar CSS now being generated on the page. (This is just one of those "I'm going to run into some suboptimal interactions" kind of things. It actually would have happened whether I made that change or not across everything that used vertical-navbox.) As it happens, it's not just size and alignment, it's also the padding on the full element. There are some options to ameliorate it:
  1. Add all the CENT styles necessary to reset the sidebar styles to restore it to its former glory.
  2. Remove the class. I think the class is appropriately semantic for what the template does (and why I changed it rather than remove it in the first place), so I disfavor this option.
  3. Don't use both on the same page. That option probably doesn't make a lot of sense. :^)
  4. Variant on #1, which I'll probably do, is add templatestyles to CENT.
  5. Tolerate the difference in styling, possibly using ((plainlist)) or something for users who have sidebar styles loading from another template (because you're probably not the only one). Maybe this would impact all views? :thinking:
Opinions welcome. --Izno (talk) 16:51, 21 February 2021 (UTC)[reply]
Sorry, I'm not fluent enough in CSS to have an opinion on which option is best. Would appreciate if you could just use your best judgement and test a solution in Template:Centralized discussion/core/sandbox. Or ask for other opinions at WP:VPT. Thanks, wbm1058 (talk) 15:23, 24 March 2021 (UTC)[reply]
Got an edit queued for this one but I need to go to bed right now. Izno (talk) 06:14, 25 March 2021 (UTC)[reply]
Thanks! Works for me. wbm1058 (talk) 14:06, 26 March 2021 (UTC)[reply]

Collapsible section

Hey, as an aside, when you recently edited ((Collapsible section)), did you make it automatically display uncollapsed when viewing on mobile Wikipedia? It seems it does that now, but I think I remember it didn't earlier on... ɱ (talk) 20:24, 22 February 2021 (UTC)[reply]

@: No, that was one of the points I made in the TFD. That template has never been collapsed on mobile. --Izno (talk) 20:26, 22 February 2021 (UTC)[reply]
That's peculiar, because I'm pretty sure it had, and I even created links in many places, like at High Line, that would ensure mobile users could view the content even though the view button would not display. And I wouldn't have done all that figuring out linking without testing to see how the template works on mobile first... ɱ (talk) 20:34, 22 February 2021 (UTC)[reply]
Only if you view it on the en.m.wikipedia url, you can see that "Interactive route map [show]" gives a direct link to the content within the template. ɱ (talk) 20:37, 22 February 2021 (UTC)[reply]

protection on March

Thanks for protecting March. I know we don't typically protect talk pages, but the same twitch followers are now bombarding the talk page with empty or nonsensical edit requests. Do we ignore them until they get bored and then clean it up? Or can we temporarily protect the talk page as well? Schazjmd (talk) 00:54, 1 March 2021 (UTC)[reply]

@Schazjmd: My protection muscles are a little weak, but I'll take a look. Ignoring and then cleaning up is valid too. --Izno (talk) 00:56, 1 March 2021 (UTC)[reply]
As long as it's not in the article, I guess it's not as critical...just annoying. :) Thanks! Schazjmd (talk) 00:58, 1 March 2021 (UTC)[reply]
@Schazjmd: Protected it much shorter, a couple hours. --Izno (talk) 01:26, 1 March 2021 (UTC)[reply]
Thank you! Schazjmd (talk) 01:30, 1 March 2021 (UTC)[reply]

Template:Multi-listen item

Hello. Today you modified the above template. It applies to single audio files as well as multiple files. One example given in the documentation is the "Skye boat song". As a result of your changes, you introduced a "full stop" (or "bullet point") in single audio files. That can be seen in the example of the Skye boat song occurring in the documentation. In many circumstances, several isolated single audio files can occur in a single movement (a subsection of an article). That happens for example in BWV 39, where there are four separated audio files corresponding to four different segments of the first lengthy movement. I am about to add/modify 18 new files for Organ Sonatas (Bach). Please could the template be corrected so that the bullet point no longer occurs? (Detailed prose content with be added, as has already happened for BWV 529.) Thanks, Mathsci (talk) 15:49, 3 March 2021 (UTC)[reply]

@Mathsci: I think a template named "multi-listen item" should a) be used with other listening items. If in fact it is not, it must still b) be compliant with the expectations outlined at WP:ACCESS, namely that it produces good HTML output. That means it needs to have the start and end templates. The output previously was more or less invalid output when taken in context of the multi-line variant.
Consider using Template:Listen, which I think should probably be used instead for your use case. --Izno (talk) 22:41, 3 March 2021 (UTC)[reply]


Regarding ElinorFan2016, whom you have just recently blocked, there is an ongoing SPI involving them at Wikipedia:Sockpuppet investigations/HarveyTeenager. The Grand Delusion(Send a message) 01:22, 4 March 2021 (UTC)[reply]

A barnstar for you!

The Barnstar of Diligence
Thank you so much for catching the privacy issue with Wikipedia:Discord Comments Hall of Fame; it didn't even cross my mind that it might be an issue (which in retrospect it totally should have), so without your quick action I might have inadvertently caused some serious harm. Keep up your amazing work for this lovely community! Yitz (talk) 06:03, 5 March 2021 (UTC)[reply]

Block evasion

Hello, can you please block Denizgezmis559361 -block evasion of globally locked Denizgezmis557761. --Ashleyyoursmile! 06:26, 7 March 2021 (UTC)[reply]

They have been blocked, sorry to bother you. Ashleyyoursmile! 06:27, 7 March 2021 (UTC)[reply]
No worries, have faith in the system. :^) --Izno (talk) 06:28, 7 March 2021 (UTC)[reply]

The Secretary of Transportation

Izno attacking problematic templates

Thanks for fixing the whitespace issue with that template.  Bait30  Talk 2 me pls? 08:34, 7 March 2021 (UTC)[reply]

Help close a discussion

Hello, there has been an ongoing dispute between two editors including myself with another user who continues to dispute the factual nobility of an article, Arab states–Israeli alliance against Iran. The user, Selfstudier, continues to allege this article is SYNTH and he has made three failed proposals to delete, merge, and move the article. He's been repeatedly been told to stop and to leave the article alone or contribute in a meaningful way, but he refuses to do so. From the three discussions, the majority of editors reached a consensus to keep the article as it is but denies a consensus was reached. He is the only one making the claim against the article's verifiability. If anyone removes the variability tag, he will reverse it claiming it as disruptive editing. Since you're an administrator, it would be greatly appreciated if you could put your input into this. Here is the ongoing discussion on the article's talk page. Thank you. --WikiCleanerMan (talk) 16:33, 7 March 2021 (UTC)[reply]

I support @WikiCleanerMan's request--Steamboat2020 (talk) 16:55, 7 March 2021 (UTC)[reply]
@WikiCleanerMan and Steamboat2020: I am not really the right admin for this request right now. If you believe the editor is disruptive, I would recommend WP:ANI instead. --Izno (talk) 19:44, 7 March 2021 (UTC)[reply]

Query on bot use for a category

Hi Izno, I hope you're well—I figured you might have some insight on this. Over at WP:FGTC, I'm doing some clean up our categories; I never realized that Category:Wikipedia featured topics categories was all organized incorrectly (it seems I'd forgotten to sort the categories when I made them recently, but it looks like others before me haven't been doing this for many years). Is there a bot, or quick way you know of to reorganize these categories so they sort by the first letter of the topic name, rather than "Wikipedia" ? Best - Aza24 (talk) 09:58, 18 March 2021 (UTC)[reply]

@Aza24, I don't know of an existing bot but someone experienced could probably put one together fairly quick for this request. You might ask at WT:CFD too. There is another solution, to create a template that sorts things for you, but I think you still run into cases where you don't want the first real letter to sort e.g. I see Dan Leno is under L. (I don't particularly favor that solution unless you see another reason to add a category.) Izno (talk) 13:17, 18 March 2021 (UTC)[reply]

You've got mail

Hello, Izno. Please check your email; you've got mail!
It may take a few minutes from the time the email is sent for it to show up in your inbox. You can remove this notice at any time by removing the ((You've got mail)) or ((ygm)) template.NASCARfan0548  01:11, 19 March 2021 (UTC)[reply]
@NASCARfan0548: No, this matter neither needs nor deserves an email discussion. What is it you believe you did wrong, and what behavior are you promising not to repeat? --Izno (talk) 01:36, 19 March 2021 (UTC)[reply]
Repeatedly sending unsolicited messages to other users. That I will promise I will not do anymore. NASCARfan0548  01:38, 19 March 2021 (UTC)[reply]
@NASCARfan0548: No, that was not what you were asked not to do. One more chance. You may take as much time as you need to identify what it is you were asked not to do. --Izno (talk) 01:46, 19 March 2021 (UTC)[reply]
Now I have remembered why I was banned, I kept calling other users without their permission repeatedly. NASCARfan0548  02:08, 19 March 2021 (UTC)[reply]
@Izno: are you there? NASCARfan0548  02:05, 21 March 2021 (UTC)[reply]
@NASCARfan0548: I have been trying to decide whether that answer was sufficient. I think it is not. What else were you asked not to do? --Izno (talk) 03:46, 21 March 2021 (UTC)[reply]
Izno, 2 days later, I have finally figured it out. It was: repeatedly sending DMs to other users. NASCARfan0548  22:52, 22 March 2021 (UTC)[reply]
What do you mean by "repeatedly"? Izno (talk) 16:47, 28 March 2021 (UTC)[reply]

My JavaScript

Hi, I’m User:IronManCap, could you please remove my WP:Wikibreak Enforcer from my JavaScript? I’ve decided to take shorter, frequent wikibreaks, rather than a full-on one. Thanks. 2A00:23C7:5EA2:D000:4435:7FA4:7811:B218 (talk) 16:23, 21 March 2021 (UTC)[reply]

You may request that at WP:IANB. Izno (talk) 17:31, 21 March 2021 (UTC)[reply]

Accessibility question

I am confused regarding the seemingly directly conflicting guidance between MOS:TABLE and WP:DTABTUT on which colunn should be the header in tables presenting lists of works. The examples at the MOS use year as the header (in the filmography and discography examples), while DTABTUT actively discourages this (?).

Examining the MOS page's history and the talk page discussion in recent years is even more confusing, because it appears to have changed a few times between the styles.

This seems like a bad state of affairs. I was going to start another discussion on the MOS talk about this, but I thought I would ask you first (perhaps it would be more effective if you could start one). — Goszei (talk) 08:19, 23 March 2021 (UTC)[reply]

testing how to ping

@Izno: Still not working it looks like. Trying ping on a new paragraph instead of in a list. Nicole Sharp (talk) 15:55, 29 March 2021 (UTC)[reply]

new section

@Izno: Trying ping in a new section. I thought that MediaWiki should be able to tell me if the ping works. Nicole Sharp (talk) 15:57, 29 March 2021 (UTC)[reply]

pinging mystery

CENT template div

Hi Izno, this issue may already be resolved when you read this message – either because a cache has been cleared, a style has been updated or an edit to the template has been made. At the moment, the transclusion of WP:CENT at WP:AN (and there only!) has a strange asterisk at the top of the list (see File:20210329-temp-an-cent-broken-enwiki.png).

Perhaps you have an idea what could cause this; I've already tried purging the page. Could it be a syntax error that suddenly became visible by your div cleanup of the CENT template? I have a feeling the issue is not your edit itself. Strange case. 🙂 ~ ToBeFree (talk) 21:56, 29 March 2021 (UTC)[reply]

Perhaps this is caused by the single newline character before (({1))} for the "very compact" style at https://en.wikipedia.org/w/index.php?title=Template:Centralized_discussion/core&oldid=1014330806 , and perhaps the div at https://en.wikipedia.org/w/index.php?title=Template:Centralized_discussion&diff=1014917153&oldid=1014414146&diffmode=source was a workaround to prevent this from happening? ~ ToBeFree (talk) 22:04, 29 March 2021 (UTC)[reply]
Yeah, I trusted preview on this one. Reverted. Izno (talk) 22:25, 29 March 2021 (UTC)[reply]
Well, a practically redundant div tag as a workaround for this strange issue is new to me, and I can completely understand its removal. It does look strange and unneeded. 😄 Thanks ~ ToBeFree (talk) 22:33, 29 March 2021 (UTC)[reply]