User talk:A876

Hello A876! Welcome to Wikipedia! Thank you for signing up. Here are some recommended guidelines to facilitate your involvement. Best of luck. Have fun! ---- ElectricEye 10:05, 12 April 2006 (UTC) Getting Started Wikipedia Tutorial How to edit a page The five pillars of Wikipedia Manual of Style Be bold in editing How to write a great article Getting your info out there Cite your sources Neutral Point of View Point of View Verifiability Uploading images Image use policy Getting more Wikipedia rules Policy Library Getting Help Where to ask a question Help Desk Getting along Wikiquette Civility Sign your posts Conflict resolution Getting technical Pages needing attention Peer review Utilities Village pump

Atomic bomb v. nuclear weapon

I agree that "atomic bomb" is a misnomer, but in some contexts it is common to refer to "nuclear weapons" as "atomic bombs" to indicate that they are fission-powered air-dropped devices. In referring to a country's early development of nuclear weapons it is quite commonplace. It also helps to break up the style in some places, where one is looking for more than one way to say "nuclear weapons". Anyway, I'm just putting that out there as considerations before you try to change all instances of "atomic bomb" to "nuclear weapon" -- I don't think it's always required, especially in referring to historical circumstances. In situations where it is ambiguous as to whether they are fission or fusion weapons, or the delivery method is ambiguous, I think "nuclear weapon" is always preferable, of course. --Fastfission 17:20, 24 June 2006 (UTC)

---

I caught myself. Changing all instances is not the way to go for this one. Looking at places where replacement was tempting, it just did not feel right. Most uses of "atomic bomb" really have to be left as they are.

They always told us that "atomic bomb" and "atomic energy" were unfortunate misnomers. Everything is made of atoms. Every object, tool, and weapon ever made uses the mechnical, electrical, chemical, and nuclear properties... of atoms. The word "atomic" is too general. Atoms consist of nuclei and electrons. Does "atomic energy", refer to interacting electrons or interacting nuclei? To properly name the special new tools and weapons that release energy from interacting nuclei, we have to call them "nuclear bomb" and "nuclear energy", they say.

But then why does everyone understand "atomic bomb", "atomic energy", "atomic decay", and "atom smasher"? These terms are quite unambiguous. When I say "atomic energy", no one will EVER think that I am talking about rubber bands, batteries, light bulbs, or gasoline. "Atomic" has long been synonymous with "nuclear" in these terms. "Nuclear" may be preferred, but "atomic" is an accepted alternate, not slang as some might suggest. The Atomic Energy Commission disappeared into the Nuclear Regulatory Commmission, but there is still an International Atomic Energy Agency.

In chemistry, "atom" and "nucleus" are close to interchangeable. An ion is a charged atom or molecule. A fully ionized atom is a bare nucleus, but it is still called an atom. Conversely, hydrogen ions are interchangably called protons.

To talk about the remaining energies or properties of materials (atoms) that are not nuclear, the term "molecular" covers most or all of them. (Molecules stretch, bend, burn, dissolve, fluoresce, etc.) A piece of metal is actually a macromolecule. Non-molecular atoms are actually not a common thing in chemistry. The "noble gases" are "monatomic" because they are nonreactive.

Historically, "atomic bomb" was what everyone called the thing as it emerged. It is in the old books, old movies, and our memories. "Atomic bomb", "atom bomb", or "A-bomb". It sounds smoother. Even if we want to call it a "nuclear bomb" or "nuclear weapon", we will always call it the "atomic bomb".

By The Way: "Nuclear" might be more correct than "atomic", but how did "bomb" get laundered into "weapon"? It's a perverted euphemism. Every "nuclear weapon" IS A BOMB. "Nuclear bomb" is an honest name. (As would be "Incinerator of Cities".) "Nuclear bomb" doesn't sound as smooth as "nuclear weapon". Maybe those who coined "nuclear weapon" were also considering how it sounded.

It seems like "forced correctness" to title the article "Nuclear weapon". ("Atomic bomb" outnumbers "Nuclear weapon", 11 million to 8 million hits on Google. "Nuclear bomb" has 4 million.) "Forced correctness" is not going to succeed in renaming the thing. (And the name is wrong anyway. We should follow the lead and rename the article "Nuclear bomb".)

And then there's the specificity of the historical "Atomic bomb" / "Hydrogen bomb" distinction. "A-bomb" referred to the initial fission bomb, since the days when it was the only nuclear bomb. The later fission-fusion "super" bomb was named "H-bomb" when it came along. The term "A-bomb" never refers to an H-bomb. But every H-bomb contains an A-bomb, so the A-bomb article can legitimately include the H-bomb. "Nuclear bomb" automatically refers to both "A-bomb" and "H-bomb". The ambiguity can be annoying or useful. -A876 23:41, 24 June 2006 (UTC)

Reverting 101

(this same thread is also assembled completely at User_talk:Deeptrivia#Reverting_101)

1) A revert of a major edit is NOT a minor edit. (Rupee: history)

2) A revert needs an EXPLANATION. Your revert was right, I got it wrong. The edit which I reverted was not explained correctly. He really did add the template, not just suggest it as his edit note implied. (The templates are kind of tiny, which should be another problem to address on Wikipedia.) Was it really that hard to type in that the previous changes DID add the template? Reverting anyone's edit or revert, within one minute of the edit, with NO explanation, makes you look like a "revert-bot" or a sock-puppet of the previous editor. Just as you left me to figure out why my inept edit deserved to be reverted, likewise you have left anyone after us to figure out the same. --A876 01:48, 3 July 2006 (UTC)

Hey, A876, sorry for the inconvenience. I do use an automated revert tool that marks a revert as a minor edit, and doesn't allow writing a custom made summary. I think your suggestion are quite useful, and I'll pass them on to the person who made the tool. Meanwhile, it's great that you figured out that the revert was indeed useful. The template is quite handy because it provides a uniform access to and from all Rupee related articles. Please feel free to improve the template in any way you can. Regards, deeptrivia (talk) 01:57, 3 July 2006 (UTC)

Thanks. I made other subtler tweaks on "Rupee"; let's see if they help.

I also adjusted Category:Rupee some, all formatting changes. I think I changed this category box for the better.

I have caught a gross problem that seems to affect most or all category boxes, having smaller print than the main article and italic instead of bold, thereby REDUCING visibility of the linked related topics that they are supposed to highlight.

If my style changes to that category box are for the better, then I would hope that the differences will get copied to other category pages. Sadly, I think the opposite will happen. My changed box is outnumbered by other boxes, so it is very likely that someone will come through and, in the name of Consistency (god), will restore the category page to small-print unreadability, not thinking of the drawbacks. I would look for a way to Meta-fix the category boxes, but sadly they are not using only template features. Every (?) category box seems to have font size specified within it, a very wrong thing. --A876 02:45, 3 July 2006 (UTC)

Template:Rupee

Hello,

I don't understand why you changed the Template:Rupee. The reason I set that to 90% was because there are other currency navigation template like Template:AsianCurrencies, which includes more that that Template:Rupee includes. Therefore, 90% would be better. I'm trying really hard to make sure that things are consistent. So whatever change we decide here, it must be applied to these templates as well:

• {{AfricanCurrencies}}
• {{AsianCurrencies}}
• {{AmericanCurrencies}}
• {{EuropeanCurrencies}}
• {{PreEuroCurrencies}}
• {{Crown}}

--Chochopk 09:00, 3 July 2006 (UTC)

---

Hmm. Thanks for not slamming it back. To re-state the case all in one place (as if anyone else is looking):

My edit description for that change was:

de-center and add "See also" heading for article "History of the rupee"; upsize (small print is not fair); bold the section headings (like any other article)

And here are my (edited) notes, originally an aside to a different issue:

I have caught a problem that seems to affect most or all category boxes. Surprisingly, many category boxes seem to have smaller print than the main article. Is that a benefit? Section headings within these boxes are merely Italic, instead of Bold, as they are in article. Overall, I think that some category box stylings are REDUCING the visibility of the content (links to categorically related articles) that they are supposed to highlight. Links that seemed visible outside the box become invisible inside the box. I think the reduced size and altered font style are a big part of the problem.

If the changes I made to that category box really are for the better, then I would hope that the differences will get copied to other category pages. Sadly, I think the opposite will happen. My changed box is outnumbered by other boxes, so it is very likely that someone will come through and, in the name of Consistency (god), will restore the category page to small-print unreadability, not thinking of the drawbacks. I would look for a way to Meta-fix the category boxes, but sadly the templates are not using only template features. Every (?) category box seems to have font size specified within it, which is not the way things are supposed to work.

Centering also makes things hard to read -- or to find! I did not systematically address centering; I only removed it where it seemed to be making a problem.

As we both mentioned, related boxes ARE affected by a change to this box. I didn't want to just go hunt down every category box and edit it. Creating this difference and then discussing it gives a chance for a resolution. Consistency is nice, but clearly you are thinking about more than just consistency. (There's nothing like a negative expectation to bring out the best in people.)

After these boxes are decided, if we decide to revise them as a set, then this little box-altering meme will want to spread to all the other category boxes, won't it?

So there's another reason to be cautious, as this box styling gets to be a Wikipedia Style issue. We should find the guidelines that affect category boxes, or else create them, or else correct what's there, if they forgot to address little old READABILITY.

90% font, with the browser and fonts that I use, works out to 86% height. (Height of "o" goes from 7 pixels to 6 pixels.)

These boxes seem to be a bit too technical, with all the cryptic HTML-like mark-up (WikiML?) for tables and the like. I don't know how or when that happened. It's taking the edit process away from the editors. If category boxes are important, I'd think that they would be easier to edit. Maybe they should be lower-tech, resulting in a format looking more like a regular page -- Category box would act more like a simple "include" of text with the usual formatting.

I also notice, when comparing the "Category:Hogwarts" page and the "Hogwarts" page (for example), that there is often awkwardness or ambiguity or lack of linkage or even diparate content. I'm not sure that these are working as they should.

Eventually I might try to adjust such things on Wikipedia. It takes a little more research on the topics, which takes a litte more to,e than tweaks incidental to browsing or browsing incidental to tweaking. So I need a time when I can focus.

I find it painful navigating the Wiki Help and Guides pages -- they seem not to be in the regular like normal pages AND they seem to have no search function of their own. Even "Meta" does not seem to be Meta enough. Everything in Help must be navigated to by the use of links and Ctrl+F (the browser's "Find on page" command).

Getting back to the issue at-hand, what are your thoughts? Is my hack more legible and reasonable to use? Is it better or righter?

If you want to propagate it to see what happens (someone else will surely question it), go ahead. I have edited some category pages, hence my wondering if they are styled correctly, but I am not watching any collections of category pages for consistency. If you are suggesting that I should edit the related pages you listed, I would be happy to edit them myself as well.

--A876 01:27, 4 July 2006 (UTC)

---

I can understand your concerns about readability. So let's lay down the concerns one by one

• font size
• font for sub group (i.e. current v.s. defunct)
• center or not

(if I miss some your points, please remind me again)

So let's see other navigational boxes on some other subjects

{{EU countries and candidates}}

It in turns calls {{Navbox}}, which specifies font-size: 90%; and appears to be centered as it renderes on my browser. {{Navbox}} is used by 802 other templates.

{{USPoliticalDivisions}}

{{Polygons}}

They are also 90%, center, but do not use {{Navbox}}. They are built from ground up.

{{United States topics}}

This one is a little out of the norm. The font is <small>, and it looks smaller than 90% on my browser.

{{Philosophy topics}}

91% font, wierd choice. Whether or not this box is centered is not meaningful, as it is always 100% of available space, even if I enlarge my browser to more thab 2800 pixel wide.

{{tl|Star Wars]]

<small> again, with bolded categories on the left.

There are more at Wikipedia:Navigational_templates.

So going back to the points above

• font size

I guess 90% is the common ground, as it is used by {{Navbox}} and is copied to many other directly-built boxes

• font for sub group (i.e. current v.s. defunct)

I now agree that we should use bold

• center or not

Most are centered. I still don't know what kind of problem it causes on your computer. =P

We can either use {{Navbox}} (with table in table), or to write up the style directly. I have to try both to make a better decision. --Chochopk 02:47, 4 July 2006 (UTC)

---

- Font Style for subgroups within category box: Bold is the trend and we both like it. More important, the reason, it reads better. And it's more consistent with the section titles in regular articles. Let's go for it. In any templates where we happen to notice it, let's change Italic subgroups to Bold.

- Font Size: 90% seems the common size (but not constant). If it is the common size, then the common size is wrong. It shouldn't be so surprising. The font is undersized where it needs to be clear. Maybe some Wikipedia guideline should prescribe 100% as the minimum font size. I need a little more thought to take an exact stand on this. I have had 20/13 eyesight, but my focus is just starting to change. When I see "fine print" on a web page, I can't help but ask why. Someone was being too clever. Let's go look at a paper encyclopedia or two, just to see how they handle font size in inset boxes and photo captions. In these Category boxes, i find that the Title is too small, the entries are too small, and the subgroup titles are too small! In small fonts, Italic and Bold blur the letters more than they do at larger fonts. I notice that in some of the examples you posted, the subgroup title is deliberately made larger than the the contents of the subgroup, presumably also in keeping with the regular article format that automatically makes section titles larger.

So next some thought or research, and then maybe i'll try to carefully change that template. Maybe try "sandbox" like they suggest.

In spite of the warnings there, there are several "oops" corrections in its history. The warning says "This template employs some extremely complicated and esoteric features of template syntax. Please do not attempt to alter it unless you are certain that you understand the setup and are prepared to repair any consequent collateral damage if the results are unexpected. ..." The template is even more gruesome than the Category pages that use it! Why does such crazy coding and unnecessary fiddling with format have any place on Wikipedia?

- Centering: I guess I was a little vague. All of the boxes are centered. (100%-width boxes are by definition left-justified, right-justified AND centered, regardless of which alignment is requested.) Centering seems to be what one does with boxes. I hadn't thought much about the centering OF the box. Maybe it's okay. Centering of subgroup names within their little invisible cells can be problematic. The worst thing, which made me go in and de-center something, is when there is a single item in a list and that list is centered. The closest example is in the "The Star Wars Saga" box. The subgroup "Spin-off films:" -- then way, way, way, way, way over is that listed item, "The Star Wars Holiday Special". (Actually that box is an especially bad example of a box. Some subgroups are one row and some are two rows. The lists are vertically centered, so that a two-row list includes items that are above and below the subgroup title.) How do I know what goes with what?? It's not user-friendly or reader-friendly. It has an oppressive feel that makes me look away. Some of the other examples show attractive styling and some show good usability.

--A876 05:49, 4 July 2006 (UTC)

---

I will spend some time on fixing the other boxes, maybe tomorrow. I am just so occupied with other stuff about currencies. It's not easy to manage 170 some currencies. As you can see, consistency is important to me. Once I start doing it, I might find myself modifying the polygon template!

It's good that we resolve this in a non-Wikipedia fashion (revert war) =). About the font size, have you thought about enlarging it with your browser setting? I do make use of that feature from time to time. --Chochopk 06:08, 4 July 2006 (UTC)

And yes, I agree with you. The Star Wars box is stupid. --Chochopk 06:09, 4 July 2006 (UTC)

your edits at coroutine

((moved to Talk:Coroutine)) --A876 06:10, 18 July 2006 (UTC)

Cat renames

I see you renaming cats by hand and saying it is a pain. Yes it is. If you go to the WP:CFD page and request the name change properly, you'll see that bots will happily do it. What you are doing would likely be a Speedy Rename request. — RevRagnarok ^{Talk Contrib} 14:26, 18 April 2007 (UTC)

Triiodide

Thanks for your significant contribution to triiodide. One aspect to strive for in future edits of this nature is a reference, preferably to a textbook or a review. As you will discover, WE-chem relies heavily on citations. --Smokefoot 11:31, 11 September 2007 (UTC)

(Please put a link on "WE-chem" -- I have no idea what it is, and no idea where to look for it.)

The references will of course bear me out. :) We all hope for a better place. It is so hard to get basic things right. I generally re-assemble what's there, in hopes of making it meaningful to whoever reads it for the first time. I edited what bothered me the most, which was lack of structure and lack of meaning. Lack of references didn't bother me that much. Anyone should know these things. Putting in good references is not MY thing. Trying to edit it well enough that people won't be tempted to unravel it is my thing. And it is depleting. I'm stuck on quality, not quantity. I can't leave the edit until i've fixed whatever i could in that article and usually a few related articles. Hopefully i've made the article worthy of someone's effort who is able to add references.

