![]() | This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 155 | ← | Archive 159 | Archive 160 | Archive 161 | Archive 162 |
@ Dondervogel 2: (who previously edited here as Thunderbird2 ( talk · contribs)) doesn't like WP:COMPUNITS, specifically the requirements around not using IEC units except under very specific circumstances. He'd like to change it. As I'm very much opposed to using IEC units as they are very rarely used in anything with widespread use (most of our sources use classic metric terms like KB, MB, GB, not KiB, MiB, and GiB), I'll leave it to them to fill in the reasoning for using these archaic terms that somehow overrides WP:NOR and WP:VNT. — Locke Cole • t • c 16:54, 25 April 2021 (UTC)
@ Denniss and Zac67: since you apparently agree with IEC units and also want the MoS changed. — Locke Cole • t • c 16:56, 25 April 2021 (UTC)
I'm a bit surprise of the aggressive tone seen in the comments here. We reverted the undiscussed changes to SDRAM-related articles where KiB etc are desired and required. Locke Cole did not even try to enter a discussion but simply continued to revert. We did start a discussion at Talk:Synchronous_dynamic_random-access_memory#Disputed_edits but all he did was simply closing it off. We do not intent to change Mosnum, you just have to accept there are areas where KiB etc has more value than KB etc.-- Denniss ( talk) 19:36, 25 April 2021 (UTC)
In my day job I program embedded devices. Which means I spend a lot of time in the manufacturer's data sheets. I can't remember the last time I saw a MiB, KiB, etc in an official datasheet. Nor do I find them on Stack Overflow, or programming blogs or any other online resource when searching for answers for particularly hard problems. In fact, the only times I can remember is here on WP in talk page discussions arguing about whether to use them. It simply isn't used in the industry to any great extent. Stepho talk 22:55, 25 April 2021 (UTC)
@ Compvis, Jc3s5h, Cybercobra, Woodstone, Greg L, Art LaPella, Seraphimblade, MJCdetroit, Pyrotec, Theaveng, and Cyde: ping'ing editors from the prior discussions since this has apparently turned into a larger discussion. Dondervogel 2 is attempting to use IEC units as disambiguation in articles despite longstanding recommendations being available here at WP:COMPUNITS. My reading is that there are very few exceptions for using IEC, and most are around whether the majority of sources use them or not, and whether or not it's possible to use one of the other methods to disambiguate the terms. Additional input would be appreciated. — Locke Cole • t • c 18:27, 3 May 2021 (UTC)
@ Dondervogel 2: I'm not sure if it was obvious, but this discussion is largely over. COMPUNITS is not changing, and we're not going to be using IEC units in articles. If you persist in attempting to add them in to articles, you may be blocked for disruption as there is clearly no consensus to use IEC in articles, and simply arguing at length until your opponents tire and go away is not "consensus" as you seem to think. I'm going to revert your additions to the various Apple articles. If you re-add them, then the next step will be a visit to WP:AN/I. Stop now. — Locke Cole • t • c 19:41, 14 June 2021 (UTC)
Withdrawing from communication with a tendentious or quarrelsome editor does not give that editor consent to do what they like.
I’ve not once proposed a change to mosnum: yes, you've just wanted to re-litigate IEC prefixes in each and every instance despite the guideline clearly saying they are "not to be used". But sure, you're not trying to change the MOS, you're just trying to ignore it and run roughshod over existing consensus.
Where there is a global consensus to edit in a certain way, it should be respected and cannot be overruled by a local consensus.COMPUNITS is the existing global consensus, stop proposing edits that run counter to it. — Locke Cole • t • c 20:13, 19 June 2021 (UTC)
The articles in question do use mixed prefixes and using inflationary footnotes is impractical, IMHO ( see example). Nonetheless, you keep reverting, and your way of disrupting discussion and replying to arguments at least borders on harassment to me. -- Zac67 ( talk) 07:39, 20 June 2021 (UTC)The IEC prefixes kibi- (symbol Ki), mebi- (Mi), gibi- (Gi), etc., are generally not to be used except [...] in articles in which both types of prefix are used with neither clearly primary, or in which converting all quantities to one or the other type would be misleading or lose necessary precision, or declaring the actual meaning of a unit on each use would be impractical.
when the majority of cited sources on the article topic use IEC prefixes;, or let's ignore that (you guys clearly are), if you really believe the "or" gives you carte blanche to override policies like WP:V and WP:NOR from a guideline (hint: MOS does not have the ability to circumvent WP:V and WP:NOR; you'd still need sources that use IEC prefixes). And of course you also completely ignore
or declaring the actual meaning of a unit on each use would be impractical.. it would not be impracticle to have a footnote with relevent values to inform the reader of the difference using simple, easy to use language like "1 GB = 1 billion bytes" (or use one of the examples for disambiguating provided that do not involve using IEC). I hope using logic and reason here isn't some weird backhanded harassment for you, I wouldn't want you to feel harassed. If I need to do something to make this reply less harassing, please let me know. Maybe I can just let your reply sit for a month and then I'll spontaneously reply to it. That appears to be what passes for perfectly acceptable behavior for you. — Locke Cole • t • c 17:42, 20 June 2021 (UTC)
Apparently, you can't be bothered with facts or policyReally? You suppose the weeks of conversation below were just imaginary? I mean you didn't respond to the print media sourcing, or to the scholarly works commentary, so maybe you just ignore things you don't like? Just because you want to pretend the sky is green doesn't mean I have to play along. As to "facts" and "policy", sure, here you go:
The [...] never use them has been disproven... oh has it? Care to show me where?
You demand scientific sources, ...I did no such thing. In fact, I have no idea why Dondervogel presented scholarly papers, my only theory is that it has something to do with their nearly religious maintenance of User:Thunderbird2/The case against deprecation of IEC prefixes ( | talk | history | links | watch | logs) where they have apparently made it their mission to cling to the notion that usage in Google Scholar visible papers is somehow relevant (I actually don't think they are, I think wider use in the media (print/web/television) is more relevant, as is usage by manufacturers and software companies).
Who's the die-hard here?Uh... is that rhetorical? I've only been involved in this discussion for a few months. Some of you people have been at this for over a fucking decade and won't give up. So... [w]ho's the die-hard here? is not me. I'm just not afraid to call out bullshit. :D I hate to keep saying it, but WP:CIR is still looking more and more relevant. — Locke Cole • t • c 06:48, 21 June 2021 (UTC)
@
Archon 2488: I'm starting to think you haven't read much of this thread. So we're now openly insinuating that the editors who don't agree with this very broad interpretation of verifiability ...
So my alternative choice is to assume Dondervogel 2 is acting in bad faith, not incompetence. However, according to
WP:AGF, I need to assume good faith. So I am. I assume the reason they continue on as they do is because they don't understand what they're talking about. This is a much better assumption than assuming malicious intent. And I note with interest that you have, in your userspace, an essay outlining why "
IEC units are bad" – how's that for a neutral POV?
Wonderful. Dondervogel 2 also has
User:Thunderbird2/The case against deprecation of IEC prefixes, I'm sure this "interests" you as well? Or perhaps not? Also, if you've read my userspace "essay" you'd see it is simply a collection of my arguments from this broader discussion in an easier to digest form.
... regardless of circumstances or context, that anyone who suggests using IEC prefixes in any situation is to be treated as a dangerous crank or an incompetent charlatan.
I mean, those are your words. But after two months, and disruptive behavior from Dondervogel 2 (such as starting multiple forked conversations across nearly a dozen pages now, which I've had to corral back here, where they still insist on fragmenting the discussions anyways even though the topic is largely the same). I've engaged them on their "sources", I've provided counterpoints, and as nobody here seems convinced to take this any further,
WP:COMPUNITS stands. Nothing is going to change, as I said above, and so the status quo, The
IEC prefixes kibi- (symbol Ki), mebi- (Mi), gibi- (Gi), etc., are generally not to be used
stands. Now as to your broader attack on MOSNUM in general, knock it off. A manual of style that helps provide a consistent experience for our readers is something the editors of this project have decided they think is valuable. I'm sorry you think we should be carving out exceptions across the project, but that way lies confusion for both our readers and our editors. We have methods of disambiguation provided, and certainly using other methods is not unacceptable (especially if they match what our sources say), however, using IEC units is not one of those options (except in very specific instances).
I sincerely regret not taking this to AN/I immediately as I was told to do at the start of this thread. I regret taking the time to listen to Dondervogel 2, to consider their "sources", to listen to their arguments, and to try and keep an open mind. Clearly I should have addressed the core behavioral problem before letting this go off the rails for two months, and that mistake is on me. Thanks for making it crystal clear to me now. — Locke Cole • t • c 03:50, 22 June 2021 (UTC)
Now as to your broader attack on MOSNUM in general...I honestly have no idea where you got the idea that I'm attacking MOSNUM, not least because I've participated in many discussions here over the years. I never said anything to the effect of
carving out exceptions across the project; closest I came was vaguely implying I'd be OK with the MOS allowing IEC to be used in a wider scope – and since we already recommend glossing less common units,
Units unfamiliar to general readers should be presented as a name–symbol pair on first use, linking the unit name, I personally think this is unlikely to be as much of a problem for readers as it is for those editors who stridently object to IEC. But as I said before, this isn't a subject I have a huge personal stake in; I do however take it as a good sign when editors who have been less involved in divisive, recurring MOS disputes such as this one feel comfortable to come forward and offer their input. A large part of the problem with yelling accusations of incompetence, Dunning-Kruger, or bad faith, is not so much that it's abusive to the editor directly targeted, but that others who are observing but not actively participating will feel much less inclined to join such a toxic discussion. Hence you end up with an "evaporative cooling" effect in which all but the most stridently opinionated people have left, or left well enough alone.
WP:COMPUNITS is not a licence to introduce ambiguity in any article. I have restored an earlier, stable version of the article so we can discuss the disputed edits since 20 April. Relevant statements include:
The bottom line is that disambiguation is needed. The only question is how. It's hard to satisfy all three requirements, suggesting WP:IAR as the only practical guideline, and disambiguation using the most practical method to hand. What do others think? Dondervogel 2 ( talk) 16:46, 24 April 2021 (UTC)
No. That's not the solution. A Gbit is either 1000^3 bit or 1024^3 bit. At the moment it's both but we need to choose between them. Which is it? Dondervogel 2 ( talk) 09:08, 2 May 2021 (UTC)
@
Tom94022 and
Dondervogel 2:
Quoting the first sentence of
WP:CALC: Routine calculations do not count as original research, provided there is
consensus among editors that the result of the calculation is obvious, correct, and a meaningful reflection of the
sources.
Let's take the requirements one by one:
[…] provided there is consensus among editors […]– seems like an important point;
[…] that the result of the calculation is obvious, correct, […]– no disagreement there, as the IEC units as defined are a drop-in replacement for the classic metric unit names;
[…] and a meaningful reflection of the sources– …and here is where it all falls to pieces, very few reliable sources use these IEC units/prefixes. The vast majority, I'd expect somewhere north of 95% of sources use the classic kilobyte/KB, megabyte/MB, gigabyte/GB, terabyte/TB and so on. And regardless of that, the language here at WP:COMPUNITS has enjoyed consensus for over a decade. It is unacceptable to disrupt editors working to implement our style guidelines because you disagree with the result of the discussions here. If you want to change WP:COMPUNITS, this is the place to hold that discussion. That being said, endless debate because you disagree with what the majority supports is not going to work: Wikipedia does not have a filibuster. — Locke Cole • t • c 16:23, 30 April 2021 (UTC)
[…] or declaring the actual meaning of a unit on each use would be impractical.My edit shows that using {{ BDprefix}} made it possible to declare the actual meaning of each unit. This also keeps it in line with our sources which do not use GiB or MiB or KiB. — Locke Cole • t • c 17:58, 30 April 2021 (UTC)
The appropriate place for this discussion is Talk:Memory_hierarchy#IEC_units where the editors of that article can decide which section of this article is most applicable. Locke Cole is formum shopping by raising it here and any editor having knowledge and interest in application of IEC prefixes to memory hierarchy should comment there. Tom94022 ( talk) 17:40, 30 April 2021 (UTC)
Google query results | |||
---|---|---|---|
Newspaper | site:<URL> "gibibyte" | site:<URL> "gigabyte" | site:<URL> " fatberg" [1] |
usatoday.com | 0 | 745 | 26 |
wsj.com | 1 [2] | 2,890 | 2 |
nytimes.com | 1 | 4,610 | 168 |
nypost.com | 0 | 234 | 130 |
latimes.com | 0 | 1,390 | 5 |
washingtonpost.com | 0 | 971 | 47 |
startribune.com | 0 | 410 | 1 |
newsday.com | 0 | 270 | 0 |
chicagotribune.com | 0 | 952 | 41 |
bostonglobe.com | 0 | 278 | 3 |
Extra entries for fun | |||
seattletimes.com | 0 | 611 | 23 |
seattlepi.com | 0 | 383 | 0 |
International (English-speaking) | |||
timesofindia.com | 0 | 490 | 4 |
metro.co.uk | 0 | 109 | 2,290 |
thesun.co.uk | 0 | 137 | 135 |
dailymail.co.uk | 0 | 710 | 318 |
www.standard.co.uk | 0 | 88 | 17,900 [3] |
mirror.co.uk | 0 | 154 | 170 |
thetimes.co.uk | 0 | 439 | 65 |
www.telegraph.co.uk | 0 | 407 | 72 |
theguardian.com | 0 | 546 | 3,270 [4] |
heraldsun.com.au | 0 | 76 | 26 |
www.dailytelegraph.com.au | 0 | 84 | 45 |
www.couriermail.com.au | 0 | 49 | 34 |
www.smh.com.au | 0 | 1,030 | 29 |
www.theaustralian.com.au | 0 | 364 | 8 |
www.theglobeandmail.com | 0 | 602 | 2 |
www.thestar.com | 0 | 387 | 22 |
nationalpost.com | 0 | 58 | 49 |
No "site:" filtering, just the terms in quotes | |||
213,000 | 72,400,000 | 238,000 |
(In 1997 a standards body tried to clarify things by renaming the binary-derived units as gibibytes, which tells you all you need to know about the usefulness of engineers tinkering with language.)
I may expand this, but as a datapoint I thought it might be interesting to see. — Locke Cole • t • c 15:30, 1 May 2021 (UTC)
If not they are not relevant to the discussion.Sorry, what? In what universe do you think the media-at-large not using the terms you're pushing is somehow not a death-knell for the idea at the outset? And I'll say again, I've yet to see any sources in the articles I've changed which utilized IEC units, let alone any with a ratio of IEC being more prominent than the traditional metric units. Wikipedia is not a platform to push your agenda. — Locke Cole • t • c 19:11, 1 May 2021 (UTC)
Archon 2488 ( talk) 09:36, 14 June 2021 (UTC)The SI prefixes refer strictly to powers of 10. They should not be used to indicate powers of 2 (for example, one kilobit represents 1000 bits and not 1024 bits). The names and symbols for prefixes to be used with powers of 2 are recommended as follows: [tabulated IEC prefixes]
the ones that do disambiguate use IEC prefixesis simply not true. — Locke Cole • t • c 15:32, 7 May 2021 (UTC)
The IEC prefixes kibi- (symbol Ki), mebi- (Mi), gibi- (Gi), etc., are generally not to be used. There are already methods in COMPUNITS to disambiguate that do not involve using IEC units. You're not convincing anyone with this game you're playing at where you fork these discussions (which are largely about the same fucking thing) and then pretend you don't see or choose to ignore conversations that don't go as you wanted. The IEC units are not widely used by our reliable sources, by the media at large, by scholarly works, or by businesses and manufacturers in the industry. Full stop, end of story. I'm done here unless someone besides you says something even remotely compelling. — Locke Cole • t • c 08:08, 9 May 2021 (UTC)
like a moth to the flame I can't resist; so long as you don't set yourself alight because I might still take you up on that hose offer above. Luckily I can see titles and an abstract for the Springer/IEEE links, so really you just need to look at 1) how prominent SDRAM is as a topic to the paper overall (is it mentioned in passing as a dry tech spec, is SDRAM itself actually discussed in great detail, or..?), 2) is the paper using IEC units (KiB/kibibyte, MiB/mebibyte, GiB/gibibyte, TiB/tebibyte, etc) and 3) does the paper also utilize decimal versions of the metric units (KB/kilobyte, MB/megabyte, GB/gigabyte, TB/terabyte, etc). Here's the links in table form, just fill in the blanks:
Link | Title | Authors | 1) SDRAM prominence | 2) Uses IEC units | 3) Uses metric units |
---|---|---|---|---|---|
[4] | LEON Processor Devices for Space Missions: First 20 Years of LEON in Space | Andersson et al, 2017 | Totality of referencex to SDRAM, KB, MB, GB, KiB, MiB, GiB, Kbit, Mbit, Gbitare: *PROM/SRAM/SDRAM memory controller ... 32 MiB PROM ... 32 MiB SRAM ... 512 MiB SDRAM ... 192 KiB on-chip RAM | ||
[5] | BiPS – A Real-Time-Capable Protocol Framework for Wireless Networked Control Systems and Its Application | Engel et al, 2019 | Intel XScale PXA 270 controller with 256 KiB SRAM, 32 MiB SDRAM, and 32 MiB FLASH. It supports clock rates up to 416 MHz | ||
[6] | Implementation Aspects of ProNet 4.0 | Gotzhein, 2020 | Intel XScale PXA271 processor with 256 KiB SRAM, 32 MiB SDRAM, and 32 MiB FLASH ... clock rates up to 416 MHz ... executed from SDRAM ... platform offers 32 MiB flash memory ... provides 256 KiB SRAM and 32 MiB SDRAM ... consumed only about 59 KiB ... 59 KiB static memory and 26 KiB dynamic ... needs at least 140 KiB static and 26 KiB dynamic ... consumes about 350 KiB static and 26 KiB dynamic ... | ||
[7] | An efficient SpiNNaker implementation of the Neural Engineering Framework | Mundy et al 2015 | *32 KiB for instructions and 64 KiB for data; and shares 128 MiB of off-chip SDRAM |
@ Dondervogel 2: At User:Thunderbird2/The case against deprecation of IEC prefixes, which you apparently have religiously updated over the years, there is a Google Scholars link that you use to determine how many articles are using IEC units. I note that currently for the 2020-2022 period there are 582 hits for MiB/GiB. That same search ran with MB/GB returns 44,900. Granted, some of those may be false positives (since MB/GB are more likely to occur as initials for other terms), so for clarity I ran the search using mebibytes/gibibytes and megabytes/gigabytes. There were 28 hits for the IEC unit, and 1,560 for the traditional metric unit. It would seem, even among research papers, that IEC units make up a small fragment, about 1.76%. Metric units accounted for 98.23% of the results. As I've already explained above, the wider media at large does not use the IEC units whatsoever, and their use in academic circles appears to be vastly outnumbered by the traditional metric units. — Locke Cole • t • c 16:06, 3 May 2021 (UTC)
I just stopped Dondervogel 2 ( talk · contribs) from moving yet another conversation here from Talk:SD card. Is there any consensus for having multiple almost identical discussions? When I started this discussion it was with a goal of letting them see if they can convince editors here to change WP:COMPUNITS to allow for more IEC usage. Dondervogel 2 has forked this conversation into separate discussions unnecessarily as the issue is not with these individual articles, but rather with whether or not IEC units are something the editors here feel have reached a point where they should be used in Wikipedia-at-large. After the AN/EW closure I thought we might see some actual discussion, but instead I see Dondervogel has returned to starting forest fires and trying to fork these conversations. So again: Is there any consensus for having multiple discussions here on different articles? — Locke Cole • t • c 17:08, 3 May 2021 (UTC)
Does the discussion about changes to SD card belong at the article's talk page or on MOSNUM? Dondervogel 2 ( talk) 17:30, 3 May 2021 (UTC)
The community has spoken on this issue. Thunderbird2 was without a doubt the most tendentious editor I ever experienced. I don’t know if the fact that years have passed makes this tendentiousness more forgivable or less. The purpose of a general-interest encyclopedia is to communicate clearly. There are many things in the world that should have had better naming conventions, like planetary nebula, which have nothing at all to do with planets, but a general-interest encyclopedia goes with the flow and doesn’t try to effect change in an “Oh, didn’tcha know”-fashion by using unconventional terminology that 99% of our readership has never seen before… all in the vain hope that somehow our leadership might catch on with the rest of the world.
As a general-interest encyclopedia, Wikipedia follows the standard conventions used throughout the dominant bulk of the computer industry. The vast majority of the computer industry, including industry leaders of DRAM like Crucial ( here) Micron ( here) use conventional terminology familiar to every single computer user, from the aficionado to experts. Industry-leading manufacturers of PCs, like Dell here) and Apple ( here) also use conventional technology. If you want to buy DRAM at an online retailer, they are smart enough to use conventional terminology ( Amazon, here). The use of non-standard terminology is confusing and a disservice to our readership.
Why are we even debating Thunderbird2/Dondervogel 2? He’s out in left field tilting at technology windmills. We have better things to do in life than deal with tendentious. Doesn’t Wikipedia have an expedient system to just say “No. Move on”? Greg L ( talk) 05:50, 4 May 2021 (UTC)
You underestimate the usage in the real world.#IEC usage in print media, #IEC units in scholarly writings; and you grossly overestimate their use in the real world. — Locke Cole • t • c 07:48, 7 May 2021 (UTC)
when the majority of cited sources on the article topic use IEC prefixes;as one of the reasons one could conceivably use IEC units. Which I think is reasonable, but in the end, it's just a different way of tackling WP:V and WP:NPOV (specifically, WP:UNDUE). And given the data I've presented above, there seems to be very little use of IEC units compared to the traditional metric units for computing articles, so really it ought to be a moot point. But, here we are... — Locke Cole • t • c 20:53, 4 May 2021 (UTC)
when the majority of cited sources on the article topic use IEC prefixeslooks fine but I fear it's being stretched too far. For example, if the majority of sources on RAM used IEC prefixes, that might justify using IEC prefixes in an article about RAM. But I've found IEC prefixes being used in articles about iPads to say how much RAM they have. There are 87 references for iPad 2. I haven't checked them all but frankly, if someone wants to make the extraordinary claim that most of them use IEC prefixes, they need to produce the extraordinary proof.
I wholeheartedly agree with what NebY wrote. To merely speak about “64 MB” DRAM in an article that is also discussing hard drive sizes does not…
For the most part, it suffices to merely write that Alpha’s XYZ computer had 4 GB of RAM and a 1 TB hard drive but their XYZ-8 computer had 8 GB of RAM. In most cases, the reader really only needs to know—and only wants to know—that the XYZ-8 has twice the RAM.
It is a rare instance that mere mentioning of both attributes within an article requires “disambiguation,” which often really only means “explain the small difference in actual magnitude.” One example that quickly comes to mind is when one is writing about very arcane technical details pertaining to swapping data in and out of a RAM disk. And even then, one can make the technical details perfectly clear while using conventional units of measure that are commonly used in the computer industry and which 999 milliuno of our readership are perfectly familiar with.
Good technical writing is that which is suitable for its intended audience, informs and educates quickly, does so with ease and makes for an enjoyable experience, and does so without drawing attention to itself. Greg L ( talk) 02:14, 5 May 2021 (UTC)
1 TB RAM(implying 10244) and
1 TB HDD(implying 10004) side by side? Mind you, the "small" error is roughly 10 % (1.0244) – the deviance has grown quite a bit since we've used kilobytes and it won't stop there. Also, that ambiguity totally ignores
Do not assume that the binary or decimal meaning of prefixes will be obvious to everyone.-- Zac67 ( talk) 05:11, 5 May 2021 (UTC)
Here are a few examples of the consequences for our articles, for those of us who find it easier to compare examples directly rather than follow a sea of links. They're from recent versions of a rather random selection of articles from this interaction list. These may not represent editors' best efforts, of course.
Article | preferring IEC units | not preferring IEC units |
---|---|---|
X86-64 | This allows up to 256
TiB (248
bytes) of virtual address space.
... this would allow addressing of up to 4 PiB of RAM. etc |
This allows up to 256
TB (248
bytes) of virtual address space.
... this would allow addressing of up to 4 PB of RAM |
WinZip | Beginning with WinZip 9.0, ZIP64 archives are supported, eliminating ... the 4-
gibibyte size limit
[sole instance in this article] |
Beginning with WinZip 9.0, ZIP64 archives are supported, eliminating ... the 4- gigabyte size limit |
SD card | format supports cards up to 128
TiB or 140,737488355328 TB or 140 737 488 355 328 bytes (SI) or 154 742 504 910 672,534362390528 (Binary) and offers
... supports cards up to 2 TiB (2199023255552 bytes) ... but it requires the use of 64 KiB clusters etc |
format supports cards up to 128
TB and offers
... supports cards up to 2 TB (2199023255552 bytes).. ... but it requires the use of 64 KB clusters |
IPad Pro (4th generation) | [infobox] Memory 6
GiB RAM
... the RAM was increased from 4 to 6 GiB on the 128 GB, 256 GB and 512 GB models etc |
Memory 6 GB RAM
.... the RAM was increased from 4 to 6 GB (4-6 GiB) on the 128 GB, 256 GB and 512 GB models |
Synchronous dynamic random-access memory | For reference, a row of a 1
Gibit
DDR3 device is 2,048
bits wide
etc |
For reference, a row of a 1 Gbit [1] DDR3 device is 2,048 bits wide |
References
Over at the talk page for Template:Quantities of bytes ( | talk | history | links | watch | logs) in the section Recent Edit to Table the discussion has somehow switched to how JEDEC memory units are being given undue weight in the template (despite the presence of IEC units which, as shown above in media and scholarly use, are basically non-existent in sources or the wider media-at-large). Interested editors may wish to chime in there; I didn't initially move the discussion here because it started out innocently enough as a discussion about whether or not JEDEC terabyte should be in the table, but now the discussion has taken a turn to whether or not JEDEC units belong at all... I'm personally of the opinion that the IEC units are the ones being given undue weight, and we're effectively pushing a fringe theory by even giving them this much life outside of the IEC standards article(s), but more opinions would be appreciated. — Locke Cole • t • c 16:42, 5 May 2021 (UTC)
Why are the capacities in the thumbnail descriptions given in powers of 1000 (or 10x where x is an int), e.g MB, GB, TB, while elsewhere they are in powers of 1024 (or 2x where x % 10 = 0), e.g MiB, GiB, TiB? I'm concerned because as the capacities increase, esp for TB vs TiB and PB vs PiB, the difference in bytes is huge.
Fezzy1347 ( talk) 17:12, 25 May 2020 (UTC)
Let me point out one example of the problem I see.The case you cite is a blatant failure to wp:think of the reader. Any given article should use the initialism with just one and only one meaning throughout. (IMO, it also should have a comment note that advices future editors of that choice – I thinking of something like {{ use DMY dates}}.) In the exceptional case where both meanings are needed,
Locke Cole is now back-tracking and claims he doesn't care where the discussion is held- I've done no such thing. Stop lying. — Locke Cole • t • c 21:16, 14 May 2021 (UTC)
The GiB notation has never gained acceptance and Wikipedia cannot assume that readers (and many editors) have ever even seen it, let alone know what it means.That remains my position. This notation does not solve your
example of the problembecause readers will not know what it means, any more than if you had suggested we use the Chinese character. The only practical solution is to spell out abbreviations clearly: if we mean 1,073,741,824 then that is what we should say. What we must not do in the same article is have GB mean 109 in one sentence and have it mean 230 in the next sentence. -- John Maynard Friedman ( talk) 23:22, 14 May 2021 (UTC)
This is the correct place to discuss it. It is a problem that comes up in many computer related articles, so thrashing it out in a single article's talk page will just make it a discussion that has to be repeated for each and every article - what a waste of time!
To summarise the problem (using GB in the examples but also applying to the other prefixes): some uses of GB (giga bytes) means 10^9 and some mean 2^30. Some editors prefer to:
The short explanation is that memory this is directly addressable by the CPU (eg RAM, ROM) uses powers of 2 while practically everything else uses powers of 10 (eg hard drives, thumb drives and anything to do with rates or time). It is the directly addressable part that is critical. For RAM or ROM the CPU has to provide a certain number of binary address lines, so the size must be a power of 2. For devices that have some type of interface (eg IDE/PATA, SATA, USB), the address is sent as a number within a command. The remote device is free to remap that address in any way that it feels fit (eg, hard drives mapped a single address into cylinder, head, sector and the CHS numbers were usually not powers of 2), so the address is not constrained to powers of 2. This is anecdotal but based on my 3-4 decades of professional experience designing/programming computers.
Trying to explain to explain this in every computer article will just clutter up every article. Instead, I suggest that most articles are just left in the ambiguous state. After all, most readers don't really care about a 7% difference - most readers don't even know or care how much RAM their PC or phone has, only that it has enough. The people that care tend to already know when to use 10^9 or 2^30. But some articles that cover a broad topic like RAM, hard disk, or SD Card can spell out the appropriate form (or forms if it needs to specify capacity in powers of 2 and rates in powers of 10). Stepho talk 01:54, 15 May 2021 (UTC)
This article by the editor of Macworld explains the storage capacity of iPhones, iPads and iPods, and leads with "What is the true formatted storage capacity of an iPhone, iPad or iPod - how many songs, films, apps and games can they hold? And why is the true capacity lower than the advertised figure?". To make himself clear the author uses GB to mean 1000^3 B and GiB to mean 1024^3 B. The introduction to the article reads
128GB: approx. 114GiB 64GB: approx. 56.5GiB 32GB: approx. 27.5GiB 16GB: approx. 11.5GiB
The article was cited in several Wikipedia articles, but it seems to have been removed. I suggest reinstating the reference because it helps to explain the storage capacity in a language WP readers can understand. Dondervogel 2 ( talk) 08:19, 30 May 2021 (UTC)
It is a fool's errand to try to nail the exact size down. Which size are you after?
For the most part, user don't care about the exact number - as long as it is in the ball park. Stepho talk 02:43, 20 June 2021 (UTC)
References
Wikipedia strongly prefers secondary sources, so objecting because something is not a primary source is no kind of argument that WP entertains. — SMcCandlish ☏ ¢ 😼 14:24, 30 July 2021 (UTC)
Somewhat related to all of the above, but apparently a small group of editors has decided that the JEDEC definitions of kilobyte, megabyte, gigabyte, etc. are "deprecated" based on a poor reading of the definition here. See {{ Quantities of bits}} and {{ Quantities of bytes}}, and the discussion at Template talk:Quantities of bytes. It's relevant here because {{ Bit and byte prefixes}} which is included in WP:COMPUNITS and is similarly designed, also contains a "JEDEC" header. — Locke Cole • t • c 17:32, 21 June 2021 (UTC)
[t]o give false information intentionally with intent to deceive.) is a problem for them, but the proof is in the diffs where they've repeatedly misrepresented the truth for their own ends: [18] [19] (notwithstanding the claims of consensus for "deprecating" units without actually having consensus, or the distortion of reality one has to live in to push IEC units like they do). — Locke Cole • t • c 15:07, 30 June 2021 (UTC)
Right, this has gone far enough and is getting unhealthy. I've made an ANI post about it. Archon 2488 ( talk) 15:29, 30 June 2021 (UTC)
Currently two-digit ending years allowed in two consecutive years, however I believe that this should be clarified for recurring events such as sport (example 2019–20 UEFA Champions League). Not for a single event ( Indonesian mass killings of 1965–66 & 2019–20 coronavirus pandemic (before moved to COVID-19 pandemic)), because it looks ambiguous. Hddty ( talk) 03:31, 21 August 2021 (UTC)
In the line 0123 notation for octal is unclear. In prose use 1238. If needed for computer code samples, explain the prefix on first use.
, what is "the prefix"? If it's meant as a reference to the 8 at the end of 1238, that's not a prefix but something more like a suffix. (Judging by
the computing sense of prefix, "123" could be described as a prefix, but if this is what is meant, it could be expressed more intelligibly by using another phrase like "explain the notation".)
Our article says octal can be indicated by "a variety of prefixes, including the digit 0, the letters o or q, the digit–letter combination 0o [...as in] 073, o73, q73, 0o73", but if the guideline is meant as an exhortation to explain those on first use, it should actually mention one of them, IMO.
-sche (
talk)
01:32, 9 August 2021 (UTC)
"For octal, the prefix 0 is unclear (0201) and other prefixes may be unfamiliar; avoid using a prefix unless it is needed for computer code samples, in which case explain the prefix on first use. In prose, use the subscript 8 (2018) or avoid octal entirely as a crime against nature."?
There is a discussion at Wikipedia:Administrators' noticeboard#Cleaning up stale general sanctions on a proposal to revoke authorisation for sanctions including Wikipedia:General sanctions/Units in the United Kingdom. NebY ( talk) 17:51, 1 September 2021 (UTC)
MOS:ERA currently has the following wording:
BP or YBP: In scientific and academic contexts, BP (Before Present) or YBP (years Before Present) are often used. (Present in this context by convention refers to January 1, 1950.) Write 3000 years BP or 3000 YBP or 3000 years before present but not forms such as 3000 before present and 3000 years before the present. If one of the abbreviated forms is used, link to Before Present on first use: The Jones artifact was dated to 4000 YBP, the Smith artifact to 5000 YBP.
Why does it use capitalization in "BP (Before Present) or YBP (years Before Present)" but not in "Write ... 3000 years before present"? It seems that a large portion of scientific literature does not capitalize this term in any context, so according to MOS:CAPS, the first sentence should use the lower case as well ("BP (before present) or YBP (years before present)"). I've nominated the article Before Present to be renamed to Before present based on these considerations, but this was met with a strong opposition from several editors, although they've failed to provide substantial evidence (see the discussion). Could anybody here help them to prove that it must be capitalized? Or we should indeed switch to the lower case? — Mikhail Ryazanov ( talk) 20:25, 10 August 2021 (UTC)
Capitalising the term Before Present in keeping with its initialism is perfectly normal— MOS:EXPABBR disagrees, saying "Do not apply initial capitals ... just because capitals are used in its abbreviation". Mitch Ames ( talk) 04:57, 11 August 2021 (UTC)
as concept in its own right— MOS:CAPS says "capitalization is primarily needed for proper names", not "... concept in its own right". If you mean "proper name" (which has an entire article tells us what it means, so we know) it would probably be better to say so. Inventing new terms (that are not in MOS) probably won't help the discussion. Mitch Ames ( talk) 12:30, 11 August 2021 (UTC)
@ Mikhail Ryazanov:, if you look at the dates example, the MOS says this:
Phrases such as Fourth of July (or July Fourth, but not July 4th), Cinco de Mayo, Seventh of March Speech, and Sete de Setembro are proper names, to which rules for dates do not apply (A typical Fourth of July celebration includes fireworks).
Note how the example of correct usage doesn't wlink Fourth of July. (Otherwise it would imply that every time you write the phrase "Fourth of July", you should link it?) The point of the MOS is to recommend (sometimes strongly) how text should be written; when to apply a wikilink is in a different cookie jar. So I think that the answer to your question is that the MOS as it stands is correct and consistent with the way that similar rules of the MOS are written. Of course if your RtM succeeds, the article reference will need changing. Does that help? -- John Maynard Friedman ( talk) 18:28, 11 August 2021 (UTC)
References
Earlier this month, Daniel Case changed the syntax of The Exorcist's RT approval rating from "83%" to "83 percent", citing MOS:%. Later, when I updated the Rotten Tomatoes data on the film, I changed it back to the percent sign for two main reasons:
Frankly, I don't see why the suggestion in MOS:% should supercede the standard set by Wikipedia's film articles, especially given that MOS:% merely says that use of the word percent in non-scientific articles is common, not that it should be used. We should allow the shorter character to keep carrying the score. Songwaters ( talk) 01:10, 20 August 2021 (UTC)
So apparently there is a dispute about quarterly dates in MOS:DATEFORMAT and MOS:DATESNO:
The initial addition was made as the result of this discussion at Help talk:Citation Style 1. As I said there, I don't think that the addition here is appropriate because cs1|2 does not determine how dates in article text are to be formatted. cs1|2 has adopted MOS:DATE as its standard for date formats. Help:Citation Style 1 § Date compliance with Wikipedia's Manual of Style lists the parts of MOS:DATE with which cs1|2 does or does not comply. In the table there, the format of quarterly dates, not previously specified here, is defined. For cs1|2, that is all that is required so the quarterly date specification here is not required unless or until it becomes necessary to specify a quarterly date format for article text. The addition to MOS:DATEFORMAT and MOS:DATESNO should be reverted.
— Trappist the monk ( talk) 17:47, 29 August 2021 (UTC)
First Quarter 2020may be appropriate for citations, it's certainly not appropriate for general article text, which strengthens the idea that it doesn't belong in this guideline at all.So it seems to me that the mention at Help: (linked by Trappist above) is exactly the right place to touch on this. Second choice (distant second choice) would be something in 2.5, as mentioned. E Eng 20:49, 29 August 2021 (UTC)
@ EEng: What is inappropriate about quarters? I understand the reason for avoiding seasons whenever possible as they are so ambiguous, but working in quarters in very common in the business world. Hawkeye7 (discuss) 04:20, 30 August 2021 (UTC)
Jul–Sep 1952, not Q-something. Though it occurs to me that might be misinterpreted as an unusually difficult labor. E Eng 11:36, 30 August 2021 (UTC)
Wikipedia:Categories for discussion/Log/2021 March 3#Category:10¼ in gauge railways in England decided to keep the precomposed fraction in that title. That discussion has a list of categories with precomposed fractions (collapsed) all of which are either about railroads (under e.g. [[:Category:Track gauges by imperial unit) or Ranma ½, except Category:The 2½ Pillars of Wisdom and Category:Lil' ½ Dead albums.
There are lots of articles that have precomposed fractions in the title which MOS:FRAC says should do something else in the body, for example:
ASCII vulgar fractions seem rare in article titles, but I did find 1/2 + 1/4 + 1/8 + 1/16 + ⋯. It appears 1/16 is not available as a precomposed Unicode character.
On Talk:Ranma ½#Fraction in page title we discussed ways to use DISPLAYTITLE to make an ASCII fraction title consistent in appearance with {{ frac}}, which is how the current MOS guidance indicates the title should be rendered in body text, like so: "Ranma 1⁄2". I've done this at Draft:Ranma 1/2 and it seems to work. (FTR, with "{{DISPLAYTITLE:{{NAMESPACE}}:Ranma <sup>1</sup>/<sub>2</sub>}}", in case the draft is deleted again.) An alternative proposed in that discussion was to simply leave the title as "Ranma ½" with a precomposed fraction. That raises the question of whether the MOS should be changed to make the article body consistent with the title.
Considerations:
I'm not sure what the best reconciliation is, and if there are other considerations or opinions worth mentioning, so I'm starting a discussion here. To get things started, here are some possibilities:
I think 2A would be the easiest to implement; we're already most of the way there. The other options for 2 require "if X then Y else Z" rules, which make it considerably more difficult to automate compliance.
-- Beland ( talk) 23:28, 9 September 2021 (UTC)
OK, so if that gets moved to "Spin-1/2", here's a stab at taking into account the other comments above and what Graham87 mentioned on Wikipedia talk:Manual of Style/Mathematics#Accessibility of precomposed fraction characters - it sounds like we don't care to impose any particular style on non-science/math articles, but that only some precomposed fractions are screenreader-friendly. If so, then maybe a small note in the section applicable to science/math articles, changing:
1/2
to something like:
1/2
(and this style should be used for article titles like
Spin-1/2)and a broadening of the chess exception to general guidance, changing:
½
½
to something like [edited to spell it "screen reader"]:
½
½
References
?
This would mean, for example, that the existing title Naked Gun 33⅓: The Final Insult is not OK and I think would have to be moved to Naked Gun 33 1/3: The Final Insult? That also looks like a problem for Category:4 ft 10⅞ in gauge railways, though that seems to be the only problematic category. -- Beland ( talk) 07:44, 11 September 2021 (UTC)
I published this statement and it got reverted: "Figures and numbers tend to be more easily understood than words by non-native English speakers." and my brief summary was: "maybe not the best place but this fact must be stated in a quite visible place in MoS!".
I didn't think it was a substantive edit to the page, nor it should reflect "formal" consensus. It could just have been moved at the most appropriate place on the page!
This is obvious for people who read in a language other than their mother tongue: "the reading of numbers as words needs translation for understanding", while "the reading of the figures and numbers allows an instantaneous comprehension without possible error (as most parts of the world use Arabic numerals)"
Unless you speak German, if you switch to [ de.wikipedia.org], the only things that you will understand instantaneously are years and figures/numbers. If you speak German, try switching to Finish: [ fi.wikipedia.org], Danish...
Obviously some editors want bureaucracy. — Antoine Legrand ( talk) 12:43, 16 September 2021 (UTC)
An IP range has taken it upon themselves to change date formatting for a large number of European BLP's and topics. Rather than getting into an edit war with them I wanted to seek some clarification. There seems to be a grey area between what is being implied in MOS:DATETIES that date format's should only changed based on ties to an English speaking country, rather any date format associated with every country. Given this, it seems that MOS:DATEVAR applies which states we shouldn't be changing pre-existing formats for an article? Do we want this to continue and should such changes be discouraged? Seddon talk 14:24, 11 September 2021 (UTC)
"we follow European date formats ... The European date format is date month year". I see no discussion of that on the talk pages there and no attempts to edit it since that style page was written in 2008. Perhaps we should simply add the WP:DATERET principle to it. NebY ( talk) 15:52, 11 September 2021 (UTC)
The question and discussion above both seem to ignore a point that needs clarification itself: Why does
MOS:DATETIES refer to English-speaking? What does the language have to do with the date? Shouldn't DATETIES say, Articles on topics with strong ties to a particular English-speaking country should generally use the date format most commonly used in that nation? I'm probably missing something, but we're not going to use septembre instead of September, so the date format, ISTM, is entirely independent of the language. Right? Canada's a bit tricky, but we can decide on a case-by-case basis if there are strong regional ties to, say, Montreal or Quebec (suggesting dmy) or just go with dmy in general for all strong-tied Canadian topics. Why do we need to specify "English"? —
JohnFromPinckney (
talk /
edits)
17:56, 11 September 2021 (UTC)
I doubt such a presumption would work ...They are the existing guidelines. Feel free to establish a new consensus. Incidentally, English being an official language of India, Indian preferences could be applied to related articles.— Bagumba ( talk) 01:29, 19 September 2021 (UTC)
restrain the American format to "American topics may use MDY. Everyone else should use DMY" +- ISO . . .Seems reasonable. Though using the ISO format with English does seems a bit awkward but I don't mind it that much. And since you brought it up, we need to identify when exactly the US military format (DMY) comes into effect and takes precedence over the American MDY format. Does it follow the year of adoption? Is it limited to military vehicles? What about military relations and exercises between the US and other countries? What about the wars that the US has been involved in? These are just some of several such questions that would need to be considered. - Rajan51 ( talk) 20:18, 19 September 2021 (UTC)
Isn't the ISO format YYYY-MM-DD, not DD-MM-YYYY? The former is what I use whenever I remember to give a damn (although I will admit I'm not very diligent about it). Another thing I do sometimes is writr out dates like "2021 Sep 19", so that it is obvious what I mean to hamburger, leaf, and lime alike. jp× g 21:50, 19 September 2021 (UTC)
were documented in MDY, and are described in that format in most published sources. We use our MOS, not anyone else's, to determine whether a date should be a certain format. Izno ( talk) 23:30, 19 September 2021 (UTC)
then they can use DMY, don't you mean MDY??? E Eng 00:11, 20 September 2021 (UTC)
I sure wish we'd never gone down this TIES path at all. Look, let's remember the basic principles of ENGVAR (my paraphrase):
I don't think we ever really needed the special case. It shouldn't be too hard to get consensus to change the spelling of colour in Abraham Lincoln. But the arguments on this exceptional carve-out have grown to dominate the conversation as a whole. Let's not repeat the error with date formats. -- Trovatore ( talk) 17:11, 20 September 2021 (UTC)
that the proposed "guideline for all articles" requires deciding what an "American topic" isThis already happens under the current guideline. Izno ( talk) 20:09, 20 September 2021 (UTC)
. . . That way everyone got something . . .Clearly non-British and non-Americans didn't get anything.
. . . we are not fucking going to make that a debate on every single article all the time -- is John von Neumann a Hungarian article, or American? . . . Under your plan we have to argue about it . . .Nope. He's not strongly and solely tied to
Clearly non-British and non-Americans didn't get anything.– I was hoping you'd say that, and you walked right into it. What I said is
those up in arms could feel they'd both won something ... that way everyone got something. What was needed was to bring peace among the superpowers on an issue that doesn't substantively matter anyway. Creating hundreds of new, additional debates doesn't bring any more peace (in fact the opposite), and since the issue doesn't substantively matter anyway, it doesn't improve anything else either. So not only a net negative, but an absolute negative.
If there are strong ties to two countries, we default to the DMY format. It's that simple.– Uh, no actually, and thus we find that your inexperience, and consequent misunderstanding of the rules, disqualifies your from participating intelligently in this discussion.
the equivalent of causing the destruction of the world– It's not consequence that's equivalent (or analogous, anyway), it's the idiocy (since you force me to come right out and say it).
. . . What was needed was to bring peace among the superpowers on an issue that doesn't substantively matter anyway . . .It matters just as much to anyone else as it does to Britons and Americans. Just because they were the only ones up in arms, does not mean English-speakers from all other countries can be ignored.
. . . Creating hundreds of new, additional debates doesn't bring any more peace . . .The proposed rules only reduces debates. When an article (such as United Kingdom–United States relations or John von Neumann) is strongly tied to more than one country, we revert to the DMY format. There is no need for a debate over which format should be used.
. . . consequent misunderstanding of the rules . . .In case it was not obvious enough, I was talking about the new proposed rules that has been mentioned above, not the currently existing rules. - Rajan51 ( talk) 04:34, 21 September 2021 (UTC)
References
that the variety of English and the date format used in a country are unrelated in most cases", but I think we could reasonably consider the date format to be a part of "the variety of English". WP:ENGVAR says "... date formatting (September 20, 2021 vs. 20 September 2021) is also related to national varieties of English". Mitch Ames ( talk) 23:33, 20 September 2021 (UTC)
. . . I think we could reasonably consider the date format to be a part of "the variety of English" . . .I guess you could in the UK or the US. Most other countries use different hybrids of the two varieties, so a universal direct relationship between the variety of English and the date format used would be hard to make. It would be simpler to just keep the date format an independent issue, which is what MOS:DATETIES does and it states: For any given article, the choice of date format and the choice of national variety of English are independent issues. - Rajan51 ( talk) 07:30, 21 September 2021 (UTC)
DMY for American articles and DMY for the rest proposal will spawn endless debates about whether a tenuous link to America is enough to flip it to MDYAssuming you meant MDY for American articles, the proposed guideline is that an article can use MDY provided it is strongly and solely tied to the US. If an article is strongly tied to the US and at least one other country, we switch to the DMY format. - Rajan51 ( talk) 06:07, 22 September 2021 (UTC)
. . . for using both depending on circumstances . . . not for using the DMY system exclusively as was suggested above.In case you did not read the full discussion, the proposal is to use the DMY format for all pages except when an article is strongly and solely tied to the US, in which case the MDY format will be used for the article. This clearly means we would be using both formats depending on the circumstances of national ties. - Rajan51 ( talk) 17:39, 22 September 2021 (UTC)
Our usual philosophy when we have multiple styles is not to pick winners and losers but rather to allow variation as long as everything is consistent within each article.That does not seem to be the usual philosophy since winners and losers are already being picked, as the existence and implementation of MOS:DATETIES shows. The rationale behind the proposed change is to ensure articles related to countries that are not covered under the current MOS are not left out and to ensure the removal of the existing bias. - Rajan51 ( talk) 18:56, 22 September 2021 (UTC)
"we should be more concerned 'English Wikipedia readers' (our audience), not 'English language speakers'" ... [sez who?]— says WP:PURPOSE, WP:AUDIENCE, WP:RF, WP:READER.
And 40% [does not equal] 0%— 40% (from the US) is less than the 60% who are not from the US. Mitch Ames ( talk) 01:48, 23 September 2021 (UTC)
they have their own wikis, are by definition bi-lingual at least (most English speakers speak only English and can't go to another wiki)– this is a massive oversimplification. It neglects that, other than the major-language Wikis (French/German/Russian/Spanish etc – and often even these), most other-language WPs are orders of magnitude smaller, both by pages and depth of content, than en-wp. Certainly when it comes to topics that are not primarily related to that specific language/country/culture. So it's not remotely uncommon for speakers of English as a second language to use en.wp as their primary WP; for example, I recall reading a social media post by a Lithuanian guy I follow, saying that pretty much the only time he looked at lt.wp was to find information about Lithuania-related topics he couldn't find on en.wp (and then, the topic was typically obscure enough that he often couldn't find it even there). South Asian and African countries are great cases in point – only a tiny minority of Nigerians or Indians speak English as their L1, but a huge proportion of Nigerians and Indians use English extensively, in exactly the sort of use cases that an encyclopedia caters for. Archon 2488 ( talk) 11:43, 23 September 2021 (UTC)
... I'm not seeing that as telling me "Well, for let's say the date of the discovery of a comet, obviously we are going to use DMY". Herostratus ( talk) 13:48, 23 September 2021 (UTC)
Regarding this edit, is there any consensus on hyphenating non-adjectival fractions? The Chicago Manual of Style has "Simple fractions .... are hyphenated in noun, adjective, and adverb forms. ... She has read three-fourths of the book", etc., and WP articles largely seem to follow that format (e.g., "two-thirds of the population," "two-thirds of reported infections," etc.). However, some online style guides recommend no hyphen for noun fractions ("do not hyphenate fractions used as nouns", "when the fraction is serving as a noun, there is no hyphen," etc.)—which could create occasional ambiguities ("The pianist played two thirds", "He drank two fifths", etc.). If there is consensus on hyphenating fractions used as nouns, I'd suggest expanding the example at MOS:FRAC to read "Spelled-out fractions are hyphenated: seven-eighths of a book, a seven-eighths share" or simply changing the text to always hyphenated. (This would also have the advantage of not requiring editors to parse out whether a particular fraction is nominal or adjectival.) Thanks. Doremo ( talk) 13:22, 27 September 2021 (UTC)
{{#invoke:ConvertNumeric|numeral_to_english|37}}
→ thirty-seven{{#invoke:ConvertNumeric|numeral_to_english|12|numerator=2|denominator=3}}
→ twelve and two-thirdstwo fifths of cheap bourbonis an unfortunate example for this discussion because, in that context (involving bourbon of any grade), the two fifths isn't a fraction any more than two quarts is a fraction in
two quarts of milk. E Eng 02:03, 28 September 2021 (UTC)
Anyhow, back to the original question: MOS:FRAC currently seems to indicate that all spelled-out fractions should be hyphenated with no exception mentioned for function (adjectival, nominal, etc.): "Spelled-out fractions are hyphenated: seven-eighths." Should this be made more explicit (e.g., "All spelled-out fractions are hyphenated: seven-eighths." or "Spelled-out fractions are hyphenated regardless of function: seven-eighths." or "Spelled-out fractions are hyphenated: seven-eighths, seven-eighths of a book, a seven-eighths share.") to clarify what seems to be both actual practice and already general WP practice? Or is the current phrasing clear enough? (Or is ambiguity and editorial preference preferred?) Doremo ( talk) 06:52, 28 September 2021 (UTC)
In my opinion, when an article is written in American English, whenever a conversion is given the American measure should be given first, in prose, and the conversion should be given second, in parentheses. Vice versa when written in another English variety. In terms of best practice, I don't remember ever seeing it done differently, until recently. My questions are: what, if anything does the MoS say about this? And: if the MoS were to say something about it, what do others think it should rightly say, if anything? Perhaps it's a matter of style to be left to an editor's discretion, or perhaps there is a best practice that ought to be followed. I am curious to see what others have to say. Thank you.-- John Cline ( talk) 14:03, 9 October 2021 (UTC)
The Arbitration Committee has ruled that editors should not change an article from one guideline-defined style to another– editors would sometimes insist that this means because two styles might both be permissible in the abstract, they were therefore both permissible for any specific article, and thus changing between them (even when one was explicitly favoured by the MOS and the other was proscribed, in the relevant context) was impermissible. I wonder if it might be worthwhile to insert an explicit clarification somewhere in WP:UNITS or MOS:CONVERSIONS that rules such as WP:ENGVAR and WP:RETAIN don't apply here? Archon 2488 ( talk) 17:47, 9 October 2021 (UTC)
every computer program has its regional settings for a user, with date format, measuring units. above @ Sdkb: responded on "format of date tags should be a user property, not a server property" that it is a Wikipedia:Perennial_proposals. would have some links where such a setting in the user preferences was discussed, for both, data format, as well as units of measurment metric vs imperial? -- ThurnerRupert ( talk) 06:08, 25 October 2021 (UTC)
<br>
and 1 July 1999</i>
- ie some trailing HTML tags require a comma and some require no comma.created a phabricator task to provide a test with persons heights as a personal preference: https://phabricator.wikimedia.org/T294707. -- ThurnerRupert ( talk) 17:45, 31 October 2021 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
The premier league states the height of its players in metric, see
this example, but in the english wikipedia this will be switched via flip,
Max Aarons as example again, referring to
MOS:UNIT. Can we please remove or add a couple of workds in
MOS:UNIT to avoid this flipping? --
ThurnerRupert (
talk)
20:39, 15 October 2021 (UTC)
where does this consensus come from @ Archon 2488:? intuitively if i read feet in a piece of text it does not look so strange as an author has his style. but in tables, or in WP infofoxes it looks weird, as you barely see it. -- ThurnerRupert ( talk) 18:32, 16 October 2021 (UTC)
thanks a lot everybody for the excellent insight, which made me smile a lot sometimes, much appreciated!! coming back to the original question, do i interpret the outcome of the discussion correctly: 5 people do not mind make a proposal to ammend MOS:UNIT to allow metric for footballers (@ Archon 2488:, @ NebY:, @ John Maynard Friedman:, @ Dondervogel 2:, ThurnerRupert), and 1 person is not favourable (@ Kahastok:)? if so, how is the process? -- ThurnerRupert ( talk) 20:58, 17 October 2021 (UTC)
@ NebY:, a game? the link you sared is hilarious, "how brits measure" :) :) if you write "don't you see how unrealistic it is even if it would be desireable?": does this mean you desire it or you don't? -- ThurnerRupert ( talk) 16:49, 20 October 2021 (UTC)
as there is no more input, lets close this thread and make a real proposal which allows to vote for, and against. -- ThurnerRupert ( talk) 07:31, 23 October 2021 (UTC)
change the manual of style, dates and numbers, UK related section Wikipedia:Manual_of_Style/Dates_and_numbers#Unit_choice_and_order, in the following way:
the reasoning and arguments are given above, and in the manual of style itself. in scientific contexts as well as statistical contexts, presenations in lists and tables, presentation in the UK follows the UK standard, even for personal heights. in running text both variants, imperial and metric, do exist and are proven over time. the proposal aims to let tables conform to standard, and not touch the proven way to write text in wikipedia. votes can be basted with "support" "oppose". no comment, or other comments are counted as "i do not care". -- ThurnerRupert ( talk) 07:31, 23 October 2021 (UTC)
Would writing the six-digit number "250,000" as "250 thousand" be considered acceptable per MOS:NUMERAL? It does seems to be a "format" used quite a bit project wide, but that doesn't necessarily mean it should be being used. Would "Two hundred fifty thousand" or "Twenty-five hundred thousand" be preferable instead? How should this be treated when dealing with ranges of numbers? Is "250 thousand to 2.5 million" acceptable? Would "250,000 to 2.5 million" or "250,000 to 2,500,000" be better? My question has to do with some wording used in the lead of Eurasian eagle-owl. It was changed from "250 thousand to 2.5 million" to "250,000 to 2.5 million" which seemed odd to me. I reverted the change, but it was contested. I self-reverted since I may have been wrong, but still would like some other opinions on the matter. -- Marchjuly ( talk) 23:11, 24 October 2021 (UTC)
Integers greater than nine expressible in one or two words may be expressed either in numerals or in words). NebY ( talk) 23:53, 24 October 2021 (UTC)
Well, I've had some sleepless nights wondering if I was too quick to add something addressing a problem which might not qualify as a MOS-worthy under the criteria I originated: WP:MOSBLOAT. Here's the new text -- thoughts?
In the specific case of thousands, there are few if any situations in which e.g. 5 thousand or 250 thousand would be preferable to 5000, 5,000, or 250,000. [Link to footnote]
[Footnote:] And positively don't write 5 hundred or 25 hundred thousand.
Again, I'm only belaboring this because I'm usually the MOSBLOAT tsk-tsker and I don't want to seem like a hypocrite. E Eng 23:30, 27 October 2021 (UTC)
In the specific case of thousands, there are few if any situations in which e.g. 5 thousand or 250 thousand would be preferable to 5000, 5,000, or 250,000. And I think I (who added it) am going to remove it, per MOSBLOAT. It's not that I think it's overprescriptive -- if this became a recurring fight among editors, MOS should tell them what to do i.e. don't write 5 thousand -- but I see no evidence of that. There's a very small number (in the scheme of things) uses of such yukky forms project-wide, and adding something to MOS isn't going to fix that, because those editors probably aren't looking at MOS.Also: [28]. E Eng 17:23, 31 October 2021 (UTC)
Right at the top the question is kind of answered: " It does seems to be a 'format' used quite a bit project wide, but that doesn't necessarily mean it should be being used" I mean, yeah it does? Rules codify general behavior, so you can't have a rule prohibiting what editors have 'voted with their feet' for. That's not how it's supposed to work.
As to "I do personally find mixed numerical-verbal number formats as you describe stylistically needlessly clunky". Fine that you do personally not write that way.
Again with "My question though now has to do with all of the cases where '250 thousand' is currently being used in articles. Should these be cleaned up? If 'all the cases' means a lot of cases, then no, you wouldn't be cleaning them up, you'd be imposing by fiat your preferred format on other editors work. ˙ʎʇɹıp ʎllɐnʇɔɐ ǝɹ,ʎǝɥʇ ssǝlu∩ In which case yeah. And if just a few cases, then that too is different. That means that those are outliers and common-accepted-practice is not to do that. In which case, a rule to codify that is OK. If it happens enough to need a rule then I'd have to wonder, though. — Preceding unsigned comment added by Herostratus ( talk • contribs) 23:39, 31 October 2021 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Hi all! I've noticed that many articles for more obscure United States topics lack date tags, which results in them defaulting to the ugly YYYY-MM-DD format (e.g. 2021-10-17).
MOS:DATERET permits changing the format when a topic has strong national ties to the topic
, so I've been running an AWB task recently to add {{
Use mdy dates}} to any article that's in a subcategory of
Category:United States (to 3 levels) and does not already have a date format tag. It seems to be working well, so I'd like to seek consensus from you all to convert it to a task for my bot.
The initial list of articles that will be affected is here. From my checks, almost all of these are U.S.-related. There are a few exceptions from times where the category tree is broken or weird edge cases (e.g. Lake Saint Francis (Canada), a lake in both the U.S. and Canada), but there's no real harm done in those (MDY will be an improvement over YYYY-MM-DD and anyone who wants to switch to DMY can easily do so). Overall, I think this task will improve lots of U.S.-related articles by converting them to the date format American readers generally expect. Thoughts? {{u| Sdkb}} talk 23:32, 17 October 2021 (UTC)
the ambiguous abomination that is the stylistic atrocity of "5/12/19" should be utterly forbidden.— It is, by MOS:BADDATE. Mitch Ames ( talk) 12:18, 18 October 2021 (UTC)
I've been running an AWB task recently to add {{ Use mdy dates}} to any article that's in a subcategory of Category:United States": DO NOT DO THIS. Some of us use and prefer variant styles that are nevertheless consistent with both the MOS and US date conventions (such as the style discussed in the link given above by EEng) and take drive-by efforts to change date formats from our preferences to something else with great hostility. The MOS says not to change consistent date formats without consensus. Adding {{ Use mdy dates}}, even to an article on a US topic in which some of the dates are formatted as mdy, can be a change of a consistent date format. Unless your AWB script is smart enough to recognize and correctly tag these variations (and I'm betting it isn't) you should not be using AWB to do this. If you are editing by hand and are capable of distinguishing consistent formatting that mixes mdy/ymd (yes, that is a thing) from inconsistent formatting, and only want to tag the inconsistent ones, then that's less problematic, but I don't think that AWB and the level of care needed for this tend to go together. — David Eppstein ( talk) 08:20, 20 October 2021 (UTC)
I was reading an article where a fraction was rendered as three separate characters for something as simple as 1/2 and 1/4. This does not seem right to me and frankly looks absolutely hideous. From an accessibility perspective, I suspect that screen readers will also be able to do a much better job of reading ¼ vs. 1⁄4.
This policy seems to be around a decade old at this point and web browser (and other client) support for the full Unicode set has dramatically improved since it was written. Is it time to revisit it? — lensovet– talk – 22:11, 4 November 2021 (UTC)
The note currently reads:
t or troy must be specified where applicable. Use oz avdp or lb avdp only where there is risk of confusion with troy ounce, imperial fluid ounce, US fluid ounce, or troy pound; but articles about precious metals, black powder, and gemstones should always specify avoirdupois or troy.
Does any object my revising this to read
the qualifier t or troy must be specified where applicable. Use oz avdp or lb avdp only where there is risk of confusion with troy ounce, imperial fluid ounce, US fluid ounce, or troy pound. Articles about precious metals,
coins,black powder, and gemstones should always specify which type of ounce (avoirdupois or troy) is being used, noting that these materials are normally measured in troy ounces and grams.
(bold just to highlight proposed changes). -- John Maynard Friedman ( talk) 20:23, 6 November 2021 (UTC)
I would repeat my personal view that when such confusing and ambiguous units as "ounces" are used, disambiguation should always be a priority, and a correct conversion into real units should always be provided. There have been about as many different kinds of ounces (tower measure, anyone?) as there have been coins. Archon 2488 ( talk) 23:37, 6 November 2021 (UTC)
Generally, conversions to and from metric units and US or imperial units should be providedand I don't think anyone has argued that this should not apply in this case. If there's anything that needs adding to this, it is to point out that the most "real" unit for precious metals is the unit used by the international markets and in most physical sales, i.e. the troy ounce. I would certainly agree that any weight measurement for precious metals needs to include a conversion into troy ounces. Kahastok talk 15:20, 7 November 2021 (UTC)
Use oz avdp or lb avdp only where there is risk of confusion with troy ounce, imperial fluid ounce, US fluid ounce, or troy pound, so may I request that we go no further up this blind alley? Or does it need to say
Use the qualifier avdp only where there is risk of confusion with troy ounce, imperial fluid ounce, US fluid ounce, or troy pound? [comments please].
noting that these materials are normally measured in troy ounces and grams. -- John Maynard Friedman ( talk) 15:40, 7 November 2021 (UTC)
Assuming that silence signifies assent, I have made this change (with this diff). -- John Maynard Friedman ( talk) 14:11, 10 November 2021 (UTC)
Question raised by User:Melbguy05 User:I dream of horses So we had a discussion also involving other editors about an article Mr Cruel /info/en/?search=Talk:Mr_Cruel#U.S._dollars_or_Australian_dollars about events wholly in Australia. Australia, like the U.S., uses a currency they call the "dollar." The question was whether the article should mention that reward amounts are in Australian dollars. The consensus seems to have been that it should. However, Manual of Style mentions that, "In articles entirely on EU-, UK- and/or US-related topics, all occurrences may be shortened (€26, £22 or $34), unless this would be unclear." So the question is why should an article about events wholly in Australia mention that dollar amounts are in Australian money, but an article about events wholly in America doesn't have to mention that dollar amounts are in American dollars? Greg Dahlen ( talk) 12:10, 7 October 2021 (UTC)
nobody is going to think, in a purely Australian context, that an arbitrary amount quoted in "dollars" (or "$") with no clarification refers to USD rather than AUD– That's if they're aware that Australia even uses dollars. E Eng 18:56, 9 October 2021 (UTC)
Australia and NZ renamed their respective currencies from "pound" to "dollar"— Australia did not rename the currency, we changed it. The dollar as a different currency with a different value. Mitch Ames ( talk) 23:31, 10 October 2021 (UTC)
unless context indicates otherwise– here we are explicitly discussing an Australian context, in which I would default to presuming (per the practice of relevant reliable sources, like any Australian publication) that a "dollar" is an Australian dollar, not an American one. Or do you think that the Sydney Morning Herald feels the need to reassure its readers that the prices it quotes are not in US dollars? I would tend to lean towards using ISO currency codes or some other form of unambiguous notation, regardless. It is clear from this discussion alone that different people have very divergent perceptions of what our readers will presume is meant in a given context. And across the board, I am strongly opposed to context-specific disambiguation – i.e. an editor taking it for granted that a reader will make the same assumptions about what, say, a "dollar" is that they do, then finding out in short order that that is not the case, because different people focus on different information in constructing their picture of what the context is. Archon 2488 ( talk) 17:51, 10 October 2021 (UTC)
If there is no common English abbreviation or symbol, follow the ISO 4217 standard.(emphasis added). E Eng 20:34, 10 October 2021 (UTC)
Why doesn't first mention of U.S. money have to have "US" put in front of it?(and the inline text in the original inquiry:
...but an article about events wholly in America doesn't have to mention that dollar amounts are in American dollars?) I mentioned the Apple source in passing as it appears to support the idea that businesses even within Australia disambiguate the AUD from USD. — Locke Cole • t • c 21:35, 10 October 2021 (UTC)
References
Currently, the #Specific units table reads, in part:
Group
|
Name | Symbol | Comment |
---|---|---|---|
Volume, flow
|
|
|
US or imperial (or imp) must be specified; fluid or fl must be specified for fluid ounces and US units, except with gallon. (Without fluid, ounce is ambiguous – versus avoirdupois ounce or troy ounce – and US pint or US quart are ambiguous – versus US dry pint or US dry quart.) |
I would argue that the requirement to specify fluid for U.S. pints and quarts is unnecessary, given that everyday usage of dry pints and quarts - even in the United States, where I live - is essentially nonexistent (as a matter of fact, I didn't even know that dry pints and quarts existed before reading this table, and have literally never used them). Any American seeing US pt or US qt will immediately think of the liquid measure, and, in the rare cases when we do need to refer to dry pints or quarts, they can be explicitly specified as such (much like how, for U.S. measures of weight, we use generic pounds vs. troy pounds, rather than avoirdupois pounds vs. troy pounds). As such, I propose the following modification to the row of the table dealing with U.S. and imperial fluid measures:
Group
|
Name | Symbol | Comment |
---|---|---|---|
Volume, flow
|
|
|
US or imperial (or imp) must be specified; fluid or fl must be specified for fluid ounces. (Without fluid,
ounce is ambiguous versus avoirdupois ounce or troy ounce.)
In the rare case that one needs to refer to the U.S. dry pint or quart, dry must be specified, and the difference between the dry pint and quart and the fluid measures of the same names should be explained in a footnote upon first use (as even U.S. readers are highly unlikely to be familiar with the dry units). |
Thoughts? Whoop whoop pull up Bitching Betty ⚧ Averted crashes 05:42, 28 October 2021 (UTC)
different reference temperatures for volumes of gasoline– I can hardly believe that. E Eng 14:55, 28 October 2021 (UTC)
Group
|
Name | Symbol | Comment |
---|---|---|---|
Volume, flow
|
|
|
US or imperial (or imp) must be specified; fluid or fl must be specified for fluid ounces. (Without fluid,
ounce is ambiguous versus avoirdupois ounce or troy ounce.)
Unless otherwise specified, US pt and US qt refer to the liquid measures of those names. In the rare case that one needs to refer to the U.S. dry pint or quart, dry must be specified. Link to Pint#US dry pint or Quart#US dry quart (depending on which is being referenced) on first use. |
Whoop whoop pull up Bitching Betty ⚧ Averted crashes 21:39, 28 October 2021 (UTC)
We still have 'US fl pt' recommended for the liquid pint. Shouldn't that be changed to 'US liq pt'? Dondervogel 2 ( talk) 10:50, 6 November 2021 (UTC)
Based on the above, I've made the following edit: [30].
Gills, minims, scruples, bushels, drams / drachms and the rest of the zoo have similar issues (e.g. When necessary to distinguish the avoirdupois dram from the apothecaries dram, or to distinguish the avoirdupois dram or ounce from the fluid dram or ounce, or to distinguish the avoirdupois ounce or pound from the troy or apothecaries ounce or pound, the word “avoirdupois” or the abbreviation “avdp” should be used in combination with the name or abbreviation of the avoirdupois unit.
) But please let's not tackle those now.
I invite one and all to carefully check what I say above, and my edit. E Eng 17:52, 6 November 2021 (UTC)
This is bizarre!
So which is correct? -- Shmuel (Seymour J.) Metz Username:Chatul ( talk) 13:29, 7 November 2021 (UTC)
Do we have any evidence that either "liquid pint" or "fluid pint" are commonly used in the US? We seem to have various British editors here assuming that Americans must need clarification, which may underestimate the intelligence of Americans and the power of US English norms.
Indeed, do we even have any evidence that when fruit, for example, is sold by the pint it usually or even commonly has to be stated as a dry pint? I have tried a Google ngram for "a dry pint of strawberries" and "a pint of strawberries", and also for blueberries, but received no results for the dry phrasing. [31] Then I reduced it to simply comparing "a dry pint" - of anything, I don't care - with "a pint of strawberries" and "a pint of blueberries", and found any use at all of "a dry pint" is now vastly rarer than either of those. [32] NebY ( talk) 17:27, 10 November 2021 (UTC)
While this article has guidance to not spell out numbers in sports scores and vote tallies (in the “Notes and exceptions” list under “Numbers as figures or words”), it does not have any guidance to use en dashes with them. However, it seems to be a well established convention to use en dashes with them, and the sample sports score in the above referenced text uses an en dash, too, albeit without explicitly calling out that fact.
I’d therefore like to either add a “Sports scores and vote tallies” section following “Number ranges”, or append guidance to “Number ranges” and change its title to “Number ranges, sports scores, and vote tallies”. The guidance could be simply something along the lines of the following:
Separate sports scores and vote tallies with an en dash:
Using single-digit scores and tallies in the above examples would also implicitly reinforce the guidance from the other section to always use digits and not spell out single-digits in these contexts.
SixSix ( talk) 19:54, 18 November 2021 (UTC)
While looking for guidance for how to format a non-base 10 number the other day, I ran across the guidance here. I found it to be unwieldy and made some copy edits for brevity and clarity. I thought my edits were non-substantive but my edit was reverted with the suggestion that I discuss it here first.
Here were my beefs:
Let me know what you think, thanks
SixSix ( talk) 20:10, 18 November 2021 (UTC)
{{
base}}
(eg 2008), which seemed to be warmly received and it was actually mentioned directly in the MOS. Then it was removed from MOS and now nobody knows of it. :(Example: 15.38 km instead of 15.382 km
For one thing, with metric units you might as well replace it with "15,382 m" since its giving the exact same amount of detail.
More importantly, plenty of countries use , and . the other way around (, for decimal places and . as a separator for thousandths), and with three digit precision there is a potential for easy misunderstand when one isnt careful.
When a number is large enough that it is given in Kilometers there rarely is a point in stating its length exact to the meter, or a number in tons to the exact Kilo and so on. Most of the time rounding to the next integer or just having one decimal place is probably sufficient anyway, so I can't think of a case were having two instead of three decimal places would cause significant problems. I wont go so far as to propose using a bot to truncate every number in every article, but adding it as a preferred style to the manual wouldn't hurt. For context: Decimal_separator#Examples_of_use jonas ( talk) 01:13, 17 November 2021 (UTC)
round to an appropriate number of significant digits; the precision presented should usually be conservative. Precise values ... should be used only where ...appropriate to the context. Mitch Ames ( talk) 02:31, 17 November 2021 (UTC)
is there a reason why the example used to illustrate the usage of floruit (fl.) does not have a spaced en dash?
the last point in the mos:approxdate section notes that spaced en dashes should be used when "fl." appears in a range, "whether on one or both sides", and i can't seem to find an applicable exception for this example. had the point explicitly stated "whether on the right or both sides", i would have understood the lack of a spaced dash, but that is currently not the case. dying ( talk) 06:53, 16 April 2021 (UTC)
1571–1588
bind to each other first, and the fl.
applies to them as a unit: fl. 1571–1588.In contrast, in c. 1588 – 1622, the c.
applies (presumably) only to the 1588
, so we move the latter a bit away from the 1622
so as to put it in closer visual association with the c.
.
E
Eng
08:00, 17 April 2021 (UTC)
r. c. 1353–1336 BC | or | r. c. 1353 – 1336 BC |
fl. 12 BH–AH 10 | or | fl. 12 BH – AH 10 |
traditionally 1585– c. 1590 | or | traditionally 1585 – c. 1590 |
Ravenpuff, i agree that the recent changes are reasonable, but i don't think they are consistent with the previous guidelines. i am not sure if this is the case, but i think we are currently disagreeing on whether the previous guidelines would have called for a spaced en dash in the original floruit example. i believe the previous guidelines would have called for a spaced en dash, while your comment has led me to believe that you believe the previous guidelines would have called for an unspaced en dash. if so, i would like to understand why we disagree, but i wanted to determine if that was actually the case.
by the way, i also share your confusion over the behaviour of the floruit template when two arguments are provided, as i mentioned in footnote [f]. the behaviour appears to have been introduced when code was copied from the circa template at the time, [i] as mentioned in the edit summary of the floruit template edit, and i don't know if retaining that behaviour was intentional. [j] however, i agree that it's consistent with both the previous and current guidelines.
in any case, whether the current guidelines are consistent with the previous guidelines was not why i had proposed two solutions to what i believe is an ambiguity problem. do you agree that the guidelines, as they currently stand, are ambiguous? if so, do you have any suggestions regarding how to resolve the ambiguity? if not, then could you explain how the en dashes in the three examples above are spaced (or not spaced) according to the current guidelines, and why? dying ( talk) 23:00, 18 June 2021 (UTC)
x. | x. 1571 | x. 1571–1588 | x. 1571 – 1588 | 1571 – x. 1588 | x. 1571 – x. 1588 | |
---|---|---|---|---|---|---|
1. | c., after | ![]() |
![]() |
![]() |
![]() |
![]() |
2. | fl., r. | ![]() |
![]() |
![]() |
![]() |
![]() |
3. | trad. | ![]() |
![]() |
![]() |
![]() |
![]() |
Ravenpuff, it recently occurred to me that it might be simpler to draft the proposal first, and then edit it together if there are any disagreements, as with blurbs on tfar. i have reproduced below what i believe are the relevant bullet points of the guideline, with the original text first and my proposed text following. note that this reply consists of two edits, so that (hopefully) a diff will be able to show what the proposed changes are. some of the comments in the code have also been modified, so looking at the diff may provide more information than simply comparing the visible text below.
of course, for this to work properly, i'm obviously giving permission to edit the proposed text below, waiving any tpo concerns. also, if you feel that any additional bullet points should be addressed, feel free to add them as well. dying ( talk) 17:59, 5 October 2021 (UTC)
original text:
{{
snd}}
) is used. For example:
[[Floruit|fl.]]
, or {{
fl.}}
may be used:
{{snd}}
) and ideally a non-breaking space should follow very short modifiers such as c.. Examples: 1896 – after 1954,
c. 470 – c. 540. Markup: 1896{{snd}}after 1954
, {{c.|470|540}}
.
proposed text:
{{
snd}}
) is used. For example:
[[Floruit|fl.]]
, or {{
fl.}}
may be used:
{{snd}}
).
1896{{snd}}after 1954
, 470{{snd}}{{c.|540}}
, {{c.|470}}{{snd}}540
, {{c.|470|540}}
.here is a link to the initial revision. there is a lot of formatting that could probably be improved, but i tried to emulate what was already present so that we could focus on the content differences first. i don't have any significant preferences regarding the formatting, so i will probably be happy with whatever you choose if you decide to change any of it.
i ended up removing "after" from the introductory sentence of one of the bullet points because i felt that it was possible to use "after" to apply to a range as a whole, such as in "the minister held the office during the 2025–2030 term, so could not hold it again until after 2030–2035 due to term limits". (that bullet point's "after" example still applies, though, so i left it there.) feel free to restore "after" to the introductory sentence if you feel otherwise.
by the way, if one does not treat the '−' (the minus sign, not a dash or hyphen-minus) used in astronomical year numbering as a modifier, then the range "−10–10" appears to be appropriately formatted. this is not ambiguous, but is this desirable? we could consider "−" to be a modifier of the first category, but i hesitate to do this because the '−' seems, at least to me, to be an integral part of the number "−10" rather than a modifier, much like the '0' is. i also do not think it would be appropriate to have a non-breaking space follow the '−', like one generally does with very short modifiers. dying ( talk) 18:04, 5 October 2021 (UTC)
Notes
Hey everyone. So a big big big debate issue that has been going on for over 2 years is whether 2021–present can be used (in 2019 it was 2019–present, in 2020 it was 2020–present, and if this continues next year, it will be 2022–present etc.). Soap operas used to use just a dash e.g. (2009– = since 2009), but over the past 2 years this was changed to –present. Several editors have said that 2021–present is wrong as 2021 is the present. However, myself and several other editors really do not agree with putting just "2021" as it looks like that event/character/appearance etc took place only in 2021 and has finished/is expected to finish in 2021, and also because sometimes pages are not updated at the end of the year and so it looks like it is giving wrong information. This also goes against other pages that are not soap opera related (for example, at the Duke of Edinburgh page, in the Third Creation area, it says that Prince Charles has been Duke of Edinburgh "2021–present"). In some soap opera articles, I changed "2021" to "Since 2021" to clarify that the characters have been appearing since 2021, rather than just appearing in 2021, but some are also against this. I think 2021–present is very acceptable as yes, 2021 is the present, but February 2021 is not the present etc, and even the beginning of December 1st is not the present either. Although in an ideal world, I would much rather prefer just "2021–" as it was much more simple and created less clutter (also going through the Wikipedia discussions from years ago on this page it seems that many editors disagreed with it in general).
Sorry for the long message, but in a nutshell, we need to decide whether 2021–present is okay to be used and, if not, what alternative we can use (e.g. "Since 2021").
I vote in favour for using "2021–present" or preferably allowing editors to use simply "2021–" DaniloDaysOfOurLives ( talk) 19:13, 1 December 2021 (UTC)
{{
Infobox_automobile}}
, which states "If production started in any year prior to the current year and is still ongoing, 2008–present
, et cetera, is the preferred style. However, 2021–
is preferable to 2021–present
while we are still in 2021." So both forms are allowed but the shorter form is preferred.
Stepho
talk
10:57, 2 December 2021 (UTC)The article cites as a good example: "Typically, 1-naphthylamine is synthesized via the Feldenshlager–Glockenspiel process. Or: Feldenshlager–Glockenspiel is the process typically used in the synthesis of 1-naphthylamine."
The first one is OK, but the second one is ungrammatical. It should be written as "The Feldenshlager-Glockenspiel process is the one . . ." As a rule, scientific texts don't refer to processes, reactions, etc., that way; eponyms are used as adjectives ("Diels-Alder adducts are"), but not as stand-alone nouns ("Diels-Alder is the best way . . ."). Samer ( talk) 18:05, 16 December 2021 (UTC)
3SAT is a variant of SATis just too common nowadays, and widely accepted. And such forms are quite different from
50 soldiers were killed.E Eng 16:45, 18 December 2021 (UTC)
It would be useful if the comment column of #2.2.1 Formats included a comment and example following "2 September 2001" to the effect that in British English (used in the UK, Australia and elsewhere) commas aren't used unless required by the sentence's grammar and an example such as "On 13 May 2007 Daniel was born." https://www.grammarly.com/blog/how-to-write-dates/. There are many articles with dates in British English style but with unnecessary commas. — Preceding unsigned comment added by Mcljlm ( talk • contribs) 08:14, 18 December 2021 (UTC)
I've looked through the whole MoS for Wikipedia, and I haven't found a specific section or article explaining how to format time. Does Wikipedia have set rules for this? For example, if I want to say that a song lasted 3 minutes and 48 seconds, would I format the duration as "3:48" or "3m 48s"?
User:Jale1162 ( talk) 21:06, 21 December 2021 (UTC)
I'm thinking that "1400s" is better than "15th century" in text.
I was a grown man before I was I was facile with the notion that 18th century referred to the 1700s. To this day I usually do a little mental stutter-step to translate "8th century" to the 700s and so on. And I went to college (well, for a bit). Maybe you don't, Dear Reader, but there's a whole lot of people who aren't as smart and literate as you.
We do not have a rule about this that I can find here. But all the examples use "XXth century", except for one which says "When using forms such as the 1900s...". And I think "XXth century" is much more common in text. I don't want a rule, and I don't think every discussion here has to be about making another rule. I'm just thinking that writing "1500s" instead of "16th century" is more clear to more people (in contexts where "1500s" is clearly not meaning 1500-1509), and editors might want to consider this. Herostratus ( talk) 20:53, 18 December 2021 (UTC)
"1500s" means 1500–1509, which quite surprises me. I would never come to that conclusion as a first assumption (although I can see it, the same way I can decide to translate left-handed pipe wrench as a wrench for left-handed pipes). I suppose if I read that somebody or something flourished in the early 1700s, I should interpret that to mean from 1700 to 1703 or so? That's not the way I'm used to thinking about this form. — JohnFromPinckney ( talk / edits) 01:36, 19 December 2021 (UTC)
"1400s" is better than "15th century" in text. ... To this day I usually do a little mental stutter-step to translate "8th century" to the 700s and so on.Stepho responded
I would recommend avoiding that usage, which I was trying to support by demonstrating that (for example) "1800s" and "1900s" would not clearly mean entire centuries and would also demand effort from the reader. Indeed it seems you would not take them to mean entire centuries either. NebY ( talk) 23:44, 19 December 2021 (UTC)
This form of art movement started in the 19th century. DaniloDaysOfOurLives ( talk) 06:05, 19 December 2021 (UTC)
Herostratus has become an eponym for someone who commits a criminal act in order to become famousor more recently, someone who starts a new section at WT:MOSNUM to watch it burn. NebY ( talk) 01:20, 21 December 2021 (UTC)
two connected events that occur in the wee hours of the day that daylight saving time ends... We need a rule for this— Actually, we have one: MOS:TIMEZONE - "... the time zone in which an event took place has since changed ... show the UTC or offset appropriate to the clock time in use at the time of the event". Mitch Ames ( talk) 01:46, 21 December 2021 (UTC)
Really either is non-excellent. "XXth century" is difficult, "XX00s" potentially confusing. I do think that "the latter half of the 1400s" can be quite clear in context, eg "The first edition was printed in 1423, the second in 1437, and several in the last half of the 1400s", for instance. But yes, there can't be a hard and fast rule. Herostratus ( talk) 01:19, 21 December 2021 (UTC)
@
EEng: To answer the question you asked in the edit summary of
this revert ("is there any evidence that our elite cadre of abstract algebra editors need this guidance?"): The question presupposes that only editors who are familiar with abstract algebra are affected. I was actually cleaning up math notation project-wide for compliance with
MOS:BBB and happened to convert some fraction slashes to horizontal fraction bars because that appeared to be the only notation permitted by
MOS:FRAC inside <math>...</math>
. Another editor pointed out the convention in this subfield was fraction slash only. I thought it would be helpful to note this exception so that in the future editors making articles compliant with MOS:FRAC know enough to check if the topic is related to
quotient objects. Otherwise we'd be relying on watchlist editors carefully reading diffs with messy math markup to catch the sort of mistake that I made. --
Beland (
talk)
00:25, 28 December 2021 (UTC)
When updating isotopes of element pages, in this case isotopes of hydrogen (though this question applies to any and all of them), I'm having difficulties determining how many significant figures to represent in the data tables. I had a short discussion with User:MeasureWell regarding this issue, and we decided to ask for second opinions here because there isn't a clear guideline in the MOS for this.
The lists of isotopes are sourced to {{ NUBASE2020}} and {{ AME2020 II}} (or earlier versions, such as 2003 or 2016), though apparently the sources themselves are not internally consistent. The PDF for AME2020 II gives most values with 6-7 significant figures (bar exceptions that are known to such high precision) and 1-2 (occasionally 3) digits of uncertainty, which have been in widespread use on WP. However, I was directed to a web/txt version of NUBASE, where there is one file congruent to the PDF giving "rounded" values ( [36]) and another giving about 3 more digits in "exact" values ( [37])
The problem is that both are supposed to be the same source, yet the "exact" values sometimes have at least 4 digits of uncertainty, which is bad practice in data analysis and renders the extra precision nearly useless. Furthermore, the same file gives mass excess values in energy units to about the same number of significant figures as the "rounded" masses, so I'd also think that a straight unit conversion (E=mc2, adjusted for units) should not introduce additional precision. Keeping smaller relative uncertainties also allows a much more concise and meaningful representation of the data. Taking hydrogen-4 as an example, we have 4.026431867(107354) u "exact" vs. 4.02643(11) u "rounded".
I'm inclined to stick to the latter "rounded" values for these reasons, as it seems to better follow general practice and not clutter data tables with meaningless digits, though I'm unsure if a case can be made for a possible loss of precision (less sure because of the large relative uncertainty) Whatever the general preferred practice is, could it be codified in MOS to encourage more consistent and meaningful data representation and resolve such discrepancies? ComplexRational ( talk) 01:48, 30 December 2021 (UTC)
You are invited to join the discussion at
Talk:Keiji Nishikawa § Date format. --
Marchjuly (
talk)
12:45, 22 January 2022 (UTC)
Hello.
This is exactly as weird as it sounds. After reverting three (different) edits by me, a user claims that I have to seek consensus for edits intended to make the article adhere to MOS.
It would be detrimental to the project if editors had to seek consensus to edits intended to implement MOS on every single article.
Please add your two cents here: Talk:List of Girl Meets World episodes#Proposal to adhere to the Manual of Style in the article.
Thank you.
HandsomeFella ( talk) 20:21, 17 January 2022 (UTC)
My apologies in advance for bringing drama to this otherwise drama-free zone. I am looking primarily for a link to a previous discussion, but I have been unable to conjure the right search terms for use in the archives of this page.
Srich32977 has been asked many times on their User talk page to stop replacing page ranges like "807–813" with "807–13", and they have consistently responded that MOS:NUMRANGE does not apply to the text that they are changing. The text of that MOS section looks clear to me, but I will defer to the guidance of the more experienced MOS-heads among you. A link to a detailed previous discussion or RFC on the issue would be helpful. Thanks in advance. – Jonesey95 ( talk) 22:29, 13 January 2022 (UTC)
There is much discussion throughout Wikipedia on the use of IEC prefixes. I didn't know until today about the difference between k and K. (Traditionally K was sometimes used when only upper case was available. I believe K is often used for resistors.) Often in articles, numbers are written with excessive Sigfigs, and I suspect including for computers. kiB/kB is only 2%, and by GiB/GB is 7%, but often enough that is still more precision than is needed. Also, I believe we are allowed to give less precision than the WP:RS when precision isn't needed for the article. I think that means that I agree with the suggestion not to use IEC prefixes most of the time. Gah4 ( talk) 23:29, 4 February 2022 (UTC)
A few minutes ago, I made this edit to the unit-specific guidance for knots, with the intent of reducing the potential for ambiguity in instances where more than one type of airspeed is referred to in a single section. Dondervogel 2 reverted, requesting that I open a discussion in talk regarding the proposed changes. Hence the following, with no ill will intended against Dv2:
Group
|
Name | Symbol | Comment |
---|---|---|---|
Length, speed
|
|
Used in aviation contexts for aircraft and wind speeds, and also used in some nautical and general meteorological contexts. When applied to aircraft speeds, kn means KIAS unless stated otherwise; if kn is used for calibrated airspeed, equivalent airspeed, true airspeed, or groundspeed, explicitly state and link to, upon first use, the type of speed being referred to (for instance, kn equivalent airspeed, or, if severely short of space, kn EAS); for airspeeds other than indicated airspeed, the use of the specific abbreviation for the type of airspeed being referred to (such as KEAS) is preferred. When referring to indicated airspeed, either kn or KIAS is permissible. Groundspeeds and wind speeds must use the abbreviation kn only. |
Group
|
Name | Symbol | Comment |
---|---|---|---|
Length, speed
|
|
Used in aviation contexts for aircraft and wind speeds, and also used in some nautical and general meteorological contexts. When applied to aircraft speeds, kn means KIAS unless stated otherwise; if kn is used for calibrated airspeed, equivalent airspeed, true airspeed, or groundspeed, explicitly state and link to, upon first use, the type of speed being referred to (for instance, kn equivalent airspeed, or, if severely short of space, kn EAS); for airspeeds other than indicated airspeed, the use of the specific abbreviation for the type of airspeed being referred to (such as KEAS) is preferred. When referring to indicated airspeed, either kn or KIAS is permissible. If knots are used to describe multiple different types of airspeed in a single section, the type of airspeed being referred to in each particular case must be specified (either by using the specific abbreviations for each type of airspeed or by spelling out the full long form of the type of airspeed in question) unless the context makes absolutely clear, in every instance, what type of airspeed is being referred to; even then, it is strongly encouraged to explicitly state the type of airspeed being given (this is also strongly encouraged, although not absolutely required, if different types of airspeed are mixed within an article but not within any specific section). Groundspeeds and wind speeds must use the abbreviation kn only. |
Thoughts? Whoop whoop pull up Bitching Betty ⚧️ Averted crashes 22:59, 30 January 2022 (UTC)
I'm seeing this arcane unit of measurement pop up, for instance with Underground line articles. Chains, not miles, that is. What gives? Why is Wikipedia retrograde here? The conversion template even admits chains is not commonplace or familiar to the readership? Let us not be cute, let us stop this movement to use chains immediately. CapnZapp ( talk) 20:52, 28 January 2022 (UTC)
I too could not find any conclusion. Perhaps the proponents of this obscure units just kept talking until everybody else tired of opposing. (See Sealioning). How about a much simpler proposal?
Cheers CapnZapp ( talk) 12:27, 31 January 2022 (UTC)
According to
Metrication in the United Kingdom#Road and rail transport, Standards relating to the design and building of new road and rail vehicles have been metric since the engineering changeover in the 1970s.
[1]
and specifically London Underground has converted to using metric units for distances but not for speeds.
[2]
HOWEVER chains were used when all but the most recent lines were built so translation continues to be needed: whether the original measure should be displayed is a different debate. There is only becomes a problem when
metric martyrs want to 'translate' modern engineering specifications back to these obsolete measures. --
John Maynard Friedman (
talk)
00:17, 1 February 2022 (UTC)
I'm going to list a few things that I consider self-evident.
{{
convert}}
a lot more than I trust most editor's arithmetic.Points that are up for discussion:
Comments? Stepho talk 11:45, 1 February 2022 (UTC)
According to Metrication in the United Kingdom#Road and rail transport,-- John Maynard Friedman ( talk) 18:03, 4 February 2022 (UTC)
Imperial units have been retained for both road and railway signage except on new railways. What else do you want? The difference between "measured in metres and converted to miles and chains and displayed as such" and "measured in miles and chains" is entirely academic and of no practical relevance. As far as we know, the distances are given in miles and chains, and that's the unit which the railway does use (plus, speeds limits on British railways [and roads] are also in MPH, so that makes total sense). RandomCanadian ( talk / contribs) 18:43, 4 February 2022 (UTC)
I suggest that this discussion be closed as there is not the slightest possibility of a consensus for change. No doubt The Colonel could put it more succinctly. -- John Maynard Friedman ( talk) 20:47, 4 February 2022 (UTC)
This appears to be a classic case where our decision process breaks down when a topic is discussed mostly by the people most interested in said topic. That is, people that does not necessarily realize that what is best for the technical experts might not be for the general public. It is obvious to me the value of Wikipedia is lessened by having rail station articles include archaic and obsolete units of measurements as if that was a reasonable thing to do. It is actively user hostile (compare the kibi disaster that thankfully was averted in the end). That a unit of measurement is used by specialists in the field should be entirely irrelevant for a project like Wikipedia, and had this topic been visited by a representative selection of editors, I am sure the voices in support for presenting this unit to an unsuspecting public would have been drowned out entirely. My conclusion is that the only path forward is to devote enough time soliciting comments from elsewhere, and I'm sorry - I don't feel like it. Instead this will be a case of "you deserve each other". Thanks to those seeing that "the UK rail industry uses this" and "for historic reasons" are really really bad reasons when we're discussing non-technical articles of general interest such as rail station articles. CapnZapp ( talk) 07:48, 14 February 2022 (UTC)
I don't agree that we need to state chains in the articleJust as a heads-up: I am going to assume you meant to say "I do agree with you CapnZapp we don't need to state chains in the article". Just clarifying since I am arguing the exact opposite of what you appeared to ascribe to me. Cheers CapnZapp ( talk) 08:52, 14 February 2022 (UTC)
It is obvious to me the value of Wikipedia is lessened by having rail station articles include archaic and obsolete units of measurements as if that was a reasonable thing to doWhy? Even if it were true that chains are "archaic" and "obsolete" (they are neither, being in active, every day use) it is not at all obvious why including them in a Wikipedia article would "lessen the value" of that article. When a subject uses was built to units that, unlike chains, are no longer in every day use we still include them where it is relevant. Is the Great Pyramid of Giza article's value lessened by it giving the dimensions in royal cubits? Is the Bromsgrove article lesser for noting "The town appears to have been founded as a series of plots of sizes between two and four rods (10 and 20 m), marked out along the current High Street."? Thryduulf ( talk) 10:22, 14 February 2022 (UTC)
the authorities use chains?); the following is the London North Western route specification from Network Rail which states on page 8:
“ | This secondary urban route leads in an easterly direction from Manchester to Mirfield via Rochdale, with another route diverging to Stalybridge, via Ashton-under-Lyne. The former crosses the London North Western/London North Eastern boundary at 22 miles 62 chains on MVN2 just west of Hebden Bridge. [5] | ” |
But I would consider this a primary source, however, Network Rail use miles and chains in all their documentation. Publications such as Rail Magazine, Trackmaps etc, ie secondary sources, also all use chains where necessary, and in Trackmaps, every station is listed from a fixed zero point in miles and chains (see images here). The chainage is particularly relevant in crash/accident articles, when the RAIB issue their reports. They do so in miles and chains when necessary, because that is how the distances on UK railways (apart from HS1 and HS2) are measured. The example given here is due to the check rail having a curve radius of "10 chains or less". [6] However, not all RAIB accident reports use chains, they do so when required, which is why I do not advocate deprecating the chains and getting rid of them completely. Chains are also used as a measure of wildfires in the USA! Strange, but that's how they do it. The problem here is in the rounding, which can be quite inaccurate. Regards. The joy of all things ( talk) 10:05, 14 February 2022 (UTC)
Swindon railway station is on the Great Western Main Line in South West England, serving the town of Swindon, Wiltshire. It is 77 miles 23 chains (77.29 mi; 124.4 km) down the line from the zero point at London Paddington.
Swindon railway station is on the Great Western Main Line in South West England, serving the town of Swindon, Wiltshire. It is a little less than 80 miles (125 km) west of London Paddington.
"In the chainage notation traditionally used on British railways, it is 77 miles 23 chains (77.29 mi; 124.4 km) down the line from the zero point at London Paddington".
"In the chainage notation traditionally used on British railways, it is 77 miles 23 chains (77.29 mi; 124.4 km) down the line from the zero point ...This is just a rod (or four) for our own back. Cinderella157 ( talk) 12:48, 18 February 2022 (UTC)
References
"an up-to-date metric guide" (para 1.2)
I'm monitoring a disagreement regarding date formats in US space articles. MOS:DATETIES supports an article such as STS-47 ("the 50th NASA Space Shuttle mission") using mdy dates. However, Wikipedia:WikiProject Spaceflight/Style guide included the advice "Dates should be in day-month-year format" for many years apparently due to a NASA style guide which includes "full dates should be in a day-month-year format". The wikiproject guide was updated on 11 January 2022 to remove the advice to use dmy with a discussion at project talk. That discussion includes claims that the NASA style guide is for certain historical documents and is contradicted by recent NASA publications which use mdy. The project talk points out that a local consensus about date formats cannot overrule site-wide conventions so I'm afraid the ball lands here.
Should STS-47 use dmy or mdy? The quick answer would be to thrash it out on article talk, but there is at least one user (see user talk) who appears to want to change any mdy to dmy in all space articles so the issue should be settled in a central location. If an RfC is needed, where should it be held? Johnuniq ( talk) 06:26, 12 February 2022 (UTC)
In topics where a date format that differs from the usual national one is in customary usage, that format should be used for related articles: for example, articles on the modern US military, including biographical articles related to the modern US military, should use day-before-month, in accordance with US military usage.appears to give the US military as just one example of a topic with "customary usage" of another date format. I don't think the MOS needs to be changed in order to decide that NASA is a second example after the US military. I think a RFC on WT:SPACEFLIGHT should be sufficient to establish a second example. The MOS clearly says the military is one example, it's not an exhaustive list. Leijurv ( talk) 06:41, 12 February 2022 (UTC)
MOS guidance is to use variationsas appropriate and to WP:RETAIN. The military and NASA are variations within a variation. The argument is therefore somewhat self-defeating. Cinderella157 ( talk) 11:50, 19 February 2022 (UTC)
This isn't a conversation about the common date format used by US publications and NASA, but rather if spaceflight articles should use DMY because of their international readership.No, it is a conversation about the date format to be used in NASA related articles and whether NASA falls to the same exception as the US military. That you raised an opinion about readership does not make this whole thread/discussion about readership.
US-centric space articles are likely to be read by US readers? Cinderella157 ( talk) 13:12, 19 February 2022 (UTC)
I think WP:Ordinal used to have guidelines on when to use "first" and when to use "1st". I can't find it now. An editor is consistently using "1st" in a sentence when it should be "first". Where is the MOS guideline? Bubba73 You talkin' to me? 07:56, 19 February 2022 (UTC)
Integers from zero to nine are spelled out in words.So "first" is correct per MOS. Schazjmd (talk) 20:13, 19 February 2022 (UTC)
spell=on
flag in the convert template for such numerals, as this is what the MOS calls for. An editor disregarding this is editing against the MOS (and normal English prose conventions).
Archon 2488 (
talk)
14:41, 20 February 2022 (UTC)
Centuries and millennia are identified using either "Arabic" numerals (the 18th century) or words (the second millennium)Considering that and MOS:1ST together, we should write "first century". But MOS:CENTURY actually uses "1st century" elsewhere. MB 18:44, 20 February 2022 (UTC)
Following on from the above conversation, I came here to check it if should be 12th or twelfth in a DYK submission. The guidance remains confusing because under ordinals it says "For guidance on choosing between e.g. 15th and fifteenth, see § Numbers as figures or words" but under that section nothing is mentioned ... or am I missing something? Mujinga ( talk) 11:08, 23 February 2022 (UTC)
Integers greater than nine expressible in one or two words may be expressed either in numerals or in words (16 or sixteen…, which I take as licence to use either 12th or twelfth as you prefer. Certes ( talk) 13:27, 23 February 2022 (UTC)
WP:DIGITS says to group multi-digit quantities, with only a few exceptions for years. This looks absolutely horrific for multi-digit fractions, as occur for instance in Harmonic series (mathematics): we get atrocities like "14274301/4084080". Even spacing the slash doesn't help: "14274301 / 4084080". Compare the obvious way of writing this as a horizontal fraction, "14274301/4084080". Can we maybe add an exception that numbers used as part of larger mathematical expressions should not be spaced? — David Eppstein ( talk) 20:10, 27 February 2022 (UTC)
{{
frac}}
{{
sfrac}}
WP:DIGITS says to group multi-digit quantities, with only a few exceptions for years. This looks absolutely horrific for multi-digit fractions, as occur for instance in Harmonic series (mathematics): we get atrocities like "14274301/4084080". Even spacing the slash doesn't help: "14274301 / 4084080". Compare the obvious way of writing this as a horizontal fraction, "14274301/4084080". Can we maybe add an exception that numbers used as part of larger mathematical expressions should not be spaced? — David Eppstein ( talk) 20:10, 27 February 2022 (UTC)
{{
frac}}
{{
sfrac}}
Would it be acceptable to write "USD" instead of "US$," in situations where disambiguation is needed for the country but not for the fact that USD refers to currency? Just curious, because I like "USD" better. Birdsinthewindow ( talk) 21:59, 10 April 2022 (UTC)
This stems from a discussion on WP:ERRORS yesterday. MOS:PERCENT currently states "percent (American English) or per cent (British English)", but that's not quite right. I understand American English does mandate 'percent', but British English allows both forms. Dictionaries split equally on which version they prefer: Cambridge percent, Oxford per cent, Collins percent, Macmillan per cent. In all cases they list the other version as a valid variant. Style guides seem to follow either Oxford or Cambridge spellings throughout, though the BBC's style guide encourages the % symbol instead. It appears we should not be prescribing one version as 'British' when both are valid in British English. I suggest a minor tweak to the phrasing:
Modest Genius talk 18:13, 6 January 2022 (UTC)
a large percent of students. Barbarous. E Eng 19:26, 6 January 2022 (UTC)
a large percentage of students. — David Eppstein ( talk) 21:36, 6 January 2022 (UTC)
'Zero-percent [ sic] financing' is an interest-free loan.-- John Maynard Friedman ( talk) 19:49, 6 January 2022 (UTC)
The discussion above indicated a general preference for standardising on 'percent' for WP:COMMONALITY reasons. Can we implement that change? Modest Genius talk 12:05, 9 February 2022 (UTC)
I don't think a full request for comment is necessary, but if others disagree, we could do that. How does this language change sound?
The current section on percentages says (in full):
- In the body of non-scientific/non-technical articles, percent (American English) or per cent (British English) are commonly used: 10 percent; ten percent; 4.5 per cent. Ranges are written ten to twelve per cent or ten to twelve percent, not ten–twelve per cent.
- In the body of scientific/technical articles, and in tables and infoboxes of any article, the symbol
%
(unspaced) is more common: 3%, not 3 % or three %. Ranges: 10–12%, not 10%–12% or 10 to 12%.- When expressing the difference between two percentages, do not confuse a percentage change with a change in percentage points.
I propose changing the first bullet point to:
- In the body of non-scientific/non-technical articles, percent is commonly used: 10 percent; ten percent; 4.5 percent. Ranges are written ten to twelve percent, not ten–twelve percent. Percent is commonly used in American and British English. Avoid per cent on the basis of WP:COMMONALITY.
The other bullet points would not change.
Thank you, SchreiberBike | ⌨ 16:27, 9 February 2022 (UTC)
So: should all centuries use the same form (numeral vs word) in an article for consistency and per MOS:NUMNOTES? Or should they respect MOS:ORDINAL? Except when they are in the same sentence ("From the fifth to the 11th century" => "From the 5th to the 11th century" or "From the fifth to the eleventh century")?
Would be great to add a bullet point to MOS:CENTURY to clarify that issue. A455bcd9 ( talk) 08:44, 8 April 2022 (UTC)
I knew this had been resolved once, but it took me a while to track it down. There was a discussion at
Wikipedia talk:Manual of Style/Dates and numbers/Archive 138#Centuries format in September 2012 where the consensus was to write "Centuries not in quotes or titles should be either spelled out (eighth century) or in Arabic numeral(s) (8th century). The same style should be used throughout any article."
Minor modifications later changed it to "Centuries and millennia not in quotes or titles should be either spelled out (eighth century) or in Arabic numeral(s) (8th century), with in-article consistency."
On March 19, 2014,
EEng
removed that paragraph and replaced it with "Centuries are given in figures (the 18th century BCE, not XVIII century) or words (the eighteenth century BCE)."
This removed the phrase "in-article consistency"
. That was
explained on the talk page at the time by EEng that "The bit about in-article consistency isn't needed because that's a general principle given in the boilerplate at the top of the page."
To make it explicit, I think we should add back "in-article consistency"
.
SchreiberBike |
⌨
04:01, 15 April 2022 (UTC)
Please see Wikipedia talk:Manual of Style#MOS:ERA: dispute over what "established era style" means. — SMcCandlish ☏ ¢ 😼 22:45, 3 April 2022 (UTC)
Does MOS:DATETOPRES apply to infoboxes, tables or just prose? If it applies to infoboxes a number of sport projects will need to change their documentation (and many articles) Wikipedia:WikiProject Football/Players is one example. If not, then this should probably be reverted. Either way, the section on this project should probably make the scope clear. Not watching here, so please ping me if you would like me to respond. Walter Görlitz ( talk) 03:39, 24 February 2022 (UTC)
...tables and infoboxes where space is limited, pres. may be used (1982–pres.)— Bagumba ( talk) 00:37, 25 February 2022 (UTC)
You are trying to change how an entire WikiProject operates, and has done with no issues for 16+ years, affecting tens of thousands of articles. Giant Snowman 19:31, 7 March 2022 (UTC)
MOS:DATETOPRES and the broader community consensus seems pretty clear and specifically states "Do not use incomplete-looking constructions such as 1982–", which appears to be what this is all about. Cinderella157 ( talk) 00:51, 8 March 2022 (UTC)
It seems clear that the projects should meet the MoS's requirement rather than a requirement to change the MoS because a few sports projects object to implementing it. Is this worth an RfC? Walter Görlitz ( talk) 23:19, 6 April 2022 (UTC)
There aren't tens of thousands of active players with page- almost all current association footballers, which itself would be thousands of articles I imagine. And then there's at least 4 other sports listed (albeit I imagine they have fewer articles, as the sports have not as many countries with professional leagues). Joseph 2302 ( talk) 10:25, 7 April 2022 (UTC)
–pres.
as this MoS suggests and it is actually narrower than a four-digit year and it makes the construction complete, which is the goal of this MoS.
Walter Görlitz (
talk)
19:54, 7 April 2022 (UTC)
I have edited the MOS to make it clear that whilst you should generally avoid open ended dates, some sports do and that's fine. That a) reflects the actual usage of certain sports WikiProjects whilst b) not opening the floodgates for implementation in other types of articles (which should continue to use –pres.
Giant
Snowman
19:23, 17 April 2022 (UTC)
2017—
or 2017—pres.
in the infoboxes of sports people is not. Unsure why you are suggesting I read AGF - that in itself is ABF. The irony.
Giant
Snowman
09:31, 18 April 2022 (UTC)
Over on Talk:Euclid–Mullin sequence, someone with more MOS knowledge than common sense suggested modifying a comma-separated list of numbers (of widely varying numbers of digits) to add more commas separating groups of digits, and someone else with more MOS knowledge than common sense agreed. I was horrified to see that WP:DIGITS does not warn against doing this. Maybe it should? — David Eppstein ( talk) 07:27, 4 May 2022 (UTC)
{{
val}}
to display numbers like 12345678.
Stepho
talk
08:05, 4 May 2022 (UTC)
The passage in the article mentioned by David Eppstein is
2, 3, 7, 43, 13, 53, 5, 6221671, 38709183810571, 139, 2801, 11, 17, 5471, 52662739, 23003, 30693651606209, 37, 1741, 1313797957, 887, 71, 7127, 109, 23, 97, 159227, 643679794963466223081509857, 103, 1079990819, 9539, 3143065813, 29, 3847, 89, 19, 577, 223, 139703, 457, 9649, 61, 4357, 87991098722552272708281251793312351581099392851768893748012603709343, 107, 127, 3313, 227432689108589532754984915075774848386671439568260420754414940780761245893, 59, 31, 211... (sequence A000945 in the OEIS)
I suggest that in this day and age, this passage should not be considered human-readable. Maybe 80 years ago a passage like this might have been considered human readable, because the printing press was almost all we had for disseminating information. But today, trying to retype a passage like this by hand would be irresponsible. So this kind of information should be in some machine-readable format. Jc3s5h ( talk) 00:44, 5 May 2022 (UTC)
The point of this thread is ... to seek a change to the MOS that explicitly discourages comma-separated digit groups in comma-separated numbers.Separating list items with semicolons is an established method for text that also includes commas ("Queen Abi; Gordon, professor of punctuation; Eric ....) and may even be becoming more popular. Semicolon-separated number lists are easily imported into eg Excel. Should we recommend semicolons? NebY ( talk) 15:32, 28 May 2022 (UTC)
The Australian Commonwealth Style Guide recommends using spaces instead of commas for separating digit groups this reason. Hawkeye7 (discuss) 19:31, 28 May 2022 (UTC)
Sometimes figures and words carry different meanings; for example, Every locker except one was searched implies there is a single exception (without specifying which), while Every locker except 1 was searched means that locker number 1 was the only locker not searched.
Suppose we change the statement and its variants to being about a locker numbered 128. Suppose we had thousands of lockers and we want to know how to interpret this statement:
Every locker except 128 was searched.
Georgia guy ( talk) 19:01, 26 May 2022 (UTC)
I noticed 2001-09-02 is acceptable in some conditions when space is limited, same goes with 2 Sep 2001 and all other abbreviated formats like Sep 2, 2001
Formats like 2 September 2001 and September 2, 2001 are allowed everywhere, in an American article it's September 2, 2001 whereas in a British article it's 2 September 2001
Formats like 2001-09 are unacceptable as it could be mistaken by a range of ranges 2001–2009, and formats like 02-09-2001 are unacceptable as it could mean February 9, 2001 or 2 September 2001, and 01-09-02 could mean January 9, 2002
in MDY format
, 1 September 2002
in DMY format
, or 2001 September 2
in YMD format
A template like {{FULLDATE|type=mdy|time=2001-09-02}}
outputs as September 2, 2001
or in DMY format {{FULLDATE|type=dmy|time=2001-09-02}}
outputs as 2 September 2001
-- 98.31.29.4 ( talk) 01:38, 30 May 2022 (UTC)
I propose that this text needs clarification, because the meaning of the word "conservative" in this context is not clear:
Where explicit uncertainty is unavailable (or is unimportant for the article's purposes) round to an appropriate number of significant digits; the precision presented should usually be conservative.
If "
conservative" means "resisting change", then rounding conservatively means keeping more significant digits (making less change to the original value, but the next sentence Precise values ... should be used only where stable and appropriate ..., or significant ...
implies that fewer significant digits are generally preferred, which would be consistent with "conservative" meaning "cautious, moderate" (fewer significant digits are more likely to be "correct" within the precision implied by those fewer significant digits).
Which is the intended meaning? How can we reword the MOS sentence to make it explicit? Mitch Ames ( talk) 11:50, 5 June 2022 (UTC)
measuring with more precision takes more effort— That's true, but Wikipedia editors are never measuring anything, we are reporting what others have done. In the sentence I quoted from MOS:UNCERTAINTY we are explicitly rounding an existing value. Mitch Ames ( talk) 12:40, 5 June 2022 (UTC)
I've moved "normal rounding" into a separate section from #Meaning of "conservative" when rounding, because the two are separate and independent issues. Mitch Ames ( talk) 00:01, 15 June 2022 (UTC)
The meaning of "a normal and expected way" also seems to be unclear, as I keep seeing editors in film articles apparently not understanding how to round numbers and rounding the same number inconsistently. This guideline does not make it explicitly clear how normal rounding works, ie that more than half .5 or higher rounds up (or that 30 seconds or more rounds up if it is minute, etc). I don't know if editors do not understand the basic mathematics of how normal rounding works or if they are oblivious and decided to truncate instead of round the numbers (some people are all right brain and can't do math). -- 109.77.199.246 ( talk) 13:50, 14 June 2022 (UTC)
I sometimes see an editor add a weekday name to a date in an article. For example, changing "X occurred on 19 June 2022" to "X occurred on Saturday, 19 June 2022". This seems to me to be unnecessary, except in a very few cases where the day of the week is relevant to the event, but it's not clear to me whether it actually violates the MOS. I don't see any mention in the MOS of using or not using weekday names in dates. Should such changes be reverted, ignored, or even encouraged? CodeTalker ( talk) 22:52, 19 June 2022 (UTC)
"unnecessary, except in a very few cases where the day of the week is relevant to the event"like the attack on Pearl Harbor (an attack will be more successful when people were away from the defenses for the weekend), but usually it's not. I've taken out days of the week many times and no one has objected. SchreiberBike | ⌨ 23:49, 19 June 2022 (UTC)
There is a discussion at Template talk:GBP#Semi-protected edit request on 12 June 2022 that may interest watchers of this page. Although there is a consensus in favour of the change, more eyes may identify unforeseen consequences before they happen. Comments welcome. -- John Maynard Friedman ( talk) 16:46, 25 June 2022 (UTC)
Avoid making up new abbreviations, especially acronyms. For example, " International Feline Federation" is good as a translation of Fédération Internationale Féline, but neither the anglicisation nor the reduction IFF is used by the organisation; use the original name and its official abbreviation, FIFe.
Currently there is a rule that numbers are not spelled out in mathematical formulas. I think that this rule should be widened. Spelled numbers look somewhat strange in any mathematical text, not only in formulas, if they are considered as mathematical objects. But if a number in a mathematical text is simply a number of objects then it is good and sometimes even very desirable to spell it out. For example: "The smallest three prime numbers are 2, 3, 5." In my opinion, it is very undesirable to write this as "The smallest three prime numbers are two, three, five.", but just this way of writing is technically the best one according to the current Wikipedia rules. I propose to change the rules according to this explanation. D.M. from Ukraine ( talk) 18:12, 21 July 2022 (UTC)
note that the statement "the first three primes are 2, 3, and 5" was replaced to avoid the issue of alternative definitions of prime numbers. dying ( talk) 03:51, 27 July 2022 (UTC)Integers from zero to nine, used in a mathematical context, are not required to be spelled out: the prime numbers 2, 3, and 5, not the prime numbers two, three, and five.
If the event's specific date, which consists of the day and month, is unknown but the year is the same as the event before it, may "in the same year" be used? — Princess Faye ( my talk) 09:27, 26 June 2022 (UTC)
EEng, regarding your comment in the summary of this edit, i think the second counterexample in the first column ("9. June") suggests that the "dot to the day" was referencing the ordinal dot. however, now that "to the day or" has been removed, i am admittedly somewhat worried that readers who see the second counterexample and its associated comment may be confused about how abbreviated months are relevant to the counterexample "9. June". would it have been more helpful to, for example, link "to the day" to the description of the ordinal dot? alternatively, the cell in the third column containing the comment can be split into two rows, one for each of the two counterexamples. dying ( talk) 14:21, 11 August 2022 (UTC)
Apparently, this guideline says we don’t have to use a comma after the year if we write “On 5 May 1822 the act became law” but we do have to use a comma after the year if we write “On May 5, 1822 the act became law”. This seems like a really silly distinction. Is it for real? Even in an article title? This issue has arisen today at Talk:2021 United States Capitol attack. Anythingyouwant ( talk) 00:00, 29 July 2022 (UTC)
Correct: | He set October 1, 2011, as the deadline for Chattanooga, Oklahoma, to meet his demands. |
Incorrect: | He set October 1, 2011 as the deadline for Chattanooga, Oklahoma, to meet his demands. |
Surely you would never think proper a title that says Capitol attack of January 6, 2021,As I said on the talk page the editor is referring to, this is a bad faith, literalist interpretation of the DATECOMMA. Obviously all titles on Wikipedia do not have ending punctuation. Thrakkx ( talk) 13:30, 29 July 2022 (UTC)
The [year] is treated as parenthetical.Thrakkx ( talk) 13:33, 29 July 2022 (UTC)
She was frustrated with her December 15, 2021, jury duty.
She was frustrated with the jury duty she served on December 15, 2021.
Waco, Texas, physician John Smith...
John Smith, a physician from Waco, Texas, ...Thrakkx ( talk) 21:17, 29 July 2022 (UTC)
The South Sudanese pound has no unique symbolic abbreviation, it exclusively uses an unadorned £. For distinction I recommend advising £10,000 SSP be used, with the ISO code appending the numerals.
Discussions on several pages have concluded that ₤ is merely a stylistic choice and is not regarded as a distinct separate sign from £ in general usage, and that the only reason for its inclusion as a separate character from £ in Unicode is for compatibility with a legacy character set ( HP Roman). I recommend noting that and advising against its use anywhere due to compatibility problems that would arise.
The Egyptian pound sign displayed on this page is also a point of contention. E£ was taken out of the Egyptian pound's article after it was found to lack any reliably sourced citations (the correct sign is £E or LE).
And my last point on currency is that Wikipedia's sign for the Australian dollar, A$, is not recommended by style guides and is not used by the Reserve Bank of Australia, these sources use $A. Countries with a recent strong British heritage usually place the disambiguating abbreviation after the currency sign, not before it. It is a minor swap, but not all currencies use the US dollar's abbreviation as a template. The Australian and New Zealand dollars inherited this practice from their £sd-based currencies, which were abbreviated £A and £NZ respectively.
Finally (you can all breathe a sigh of relief), I believe it is probably more efficacious for UK-centric articles to always display the imperial units first followed by an SI conversion. The BBC recommends this usage
in their style guide. Especially as it is likely more use of imperial will be made in the future.
TheCurrencyGuy (
talk)
15:38, 9 August 2022 (UTC)
I believe it is probably more efficacious for UK-centric articles to always display the imperial units first followed by an SI conversionmeans we can all
breathe a sigh of relief, you're mistaken. You've basically just whacked a hornets nest with a stick. I strongly oppose making such a change in this area.
consensuses were established on the relevant pagesseems inaccurate on the case of Egyptian pound, where the "consensus" is the WP:WRONGVERSION from when you were blocked for edit warring. Kahastok talk 07:22, 12 August 2022 (UTC)
For the British pound sterling (GBP), use the £ symbol, with one horizontal bar, not the double-barred ₤ (which is used for Italian lira). For non-British currencies that use pounds or a pound symbol (e.g. the Egyptian pound, E£) use the symbol conventionally employed for that currency.
For the British pound sterling (GBP), use the £ symbol, with one horizontal bar, not the double-barred ₤ symbol ("lira sign") (Whether a pound sign uses one or two bars is purely a type-design choice.) For non-British currencies that use pounds, use the symbol or abbreviation conventionally employed for that currency, if any.
For the British pound sterling (GBP), use U+00A3 £ POUND SIGN, not U+20A4 ₤ LIRA SIGN (the latter being a code-point for a legacy character set. Whether a pound sign uses one or two bars is purely a type-design choice.) For other currencies named "pound" or similar, use the symbol or abbreviation conventionally employed for that currency, if any.TheCurrencyGuy ( talk) 00:04, 17 August 2022 (UTC)
For the British pound sterling (GBP), use U+00A3 £ POUND SIGN, not U+20A4 ₤ LIRA SIGN (the latter being a code-point for a legacy character set; whether a pound sign uses one or two bars is purely a type-design choice). For other currencies named "pound" or similar, use the symbol or abbreviation conventionally employed for that currency, if any – e.g. IR£ for Irish Pound (IEP).
The broader issue (below) will take a lot longer to resolve so unless anyone objects, I propose to change the MOS to read:
I don't think that the MOS needs to go the history of Unicode as TCG proposes. If anyone wants it, the linked articles provide it. -- John Maynard Friedman ( talk) 20:27, 18 August 2022 (UTC)
It seems to me that a broader issue here is that TheCurrencyGuy is interested in "cleaning up" currency notation across a wide variety of Wikipedia pages, and he is often running into conflicts because the notation he chooses isn't always exactly right, or doesn't quite have consensus. I know that MOS creep is an issue but, since currencies are used on a wide variety of Wikipedia pages, it doesn't seem absurd to me to have a subpage (or just somewhat expand the section of this page) where the actual notations are listed for a variety of currencies.....then people interested in cleaning up currency notations on Wikipedia could get consensus for the style there before deploying it on many pages. I think the situation is not always clear. For example, in languages that don't use the Latin alphabet, the currency notation that is generally used "in the wild" is not always the one that is used in English-language sources.... CapitalSasha ~ talk 16:15, 17 August 2022 (UTC)
I couldn't find that in MOS:TOPRESENT. — Guarapiranga ☎ 01:41, 15 August 2022 (UTC)
if you're interested, I'd change that to "If you're interested and prepared to be bored to tears". E Eng 15:39, 18 August 2022 (UTC)
Hey everyone, I hope you are all well.
Over the years this issue has come up again and again: whether it is okay to use "2022–present" (or whatever the current year is; last year it was "2021–present", next year it will be "2023–present" etc). This used to not be an issue as on soap articles etc we would format ranges like "2022–", "2021–", "1991–2009, 2011–" etc, but now several editors are opposing to "2022–present" due to 2022 being the present, and to put "2022" on list articles (e.g. List of Days of Our Lives cast members). However, this causes many issues such as:
1.) Putting simply "2022" suggests that the event has already been completed, especially as in the past "2022" would mean that the stint is already finished whereas "2022–" or "2022–present" means that it is ongoing. This is especially true in things such as lists of characters, as many cast members appear in guest stints and thus "2022" suggests that the stint has already ended/is confirmed to end this year. For example "1999–2008, 2022" looks like the stint in 2022 has already been completed, whereas "2022–present" illustrates that it is still ongoing.
2.) This is inconsistent with other wikipedia lists, where "2022–" or "2022–present" is used in lists
3.) It is inconsistent with the MOS technically as the MOS says to use "–present" and not just "2022" if it is the current year
4.) Often they are not updated the following year and thus this makes it incorrect as wrong (e.g. I recently found an article which said just "2020" instead of "2020–present"/"2020–"
In the past I have tried to avoid unambiguity by using "Since 2022" in tables, but this is quite unusual as it differs from other articles. Even though we are in 2022, "2022" is also not technically the present - January 2022 is not the present, and even August 18 is not the present. Hence, I have started this discussion to allow the use of "2022–present" and avoid the ambiguous use of simply "2022" for ongoing events/durations. DaniloDaysOfOurLives ( talk) 17:32, 20 August 2022 (UTC)
This is not the same – what I am asking is there to be clarity on whether "2022–present" (or even "2022–") to be used as some editors keep reverting it to simply "2022" but this is extremely ambiguous DaniloDaysOfOurLives ( talk) 13:48, 21 August 2022 (UTC)
"Unfortunately, MOS:DATETOPRES does not cover what happens when the start year is the present year."It still doesn't. Suggestions included adding the month, or (updating the suggestions) "beginning 2022" or "since 2022". I agree that "2022-present" looks weird in 2022, and it's little comfort that it'll look better in a few months. NebY ( talk) 16:26, 23 August 2022 (UTC)
Currently this guideline MOS:SEASON says magazine issue dates should be lower-case -- there's an example given: details appeared in Quarterly Review, summer 2015. I think this should be changed. The sources I use for magazine articles invariably capitalize the initial letter of the season in these cases. Some examples:
I also tried looking in Google Books for "fall 1943 issue" to see what the usage is. The genre uses appear to be exclusively uppercase, but the non-genre magazines vary. I found:
Eight with uppercase, three with lowercase. I think we could change the guidance to say either "upper or lower case is OK", or we could say upper case is preferred. I don't think we can say "follow the source" because here we have two sources differing in referring to the same magazine. And I don't think it should stay as lower case; that's clearly not the customary usage. Mike Christie ( talk - contribs - library) 19:31, 19 August 2022 (UTC)
There's an interesting discussion at Talk:Ceres (dwarf planet). As far as I can see, the article was started in British English, was peer-reviewed in 2007 in that dialect, but has recently drifted to using US English. There seems to be some confusion about date formatting versus spelling variants there. I don't have the patience to argue it out, having made all the points I can. It might be helpful to have some input from folks with experience of MOS:RETAIN and how it works there. The worst of it is that this is in danger of derailing an otherwise positive FAC for this otherwise pretty good article. Thanks for any time you can spare. John ( talk) 22:29, 22 September 2022 (UTC)
There is currently a discussion at the linked talk page above about the heading for the binary versions of kilo/mega/giga/etc. Separate from the ongoing disruption, which will need to be dealt with at AN/I most likely, there is currently an attempt to defy our sources and this guidance in the MOS by referring to the units as "Legacy" (which is both unsupported by the sources, original research, and the only attempts to justify it are done by misattributing a JEDEC standard quoting an IEEE statement). — Locke Cole • t • c 20:35, 23 September 2022 (UTC)
TLDR: I don't think we should repeat the time zone designation throughout an article and I can't find it in the MOS. Is it in there? Where? If not, should it be?
Boring content yadda yadda: I've found the guidance on time zones but if guidance exists on repeating them I have not seen it yet – please enlighten me.
What I mean is that I understand that it may be desirable/necessary to specify the time zone when we are talking about an event (or, at least, we like to pretend it is, but that is another debate) but I don't see any guidance on whether it is necessary to repeat it every time we mention a time, when some (I) might argue that it has an annoying choppy effect on the text and is ludicrously unnecessary when the context has already been set. I find this just annoying: At 0830 BST DBaK made some coffee and by 0835 BST was applying milk and yoghurt to some cereal. At 0930 BST he sat down to read about
the Queen's funeral and by 0945 BST he was ready to throw the laptop across the room because it said BST twelve frakking times in the one article set in the same few days in the United Kingdom of Great Britain and Northern Ireland so it's not like it's going to suddenly change to Pacific Daylight Time halfway through the story ffs. At 1000 BST he talked to the dog for a while then at 1005 BST he made some coffee because meh.
Now I realize that if the MOS doesn't say don't do it then some editors, about whom I am trying not to be too rude, will argue that of course it is right and proper and that the Queen's article is just great saying BST twelve times. As I say, if this guidance does exist then I have sadly failed to find it, and if it doesn't exist then I think it should. Even if it said "yeah you should put the time zone in every time you mention it" then I could sortof live with that because at least it would be there in black and white, but I find the current absence (is it?) of anything on this very unhelpful. And yes of course I wish I could find something that said don't repeat it unless there is a really good reason to, but I haven't yet. Does it exist and if not should it? Help! Thanks and best to all DBaK ( talk) 09:39, 17 September 2022 (UTC)
so much common sense all in one place!– We like to purge ourselves of our monthly quota of required common sense as quickly as possible. Now we'll return to our usual menu of half-baked drive-by comments, parochial backbiting, and long-term score-settling. E Eng 05:54, 28 September 2022 (UTC)
I see YYYY-MM--
could be the alternative to YYYY-MM
, because of sorting dates, when the day of month is included you can use YYYYMMDD
to sort as
ISO 8601 allows both YYYY-MM-DD
and YYYYMMDD
, but when the day of the month is omitted only YYYY-MM
is allowed, but
MOS:DATEFORMAT doesn't allow that format at all because of the range of years, YYYY-MM-DD
can only be used where space is limited, and cite sources. 2001-07 is not permitted due to the ambiguity of range of years, 2001-07-- could be used in some places.
For an example
When the day of the month is included.
American article - {{sort|20010902|September 2, 2001}}
- September 2, 2001
European article - {{sort|20010902|2 September 2001}}
- 2 September 2001
When the day of the month is excluded.
{{sort|2001-07--|July 2001}}
- July 2001
Although there is {{
date table sorting}}
as well, you can use when the day of the month is omitted.
98.31.29.4 (
talk)
00:04, 4 October 2022 (UTC)
Based on what I read here, I attempted to add the converter tool to dollars for £2.192 billion. I used the following surrounded by {{ }}: To USD round|2192000000|GBR|2022 It results in:
2.798×109
I'm sure I'm stupidly missing something. What is it? HarvardStuff ( talk) 01:42, 6 October 2022 (UTC)
Can we get some extra eyes over to NTFS ( | talk | history | protect | delete | links | watch | logs | views), there are a number of editors revert warring over using IEC units in an article that clearly uses standard metric units. Worse, they're mixing units within the same statement, leading to a confusing experience for our readers. I'd standardized on the correct unit, but am being blindly reverted against the guidance of WP:COMPUNITS. Thanks! — Locke Cole • t • c 16:38, 5 October 2022 (UTC)
There is an RFC to answer questions about the {{ Quantities of bits}} and related templates. Please see the questions there and answer as you see fit. — Locke Cole • t • c 01:23, 10 October 2022 (UTC)
Section
§ Grouping of digits now says "Markup: Templates {{
val}} and {{
gaps}} may be used to produce this formatting. .. use of any space character
as a separator .. is problematic for screen readers". It is unclear whether the two templates prevent, ie solve, that issue or have the same issue. BTW, that issue might also occur with copy/paste effect: "Does {{val}} result in correct copy/space effects in this?" (iow, does c/p produce spaced number strings, IMO undesired?).
DePiep (
talk)
07:33, 10 October 2022 (UTC)
{{val|9.123456789}}
→ 9.123456789 → 9.123456789 (copy/paste){{gaps|123|456|789}}
→ 123456789 → 123456789 (copy/paste)The MOS doesn't come right out and say it, but since "On 5 May 1822 the act became law" (with no comma) is correct, I have assumed that "In 1822 the act became law" (with no comma after the year) is also correct. I don't normally remove a comma if it's already there, but lately I've been seeing a plague of people adding commas to this kind of sentence, and I sometimes revert if that's the only change being made in an edit. The comma doesn't belong, does it? GA-RT-22 ( talk) 20:46, 9 October 2022 (UTC)
I have started a discussion about the usage of plural or singular units for distances of swimming events (ie 100 metres vs 100 metre freestyle) and invite others for their input at Wikipedia talk:WikiProject Olympics#metres vs metre. Thanks. A7V2 ( talk) 04:16, 31 October 2022 (UTC)
Is there some good reason why most articles about electric vehicles use "kW-hr" instead of "kWh"? I checked the cited sources for a few of them and as far as I can tell the sources all use "kWh". Apparently "kW-hr" is sometimes used by the US government. Search for "kW-hr" GA-RT-22 ( talk) 03:19, 1 November 2022 (UTC)
Exception: In some topic areas, such as power engineering, certain products take neither space nor ⋅. Follow the practice of reliable sources in the article's topic area. Wh, VA, Ah kWh, MVA, GAh. As you've found reliable sources use in the topic area of electric vehicles use kWh, that's what I'd expect to see in our articles.
A few months ago I inquired about this, but didn't get any responses, so figured I'd try again. My results below are slightly off due to the time passed FYI.
The current MOS is to use No. instead of #, but I'm wondering why this is. It's only been discussed a few times, most recently back in 2016. From what I gathered, using "No." instead of "#" is more popular in the U.K., but not in the U.S., so why should the U.S. articles adopt the same style?
I know this is a piss poor example, but I quickly searched on Google "#11 on the" and got 65million results. Then I searched for "No. 11 on the" and only got 418,000 results ("his album reached #11 on The Chart" & "his album reached No. 11 on The Chart" was my thinking). I then did the same thing for Wikipedia. "#11 on the" got 21,800 results and "No. 11 on the" got 1,790 results. Wouldn't it be a waste of time trying to convert all of that? If the total amount was similar in both cases, it'd be understandable, but there's no way that "No." will catch up (so to speak) with "#".
I'm also aware that Twitter popularized the usage of "#" as a tag, but I don't think that matters much on Wikipedia since we rarely use it in that way here, except in edit summaries. Was hoping someone could shine some light on all of this for me. Thanks in advance. Xanarki ( talk) 20:33, 3 November 2022 (UTC)
#meant number was near-unknown in Britain until the internet came along. I have a memory of a family member once confusing an American server by asking for "hash 5" from the menu. And you will still find people who will not understand it. I don't believe the same is true of
No.in the US. MOS:COMMONALITY would require that we prefer
No.. Kahastok talk 21:09, 3 November 2022 (UTC)
£. Kahastok talk 21:09, 3 November 2022 (UTC)
lb. Martin of Sheffield ( talk) 21:48, 3 November 2022 (UTC)
Read Wikipedia:Logical_quotation_on_Wikipedia#Wikipedia_is_not_bound_by_external_style_guides,_anyway. (Just this section of the essay please.) Can you apply the terminology this essay uses in the second and third paragraphs with 4 examples of wrong and right reasons Wikipedia's rules are set up the way they are to the sentence "We use No. rather than #, not because...but because..."?? Georgia guy ( talk) 16:43, 8 November 2022 (UTC)
Applause for @ SilkTork:, who's sorted out WT:MOSNUM's archives, making them navigable and searchable right back to the year dot! I'd feared we'd have to live with the old mess forever. NebY ( talk) 18:32, 1 November 2022 (UTC)
Talk:2022 Morbi bridge collapse has an RFC for possible consensus. A discussion is taking place. If you would like to participate in the discussion, you are invited to add your comments on the discussion page. Thank you. BilledMammal ( talk) 06:47, 14 November 2022 (UTC)
Hello, a question. I destubbed an article and used format of dates in references in uniform format 2022-11-13, no other dates were used in the article. A user came and added use dmy dates template (which from the point of view of its national ties is OK). Do I have to change all the dates in the references to the dmy format, or can I keep it per MOS:DATERET? On the outside, there is dmy everywhere thanks to the template, so it's just the code. If the data format was uniform before, wasn't adding the template pointless? FromCzech ( talk) 07:03, 13 November 2022 (UTC)
|cs1-dates=y
with one of these two templates. —
David Eppstein (
talk)
08:12, 13 November 2022 (UTC)
{{
Use dmy dates|cs1-dates=yy}}
.
Stepho
talk
22:29, 13 November 2022 (UTC):::(
edit conflict)
|date=
:
|date=
occurred at
this edit which added the first reference to the article. It used |date=2020-04-30
. That is a perfectly legitimate date format. So long as subsequent references use |date=
with the same date format, cs1|2 is happy. There is nothing at Help:CS1 that prohibits the use of year-initial numeric dates in any date-holding parameter so long as all cs1|2 templates in the article follow the same formatting.Citation Style 1 is a specific style, documented at Help:Citation Style 1, and errors may be corrected to conform to that documentation. This is the same as if an article followed The Chicago Manual of Style; errors could be fixed if citations departed from the Chicago Manual. The only time the article itself would set the rules for how citations are done would be if the article consistently followed an ad hoc style developed just for that article. Jc3s5h ( talk) 02:00, 14 November 2022 (UTC)
{{use xxx dates}}
template when it updates the |date=
parameter. In doing so, it preserves |cs1-dates=
but does not apply that setting to dates in cs1|2 templates. I suspect, but don't know, that it is possible for the script to do the right thing and rewrite the dates in cs1|2 templates in the forms specified by |cs1-dates=
.|cs1-dates=
. The real purpose of that parameter is to cause the cs1|2 templates to render the dates as directed by the {{use xxx dates}}
template regardless of how those dates are written in the cs1|2 template. If I remember correctly, there was a period of time when the script did not modify cs1|2 template dates. But, because editors complained that the cs1|2 dates weren't being updated when the script was run, a change was made to rewrite dates to use the canonical date format specified by the {{use xxx dates}}
template. The script should probably be changed so that cs1|2 template dates are rewritten to obey the format specified in |cs1-dates=
. I acknowledge that this change would likely only apply to those cs1|2 template under their canonical names. The script won't be able to rewrite dates in templates using redirected names nor will it be able to rewrite dates of cs1|2 templates that exist inside wrapper templates (there are a lot of both types). Still, the preponderance of cs1|2 template use is by the canonical name.|accessdate=
and |archivedate=
parameters irrespective of the parameter in place. If I were to rewrite so that date format mirrors the |cs1-dates=
parameter, the script will first have to detect the parameter and act accordingly. I will need the help of someone who possesses the relevant skills. Volunteers kindly come forward.
Hello, I recently come across with an editor who change date format in references from "yyyy-mm-dd" to "d mmmm yyyy". The body of article itself already use "d mmmm yyyy" format and have Template:Use dmy dates in place.
In my understanding, between manually input "d mmmm yyyy" and using "yyyy-mm-dd" when Template:Use dmy dates used, both will show "d mmmm yyyy" to the reader. So in the eye of reader, they are the same format. Hence, no need to change from "yyyy-mm-dd" to "d mmmm yyyy" on the references.
However his argument to change the date format are:
Publication dates in an article's citations should all use the same format
Therefore, I asked here to get clarity on what considered as "same date format". Thanks. Ckfasdf ( talk) 23:10, 26 November 2022 (UTC)
{{
Use dmy dates}}
has the |cs1-dates=
parameter then the format that |cs1-dates=
specifies is the format that will be displayed in references.{{
Use dmy dates}}
does not have the |cs1-dates=
parameter then dmy will be displayed in references.{{
Use dmy dates}}
was recently added and it changed the majority of the references then it should have |cs1-dates=
added to keep the references in the majority format that they used to have - as per
WP:DATERET.{{
Use dmy dates}}
will override it.{{
Use dmy dates}}
since August 2020 and it does not have the |cs1-dates=
specified. And yes, both "d mmmm yyyy" and "yyyy-mm-dd" version display correctly as "d mmmm yyyy", I also agree that this really minor issue.I didn't find in the page so I ask it here: which of the two is correct, 7th–5th century BC or 7–5th century BC?-- Carnby ( talk) 07:49, 10 September 2022 (UTC)
{{
daterange|Starting Date|Ending Date}}
and {{
daterangedash|Starting date|Ending date|Date format string}}
would help, with a parameter indicating century and support for local style, e.g., {{
mdy}}. --
Shmuel (Seymour J.) Metz Username:Chatul (
talk)
14:39, 29 November 2022 (UTC)Should MOS:CIRCA apply even in less formal usage in running text, such as that found in the final sentence of I Want to Know What Love Is#Music video? I was thinking that the sudden appearance of an abbreviation in the running text might seem jarring. Or is there a better way to recast the sentence? I haven't done anything with it. 1980fast ( talk) 23:50, 29 November 2022 (UTC)
This RFC is about the use of the BC/AD and BCE/CE in article titles for years, decades, centuries, millennia. The questions I would like answered in this RFC would be to determine whether we should use the BC/AD styling for years or the BCE/CE styling. Examples include: AD 10, 13 BC, 420s BC, 16th century BC, 2nd millennium BC. Interstellarity ( talk) 13:53, 29 October 2022 (UTC)
article titles for years, decades, centuries, millennia. Levivich ( talk) 16:45, 15 November 2022 (UTC)
This RfC is out of scope for this page; you are attempting to set up a WP:LOCALCONSENSUS to override MOS:ERA. The discussion shoule be at Wikipedia talk:Manual of Style/Dates and numbers at the very least, better still would be Wikipedia talk:Manual of Style or WP:VPP. -- Redrose64 🌹 ( talk) 14:09, 29 October 2022 (UTC)
Could anyone supporting "Allow either" provide an example of any article where it would be "appropriate" to use BCE in the article title? St Anselm ( talk) 20:11, 29 October 2022 (UTC)
Proposer wishes to see articles retitled using BCE/CE, whatever's in the body [62] They are alone in seeking this. Can we snow-close this before it becomes any more disruptive? NebY ( talk) 21:03, 29 October 2022 (UTC)
I'm confused by the wording of the RfC, but the titles should be consistent. In other words articles in a sequence of similarly named articles should either all use AD/BC or all use CE/BCE. I don't have a view on which that should be (happy to accept the consensus choice of fellow editors). Dondervogel 2 ( talk) 11:01, 3 November 2022 (UTC)
12 January 1999 instead of January 12, 1999? 47.205.254.217 ( talk) 07:57, 4 December 2022 (UTC)
I fixed a singer's birthdate as December 29, 1959 and they reverted it to 29 December 1959 the user labeled good faith but it was December 29, 1959 before it was changed. 47.205.254.217 ( talk) 06:50, 5 December 2022 (UTC)
{{
use dmy dates}}
. For you to insist that everybody use your American format instead of their own national format shows either ignorance (forgivable) or rudeness. Put simply, you are trying to force American customs onto other people.
Stepho
talk
11:06, 5 December 2022 (UTC)
{{
use dmy dates}}
template, which should be followed.
Peter coxhead (
talk)
13:10, 5 December 2022 (UTC)
I was editing
Umibōzu and I found this statement: "They are often a few meters to a few tens of meters in length." I would add a conversion in milesyards or feet but I don't know whether is necessary or not. Perhaps milesyards would be more correct in that case, getting rid of kmsmetres/meters, since there's no value? Also: is it correct the U.S. spelling "meters" in articles dealing with Japanese mythology? Thanks in advance.--
Carnby (
talk)
21:43, 11 December 2022 (UTC)
An editor is repeatedly removing Template:Bit and byte prefixes from Binary prefix (the only article the template is used on on the project). It appears they're doing this because they don't like the way a recent RFC went, so they're effectively subst'ing the template portion they prefer and beginning the argument anew. Instead of engaging in discussion, they're engaging in protracted revert warring to force it their way. Help. — Locke Cole • t • c 00:03, 17 December 2022 (UTC)
BTW, why is the market share of MS relevant given my toungue in cheek comment about graduating from MS? Just curious.Just noting that while it's indeed true that other desktop OS's may be moving towards these units, that the one in widest use by our readers and the public at-large still clings to the commonly used binary prefixes. — Locke Cole • t • c 05:23, 19 December 2022 (UTC)
The table in WP:MOSNUM#Quantities of bytes and bits ( MOS:COMPUNITS) is currently provided by a template. Recent conflict over that template have sometimes left the table confusingly in conflict with the MOS text eg listing units as "deprecated" removing the prefix "tera-". Our text has been the subject of (ahem) vigorous discussion here, but most of us are very happy not to join in discussions about the template and are blissfully unaware of changes in it.
Suggestion: we take a stable, compatible version of the template and make it a simple table in COMPUNITS, no longer transcluded from Template:Bit and byte prefixes. NebY ( talk) 16:42, 18 December 2022 (UTC)
Why is this table and the last column still an obsession by certain writers here. The only reason it is labeled as it is, is because it provides the only hope for refusenics of unambigous storage units to hang on to a sliver of credibility, when every standards bureau that actually has a voice in the subject matter has deprecated the binary interpretation and stood firm on the new standards, and when new software written these days uses these prefixes accordingly and without which the software may not be distributed in certain environments. And JEDEC in fact agrees with them and refers to their definitions in clear language by pronouncing their ambiguity and deprecation. They state their intent unambiguously in listing them because of ongoing usage. They do not define them in any binding manner. Why is this simply ignored here and why is this column even there? We are listing examples of outdated usage solely because an industry interest group still explains the old usage. Why is it not sufficient to display the standard definitions and discuss deviations in each article in prose? In every other article of units and natural constants or metrics and such the standards orgs are followed rigorously. Why hot here? It's obvious that there still are WP editors who let their personal tastes cloud their mind and deny readers a modern, accurate, unambiguous presentation of these subject matters. Childish belittling the sounds or pronunciations of the units is much like teenager bullying. When the newest SI prefixes got defined this fall, WP editors were eager and quick to add them to every table there is, without regard to actual usage, and without criticism in stupid opinions about their sound or pronunciation. None of these sound any more or less stupid or amusing than giga or pico or any other one. Get rid of the column, or fill it out with a header Deprecated. The MOSNUM needs to be changed and modernized. Too long has it represented a presumed consensus that was only slimly obtained by opinionated prejudice, bullying to drive intelligent contributors away, and proliferation of sock puppets of refusenics. kbrose ( talk) 20:15, 18 December 2022 (UTC)
This manual recommends using the confusing prefixes for bytes with the meaning specified for the article. I think that's not very good because copying them to another article can result in errors if the copier doesn't replace them (e.g., if they don't know about that). I think there should be templates that automatically place the correct name for units. Orisphera2 ( talk) 12:06, 7 January 2023 (UTC)
{{
unit|32|Ki|byte}}
should produce either "32
kbytes" or "32
Kibytes", depending on the pages default interpretation of SI decimal prefixes. Any such templates should support at least bit, byte and word --
Shmuel (Seymour J.) Metz Username:Chatul (
talk)
23:40, 7 January 2023 (UTC)
References
Hi. The instructions about how to provide the explanation of units in quotations are currently inconsistent:
This page therefore does mention article text whereas WP:MOS does not. I suggest that article text is also removed here as it is self-referential and self-references should be avoided as per WP:SELFREF. -- TadejM my talk 15:25, 10 January 2023 (UTC)
One does mention 'article text' whereas the other does not. No problem, sir. /s TadejM my talk 09:30, 13 January 2023 (UTC)
![]() | This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 155 | ← | Archive 159 | Archive 160 | Archive 161 | Archive 162 |
@ Dondervogel 2: (who previously edited here as Thunderbird2 ( talk · contribs)) doesn't like WP:COMPUNITS, specifically the requirements around not using IEC units except under very specific circumstances. He'd like to change it. As I'm very much opposed to using IEC units as they are very rarely used in anything with widespread use (most of our sources use classic metric terms like KB, MB, GB, not KiB, MiB, and GiB), I'll leave it to them to fill in the reasoning for using these archaic terms that somehow overrides WP:NOR and WP:VNT. — Locke Cole • t • c 16:54, 25 April 2021 (UTC)
@ Denniss and Zac67: since you apparently agree with IEC units and also want the MoS changed. — Locke Cole • t • c 16:56, 25 April 2021 (UTC)
I'm a bit surprise of the aggressive tone seen in the comments here. We reverted the undiscussed changes to SDRAM-related articles where KiB etc are desired and required. Locke Cole did not even try to enter a discussion but simply continued to revert. We did start a discussion at Talk:Synchronous_dynamic_random-access_memory#Disputed_edits but all he did was simply closing it off. We do not intent to change Mosnum, you just have to accept there are areas where KiB etc has more value than KB etc.-- Denniss ( talk) 19:36, 25 April 2021 (UTC)
In my day job I program embedded devices. Which means I spend a lot of time in the manufacturer's data sheets. I can't remember the last time I saw a MiB, KiB, etc in an official datasheet. Nor do I find them on Stack Overflow, or programming blogs or any other online resource when searching for answers for particularly hard problems. In fact, the only times I can remember is here on WP in talk page discussions arguing about whether to use them. It simply isn't used in the industry to any great extent. Stepho talk 22:55, 25 April 2021 (UTC)
@ Compvis, Jc3s5h, Cybercobra, Woodstone, Greg L, Art LaPella, Seraphimblade, MJCdetroit, Pyrotec, Theaveng, and Cyde: ping'ing editors from the prior discussions since this has apparently turned into a larger discussion. Dondervogel 2 is attempting to use IEC units as disambiguation in articles despite longstanding recommendations being available here at WP:COMPUNITS. My reading is that there are very few exceptions for using IEC, and most are around whether the majority of sources use them or not, and whether or not it's possible to use one of the other methods to disambiguate the terms. Additional input would be appreciated. — Locke Cole • t • c 18:27, 3 May 2021 (UTC)
@ Dondervogel 2: I'm not sure if it was obvious, but this discussion is largely over. COMPUNITS is not changing, and we're not going to be using IEC units in articles. If you persist in attempting to add them in to articles, you may be blocked for disruption as there is clearly no consensus to use IEC in articles, and simply arguing at length until your opponents tire and go away is not "consensus" as you seem to think. I'm going to revert your additions to the various Apple articles. If you re-add them, then the next step will be a visit to WP:AN/I. Stop now. — Locke Cole • t • c 19:41, 14 June 2021 (UTC)
Withdrawing from communication with a tendentious or quarrelsome editor does not give that editor consent to do what they like.
I’ve not once proposed a change to mosnum: yes, you've just wanted to re-litigate IEC prefixes in each and every instance despite the guideline clearly saying they are "not to be used". But sure, you're not trying to change the MOS, you're just trying to ignore it and run roughshod over existing consensus.
Where there is a global consensus to edit in a certain way, it should be respected and cannot be overruled by a local consensus.COMPUNITS is the existing global consensus, stop proposing edits that run counter to it. — Locke Cole • t • c 20:13, 19 June 2021 (UTC)
The articles in question do use mixed prefixes and using inflationary footnotes is impractical, IMHO ( see example). Nonetheless, you keep reverting, and your way of disrupting discussion and replying to arguments at least borders on harassment to me. -- Zac67 ( talk) 07:39, 20 June 2021 (UTC)The IEC prefixes kibi- (symbol Ki), mebi- (Mi), gibi- (Gi), etc., are generally not to be used except [...] in articles in which both types of prefix are used with neither clearly primary, or in which converting all quantities to one or the other type would be misleading or lose necessary precision, or declaring the actual meaning of a unit on each use would be impractical.
when the majority of cited sources on the article topic use IEC prefixes;, or let's ignore that (you guys clearly are), if you really believe the "or" gives you carte blanche to override policies like WP:V and WP:NOR from a guideline (hint: MOS does not have the ability to circumvent WP:V and WP:NOR; you'd still need sources that use IEC prefixes). And of course you also completely ignore
or declaring the actual meaning of a unit on each use would be impractical.. it would not be impracticle to have a footnote with relevent values to inform the reader of the difference using simple, easy to use language like "1 GB = 1 billion bytes" (or use one of the examples for disambiguating provided that do not involve using IEC). I hope using logic and reason here isn't some weird backhanded harassment for you, I wouldn't want you to feel harassed. If I need to do something to make this reply less harassing, please let me know. Maybe I can just let your reply sit for a month and then I'll spontaneously reply to it. That appears to be what passes for perfectly acceptable behavior for you. — Locke Cole • t • c 17:42, 20 June 2021 (UTC)
Apparently, you can't be bothered with facts or policyReally? You suppose the weeks of conversation below were just imaginary? I mean you didn't respond to the print media sourcing, or to the scholarly works commentary, so maybe you just ignore things you don't like? Just because you want to pretend the sky is green doesn't mean I have to play along. As to "facts" and "policy", sure, here you go:
The [...] never use them has been disproven... oh has it? Care to show me where?
You demand scientific sources, ...I did no such thing. In fact, I have no idea why Dondervogel presented scholarly papers, my only theory is that it has something to do with their nearly religious maintenance of User:Thunderbird2/The case against deprecation of IEC prefixes ( | talk | history | links | watch | logs) where they have apparently made it their mission to cling to the notion that usage in Google Scholar visible papers is somehow relevant (I actually don't think they are, I think wider use in the media (print/web/television) is more relevant, as is usage by manufacturers and software companies).
Who's the die-hard here?Uh... is that rhetorical? I've only been involved in this discussion for a few months. Some of you people have been at this for over a fucking decade and won't give up. So... [w]ho's the die-hard here? is not me. I'm just not afraid to call out bullshit. :D I hate to keep saying it, but WP:CIR is still looking more and more relevant. — Locke Cole • t • c 06:48, 21 June 2021 (UTC)
@
Archon 2488: I'm starting to think you haven't read much of this thread. So we're now openly insinuating that the editors who don't agree with this very broad interpretation of verifiability ...
So my alternative choice is to assume Dondervogel 2 is acting in bad faith, not incompetence. However, according to
WP:AGF, I need to assume good faith. So I am. I assume the reason they continue on as they do is because they don't understand what they're talking about. This is a much better assumption than assuming malicious intent. And I note with interest that you have, in your userspace, an essay outlining why "
IEC units are bad" – how's that for a neutral POV?
Wonderful. Dondervogel 2 also has
User:Thunderbird2/The case against deprecation of IEC prefixes, I'm sure this "interests" you as well? Or perhaps not? Also, if you've read my userspace "essay" you'd see it is simply a collection of my arguments from this broader discussion in an easier to digest form.
... regardless of circumstances or context, that anyone who suggests using IEC prefixes in any situation is to be treated as a dangerous crank or an incompetent charlatan.
I mean, those are your words. But after two months, and disruptive behavior from Dondervogel 2 (such as starting multiple forked conversations across nearly a dozen pages now, which I've had to corral back here, where they still insist on fragmenting the discussions anyways even though the topic is largely the same). I've engaged them on their "sources", I've provided counterpoints, and as nobody here seems convinced to take this any further,
WP:COMPUNITS stands. Nothing is going to change, as I said above, and so the status quo, The
IEC prefixes kibi- (symbol Ki), mebi- (Mi), gibi- (Gi), etc., are generally not to be used
stands. Now as to your broader attack on MOSNUM in general, knock it off. A manual of style that helps provide a consistent experience for our readers is something the editors of this project have decided they think is valuable. I'm sorry you think we should be carving out exceptions across the project, but that way lies confusion for both our readers and our editors. We have methods of disambiguation provided, and certainly using other methods is not unacceptable (especially if they match what our sources say), however, using IEC units is not one of those options (except in very specific instances).
I sincerely regret not taking this to AN/I immediately as I was told to do at the start of this thread. I regret taking the time to listen to Dondervogel 2, to consider their "sources", to listen to their arguments, and to try and keep an open mind. Clearly I should have addressed the core behavioral problem before letting this go off the rails for two months, and that mistake is on me. Thanks for making it crystal clear to me now. — Locke Cole • t • c 03:50, 22 June 2021 (UTC)
Now as to your broader attack on MOSNUM in general...I honestly have no idea where you got the idea that I'm attacking MOSNUM, not least because I've participated in many discussions here over the years. I never said anything to the effect of
carving out exceptions across the project; closest I came was vaguely implying I'd be OK with the MOS allowing IEC to be used in a wider scope – and since we already recommend glossing less common units,
Units unfamiliar to general readers should be presented as a name–symbol pair on first use, linking the unit name, I personally think this is unlikely to be as much of a problem for readers as it is for those editors who stridently object to IEC. But as I said before, this isn't a subject I have a huge personal stake in; I do however take it as a good sign when editors who have been less involved in divisive, recurring MOS disputes such as this one feel comfortable to come forward and offer their input. A large part of the problem with yelling accusations of incompetence, Dunning-Kruger, or bad faith, is not so much that it's abusive to the editor directly targeted, but that others who are observing but not actively participating will feel much less inclined to join such a toxic discussion. Hence you end up with an "evaporative cooling" effect in which all but the most stridently opinionated people have left, or left well enough alone.
WP:COMPUNITS is not a licence to introduce ambiguity in any article. I have restored an earlier, stable version of the article so we can discuss the disputed edits since 20 April. Relevant statements include:
The bottom line is that disambiguation is needed. The only question is how. It's hard to satisfy all three requirements, suggesting WP:IAR as the only practical guideline, and disambiguation using the most practical method to hand. What do others think? Dondervogel 2 ( talk) 16:46, 24 April 2021 (UTC)
No. That's not the solution. A Gbit is either 1000^3 bit or 1024^3 bit. At the moment it's both but we need to choose between them. Which is it? Dondervogel 2 ( talk) 09:08, 2 May 2021 (UTC)
@
Tom94022 and
Dondervogel 2:
Quoting the first sentence of
WP:CALC: Routine calculations do not count as original research, provided there is
consensus among editors that the result of the calculation is obvious, correct, and a meaningful reflection of the
sources.
Let's take the requirements one by one:
[…] provided there is consensus among editors […]– seems like an important point;
[…] that the result of the calculation is obvious, correct, […]– no disagreement there, as the IEC units as defined are a drop-in replacement for the classic metric unit names;
[…] and a meaningful reflection of the sources– …and here is where it all falls to pieces, very few reliable sources use these IEC units/prefixes. The vast majority, I'd expect somewhere north of 95% of sources use the classic kilobyte/KB, megabyte/MB, gigabyte/GB, terabyte/TB and so on. And regardless of that, the language here at WP:COMPUNITS has enjoyed consensus for over a decade. It is unacceptable to disrupt editors working to implement our style guidelines because you disagree with the result of the discussions here. If you want to change WP:COMPUNITS, this is the place to hold that discussion. That being said, endless debate because you disagree with what the majority supports is not going to work: Wikipedia does not have a filibuster. — Locke Cole • t • c 16:23, 30 April 2021 (UTC)
[…] or declaring the actual meaning of a unit on each use would be impractical.My edit shows that using {{ BDprefix}} made it possible to declare the actual meaning of each unit. This also keeps it in line with our sources which do not use GiB or MiB or KiB. — Locke Cole • t • c 17:58, 30 April 2021 (UTC)
The appropriate place for this discussion is Talk:Memory_hierarchy#IEC_units where the editors of that article can decide which section of this article is most applicable. Locke Cole is formum shopping by raising it here and any editor having knowledge and interest in application of IEC prefixes to memory hierarchy should comment there. Tom94022 ( talk) 17:40, 30 April 2021 (UTC)
Google query results | |||
---|---|---|---|
Newspaper | site:<URL> "gibibyte" | site:<URL> "gigabyte" | site:<URL> " fatberg" [1] |
usatoday.com | 0 | 745 | 26 |
wsj.com | 1 [2] | 2,890 | 2 |
nytimes.com | 1 | 4,610 | 168 |
nypost.com | 0 | 234 | 130 |
latimes.com | 0 | 1,390 | 5 |
washingtonpost.com | 0 | 971 | 47 |
startribune.com | 0 | 410 | 1 |
newsday.com | 0 | 270 | 0 |
chicagotribune.com | 0 | 952 | 41 |
bostonglobe.com | 0 | 278 | 3 |
Extra entries for fun | |||
seattletimes.com | 0 | 611 | 23 |
seattlepi.com | 0 | 383 | 0 |
International (English-speaking) | |||
timesofindia.com | 0 | 490 | 4 |
metro.co.uk | 0 | 109 | 2,290 |
thesun.co.uk | 0 | 137 | 135 |
dailymail.co.uk | 0 | 710 | 318 |
www.standard.co.uk | 0 | 88 | 17,900 [3] |
mirror.co.uk | 0 | 154 | 170 |
thetimes.co.uk | 0 | 439 | 65 |
www.telegraph.co.uk | 0 | 407 | 72 |
theguardian.com | 0 | 546 | 3,270 [4] |
heraldsun.com.au | 0 | 76 | 26 |
www.dailytelegraph.com.au | 0 | 84 | 45 |
www.couriermail.com.au | 0 | 49 | 34 |
www.smh.com.au | 0 | 1,030 | 29 |
www.theaustralian.com.au | 0 | 364 | 8 |
www.theglobeandmail.com | 0 | 602 | 2 |
www.thestar.com | 0 | 387 | 22 |
nationalpost.com | 0 | 58 | 49 |
No "site:" filtering, just the terms in quotes | |||
213,000 | 72,400,000 | 238,000 |
(In 1997 a standards body tried to clarify things by renaming the binary-derived units as gibibytes, which tells you all you need to know about the usefulness of engineers tinkering with language.)
I may expand this, but as a datapoint I thought it might be interesting to see. — Locke Cole • t • c 15:30, 1 May 2021 (UTC)
If not they are not relevant to the discussion.Sorry, what? In what universe do you think the media-at-large not using the terms you're pushing is somehow not a death-knell for the idea at the outset? And I'll say again, I've yet to see any sources in the articles I've changed which utilized IEC units, let alone any with a ratio of IEC being more prominent than the traditional metric units. Wikipedia is not a platform to push your agenda. — Locke Cole • t • c 19:11, 1 May 2021 (UTC)
Archon 2488 ( talk) 09:36, 14 June 2021 (UTC)The SI prefixes refer strictly to powers of 10. They should not be used to indicate powers of 2 (for example, one kilobit represents 1000 bits and not 1024 bits). The names and symbols for prefixes to be used with powers of 2 are recommended as follows: [tabulated IEC prefixes]
the ones that do disambiguate use IEC prefixesis simply not true. — Locke Cole • t • c 15:32, 7 May 2021 (UTC)
The IEC prefixes kibi- (symbol Ki), mebi- (Mi), gibi- (Gi), etc., are generally not to be used. There are already methods in COMPUNITS to disambiguate that do not involve using IEC units. You're not convincing anyone with this game you're playing at where you fork these discussions (which are largely about the same fucking thing) and then pretend you don't see or choose to ignore conversations that don't go as you wanted. The IEC units are not widely used by our reliable sources, by the media at large, by scholarly works, or by businesses and manufacturers in the industry. Full stop, end of story. I'm done here unless someone besides you says something even remotely compelling. — Locke Cole • t • c 08:08, 9 May 2021 (UTC)
like a moth to the flame I can't resist; so long as you don't set yourself alight because I might still take you up on that hose offer above. Luckily I can see titles and an abstract for the Springer/IEEE links, so really you just need to look at 1) how prominent SDRAM is as a topic to the paper overall (is it mentioned in passing as a dry tech spec, is SDRAM itself actually discussed in great detail, or..?), 2) is the paper using IEC units (KiB/kibibyte, MiB/mebibyte, GiB/gibibyte, TiB/tebibyte, etc) and 3) does the paper also utilize decimal versions of the metric units (KB/kilobyte, MB/megabyte, GB/gigabyte, TB/terabyte, etc). Here's the links in table form, just fill in the blanks:
Link | Title | Authors | 1) SDRAM prominence | 2) Uses IEC units | 3) Uses metric units |
---|---|---|---|---|---|
[4] | LEON Processor Devices for Space Missions: First 20 Years of LEON in Space | Andersson et al, 2017 | Totality of referencex to SDRAM, KB, MB, GB, KiB, MiB, GiB, Kbit, Mbit, Gbitare: *PROM/SRAM/SDRAM memory controller ... 32 MiB PROM ... 32 MiB SRAM ... 512 MiB SDRAM ... 192 KiB on-chip RAM | ||
[5] | BiPS – A Real-Time-Capable Protocol Framework for Wireless Networked Control Systems and Its Application | Engel et al, 2019 | Intel XScale PXA 270 controller with 256 KiB SRAM, 32 MiB SDRAM, and 32 MiB FLASH. It supports clock rates up to 416 MHz | ||
[6] | Implementation Aspects of ProNet 4.0 | Gotzhein, 2020 | Intel XScale PXA271 processor with 256 KiB SRAM, 32 MiB SDRAM, and 32 MiB FLASH ... clock rates up to 416 MHz ... executed from SDRAM ... platform offers 32 MiB flash memory ... provides 256 KiB SRAM and 32 MiB SDRAM ... consumed only about 59 KiB ... 59 KiB static memory and 26 KiB dynamic ... needs at least 140 KiB static and 26 KiB dynamic ... consumes about 350 KiB static and 26 KiB dynamic ... | ||
[7] | An efficient SpiNNaker implementation of the Neural Engineering Framework | Mundy et al 2015 | *32 KiB for instructions and 64 KiB for data; and shares 128 MiB of off-chip SDRAM |
@ Dondervogel 2: At User:Thunderbird2/The case against deprecation of IEC prefixes, which you apparently have religiously updated over the years, there is a Google Scholars link that you use to determine how many articles are using IEC units. I note that currently for the 2020-2022 period there are 582 hits for MiB/GiB. That same search ran with MB/GB returns 44,900. Granted, some of those may be false positives (since MB/GB are more likely to occur as initials for other terms), so for clarity I ran the search using mebibytes/gibibytes and megabytes/gigabytes. There were 28 hits for the IEC unit, and 1,560 for the traditional metric unit. It would seem, even among research papers, that IEC units make up a small fragment, about 1.76%. Metric units accounted for 98.23% of the results. As I've already explained above, the wider media at large does not use the IEC units whatsoever, and their use in academic circles appears to be vastly outnumbered by the traditional metric units. — Locke Cole • t • c 16:06, 3 May 2021 (UTC)
I just stopped Dondervogel 2 ( talk · contribs) from moving yet another conversation here from Talk:SD card. Is there any consensus for having multiple almost identical discussions? When I started this discussion it was with a goal of letting them see if they can convince editors here to change WP:COMPUNITS to allow for more IEC usage. Dondervogel 2 has forked this conversation into separate discussions unnecessarily as the issue is not with these individual articles, but rather with whether or not IEC units are something the editors here feel have reached a point where they should be used in Wikipedia-at-large. After the AN/EW closure I thought we might see some actual discussion, but instead I see Dondervogel has returned to starting forest fires and trying to fork these conversations. So again: Is there any consensus for having multiple discussions here on different articles? — Locke Cole • t • c 17:08, 3 May 2021 (UTC)
Does the discussion about changes to SD card belong at the article's talk page or on MOSNUM? Dondervogel 2 ( talk) 17:30, 3 May 2021 (UTC)
The community has spoken on this issue. Thunderbird2 was without a doubt the most tendentious editor I ever experienced. I don’t know if the fact that years have passed makes this tendentiousness more forgivable or less. The purpose of a general-interest encyclopedia is to communicate clearly. There are many things in the world that should have had better naming conventions, like planetary nebula, which have nothing at all to do with planets, but a general-interest encyclopedia goes with the flow and doesn’t try to effect change in an “Oh, didn’tcha know”-fashion by using unconventional terminology that 99% of our readership has never seen before… all in the vain hope that somehow our leadership might catch on with the rest of the world.
As a general-interest encyclopedia, Wikipedia follows the standard conventions used throughout the dominant bulk of the computer industry. The vast majority of the computer industry, including industry leaders of DRAM like Crucial ( here) Micron ( here) use conventional terminology familiar to every single computer user, from the aficionado to experts. Industry-leading manufacturers of PCs, like Dell here) and Apple ( here) also use conventional technology. If you want to buy DRAM at an online retailer, they are smart enough to use conventional terminology ( Amazon, here). The use of non-standard terminology is confusing and a disservice to our readership.
Why are we even debating Thunderbird2/Dondervogel 2? He’s out in left field tilting at technology windmills. We have better things to do in life than deal with tendentious. Doesn’t Wikipedia have an expedient system to just say “No. Move on”? Greg L ( talk) 05:50, 4 May 2021 (UTC)
You underestimate the usage in the real world.#IEC usage in print media, #IEC units in scholarly writings; and you grossly overestimate their use in the real world. — Locke Cole • t • c 07:48, 7 May 2021 (UTC)
when the majority of cited sources on the article topic use IEC prefixes;as one of the reasons one could conceivably use IEC units. Which I think is reasonable, but in the end, it's just a different way of tackling WP:V and WP:NPOV (specifically, WP:UNDUE). And given the data I've presented above, there seems to be very little use of IEC units compared to the traditional metric units for computing articles, so really it ought to be a moot point. But, here we are... — Locke Cole • t • c 20:53, 4 May 2021 (UTC)
when the majority of cited sources on the article topic use IEC prefixeslooks fine but I fear it's being stretched too far. For example, if the majority of sources on RAM used IEC prefixes, that might justify using IEC prefixes in an article about RAM. But I've found IEC prefixes being used in articles about iPads to say how much RAM they have. There are 87 references for iPad 2. I haven't checked them all but frankly, if someone wants to make the extraordinary claim that most of them use IEC prefixes, they need to produce the extraordinary proof.
I wholeheartedly agree with what NebY wrote. To merely speak about “64 MB” DRAM in an article that is also discussing hard drive sizes does not…
For the most part, it suffices to merely write that Alpha’s XYZ computer had 4 GB of RAM and a 1 TB hard drive but their XYZ-8 computer had 8 GB of RAM. In most cases, the reader really only needs to know—and only wants to know—that the XYZ-8 has twice the RAM.
It is a rare instance that mere mentioning of both attributes within an article requires “disambiguation,” which often really only means “explain the small difference in actual magnitude.” One example that quickly comes to mind is when one is writing about very arcane technical details pertaining to swapping data in and out of a RAM disk. And even then, one can make the technical details perfectly clear while using conventional units of measure that are commonly used in the computer industry and which 999 milliuno of our readership are perfectly familiar with.
Good technical writing is that which is suitable for its intended audience, informs and educates quickly, does so with ease and makes for an enjoyable experience, and does so without drawing attention to itself. Greg L ( talk) 02:14, 5 May 2021 (UTC)
1 TB RAM(implying 10244) and
1 TB HDD(implying 10004) side by side? Mind you, the "small" error is roughly 10 % (1.0244) – the deviance has grown quite a bit since we've used kilobytes and it won't stop there. Also, that ambiguity totally ignores
Do not assume that the binary or decimal meaning of prefixes will be obvious to everyone.-- Zac67 ( talk) 05:11, 5 May 2021 (UTC)
Here are a few examples of the consequences for our articles, for those of us who find it easier to compare examples directly rather than follow a sea of links. They're from recent versions of a rather random selection of articles from this interaction list. These may not represent editors' best efforts, of course.
Article | preferring IEC units | not preferring IEC units |
---|---|---|
X86-64 | This allows up to 256
TiB (248
bytes) of virtual address space.
... this would allow addressing of up to 4 PiB of RAM. etc |
This allows up to 256
TB (248
bytes) of virtual address space.
... this would allow addressing of up to 4 PB of RAM |
WinZip | Beginning with WinZip 9.0, ZIP64 archives are supported, eliminating ... the 4-
gibibyte size limit
[sole instance in this article] |
Beginning with WinZip 9.0, ZIP64 archives are supported, eliminating ... the 4- gigabyte size limit |
SD card | format supports cards up to 128
TiB or 140,737488355328 TB or 140 737 488 355 328 bytes (SI) or 154 742 504 910 672,534362390528 (Binary) and offers
... supports cards up to 2 TiB (2199023255552 bytes) ... but it requires the use of 64 KiB clusters etc |
format supports cards up to 128
TB and offers
... supports cards up to 2 TB (2199023255552 bytes).. ... but it requires the use of 64 KB clusters |
IPad Pro (4th generation) | [infobox] Memory 6
GiB RAM
... the RAM was increased from 4 to 6 GiB on the 128 GB, 256 GB and 512 GB models etc |
Memory 6 GB RAM
.... the RAM was increased from 4 to 6 GB (4-6 GiB) on the 128 GB, 256 GB and 512 GB models |
Synchronous dynamic random-access memory | For reference, a row of a 1
Gibit
DDR3 device is 2,048
bits wide
etc |
For reference, a row of a 1 Gbit [1] DDR3 device is 2,048 bits wide |
References
Over at the talk page for Template:Quantities of bytes ( | talk | history | links | watch | logs) in the section Recent Edit to Table the discussion has somehow switched to how JEDEC memory units are being given undue weight in the template (despite the presence of IEC units which, as shown above in media and scholarly use, are basically non-existent in sources or the wider media-at-large). Interested editors may wish to chime in there; I didn't initially move the discussion here because it started out innocently enough as a discussion about whether or not JEDEC terabyte should be in the table, but now the discussion has taken a turn to whether or not JEDEC units belong at all... I'm personally of the opinion that the IEC units are the ones being given undue weight, and we're effectively pushing a fringe theory by even giving them this much life outside of the IEC standards article(s), but more opinions would be appreciated. — Locke Cole • t • c 16:42, 5 May 2021 (UTC)
Why are the capacities in the thumbnail descriptions given in powers of 1000 (or 10x where x is an int), e.g MB, GB, TB, while elsewhere they are in powers of 1024 (or 2x where x % 10 = 0), e.g MiB, GiB, TiB? I'm concerned because as the capacities increase, esp for TB vs TiB and PB vs PiB, the difference in bytes is huge.
Fezzy1347 ( talk) 17:12, 25 May 2020 (UTC)
Let me point out one example of the problem I see.The case you cite is a blatant failure to wp:think of the reader. Any given article should use the initialism with just one and only one meaning throughout. (IMO, it also should have a comment note that advices future editors of that choice – I thinking of something like {{ use DMY dates}}.) In the exceptional case where both meanings are needed,
Locke Cole is now back-tracking and claims he doesn't care where the discussion is held- I've done no such thing. Stop lying. — Locke Cole • t • c 21:16, 14 May 2021 (UTC)
The GiB notation has never gained acceptance and Wikipedia cannot assume that readers (and many editors) have ever even seen it, let alone know what it means.That remains my position. This notation does not solve your
example of the problembecause readers will not know what it means, any more than if you had suggested we use the Chinese character. The only practical solution is to spell out abbreviations clearly: if we mean 1,073,741,824 then that is what we should say. What we must not do in the same article is have GB mean 109 in one sentence and have it mean 230 in the next sentence. -- John Maynard Friedman ( talk) 23:22, 14 May 2021 (UTC)
This is the correct place to discuss it. It is a problem that comes up in many computer related articles, so thrashing it out in a single article's talk page will just make it a discussion that has to be repeated for each and every article - what a waste of time!
To summarise the problem (using GB in the examples but also applying to the other prefixes): some uses of GB (giga bytes) means 10^9 and some mean 2^30. Some editors prefer to:
The short explanation is that memory this is directly addressable by the CPU (eg RAM, ROM) uses powers of 2 while practically everything else uses powers of 10 (eg hard drives, thumb drives and anything to do with rates or time). It is the directly addressable part that is critical. For RAM or ROM the CPU has to provide a certain number of binary address lines, so the size must be a power of 2. For devices that have some type of interface (eg IDE/PATA, SATA, USB), the address is sent as a number within a command. The remote device is free to remap that address in any way that it feels fit (eg, hard drives mapped a single address into cylinder, head, sector and the CHS numbers were usually not powers of 2), so the address is not constrained to powers of 2. This is anecdotal but based on my 3-4 decades of professional experience designing/programming computers.
Trying to explain to explain this in every computer article will just clutter up every article. Instead, I suggest that most articles are just left in the ambiguous state. After all, most readers don't really care about a 7% difference - most readers don't even know or care how much RAM their PC or phone has, only that it has enough. The people that care tend to already know when to use 10^9 or 2^30. But some articles that cover a broad topic like RAM, hard disk, or SD Card can spell out the appropriate form (or forms if it needs to specify capacity in powers of 2 and rates in powers of 10). Stepho talk 01:54, 15 May 2021 (UTC)
This article by the editor of Macworld explains the storage capacity of iPhones, iPads and iPods, and leads with "What is the true formatted storage capacity of an iPhone, iPad or iPod - how many songs, films, apps and games can they hold? And why is the true capacity lower than the advertised figure?". To make himself clear the author uses GB to mean 1000^3 B and GiB to mean 1024^3 B. The introduction to the article reads
128GB: approx. 114GiB 64GB: approx. 56.5GiB 32GB: approx. 27.5GiB 16GB: approx. 11.5GiB
The article was cited in several Wikipedia articles, but it seems to have been removed. I suggest reinstating the reference because it helps to explain the storage capacity in a language WP readers can understand. Dondervogel 2 ( talk) 08:19, 30 May 2021 (UTC)
It is a fool's errand to try to nail the exact size down. Which size are you after?
For the most part, user don't care about the exact number - as long as it is in the ball park. Stepho talk 02:43, 20 June 2021 (UTC)
References
Wikipedia strongly prefers secondary sources, so objecting because something is not a primary source is no kind of argument that WP entertains. — SMcCandlish ☏ ¢ 😼 14:24, 30 July 2021 (UTC)
Somewhat related to all of the above, but apparently a small group of editors has decided that the JEDEC definitions of kilobyte, megabyte, gigabyte, etc. are "deprecated" based on a poor reading of the definition here. See {{ Quantities of bits}} and {{ Quantities of bytes}}, and the discussion at Template talk:Quantities of bytes. It's relevant here because {{ Bit and byte prefixes}} which is included in WP:COMPUNITS and is similarly designed, also contains a "JEDEC" header. — Locke Cole • t • c 17:32, 21 June 2021 (UTC)
[t]o give false information intentionally with intent to deceive.) is a problem for them, but the proof is in the diffs where they've repeatedly misrepresented the truth for their own ends: [18] [19] (notwithstanding the claims of consensus for "deprecating" units without actually having consensus, or the distortion of reality one has to live in to push IEC units like they do). — Locke Cole • t • c 15:07, 30 June 2021 (UTC)
Right, this has gone far enough and is getting unhealthy. I've made an ANI post about it. Archon 2488 ( talk) 15:29, 30 June 2021 (UTC)
Currently two-digit ending years allowed in two consecutive years, however I believe that this should be clarified for recurring events such as sport (example 2019–20 UEFA Champions League). Not for a single event ( Indonesian mass killings of 1965–66 & 2019–20 coronavirus pandemic (before moved to COVID-19 pandemic)), because it looks ambiguous. Hddty ( talk) 03:31, 21 August 2021 (UTC)
In the line 0123 notation for octal is unclear. In prose use 1238. If needed for computer code samples, explain the prefix on first use.
, what is "the prefix"? If it's meant as a reference to the 8 at the end of 1238, that's not a prefix but something more like a suffix. (Judging by
the computing sense of prefix, "123" could be described as a prefix, but if this is what is meant, it could be expressed more intelligibly by using another phrase like "explain the notation".)
Our article says octal can be indicated by "a variety of prefixes, including the digit 0, the letters o or q, the digit–letter combination 0o [...as in] 073, o73, q73, 0o73", but if the guideline is meant as an exhortation to explain those on first use, it should actually mention one of them, IMO.
-sche (
talk)
01:32, 9 August 2021 (UTC)
"For octal, the prefix 0 is unclear (0201) and other prefixes may be unfamiliar; avoid using a prefix unless it is needed for computer code samples, in which case explain the prefix on first use. In prose, use the subscript 8 (2018) or avoid octal entirely as a crime against nature."?
There is a discussion at Wikipedia:Administrators' noticeboard#Cleaning up stale general sanctions on a proposal to revoke authorisation for sanctions including Wikipedia:General sanctions/Units in the United Kingdom. NebY ( talk) 17:51, 1 September 2021 (UTC)
MOS:ERA currently has the following wording:
BP or YBP: In scientific and academic contexts, BP (Before Present) or YBP (years Before Present) are often used. (Present in this context by convention refers to January 1, 1950.) Write 3000 years BP or 3000 YBP or 3000 years before present but not forms such as 3000 before present and 3000 years before the present. If one of the abbreviated forms is used, link to Before Present on first use: The Jones artifact was dated to 4000 YBP, the Smith artifact to 5000 YBP.
Why does it use capitalization in "BP (Before Present) or YBP (years Before Present)" but not in "Write ... 3000 years before present"? It seems that a large portion of scientific literature does not capitalize this term in any context, so according to MOS:CAPS, the first sentence should use the lower case as well ("BP (before present) or YBP (years before present)"). I've nominated the article Before Present to be renamed to Before present based on these considerations, but this was met with a strong opposition from several editors, although they've failed to provide substantial evidence (see the discussion). Could anybody here help them to prove that it must be capitalized? Or we should indeed switch to the lower case? — Mikhail Ryazanov ( talk) 20:25, 10 August 2021 (UTC)
Capitalising the term Before Present in keeping with its initialism is perfectly normal— MOS:EXPABBR disagrees, saying "Do not apply initial capitals ... just because capitals are used in its abbreviation". Mitch Ames ( talk) 04:57, 11 August 2021 (UTC)
as concept in its own right— MOS:CAPS says "capitalization is primarily needed for proper names", not "... concept in its own right". If you mean "proper name" (which has an entire article tells us what it means, so we know) it would probably be better to say so. Inventing new terms (that are not in MOS) probably won't help the discussion. Mitch Ames ( talk) 12:30, 11 August 2021 (UTC)
@ Mikhail Ryazanov:, if you look at the dates example, the MOS says this:
Phrases such as Fourth of July (or July Fourth, but not July 4th), Cinco de Mayo, Seventh of March Speech, and Sete de Setembro are proper names, to which rules for dates do not apply (A typical Fourth of July celebration includes fireworks).
Note how the example of correct usage doesn't wlink Fourth of July. (Otherwise it would imply that every time you write the phrase "Fourth of July", you should link it?) The point of the MOS is to recommend (sometimes strongly) how text should be written; when to apply a wikilink is in a different cookie jar. So I think that the answer to your question is that the MOS as it stands is correct and consistent with the way that similar rules of the MOS are written. Of course if your RtM succeeds, the article reference will need changing. Does that help? -- John Maynard Friedman ( talk) 18:28, 11 August 2021 (UTC)
References
Earlier this month, Daniel Case changed the syntax of The Exorcist's RT approval rating from "83%" to "83 percent", citing MOS:%. Later, when I updated the Rotten Tomatoes data on the film, I changed it back to the percent sign for two main reasons:
Frankly, I don't see why the suggestion in MOS:% should supercede the standard set by Wikipedia's film articles, especially given that MOS:% merely says that use of the word percent in non-scientific articles is common, not that it should be used. We should allow the shorter character to keep carrying the score. Songwaters ( talk) 01:10, 20 August 2021 (UTC)
So apparently there is a dispute about quarterly dates in MOS:DATEFORMAT and MOS:DATESNO:
The initial addition was made as the result of this discussion at Help talk:Citation Style 1. As I said there, I don't think that the addition here is appropriate because cs1|2 does not determine how dates in article text are to be formatted. cs1|2 has adopted MOS:DATE as its standard for date formats. Help:Citation Style 1 § Date compliance with Wikipedia's Manual of Style lists the parts of MOS:DATE with which cs1|2 does or does not comply. In the table there, the format of quarterly dates, not previously specified here, is defined. For cs1|2, that is all that is required so the quarterly date specification here is not required unless or until it becomes necessary to specify a quarterly date format for article text. The addition to MOS:DATEFORMAT and MOS:DATESNO should be reverted.
— Trappist the monk ( talk) 17:47, 29 August 2021 (UTC)
First Quarter 2020may be appropriate for citations, it's certainly not appropriate for general article text, which strengthens the idea that it doesn't belong in this guideline at all.So it seems to me that the mention at Help: (linked by Trappist above) is exactly the right place to touch on this. Second choice (distant second choice) would be something in 2.5, as mentioned. E Eng 20:49, 29 August 2021 (UTC)
@ EEng: What is inappropriate about quarters? I understand the reason for avoiding seasons whenever possible as they are so ambiguous, but working in quarters in very common in the business world. Hawkeye7 (discuss) 04:20, 30 August 2021 (UTC)
Jul–Sep 1952, not Q-something. Though it occurs to me that might be misinterpreted as an unusually difficult labor. E Eng 11:36, 30 August 2021 (UTC)
Wikipedia:Categories for discussion/Log/2021 March 3#Category:10¼ in gauge railways in England decided to keep the precomposed fraction in that title. That discussion has a list of categories with precomposed fractions (collapsed) all of which are either about railroads (under e.g. [[:Category:Track gauges by imperial unit) or Ranma ½, except Category:The 2½ Pillars of Wisdom and Category:Lil' ½ Dead albums.
There are lots of articles that have precomposed fractions in the title which MOS:FRAC says should do something else in the body, for example:
ASCII vulgar fractions seem rare in article titles, but I did find 1/2 + 1/4 + 1/8 + 1/16 + ⋯. It appears 1/16 is not available as a precomposed Unicode character.
On Talk:Ranma ½#Fraction in page title we discussed ways to use DISPLAYTITLE to make an ASCII fraction title consistent in appearance with {{ frac}}, which is how the current MOS guidance indicates the title should be rendered in body text, like so: "Ranma 1⁄2". I've done this at Draft:Ranma 1/2 and it seems to work. (FTR, with "{{DISPLAYTITLE:{{NAMESPACE}}:Ranma <sup>1</sup>/<sub>2</sub>}}", in case the draft is deleted again.) An alternative proposed in that discussion was to simply leave the title as "Ranma ½" with a precomposed fraction. That raises the question of whether the MOS should be changed to make the article body consistent with the title.
Considerations:
I'm not sure what the best reconciliation is, and if there are other considerations or opinions worth mentioning, so I'm starting a discussion here. To get things started, here are some possibilities:
I think 2A would be the easiest to implement; we're already most of the way there. The other options for 2 require "if X then Y else Z" rules, which make it considerably more difficult to automate compliance.
-- Beland ( talk) 23:28, 9 September 2021 (UTC)
OK, so if that gets moved to "Spin-1/2", here's a stab at taking into account the other comments above and what Graham87 mentioned on Wikipedia talk:Manual of Style/Mathematics#Accessibility of precomposed fraction characters - it sounds like we don't care to impose any particular style on non-science/math articles, but that only some precomposed fractions are screenreader-friendly. If so, then maybe a small note in the section applicable to science/math articles, changing:
1/2
to something like:
1/2
(and this style should be used for article titles like
Spin-1/2)and a broadening of the chess exception to general guidance, changing:
½
½
to something like [edited to spell it "screen reader"]:
½
½
References
?
This would mean, for example, that the existing title Naked Gun 33⅓: The Final Insult is not OK and I think would have to be moved to Naked Gun 33 1/3: The Final Insult? That also looks like a problem for Category:4 ft 10⅞ in gauge railways, though that seems to be the only problematic category. -- Beland ( talk) 07:44, 11 September 2021 (UTC)
I published this statement and it got reverted: "Figures and numbers tend to be more easily understood than words by non-native English speakers." and my brief summary was: "maybe not the best place but this fact must be stated in a quite visible place in MoS!".
I didn't think it was a substantive edit to the page, nor it should reflect "formal" consensus. It could just have been moved at the most appropriate place on the page!
This is obvious for people who read in a language other than their mother tongue: "the reading of numbers as words needs translation for understanding", while "the reading of the figures and numbers allows an instantaneous comprehension without possible error (as most parts of the world use Arabic numerals)"
Unless you speak German, if you switch to [ de.wikipedia.org], the only things that you will understand instantaneously are years and figures/numbers. If you speak German, try switching to Finish: [ fi.wikipedia.org], Danish...
Obviously some editors want bureaucracy. — Antoine Legrand ( talk) 12:43, 16 September 2021 (UTC)
An IP range has taken it upon themselves to change date formatting for a large number of European BLP's and topics. Rather than getting into an edit war with them I wanted to seek some clarification. There seems to be a grey area between what is being implied in MOS:DATETIES that date format's should only changed based on ties to an English speaking country, rather any date format associated with every country. Given this, it seems that MOS:DATEVAR applies which states we shouldn't be changing pre-existing formats for an article? Do we want this to continue and should such changes be discouraged? Seddon talk 14:24, 11 September 2021 (UTC)
"we follow European date formats ... The European date format is date month year". I see no discussion of that on the talk pages there and no attempts to edit it since that style page was written in 2008. Perhaps we should simply add the WP:DATERET principle to it. NebY ( talk) 15:52, 11 September 2021 (UTC)
The question and discussion above both seem to ignore a point that needs clarification itself: Why does
MOS:DATETIES refer to English-speaking? What does the language have to do with the date? Shouldn't DATETIES say, Articles on topics with strong ties to a particular English-speaking country should generally use the date format most commonly used in that nation? I'm probably missing something, but we're not going to use septembre instead of September, so the date format, ISTM, is entirely independent of the language. Right? Canada's a bit tricky, but we can decide on a case-by-case basis if there are strong regional ties to, say, Montreal or Quebec (suggesting dmy) or just go with dmy in general for all strong-tied Canadian topics. Why do we need to specify "English"? —
JohnFromPinckney (
talk /
edits)
17:56, 11 September 2021 (UTC)
I doubt such a presumption would work ...They are the existing guidelines. Feel free to establish a new consensus. Incidentally, English being an official language of India, Indian preferences could be applied to related articles.— Bagumba ( talk) 01:29, 19 September 2021 (UTC)
restrain the American format to "American topics may use MDY. Everyone else should use DMY" +- ISO . . .Seems reasonable. Though using the ISO format with English does seems a bit awkward but I don't mind it that much. And since you brought it up, we need to identify when exactly the US military format (DMY) comes into effect and takes precedence over the American MDY format. Does it follow the year of adoption? Is it limited to military vehicles? What about military relations and exercises between the US and other countries? What about the wars that the US has been involved in? These are just some of several such questions that would need to be considered. - Rajan51 ( talk) 20:18, 19 September 2021 (UTC)
Isn't the ISO format YYYY-MM-DD, not DD-MM-YYYY? The former is what I use whenever I remember to give a damn (although I will admit I'm not very diligent about it). Another thing I do sometimes is writr out dates like "2021 Sep 19", so that it is obvious what I mean to hamburger, leaf, and lime alike. jp× g 21:50, 19 September 2021 (UTC)
were documented in MDY, and are described in that format in most published sources. We use our MOS, not anyone else's, to determine whether a date should be a certain format. Izno ( talk) 23:30, 19 September 2021 (UTC)
then they can use DMY, don't you mean MDY??? E Eng 00:11, 20 September 2021 (UTC)
I sure wish we'd never gone down this TIES path at all. Look, let's remember the basic principles of ENGVAR (my paraphrase):
I don't think we ever really needed the special case. It shouldn't be too hard to get consensus to change the spelling of colour in Abraham Lincoln. But the arguments on this exceptional carve-out have grown to dominate the conversation as a whole. Let's not repeat the error with date formats. -- Trovatore ( talk) 17:11, 20 September 2021 (UTC)
that the proposed "guideline for all articles" requires deciding what an "American topic" isThis already happens under the current guideline. Izno ( talk) 20:09, 20 September 2021 (UTC)
. . . That way everyone got something . . .Clearly non-British and non-Americans didn't get anything.
. . . we are not fucking going to make that a debate on every single article all the time -- is John von Neumann a Hungarian article, or American? . . . Under your plan we have to argue about it . . .Nope. He's not strongly and solely tied to
Clearly non-British and non-Americans didn't get anything.– I was hoping you'd say that, and you walked right into it. What I said is
those up in arms could feel they'd both won something ... that way everyone got something. What was needed was to bring peace among the superpowers on an issue that doesn't substantively matter anyway. Creating hundreds of new, additional debates doesn't bring any more peace (in fact the opposite), and since the issue doesn't substantively matter anyway, it doesn't improve anything else either. So not only a net negative, but an absolute negative.
If there are strong ties to two countries, we default to the DMY format. It's that simple.– Uh, no actually, and thus we find that your inexperience, and consequent misunderstanding of the rules, disqualifies your from participating intelligently in this discussion.
the equivalent of causing the destruction of the world– It's not consequence that's equivalent (or analogous, anyway), it's the idiocy (since you force me to come right out and say it).
. . . What was needed was to bring peace among the superpowers on an issue that doesn't substantively matter anyway . . .It matters just as much to anyone else as it does to Britons and Americans. Just because they were the only ones up in arms, does not mean English-speakers from all other countries can be ignored.
. . . Creating hundreds of new, additional debates doesn't bring any more peace . . .The proposed rules only reduces debates. When an article (such as United Kingdom–United States relations or John von Neumann) is strongly tied to more than one country, we revert to the DMY format. There is no need for a debate over which format should be used.
. . . consequent misunderstanding of the rules . . .In case it was not obvious enough, I was talking about the new proposed rules that has been mentioned above, not the currently existing rules. - Rajan51 ( talk) 04:34, 21 September 2021 (UTC)
References
that the variety of English and the date format used in a country are unrelated in most cases", but I think we could reasonably consider the date format to be a part of "the variety of English". WP:ENGVAR says "... date formatting (September 20, 2021 vs. 20 September 2021) is also related to national varieties of English". Mitch Ames ( talk) 23:33, 20 September 2021 (UTC)
. . . I think we could reasonably consider the date format to be a part of "the variety of English" . . .I guess you could in the UK or the US. Most other countries use different hybrids of the two varieties, so a universal direct relationship between the variety of English and the date format used would be hard to make. It would be simpler to just keep the date format an independent issue, which is what MOS:DATETIES does and it states: For any given article, the choice of date format and the choice of national variety of English are independent issues. - Rajan51 ( talk) 07:30, 21 September 2021 (UTC)
DMY for American articles and DMY for the rest proposal will spawn endless debates about whether a tenuous link to America is enough to flip it to MDYAssuming you meant MDY for American articles, the proposed guideline is that an article can use MDY provided it is strongly and solely tied to the US. If an article is strongly tied to the US and at least one other country, we switch to the DMY format. - Rajan51 ( talk) 06:07, 22 September 2021 (UTC)
. . . for using both depending on circumstances . . . not for using the DMY system exclusively as was suggested above.In case you did not read the full discussion, the proposal is to use the DMY format for all pages except when an article is strongly and solely tied to the US, in which case the MDY format will be used for the article. This clearly means we would be using both formats depending on the circumstances of national ties. - Rajan51 ( talk) 17:39, 22 September 2021 (UTC)
Our usual philosophy when we have multiple styles is not to pick winners and losers but rather to allow variation as long as everything is consistent within each article.That does not seem to be the usual philosophy since winners and losers are already being picked, as the existence and implementation of MOS:DATETIES shows. The rationale behind the proposed change is to ensure articles related to countries that are not covered under the current MOS are not left out and to ensure the removal of the existing bias. - Rajan51 ( talk) 18:56, 22 September 2021 (UTC)
"we should be more concerned 'English Wikipedia readers' (our audience), not 'English language speakers'" ... [sez who?]— says WP:PURPOSE, WP:AUDIENCE, WP:RF, WP:READER.
And 40% [does not equal] 0%— 40% (from the US) is less than the 60% who are not from the US. Mitch Ames ( talk) 01:48, 23 September 2021 (UTC)
they have their own wikis, are by definition bi-lingual at least (most English speakers speak only English and can't go to another wiki)– this is a massive oversimplification. It neglects that, other than the major-language Wikis (French/German/Russian/Spanish etc – and often even these), most other-language WPs are orders of magnitude smaller, both by pages and depth of content, than en-wp. Certainly when it comes to topics that are not primarily related to that specific language/country/culture. So it's not remotely uncommon for speakers of English as a second language to use en.wp as their primary WP; for example, I recall reading a social media post by a Lithuanian guy I follow, saying that pretty much the only time he looked at lt.wp was to find information about Lithuania-related topics he couldn't find on en.wp (and then, the topic was typically obscure enough that he often couldn't find it even there). South Asian and African countries are great cases in point – only a tiny minority of Nigerians or Indians speak English as their L1, but a huge proportion of Nigerians and Indians use English extensively, in exactly the sort of use cases that an encyclopedia caters for. Archon 2488 ( talk) 11:43, 23 September 2021 (UTC)
... I'm not seeing that as telling me "Well, for let's say the date of the discovery of a comet, obviously we are going to use DMY". Herostratus ( talk) 13:48, 23 September 2021 (UTC)
Regarding this edit, is there any consensus on hyphenating non-adjectival fractions? The Chicago Manual of Style has "Simple fractions .... are hyphenated in noun, adjective, and adverb forms. ... She has read three-fourths of the book", etc., and WP articles largely seem to follow that format (e.g., "two-thirds of the population," "two-thirds of reported infections," etc.). However, some online style guides recommend no hyphen for noun fractions ("do not hyphenate fractions used as nouns", "when the fraction is serving as a noun, there is no hyphen," etc.)—which could create occasional ambiguities ("The pianist played two thirds", "He drank two fifths", etc.). If there is consensus on hyphenating fractions used as nouns, I'd suggest expanding the example at MOS:FRAC to read "Spelled-out fractions are hyphenated: seven-eighths of a book, a seven-eighths share" or simply changing the text to always hyphenated. (This would also have the advantage of not requiring editors to parse out whether a particular fraction is nominal or adjectival.) Thanks. Doremo ( talk) 13:22, 27 September 2021 (UTC)
{{#invoke:ConvertNumeric|numeral_to_english|37}}
→ thirty-seven{{#invoke:ConvertNumeric|numeral_to_english|12|numerator=2|denominator=3}}
→ twelve and two-thirdstwo fifths of cheap bourbonis an unfortunate example for this discussion because, in that context (involving bourbon of any grade), the two fifths isn't a fraction any more than two quarts is a fraction in
two quarts of milk. E Eng 02:03, 28 September 2021 (UTC)
Anyhow, back to the original question: MOS:FRAC currently seems to indicate that all spelled-out fractions should be hyphenated with no exception mentioned for function (adjectival, nominal, etc.): "Spelled-out fractions are hyphenated: seven-eighths." Should this be made more explicit (e.g., "All spelled-out fractions are hyphenated: seven-eighths." or "Spelled-out fractions are hyphenated regardless of function: seven-eighths." or "Spelled-out fractions are hyphenated: seven-eighths, seven-eighths of a book, a seven-eighths share.") to clarify what seems to be both actual practice and already general WP practice? Or is the current phrasing clear enough? (Or is ambiguity and editorial preference preferred?) Doremo ( talk) 06:52, 28 September 2021 (UTC)
In my opinion, when an article is written in American English, whenever a conversion is given the American measure should be given first, in prose, and the conversion should be given second, in parentheses. Vice versa when written in another English variety. In terms of best practice, I don't remember ever seeing it done differently, until recently. My questions are: what, if anything does the MoS say about this? And: if the MoS were to say something about it, what do others think it should rightly say, if anything? Perhaps it's a matter of style to be left to an editor's discretion, or perhaps there is a best practice that ought to be followed. I am curious to see what others have to say. Thank you.-- John Cline ( talk) 14:03, 9 October 2021 (UTC)
The Arbitration Committee has ruled that editors should not change an article from one guideline-defined style to another– editors would sometimes insist that this means because two styles might both be permissible in the abstract, they were therefore both permissible for any specific article, and thus changing between them (even when one was explicitly favoured by the MOS and the other was proscribed, in the relevant context) was impermissible. I wonder if it might be worthwhile to insert an explicit clarification somewhere in WP:UNITS or MOS:CONVERSIONS that rules such as WP:ENGVAR and WP:RETAIN don't apply here? Archon 2488 ( talk) 17:47, 9 October 2021 (UTC)
every computer program has its regional settings for a user, with date format, measuring units. above @ Sdkb: responded on "format of date tags should be a user property, not a server property" that it is a Wikipedia:Perennial_proposals. would have some links where such a setting in the user preferences was discussed, for both, data format, as well as units of measurment metric vs imperial? -- ThurnerRupert ( talk) 06:08, 25 October 2021 (UTC)
<br>
and 1 July 1999</i>
- ie some trailing HTML tags require a comma and some require no comma.created a phabricator task to provide a test with persons heights as a personal preference: https://phabricator.wikimedia.org/T294707. -- ThurnerRupert ( talk) 17:45, 31 October 2021 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
The premier league states the height of its players in metric, see
this example, but in the english wikipedia this will be switched via flip,
Max Aarons as example again, referring to
MOS:UNIT. Can we please remove or add a couple of workds in
MOS:UNIT to avoid this flipping? --
ThurnerRupert (
talk)
20:39, 15 October 2021 (UTC)
where does this consensus come from @ Archon 2488:? intuitively if i read feet in a piece of text it does not look so strange as an author has his style. but in tables, or in WP infofoxes it looks weird, as you barely see it. -- ThurnerRupert ( talk) 18:32, 16 October 2021 (UTC)
thanks a lot everybody for the excellent insight, which made me smile a lot sometimes, much appreciated!! coming back to the original question, do i interpret the outcome of the discussion correctly: 5 people do not mind make a proposal to ammend MOS:UNIT to allow metric for footballers (@ Archon 2488:, @ NebY:, @ John Maynard Friedman:, @ Dondervogel 2:, ThurnerRupert), and 1 person is not favourable (@ Kahastok:)? if so, how is the process? -- ThurnerRupert ( talk) 20:58, 17 October 2021 (UTC)
@ NebY:, a game? the link you sared is hilarious, "how brits measure" :) :) if you write "don't you see how unrealistic it is even if it would be desireable?": does this mean you desire it or you don't? -- ThurnerRupert ( talk) 16:49, 20 October 2021 (UTC)
as there is no more input, lets close this thread and make a real proposal which allows to vote for, and against. -- ThurnerRupert ( talk) 07:31, 23 October 2021 (UTC)
change the manual of style, dates and numbers, UK related section Wikipedia:Manual_of_Style/Dates_and_numbers#Unit_choice_and_order, in the following way:
the reasoning and arguments are given above, and in the manual of style itself. in scientific contexts as well as statistical contexts, presenations in lists and tables, presentation in the UK follows the UK standard, even for personal heights. in running text both variants, imperial and metric, do exist and are proven over time. the proposal aims to let tables conform to standard, and not touch the proven way to write text in wikipedia. votes can be basted with "support" "oppose". no comment, or other comments are counted as "i do not care". -- ThurnerRupert ( talk) 07:31, 23 October 2021 (UTC)
Would writing the six-digit number "250,000" as "250 thousand" be considered acceptable per MOS:NUMERAL? It does seems to be a "format" used quite a bit project wide, but that doesn't necessarily mean it should be being used. Would "Two hundred fifty thousand" or "Twenty-five hundred thousand" be preferable instead? How should this be treated when dealing with ranges of numbers? Is "250 thousand to 2.5 million" acceptable? Would "250,000 to 2.5 million" or "250,000 to 2,500,000" be better? My question has to do with some wording used in the lead of Eurasian eagle-owl. It was changed from "250 thousand to 2.5 million" to "250,000 to 2.5 million" which seemed odd to me. I reverted the change, but it was contested. I self-reverted since I may have been wrong, but still would like some other opinions on the matter. -- Marchjuly ( talk) 23:11, 24 October 2021 (UTC)
Integers greater than nine expressible in one or two words may be expressed either in numerals or in words). NebY ( talk) 23:53, 24 October 2021 (UTC)
Well, I've had some sleepless nights wondering if I was too quick to add something addressing a problem which might not qualify as a MOS-worthy under the criteria I originated: WP:MOSBLOAT. Here's the new text -- thoughts?
In the specific case of thousands, there are few if any situations in which e.g. 5 thousand or 250 thousand would be preferable to 5000, 5,000, or 250,000. [Link to footnote]
[Footnote:] And positively don't write 5 hundred or 25 hundred thousand.
Again, I'm only belaboring this because I'm usually the MOSBLOAT tsk-tsker and I don't want to seem like a hypocrite. E Eng 23:30, 27 October 2021 (UTC)
In the specific case of thousands, there are few if any situations in which e.g. 5 thousand or 250 thousand would be preferable to 5000, 5,000, or 250,000. And I think I (who added it) am going to remove it, per MOSBLOAT. It's not that I think it's overprescriptive -- if this became a recurring fight among editors, MOS should tell them what to do i.e. don't write 5 thousand -- but I see no evidence of that. There's a very small number (in the scheme of things) uses of such yukky forms project-wide, and adding something to MOS isn't going to fix that, because those editors probably aren't looking at MOS.Also: [28]. E Eng 17:23, 31 October 2021 (UTC)
Right at the top the question is kind of answered: " It does seems to be a 'format' used quite a bit project wide, but that doesn't necessarily mean it should be being used" I mean, yeah it does? Rules codify general behavior, so you can't have a rule prohibiting what editors have 'voted with their feet' for. That's not how it's supposed to work.
As to "I do personally find mixed numerical-verbal number formats as you describe stylistically needlessly clunky". Fine that you do personally not write that way.
Again with "My question though now has to do with all of the cases where '250 thousand' is currently being used in articles. Should these be cleaned up? If 'all the cases' means a lot of cases, then no, you wouldn't be cleaning them up, you'd be imposing by fiat your preferred format on other editors work. ˙ʎʇɹıp ʎllɐnʇɔɐ ǝɹ,ʎǝɥʇ ssǝlu∩ In which case yeah. And if just a few cases, then that too is different. That means that those are outliers and common-accepted-practice is not to do that. In which case, a rule to codify that is OK. If it happens enough to need a rule then I'd have to wonder, though. — Preceding unsigned comment added by Herostratus ( talk • contribs) 23:39, 31 October 2021 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Hi all! I've noticed that many articles for more obscure United States topics lack date tags, which results in them defaulting to the ugly YYYY-MM-DD format (e.g. 2021-10-17).
MOS:DATERET permits changing the format when a topic has strong national ties to the topic
, so I've been running an AWB task recently to add {{
Use mdy dates}} to any article that's in a subcategory of
Category:United States (to 3 levels) and does not already have a date format tag. It seems to be working well, so I'd like to seek consensus from you all to convert it to a task for my bot.
The initial list of articles that will be affected is here. From my checks, almost all of these are U.S.-related. There are a few exceptions from times where the category tree is broken or weird edge cases (e.g. Lake Saint Francis (Canada), a lake in both the U.S. and Canada), but there's no real harm done in those (MDY will be an improvement over YYYY-MM-DD and anyone who wants to switch to DMY can easily do so). Overall, I think this task will improve lots of U.S.-related articles by converting them to the date format American readers generally expect. Thoughts? {{u| Sdkb}} talk 23:32, 17 October 2021 (UTC)
the ambiguous abomination that is the stylistic atrocity of "5/12/19" should be utterly forbidden.— It is, by MOS:BADDATE. Mitch Ames ( talk) 12:18, 18 October 2021 (UTC)
I've been running an AWB task recently to add {{ Use mdy dates}} to any article that's in a subcategory of Category:United States": DO NOT DO THIS. Some of us use and prefer variant styles that are nevertheless consistent with both the MOS and US date conventions (such as the style discussed in the link given above by EEng) and take drive-by efforts to change date formats from our preferences to something else with great hostility. The MOS says not to change consistent date formats without consensus. Adding {{ Use mdy dates}}, even to an article on a US topic in which some of the dates are formatted as mdy, can be a change of a consistent date format. Unless your AWB script is smart enough to recognize and correctly tag these variations (and I'm betting it isn't) you should not be using AWB to do this. If you are editing by hand and are capable of distinguishing consistent formatting that mixes mdy/ymd (yes, that is a thing) from inconsistent formatting, and only want to tag the inconsistent ones, then that's less problematic, but I don't think that AWB and the level of care needed for this tend to go together. — David Eppstein ( talk) 08:20, 20 October 2021 (UTC)
I was reading an article where a fraction was rendered as three separate characters for something as simple as 1/2 and 1/4. This does not seem right to me and frankly looks absolutely hideous. From an accessibility perspective, I suspect that screen readers will also be able to do a much better job of reading ¼ vs. 1⁄4.
This policy seems to be around a decade old at this point and web browser (and other client) support for the full Unicode set has dramatically improved since it was written. Is it time to revisit it? — lensovet– talk – 22:11, 4 November 2021 (UTC)
The note currently reads:
t or troy must be specified where applicable. Use oz avdp or lb avdp only where there is risk of confusion with troy ounce, imperial fluid ounce, US fluid ounce, or troy pound; but articles about precious metals, black powder, and gemstones should always specify avoirdupois or troy.
Does any object my revising this to read
the qualifier t or troy must be specified where applicable. Use oz avdp or lb avdp only where there is risk of confusion with troy ounce, imperial fluid ounce, US fluid ounce, or troy pound. Articles about precious metals,
coins,black powder, and gemstones should always specify which type of ounce (avoirdupois or troy) is being used, noting that these materials are normally measured in troy ounces and grams.
(bold just to highlight proposed changes). -- John Maynard Friedman ( talk) 20:23, 6 November 2021 (UTC)
I would repeat my personal view that when such confusing and ambiguous units as "ounces" are used, disambiguation should always be a priority, and a correct conversion into real units should always be provided. There have been about as many different kinds of ounces (tower measure, anyone?) as there have been coins. Archon 2488 ( talk) 23:37, 6 November 2021 (UTC)
Generally, conversions to and from metric units and US or imperial units should be providedand I don't think anyone has argued that this should not apply in this case. If there's anything that needs adding to this, it is to point out that the most "real" unit for precious metals is the unit used by the international markets and in most physical sales, i.e. the troy ounce. I would certainly agree that any weight measurement for precious metals needs to include a conversion into troy ounces. Kahastok talk 15:20, 7 November 2021 (UTC)
Use oz avdp or lb avdp only where there is risk of confusion with troy ounce, imperial fluid ounce, US fluid ounce, or troy pound, so may I request that we go no further up this blind alley? Or does it need to say
Use the qualifier avdp only where there is risk of confusion with troy ounce, imperial fluid ounce, US fluid ounce, or troy pound? [comments please].
noting that these materials are normally measured in troy ounces and grams. -- John Maynard Friedman ( talk) 15:40, 7 November 2021 (UTC)
Assuming that silence signifies assent, I have made this change (with this diff). -- John Maynard Friedman ( talk) 14:11, 10 November 2021 (UTC)
Question raised by User:Melbguy05 User:I dream of horses So we had a discussion also involving other editors about an article Mr Cruel /info/en/?search=Talk:Mr_Cruel#U.S._dollars_or_Australian_dollars about events wholly in Australia. Australia, like the U.S., uses a currency they call the "dollar." The question was whether the article should mention that reward amounts are in Australian dollars. The consensus seems to have been that it should. However, Manual of Style mentions that, "In articles entirely on EU-, UK- and/or US-related topics, all occurrences may be shortened (€26, £22 or $34), unless this would be unclear." So the question is why should an article about events wholly in Australia mention that dollar amounts are in Australian money, but an article about events wholly in America doesn't have to mention that dollar amounts are in American dollars? Greg Dahlen ( talk) 12:10, 7 October 2021 (UTC)
nobody is going to think, in a purely Australian context, that an arbitrary amount quoted in "dollars" (or "$") with no clarification refers to USD rather than AUD– That's if they're aware that Australia even uses dollars. E Eng 18:56, 9 October 2021 (UTC)
Australia and NZ renamed their respective currencies from "pound" to "dollar"— Australia did not rename the currency, we changed it. The dollar as a different currency with a different value. Mitch Ames ( talk) 23:31, 10 October 2021 (UTC)
unless context indicates otherwise– here we are explicitly discussing an Australian context, in which I would default to presuming (per the practice of relevant reliable sources, like any Australian publication) that a "dollar" is an Australian dollar, not an American one. Or do you think that the Sydney Morning Herald feels the need to reassure its readers that the prices it quotes are not in US dollars? I would tend to lean towards using ISO currency codes or some other form of unambiguous notation, regardless. It is clear from this discussion alone that different people have very divergent perceptions of what our readers will presume is meant in a given context. And across the board, I am strongly opposed to context-specific disambiguation – i.e. an editor taking it for granted that a reader will make the same assumptions about what, say, a "dollar" is that they do, then finding out in short order that that is not the case, because different people focus on different information in constructing their picture of what the context is. Archon 2488 ( talk) 17:51, 10 October 2021 (UTC)
If there is no common English abbreviation or symbol, follow the ISO 4217 standard.(emphasis added). E Eng 20:34, 10 October 2021 (UTC)
Why doesn't first mention of U.S. money have to have "US" put in front of it?(and the inline text in the original inquiry:
...but an article about events wholly in America doesn't have to mention that dollar amounts are in American dollars?) I mentioned the Apple source in passing as it appears to support the idea that businesses even within Australia disambiguate the AUD from USD. — Locke Cole • t • c 21:35, 10 October 2021 (UTC)
References
Currently, the #Specific units table reads, in part:
Group
|
Name | Symbol | Comment |
---|---|---|---|
Volume, flow
|
|
|
US or imperial (or imp) must be specified; fluid or fl must be specified for fluid ounces and US units, except with gallon. (Without fluid, ounce is ambiguous – versus avoirdupois ounce or troy ounce – and US pint or US quart are ambiguous – versus US dry pint or US dry quart.) |
I would argue that the requirement to specify fluid for U.S. pints and quarts is unnecessary, given that everyday usage of dry pints and quarts - even in the United States, where I live - is essentially nonexistent (as a matter of fact, I didn't even know that dry pints and quarts existed before reading this table, and have literally never used them). Any American seeing US pt or US qt will immediately think of the liquid measure, and, in the rare cases when we do need to refer to dry pints or quarts, they can be explicitly specified as such (much like how, for U.S. measures of weight, we use generic pounds vs. troy pounds, rather than avoirdupois pounds vs. troy pounds). As such, I propose the following modification to the row of the table dealing with U.S. and imperial fluid measures:
Group
|
Name | Symbol | Comment |
---|---|---|---|
Volume, flow
|
|
|
US or imperial (or imp) must be specified; fluid or fl must be specified for fluid ounces. (Without fluid,
ounce is ambiguous versus avoirdupois ounce or troy ounce.)
In the rare case that one needs to refer to the U.S. dry pint or quart, dry must be specified, and the difference between the dry pint and quart and the fluid measures of the same names should be explained in a footnote upon first use (as even U.S. readers are highly unlikely to be familiar with the dry units). |
Thoughts? Whoop whoop pull up Bitching Betty ⚧ Averted crashes 05:42, 28 October 2021 (UTC)
different reference temperatures for volumes of gasoline– I can hardly believe that. E Eng 14:55, 28 October 2021 (UTC)
Group
|
Name | Symbol | Comment |
---|---|---|---|
Volume, flow
|
|
|
US or imperial (or imp) must be specified; fluid or fl must be specified for fluid ounces. (Without fluid,
ounce is ambiguous versus avoirdupois ounce or troy ounce.)
Unless otherwise specified, US pt and US qt refer to the liquid measures of those names. In the rare case that one needs to refer to the U.S. dry pint or quart, dry must be specified. Link to Pint#US dry pint or Quart#US dry quart (depending on which is being referenced) on first use. |
Whoop whoop pull up Bitching Betty ⚧ Averted crashes 21:39, 28 October 2021 (UTC)
We still have 'US fl pt' recommended for the liquid pint. Shouldn't that be changed to 'US liq pt'? Dondervogel 2 ( talk) 10:50, 6 November 2021 (UTC)
Based on the above, I've made the following edit: [30].
Gills, minims, scruples, bushels, drams / drachms and the rest of the zoo have similar issues (e.g. When necessary to distinguish the avoirdupois dram from the apothecaries dram, or to distinguish the avoirdupois dram or ounce from the fluid dram or ounce, or to distinguish the avoirdupois ounce or pound from the troy or apothecaries ounce or pound, the word “avoirdupois” or the abbreviation “avdp” should be used in combination with the name or abbreviation of the avoirdupois unit.
) But please let's not tackle those now.
I invite one and all to carefully check what I say above, and my edit. E Eng 17:52, 6 November 2021 (UTC)
This is bizarre!
So which is correct? -- Shmuel (Seymour J.) Metz Username:Chatul ( talk) 13:29, 7 November 2021 (UTC)
Do we have any evidence that either "liquid pint" or "fluid pint" are commonly used in the US? We seem to have various British editors here assuming that Americans must need clarification, which may underestimate the intelligence of Americans and the power of US English norms.
Indeed, do we even have any evidence that when fruit, for example, is sold by the pint it usually or even commonly has to be stated as a dry pint? I have tried a Google ngram for "a dry pint of strawberries" and "a pint of strawberries", and also for blueberries, but received no results for the dry phrasing. [31] Then I reduced it to simply comparing "a dry pint" - of anything, I don't care - with "a pint of strawberries" and "a pint of blueberries", and found any use at all of "a dry pint" is now vastly rarer than either of those. [32] NebY ( talk) 17:27, 10 November 2021 (UTC)
While this article has guidance to not spell out numbers in sports scores and vote tallies (in the “Notes and exceptions” list under “Numbers as figures or words”), it does not have any guidance to use en dashes with them. However, it seems to be a well established convention to use en dashes with them, and the sample sports score in the above referenced text uses an en dash, too, albeit without explicitly calling out that fact.
I’d therefore like to either add a “Sports scores and vote tallies” section following “Number ranges”, or append guidance to “Number ranges” and change its title to “Number ranges, sports scores, and vote tallies”. The guidance could be simply something along the lines of the following:
Separate sports scores and vote tallies with an en dash:
Using single-digit scores and tallies in the above examples would also implicitly reinforce the guidance from the other section to always use digits and not spell out single-digits in these contexts.
SixSix ( talk) 19:54, 18 November 2021 (UTC)
While looking for guidance for how to format a non-base 10 number the other day, I ran across the guidance here. I found it to be unwieldy and made some copy edits for brevity and clarity. I thought my edits were non-substantive but my edit was reverted with the suggestion that I discuss it here first.
Here were my beefs:
Let me know what you think, thanks
SixSix ( talk) 20:10, 18 November 2021 (UTC)
{{
base}}
(eg 2008), which seemed to be warmly received and it was actually mentioned directly in the MOS. Then it was removed from MOS and now nobody knows of it. :(Example: 15.38 km instead of 15.382 km
For one thing, with metric units you might as well replace it with "15,382 m" since its giving the exact same amount of detail.
More importantly, plenty of countries use , and . the other way around (, for decimal places and . as a separator for thousandths), and with three digit precision there is a potential for easy misunderstand when one isnt careful.
When a number is large enough that it is given in Kilometers there rarely is a point in stating its length exact to the meter, or a number in tons to the exact Kilo and so on. Most of the time rounding to the next integer or just having one decimal place is probably sufficient anyway, so I can't think of a case were having two instead of three decimal places would cause significant problems. I wont go so far as to propose using a bot to truncate every number in every article, but adding it as a preferred style to the manual wouldn't hurt. For context: Decimal_separator#Examples_of_use jonas ( talk) 01:13, 17 November 2021 (UTC)
round to an appropriate number of significant digits; the precision presented should usually be conservative. Precise values ... should be used only where ...appropriate to the context. Mitch Ames ( talk) 02:31, 17 November 2021 (UTC)
is there a reason why the example used to illustrate the usage of floruit (fl.) does not have a spaced en dash?
the last point in the mos:approxdate section notes that spaced en dashes should be used when "fl." appears in a range, "whether on one or both sides", and i can't seem to find an applicable exception for this example. had the point explicitly stated "whether on the right or both sides", i would have understood the lack of a spaced dash, but that is currently not the case. dying ( talk) 06:53, 16 April 2021 (UTC)
1571–1588
bind to each other first, and the fl.
applies to them as a unit: fl. 1571–1588.In contrast, in c. 1588 – 1622, the c.
applies (presumably) only to the 1588
, so we move the latter a bit away from the 1622
so as to put it in closer visual association with the c.
.
E
Eng
08:00, 17 April 2021 (UTC)
r. c. 1353–1336 BC | or | r. c. 1353 – 1336 BC |
fl. 12 BH–AH 10 | or | fl. 12 BH – AH 10 |
traditionally 1585– c. 1590 | or | traditionally 1585 – c. 1590 |
Ravenpuff, i agree that the recent changes are reasonable, but i don't think they are consistent with the previous guidelines. i am not sure if this is the case, but i think we are currently disagreeing on whether the previous guidelines would have called for a spaced en dash in the original floruit example. i believe the previous guidelines would have called for a spaced en dash, while your comment has led me to believe that you believe the previous guidelines would have called for an unspaced en dash. if so, i would like to understand why we disagree, but i wanted to determine if that was actually the case.
by the way, i also share your confusion over the behaviour of the floruit template when two arguments are provided, as i mentioned in footnote [f]. the behaviour appears to have been introduced when code was copied from the circa template at the time, [i] as mentioned in the edit summary of the floruit template edit, and i don't know if retaining that behaviour was intentional. [j] however, i agree that it's consistent with both the previous and current guidelines.
in any case, whether the current guidelines are consistent with the previous guidelines was not why i had proposed two solutions to what i believe is an ambiguity problem. do you agree that the guidelines, as they currently stand, are ambiguous? if so, do you have any suggestions regarding how to resolve the ambiguity? if not, then could you explain how the en dashes in the three examples above are spaced (or not spaced) according to the current guidelines, and why? dying ( talk) 23:00, 18 June 2021 (UTC)
x. | x. 1571 | x. 1571–1588 | x. 1571 – 1588 | 1571 – x. 1588 | x. 1571 – x. 1588 | |
---|---|---|---|---|---|---|
1. | c., after | ![]() |
![]() |
![]() |
![]() |
![]() |
2. | fl., r. | ![]() |
![]() |
![]() |
![]() |
![]() |
3. | trad. | ![]() |
![]() |
![]() |
![]() |
![]() |
Ravenpuff, it recently occurred to me that it might be simpler to draft the proposal first, and then edit it together if there are any disagreements, as with blurbs on tfar. i have reproduced below what i believe are the relevant bullet points of the guideline, with the original text first and my proposed text following. note that this reply consists of two edits, so that (hopefully) a diff will be able to show what the proposed changes are. some of the comments in the code have also been modified, so looking at the diff may provide more information than simply comparing the visible text below.
of course, for this to work properly, i'm obviously giving permission to edit the proposed text below, waiving any tpo concerns. also, if you feel that any additional bullet points should be addressed, feel free to add them as well. dying ( talk) 17:59, 5 October 2021 (UTC)
original text:
{{
snd}}
) is used. For example:
[[Floruit|fl.]]
, or {{
fl.}}
may be used:
{{snd}}
) and ideally a non-breaking space should follow very short modifiers such as c.. Examples: 1896 – after 1954,
c. 470 – c. 540. Markup: 1896{{snd}}after 1954
, {{c.|470|540}}
.
proposed text:
{{
snd}}
) is used. For example:
[[Floruit|fl.]]
, or {{
fl.}}
may be used:
{{snd}}
).
1896{{snd}}after 1954
, 470{{snd}}{{c.|540}}
, {{c.|470}}{{snd}}540
, {{c.|470|540}}
.here is a link to the initial revision. there is a lot of formatting that could probably be improved, but i tried to emulate what was already present so that we could focus on the content differences first. i don't have any significant preferences regarding the formatting, so i will probably be happy with whatever you choose if you decide to change any of it.
i ended up removing "after" from the introductory sentence of one of the bullet points because i felt that it was possible to use "after" to apply to a range as a whole, such as in "the minister held the office during the 2025–2030 term, so could not hold it again until after 2030–2035 due to term limits". (that bullet point's "after" example still applies, though, so i left it there.) feel free to restore "after" to the introductory sentence if you feel otherwise.
by the way, if one does not treat the '−' (the minus sign, not a dash or hyphen-minus) used in astronomical year numbering as a modifier, then the range "−10–10" appears to be appropriately formatted. this is not ambiguous, but is this desirable? we could consider "−" to be a modifier of the first category, but i hesitate to do this because the '−' seems, at least to me, to be an integral part of the number "−10" rather than a modifier, much like the '0' is. i also do not think it would be appropriate to have a non-breaking space follow the '−', like one generally does with very short modifiers. dying ( talk) 18:04, 5 October 2021 (UTC)
Notes
Hey everyone. So a big big big debate issue that has been going on for over 2 years is whether 2021–present can be used (in 2019 it was 2019–present, in 2020 it was 2020–present, and if this continues next year, it will be 2022–present etc.). Soap operas used to use just a dash e.g. (2009– = since 2009), but over the past 2 years this was changed to –present. Several editors have said that 2021–present is wrong as 2021 is the present. However, myself and several other editors really do not agree with putting just "2021" as it looks like that event/character/appearance etc took place only in 2021 and has finished/is expected to finish in 2021, and also because sometimes pages are not updated at the end of the year and so it looks like it is giving wrong information. This also goes against other pages that are not soap opera related (for example, at the Duke of Edinburgh page, in the Third Creation area, it says that Prince Charles has been Duke of Edinburgh "2021–present"). In some soap opera articles, I changed "2021" to "Since 2021" to clarify that the characters have been appearing since 2021, rather than just appearing in 2021, but some are also against this. I think 2021–present is very acceptable as yes, 2021 is the present, but February 2021 is not the present etc, and even the beginning of December 1st is not the present either. Although in an ideal world, I would much rather prefer just "2021–" as it was much more simple and created less clutter (also going through the Wikipedia discussions from years ago on this page it seems that many editors disagreed with it in general).
Sorry for the long message, but in a nutshell, we need to decide whether 2021–present is okay to be used and, if not, what alternative we can use (e.g. "Since 2021").
I vote in favour for using "2021–present" or preferably allowing editors to use simply "2021–" DaniloDaysOfOurLives ( talk) 19:13, 1 December 2021 (UTC)
{{
Infobox_automobile}}
, which states "If production started in any year prior to the current year and is still ongoing, 2008–present
, et cetera, is the preferred style. However, 2021–
is preferable to 2021–present
while we are still in 2021." So both forms are allowed but the shorter form is preferred.
Stepho
talk
10:57, 2 December 2021 (UTC)The article cites as a good example: "Typically, 1-naphthylamine is synthesized via the Feldenshlager–Glockenspiel process. Or: Feldenshlager–Glockenspiel is the process typically used in the synthesis of 1-naphthylamine."
The first one is OK, but the second one is ungrammatical. It should be written as "The Feldenshlager-Glockenspiel process is the one . . ." As a rule, scientific texts don't refer to processes, reactions, etc., that way; eponyms are used as adjectives ("Diels-Alder adducts are"), but not as stand-alone nouns ("Diels-Alder is the best way . . ."). Samer ( talk) 18:05, 16 December 2021 (UTC)
3SAT is a variant of SATis just too common nowadays, and widely accepted. And such forms are quite different from
50 soldiers were killed.E Eng 16:45, 18 December 2021 (UTC)
It would be useful if the comment column of #2.2.1 Formats included a comment and example following "2 September 2001" to the effect that in British English (used in the UK, Australia and elsewhere) commas aren't used unless required by the sentence's grammar and an example such as "On 13 May 2007 Daniel was born." https://www.grammarly.com/blog/how-to-write-dates/. There are many articles with dates in British English style but with unnecessary commas. — Preceding unsigned comment added by Mcljlm ( talk • contribs) 08:14, 18 December 2021 (UTC)
I've looked through the whole MoS for Wikipedia, and I haven't found a specific section or article explaining how to format time. Does Wikipedia have set rules for this? For example, if I want to say that a song lasted 3 minutes and 48 seconds, would I format the duration as "3:48" or "3m 48s"?
User:Jale1162 ( talk) 21:06, 21 December 2021 (UTC)
I'm thinking that "1400s" is better than "15th century" in text.
I was a grown man before I was I was facile with the notion that 18th century referred to the 1700s. To this day I usually do a little mental stutter-step to translate "8th century" to the 700s and so on. And I went to college (well, for a bit). Maybe you don't, Dear Reader, but there's a whole lot of people who aren't as smart and literate as you.
We do not have a rule about this that I can find here. But all the examples use "XXth century", except for one which says "When using forms such as the 1900s...". And I think "XXth century" is much more common in text. I don't want a rule, and I don't think every discussion here has to be about making another rule. I'm just thinking that writing "1500s" instead of "16th century" is more clear to more people (in contexts where "1500s" is clearly not meaning 1500-1509), and editors might want to consider this. Herostratus ( talk) 20:53, 18 December 2021 (UTC)
"1500s" means 1500–1509, which quite surprises me. I would never come to that conclusion as a first assumption (although I can see it, the same way I can decide to translate left-handed pipe wrench as a wrench for left-handed pipes). I suppose if I read that somebody or something flourished in the early 1700s, I should interpret that to mean from 1700 to 1703 or so? That's not the way I'm used to thinking about this form. — JohnFromPinckney ( talk / edits) 01:36, 19 December 2021 (UTC)
"1400s" is better than "15th century" in text. ... To this day I usually do a little mental stutter-step to translate "8th century" to the 700s and so on.Stepho responded
I would recommend avoiding that usage, which I was trying to support by demonstrating that (for example) "1800s" and "1900s" would not clearly mean entire centuries and would also demand effort from the reader. Indeed it seems you would not take them to mean entire centuries either. NebY ( talk) 23:44, 19 December 2021 (UTC)
This form of art movement started in the 19th century. DaniloDaysOfOurLives ( talk) 06:05, 19 December 2021 (UTC)
Herostratus has become an eponym for someone who commits a criminal act in order to become famousor more recently, someone who starts a new section at WT:MOSNUM to watch it burn. NebY ( talk) 01:20, 21 December 2021 (UTC)
two connected events that occur in the wee hours of the day that daylight saving time ends... We need a rule for this— Actually, we have one: MOS:TIMEZONE - "... the time zone in which an event took place has since changed ... show the UTC or offset appropriate to the clock time in use at the time of the event". Mitch Ames ( talk) 01:46, 21 December 2021 (UTC)
Really either is non-excellent. "XXth century" is difficult, "XX00s" potentially confusing. I do think that "the latter half of the 1400s" can be quite clear in context, eg "The first edition was printed in 1423, the second in 1437, and several in the last half of the 1400s", for instance. But yes, there can't be a hard and fast rule. Herostratus ( talk) 01:19, 21 December 2021 (UTC)
@
EEng: To answer the question you asked in the edit summary of
this revert ("is there any evidence that our elite cadre of abstract algebra editors need this guidance?"): The question presupposes that only editors who are familiar with abstract algebra are affected. I was actually cleaning up math notation project-wide for compliance with
MOS:BBB and happened to convert some fraction slashes to horizontal fraction bars because that appeared to be the only notation permitted by
MOS:FRAC inside <math>...</math>
. Another editor pointed out the convention in this subfield was fraction slash only. I thought it would be helpful to note this exception so that in the future editors making articles compliant with MOS:FRAC know enough to check if the topic is related to
quotient objects. Otherwise we'd be relying on watchlist editors carefully reading diffs with messy math markup to catch the sort of mistake that I made. --
Beland (
talk)
00:25, 28 December 2021 (UTC)
When updating isotopes of element pages, in this case isotopes of hydrogen (though this question applies to any and all of them), I'm having difficulties determining how many significant figures to represent in the data tables. I had a short discussion with User:MeasureWell regarding this issue, and we decided to ask for second opinions here because there isn't a clear guideline in the MOS for this.
The lists of isotopes are sourced to {{ NUBASE2020}} and {{ AME2020 II}} (or earlier versions, such as 2003 or 2016), though apparently the sources themselves are not internally consistent. The PDF for AME2020 II gives most values with 6-7 significant figures (bar exceptions that are known to such high precision) and 1-2 (occasionally 3) digits of uncertainty, which have been in widespread use on WP. However, I was directed to a web/txt version of NUBASE, where there is one file congruent to the PDF giving "rounded" values ( [36]) and another giving about 3 more digits in "exact" values ( [37])
The problem is that both are supposed to be the same source, yet the "exact" values sometimes have at least 4 digits of uncertainty, which is bad practice in data analysis and renders the extra precision nearly useless. Furthermore, the same file gives mass excess values in energy units to about the same number of significant figures as the "rounded" masses, so I'd also think that a straight unit conversion (E=mc2, adjusted for units) should not introduce additional precision. Keeping smaller relative uncertainties also allows a much more concise and meaningful representation of the data. Taking hydrogen-4 as an example, we have 4.026431867(107354) u "exact" vs. 4.02643(11) u "rounded".
I'm inclined to stick to the latter "rounded" values for these reasons, as it seems to better follow general practice and not clutter data tables with meaningless digits, though I'm unsure if a case can be made for a possible loss of precision (less sure because of the large relative uncertainty) Whatever the general preferred practice is, could it be codified in MOS to encourage more consistent and meaningful data representation and resolve such discrepancies? ComplexRational ( talk) 01:48, 30 December 2021 (UTC)
You are invited to join the discussion at
Talk:Keiji Nishikawa § Date format. --
Marchjuly (
talk)
12:45, 22 January 2022 (UTC)
Hello.
This is exactly as weird as it sounds. After reverting three (different) edits by me, a user claims that I have to seek consensus for edits intended to make the article adhere to MOS.
It would be detrimental to the project if editors had to seek consensus to edits intended to implement MOS on every single article.
Please add your two cents here: Talk:List of Girl Meets World episodes#Proposal to adhere to the Manual of Style in the article.
Thank you.
HandsomeFella ( talk) 20:21, 17 January 2022 (UTC)
My apologies in advance for bringing drama to this otherwise drama-free zone. I am looking primarily for a link to a previous discussion, but I have been unable to conjure the right search terms for use in the archives of this page.
Srich32977 has been asked many times on their User talk page to stop replacing page ranges like "807–813" with "807–13", and they have consistently responded that MOS:NUMRANGE does not apply to the text that they are changing. The text of that MOS section looks clear to me, but I will defer to the guidance of the more experienced MOS-heads among you. A link to a detailed previous discussion or RFC on the issue would be helpful. Thanks in advance. – Jonesey95 ( talk) 22:29, 13 January 2022 (UTC)
There is much discussion throughout Wikipedia on the use of IEC prefixes. I didn't know until today about the difference between k and K. (Traditionally K was sometimes used when only upper case was available. I believe K is often used for resistors.) Often in articles, numbers are written with excessive Sigfigs, and I suspect including for computers. kiB/kB is only 2%, and by GiB/GB is 7%, but often enough that is still more precision than is needed. Also, I believe we are allowed to give less precision than the WP:RS when precision isn't needed for the article. I think that means that I agree with the suggestion not to use IEC prefixes most of the time. Gah4 ( talk) 23:29, 4 February 2022 (UTC)
A few minutes ago, I made this edit to the unit-specific guidance for knots, with the intent of reducing the potential for ambiguity in instances where more than one type of airspeed is referred to in a single section. Dondervogel 2 reverted, requesting that I open a discussion in talk regarding the proposed changes. Hence the following, with no ill will intended against Dv2:
Group
|
Name | Symbol | Comment |
---|---|---|---|
Length, speed
|
|
Used in aviation contexts for aircraft and wind speeds, and also used in some nautical and general meteorological contexts. When applied to aircraft speeds, kn means KIAS unless stated otherwise; if kn is used for calibrated airspeed, equivalent airspeed, true airspeed, or groundspeed, explicitly state and link to, upon first use, the type of speed being referred to (for instance, kn equivalent airspeed, or, if severely short of space, kn EAS); for airspeeds other than indicated airspeed, the use of the specific abbreviation for the type of airspeed being referred to (such as KEAS) is preferred. When referring to indicated airspeed, either kn or KIAS is permissible. Groundspeeds and wind speeds must use the abbreviation kn only. |
Group
|
Name | Symbol | Comment |
---|---|---|---|
Length, speed
|
|
Used in aviation contexts for aircraft and wind speeds, and also used in some nautical and general meteorological contexts. When applied to aircraft speeds, kn means KIAS unless stated otherwise; if kn is used for calibrated airspeed, equivalent airspeed, true airspeed, or groundspeed, explicitly state and link to, upon first use, the type of speed being referred to (for instance, kn equivalent airspeed, or, if severely short of space, kn EAS); for airspeeds other than indicated airspeed, the use of the specific abbreviation for the type of airspeed being referred to (such as KEAS) is preferred. When referring to indicated airspeed, either kn or KIAS is permissible. If knots are used to describe multiple different types of airspeed in a single section, the type of airspeed being referred to in each particular case must be specified (either by using the specific abbreviations for each type of airspeed or by spelling out the full long form of the type of airspeed in question) unless the context makes absolutely clear, in every instance, what type of airspeed is being referred to; even then, it is strongly encouraged to explicitly state the type of airspeed being given (this is also strongly encouraged, although not absolutely required, if different types of airspeed are mixed within an article but not within any specific section). Groundspeeds and wind speeds must use the abbreviation kn only. |
Thoughts? Whoop whoop pull up Bitching Betty ⚧️ Averted crashes 22:59, 30 January 2022 (UTC)
I'm seeing this arcane unit of measurement pop up, for instance with Underground line articles. Chains, not miles, that is. What gives? Why is Wikipedia retrograde here? The conversion template even admits chains is not commonplace or familiar to the readership? Let us not be cute, let us stop this movement to use chains immediately. CapnZapp ( talk) 20:52, 28 January 2022 (UTC)
I too could not find any conclusion. Perhaps the proponents of this obscure units just kept talking until everybody else tired of opposing. (See Sealioning). How about a much simpler proposal?
Cheers CapnZapp ( talk) 12:27, 31 January 2022 (UTC)
According to
Metrication in the United Kingdom#Road and rail transport, Standards relating to the design and building of new road and rail vehicles have been metric since the engineering changeover in the 1970s.
[1]
and specifically London Underground has converted to using metric units for distances but not for speeds.
[2]
HOWEVER chains were used when all but the most recent lines were built so translation continues to be needed: whether the original measure should be displayed is a different debate. There is only becomes a problem when
metric martyrs want to 'translate' modern engineering specifications back to these obsolete measures. --
John Maynard Friedman (
talk)
00:17, 1 February 2022 (UTC)
I'm going to list a few things that I consider self-evident.
{{
convert}}
a lot more than I trust most editor's arithmetic.Points that are up for discussion:
Comments? Stepho talk 11:45, 1 February 2022 (UTC)
According to Metrication in the United Kingdom#Road and rail transport,-- John Maynard Friedman ( talk) 18:03, 4 February 2022 (UTC)
Imperial units have been retained for both road and railway signage except on new railways. What else do you want? The difference between "measured in metres and converted to miles and chains and displayed as such" and "measured in miles and chains" is entirely academic and of no practical relevance. As far as we know, the distances are given in miles and chains, and that's the unit which the railway does use (plus, speeds limits on British railways [and roads] are also in MPH, so that makes total sense). RandomCanadian ( talk / contribs) 18:43, 4 February 2022 (UTC)
I suggest that this discussion be closed as there is not the slightest possibility of a consensus for change. No doubt The Colonel could put it more succinctly. -- John Maynard Friedman ( talk) 20:47, 4 February 2022 (UTC)
This appears to be a classic case where our decision process breaks down when a topic is discussed mostly by the people most interested in said topic. That is, people that does not necessarily realize that what is best for the technical experts might not be for the general public. It is obvious to me the value of Wikipedia is lessened by having rail station articles include archaic and obsolete units of measurements as if that was a reasonable thing to do. It is actively user hostile (compare the kibi disaster that thankfully was averted in the end). That a unit of measurement is used by specialists in the field should be entirely irrelevant for a project like Wikipedia, and had this topic been visited by a representative selection of editors, I am sure the voices in support for presenting this unit to an unsuspecting public would have been drowned out entirely. My conclusion is that the only path forward is to devote enough time soliciting comments from elsewhere, and I'm sorry - I don't feel like it. Instead this will be a case of "you deserve each other". Thanks to those seeing that "the UK rail industry uses this" and "for historic reasons" are really really bad reasons when we're discussing non-technical articles of general interest such as rail station articles. CapnZapp ( talk) 07:48, 14 February 2022 (UTC)
I don't agree that we need to state chains in the articleJust as a heads-up: I am going to assume you meant to say "I do agree with you CapnZapp we don't need to state chains in the article". Just clarifying since I am arguing the exact opposite of what you appeared to ascribe to me. Cheers CapnZapp ( talk) 08:52, 14 February 2022 (UTC)
It is obvious to me the value of Wikipedia is lessened by having rail station articles include archaic and obsolete units of measurements as if that was a reasonable thing to doWhy? Even if it were true that chains are "archaic" and "obsolete" (they are neither, being in active, every day use) it is not at all obvious why including them in a Wikipedia article would "lessen the value" of that article. When a subject uses was built to units that, unlike chains, are no longer in every day use we still include them where it is relevant. Is the Great Pyramid of Giza article's value lessened by it giving the dimensions in royal cubits? Is the Bromsgrove article lesser for noting "The town appears to have been founded as a series of plots of sizes between two and four rods (10 and 20 m), marked out along the current High Street."? Thryduulf ( talk) 10:22, 14 February 2022 (UTC)
the authorities use chains?); the following is the London North Western route specification from Network Rail which states on page 8:
“ | This secondary urban route leads in an easterly direction from Manchester to Mirfield via Rochdale, with another route diverging to Stalybridge, via Ashton-under-Lyne. The former crosses the London North Western/London North Eastern boundary at 22 miles 62 chains on MVN2 just west of Hebden Bridge. [5] | ” |
But I would consider this a primary source, however, Network Rail use miles and chains in all their documentation. Publications such as Rail Magazine, Trackmaps etc, ie secondary sources, also all use chains where necessary, and in Trackmaps, every station is listed from a fixed zero point in miles and chains (see images here). The chainage is particularly relevant in crash/accident articles, when the RAIB issue their reports. They do so in miles and chains when necessary, because that is how the distances on UK railways (apart from HS1 and HS2) are measured. The example given here is due to the check rail having a curve radius of "10 chains or less". [6] However, not all RAIB accident reports use chains, they do so when required, which is why I do not advocate deprecating the chains and getting rid of them completely. Chains are also used as a measure of wildfires in the USA! Strange, but that's how they do it. The problem here is in the rounding, which can be quite inaccurate. Regards. The joy of all things ( talk) 10:05, 14 February 2022 (UTC)
Swindon railway station is on the Great Western Main Line in South West England, serving the town of Swindon, Wiltshire. It is 77 miles 23 chains (77.29 mi; 124.4 km) down the line from the zero point at London Paddington.
Swindon railway station is on the Great Western Main Line in South West England, serving the town of Swindon, Wiltshire. It is a little less than 80 miles (125 km) west of London Paddington.
"In the chainage notation traditionally used on British railways, it is 77 miles 23 chains (77.29 mi; 124.4 km) down the line from the zero point at London Paddington".
"In the chainage notation traditionally used on British railways, it is 77 miles 23 chains (77.29 mi; 124.4 km) down the line from the zero point ...This is just a rod (or four) for our own back. Cinderella157 ( talk) 12:48, 18 February 2022 (UTC)
References
"an up-to-date metric guide" (para 1.2)
I'm monitoring a disagreement regarding date formats in US space articles. MOS:DATETIES supports an article such as STS-47 ("the 50th NASA Space Shuttle mission") using mdy dates. However, Wikipedia:WikiProject Spaceflight/Style guide included the advice "Dates should be in day-month-year format" for many years apparently due to a NASA style guide which includes "full dates should be in a day-month-year format". The wikiproject guide was updated on 11 January 2022 to remove the advice to use dmy with a discussion at project talk. That discussion includes claims that the NASA style guide is for certain historical documents and is contradicted by recent NASA publications which use mdy. The project talk points out that a local consensus about date formats cannot overrule site-wide conventions so I'm afraid the ball lands here.
Should STS-47 use dmy or mdy? The quick answer would be to thrash it out on article talk, but there is at least one user (see user talk) who appears to want to change any mdy to dmy in all space articles so the issue should be settled in a central location. If an RfC is needed, where should it be held? Johnuniq ( talk) 06:26, 12 February 2022 (UTC)
In topics where a date format that differs from the usual national one is in customary usage, that format should be used for related articles: for example, articles on the modern US military, including biographical articles related to the modern US military, should use day-before-month, in accordance with US military usage.appears to give the US military as just one example of a topic with "customary usage" of another date format. I don't think the MOS needs to be changed in order to decide that NASA is a second example after the US military. I think a RFC on WT:SPACEFLIGHT should be sufficient to establish a second example. The MOS clearly says the military is one example, it's not an exhaustive list. Leijurv ( talk) 06:41, 12 February 2022 (UTC)
MOS guidance is to use variationsas appropriate and to WP:RETAIN. The military and NASA are variations within a variation. The argument is therefore somewhat self-defeating. Cinderella157 ( talk) 11:50, 19 February 2022 (UTC)
This isn't a conversation about the common date format used by US publications and NASA, but rather if spaceflight articles should use DMY because of their international readership.No, it is a conversation about the date format to be used in NASA related articles and whether NASA falls to the same exception as the US military. That you raised an opinion about readership does not make this whole thread/discussion about readership.
US-centric space articles are likely to be read by US readers? Cinderella157 ( talk) 13:12, 19 February 2022 (UTC)
I think WP:Ordinal used to have guidelines on when to use "first" and when to use "1st". I can't find it now. An editor is consistently using "1st" in a sentence when it should be "first". Where is the MOS guideline? Bubba73 You talkin' to me? 07:56, 19 February 2022 (UTC)
Integers from zero to nine are spelled out in words.So "first" is correct per MOS. Schazjmd (talk) 20:13, 19 February 2022 (UTC)
spell=on
flag in the convert template for such numerals, as this is what the MOS calls for. An editor disregarding this is editing against the MOS (and normal English prose conventions).
Archon 2488 (
talk)
14:41, 20 February 2022 (UTC)
Centuries and millennia are identified using either "Arabic" numerals (the 18th century) or words (the second millennium)Considering that and MOS:1ST together, we should write "first century". But MOS:CENTURY actually uses "1st century" elsewhere. MB 18:44, 20 February 2022 (UTC)
Following on from the above conversation, I came here to check it if should be 12th or twelfth in a DYK submission. The guidance remains confusing because under ordinals it says "For guidance on choosing between e.g. 15th and fifteenth, see § Numbers as figures or words" but under that section nothing is mentioned ... or am I missing something? Mujinga ( talk) 11:08, 23 February 2022 (UTC)
Integers greater than nine expressible in one or two words may be expressed either in numerals or in words (16 or sixteen…, which I take as licence to use either 12th or twelfth as you prefer. Certes ( talk) 13:27, 23 February 2022 (UTC)
WP:DIGITS says to group multi-digit quantities, with only a few exceptions for years. This looks absolutely horrific for multi-digit fractions, as occur for instance in Harmonic series (mathematics): we get atrocities like "14274301/4084080". Even spacing the slash doesn't help: "14274301 / 4084080". Compare the obvious way of writing this as a horizontal fraction, "14274301/4084080". Can we maybe add an exception that numbers used as part of larger mathematical expressions should not be spaced? — David Eppstein ( talk) 20:10, 27 February 2022 (UTC)
{{
frac}}
{{
sfrac}}
WP:DIGITS says to group multi-digit quantities, with only a few exceptions for years. This looks absolutely horrific for multi-digit fractions, as occur for instance in Harmonic series (mathematics): we get atrocities like "14274301/4084080". Even spacing the slash doesn't help: "14274301 / 4084080". Compare the obvious way of writing this as a horizontal fraction, "14274301/4084080". Can we maybe add an exception that numbers used as part of larger mathematical expressions should not be spaced? — David Eppstein ( talk) 20:10, 27 February 2022 (UTC)
{{
frac}}
{{
sfrac}}
Would it be acceptable to write "USD" instead of "US$," in situations where disambiguation is needed for the country but not for the fact that USD refers to currency? Just curious, because I like "USD" better. Birdsinthewindow ( talk) 21:59, 10 April 2022 (UTC)
This stems from a discussion on WP:ERRORS yesterday. MOS:PERCENT currently states "percent (American English) or per cent (British English)", but that's not quite right. I understand American English does mandate 'percent', but British English allows both forms. Dictionaries split equally on which version they prefer: Cambridge percent, Oxford per cent, Collins percent, Macmillan per cent. In all cases they list the other version as a valid variant. Style guides seem to follow either Oxford or Cambridge spellings throughout, though the BBC's style guide encourages the % symbol instead. It appears we should not be prescribing one version as 'British' when both are valid in British English. I suggest a minor tweak to the phrasing:
Modest Genius talk 18:13, 6 January 2022 (UTC)
a large percent of students. Barbarous. E Eng 19:26, 6 January 2022 (UTC)
a large percentage of students. — David Eppstein ( talk) 21:36, 6 January 2022 (UTC)
'Zero-percent [ sic] financing' is an interest-free loan.-- John Maynard Friedman ( talk) 19:49, 6 January 2022 (UTC)
The discussion above indicated a general preference for standardising on 'percent' for WP:COMMONALITY reasons. Can we implement that change? Modest Genius talk 12:05, 9 February 2022 (UTC)
I don't think a full request for comment is necessary, but if others disagree, we could do that. How does this language change sound?
The current section on percentages says (in full):
- In the body of non-scientific/non-technical articles, percent (American English) or per cent (British English) are commonly used: 10 percent; ten percent; 4.5 per cent. Ranges are written ten to twelve per cent or ten to twelve percent, not ten–twelve per cent.
- In the body of scientific/technical articles, and in tables and infoboxes of any article, the symbol
%
(unspaced) is more common: 3%, not 3 % or three %. Ranges: 10–12%, not 10%–12% or 10 to 12%.- When expressing the difference between two percentages, do not confuse a percentage change with a change in percentage points.
I propose changing the first bullet point to:
- In the body of non-scientific/non-technical articles, percent is commonly used: 10 percent; ten percent; 4.5 percent. Ranges are written ten to twelve percent, not ten–twelve percent. Percent is commonly used in American and British English. Avoid per cent on the basis of WP:COMMONALITY.
The other bullet points would not change.
Thank you, SchreiberBike | ⌨ 16:27, 9 February 2022 (UTC)
So: should all centuries use the same form (numeral vs word) in an article for consistency and per MOS:NUMNOTES? Or should they respect MOS:ORDINAL? Except when they are in the same sentence ("From the fifth to the 11th century" => "From the 5th to the 11th century" or "From the fifth to the eleventh century")?
Would be great to add a bullet point to MOS:CENTURY to clarify that issue. A455bcd9 ( talk) 08:44, 8 April 2022 (UTC)
I knew this had been resolved once, but it took me a while to track it down. There was a discussion at
Wikipedia talk:Manual of Style/Dates and numbers/Archive 138#Centuries format in September 2012 where the consensus was to write "Centuries not in quotes or titles should be either spelled out (eighth century) or in Arabic numeral(s) (8th century). The same style should be used throughout any article."
Minor modifications later changed it to "Centuries and millennia not in quotes or titles should be either spelled out (eighth century) or in Arabic numeral(s) (8th century), with in-article consistency."
On March 19, 2014,
EEng
removed that paragraph and replaced it with "Centuries are given in figures (the 18th century BCE, not XVIII century) or words (the eighteenth century BCE)."
This removed the phrase "in-article consistency"
. That was
explained on the talk page at the time by EEng that "The bit about in-article consistency isn't needed because that's a general principle given in the boilerplate at the top of the page."
To make it explicit, I think we should add back "in-article consistency"
.
SchreiberBike |
⌨
04:01, 15 April 2022 (UTC)
Please see Wikipedia talk:Manual of Style#MOS:ERA: dispute over what "established era style" means. — SMcCandlish ☏ ¢ 😼 22:45, 3 April 2022 (UTC)
Does MOS:DATETOPRES apply to infoboxes, tables or just prose? If it applies to infoboxes a number of sport projects will need to change their documentation (and many articles) Wikipedia:WikiProject Football/Players is one example. If not, then this should probably be reverted. Either way, the section on this project should probably make the scope clear. Not watching here, so please ping me if you would like me to respond. Walter Görlitz ( talk) 03:39, 24 February 2022 (UTC)
...tables and infoboxes where space is limited, pres. may be used (1982–pres.)— Bagumba ( talk) 00:37, 25 February 2022 (UTC)
You are trying to change how an entire WikiProject operates, and has done with no issues for 16+ years, affecting tens of thousands of articles. Giant Snowman 19:31, 7 March 2022 (UTC)
MOS:DATETOPRES and the broader community consensus seems pretty clear and specifically states "Do not use incomplete-looking constructions such as 1982–", which appears to be what this is all about. Cinderella157 ( talk) 00:51, 8 March 2022 (UTC)
It seems clear that the projects should meet the MoS's requirement rather than a requirement to change the MoS because a few sports projects object to implementing it. Is this worth an RfC? Walter Görlitz ( talk) 23:19, 6 April 2022 (UTC)
There aren't tens of thousands of active players with page- almost all current association footballers, which itself would be thousands of articles I imagine. And then there's at least 4 other sports listed (albeit I imagine they have fewer articles, as the sports have not as many countries with professional leagues). Joseph 2302 ( talk) 10:25, 7 April 2022 (UTC)
–pres.
as this MoS suggests and it is actually narrower than a four-digit year and it makes the construction complete, which is the goal of this MoS.
Walter Görlitz (
talk)
19:54, 7 April 2022 (UTC)
I have edited the MOS to make it clear that whilst you should generally avoid open ended dates, some sports do and that's fine. That a) reflects the actual usage of certain sports WikiProjects whilst b) not opening the floodgates for implementation in other types of articles (which should continue to use –pres.
Giant
Snowman
19:23, 17 April 2022 (UTC)
2017—
or 2017—pres.
in the infoboxes of sports people is not. Unsure why you are suggesting I read AGF - that in itself is ABF. The irony.
Giant
Snowman
09:31, 18 April 2022 (UTC)
Over on Talk:Euclid–Mullin sequence, someone with more MOS knowledge than common sense suggested modifying a comma-separated list of numbers (of widely varying numbers of digits) to add more commas separating groups of digits, and someone else with more MOS knowledge than common sense agreed. I was horrified to see that WP:DIGITS does not warn against doing this. Maybe it should? — David Eppstein ( talk) 07:27, 4 May 2022 (UTC)
{{
val}}
to display numbers like 12345678.
Stepho
talk
08:05, 4 May 2022 (UTC)
The passage in the article mentioned by David Eppstein is
2, 3, 7, 43, 13, 53, 5, 6221671, 38709183810571, 139, 2801, 11, 17, 5471, 52662739, 23003, 30693651606209, 37, 1741, 1313797957, 887, 71, 7127, 109, 23, 97, 159227, 643679794963466223081509857, 103, 1079990819, 9539, 3143065813, 29, 3847, 89, 19, 577, 223, 139703, 457, 9649, 61, 4357, 87991098722552272708281251793312351581099392851768893748012603709343, 107, 127, 3313, 227432689108589532754984915075774848386671439568260420754414940780761245893, 59, 31, 211... (sequence A000945 in the OEIS)
I suggest that in this day and age, this passage should not be considered human-readable. Maybe 80 years ago a passage like this might have been considered human readable, because the printing press was almost all we had for disseminating information. But today, trying to retype a passage like this by hand would be irresponsible. So this kind of information should be in some machine-readable format. Jc3s5h ( talk) 00:44, 5 May 2022 (UTC)
The point of this thread is ... to seek a change to the MOS that explicitly discourages comma-separated digit groups in comma-separated numbers.Separating list items with semicolons is an established method for text that also includes commas ("Queen Abi; Gordon, professor of punctuation; Eric ....) and may even be becoming more popular. Semicolon-separated number lists are easily imported into eg Excel. Should we recommend semicolons? NebY ( talk) 15:32, 28 May 2022 (UTC)
The Australian Commonwealth Style Guide recommends using spaces instead of commas for separating digit groups this reason. Hawkeye7 (discuss) 19:31, 28 May 2022 (UTC)
Sometimes figures and words carry different meanings; for example, Every locker except one was searched implies there is a single exception (without specifying which), while Every locker except 1 was searched means that locker number 1 was the only locker not searched.
Suppose we change the statement and its variants to being about a locker numbered 128. Suppose we had thousands of lockers and we want to know how to interpret this statement:
Every locker except 128 was searched.
Georgia guy ( talk) 19:01, 26 May 2022 (UTC)
I noticed 2001-09-02 is acceptable in some conditions when space is limited, same goes with 2 Sep 2001 and all other abbreviated formats like Sep 2, 2001
Formats like 2 September 2001 and September 2, 2001 are allowed everywhere, in an American article it's September 2, 2001 whereas in a British article it's 2 September 2001
Formats like 2001-09 are unacceptable as it could be mistaken by a range of ranges 2001–2009, and formats like 02-09-2001 are unacceptable as it could mean February 9, 2001 or 2 September 2001, and 01-09-02 could mean January 9, 2002
in MDY format
, 1 September 2002
in DMY format
, or 2001 September 2
in YMD format
A template like {{FULLDATE|type=mdy|time=2001-09-02}}
outputs as September 2, 2001
or in DMY format {{FULLDATE|type=dmy|time=2001-09-02}}
outputs as 2 September 2001
-- 98.31.29.4 ( talk) 01:38, 30 May 2022 (UTC)
I propose that this text needs clarification, because the meaning of the word "conservative" in this context is not clear:
Where explicit uncertainty is unavailable (or is unimportant for the article's purposes) round to an appropriate number of significant digits; the precision presented should usually be conservative.
If "
conservative" means "resisting change", then rounding conservatively means keeping more significant digits (making less change to the original value, but the next sentence Precise values ... should be used only where stable and appropriate ..., or significant ...
implies that fewer significant digits are generally preferred, which would be consistent with "conservative" meaning "cautious, moderate" (fewer significant digits are more likely to be "correct" within the precision implied by those fewer significant digits).
Which is the intended meaning? How can we reword the MOS sentence to make it explicit? Mitch Ames ( talk) 11:50, 5 June 2022 (UTC)
measuring with more precision takes more effort— That's true, but Wikipedia editors are never measuring anything, we are reporting what others have done. In the sentence I quoted from MOS:UNCERTAINTY we are explicitly rounding an existing value. Mitch Ames ( talk) 12:40, 5 June 2022 (UTC)
I've moved "normal rounding" into a separate section from #Meaning of "conservative" when rounding, because the two are separate and independent issues. Mitch Ames ( talk) 00:01, 15 June 2022 (UTC)
The meaning of "a normal and expected way" also seems to be unclear, as I keep seeing editors in film articles apparently not understanding how to round numbers and rounding the same number inconsistently. This guideline does not make it explicitly clear how normal rounding works, ie that more than half .5 or higher rounds up (or that 30 seconds or more rounds up if it is minute, etc). I don't know if editors do not understand the basic mathematics of how normal rounding works or if they are oblivious and decided to truncate instead of round the numbers (some people are all right brain and can't do math). -- 109.77.199.246 ( talk) 13:50, 14 June 2022 (UTC)
I sometimes see an editor add a weekday name to a date in an article. For example, changing "X occurred on 19 June 2022" to "X occurred on Saturday, 19 June 2022". This seems to me to be unnecessary, except in a very few cases where the day of the week is relevant to the event, but it's not clear to me whether it actually violates the MOS. I don't see any mention in the MOS of using or not using weekday names in dates. Should such changes be reverted, ignored, or even encouraged? CodeTalker ( talk) 22:52, 19 June 2022 (UTC)
"unnecessary, except in a very few cases where the day of the week is relevant to the event"like the attack on Pearl Harbor (an attack will be more successful when people were away from the defenses for the weekend), but usually it's not. I've taken out days of the week many times and no one has objected. SchreiberBike | ⌨ 23:49, 19 June 2022 (UTC)
There is a discussion at Template talk:GBP#Semi-protected edit request on 12 June 2022 that may interest watchers of this page. Although there is a consensus in favour of the change, more eyes may identify unforeseen consequences before they happen. Comments welcome. -- John Maynard Friedman ( talk) 16:46, 25 June 2022 (UTC)
Avoid making up new abbreviations, especially acronyms. For example, " International Feline Federation" is good as a translation of Fédération Internationale Féline, but neither the anglicisation nor the reduction IFF is used by the organisation; use the original name and its official abbreviation, FIFe.
Currently there is a rule that numbers are not spelled out in mathematical formulas. I think that this rule should be widened. Spelled numbers look somewhat strange in any mathematical text, not only in formulas, if they are considered as mathematical objects. But if a number in a mathematical text is simply a number of objects then it is good and sometimes even very desirable to spell it out. For example: "The smallest three prime numbers are 2, 3, 5." In my opinion, it is very undesirable to write this as "The smallest three prime numbers are two, three, five.", but just this way of writing is technically the best one according to the current Wikipedia rules. I propose to change the rules according to this explanation. D.M. from Ukraine ( talk) 18:12, 21 July 2022 (UTC)
note that the statement "the first three primes are 2, 3, and 5" was replaced to avoid the issue of alternative definitions of prime numbers. dying ( talk) 03:51, 27 July 2022 (UTC)Integers from zero to nine, used in a mathematical context, are not required to be spelled out: the prime numbers 2, 3, and 5, not the prime numbers two, three, and five.
If the event's specific date, which consists of the day and month, is unknown but the year is the same as the event before it, may "in the same year" be used? — Princess Faye ( my talk) 09:27, 26 June 2022 (UTC)
EEng, regarding your comment in the summary of this edit, i think the second counterexample in the first column ("9. June") suggests that the "dot to the day" was referencing the ordinal dot. however, now that "to the day or" has been removed, i am admittedly somewhat worried that readers who see the second counterexample and its associated comment may be confused about how abbreviated months are relevant to the counterexample "9. June". would it have been more helpful to, for example, link "to the day" to the description of the ordinal dot? alternatively, the cell in the third column containing the comment can be split into two rows, one for each of the two counterexamples. dying ( talk) 14:21, 11 August 2022 (UTC)
Apparently, this guideline says we don’t have to use a comma after the year if we write “On 5 May 1822 the act became law” but we do have to use a comma after the year if we write “On May 5, 1822 the act became law”. This seems like a really silly distinction. Is it for real? Even in an article title? This issue has arisen today at Talk:2021 United States Capitol attack. Anythingyouwant ( talk) 00:00, 29 July 2022 (UTC)
Correct: | He set October 1, 2011, as the deadline for Chattanooga, Oklahoma, to meet his demands. |
Incorrect: | He set October 1, 2011 as the deadline for Chattanooga, Oklahoma, to meet his demands. |
Surely you would never think proper a title that says Capitol attack of January 6, 2021,As I said on the talk page the editor is referring to, this is a bad faith, literalist interpretation of the DATECOMMA. Obviously all titles on Wikipedia do not have ending punctuation. Thrakkx ( talk) 13:30, 29 July 2022 (UTC)
The [year] is treated as parenthetical.Thrakkx ( talk) 13:33, 29 July 2022 (UTC)
She was frustrated with her December 15, 2021, jury duty.
She was frustrated with the jury duty she served on December 15, 2021.
Waco, Texas, physician John Smith...
John Smith, a physician from Waco, Texas, ...Thrakkx ( talk) 21:17, 29 July 2022 (UTC)
The South Sudanese pound has no unique symbolic abbreviation, it exclusively uses an unadorned £. For distinction I recommend advising £10,000 SSP be used, with the ISO code appending the numerals.
Discussions on several pages have concluded that ₤ is merely a stylistic choice and is not regarded as a distinct separate sign from £ in general usage, and that the only reason for its inclusion as a separate character from £ in Unicode is for compatibility with a legacy character set ( HP Roman). I recommend noting that and advising against its use anywhere due to compatibility problems that would arise.
The Egyptian pound sign displayed on this page is also a point of contention. E£ was taken out of the Egyptian pound's article after it was found to lack any reliably sourced citations (the correct sign is £E or LE).
And my last point on currency is that Wikipedia's sign for the Australian dollar, A$, is not recommended by style guides and is not used by the Reserve Bank of Australia, these sources use $A. Countries with a recent strong British heritage usually place the disambiguating abbreviation after the currency sign, not before it. It is a minor swap, but not all currencies use the US dollar's abbreviation as a template. The Australian and New Zealand dollars inherited this practice from their £sd-based currencies, which were abbreviated £A and £NZ respectively.
Finally (you can all breathe a sigh of relief), I believe it is probably more efficacious for UK-centric articles to always display the imperial units first followed by an SI conversion. The BBC recommends this usage
in their style guide. Especially as it is likely more use of imperial will be made in the future.
TheCurrencyGuy (
talk)
15:38, 9 August 2022 (UTC)
I believe it is probably more efficacious for UK-centric articles to always display the imperial units first followed by an SI conversionmeans we can all
breathe a sigh of relief, you're mistaken. You've basically just whacked a hornets nest with a stick. I strongly oppose making such a change in this area.
consensuses were established on the relevant pagesseems inaccurate on the case of Egyptian pound, where the "consensus" is the WP:WRONGVERSION from when you were blocked for edit warring. Kahastok talk 07:22, 12 August 2022 (UTC)
For the British pound sterling (GBP), use the £ symbol, with one horizontal bar, not the double-barred ₤ (which is used for Italian lira). For non-British currencies that use pounds or a pound symbol (e.g. the Egyptian pound, E£) use the symbol conventionally employed for that currency.
For the British pound sterling (GBP), use the £ symbol, with one horizontal bar, not the double-barred ₤ symbol ("lira sign") (Whether a pound sign uses one or two bars is purely a type-design choice.) For non-British currencies that use pounds, use the symbol or abbreviation conventionally employed for that currency, if any.
For the British pound sterling (GBP), use U+00A3 £ POUND SIGN, not U+20A4 ₤ LIRA SIGN (the latter being a code-point for a legacy character set. Whether a pound sign uses one or two bars is purely a type-design choice.) For other currencies named "pound" or similar, use the symbol or abbreviation conventionally employed for that currency, if any.TheCurrencyGuy ( talk) 00:04, 17 August 2022 (UTC)
For the British pound sterling (GBP), use U+00A3 £ POUND SIGN, not U+20A4 ₤ LIRA SIGN (the latter being a code-point for a legacy character set; whether a pound sign uses one or two bars is purely a type-design choice). For other currencies named "pound" or similar, use the symbol or abbreviation conventionally employed for that currency, if any – e.g. IR£ for Irish Pound (IEP).
The broader issue (below) will take a lot longer to resolve so unless anyone objects, I propose to change the MOS to read:
I don't think that the MOS needs to go the history of Unicode as TCG proposes. If anyone wants it, the linked articles provide it. -- John Maynard Friedman ( talk) 20:27, 18 August 2022 (UTC)
It seems to me that a broader issue here is that TheCurrencyGuy is interested in "cleaning up" currency notation across a wide variety of Wikipedia pages, and he is often running into conflicts because the notation he chooses isn't always exactly right, or doesn't quite have consensus. I know that MOS creep is an issue but, since currencies are used on a wide variety of Wikipedia pages, it doesn't seem absurd to me to have a subpage (or just somewhat expand the section of this page) where the actual notations are listed for a variety of currencies.....then people interested in cleaning up currency notations on Wikipedia could get consensus for the style there before deploying it on many pages. I think the situation is not always clear. For example, in languages that don't use the Latin alphabet, the currency notation that is generally used "in the wild" is not always the one that is used in English-language sources.... CapitalSasha ~ talk 16:15, 17 August 2022 (UTC)
I couldn't find that in MOS:TOPRESENT. — Guarapiranga ☎ 01:41, 15 August 2022 (UTC)
if you're interested, I'd change that to "If you're interested and prepared to be bored to tears". E Eng 15:39, 18 August 2022 (UTC)
Hey everyone, I hope you are all well.
Over the years this issue has come up again and again: whether it is okay to use "2022–present" (or whatever the current year is; last year it was "2021–present", next year it will be "2023–present" etc). This used to not be an issue as on soap articles etc we would format ranges like "2022–", "2021–", "1991–2009, 2011–" etc, but now several editors are opposing to "2022–present" due to 2022 being the present, and to put "2022" on list articles (e.g. List of Days of Our Lives cast members). However, this causes many issues such as:
1.) Putting simply "2022" suggests that the event has already been completed, especially as in the past "2022" would mean that the stint is already finished whereas "2022–" or "2022–present" means that it is ongoing. This is especially true in things such as lists of characters, as many cast members appear in guest stints and thus "2022" suggests that the stint has already ended/is confirmed to end this year. For example "1999–2008, 2022" looks like the stint in 2022 has already been completed, whereas "2022–present" illustrates that it is still ongoing.
2.) This is inconsistent with other wikipedia lists, where "2022–" or "2022–present" is used in lists
3.) It is inconsistent with the MOS technically as the MOS says to use "–present" and not just "2022" if it is the current year
4.) Often they are not updated the following year and thus this makes it incorrect as wrong (e.g. I recently found an article which said just "2020" instead of "2020–present"/"2020–"
In the past I have tried to avoid unambiguity by using "Since 2022" in tables, but this is quite unusual as it differs from other articles. Even though we are in 2022, "2022" is also not technically the present - January 2022 is not the present, and even August 18 is not the present. Hence, I have started this discussion to allow the use of "2022–present" and avoid the ambiguous use of simply "2022" for ongoing events/durations. DaniloDaysOfOurLives ( talk) 17:32, 20 August 2022 (UTC)
This is not the same – what I am asking is there to be clarity on whether "2022–present" (or even "2022–") to be used as some editors keep reverting it to simply "2022" but this is extremely ambiguous DaniloDaysOfOurLives ( talk) 13:48, 21 August 2022 (UTC)
"Unfortunately, MOS:DATETOPRES does not cover what happens when the start year is the present year."It still doesn't. Suggestions included adding the month, or (updating the suggestions) "beginning 2022" or "since 2022". I agree that "2022-present" looks weird in 2022, and it's little comfort that it'll look better in a few months. NebY ( talk) 16:26, 23 August 2022 (UTC)
Currently this guideline MOS:SEASON says magazine issue dates should be lower-case -- there's an example given: details appeared in Quarterly Review, summer 2015. I think this should be changed. The sources I use for magazine articles invariably capitalize the initial letter of the season in these cases. Some examples:
I also tried looking in Google Books for "fall 1943 issue" to see what the usage is. The genre uses appear to be exclusively uppercase, but the non-genre magazines vary. I found:
Eight with uppercase, three with lowercase. I think we could change the guidance to say either "upper or lower case is OK", or we could say upper case is preferred. I don't think we can say "follow the source" because here we have two sources differing in referring to the same magazine. And I don't think it should stay as lower case; that's clearly not the customary usage. Mike Christie ( talk - contribs - library) 19:31, 19 August 2022 (UTC)
There's an interesting discussion at Talk:Ceres (dwarf planet). As far as I can see, the article was started in British English, was peer-reviewed in 2007 in that dialect, but has recently drifted to using US English. There seems to be some confusion about date formatting versus spelling variants there. I don't have the patience to argue it out, having made all the points I can. It might be helpful to have some input from folks with experience of MOS:RETAIN and how it works there. The worst of it is that this is in danger of derailing an otherwise positive FAC for this otherwise pretty good article. Thanks for any time you can spare. John ( talk) 22:29, 22 September 2022 (UTC)
There is currently a discussion at the linked talk page above about the heading for the binary versions of kilo/mega/giga/etc. Separate from the ongoing disruption, which will need to be dealt with at AN/I most likely, there is currently an attempt to defy our sources and this guidance in the MOS by referring to the units as "Legacy" (which is both unsupported by the sources, original research, and the only attempts to justify it are done by misattributing a JEDEC standard quoting an IEEE statement). — Locke Cole • t • c 20:35, 23 September 2022 (UTC)
TLDR: I don't think we should repeat the time zone designation throughout an article and I can't find it in the MOS. Is it in there? Where? If not, should it be?
Boring content yadda yadda: I've found the guidance on time zones but if guidance exists on repeating them I have not seen it yet – please enlighten me.
What I mean is that I understand that it may be desirable/necessary to specify the time zone when we are talking about an event (or, at least, we like to pretend it is, but that is another debate) but I don't see any guidance on whether it is necessary to repeat it every time we mention a time, when some (I) might argue that it has an annoying choppy effect on the text and is ludicrously unnecessary when the context has already been set. I find this just annoying: At 0830 BST DBaK made some coffee and by 0835 BST was applying milk and yoghurt to some cereal. At 0930 BST he sat down to read about
the Queen's funeral and by 0945 BST he was ready to throw the laptop across the room because it said BST twelve frakking times in the one article set in the same few days in the United Kingdom of Great Britain and Northern Ireland so it's not like it's going to suddenly change to Pacific Daylight Time halfway through the story ffs. At 1000 BST he talked to the dog for a while then at 1005 BST he made some coffee because meh.
Now I realize that if the MOS doesn't say don't do it then some editors, about whom I am trying not to be too rude, will argue that of course it is right and proper and that the Queen's article is just great saying BST twelve times. As I say, if this guidance does exist then I have sadly failed to find it, and if it doesn't exist then I think it should. Even if it said "yeah you should put the time zone in every time you mention it" then I could sortof live with that because at least it would be there in black and white, but I find the current absence (is it?) of anything on this very unhelpful. And yes of course I wish I could find something that said don't repeat it unless there is a really good reason to, but I haven't yet. Does it exist and if not should it? Help! Thanks and best to all DBaK ( talk) 09:39, 17 September 2022 (UTC)
so much common sense all in one place!– We like to purge ourselves of our monthly quota of required common sense as quickly as possible. Now we'll return to our usual menu of half-baked drive-by comments, parochial backbiting, and long-term score-settling. E Eng 05:54, 28 September 2022 (UTC)
I see YYYY-MM--
could be the alternative to YYYY-MM
, because of sorting dates, when the day of month is included you can use YYYYMMDD
to sort as
ISO 8601 allows both YYYY-MM-DD
and YYYYMMDD
, but when the day of the month is omitted only YYYY-MM
is allowed, but
MOS:DATEFORMAT doesn't allow that format at all because of the range of years, YYYY-MM-DD
can only be used where space is limited, and cite sources. 2001-07 is not permitted due to the ambiguity of range of years, 2001-07-- could be used in some places.
For an example
When the day of the month is included.
American article - {{sort|20010902|September 2, 2001}}
- September 2, 2001
European article - {{sort|20010902|2 September 2001}}
- 2 September 2001
When the day of the month is excluded.
{{sort|2001-07--|July 2001}}
- July 2001
Although there is {{
date table sorting}}
as well, you can use when the day of the month is omitted.
98.31.29.4 (
talk)
00:04, 4 October 2022 (UTC)
Based on what I read here, I attempted to add the converter tool to dollars for £2.192 billion. I used the following surrounded by {{ }}: To USD round|2192000000|GBR|2022 It results in:
2.798×109
I'm sure I'm stupidly missing something. What is it? HarvardStuff ( talk) 01:42, 6 October 2022 (UTC)
Can we get some extra eyes over to NTFS ( | talk | history | protect | delete | links | watch | logs | views), there are a number of editors revert warring over using IEC units in an article that clearly uses standard metric units. Worse, they're mixing units within the same statement, leading to a confusing experience for our readers. I'd standardized on the correct unit, but am being blindly reverted against the guidance of WP:COMPUNITS. Thanks! — Locke Cole • t • c 16:38, 5 October 2022 (UTC)
There is an RFC to answer questions about the {{ Quantities of bits}} and related templates. Please see the questions there and answer as you see fit. — Locke Cole • t • c 01:23, 10 October 2022 (UTC)
Section
§ Grouping of digits now says "Markup: Templates {{
val}} and {{
gaps}} may be used to produce this formatting. .. use of any space character
as a separator .. is problematic for screen readers". It is unclear whether the two templates prevent, ie solve, that issue or have the same issue. BTW, that issue might also occur with copy/paste effect: "Does {{val}} result in correct copy/space effects in this?" (iow, does c/p produce spaced number strings, IMO undesired?).
DePiep (
talk)
07:33, 10 October 2022 (UTC)
{{val|9.123456789}}
→ 9.123456789 → 9.123456789 (copy/paste){{gaps|123|456|789}}
→ 123456789 → 123456789 (copy/paste)The MOS doesn't come right out and say it, but since "On 5 May 1822 the act became law" (with no comma) is correct, I have assumed that "In 1822 the act became law" (with no comma after the year) is also correct. I don't normally remove a comma if it's already there, but lately I've been seeing a plague of people adding commas to this kind of sentence, and I sometimes revert if that's the only change being made in an edit. The comma doesn't belong, does it? GA-RT-22 ( talk) 20:46, 9 October 2022 (UTC)
I have started a discussion about the usage of plural or singular units for distances of swimming events (ie 100 metres vs 100 metre freestyle) and invite others for their input at Wikipedia talk:WikiProject Olympics#metres vs metre. Thanks. A7V2 ( talk) 04:16, 31 October 2022 (UTC)
Is there some good reason why most articles about electric vehicles use "kW-hr" instead of "kWh"? I checked the cited sources for a few of them and as far as I can tell the sources all use "kWh". Apparently "kW-hr" is sometimes used by the US government. Search for "kW-hr" GA-RT-22 ( talk) 03:19, 1 November 2022 (UTC)
Exception: In some topic areas, such as power engineering, certain products take neither space nor ⋅. Follow the practice of reliable sources in the article's topic area. Wh, VA, Ah kWh, MVA, GAh. As you've found reliable sources use in the topic area of electric vehicles use kWh, that's what I'd expect to see in our articles.
A few months ago I inquired about this, but didn't get any responses, so figured I'd try again. My results below are slightly off due to the time passed FYI.
The current MOS is to use No. instead of #, but I'm wondering why this is. It's only been discussed a few times, most recently back in 2016. From what I gathered, using "No." instead of "#" is more popular in the U.K., but not in the U.S., so why should the U.S. articles adopt the same style?
I know this is a piss poor example, but I quickly searched on Google "#11 on the" and got 65million results. Then I searched for "No. 11 on the" and only got 418,000 results ("his album reached #11 on The Chart" & "his album reached No. 11 on The Chart" was my thinking). I then did the same thing for Wikipedia. "#11 on the" got 21,800 results and "No. 11 on the" got 1,790 results. Wouldn't it be a waste of time trying to convert all of that? If the total amount was similar in both cases, it'd be understandable, but there's no way that "No." will catch up (so to speak) with "#".
I'm also aware that Twitter popularized the usage of "#" as a tag, but I don't think that matters much on Wikipedia since we rarely use it in that way here, except in edit summaries. Was hoping someone could shine some light on all of this for me. Thanks in advance. Xanarki ( talk) 20:33, 3 November 2022 (UTC)
#meant number was near-unknown in Britain until the internet came along. I have a memory of a family member once confusing an American server by asking for "hash 5" from the menu. And you will still find people who will not understand it. I don't believe the same is true of
No.in the US. MOS:COMMONALITY would require that we prefer
No.. Kahastok talk 21:09, 3 November 2022 (UTC)
£. Kahastok talk 21:09, 3 November 2022 (UTC)
lb. Martin of Sheffield ( talk) 21:48, 3 November 2022 (UTC)
Read Wikipedia:Logical_quotation_on_Wikipedia#Wikipedia_is_not_bound_by_external_style_guides,_anyway. (Just this section of the essay please.) Can you apply the terminology this essay uses in the second and third paragraphs with 4 examples of wrong and right reasons Wikipedia's rules are set up the way they are to the sentence "We use No. rather than #, not because...but because..."?? Georgia guy ( talk) 16:43, 8 November 2022 (UTC)
Applause for @ SilkTork:, who's sorted out WT:MOSNUM's archives, making them navigable and searchable right back to the year dot! I'd feared we'd have to live with the old mess forever. NebY ( talk) 18:32, 1 November 2022 (UTC)
Talk:2022 Morbi bridge collapse has an RFC for possible consensus. A discussion is taking place. If you would like to participate in the discussion, you are invited to add your comments on the discussion page. Thank you. BilledMammal ( talk) 06:47, 14 November 2022 (UTC)
Hello, a question. I destubbed an article and used format of dates in references in uniform format 2022-11-13, no other dates were used in the article. A user came and added use dmy dates template (which from the point of view of its national ties is OK). Do I have to change all the dates in the references to the dmy format, or can I keep it per MOS:DATERET? On the outside, there is dmy everywhere thanks to the template, so it's just the code. If the data format was uniform before, wasn't adding the template pointless? FromCzech ( talk) 07:03, 13 November 2022 (UTC)
|cs1-dates=y
with one of these two templates. —
David Eppstein (
talk)
08:12, 13 November 2022 (UTC)
{{
Use dmy dates|cs1-dates=yy}}
.
Stepho
talk
22:29, 13 November 2022 (UTC):::(
edit conflict)
|date=
:
|date=
occurred at
this edit which added the first reference to the article. It used |date=2020-04-30
. That is a perfectly legitimate date format. So long as subsequent references use |date=
with the same date format, cs1|2 is happy. There is nothing at Help:CS1 that prohibits the use of year-initial numeric dates in any date-holding parameter so long as all cs1|2 templates in the article follow the same formatting.Citation Style 1 is a specific style, documented at Help:Citation Style 1, and errors may be corrected to conform to that documentation. This is the same as if an article followed The Chicago Manual of Style; errors could be fixed if citations departed from the Chicago Manual. The only time the article itself would set the rules for how citations are done would be if the article consistently followed an ad hoc style developed just for that article. Jc3s5h ( talk) 02:00, 14 November 2022 (UTC)
{{use xxx dates}}
template when it updates the |date=
parameter. In doing so, it preserves |cs1-dates=
but does not apply that setting to dates in cs1|2 templates. I suspect, but don't know, that it is possible for the script to do the right thing and rewrite the dates in cs1|2 templates in the forms specified by |cs1-dates=
.|cs1-dates=
. The real purpose of that parameter is to cause the cs1|2 templates to render the dates as directed by the {{use xxx dates}}
template regardless of how those dates are written in the cs1|2 template. If I remember correctly, there was a period of time when the script did not modify cs1|2 template dates. But, because editors complained that the cs1|2 dates weren't being updated when the script was run, a change was made to rewrite dates to use the canonical date format specified by the {{use xxx dates}}
template. The script should probably be changed so that cs1|2 template dates are rewritten to obey the format specified in |cs1-dates=
. I acknowledge that this change would likely only apply to those cs1|2 template under their canonical names. The script won't be able to rewrite dates in templates using redirected names nor will it be able to rewrite dates of cs1|2 templates that exist inside wrapper templates (there are a lot of both types). Still, the preponderance of cs1|2 template use is by the canonical name.|accessdate=
and |archivedate=
parameters irrespective of the parameter in place. If I were to rewrite so that date format mirrors the |cs1-dates=
parameter, the script will first have to detect the parameter and act accordingly. I will need the help of someone who possesses the relevant skills. Volunteers kindly come forward.
Hello, I recently come across with an editor who change date format in references from "yyyy-mm-dd" to "d mmmm yyyy". The body of article itself already use "d mmmm yyyy" format and have Template:Use dmy dates in place.
In my understanding, between manually input "d mmmm yyyy" and using "yyyy-mm-dd" when Template:Use dmy dates used, both will show "d mmmm yyyy" to the reader. So in the eye of reader, they are the same format. Hence, no need to change from "yyyy-mm-dd" to "d mmmm yyyy" on the references.
However his argument to change the date format are:
Publication dates in an article's citations should all use the same format
Therefore, I asked here to get clarity on what considered as "same date format". Thanks. Ckfasdf ( talk) 23:10, 26 November 2022 (UTC)
{{
Use dmy dates}}
has the |cs1-dates=
parameter then the format that |cs1-dates=
specifies is the format that will be displayed in references.{{
Use dmy dates}}
does not have the |cs1-dates=
parameter then dmy will be displayed in references.{{
Use dmy dates}}
was recently added and it changed the majority of the references then it should have |cs1-dates=
added to keep the references in the majority format that they used to have - as per
WP:DATERET.{{
Use dmy dates}}
will override it.{{
Use dmy dates}}
since August 2020 and it does not have the |cs1-dates=
specified. And yes, both "d mmmm yyyy" and "yyyy-mm-dd" version display correctly as "d mmmm yyyy", I also agree that this really minor issue.I didn't find in the page so I ask it here: which of the two is correct, 7th–5th century BC or 7–5th century BC?-- Carnby ( talk) 07:49, 10 September 2022 (UTC)
{{
daterange|Starting Date|Ending Date}}
and {{
daterangedash|Starting date|Ending date|Date format string}}
would help, with a parameter indicating century and support for local style, e.g., {{
mdy}}. --
Shmuel (Seymour J.) Metz Username:Chatul (
talk)
14:39, 29 November 2022 (UTC)Should MOS:CIRCA apply even in less formal usage in running text, such as that found in the final sentence of I Want to Know What Love Is#Music video? I was thinking that the sudden appearance of an abbreviation in the running text might seem jarring. Or is there a better way to recast the sentence? I haven't done anything with it. 1980fast ( talk) 23:50, 29 November 2022 (UTC)
This RFC is about the use of the BC/AD and BCE/CE in article titles for years, decades, centuries, millennia. The questions I would like answered in this RFC would be to determine whether we should use the BC/AD styling for years or the BCE/CE styling. Examples include: AD 10, 13 BC, 420s BC, 16th century BC, 2nd millennium BC. Interstellarity ( talk) 13:53, 29 October 2022 (UTC)
article titles for years, decades, centuries, millennia. Levivich ( talk) 16:45, 15 November 2022 (UTC)
This RfC is out of scope for this page; you are attempting to set up a WP:LOCALCONSENSUS to override MOS:ERA. The discussion shoule be at Wikipedia talk:Manual of Style/Dates and numbers at the very least, better still would be Wikipedia talk:Manual of Style or WP:VPP. -- Redrose64 🌹 ( talk) 14:09, 29 October 2022 (UTC)
Could anyone supporting "Allow either" provide an example of any article where it would be "appropriate" to use BCE in the article title? St Anselm ( talk) 20:11, 29 October 2022 (UTC)
Proposer wishes to see articles retitled using BCE/CE, whatever's in the body [62] They are alone in seeking this. Can we snow-close this before it becomes any more disruptive? NebY ( talk) 21:03, 29 October 2022 (UTC)
I'm confused by the wording of the RfC, but the titles should be consistent. In other words articles in a sequence of similarly named articles should either all use AD/BC or all use CE/BCE. I don't have a view on which that should be (happy to accept the consensus choice of fellow editors). Dondervogel 2 ( talk) 11:01, 3 November 2022 (UTC)
12 January 1999 instead of January 12, 1999? 47.205.254.217 ( talk) 07:57, 4 December 2022 (UTC)
I fixed a singer's birthdate as December 29, 1959 and they reverted it to 29 December 1959 the user labeled good faith but it was December 29, 1959 before it was changed. 47.205.254.217 ( talk) 06:50, 5 December 2022 (UTC)
{{
use dmy dates}}
. For you to insist that everybody use your American format instead of their own national format shows either ignorance (forgivable) or rudeness. Put simply, you are trying to force American customs onto other people.
Stepho
talk
11:06, 5 December 2022 (UTC)
{{
use dmy dates}}
template, which should be followed.
Peter coxhead (
talk)
13:10, 5 December 2022 (UTC)
I was editing
Umibōzu and I found this statement: "They are often a few meters to a few tens of meters in length." I would add a conversion in milesyards or feet but I don't know whether is necessary or not. Perhaps milesyards would be more correct in that case, getting rid of kmsmetres/meters, since there's no value? Also: is it correct the U.S. spelling "meters" in articles dealing with Japanese mythology? Thanks in advance.--
Carnby (
talk)
21:43, 11 December 2022 (UTC)
An editor is repeatedly removing Template:Bit and byte prefixes from Binary prefix (the only article the template is used on on the project). It appears they're doing this because they don't like the way a recent RFC went, so they're effectively subst'ing the template portion they prefer and beginning the argument anew. Instead of engaging in discussion, they're engaging in protracted revert warring to force it their way. Help. — Locke Cole • t • c 00:03, 17 December 2022 (UTC)
BTW, why is the market share of MS relevant given my toungue in cheek comment about graduating from MS? Just curious.Just noting that while it's indeed true that other desktop OS's may be moving towards these units, that the one in widest use by our readers and the public at-large still clings to the commonly used binary prefixes. — Locke Cole • t • c 05:23, 19 December 2022 (UTC)
The table in WP:MOSNUM#Quantities of bytes and bits ( MOS:COMPUNITS) is currently provided by a template. Recent conflict over that template have sometimes left the table confusingly in conflict with the MOS text eg listing units as "deprecated" removing the prefix "tera-". Our text has been the subject of (ahem) vigorous discussion here, but most of us are very happy not to join in discussions about the template and are blissfully unaware of changes in it.
Suggestion: we take a stable, compatible version of the template and make it a simple table in COMPUNITS, no longer transcluded from Template:Bit and byte prefixes. NebY ( talk) 16:42, 18 December 2022 (UTC)
Why is this table and the last column still an obsession by certain writers here. The only reason it is labeled as it is, is because it provides the only hope for refusenics of unambigous storage units to hang on to a sliver of credibility, when every standards bureau that actually has a voice in the subject matter has deprecated the binary interpretation and stood firm on the new standards, and when new software written these days uses these prefixes accordingly and without which the software may not be distributed in certain environments. And JEDEC in fact agrees with them and refers to their definitions in clear language by pronouncing their ambiguity and deprecation. They state their intent unambiguously in listing them because of ongoing usage. They do not define them in any binding manner. Why is this simply ignored here and why is this column even there? We are listing examples of outdated usage solely because an industry interest group still explains the old usage. Why is it not sufficient to display the standard definitions and discuss deviations in each article in prose? In every other article of units and natural constants or metrics and such the standards orgs are followed rigorously. Why hot here? It's obvious that there still are WP editors who let their personal tastes cloud their mind and deny readers a modern, accurate, unambiguous presentation of these subject matters. Childish belittling the sounds or pronunciations of the units is much like teenager bullying. When the newest SI prefixes got defined this fall, WP editors were eager and quick to add them to every table there is, without regard to actual usage, and without criticism in stupid opinions about their sound or pronunciation. None of these sound any more or less stupid or amusing than giga or pico or any other one. Get rid of the column, or fill it out with a header Deprecated. The MOSNUM needs to be changed and modernized. Too long has it represented a presumed consensus that was only slimly obtained by opinionated prejudice, bullying to drive intelligent contributors away, and proliferation of sock puppets of refusenics. kbrose ( talk) 20:15, 18 December 2022 (UTC)
This manual recommends using the confusing prefixes for bytes with the meaning specified for the article. I think that's not very good because copying them to another article can result in errors if the copier doesn't replace them (e.g., if they don't know about that). I think there should be templates that automatically place the correct name for units. Orisphera2 ( talk) 12:06, 7 January 2023 (UTC)
{{
unit|32|Ki|byte}}
should produce either "32
kbytes" or "32
Kibytes", depending on the pages default interpretation of SI decimal prefixes. Any such templates should support at least bit, byte and word --
Shmuel (Seymour J.) Metz Username:Chatul (
talk)
23:40, 7 January 2023 (UTC)
References
Hi. The instructions about how to provide the explanation of units in quotations are currently inconsistent:
This page therefore does mention article text whereas WP:MOS does not. I suggest that article text is also removed here as it is self-referential and self-references should be avoided as per WP:SELFREF. -- TadejM my talk 15:25, 10 January 2023 (UTC)
One does mention 'article text' whereas the other does not. No problem, sir. /s TadejM my talk 09:30, 13 January 2023 (UTC)