![]() | 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 90 | ← | Archive 92 | Archive 93 | Archive 94 | Archive 95 | Archive 96 | → | Archive 100 |
This is merger of several related discussions and proposals. — SMcCandlish [ talk] [ cont] ‹(-¿-)› 00:07, 19 December 2007 (UTC)
I'm looking for some clarification about when dates should be linked. In the Autoformatting and linking section of the MOS, the last bullet reads:
"Wikipedia has articles on days of the year, years, decades, centuries and millennia. Link to one of these pages only if it is likely to deepen readers' understanding of a topic. Piped links to pages that are more focused on a topic are possible (
[[1997 in South African sport|1997]]
), but cannot be used in full dates, where they break the date-linking function."
Does the sentence in boldface (my emphasis) mean:
1. That dates (using any combiations of days, months, and year) should only be linked if the linked date will add to the reader's understanding.
2. That only full dates (i.e.
November 1,
2007) should be linked, but not dates like
November
2007.
Another Wiki user has been trying to tell me that the latter is the case, while I have been trying to indicate that the first meaning is correct. (The discussion can be viewed here: User_talk:NatureBoyMD.) Which is correct? - NatureBoyMD 21:26, 11 October 2007 (UTC)
The albums project contains the following:
[[1991 in music|1991]]
, instead add (see
1991 in music) where you feel it is appropriate.I propose that we make that generic and include it. Lightmouse 11:09, 15 November 2007 (UTC)
[[1991 in music|1991]]
can make perfect sense in a table, for example.
Septentrionalis
PMAnderson
06:32, 23 November 2007 (UTC)
[[1997 in South African sport|1997]]
), but cannot be used in full dates, where they break the date-linking function.[[1991 in music|1991]]
) in the main prose of an article. Use "(see [[1991 in music]])", if it is appropriate to link a year to such an article at all. In places where compact presetation is important (some tables, infoboxes and lists), piped links may be useful. Piped links must never be used in full dates (e.g. [[January 1]], [[1991 in music|1991]]
) because they break the date-formatting function. Piped topical year links should only be made when the event in question is genuinely notable in the context of the year article to which would link.New version to address issue raised by Woody:
[[1991 in music|1991]]
) in the main prose of an article. Use an explicit cross-reference, e.g. ''(see [[1991 in music]])''
, if it is appropriate to link a year to such an article at all. In places where compact presentation is important (some tables, infoboxes and lists), piped links may be useful. Another exception is the main prose of articles in which such links are used heavily, as if often the case with sportsperson biographies that link to numerous separate season articles, in which the ''(see ...)''
phrasing would rapidly become repetitive and cluttering; in such a case it is best to make it clear that the link is to such a topical date article, e.g. in [[2007/2008 snooker season|the 2007/2008 season]]
, rather than in [[2007/2008 snooker season|2007/2008]]
. Piped links must never be used in full dates (e.g. [[January 1]], [[1991 in music|1991]]
) because they break the date-formatting function. Topical date links should only be used when the event in question is genuinely notable in the context of the year (or month, etc.) article to which would link.Revised version below.
I think this will adequately address the cases that need to be addressed so far, and would actually slightly help advance the growing consensus that a replacement for the date formatting function is needed so that dates are only linked when there is a contextual/informative reason for linking them.
PS: If we wanted to address piped links other than dates, I believe that is a way bigger matter, and should be discussed at WT:MOS, probably with an RfC, since it is bound to be highly controversial.
— SMcCandlish [ talk] [ cont] ‹(-¿-)› 21:00, 12 December 2007 (UTC)
[[1991 in music|1991]]
) in the main prose of an article in most cases. Use an explicit cross-reference, e.g. ''(see [[1991 in music]])''
, if it is appropriate to link a year to such an article at all. Exceptions:[[January 1]], [[1991 in music|1991]]
) because they break the date-formatting function. When using piped links, it is best to clearly indicate that the link is to such a topical date article, e.g. in [[2007/2008 snooker season|the 2007/2008 season]]
, rather than in [[2007/2008 snooker season|2007/2008]]
I think input from more editors is required before removing "surprise links" from every article. It should be discussed at the village pump. -- Pixelface ( talk) 12:33, 16 December 2007 (UTC)
If you do this, then I think that, if a date appears within parentheses, it should automatically be replaced with "(see XXXX in music)" (or "video gaming" or whatever). SharkD ( talk) 03:49, 17 December 2007 (UTC)
SOME_RANDOM_FILM_NAME (1993)
, on one hand, versus SOME_VERY_SIGNIFICANT_FILM_NAME took the
1993 "Best Picture"
Oscar
on the other. And that probably isn't even a good example, really. It is hard to come up with a generalized case for when one should make such links; it is much easier to say that most of them should simply be deleted, as blue-link "noise". —
SMcCandlish [
talk] [
cont] ‹(-¿-)›
23:09, 18 December 2007 (UTC)It's on "Autoformatting and linking". Can't see the point of the continued presence of the tag. Tony (talk) 08:34, 24 September 2007 (UTC)
Just for the record I want to call for any last discussion/debate that anyone feels is needed. The #Re-proposal above seems to not be truly objectionable to anyone, even if it not a bright line in the sand, if I may mix a few metaphors. A possible exception is SharkD, but I think the concerns raised by that editor are addressed (and I speak only for myself on that observation). I think that the re-proposal (as re-re-proposed; follow the boldface) does represent actual consensus on the usage, and also feel that consensus may change on the matter to make the line brighter, one way or another, some time in the future. It is better to have some advice on the issue than either no advice, or, worse yet, advice so obsolete that everyone ignores it (since the latter case simply weakens MoS as a whole - the more it is treated as optional or theoretical, the more wildly inconsistent WP articles will become). — SMcCandlish [ talk] [ cont] ‹(-¿-)› 00:10, 19 December 2007 (UTC)
[[1991 in music|1991]]
) in the main prose of an article in most cases. Use an explicit cross-reference, e.g. ''(see [[1991 in music]])''
, if it is appropriate to link a year to such an article at all. Exceptions:Best Rock Album [[Emmy Award|Emmy]]: [[1991 in music|1991]]
.[[January 1]], [[1991 in music|1991]]
) because they break the date-formatting function....in [[2007/2008 snooker season|the 2007/2008 season]]
, rather than ...in [[2007/2008 snooker season|2007/2008]]
. In particular, keep in mind that readers print out Wikipedia articles, so one must never use
"easter-egg" links, that hide the nature of what they link to, as in ...since his [[2006/2007 snooker season|previous failure]] to remain in the top-16
.[[2007/2008 snooker season|the 2007/2008]] [[Snooker world rankings|snooker season]]
or worse yet the [[2006 in music|2006]] [[2006 Country Music Awards|Country Music Awards]]
– if a very specific dated article exists, e.g. for an event, do not also link to the more general topical or regional one.[[1991 in music|1991]]
). Use an explicit cross-reference, e.g. ''(see [[1991 in music]])''
, if it is appropriate to link a year to such an article at all. Cases where piped date links might be tolerated are:
[[January 1]], [[1991 in music|1991]]
) because they break the date-formatting function.[Outdent.] Here's an attempt to merge the original, but pared down somewhat, and Lightmouse's new wording (modified in some cases where it lost important distinctions):
[[1991 in music|1991]]
), in most cases. Use an explicit cross-reference, e.g. ''(see [[1991 in music]])''
, if it is appropriate to link a year to such an article at all.
Best Rock Album [[Emmy Award|Emmy]]: [[1991 in music|1991]]
.[[January 1]], [[1991 in music|1991]]
) because they break the date-formatting function....in [[2007/2008 snooker season|the 2007/2008 season]]
, rather than ...in [[2007/2008 snooker season|2007/2008]]
. Some readers print out Wikipedia articles, so we do not use
"easter-egg" links, that hide the nature of what they link to, as in ...since his [[2006/2007 snooker season|previous failure]] to remain in the top 16
.the [[2006 in music|2006]] [[2006 Country Music Awards|Country Music Awards]]
.How's that?
Just to be clear, the point of all of this is to address all of the following:
If it can't address all of these points, then it is leaving something out, and shouldn't, in my opinion. — SMcCandlish [ talk] [ cont] ‹(-¿-)› 18:40, 4 January 2008 (UTC)
I am pleased to announce that we have a complete draft proposal for you to inspect, comment on, and modify.
Just go to the working group's development page, read the instructions at the top, and take it from there.
Or click "show" to see a draft, right here:
See a full draft of the proposal |
---|
|
– Noetica♬♩ Talk 07:05, 16 January 2008 (UTC)
Omegatron has recently made some changes to the main page however Omegatron did not first discuss those changes, i.e. he did not gain consensus for those changes. Since his changes remove certain important portions of the guideline I am reverting them as is correct and proper. Fnag aton 14:54, 16 January 2008 (UTC)
I'm sorry, but I'm not required to ask your permission before fixing a spelling error or smoothing the wording of a sentence. You don't
own this page, and you don't make policy by yourself.
If you or anyone else has a problem with one of my small changes (such as clarifying the bit that was tagged with {{ clarifyme}}, or moving "in 1999" to a different part of a sentence), improve on it by further editing the guideline directly, or discuss it here. Revert warring every change I made is antagonistic and unproductive.
As for the "first contributor" rule:
Without consensus for a site-wide guideline on the use of binary prefixes, the issue is decided on an article-by-article basis. If there is an issue with units on a particular article, that issue is decided on the talk page for that article. There is absolutely no reason why we would choose the "first contributor's" favorite style over one that makes more sense in a certain context.
I'm sure this was invented based on the English varieties rules. In these, the "first contributor" rule is a last resort, used when there isn't a better reason to choose one over the other. It's not a precedent to jump to whenever three people disagree with something, and it doesn't necessarily carry over to unrelated issues like units or punctuation or grammar.
The use of units isn't an issue where the differences are merely aesthetic and can be decided by an arbitrary rule. The different ways of using units have different purposes, and one may be more applicable than another in different contexts (just like British English is used in articles about Tolkien, even if the first contributor happened to prefer American).
If this really were the rule, it would enable editors like Sarenne or Fnagaton to go around creating articles in their preferred format and then telling others that it couldn't be changed because they were the "first contributor". (I wouldn't be surprised if this was the original intention behind trying to squeeze it into this guideline.) This is not how Wikipedia editing works.
Please try to edit productively and cooperatively. If you continue revert warring without justification, you'll be blocked. — Omegatron 15:50, 16 January 2008 (UTC)
Too much text in the above. What is the specific complaint with Omegatron's edit? "Does not have consensus" is not informative, especially when only one editor seems to have any objection. Going to Talk first is not some mandatory requirement for every last edit. If you specifically object to some part of the edit, then state that objection succinctly and let's skip past this "block him, no block him" business. — Aluvus t/ c 23:55, 16 January 2008 (UTC)
He changed the guideline in several places without talking about it first.
He removed this section "When in doubt, stay with established usage in the article, and follow the lead of the first major contributor."
He changed "Most publications" to "Many publications".
He changed "There is no consensus to use the newer IEC-recommended prefixes in Wikipedia articles to represent binary units", basically he changed it from "There is no consensus to use X" to "There is no consensus to use X or Y".
the other changes he has made are language changes designed to try to lessen or water down the meaning of the guideline.
Fnagaton: Please address what you think is wrong with the content of my edits. Consensus is decided by people addressing the content of each other's edits and discussing them. It is not decided by vote, or majority rule, or revert warring, or "procedure", or wikilawyering. You need to address what, specifically, you dislike about my edits or you have not demonstrated consensus for removing them.
No one person, and no (limited) group of people, can unilaterally declare that community consensus has changed, or that it is fixed and determined. ... Wikipedia's decisions are not based on the number of people who showed up and voted a particular way on a particular day. It is based on a system of good reasons. Attempts to change consensus must be based on a clear engagement with the reasons behind the current consensus.
Here. I'll help you out by spelling them out for you so you can address each individually:
That's all of the edits that you are revert warring without discussion. Please address each edit and explain what specifically is wrong with that edit. In other words, explain how the edit harms the project or misrepresents consensus on the use of units in Wikipedia. If all you're going to do is repeat "but you edited without discussing it first!" over and over, and revert all of my edits en masse without addressing what's wrong with them, then there's no point in me trying to discuss this with you further. — Omegatron 15:48, 19 January 2008 (UTC)
There are many units in common use that have slightly different meanings, depending on the context. Some examples, to name but a few, are gallon, megabyte, mile and ton. A specialist will be aware of the ambiguity and can often tell which meaning is intended. We are not writing for specialists though, but for a general audience that may not even realise that an ambiguity exists. The onus is on WP, and by implication on its editors, to make it clear from the outset.
Someone (it may have been Gene Nygaard) made the comment a while back that we should not forget our own real world knowledge just because we are writing for WP. I agree with him; we should use that knowledge to make WP less ambiguous.
Let me give an example to illustrate my point. The most common meanings of the unit ‘ton’ that I know of are long ton, short ton and metric ton. With or without context, I would have no idea which was intended myself in each case (and I imagine the same holds for our average reader). But an expert editor, familiar with standard practice in the shipping industry, would know that [1] (TomTheHand, 2 Dec 2007)
Now, let’s say that an expert editor is editing an existing WW2 article about a US naval ship. He’s an expert so let’s assume he knows that the word “ton” means “long ton” in this context. Well, in that case our expert editor can improve the article by stating on first use that by “ton”, “long ton” is intended throughout, and WP will have improved by becoming an iota less ambiguous.
Specifically, what I would like to see is something like this:
On its own a link to ton would not be enough. That points out the ambiguity but does little to help the reader work out which meaning is being used. A simple statement on first use like “The ship's displacement was 2,000 tons ( long tons)” would suffice in most cases. The bullet could be followed by a helpful list of ambiguous units in common use. Thunderbird2 ( talk) 22:09, 17 January 2008 (UTC)
How should an assumed birthday (which may be correct), be listed? -thanks Byzerodivide ( talk) 01:44, 19 January 2008 (UTC)
Editors are invited to join a discussion at WT:MOS. We present the working group's completed proposal for new hard-space markup, and call for your suggestions.
– Noetica♬♩ Talk 03:46, 21 January 2008 (UTC)
What's the preferred way of doing birth/death dates? Wikipedia:Manual of Style (dates and numbers)#Dates says ISO dates are not common within prose but the birth/death dates in the first sentence of a typical biography — "Joe Bloggs ( January 1 1900 – December 31 1980)" — aren't really prose per se. On the other hand, Wikipedia:Manual of Style (dates and numbers)#Dates of birth and death doesn't give any ISO examples either. What is the community consensus about this? Thanks. howcheng { chat} 01:34, 18 January 2008 (UTC)
Which of these is correct: "the 5 mile (8 km) road" or "the five-mile road"? Thanks. Epbr123 ( talk) 19:35, 29 January 2008 (UTC)
An issue has arisen in Meter. User:Greg L has quite rightly edited the article so that instead of using a mixture of styles, it now uses commas to group large numbers into groups of 3 digits. However, there is still inconsistency in dealing with digits to the right of the decimal point. One example is:
Consequently, a practical realisation of the metre is usually delineated (not defined) today in labs as 1,579,800.762 042(33) wavelengths of helium-neon laser light in a vacuum.
Another example is "0.03937 inch".
I believe the Chicago Manual of Style says to not use spaces, commas, or anything other grouping symbol to the right of the decimal point, but as far as I can see, Wikipedia's MOS does not address this. So what should we do? -- Gerry Ashton ( talk) 19:43, 15 December 2007 (UTC)
There are currently two practices for delimiting numbers in the mantissa: spaces, and commas. It’s currently a free-for-all in the decimal place and only two practices are observed: 1) delimiting with a space, or 2) no delimiting whatsoever. Clearly, long chains of decimals in a row are extremely hard to parse and demand to be delimited. Trying to get all contributors to provide spaces in the decimal portion of numbers would be difficult but I would hope that official Wikipedia policy would be that the preferred method of numeric notation to the right of the decimal place is to delimit every three digits with non-breaking spaces {exceptions would be 1) where the last group consists of four digits and 2) where a group of five digits is delimited so the last group comprises two digits}. Further, I would propose that Wikipeida would recognize that the best practice is to permit the use of reduced-size non-breaking spaces (i.e. <font size="-1"> </font>
), which is an SI-compliant form that observes best typography practices. Examples:
Best typography practices:
3.141 592 6535 and 1,579,800.762 04
Acceptable delimiting:
3.141 592 6535 and 1,579,800.762 04
Further of course, the Euro practice of delimiting the mantissa with non-breaking spaces (preferably reduced-size ones) would also be acceptable.
Clearly, my proposal also holds that practices like “1.414213562373095” should be strongly discouraged or prohibited.
1,579,800
1,579,800.762045
1,579,800.762 045
1 579 800
1 579 800.762
1 579 800.762 045
1 579 800.762045
All the spaces are narrow, non-breaking ones coded as <font size="-1"> </font>
. Excel only treats the top two entries as numeric values. To see for yourself, just copy all seven entries, select a single cell in Excel, paste, and set up the adjacent column to multiply the pasted values by 2. Excel reports #VALUE! for the bottom five; Excel doesn’t care whether the spaces are regular, full-size spaces or these narrow, non-breaking ones. As you can see though, all the entries using Euro-style delimiting (spaces) in the mantissa (the bottom four entries) already aren’t compatible with Excel.
I think it is clear that the readability benefits of delimiting to the right of the decimal point far outweighs this minor inconvenience. I’ve long edited all my articles this way and have had many occasions to copy the values to Excel. It’s easy enough to hand-delete the spaces after pasting; this paste/edit method best ensures accuracy. Too, I agree with your final conclusion: “people probably don't do that often enough to worry about it.” Note further that the only entries above that would become non-compliant under my proposal are the second one down and the last one (as well as this abomination: 1.414213562373095). Greg L ( my talk) 00:27, 16 December 2007 (UTC)
{{formatnum:}}
(used extensively by templates) gives commas before the decimal point and no delimination afterwards, we should keep consistant with this.
J
ɪ
m
p
08:14, 18 December 2007 (UTC){{formatnum:123456.789012}}
gives you 123,456.789012. The formatting it uses is commas before and nothing after the decimal point. Unless we also use this elsewhere we'll end up with inconsistancy.
J
ɪ
m
p
19:39, 18 December 2007 (UTC)Proposed alternative: <span style="margin-left:0.2em">
1.234567890. requires 39 characters per group as compared to 21 for a small nbsp. And commas could be used to the left of the decimal point, so it'd only be needed when there are large numbers of digits to the right.—
Random832
16:26, 18 December 2007 (UTC)
Part of this discussion is whether anyone actually reads all those digits to the right of the decimal. While I seldom read them, I sometimes count how many there are, so I can understand what the precision of the number is. Grouping helps with this. -- Gerry Ashton ( talk) 19:56, 18 December 2007 (UTC)
{{formatnum:141421.35623731}}
modified so it automatically generates 141,421.35623731 and further, I would hope that the template would support the expression of uncertainty in ‘concise form’ (the parenthetical suffix digits). By the way, I used “0.3em” here, which I think is easier to read.
Greg L (
my talk)
20:50, 19 December 2007 (UTC)UPDATE: Well, that was an interesting experiment.
J
ɪ
m
p’s mentioning of span control (a feature I didn’t know about) offers a huge advantage. Please see preceding post from me for context. When numbers like this: 141,421.35623731
…are created simply by controlling pair kerning using “em”-based span control like this: 141,421.356<span style="margin-left:0.3em">237</span><span style="margin-left:0.3em">31</span>
…you can paste the displayed values into Exel. This strikes me as a win/win. I would propose that the {{formatnum}} template be modified to generate ‘Excel-pasteable’ numbers like this, and further, that the template supports concise notation for uncertainties.
I’ve already updated Kilogram with span-controlled numbers. To see examples, examine the article starting here. As you will see, it will be a rare number indeed that simultaneously requires delimiting in both its mantissa and its decimal side. Values with expansive decimal sections requiring delimiting rarely have mantissas greater than three or four digits. In other words, a template that functions as I am proposing here would typically be used to generate values that are an “either/or” proposition: for any given value, the expansive portion requiring delimiting will usually only be found on one side of the decimal point.
I would specifically propose that {{formatnum:60451.02214179}}
would return 60,451.02214179
…and variations of {{formatnum:6.0221417912}}
would further generate the following values:
6.02214179
6.022141791
6.0221417912
6.02214179123
Further, I would propose that {{formatnum:6.02214179|30}}
would return 6.02214179(30)
Go ahead, copy all four of the above maroon-colored values and paste them into Excel; works great.
Greg L ( my talk) 22:30, 19 December 2007 (UTC)
<span>
must have a </span>
or it must be <span ... />
And <br>
should be <br />
(yes, I'm aware that the MediaWiki software is smart enough to compensate for the latter type of error, but this is no reason to use deprecated markup; our code, like our facts, ought to be exemplary. Speaking of which, it is also best to terminate CSS directives with ";", since others may be added later in which case they must be semicolon-separated: style="margin-left:0.3em;"
—
SMcCandlish [
talk] [
cont] ‹(-¿-)›
01:11, 20 December 2007 (UTC)
So now the question to all of the rest of you (Jimp too) becomes: does the 0.2-em spacing shown in the picture at right match what you see?
As for you Jimp, I just checked out your answer below. It seems I’ve accidentally gotten your hackles up and you’ve gotten steamed. I no longer appreciate your tone (it’s uncivil) and no longer care to participate here whatsoever. Goodby. Greg L ( my talk) 02:29, 21 December 2007 (UTC)
Jimp, apology accepted. Now let’s ‘get dirty’ in the technical details. Shown below are various ways of delimiting the remainder. To the right is how it appears on my system.
6.02241679
6.022416794
6.0224167942
6.02241679423
6.02241679
6.022416794
6.0224167942
6.02241679423
6.02241679
6.022416794
6.0224167942
6.02241679423
6.02241679
6.022416794
6.0224167942
6.02241679423
6.022 416 79
6.022 416 794
6.022 416 7942
6.022 416 794 23
6.02241679
6.022416794
6.0224167942
6.02241679423
Shown above is how
delimiting appears with
live text on your
system.
As you can see, my system (at least) does not treat 0.25 em different from 0.3 em. Also on my system, 0.3 em is about midway between 0.2 em and a non-breaking space. How does this all appear on your systems? A subjective but simple way to communicate the appearance on your system is just to declare whether or not the text-based version (on the left) appears similar to the photo on the right. To my eye, the 0.2-em option on the right (what I see) seems too crowded; that is, the delimiting is hard to discern. Greg L ( my talk) 06:08, 21 December 2007 (UTC)
<span style="margin-left:0.3em;">
is a perfect solution to the copy-&-pastability problem, note also that these spaces are non-breaking (an essential feature).<span style="margin-left:0.3em;">
display correctly in common browsers? This is the consideration is that killed the use of  
. If this is to be implimented I would suggest, for consistency, that {{formatnum:}}
be modified rather than have {{formatnum-therival:}}
created.{{formatnum:}}
(or whatever other thing we pull out of our hat) for fat breaking non-copy-&-pasteable spaces are not what we want.
J
ɪ
m
p
02:45, 20 December 2007 (UTC)We don’t have to agree that Wikipedia should adopt one style or the other with regard to delimiting the mantissa…nor should we. We can simply make two versions of a numbering template (or an option to check in a single template). Trying to necessarily link the treatment of the decimal portion to how we delimit the mantissa will only doom to failure any efforts here. We should address only one issue: should a template be made to make it easier to delimit the decimal portions to make long strings easier to read(?). My point would be that narrow spaces are so damn easy to read, that even a novice who has never seen it before instantly understands what it’s all about. And in articles where numbers are important, delimiting is crucial because long strings of non-delimited digits to the right of the decimal point unusable to the point of being barbaric. There should be an easy way for others to do so (rather than hand-coding it all). Greg L ( my talk) 03:59, 20 December 2007 (UTC)
{{formatnum:}}
which produces it with no optional formatting (note also that this is {{formatnum:}}
not {{formatnum}}
... a "magic word" no template ... ordinary folk like us can't edit it). If "Trying to necessarily link the treatment of the decimal portion to how we delimit the mantissa will only doom to failure any efforts here.", so be it.
J
ɪ
m
p
04:54, 20 December 2007 (UTC)Wikipedia policy (and the every-day practices here on all of Wikipedia’s articles) is clear: Both European (British) English and American English are recognized as correct. The hat is tipped to one way or another based mainly on two criteria: 1) The style the first major contributor to an article used becomes the standard for that article, and 2) if the subject is about a country or subject that is closely attached to a particular country, then that country’s spelling, punctuation, and formatting conventions would be observed. If you don’t believe me, check out Metre / Meter and note that it uses British English throughout. Go try and “correct” realise to realize. May God be with you. ;-)
Note further that Wikipedia’s supposed even-handed policy regarding national conventions isn’t as even handed as it seems; Wikipedia has standardized on using a full-stop (.) as a decimal point. Europeans readily adapt to reading the style used in their countries and to reading the American style, which is heavily represented in print, the Web, and (especially) in scientific literature. So…
Americans are already getting their way with the decimal point. Further, most Wikipedia articles use commas to delimit the mantissa. It’s the well recognized American way of doing things that Europeans readily recognize and accept. This leaves only the issue of delimiting the decimal side of things. It’s a straightforward solution.
If, as you say, there should be one format, then IMO, it should be comma-delimited mantissa|full-stop decimal separator|narrow space-delmited remainder
. That is the closest to a universal method that one can obtain. Although highly biased towards American conventions, Europeans are quite flexible because they speak multiple languages and are familiar with entirely different formatting styles.
Lest I seem biased towards the American-way of doing things, I’m not. I just realize that there is no fighting the ever-expanding method of American writing style. I’ve worked with a Swedish-American engineer. He was bragging to a Swedish friend of his who was visiting. The engineer told him he had presented a scientific paper at an English-speaking conference. “Wow” said his friend. And he had done it in American English. “Wow” said his friend. Personally, I do all my design in metric (it’s the only way to go) and only do final conversion to inches etc. when the prints go to a machine shop. There are a variety of European conventions I like. My wife and I visited a number of European countries this summer. The ground floor on elevators are level “0” (zero). The floors above are 1, 2, etc. The first level below (the top-most) basement is -1, then -2 etc. How logical is that? My main point is that I don’t want to come across as biased for advocating an American way of doing things.
Trying to format numbers in a European way would baffle Americans. Conversely, the American way of formatting numbers is readily accepted by other English-speaking countries simply because they are more sophisticated than Americans (don’t bother whining to me about that statement; it’s true). So it’s a simple solution: comma-delimiting of mantissas, ful-stop decimal marker, and narrow spaces for the remainder. That’s what will work best given what reality has thrown us. Greg L ( my talk) 19:20, 20 December 2007 (UTC)
{{formatnum:}}
could be tweaked such that the user could go to his/her "preferences" and choose his/her number formatting scheme. The defualt would remain commas-point-nothing but there'd be the option of commas-point-spaces or spaces-point-spaces (or some other option, perhaps). Then we'd have the best of both worlds. Of course, it would be up to the developers to impliment such a thing ... and considering how promptly they're dealing with the disentanglement of date autoformatting and linking, let's not get our hopes up.
J
ɪ
m
p
06:19, 20 December 2007 (UTC)You’ve already made your fantastically well-considered vote and I don’t expect that anything I write here will make one twit of a difference in how you vote. I agree, the “chaotic spaghetti of discourse” is hard to track. That’s still no excuse for voting on an issue you admit to not even understanding! What’s wrong with you that you can’t see that? I didn’t do the page layout on this section; it’s the product of many people in a rapid back & forth debate. You could go in a clean it up just as well as anyone else here but I don’t see you volunteering. Given the history of your contributions (music-related topics), I also am quite skeptical that your interest in this topic is anything more than just passing. Tony: as regards alleging I made a “personal attack” here’s what the Wikipedia:No personal attacks article says:
There is no bright-line rule about what constitutes a personal attack as opposed to constructive discussion, but some types of comments are never acceptable:
- Racial, sexual, homophobic, ageist, religious, political, ethnic, or other epithets (such as against disabled people) directed against another contributor. Disagreement over what constitutes a religion, race, sexual preference, or ethnicity is not a legitimate excuse.
- Using someone's affiliations as a means of dismissing or discrediting their views -- regardless of whether said affiliations are mainstream or extreme.
- Threats of legal action.
- Threats of violence, particularly death threats.
- Threats of vandalism to userpages or talk pages.
- Threats or actions which expose other Wikipedia editors to political, religious or other persecution by government, their employer or any others. Violations of this sort may result in a block for an extended period of time, which may be applied immediately by any administrator upon discovery. Admins applying such sanctions should confidentially notify the members of the Arbitration Committee of what they have done and why.
As you can see, saying that I think what you wrote is hogwash and is without merit falls about a light-year short of “personal attack” as defined by A) common sense, and 2) Wikipedia. I’m saying your idea sucks, as was your fundamental position on this subject, as was the way you went out of your way trying to take the high road and seek out ways to criticize others who don’t produce well laid-out discussions pages so you can arrive late in the game and have to actually read and parse what’s here to understand it! Too bad. I have my opinion on the constructiveness of what I call your “drive-by shooting” on this topic: just enough of a cursory visit to make a glib pronouncement of how everyone hasn’t done a good enough of a job to meet your lofty standards. A “total disgrace”(?) P-u-h-l-e-e-z-e. Do you think the people here trying to hammer out technical details of delimiting numeric strings need some sort of benediction from you when you arrive late to the discussion? Just who in the world do you think you are? You want me to retract what I truly feel? That’s my opinion of what you wrote above and I’m sticking to it. Do you think Wikipedia gives you the entitlement of being free of well-deserved criticism and critical commentary on every damn thing you write? Everyone on Wikipedia deserves to be free from “personal attacks” as defined as Wikipedia above, and everyone needs to be treated civilly. Simultaneously, I can call B.S. garbage that anyone writes as I see it: “garbage”. If you disagree with me on this, then we’ll have to agree to disagree.
Finally, I am quite done dealing with you—or anyone else for that matter—here in this forum. Don’t chase me down and leave messages on my talk page. I don’t have to deal with you any more and I don’t have to deal with this topic here any more. OK? You won’t have to be all indignant over how Greg L didn’t give you a pat on your head for what you wrote because I’m done here. Goodbye. Greg L ( my talk) 06:07, 28 December 2007 (UTC)
<giggle> Tony (talk) 06:30, 28 December 2007 (UTC)
Please, for the love of $deity, can someone point me in the write direction to put forth a recommendation that we use the international / universal dating convention of DD/MM/YYYY rather than MM/DD/YYYY as is becoming prolific. Whilst I appreciate this is due to many of our editors and authors being of American origin, and no one system is correct, the most widely used system is smallest to largest, not medium to smallest to largest and we should perhaps adhere to that more stringently. At present reverting the use of two styles for dating will be a lot of work, but the longer we leave it the worse it will get. 58.107.154.192 ( talk) 02:51, 3 February 2008 (UTC)
An editor has recently changed "9th century" to "ninth ..." and several similar changes, in Bath, Somerset. MOSNUM says "Use numerals for centuries (the 17th century); do not capitalize century. " The example isn't as powerful as it could be, as "17" would be written as a number in any case. Could we change the wording to "Use numerals for centuries (the 9th century); do not capitalize century."? PamD ( talk) 00:43, 27 January 2008 (UTC)
This page is 657KB; every time I try to edit I get an edit conflict or hung on load time. SandyGeorgia ( Talk) 05:00, 1 February 2008 (UTC)
Dear fellow colleagues: the idea is to centralise debate and consensus-gathering when there are inconsistencies between the pages. The most straightforward way is to have MOS-central prevail, and to involve expertise from sub-pages on the talk page there, rather than the fragmentary discourse—more usually the absence of discourse and the continuing inconsistency—that characterises WP's style guideline resources now. Of course, no one owns MOS-central, and we're all just as important to its running as other editors. I ask for your support and feedback HERE. Tony (talk) 12:12, 5 February 2008 (UTC)
Unless an article is discussing the sale of cherries, strawberries or something similar (cherries and strawberries are what came to mind first), the likelihood of encountering a U.S. dry pint or quart is highly unlikely. I checked and I couldn't find any occurrences and dry pints and quarts are not likely enough to include a provision about them in the MOS. Also, there really isn't a need to include liquid in front of U.S. pints and quarts either. When measuring beer, motor oil, trans fluid, water, et cetera, it is somewhat clear that a liquid is being measured. That being said, I've removed the line from the style guide about "quarts". If there is an argument for keeping it in, I'd like to hear it. Regards, — MJCdetroit (yak) 16:53, 5 February 2008 (UTC)
The line for [[May 15]] [[2005]] is not correct. When there is no comma in this format in the wikitext, a comma is added for (at least some) IPs and users with no date preference. Likewise, for [[15 May]], [[2005]] the comma is removed for (at least some) IPs and users without preferences. Gimmetrow 23:16, 6 February 2008 (UTC)
To answer Gimmetrow's question about "14 February, 1991": yes, if the brackets are inserted, as you and I understood, it does display as an "acceptable" format. If the brackets are removed (and some editors will do that), then it will display in a format that is not "acceptable". I also think that the comma acts as a "speed bump" (US translation) or "sleeping policeman" (UK translation) for some editors. I can see no reason to encourage "14 February, 1991" when "14 February 1991" is the "acceptable" format and works just fine. On the other hand, I wouldn't edit an article just to remove the comma. Chris the speller ( talk) 04:00, 10 February 2008 (UTC)
Please look at Norwich City F.C. and its recent edit history. It is a featured article but I believe that the way it handles dates is poor. For example some date links are broken and it had solitary months linked. It would be relatively easy for a few editors to correct this. However as a general point I wonder if the featured article process is allowing these things through? Lightmouse ( talk) 12:40, 7 February 2008 (UTC)
Please see this example. Tony (talk) 12:51, 7 February 2008 (UTC)
It might be helpful to give slightly more information. The issue is the placement of AD (anno Domini). This page says that we should write "AD 1066" while WP:MOS says that both "AD 1066" and "1066 AD" are acceptable. The discussion in the section that Tony linked to has strayed a bit from the topic, but I hope that the section Wikipedia talk:Manual of Style#Resolving the AD issue itself will stay on the narrow issue of where to place AD. Your comments there would be most welcome. -- Jitse Niesen ( talk) 21:58, 9 February 2008 (UTC)
Well, some friends and I went off and spent the last month working on this issue here on my talk page. Temporarily moving to a forum where I had greater liberty to rearrange and revise things after-the-fact kept things much more manageable and understandable and allowed rapid and constructive progress. Unfortunately, it takes things off the radar too much and makes it impossible to obtain a consensus here. So I’ve transplanted the below work product from my talk page. To avoid the confusion that Noetica pointed out above, I will, where necessary, take the liberty here of rearranging things after-the-fact (after people have responded) but will do so in ways that make it clear who was responding to what. I think this will be necessary to keep this complex topic organized and understandable.
Below are the latest specifics of the proposal:
{{delimitnum:6.02246479|30|23|kg}}
in order to obtain the following: 6.02246479(30) × 1023 kgThe parenthetical (30) in the above value denotes the uncertainty at 1σ standard deviation (68% confidence level) in the two least significant digits of the significand.
6.022<span style="margin-left:0.25em">464<span style="margin-left:0.25em">79</span></span>(30)
× 10<sup>23</sup> kg
(*Phew*)
) on both sides of the “times” (×) symbol and just before the unit symbol. Thus, there would be no line-end occurrences like the following:
{{frac|2}}
produces 1⁄2 and {{frac|10|11}}
produces 10⁄11. For instance, one need only type {{delimitnum:6.022464}}
to obtain 6.022464 or they could type {{delimitnum:1579800.298728}}
to obtain 1,579,800.298728{{delimitnum:1.356392733||50|Hz}}
yields 1.356392733 × 1050 Hz and {{delimitnum:0.45359237|||kg}}
yields 0.45359237 kg
2.1
2.12
2.123
2.1234
2.12345
2.123456
2.1234567
2.12345678
2.123456789
2.1234567890
2.12345678901
2.123456789012
2.1234567890123
The logic tree underlying this parsing method is shown in Digit-counting parsing logic, below.
This template/parser function will avoid future occurances of editors hand-coding improper, hanging digits—as exemplified
in this section of Font size, which features this numeric string: 0.187 985 755 2 mm
<span style="margin-left:0.25em">
). Margin positioning is part of what the Web-authoring community calls
span tags, which, in turn, is part of
Cascading Style Sheets (CSS). Effectively, what appears to be a space would really only be a visual effect caused by the precise placement of the digits; the “spaces” wouldn’t be separate, typeable characters.To see the difference, slowly select the two values below with your mouse:
</span>
. Note the example code shown in the third bullet item down in this list.{{delimitnum:6.02214179|30|23|kg}}
→ 6.02214179(30) × 1023 kg{{delimitnum:1579800.298728}}
→ 1,579,800.298728{{delimitnum:1.356392733||50|Hz}}
→ 1.356392733 × 1050 Hz{{delimitnum:0.45359237|||kg}}
→ 0.45359237 kg{{delimitnum:6.022461}}
→ 6.022461{{delimitnum:6.0224613}}
→ 6.0224613{{delimitnum:6.02246134}}
→ 6.02246134{{delimitnum:6.022461342}}
→ 6.022461342
Q2: Is the span gap to be added following the digit “1”? No=Add a span gap of 0.25 em and then goto Q1 / Yes=Add a span gap of 0.2 em and then goto Q1.
In any discussion of delimiting numbers to the right of the decimal marker with gaps, we must also settle on what to do to with the integer portion of the significand (the left-hand side of the decimal marker). I advocate using commas for two reasons:
Note the above examples (copied from Kilogram and Font size). In those examples, only the third example (the definition of the meter) has five or more digits in both the integral and fractional portions of the significand. All the others require delimiting only on one side of the decimal marker or the other, but not both. Greg L ( my talk) 20:06, 31 January 2008 (UTC)
I’ve seen many Wikipedia articles that feature space-delimited numbers to the right of the decimal marker and they’ve been stable for years without one single “drive-by shooting” by an unregistered editor-in-a-hurry attempting to “fix” the ‘funny-looking’ values. Font size is just one such example; there are too many Wikipedia articles to count. This is clear proof that essentially all readers readily recognize that what they’re looking at are space-delimited numeric values. If this can occur with full-width spaces, then reduced-width ones—which just look “right”—will be even easier and more natural for readers. Delimiting numeric strings to the right of the decimal marker serves precisely the same purpose as does doing so to the left of the marker and is very much needed. Greg L ( my talk) 19:42, 1 February 2008 (UTC)
In
“Continuing Discussion” below, Tony asked whether MOSNUM policy regarding the use of this template/parser function should be “framed as mandatory or optional”, my suggestion would be a formal policy as follows:
6.022461342
so they have the following appearance: 6.022461342 (making them easier to parse) and simultaneously retains their functionality as
Excel-pasteable numeric values.In furtherance of this policy, the fractional portion of significands may no longer be delimited using either spaces or
non-breaking spaces (e.g. coding 0.187 985 755<
or 0.187 985 755
to produce 0.187 985 755) because such text strings can break at line-end
word wraps and/or are not treated as numeric values when pasted into Excel. Values such as these should be irreversibly “upgraded” via use of {{delimitnum}}. “Irreversibly” means that it is impermissible to convert a value that is delimited with {{delimitnum}} to a simple, non-delimited numeric string.
Further, numeric equivalencies that can wrap between the value and its unit symbol (e.g. 75.2 kg), as well as numeric values expressed in scientific notation (e.g. 15.25 × 106) that were neither created with the {{e}} template nor unified with a non-breaking space and can therefore wrap on either side of its times symbol (×), should be “upgraded” via either 1) the use of non-breaking spaces, 2) use of the {{nowrap}} template, or 3) use of {{delimitnum}}—exclusively so if the value has 5+ fractional-side digits.
The effect of this is that new editors who don’t know of the template/parser function or how to use it wouldn’t be doing anything “wrong” when they write “3,210.123456”. Existing, hand-entered values like this, which meet the proposed MOSNUM policy, would be considered as acceptable (though not ideal) and may be irreversibly upgraded. Articles like Font size, which use the non-Excel-pasteable non-breaking spaces (and also leave dangling single digits) would become “incorrect” and should be irreversibly upgraded. Greg L ( my talk) 07:59, 13 February 2008 (UTC)
a. | Numbers cannot be copied and pasted as numbers into another application if they contain spaces. | |
b. | Commas then no delimiting is the accepted standard on Wikipedia. | |
c. | Commas then no delimiting is the the norm in English. |
{{#expr:1,234*56}}
won't work).{{formatnum:}}
produces no spaces after the decimal point.{{formatnum:}}
adapted accordingly.15 625 / 83 118 ≈ 0.187 985 755 2 mm
hard to read. It took me a second to realize the left-hand side was the ratio of two five-digit numbers, and more time to realize that both sides were intended to be in mm. Septentrionalis PMAnderson 15:27, 14 February 2008 (UTC)
We should limit our efforts here to agreeing on a policy—and developing a tool—that avoids instances of 0.187 985 755 2 mm, which (*sound of “raz” buzzer noise*) leaves a hanging digit and (*buzz*) uses full-width spaces and (*buzz*) can’t be pasted into Excel. A tool that automates delimiting to the right of the decimal marker will also make expressions such as e = 2.718281828459 far more readable. Greg L ( my talk) 18:32, 14 February 2008 (UTC)
Note that 2.718281828459 had
long appeared in
Natural logarithm until only a few weeks ago. When
I changed it and explained that the value is now delimited and Excel-pasteable, it has been readily accepted even though the code required to do so is expansive. Giving authors a tool so all they have to type is {{delimitnum:2.718281828459}}
will be extremely well received in my opinion.
The proposed {{delimitnum}} parser function wouldn’t change the way digits are currently delimited to the left of the decimal marker. What it does do is allow authors to quickly and easily produce easy-to-parse, non-wrapping, Excel-pasteable, properly delimited numeric values when they have five or more digits to the right. Greg L ( my talk) 01:09, 15 February 2008 (UTC)
{{formatnum:}}
. How would we be able to make such a thing possible? Unless this is adopted as the standard formatting I don't believe we've got a chance.
J
ɪ
m
p
03:41, 15 February 2008 (UTC)
</span>
. I realize I didn’t explicity point out the closing of spans out so I’ve taken the liberty of adding a bullet point regarding this into the
“Overview” section, above. But let it be noted here that this information wasn’t there before your above-posted question. Thanks.Regarding why a 0.2-em gap is occasionally used rather than the more common 0.25-em gap, see Gap width details, above (scroll to the bottom of that subsection). The short answer though, is that the 0.2-em gap follows the digit 1. It slightly tightens the gap following the digit 1, which is important because the eye is sensitive to overly wide gaps, which can begin looking like separate numbers if not kept tight. P.S. Noting that this too wasn’t nearly explicit enough, I added a short paragraph to that section regarding the slightly thinner gap following the digit 1. Let it be here-known that this too wasn’t there until after your question.
As to your last question (is {{formatunum}} going to be messed with), not to my knowledge. I don’t think anyone is proposing such and I am certainly not advocating it since doing so might have deleterious effects in existing articles. It would simply be a new magic word called {{delimitnum}}. Greg L ( my talk) 07:39, 15 February 2008 (UTC)
I have noticed that I sometimes have odd problems when bolding and italicizing using ''
(straight single quotes) if I have span-based delimiting in the paragraph. So what you’re saying might well be the case. Thanks.
Greg L (
my talk)
00:06, 16 February 2008 (UTC)
2.718<span style="margin-left:0.25em">281</span><span style="margin-left:0.2em">828</span><span style="margin-left:0.25em">459</span>
. Although it’s the same amount of finger wear, would placing the close-spans all at the end, like this: 2.718<span style="margin-left:0.25em">281<span style="margin-left:0.2em">828<span style="margin-left:0.25em">459</span></span></span>
be OK too? The only virtue is—for some people—it might make it a little easier to parse the code one writes. You take a number, paste the spans every three digits, and then paste the required number of close-spans. This method also generates the value “2.718281828459”. So let me check alignment after a font check of italicizing and bolding and italicized bolding. That all seems to work bug-free. What if I try to bold the delimited value: 2.718281828459. I think that one would have given me flack before. And what about alignment of a new paragraph?Yup, a new paragraph aligns well. Is this “save ‘em to the end” method OK too? Greg L ( my talk) 02:29, 16 February 2008 (UTC)
P.S. I’ve revised the third and eighth bullet items in Overview, above per both your teachings. Greg L ( my talk) 05:27, 16 February 2008 (UTC)
I believe broader consensus is required before asking for someone to devote time to coding this. So far as I know, outside Wikipedia, the appearance of number separations may be outlined thus:
The existing rules in WP:MOS and WP:MOSNUM were chosen from the above options. Since no one uses comma separators in the integer part combined with thin space separators in the fraction part (remember, I'm talking about appearance) the existing rules should not be read to mean that the fraction part is fair game. It would be necessary to gain consensus on both talk pages for the concept of the appearance of thin spaces in the fraction part. -- Gerry Ashton ( talk) 06:09, 15 February 2008 (UTC)
As also addressed in the proposal at Rationale for using “comma delimiting” with “narrow-gap delimiting above, “it will be a rare number where commas (a U.S. style) and narrow spaces (a European/SI style) are juxtaposed within a single value.”
What has also been covered in Making a case for why narrow gaps are already well-accepted on Wikipedia, above (and elsewhere throughout these discussions) is that the use of spaces to delimit values on the fractional side is today a common practice on the English Wikipedia pages. And why are editors using spaces to delimit the fractional portion? Because of this obvious truth: delimiting numeric strings to the right of the decimal marker serves precisely the same purpose as does doing so to the left of the marker and is very much needed on Wikipedia. However, it’s very often being done incorrectly and the resulting efforts are 1) inconsistent, 2) don’t look good due to the full-width spaces, 3) occasionally improperly leave single dangling digits, 4) often do line-end word wraps within the value, and 5) the values can’t be copied and directly pasted into Excel.
Hand coding 6.022<span style="margin-left:0.25em">464<span style="margin-left:0.25em">79</span></span>
× 10<sup>23</sup> kg
to produce 6.02246479 × 1023 kg address all these shortcomings but is extremely cumbersome and inflates the size of articles.
All these shortcomings—with a practice that is already widespread on the English Wikipedia—are addressed with this convenient tool.
Finally, as regards your assertion that it is “necessary to gain consensus on both [WP:MOS and WP:MOSNUM] talk pages,” that makes no sense whatsoever and frankly strikes me as a metric ton of weapons-grade bullonium. Wikipedia would grind to a complete halt and nothing could ever get accomplished if simultaneous and/or duplicate discussions had to occur across multiple forums! Talk:MOSNUM is clearly the proper and logical forum for this topic; that’s why it exists. Greg L ( my talk) 08:26, 15 February 2008 (UTC)
I oppose this proposal on the grounds that it is a bastard. -- Gerry Ashton ( talk) 17:39, 15 February 2008 (UTC)
Congratulations to all; the proposal was accepted and presented to a developer on 02-15-08 to be made into a parser function. Thanks for your passionate and hard work on this {{delimitnum}} proposal. As many of you have no doubt noticed, the debates and comments here resulted in my having to go back to the Overview section many many times to modify and/or add bullet points to incorporate your many observations and suggestions.
It might be a bit premature to check-mark this as resolved (and move it to an archive) as technical issues may arise during the developer’s work. Currently, the Overview section serves as a concise central reference source/depository that can be conveniently updated when corrections and additionals are required. I suggest we leave this here and archive it after the parser function is delivered.
In advance, thanks to the anonymous developer(s) quietly volunteering their time in the background to provide us the tools that make our editing life easier.
Greg L ( my talk) 05:56, 16 February 2008 (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 90 | ← | Archive 92 | Archive 93 | Archive 94 | Archive 95 | Archive 96 | → | Archive 100 |
This is merger of several related discussions and proposals. — SMcCandlish [ talk] [ cont] ‹(-¿-)› 00:07, 19 December 2007 (UTC)
I'm looking for some clarification about when dates should be linked. In the Autoformatting and linking section of the MOS, the last bullet reads:
"Wikipedia has articles on days of the year, years, decades, centuries and millennia. Link to one of these pages only if it is likely to deepen readers' understanding of a topic. Piped links to pages that are more focused on a topic are possible (
[[1997 in South African sport|1997]]
), but cannot be used in full dates, where they break the date-linking function."
Does the sentence in boldface (my emphasis) mean:
1. That dates (using any combiations of days, months, and year) should only be linked if the linked date will add to the reader's understanding.
2. That only full dates (i.e.
November 1,
2007) should be linked, but not dates like
November
2007.
Another Wiki user has been trying to tell me that the latter is the case, while I have been trying to indicate that the first meaning is correct. (The discussion can be viewed here: User_talk:NatureBoyMD.) Which is correct? - NatureBoyMD 21:26, 11 October 2007 (UTC)
The albums project contains the following:
[[1991 in music|1991]]
, instead add (see
1991 in music) where you feel it is appropriate.I propose that we make that generic and include it. Lightmouse 11:09, 15 November 2007 (UTC)
[[1991 in music|1991]]
can make perfect sense in a table, for example.
Septentrionalis
PMAnderson
06:32, 23 November 2007 (UTC)
[[1997 in South African sport|1997]]
), but cannot be used in full dates, where they break the date-linking function.[[1991 in music|1991]]
) in the main prose of an article. Use "(see [[1991 in music]])", if it is appropriate to link a year to such an article at all. In places where compact presetation is important (some tables, infoboxes and lists), piped links may be useful. Piped links must never be used in full dates (e.g. [[January 1]], [[1991 in music|1991]]
) because they break the date-formatting function. Piped topical year links should only be made when the event in question is genuinely notable in the context of the year article to which would link.New version to address issue raised by Woody:
[[1991 in music|1991]]
) in the main prose of an article. Use an explicit cross-reference, e.g. ''(see [[1991 in music]])''
, if it is appropriate to link a year to such an article at all. In places where compact presentation is important (some tables, infoboxes and lists), piped links may be useful. Another exception is the main prose of articles in which such links are used heavily, as if often the case with sportsperson biographies that link to numerous separate season articles, in which the ''(see ...)''
phrasing would rapidly become repetitive and cluttering; in such a case it is best to make it clear that the link is to such a topical date article, e.g. in [[2007/2008 snooker season|the 2007/2008 season]]
, rather than in [[2007/2008 snooker season|2007/2008]]
. Piped links must never be used in full dates (e.g. [[January 1]], [[1991 in music|1991]]
) because they break the date-formatting function. Topical date links should only be used when the event in question is genuinely notable in the context of the year (or month, etc.) article to which would link.Revised version below.
I think this will adequately address the cases that need to be addressed so far, and would actually slightly help advance the growing consensus that a replacement for the date formatting function is needed so that dates are only linked when there is a contextual/informative reason for linking them.
PS: If we wanted to address piped links other than dates, I believe that is a way bigger matter, and should be discussed at WT:MOS, probably with an RfC, since it is bound to be highly controversial.
— SMcCandlish [ talk] [ cont] ‹(-¿-)› 21:00, 12 December 2007 (UTC)
[[1991 in music|1991]]
) in the main prose of an article in most cases. Use an explicit cross-reference, e.g. ''(see [[1991 in music]])''
, if it is appropriate to link a year to such an article at all. Exceptions:[[January 1]], [[1991 in music|1991]]
) because they break the date-formatting function. When using piped links, it is best to clearly indicate that the link is to such a topical date article, e.g. in [[2007/2008 snooker season|the 2007/2008 season]]
, rather than in [[2007/2008 snooker season|2007/2008]]
I think input from more editors is required before removing "surprise links" from every article. It should be discussed at the village pump. -- Pixelface ( talk) 12:33, 16 December 2007 (UTC)
If you do this, then I think that, if a date appears within parentheses, it should automatically be replaced with "(see XXXX in music)" (or "video gaming" or whatever). SharkD ( talk) 03:49, 17 December 2007 (UTC)
SOME_RANDOM_FILM_NAME (1993)
, on one hand, versus SOME_VERY_SIGNIFICANT_FILM_NAME took the
1993 "Best Picture"
Oscar
on the other. And that probably isn't even a good example, really. It is hard to come up with a generalized case for when one should make such links; it is much easier to say that most of them should simply be deleted, as blue-link "noise". —
SMcCandlish [
talk] [
cont] ‹(-¿-)›
23:09, 18 December 2007 (UTC)It's on "Autoformatting and linking". Can't see the point of the continued presence of the tag. Tony (talk) 08:34, 24 September 2007 (UTC)
Just for the record I want to call for any last discussion/debate that anyone feels is needed. The #Re-proposal above seems to not be truly objectionable to anyone, even if it not a bright line in the sand, if I may mix a few metaphors. A possible exception is SharkD, but I think the concerns raised by that editor are addressed (and I speak only for myself on that observation). I think that the re-proposal (as re-re-proposed; follow the boldface) does represent actual consensus on the usage, and also feel that consensus may change on the matter to make the line brighter, one way or another, some time in the future. It is better to have some advice on the issue than either no advice, or, worse yet, advice so obsolete that everyone ignores it (since the latter case simply weakens MoS as a whole - the more it is treated as optional or theoretical, the more wildly inconsistent WP articles will become). — SMcCandlish [ talk] [ cont] ‹(-¿-)› 00:10, 19 December 2007 (UTC)
[[1991 in music|1991]]
) in the main prose of an article in most cases. Use an explicit cross-reference, e.g. ''(see [[1991 in music]])''
, if it is appropriate to link a year to such an article at all. Exceptions:Best Rock Album [[Emmy Award|Emmy]]: [[1991 in music|1991]]
.[[January 1]], [[1991 in music|1991]]
) because they break the date-formatting function....in [[2007/2008 snooker season|the 2007/2008 season]]
, rather than ...in [[2007/2008 snooker season|2007/2008]]
. In particular, keep in mind that readers print out Wikipedia articles, so one must never use
"easter-egg" links, that hide the nature of what they link to, as in ...since his [[2006/2007 snooker season|previous failure]] to remain in the top-16
.[[2007/2008 snooker season|the 2007/2008]] [[Snooker world rankings|snooker season]]
or worse yet the [[2006 in music|2006]] [[2006 Country Music Awards|Country Music Awards]]
– if a very specific dated article exists, e.g. for an event, do not also link to the more general topical or regional one.[[1991 in music|1991]]
). Use an explicit cross-reference, e.g. ''(see [[1991 in music]])''
, if it is appropriate to link a year to such an article at all. Cases where piped date links might be tolerated are:
[[January 1]], [[1991 in music|1991]]
) because they break the date-formatting function.[Outdent.] Here's an attempt to merge the original, but pared down somewhat, and Lightmouse's new wording (modified in some cases where it lost important distinctions):
[[1991 in music|1991]]
), in most cases. Use an explicit cross-reference, e.g. ''(see [[1991 in music]])''
, if it is appropriate to link a year to such an article at all.
Best Rock Album [[Emmy Award|Emmy]]: [[1991 in music|1991]]
.[[January 1]], [[1991 in music|1991]]
) because they break the date-formatting function....in [[2007/2008 snooker season|the 2007/2008 season]]
, rather than ...in [[2007/2008 snooker season|2007/2008]]
. Some readers print out Wikipedia articles, so we do not use
"easter-egg" links, that hide the nature of what they link to, as in ...since his [[2006/2007 snooker season|previous failure]] to remain in the top 16
.the [[2006 in music|2006]] [[2006 Country Music Awards|Country Music Awards]]
.How's that?
Just to be clear, the point of all of this is to address all of the following:
If it can't address all of these points, then it is leaving something out, and shouldn't, in my opinion. — SMcCandlish [ talk] [ cont] ‹(-¿-)› 18:40, 4 January 2008 (UTC)
I am pleased to announce that we have a complete draft proposal for you to inspect, comment on, and modify.
Just go to the working group's development page, read the instructions at the top, and take it from there.
Or click "show" to see a draft, right here:
See a full draft of the proposal |
---|
|
– Noetica♬♩ Talk 07:05, 16 January 2008 (UTC)
Omegatron has recently made some changes to the main page however Omegatron did not first discuss those changes, i.e. he did not gain consensus for those changes. Since his changes remove certain important portions of the guideline I am reverting them as is correct and proper. Fnag aton 14:54, 16 January 2008 (UTC)
I'm sorry, but I'm not required to ask your permission before fixing a spelling error or smoothing the wording of a sentence. You don't
own this page, and you don't make policy by yourself.
If you or anyone else has a problem with one of my small changes (such as clarifying the bit that was tagged with {{ clarifyme}}, or moving "in 1999" to a different part of a sentence), improve on it by further editing the guideline directly, or discuss it here. Revert warring every change I made is antagonistic and unproductive.
As for the "first contributor" rule:
Without consensus for a site-wide guideline on the use of binary prefixes, the issue is decided on an article-by-article basis. If there is an issue with units on a particular article, that issue is decided on the talk page for that article. There is absolutely no reason why we would choose the "first contributor's" favorite style over one that makes more sense in a certain context.
I'm sure this was invented based on the English varieties rules. In these, the "first contributor" rule is a last resort, used when there isn't a better reason to choose one over the other. It's not a precedent to jump to whenever three people disagree with something, and it doesn't necessarily carry over to unrelated issues like units or punctuation or grammar.
The use of units isn't an issue where the differences are merely aesthetic and can be decided by an arbitrary rule. The different ways of using units have different purposes, and one may be more applicable than another in different contexts (just like British English is used in articles about Tolkien, even if the first contributor happened to prefer American).
If this really were the rule, it would enable editors like Sarenne or Fnagaton to go around creating articles in their preferred format and then telling others that it couldn't be changed because they were the "first contributor". (I wouldn't be surprised if this was the original intention behind trying to squeeze it into this guideline.) This is not how Wikipedia editing works.
Please try to edit productively and cooperatively. If you continue revert warring without justification, you'll be blocked. — Omegatron 15:50, 16 January 2008 (UTC)
Too much text in the above. What is the specific complaint with Omegatron's edit? "Does not have consensus" is not informative, especially when only one editor seems to have any objection. Going to Talk first is not some mandatory requirement for every last edit. If you specifically object to some part of the edit, then state that objection succinctly and let's skip past this "block him, no block him" business. — Aluvus t/ c 23:55, 16 January 2008 (UTC)
He changed the guideline in several places without talking about it first.
He removed this section "When in doubt, stay with established usage in the article, and follow the lead of the first major contributor."
He changed "Most publications" to "Many publications".
He changed "There is no consensus to use the newer IEC-recommended prefixes in Wikipedia articles to represent binary units", basically he changed it from "There is no consensus to use X" to "There is no consensus to use X or Y".
the other changes he has made are language changes designed to try to lessen or water down the meaning of the guideline.
Fnagaton: Please address what you think is wrong with the content of my edits. Consensus is decided by people addressing the content of each other's edits and discussing them. It is not decided by vote, or majority rule, or revert warring, or "procedure", or wikilawyering. You need to address what, specifically, you dislike about my edits or you have not demonstrated consensus for removing them.
No one person, and no (limited) group of people, can unilaterally declare that community consensus has changed, or that it is fixed and determined. ... Wikipedia's decisions are not based on the number of people who showed up and voted a particular way on a particular day. It is based on a system of good reasons. Attempts to change consensus must be based on a clear engagement with the reasons behind the current consensus.
Here. I'll help you out by spelling them out for you so you can address each individually:
That's all of the edits that you are revert warring without discussion. Please address each edit and explain what specifically is wrong with that edit. In other words, explain how the edit harms the project or misrepresents consensus on the use of units in Wikipedia. If all you're going to do is repeat "but you edited without discussing it first!" over and over, and revert all of my edits en masse without addressing what's wrong with them, then there's no point in me trying to discuss this with you further. — Omegatron 15:48, 19 January 2008 (UTC)
There are many units in common use that have slightly different meanings, depending on the context. Some examples, to name but a few, are gallon, megabyte, mile and ton. A specialist will be aware of the ambiguity and can often tell which meaning is intended. We are not writing for specialists though, but for a general audience that may not even realise that an ambiguity exists. The onus is on WP, and by implication on its editors, to make it clear from the outset.
Someone (it may have been Gene Nygaard) made the comment a while back that we should not forget our own real world knowledge just because we are writing for WP. I agree with him; we should use that knowledge to make WP less ambiguous.
Let me give an example to illustrate my point. The most common meanings of the unit ‘ton’ that I know of are long ton, short ton and metric ton. With or without context, I would have no idea which was intended myself in each case (and I imagine the same holds for our average reader). But an expert editor, familiar with standard practice in the shipping industry, would know that [1] (TomTheHand, 2 Dec 2007)
Now, let’s say that an expert editor is editing an existing WW2 article about a US naval ship. He’s an expert so let’s assume he knows that the word “ton” means “long ton” in this context. Well, in that case our expert editor can improve the article by stating on first use that by “ton”, “long ton” is intended throughout, and WP will have improved by becoming an iota less ambiguous.
Specifically, what I would like to see is something like this:
On its own a link to ton would not be enough. That points out the ambiguity but does little to help the reader work out which meaning is being used. A simple statement on first use like “The ship's displacement was 2,000 tons ( long tons)” would suffice in most cases. The bullet could be followed by a helpful list of ambiguous units in common use. Thunderbird2 ( talk) 22:09, 17 January 2008 (UTC)
How should an assumed birthday (which may be correct), be listed? -thanks Byzerodivide ( talk) 01:44, 19 January 2008 (UTC)
Editors are invited to join a discussion at WT:MOS. We present the working group's completed proposal for new hard-space markup, and call for your suggestions.
– Noetica♬♩ Talk 03:46, 21 January 2008 (UTC)
What's the preferred way of doing birth/death dates? Wikipedia:Manual of Style (dates and numbers)#Dates says ISO dates are not common within prose but the birth/death dates in the first sentence of a typical biography — "Joe Bloggs ( January 1 1900 – December 31 1980)" — aren't really prose per se. On the other hand, Wikipedia:Manual of Style (dates and numbers)#Dates of birth and death doesn't give any ISO examples either. What is the community consensus about this? Thanks. howcheng { chat} 01:34, 18 January 2008 (UTC)
Which of these is correct: "the 5 mile (8 km) road" or "the five-mile road"? Thanks. Epbr123 ( talk) 19:35, 29 January 2008 (UTC)
An issue has arisen in Meter. User:Greg L has quite rightly edited the article so that instead of using a mixture of styles, it now uses commas to group large numbers into groups of 3 digits. However, there is still inconsistency in dealing with digits to the right of the decimal point. One example is:
Consequently, a practical realisation of the metre is usually delineated (not defined) today in labs as 1,579,800.762 042(33) wavelengths of helium-neon laser light in a vacuum.
Another example is "0.03937 inch".
I believe the Chicago Manual of Style says to not use spaces, commas, or anything other grouping symbol to the right of the decimal point, but as far as I can see, Wikipedia's MOS does not address this. So what should we do? -- Gerry Ashton ( talk) 19:43, 15 December 2007 (UTC)
There are currently two practices for delimiting numbers in the mantissa: spaces, and commas. It’s currently a free-for-all in the decimal place and only two practices are observed: 1) delimiting with a space, or 2) no delimiting whatsoever. Clearly, long chains of decimals in a row are extremely hard to parse and demand to be delimited. Trying to get all contributors to provide spaces in the decimal portion of numbers would be difficult but I would hope that official Wikipedia policy would be that the preferred method of numeric notation to the right of the decimal place is to delimit every three digits with non-breaking spaces {exceptions would be 1) where the last group consists of four digits and 2) where a group of five digits is delimited so the last group comprises two digits}. Further, I would propose that Wikipeida would recognize that the best practice is to permit the use of reduced-size non-breaking spaces (i.e. <font size="-1"> </font>
), which is an SI-compliant form that observes best typography practices. Examples:
Best typography practices:
3.141 592 6535 and 1,579,800.762 04
Acceptable delimiting:
3.141 592 6535 and 1,579,800.762 04
Further of course, the Euro practice of delimiting the mantissa with non-breaking spaces (preferably reduced-size ones) would also be acceptable.
Clearly, my proposal also holds that practices like “1.414213562373095” should be strongly discouraged or prohibited.
1,579,800
1,579,800.762045
1,579,800.762 045
1 579 800
1 579 800.762
1 579 800.762 045
1 579 800.762045
All the spaces are narrow, non-breaking ones coded as <font size="-1"> </font>
. Excel only treats the top two entries as numeric values. To see for yourself, just copy all seven entries, select a single cell in Excel, paste, and set up the adjacent column to multiply the pasted values by 2. Excel reports #VALUE! for the bottom five; Excel doesn’t care whether the spaces are regular, full-size spaces or these narrow, non-breaking ones. As you can see though, all the entries using Euro-style delimiting (spaces) in the mantissa (the bottom four entries) already aren’t compatible with Excel.
I think it is clear that the readability benefits of delimiting to the right of the decimal point far outweighs this minor inconvenience. I’ve long edited all my articles this way and have had many occasions to copy the values to Excel. It’s easy enough to hand-delete the spaces after pasting; this paste/edit method best ensures accuracy. Too, I agree with your final conclusion: “people probably don't do that often enough to worry about it.” Note further that the only entries above that would become non-compliant under my proposal are the second one down and the last one (as well as this abomination: 1.414213562373095). Greg L ( my talk) 00:27, 16 December 2007 (UTC)
{{formatnum:}}
(used extensively by templates) gives commas before the decimal point and no delimination afterwards, we should keep consistant with this.
J
ɪ
m
p
08:14, 18 December 2007 (UTC){{formatnum:123456.789012}}
gives you 123,456.789012. The formatting it uses is commas before and nothing after the decimal point. Unless we also use this elsewhere we'll end up with inconsistancy.
J
ɪ
m
p
19:39, 18 December 2007 (UTC)Proposed alternative: <span style="margin-left:0.2em">
1.234567890. requires 39 characters per group as compared to 21 for a small nbsp. And commas could be used to the left of the decimal point, so it'd only be needed when there are large numbers of digits to the right.—
Random832
16:26, 18 December 2007 (UTC)
Part of this discussion is whether anyone actually reads all those digits to the right of the decimal. While I seldom read them, I sometimes count how many there are, so I can understand what the precision of the number is. Grouping helps with this. -- Gerry Ashton ( talk) 19:56, 18 December 2007 (UTC)
{{formatnum:141421.35623731}}
modified so it automatically generates 141,421.35623731 and further, I would hope that the template would support the expression of uncertainty in ‘concise form’ (the parenthetical suffix digits). By the way, I used “0.3em” here, which I think is easier to read.
Greg L (
my talk)
20:50, 19 December 2007 (UTC)UPDATE: Well, that was an interesting experiment.
J
ɪ
m
p’s mentioning of span control (a feature I didn’t know about) offers a huge advantage. Please see preceding post from me for context. When numbers like this: 141,421.35623731
…are created simply by controlling pair kerning using “em”-based span control like this: 141,421.356<span style="margin-left:0.3em">237</span><span style="margin-left:0.3em">31</span>
…you can paste the displayed values into Exel. This strikes me as a win/win. I would propose that the {{formatnum}} template be modified to generate ‘Excel-pasteable’ numbers like this, and further, that the template supports concise notation for uncertainties.
I’ve already updated Kilogram with span-controlled numbers. To see examples, examine the article starting here. As you will see, it will be a rare number indeed that simultaneously requires delimiting in both its mantissa and its decimal side. Values with expansive decimal sections requiring delimiting rarely have mantissas greater than three or four digits. In other words, a template that functions as I am proposing here would typically be used to generate values that are an “either/or” proposition: for any given value, the expansive portion requiring delimiting will usually only be found on one side of the decimal point.
I would specifically propose that {{formatnum:60451.02214179}}
would return 60,451.02214179
…and variations of {{formatnum:6.0221417912}}
would further generate the following values:
6.02214179
6.022141791
6.0221417912
6.02214179123
Further, I would propose that {{formatnum:6.02214179|30}}
would return 6.02214179(30)
Go ahead, copy all four of the above maroon-colored values and paste them into Excel; works great.
Greg L ( my talk) 22:30, 19 December 2007 (UTC)
<span>
must have a </span>
or it must be <span ... />
And <br>
should be <br />
(yes, I'm aware that the MediaWiki software is smart enough to compensate for the latter type of error, but this is no reason to use deprecated markup; our code, like our facts, ought to be exemplary. Speaking of which, it is also best to terminate CSS directives with ";", since others may be added later in which case they must be semicolon-separated: style="margin-left:0.3em;"
—
SMcCandlish [
talk] [
cont] ‹(-¿-)›
01:11, 20 December 2007 (UTC)
So now the question to all of the rest of you (Jimp too) becomes: does the 0.2-em spacing shown in the picture at right match what you see?
As for you Jimp, I just checked out your answer below. It seems I’ve accidentally gotten your hackles up and you’ve gotten steamed. I no longer appreciate your tone (it’s uncivil) and no longer care to participate here whatsoever. Goodby. Greg L ( my talk) 02:29, 21 December 2007 (UTC)
Jimp, apology accepted. Now let’s ‘get dirty’ in the technical details. Shown below are various ways of delimiting the remainder. To the right is how it appears on my system.
6.02241679
6.022416794
6.0224167942
6.02241679423
6.02241679
6.022416794
6.0224167942
6.02241679423
6.02241679
6.022416794
6.0224167942
6.02241679423
6.02241679
6.022416794
6.0224167942
6.02241679423
6.022 416 79
6.022 416 794
6.022 416 7942
6.022 416 794 23
6.02241679
6.022416794
6.0224167942
6.02241679423
Shown above is how
delimiting appears with
live text on your
system.
As you can see, my system (at least) does not treat 0.25 em different from 0.3 em. Also on my system, 0.3 em is about midway between 0.2 em and a non-breaking space. How does this all appear on your systems? A subjective but simple way to communicate the appearance on your system is just to declare whether or not the text-based version (on the left) appears similar to the photo on the right. To my eye, the 0.2-em option on the right (what I see) seems too crowded; that is, the delimiting is hard to discern. Greg L ( my talk) 06:08, 21 December 2007 (UTC)
<span style="margin-left:0.3em;">
is a perfect solution to the copy-&-pastability problem, note also that these spaces are non-breaking (an essential feature).<span style="margin-left:0.3em;">
display correctly in common browsers? This is the consideration is that killed the use of  
. If this is to be implimented I would suggest, for consistency, that {{formatnum:}}
be modified rather than have {{formatnum-therival:}}
created.{{formatnum:}}
(or whatever other thing we pull out of our hat) for fat breaking non-copy-&-pasteable spaces are not what we want.
J
ɪ
m
p
02:45, 20 December 2007 (UTC)We don’t have to agree that Wikipedia should adopt one style or the other with regard to delimiting the mantissa…nor should we. We can simply make two versions of a numbering template (or an option to check in a single template). Trying to necessarily link the treatment of the decimal portion to how we delimit the mantissa will only doom to failure any efforts here. We should address only one issue: should a template be made to make it easier to delimit the decimal portions to make long strings easier to read(?). My point would be that narrow spaces are so damn easy to read, that even a novice who has never seen it before instantly understands what it’s all about. And in articles where numbers are important, delimiting is crucial because long strings of non-delimited digits to the right of the decimal point unusable to the point of being barbaric. There should be an easy way for others to do so (rather than hand-coding it all). Greg L ( my talk) 03:59, 20 December 2007 (UTC)
{{formatnum:}}
which produces it with no optional formatting (note also that this is {{formatnum:}}
not {{formatnum}}
... a "magic word" no template ... ordinary folk like us can't edit it). If "Trying to necessarily link the treatment of the decimal portion to how we delimit the mantissa will only doom to failure any efforts here.", so be it.
J
ɪ
m
p
04:54, 20 December 2007 (UTC)Wikipedia policy (and the every-day practices here on all of Wikipedia’s articles) is clear: Both European (British) English and American English are recognized as correct. The hat is tipped to one way or another based mainly on two criteria: 1) The style the first major contributor to an article used becomes the standard for that article, and 2) if the subject is about a country or subject that is closely attached to a particular country, then that country’s spelling, punctuation, and formatting conventions would be observed. If you don’t believe me, check out Metre / Meter and note that it uses British English throughout. Go try and “correct” realise to realize. May God be with you. ;-)
Note further that Wikipedia’s supposed even-handed policy regarding national conventions isn’t as even handed as it seems; Wikipedia has standardized on using a full-stop (.) as a decimal point. Europeans readily adapt to reading the style used in their countries and to reading the American style, which is heavily represented in print, the Web, and (especially) in scientific literature. So…
Americans are already getting their way with the decimal point. Further, most Wikipedia articles use commas to delimit the mantissa. It’s the well recognized American way of doing things that Europeans readily recognize and accept. This leaves only the issue of delimiting the decimal side of things. It’s a straightforward solution.
If, as you say, there should be one format, then IMO, it should be comma-delimited mantissa|full-stop decimal separator|narrow space-delmited remainder
. That is the closest to a universal method that one can obtain. Although highly biased towards American conventions, Europeans are quite flexible because they speak multiple languages and are familiar with entirely different formatting styles.
Lest I seem biased towards the American-way of doing things, I’m not. I just realize that there is no fighting the ever-expanding method of American writing style. I’ve worked with a Swedish-American engineer. He was bragging to a Swedish friend of his who was visiting. The engineer told him he had presented a scientific paper at an English-speaking conference. “Wow” said his friend. And he had done it in American English. “Wow” said his friend. Personally, I do all my design in metric (it’s the only way to go) and only do final conversion to inches etc. when the prints go to a machine shop. There are a variety of European conventions I like. My wife and I visited a number of European countries this summer. The ground floor on elevators are level “0” (zero). The floors above are 1, 2, etc. The first level below (the top-most) basement is -1, then -2 etc. How logical is that? My main point is that I don’t want to come across as biased for advocating an American way of doing things.
Trying to format numbers in a European way would baffle Americans. Conversely, the American way of formatting numbers is readily accepted by other English-speaking countries simply because they are more sophisticated than Americans (don’t bother whining to me about that statement; it’s true). So it’s a simple solution: comma-delimiting of mantissas, ful-stop decimal marker, and narrow spaces for the remainder. That’s what will work best given what reality has thrown us. Greg L ( my talk) 19:20, 20 December 2007 (UTC)
{{formatnum:}}
could be tweaked such that the user could go to his/her "preferences" and choose his/her number formatting scheme. The defualt would remain commas-point-nothing but there'd be the option of commas-point-spaces or spaces-point-spaces (or some other option, perhaps). Then we'd have the best of both worlds. Of course, it would be up to the developers to impliment such a thing ... and considering how promptly they're dealing with the disentanglement of date autoformatting and linking, let's not get our hopes up.
J
ɪ
m
p
06:19, 20 December 2007 (UTC)You’ve already made your fantastically well-considered vote and I don’t expect that anything I write here will make one twit of a difference in how you vote. I agree, the “chaotic spaghetti of discourse” is hard to track. That’s still no excuse for voting on an issue you admit to not even understanding! What’s wrong with you that you can’t see that? I didn’t do the page layout on this section; it’s the product of many people in a rapid back & forth debate. You could go in a clean it up just as well as anyone else here but I don’t see you volunteering. Given the history of your contributions (music-related topics), I also am quite skeptical that your interest in this topic is anything more than just passing. Tony: as regards alleging I made a “personal attack” here’s what the Wikipedia:No personal attacks article says:
There is no bright-line rule about what constitutes a personal attack as opposed to constructive discussion, but some types of comments are never acceptable:
- Racial, sexual, homophobic, ageist, religious, political, ethnic, or other epithets (such as against disabled people) directed against another contributor. Disagreement over what constitutes a religion, race, sexual preference, or ethnicity is not a legitimate excuse.
- Using someone's affiliations as a means of dismissing or discrediting their views -- regardless of whether said affiliations are mainstream or extreme.
- Threats of legal action.
- Threats of violence, particularly death threats.
- Threats of vandalism to userpages or talk pages.
- Threats or actions which expose other Wikipedia editors to political, religious or other persecution by government, their employer or any others. Violations of this sort may result in a block for an extended period of time, which may be applied immediately by any administrator upon discovery. Admins applying such sanctions should confidentially notify the members of the Arbitration Committee of what they have done and why.
As you can see, saying that I think what you wrote is hogwash and is without merit falls about a light-year short of “personal attack” as defined by A) common sense, and 2) Wikipedia. I’m saying your idea sucks, as was your fundamental position on this subject, as was the way you went out of your way trying to take the high road and seek out ways to criticize others who don’t produce well laid-out discussions pages so you can arrive late in the game and have to actually read and parse what’s here to understand it! Too bad. I have my opinion on the constructiveness of what I call your “drive-by shooting” on this topic: just enough of a cursory visit to make a glib pronouncement of how everyone hasn’t done a good enough of a job to meet your lofty standards. A “total disgrace”(?) P-u-h-l-e-e-z-e. Do you think the people here trying to hammer out technical details of delimiting numeric strings need some sort of benediction from you when you arrive late to the discussion? Just who in the world do you think you are? You want me to retract what I truly feel? That’s my opinion of what you wrote above and I’m sticking to it. Do you think Wikipedia gives you the entitlement of being free of well-deserved criticism and critical commentary on every damn thing you write? Everyone on Wikipedia deserves to be free from “personal attacks” as defined as Wikipedia above, and everyone needs to be treated civilly. Simultaneously, I can call B.S. garbage that anyone writes as I see it: “garbage”. If you disagree with me on this, then we’ll have to agree to disagree.
Finally, I am quite done dealing with you—or anyone else for that matter—here in this forum. Don’t chase me down and leave messages on my talk page. I don’t have to deal with you any more and I don’t have to deal with this topic here any more. OK? You won’t have to be all indignant over how Greg L didn’t give you a pat on your head for what you wrote because I’m done here. Goodbye. Greg L ( my talk) 06:07, 28 December 2007 (UTC)
<giggle> Tony (talk) 06:30, 28 December 2007 (UTC)
Please, for the love of $deity, can someone point me in the write direction to put forth a recommendation that we use the international / universal dating convention of DD/MM/YYYY rather than MM/DD/YYYY as is becoming prolific. Whilst I appreciate this is due to many of our editors and authors being of American origin, and no one system is correct, the most widely used system is smallest to largest, not medium to smallest to largest and we should perhaps adhere to that more stringently. At present reverting the use of two styles for dating will be a lot of work, but the longer we leave it the worse it will get. 58.107.154.192 ( talk) 02:51, 3 February 2008 (UTC)
An editor has recently changed "9th century" to "ninth ..." and several similar changes, in Bath, Somerset. MOSNUM says "Use numerals for centuries (the 17th century); do not capitalize century. " The example isn't as powerful as it could be, as "17" would be written as a number in any case. Could we change the wording to "Use numerals for centuries (the 9th century); do not capitalize century."? PamD ( talk) 00:43, 27 January 2008 (UTC)
This page is 657KB; every time I try to edit I get an edit conflict or hung on load time. SandyGeorgia ( Talk) 05:00, 1 February 2008 (UTC)
Dear fellow colleagues: the idea is to centralise debate and consensus-gathering when there are inconsistencies between the pages. The most straightforward way is to have MOS-central prevail, and to involve expertise from sub-pages on the talk page there, rather than the fragmentary discourse—more usually the absence of discourse and the continuing inconsistency—that characterises WP's style guideline resources now. Of course, no one owns MOS-central, and we're all just as important to its running as other editors. I ask for your support and feedback HERE. Tony (talk) 12:12, 5 February 2008 (UTC)
Unless an article is discussing the sale of cherries, strawberries or something similar (cherries and strawberries are what came to mind first), the likelihood of encountering a U.S. dry pint or quart is highly unlikely. I checked and I couldn't find any occurrences and dry pints and quarts are not likely enough to include a provision about them in the MOS. Also, there really isn't a need to include liquid in front of U.S. pints and quarts either. When measuring beer, motor oil, trans fluid, water, et cetera, it is somewhat clear that a liquid is being measured. That being said, I've removed the line from the style guide about "quarts". If there is an argument for keeping it in, I'd like to hear it. Regards, — MJCdetroit (yak) 16:53, 5 February 2008 (UTC)
The line for [[May 15]] [[2005]] is not correct. When there is no comma in this format in the wikitext, a comma is added for (at least some) IPs and users with no date preference. Likewise, for [[15 May]], [[2005]] the comma is removed for (at least some) IPs and users without preferences. Gimmetrow 23:16, 6 February 2008 (UTC)
To answer Gimmetrow's question about "14 February, 1991": yes, if the brackets are inserted, as you and I understood, it does display as an "acceptable" format. If the brackets are removed (and some editors will do that), then it will display in a format that is not "acceptable". I also think that the comma acts as a "speed bump" (US translation) or "sleeping policeman" (UK translation) for some editors. I can see no reason to encourage "14 February, 1991" when "14 February 1991" is the "acceptable" format and works just fine. On the other hand, I wouldn't edit an article just to remove the comma. Chris the speller ( talk) 04:00, 10 February 2008 (UTC)
Please look at Norwich City F.C. and its recent edit history. It is a featured article but I believe that the way it handles dates is poor. For example some date links are broken and it had solitary months linked. It would be relatively easy for a few editors to correct this. However as a general point I wonder if the featured article process is allowing these things through? Lightmouse ( talk) 12:40, 7 February 2008 (UTC)
Please see this example. Tony (talk) 12:51, 7 February 2008 (UTC)
It might be helpful to give slightly more information. The issue is the placement of AD (anno Domini). This page says that we should write "AD 1066" while WP:MOS says that both "AD 1066" and "1066 AD" are acceptable. The discussion in the section that Tony linked to has strayed a bit from the topic, but I hope that the section Wikipedia talk:Manual of Style#Resolving the AD issue itself will stay on the narrow issue of where to place AD. Your comments there would be most welcome. -- Jitse Niesen ( talk) 21:58, 9 February 2008 (UTC)
Well, some friends and I went off and spent the last month working on this issue here on my talk page. Temporarily moving to a forum where I had greater liberty to rearrange and revise things after-the-fact kept things much more manageable and understandable and allowed rapid and constructive progress. Unfortunately, it takes things off the radar too much and makes it impossible to obtain a consensus here. So I’ve transplanted the below work product from my talk page. To avoid the confusion that Noetica pointed out above, I will, where necessary, take the liberty here of rearranging things after-the-fact (after people have responded) but will do so in ways that make it clear who was responding to what. I think this will be necessary to keep this complex topic organized and understandable.
Below are the latest specifics of the proposal:
{{delimitnum:6.02246479|30|23|kg}}
in order to obtain the following: 6.02246479(30) × 1023 kgThe parenthetical (30) in the above value denotes the uncertainty at 1σ standard deviation (68% confidence level) in the two least significant digits of the significand.
6.022<span style="margin-left:0.25em">464<span style="margin-left:0.25em">79</span></span>(30)
× 10<sup>23</sup> kg
(*Phew*)
) on both sides of the “times” (×) symbol and just before the unit symbol. Thus, there would be no line-end occurrences like the following:
{{frac|2}}
produces 1⁄2 and {{frac|10|11}}
produces 10⁄11. For instance, one need only type {{delimitnum:6.022464}}
to obtain 6.022464 or they could type {{delimitnum:1579800.298728}}
to obtain 1,579,800.298728{{delimitnum:1.356392733||50|Hz}}
yields 1.356392733 × 1050 Hz and {{delimitnum:0.45359237|||kg}}
yields 0.45359237 kg
2.1
2.12
2.123
2.1234
2.12345
2.123456
2.1234567
2.12345678
2.123456789
2.1234567890
2.12345678901
2.123456789012
2.1234567890123
The logic tree underlying this parsing method is shown in Digit-counting parsing logic, below.
This template/parser function will avoid future occurances of editors hand-coding improper, hanging digits—as exemplified
in this section of Font size, which features this numeric string: 0.187 985 755 2 mm
<span style="margin-left:0.25em">
). Margin positioning is part of what the Web-authoring community calls
span tags, which, in turn, is part of
Cascading Style Sheets (CSS). Effectively, what appears to be a space would really only be a visual effect caused by the precise placement of the digits; the “spaces” wouldn’t be separate, typeable characters.To see the difference, slowly select the two values below with your mouse:
</span>
. Note the example code shown in the third bullet item down in this list.{{delimitnum:6.02214179|30|23|kg}}
→ 6.02214179(30) × 1023 kg{{delimitnum:1579800.298728}}
→ 1,579,800.298728{{delimitnum:1.356392733||50|Hz}}
→ 1.356392733 × 1050 Hz{{delimitnum:0.45359237|||kg}}
→ 0.45359237 kg{{delimitnum:6.022461}}
→ 6.022461{{delimitnum:6.0224613}}
→ 6.0224613{{delimitnum:6.02246134}}
→ 6.02246134{{delimitnum:6.022461342}}
→ 6.022461342
Q2: Is the span gap to be added following the digit “1”? No=Add a span gap of 0.25 em and then goto Q1 / Yes=Add a span gap of 0.2 em and then goto Q1.
In any discussion of delimiting numbers to the right of the decimal marker with gaps, we must also settle on what to do to with the integer portion of the significand (the left-hand side of the decimal marker). I advocate using commas for two reasons:
Note the above examples (copied from Kilogram and Font size). In those examples, only the third example (the definition of the meter) has five or more digits in both the integral and fractional portions of the significand. All the others require delimiting only on one side of the decimal marker or the other, but not both. Greg L ( my talk) 20:06, 31 January 2008 (UTC)
I’ve seen many Wikipedia articles that feature space-delimited numbers to the right of the decimal marker and they’ve been stable for years without one single “drive-by shooting” by an unregistered editor-in-a-hurry attempting to “fix” the ‘funny-looking’ values. Font size is just one such example; there are too many Wikipedia articles to count. This is clear proof that essentially all readers readily recognize that what they’re looking at are space-delimited numeric values. If this can occur with full-width spaces, then reduced-width ones—which just look “right”—will be even easier and more natural for readers. Delimiting numeric strings to the right of the decimal marker serves precisely the same purpose as does doing so to the left of the marker and is very much needed. Greg L ( my talk) 19:42, 1 February 2008 (UTC)
In
“Continuing Discussion” below, Tony asked whether MOSNUM policy regarding the use of this template/parser function should be “framed as mandatory or optional”, my suggestion would be a formal policy as follows:
6.022461342
so they have the following appearance: 6.022461342 (making them easier to parse) and simultaneously retains their functionality as
Excel-pasteable numeric values.In furtherance of this policy, the fractional portion of significands may no longer be delimited using either spaces or
non-breaking spaces (e.g. coding 0.187 985 755<
or 0.187 985 755
to produce 0.187 985 755) because such text strings can break at line-end
word wraps and/or are not treated as numeric values when pasted into Excel. Values such as these should be irreversibly “upgraded” via use of {{delimitnum}}. “Irreversibly” means that it is impermissible to convert a value that is delimited with {{delimitnum}} to a simple, non-delimited numeric string.
Further, numeric equivalencies that can wrap between the value and its unit symbol (e.g. 75.2 kg), as well as numeric values expressed in scientific notation (e.g. 15.25 × 106) that were neither created with the {{e}} template nor unified with a non-breaking space and can therefore wrap on either side of its times symbol (×), should be “upgraded” via either 1) the use of non-breaking spaces, 2) use of the {{nowrap}} template, or 3) use of {{delimitnum}}—exclusively so if the value has 5+ fractional-side digits.
The effect of this is that new editors who don’t know of the template/parser function or how to use it wouldn’t be doing anything “wrong” when they write “3,210.123456”. Existing, hand-entered values like this, which meet the proposed MOSNUM policy, would be considered as acceptable (though not ideal) and may be irreversibly upgraded. Articles like Font size, which use the non-Excel-pasteable non-breaking spaces (and also leave dangling single digits) would become “incorrect” and should be irreversibly upgraded. Greg L ( my talk) 07:59, 13 February 2008 (UTC)
a. | Numbers cannot be copied and pasted as numbers into another application if they contain spaces. | |
b. | Commas then no delimiting is the accepted standard on Wikipedia. | |
c. | Commas then no delimiting is the the norm in English. |
{{#expr:1,234*56}}
won't work).{{formatnum:}}
produces no spaces after the decimal point.{{formatnum:}}
adapted accordingly.15 625 / 83 118 ≈ 0.187 985 755 2 mm
hard to read. It took me a second to realize the left-hand side was the ratio of two five-digit numbers, and more time to realize that both sides were intended to be in mm. Septentrionalis PMAnderson 15:27, 14 February 2008 (UTC)
We should limit our efforts here to agreeing on a policy—and developing a tool—that avoids instances of 0.187 985 755 2 mm, which (*sound of “raz” buzzer noise*) leaves a hanging digit and (*buzz*) uses full-width spaces and (*buzz*) can’t be pasted into Excel. A tool that automates delimiting to the right of the decimal marker will also make expressions such as e = 2.718281828459 far more readable. Greg L ( my talk) 18:32, 14 February 2008 (UTC)
Note that 2.718281828459 had
long appeared in
Natural logarithm until only a few weeks ago. When
I changed it and explained that the value is now delimited and Excel-pasteable, it has been readily accepted even though the code required to do so is expansive. Giving authors a tool so all they have to type is {{delimitnum:2.718281828459}}
will be extremely well received in my opinion.
The proposed {{delimitnum}} parser function wouldn’t change the way digits are currently delimited to the left of the decimal marker. What it does do is allow authors to quickly and easily produce easy-to-parse, non-wrapping, Excel-pasteable, properly delimited numeric values when they have five or more digits to the right. Greg L ( my talk) 01:09, 15 February 2008 (UTC)
{{formatnum:}}
. How would we be able to make such a thing possible? Unless this is adopted as the standard formatting I don't believe we've got a chance.
J
ɪ
m
p
03:41, 15 February 2008 (UTC)
</span>
. I realize I didn’t explicity point out the closing of spans out so I’ve taken the liberty of adding a bullet point regarding this into the
“Overview” section, above. But let it be noted here that this information wasn’t there before your above-posted question. Thanks.Regarding why a 0.2-em gap is occasionally used rather than the more common 0.25-em gap, see Gap width details, above (scroll to the bottom of that subsection). The short answer though, is that the 0.2-em gap follows the digit 1. It slightly tightens the gap following the digit 1, which is important because the eye is sensitive to overly wide gaps, which can begin looking like separate numbers if not kept tight. P.S. Noting that this too wasn’t nearly explicit enough, I added a short paragraph to that section regarding the slightly thinner gap following the digit 1. Let it be here-known that this too wasn’t there until after your question.
As to your last question (is {{formatunum}} going to be messed with), not to my knowledge. I don’t think anyone is proposing such and I am certainly not advocating it since doing so might have deleterious effects in existing articles. It would simply be a new magic word called {{delimitnum}}. Greg L ( my talk) 07:39, 15 February 2008 (UTC)
I have noticed that I sometimes have odd problems when bolding and italicizing using ''
(straight single quotes) if I have span-based delimiting in the paragraph. So what you’re saying might well be the case. Thanks.
Greg L (
my talk)
00:06, 16 February 2008 (UTC)
2.718<span style="margin-left:0.25em">281</span><span style="margin-left:0.2em">828</span><span style="margin-left:0.25em">459</span>
. Although it’s the same amount of finger wear, would placing the close-spans all at the end, like this: 2.718<span style="margin-left:0.25em">281<span style="margin-left:0.2em">828<span style="margin-left:0.25em">459</span></span></span>
be OK too? The only virtue is—for some people—it might make it a little easier to parse the code one writes. You take a number, paste the spans every three digits, and then paste the required number of close-spans. This method also generates the value “2.718281828459”. So let me check alignment after a font check of italicizing and bolding and italicized bolding. That all seems to work bug-free. What if I try to bold the delimited value: 2.718281828459. I think that one would have given me flack before. And what about alignment of a new paragraph?Yup, a new paragraph aligns well. Is this “save ‘em to the end” method OK too? Greg L ( my talk) 02:29, 16 February 2008 (UTC)
P.S. I’ve revised the third and eighth bullet items in Overview, above per both your teachings. Greg L ( my talk) 05:27, 16 February 2008 (UTC)
I believe broader consensus is required before asking for someone to devote time to coding this. So far as I know, outside Wikipedia, the appearance of number separations may be outlined thus:
The existing rules in WP:MOS and WP:MOSNUM were chosen from the above options. Since no one uses comma separators in the integer part combined with thin space separators in the fraction part (remember, I'm talking about appearance) the existing rules should not be read to mean that the fraction part is fair game. It would be necessary to gain consensus on both talk pages for the concept of the appearance of thin spaces in the fraction part. -- Gerry Ashton ( talk) 06:09, 15 February 2008 (UTC)
As also addressed in the proposal at Rationale for using “comma delimiting” with “narrow-gap delimiting above, “it will be a rare number where commas (a U.S. style) and narrow spaces (a European/SI style) are juxtaposed within a single value.”
What has also been covered in Making a case for why narrow gaps are already well-accepted on Wikipedia, above (and elsewhere throughout these discussions) is that the use of spaces to delimit values on the fractional side is today a common practice on the English Wikipedia pages. And why are editors using spaces to delimit the fractional portion? Because of this obvious truth: delimiting numeric strings to the right of the decimal marker serves precisely the same purpose as does doing so to the left of the marker and is very much needed on Wikipedia. However, it’s very often being done incorrectly and the resulting efforts are 1) inconsistent, 2) don’t look good due to the full-width spaces, 3) occasionally improperly leave single dangling digits, 4) often do line-end word wraps within the value, and 5) the values can’t be copied and directly pasted into Excel.
Hand coding 6.022<span style="margin-left:0.25em">464<span style="margin-left:0.25em">79</span></span>
× 10<sup>23</sup> kg
to produce 6.02246479 × 1023 kg address all these shortcomings but is extremely cumbersome and inflates the size of articles.
All these shortcomings—with a practice that is already widespread on the English Wikipedia—are addressed with this convenient tool.
Finally, as regards your assertion that it is “necessary to gain consensus on both [WP:MOS and WP:MOSNUM] talk pages,” that makes no sense whatsoever and frankly strikes me as a metric ton of weapons-grade bullonium. Wikipedia would grind to a complete halt and nothing could ever get accomplished if simultaneous and/or duplicate discussions had to occur across multiple forums! Talk:MOSNUM is clearly the proper and logical forum for this topic; that’s why it exists. Greg L ( my talk) 08:26, 15 February 2008 (UTC)
I oppose this proposal on the grounds that it is a bastard. -- Gerry Ashton ( talk) 17:39, 15 February 2008 (UTC)
Congratulations to all; the proposal was accepted and presented to a developer on 02-15-08 to be made into a parser function. Thanks for your passionate and hard work on this {{delimitnum}} proposal. As many of you have no doubt noticed, the debates and comments here resulted in my having to go back to the Overview section many many times to modify and/or add bullet points to incorporate your many observations and suggestions.
It might be a bit premature to check-mark this as resolved (and move it to an archive) as technical issues may arise during the developer’s work. Currently, the Overview section serves as a concise central reference source/depository that can be conveniently updated when corrections and additionals are required. I suggest we leave this here and archive it after the parser function is delivered.
In advance, thanks to the anonymous developer(s) quietly volunteering their time in the background to provide us the tools that make our editing life easier.
Greg L ( my talk) 05:56, 16 February 2008 (UTC)