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

SISTEMAS de seguridad 189.201.9.129 (talk) 15:51, 3 May 2025 (UTC)[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]

@

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

]

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

]

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

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]

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

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

]

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

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]

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]

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

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]

@

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]

@

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,

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,

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]

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.

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]

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]

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:

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"
}

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]

Per

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

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]

Following the consensus at Wikipedia:Categories_for_discussion/Log/2025_March_11#Establishments_in_the_Spanish_West_Indies_(years), you may want to follow up with Category:Disestablishments in the Spanish West Indies. – Fayenatic London 22:09, 22 March 2025 (UTC)[reply]

Well spotted, will do! -- Beland (talk) 21:09, 24 March 2025 (UTC)[reply]

A discussion is taking place as to whether the article List of obsolete technology is suitable for inclusion in Wikipedia according to Wikipedia's policies and guidelines or whether it should be deleted.

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

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

Interstellarity (talk) 14:44, 3 April 2025 (UTC)[reply]

I'm really not sure there's consensus for these sorts of edits [1]. Especially on a mass scale with AWB.

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]

Hi, thanks for your close there. You took on an unenviable job. I'm not here to dispute the overall option 2 finding, but I did want to ask about the second paragraph. Your close says Euro-Med did not clearly say that an Israel Supreme Court decision had legalized organ theft; it said the court had allowed burial of bodies in the "Numbers Cemetery". It does not make clear how this decision relates to other laws passed by the Knesset and which exactly legally authorizes the taking of organs (if that's true). Other sources are available on the legal question and report it in more detail, and these should be consulted and non-advocacy sources preferentially used.

Maybe I missed it but I don't think this was an argument that was articulated clearly in the RfC itself. Did I miss it? I did look again before posting this and didn't see it. Samuelshraga (talk) 11:59, 23 June 2025 (UTC)[reply]

Correct, participants did not work through the examples to this degree, at least not in the RFC text. I included this as an illustrative example of what I found when I looked at the examples people were arguing about in detail. In various cases, the claims being made by Euro-Med were not as strong as argued, or were not as badly sourced as argued. I didn't want to just blindly accept the majority support for Option 2; I wanted to confirm it was based on a fair reading of the sources cited, and not merely a bunch of like-minded people arguing for an outcome favoring one side. Both the majority opinion and my evaluation of the evidence and arguments pointed in the same direction, so that makes me confident in the closure outcome. -- Beland (talk) 17:21, 23 June 2025 (UTC)[reply]

I've taken a while to think about this. In principle I love the fact that a closer really checked to see that it was not merely a bunch of like-minded people arguing for an outcome favoring one side. However your close, beyond the first paragraph, introduces a new argument that wasn't made in the discussion. I understand what you're saying but I would have disputed what you said. The point is that Euro-Med made a claim - in principle a citable one - that Israel had made organ theft lawful. I don't think it's useful for me to litigate with you that issue (how that claim, plus other factors, impact on Euro-med's reliability). What matters to me is that by introducing a new counter-argument in the close, you've gone beyond the closer's role of summarising the discussion and given yourself the last word on one of the disputed points.

Like I say, I don't ask you to vacate the close or the Option 2 outcome. However, I do ask you to re-write or discard the paragraphs after the first one, because they're not summarising the discussion or the consensus, they're giving your opinion on the organ theft claim, its context and how it might be used in articles. I've searched and literally no one at the RfC defended the specific claim that "Israel has legalised organ theft", let alone did the close reading of the article that make up your 2nd-4th paragraphs.

I don't think much will be lost by this. We'll still know where we stand with this source, and particular claims cited to it can be evaluated accordingly. Samuelshraga (talk) 20:20, 24 June 2025 (UTC)[reply]

Thanks for considering this carefully. I looked back at what I wrote and pondered how people will interpret it in the future.

I specifically wrote "did not clearly say" in the second paragraph, rather than "clearly did not say", because the ambiguous phrasing there is disputed, with one interpretation (of how the first sentence in the Euro-Med paragraph relates to the second sentence) apparently correctly describing the Supreme Court ruling and the other not. It sounds like your interpretation is the latter. That's fine; the ambiguity of phrasing here is a good reason not to use the combination of those sentences as a citation to support a claim like "the Israeli Supreme Court legalized organ theft" and a good reason not to attribute that accusation to Euro-Med.

The point of the second paragraph is to provide guidance on how to delicately handle a source which does both fact-gathering and advocacy. It was noted in the RFC that triangulation with other reliable sources is a best practice, and also that we need to be careful to separate fact reporting vs. opinions. So I give the example here that the claim "Israel legalized organ theft" should be triangulated with legal expert sources. It is probably better to cite other sources instead for any definitive claims in Wikipedia's voice. As editors suggested, if there is disagreement among legal experts or between legal experts and Euro-Med, treat "Israel legalized organ theft" as an accusation (like the 4th paragraph example) and state it with attribution or not at all.

The point of the third paragraph is to give guidance in cases where Euro-Med is directly gathering and reporting facts. Editors seemed to think these were the most reliable part of their content, a sign of overall reliability, and an important factor because facts are hard to come by in this situation. RFC participants advocated for taking lots of care and specifically for explaining to readers where Euro-Med is getting its information, so I tried to convey that advice using a concrete example.

I think these examples will be useful if editors look to this RFC to help decide the complicated question of which other claims should and shouldn't use Euro-Med as a source. -- Beland (talk) 22:30, 24 June 2025 (UTC)[reply]

I think you're right to say that the Euro-Med piece "does not clearly say" that the Israeli supreme court made organ theft legal. If somebody were to "The Israeli supreme court legalised organ theft" and cite it to Euro-Med, I would just remove it because the source doesn't explicitly support the claim.

However, Euro-Med does explicitly say that Israel made it lawful to steal Palestinians' organs. In the discussion, nobody corroborated this claim, and it was explicitly described as false.

I may have caused some of the confusion by describing the specific claim inaccurately: saying that Euro-Med said the Israeli Supreme Court legalised organ theft, rather than Israel in general. However, correction of this and exploration of the accuracy/inaccuracy of the actual claim was not part of the discussion you closed. I would have argued that it is equally inaccurate, but because your analysis of the underlying sources is in the close rather than the discussion, we can't go there.

I think the general message of attribution and triangulation with other sources are fine, I'm not interested in changing your understanding of the consensus. But I think that by taking a specific example and counter-arguing what several editors said in the discussion, you undermine the close as a whole. The close can't be a a summary of the discussion if it introduces new arguments on one of the key points. Samuelshraga (talk) 05:32, 25 June 2025 (UTC)[reply]