Feel free to leave a note on this page in the usual manner; I'll probably ping you back with a reply. Just to keep things tidy, I generally only keep stuff on this page if it requires further action from me or you haven't read my reply yet, so check the page history for older conversations if you need to refer back.

I created the spelling and grammar checking project at Wikipedia:Typo Team/moss. If you are responding to an edit related to special characters, language tags, or manual of style compliance, HTML cleanup or markup issues, it might have been motivated by some report generated by that project. -- Beland (talk) 03:52, 9 July 2021 (UTC)Reply[reply]

Hi, just wanted to let you know that I have decided not to pursue this merge. I did a lot of work to reduce keyboard layout/keyboard technology/computer keyboard triplication, ending with clearing out the last of these to make it a redirect. It has all been undone and I don't have the inclination to pursue it to the bitter end, I just don't care that much. I can't see why the RTM that we have discussed would have any different result. If you want to go ahead anyway, feel free. --John Maynard Friedman (talk) 10:56, 26 August 2021 (UTC)Reply[reply]

In Nilpotent Lie algebra, you introduced recently the awful formula ((math|''n'' ∈ <math>\mathbb{N}</math>)). I have changed it into <math>n\in\mathbb{N}</math>. Please, avoid mixing latex and html rendering in the same formula.

Happy new year. D.Lazard (talk) 09:42, 31 December 2021 (UTC)Reply[reply]

@D.Lazard: Yeah, it's definitely more readable when it's all in LaTeX. I've just been going through making articles compliant with MOS:BBB, which only requires changing over the blackboard bold characters. I had been converting relatively simple formulas to LaTeX completely, but it got a bit time consuming, and some longer formulas were quite daunting. MOS:MATH doesn't say anything about not mixing the two, so my thinking was that the mixed style was at least MOS-compliant, and we could go back and convert the rest of the markup later. I was hoping some other editors skilled in LaTeX would be able to help with that. Would you be able to help with some conversions? I see 88 articles with mixed markup (not all of which are from my edits) and several hundred articles with ℝ, ℤ, or ℂ. We could also add a note to MOS:MATH saying not to mix LaTeX and HTML, and resolve to do blackboard-bold-motivated conversions in one step rather than two? -- Beland (talk) 18:59, 31 December 2021 (UTC)Reply[reply]

Well, I added the note to MOS:MATH and put the mixed markup pages on my personal cleanup todo list. It may be a few months before I get to all of them, as there are thousands of articles in my cleanup queue. -- Beland (talk) 22:36, 2 June 2022 (UTC)Reply[reply]

Hello! I have recently been fixing typos from moss and I see there is a list of possible chemical formulas that don't use subscripts. I was wondering a couple of things:

• what do the numbers on the left of the entries mean?　For example 16/5 - H3S10

• are they for reference only, or would it be in any way helpful to investigate and tag them with their common names, if they are indeed chemical formulae?

Thanks and happy typo hunting 😄 rbstrachan (talk) 19:41, 5 August 2022 (UTC)Reply[reply]

Greetings! The first is the number of instances this possible formula was found, and the second is the number of pages. So in this instance, H3S10 was found 16 times across 5 pages. It looks like Graeme Bartlett already determined it is not a chemical formula and made a redirect for H3S10, so I took that off the list. That's a preferred way to fix items that are not chemical formulas if they have articles. The spell checker won't care if you make it a link or not, but it might help readers to do so.

Yes, the general intention is to investigate each, determine if they are actually a chemical formula, and update the markup accordingly. There's a full list of suggestions of what to do at Wikipedia:Typo Team/moss#Chemical formulas.

The idea of using the common name to link these to articles is interesting, and something I hadn't really thought about. The spell checker doesn't really care if there's a link or not; it only looks at the display text. So, it will complain about both "H20" and "H2O" ("[[water|H2O]]") because the manual of style says it should be H₂O (using ((chem2))). Turning that into a link would make it H₂O, which is a bit ugly but potentially helpful to the reader. Sometimes there's a very technical context, and the problem text shows up in chemical equations or something, where putting words (like "water") wouldn't make sense. In that case, we probably don't need a link anyway, and fixing the typography is all that's needed. Sometimes having the name instead of the formula would make the article easier to read, so switching it out and making it a link would be an improvement; you'd have to use your judgement.

I suspect most or all of these either aren't chemical formulas or don't have chemical substance articles we can point to, so the suggestion to add links to chemical articles might apply more to Wikipedia:Typo Team/moss#Known chemical formulas that don't use subscripts, where there usually is an article.

Poking at the "Possible" list just now, I had a bit of trouble figuring out which articles the spell checker was complaining about. I put a note at the top explaining how to use the "insource://" trick, which should be sufficient until I can get those included in the report automatically (or we empty out this list). Thanks for your interesting question and your ongoing cleanup work! -- Beland (talk) 08:09, 8 August 2022 (UTC)Reply[reply]

(talk page stalker) Just out of curiosity, is there a comparable list of chemical formulas that don't contain numbers (like HNO and NaCl), and therefore could be mistaken for words? BD2412 T 22:39, 8 August 2022 (UTC)Reply[reply]

