User talk: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)[reply]

I have kept archives of Q&A on closures I've done for Wikipedia:Closure requests at User talk:Beland/archived closures, in case they are needed for future discussion. -- Beland (talk) 23:22, 14 October 2025 (UTC)[reply]

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)[reply]

@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)[reply]

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)[reply]

@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)[reply]

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)[reply]

@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)[reply]

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)[reply]

@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)[reply]

"Colony of Trinidad and Tobago"

Hi. I noticed that you've added "Colony of Trinidad and Tobago" as the birth place for a lot of people. There was never an entity by that name - from the time the two states were united only the name "Trinidad and Tobago" was used. It's a bit like talking about "the Republic of the United States of America" - sure, the country's a republic, but that isn't the formal or common name. Guettarda (talk) 22:54, 27 November 2024 (UTC)[reply]

If I remember correctly, the "nationality" field is considered redundant if legal nationality was the same country as birthplace, and I was removing redundant fields. I remember adding in this case "British Empire" to clarify that people born in Trinidad and Tobago when it was a colony have British nationality. It doesn't particularly matter on its own if that field says "Trinidad and Tobago, British Empire" or "Colony of Trinidad and Tobago, British Empire".

For death place, we often omit the country or other larger-scale entities for the sake of brevity, but just writing "Trinidad and Tobago" would be a bit confusing it if it's referring to the British Crown Colony. It's also confusing if the birthplace refers to the colony and the death place refers to the sovereign country with the same phrase "Trinidad and Tobago". If we always use "Colony of Trinidad and Tobago" to refer to the colony and "Trinidad and Tobago" to refer to the sovereign country, that seems a bit less confusing. We could say that "Colony" here is not part of the name so much as a disambiguation phrase, so in principle we could write "Trinidad and Tobago (colony)" instead, but that seems a bit clunkier.

Even more important is to link the country name to the right article. For example, I link to Gran Colombia for people born there 1819-1831, because linking to Colombia gives the erroneous impression they were born in the modern state, but the two had different borders and some areas are now part of different sovereign countries (which I often add a parenthetical to identify). Both those entities were officially called "Republic of Colombia", but that's just a redirect to the modern entity, and so isn't a suitable link target.

Usually there's a separate article on the colonial period (e.g. Massachusetts Bay Colony), though in this case, Colony of Trinidad and Tobago is a redirect to History of Trinidad and Tobago. That article does use the capitalized phrase "Colony of Trinidad and Tobago", and that's the target for the incoming redirect. I do see the phrase "Colony of Trinidad and Tobago" and "Crown Colony of Trinidad and Tobago" capitalized that way in professional academic journals when I do a search on Google Scholar, though a lowercase "colony" is more common. I would infer that "Colony of Trinidad and Tobago" as a name is not incorrect, even if it is not official and not the most common form. It seems useful for disambiguation in infoboxes, but I'm open to suggestions. -- Beland (talk) 23:46, 27 November 2024 (UTC)[reply]

For starters, "Crown Colony of Trinidad and Tobago" is incorrect. The type of government that developed in Trinidad, and which was copied elsewhere, came to be called "crown colony government". You could apply it to Trinidad and Tobago between 1889 and roughly 1920, but it's a term political scientists and historians use. And it's problematic to draw conclusions based on capitalisation of the word "Colony", given that Victorians regularly capitalised nouns that Wikipedia would never capitalise. And if we just chose to follow contemporary usage, we'd use "colony of Trinidad", because Tobago was pretty much ignored until the 1950s.

I remember adding in this case "British Empire" to clarify that people born in Trinidad and Tobago when it was a colony have British nationality. For starters, using "British Empire" for people born outside the UK, but not people born in it makes no sense unless we think of people from "the colonies" as somehow lesser. It was normal to consider "colonials" less human in the middle of the 20th century, but it's no ok today.

Beyond that, I don't think you're clarifying anything for readers. British nationality law is complicated, and it wasn't codified until 1948, and was changed radically in 1962 (before independence). Someone born in Trinidad and Tobago before 1948, or between 1948 and April 1962 or between April and August 31 1962 presumably did not have the same legal status. And it's even worse if you're talking about Bajans or Grenadians.

Inventing an entity called the "Colony of Trinidad and Tobago, British Empire" doesn't clarify things. Instead, it's more likely to reinforce false perceptions that our readers probably have already. While "colony" isn't incorrect, it's an imprecise term that means something very different from the common understanding of the word; unlike the US, Canada, or Australia, there was no real colonisation.

Gran Colombia is a totally different entity from modern Colombia. "United Kingdom (European Union)" from "United Kingdom (Brexit)" is probably a closer comparison, though in practical terms independence less disruption than Brexit. We also don't disambiguate people born in the Fourth French Republic from those born in the Fifth French Republic, despite the differences in the country's borders.

Finally, "colony" and "empire" reinforce a lesser, subaltern position. While they are factual descriptors, using them when they aren't precisely necessary isn't good. Guettarda (talk) 03:27, 28 November 2024 (UTC)[reply]

How would you prefer to convey the notion "this person was born in Trinidad and Tobago and had British nationality at the time of their birth"? -- Beland (talk) 05:03, 29 November 2024 (UTC)[reply]

Template:Infobox legislation

I've reverted part of your edit to {{Infobox legislation}} based on the comments at Template talk:Infobox legislation#Please restore the image function to this template. While I'm not sure that an image is helpful I really think a full discussion should be held first. Cheers. CambridgeBayWeather (solidly non-human), Uqaqtuq (talk), Huliva 17:08, 30 November 2024 (UTC)[reply]

By the way is it a feature of your talk page that I can't start a new section and have to edit the full page? More likely my browser is acting up. CambridgeBayWeather (solidly non-human), Uqaqtuq (talk), Huliva 17:08, 30 November 2024 (UTC)[reply]

