User talk:Sbb/Archive 2

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Battle of Cape Engano

It’s considered to be part of the larger Battle of Leyte Gulf, and the link to it redirects to the Battle of Leyte Gulf. There wasn’t a much of a need for correction. In my opinion. Lordkhain (talk) 00:58, 27 January 2020 (UTC)

@Lordkhain: Before my edits (I made about 40), there were about 39 pages that used "Battle of Cape Enga[nñ]o", and about 60 that used "Battle off Cape Enga[nñ]o". I figured the need for correction was to make it consistent through WP, and also because the most consistent reference to the battle in DANFS & action reports is "off". It's perhaps a minor distinction, but it's similar with the Battle off Samar. I realize the Battle off Cape Engaño is considered to be a part of the larger Battle of Leyte Gulf (BoLG), but then again, so is the Battle off Samar, Battle of Surigão Strait, and the Battle of the Sibuyan Sea. Quoting directly from the intro section of BoLG: "The battle consisted of four main separate engagements: the Battle of the Sibuyan Sea, the Battle of Surigao Strait, the Battle off Cape Engaño and the Battle off Samar, as well as lesser actions." That 3 of those battles don't have their own WP pages and are only sections in the BoLG page doesn't mean that they don't deserve correct spelling and consistent reference. (i.e., WP:NOTSOURCE). 01:34, 27 January 2020 (UTC)

Template:-s

Hi, I don't know if you aware of the template with the same name on the French Wikipedia (fr:template:-s). for years, I (and others) have been finding/cleaning up places where people copy-and-paste text from the French Wikipedia to this Wikipedia. I usually do this by checking Special:WhatLinksHere/Template:-s, but now that method doesn't work. for fr:template:e, we have a tracking category, Category:Articles using E without any arguments. we could do something similar in this case if we disallow the |1= parameter and add tracking. or, we could rename your new template? do you have any suggestions on what to do? thank you. Frietjes (talk) 14:25, 12 August 2020 (UTC)

@Frietjes: No, I definitely wasn't aware of the template on French Wikipedia. I'm sorry, it didn't even occur to me such a case would impair interwiki maintenance and cleanup. I'm not quite clear, but are you saying that if the {{-s}} template didn't have parameters, then you could track fr-to-en copy-paste uses easier (because fr:template:-s has a required parameter)? If that's the case, then I see 3 possible paths forward:
1. Rename {{-s}}. I really don't like this path at all.
2. Disallow |1=, and also create {{-es}} to handle the cases where pluralization requires "-es" (i.e., words ending in "s", "x", or "z"). I was going to do this originally, but I figured it was kinda of a waste of a short-named template for the relatively infrequent need for a template for the "-es" suffix case. On the other hand, {{-es}} would have some nice symmetry of use – similar to using {{'}} and {{'s}}.
3. Modify {{sclass-}} to accept additional parameter(s) (or create a new similar template, perhaps something like {{sclassu-}}?) to handle the space formatting in the italicized word itself (and also format the text unlinked, whereas {{sclass-}} always produces links now), rather than letting the suffix deal with the spacing. This would solve the very minor kerning issue when words like "-class" are adjacent to the italicized word. However, this is a lot more complicated of a template change, and probably also should be shopped around WP:SHIP.
Option 2 is trivial, and seems to be the least amount of hassle. I'm all for it if you want me to do it. I can knock it out, and make the edits to the few uses of {{-s|es}} I've done so far. sbb (talk) 19:54, 12 August 2020 (UTC)
@Frietjes: Update: I went ahead with option 2 — I created the {{-es}} template, and am removing all uses of the unnamed parameter in my edits that used {{-s|es}}. sbb (talk) 19:53, 13 August 2020 (UTC)