Want solid references from the get-go, try the site started by the founder of Wikipedia when he gave up(?) on Wikipedia: Citizendium. Too strict, surely slow to fill in. Probably even more pompous. Someday i'll have to go see how it's doing...

My idea of a clever reference would be to cite Answers.com, which usually merely caches Wikipedia! And for pure unattributed plagiarism, it's hard to beat Wikipedia. -A876 09:29, 14 September 2007 (UTC)

AfD nomination of List of oxymora

An editor has nominated List of oxymora, an article on which you have worked or that you created, for deletion. We appreciate your contributions, but the nominator doesn't believe that the article satisfies Wikipedia's criteria for inclusion and has explained why in his/her nomination (see also "What Wikipedia is not").

Your opinions on whether the article meets inclusion criteria and what should be done with the article are welcome; please participate in the discussion by adding your comments at Wikipedia:Articles for deletion/List of oxymora (2nd nomination) and please be sure to sign your comments with four tildes (~~~~).

You may also edit the article during the discussion to improve it but should not remove the articles for deletion template from the top of the article; such removal will not end the deletion debate. Thank you. BJBot (talk) 06:29, 8 January 2008 (UTC)

It was fun to start editing on an "insignificant" article like that. I was a little irked by the deletion but, looking back, I agree with it. [List of oxymora] was a funny research project; a collection (or competition) trivia and jokes. Entries were too trivial to source. Wikipedia should not host that kind of content. Maybe Wiktionary could, if they seriously consider that aspect of language. Wikipedia could link to a good list, funny or scholarly. -A876 (talk) 23:20, 7 November 2021 (UTC)

Wow you can proof read

I saw you fly through self replicating machines, you are like a proofreading machine. I was convinced you were a bot until I saw more of your edit history. You are amazing, keep it up! Bobprime (talk) 05:17, 27 February 2008 (UTC)

I started with a search for pages that link to a redirect page for a specific misspelling or variant spelling. (The misspelling had its own redirect page.) (Bypassing redirects is not so important, but i thought the misspell was.)

Whenever I am editing, I usually check some or all links (so many links are a little off), and take some notice of spelling, spacing, punctuation, grammar, style, and other "lint" as I read. (Wikipedia is almost fun for those of us who typically read with a pen in hand.)

Spelling check is very easy if you use Mozilla Firefox or similar web browser -- it includes an automatic built-in spell-checker for all form fields. Just scan for red underlines. -A876 (talk) 16:58, 27 February 2008 (UTC)

I think everyone has since-then discovered the spell-checker in their web browsers' text editors. -A876 (talk) 23:20, 7 November 2021 (UTC)

Oh, What A Merry Spring-like Day!

Happy First Day of Spring!

A Beautiful Cherry Tree in Spring Bloom

Theres nothing like seeing a field full of spring flowers.

Just wishing you a wonderful First Day of Spring {{subst:CURRENTYEAR}}! ~~~~

If you live in the Southern Hemisphere and are entering the season of Autumn not Spring then I wish you a happy First Day of Autumn {{subst:CURRENTYEAR}}!
To spread this message to others, add {{subst:First Day Of Spring}} to their talk page with a friendly message.

--Cinemaniac (talk • contribs • critique) 03:07, 21 March 2008 (UTC)

Peter Schickele

geez dude, the hostility in your change comment is palpable, and there's really no call for that. at any rate, 1) thanks for the spelling correction. 2) technically, yes, baroque is more correct than the general term classical when referring to an era. however, i'm sure you know that an argument can be made both ways when referring to the genre. particularly since not all--most, but not all-- of Schickele's work is in the manner of the baroque. but since quibbling over the differences in nuance is fruitless, have it your way. 3) i'm very well aware of the template {{birthdate and age}}. however, its use in the header is inappropriate and does not comply with wp:mos. it has been removed. cheers! --emerson7 03:49, 27 March 2008 (UTC)

i've had a bad week, month etc. you do good edits generally (i forgot to mention), so your changes there were puzzling -- it looked like three random bullets were fired, and then described as "copyediting; cleanup". bad edits irk me; "random" deletions irk me; dis-explained edits irk me. 1) using Firefox, new spellings are underlined (a great feature), so i just scan for red sometimes. i used to be amazed how many typos i spotted; now i'm amazed how many typos i don't spot myself. 2) the article needed a mention of baroque somewhere (the word was totally absent). i admit i was a little nervous changing it to read "parodies of baroque and classical music", because of the "overlap" (unofficially and officially, "classical" includes baroque, classical, romantic, ... . "Classical Music" radio stations play renaissance.). i'm angry at having to edit defensively -- anticipating how others will misconstrue and mess things up. my afterthought, for when someone else deletes "baroque" again, is to cite a review, quoted on one of his older album covers, where some reviewer helpfully said that PDQ "should set the baroque back another hundred years", or something like that. (cannot find the quote.) 3) sorry i did not research that template. i'm embarrassed to beat you up for something you did right. glad you fixed it again, but now i hate the description "cleanup; per mos guidelines". i hate any description that cites WP:MOS (not "mos") -- as if i'm going to go read MOS and bow down to it. the template is actually mentioned at Wikipedia:Manual of Style (dates and numbers), saying that {{birth date and age}} should be used "In[side] biographical infobox templates", but there is no mention of where they should NOT be used. Template:Birth_date_and_age is no help either. you're probably right that the template does NOT belong in article bodies (not "headers"), but someone should try to get that notion or fact documented, so that others are less likely to go putting that template where it doesn't belong. -A876 (talk)

Edits to High-Definition Multimedia Interface

As you have been around Wikipedia for 2 years, I shouldn't have to remind you of the WP:OR rule or WP:CRITICISM as your 1am edit to High-Definition Multimedia Interface seemed to ignore. Also though it is not a topic for discussion on wikipedia, I'll say that the issue you noticed with your particular equipment has nothing to do with HDMI interface but on the implementation by the HDTV maker or video card makers. There are many, many Media Center PCs are hooked up to a HDMI monitors without experiencing your pervasive "problem". Samsung for example is notorious for screwing this up.

Cheers though and I hope you fix this. The underscan at the videocard trick that you mentioned is the crappy way to fix it. -- KelleyCook (talk) 21:02, 28 March 2008 (UTC)

Grandee

Grandee (New Model Army) is a perfectly good redirect. There was no reason to change it to Grandee. Next time please check the redirect to see if the section name has changed. In this case it had been changed in the article from "New Model Army" to "English 'Grandee' & New Model Army" so the redirect just redirected to the top of the Grandee article. I changed the section heading back to "New Model Army" so that the redirect works. If the new section name was better and should be left in the article, then one can either fix it by altering the section part of the redirect, or by adding the original section back in as a hidden section header using the section template: {{section|New Model Army}}. -- PBS (talk) 11:17, 27 May 2010 (UTC)

I'll look more carefully next time. I noticed that under Grandee, you commented the section heading "New Model Army" so that people are less likely to rename it (which would break the links to it). The article I edited (Instrument of Government) has gotten more attention, from several editors, since then. Just now, it occurred to me to change [[Grandee (New Model Army)|Grandee]]s, this time to [[Grandee#New Model Army|Grandee]]s. I think a direct link to a subsection makes the intent more obvious than the former (a link to a redirect to a subsection). (The destination shows when hovering over the link.) - A876 (talk) 16:04, 27 May 2010 (UTC)

Photon

Photon is an WP:FA and not a WP:Sandbox. Thus choose your words and references well. Microwave doesn't cover 440 GHz and above (mostly called sub-millimeter range or alike). "All electromagnetic radiation consists of photons" is a strong rhetoric claim which needs multiple reliable secondary sources. Low-frequency ranges are usually treated as waves, not photons, as far as I know. Materialscientist (talk) 05:43, 29 June 2011 (UTC)

Irks

I don't buy the "is"ness of things. "Do you know who I AMMMMM?" Oh my, that article "is" now a Sacred Cow. Don't dare add anything. Chilling Effect, anyone? The article is now a defended magic wall that bounces away everything that hits it? Nothing sticks unless it's perfect?? That's not the way. Maybe check into Citizendium, where "is"ness reigns supreme, and there is no content.

I wrote what I (correctly) knew to be true. I know your 20-plus-edit-per-hour watchdogging helps, but not always. You treated me as a vandal. If you knew it to be true, you could leave it alone, thin it out, or (shudder) improve upon it. Or move it down to a more suitable section of the article. What, no time? AHEM. Oh, and there is also an "unsourced" tag. But i suppose those are too ugly to put on a Sacred Cow page.

I thought it a significant addition. Maybe I can look forward to a Discussion where admitted non-experts express opinions anyway, on whether it is "noteworthy".

"(Undid revision 436795973 by A876 grammar, weasels - duibious and unsourced statement)". Oh my terrible grammar. I went back to change my typo of "is" to "are", and found already an instant edit conflict. I didn't zing on your mis-spelling (typo) of dubious. Did my grammar "profile" me as a vandal, like bad spelling on a package indicates higher likelihood of a package bomb? The true statement was un-sourced. One does not need expertise to revert everything that is "unsourced" - I could hire a drop-out to sit and do that. Especially when an expert knows that the statement is correct.

"(rvt: not microwave, but sub-millimeter; no source for "all electromagnetic radiation consists of photons." - low-frequency ranges are usually treated as waves)". Well, the cite says "microwave", and "sub-millimeter" is a red-link. What of that? And, "... usually treated as waves" – of course, and x-rays are "usually" treated as particles. But polarization and reflection of x-rays have been demonstrated, as well as microwave photons. Wave–particle duality goes all the way. (But you know that.) Maybe i need to go vandalize over there. Wave–particle duality has not [yet] been tagged a Sacred Cow. – A876 (talk) 06:23, 29 June 2011 (UTC)

I keep you not as a vandal, but as a specialist, and thus require focus, factual accuracy, and proper referencing. This was lacking, which is why I didn't correct your typos and didn't move that sentence down where it belongs. To me, duality is mere philosophy and convenience of theoretical treatment. I personally see no use in the concept of photon in the radio range and below where discrete transitions vanish in almost any matter. Detection of single low-energy photons is a separate and interesting topic, but it is extremely difficult in any foreseeable future even for the microwave range, AFAIK. Thus I disagree with you, but am keen to learn and change my mind, not because "you know it's true" but because reliable sources said so. Neither your reference nor the irks above help me with that. Regards. Materialscientist (talk) 06:44, 29 June 2011 (UTC)

Edit war

A876 and Materialscientist - you probably know that you have both been edit warring at Photon, and engaging in aggressive and personal philosophical debates in the edit comments and user talk pages. Please, both of you, take 24 hours to calm down, then come back to Talk:Photon to discuss whether the proposed sentence is useful and appropriate for readers.

(When a war is brewing, make proposals but let others edit.) --Hroðulf (or Hrothulf) (Talk) 10:39, 29 June 2011 (UTC)

next thoughts

Yup, that's what happened. (As i sheepishly conceal the smoking guns.) I appreciate the sentiment.

Welcome to Wikipedia,

the free encyclopedia that anyone can edit.

Every so often I am forced to question whether that ever meant what it says.

If every edit triggers a REVERT-BOT, then no one can actually edit! The pretense of openness becomes absurd. Why not just lock the knighted page forever? Or change the publishing model such that edits do not become viewable until the resident reviewer(s) decide whether the flavor is right? Naturally that would restructure Wikipedia as a bureaucratic pyramid whose primary function is deciding WHO gets to decree what is truth. (Citizendium? Congress? IUPAC? One has to wonder how hierarchies get things done. And then consensus is an even scarier notion.)

If every article has an OWNER, likewise, just take away those "edit" tags for everyone else as soon as possible, because they are a big lie. I have seen an edit tweaking my edit, just to put the self-appointed-mayor's stink on it, with an edit comment like "... , but I'll allow it". Really? As if every edit is a humble plea for his comment and consent, or tentative assent? Every alternate edit of that article was by the same pompous ass.

An editor could assume good faith on the part of another editor who adds content (other than replacing paragraphs with "pisssssssssssssssssssssssssss").

Wrong grammar? Fix it.
Lacks citation? Add a citation, or tag it.
"Weasel words"? Correct it or tag it. Else what are those tags for?
Added to the wrong article? Move it. Who exempted you from responsibility?
Assume that Undo and Erase are usually the wrong buttons to press -- they destroy. Use with caution! Edits deserve explanation (which is why we hate unexplained edits). Undo is the harshest edit of all. If used, it needs a sound rationale, concisely spelled out.

But there are some who blithely break out the Eraser, the Annihilator, the Stark Fist of Removal, whatever you want to call it. We enjoy their work about as much as a bear enjoys a beartrap, or a Cambodian farmer enjoys a landmine. It can ruin your whole day.

I can imagine that some day this Project might start to be "complete" -- having reached the point where no edit can be of benefit; where no edit can do anything but subtract from the perfection that is Wikipedia. Then they can turn off all this problematic "input" stuff, set the data servers to read-only, throw away the keys, and stop collecting money. But that day is far off, by any estimate.

I do a lot of reading and a little bit of writing. At times i wish for a better interactive editing tool. I encounter many small defects, but often don't edit them until they exceed a threshold of annoyance. I'm a gentler editor. I rephrase locally, with varying scope. I've re-shuffled, re-ordered, sometimes at the top level. Deletion is usually a consequence of de-duplication. Even when de-duplicating, consolidation usually makes a better result than pure deletion. Glaring omissions are one kind of problem that can exceed my threshold. Sometimes I've been "lazy". I spot the missing aspect, and i put in just a hint of it, lacking time and/or hoping that someone will flesh it out. Sometimes i do the work, sometimes someone else. Either way the result has been enjoyable. And I'm sure I've fleshed out some skeletons placed by others.

RF photons are significant, otherwise they would not make exciting news stories. They are a triumph of science, if not a Triumph of Science. Someone predicted them. Someone went looking for them. And someone devised equipment that detected them. This is on a par with the latest Schmiggs Bozon in the particle zoo. Hardly anyone has any use for such knowledge. But it adds to the knowledge of [the current model of] reality. Every polarizable, reflectable, refractable, long radio wave passing by can be detected as fluxions of voltage and/or electrical field strength, but they can also be [potentially] detected as a huge number of extremely weak particles. There might be a place for mention of this, if it isn't there already. Your mention of waves tipped me closer to the grouping this idea with wave-particle duality. Although looking now at the introductory sentence, i see "a photon is ... the basic unit of light and all other forms of electromagnetic radiation." That's the notion i was trying to emphasize using the extreme example. One big problem with that opening sentence is that the "wave" also wants to be the basic unit of all forms of electromagnetic radiation. Or, as you pointed out: x-rays (polarizable though they may be) are typically observed only as particles, while radio waves (particle-countable though they may be) are almost exclusively observed as waves. Is that in the article? Also, must mention: looking at Featured Article statistics, i notice that some are occasionally demoted. Is that due to article degradation by poor editing, or just a shift of relevance?

The latter does not apply. The former is usually the reason - articles get cluttered with unsourced statements. When freshly spotted, they can be removed. What happens later is our copyeditors integrate the added statements without checking their relevance. After some time it becomes hard to understand what was added when. Materialscientist (talk) 04:33, 30 June 2011 (UTC)