That's an interesting question! While thinking about it, I thought of another, related question.

While converting chemical formulae written with HTML <sub> tags to use the ((chem2)) template, should element names such as In, Fe, etc. and chemical formulas that don't contain numbers, such as HNO and NaCl as you mentioned, also be converted?

On one hand, I'm not sure that it's worth adding the bulk of a template for things that don't technically need them and which don't benefit from a visual improvement to the way they are displayed. On the other hand, it may reduce the number of false positives for projects like WP:TT/M.

One of the main reasons that I can see for converting HTML tags to the ((chem2)) template is to make it possible to search Wikipedia for chemical formulae without having to resort to regex.^[1] Having said that, since elements and most basic chemical formulas don't contain numbers, they don't contain <sub> tags, so making them use the ((chem2)) template would not do anything to make them more easily searchable.

In regards to both of our questions I do vaguely remember reading somewhere that the Moss scripts ignore capitalised words, and as elements and chemical formulas (should) always start with a capital, these may not be issues in the first place. 😅

😊 — rbstrachan (talk) 23:34, 8 August 2022 (UTC)Reply[reply]

That's right, for spell-checking purposes moss ignores capitalized words made of only letters, on the assumption they are proper nouns. (These problem formulas are actually pulled from a list of ignored but suspicious words.) Even when I stop doing that (because I want to verify the spellings of proper nouns) most of the ones without numbers would have articles or redirects, so they would still be ignored. The only reason they became an issue for moss is that not using subscripts violates Wikipedia:Manual of Style/Chemistry#Symbols and Unicode subscripts violate MOS:SUBSCRIPT.

There may be other reasons to wrap these formulas, though, such as for accessibility. It doesn't look like they are currently adding alt text, but if you use "auto=yes" with ((chem2)), it does link each element symbol to the article on that element. I'm not sure if that's something we should be doing everywhere or nowhere? It might be worth checking with Graham87 (who uses a screen reader and who helped figure out how to handle fractions) or Wikipedia:WikiProject Accessibility or Wikipedia:WikiProject Chemistry to see if anyone has any particular preferences. -- Beland (talk) 01:36, 9 August 2022 (UTC)Reply[reply]

Thanks, I don't have any opinions on these issues accessibility-wise ... I guess what to do depends on context. Graham87 02:17, 9 August 2022 (UTC)Reply[reply]

👍 -- Beland (talk) 02:42, 9 August 2022 (UTC)Reply[reply]

Hebrew is written right to left, unlike English which is written left to right. So the character following a Hebrew letter like Aleph will appear to its left rather than to its right. This causes a problem when the Hebrew letter is intended to be part of an English text rather than a Hebrew text. You have twice ignored this fact when replacing ℵ₀ with א₀ at Cardinality of the continuum.

More generally, you should always look at the resulting text as it is displayed to the ordinary user and make sure that it is what you want it to be. JRSpriggs (talk) 14:45, 31 January 2023 (UTC)Reply[reply]

@JRSpriggs: Ah, thanks for the note! I hadn't noticed that I had made the same edit before. That's surprising that the character and the HTML entity have different text direction behavior; I'll be on the lookout for that in the future. -- Beland (talk) 16:35, 31 January 2023 (UTC)Reply[reply]

In this edit, what is the justification for replacing my use of non-breaking hyphens with breaking hyphens? It's not just you. I've just checked over other places in this article as well as in other articles in which I had originally used non-breaking hyphens, and found that the non-breaking hyphens have mostly been replaced. This results in undesirable results where something like "Fig 4-
5" would show up. Prokaryotic Caspase Homolog (talk) 10:24, 27 June 2023 (UTC)Reply[reply]

@Prokaryotic Caspase Homolog: It does not seem like non-breaking hyphens are actually needed for short character sequences in article text. My browser, for example, breaks on spaces not hyphens in this block, no matter how narrow I make the window:

Fig 4-5 Fig 4-5 Fig 4-5 Fig 4-5 Fig 4-5 Fig 4-5 Fig 4-5 Fig 4-5 Fig 4-5 Fig 4-5 Fig 4-5 Fig 4-5 Fig 4-5 Fig 4-5 Fig 4-5 Fig 4-5 Fig 4-5 Fig 4-5 Fig 4-5 Fig 4-5 Fig 4-5 Fig 4-5 Fig 4-5 Fig 4-5 Fig 4-5 Fig 4-5 Fig 4-5

There is a general guideline to keep markup simple. Using the ASCII hyphen makes things more WYSIWYG, for example making it easier for editors to use web browser "find in page" functionality to find the text they see on the page in the wikitext. Sometimes it also makes a difference for search engines.

In my experience, editors are generally supportive of (or apathetic to) avoiding numeric HTML entities unless absolutely necessary. Most editors don't know what HTML entities in general are, and even those that do generally haven't memorized what "8209" means. I actually run an automated scan looking for numeric HTML entities that should be simplified, which picked up Special relativity and is why I edited it. I convert 8209 to ASCII hyphens out of course because the non-breaking variety is generally not needed.