@Frietjes: Final update: Blanked & request deletion of the templates, and undid all the page edits I made that used them. I was trying to solve a presentation problem that exists in Vector.css, not any of the newer skins (don't care about older skins). Full documentation at: User:Sbb/Oops#Template -s. Sorry for the hassle. =) sbb (talk) 03:55, 14 August 2020 (UTC)

Okay, that works too. Thanks for the update! Frietjes (talk) 17:28, 14 August 2020 (UTC)

ISBNs and OCLCs

If you click the ISBN on a source, it takes you to this page, where Worldcat is one option to search for the book. We don't need the general link and the Worldcat specific link. Parsecboy (talk) 19:23, 14 December 2020 (UTC)

@Parsecboy:
 – sbb (talk) 19:44, 14 December 2020 (UTC)

Peterhead whaleboat - just curious

Seeing your pointers on the Peterhead Whaleboat on Wikipedia talk:WikiProject Ships I am curious as to whether (a) you already knew about the Peterhead Whaleboat or (b) you knew of a good place to look up this information?

I ask because I am steadily gathering sources to work on traditional small craft, particularly open boats, and have not detected much of a level of knowledge in the editor community on the subject. (I am, for instance, waiting for the arrival in the mail of source that should allow me to sort out Ship's boat - I discovered the existence of this book from an e-mail conversation with the historian employed at USS Constitution.) ThoughtIdRetired (talk) 08:35, 28 December 2020 (UTC)

@ThoughtIdRetired: No, I'm sorry, I'm not knowledgeable about whaleboats, nor good places to look up this information. I just queried those terms, and spent about 15 minutes reading and searching to convince myself that I wasn't missing any possible other types of ships. =) sbb (talk) 16:56, 28 December 2020 (UTC)

Kabuto and Lang Templates

Hi there. So the edit about the language template all across Kabuto. I was a little hasty, I'll admit it, and it only looks completely ugly on Safari. On Chrome on a desktop it looks fine, non-notable other than the italics. So yeah fair. Apologies for the revert.

It does however raise an interesting point I'd like to discuss. The automated template insertion you used has also put the template in section headers which, I believe, is a violation of MOS:HEADINGS. Specifically that headers can "Not contain template transclusions", it also says "These restrictions are necessary to avoid technical complications, and are not subject to override by local consensus." So the script you used and the replacement in the section headers appears to violate that and should be rectified. Unless I'm completely missing something. Am I misunderstanding the term transclusion here as its not technically pulling in other data in a way? Serious conversation, not trying to start anything. Canterbury Tail talk 01:40, 26 February 2021 (UTC)

@Canterbury Tail: Firstly, no worries, no need to apologize for the revert. Clearly you assume good-faith on my part, and I assume so on yours as well. =) Secondly, you're absolutely right about not using templates in headings. I wasn't really aware of that (I know I've read the MOS many many times, but I guess that detail never registered with me). In cases where foreign language words are used in section headings, the MOS rule seems a bit broken, but as you note, "These restrictions ... are not subject to override by local consensus."
In searching around, there is a {{heading}} template that supposedly is to be used when heading wikitext can't be used. But if you check that template's "What links here", restrict it to Article namespace, and only show transclusions, it's used on only 5 pages, and even then, it looks like only one of those uses is even slightly novel (creating section headings within a multi-column list). So while I'd like to have the need for {{transl}} around foreign text justify use of the {{heading}} template, I don't think it's a good idea.
Thanks for the heads up. I'll remove the {{transl}} template use in the headings. Cheers! sbb (talk) 02:15, 26 February 2021 (UTC)
@Canterbury Tail: Sorry, forgot to also mention, I double-checked browsers as well. It doesn't look bad in iOS or iPadOS Safari, the Wikipedia iOS app, or in macOS Firefox. I'm pretty sure the Mac Safari font-stack for the Vector skin is outdated. I have run into other font display issues in Mac Safari, such as italic text followed immediately by non-italic text (without spaces in between) to be kerned together too closely. I've been meaning to raise the issue ... somewhere? Villge pump? Mediawiki bug tracker? sbb (talk) 02:22, 26 February 2021 (UTC)
Clarify the bad bit. It was Chrome on my iPad that it looked bad on. The foreign fonts were a thinner font and a couple points larger than the rest of the page so it really stood out. Could be my config, could be that Chrome using the Safari engine on the iPad is just wonky (well we know that's the case.) Desktop, can't see any issues.
I do wonder if that section of the MOS (template transclusions) is perhaps out of date as it does cause a clash with the Foreign Language MOS sections which is what you're trying to deal with. I wonder who would know more around that and if what you're doing is truly going to cause a technical issue (I can see links to sections from other articles potentially having issues, but I think they work on pure text and the links to headers all appear to function fine.) It's not like the template is pulling in additional data not present on the article or anything. Canterbury Tail talk 13:16, 26 February 2021 (UTC)

refbegin/end

What exact accessibility info does the template add that isn't already provided by the headers? And isn't outweighed by the shrinking of the text? See the comments by BilCat on my talk page.--Sturmvogel 66 (talk) 09:36, 27 February 2021 (UTC)

@Sturmvogel 66: Semantic information / metadata is accessibility-forward. From the doc page for {{refbegin}}: "These bibliographies or reference lists frequently appear in dedicated sections within an article, variously titled ==References==, ==Works cited==, ==Bibliography==, ==Further reading==, ==Published works==, and so on." Scraping headers for various spellings, provides absolutely no means for accessibly accessing information, as compared to identifying <div class="refbegin"> HTML tags.
With regards to BilCat's comments, the solution is simple for any individual: add the CSS rule, div.reflist {font-size:100% !important;} to Special:MyPage/common.css. Alternately, if you wish to change the default for all users, edit the {{refbegin}} template to not adjust font size. There are several ways to effect 100% font size change for you, and still maintain semantic information in the page.sbb (talk) 04:02, 28 February 2021 (UTC)
Frankly, I see no particular value to being able to scrape info in the manner to which you refer, but I'm not a coder and honestly cannot attribute a value to that property. But right now I see something that actively impairs readers like BilCat from easily reading the material in question and that's something that I find much more important in the short term. I'll try the CSS rule, but eliminating the font size change entirely should be the standard for all users with a font reduction opt in, IMO. That, however, is a long-term objective, as a consensus must be established (I'm certain that I'd be reverted were I to boldly change that property myself without such) and that's a PitA, albeit a necessary one.--Sturmvogel 66 (talk) 15:25, 28 February 2021 (UTC)

Germany and the Second World War

Given that Diannaa weighed in on this to your favor, an admin editor whose opinion I respect, go ahead and convert the citation to your preferred format. Nonetheless, you'll note that Diannaa also acknowledged its listing in Worldcat, which lists it the Chicago Manual of Style format. Technically I knew you were correct about Wikipedia guidelines; however, I am a professional (Ph.D) historian and know how we cite that work in the "real" world of academia. Victory is yours, nevertheless. We won't need to wait on other editors, even if they agree with my approach. --Obenritter (talk) 11:52, 22 April 2021 (UTC)

@Obenritter: I appreciate your viewpoint and your real world experience and knowledge about citation in academia; I am grateful for the opportunity to interact and learn, always. I am not in a hurry to update the reference, and I do want to give some time for others to weigh in – if for no other reason to help calibrate my own sense of what the community consensus is. — sbb (talk) 14:58, 22 April 2021 (UTC)
BTW -- I chuckled when you left the "game on" message on my Talk Page, because I already knew you were right, technically speaking. However, since an Admin already agreed with you because it is Wikipedia standard, pretty sure the decision was rendered. --Obenritter (talk) 16:11, 22 April 2021 (UTC)

Jabari Simama/Edits

Hello Sbb, I am a bit dismayed by the attention you have given to this wikipedia page but let me assure you that there is no inherent COI. I became concerned about the number of edits you made to this article and wondered if you did not have some interest in this particular issue. — Preceding unsigned comment added by MsMaam (talk • contribs) 20:39, 27 April 2021 (UTC)

@MsMaam: My attention to the page came about only because of your edits. I assure you, I have absolutely no COI with this page. I don't know who Jabari Simama is (outside of this Wikipedia article). But your edit history leads me to believe that you are indeed Mr. Jabari Simama. I know Wikipedia requires WP:GOODFAITH, but since this is my own Talk page... I'm calling you out. I think YOU ARE Mr. Jabari Simama.  — sbb (talk) 20:51, 27 April 2021 (UTC)
Hello Sbb, I am not Jabari Simama and you are not calling me out. Who are you? I am not going to let the racist biased news stand as truth, even in a wikipedia article that is tampered with consistently by you as some objective source and crusader for truth and accuracy. Sources do not speak for themselves and journalism is not a science. You are someone who obviously has an interest in this story.
@MsMaam: I had no interest in Jabari Simama. I merely came across this article because of category maintenance flags, and accidentally left it in my watchlist. But then I noticed your highly irregular edit pattern of deleting anything remotely negative about the subject of the article, deleting reliable sources in the article, and consistently editing the article in a favorable light. You may not be Jabari Simama, but you seem to have a particular interest in editing the article to always appear apologetic or favorable to the subject, without having ANY appearance of objectivity. You clearly have an agenda with regards to the article.  — sbb (talk) 01:57, 28 April 2021 (UTC)
 – discussion about WP:COI edits belong at article Talk, not user Talk.  — sbb (talk) 02:10, 28 April 2021 (UTC)
 — sbb (talk) 02:10, 28 April 2021 (UTC)

A barnstar for you!

The Original Barnstar
Sbb, thanks for letting me know about my faux pas; I've added the references. The bribery involved in the construction of the Kongo caused the fall of a government as well as the arrest, trial, incarceration, and death of people--as such it's a significant fact that people ought to be aware of.

If you have modifications to suggest I'm glad to discuss this with you further. Patrick Marder. Guerre1859 (talk) 03:51, 17 May 2021 (UTC)

@Guerre1859: Thank you, very kind of you! I see your latest addition of the material to Japanese battleship Kongō was reverted. I presume that was probably a mistaken revert; User Cléééston is usually a very conscientious editor. They probably quickly assumed you reverted my revert, is all.
I restored your latest source addition of material, and made some minor copy edits to the addition. Thanks for your contribution.  — sbb (talk) 16:45, 17 May 2021 (UTC)

gkm?

At this edit (line 1555-ish), you added this:

{{lang|gkm|dēmos}}

which renders as:

[dēmos] Error: {{Lang}}: unrecognized language code: gkm (help)

What did you really mean to write? Please preview your edits.

—Trappist the monk (talk) 14:41, 4 June 2021 (UTC)

At the time, I did intend to use gkm, for what I assume was medieval greek. I'm not sure where I sourced the code, but clearly it's not a correct ISO code. I've edited the article to use grc in that instance.
At any rate, I always to preview my edits. Sometimes the Wikipedia previewer doesn't render, perhaps this was one of those times. Thank you for your time, sorry for the confusion.  — sbb (talk) 16:12, 4 June 2021 (UTC)
{{lang|grc-x-medieval|dēmos}} → dēmos
I would be very interested to know under what conditions Module:Lang fails to render an error message in preview mode; I have never seen that happen. Can you give me an example of such an occurrence?
—Trappist the monk (talk) 16:30, 4 June 2021 (UTC)
Sorry, to be clear, it's not that Module:Lang fails to render — it's the entire preview that occasionally fails to render. I tend to use the 2017 visual editor (I think, I don't really understand the names of the different WP editor tools).  — sbb (talk) 16:34, 4 June 2021 (UTC)

Tables

Hi, I noticed you've been updating the markup for some tables, but wanted to ask that you check them when you're done. There was a minor issue at List of aircraft carriers of the United States Navy, since fixed, but there are still some errors at Arleigh Burke-class destroyer that need to be fixed. Thanks - wolf 02:29, 6 August 2021 (UTC)

Hi Wolf. I do try to check what I'm doing as I go along. I admit, I'm kinda doing big changes all at once, so I'm sure I can do better. I'll go back and diff the histories. What did I screw up, in case I don't see it in my comparisons? It could be that my regex replacements made systematic errors (which frankly, is probably easier to spot than several one-off screwups). Again, apologies. I'll stop moving forwards, and spend some time diffing.  — sbb (talk) 04:34, 6 August 2021 (UTC)
Ah, was it the missing format parameter of the several {{USS}} templates (~30 of them), that showed full "USS Ship destroyer"? (Fixed here) Sorry about that. Indeed, there must have been some regex copy/paste errors in my work. I'll try to pay more attention if I do any more tables.  — sbb (talk) 04:46, 6 August 2021 (UTC)
I see you made some edits/fixes, including one with the edit summary: "fixed <ref> in ((efn)) error", but after that edit, the multiple, large, red "error" notices still remain at the bottom of the table and now in the ref section. These errors weren't there before your initial edit, so it seems something is being missed. I know you're trying to make improvements, and even appreciate that, given the effort you're putting in. But articles should be left better than as they were found. Should the table be reverted to its previous state, or are you still working out the error issue? Thanks again - wolf 16:05, 6 August 2021 (UTC)
Hmm. I made the fix, and the large red error notices went away after I submitted my edit. I'm wondering if I'm seeing a caching issue in my browser. I'm working on it. Sorry for the hassle...  — sbb (talk) 16:42, 6 August 2021 (UTC)
More hmm. I've been doing some experimenting in my sandbox, and I think there's either a bug in the {{efn}}/{{notelist}} parsing, or I'm using them wrong. I'm loathe to suggest there's a bug in the module (because it's usually a "when you hear hoofbeats, think horses, not zebras" issue). But I'm fairly confident I'm doing everything right in Arleigh Burke-class destroyer. I'll keep experimenting and digging in.  — sbb (talk) 18:09, 6 August 2021 (UTC)
I see you're still looking for a fix for the Burke class table, have you tried asking posting at VP/T? Also, I noted the changes you made to the list of USN subs, but wanted to ask; what benefit does the extra markup there provide? I maintain some of these tables (even created a few), so this is just for my own edification. Thanks - wolf 12:45, 9 August 2021 (UTC)

@Thewolfchild: (Note: I outdented my reply because I couldn't get my tables below to display when they are indented in the reply.)

re: still working on {{efn}}/<ref> errors in Arleigh Burke-class destroyer: No, I haven't asked at VP/T, but that's a good suggestion. That'll be my next step, in addition to more experimentation and trying to narrow down the issue in my sandbox.

re: table markup at e.g. USN subs: what I've been doing is all for data table accessibility. Basically, following Wikipedia:Manual of Style/Accessibility/Data tables tutorial (MOS:DTT), data tables need a caption, row & column headers, and scope="col" / scope="row" for those headers. scope=... is there to help screen reader software associate headers with their corresponding data in the table.

Also, once a table is sortable, some glaring accessibility issues pop up where they might not be obvious. For instance, before I edited Arleigh Burke-class destroyer, the table had interstitial "subheader rows" separating Flight I, Flight IA, Flight II, etc. ... Arleigh Burkes. But the table is sortable, so the moment the table is sorted, all of those "subheader rows" get lumped together at the top or bottom, and their meaning is lost, no longer associated with the ships that belong to Flight I, etc. MOS:COLHEAD advises against doing that, either by splitting it into separate tables for each Flight, or more preferably, adding a data column specifying the Flight, thus allowing Flight to be another sortable characteristic.

the "plainrowheaders" addition to the table's class isn't an accessibility thing — I just didn't want to make too much of a visual change in my cavalier editing =). It just makes the row headings not bold, and default left-aligned, instead of center-aligned and bold like table heading cells normally are:

without plainrowheaders
Name Hull No. Flight Builder
Mitscher DDG-57 I Ingalls
Laboon DDG-58 I Bath
with plainrowheaders
Name Hull No. Flight Builder
Mitscher DDG-57 I Ingalls
Laboon DDG-58 I Bath

 — sbb (talk) 16:17, 9 August 2021 (UTC)

Thanks for the reply and info. Good luck with your effort to resolve the markup issues. - wolf 21:57, 9 August 2021 (UTC)
Looks like you got it ;-) - wolf 17:04, 18 August 2021 (UTC)

I certainly hope so! =)  — sbb (talk) 19:14, 18 August 2021 (UTC)  — sbb (talk) 19:14, 18 August 2021 (UTC)

Tables

Hi, I'm also working on the Moss project and saw your comment on the page for letter S in the HB+ section about the side by side tables. This is one of the html issues that I haven't been able to figure out how to fix. If these can't be sent to a Wikiproject, can you point me to a page that you've already fixed, so I can see how it's done and also fix these pages? And thanks for all your help on the Moss project. Ira Leviton (talk) 13:56, 9 August 2021 (UTC)

Hi Ira. No no no, thank you for all that you do on Moss. =)
Thankfully, in mid-June, Help:Table#Side by side tables was updated to completely eliminate the suggestion of using list items (<ol><li style=display:inline-table>), instead just wrapping the tables with <div style=display:inline-table>...</div>. So that's how to eliminate all those <ol> and <li> from those types of use cases that appear in the cricket club articles.
But in the larger scheme, the tables in those cricket club articles are a complete mess. Some of them rely on color-only coding (against MOS:COLOR). The "honours" tables near the end should be combined into just 2 (at most tables): a table for cup wins, and a table for divisional/league championships. For instance, my edit to Risley Cricket Club shows how at least the Honours section could be refactored (note, I didn't bother making the earlier tables in the article MOS:COLOR compliant. That's probably part of a larger effort to bring ALL of those articles into a better shape. There might be cricket templates that can help with that, but I don't know anything about cricket). I have also been at least improving the tables with accessibility markup per MOS:DTT (captions, column and row headers, and scope="col"/scope="row" for col/row headers), and strip away outdated or unused style and formatting.
Two other recent cricket articles I edited are Spondon Cricket Club and Stanton-by-Dale Cricket Club. I did very little, if any, Honours refactoring one those two.  — sbb (talk) 16:52, 9 August 2021 (UTC)

250t-class torpedo boats

G'day Sbb, thanks for updating the table formatting on this article and add the nbsp's. I just wanted to add that I am probably not the only one that finds it irritating when editors change the structure and headings of the end matter sections of an article to one they prefer. I have had dozens of FAs promoted with the end matter structure the article had, and it is my view that no editor should be going around changing article reference structures that are completely within the existing guidelines of MOS:REFERENCES to one they prefer, and I suggest that if this has been your practice, you stop doing it. Thanks, Peacemaker67 (click to talk to me) 21:44, 17 August 2021 (UTC)

@Peacemaker67: Hi. It didn't occur to me that article was FA. I do often refactor reference sections if they aren't consistent, but I try to pay attention and not do that if they are FA. In fact, if they are FA, and I feel that the article can be improved, I'll ask for consensus first on the Talk page (and wait for at least 30 days).
Sorry about that. If you haven't done so, I'll be happy to go back and selectively revert the refs section changes to the article.  — sbb (talk) 22:47, 17 August 2021 (UTC)

Navy table problem

Thewolfchild asked me to contact you about this problem, and states that you are reformatting tables that need updated markup. For some reason, I'm having formatting problems with the List of United States Navy three-star admirals since 2010. The date of rank column (the dates for each admiral, not the column name itself) are supposed to be align="right" (like this) but for some reason they are all misaligned. Can't find the issue myself, may need help to fix the alignment. You can remove this message once you've read it. Thanks! SuperWIKI (talk) 17:01, 18 August 2021 (UTC)

@Sbb: There may have been a miscommunication. What I requested for the align format and design to match these lists, but with the alignment fixed. Is there any way to fix that? It doesn't seem to have any problems on other pages I've made, but the Navy one has odd problems. SuperWIKI (talk) 18:45, 18 August 2021 (UTC)
I don't believe there was miscommunication. The dates of rank are right-aligned. Also, please undo your reverts, because all of the changes I made were in accordance with the MOS table accessibility guidelines.  — sbb (talk) 19:00, 18 August 2021 (UTC)
Hi SuperWIKI. I went ahead and cleaned up the table for accessibility by adding a caption, adding row headers (columns were already headers), and adding scope="col"/scope="row" to the column/row headings, and also added "plainrowheaders" to the table class list (to keep the row headings non-bold and left-aligned).
The date of rank column was right-aligned. However, use of align=right is deprecated in HTML 5 (probably also in XHTML, and perhaps in HTML 4.01 too). Instead, use CSS styling: style="text-align: right;". Additionally, most of the rows had a trailing " &nbsp;" (that is, a space followed by the non-breaking space character). That was preventing the year from aligning to the far right. I removed those trailing spaces.
Some other edits:
  1. I removed the {{sort}} template use for the name and dates of rank columns, replaced them with data-sort-value="" in the cell's parameters section (before the "|" before the cell's contents). {{sort}} is deprecated (see it's documentation page), and should be replaced with data-sort-value="".
  2. I removed the column widths from the header cells. Firstly, the column widths were specifying pixels, which is bad for flexible layouts. Furthermore, per Help:Table § Width: "Note: width=x is ignored in tables in HTML5 in Wikipedia."  — sbb (talk) 18:58, 18 August 2021 (UTC)
Are there any ways to customize to an extent that say, allows for changes in size of the table widths, or boldings of the columns, or does the new format not allow for those at all? Apologies, but the sudden change in the way the list looked blindsided me, as I was used to the way things normally looked and got a bit scared. The dates of ranks and names now look squashed and too small. SuperWIKI (talk) 19:19, 18 August 2021 (UTC)
Hmm, interesting. Other than darker background for the tow header cells, I didn't notice hardly any other difference. Possibly could be due to browser and system differences? Are you on desktop or mobile? What is your browser?  — sbb (talk) 19:46, 18 August 2021 (UTC)
Desktop, Chrome. But I don't think it's a browser problem, more my discomfort with the sudden change in markup and me having to learn everything again. I might draw your attention to these pages which may need changes in wiki markup (and mind you, I do so with genuine trepidation because I'm still not used to the change but I'm starting to feel better now). Before making the changes, I highly suggest you contact Morinao and Neovu79 first before making the changes, and tell them what will change. They are the main editors of the pages that I mention (my list you edited was based off of Morinao's style, which was done in 2007-2009), so I highly encourage informing them of the changes and getting a reply before doing anything. I don't want them blindsided like I was earlier, and I do this with good faith. So here's the relevant pages:
These are my pages (which you may change as necessary). Just keep me appraised of what will change:
Still unfamiliar with the markup, and since I believe you specialize in converting this material, I appreciate your assistance.SuperWIKI (talk) 20:21, 18 August 2021 (UTC)
P.S. There is still more of a visual problem about the date of rank for each admiral looking squeezed between columns instead of being one straight line like from before your edit to the new format. Might need to rectify that before revamping for the pages listed above. Plus, this problem persists on both Chrome and mobile. SuperWIKI (talk) 20:35, 18 August 2021 (UTC)
(I'm responding on mobile while I'm out and about, and the indentation seems weird. I have no control over it, and if I go into desktop view on my mobile, I'm unable to edit source and handle it correctly, so bear with me if this isn't indented correctly)
Please describe what you mean by "date of rank being squeezed between columns instead of being one straight line like from before your edit". From my browser's view, there is relatively little difference between before my edits vs. after.
Big picture, over-specifying column widths, adding extra empty spacing, etc. to make tables look "good", don't really work. Different display/monitor sizes make a huge difference in how tables appear.
When you asked me originally, what I noticed about the date column (on my screen) was the day and month in the first line, and year on the 2nd, with extra space after the year (because of the space+nbsp that's I mentioned). After my edits, the column appeared the same, except the year was nestled fully to the right (without the right padding from the spaces).
I'm not sure a problem actually persists. Once you remove the invalid markup (valign, align=), and move to semantically valid (and recommended, from an accessibility standpoint), things might look a little different, but then there's the opportunity to use some slight "tweaking" surgically, rather than trying to "hammer" the table to fit what we think it might/should look like. The old web idea of trying to make pixel-perfect representations is long dead. Things are now more flow-oriented and data-centric, rather than presentation-centric.  — sbb (talk) 21:19, 18 August 2021 (UTC)
I will try to describe it. The date (for example 05 May 2021) is presented in the column as occupying one line with no break, with the numbered day, month, and year on the same line. There is a slight space after the end of the year. Otherwise, I do get why the changes have to be done, to make tables easily readable as much as possible across all devices rather than look aesthetically pleasing. If my description doesn't assist you, should I send appropriate screengrabs? Additionally, Morinao added 0 before the number of the day if the day was single-digit (05 Apr 2011 for example), and a user removed all the zeroes soon after yr edit. Does that style break table MOS? SuperWIKI (talk) 04:01, 19 August 2021 (UTC)
(Edited above for indentation only, no other changes)  — sbb (talk) 01:26, 19 August 2021 (UTC)
Found the {{{1}}} which AFAIK isn't deprecated. I'll see if I can use that for dates. SuperWIKI (talk) 07:50, 19 August 2021 (UTC)
  1. {{nowrap}} is certainly a way to do it. I have used it, even quite recently, for exactly what you're doing. Another option is to use &nbsp; (or, equivalently, the {{nbsp}} template) instead of spaces in the date. However, there's another way: use style="white-space: nowrap;" (as suggested at Help:Table § Nowrap) for just one of the date cells (it won't work in the header cell for the date column), the cell with the longest date in terms of character width. So, a date with 20-something or 30-something for the day of month, where the month isn't "Jul" (the "l" in July is a bit narrow), with wide digits for the year. It does seem sort of "hacky" to me, but it is recommended by Help:Table.
  2. Also, just targeting the same single date with {{nowrap}} (or nbsp; spaces) instead of the style="white-space: nowrap;" works too. There isn't really a need to {{nowrap}} all the dates. It doesn't hurt anything to have them all nowrapped, but if a page gets large (especially easy with table list pages), a lot of template replacements slow down page processing on edit saves. Just personally speaking, I dislike seeing extra "clutter" that isn't necessary, but that's just a personal thing of mine, and I don't go removing all that (unless I'm doing huge sweeping edits for other reasons). And if, in the future, people decide that they don't mind if the year wraps in order to allow the column to be narrower (perhaps because of tight spacing for mobile, etc.), it's only a single place to make a quick edit to allow that to happen, rather than having to remove {{nowrap}} from every. single. instance. =)
  3. Also also, because none of the dates in the column will wrap, hard-setting "style:width=5m;" on the column is unnecessary, but not wrong, IMO.
  4. MOS date style: per MOS:BADDATE, 0-padded days aren't an acceptable date format. So "5 Apr 2011" is the MOS format.
  5. Also, just for clarity, MOS:DATE say "5 Apr 2011" is acceptable "only in limited sutations where brevity is helpful" (with a footnote giving tables, infoboxes, references, etc., as examples). So, fine in the table, just not in body text.  — sbb (talk) 14:04, 19 August 2021 (UTC)
I understand that what you're doing now has not much to do with the appearance but more of removing deprecated code and replacing it for accessibility, especially code that require px guidelines. Thank you for informing me of this. I will continue to edit the table to maintain current code, but appearance-wise, such as bolding of the names does not seem to be one of the actual accessibility guidelines. I will take a look at that. In the meantime, I would appreciate the updating of deprecated code and updating of accessibility standards of the listed pages, which are part of the same series of pages that you edited. I will come in after you have finished and make any necessary cosmetic changes. Thanks very much! SuperWIKI (talk) 17:42, 19 August 2021 (UTC)
I haven't made any edits to any of those pages, other than the one you came to me about. I didn't bold the names (I'm assuming you're talking about the row header cells). My 2nd edit to that article added "plainrowheaders" to the class list of the table (I forgot to do that in my first edit). "plainrowheaders" makes row header cells (the ones starting with ! scope="row" | not-bold, and left-aligned. Add that back in, and Bob's your uncle.
I'll add those pages to the list of articles I'll update for table accessibility, but fair warning: it'll be awhile. WP:SHIPS is my main interest, and I'm currently working on tables in each article listed at List of ship classes of World War II, and I'm only in the A's so far.  — sbb (talk) 18:06, 19 August 2021 (UTC)
I'll try updating some of the shorter ones to help you out. No biggie. I'll come to you for further help on markup if necessary, thank you. SuperWIKI (talk) 18:15, 19 August 2021 (UTC)

Small changes big impact

Thanks for your edits to the USS Samuel B. Roberts page, it's much freer reading & the section moves makes sense. My own personal bugbear with a lot of USS ship pages is that they're a bit too Marvel Comic & not encyclopedic "Steaming aggressively through a gauntlet of incoming shells" being an example although I don't wish to undermine the actions of the crews. Steve Bowen (talk) 06:28, 23 August 2021 (UTC)

Thanks. But make sure to give credit for deleting the peacock wording to User:TenthEagle.
Most of the time, that type of wording came straight from the ship's entry in DANFS. Because it's a US Gov work product, it's public domain. So it was used as the basis for _many_ ship articles years ago. But yeah, its wording is definitely not encyclopedic! =)  — sbb (talk) 14:56, 23 August 2021 (UTC)
Ah... I didn't see you are TenthEagle. Lol. =)  — sbb (talk) 14:59, 23 August 2021 (UTC)
Thanks for the clarification on DANFS, I edit quite a few of these pages & hope I don't upset too many people. As for US-isms, I'm with you when it comes to US articles & do my best, particularly as a lot make more sense anyway but "airplanes" over aeroplanes is a new one on me. + As an aside, I live 19km from Stanton-by-Dale Cricket Club and just 12km from Spondon Cricket Club. Bizzare :D Steve Bowen (talk) 06:49, 24 August 2021 (UTC) Enjoy your editing
nah, your edits of the obviously bad peacock & puffery is definitely appreciated. Re: the cricket clubs, heh, I was wondering if/when I was going to get any comments at all. I've edited maybe about a dozen cricket club articles, probably all in the same local league (or related... league? I know nothing about cricket, and even less about regional or club-level). They came across my radar while clearing out articles as a part of Wikipedia:Typo Team/moss cleanup.  — sbb (talk) 13:19, 24 August 2021 (UTC)

They say lives too short to explain the rules of Cricket to an American - so I won't but Try THIS

List of United States Coast Guard three-star admirals since 2010

Did the relevant CSS markup updates for this page but the date alignment still won't fix. Would you mind checking for any problems? — Preceding unsigned comment added by SuperWIKI (talk • contribs) 10:03, 31 August 2021 (UTC)

@SuperWIKI: I added "white-space: nowrap;" to the style= table cell parameter for what looks like the widest date (in terms of character widths).  — sbb (talk) 15:17, 31 August 2021 (UTC)
Thanks! SuperWIKI (talk) 15:21, 31 August 2021 (UTC)

USN WWII submarine list articles

Thank you for improving the style of List of Gato-class submarines, which I created. I just want to let you know that List of Balao-class submarines and List of Tench-class submarines could probably use similar rework at your convenience. RobDuch (talk·contribs) 21:02, 7 September 2021 (UTC)

@RobDuch: Thanks for the thanks, and done. =) Honestly, I'm surprised I hadn't already edited the Balao and Tench lists. I thought I got all of the big lists of US and British ships.  — sbb (talk) 21:55, 7 September 2021 (UTC)
They're only 3.5 years old, and I didn't link them too much except for the parent articles. One of these years I might do the American S-boats. There are at least a couple of other US submarine class lists, namely Sturgeon and Los Angeles (probably Ohio also), but I haven't worked on them. RobDuch (talk·contribs) 23:26, 7 September 2021 (UTC)
Eventually I'll make it to all the tables in ship class, List of ..., and even individual ship articles. Currently I'm working my way down each row in List of ship classes of World War II, and working on the table accessibility for each one (if the article contains tables, that is). Sometimes it's fast, sometimes it takes work. =)  — sbb (talk) 23:31, 7 September 2021 (UTC)

As requested...

Hi Sbb,

As requested I am leaving a message with you here, though I am uncertain how to simply leave a message without starting a topic, so I apologize if I have responded incorrectly.

I am Sunartesis. You removed a link I had placed from the LSJ to a public domain version of the LSJ. You said this link was inappropriate for an encyclopedia, but did not explain why. Respectfully, I cannot imagine it being more appropriate. Are you familiar with the LSJ, and did you visit the link? I think this removal is in error, and would like to better understand your reasons.

Many thanks, and have a great day. — Preceding unsigned comment added by Sunartesis (talk • contribs) 13:49, 12 December 2021 (UTC)

@Sunartesis: I removed the link because after looking at your edit history, every edit you have made, save 1 edit, have been to add a link to stoictherapy.com in the External links sections of those articles. Are you promoting that site? Are you in any way related to that site (i.e., having an ownership interest, paid by, hired by, write for, etc.)? If so, your edits, while certainly topically correct, amount to a form of spamming.  — sbb (talk) 21:20, 12 December 2021 (UTC)

I'm not affiliated, I'm aware of Wikipedia's policy regarding promotion, thanks for checking, and I'm not spamming, but just including relevant links to material I like, to a site I like. Please reinstate the link if you deem it appropriate, and if I may be so bold, maybe next time you could talk first with a person before reacting, much like I am sure you would prefer a police officer to talk to you first rather than give you a ticket before even walking up to the vehicle. Or that's how it seems to me. Just trying to help. Thanks again, Sunartesis. — Preceding unsigned comment added by Sunartesis (talk • contribs) 21:47, 12 December 2021 (UTC)

@Sunartesis: I stand by my edit. I don't see a need to have a link to LSJ hosted at stoictherapy, when there are already several external link sources already in the article, as well as links to online versions.  — sbb (talk) 22:26, 12 December 2021 (UTC)

That makes sense, it's a busy page. I think there are good reasons for that link (one really good one is because you can ctrl-f and search for terms of interest across multiple entries whereas other places like Tufts only show one entry at a time), but you don't seem interested in figuring out what's best here for Wiki surfers interested in the LSJ and are instead changing your reasons first from some unsupported appropriateness to promotion to clutter. Finally your third argument has some merit (still disagree, but hey, that's life). But constantly changing reasons makes it seem like something else is going on; I'd expect more from a Gnome. Anyways, moving on. — Preceding unsigned comment added by Sunartesis (talk • contribs) 11:53, 13 December 2021 (UTC)

@Sunartesis: You seem to be heavily invested in making sure that that specific link (i.e., the one at stoictherapy.com) is on the page. Additionally, all of your edits at Wikipedia except a single one have only added links to stoictherapy.com. Taken as a whole, it appears your account is a WP:SPA, whose primary interest is directing traffic to that website.  — sbb (talk) 15:18, 13 December 2021 (UTC)

You're back to that? I'm zero-invested in that link, and the evidence is that I said I'm walking away from it, but you just persist. All I'm doing is defending in text so others can read it if need be that I am not as you accuse, so they can judge the incident for themselves. I'm sorry I replied here. — Preceding unsigned comment added by Sunartesis (talk • contribs) 15:46, 13 December 2021 (UTC)

Disambiguation link notification for January 3

Hi. Thank you for your recent edits. An automated process has detected that when you recently edited List of medical roots, suffixes and prefixes, you added a link pointing to the disambiguation page Celiac. Such links are usually incorrect, since a disambiguation page is merely a list of unrelated topics with similar titles. (Read the FAQ • Join us at the DPL WikiProject.)

It's OK to remove this message. Also, to stop receiving these messages, follow these opt-out instructions. Thanks, DPL bot (talk) 06:03, 3 January 2022 (UTC)

Naval Battle of Guadalcanal

Do you have a source for Naval Battle of Guadalcanal for the change of 50 to 56 5-inch guns? The Banner talk 21:55, 21 February 2022 (UTC)

@The Banner: The source of the counts is the info boxes for all of the destroyers listed in that section, and added up their 5" (127 mm) gun counts.  — sbb (talk) 00:12, 22 February 2022 (UTC)

WP:SYNTH?? The Banner talk 01:56, 22 February 2022 (UTC)
@The Banner: The difference is, IMO, can a simple database query produce the result? That is, if we pre-assume that WP:SHIPS were using Wikidata to store/retrieve the infobox values, can a series of Wikidata queries produce the quantity of 56 five-inch guns used in the Battle of Guadalcanal? The answer is yes: (WD Query:IJN Teruzuki:# 127mm guns) + (WD Query:IJN Amatsukaze:# 127mm guns) + ... = 56 5" (127mm) guns. But could a Wikidata query synthesize provable statements such as those in WP:SYNTH? No, it couldn't.
WP:SYNTH is meant to prohibit synthesis by combining material from multiple sources to reach or imply a conclusion not explicitly stated by any source. It is not meant to deny/revert my edit (backing up the editor by the IP editor, who I generally agree is problematic, but in this instance was correct) that merely makes WP articles internally self-consistent on a simple mathematical basis (that is, the sum of # of 5" guns brought to bear in the Naval Battle of Guadalcanal).
I propose this: either
  1. object to the entirety of listing # of guns in the Naval Battle of Guadalcanal article's multiple forces lists (on the basis of all of them being synthesis of the # of guns of various types summed from the infoboxes of the constituent ships' articles) (assuming such a listing isn't itself individually citeable by sources); or
  2. encourage and advocate for the WP internal self-consistency of such number-based lists.
 — sbb (talk) 21:45, 23 February 2022 (UTC)
I just go for WP:V and WP:RS. The Banner talk 21:51, 23 February 2022 (UTC)
@The Banner: I get it, and I do appreciate your point and vigilance. I agree, statements should be verifiable and reliably sourced. But on that basis, perhaps the entirety of the sublists quantifying # of guns in the battle should be challenged on WP:V and/or WP:RS grounds, not just individual edits changing numbers to be WP internally self-consistent.  — sbb (talk) 21:59, 23 February 2022 (UTC)
That sounds like a good idea. No sources, no mention. The Banner talk 23:33, 23 February 2022 (UTC)

If you aren't doing other changes, please don't just run around changing : indentation to math display=block

First, this causes churn for limited reader benefit and isn't necessarily a consensus choice on any particular page, but also math display=block has its own issues. It generates invalid and somewhat broken HTML unless you surround each instance by blank lines. It sometimes creates unnecessary phantom scroll bars in some browsers. It tries to fit next to floating images irrespective of formula width, sometimes causing the formula to not render entirely but need scrolling to view even on average-width windows. Etc.

If you are making a bunch of mathematical or other changes and you personally prefer math display=block, it's usually okay to make that change as long as you are willing to check to make sure that the results are good. But please don't just make mass changes across a large number of math pages that you aren't otherwise engaged with. It forces other people to come check and clean up after unless carefully done, and there's no consensus around forcing this change site wide. –jacobolus (t) 02:46, 15 June 2023 (UTC)

Hi. First and foremost, the reason I'm doing this is because colon-indent generates semantically invalid HTML5, by producing a description list (<dl></dl>) with a single <dd> without a preceding <dt>. That is invalid HTML5. That is my main reason for making those changes. Sitewise, officially:
  • Using colons to indent text isn't promoted in any MOS or help.
  • "Do not abuse block quotation markup to indent non-quotations. ... Avoid : (description list markup) for simple visual indentation in articles (common as it may be on talk pages). It causes accessibility problems and outputs invalid HTML." (MOS:INDENT)
  • "To display a mathematical formula or expression on its own line, it is recommended that <math display="block">... be used instead of :<math>...." (MOS:INDENTGAP)
I'm not aware of invalid or broken HTML generated by <math display="block">. I have noticed that blank lines in wikitext surrounding block math generates empty paragraph tags, but that can be solved by eliminating the blank wikitext lines. IMO that makes reading the wikitext slightly more difficult, but I'm not opposed to doing that to eliminate blank lines.
Regarding phantom scroll bars, I have seen that. And I sometimes see them when an equation image is not displayed block (that is, it's colon-indented). Sometimes my edits have made those phantom scroll bars go away, sometimes they don't.
I'll be happy to make other changes to maths articles as I edit. My changes to maths articles are almost never substantially for content (I am not a SME, just a maths hobbyist); they are usually more gnomish or mechanical, such as moving punctuation inside inline <math> (to prevent line breaks between the math and trailing punctuation); cleaning up or checking references match the style of refs used in the majority of the article; fixing ref errors; etc.
In order to make it easier for others to verify that that I haven't screwed up equations, if you'd like, I'll make ":"→<math display="block"> changes completely atomic in one commit (that is, merely a careful regex replacement, no other changes), followed by other gnomish edits. I'm absolutely more than happy to do that if it will help other editors be confident in my edits.
But IMO, replacing invalid HTML5 markup–generating wikitext with recommended best practice doesn't need consensus. And I'm going to continue WP:BOLDly fixing them.  — sbb (talk) 11:39, 15 June 2023 (UTC)
The colon indentation is in theory an abuse of definition lists, but it's also the main way Wikipedia math articles have been indenting block math since the beginning of Wikipedia and there are thousands of such articles, and it has been working pretty well all these years. There is no hurry to change them all, and trying to do so is more disruptive than helpful.
Again, if you are writing a new mathematical article, substantially rewriting an article, or making other large-scale changes, feel free to switch all of the indentation in an article. But please stop running around making script assisted edits to large numbers of separate articles.
Inre the need for adding extra blank lines around block math, user:jacobolus/math block example is a page explaining the issue and https://phabricator.wikimedia.org/T182041 is the relevant bug report. It was reported in 2017 and the developers don't seem to be in any particular hurry to fix such issues. –jacobolus (t) 14:53, 15 June 2023 (UTC)
The colon indentation is in theory an abuse of definition lists, C'mon, it's not theory. It's absolutely an abuse of <dd>.
but it's also the main way Wikipedia math articles have been indenting block math since the beginning of Wikipedia yep, and it's been wrong (but more or less accepted), and in the last few years, especially with WP generating HTML5, it's now invalid HTML, and won't be fixed by the parser, ever.
and there are thousands of such articles, and it has been working pretty well all these years. The journey of a thousand miles starts with small steps by committed editors.
Again, if you are writing a new mathematical article, substantially rewriting an article, or making other large-scale changes, feel free to switch all of the indentation in an article. But please stop running around making script assisted edits to large numbers of separate articles. To be clear, I am not making script-assisted edits. I'm using a regex find & manual replace in an external editor, to make sure I don't blanketly change a math block that has trailing text or manual equation number, etc.
Regarding the Phab report, I'm not okay with accepting garbage-in to the parser, in order to massage everything to maybe look right. I'm intent on improving the wikitext, and hopefully the bugs in the parser will be fixed. It appears that display="block" was added around 2104? 2015? I have faith they'll come around. But they specifically can't/won't change the parser to not produce lone <dd> tags. As such, colon-indent is simply bad input.
At any rate, respectfully, no, I don't intend to stop. As I said, I'm willing to spend more time on each one. And I'm willing to take any reasonable steps that you might suggest, but this is how I choose to spend my time improving WP. I'm doing acceptable work, completely IAW the MOS, literally fixing bad input to the parser.  — sbb (talk) 16:09, 15 June 2023 (UTC)
The articles that have been sitting using : indentation for 10+ years do not urgently need to be changed. Trying to do so at mass scale / rapid speed is disruptive. Please stop it.
If you keep going the way you are it generates a bunch of extra work for someone to clean up after for negligible benefit to readers. We can spin it up into a bigger fight at a higher political level I guess, and both waste dozens of hours on it.
But it seems like an incredibly pointless waste of time. I just went through a similar one on another bot-mimicking user who has now wasted thousands of hours of volunteer cleanup effort.
Yours isn't quite as awful as that, but is still very annoying. Can't you find some more productive crusade to fight somewhere else, instead of making a mess of Wikipedia math pages? –jacobolus (t) 16:29, 15 June 2023 (UTC)
If you really want to have this fight, please desist immediately from further script-assisted mass changes and start a conversation on Wikipedia:WikiProject Mathematics. Consider this like the "revert" stage of WP:BRD, except I don't want to run around reverting all of your changes and starting a literal edit war. –jacobolus (t) 16:31, 15 June 2023 (UTC)
Now you're insulting me. I have tried to be reasonable with you, and you are insisting I do what you say. And not only that, you spam my talk page with lots of serial messages, and continually slander me by saying I'm make "script-assisted mass changes", when I explicitly said I do not use a script to make my changes.
Do what you need to do, but bullying me around, and purposely mischaracterizing my edits to win points when you seem determined to escalate a non-issue, is dishonest. You are no longer welcome in my talk page. Goodbye.  — sbb (talk) 16:37, 15 June 2023 (UTC)
I consider some tuned regular expression find/replace to be a kind of a "script". What I mean is, you are not typing the changes one by one on your keyboard: a computer is doing the text change for you. I am not insulting, slandering, or bullying you. I am explaining what your edits feel like to me and asking you to please stop doing them because in my opinion they are disruptive. If you continue doing them instead of starting a conversation about it (I recommend Wikipedia:WikiProject Mathematics) I am going to start reverting your changes. If you prefer we can instead have a separate conversation about it on each article talk page. –jacobolus (t) 16:40, 15 June 2023 (UTC)
Don't be obtuse. There is no requirement to manually type every single edit. Hell, the Visual Editor has regex, search/replace. If you have ever copy/pasted text, sentences, or words, then you have violated your own standard, and your being hypocritical. J'accuse. I consider some tuned regular expression find/replace to be a kind of a "script". You can't define terms to suit your whims when doing so blatantly misrepresents the person you are arguing against.  — sbb (talk) 16:44, 15 June 2023 (UTC)
I am not saying there is a requirement to do any particular kind of edit. Bots and bot-like human editing (script-assisted, using regular expressions, etc.) are not forbidden and can be helpful. They just have a heightened risk of causing wider scale disruption than edits done one by one, and cause asymmetrical work for someone to clean up after.
I feel like you are intentionally not listening to what I am saying as part of some weird rhetorical strategy to misinterpret me so you can redirect the conversation. (Why you are doing this I can't really figure out.) The point is not the specific editing technology. The point is that you are making many changes to a large number of articles in short succession without individual intention directing each edit.
The articles in question have been sitting just fine for years if not decades and do not urgently need to be "fixed". The changes are not uncontroversial but need to be manually checked and fixed, which takes disproportionate amounts of time for whoever is going to come do the checking and fixing compared to the very small amount of time it takes you to make them.
It's creating busywork for someone else, for little or no tangible benefit. I don't really understand why you care about this? From what you have said the colon indentation does not personally cause you any problem. So you are just doing this as part of some kind of "everything must be proper" crusade. But causing distraction, annoyance, and extra work to other editors is its own cost which you should take into account. The trivial (if any) benefit here is not worth the cost.
Again, if you are working on a specific article and you want to change the indentation style as part of some larger set of changes, that's completely fine with me. In that case you'll be taking individual care with each formula, previewing them to make sure they render correctly, and the amount of work for someone to make corrective changes is proportionate to the the effort you are putting in on that article. There is plenty of room to have individual discussions about the indentation method on the article talk page, if it causes an issue. There's no issue with that. –jacobolus (t) 17:11, 15 June 2023 (UTC)
I feel like you are intentionally not listening to what I am saying as part of some weird rhetorical strategy to misinterpret me so you can redirect the conversation. (Why you are doing this I can't really figure out.) Right. Back. At. You. You haven't listened to me, at all.
The point is that you are making many changes to a large number of articles in short succession without individual intention directing each edit. And there's where you're wrong. I am not doing a global search/replace. I'm letting the search find "^: *<math", and individually, visually evaluating each instance that it can safely be replaced with <math display="block"> (such as not having trailing text, equations, refs, etc.).
So please don't tell me that I'm not listening to you, when you repeatedly mischaracterize what I'm doing, and then get insulted that I'm pushing back when you carelessly and dismissively mischaracterize what I'm doing.
As far as the rest of your last comment... I'm not going to justify my edits, where I choose to focus my efforts, to you. Stop asking me to defer to what you want. I was extremely patient, and offered to spend more making more edits that need to be made to articles, and you completely skipped over my olive branch, insisted I stop, and then went on to insult me, require me to justify what gets my attention. Just stop. Do what you need to do. I'm going to continue to edit where I think it's necessary. I will do my best to be extra careful, and try to add more value to each edit (or group of edits to make edits more atomic).
But beyond that, please, cease this discussion on my talk page. It's distracting, and it's just arguing. You do WP your way, I'll do it my way. Respectfully, we don't have anything else to say to each other on this matter, IMO. Peace.  — sbb (talk) 17:24, 15 June 2023 (UTC)
That's targeted reversion. Thanks for the heads up. I presume we're going to be meeting at ANI sooner rather than later. I'm not going to ask you for permission before I edit.  — sbb (talk) 16:46, 15 June 2023 (UTC)
Also, there's nothing stopping hobbyists from doing library-type research. Many if not most of the technical articles on this site were written by hobbyists. Hobbyists can learn anything that anyone else can learn, and don't let anyone tell you otherwise. The whole internet is at your fingertips, starting with the articles here and their citations. Pick a topic you care about, type whatever keywords seem relevant into Google scholar or some other citation index, and start skimming papers and navigating the citation tree. If you hit paywalls see if you can use Wikipedia:The Wikipedia Library for access. The Internet Archive, Google Books, and other sites have the full text of thousands of mathematical monographs, old journal volumes, etc. –jacobolus (t) 15:04, 15 June 2023 (UTC)

I created a topic at Wikipedia talk:WikiProject Mathematics § Should all math articles be immediately switched from : indentation to <math display=block>? where more editors can weigh in with their feedback. –jacobolus (t) 18:47, 15 June 2023 (UTC)

Red blobs

It's because you didn't wrap the math tag in your quote in nowiki tags, probably. --JBL (talk) 00:21, 17 June 2023 (UTC)

🤦🏼‍♂️🤦🏼‍♂️🤦🏼‍♂️ Dammit. thank you. I'm going crazy, and trying not to let myself fly off the handle. FFS, I'm a moron at time. Much appreciated.  — sbb (talk) 00:27, 17 June 2023 (UTC)
You're very welcome, happy to help :).
With respect to trying not to let myself fly off the handle: can I encourage you to disengage somewhat? You & jacobolus are clearly aggravating each other on a personal level a fair amount, so one of you needs to be the adult and step back from the personal back-and-forth. The conversation at WT:WPM is drawing in a sufficiently wide range of voices that I doubt it's necessary for you to be the main defender of your position. (As I said, I don't know enough about HTML to have an informed opinion on the technical question of how the world works -- but your argument seems a better account of how the world should work to me.) --JBL (talk) 00:37, 17 June 2023 (UTC)
(To be very concrete: I think that in your last two paragraphs in this edit, the text after "I'm not, nor ever have been, trying to disparage you." and before the numbered list is unnecessarily personalized, and that the world would be a better place if you forwent that part.) --JBL (talk) 00:46, 17 June 2023 (UTC)
You wisdom, advice, and counsel are all recognized, well-received, and appreciated. Thank you for the non-partisan calming tone. I should take my own direction and stop and breathe. Again, thank you.  — sbb (talk) 01:13, 17 June 2023 (UTC)

Concern regarding Draft:Bibliography of works about social democracy

Information icon Hello, Sbb. This is a bot-delivered message letting you know that Draft:Bibliography of works about social democracy, a page you created, has not been edited in at least 5 months. Drafts that have not been edited for six months may be deleted, so if you wish to retain the page, please edit it again or request that it be moved to your userspace.

If the page has already been deleted, you can request it be undeleted so you can continue working on it.

Thank you for your submission to Wikipedia. FireflyBot (talk) 03:01, 8 July 2023 (UTC)

Disambiguation link notification for September 3

An automated process has detected that when you recently edited Gaussian units, you added a link pointing to the disambiguation page Coulombs.

(Opt-out instructions.) --DPL bot (talk) 06:03, 3 September 2023 (UTC)

Thanks. Fixed from coulombs -> coulombs ([[coulombs]] -> [[coulomb]]s)  — sbb (talk) 15:45, 4 September 2023 (UTC)

f-stop template

Hi - I've just noticed your recent edits to {{f/}} - I'm not quite sure what's happened here but something quite weird is going on. In Firefox (both logged in and logged out) it shows up with some kind of offset, so that it renders 

    f/
the 2  lens

rather than 

the f/2 lens

However in Chrome it renders f/2 as normal, & the old version of the template rendered OK in Firefox. I don't suppose you have any idea what might be going on here & if there's an easy fix? Andrew Gray (talk) 22:38, 2 February 2024 (UTC)

Hmm. I've checked it against MacOS versions of Safari, Chrome, and Firefox, using this account, a new test account (no customizations of CSS, or changes to user preferences), and also logged-out. I've also tested it logged-out with Safari, Chrome, and Firefox on both iOS (iPhone) and iPadOS (iPad), and it displays as expected.
I haven't tested it on any Windows- or Linux-based browsers. Can you go to {{f//testcases}} and see if the examples that use {{f//sandbox}} (which correspondingly uses {{f//sandbox/styles.css}}, which currently doesn't have a −0.8 rem "squeeze" for the first character that {{f/}} does) show the same problem you're seeing?  — sbb (talk) 19:35, 3 February 2024 (UTC)
Also, what is your version of Firefox?  — sbb (talk) 19:40, 3 February 2024 (UTC)
Thankyou for investigating - how very mysterious! I am on FF 122.0 under Linux; I'll fire up a Windows machine in a minute and check that as well.
On Template:F//testcases on the current (122.0; Linux) browser the first three are OK, then {{F/|2.8}} and all the following ones break. For 2.8 the f/ is on the first line and the number is shown on the second; for 4–6.3 the f/4- is one one line and the 6.3 on another. The effect is identical for both {{f/}} & {{f//sandbox}} lines on each entry. Andrew Gray (talk) 13:11, 4 February 2024 (UTC)
And from the laptop (Windows 10, Firefox 122.0), exactly the same. First three OK, later ones all split over two lines. (I tested Edge on the Windows machine as well: everything looks fine there)
However! I have tried resizing the text. If I zoom in or out (90% sizing, 100% sizing) they instantly flip to the correct format in both cases. Returning the sizing to 100% and they stay correct. Refreshing the page (on any zoom level) and they go back to split. This happens on both machines (Linux & Windows). So something to do with how it's being originally loaded, that then gets fixed whenever the page is resized?
I'm completely baffled. Maybe something to write off as an odd anomaly and hope it goes away in future... Andrew Gray (talk) 13:23, 4 February 2024 (UTC)
I apologize. I'm doing some testing now, and I see what you're talking about in some places. For instance, in Depth of field § DOF scales, the captions for the lens closeup showing DoF scale are messed up, like you say.
My hunch is that the bounding box for, say, "f/11", is being generated too narrow, causing an unnecessary line-break in the bounding box for "f/11". I added a white-space: nowrap; to the <span> that wraps the entire "f/number" string. It looks like it fixed the problem in Firefox. Can you test on your end? Thanks.  — sbb (talk) 00:30, 11 February 2024 (UTC)
Hmmm... it's better, but not fixed. For instance, in the template's documentation, in the 2nd paragraph under Usage, it shows "f/4–5.6." with the final period (end of sentence) squeezed too far left, just in front of the "6". Looking into it...  — sbb (talk) 00:37, 11 February 2024 (UTC)

Let's move this discussion to the template's talk page, Template talk:f/ § Firefox bug

IP block exempt

I have granted your account an exemption from IP blocking for a period of 2 years. If you still need an IP block exemption after it expires please file a new request. This will allow you to edit the English Wikipedia through full blocks affecting your IP address when you are logged in.

Please read the page Wikipedia:IP block exemption carefully, especially the section on IP block exemption conditions. Inappropriate usage of this user right may result in revocation. I hope this will enhance your editing, and allow you to edit successfully and without disruption. DatGuyTalkContribs 10:49, 27 February 2024 (UTC)

Retrieved from "https://en.wikipedia.org/w/index.php?title=User_talk:Sbb/Archive_2&oldid=1210707122"