I personally don't see the significance or notability of anything to do with professional and amateur sports. Maybe there should be an independent Wiki for trivia. And maybe a separate Wiki for literature and all works of fiction, poetry, songs, abstract art. And so on. But historical people are encyclopedic. They're often famous because of their fiction, "Great" or otherwise. Sports links at least to sports medicine and architecture. It all fits together. So i leave it as it is. I don't start deleting articles.

I need a new Wikipedia name. The current one started as a bad ironic joke, that happened to be available. I failed to anticipate my sustained interest in Wikipedia. I think it might prejudice people. I almost wish for a random anonymous alias generator, that would issue an unused alias similar to a license plate, alphabetic prefix plus a sequential or keyed number, like THX1138 or Anon66139269. Names I think of are mostly illegal (e.g., RevertBot), too ironic (PageScrambler, PackOfLies, RevertBot), or too likely to be taken (SomeRandomGuy). I'm not in SCA, so i don't have a Renaissance alias ... --A876 (talk) 04:17, 30 June 2011 (UTC)

See WP:UNC. Materialscientist (talk) 04:33, 30 June 2011 (UTC)

(Belated thanks. I did so.) - A876 (talk) 16:46, 11 June 2019 (UTC)

Refactoring others' talk page comments

You are welcome to comment again at Talk:Conventional PCI, but please don't change the text of other peoples' comments, even for spelling and grammar errors. Jasper Deng (talk) 19:07, 20 December 2011 (UTC)

But you reverted MY comment in the process! THAT did NOT have to happen! What is wrong with you? You call my action rude, but yours is unacceptable! Or maybe you don't know how to edit. A876 (talk) 20:46, 20 December 2011 (UTC)

WP:AGF, please. It's a rule, don't change others' comments. Simple as that. I reverted your comment in the process simply because you decided that it was OK to change someone else's comment.Jasper Deng (talk) 21:25, 20 December 2011 (UTC)

AGF? You confessed right here that you reverted my comment because I edited someone else's comments! You zinged me to pay me back in kind! (Seriously changed my comment, so I can see how it feels.) Please don't do things like that!

Aside from deleting my comment, I don't like what you did. You saw something you did not like, and you reverted it. If my effort was useless, your effort (restoring obvious typos) was far more worthless, and antagonistic. Who assigned the mission to undo such a harmless thing when it happens?

Yes it is "a rule", and it's not as simple as that. I did not break the intent of the rule. Never change meaning. Don't make adjustments that you wouldn't appreciate yourself.

from WP:TALKNO:

Behavior that is unacceptable

Please note that some of the following are of sufficient importance to be official Wikipedia policy. Violations (and especially repeated violations) may lead to the offender being blocked or banned from editing Wikipedia. [...]

• Do not misrepresent other people: The record should accurately show significant exchanges that took place, and in the right context. This usually means: [...]
  • Generally, do not alter others' comments, including signatures. Exceptions are described in the next section. [...]

Editing comments

Others' comments

It is not necessary to bring talk pages to publishing standards, so there is no need to correct typing or spelling errors, grammar, etc. It tends to irritate the users whose comments you are correcting. The basic rule—with some specific exceptions outlined below—is that you should not edit or delete the comments of other editors without their permission. [...]

Editing—or even removing—others' comments is sometimes allowed. But you should exercise caution in doing so, and normally stop if there is any objection. Some examples of appropriately editing others' comments: [...]

• Fixing format errors that render material difficult to read. In this case, restrict the edits to formatting changes only and preserve the content as much as possible. Examples include fixing indentation levels, removing bullets from discussions that are not consensus polls or requests for comment (RfC), using <nowiki> and other technical markup to fix code samples, and providing wikilinks if it helps in better navigation. [...]
• Disambiguating or fixing links, if the linked-to page has moved, [...]

I found the term for pointless reversion (plus optional abuse) on a technicality: Wikilawyering! -A876 (talk) 19:22, 14 August 2012 (UTC)

Disambiguation link notification for August 21, 2012

Hi. When you recently edited Rampuri, you added a link pointing to the disambiguation page Thug (check to confirm | fix with Dab solver). Such links are almost always unintended, since a disambiguation page is merely a list of "Did you mean..." article 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) 12:19, 21 August 2012 (UTC)

It was intentional. The article used "thug" in the modern generic sense. The disambiguation page Thug seemed appropriate, because it defines "thug" as a specific kind of criminal, while also mentioning "Thug", as in the long-gone Indian Thuggee cult of killers. Maybe I could bypass disambiguation and link "thug" to to criminal, but then the linkage to the older Indian term "Thug" is lost. So I'm not going to change it. Also I am about to make the same link on another page.-A876 (talk) 21:20, 21 August 2012 (UTC)

Disambiguation link notification for October 20

Hi. Thank you for your recent edits. Wikipedia appreciates your help. We noticed though that when you edited Pigging, you added a link pointing to the disambiguation page Roundness (check to confirm | fix with Dab solver). Such links are almost always unintended, since a disambiguation page is merely a list of "Did you mean..." article 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) 12:04, 20 October 2012 (UTC)

For the record, I intended to link to an article on geometrical roundness or unroundness or out-of-roundness, but no such article exists. I though there was some numerical measure of how round or unround something is. In general, a number that expresses how different the curve is from a best-fit circle. (The details being, how do you define the best-fit circle, and how do you quantify deviation?) A simpler version of roundness might be to find the best-fit ellipse, and divide the minor axis by the major axis. A circle gets a value of 1; all other ellipses have lower numbers. -A876 (talk) 19:26, 22 October 2012 (UTC)

Robot, you were right. On the disambiguation page, Roundness (object) is close to what I wanted, while the other choices are way off. Initially I didn't like "Roundness (object)" because of its intro ("Roundness is the measure of the sharpness of a particle's edges and corners."). It seems to overlook that an out-of-round pipe (for example) could be a perfect ellipse, which has no corners (unless the two apices count as two corners). Also, the article ellipse mentions the article I initially wanted, one that addresses unroundness of ellipses: Eccentricity (mathematics). So I made "Roundness (object)" and "Eccentricity (mathematics)" mention each other under "See also". -A876 (talk) 20:14, 22 October 2012 (UTC)

Tripropylene is wrong?

A long time ago, you wrote an article on propene trimer, aka tripropylene. I suspect that the article is mostly incorrect, that this material is in fact the trimer of propylene, not what is represented. But maybe you as originator can provide some insights. --Smokefoot (talk) 17:29, 9 February 2014 (UTC)

"The three trimers of propene", all nonanes. (Are there three?) (Should these be nonenes?)

Thanks for reporting the change. I did NOT make this up (at least not unabetted). I was inspired by someone's image of three trimers, plus other confirmation (which I don't remember). Looking now at the old image (shown here) and the undamaged article, I am surprised that they show and discuss three [iso-]nonanes. (I should contact the creator of that image.) One might expect strict trimers of propene to be nonenes, like the one you made up. Both nonene and nonane claim to encompass trimers of propene. ("Industrially, the most important nonenes are trimers of propene." - Wikipedia!)

Mention of the tripropene or tripropylene isomers is a little hard to find. Look harder. (Most mentions of tripropylene are tripropylene glycol, a very different molecule, so exclude glycol in a web search.) Also, you seem to suppose that there is only one trimer. It is conceivable that propene will trimerize more than one way; the third propene has a choice of carbons to attach to. Other common propene compounds consist of isomers: "Dipropylene glycol is a mixture of three isomeric chemical compounds ..." -A876 (talk) 20:04, 11 February 2014 (UTC)

You suspect and you deleted. You suspect and you fabricated a structural formula (independent research). Nice edit summary, too: "that kind of stuff gives Wikipedia a bad name". Indeed. Here's one page you didn't find: "Tripropylene (CAS RN: 13987-01-4) IUPAC Name: 2,3-dimethylheptane; 2,4-dimethylheptane; 2,3,5-trimethylhexane" (the very text you deleted) "| CAS Registry Number: 13987-01-4 Synonyms: 1-Propene, trimer, AC1L1B03, CID26374, UN2057, Tripropylene [UN2057] [Flammable liquid]. [1] -A876 (talk) 23:50, 24 February 2014 (UTC)

I am pretty sure that the article as it stood a few weeks ago was badly flawed. No embarrassment because like you said the literature is flakey. Yes there are isomers since this material is generated by the trimerization of propylene and there are several ways to put these units together. The key aspect, which I am fairly confident about, is that tripropylene is unsaturated, otherwise it could not be used to alkylate aromatics. Yes, you are correct it is flammable, like any organic compound. If you find a paper that indicates that it is saturated, please indicate so. Happy editing. --Smokefoot (talk) 01:37, 25 February 2014 (UTC)

I stumbled upon a possibly similar reaction at Telomerization (dimerization)#Reaction, the "telomerization of 1,3-butadiene", which forms "several isomers". Naturally the products shown there are not strictly isomers, one being 1,3,7-octatriene, while the others have an -X group attached. (Maybe they should be called congeners, formed from the same reaction.) 1-Octene is made by oligomerization of ethylene (4 units), or telomerisation of butadiene (2 units) (plus adjustments). Oligomerization (in this case) joins an -ene to another -ene (or something else). Telomerization joins a 1,3-diene to another 1,3-diene (or something else). (I still don't know what they do to propylene; the needed "trimerization" could make "the isomer shown in the figure" (4,6-dimethylheptane), other isomers of nonene, and maybe some that are not isomers of nonene.) - A876 (talk) 22:01, 11 June 2019 (UTC)

February 2014

Please do not attack other editors. Comment on content, not on contributors. Personal attacks damage the community and deter users. Please stay cool and keep this in mind while editing. Thank you. Fleet Command (talk) 13:47, 17 February 2014 (UTC)

So busy slapping me around, you forgot to edumacate the lamer who started this by undoing an improvement, with insult, and for undoing it rather than fix it better (as you eventually did). Thanks. (By the way, he/she has two usernames, I notice. Maybe time to look into why, whether it's legit.) Just before that, flustered to slap back the bad guy, you hastily Undid (assume bad faith, right?) my edit (So many love that Undo button. It's a disease!) without even previewing and testing that edit! It took you two edits to figure out how to do right what I did 3/4 right the first time and 1/2 right (out of fear of reversion) the second time. "Codename Lisa" didn't pay attention to the work done before deciding I was an idiot. You didn't pay attention to the work done, before deciding I'm a bastard. People, pay attention to the work done! First make an accurate determination whether I'm an idiot or a bastard. Then abuse at will. -A876 (talk) 19:50, 17 February 2014 (UTC)

Removing other people's talk page posts

This was completely inappropriate. You can't just remove someone else's post because you think it's irrelevant. Jackmcbarn (talk) 02:43, 4 December 2014 (UTC)

A barnstar for you!

	The Copyeditor's Barnstar
	You're darned right that "/" is not a word! :-D You inspired me to finally start writing a list of common Wikipedian faux pas including that, "also", "despite", and other hyperboles. I have a process of undoing feature creep that's so common I just call it "de-also-ification". ;) — Smuckola (Email) (Talk) 06:26, 4 January 2015 (UTC)

I sometimes aspire to go hunting them, but there's just too many. When they cross my path, I usually "shoot on sight", but sometimes I can't untangle it or improve the situation, and I have to leave it alone.
So many peeves, so little time.
See also Wikipedia:It should be noted.
I also reduce multiple spaces between words. (Must be careful; I have to leave extras spaces in where they count (between code tags, and between formatted text tags), and where they might align markup (inside tables).) In the markup, as in HTML, spaces between words are reduced to one. -A876 (talk) 08:53, 5 February 2015 (UTC)

February 2015

Hello, I'm BracketBot. I have automatically detected that your edit to Base64 may have broken the syntax by modifying 1 "[]"s. If you have, don't worry: just edit the page again to fix it. If I misunderstood what happened, or if you have any questions, you can leave a message on my operator's talk page.

List of unpaired brackets remaining on the page:

• <code>o</code>: Its 64-character set is «<code>!"#$%&'()*+,-012345689@ABCDEFGHIJKLMNPQRSTUVXYZ[`abcdefhijklmpqr</code>».

It's OK to remove this message. Also, to stop receiving these messages, follow these opt-out instructions. Thanks, BracketBot (talk) 08:16, 5 February 2015 (UTC)

The content is correct. It's inside a code tag, so it's not markup. The unmatched bracket might be a code error, but it's not really code. Would <nowiki>...</nowiki> help? -A876 (talk) 09:09, 5 February 2015 (UTC)

The <code>...</code> tags do nothing special other than change the font, colour, background and border - much like the <i>...</i> tags do nothing other than apply italicisation. Everything enclosed by them is still treated as normal wiki markup. Using <nowiki>...</nowiki> should help. --Redrose64 (talk) 12:34, 5 February 2015 (UTC)

Thanks. Adding <nowiki>...</nowiki> inside the <code>...</code> displays correctly and most-likely prevents BracketBot from testing, so I did it.
(Adding <nowiki>...</nowiki> outside the <code>...</code> prevented the <code>...</code> from processing, so I didn't do that.) -A876 (talk) 19:45, 5 February 2015 (UTC)

9-1-1 article

Hello, A876. Regarding this edit you made to the 9-1-1 article, you shouldn't alter the title of the references; if a title of a reference states "911" instead of "9-1-1," you should leave that as it is. Flyer22 (talk) 20:18, 23 May 2015 (UTC)

I considered that, briefly. (I'm glad you made this a soft reminder and didn't waste time checking and changing.) I probably corrected as many mis-cites as I introduced, but I refuse to check more than I already did. Some referenced titles actually include "9-1-1", and they were mis-cited in the article. But yes, some referenced titles include "911". Unfortunately, every such reference is in error, for well-known reasons that are tragically not mentioned in the article. (You're never supposed to write 911 because you're never supposed to pronounce it "nine eleven" because some child will die because they can't find "eleven" on the telephone keypad. One only writes it "9-1-1", to force people to pronounce it "nine one one" because that is the only way to pronounce it. I get really irritated when a TV news program fails to edit out some idiot saying "nine eleven", especially when they are a salaried professional idiot in fire "protection" or law "enforcement". I want to graffiti on that idiot police vehicle and idiot highway sign pictured in the article that say 911. The people who painted them surely know better, and they deserve to be impoverished by a wrongful-death lawsuit and imprisoned for negligent homicide.) -A876 (talk) 05:40, 25 May 2015 (UTC)

I figured that you had a significant objection to the "911" wording. After all, when it is pronounced as "nine eleven," it sounds like a person is referring to the September 11 attacks. I added the alternative wording to the WP:Lead, but removed it moments ago because of what you stated in this section. Flyer22 (talk) 17:17, 25 May 2015 (UTC)

That stated, when 9-1-1 is spelled as 911, it is meant to be pronounced as 9-1-1, not as "nine eleven." Well, usually anyway. Flyer22 (talk) 17:20, 25 May 2015 (UTC)

Well, "911" could be pronounced either way. "9-1-1" is strongly suggestive, but a strong enough idiot could prevail and pronounce it "nine eleven" in spite of the "training wheels". I had no objection to your addition "or 911". I have no objection to your removing it. Two new items on my transfinite list of things I won't get around to are: finding a reference for my story about how they got started writing it as "9-1-1" (above) so that I could add it to the article, and finding replacement pictures for the article of a correctly labeled vehicle and correct highway sign. -A876 (talk) 05:51, 27 May 2015 (UTC)

Okay. Flyer22 (talk) 07:26, 27 May 2015 (UTC)

There is no "I" in Wikipedia!

There is no "I" in Wikipedia! -A876 (talk) 21:42, 12 July 2015 (UTC)

July 2015

Hello, I'm BracketBot. I have automatically detected that your edit to Otto Hahn may have broken the syntax by modifying 2 "{}"s. If you have, don't worry: just edit the page again to fix it. If I misunderstood what happened, or if you have any questions, you can leave a message on my operator's talk page.

List of unpaired brackets remaining on the page:

• Spence: ''Otto Hahn.'' Biographical memoirs of Fellows of the Royal Society, Vol. 16, 1970</ref>''}}