It's certainly not anything I've done intentionally to my talk page. It's a bit frustrating to have something reverted in order to have a discussion "first" when the only reason I made the change was in response to...a discussion. But such is the nature of consensus-building unless everyone is personally informed about every single proposed change. -- Beland (talk) 17:24, 30 November 2024 (UTC)[reply]

Experimenting with the OpenAI API for the moss project

Hi Beland, I experimented a little to explore how the OpenAI API could be used to help with the moss project. I wrote another javascript script to extract sentences with unknown words from the last few entries of Wikipedia:Typo_Team/moss/D#Dan_-Danb and then asked the AI model to assess the unknown words and provide correction suggestions in case there is a problem. I got the following results:

Results

Text: "Brain Awareness Week (#brainweek) is the global campaign to increase public awareness of the progress and benefits of brain research."
Word to check: "brainweek"
AI response:
{
  "word": "brainweek",
  "misspelled": true,
  "correct_spelling": "Brain Week"
}


Text: "Named by US-ACAN for Gerald J. Schoofs, radioscience researcher at Byrd Station, summer 1965-66."
Word to check: "radioscience"
AI response:
{
  "word": "radioscience",
  "misspelled": true,
  "correct_spelling": "radio science"
}


Text: "Pe'er is also involved in the Human Cell Atlas as a member of the organizing committee, co-chair of the Analysis Working Group, and member of the Human Lung Cell Atlas initiative, and serves on the scientific advisory board of scverse."
Word to check: "scverse"
AI response:
{
  "word": "scverse",
  "misspelled": false,
  "correct_spelling": null
}


Text: "Both are collected short-short stories and schetches."
Word to check: "schetches"
AI response:
{
  "word": "schetches",
  "misspelled": true,
  "correct_spelling": "sketches"
}


Text: "In Cambridge, he served numerous posts in the local government, including selectman, constable, tythingman, and grand juror."
Word to check: "tythingman"
AI response:
{
  "word": "tythingman",
  "misspelled": true,
  "correct_spelling": "tithingman"
}


Text: "The Danaes were based on the design of the preceding C class series, but were lengthened by 20 feet (6 m) to allow a sixth 6-inch (152 mm) gun to be worked in between the bridge and the forefunnel."
Word to check: "forefunnel"
AI response:
{
  "word": "forefunnel",
  "misspelled": true,
  "correct_spelling": "fore funnel"
}


Text: "The major facilities available are waiting room, free wifi from railwire, computerized reservation facility and vehicle parking."
Word to check: "railwire"
AI response:
{
  "word": "railwire",
  "misspelled": false,
  "correct_spelling": null
}


Text: "During the 1950s through 1970s, the fair's multivaried attractions included New England Village, Dutch Village, lumberjack competitions, oxen draws, sheep shearing contests, music and dancing, puppet shows, animal petting zoos, rides and games, displays of farm machinery, and food and livestock exhibits and judging."
Word to check: "multivaried"
AI response:
{
  "word": "multivaried",
  "misspelled": true,
  "correct_spelling": "multifaceted"
}

System prompt for AI model

Determine if a specific word in a provided text is misspelled and, if so, provide the correct spelling.

# Steps

1. Verify the spelling of the word to check against a standard English dictionary.
2. If the word is misspelled, determine the correct spelling.
3. Provide a conclusion on whether the word is misspelled or correctly spelled.
4. If misspelled, offer the corrected spelling.

# Output Format

- A JSON object with the following structure:
  ```json
  {
    "word": "[word in question]",
    "misspelled": [true/false],
    "correct_spelling": "[correct spelling if misspelled, otherwise null]"
  }
  ```

# Examples

**Example 1**

- Input: 
Text: "The quick brown fox jumps oveer the lazy dog."
Word to check: "oveer"
  
- Output:
  ```json
  {
    "word": "oveer",
    "misspelled": true,
    "correct_spelling": "over"
  }
  ```

**Example 2**

- Input:
Text: "The quick brown fox jumps over the lazy dog."
Word to check: "fox"
  
- Output:
  ```json
  {
    "word": "fox",
    "misspelled": false,
    "correct_spelling": null
  }
  ```

# Notes

- Ensure that only the specific word in question is evaluated for spelling accuracy.
- Provide clear and concise spelling corrections if applicable.

I'm not sure about the first one (is it a hashtag on social media?) but the others seem to be correct. Do you think something like this could have uses for the moss project? Phlsph7 (talk) 14:57, 13 December 2024 (UTC)[reply]

This particular batch is from the "ME+" sublist, which are words that moss has identified as coMpound English words, basically two dictionary words stuck together. It's often unclear if the words should be separated or if the compound should be added to the dictionary, and determining that can take a Google Scholar or Google Books search. (Or not, if separate words sounds better and the volunteer decides it's more important to go fast than add every compound seen in the wild to Wiktionary.) I'd have to manually review whether "scverse" should be "SCVerse", if "tythingman" is a compound in British English or something, maybe put "varied" instead of "multifaceted". But these are the sorts of things that human editors do now with the moss listings, and the AI suggestions might speed that along. -- Beland (talk) 20:35, 13 December 2024 (UTC)[reply]

Oh, I should also say that moss could generate suggestions for ME on its own, if we're happy with the automatic suggestion being splitting the word into the two dictionary words. It can also supply suggestions for T1, since those are potential typos that are an edit distance of 1 away from a dictionary word. Certain other sublists like TE, moss would not have obvious suggestions for, and OpenAI might be more of a help for those. -- Beland (talk) 20:38, 13 December 2024 (UTC)[reply]

Formatting citations