There is also a general aversion to using raw characters when they are visually indistinguishable from common characters, so using the raw non-breaking hyphen character is not a great option. Sometimes I use named HTML entities in these situations, because even if they look weird, people can generally get the idea. In this case MOS:HYPHEN actually recommends ((nbhyph)). Templates have the advantage of allowing for on-wiki documentation, and it's kind of unavoidable to learn how they work if you edit Wikipedia long enough. My automated scans also leave them alone, because they are generally used properly and on purpose.

In this case, the phrase also contains a non-breaking space, and if that and the non-breaking hyphen were both necessary to prevent problems, I would write ((nowrap|Fig 4-5)) which is pretty close to WYSIWYG. But my scans leave &nbsp; alone because they are extremely common, the raw character can't be used because it's visually identical to an ASCII space, and at least they aren't numeric. But my advice would be to use an ASCII hyphen either way, since it seems to work fine. -- Beland (talk) 17:14, 27 June 2023 (UTC)Reply[reply]

My experience is different (Interesting!). I have quite often seen breaks on hyphens in my Fig numbering, but they occurred infrequently enough on spaces that I generally haven't bothered with &nbsp;. But ((nowrap|Fig 4-5)) is good, because it will protect both the spaces and the hyphens. Thanks for the reasoned discussion. Prokaryotic Caspase Homolog (talk) 21:34, 27 June 2023 (UTC)Reply[reply]

You've made several recent edits to mathematical pages with edit summary "convert special characters found by Wikipedia:Typo Team/moss" which were regressions, replacing glyphs with incorrect alternatives that have a different meaning, removing typographically significant whitespace, etc.

Please don't make try to "fix typos" in mathematical typography unless you are careful and know what you are doing. Otherwise you just leave a mess behind. –jacobolus (t) 21:18, 14 July 2023 (UTC)Reply[reply]

In particular, please do not replace the set minus glyph ∖ with reverse solidus \, and stop taking out thin spaces that other authors intentionally added for legibility. And maybe try to check the output of your script more carefully; careless use of automated tools costs an order of magnitude more time for someone else to check and clean up than it initially takes for you to make the edits. –jacobolus (t) 21:31, 14 July 2023 (UTC)Reply[reply]

@Jacobolus: Sorry, looking back in my notes it appears I had intended to ask around before changing the set-minus character to backslash. I have opened a discussion at Wikipedia talk:Manual of Style/Mathematics#Changing special symbol guidance which explains the rationale for potentially flipping the guidance on this and other characters. I will have to go back and look at the whitespace changes in more detail; I tidied up some of them by hand and thought I had done that correctly. Thanks for your vigilant attention to detail. -- Beland (talk) 21:56, 14 July 2023 (UTC)Reply[reply]

Sorry to be sharp here. I just am generally tired out with all of the bots and script-assisted editors running around twiddling stuff project-wide in ways that are at best marginal improvements and often make a mess. It's not anything personal. –jacobolus (t) 00:16, 15 July 2023 (UTC)Reply[reply]

@Beland can you please stop changing the width of spaces? You keep deleting thin spaces, narrow non-breaking spaces, etc. and replacing them with full-width spaces in the middle of mathematical typography. You should not do this without consensus. Examples: special:diff/1192008011, special:diff/1192004819. –jacobolus (t) 04:24, 27 December 2023 (UTC)Reply[reply]

@Jacobolus: My goal is to make the wikitext simpler and easier to read per MOS:MARKUP; this numeric HTML entity is quite obscure. Comparing full, narrow, and no space versions of the markup from Schläfli symbol:

| p | q | r | ... | z |

| p | q | r | ... | z |

|p|q|r|...|z|

This all actually look find to me. I'd lean toward the no-space option, because it's nice and compact, and also the cleanest wikitext. Which do you prefer? If you think the narrow spaces are needed, we can use ((nnbsp)) instead of the numeric HTML entity.

For unit sphere, I think the equations I changed look a lot better after I put them in ((math)). -- Beland (talk) 04:58, 27 December 2023 (UTC)Reply[reply]

@Beland I would recommend just leaving things alone unless you want to go carefully manually audit every one. Usually people who carefully choose a specific width of spaces do so for a reason. On my particular browser/font it looks like no-space and narrow no-break spaces render the same, but it's plausible there's a difference in someone else's browser; the full-width spaces seem too big. I changed unit sphere to all LaTeX instead. –jacobolus (t) 05:01, 27 December 2023 (UTC)Reply[reply]

Looks like the latest round of HTML entities was added in this edit by an anonymous editor, so it seems unlikely we could know the rationale. I took a look in Chrome, and the no-space version technically doesn't have any overlapping characters, but it does look a bit crowded. So if full spaces look too big, sounds like keeping thin spaces are a good choice. I kept those but used a template instead of a numerical HTML entity for clarity. -- Beland (talk) 16:34, 27 December 2023 (UTC)Reply[reply]