It's OK to remove this message. Also, to stop receiving these messages, follow these opt-out instructions. Thanks, BracketBot (talk) 03:51, 30 July 2015 (UTC)

Somehow I failed to change one of the markup tags I set out to change, damaging the page format. (Overly indented after the error.) I always look at Preview and Show changes, but not always closely enough. There were no RED WARNINGS, and I failed to notice the damage, so I saved a damaged page. Thanks again, BracketBot. -A876 (talk) 04:27, 30 July 2015 (UTC)

Leap second

Hi A876

No offence intended, but I reverted your changes to Leap second. Please don't edit articles to change capitalization of the first letter of templates (e.g. {{cite vs. {{Cite); as you undoubtedly know, all wiki article titles and template names are stored and accessed with the first letter capitalized; however, the amount of time and effort to review dozens of needless changes to template formatting in articles, as with your changes to Leap second, the waste of server resources & bandwidth to make & review such changes, and the potential for, as occurred in the case of your edits, unintentional damage to citations (beyond the one that you noticed because of the small red error), makes such edits ill-advised. Also, please keep in mind that ‘title’ parameters used in citations and external hyperlinks should reflect the name of the article as it exists, regardless of whether a Wikipedian feels that “and” is preferable to “&” or otherwise, and even if there are errors in the title at the source (invariably Wikipedia should reflect what sources indicate). Further, ‘accessdate’ parameters in citation templates should only be updated if information in the article is changed; updating the accessdate parameter to reflect that an external source was reviewed generates unnecessary edits which must be reviewed and potentially causes problems for bots that might make use of the information. As for your assertion, and edit, that “/” is not an acceptable abbreviation, I am unable to find any substantiation for that claim; in fact, while the WP:MOS (Wikipedia:Manual of Style) does not, that I could find, explicitly comment on whether or not or when “/” is an acceptable abbreviation, Wikipedia:Manual of Style/Abbreviations uses the “/” dozens of times to indicate two or more optional values, roughly equating to “ or ” (such as "TV/radio" or "compare/consult"); if you know of a reliable source or consensus that indicates otherwise I would be interested to review it. Finally, as per WP:IMGSYN (Wikipedia:Manual of Style/Images), “The "File:" prefix may be used interchangeably with "Image:":”, so it is inappropriate to edit articles to exchange one for the other. I just wanted to explain why I reverted your lengthy edits as I know how unsettling it can be when something is reverted without a proper explanation of the thinking involved. Rest assured that I restored the fixes of the two mistakes you found and repaired in your edits. Cheers — Who R you? Talk 04:04, 20 November 2015 (UTC)

1. Lets see.
2. You said "Please don't edit articles to change capitalization of the first letter of templates". That's a complete misrepresentation of what I did. Intentional or careless, you have made an offensive accusation. I edited the article. I also repaired some cruft that I found, making all of Cite have the same casing. To see which which one, I visited Template:Cite.
3. You said "Capitalization of initial letter of templates is irrelevant". And then you changed them back. Make up your mind. If you say it's irrelevant, WHILE CHANGING IT, It's hard to find a more perfect example of hypocrisy.
4. You said "Rest assured that I restored the fixes of the two mistakes you found and repaired in your edits." "Rest assured"? Really? You applied reversion JUST TO MAKE A POINT.

What you said and did, and the hypocrisy embodied in most of it, is unsettling. (More to follow.) -A876 (talk) 18:22, 20 November 2015 (UTC)

• My apologies if I was less than clear. I reverted your edits only because I noticed errors caused in two of the references (numbers 3 & 5 if memory serves) which related to Google books. Clearly nothing in your edits of the cite templates was intentionally meant to damage any of the references; I noticed in addition to changing the case you slightly altered spacing around some of the pipes “|” which precede template parameters which may have caused the problems (I didn't investigate). Rather than me going through and manually rechecking each reference in the article, I simply reverted your edits in their entirety then manually recreated the two specific errors that you had fixed. The issue with changing something like capitalization of a first letter of templates is that each change appears in the edit diff; so if 50 changes are made to capitalization and 2 other corrections are made, 52 changes must be reviewed, with leading and following lines also displayed that means that the diff is, a minimum of 156 lines for someone else to check; therefore, if a change isn't necessary (like changing first letter capitalization on templates) then whatever is there should be left; similarly, if there are extra spaces somewhere then, unless one is making other changes to the same line, it is generally better to just leave what is there. If you review the diff from your edits, I trust you'll agree that the large number of changes simply makes more work for anyone reviewing changes made (and if you look at References #3, 5, & 7 in the preview at the end of that diff, you'll see why I reverted all your changes rather than trying to find and correct the unintentional damage done to a list of 67 references). At all times I tried to assume good faith in your changes and I hope you'll do the same in believing that I reverted your edits as it seemed the best method of ensuring that every problem was caught and fixed. I then simply sought to explain to you why. I hope it is therefore less unsettling. Cheers — Who R you? Talk 04:05, 21 November 2015 (UTC)

Wolfgang

Good eye. Thank you.

-Forever IP

119.92.93.84 (talk) 10:27, 11 January 2016 (UTC)

Please don't make changes that don't affect the rendered text (re RS-232)

This is purely my personal opinion, not official WP policy or guideline or even an essay—but speaking strictly personally, I would like to ask you to refrain from edits that do not affect the rendered text, such as most of this edit that you made to RS-232.

Specifics:

1. Some editors like to break up the Wikitext by hitting Enter after each sentence. Or even after a major phrase. I often do this myself, depending on the article and the text. In complex text this can makes the edit window much less cluttered. Text followed by a single newline and more text does not produce a paragraph break (or "short paragraphs" as in your edit cmt). It takes two newlines to do that. The paragraphs following this item list were entered this way and you'll notice that they render like any other paragraph. (n.b.: In a list item such as this, one can't do that; a newline ends the list item.)
2. A single blank line in the Wikitext before or after a section head—or both—doesn't render. As with so many other things here, many editors like to leave these blank lines to make it easier to find things in the edit window.
3. Many editors like to break up a lengthy template, particularly citation templates, by using one line per parameter (again, usually to make the parameters easier to find in the edit window). If you find it that way, please leave it that way. There is actually a guideline on this, that template styles should be not be converted just for the sake of personal preference.
4. On the other hand, some editors do prefer to pack the edit window as densely as possible. Either way this is a personal preference and the preference of the previous editor(s) should be respected, just as is done with WP:ENGVAR.
5. In headings such as ==Text==, it doesn't matter whether there are spaces between the equal signs and the heading text. The spaces don't affect the rendered text.
6. A space between the asterisk and the first text letter in a list item does not render. This particular list has several items with the space, several without; you'll notice they all render the same. Some editors do like to include the space to make the edit window less "busy".
7. Changing the case of the first letter of an article title in a pipelink will have no effect on the rendered text; what will render is, after all, the text after the pipe. The actual article is always stored with a leading capital but lowercased article title links do work because there is a "silent redirect" that takes care of this. There is no reason to change the Wikitext if it already renders as appropriate for the usage.
8. The "File:" prefix does the exact same thing as the "Image:" prefix, so there is no reason to exchange one for the other. Particularly in the case where it is an image, why change it to "File:", when "Image:" is more informative to the next editor?

Note that if a particular style of using whitespace or newlines or etc. in the wikitext is considered an "optional style", then changing them purely for personal preference is contrary to an Arbcom ruling.

I'm not reverting these changes (although as I work on the article in the future it may well be "migrated" back to my preferred style) and I certainly am not going to bring any "cases" anywhere. The reason I'm leaving you this note is to ask you to consider: While such edits do not affect the text seen by the reader, they do increase editor workload. They complicate the editing history of the article and make diffs between versions more time-consuming to go through. Many of these changes can be difficult to see and evaluate in the diffs display. This can sometimes cause a lot of wasted time and effort for later editors trying to figure out what a previous edit has done.

All because of edits that do not improve the article for the reader not in the slightest.

Thank you for considering this suggestion. I realize you are acting in good faith to improve the encyclopedia as you see it, but please consider that you are making unnecessary work for those who follow you. Jeh (talk) 19:56, 3 February 2016 (UTC)

thoughts

I get much of what you say here.

I have lectured in general on the [stupidity] of making white-space-only edits. (It's amazing what people will do, eagerly undoing invisible markup changes and nothing else (because they see every change shown in a diff as a challenge or a mistake, or they defend the status quo of a perfect page that they own) or, worse, compound-reverting the useful visible changes by undoing the entire edit, even while there is real work (however minute) that they could have been doing, on that very page or 1,000,000 others.)

[sorry for an incomplete reply; not the best form. have to save it now. might get to it later.] [okay, filled it in.] points:

1. Considered. No. In Wikimedia markup, one linebreak between sentences makes it perfectly ambiguous whether the two markup "paragraphs" were intended to be one display paragraph (with an unnecessary invisible linebreak), or accidentally made into one display paragraph (intended to be two display paragraphs) (because someone forgot to add the second, necessary, visible linebreak). Anyone reading such mark-up has to re-determine the intent from the context. Therefore: If sentences are in the same paragraph, use one space between, to make it unambiguous. If sentences are in two paragraphs, use two linebreaks between, to make it unambiguous. Even if this particular private invisible code did not impair editing, it is annoying, because it makes paragraphs inconsistent from section to section, on whim. It is like some insane form of steganography. It begs for removal. (A single linebreak is invisible in Wikimedia markup only because of an enduring tragedy. Wikimedia markup inherited the HTML tradition of making all whitespace equal. In HTML, linebreak is whitespace, because many [especially older] text-editing programs only support finite paragraph length and forcibly insert hard linebreaks, even though paragraph length needs to be unlimited. So HTML could not use single-linebreak to indicate (mark up) new-paragraph, and double-linebreak became the way to indicate a new paragraph. If Wikimedia had designed that every linebreak makes a new paragraph, this discussion would not have been possible. Sadly, with millions of ambiguities in their valuable managed content, it would be painful to change style, because automatically resolving every case (by joining up the paragraphs, as-displayed) would destroy some information (all the invisible hints embodied in all those invisible line-breaks, that some of them should have been changed into paragraph-breaks). However, conversion seems even more unlikely because people can copy and paste text into and out of external editors; editors which might only support finite line-length (paragraph-length). (Every so often I see pages where I suspect that this has happened.))
2. Yup: Most blank lines don't render, but some do (WikiMedia inconsistency), so use 0 or 1, but never more than 1. (And ignore the one moronic rule that prescribes 2 somewhere. (I won't tell you where.)) Consistency is best, in-page and page-to-page. Exactly 1 blank line before ==Section==; exactly 0 blank lines after. For people who need to find things: type Ctrl+F and then start typing. To jump between preview and markup: click and drag to select "some" text with mouse; type CTRL+C (copy); type CTRL+F (find); type Ctrl+V (paste); hit Enter or click on the little next button. You will alternate between the two places (in any real browser). I use it endlessly. ("Some text" means "enough text to be unique or nearly unique on the page".) (Careless selection boundaries are fine; we're not pasting, we're just searching.)
3. I appreciate that "cite"s laid out one field per line can be nice. And ...
4. I appreciate that 7 7-line "cite"s in a 3-line paragraph is bloated and looks pompous. (It has me expecting to see one-word-per-line any day now.) Either way is has annoyances when trying to view it. Consistency is nice. Ain't seen that guideline; ain't gonna look for it. I'll try not to be overzealous. (And maybe a little cautious on articles that have "owner"s.) After any flurry of editing winds down, no one looks at the refs that closely. (Maybe a visual editor (in Wikipedia or external) would help by collapsing these things.) (Named refs look like another way to not put distractingly long "cite"s inline (inside the paragraph), instead using a much shorter version inline and a longer version "someplace else". But people are not yet using them well.) Maybe someone will innovate and enter "cite"s as tabbed fields (like is common in Chembox and other templates, and in punched-card programs and data files from the 1960s). Anyone using, advocating, or respecting that "style" will be fed to the hogs.
5. Yup: They render the same. Nope: It kinda matters. == Section == is crufty in mark-up. (== Section ========== is a style option for plain-text documents.) ==Section== is a norm on Wiktionary. (Well, one norm there that I agree with.) Consistency is nice, in-page and page-to-page.
6. [maybe later] Similarly, crufty and inconsistent. So far I cannot consider making it consistent as star-space, but I can make it consistent as star-no-space.
7. Yup: They render the same. Nope: It kinda matters. The first letter of the link "should" generally fit the sentence case that it would have if if weren't a link. (Yes, that is a guideline I saw somewhere (while not looking for it. It was pleasantly surprising to see that guideline writer(s) came to the right conclusion independent of me.) Sentence: "It was common in ancient Egypt." With link: "It was common in ((ancient Egypt))." With piped link: "It was common in ((ancient Egypt|Egypt))." To capitalize Ancient here is quite undesirable; it only pains ... future editors. Another reason lowercase is valid: "the pipe trick" (a way of entering that converts into a piped-link up on saving). With piped link using "the pipe trick": "Black's rook took White's ((knight (chess)|))." If you uppercase "knight" before the pipe symbol, "the pipe trick" does a visibly wrong thing (puts upper-case "knight" after the pipe symbol).
8. (If I remember correctly:) The template is File:. Image: is kind of legacy, an alias, and/or deprecated. And usage has gone that way. Image: is rare, others have reduced its incidence. So I replace it when I notice it. Consistency is nice, in-page and page-to-page

Most of my minute changes are removal of cruft. When the cruft is gone, it's (usually) often forever. The unbearable agony of countenancing all those "unnecessary" changes happens once, and it's over; that seems preferable to leaving them hanging as a possibility forever. Removing them is for future editors (especially me, obviously) and removes useless bytes from every future edit of the page.

(Thanks for the bracket-bot fix. My oops.) -A876 (talk) 21:55, 3 February 2016 (UTC)

Thank you for the reply. Your point about future editors having to consider "was this newline really meant to start a new graf?" is something I had not considered. Cheers! Jeh (talk) 22:34, 3 February 2016 (UTC)

Thank you again for your replies. I have no intention of trying to convince you of anything. I expressed my opinion, and I appreciate that you took the time to craft reasoned replies with which to express yours. So cheers! again. Jeh (talk) 13:46, 28 March 2016 (UTC)

Edit tags

I saw your sandbox edits. I guess it's the issue at Wikipedia:Village pump (technical)#Edit section links in article. A purge should fix affected pages. PrimeHunter (talk) 10:13, 28 February 2016 (UTC)

Cecil Kelley

Thank you for the thanks. You cannot possibly know how this particular article has ended up affecting me personally, but since I have actually exchanged emails with the daughter of Mr. Kelley regarding this article and heard her side of what happened to her family after the day of the accident, this article has become something rather precious if also incredibly sad for me. I cannot read it now and not break down into tears. I guess that's what happens when you touch the real world and it is so broken. Anyhow. Thanks for the thanks, is all. KDS4444^Talk 13:17, 1 April 2016 (UTC)

Welcome!

Dear A876,

I really feel glad that you thanked me for my edit, you are most welcome. I plan to make the most of Wikipedia.

Best Rgds. (~~SB~~ (talk) 16:26, 19 August 2016 (UTC))

Disambiguation link notification for September 4

Hi. Thank you for your recent edits. Wikipedia appreciates your help. We noticed though that when you edited Extraordinary People (2003 TV series), you added links pointing to the disambiguation pages Ability and Past life. Such links are almost always unintended, since a disambiguation page is merely a list of "Did you mean..." article 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) 09:30, 4 September 2016 (UTC)

It was intentional. -A876 (talk) 19:55, 13 September 2016 (UTC)

Revision to clarify usage of historical term

@A876:, since you wrote at length regarding the term "Sh'erit ha-Pletah" as a page name, kindly have a look at an explanation of my recent edit that qualifies the definition to clarify its difference from the general term "Holocaust survivors." I'll be doing more editing on that page, but this is a start. I'll also look for and add a citation supporting this more specific definition. -- Deborahjay (talk) 13:23, 19 June 2017 (UTC)

Unnecessary changes