Per WP:WHENINROME, editors should follow the existing citation style on an article. When editing an article that already uses CS1 citation templates, like Alewife station, please add any new citations with CS1 templates as well. Adding unformatted and incomplete citations, like you did with these edits, is not helpful. Pi.1415926535 (talk) 02:16, 11 January 2025 (UTC)[reply]

I think it's a heck of a lot more helpful than not citing sources, or not adding content at all. Converting citation formatting is something a bot can do. -- Beland (talk) 03:25, 11 January 2025 (UTC)[reply]

Why do you think this guideline does not apply to you? Someone else still has to take the time to format the citation. There is not a bot that formats citations, but there are tools you can use when you make edits, like Wikipedia:RefToolbar. Either follow the guideline and properly format your citations, or do not make the edits in the first place. Pi.1415926535 (talk) 20:14, 11 January 2025 (UTC)[reply]

Guidelines apply equally to everyone. The question is how to respond to contributions that don't follow them all perfectly. We've accumulated thousands of rules content is supposed to follow, and it would be unreasonable for any editor to be expected to know them all. In some cases, it really is better to delete a contribution and follow up with the editor rather than leave in non-compliant content. That includes biased content, stuff that's so badly written it's unclear what it means, and unsourced claims where you don't want to seek sources yourself or tag as "citation needed".

For typos and cases of minor style violations, though, it's much better to accept the contribution and fix the issue. I don't have a problem with educating new editors in ways that could reduce the overall number of volunteer-hours needed, but I find it alarming that anyone would be going around discouraging editors from making informative, neutral, sourced contributions rather than thanking them for that content. We have a long-term problem with editor retention, and that sort of unwelcoming practice will make it worse than it needs to be. Doing the research to fill in content gaps is way more time-consuming than formatting fixes, and often requires subject-matter expertise. Chasing away editors who are doing that pushes a disproportionately large amount of work onto the remaining cadre of volunteers, and in some cases will mean that Wikipedia simply doesn't learn about certain notable facts.

I probably spent about 8 hours yesterday researching interesting facts and chasing down sources and updating Wikipedia articles. Filling out cite templates is probably the most annoying part of that process. So yes, I feel like I did my fair share of work and I gave myself permission to be a bit lazy and not add a bunch of curly braces and whatnot in footnotes where I didn't think it made a difference to anyone being able to verify the added content or get more info or add full metadata later if desired. I'm pretty sure Wikipedia:reFill will upgrade the formatting far quicker than I could do manually, so it doesn't seem like the best use of my time.

I've spent thousands of hours cleaning up contributions that have spelling errors, don't format their quote marks or dashes correctly, have HTML syntax errors, aren't wikified, don't convert to metric units, or don't use {{lang}} or {{chem}} or math markup like they are supposed to. I have never told anyone they shouldn't be making contributions if they don't have perfect spelling or don't follow the rules English Wikipedia has made up in this areas. I just fix the problems, or tag them if there are appropriate work queues and I don't have time to do it myself. Sometimes I let contributors know about the fixes I'm making if I think they could make use of that info in future edits, especially if manual cleanup is messy, and I have no problem with other editors doing the same by bringing guidelines to my attention if I'm not following them. If someone questions the fixes I'm making, I try to politely explain about and link to our guidelines. But being told that a slightly imperfect contribution is worse than no contribution at all made me feel like all the hours and deep reading I did to shape useful content was disrespected, and that's exactly how I do not want new editors to feel. I would simply ask that you extend to me and other editors the same grace that I extend to everyone. -- Beland (talk) 23:25, 11 January 2025 (UTC)[reply]

I am not saying your edits were worse than no contribution at all. However, I am saying that being a highly experienced editor does not excuse you from following this guideline. It's very frustrating to have put in the work to write a Good Article, and then have other editors make additions that don't maintain the article quality. In this case, I'm also concerned because you introduced a factual error with your edits, writing ...to supplement the only current entrance.... That does not correspond to the source, which says ...the nearest entrance/exit point.... (For the record, I count at least 7 other hi-rail access points on the line: Longfellow Bridge, Cabot Yard, Von Hillern Street, Tenean, Codman Yard, Water Street, and Caddigan Yard. An additional one at Linden Street appears to be disused.) Pi.1415926535 (talk) 01:05, 14 January 2025 (UTC)[reply]

The instruction "follow the guideline and properly format your citations, or do not make the edits in the first place" implies to me you would have preferred I not make these edits in the first place because the citations were not properly formatted, thus no contribution at all. If that's not what you meant, that's fine, no worries.

It's certainly fair enough to be frustrated, but less-than-good-article-quality and less-than-featured-article quality contributions seem inevitable whenever there's more to say about the subject, either because we learn more over time, find better sources, or history keeps on being written about a thing that still exists. I can only hope that we will always be able to keep up with article maintenance as the world changes around us. Well, more than hope, given that I spend more time fixing other people's contributions than making my own. I usually see the other end of the process, where I start a stub that's lucky to have any citations at all, and the next time I get around to checking up on it there is magically a full article created by seven years of accretions from random editors.

I just went back to fix the formatting of my citations and address the factual claim, but it seems you have already done it, so thank you for that, and sorry I was too upset to do it when you first pointed it out.

I always appreciate a good fact-check, especially in this case as I was about to start investigating whether the MBTA should be building more hi-rail access on the south side of the Red Line. The official project page does say: "Right now, the only access tunnel for these vehicles is at Charles/MGH station." and I think I read that at some point and internalized it.

