Beland

Feel free to leave a note at the bottom of this page in the usual manner; I assume you'll be subscribed to the thread to get notified about replies. 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) 16:48, 6 June 2024 (UTC)

Coherent style for formulas

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)

@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)

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)

Did a few of these today. Note to myself, use edit summary:

per [[MOS:FORMULA]], do not mix LaTeX and {{math}} in the same expression

-- Beland (talk) 15:44, 12 March 2024 (UTC)

List of possible chemical formulas that don't use subscripts

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)

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)

(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)

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. 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)

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)

References

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)

👍 -- Beland (talk) 02:42, 9 August 2022 (UTC)

Watch out for Hebrew letters

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)

@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)

Please stop converting thin spaces to ordinary spaces in mathematical typography.

Edits such as special:diff/1219321937, which in part converted some explicit thin spaces in mathematical typography to ordinary spaces, are not helpful. If another editor explicitly chose a size of space to stick into a formula, you should assume they did so for an intentional reason and not automatically second-guess that decision. Often regular spaces leave formulas written using plain wikimarkup (e.g. in {{math}} templates) looking incorrect, and explicit hair spaces or thin spaces make the formula appear more correctly. –jacobolus (t) 01:53, 17 April 2024 (UTC)

@Jacobolus: In my experience, thin and hair spaces usually aren't necessary, and can sometimes cause excess whitespace. This is a good reason to keep markup simple, along with reducing the skill burden of learning wikitext so we can attract and retain editors. The version of Tensor with those removed renders correctly for me. Sometimes different operating systems and web browsers and fonts render characters like these in an overlapping way; I would consider that a bug in that stack which should be reported and fixed. But once that happens, we don't need to keep these characters around forever. Does the version without thin and hair spaces render incorrectly for you? It looks like Cedar101 may have been the first editor to introduce this character in 2017; pinging them to see if they are (still) having typographical problems. -- Beland (talk) 02:12, 17 April 2024 (UTC)

I am extremely dubious of the evidence-free claim that editors of very mathematical pages are deterred by the presence of occasional explicit unicode characters. But I can tell you for certain that good editors are highly discouraged by having their careful deliberate choices trampled by lazy automated regressions.

The version of Tensor with the full-sized spaces is definitely worse than the version with thin spaces, and it is clear why the thin spaces were originally chosen. If you feel like it you are welcome to rewrite the whole page using LaTeX instead, which looks better and has simpler markup, but please stop automatically breaking people's intentional choices in mathematical typography. –jacobolus (t) 03:27, 17 April 2024 (UTC)

@Jacobolus: Ah, your comment pointed out that I added space rather than removing it, which I missed. I would have expected the latter to generate complaints about overlapping text characters. I'm surprised that the complaint is that there was too much space; a full space is normally a safe substitution. It turns out I actually get overlapping characters myself with no space there, so I'll see what I can do to get that fixed. In the meantime, I'll use {{thinsp}} since those are generally a sign that someone is intentionally using a thin space in wikitext. (And it's nice that templates can have documentation to explain what they mean and why they are being used.) HTML entities are often automatically imported from other environments rather than being inserted intentionally.

A high difficulty of editing can result from an accumulation of small difficulties, which new editors sometimes must confront all at once to make useful contributions. Much of the point of wikitext is to spare editors from having to learn HTML, though it's reasonable to expect deeply involved math editors to know LaTeX. But it seems a bit much to expect, say, a math professor who already knows LaTeX to learn wikitext and HTML syntax if one of those isn't really necessary. Perhaps the added difficulty is more pronounced for articles where there isn't already a lot of complicated mathematical markup, but that is most of them. -- Beland (talk) 16:34, 17 April 2024 (UTC)

Wikitext is built on HTML, and HTML entities are a basic feature. Using {{thinsp}} instead of   is not substantially beneficial. The template is not inherently more accessible, being a weird english-wikipedia-ism that someone has to go do a search to learn about instead of a common standard used across the web.

If you are writing a new page, feel free to use either one. But please don't do automatic replacements of one for another (not sure if you were planning on it). At best it creates pointless watchlist spam. From what I can tell this kind change does not have (and should not have) the backing of any sitewide policy. –jacobolus (t) 17:12, 17 April 2024 (UTC)

@Jacobolus: I generally assume that editors have to learn how to use Wikipedia templates, because they are used in pretty much every article, usually quite frequently. Wikification, where we replace web-standard HTML tags (which do work without modification) with Wikipedia-specific markup, is a general directive, and indeed the whole point of Wikipedia:WikiProject Wikify. That wouldn't be necessary if we weren't trying to save people from learning HTML. I wasn't planning to mindlessly swap thin space HTML entities for templates, but at some point I will probably do a pass through the entire project to remove inappropriate ones. As you can see, most of the existing instances are not in math articles, are not fixing problems with overlapping characters, and do not align with our usual style. -- Beland (talk) 17:28, 17 April 2024 (UTC)

This seems like a huge waste of time. Most of the examples of thin spaces from your link seem deliberate, and don't seem to be harming anything. –jacobolus (t) 17:33, 17 April 2024 (UTC)