In the context of this edit, may I endorse the feedback offered to you in the section above titled "Please don't make changes that don't affect the rendered text". In many cases you are simply imposing your own personal preferences, pushing aside the personal preferences of the editors who write the articles. This includes adding and removing capitals in templates etc and making entirely unnecessary changes to wikilink formats. --Epipelagic (talk) 07:01, 8 July 2017 (UTC)

0) "I endorse the feedback in the section above..."

•As if "the editors who write the articles" (must be better people, a higher class than me) care that their mark-up must be inconsistent and quirky. Consistency is a small benefit for editors who edit articles and editors who write articles.

•I "endorse" my replies above.

Have we made a better encyclopedia? -A876 (talk) 19:58, 20 August 2017 (UTC)

A876 (talk · contribs · deleted contribs · logs · filter log · block user · block log), regarding Serial port, you claim that this

[[gender of connectors and fasteners|male]]

(rendered version: male )

renders differently from this

[[Gender of connectors and fasteners|male]]

(rendered version: male )

Your claim is flatly not possible, because the stuff to the left of the pipe (|) doesn't render at all.

I would also argue that the capitalized form of the article name is more correct, as that will be the actual name of the article. Granted, the engine fixes it automatically.

Also, please do not add or subtract nonrendering spaces between the ='s and the text of section headings (no, they don't render).

And please don't reformat embedded edit comments (like the one in Serial port about DE-9 vs DB-9). (I formatted it that way because I wanted it to look like that in the edit window.)

Please be aware that every edit increases other editors' workload, because nearly every edit is checked by other editors - often several of them. It is annoying to look at an edit and find a predominance of things like this. They are often subtle and hard to spot in the differences display.

In addition, as such choices can be considered an "optional style", then changing them purely for personal preference is contrary to an Arbcom ruling. Jeh (talk) 02:41, 19 August 2017 (UTC)

Interesting. But:

1) "you claim that [[gender of connectors and fasteners|male]] renders differently from [[Gender of connectors and fasteners|male]]".

•No, I don't. You neglected to mention my visible changes. I claim that least significant bit renders differently from Least Significant Bit, as seen. ("Least Significant Bit" is incorrect in context, but Jeh changed it back to "least significant bit" anyway).

2) "I would also argue that the capitalized form of the article name is more correct, as..."

•Nope. The article name before the pipe is supposed to fit the sentence-case of its context, to avoid distracting reading in mark-up. Every editor sees links done that way; many know or suspect the good reason for doing it that way; most "authors" add links that way; most "authors" who add links the wrong way don't do it intentionally; and those who do it the wrong way surely don't care whether someone "imposes" their own "personal preference". Despite this, some few object and think the "original author"'s mistake was intentional and important to preserve. ("Author" is in ironic quotes because Wikipedia only has editors. There are no actual classes of editors.)

•I think you "would argue" for the uninformed way only to say I could be wrong, or at least not doing uncontested right. (I did right.)

•(Incidentally, capitalizing makes an incorrect result when using the "pipe trick".)

3) "please do not add or subtract nonrendering spaces between the ='s and the text"

•Well, Wikimedia should have silently standardized these, one way or the other, automatically upon every edit, since day two, so that users never have to wonder about it. (They still can do it any time. I am waiting.) We don't need options that let markup grow inconsistent (=ugly), for no gain.

•Wiktionary has made ==Section== their norm, valuing consistency over "preference", which amounts to accidental variation based on inconsistent examples, arbitrary template content, and habits. "==Section==" must have been the prevailing practice, as it is on Wikipedia (despite pressure from outdated examples and templates that pre-fill "== Section =="). Wikipedia hasn't caught up to its own practice, or to Wiktionary.

•A page that mixes "==Section 1==" and "== Section 2 ==" is inconsistent within the page; consistency within the page is a virtue generally, so adding consistency is an improvement.

•Is preserving this particular inconsistency actually important enough to mention?

4) "please don't reformat embedded edit comments (like the one in Serial port about DE-9 vs DB-9). (I formatted it that way because I wanted it to look like that in the edit window.)"

•Apparently this, #4, is the real provocation for your action. You put back "your" unnecessary single linebreaks (consider WP:Don't use line breaks) (and with them your redundant "as as" spanning a linebreak). That edit was not justified, so you expanded it to "rv nonrendering changes to wikitext" (which is a trivial edit in intent, plus reverting over "personal preference", both bigger than my making some nonrendering changes in a non-trivial edit), apparently to make me look really egregious. In the process you also undid valid changes (a "compound revert", another edit greatly to avoid). You even put it back again, edit comment: "rv one change by A876. I wrote that comment and that's how I want it to look in the edit window". (So many "I"s.) (How you want a comment to look in an edit window must be very important to the article. Important enough to change it back and go after me for changing it, citing rules that might apply.)

•(101) If you can't bear to have "your" contributions "mercilessly edited", maybe Wikipedia isn't the place for you.

•("I wanted it to look like that...") Is there an "I" in Wikipedia? No one owns that comment, its wording, or its appearance. And the comment only "looks like that" on your edit window, based on your screen width. I stumbled upon this: Help:Whitespace: "Avoid 'fixing' white space issues which are peculiar to your combination of screen or window and font sizes, choice of browser, image settings, and so on." Why is it important to have comments that get extra linebreaks in other-sized windows? You put them back twice, lectured me, and it isn't even good practice.

5) "Please be aware that every edit increases other editors' workload, because nearly every edit is checked by other editors - often several of them. It is annoying..."

•Having cruft back invites it to be removed, sooner or later.

•Putting cruft back invites it to be removed 'again', sooner or later.

•When cruft is removed, most of it stays gone, for a long time.

•Does every edit feed into multiple workfeeds for review? (I sometimes suspect this.) If so, the providers of that "Save changes" button should provide a warning near it. (Many comment forums also lack fair warning. Many only advise afterward that "your comment is awaiting moderation", and some restrict editing or deletion of a waiting comment, very unfair, similar to create-only permissions on a file folder (directory).)

•Every edit is announced to every editor who "watches" the article. (Maybe you shouldn't watch so many articles.)

•Lecturing editors is counterproductive. (Yuge™ waste. Sad.™ ☹) Have we made a better encyclopedia?

6) "They are often subtle and hard to spot in the differences display."

•Big differences are bolded.

•I'm not the biggest fan of the differences display - it doesn't bold added and deleted paragraphs, of all things.

•Maybe the difference display should conceal changes that don't render. Wouldn't that help everyone.

That arbcom ruling had some interesting points.

•"Wikipedia has established a Manual of Style for the 'purpose of making things easy to read by following a consistent format,'"

•"The prescriptions of Wikipedia's manual of style are not binding, but it is suggested that ..." "..., but be consistent within an article."

•"Revert warring over optional styles is unacceptable"

•"Sincere disputes are unlikely to be resolved by forcing the issue"

•It does not address nonrendering stuff (only example was American versus British spellings).

I recalled a mention of "cosmetic changes" (nonrendering stuff). It is over at WP:Bot policy#Cosmetic changes. (Because mass changes by robots tax resources and can irk people if they are not agreed upon. I don't get to mass-produce my mistakes.) Even so, it is relevant and agrees with us both: "Cosmetic changes to the wikitext are sometimes the most controversial, either in themselves or because they clutter page histories, watchlists, and/or the recent changes feed with edits that are not worth the time spent reviewing them. Such changes should not usually be done on their own, but may be allowed in an edit that also includes a substantive change." (And this is a guideline for robot mass-actions.)

I understand the intent of not stepping on other editors' [reasonable] preferences. I actually try not to.

I examine my diffs before saving so that they at least appear reasonable, so that I can check what I did and so that others examining the diff are not bewildered.

I don't make 50 sequential tiny little edits on an article; that makes an UGLY edit history, and seems almost obfuscatory (you can't see what they fully did without making a custom diff encompassing multiple edits) as well as wasteful. I tend to group my edits so that the edit history is not endless. A long interval between "Edit" and "Save changes" sometimes incurs an edit conflict; I handle it when it happens (which not often because I rarely edit active pages). Sometimes I remember to split up logically disparate changes into more than one edit. -A876 (talk) 19:58, 20 August 2017 (UTC)

I see that you are still doing this with this edit. These changes are mostly useless.—Anita5192 (talk) 18:22, 26 September 2018 (UTC)

It was almost as useless as this disparaging edit. I prefer to think of the cup as half-full. Many of the "changes" are only somewhat "useless". Most are useful or somewhat useful, now, or down the road. "Doing this" (making "insignificant" "useless" "meaningless" changes) helped me notice and correct more "real" defects. –18:53, 26 September 2018 (UTC)

WP:STUBSPACING

When and where was consensus forged for one instead of two blank lines preceding stub templates (ping SMcCandlish) ? – Finnusertop (talk ⋅ contribs) 20:26, 15 December 2017 (UTC)

Sounds like a question for WT:STUB. I stopped keeping track of that pseudo-issue in 2016. The WP:STUB text suggests that the two-blank-lines rule was instituted for technical reasons which have now been obviated, so who cares?  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  21:37, 15 December 2017 (UTC)

(@SMcCandlish: Correct. No one should care. I triggered this on 2017-11-05 when I boldly or brashly changed "two" to "one" at WP:STUBSPACING.)

"When and where" was "consensus forged" to specify two blank lines instead of one before {...-stub}? (Answer: The ridiculous notion surely got in there by accident, before discussion.) (BTW, "when and where" was "consensus forged" to specify even one blank line before {stub}?) What was the alleged "now-obsolete technical reason" that "used to" necessitate two blank lines? (Answer: There can't be one.) Is {stub} so very special that it gets to be the only feature that demands a spurious blank line? (Answer: It isn't, so it doesn't.) One blank line works, therefore there is no excuse for two, so forget about two. Like in many situations, a system built around "never" is as functional as a system built around "always". (I.e., "Never use two blank lines instead of one before {stub}." works just as well as "Always use two blank lines instead of one before {stub}.". (Actually, it works better.) There is no excuse for the exception, so the pointless exception goes away.)

It seems more likely that it was aesthetic (not technical), either in markup or in rendering. Markup: It made it so much easier to ... do something no one does. (Search for stub tag by typing Ctrl+F and then s t u b }.) No markup can be so special that it needs special rules around it. You =can't= $feature$ *everything*. (You can't.) What about all the other unfeatured tags that deserve special unique formatting (pointless blank lines, indenting, indenting, etc.) - it would make the page into an uneditable see of patterned whitespace. Not gonna happen. Rendering: If the Wikimedia software works right, rendered spacing before stubs should be the same regardless of whether there are 2, 1, 0, 3, or 42 blank lines before {stub} (or none at all, or if {stub} is in the middle of a line). The place to manage that spacing is in the renderer, not in the markup. Would anyone urge a change to two blank lines if there had only ever been only one blank line? Nope. Stupid rule (or guideline). Now it's not there to annoy any more. Time wasted. -A876 (talk) 09:24, 16 December 2017 (UTC)

"across the world" listed at Redirects for discussion

An editor has asked for a discussion to address the redirect "across the world". Since you had some involvement with the "across the world" redirect, you might want to participate in the redirect discussion if you have not already done so. — PinkAmpers&^{(Je vous invite à me parler)} 00:58, 2 January 2018 (UTC)

Disambiguation page

Re Projection, [2] it may help to check out WP:MOSDAB. Widefox; talk 12:05, 15 May 2018 (UTC)