Where are you getting the info about hi-rail access at other points? I'm unable to find a list from a reliable source with a simple web search. I'm wondering if "at Charles/MGH Station" is actually referring to the access point on the Longfellow Bridge? The station is next to the bridge, but the access point is near the tunnel at the other end, probably closer to Kendall. I can confirm it's real...the Google Street View capture for August 2024 actually shows the Red Line in the middle of a shutdown, with the access gate to the westbound automobile lane open, and a hi-rail vehicle actually on the tracks headed downhill. There's a telltale track-level pad inside the gate for vehicles to make the transition. I can also see "MBTA Von Hillern Truck Pad" on Google Maps, but searching that site for "MBTA Truck Pad" shows only 8 such entries, including Water Street and some on the Orange and Green Lines. Given that shutdowns and the duration and frequency thereof have become a major local political issue lately, it would be quite interesting to have these access point documented on Red Line (MBTA). -- Beland (talk) 06:59, 14 January 2025 (UTC)[reply]

I found the "Tenean" site. It's actually off Conley Street, and there's a sign "Tenean Storage" that also says "Carl E. Hosea, Jr., Memorial Rail Yard". There's a bunch of hi-rail vehicles parked there. -- Beland (talk) 07:32, 14 January 2025 (UTC)[reply]

FYI, I have reverted your edits to Green Line (MBTA), as you added content regarding hi-rail vehicles without any references whatsoever. Turini2 (talk) 08:44, 14 January 2025 (UTC)[reply]

The existence of the hi-rail access points can be verified in plain sight from public places, which is one of the cases Wikipedia:Common knowledge recommends for not requiring citations. Do you have any objection to relying on that? I can chase down citations for the other claims. -- Beland (talk) 21:45, 14 January 2025 (UTC)[reply]

I would consider hi-rail access points to be technical knowledge rather than "common knowledge" - a layperson probably wouldn't be able to tell you what the thing was. Regardless, it seems a bit too much detail for a wikipedia article to include all the locations - a mention of the access points more generally with a valid reference would probably be enough. Turini2 (talk) 22:01, 14 January 2025 (UTC)[reply]

Hmm, it seems pretty obvious the purpose of a gate between an automobile lane and train tracks is to allow vehicles to enter, especially when there's a special surface that tire vehicles can drive which is the same as at at-grade crossings and which doesn't appear anywhere else on the tracks. There is also usually a sign identifying the site as a truck pad, which I how I think these things end up on Google Maps. It doesn't take any technical knowledge to read a sign. -- Beland (talk) 23:20, 14 January 2025 (UTC)[reply]

Fully agreed with Turini2 here on both points. For the article on the line, no more than a single cited sentence is needed. For truck pads adjacent to a station, a single cited sentence on the station article might be worthwhile. Pi.1415926535 (talk) 22:03, 14 January 2025 (UTC)[reply]

OK. I'm still wondering where the list of Red Line access points came from? -- Beland (talk) 22:45, 14 January 2025 (UTC)[reply]

Personal knowledge, which is why it's not in the article, because I don't have a citable source available. But the citation in the Alewife station article makes it clear that the Longfellow Bridge truck pad is not the only one on the line. Pi.1415926535 (talk) 23:08, 14 January 2025 (UTC)[reply]

Scientific notation

I'm really not sure there's consensus for these sorts of edits [1]. Especially on a mass scale with AWB. Headbomb {t · c · p · b} 08:56, 13 June 2025 (UTC)[reply]