@Jacobolus: Well, the first instance, on Kazakhstan, actually is breaking the citation template, causing the string "&thinsp," to show up in the article. Even if it was working properly, a non-ASCII space would be polluting downstream data for citation consumers. (For example, journal web sites that list all Wikipedia references to papers on that paper's page.) The Pirate Bay is also polluting a citation template.

In the second article, Moon, the usage violates MOS:UNITNAMES, which specifies a full, non-breaking space between a number and a unit abbreviation. It looks sloppy to have different amounts of whitespace in different measurement expressions.

In the third article, Amazon (company), the usage violates MOS:$, which specifies no space after "US$" and a full, non-breaking space before "million". It looks sloppy to have different amounts of whitespace in different instances of currency expressions. Apartheid is breaking the same rule.

And so on. -- Beland (talk) 22:21, 17 April 2024 (UTC)

Removal of special characters

The changes you are making such as here and here, such as removing   and ⁠ make changes to the intended formatting. What is problematic about these that they need to be changed? —Quondum 14:25, 14 November 2024 (UTC)

Greetings, and thanks for your attention to detail! There is a general mandate from MOS:MARKUP to keep markup simple, and to use wiki markup instead of HTML markup (like HTML entities) where there are equivalents. Various templates can be used to prevent word wrapping where needed, though in some cases, preventing word wrapping causes other problems.

Having a non-breaking space next to a regular space does not prevent breaking, so I tend to remove those automatically. In the case of in Binary prefix, I presume the nbsp;s are there to add horizontal space between numbers like "0.9766" and percentages like "(−2.3%)". Given the parentheses, this space is not needed for clarity, and generally not included on English Wikipedia in this type of context. The extra spaces make the content wider, which in tables on narrow screens can cause horizontal scrolling or unnecessary word wrapping.

Regarding ISO/IEC 80000...NoBreak; isn't used anywhere on English Wikipedia other than the three articles I removed it from yesterday (except for special cases, like discussing the entity itself). I went back today and tested to see if browsers would break on a dash in the middle of numerical digits. Firefox does not, but Chrome does. However, making my Chrome window as narrow as possible causes horizontal scrolling in the Overview table, which is an even worse experience for readers than awkward word wrapping. To prevent this, I removed all the non-breaking directives from that table. I also added some soft hyphens to prevent some long words from making certain columns gratuitously wide. That should minimize but not eliminate breaking inside ISO and IEC document names. Does that look like a reasonable solution? -- Beland (talk) 15:52, 14 November 2024 (UTC)

From what you say, you took into account that the   was intended in some cases to increase space width, so your tweaks to achieve a preferred result is great. From the initial edit comment I thought perhaps it was simply an automated change.

The ⁠ was me trying to create cohesive (nonbreaking) names, but your consideration of narrow screens makes sense. I had neglected that entirely, and inside tables that becomes much significant. Besides, it was a sort of experiment by me, and if it does not make sense in general, it probably doesn't make sense in any given article. So I think your approach makes sense.

On the ⁠, I have found it to be a workable way to suppress breaking where it is really not wanted. The different major browsers (Firefox, Chrome, Safari) all have different breaking behaviour, and this gives a way of ensuring that they behave similarly. And while your comment about non-use in article wikitext applies, I have used ⁠ for benefit in some templates, specifically to avoid breaking between their output and adjacent text (see {{tmath}}, for example, where wrapping was happening between the output and adjacent punctuation). Given that this is entirely something that I found through experimentation (borne of frustration at wrapping behaviour), if you have any comment on this use, it would be most welcome. —Quondum 16:23, 14 November 2024 (UTC)

For articles, I generally find the wikitext alternative {{nowrap}} to be more readable. Templates do a good job hiding complex HTML from article editors who benefit from simple markup, so I generally leave the HTML entities in templates alone. However, when crafting templates you may find the CSS method of wrap-suppression more readable and probably useful in more situations. (See Template:Nowrap/doc#Technical details.) -- Beland (talk) 16:48, 14 November 2024 (UTC)

{{nowrap}} in a template is insufficient for the purpose, where the addition of ⁠ is at least hidden from editors. Anyhow, if you don't immediately see an issue, it is fine. —Quondum 19:14, 14 November 2024 (UTC)

Term fascism (Talk:Donald Trump and fascism#Fascism?)

Hi. I'm sincerely disappointed that, within the pages on Trump, the term fascism is used without knowing in detail the true roots of fascism (it was, unfortunately, born in Italy), but I don't want to start a new discussion about this (Talk:Donald Trump and fascism#Fascism?). If you all agree, I would like to change the title to something less direct. JacktheBrown (talk) 02:17, 17 November 2024 (UTC)

You have already raised this issue at Talk:Donald Trump and fascism#Current title. That is the appropriate forum to discuss a page move, not user talk pages. (I'm not sure who you mean by "you all".) As Artem_P75 mentioned, this article has just undergone a community process and the current title was affirmed. You can read that discussion for yourself at Talk:Donald Trump and fascism/Archive 1#Requested move 29 October 2024. I have no particular opinion on the title of this article, but I think it would be inappropriate to ask the community the same question again unless the article or real-life facts have substantially changed, or several years have passed. -- Beland (talk) 02:49, 17 November 2024 (UTC)

"You all" = active users on the page; I should have used a more appropriate term (I was very sleepy, forgive me). Thank you very much for your reply. JacktheBrown (talk) 08:10, 17 November 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:05, 19 November 2024 (UTC)