Your edit on 20180515 improved categorization. You also thinned a bunch of items (lines), as "clutter". They probably were "clutter" on the disambiguation page – they might deserve mass listing only in a comprehensive "list of projections" (if that article existed). I did not add those items, though I preserved or "curated" them when I edited. I want to edit your edit-comment (though I can't): (create according to WP:MOSDAB (overview WP:DABYESNO) - note all those redirects to sections are already linked to the main article and clutter). "Create" is not quite the correct verb for an edit, however deep. Also I think the essay WP:NOTED should apply to edit-comments too, for good form. :)

I see possible encouragement in your mention of my edit on 20171010 (which was undone 50 days later). I think you appreciated my attempt to expand optical projection, though I misplaced my effort because it made the disambiguation page too much like an article. Disambiguation guidelines are at least simple. The harder part is to know what belongs in which article(s). (I forget whether I tried to see whether some of that writing could help another article, or become an article itself.)

Content should show the close relationship between mathematical or geometric projection, graphic projection, and optical projection.

Optical projection is not limited to projectors.

Every shadow is formed by projection.

Every conventional radiograph is formed by projection. -A876 (talk) 22:00, 15 May 2018 (UTC)

Move of Sjögren syndrome

The page was originally moved based on a Wikipedia:Requested moves. The ICD10 uses the term without the "'s". If we are to change another formal move request is needed. Best Doc James (talk · contribs · email) 14:17, 27 June 2018 (UTC)

That was arrogant of me. So you moved it back without investigating the reasons I gave or starting that discussion? Payback in-kind? "The page was originally moved based on a Wikipedia:Requested moves." No, it was on Wikipedia:Requested moves/Technical requests, implying that the requester would have done it themselves but could not and, as always, there was no "discussion" whatsoever – so much for unvetted "formal move requests". The reason given was "to match the article text" (but the article text was and still is mixed with multiple variations, copied incorrectly from article names and even the Foundation's name). Anthony Appleyard made this "uncontroversial technical request" with no sign of thinking about it. I contest that "uncontroversial" undiscussed move. I'm too late, as always, huh? I undid the move because it was wrong. You put it back because I am wrong. Where did you get your consent? Can you say who made the WHO and ICD10/ICD11 the ultimate and only arbiter of correctness in Wikipedia, overriding Mayo Clinic, the Foundation, NHS, and prevalence (almost everyone else)? Everywhere in English it is Sjögren's syndrome (also the original Swedish, minus the apostrophe - don't they have a say?). Only a small minority of articles get it "right" as you see it. Is there a mission to impose a WHO committee's idea of correctness on the world? Maybe we must rename every chemical to the international name (dodecan or dodecane?) too. Yes I've noticed the fad of dropping the 's from some disease names (Hodgkin, Down, Huntington?). No one needs it. It's confusing. Is it official? (Cite.)

Who is this "we"? And what do you mean "is needed"? Moves just go through until someone reverts them. Once decoded, what you wrote is a command (couched as politeness), not even advice. Utterly unhelpful.

"Originally moved" – there's a new oxymoron to remember. - A876 (talk) 21:45, 27 June 2018 (UTC)

Talk page etiquette

It is generally considered bad etiquette to edit other users' comments on talk pages and other discussion fora at Wikipedia, as you did here, even to correct typos. Probably best to just leave the mistakes alone. WikiDan61^ChatMe!_ReadMe!! 11:54, 6 July 2018 (UTC)

Proposed deletion of Hypothetical chemical compound

The article Hypothetical chemical compound has been proposed for deletion because of the following concern:

Newly created article that does not cite any sources.

While all constructive contributions to Wikipedia are appreciated, pages may be deleted for any of several reasons.

You may prevent the proposed deletion by removing the {{proposed deletion/dated}} notice, but please explain why in your edit summary or on the article's talk page.

Please consider improving the page to address the issues raised. Removing {{proposed deletion/dated}} will stop the proposed deletion process, but other deletion processes exist. In particular, the speedy deletion process can result in deletion without discussion, and articles for deletion allows discussion to reach consensus for deletion. Leyo 09:44, 10 July 2018 (UTC)

Someone de-tagged it, saying "newly created is not a reason to delete", but that's okay. - A876 (talk) 21:14, 23 July 2018 (UTC)

Ways to improve Basic aluminium

Hi, I'm Meatsgains. A876, thanks for creating Basic aluminium!

I've just tagged the page, using our page curation tools, as having some issues to fix. Consider providing reliable sources to strengthen the page's verifiability.

The tags can be removed by you or another editor once the issues they mention are addressed. If you have questions, you can leave a comment on my talk page. Or, for more editing help, talk to the volunteers at the Teahouse.

Meatsgains^(talk) 02:16, 28 August 2018 (UTC)

Please consider making more granular edits

Hi, and thank you for your recent edit to singular they. As far as I can tell, the content of the edit was constructive, and it looks like it required quite some effort. However, it was much more extensive than its edit summary implied. I don't want to cramp your style (keep up the good work!) but if you could, in future, consider breaking extensive edits like that into multiple edits, each addressing a distinct issue (or class of issue) and with an edit summary that clarifies the nature/purpose of the edit, that would be wonderful. Thank you again, Zazpot (talk) 22:33, 16 October 2018 (UTC)

I appreciate the sentiment.

I think I have grouped sets of changes by "class", when two major kinds of changes were involved. But generally I think doing so would annoy someone else. The resulting two long diffs would be longer (in total) than the one long diff. Some "classes" make the markup consistent as I would expect to find it; they don't always make visible rendering differences, and "cosmetic"-only edits are not desirable.

I try to make just one edit on a page if I can. In part because some editors save every 5 words or 2 minutes. This is so ugly. It fills up the History and makes it painful to figure out what they did. To see their actual net change in one view, I have to combine multiple edits when diffing. It is so wasteful, clogging the database with dozens of entries, and saving dozens of copies of the entire article. Half the time I need a follow-up edit because there's always one more thing.

Clarity of the article is most important, followed by clarity of the markup, followed by clarity of the diff. Still, I always use "Show changes" and review my diffs, for the actual changes and for readability. I always use "Show preview" and check edit summary before saving changes. (Well, almost always. Whenever I forgot to check these things, I always found a mistake after.)

Rounding templates

I started a TfM for templates Template:Rnd, Template:Round, and Template:Decimals at Wikipedia:Templates for discussion/Log/2018 December 14#Template:Rnd, thought you'd be interested. – BrandonXLF ^(t@lk) 00:49, 14 December 2018 (UTC)

Evolution News & Science Today listed at Redirects for discussion

An editor has asked for a discussion to address the redirect Evolution News & Science Today. Since you had some involvement with the Evolution News & Science Today redirect, you might want to participate in the redirect discussion if you wish to do so. PamD 17:09, 1 March 2019 (UTC)

Evolution News listed at Redirects for discussion

An editor has asked for a discussion to address the redirect Evolution News. Since you had some involvement with the Evolution News redirect, you might want to participate in the redirect discussion if you wish to do so. PamD 17:11, 1 March 2019 (UTC)

Seismic scales: not singular.

Your renaming of Seismic magnitude scales and Seismic intensity scales (and the associated talk pages) to the singular form is contrary to the nature of topic. Neither article is about a single scale, nor about the concept of a magnitude or intensity scale, but about multiple instances of each kind of scale. I suggest you should undo those changes. ♦ J. Johnson (JJ) (talk) 20:55, 22 March 2019 (UTC)

Hi. Thanks for not slamming it back. Very civil; not as bitey as reflexive "BRD". If it's wrong, leaving it wrong for a few days is no big deal. Let's try this consensus thing. If it's really not the right style, I'll happily undo it, without need for referee. I will look for counterexamples that could prove me wrong. I really thought I had it right and no one would object. The article [butterfly] is about ... butterflies. The singular title might discomfort some, but it is the norm. There are exceptions, for many unrelated reasons (scissors?). I'll look for similar concepts to see whether there is a trend. The plural titles were either sensible or an old unnecessary inconsistency. I'll try to change them back, but if I can't get comfortable with it, I'll object. I think we'll be comfortable with the result. I'll look at it in the next few days. - A876 (talk) 01:57, 23 March 2019 (UTC)

I was tempted to revert (and I did on the template), but didn't want to deal with the whole set of interconnected changes. Do keep in mind that we can tolerate bold editing – even with the prospect of Bad editing, even without prior discussion — because we have BRD available as a cure. Where editors complain of their work or time being wasted, well, that's why it's always a good idea to ask on the Talk page before getting too deep.

There is specific guidance on this kind of question. I will post that at Talk:Seismic magnitude scales so it is available for future reference.♦ J. Johnson (JJ) (talk) 20:42, 23 March 2019 (UTC)

Unprecedented civility, whatever the reason, to do "Bold-Discuss" rather than "Bold-Revert-Discuss" (which, for some, surely is a mantra). Let's see how it works out. Revert is not mandated, unless one is pretty sure that someone got it wrong. Revert is not there to "punish" for the non-offense not discussing a considered change. Every page is not a minefield. ("Not-broken" is not law either. Reverting not-broken to make a Point in the edit comments (seen elsewhere) is an offense.) "Bold" - as in good-faith belief that I had it right and no one would object.

Are "changes" suddenly a bad thing? "Extensive" changes - that's merely global search-and-replace. "Undiscussed" ... is not an offense. "Ill-advised" - uh, thanks? (compound revert at Template:M: Difference between revisions)

I'm leery to see use of "we", because "we" is ambiguous. Who is this "we"? Is there some group of right-minded editors that does not include me? - A876 (talk) 01:40, 24 March 2019 (UTC)

"We" = Wikipedians. "Right-minded" or not.

Are "changes" absolutely guaranteed inclusion unless and until "proven" to contravene some policy? Some editors have argued that, but I (and other editors) say that is nonsense. I don't know that Revert is mandated (except for BLP, copyvio, and certain other legal cases). It certainly is permitted, and I do not see any "unless ..." about it.

I would suggest you not lean towards invoking strawman arguments here. E.g., I have made no suggestion that not discussing something is any kind of "offense". What I have suggested is that it is unwise to get too deeply involved in changes without querying. Which hardly amounts to a discussion. ♦ J. Johnson (JJ) (talk) 20:07, 24 March 2019 (UTC)

Sulphur

You do not seem to be aware of WP:ENGVAR - sulphur is the spelling in British English and used by eg the international Sulphur Institute. Undiscussed changes against the language version in force will be reverted and may be treated as vandalism. So please stop. Btw, it is a complete waste of time decapitalizing the first terms in piped links - there's no benefit & it just wastes other's time checking your edits. Johnbod (talk) 13:01, 19 May 2019 (UTC)

You "do not seem to be aware" of the article contents.

Sulfur is not "the spelling in British English". Quite the opposite. It is approaching deprecation. From the article:

Oxford Dictionaries note that "in chemistry and other technical uses ... the -f- spelling is now the standard form for this and related words in British as well as US contexts, and is increasingly used in general contexts as well."

Yes "sulphur" is "used by" the "international" authority (industry association) that you sought out (founded 1960), that trolls the world by clinging to its outdated name. What about IUPAC (established 1919 and prescribes "sulfur" since 1990)?

The IUPAC adopted the spelling sulfur in 1990, as did the Nomenclature Committee of the Royal Society of Chemistry in 1992, restoring the spelling sulfur to Britain.

"The language version in force" is: "{{Use American English|date=March 2017}}".

"may be treated as vandalism". Classic.

1) "wastes other's [sic] time". (this is by far a larger example) + 2) POINTy full (compound) revert with edit comment "mixture of OR, ENGVAR breaches, and pointless fiddling". (I count one "breach".) Barnstar of Condescension. - A876 (talk) 16:39, 19 May 2019 (UTC)

Yes - wasting everyone's time! You clearly have massive self-righteousness but the majority of your edits I've looked at add no benefit to WP. I see this is the latest in a long list of complaints, which you completely ignore. Sulphur is NOT approaching deprecation in the UK outside chemistry departments and should not be changed in BE non-technical articles. The RSC probably jumped the gun in 1992, & the change has just not taken as far as the general media is concerned. Johnbod (talk) 16:48, 19 May 2019 (UTC)

Exceeded only by your "massive self-righteousness" and your wasting of others' time. I've only wasted time of those who choose to waste their time. Otherwise, it saves time – one edit "&" it's done forever; compound-revert it and now there's two complex edits. Undo what needs undoing (or, better, improve it - at the very least, "Sulfur or sulphur" is not true internationally). If you actually re-did every "pointless fiddling" that I did here, in the process of consistently applying the opposite styling (incidental to a "substantial" edit), I would be equally disgusted, but I would respect it more, to know that someone values the cruft that I would remove, and is not just putting back the cruft to make a point.

Gnome: "A user of Wikipedia or any wiki who makes useful incremental edits without clamouring for attention is called a WikiGnome." (I know, it's hard to comprehend.) I am worthless because "the majority of [my] edits [that you]'ve looked at add no benefit" that you recognize. Thanks.

I "completely ignore" the "long list of complaints"? No. I completely refute... or relent.

"The RSC probably jumped the gun in 1992..." Really? You know better than RSC? (WP:OR much?) (And why cite RSC? Like RSC, Wikipedia follows IUPAC.)

WP:SULF: "For articles about chemistry-related topics, Wikipedia follows the international standard spellings of the International Union of Pure and Applied Chemistry (IUPAC): ... sulfur not sulphur ... These spellings should be used in all chemistry-related articles on English Wikipedia, even if they conflict with the other national spelling varieties used in the article."

MOS:CONSISTENCY: "For articles about chemistry-related topics, the international standard spellings aluminium, sulfur, caesium (and derivative terms) should be used, regardless of the national English variant employed in the article generally."

I didn't change "sulphur" to "sulfur" in this [technical] article. "sulfur is the usual spelling in American English. Sulphur is generally the preferred spelling in nonscientific texts from outside North America, but sulfur is gaining ground in scientific writing throughout the English-speaking world." Much as I hate "sulphur" (I admit it), I won't be pumping "sulfur" into every "BE non-technical article".

wikt:sulfur: "... Alternative forms: sulphur (Australia, Canada, India, New Zealand, UK; nonstandard in scientific usage)".

So at the very least, "Sulfur or sulphur" was an oversimplification – it's sulfur except in "non-technical" and/or non-US writing. How to express that concisely in the introduction to an encyclopedia article? I was considering changing it back to a form it had in 2008: "Sulfur or sulphur (/ˈsʌlfɚ/, see spelling below)". While we've been chatting, Maxeto0910 has changed it to "Sulfur (also spelled sulphur) is...", paralleling the intro to Aluminium=Aluminum. The intro to Caesium=Cesium handles the UK≈IUPAC≈US differences yet another way. - A876 (talk) 19:31, 19 May 2019 (UTC)

Capitals

In this edit I see you changed {{main article}} to {{Main}}, but {{Cite web}} to {{cite web}}. First of all I'd like to remind you that if changing capitalization is all you do, then WP:KISS applies, and you shouldn't make the edit. But in this case you made many edits, so that is not the issue. The problem is simply that this is inconsistent: either all capitals or none. The fact is that names of templates are capitalized on Wikipedia. Debresser (talk) 20:40, 10 June 2019 (UTC)

Those inconsistencies are intentional. They do not make me a hypocrite. Many things are consistent, but it is not possible to make everything consistent in every way. Making things consistent in one way makes some things inconsistent in other ways. All instances of {cite} are now consistent (to each other); all instances of {Main} are now consistent (to each other). {Main} is inconsistent with {cite}, but even that inconsistency is consistent in another way.

Like the titles of templates, the title of every article is also capitalized. You can't create an article with a lowercase first letter if you try. This was established by design long ago, and it seems quite helpful. In articles, wikilinks to non-proper-names are capitalized consistent with their context, not the (mandatory) capitalization of the linked article's title. Trivial examples: Ancient Greece is ancient Greece. When clicking on a wikilink, the other capitalization rule kicks in: [ancient Greece] automatically acts like a wikilink directly to [Ancient Greece] (the actual title), without need of a piped wikilink or a redirect article. For piped wikilinks, the same rule. [[Superheating|Superheated vapor]] is [[superheating|superheated vapor]] renders as: Superheated vapor is superheated vapor. The casings of the parts before the pipes are invisible to the viewer, but visible to editors. Reading markup like [[superheating|Superheated vapor]] is [[Superheating|superheated vapor]] (which renders exactly the same) is distracting because the initial non-capitalization and the mid-sentence capitalization are inconsistent with the context. Capitalizing the invisible part of the piped wikilink consistent with its context is a guideline.

For templates, capitalizing consistently with context is much preferred over capitalizing every invoked template the same way which would be the most consistent, but ugly). The examples given in templates' documentation, and predominant usage, seem to bear that out. {Main}, {See also}, {Further}, etc. usually begin a section and render to a sentence or a clause that gets or would get an initial capital. Similarly hatnotes like {Food article}, {Otheruses}, {Use YYYY-MM-DD dates}. {Reflist} and {Div col} don't render directly, but they begin and/or end sections. Things like {snd} and {tl} are used mid-sentence or mid-phrase, so never capitalized. One could argue either way for {Cite} versus {cite}. (Regardless, consistently using one or the other is preferable to a mix.) Most uses of {cite} follow a period or a comma, with no space allowed between, so I find lowercase more comfortable there; and most editors do it that way most of the time in most articles. When I see References sections with many *{cite...} entries, it is mildly uncomfortable, but I'm not planning to change to {cite...} inline but {Cite...} under References, nor change {cite...} to {Cite...} everywhere. (I don't see enough of {Citation...} or {citation...}, so I don't have a leaning.) {DOI} is cased wrong; it redirects to {Doi}; but the correct form is {doi}. - A876 (talk) 22:07, 10 June 2019 (UTC)

I don't think that most editors find lowercase more "comfortable". I think they are simply too lazy to use capitals. See the lack of usage of punctuation in texting culture for another clear example of this.

By the way, I see you removed the spaces from the heading of this section. You can't disagree with me that the default of Wikipedia is to have spaces. I always find it strange when editors remove them in articles, against the default. Personally I find them helpful for a clear layout as well. Debresser (talk) 22:34, 10 June 2019 (UTC)

Because most editors write {cite} instead of {Cite} most of the time in most articles, whether they are "lazy" or not, no one would say they that they are "uncomfortable" with doing so. Discomfort motivates most edits – any item or article needs to exceed a threshold of discomfort before someone will actually modify it. So here it is: Most editors are comfortable with lowercase {cite}. Some prefer {Cite}. And many don't notice, don't care, or don't bother. (Regardless, consistently using one or the other is preferable to a mix.)

Next, you mention the use of all-lowercase by "texting culture" as an example of "laziness", but you've recognized that all-lowercase writing is normal (in the sense of what people do), as well as a style, in some modes of communication. Anyway, texting in a hurry is not article writing. The only examples of possible leakage from degenerate "texting culture" that I have noticed here are the occasional "&" instead of " and " and "/" instead of " or ". (Did u c any?) Well, and NOOBS occasionally make sloppy additions in all-lower-case text (not intended as vandalism). If it is useful, someone promptly fixes it up, but usually it is non-helpful, so someone promptly Undoes it; that is why you usually only see these under Revision history.