Do you personally have a reason for preferring the scientific notation, or do you suspect other unidentified editors would have a reason? In my mind, the main precedent is that we specifically had MOS:CONVERSIONS recommend for astronomical distances e.g. "2 million ly" or "5 Mpc" over "7 × 10⁶ ly" out of concern that some readers would find the scientific notation harder to understand. To me, it makes sense to generalize that to other STEM topics, though the rationale breaks down when the words become more obscure than the scientific notation (e.g. I'd have to look up what "quadrillion" means) or alternatives are awkward (e.g. for very small fractions).

BTW, this article Quark–gluon plasma already uses "trillion" in terms of temperature in two other places, and also uses "billion" once. For "5.5 trillion (5.5×10¹²) kelvin" I think the translation to scientific notation is unnecessary and should be removed to avoid clutter. -- Beland (talk) 20:42, 13 June 2025 (UTC)[reply]

Punctuation

Hello, not sure how much you're interested in this, but this search seems to have a rather large number of incorrectly punctuated quotations. 1234qwer 1234qwer 4 21:34, 7 January 2026 (UTC)[reply]

Ah, well spotted. I can put together some code to try to separate the legitimate instances from the violations of MOS:LOGICAL, though I might need some clarification. Would you be interested in getting set up on AWB or JWB to go through and fix these en masse? -- Beland (talk) 11:01, 9 January 2026 (UTC)[reply]

Please do watch for false positives and different types of errors. In the first page of search results (100 pages), I'm seeing usage that looks OK in Woman, Ulysses S. Grant (a File name), Watergate scandal (a File name), and other pages. In New York City, " needs to be changed to ' and a space needs to be added before an ellipsis (a similar pattern exists at Indigenous Australians and Isaac Asimov). There is a difference in error type between the pattern followed by a space, versus the pattern followed by ..., versus the pattern followed by a ref tag or sfn template. I would break down the search into subgroups to make fixes easier.

Limiting the search to the pattern followed by a ref tag might be a good place to start. That's still thousands of pages! – Jonesey95 (talk) 17:32, 9 January 2026 (UTC)[reply]

No, I'm not ready to do a task like this; I was mostly wondering whether this would fall into any project you know of. 1234qwer 1234qwer 4 17:55, 20 January 2026 (UTC)[reply]

This certainly folds well into the database scan I do for Wikipedia:Typo Team/moss. There are people working on fixing misspellings and a handful of other reports, but unfortunately we have a lot of reports that no one is using to fix things, or it's just me pecking at enormous backlogs. For example, in the last database dump I found 1,851,844 likely parenthetical references that need to be fixed, 539,779 violations of MOS:LOGICAL, 487,756 missing redirects according to our policy on using ASCII characters, 359,680 violations of MOS:INFONAT, 266,930 possible violations of MOS:FRAC, and 167,405 instances of unbalanced quotation marks that are preventing spell checking, 107,176 characters that need to be normalized, 34,402 instances of a comma being used as a decimal point, and probably over 100,000 violations of MOS:UNITS and missing metric conversions.

I'll put it on my todo list to use moss to refine reliable patterns for detecting and fixing some subset of redundant periods and contribute regexes to Wikipedia:AutoWikiBrowser/Typos (also known as RETF) so perhaps editors who use AWB or JWB will serendipitously fix these issues as they fix other things on the same pages. But as of the last database dump there are 1,345,404 instances of 3,290 RETF-identified problems. So I think actually getting this sort of thing fixed will require more volunteers. -- Beland (talk) 22:45, 20 January 2026 (UTC)[reply]

I'm already glad enough if a "backlog" becomes known "officially"... there's a lot of smaller ones I have found from time to time where I had been pondering whether to take them on or talk about them somewhere. 1234qwer 1234qwer 4 03:05, 25 January 2026 (UTC)[reply]

Avangrid updates

Hi Beland,

I see that you recently made contributions to the Vineyard Wind article, so I hope you'll be interested in taking a look at the edit request I posted on the Avangrid Talk page which references the Vineyard Wind project. The request can be seen here: https://en.wikipedia.org/wiki/Talk:Avangrid#History_Section_Updates.

Thanks for your help, ResRose (talk) 17:55, 28 January 2026 (UTC)[reply]

Move review for Anura

An editor has asked for a Move review of Anura. Because you closed the move discussion for this page, or otherwise were interested in the page, you might want to participate in the move review. --Joy (talk) 12:53, 6 April 2026 (UTC)[reply]

Incorrect minus sign in automatic replacement

In Special:Diff/1344095727, you replaced U+207B SUPERSCRIPT MINUS by a superscript hyphen-minus "-". Per MOS:MINUS, that should be a minus sign "−". 1234qwer 1234qwer 4 17:50, 7 April 2026 (UTC)[reply]

Ah, thanks for the note. I think it should actually be &minus; as shown in the MOS examples, rather than the raw character, because otherwise editors can't tell the difference. My replacement script retains the HTML entity. -- Beland (talk) 18:33, 7 April 2026 (UTC)[reply]

FTR, I just fixed 200 of these, but this is probably worth keeping on the radar. Another one you might find interesting is this. (There is also a lot of usage of "x" for multiplication, and I started fixing these along the way (I even found one using a Cyrillic "х"), but am going to request fixing a query specifically for these at WP:AWBREQ.) 1234qwer 1234qwer 4 01:38, 8 April 2026 (UTC)[reply]

Oh, good; I see not only "x" for multiplication, but sometimes "X" (mostly when looking at scientific notation and units of measure for other reasons). I've added a moss pattern for the solar mass notation, blech! -- Beland (talk) 02:40, 8 April 2026 (UTC)[reply]

...these also use U+2299 CIRCLED DOT OPERATOR. 1234qwer 1234qwer 4 02:44, 8 April 2026 (UTC)[reply]

Added! -- Beland (talk) 02:47, 8 April 2026 (UTC)[reply]

You might also want to add things like this and variations to your patterns. I've fixed some "<ref>>"s and "<</ref>"s in the past. 1234qwer 1234qwer 4 19:44, 9 April 2026 (UTC)[reply]

Ooo, yuck. That sort of typo could completely break parsing of the page, at least as far as the spell checker is concerned; I've added four variants of that typo to moss fixup patterns. -- Beland (talk) 00:26, 10 April 2026 (UTC)[reply]

Also, I am not sure "million M_⊙" is particularly less technical (while also being somewhat awkward)... 1234qwer 1234qwer 4 20:50, 9 April 2026 (UTC)[reply]

Yeah, that was a partial cleanup of scientific notation, which some people don't know. I think in prose that should say "million solar masses"; most people aren't going to know the astronomical notation. Space is more limited in infoboxes; maybe M_☉ is OK to leave in place there, as long as it's linked. -- Beland (talk) 00:24, 10 April 2026 (UTC)[reply]

Oh, I just found {{solar mass}}, which also produces the M_☉ notation. -- Beland (talk) 00:29, 10 April 2026 (UTC)[reply]

Yes, I stumbled upon that as well afterward. It also italicises the letter M. 1234qwer 1234qwer 4 11:55, 10 April 2026 (UTC)[reply]

AN/I Notice

There is currently a discussion at Wikipedia:Administrators' noticeboard/Incidents regarding an issue with which you may have been involved. The thread is Disruptive editing by ErnestKrause on Donald Trump. BootsED (talk) 15:14, 19 April 2026 (UTC)[reply]

RM closure

Hi, @Beland:

I think that you may have misread consensus at Talk:2024 Lebanon War § Requested move 7 March 2026. I did not participate in that discussion (and probably would have opposed a move if I had), but participants appear to have preferred "war" over "War". Would you consider amending your closure? –Gluonz^{talk contribs} 15:50, 20 April 2026 (UTC)[reply]

Search on Google Scholar shows "War" not "war". -- Beland (talk) 16:49, 20 April 2026 (UTC)[reply]

Continuing at Talk:2024 Lebanon War § 2024 Lebanon War or 2024 Lebanon war?. -- Beland (talk) 16:56, 20 April 2026 (UTC)[reply]

Hey Beland, can you also give an explanation for this closure? Thanks, VR _{(Please ping on reply)} 14:16, 23 April 2026 (UTC)[reply]

Participants favored change of scope to "war" from "invasion" more than 2:1. The ideas that the invasion was a subset of the war and the war was a subset of Hezbollah–Israel conflict (2023–present) were supported by reliable sources. -- Beland (talk) 18:53, 23 April 2026 (UTC)[reply]

Thanks for the explanation. In your opinion was there consensus on the starting date of the war (given the scope change), or is that to be determined by further discussion on the article's talk page? VR _{(Please ping on reply)} 02:39, 25 April 2026 (UTC)[reply]

The consensus seems to be that the war began in September, 2024. If there's a specific day that it began in that month, it seems to be when the pager explosions happened.

As for whether this conclusion can be challenged going forward, I would recommend accepting that as a starting point for now but keeping an eye on sources and maybe revisiting that question a year or two from now. How to treat all the nuances of the history in the article is a complicated question which I think goes beyond what was answered in this discussion.

Periodization always needs to be grounded in reliable sources, but academic consensus could change over time. The infobox currently reflects the pager attacks as the starting date of the war, and this is reasonable given the cited sources. NPOV was raised as an objection, but a single date need not be unanimously cited by all sources to be the one used by an infobox. For example, see World War II#Start and end dates. NPOV is apparently satisfied by noting that some academic sources dissent from the most common view. The infobox on the 2024 Lebanon war article does note the invasion phase separately, and that arguably gives readers enough information to understand the history to some degree regardless of how the various phases are labeled. If some sources describe the war as starting with the air strikes or the invasion, that could be worth mentioning in proportion to due weight. If some consider the 2024 violence to be part of a war that started in 2023, that could be worth mentioning in proportion to due weight. If it develops that there are two strong contradictory viewpoints, then maybe having a single date in an infobox isn't NPOV anymore; this is subject to research and discussion. -- Beland (talk) 03:29, 25 April 2026 (UTC)[reply]

I'm surprised you find consensus that the war began in September 2024, especially with the pager attacks, as few sources were presented in the discussion that clearly identified the pager attacks as the beginning of the war. Meanwhile, a dozen or so sources[2] seem to say the war began in 2023.VR _{(Please ping on reply)} 06:26, 25 April 2026 (UTC)[reply]

The lead currently says: "The war began in September 2024 following nearly 12 months of conflict between Israel and Hezbollah, when the former initiated major attacks in Lebanon including an attack on pagers and electronic devices," followed by 3 sources. I checked all 3 of them, none of them say anything about "The war began in September 2024", nor "when the former initiated major attacks in Lebanon including an attack on pagers and electronic devices". IMO that's a WP:V violation, unless other sources in the rest of the article support it.VR _{(Please ping on reply)} 06:32, 25 April 2026 (UTC)[reply]

Other editors looked at the sources that say the war began in 2023 and found them dated. The article should indeed have sources documenting the periodization; I've added a "citation needed" tag to the claim about when the war started, and leave it up to interested editors to resolve. -- Beland (talk) 18:22, 25 April 2026 (UTC)[reply]

One editor did initially call them dated, but then I provided sources from Feb/Mar 2026[3] (which are obviously not dated, given the RM was opened 7 March). If its ok with you, can I open a discussion on the talk page to further discuss and try to arrive at consensus on what do the sources say about when the war began and therefore what should the article say? From my view, only person engaged with the large source table I provided.VR _{(Please ping on reply)} 18:37, 25 April 2026 (UTC)[reply]

I started a discussion at Talk:2024 Lebanon war § Sourcing for start of war. I would give folks 2-3 days to reply, and if a good source can be provided then I don't think it would be a good idea to directly re-hash the same argument that was just had in the RFC. As I mentioned above, it might be appropriate to mention in the article that some sources consider this to be a continuation of a war that began in 2023. I would recommend establishing consensus for text in the article that this is at least a minority view with enough due weight to mention, before attempting to establish consensus that this is actually the majority view. -- Beland (talk) 19:41, 25 April 2026 (UTC)[reply]

Thanks.VR _{(Please ping on reply)} 20:02, 25 April 2026 (UTC)[reply]

Hong Kong RfC

I saw that you closed that RfC while I was writing up my close. I have the same conclusion. Given that the CR lister asked for a rationale, would you mind if I substituted my close for yours and that you endorse it if you find it agreeable?

I append:

There is consensus for option 1 and for it to be used in all applicable templates as described in the RfC.

Editors supporting the option (indeed, of the options, only option 1 saw any support) saw no need for further differentiation, advancing both policy-based and non-policy-based arguments. They were happy with Hong Kong.

The only opposition expressed that this was a bad RfC, that Wikipedia is not a bureaucracy, and that we are to avoid instruction creep. However, these arguments proved unconvincing to the community; every later !vote was for option 1.

Separately, it may be the case that some templates or infoboxes require a more tailored solution. As with all processes here, that ought to be resolved via further discussion.

Iseult^Δxtalk to me 07:12, 30 April 2026 (UTC)[reply]

Feel free to post it as a concurring close. I'm not sure how I feel about the last paragraph and don't wish to comment on it. -- Beland (talk) 07:15, 30 April 2026 (UTC)[reply]

A cookie for you!

For your effort in closing the RfC regarding the persecution of trans people in the Trump article. It's not an easy task, and sticking your neck out on such a hot page is worthy of recognition. -- Cdjp1 (talk) 13:06, 30 April 2026 (UTC)[reply]

"Biology symbols" listed at Redirects for discussion

The redirect Biology symbols has been listed at redirects for discussion to determine whether its use and function meets the redirect guidelines. Anyone, including you, is welcome to comment on this redirect at Wikipedia:Redirects for discussion/Log/2026 May 1 § Biology symbols until a consensus is reached. —Myceteae‍🍄‍🟫 (talk) 19:48, 1 May 2026 (UTC)[reply]

Composers RfC

Intrigued by the comment ”comments made by AirshipJungleman29 went so far that I would regard them as a personal attack on another editor”. Mind expanding? Thanks, ~~ AirshipJungleman29 (talk) 05:59, 3 May 2026 (UTC)[reply]

Backlink: Wikipedia talk:WikiProject Classical music § RfC: amending project guidelines on infoboxes

"Are you interested in this topic? What contributions have you made to classical music articles?" is an attempt to delegitimize the contributions of an editor by attacking them personally, rather than discussing the merits of adding infoboxes to classical music articles. The idea that only editors who have previously contributed to articles (or contributed in specific ways) are allowed to make decisions about them appears to violate WP:OWN, even if you are not claiming ownership for yourself.

Your second reply in that thread was: 'So no, you are not interested in this topic, and are wasting the community's time with an RfC about a page which has "has no actual authority", as you say. Why? Point-scoring, it looks like. Heigh-ho.' Telling another editor that they are not interested in a topic they have just asserted interest in is quite rude, a violation of WP:CIVIL. Ascribing a nefarious motivation to another editor is a violation of WP:AGF, especially galling given they actually did a good job of following WP:RFCBEFORE and other editors are grateful they opened this RFC to address a perennial problem. -- Beland (talk) 06:47, 3 May 2026 (UTC)[reply]

Thanks for your response. On the first paragraph, you appear to be under the impression that the discussion made decisions about any articles. I suggest you remind yourself of what a WikiProject is. On the second, you may wish to consult the ongoing ArbCom case, in which the arbitrators have characterised this particular discussion with the remark ”turning minor disputes into RfCs”, as part of ”persistently disruptive participation in projectspace” for which the filer is shortly to be banned. I think I’ll stand by my comment. ~~ AirshipJungleman29 (talk) 07:03, 3 May 2026 (UTC)[reply]

A barnstar for you!

	The Tireless Contributor Barnstar
	This is for closing the monstrous RfC at Talk:Zionism. The thread was massive! بادهای شمال ❄️ (talk) 08:14, 3 May 2026 (UTC)[reply]

Request to reopen RfC due to flawed source analysis

You recently closed this RfC regarding the lead sentence in the Zionism article. In your close, you referenced and relied on source analysis presented by an editor when explaining several of the recommendations and observations in the close regarding distinctions between different strands of Zionism, demographic goals, and how the sources aligned (or did not align) with the current wording.

However, that source analysis contains serious problems which materially affect the conclusions drawn from it. Earlier this week, I began reviewing the sources cited there and found that multiple works categorized as supporting option B or as "mixed", including Rubin, Segev, Shlaim, Pappé, and Rouhana & Sabbagh-Khoury, were characterized in ways that do not reflect their overall arguments and conclusions.

I knew this was the case for Rubin as I had recently examined the text in detail for a talk-page discussion concerning it. As I showed there, with citations from the text, Rubin’s central thesis regarding Jabotinsky and major currents within the Zionist movement directly supports the characterization disputed in this RfC rather than undermining it. Despite this, the source analysis cited Rubin twice as supporting option B based on selective excerpts that omitted the broader context and conclusions of the work. Furthermore, as I noted in the same discussion, there are additional sources including those currently cited in the article that also do so yet are omitted in the analysis, such as the Brenner, Gorny, Finkelstein and Tress. These omitted and misrepresented sources extend from the origins of the Zionist movement to the contemporary period.

Another serious flaw is that the source analysis has a tab for "contested by", described by the editor as Finally, where relevant, I noted whether the source or its broader interpretive framework has been explicitly contested by other historians. This tab is helpful. However, it is selectively utilized to contest sources supportive of Option A or mixed while not doing the same for Option B. One glaring instance of this is the Rubin case. Rubin explicitly contests the intepretive framework of the twice cited as strong support for B source Shindler (alongside the other sources cited for Jabotinsky). It is not cited as such in this tab. Elsewhere the editor uses the tab to cite Framework-level contestation by historians/commentators who reject the settler-colonial model for Zionism for Option A/mixed sources.

After noticing this issue, I began reviewing the other sources cited in the analysis and have so far found similar problems with the treatment of Segev, Shlaim, Pappé, and Rouhana & Sabbagh-Khoury, which were described as "mixed" despite supporting the current lead wording. I was in the process of preparing a response addressing these sourcing issues when the RfC was closed.

Because the close itself relies in part on this source analysis in making recommendations about the article text and in identifying alleged mismatches between the sources and the current wording, I believe these sourcing issues should be examined more closely as I intended to do.

For that reason, I request that the RfC be reopened for a limited period so that my review of the sources and their characterization in the analysis can be presented and evaluated by participants. Lf8u2 (talk) 21:27, 3 May 2026 (UTC)[reply]

I think there will be a lot of refinement and consensus-building for sourcing on the beliefs of various strains of Zionism that could take months. I recommend making a separate page along the lines of Template:Expert opinions in the Gaza genocide debate. Then that can represent the current consensus analysis at any given time. -- Beland (talk) 22:39, 3 May 2026 (UTC)[reply]

Thank you for the response. I agree that broader sourcing discussions regarding different strands of Zionism could continue. However, my concern is narrower and relates specifically to the basis and content of the close itself.

The close does not simply state that no consensus was reached to change the lead. It also makes a number of substantive observations and prescriptive recommendations regarding the relationship between the sources and the current wording, and those observations rely on the aforementioned flawed source analysis. In particular, your close suggested that dispute tags might be appropriate pending further resolution of the sourcing issues, though you would not add them yourself. While this was framed as a recommendation, the close also stated that if such tags were added they should not be removed without consensus on the talk page. In practice, this went beyond a general recommendation and functioned as a prescriptive content adjustment, and editors subsequently added the tags in reliance on your close despite the clear lack of consensus for such.

I would point you to WP:ACD, which notes: The first principle of closures: The closer’s role is descriptive, not prescriptive. In other words, the closer describes what other editors have decided on, and does not make any decisions for anyone else. The goal of any closing statement is to determine and summarize the consensus reached by the editors in the discussion. The outcome is determined solely by the participants; the closer’s role is solely to find out what the participants have decided. If you personally make a decision about the issue at any point, as opposed to evaluating the contents of the discussion, then you are making a prescriptive closure. This is often referred to as a supervote because you’re placing your own reasoning above that of the participants.

I therefore again request you to either reopen the RfC so that these source-characterization concerns can be presented and properly evaluated, or remove the prescriptive portions of the close relying on that flawed source analysis pending further review in a separate process, thus retaining the status quo. In highly contentious instances like these where no clear consensus has emerged, it is preferable to preserve the status quo until the sourcing disputes themselves are more fully examined. Lf8u2 (talk) 23:41, 3 May 2026 (UTC)[reply]

Well, any editor can tag any claim where they dispute accuracy, and in general such tags shouldn't be removed until the dispute is settled. It is weird to complain that such tags should not be used without consensus, because the point of them is to indicate a lack of consensus and confidence in the accuracy of our prose. I would not call this a content change; the content may end up staying the same depending on source analysis.

WP:ACD is an essay, not a guideline. I'm not sure I agree with it because it does not seem to allow for bartender closes, which seem generally accepted in practice. -- Beland (talk) 10:14, 4 May 2026 (UTC)[reply]

Above you write the point of them is to indicate a lack of consensus and confidence in the accuracy of our prose.

However in your close you wrote "Participants did not endorse a change to the lede".

These two statements don't seem to line up very well, as your close did not state that there was no consensus on the sentence being in the lead, only that the removal was not endorsed. I think perhaps your close may be in need of some clarification. Unless there is a no consensus outcome the maintenance tags shouldn't be there given that existing consensus as determined by the prior RFC was that the sentence was NPOV compliant and that it should stay. TarnishedPath^talk 10:24, 4 May 2026 (UTC)[reply]

I'm not sure "no consensus" adequately sums up the situation. There was not consensus to simply endorse the proposed change to the lede, but there also seems to be consensus for change if improved sourcing supports changes in the body. I have added a clarifying TLDR. -- Beland (talk) 17:21, 4 May 2026 (UTC)[reply]

I'm not sure you can find support for change to an undetermined conditional state. TarnishedPath^talk 22:13, 4 May 2026 (UTC)[reply]

Is there a rule that prohibits this? -- Beland (talk) 03:02, 5 May 2026 (UTC)[reply]

Not so much a rule. More that it would seem be illogical to state that consensus has been formed on the basis of some yet to occur event. Kind of putting the cart before the horse. TarnishedPath^talk 03:20, 5 May 2026 (UTC)[reply]

I see nothing illogical about resolving a conflict by agreeing to a procedure to determine the outcome instead of agreeing to a specific outcome. There may be another dispute about whether the output of the procedure should result in a specific outcome, and that's OK; the point of the procedure is to make the second dispute easier to resolve than the first. "Something needs to change, but this proposal isn't the right change" is also a not-unheard-of outcome for plenty of group decisions. -- Beland (talk) 18:25, 5 May 2026 (UTC)[reply]

Ps, I'll have a read of your updated close statement later on today (presently at work). TarnishedPath^talk 22:14, 4 May 2026 (UTC)[reply]

I've just read your clarifying TLDR in which you've stated:

Clarifying TLDR: There is not consensus for an immediate change to the lede, but there are serious accuracy concerns and consensus to entertain a future proposal for changes to the lede, conditional on improved sourcing supporting changes to the body. While this is pending, it is OK to tag for accuracy dispute.

This does not come close to stating that there is no consensus for the current sentence staying in the lead.

Given what you have actually written (both the long version and the TLDR), the previous RFC, and comments from @Lf8u2 above, I'm going to request you remove statements about placement of the {{disputed}} or {{disputed inline}} tags.

Ps, if you're looking for the RFC, another editor thought it would be helpful to archive it immediately after closure and it can be found at Talk:Zionism/Archive 40#RfC: Moving "as few Arabs". TarnishedPath^talk 11:00, 5 May 2026 (UTC)[reply]

If the clarification does not say what you want it to say, then perhaps we simply disagree on what the result of the closure should be, including whether or not it's appropriate to add accuracy tags. Continuing this thread would violate your topic ban, so I guess we'll have to leave it at that. -- Beland (talk) 18:32, 5 May 2026 (UTC)[reply]

Even if there wasn't consensus for the proposed discussion to the lead, it still could have been closed as "consensus not to keep the status quo with later discussion on specific wording"; "discussion on specific wording" is a clause I put in the RfC specifically if the change I proposed was not agreed upon exactly. VidanaliK (talk to me) (contributions) 21:34, 10 May 2026 (UTC)[reply]

Notice of noticeboard discussion

There is currently a discussion at Wikipedia:Administrators' noticeboard regarding an issue with which you may have been involved. Specifically this is a close-challenge regarding your closure at Talk:Donald Trump. Simonm223 (talk) 11:52, 4 May 2026 (UTC)[reply]

Redirect listed at Redirects for discussion

Redirects you have created have been listed at redirects for discussion to determine whether its use and function meets the redirect guidelines. Anyone, including you, is welcome to comment on this redirect at Wikipedia:Redirects for discussion/Log/2026 May 4 § Arabic diacritics + anything else until a consensus is reached. –LaundryPizza03 (d c̄) 23:53, 4 May 2026 (UTC)[reply]