Annoyingly, Wikipedia hasn't declared a standard for ==Section== versus == Section ==, beyond a mild preference for consistency – which is not helped by its lack of a standard and lack of automatic silent enforcement of that standard (trivial to implement). They kind-of ignored the question, as if it would solve itself, only saying "Spaces around the (section) title are optional and ignored." I can't find what is "the default of Wikipedia". Some automatic things start out with spaces, and some without. Explicit examples are decidedly a mix. Because non-spaced section titles predominate despite some examples that go against that preference, I would say that non-spaced is strongly preferred, and should also be standard here at Wikipedia. I feel uncomfortable with anyone going around adding such spaces, but I have not yet queried them or urged them not to. Wiktionary has standardized on ==Section== (with NO blank line between the section title and the section). I see a growing prevalence of ==Section== over == Section == in Wikipedia. Older articles have a mix, with more == Section == in their older, standard sections (I'd say "boilerplate" sections, but no boilerplate is provided; the default new article is a null string), while newer sections and articles use ==Section==. Those are enough reasons for me. This is markup. The == don't render. (However, when I make partial horizontal lines in non-markup documents, I use spaces in the titles, such as ===== Section or ----- Section.) As expected, Wikipedia also fails to address the "blank line between section heading and section" - the closest is "Do not leave blank lines between items in a bulleted or numbered list..." But Wikipedia:MOS pages don't have the extra blank lines in their markup; that might be an example more than prevalent usage in article space. It's time to get back to encyclopediaing. - A876 (talk) 00:37, 11 June 2019 (UTC)

@A876: Greetings! In this thread you wrote "Capitalizing the invisible part of the piped wikilink consistent with its context is a guideline." I am unaware of such a guideline. I will be grateful if you identify the guideline you are referring to. Many thanks. Dolphin (t) 22:50, 10 July 2019 (UTC)

I hope you are agreeing with the practice, not challenging it. Either way, a cite would be great to have. At the moment I cannot provide one. I'm pretty sure I "stumbled upon" an official "should" recommendation (naturally while searching for something quite else, years ago). I was encouraged that sense prevailed, but I didn't stop and engrave it in stone. I never went back to look for it. I just continued doing it. Naturally, recent searches under WP:MOS:Wikilinks or similar failed to turn it up. I will have to try again. Is it on some obscure page? buried in the History of a prominent page? Was it an essay? an archived discussion? Was it OR and/or a hallucination? Here's the reasoning: 1) One way or the other is better than chaos. (consistency) Can't debate that. 2) Consistent-with-context predominates; capitalize-always is the exception. Consistentizing in the predominant direction should be the least less objectionable. 3) (I say) consistent-with-context is far more sensible than capitalizing every piped link, shown by most editors doing it that, way with or without thinking about it. Various tests point to consistent-with-context. If you use The Pipe Trick mid-sentence, you cannot capitalize the invisible part of the resulting piped link. (I think I've mentioned this and other tests before.)

Consistent-with-context, capitalize-always, and even comedic lowercase-always (e.g. [[george W. Bush|Dubya]]) all function the same, so consistent-with-context can't be made "mandatory". At most it can be a "should". If that's not a guideline, maybe it should be. It's so basic that the Wikipedia editor should do it automatically, but it would be difficult to implement – the editor would have to know WHY each individual article is capitalized, to know whether or not the piped link should be capitaliaed in context. Maybe it should be an essay? Start as a user-page article? Something for the Village Pump (a place I never visit). I can't say much more until I dig a bit harder for where I saw that "should".

(One Hungarian Wikipedia editor didn't like consistent-with-context, and undid a pageful saying "szerkesztésére: szócikkcím nagybetűvel" implying that all piped links must be capitalized like the article Titles (which makes no sense because there could never be un-piped links except at the beginning of sentences and for proper names). there would- which definitely is not a guideline on English Wikipedia. I didn't have enough patience to look for guidelines viat translation to tell the Romanian user how unconstructive and incorrect the reversion was, so I didn't try to explain.) - A876 (talk) 00:38, 11 July 2019 (UTC)

Hi A876. Thank you for your prompt reply to my request.

The article Joule–Thomson effect is on my watchlist so I set out to make a quick check of your recent edit – see your diff. I immediately noticed that your edit includes about a dozen changes to reduce a leading letter from a capital to the lower case in links that make use of the pipe. As you know, these changes are invisible to the reader. I have never seen anyone make that change before so, at first, I assumed you must be a newcomer.

Wikipedia values consistency within an article. In this context, that means consistency from the reader’s viewpoint. Your changes are invisible to the reader so they do not increase (or decrease) the reader’s perception of consistency within the article.

Wikipedia has identified a number of areas where two or more different presentations are acceptable: for example, American and British English are both acceptable, both in spelling and grammar. At least two different date formats are acceptable. At least two different citation formats are acceptable. For further examples see Wikipedia:Consistency.

Where two or more different presentations are acceptable, Wikipedia says only that consistency (as perceived by the reader) is desirable within each article. Wikipedia does not suggest that one is superior to the other, or that one should be changed to the other (except to achieve consistency, as perceived by the reader.) Consider the following partial quotations taken from Wikipedia:Manual of Style#Retaining the existing variety. I have omitted words and expressions that pertain only to different varieties of English language. The same principle is applied to different date formats and different citation formats within an article. I consider these partial quotations are also relevant to capitalization in Wikilinks that use the pipe.

"When a ... variety's consistent usage has been established in an article, maintain it in the absence of consensus to the contrary. With few exceptions ... there is no valid reason for changing from one acceptable option to another."

"An article should not be edited ... simply to switch from one variety ... to another."

In summary, Wikilinks that use the pipe are acceptable with a leading capital letter, and they are also acceptable without a leading capital letter. There is no valid reason to change from one to the other.

Keep up the good work! Dolphin (t) 13:22, 11 July 2019 (UTC)

All are visible to editors (at least the majority(?) who [still] edit markup); that's obviously who they're for. Initial-capital-always is annoying, and a mix is even more annoying. One could say I am applying the Golden Rule: When I begin to edit any article, I expect the markup to already exhibit several kinds of consistency. (It's like expecting all the men's shoes in the department store to be in the men's shoes section, grouped by maker, style, and then size.)

I only make "invisible" changes incidental to "real" edits. The process Often corrects real errors (improper capitalization of non-piped links) that would have gone unnoticed. It's like running a syntax checker on a program. It clarifies what's there by removing "lint" that obscures the view.

Templates like {Use British English Oxford spelling}(hmm!), {Use Trinidadian English}, etc. and {Use MYD dates} disallow mixing several kinds of "acceptable" "presentations" within labeled articles. If parts of an article do not follow the explicit or implied preference, one can and should at least nudge it toward the preferred style, or even enforce that style article-wide. I can't imagine "mix" recognized as a style that should be preserved. (Mixed ref styles seem allowed - people are just thinking about what to do about it, if anything.)

I'm unlikely to leave two or more spaces between words in sentences, trailing spaces at the end of Lines, random Capitalization, etc. just because someone "might have" [obliviously] "intended" them that way – they are not "styles" that anyone need respect. Both ways of using the pipe are "acceptable" because both work, and the Community is not petty enough to "enforce" one way; they have an encyclopedia to maintain, and there are lots of other things to correct (and people to disparage). Both ways survive because no one has decided to automate a standardization. But one of the "acceptable" ways basically sucks. I can fix things that I find "a little broken" (I know a phrase like that is in there somewhere – I've looked into this too). It harms no one; benefits some. Once on a page and it's over (for a long time). I don't fill up hard drives saving a hundred tiny edits, saving every 30 seconds or 30 characters for imaginary reasons; I make a hundred tiny edits in one big save, and somehow people see fit to whine that -I- am wasting their time reviewing. It's good. Let it be. Enjoy the clarity. Consensus? Implied. One could canvas for proponents of Initial-capital-always, consistent-with-context, Never-Ever-Change-Anything-Ever, never-thought-about it, and simply-don't-care. (Not going to happen.) - A876 (talk) 19:05, 11 July 2019 (UTC)

Does this new section header which I created by pressing "new section" have spaces?

Let's see. Debresser (talk) 11:03, 11 June 2019 (UTC)

It does. So Wiktionary is not Wikipedia in this regards. Debresser (talk) 11:05, 11 June 2019 (UTC)

We both mostly knew that the "New section" automation on Wikipedia User_talk pages surrounds the entered "Subject/headline" field with == ... == (with the optional spaces), on a line by itself (good), preceded by a blank line (good), followed by a blank line (ugh), and then the contents of the text box, all at the bottom of the existing page; and that the person using that button has no choice. (Notice also the form's lazy/incorrect use of "/" in place of " or ".) I acknowledged that, when I said "Some automatic things start out with spaces...." I mentioned Wiktionary as a good example of making choices (as well as agreeing with their choices, in this case). I said "(Pages that e)xplicit(ly give) examples are decidedly a mix." Browse a few "Random page"s in article space, and it is obvious that "non-spaced section titles predominate" – and they predominate "despite some examples (and some automation, including, at some time, an automated editor) that go against that (clear) preference". I've considered it. I'm comfortable. - A876 (talk) 16:46, 11 June 2019 (UTC)

Sure. Thanks for your time. Debresser (talk) 17:59, 11 June 2019 (UTC)

Disambiguation link notification for June 29

An automated process has detected that when you recently edited Material (disambiguation), you added a link pointing to the disambiguation page Substance (check to confirm | fix with Dab solver).

(Opt-out instructions.) --DPL bot (talk) 14:36, 29 June 2019 (UTC)

Thanks, I reworked it even more. - A876 (talk) 00:38, 11 July 2019 (UTC)

Google Code-In 2019 is coming - please mentor some documentation tasks!

Hello,

Google Code-In, Google-organized contest in which the Wikimedia Foundation participates, starts in a few weeks. This contest is about taking high school students into the world of opensource. I'm sending you this message because you recently edited a documentation page at the English Wikipedia.

I would like to ask you to take part in Google Code-In as a mentor. That would mean to prepare at least one task (it can be documentation related, or something else - the other categories are Code, Design, Quality Assurance and Outreach) for the participants, and help the student to complete it. Please sign up at the contest page and send us your Google account address to google-code-in-admins@lists.wikimedia.org, so we can invite you in!

From my own experience, Google Code-In can be fun, you can make several new friends, attract new people to your wiki and make them part of your community.

If you have any questions, please let us know at google-code-in-admins@lists.wikimedia.org.

Thank you!

--User:Martin Urbanec (talk) 21:58, 23 November 2019 (UTC)

I have sent you a note about a page you started

Hello, A876

Thank you for creating Icing sugar fungus.

User:Willbb234, while examining this page as a part of our page curation process, had the following comments:

I don't see anything on the target article saying that the fungus is known by this name. If it is, please add the info to the article with a WP:RS. Thanks.

To reply, leave a comment here and prepend it with {{Re|Willbb234}}. And, don't forget to sign your reply with ~~~~ .

(Message delivered via the Page Curation tool, on behalf of the reviewer.)

Willbb234^Talk (please {{ping}} me in replies) 21:45, 20 December 2019 (UTC)

Unnecessary changes (again)

I appreciate feedback is something you usually flush away in a torrent of irrelevant diversion, so there is no need to respond to this. I'll merely record (again) my dismay that you largely confine your edits to unnecessary changes. Such as this edit, apparently made with the primary aim of overriding whatever personal markup preferences the editors who actually write the encyclopedia might have with your own personal markup preferences. It is naturally frustrating for content builders who find they waste their time trying to review your edits, since they rarely contain anything that makes the slightest material difference to how the article renders or what it actually says. You present instead avalanches of inconsequential tweaks to the source code, such as endlessly adding and subtracting spaces in places where it makes no difference to the display or meaning, and endlessly capitalising and uncapitalising in places where it just doesn't matter (...though content builders often format code in ways that make subsequent editing of the source code easier, and you overwrite this). The main real world consequence of your edits is to leave in your trail Wikipedia editors who have just been further discouraged from trying to actually write the encyclopedia. – Epipelagic (talk) 22:29, 20 December 2019 (UTC)

To editor Epipelagic: I agree 100%, especially after looking at the edit you linked to, even though there were a couple changes within that great clump that I did think were necessary. I came to this talk page curious to see if anybody else was discussing A876's edit pattern after seeing an edit made in the MoS (diff) an hour ago. The edit pattern is baffling. Glad to see I wasn't missing some buried point to it all! Worse, it's difficult to review such edits because the unnecessary changes are so dense all at once that they drown out any necessary changes and also any outright errors. Any novice looking at that diff for clues on how to edit would be so confused and misdirected.

Sorry all I can do is throw my support behind you briefly like this but my real-life limitations get in the way of me doing more. Thanks! —Geekdiva (talk) 08:09, 21 March 2020 (UTC)

I'm also going to agree. Having looked at some of these edits (prompted by the MOS one), all I can say is that you (A876) need to remember that an edit that doesn't affect how the page renders or functions is usually unneeded and should be avoided. Most especially disturbing is the intentional linking of redirects behind pipes. Redirects may be cheap and not broken themselves, so a redirect doesn't need to be changed if it's already in place, but changing a valid direct link to a redirect is not only pointless, it creates performance issues for the site. please stop doing that. oknazevad (talk) 14:30, 21 March 2020 (UTC)

There is currently a discussion at Wikipedia:Administrators' noticeboard/Incidents regarding an issue with which you may have been involved. –Deacon Vorbis (carbon • videos) 22:22, 23 March 2020 (UTC)

MOS discretionary sanctions alert

This is a standard message to notify contributors about an administrative ruling in effect. It does not imply that there are any issues with your contributions to date.

You have shown interest in the English Wikipedia Manual of Style and article titles policy. Due to past disruption in this topic area, a more stringent set of rules called discretionary sanctions is in effect. Any administrator may impose sanctions on editors who do not strictly follow Wikipedia's policies, or the page-specific restrictions, when making edits related to the topic.

For additional information, please see the guidance on discretionary sanctions and the Arbitration Committee's decision here. If you have any questions, or any doubts regarding what edits are appropriate, you are welcome to discuss them with me or any other editor.

NinjaRobotPirate (talk) 22:55, 23 March 2020 (UTC)

March 2020

You have been blocked from editing for a period of 24 hours for edit warring. Once the block has expired, you are welcome to make useful contributions.

During a dispute, you should first try to discuss controversial changes and seek consensus. If that proves unsuccessful, you are encouraged to seek dispute resolution, and in some cases it may be appropriate to request page protection.

If you think there are good reasons for being unblocked, please read the guide to appealing blocks, then add the following text below the block notice on your talk page: {{unblock|reason=Your reason here ~~~~}}.  NinjaRobotPirate (talk) 08:29, 24 March 2020 (UTC)

Collaboration

I noticed Wikipedia:Administrators' noticeboard/Incidents#A876 and commented there. I see more activity at Modern ruins. Please be aware that editors must collaborate at Wikipedia. Perhaps your changes are wonderful but repeating them when challenged is disruptive. I will block you if that continues. You may not be aware of previous cases but one example comes to mind of a highly productive editor who was a respected administrator. They did hundreds of gnoming edits while changing articles to suit their particular opinions regarding inconsequential capital letters and spacing. They were blocked and eventually had their admin status removed. I'm looking at diff. Some of that can be justified but you must have worked out by now that fiddling with links is irritating other editors. Wikipedia does not work on the principle of determining who has the most perseverance. Collaboration is required. Johnuniq (talk) 03:09, 27 March 2020 (UTC)

• @A876: I am about to close the ANI discussion and am formally warning you that an indefinite block will follow any repeat of changes to the existing style of articles or other pages. A single change may not result in a block, but multiple changes, or repeating a change if reverted, will. The reason is simple: some people like wikitext done one way, and others like it another way. To avoid pointless conflict, it is long-standing procedure that there should be no style changes without really good reason. Because of the trouble (time wasted by other editors) that has occurred, you should propose style changes and get consensus for them before making any such changes. Johnuniq (talk) 05:22, 5 April 2020 (UTC)

ANI

You decision to unarchived that ANI thread and then post a wall of text damages your case.Slatersteven (talk) 11:25, 30 March 2020 (UTC)

Ways to improve Calcium hydrosulfide

Hello, A876,

Thank you for creating Calcium hydrosulfide.

I have tagged the page as having some issues to fix, as a part of our page curation process and note that:

pubchem is insufficient even to show the substance exists

The tags can be removed by you or another editor once the issues they mention are addressed. If you have questions, leave a comment here and begin it with {{Re|Graeme Bartlett}}. Remember to sign your reply with ~~~~. For broader editing help, please visit the Teahouse.

Delivered via the Page Curation tool, on behalf of the reviewer.

Graeme Bartlett (talk) 20:48, 5 November 2020 (UTC)

Nomination of Hypothetical chemical compound for deletion

A discussion is taking place as to whether the article Hypothetical chemical compound is suitable for inclusion in Wikipedia according to Wikipedia's policies and guidelines or whether it should be deleted.

The article will be discussed at Wikipedia:Articles for deletion/Hypothetical chemical compound until a consensus is reached, and anyone, including you, is welcome to contribute to the discussion. The nomination will explain the policies and guidelines which are of concern. The discussion focuses on high-quality evidence and our policies and guidelines.

Users may edit the article during the discussion, including to improve the article to address concerns raised in the discussion. However, do not remove the article-for-deletion notice from the top of the article.

–LaundryPizza03 (dc̄) 21:31, 7 November 2021 (UTC)

Disambiguation link notification for January 23

An automated process has detected that when you recently edited Botulinum toxin, you added a link pointing to the disambiguation page Protease inhibitor.

(Opt-out instructions.) --DPL bot (talk) 05:57, 23 January 2022 (UTC)

Thanked for 2 edits

Hey! I noticed you thanked me for 2 of my edits relating to a user blocked for WP:NOTHERE. May I ask why you did so? ― Blaze Wolf^Talk_{Blaze Wolf#6545} 18:12, 1 March 2022 (UTC)

"Hey!" Really? "Why?" Really? Try "Why not?" Reverting junk edits is thankless, maybe more thankless than editing, so I dropped a few thanks. This is the thanks I get? (I'd go thank myself, but that's not an option.) You're welcome. -A876 (talk) 19:58, 1 March 2022 (UTC)

Please respond to my question. It's starting to seem like you're stalking me by thanking me for a bunch of edits I did. ― Blaze Wolf^Talk_{Blaze Wolf#6545} 18:30, 1 March 2022 (UTC)

Really? Now thanking is "stalking"? Which universe is this again? Maybe Wp should remove "thanking" completely, for everyone or just for you. Maybe Wp should let you see who views your editing history (but then they'd also have to let everyone see when you check that list). Or maybe Wp should block everyone from viewing your edit history at all...

Does paranoia run deep, or are you editing contentious subjects? Have you heard of the Streisand effect? I did not browse your edit history. But now, by calling attention to yourself, you've attracted me and others to consider doing just that. ((I had considered simply deleting this section that you added, as a favor, to spare you from Streisand effect, but you would have misunderstood such an action.))

Maybe Wp should let you see a list of every edit that I've thanked. ((Why does Wikipedia not let users see that? When I click thanks, Wp confirms, saying "Send public thanks?". How can they call my thanks "public" when they are not currently "public". I (as thanker) can see which edits I've thanked, but only in edit histories and diffs. I cannot see lists of edits, articles, or users I've thanked. You (as recipient or thankee) receive one notification of who thanked them for which edit. Edit histories and diffs do not show you who thanked you, how many thanked you, or even whether anyone thanked your edit(s). No user, registered or not, can browse lists of who I've thanked or who has thanked you; nor can they see who has thanked any given edit, how many thanks it received, or even whether anyone thanked it at all. Also, I cannot revert or remove a thank that I've given.))

Explanation (drumroll please): Some dabbler, "Theleak$22.25", dropped some junk on this my talk page. Someone else reverted it because it was unconstructive and done by a strictly unconstructive user (who was soon blocked). So I "stalked" the dabbler's contribution history to see whether they did anything constructive. (They didn't. Their user page was even deleted.) Much of their other junk had also been reverted; I thanked the users who did that reverting (including you). I reviewed and reverted the rest. (Legal wp:Gravedancing, or damnatio memoriae]). End of story. I could submit this inquiry as comedy, but I didn't. In times like these, a chunk of time has been absorbed... -A876 (talk) 19:58, 1 March 2022 (UTC)

Geez. You sure are taking this harsh. I already have someone who has found out my identity. If someone is thanking me randomly for some edits and they do it a lot, it makes me think that they're stalking my edits. I am not meaning to be harsh to you. I was just concerned, especially since you've been blocked before (i'm a bit more cautious with users who have been blocked before, nothing wrong with them). ― Blaze Wolf^Talk_{Blaze Wolf#6545} 21:17, 1 March 2022 (UTC)

Relax. I never thought thanking could be perceived as stalking, so I'm a little spooked too. I don't "stalk", "out", "dox", or etc. (The people who do tend not to leave footprints.) Some users are "open" (list real-world identification), some are "closed" (obviously pseudonymous), and surely some use non-findable common names (e.g. "John Smith" without middle-name(s) or locality), real-looking names, "borrowed" real names (of non-notable strangers), etc. I can think of no reliable way of unboxing people short of them giving it away. If you suspect stalking, stalk back a little (like you did). Anyone can look at anything; that's not stalking. It would be really strange if I went and thanked every edit you every made. (I wonder whether absurd numbers or rates of thanks might activate a "trigger" in Wikipedia. I've encountered "rate limiting" when reporting [real] violations on Facebook.) I wouldn't put too much stock in finding my one brief block over "edit warring". By the way, I have only one account, and I almost never edited not-logged-in (though you have almost no way of verifying these claims). Sorry if you've had a hard time. I don't know whatothers might have done or why, so I can't apologize for them. -A876 (talk) 01:05, 2 March 2022 (UTC)

It's alright (and I did not stalk you, I'm simply using Discussion Tools which allowed me to subscribe to this thread so I receive notifs whenever someone replies to it). I'm just trying to be safe, and I got a little suspicious of you when I had posted this to your talk page, and then you proceeded to not answer it and thank me some more. ― Blaze Wolf^Talk_{Blaze Wolf#6545} 01:11, 2 March 2022 (UTC)

I have sent you a note about a page you started

Hello, A876

Thank you for creating Pixel binning.

User:North8000, while examining this page as a part of our page curation process, had the following comments:

Nice work! Wikipedia needed this article!

To reply, leave a comment here and begin it with {{Re|North8000}}. Please remember to sign your reply with ~~~~ .

(Message delivered via the Page Curation tool, on behalf of the reviewer.)

North8000 (talk) 21:35, 14 May 2022 (UTC)

@North8000: When I see a blue Notifications or Alerts count, I still clench my teeth a little, because most have been neutral, but too many have been negative. Thanks via the edit-thank buttons are pretty rare; thanks on the talk page little rarer. I appreciate it. An old redlink at Binning (disambiguation) alerted me to its absence. For content, I ripped 1.5 paragraphs out of Data binning (which I've tweaked a little more since) and expanded it a bit (no automatic diff of that, though). -A876 (talk) 05:18, 16 May 2022 (UTC)

Cool!North8000 (talk) 12:15, 16 May 2022 (UTC)

"Tolyltriazole" listed at Redirects for discussion

An editor has identified a potential problem with the redirect Tolyltriazole and has thus listed it for discussion. This discussion will occur at Wikipedia:Redirects for discussion/Log/2022 September 13#Tolyltriazole until a consensus is reached, and anyone, including you, is welcome to contribute to the discussion. Leyo 11:24, 13 September 2022 (UTC)

"OneGet" listed at Redirects for discussion

An editor has identified a potential problem with the redirect OneGet and has thus listed it for discussion. This discussion will occur at Wikipedia:Redirects for discussion/Log/2023 January 27 § OneGet until a consensus is reached, and anyone, including you, is welcome to contribute to the discussion. Aaron Liu (talk) 20:17, 27 January 2023 (UTC)

David Cameron

Please read the information about the parameter at Template:Infobox person/doc. Neighbourhoods of cities are not intended to be included in the parameter; this is well-established. --IWI (talk) 11:33, 4 April 2023 (UTC)

On 2023-03-28, ImprovedWikiImprovment removed the "neighborhood" from David Cameron with comment "City only, per template guidelines". (ImprovedWikiImprovment continues to occasionally do the same; for example, 2 days ago, with comment "No neighbourhoods per template guidelines".) (No mention of where or which guidelines might say "City only, per.." (or its new incarnation "No neighbourhoods per...").)

On 2023-04-04 (3 edits and 6 days later), I undid that edit, putting back the "neighborhood", with comment "(Undid revision 1147078877 by ImprovedWikiImprovment (talk) challenge: i cannot find any "template guideline" limiting birth_place to "city only".)" (To this day, no one has re-removed the "neighborhood".)

On 2023-04-04, you commented here advising "Please read the information about the parameter at Template:Infobox person/doc. Neighbourhoods of cities are not intended to be included in the parameter; this is well-established." (Again, no mention of where or how it is "well-established".)

Let me try to parse that. I gather that not being "intended to be included in the parameter" (birth_place, to be specific) is a passive act on the part of "neighbourhoods of cities". Furthermore, being "well-established" is a passive act on the part of the not-being-intendedness of the inclusion of the "neighbourhoods of [the] cities". I think I've got it. ((The subject should not even be "David Cameron", but "Your recent edit at David Cameron" or even "Infobox field birth_place".))

Template:Infobox person does not mention "neighbourhood" or "only" at all. The "Explanation" for "birth_place" begins with "Place of birth: city, administrative region, country." That's not quite as terse or sharp as implied. It says "Omit unnecessary or redundant details", linked to advice saying (when untangled) "The less information [an infobox] contains, the more effectively it" "summarizes" "key facts that appear in the article", "allowing readers to identify key facts at a glance." It implies limiting the total amount of information there. It restates "wherever possible, present information in short form, and exclude any unnecessary content." It gives a horrible example of "New York City" not needing state to follow it. (No one is from "New York City" unless they live in the subway system; people are from Brooklyn, Queens, Staten Island, Bronx, or Manhattan.) A million rural people live in named places that have 10 to 100 people apiece; millions of people live in named places that have a million people apiece. Tokyo is in more like a region than a place. (To have a consistent granularity, maybe small towns need not be mentioned, just say "western Massachusetts", "central Pennsylvania", or "rural Kansas"; though a name like Smallsville, Kansas implies "rural Kansas" without saying it.)

Anyway, the justification for any edit should be that it improves the article in some way. The justification here would be removing too-fine detail from the infobox that is covered in the article text. (That article mentions Marylebone 3 times. Mentioning Marylebone in the infobox might be a detraction worthy of removal. Most readers have not heard of Marylebone, though everyone has heard of London. The point is taken; I did the revert to say the basis was not obvious; someone please explain it while putting it back (though no one did). (It appears -I- have done a good job of explaining it.) There is no mandate saying "No neighbourhoods" or "City only". Any edit summary or comment using the word "per" (or "as per") brings immediate suspicion of unthinking legalistic behavior and self-consecration. (Principles are better than rules.) -A876 (talk) 22:40, 28 June 2023 (UTC)

Disambiguation link notification for June 25

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

(Opt-out instructions.) --DPL bot (talk) 06:02, 25 June 2023 (UTC)

Disambiguation link notification for August 15

An automated process has detected that when you recently edited Creation myth, you added a link pointing to the disambiguation page Montagnais.

(Opt-out instructions.) --DPL bot (talk) 06:02, 15 August 2023 (UTC)

Peroxycarbonic acid

In this edit to peroxycarbonate, you wrote: "...the anion of a hypothetical peroxocarbonic acid HO–CO–O–OH or the real hydroperoxyformic acid, HO-O-CO-OH" (formatting stripped). AFAICT, the two formulas describe the same molecule, just written in opposite order. Do you recall what distinction you were trying to make? Thanks, Bernanke's Crossbow (talk) 12:19, 19 September 2023 (UTC)

I'm staggered

...by the amount of technical and copy edit work you put in somewhat recently at the tramadol article. At first glance, the thought occurred that it must be vandalism (so large was the aggregate of deletions of all those small ones!). Kudos for your work, and if there is a heavenly reward, please find me there and introduce yourself. (I'll be in a temp. holding cell, for those with significant lost opportunity cost indebtedness, from having spent too much time here.) 98.206.14.11 (talk) 19:54, 14 May 2024 (UTC)

Re Special:Diff/1218319466 (2024-04-10): Years back, people ("Real" Contributors) complained that such edits were hard to review. I haven't had a complaint in a while, but I'm sure someone groans from time to time. Maybe they've realized I only "do that" to a page once, and editors have it better for some time afterward. I am surprised to see a note of appreciation. My "substantive" changes and "trivial" changes come as a set; it's hard to find all of one without the process of doing the other. I change pages to the way I expect to find them; the way everyone deserves to find them; the example that should be set; a baseline for ongoing work. Much of what I did could and should be automatic, standardizing format and ordering. Much is complex, and might "always" need human action, or deep algorithms with human review. I have many expectations, so I have many disappointments or "pet peeves" (not listed) in what I see. I try to change everything that I can change until no improvement or correction is possible. In one edit (or two), not fifty-five piddling quasi-edits.

My edit comment on that edit was "a wording. checked some links and URLs." I now would add "sorted.", because I sorted many parameters. I would also mention the wording that I changed. It is not easy to pick it out amid all the markup changes shown in the default "Wikitext" diff. (Did you find it? I didn't find it because I didn't scan slowly enough.) But the "Visual" diff shows it easily. It was tiny: I changed "Tramadol's use in pregnancy is generally avoided ..." to "Use of Tramadol during pregnancy is generally avoided ..." (plus other corrections of Uppercase ↔ lowercase, -hyphen ↔ −dash, commas, and other nits. Could there be a crappier phrase than the inside-out "Tramadol's use in pregnancy ..."? It starts with a pointless possessive by Tramadol, possessing "use" (the noun). And the preposition "in" doesn't fit. I retained "use" (the noun). I could have said "Using Tramadol during pregnancy ...", because using or taking Tramadol is what's "generally avoided". (I still don't like the remaining passive voice there, but I couldn't find a way to kill it.) Depassivation can make scary results; one must change verbs and add missing nouns: "Tramadol may cause some reversible withdrawal effects in the newborn, so doctors(?) discourage its use during pregnancy." (The folowing sentences are also contorted.) When content is that annoying, it exceeds some threshold and demands to be edited. -A876 (talk) 21:12, 14 May 2024 (UTC)

Twinkle Adds and Removes this Template

Hi A876,

I'm a little confused about how Twinkle adds and removes user warning templates (as you said in this edit). Could you clarify on that? I use Twinkle and I don't see how it removes it. Thanks. Myrealnamm (💬pros · ✏️cons) 14:38, 12 August 2024 (UTC)

@Myrealnamm:The documentation section of Template:Twinkle standard installation says "This template automatically categorizes pages into Category:Templates used by Twinkle." {Twinkle standard installation} is only used on Template/doc pages, to categorize the Template pages and to display a message box in the documentation section of those Template pages.

At Template:Twinkle standard installation, I changed the text that it puts in the message box from "... this template is used in the standard installation of Twinkle." That uses passive voice ("is used"?) and vague wording ("used in"?? "used by", like in the category name, would serve better). But "the standard installation of Twinkle" doesn't "use" templates. It adds (and removes) them. That's how I got to to "... the standard installation of Twinkle adds and removes this template.".

Looking at [Pages that link to "Template:Twinkle standard installation"], limited to Template space, lists 1,799 Template pages that transclude it. For example, Template:R from acronym. But those 1,799 template pages don't directly transclude {Twinkle standard installation}. [Template:R from acronym] transcludes {R from acronym/doc} and Template:R from acronym/doc transcludes {Twinkle standard installation} (and others).

I think the message box at [Template:R from acronym] displays the correct message: "the standard installation of Twinkle adds and removes this template" (meaning Twinkle adds and removes {R from acronym} from pages). (And likewise the 1,798 others.) I think I have it correct that Twinkle adds (and removes) templates. "The tag tab will tag the article, redirect or file with the template(s) of your choice." (from Wikipedia:Twinkle/doc#Tag) A876 (talk) 23:22, 14 August 2024 (UTC)

ArbCom 2024 Elections voter message

Hello! Voting in the 2024 Arbitration Committee elections is now open until 23:59 (UTC) on Monday, 2 December 2024. All eligible users are allowed to vote. Users with alternate accounts may only vote once.

The Arbitration Committee is the panel of editors responsible for conducting the Wikipedia arbitration process. It has the authority to impose binding solutions to disputes between editors, primarily for serious conduct disputes the community has been unable to resolve. This includes the authority to impose site bans, topic bans, editing restrictions, and other measures needed to maintain our editing environment. The arbitration policy describes the Committee's roles and responsibilities in greater detail.

If you wish to participate in the 2024 election, please review the candidates and submit your choices on the voting page. If you no longer wish to receive these messages, you may add {{NoACEMM}} to your user talk page. MediaWiki message delivery (talk) 00:13, 19 November 2024 (UTC)