This is an archive of past discussions on Wikipedia:Manual of Style. 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.
Confused about the phrase "do not write over the heads of the readership"
I am confused about the phrase "do not write over the heads of the readership". What does it mean? How do I write under the head of a reader? Lightmouse (talk) 22:55, 22 December 2008 (UTC)
The expression "do not write over the heads of the readership", means editors shouldn’t write in a manner that the typical reader would find too complex. Some editors try to show off how smart they are by using crap like the speed of light is 299792458 m s−1, when both the speed of light is 299792458 m/s and the speed of light is 299792458 meters per second are so much more accessible to a more general audience. I know you know this principle, Lightmouse; you were perhaps having difficulty with the idiom or were unhappy that an idiom was used on MOSNUM instead of plain-speak. I responded this way for the benefit of others who might read this. Greg L (talk)07:13, 23 December 2008 (UTC)
Thanks. I guessed it was something like that but I was having difficulty with translating the idiom into editing. If I understand the phrase correctly, I can say the idiom 'went over my head'... You are right to suggest that I prefer rules to have plain-speak instead of idioms. Its not a big deal. Lightmouse (talk) 10:40, 23 December 2008 (UTC)
Aren't all of these examples showing off. If is a case of dumbing down why not say the speed of light is approx 300,000 km/sec, or approx 300,000 km per second, or approx 300,000 km.sec-1?Pyrotec (talk) 14:50, 23 December 2008 (UTC)
I don't see it as dumbing down. 299792458 m/s is not less correct or specific than 299792458 m s−1, so there really is no trade-off here. Of course, "approx 300,000 km per second" is fine in most articles, but sometimes there is a point to be made that the speed of light (in vacuum) is exactly299792458 m/s. Abbreviating second to "sec", on the other hand, is dumbing it down to something non-standard for no benefit at all, so that should clearly not be done. -- Jao (talk) 16:11, 23 December 2008 (UTC)
Another useful guideline might be Do not use colloquial English idioms in a manual of style. In this case, I think the point could be better expressed as: "Do not use overly technical units in articles which may be used by non-technical readers". It should give an example such as: "Say that the speed of light is exactly 299,792,458 metres per second, instead of .299792458×109 m·s-1". However, telling authors to use 300,000 km/sec would be dumbing it down too far. This is an encyclopedia, after all, and we're not writing for elementary school students. RockyMtnGuy (talk) 16:54, 23 December 2008 (UTC)
Completely agree with RockyMtnGuy. IMO, for any encyclopedia, precise values should *usually* be used unless they are obscenely long and precise. An important exception would be for when one is conveying what is clearly an illustrative estimate of another point, such as this: In spacetime, time and distance are equivalent. Since the speed of light is about 300,000,000 meters per second, one microsecond of spacetime is directly equivalent to 300 meters of spacetime.(I think I have that example technically correct, but the technical-writing principle applies regardless.)
<outdent>
Greg, if you think that this is a good example illustrating this rule, let me suggest a corollary:
Spell out the names all but the most familiar symbols units of measure (e.g., ft, kg, m, W) on first use, and not represent them by symbols. For example, do not say
"its tractive force has been increased to 250 kN (56,000 lbf)"
but instead, especially on first use in an article, say
Do you agree that this would come in under the class of "do not write over the heads of the readership"? If not, I'd say your example misses the mark by a mile. Gene Nygaard (talk) 11:53, 26 December 2008 (UTC)
Gene, the topic Lightmouse originally raised (what does “writing over the heads of the readership” mean?) had been addressed and RockyMtnGuy changed the subject by raising two points: 1) MOSNUM shouldn’t use idioms, and 2) rounding off numbers like the speed of light would be dumbing things down too much for an encyclopedia. I agreed with him and raised a new point myself: that when illustrating rules of thumb to memorize, it is proper and serves a good purpose to provide rounded-off numbers. Note however, that Army1987 (see his 18:25, 26 December post, immediately below) showed us an even better way for an encyclopedia to provide easy-to-remember values for rules-of-thumb. Greg L (talk)19:39, 26 December 2008 (UTC)
I prefer a format such as 250 kN (kilonewtons), which provides both the symbol and the link, so that subsequent uses of the same unit in the same section (and, most times, in the same article) can just use the symbol, now that the reader has learnt what it stands for.
As for Greg's example, I don't think that 299,792,458 can ever be much worse than about 300,000,000, so how 'bout In spacetime, time and distance are equivalent. Since the speed of light is 299,792,458 meters per second, one microsecond of spacetime is directly equivalent to about 300 meters of spacetime. (note the about before the 300)? --Army1987 – Deeds, not words. 18:25, 26 December 2008 (UTC)
P.S. My point is that what might flabbergast the reader is the nine digits, not the fact that they're not zeros. In cases where the exact value is irrelevant, I use about 300 million, rather than about 300,000,000. --Army1987 – Deeds, not words. 18:50, 28 December 2008 (UTC)
Yes, you raise a good point and your example (second paragraph, above) is probably better Army. I was trying to show how the objective should be to provide readers with a simple easy-to-remember number when doing mental estimates of equivalencies, such as the above space-time equivalency. Providing the precise value for the entire light-second (hard to remember but it is an important, defined value), and providing readers with the rounded value of “300 meters” for a microsecond accomplishes that objective, but does so in an even more encyclopedic fashion, IMO. Very good. Greg L (talk)19:25, 26 December 2008 (UTC)
P.S. As to your “kilonewtons” example, I disagree. I think the spelled-out name of the unit measure should go first. Note that Encyclopedia Britannica spells out “megabyte” throughout an article and never resorts to its unit symbol in its computer-related articles. Though this isn’t a “right or wrong” issue, it seems more properly instructive to write The 250 kilonewton (kN) structural loading on the runway due to the B‑24 was so great…. I would hazard to guess that this is also the technique most commonly used in technical writing and textbooks. It avoids the (!) brain-interrupt by providing the pronunciation and highly descriptive name first, and then gives the rather cryptic symbol for the unit of measure. Greg L (talk)19:55, 26 December 2008 (UTC)
Yes, but it isn't just the kilonewtons; it is the pounds-force as well. The lesser-known "lbf"; not the common "lb". It wasn't kilonewtons standing alone.
And the same principle would apply, were it written as
I see: You’re talking about the conversion to SI (from the barbarian unit of measure) and the attendant parenthetical within a parenthetical. The square brackets look funny to me, if not slightly awkward, but what you have is logical and I see no other alternative at the moment. I might try a thinspace to separate the two back-to-back brackets; e.g. …56,000 pounds-force (lbf) (250 kilonewtons[kN] ). Fortunately, the square brackets need only be used once per article while the units of measure and their associated unit symbols are introduced; thereon, it need only be After they purged all their viruses and got their Windows machines to stop crashing for a whole week, they figured out how to increase the tractive force to 68,000 lbf (300 kN).Greg L (talk)21:58, 26 December 2008 (UTC)
It doesn't make any difference which way the conversion takes place. And note also that in some cases, the MOSNUM rules are cited by editors to keep SI conversions out of some of our articles. Are you willing to support a change in the MoS to say that conversions to SI units are always acceptable? Can you get general agreement on that?
Problem is, both of those are contrary to an existing, specific rule in this confused section of the MoS. According to MOSNUM, we should not write either
56,000 pounds-force (lbf) (250 kilonewtons [kN])
250 kilonewtons (kN) (56,000 pounds-force [lbf])
and furthermore we also should not write:
68,000 lbf (300 kN)
All of them are contrary to the overly prescriptive, half-thought-out rules we have here: "In the main text, spell out the main units and use unit symbols or abbreviations for conversions in parentheses".
Gene, I’m not finding the text you cite: In the main text, spell out the main units and use unit symbols or abbreviations for conversions in parentheses. Here is what I am finding:
In the main body text, the first instances of units of measurements should be spelled out at least once, and perhaps several times for less familiar units before unit symbols are employed. For instance, one should write “…the typical batch is 250 kilograms…” before one later writes “…and then 15 kg of emulsifier is added.” For less common units of measure, editors should not employ unit symbols without first showing the unit symbol parenthetically after the first use of the full unit name; e.g., “The light intensity over the metrology table was 800 lux (lx).”
And where you write “note also that in some cases, the MOSNUM rules are cited by editors to keep SI conversions out of some of our articles”, can you provide an example article and discussion thread like this? I’m trying to understand the issue better. I can’t, off the top of my head, imagine a justifiable reason to keep SI conversions out—even in Ford 351 Cleveland. Oops, I just now see that the link I provided redirects to Ford 335 engine and that article does not provide SI equivalents. Further, I see now that this is a grey area and some mental flexibility is required since providing displacement conversions everywhere throughout that article would likely look cumbersome. Where else, Gene, are SI conversions being left out that you think is a flagrant foul? Greg L (talk)23:35, 26 December 2008 (UTC)
You must have a find on the page function in your browser. Just use it, to find the text I copied and pasted above, the rule being violated in all those examples. Gene Nygaard (talk) 00:53, 27 December 2008 (UTC)
OK, found it. I have a “find” function and used it but I must have copied carelessly and picked up a piece of something unwanted.
MOSNUM prescribes something that makes a great deal of sense: you don’t use the full unit name in conversions so they don’t need a parenthetical for a unit symbol—they already are unit symbols. The guideline you cited reads, in full, as follows:
In the main text, spell out the main units and use unit symbols or abbreviations for conversions in parentheses (e.g. a pipe 5 centimetres (2 in) in diameter and 37 kilometres (23 mi) long).
However, as you can see, the current MOSNUM example doesn’t address the problem you just pointed out: providing a parenthetical unit symbol for the primary measure immediately before a parenthetical conversion. I’m thinking this should be explicitly addressed in MOSNUM. It might already be addressed but I’m too lazy at the moment to prove a negative; searching on ) ( produces only two, non-germane hits. The straightforward solution would not require using square [ ] brackets, as you proposed, by reading as follows: a pipe 5 centimetres (cm) (2 in) in diameter and 37 kilometres (km) (23 mi) long). I seem to recall having seen this technique employed on Wikipedia.
The issue here is not the inclusion or not of a parenthetical symbol with the spelled-out word. You will notice that my original corollary rule did not include that; it is irrelevant to what we are considering.
Stick to that topic--don't be sticking in a new header just because you want to drift off somewhere else. { Gee; more dickisms. Where you are taking this has everything to do with getting SI conversions “allowed” for all articles and has nothing to do with “what does ‘writing over the heads of our readership’ mean”Greg L (talk)03:26, 27 December 2008 (UTC) } The issue here is the phrase "do not write over the heads of the readership". And what I specifically claimed is that, according to your interpretation of that phrase, this would be a corollary (a rule which follows readily from the previously stated rule):
Spell out the names all but the most familiar symbols units of measure (e.g., ft, kg, m, W) on first use, and not represent them by symbols.
Go find others to get excited about this. It appears that it doesn’t take you long at all before you revert to your old habits, which rapidly turns people off. What’s it going to take for you to consistently stay civil and assume good faith(?): an assistant with a remote control who follows you around and activates your shock collar? Goodbye. Greg L (talk)03:26, 27 December 2008 (UTC)
It's the same thing as your answer to Lightmouse about what "do not write over the heads of the readership" means. So if you don't buy this, you were giving him bad advice in your response to him, too.
Your explanation wasn't very good, but my example is entirely equivalent to yours. The use of the ambiguous phrase in the MoS is a problem in its in its own right, of course. It might make some sense on the main page of the MoS, but if there is any special meaning here that would make it appropriate for the dates and numbers subpage, the meaning needs to be more clearly spelled out. But I suspect the best solution is just to throw it in the garbage can. Gene Nygaard (talk) 04:26, 27 December 2008 (UTC)
Thread drift--Ford 335 engine
It occurred to me that maybe a compromise solution for articles like Ford 335 engine (very American subject), would be to simply add a table of SI conversions somewhere. It would contain liter equivalents (American dialect) for all the displacements mentioned throughout the article (302, 335, 351, 402, etc.). The same could be done with power outputs. I also see now that there is some inconsistent usage of in-line conversions to liters in the article. Readers are smart enough to recognize that 402 is bigger than 351 in the prose; but what they do need is some convenient method to anchor them to their familiarity zone: “How do these engine sizes compare to a Ferrari 5748 cc engine?” Once anchored in the general scheme of things, most readers should understand the article. What do you think of this? Greg L (talk)00:03, 27 December 2008 (UTC)
I was addressing your 22:50, 26 December, above, where you wrote “And note also that in some cases, the MOSNUM rules are cited by editors to keep SI conversions out of some of our articles.”
As for another point in that same post, you wrote “Are you willing to support a change in the MoS to say that conversions to SI units are always acceptable?” In a word: no. For one thing, my above outdented post about the Ford 335 engine details how the lack of in-line SI conversions in certain articles can be simply and satisfactorily addressed without upsetting the apple cart. But another reason is that—for reasons that are exceedingly elusive for me—you seem to actually go out of your way to alienate editors while you are simultaneously trying to solicit support for your pet causes. See your 01:55, 27 December 2008 post, above, if you don’t understand. Drop me a line when you’ve had an epiphany about the way you interact with others here on Wikipedia, or have had a personality transplant at the Mayo Clinic. Greg L (talk)03:26, 27 December 2008 (UTC)
You demonstrated that know how to make a subsection when the topic drifts. Need a little work on the when to do it angle, it looks like. If your reply has nothing to do with the original subject, that's a good time to do so. Sure, you might be responding to a peripheral issue already raised--but the discussion in the posting in which it was contained dealt primarily with the subject header under discussion. This should have been not a subheading, but rather a new heading at the top level we use. Gene Nygaard (talk) 04:31, 27 December 2008 (UTC)
My comment about articles not using SI was merely a response to your bad-mouthing comment, "I see: You’re talking about the conversion to SI (from the barbarian unit of measure)". { That was a Freudian projection on your part and an assumption of bad faith. I am an advocate of the SI—note my contributions in the field. I often refer to Windows as “Barbarian OS”. That’s what I really feel about the US customary system too. You and I have cross paths (in depth) before and I am quite certain you’ve read my posts regarding how I do my engineering entirely in metric and convert to Barbarian units only when prints need to go so machine shops. That’s why I referred to the system as “Barbarian units”. Most Europeans feel that way; are you shocked an American can feel that way too? I recall pausing a moment, pondering whether you could somehow misconstrue my intent as I typed that and concluded you wouldn’t; boy was I was wrong. Apparently Gene, if you routinely employ facetious backhandings against others to ridicule their positions, you will be prone to jumping to the conclusion that others do so against you as well. I deleted my last rant against you from your talk page and the stub from here as a gesture of goodwill: water under the bridge. Yet it didn’t take you even 24 hours after that to “go full Gene” again. I’ve done my best. Now I don’t want to have to respond to you any more. But I felt compelled to do so here (again) because you seem so damned clueless when you piss people off. Now please go find someone else to be a dick to as you simultaneously try to win them over to your never-wrong, black & white logic.Greg L (talk)21:27, 27 December 2008 (UTC)}
If that indicates an interest in always allowing SI conversions from barbarian units of measure, fine. If not, I have nothing further to add. Gene Nygaard (talk) 05:06, 27 December 2008 (UTC) { Not interested. In my 23:35, 26 December post above, my knee-jerk reaction was in backing you 100%. I had further asked “can you provide an example article and discussion thread like this? I’m trying to understand the issue better.” I didn’t get an answer. But after digging into it on my own, I see no need to upset the apple cart with absolutisms; my above post referencing the Ford 335 engine explains my views on this subject at the moment.Greg L (talk)21:27, 27 December 2008 (UTC)}
It is far more likely that your change of heart had to do with recollecting the cases in which you yourself insisted not only on using barbarian non-SI units, but also in not allowing those barbarian non-SI units to be converted in the article.
In any case, your discussion of the engine article didn't have anything to do with not allowing SI conversions; you merely offered a suggestion related to the presentation of those conversions.
It isn't automotive articles where I see the editors refusing to allow SI conversion of barbarian units. Most of them have such conversions. Gene Nygaard (talk) 23:18, 27 December 2008 (UTC)
I notice that the Large Numbers section suggests the use of {{e}} for scientific notation, but that {{val}} is used liberally on this page, and suggested with caveats in the Scientific Notation section. There's also the {{scinote}} template that appears to serve the same purpose. So, what's the official way to indicate scientific notation in Wikipedia, and how well does it correspond to (non-Wikipedia) standards? TheFeds01:14, 28 December 2008 (UTC)
You can probably count as many opinions on this subject amongst Wikipedians as you can count noses. Note that {{val}} has had its appearance highly tweaked during a lengthy RfC and discussion process on both WT:MOSNUM and WT:MOS. It uses thinspaces on both sides of the × sign, which a lot of Wikipedians felt addressed a trade-off of appearance and utility when the numerical equivalency is part of a more complex formula. So, for simple modest-precision values, you get something like this: 2.235×106. If you want to toss in the unit of measure, you can have 2.235×106 kg. Note also that the entire value and its unit symbol always no-wraps at the end of lines. Further, there is a “link” parameter so the unit symbols will be linked to their respective articles, such as 2.235×106kg. You can even add uncertainty in several ways, including this one: 2.235(15)×106 kg. Finally, {val} adds span-based gaps in high-precision values where the significand exceeds four digits to the right of the decimal point. Thus, you get something that looks like this: 1.854875×1043. Span-based gaps are convenient because you can copy the entire significand—the “1.854875” part—and paste it into Excel where it will be treated as a number without having to hand-delete spaces.
Note the appearance of this NIST value for electron mass. Now compare it to this: 9.10938215(45)×10−31kg. Note that {val} conforms to the NIST’s practices in all ways. Note too, that {val} uses a true “minus” sign rather than a hyphen for negative exponents. Thus, you don’t have -31 but get an easier-to-see −31. Remember, you code {val} with an ordinary, keyboard-generated hyphen for negative exponents; it substitutes the true minus sign for you during rendering.
The only caveat is that {val} has trouble with very long, high-precision values and can produce a rounding error at the end. Editors have to be aware of this and double check that what you typed is what is rendered. I’m about ready to write Jimbo; the developers responded that they thought producing the special character-counting parser function to make it error free would “set a precedent” that would result in more requests for special parser functions. If volunteer developers have this sort of reaction, then its about time one of the paid developers risks the slings and arrows of a “precedent” being set with this request. (*sound of audience gasp*)Greg L (talk)02:45, 28 December 2008 (UTC)
It occasionally produces errors in the last one or two digits somewhere between 5 and 10% of the time depending on the nature of the value. If it is to be recommended at this time, the recommendation should include a high profile advisory to double check that output matches input. I’m going to stay single-mindedly focused on getting this bug solved from hereon. At the moment, I’m seeing if Jimbo (here) wants me to keep ‘working’ the volunteer developers (zero luck so far) or is inclined to assign the task of writing a quality, bullet proof character-counting parser function to a staff developer (my preference). Greg L (talk)05:14, 29 December 2008 (UTC)
Each of these three templates do different things (as you'll read on their documentation). The display that {{scinote}} uses is similar to that used by {{val}}: there are thin spaces (the same span-based gaps) either side of the multiplication sign. However, {{scinote}} does not group numerals after the decimal point (and until a stronger consensus to do so is reached, not that I intend opposing it, and until the function is debugged, which would be necessary since the subtemplate {{scinote}} uses to produce scientific notation is also used by {{convert}} thus it's no simple matter checking output against input, I'd be against adding this). One thing the {{scinote}} does do is add a "^" between the ten and its power when you copy and paste ... at least in Internet Explorer (not Google Chrome nor Safari and I haven't checked any others). JIMptalk·cont11:23, 29 December 2008 (UTC)
Above I noted that I don't intend to include the numeral grouping of {{val}}'s in {{scinote}}. Not that I don't like it, in fact I'd like to see it both sides of the decimal. As I've mentioned to Greg elsewhere, I've been thinking about how useful a character counting function would be. Not only would it get {{val}} working correctly but a function like this would greatly simplify a template like {{precision/+}}. Considering that {{precision/+}} has something of the order of 100,000 transclusions (if my counting is correct), this would be quite beneficial. JIMptalk·cont08:55, 31 December 2008 (UTC)
Naming conventions for units: 'Palm (length)' or 'Palm (unit)'
I've read through the comments to the question "Is some method of date autoformatting desirable?" to try to figure out what, if any, decision might have been reached. Unfortunately, the issue was heavily clouded by irrelevant reasoning on both sides. I've tried to be fair in my analysis. First, the reasons that strike me as valid:
Support some method of automated date formatting
Wikipedia is not paper; there is no reason not to support date preferences since so many people want it. People who don't like it can simply not use it.
Prevents date-handling templates from having to take options in every use to specify which date format to use to match the page.
Identifies dates as metadata for automated tools.
Oppose any method of automated date formatting
While it may be odd-looking to less worldly readers, no one is going to be confused when reading either "December 25" or "25 December".
Yes, that's not much. There are many more reasons that don't seem to matter, with my reasoning for discounting them following:
Support some method of automated date formatting
"I like it." So?
"Maintains consistency." A guideline like WP:ENGVAR would do the same.
"Eliminates ambiguous dates like 1/2/2008." These should never be used anyway.
"Removal may encourage date format edit warring." While true, we deal with the same risk of edit warring over other types of regional variation using WP:ENGVAR.
"The wrong format is 'annoying and distracting'." More so than other regional variations?
Oppose any method of automated date formatting
"I don't like it." / "I don't care." So?
"Unregistered readers would see unformatted dates." It could easily be coded to apply a default format to dates for unregistered readers.
"The only reason for this is MDY versus DMY, which is pointless." There is also the issue of templates, having some sort of date formatting would help enormously with their ease-of-use.
"Who cares? No one wants it." Apparently quite a few people do.
"Autoformatting would apply to all dates, even those in quotes." Brion has specifically stated that any proposed solution that would try to format dates that weren't marked in some manner will not be accepted. Thus, as long as some idiot didn't put the "<date>" tags (or whatever) around dates inside quotes, this isn't a problem.
"Only if we get a solution for color/colour too." That's not the issue here. Also, date formatting is just more than American English versus British English.
"Extremely few people would even bother to set the user preference." So?
"Date links are bad." There is absolutely no requirement that a date formatting solution also link dates. You must have been commenting in the wrong section.
"Not worth the developer time." The developers, especially the unpaid volunteers, can spend their time on whatever they want. There are some that would like to work on this.
"Not worth editor's time." The same is said about half the articles people work on. As long as people who don't care don't actively stand in the way of those who do, let them add the markup.
"Too complicated to use." Is "<date>December 25, 2008</date>" really so hard?
"Will promote edit wars." / "More harm than good." How exactly?
"Bots can't decide." This has more to do with removing the old date links than anything to do with this issue.
As for a way forward, I see several possibilities:
Do nothing, despite the good arguments for and lack of good arguments against.
Implement some markup (e.g. <date> tags and/or a {{#formatdate:}} parser function) for the dates, plus a site-wide default format and a magic word to override that per page.
Same as #2, plus the <date> tags honor the user date preference.
Same as #3, plus unregistered users get a guess at a date format based on their IP.
Option #2 is sufficient for templates, but would not satisfy those who want user preferences. #3 is sufficient for them, and #4 is just extra. IMO, the site-wide default should probably be set to DMY. I am aware of the existing patch for making [[date]] continue to format but no longer link, but I for one am opposed to that as it makes little sense to me for wikilink syntax to not create some sort of a link. Image links still link to the image, just in a special way; and categories and interwikis still link, just in a dedicated area instead of inline in the text. Anomie⚔19:04, 25 December 2008 (UTC)
I also feel that the non-linking wikilink syntax for date formatting would be confusing. If any new type of date formatting is implemented, would that force all registered users to set preferences? If not, what would they (users w/o preferences) see? Also, how would the new syntax be implemented in an efficient way? Dabomb87 (talk) 19:17, 25 December 2008 (UTC)
I would say all registered users who have not set a preference (or set the preference to "no preference") would see the same as unregistered users. The implementation would be about as efficient as the current date autoformatting, unless someone has a better suggestion. Anomie⚔19:36, 25 December 2008 (UTC)
I agree with much of your analysis with one exception: I don't think you've recognised sufficiently the concerns that editors will not know to put <date>...</date> tags (or similar) around dates - and that's a real concern, I think. However, that concern would be addressed over time as the usage increased, and I expect somebody would come along and add the tags anyway - a little more work, but worth it, imvho. --RexxS (talk) 19:27, 25 December 2008 (UTC)
Until DA was "deprecated", the same could have been said about putting double-brackets around dates to get them to auto-format. If anything here were implemented, plenty of people would now about it from this discussion, more would find out from WP:VP announcements, and plenty more would see people adding them to articles and immediately realize what was going on. Anomie⚔19:36, 25 December 2008 (UTC)
you wrote "so many people want it" - how many voiced support for it in this RfC, please and thank you? just for clarity Sssoul (talk) 21:53, 25 December 2008 (UTC)
It seems about 51 people opposed deprecating the current broken auto-formatting, and 82 supported some method of auto-formatting. Anomie⚔00:16, 26 December 2008 (UTC)
For comparison, 247 supported deprecating the current method of autoformatting, and 68 opposed some method of autoformatting. I also just thought of something else: if dates are autoformatted, will they show up as autoformatted in the edit screen? Or will we see something like this in the beginning of an article:
Bob Jones (26 December 1978 – January 1 2001) was a
... and then further down see something like:
He won the XYZ Award on 1996-03-23
? In other words, will the date inconsistencies that IP readers see in articles continue to show up in edit mode if a new autoformatting patch is developed? Dabomb87 (talk) 00:55, 26 December 2008 (UTC)
I don't understand this question. In edit mode, it would look like
'''Bob Jones''' (<date>26 December 1978</date> – <date>January 1 2001</date>) was a
and
He won the XYZ Award on <date>1996-03-23</date>
for everyone, if that's what people typed in. For anyone reading the article, even IP users, it would look like "Bob Jones (26 December 1978 – 1 January 2001) was a" and "He won the XYZ Award on 23 March 1996" (or the same with all three dates in MDY order). Anomie⚔03:03, 26 December 2008 (UTC)
Exactly. Is there any way to take the inconsistent out of edit mode? As an editor, that would be quite distracting and confusing. Dabomb87 (talk) 03:31, 26 December 2008 (UTC)
the way to make the date formats consistent in "edit" mode is for editors to type them in the same format throughout the article; and/or if it bothered someone to see dates in assorted formats in "edit" mode he/she could of course go through the article and make them consistent. (is that what you're asking??) Sssoul (talk) 09:58, 26 December 2008 (UTC)
i'm not worried about it, thanks! 8) in fact there are scripts that can help with it, so it could be at least semi-automated. Sssoul (talk) 14:40, 26 December 2008 (UTC)
Uhm, of all the things distracting and confusing about editing on Wikipedia I sincerely doubt this would be ranked highly amongst them. For true horror, observe the syntax for tables, or the various template invocations (and corresponding syntax), etc. Seeing one date format mixed with another in the raw text/article source is not going to present nearly the same issues... —Locke Cole • t • c23:26, 26 December 2008 (UTC)
Anomie⚔, under Oppose any method of automated date formatting, and specifically to the view that "Unregistered readers would see unformatted dates", you responded as follows: “It could easily be coded to apply a default format to dates for unregistered readers.” IMO, you glossed over this one way too fast; it is the $64,000 question. All the required fuss to provide some sort of autoformatting merely for registered Wikipedians is 1) totally irrelevant (because they comprise a vanishingly small percentage of our readership), and 2) undesirable and counterproductive.
Why do I say that in point #2? That is best explained by referring you to Wikipedia:Why dates should not be linked. If you are in a rush and want to go to the nugget explaining why, scroll down to the section where it shows a classroom of students. But in a nutshell, if we editors see all dates in a given article per our personal preferences, we can’t tell when dates are inappropriate for the subject matter. There might be an article on the Neighborhoods in Spokane, Washington or Kevin Coe (a famous rapist in Spokane) and some European editor might add a date that defaults to Euro format. How will this be fixed? European registered Wikipedians, who are accustomed to Euro dates, won’t notice anything that causes a (!) brain interrupt. Neither will their American counterparts. Wikipedians can’t correct a problem if they can’t see the problem. The consequence: the biggest portion of the readership of that particular article—predominately American—will see a date format that is awkward for them.
I think all this fuss is a colossal waste of time, is unnecessary, and undesirable. I see no compelling reason whatsoever to lift our fingers one iota to fix what is an imaginary problem. We Wikipedians should always be looking at precisely what our readership looks at—nothing more and nothing less. We’re all big boys; we can handle the shocks. Greg L (talk)22:01, 27 December 2008 (UTC)
Criminy you are good at digging stuff up, aren’t you! I note that 23.4% is clearly a minority. So, is your point that the needs of the American audience shouldn’t be taking a backseat to the Euro/International audience when it comes to clearly-American-related content? I would imagine that an article like Proxima Centauri would have a 23% American share but an article like Neighborhoods in Spokane, Washington is going to be >90%. Greg L (talk)04:22, 28 December 2008 (UTC)
The 23.4% is for all editions of Wikipedia. The English language edition gets 52% of the total traffic. The Japanese edition gets 10.3%, the German edition gets 8.1% and the Spanish edition gets 5.7%. The readers from English speaking countries are as follows: United States 23.4%, India 5.5%, United Kingdom 4.1%, Canada 2.1% and Australia 1.4%. The US has 24.4% to 13.1% for the other four countries. It would be a mistake to impose the European style of units and dates on the largest group of English readers. -- SWTPC6800 (talk) 02:31, 29 December 2008 (UTC)
Comment. While I don't think that date autoformatting is that useful, if we had to use them because everybody likes it, could "magic words" such as __DEFAULT_TO_DMY_DATES__ or __DEFAULT_TO_MDY_DATES__ be implemented, which would cause dates to be formatted in the chosen format for readers who haven't set date preferences? This way, one might add __DEFAULT_TO_MDY_DATES__ to articles such as Kevin Coe, and __DEFAULT_TO_DMY_DATES__ to articles such as London, and so there wouldn't be any inconsistency in the rendered article, even if the source used '''Bob Jones''' (<date>26 December 1978</date> – <date>January 1, 2001</date>) was a ... He won the XYZ Award on <date>1996-03-23</date>. (As for me, I would set my preferences to "As in the article source", if such a thing were ever implemented, so that I would still be able to see inconsistencies in the source.) --Army1987 – Deeds, not words. 19:13, 28 December 2008 (UTC)
Yes Army, I think that would work. Note that to comply with the clear intent of the recent RfCs, very little linking should be going on with any of this. Essentially, we would have to largely abandon and deprecate much of the existing link/autoformatting business (the “[[ ]]” stuff). Then we would have named magic words like you propose, where a conscious decision by editors must be made to specify which date format to use. As you also propose, the method must ensure there is no *default* to one format or another if the editor omits a parameter; to do otherwise would be a sure-fire prescription for a thorough mess.
And I also agree with your first point (“While I don't think that date autoformatting is that useful…”) ; once again, your logical mind has come up with a technical solution. But it’s a solution in search of a legitimate problem to solve; we would do this because… why??? Since when did registered editors become so sensitive to looking at dates in their non-preferred format, that we need to produce special {{DEFAULT_TO_DMY_DATES}}-stuff just so we don’t have to look at what absolutely everyone else on this pale blue dot looks at? Because we’re *privileged*? Because we’re *delicate*? Clearly neither; other factors were at play that was making editors dig their heels in on this issue, including fear-of-change. When registered editors are looking at normal editorial content (excluding special features while in edit view), we should always, always see precisely what normal users see; nothing more and nothing less. Doesn’t that basic principle seem like a common sense one to you? Greg L (talk)20:53, 28 December 2008 (UTC)
As soon as we have asserted the method of determining which date format to use for a given article (whether by first-author choice or by national ties), the importance of how every reader (registered or not) sees dates is created. If we were to assume a single constant date format for all dates regardless of the page, then there would be no issue of date formatting. --MASEM00:43, 29 December 2008 (UTC)
Well, just why the settling of which date format to use creates this "importance" is beyond me. That is what I questioned above. Is it dyslexia? Tony(talk)02:00, 29 December 2008 (UTC)
Come on guys. We know that we don’t need nor want one date format. How in the world would it be wise for our France article to say The Bastille was stormed on July 14, 1789.(?) Don’t our Euro/Australian editors react with disgust to this? Do they say Can’t happen, because we’ll out vote the yanks and prevent such garbage”? How in the world would it be wise to have an article on United States of America read The colonies declared independence from England on 4 July 1776.(?) Our American editors will revolt. A single date format clearly isn’t realistic so let’s leave that one off the table as a bargaining chip to be used while bluffing.
Clearly, we need a simple guideline to use in choosing an article-appropriate date format. I’ve long been pushing for a guideline that simply looks to the subject matter and doesn’t require looking to article history to determine whether an article had been stable in this or that format after it had first grown from a stub. I just got through such an exercise and found it extraordinarily cumbersome. We just solved this very sort of format issue in an article on a famous astronomer. He had been born in Denmark. Is that why he is famous? Because he was born in Denmark? Or is his fame due to his work while working in America at American institutions and observatories? It was the latter. Is this method perfect? No; there are gray-area articles. But it is simple, rational, works a large percentage of the time, and saves a shit pile of time spent arguing on talk pages: you just go look at what the subject matter is. This is just my personal preference; any well respected guideline that specifies a clear procedure to settle upon a date format to use in articles is fine by me.
And the larger principle that I am absolutely convince is drop-dead obvious, is that there is simply no compelling and valid reason whatsoever to provide special formatting tools to shield us editors from what we’re making the rest of the world read. Greg L (talk)02:53, 29 December 2008 (UTC)
Arbitrary section break
A guideline isn't as simple or elegant as simply providing a date formatting function for our editors to use. Further, a guideline will only format the dates for what a portion of our readership desires, totally ignoring what the other portion may desire. Finally, any word done on a patch for MediaWiki to implement this won't be done by you personally, and it won't be a "waste of time" (per Tony) because the devs choose what they want to work on regardless of what the community desires (remember: there are only one or two paid developers for MediaWiki, the other developers/MediaWiki contributors are unpaid volunteers who choose their own work). Date autoformatting is the best solution because it doesn't succumb to "gray areas" where neither date format may have weight over another (thus leading to potential disputes or conflicting edits), it allows the reader (the people we're writing for) to see things the way they want to, and it even marks up dates in a way that can be easily parsed by secondary users of our encyclopedia (microformats, etc). —Locke Cole • t • c03:05, 29 December 2008 (UTC)
OK Locke. This isn’t a loaded question; it’s a fair question. You wrote above, “A guideline isn't as simple or elegant as simply providing a date formatting function for our editors to use.” Now please explain: why do editors need special date formats that only we can avail ourselves of? Because we’re *privileged*(?), or because we’re *delicate*? What other reasons are there to justify the effort to give us a special view of pages that no one else gets? Greg L (talk)04:53, 29 December 2008 (UTC)
Please be aware: for our editors to use does not mean only for our editors to see. The date formatting functionality would, of course, be used by editors (that is, the syntax/magic word/template/whatever). But the results would be visible to all editors and readers, logged in or not. This would not be a "special view of pages that no one else gets" as everyone would get it. At least that's what I'm striving for. —Locke Cole • t • c08:15, 29 December 2008 (UTC)
Tony, it's not simply Month-Day vs. Day-Month, if you'll look at Special:Preferences there are actually many date formatting choices that must be considered. I have mine set to MM-DD-YYYY, and other editors may have other options selected. And it's not a "waste of time", but thank you for the logical fallacy. By the way, are you still beating your wife? —Locke Cole • t • c03:05, 29 December 2008 (UTC)
My wife has fur and claws: I do not beat her. So you use the month–day option? OK, you're at a disadvantage over editors who choose "No prefs", since you can't see the many discrepancies our readers put up with in within-article date formatting, nor globally wrong choices. In my travels, I pick up a lot of messy formatting and fix it; I could not do this if I bought into the put-on-my-blinkers mentality that says: "my mind would be corroded by seeing the other order of month and day". I encourage all good editors to take off the blinkers and acquire an eye for detail. Tony(talk)04:52, 29 December 2008 (UTC)
No, I said I use MM-DD-YYYY. "July 4, 2005" renders for me as "07-04-2005" (assuming it's bracketed of course). That's how I like my dates to appear as a reader. Please understand that any autoformatting system would be turned on for all readers, not just editors. So whatever the underlying syntax is it wouldn't really matter because the dates would be formatted to whatever the reader chose (or a given default in the absence of a stated preference). I don't see the harm in this at all (and it could curb issues with underlying date irregularities; an article with July 4 2005 mixed with 4 July 2005 wouldn't matter because the reader would see one date format, not both). —Locke Cole • t • c08:15, 29 December 2008 (UTC)
The MediaWiki devs are fully aware that one facet of a "correct" date formatting system means that the default date display would not be "no preference", but instead either the MD,Y or DMY format. Yes, this was a problem with the double bracket version, but need not be a continued problem. This removes any issues with in-article date inconsistencies. --MASEM05:01, 29 December 2008 (UTC)
Again, a date format system that, unlike the past double bracket version, provides a default of MD,Y or DMY no longer makes editors that set a preference "privileged"; as long as all dates in an article are marked up as dates to be formatted regardless of their format, every reader and editor will see a consistent set of dates. Only if the editor registers and sets a preference would this be to a format of their preference. The counterargument is that any guideline that states that the date format of a page is set by first editor or by nationality will lead to some type of edit war somewhere; the only way to avoid such an edit war is either to fix one date format for all pages iregardless of content, or provide a date format system that provides a consistent format for the end user regardless of being registered or not. --MASEM05:29, 29 December 2008 (UTC)
Yeah, understood. So why is it a good idea to give an “editor [who] registers and sets a preference” a special date “format of their preference”? Why is this necessary? Why do we deserve this extra effort? What problem does this solve? How does Wikipedia’s product become better? Please please answer these questions. I am baffled and don’t see the answers myself. Greg L (talk)05:37, 29 December 2008 (UTC)
Same reason we give them the ability to set the look of WP to a style they like, or to allow them to edit their monobook.js to add additional functionality, or so forth. It is not a requirement, but it is a helpful display feature that can be tied with conforming dates to the same format for anyone that chooses not to participate. --MASEM05:41, 29 December 2008 (UTC)
Still don’t get it. You said “the same reason” but didn’t specify the *reason*; just the effect (‘same as this and that’). Those other customizations are edit-view tools and such. That makes sense; we need special tools and special views of edit histories, and the ability to configure our working environment. How does Wikipedia become a better product by giving editors a special view of plain ol’ regular (non-edit view) article content?!? Where else do we editors have tools that actually makes article content different from what regular readers see? I would think there would be some really good, meritorious purpose for all this extra markup effort. Please explain just what that *really good, meritorious purpose* is. Greg L (talk)05:53, 29 December 2008 (UTC)
Let's take the ability for registered editors to set a specific page style. It is a completely non-functional from the standpoint of content, only in how its displayed to the end user, and only to those that are registered. Just like date formatting. Yet, I see no clamoring to remove this feature. Editors can further customize their monobook.js to, say, hide all internal links or change other presentation of articles at will. If we demand a "WYSIWOG" (O for Others) situation, then we probably should be asking either to disable monobook.js support or to have some means to display or preview a page without using monobook.js rendering. If we can provide a means of providing for registered users a method to alter content that (absolutely necessary) degrades gracefully for unregistered users to a satisfactory result, and does not significantly alter the process load on WP, we should offer it (and yes, this means we should consider the Brit/US versions of English as part of this aspect).
So to try to best answer your "why" question, the best answer I can offer is that "It customizes article displays to my taste". If this is not a valid reason, then we should be removing a lot of other features of WP for the same rationale. --MASEM06:12, 29 December 2008 (UTC)
(outdent)
What “other features” are you referring to, Masem, that would have to be removed based on this same rationale? Features that affect everybody(?), or features that affect the meaning or appearance of article content only for registered editors who have set a particular user preference? I’m not aware of any in this latter group as it applies to article content; only edit-view tools. It appears this date-formating stuff would be the only case for article content. Is that right? And we’re going to be putting guidelines into MOSNUM that state this(?):
• I.P. editors and all other editors should be aware that dates must be coded with either of the following: {{DEFAULT_TO_DMY_DATES|24-4-2006}} or {{DEFAULT_TO_MDY_DATES|24-4-2006}} so that a special class of user: 1) registered editors who 2) have set their user preferences setting, can see dates in a format that “suits their taste.” This will have no affect for you if you are a regular I.P. editor, nor will it appear for any regular reader of Wikipedia, but MOSNUM requires the effort because the editors who debated this are *extra special* and have put this requirement here. Be sure to use the default setting appropriate for article content since this is what virtually everyone else will see.
Masem ... you wouldn't happen to be a programmer, like Locke Cole and Tennis expert and UC_Bill and Sapphic, would you? It appears that a deep mind-set is possessed by some programmers and almost no other people: it values computer functionality per se above its broader social and psychological utility; it downplays the advantages of simplicity over complexity; it is keen to locate every possible way in which the play-thing might be of some earthly use (stats was one); it is offended when the results of sophisticated programming strings are dismissed by non-programmers on the basis of issues to do with usage and utility. I've tried, with some success, to get through to another programmer (User:HWV258), although I think at the end of the day I can't quite crack him. It really is like dealing with writers who want to construct long snake-like sentences with unnecessarily complex grammar, yet who pass up opportunities to simplify their language. I just don't understand the barrier. Tony(talk)07:28, 29 December 2008 (UTC)
Masem is likely referring to the ability for editors to customize the entire appearance of Wikipedia by editing their userspace CSS and JS files. Something an unregistered reader cannot do. Like date autoformatting, userspace CSS (and to a lesser extent, JS) serve no purpose other than to make things prettier for "upper crust" (as you seem to be calling us) of editors. Again however, date autoformatting would work for everyone, not just editors, so this point is irrelevant IMO. —Locke Cole • t • c08:20, 29 December 2008 (UTC)
You keep dodging the question: Why do we need it?, apart from the given that you seem to want it personally. On a systemic level, why is it at all important? Why not create a system for our/or and ize/ise? Tony(talk)08:43, 29 December 2008 (UTC)
I'm not dodging anything. You just don't seem willing to accept that something that a) avoid edit wars over date formats and b) provides a consistent format for our readers is useful. As to your latter suggestion, I don't think that's technically feasible (or at least, technically simple). —Locke Cole • t • c08:58, 29 December 2008 (UTC)
I can't answer "why", I can only ask the equivalent question "Why do we allow for registered editors to set their page layout style and/or access to monobook.js to alter the appearance and content of a page?" My answer to both questions is that it is a low cost (in terms of implementation and CPU cycle) feature that helps registered editors to use WP in the they want to use it, but it is simply that, a beneficial feature with no other content-improving purpose. The only (and not trivial) difference between these questions is that editors have to prepare dates for date formatting (no such preparation has to be done -- well, in the general case -- for using new page style), but this can be done by a bot and it can become second nature as was double bracket use for the old, bad way of date formatting. --MASEM11:50, 29 December 2008 (UTC)
Locke Cole said:
I use MM-DD-YYYY. "July 4, 2005" renders for me as "07-04-2005"
I misspoke, it's actually YYYY-MM-DD (do not post while tired). But to get that, go to Special:Preferences → "Date and Time" → "Date Format", and mine is set to the last choice there. Of course the date must be auto formatted, so here's an example: July 42005. —Locke Cole • t • c10:49, 29 December 2008 (UTC)
If you guys can’t be up front with why you want it, you should just give it up. The simple fact is that you think that registered editors are special and privileged and we need to have special date crap just to spoon-feed custom content to us because some of the date formats used here doesn’t suit your taste and you waaaaaaant to see only dates *you* like. But (sucks to be you) 99.9% of our readership can just go ahead and look at the fixed-text default dates chosen for a given article. That’s just stupid and you full well know it.
We’re not going to require that editors jump through extra hoops with formatting code that benefits only registered editors! Do you really expect that all editors will be required to code either {{DEFAULT_TO_DMY_DATES|24-4-2006}} or {{DEFAULT_TO_MDY_DATES|24-4-2006}} when all that 99.9% of our readership will see in the article is a fixed-format date like “24 April 2006”? Just so you don’t have to look at your less-than-favorite format? Absurd. Beyond absurd.
Now, if you are going to tell me I’m wrong, the explain *why* it is such a good idea to do this. And don’t come back with I can't answer "why". Why the hell would you waste everyone’s time here if you can’t even explain why we should do something?!? If you want something, offer up a damned good reason why it benefits Wikipedia besides “ ’cause I like ta” or “ ’cause it suits my taste better and I don’t mind pushing a lame attempt to force everyone to jump through extra hoops because we registered editors who hang out here on WT:MOSNUM are so damned *extra-special*”. We’re not. I know I’m not and I really doubt you are either. You and I can simply look at date formats everyone else is looking at. And that means you had best get to work on ensuring we have the best guideline possible that prescribes the date format editors should use in our articles. Greg L (talk)19:58, 29 December 2008 (UTC)
The "why" is the same reason why we have user preferences for any aspect of WP. Just like date formatting only 0.1% of the WP readership gains the benefits of setting user preferences, so by the same logic we should just ditch these as well.
The difference is that the markup the other preferences use is already there. Someone wants to show third-level headers in green? Fine. The === tags are already there. I, the editor, am completely unaffected by the decision to let people read green headlines. Someone wants to render all math as PNG? (I do.) Fine. The <math> tags are already there. You, the editor, are completely unaffected by this quirk of mine. For date preferences to work, we need to add new markup. (The WYSIWOG argument is more to the point, of course, but then it's impossible anyway to prohibit people from using a custom style sheet when viewing the site.) -- Jao (talk) 20:41, 29 December 2008 (UTC)
I completely acknowledge that (as mentioned below), which is where I do agree some consideration should be put. However, dates can be easily recognized by bots so were this to be selected, tagging existing dates would be trivial. There's also possibly something semantic that could be done with that (maybe there are editors that really want to have any dates linked to their date pages, despite this not being part of the WYSIWOG argument, so if the dates are wrapped in CSS, this would be a possibility). If date formatting were to be put back in place, it would have to be a brain-dead simple mechanism as double linking to make it instantly learned by all editors. --MASEM20:59, 29 December 2008 (UTC)
The consensus from the RFC shows that there is a large fraction of registered editors that want to be able to set a date format. The devs have stated that a better date formatting system can be put in place without linking and with a clean default to provide a consistent fix date for the 99.9% of the others. Just like any other user preference item, there seems to be no barriers to including this. I concede that the only aspect that is different is that dates have to be marked up in some manner to trigger date formatting (I'm not aware easily of any other user pref that interfaces directly with actual article), but we've had that in the past and once learned it takes all of a few keypresses to put it in place, and bots can be programmed to add this. If only editor was clamoring for this, sure, it would be passed to the bit bucket, but there's enough input to request it that it seems completely sensible to move forward with it, or at least trial the proposed dev solution to make sure no new problems come into play. --MASEM20:15, 29 December 2008 (UTC)
To be fair, nobody ever suggested anything as unwieldly as {{DEFAULT_TO_DMY_DATES|24-4-2006}}. If __DEFAULT_TO_DMY_DATES__ were implemented, it would of course only be necessary once in each article, not for every date. You know I'm firmly on your side, but it still helps to take care to read and understand the arguments and proposals of the other one. -- Jao (talk) 20:27, 29 December 2008 (UTC)
The proper solution is to 1) arrive upon a guideline for choosing a date format that is a sensible, compromise solution that is best for our readership, and 2) grasp the fundamental, basic notion that there is no valid reason that we can’t be exposed to the date formats everyone else has to look at.
As for adding a tag to each date so the server system can go find every instance of a date, that could be accomplished with {{15 January 2009|15-01-2009}} and {{January 15, 2009|15-01-2009}}. There would be no autoformatting for babies; just a template that would nowrap the day and month for us (at least it kinda sorta does something to make our lives easier, and has a parameter that says “print this”, and a hidden parameter that allows computers to go find these dates. I’d sure like to hear a really good reason for why we need to find dates; after all, it’s easy enough to type 15 January 2008. So far, these sort of suggestions have been a byproduct of “I don’t wanna ever have to see poopy daaaaates!” rather than a suggestion that can stand on its own merits. Greg L (talk)22:46, 29 December 2008 (UTC)
I said it above and I'll say it again since you seem to have missed it: Date auto formatting would work for all editors and all readers. —Locke Cole • t • c22:57, 29 December 2008 (UTC)
I certainly did miss that if what you are saying is the whole story. What I last understood is that what was being proposed was a tool that allows registered editors who have set their user preferences to be sheltered from being exposed to a date format they don’t particularly like, and which has a default format that everyone else gets. Is that right? Or has someone now found a way to give every visitor to Wikipedia their own preferences setting(?) (via a cookie, I suppose). Or has someone found a way to geolocate the reader by matching their I.P. address to a database and spoon-feeding custom content to them based on this? All this effort for dates?!? Please explain which of the above it is (or “other”). Greg L (talk)23:06, 29 December 2008 (UTC)
The way we seem to be heading in this discussion now is to have some syntax to markup dates, and then magic words which can be used to set the date format per-article and override any default. Readers (those not logged in) would get some default format (at this point it's impossible to say if we could determine a "best format" based on IP, but the point is some default would be used) unless a magic word was used overriding it. Logged in editors would get the format they chose in their preferences. Nobody would see bare dates as entered by default, though editors could disable date auto formatting if they wished to see the underlying date text as entered. —Locke Cole • t • c23:24, 29 December 2008 (UTC)
That’s what I thought; ergo, my 22:46, 29 December 2008 rant, above, completely applies. The tools you describe means that the very editors responsible for article content can’t see what 99.9% of our readership sees. The very fact that some editors here perceive the need for such an unwise tool just points to the fact that our current guideline governing the choice of date format to use in our articles isn’t respected by the individuals here who were responsible for putting it there. Improve the guideline, respect it, and abide by it. Greg L (talk)23:46, 29 December 2008 (UTC)
I'm sorry, what are you talking about? I just said that readers (those not logged in) would not see bare dates but auto formatted dates. —Locke Cole • t • c00:13, 30 December 2008 (UTC)
Well, that is an indulgence that the project would be well to leave behind. We need editors to see what our readers see, not some My eyes are too precious to cope with day–month techno-toy. When editors no longer see the strings that our readers see, all sorts of trouble starts. And may I remind you how trouble-prone the old square-bracket syntax was? Tony(talk)00:50, 30 December 2008 (UTC)
Am I not speaking English? Editors and readers would see auto formatted dates, so it wouldn't matter what the underlying markup was made up of. —Locke Cole • t • c02:24, 30 December 2008 (UTC)
Yes Locke Cole, I think most everybody does understand you, but the underlying question is why? Do people detest seeing dates in a slightly different way than they are used that much? I do understand that there are other formats besides month-day and day-month—ISO dates and YYYY month day—but is it that distracting? As long as articles have internal consistency, then it shouldn't matter. I don't think that those in London refuse to read the New York Times because of the order of the dates. Another overplayed argument I hear is that "there will be edit wars if we don't autoformat dates". WP:ENGVAR works for -ise/-ize and -our/-or, so why shouldn't it work for dates? I realize that my arguments won't hold much water against you or the other protesters, as it has been the same vocal minority making a fuss about it here on WT:MOSNUM for the past half-year or so, but I just wanted to put this out there. Dabomb87 (talk) 02:38, 30 December 2008 (UTC)
The response to that is, of course, why not? If it's no skin off your back, why are you so vehemently opposed to something that can only be a net improvement for the project? Does it keep you guys awake at night, this notion of auto formatted dates? If not, why constantly try to stop it? What harm is it causing you? How is it affecting you in a negative way if you're not the one actually being asked to do the work? —Locke Cole • t • c03:34, 30 December 2008 (UTC)
The Wikimedia Foundation thinks that non-programmer contributors are put off by the assembly language level of editing Wikipedia. [2] They feel that these non-technical editors would make valuable contributions if Wikipedia was easier to edit. -- SWTPC6800 (talk) 04:03, 30 December 2008 (UTC)
The Wikimedia Foundation did not decree that projects must conform to some specific standard of usability. Instead they were given money and hired staff to do this. Nothing in that announcement precludes there being "advanced editing" capabilities, just that a simpler interface be present and available for beginners. —Locke Cole • t • c05:52, 30 December 2008 (UTC)
Holy shit, I cannot believe this discussion is still going on! Maybe it doesn't so decree, but it is hardly a huge leap of common sense to work out that what you are pushing for is diametrically opposite to KISS. Ohconfucius (talk) 07:21, 30 December 2008 (UTC)
Which is easier: wrapping a date in some syntax to autoformat them, or learning a complicated MoS to try to learn when you should use one date format over another (and even then, since things seem to be tending towards using WP:ENGVAR you'll need to go spelunking into the article history to determine the original variation of English used. —Locke Cole • t • c06:08, 2 January 2009 (UTC)
Another arbitrary section break
Still cleaning up the mess from the previous system that prevented most WPian editors from seeing the raw date formats. Just how do readers out there see their supposedly favourite format without logging in, creating and account and preffing? And why are you spending time on this in the first place? It's an extraordinary misallocation of time and effort. Tony(talk)04:05, 30 December 2008 (UTC)
Unregistered editors would likely see a default date format which could be overridden on a per-page basis using a magic word (as mentioned above by others). Once we've got a system in place that works we could likely expand it to provide a way for readers to change their format and have that stored in a cookie. —Locke Cole • t • c05:52, 30 December 2008 (UTC)
The reason for this entire mess over date formatting is because we are not opting to provide one consistent date format across all articles, instead resorting to the nationalistic rules that have been developed. If WP were a print work, we've have selected one date format and used that consistently, but instead we're trying to provide some ruleset that will be editwarred over regardless of how clear the advice is. The date formatting at least provides a way that are uncomfortable with a selected date format to see what they want to see. --MASEM04:13, 30 December 2008 (UTC)
So the upside is that you won’t be “uncomfortable” seeing a date format you prefer not to be exposed to. I must admit, that I am uncomfortable with seeing a two-month-old baby on the local news that some “boy friend” killed yesterday. I actually changed the channel. But I’m not sympathizing with your plight here. I don’t think what you are complaining about is all that important. I certainly think we could use more flexibility out of you and less complaining. It’s not important that you see two date formats. My son is working his ass off in the Navy so he can deploy. He wants to go stand on a wall somewhere and say “no harm will come to you tonight; not on my watch.” That sort of stuff is important. Having special tools made so you can be spared the shock of looking at “December 7, 1941” (or whatever it is you dread) isn’t eliciting any sympathy—even any understanding—on my part.
As for the downside, many of us editors will be setting our user preferences setting. Those who do (so they can look at edit histories and such) would be unable to even see when inappropriate date formats are in our articles. That prescription has “fiasco” written all over it. As for your “let’s all have one format” suggestion (no-doubt your format of choice) you know as well as I do that isn’t a workable solution. There is no harm having two different date formats on Wikipedia and I am wholly disinclined to support burdening our articles with tools that present *special* editors with one view of regular article content and I.P. users an entirely different view just because you can’t get with the program here.
Now, please present your “I am really, REALLY *Special*” license for inspection. Failing that, I think you and I can just go ahead and come up with a sound, rational guideline governing how to chose date formats suitable for use in articles. After that, you and I can just go ahead and be exposed to the very same article content everyone else looks at. If any of that is simply too, uhm… *egalitarian* for you, please pipe up. Greg L (talk)04:46, 30 December 2008 (UTC)
This statement: Those who do (so they can look at edit histories and such) would be unable to even see when inappropriate date formats are in our articles. shows that you have missed the point; non-reg end users will see one consistent format in an article, which is what the MOS has been asking for from the start. Date formatting only extends additional functionality to alter the chosen format for a page to their own preference. We are still making sure dates within a page are consistent to make sure the mess that double bracket autoformatting led to. --MASEM04:54, 30 December 2008 (UTC)
(*sound of head going “thump - thump” on desk*) Yup. Understood. It’s the “extends additional functionality” part you want that Tony and I are convinced is not only wholly unnecessary, it is a bad idea. Greg L (talk)05:35, 30 December 2008 (UTC)
It doesn't matter if you think it's a bad idea or unnecessary, the community has sizable support for a date auto formatting system of some sort. Perhaps instead of tilting at windmills you'll help us come up with something that's workable and acceptable rather than needlessly fighting it? For example, I welcome your input on potential problems you think we should be aware of, or your opinion on what syntax to use. —Locke Cole • t • c05:52, 30 December 2008 (UTC)
Fact check: Does “sizable support” equal a “general consensus”? Is this view(s) embodied in any of the RfCs? If so, please point to the RfC. And do these editors who express these views understand that “autoformatting” (as in something *customized*) would only work for use *special* people and the rest of the world gets *default*? Tony: weigh in here too please; you are close to the RfCs. What do you see are the facts regarding community consensus on what is desired? Locke has stalled my gallant steed in her tracks and I can no longer assault the windmills!! Greg L (talk)06:25, 30 December 2008 (UTC)
We all know that there is only a very small number who really gives a shit which date format any given article is. Personally, I see two "advantages" to a new date autoformatting: for the 99% of readers who do not choose to opt out, they will not see the mess of non-unified date formatting within an article when travelling through WP - dust and dirt swept truly under the carpet. Secondly, I will have no more complaints from fellow editors (such as this one) if I choose to go around and convert all date formats to American (or International). ;-) All except those who are watching specific articles will know any better. Ohconfucius (talk) 07:21, 30 December 2008 (UTC)
My attitude is “Oh… fudge—what a hassle for such a stupid reason.” I’m going to stay focused on getting rid of the damned blue links. Our Taliban article is chock full of them and they all link to mindless trivia. Is Lightbot active? Greg L (talk)07:35, 30 December 2008 (UTC)
Alas, my attempt at starting a reasonable discussion of the RFC has degenerated into the same old MOSNUM cesspool that every discussion I've read on this page has descended into.
Greg L: Ok, we know you don't see the point, and we know you do not accept anyone else's attempt at explanation. You're clearly on record. So shut the hell up and let anyone else talk already. Anomie⚔04:58, 1 January 2009 (UTC)
The most amusing thing above is the back slapping adventure that ensued once they delinked Taliban. Despite there being a clear consensus that some date links are actually useful. Funnier still is that date linking is irrelevant in this subject: we're talking about formatting dates, not linking them, but somehow these guys devolved the discussion down to "oooh, date links, kill with fire!"... —Locke Cole • t • c06:13, 2 January 2009 (UTC)
As for real discussion: I couldn't care less about user preference for MDY versus DMY date formatting; I too would leave it at the default setting. What I would like to see is a way to mark the article "Use DMY order" or "Use MDY order" (and possibly other options, but these are unlikely to be needed in practice), and a way to use that so every template that manipulates dates doesn't require extra parameters be supplied to every instantiation to specify the output format.
Of course, user preferences for DMY versus MDY and such would be easy enough to add into such a system, and a not-insignificant number of users would like it, so I for one see no particularly good reason not to include it. I don't buy the claims that it would be infinitely damaging to the encyclopedia. I would also like to see something so those who cannot abide anything shorter than "December 31, 2008" or "31 December 2008" in lists (especially reference lists) and tables don't have to force their overly-verbose preference on those of us who prefer a shorter format in those cases. Anomie⚔04:58, 1 January 2009 (UTC)
I think the only way forward is to simply disengage from MOSNUM, which is what I threatened to do long ago and will do now that we have an RFC that presents a mandate that supports auto formatting. I'm sorry MOSNUM regulars don't like them, but they don't get to veto the community. —Locke Cole • t • c06:13, 2 January 2009 (UTC)
Yeah Locke, I'll easily forget you having a laugh at our expense about the Taliban, but it'll take a lot longer for me to forget the ordeal you meted out to me earlier. You never agreed with it to start with, and you always said that WP:MOSNUM is only a guideline and not policy, hence I understand perfectly this retreat into your secondary trench. I bet you also regret wasting so much time banging your head against a brick wall. I'm sure our paths will cross again soon enough. Ohconfucius (talk) 06:45, 2 January 2009 (UTC)
Well, I've read all of the above (including both the RfC's and their talk pages), so perhaps you'll indulge me while I explain what I'd like:
I'd like to be able to go to any article that has mixed date formats and slap <date>...</date> around each one, confident in the knowledge that anybody who looked at the article afterwards would see a consistent format. That is, without having to search the history for the first person to insert a date; and without getting involved in an argument about whether the subject was best known for their relationship to the US or not.
That's not much to ask for, surely?
I could be wrong, but I'd suggest that for that to happen, we need 3 or 4 things:
the ability for the parser to recognise <date>...</date> tags and output a date in a directed format - then a mechanism to decide the format:
a default date format - in the absence of any other direction. (I'll suggest d mmm yyyy just to get the ball rolling);
a template like {{defaultdate|us}} or {{defaultdate|int}} which would go (just once) at the top of an article giving formatting direction to all dates within <date>...</date> tags in that article. The correct template to use for the article could be argued about ad nauseum on the article talk page and, frankly, I wouldn't care because, either way, all the displayed dates would be consistent and I could spend my time on more useful things.
I'm willing to concede that many people would also like to have the ability to set a user preference which would override all the above and display dates to their preference. I wouldn't use it myself because I want to see (and correct) all those inconsistently formatted dates, but I'm content to accept that others might want that.
To that end, I'd suggest that the developers, should they wish to accept the mission, ought to produce solutions to the first three before worrying about the fourth. Thanks for listening and Happy New Year --RexxS (talk) 04:57, 3 January 2009 (UTC)
Nonstandard date format?
There is some discussion going on at Template talk:Date#Bug for the ymd output about the date format "yyyy mmm dd", or 2024 December 27. Although this seems to be in use on a handful of articles, it is not covered or endorsed by MOSNUM; we're wondering if it is explicitly or implicitly proscribed. Comments welcome. Happy‑melon15:54, 30 December 2008 (UTC)
Has anyone ever seen a date such as 2008 December 30 outside Wikipedia? (And I'm not talking about dates in Chinese. I wrote December, in English.) --Army1987 – Deeds, not words. 16:07, 30 December 2008 (UTC)
Yes, I have seen it used quite a bit. The Chinese, Japanese, Koreans, etc. often use dates like "2008 December 31" when writing in English. Multinational companies sometimes make it a corporate standard when they got fed up with internal debates over whether to use "December 31, 2008" or "31 December 2008". I've got my own preferences set to that format since I can never decide whether I'm feeling more European or more American on any particular date. The short form "2008 Dec 31" is common in computer applications, particularly for genealogy. In additional to being non-American and non-British, it has the advantage that you can do an alphanumeric sort by year when you don't particularly care about which month something happened in.RockyMtnGuy (talk) 05:36, 31 December 2008 (UTC)
Over here a question has arisen over which unit is most appropriate to express the volume of cubby (storage) compartments in cars. The cubby bins (such as the glovebox, for example, and similar compartments located elsewhere in the car) are used to store miscellaneous solid items of irregular shape and size, just like the luggage compartment and the passenger compartment. I live in a country that has long used SI Metric measurements, and have never seen litres used to specify the capacity of a cubby bin, a luggage compartment, a cargo compartment, or a passenger compartment on an automobile (or the interior volume of a microwave oven, or of a refrigerator, or…), always only ever cubic metres (or cubic centimetres, if it's too small to express neatly in cubic metres). MOSNUM is clear that SI units are preferred, but which SI unit is to be preferred in such a case as this? —ScheinwerfermannT·C03:32, 31 December 2008 (UTC)
IMO, it is best to look towards current literature on the subject. Check out what most car manufacturers use in their various print and Web-based Tech Specs. Look also towards auto-enthusiast magazines. If it is an American-made car and they use cubic feet or cubic inches, I would use that unit as the primary one and make the conversion metric. Remember, “cc” as in 749 cc motorcycle engine is not SI-compliant but Wikipedia “goes with the flow” here. So if the car manufacturers usually use “cc” for cubby/glove compartment volumes, use that terminology rather than SI-compliant cm3 or mL. If the car manufacturers rarely specify such things, then I would use the unit of measure which seems most natural for the intended audience (auto enthusiasts). In this case, I anticipate it would be cc for metric and cubic inches for U.S. customary.
Looking towards current literature should avoid the requirement that every single question like this has to come to MOSNUM to be resolved, where the editors that frequent this venue must suddenly try to become a world-class expert on this or that subject based on a whole five minutes of Google searches. We’re good, but not that good. Greg L (talk)05:16, 31 December 2008 (UTC)
I thought about this recently and I don't think that there is a preferred metric unit for cargo volume. Chrysler uses cubic feet (m3) on its vehicle specification (here) but in one press release for North America, Chrysler uses cubic feet only (here), but in the "Outside North America" version, they use Litres (cu. ft.) (seen here). So for this example, it is hard to tell. As long as there is a metric conversion we should be ok (in terms of the MOS). Oilpanhands (talk) 16:23, 31 December 2008 (UTC)
The preferred SI units are cubic metres (m3) and cubic centimetres (cm3). Litres (L) are an allowed, but not preferred unit. It's preferable to use SI-compliant units since these are unambiguous and globally recognized. The abbreviation "cc" is a historic, but depreciated, version of cm3. The problem with using old and industry-specific units and abbreviations is that young people and/or people outside the particular industry don't understand them. I could cite numerous examples of units from the oil industry, for instance, that I would be the only person here who understands.RockyMtnGuy (talk) 18:29, 31 December 2008 (UTC)
I am not sure what you mean by 'preferred SI unit'. The BIPM doesn't use the term 'preferred'. The litre is not an SI unit at all but is 'accepted for use with SI'. Sorry to be pedantic, but an element of pedantry is a good thing at MOSNUM. :) Lightmouse (talk) 19:16, 31 December 2008 (UTC)
Indeed, that unit of time known as the hour isn’t an SI unit of measure. As I write this, it is 2.9 ks from a new year in Zulu time. We should resist the temptation to make Wikipedia appear as if we wear white robes and stroll with tranquil expressions down gilded roads. The objective should be to always communicate accurately with minimal confusion. Often, that will be with non-SI units of measure like cc in certain disciplines (*look of disapproval from the robed crowd*). Greg L (talk)23:11, 31 December 2008 (UTC)
For an American-made car, there should really be no question about using "litres" or "cubic metres". Use the good old he-man sized American "liters" rather than those dinky little "litres", where it takes 4.5+ of them to make a gallon, rather than only 3.8+ liters.
Either litres, liters, cubic metres, cubic meters should be equally acceptable. We don't need to be overly specific in the Manual of Style.
We'll never get every example of what Chrysler uses in any case, and it isn't particularly relevant. What matters is that the units are used in this context. It matters not one whit what any particular manufacturer uses in it's literature; what matters is what is in actual use in a broader sense, and in this case, both liters and cubic meters (including prefixed versions) are in fact used. We are entitled to our own house rules; each article does not mimic the idiosyncracies of the manufacturer of a particular product. Gene Nygaard (talk) 23:33, 31 December 2008 (UTC)
Surely most readers would be comfortable seeing gallons/liters for the fuel tank and ft³/m³ for the trunk. I know a one-gallon milk jug is about 6×6×10 inches, so I could fit about six into a 1.5 ft³ box if it's shaped the right way. Without using a calculator I'd never realize I could pour 11.2 gallons into the same compartment. Similarly I would be very lucky to fit a case of (24) one-liter bottles into a 42 liter space. Typ932's concern seems to be that "none use qubic metyres fro so small things" as 0.042 m³. This has some merit but I don't think switching to a predominantly liquid measurement will help the readers much. Perhaps native metric speakers will disagree. — CharlotteWebb00:25, 1 January 2009 (UTC)
I think common usage is relevant, standards are relevant, and house preference is relevant. I won't be bound by the decision of a couple of suits at Chrysler, particularly when it comes to metric units. Furthermore, Wikipedia is not a specialist and regional publication so terms like 'CID', 'MBBL', 'cusec', 'tcf' rank lower in the acceptability stakes on Wikipedia than they do in the relevant nerds monthly magazine. Lightmouse (talk) 21:04, 1 January 2009 (UTC)
Happy New Year everyone, and since the discussion seems to have moved on to units of measurement, I assume the dates issue is no longer a hot topic. Therefore:
{{editprotected}}
Please remove the underdiscussion tag from the "Date linking and autoformatting" section (or update it to point to an extant discussion, if such is still taking place somewhere). I think we can also dispense with the footnote now; or at least update it to refer to a more recent and authoriatative discussion like the RfCs that were going on in December. --Kotniski (talk) 12:42, 2 January 2009 (UTC)
This is done. I've both removed the underdiscussion tag and added a link to the RFC in the footnote. Thanks for the reminder. Karanacs (talk) 17:05, 2 January 2009 (UTC)
It's no longer a "hot topic", but I can't say that consensus as to the interpretation of the guideline is established. There is definitely a weak consensus that year links should not be summarily removed, although I have no objection to any of the removals I've noticed Linkbot doing. — Arthur Rubin(talk)16:27, 4 January 2009 (UTC)
Centralized discussion for linking of units of measurement
During a recent WP:ANI discussion:[3] it came to my attention that Wikipedia guidelines are inconsistant with regards to linking units in articles. This is an attempt to provide a consistant usage across ALL relevent guidelines. That this discussion is happening at this page is somewhat arbitrary; the intent is just to have a single location to have the discussion. Other relevent pages will be notified as needed. --Jayron32.talk.contribs21:16, 31 December 2008 (UTC)
WP:MOSNUM states clearly that units should be linked at their first occurance in an article only, and not at further occurances.
WP:OVERLINK states clearly that common units should not normally be linked, falling explicitly under the category of "plain English words".
WP:MOSLINK states "In tables and infoboxes, units should not be internally linked to Wikipedia pages" but says nothing about article body text on the issue.
<please add additional guidelines here as needed>
Comment. We cannot add to this list now, and give the false impression that the information was available when people started voting on these proposals. The whole procedure is fatally flawed. Gene Nygaard (talk) 23:00, 31 December 2008 (UTC)
Reply: This is not a vote. This is a discussion to figure out a) what needs to be fixed and b) how to fix it. Feel free to add any guidelines that may be missing. It is entirely possible that these three pages are the only three which are affected. We are discussing the principle, and the principle holds regardless of which policy and/or guideline page are affected. --Jayron32.talk.contribs02:39, 1 January 2009 (UTC)
It most certainly is framed as a vote, and improperly and prematurely so.
From reviewing the discussion on this matter of linking, many people on both sides are making a dangerous assumption here, that the Manual of Style is a form of Wikipedia policy. I do not believe this is correct: the Manual of Style is a systematic expression of Best known practices. In other words, its power is persuasive, not prescriptive; one does not get penalized for violating the MoS, & attempting to advocate something in the MoS without an appropriate discussion is the same as trying to advocate a specific point of view in an article.
If everyone persists in this belief despite all else, then the most appropriate thing is to make the MoS as permissive as possible, & instead of having an MoS Wikipedia should have a collection of essays setting forth the best known practices to solve various problems of style. This actually might be the best solution, regardless of the outcome of this RfC: is there a clear philosophy of when & why to add hyperlinks to webpages? Numerous people have argued that adding links is to help the reader to find more useful information -- but how do we know that this is why a reader might follow a link? For example, I often followed links in Wikipedia -- & off it -- for reasons other than to deepen or clarify my knowledge of given point or subject. Until we have an idea of why we should link, & when it is most useful for readers, then enforcing any kind of MoS on specific kinds of links -- whether common or uncommon units & dates -- then we will simply argue endlessly over what to do. -- llywrch (talk) 02:21, 2 January 2009 (UTC)
Units should only be linked on their first occurance in the main body of an article. They should not be linked multiple times in the same article, nor should they be linked in infoboxes or tables.
— Greg L (talk)21:58, 31 December 2008 (UTC) Seems sensible. I might add that we be a bit more specific about the accompanying parenthetical conversions to other systems of measurement: they should not be linked. I believe this is already embodied somewhere on MOS or MOSNUM. The unit of measure in the conversion is supposed to be only a unit symbol (not spelled out), and, when you think about it, it’s for people who go “Ah, that’s what the value means,” so it isn’t at all necessary to link the conversion. Besides, it avoids the need for a parenthesis in a parenthesis and finally gets that issue off our backs.
Gene Nygaard, in his 20:31, 26 December 2008 post, above, wrote of the need to use square brackets to properly convey a parenthetical within a parenthetical. He wrote “So I'd put square brackets for the parenthetical symbol within the parentheses” and gave the example “56,000 pounds-force (lbf) (250 kilonewtons [kN])”. I am saying that since MOSNUM already prescribes that only the unit symbol be used in conversions, his example of adding a parenthetical unit symbol within what is already a parenthetical conversion is unnecessary. Further, we should clarify that it is not at all necessary to link the unit symbol in the conversion since it is provided only for those who find comfort with it anyway.
Therefore, I believe the way this is properly done (and what I’ve seen on Wikipedia) is—on a first occurrence of a new unit of measure, it is “…they first achieved a tractive force of only 56,000 pounds-force (lbf) (250 kN)”. Thereafter in the article (after the new unit of measure has been introduced), it is “…and was later increased to 68,000 lbf (300 kN) after a year-long…” To preempt unit-war Jihad here, I used the example here of US customary units, with SI as a conversion, only to follow Gene’s example. Please don’t misconstrue my example as advocating US customary as a preferred system of measurement; I don’t and that issue is irrelevant to the point being made here. Greg L (talk)02:41, 1 January 2009 (UTC)
Quite to the contrary, Greg. The MOS 'requires that parenthetical "kilonewtons" to be spelled out, under your official MOSNUM interpretation of the meaning of "do not write over the heads of the readership". That's why, if you are going to include the symbol parenthetically to that, it should be in square brackets. Gene Nygaard (talk) 12:26, 1 January 2009 (UTC)
--That is what I have always done and what I was taught when I got here a couple years ago, let's stick with it. If it ain't broke, don't fix it. - NeutralHomer • Talk • January 1, 2009 @ 15:27
Support, although in the end a clarification of what exactly a "first occurence" is would be needed (some articles are very very long, some have infoboxes with units, etc.).—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); 19:38, January 7, 2009 (UTC)
Discussion of this proposal
I think this is very reasonable. It offers a clear-cut balance of middle ground. Saying that all units should always be linked is well-- ridiculous and not linking at all (even the common ones) is not reasonable either. Once an article is more than fair and balanced. —MJCdetroit(yak)21:29, 31 December 2008 (UTC)
Comment. Note one of the explicit provisions of WP:Overlinking: "A link that had last appeared much earlier in the article may be repeated, but generally not in the same section." This suggestion goes beyond that. Gene Nygaard (talk) 22:00, 31 December 2008 (UTC)
Gene raises a good point. Perhaps “…generally should not be linked again in the article…” would be better. Absolutisms should be avoided. I suggest that be quickly corrected, lest we rip a hole in the fabric of space-time with something that Gene and I agree should be done. Greg L (talk)23:04, 31 December 2008 (UTC)
Proposal 3:Almost never link
In articles which discuss units or systems of measurement directly, it may be desireable to link the first occurance of a unit name. However, units should never be linked in an article in situations where they are being used merely as a unit label.
There would have to be a very good reason to link. A key problem is that the pages in question do not readily provide the assistance that a reader might want. I'm assuming that arcane historical facts about metre or stone are not the object. Tony(talk)02:08, 1 January 2009 (UTC)
Discussion of this proposal
As far as I am concerned, this seems the most logical way to handle units. To me, they seem to be common enough that we should treat them like colors, days of the week, and other such common terms. --Jayron32.talk.contribs21:18, 31 December 2008 (UTC)
Like colors, days of the week? Holy cow, don't you think we use anything more complicated that "five inches" or "37 kilometers"?
Let's, for example, take stone, a unit of mass which is completely foreign to North American usage. Maybe one person in 10 has the foggiest notion what this is, one in 100 might have some feel for what a measurement expressed in those units means, and fewer than one in a thousand have it in their active vocabulary, as something they might use in their own conversation or writing.
Good point. Though I am not sure that phrases like "get real" engender a collaborative environment where people work out problems in a pleasant and congenial manner. --Jayron32.talk.contribs21:36, 31 December 2008 (UTC)
Providing no help whatsoever for many people. And--with a metric equivalent that isn't spelled out, but rather is only cryptically encoded in a symbol, according to the strange and inappropriate rules of MOSNUM. And that cryptic symbol itself SHOULD BE LINKED BECAUSE IT ISN'T SPELLED OUT IN FULL anywhere in the article. Gene Nygaard (talk) 11:45, 1 January 2009 (UTC)
Furthermore, there is no general requirement that any conversions be included. There are a great many Wikipedia articles which do not include those conversions. And there are also articles in which conversions of some units to the SI equivalents are excluded. Gene Nygaard (talk) 12:36, 1 January 2009 (UTC)
Providing conversions is more useful than providing a link. If a single conversion does not help some people (besides stones, nautical miles spring into mind), multiple conversions should be provided (e.g. "11 st 4 lb (72 kg; 158 lb)" or "10 nm (18 km; 11,2 mi)"). — 3247 (talk) 01:54, 2 January 2009 (UTC)
Under no circumstances should a unit name be linked.
Support of this proposal
Discussion of this proposal
Proposal 5:Link uncommon units only
Common metric and standard units of length, weight/mass, and volume should not be linked, but uncommon, technical, or archaic units should be linked per standard linking guidelines.
Note: If this guideline passes, we can hammer out a list of units which are common enough not to need linking; this is just to establish support for the principle rather than an exact list right now.
Note: This is the current guideline at wp:overlink and that page gives examples of *common* units already.
--Of course. Still keen to pursue the idea of a centralised article to help readers acquire a feel for the standard metric and imperial units, where they wish. Tony(talk)13:07, 1 January 2009 (UTC)
I remind everyone that the guidelines at WP:OVERLINK have been part of this discussion since the get-go, so Lightmouse's statement here is what? Nothing at all, really.
And for once the preliminary matters were taken care of, and notice of this discussion was placed at WT:OVERLINK. If we come up with any changes here, it can be changes at WP:OVERLINK, changes at WP:MOSNUM, or both. Gene Nygaard (talk) 14:35, 3 January 2009 (UTC)
Oppose, they need to be both "common" in the particular context in which they are used, and unambiguous in that context. There is no need to link the common length units foot, inch, centimeter and meter and mass units pound and kilogram when talking about a persons height and mass. There is no need to link degrees Fahrenheit and degrees Celsius in the climate section of a geography article, nor millimeters of rainfall or centimeters of snowfall. Even liters per square meter might not need a link if they are accompanied by a conversion to length units, but there is no guarantee that they will be. But any article which uses not-universally-understood units like "lbf" should always be linking them, and also linking "lb" if they are used in the same article. Any article using tons, ounces, quarts, or gallons--all "common" units, but horribly ambiguous--can benefit from both links and visual disambiguation. What we need to be concerned with here is the problem that caused this discussion in the first place: How much of this do we dare consign to a bot-runner who will push things to every limit possible, and how much do we have to reserve for the discretion of live, thinking editors? Gene Nygaard (talk) 06:45, 6 January 2009 (UTC)
Discussion of this proposal
I think there is an important difference between "instruction creep" and reducing both the number of suggested actions and removing ambiguity and/or downright contradiction between existing ones. BenMacDui12:08, 1 January 2009 (UTC)
I propose that we merge this proposal with proposal 7. They are very similar. Proposal 5 is a radical proposal to mandate linking uncommon units, proposal 7 is merely the continuation of the existing guidance of optional linking of uncommon units. Lightmouse (talk) 20:13, 1 January 2009 (UTC)
Is the gallon a "common" unit ? Is the meter a "common" unit ? Please make an explicit list of what units are "common". Thank you ! Nicolas1981 (talk) 18:26, 4 January 2009 (UTC)
The current guidance at wp:overlink gives examples of *common* units and has done for some time. Just click on the [2] at the end of the guideline. The list itself can be modified, of course. Lightmouse (talk) 18:43, 4 January 2009 (UTC)
It does not do so in stating the rule. It does so only in a footnote, which is not standard Manual of Style procedure, not something the typical editor going to the Manual of Style is going to be looking for. And furthermore, as I have pointed out above, the wording of that page is every bit as much an issue here as the wording at the dates and numbers page. And it doesn't answer any of the questions above about gallons, for example--in mentioning English units, using the convoluted "imperial or US" description, it gives four units of length. It isn't really an acceptable list--but it shouldn't be, either. What is a "common" unit is context-dependent. It isn't predetermined by the name of the unit alone. Gene Nygaard (talk) 19:44, 4 January 2009 (UTC)
Proposal 6: Units of measurement require no special mention
Users should use context and common sense when linking units of measurement. Existing guidelines on linking and overlinking adequately cover this material, and no special mention of units of measurement should appear in any guideline. Any existing mentions of linking units or not doing so should be removed to prevent confusion.
Support of this proposal
Would I ever link inch? - no. However this seems to me a clear case of instruction creep. I trust the editors to make sensible decisions and even if they don't it is hardly a disaster.Dejvid (talk) 10:09, 1 January 2009 (UTC)
Discussion of this proposal
This idea seemed implicit in several comments in the discussion below. I do not personally support it, but it seems like a reasonable idea given some comments others have left. --Jayron32.talk.contribs02:29, 1 January 2009 (UTC)
Ideally the same kind of common sense which applies to other words should apply to the names of units of measurement. The problem is that it isn't being applied. Editors seem to think of units as being special and thus they tend to attract overlinking. So some mention should be made (at least for now), if only to tell editors not to treat the units as special. JIMptalk·cont11:06, 6 January 2009 (UTC)
Proposal 7: Do not mandate linking but discourage overlinking. Continue with current wp:overlink guidance 'generally don't link common units'
This proposal is to continue using the current guidance at wp:overlink. It says: It is generally not necessary to link:
Plain English words, including common units of measurement (particularly if a conversion is provided).
Examples of common measurements include:
units of time (millisecond, second, minute, hour, day, week, month, year)
metric units of mass (milligram, gram, kilogram), length (millimetre, centimetre, metre, kilometre), area (mm2, etc.) and volume (millilitre, litre, mm3, etc.)
imperial and US units such as inch, foot, yard, mile, etc.
combinations of the above (e.g., m/s, ft/s).
Links may sometimes be helpful where there is ambiguity in the measurement system (such as Troy weight vs Avoirdupois weight) but only if the distinction is relevant.
Likewise, in an article on units of measurement or measurement in general, such links can be useful.
This proposal is similar to proposal 5, however proposal 5 mandates linking to uncommon units. This proposal doesn't mandate anything.
Support of this proposal
Support. There is no need to link a plain English word (e.g. river) even the first time in an article. Similarly, there is no need to link common units even the first time. Common units are so excessively linked that they are very high in the list of 'most linked' articles. We don't need to link the common units each time you describe the height of a mountain or the height of a person. Lightmouse (talk) 12:40, 1 January 2009 (UTC)
Support—I agree with Lightmouse, who has vast experience of this issue through his sustained hard work in auditing a number of important mattters in WP articles. Let's make our unique wikilinking system work optimally by not watering down the links we want readers to click on. Every link comes at a slight (dilutionary) cost that must be balanced with its utility and relevance to increasing the reader's understanding of the topic. Tony(talk)13:13, 1 January 2009 (UTC)
Oppose—This is the right idea; it just sweeps up too much overly complex things, like mm3 and mm2, ft/s, etc. This sort of notation (setting aside the issue of linking it) may be appropriate in clearly-scientific articles (not general science-related articles like Water). I’ve been active in simplifying crud like a first-occurrence of “m s−1” to something more reasonable like “meter per second (m/s)”. Just because American school children and my own mother made a poor choice about the country in which to be born, we need to ensure our articles are fully accessible for everyone. Note also that we should not be be writing articles using advanced math notation typically found in science papers (m s−1) for articles like Speed of light.
“Science” is metric. So disciplines like chemistry or fuel cells are pure metric. Short of this, authors here have to resist the tendency to not provide a conversion and assume that everyone knows what a mm3 or “ft/s” is. Everyone does not. Everyone understands what “100 km/hr (62 mph)” means because either the primary or conversion is an every-day measure and unit of measure expressed in the format used in everyday life. Even if we link “m s−1”, such an expression is unnecessarily complex in most articles. And even if America went metric and carpet was sold by the square meter, it would never be advertised and priced with “m2”, it would be “$ per square meter”.
In our general-interest articles, common measures and the most common units used in daily life to express those measures need not be linked so long as it is the sole unit used in all English-speaking countries (every-day units of time), or a parenthetical conversion is provided. This would comprise common, every-day measures like “hour”, “second”, “0 °C (32 °F)”, “three meters (10 ft)”, “10 kg (22 lbs), “60 mph (97 km/hr)” (in an article on an American-made car), and “28 psi (190 kPa)”.
I’m going to read through all these various proposals and make an *attempt* at tying it all together into a something that addresses our readers needs without making our science-related articles cumbersome and without making our general-interest articles inaccessible to large portions of our readership. Remember, linking (turning a word or two blue) has extraordinarily little footprint in articles, so there is no need whatsoever to cast an overly wide dragnet on units that should be exempt from linking; the truly-everyday stuff is sufficient.
Finally, we should always, always write out the first occurrence of a unit of measure. Even in our computer articles, it should be “The WindowsPig 9000 was first introduced with 1 gigabyte (GB) of random access memory (RAM) before it was later configured with its standard 2 GB of RAM.” Greg L (talk)19:49, 1 January 2009 (UTC)
This is riddled with nonsense.
Let's start with improper symbols like "km/hr" and "lbs" and the like. If you can't even follow the rules here on the talk page, I don't like you trying to write the rules.
Giving examples of conversions with undue precision in the conversion is never helpful.
Not all science is metric.
Much of what is metric is still in need of conversions. Nobody should ever be using creaky old cgs units from the dark ages without providing conversions to SI units. No "3.7 mGal", but rather "3.7 milligals (37 mm/s²)". Things like that.
Why wouldn't carpet be $10/m²? Even symbols such as ft³ and and the like are actually common in American usage.
This ignores the myriad of conflicting guidelines set out above and does not tackle that issue. The problem here is that we have too many pages of guidelines that state different things. Woody (talk) 13:14, 1 January 2009 (UTC)
Much of that problem is due to instruction creep for which we can thank a couple of editors.
A great many of the common units are also ambiguous units in need of linking for disambiguation purposes. That solution just doesn't cut the mustard. Gene Nygaard (talk) 14:02, 1 January 2009 (UTC)
“millisecond”? My wife has been married for 28 years to a mechanical engineer who worked in R&D for most of that time and she doesn’t know what a millisecond is. So that one is clearly over the top. She guessed “is it a millionth of a second?” Then she said “Is this one of those ‘dumb tests’ ?” “No honey.” “Yes it is; it’s one of those ‘my wife didn’t know what a millisecond is and she’s representative of the typical stupid person,’ things isn’t it??” “Nothing compares to your love baby.” Now look at what you guys got me into… Greg L (talk)18:14, 1 January 2009 (UTC)
Proposal 8: There is a distinction between linking spelled out words and linking symbols not otherwise explained
Normally, this wouldn't be a problem.
But it is a problem here, first of all, because of half-thought out rules at MOSNUM prohibiting the spelling out of the units, even on first appearance, when they appear only in conversions. That is, unless GregL's interpretation of "do not write over the heads of the readership" is correct, in which case what we have is a conflict in the rules about spelling out those units.
A second reason it is a problem is that many of our MOS rules are based on the premise that the readers of Wikipedia are too stupid to understand what the superscript 3 means in "ft³", and therefore we must allow the use of "cu ft". But if they don't understand ft³, they aren't going to understand the 2 in km² either. So symbol coming out of the blue (i.e., not accompanied by the appropriate spelled-out phrase) and containing a superscript needs to be linked.
The current wording of the MOS doesn't actually prohibit the use of ft³ as it once did. However, the commonly used template {{convert}} only gives results as "cu ft" and doesn't provide for any method to change that to "ft³". And that is relevant because of the Manual of Style provision that
{{Convert}} or unit-specific templates from Category:Conversion templates can be used to convert and format many common units in accordance with this manual of style.
(Note also that there isn't any real basis for an assumption that using such templates will give results in accordance with the Manual of Style.)
We should not use "ft³" because it is illegible. I don't think superscript notation for volumes expressed in American customary units is a good idea, because some readers may not have the math background to recognize the meaning of such units easily. If people insist on using superscripts in this situation, they should be legible: "ft3". --Gerry Ashton (talk) 14:17, 6 January 2009 (UTC)
Support of this proposal
Support Spelled-our names of units and symbols for them are two different things. We should not be lumping the two together indiscriminately. See more in the discussion below. Gene Nygaard (talk) 16:44, 1 January 2009 (UTC)
Discussion of this proposal
What we really need to do is to fix the senseless rules about spelling out and not spelling out units of measures in the first place. These rules totally ignore the way that conversions are usually used. Most people only read one or the other of the units when a conversion is given—and there brains often do not do any processing whatsoever of the information given in the other units, just discarding it before it even gets into their short-term memory.
For example, if we have that some place X "is a village located 37 miles (58 km) from" Y,
Some people will read this as X "is a village located 37 miles from" Y
But others must first mentally expand the symbol km, then read it as X "is a village located 58 kilometers from" Y
Similarly, if we have that some place X "is a village located 58 kilometers (37 mi) from" Y,
Some people will read this as X "is a village located 58 kilometers from" Y,
But others must first mentally expand the symbol mi, then read it as X "is a village located 37 miles from" Y,
Proposal 9: Withdrawn as it's essentially a subset of Proposal 10 below
(I will not even try to propose a specific wording, only to express my opinion.)
Linking "kilometre" in X is a village located 58 kilometers (37 mi) from Y is quite pointless, since virtually any person able to understand written English uses either the kilometre or the mile (or both) in everyday use. But if, for some reason, we were to only use one of these units, linking "kilometre" (the first time it is used) might be useful, for those who don't use it everyday.
I propose that we should not link units for which a conversion is provided to both sets of "everyday units", so to speak, i.e. to an unit in each of the columns of the following table:
second, minute, hour, day, week, month, year, decade, century, millennium
Temperature
degree Celsius
degree Fahrenheit
Speed
kilometre per hour
mile per hour
Energy
kilowatt-hour, kilocalorie
etc.
I hope you get the point
In other words, "Group 1" should comprise all and only those units an average European grandmother understands, and "Group 2" those which an average American grandmother understands, but unlike the current "common units" wording, they exclude the electron volt, the kelvin, and other such units which are commonly used in a particular context but not in everyday life. (I have almost surely failed this in my own table—can someone native to the US check whether there are too few or too many units in group 2?) And, of course, units should be linked when they're otherwise relevant to the context, e.g. in article about systems of measurement and the like. --Army1987 – Deeds, not words. 20:19, 1 January 2009 (UTC)
Proposal 10: Tying all the principles of linking together
The first bullet point, below, may not make sense at first pass. Here is the logic: If we provide parenthetical conversions for familiar measures at every-day magnitudes (not the units of measure, such as kilogram or carats, but the measure, such as temperature and mass in familiar ranges), then there should really be no need for linking the unit of measure—regardless if it is metric or U.S. customary.
Example: older Americans will very often not understand that “kilogram” is a unit of mass, let alone have a flying clue as to its magnitude. But when common measures have accompanying conversions—like80 lb which is the weight of a sack of concrete—that clearly clarifies potential ambiguity by instantly and intuitively providing the “ah Haa” for both the measure and its magnitude. This principle clearly won’t work with obscure and scientific units of measure. Remember, the principle is not that “everyone knows what a kilogram is”; it is “if someone like an American doesn’t understand36 kg, they will always understand36 kg (80 lb).
Linking of units of measure
The first occurrence of a unit of measure should not generally be linked if it is a common measure expressed in every-day units of measure and a parenthetical conversion is provided. For instance, write Sacks of concrete premix in Germany are typically 25 kilograms (55 lb), whereas in…. Other common measures that should typically not be linked are as follows:
Speed or velocity: the common units kilometer per hour and miles per hour, but not feet per second nor kilometers per second
Temperature: the common units degree Celsius and degree Fahrenheit but not kelvin
Mass/weight: the common units kilogram, pound, gram, and ounce (provided the U.S. customary units are in the avoirdupois context)
Length: the common units meter/metre, foot, yard, centimetre/centimeter, inch, kilometer/kilometre, mile (statute)
Volume: the common units milliliter/millilitre, litre/liter, fluid ounce, quart, and gallon (provided the U.S. customary units are in the 1/32/128 ounce per liquid gallon context), but not cubic meter/metre, cubic feet, cubic inches, etc.
Common units of time should not generally be linked since they are extremely familiar to all English-speaking peoples. Editors should not generally link second, minute, hour, day, week, month, (and year when in general, non-scientific contexts); but should generally link the first occurrence of units such as millisecond and microsecond.
It is good practice to use the full unit name of units of measure throughout an article if the unit occurs infrequently enough that it would not make the article cumbersome to read. Where unit symbols are used in an article, always include the unit symbol parenthetically immediately after the first occurrence of the full unit name. Thus, editors should write The Banana Jr. 9000 computer’s stock configuration was 2 gigabytes (GB) of random access memory (RAM) before one later writes optional configurations offered RAM capacities as great as 64 GB.
Except as exempted above, the first occurrence of a unit of measure should generally be linked. Write The light intensity over the metrology table was 800 lux (lx) before later writing The light intensity in the warehouse was satisfactory at 100 lx and the employer….
In science articles and other articles where no parenthetical conversions are provided, always link the first occurrence of a unit of measure. Write the typical batch totals 2,500 kilograms (kg) and includes… before one later writes then 2 kg of polyglycerol polyricinoleate is added.
Always use unit symbols in parenthetical conversions (not the full unit name) and, except as provided above, the unit symbols in conversions should generally be linked. Write The .450 ACP with factory ball ammunition develops a muzzle velocity of 830 feet per second (ft/s) (250 m/s) before later writing but the lightest bullets can generate velocities as great as 1,060 ft/s (320 m/s).
Support/Oppose for this proposal
Support I am hoping this ties together many of the issues that are touched upon when we discuss units of measure and when to link them. Greg L (talk)23:04, 1 January 2009 (UTC)
Support the idea, though the wording might be made clearer and more concise (I'll give a try tomorrow, after a good sleep helps me completely recover from my hangover from the New Year celebration). --Army1987 – Deeds, not words. 23:57, 1 January 2009 (UTC)
Oppose. More of the typical instruction-creep overkill, attempting to be overly specific.
Double-negatives don't fly. They have no place whatsoever in our guidelines.
Inconsistent, non-parallel construction switches between the singular and the plural
A great many of our articles include both the pound and the pound. Links aren't provided because these units are unfamiliar. Rather, the links are provided to help make it clearer that the two are different units of measure, and to link to a place where readers can find more information about what distinguishes one of them from the other.
If the only use of either of those two units is as a symbol "lb" standing alone, because of weird MoS rules prohibiting the spelling out of the unit's name, then that should be linked because many people use "lb" when it is the less-common lbf, and if you don't have both of them in the article, it isn't evident. And "lbf" itself is unfamiliar enough in everyday as opposed to scientific usage, so that if that is the only way in which pounds appear in the article, that symbol should also be linked.
A great many "scientific articles" do, and should, provide conversions of various sorts.
Of course, the initial problem is the invitation for arguments about the meaning of the vague term "scientific articles". It isn't necessary here, either. It doesn't matter what the reason is for not including unit conversions; what to do when there are no unit conversions should not depend on why there are no conversions.
Part of the problem here is a silly, unwarranted notion that the only conversions we have are between metric and English units (and the refusal even to simply call the English units that, rather having to throw in convoluted combinations such as "U.S. customary or imperial units"). That simply isn't true, and should never be assumed to be the only applications of unit conversions in our MoS.
The use of "US customary" in characterizing these units is objectionable because what is being discussed is not limited to U.S. usage. Even worse, of course, would be using "imperial units" here.
The principle of writing out units at least on first use should be every bit as applicable to units appearing as conversions as those appearing anywhere else.
That is especially true when the units appearing in parentheses are not the converted units but rather the originals, but the converted measurement is expressed first. There are lots of different reasons why the conversion is expressed first with the original measurements expressed in parentheses--these include WikiProject conventions for a particular groups of articles, and simply the whim of the author who put the measurements in in the first place, and every so often we get some editor running around trying to change articles in accordance with his or her belief that "metric units should go first" or whatever.
Let's just be more explicit about that: The terminology in this proposal "parenthetical conversions" is nonsense. What is included parenthetically in not necessarily the conversion.
The basic principle "the first occurrence of a unit of measure should generally be linked" should appear at the beginning of any such section, not a screen or two below a bunch of tedious over-specificity. That's just one of the many ways in which this whole proposal is sloppily written. Gene Nygaard (talk) 07:41, 2 January 2009 (UTC)
Oppose. I can't believe that I am agreeing with Mr. Nygaard, but do we really need an additional 438 words to try to avoid a few blue links. Link the first occurrence only. Five words and a period. The end. —MJCdetroit(yak)04:57, 3 January 2009 (UTC)
I have an even better suggestion; even five words is overkill:
Zero words here (i.e., remove what was here before)
Then just general don't link more than the first occurrence, and we don't need to encourage linking that (it will most likely be linked when it is appropriate, and it doesn't hurt if first occurrence is linked even if some wouldn't find it necessary. Gene Nygaard (talk) 07:56, 3 January 2009 (UTC)
Isn't this essentially the same as my Proposal 9, with just some more istruction creep about when to spell out the name?
As for the wording (but not the spirit, I think I understand what you mean) of it, taken literally it implies that we should have a link in three days if that's the first time we use the day because there's no conversion, whereas there needn't be any link in 32 cm (320 mm)[1] because there is a conversion.
[1] Never seen anything like that on Wikipedia (until now), but I have seen a can or a bottle with something like 33 cl (330 ml) printed on its label. --Army1987 – Deeds, not words. 23:44, 1 January 2009 (UTC)
Agreed regarding time. I tried to fold that into conversions rather than treat it as a separate class. I will fix it with an added bullet point. Greg L (talk)23:50, 1 January 2009 (UTC)
1) We might want to add millilitre, pint, and quart to the common units for volume. 2) My one reservation is the one I'd raised earlier about specificity of language. The opening of the fourth bullet says "The first occurrence of a unit of measure should not be linked …", while the later sentence in that bullet says "Other common measures that need not be linked …". The first is prescriptive, while the second is suggestive. I still believe that a link to even a common measure is not harmful and could be helpful, so I'd rather we use need in both cases, so that this language could not be used as rationale for automated mass removal of links. Either way, the language needs to be consistent. Mlaffs (talk) 23:53, 1 January 2009 (UTC)
I agree regarding quart. As for pint, perhaps it’s because I hate U.S. customary, or am not a domesticated kitchen type, or am not a drinker, but I barely know that there are two pints per quart. If I’m struggling (and I know my kids do too), then we best link—after all, it just turns text blue so there’s not much downside to linking; ere on the safe side. Man, I love SI. I added quart and some other units like milliliters and fluid ounces. I also addressed your should not issue. Thanks. Greg L (talk)00:05, 2 January 2009 (UTC)
Cool beans — I'd still prefer need not, but if the consensus is that links to common measures really are a bad thing, I'll fall in line. Frankly, I'm just happy to see a MOSNUM discussion mostly not degenerate into rhetoric and hyperbole ;>) Mlaffs (talk) 00:21, 2 January 2009 (UTC)
(e.c.) As for pints, quarts and gallons, I wouldn't consider the link in I drank an imperial pint (0.57 l) of Guinness last night or A tank containing one U.S. liquid gallon (3.8 l) of gasoline evil, since these units shrink/grow when you cross the Atlantic westwards/eastwards; but I won't insist on this point. --Army1987 – Deeds, not words. 00:14, 2 January 2009 (UTC)
I tried to address your point about different pint sizes, and I also tried to address some concerns of Mlaffs regarding overly restrictive verbiage. Greg L (talk)01:03, 2 January 2009 (UTC)
I hope I don’t loose any “support” votes here, but I think we might be able to get others on board—perhaps Gene too—if we link the first occurrence of the unit symbol of a conversion). Besides, I think what I had before was a brain-fart; if we’re not even going to spell out the unit name in the first instance of a unit conversion, it ought to be linked. Greg L (talk)01:24, 2 January 2009 (UTC)
What appears in parentheses isn't necessarily the conversion.
The first appearance of a unit of measure should generally be spelled out, no matter where it appears.
That would obviate, in many cases, the need to link any symbols for units of measure.
And even if there are cases where it isn't spelled out (e.g., it appears only in abbreviated form in an infobox or some other table), there isn't any real need to link symbols that are common in the context and that will generally be understood by most readers without a link.
As Jimp pointed out above, what is "common" (whether we are talking about spelled-out words or symbols for units is context-sensitive. Let's not lose sight of that fact, and try to make broad, over-general claims about what is "common". Gene Nygaard (talk) 08:01, 2 January 2009 (UTC)
Quote "but not feet per second nor kilometers per second" Why ?! km/s is the only practical unit of measurement for space ballistics. fps is somewhat different because of multiple meanings (frames per second, feet per second). NVO (talk) 08:15, 6 January 2009 (UTC)
Comments:
I can't see why a symbol is required in parentheses more than once after initially naming a unit. Who wants to see "2 gigabytes (GB)", "6 gigabytes (GB)", and "3 gigabytes (GB)" in succession, if they are the only times the unit occurs in an article (therefore not "cumbersome" to spell out always).
"Cumbersome" sets too high a bar; it also depends on how common the symbol is. "Km" should be treated more liberally than a relatively unusual or specialised symbol.
"Always write out the full unit name on at least the first occurrence—and often several times—before using the unit symbol."
"If unit symbols are used in an article, always include the unit symbol parenthetically after each occurrence of the full unit name." I find it irritating to have to read the full name after I've been asked to remember the symbol in parentheses. Don't abbreviate if it's not boing to be used, is my by-line. The italicised "are: suggests that using unit symbols is not the default. Why?
"at least" (italicisation unnecessary, IMO) and "and often several times" cause a redundancy issue.
"Always" can probably be dropped. The use of this marker multiple times will weaken its effect. A guideline is a guideline.
"Unless as exempted below, the first occurrence of a unit of measure should always be linked."—I strongly disagree that kilogram or kg should automatically be linked on first occurrence. { Only where there is no accompanying conversion, which is only in scientific articles. This is a first-occurrence issue and what is at stake here is just an issue of turning the thing blue for the benefit of Americans, who often don’t have any idea what a kilogram is.Greg L (talk)05:11, 2 January 2009 (UTC)}
The second and third bullets should be conflated and significantly shortened. The statements in the fourth bullet should be conflated and rationalised.
The fifth bullet should come first.
Why does the example give "feet per second", then "fps", then "ft/s"? Why is the linking of main units/symbols treated differently from that of converted unit names/symbols?Tony(talk)01:35, 2 January 2009 (UTC)
The statement in GregL comment "Only where there is no accompanying conversion, which is only in scientific articles" is totally false and unjustified.
Tony, it assumes "using unit symbols is not the default" for good reason. They aren't the default. Not in actual usage, and furthermore, not in the MoS rules, and they should not be in the MoS rules.
For many of the most common units, there is no reason for including the symbol in parentheses on first use even if the symbol for it is used later in the article. Just write "165 pounds (75 kilograms)" on first use, then later use "100 pounds (45 kg)" in a typical article, or use "100 lb (45 kg)" in a measurement-intensive article. Once people know what to expect, the symbols "kg" or "lb" will be recognized without including them parenthetically.
How would you deal with an article that used "65 pounds (290 newtons)" and later "85 pounds (380 newtons)"?
First appearance: ______________
Second appearance: ______________
I'd sure be interested in knowing how various editors here would fill in those blanks, including spelling and linking and use of symbols and the introduction of symbols parenthetically following first appearance and whatever, if they were copyediting an article containing those measurements. Feel free to add any additional parameters which could affect how you'd deal with them, such as type of article, presence of other measurements, frequency of measurements in the articles, and the like. Gene Nygaard (talk) 08:30, 2 January 2009 (UTC)
Tony, I’m burned out on this one and it’s my son’s last night here before he flies out to complete his training as a Navy Diver We’re watching Generation Kill together right now. It’s getting late here. If you can improve what I got above without loosing any “support” votes, give it a whirl. Greg L (talk)03:10, 2 January 2009 (UTC)
P.S. As for the “fps”, that was just my flat-sloppy work. Now fixed. I also douched the “several times” (for reinforcing the unit symbols). You raised a number of good points. Feel free to tinker wherever you think you can build towards a greater consensus. Greg L (talk)04:55, 2 January 2009 (UTC)
Proposal 10, alternative wording
Spell out and (except as noted below) link the full name of each unit of measurement on its first occurrence; if the symbol is also used in the article, add it between parentheses next to the first occurrence; subsequent occurrences should not be linked, and may use either the name or the symbol:[1]
The minimum current a human can feel is thought to be about 1 milliampere (mA), but currents up to 5 mA are typically harmless.
Very common units need not be linked, even on their first occurrence, in the following cases:
Units of time in widespread everyday usage throughout the English speaking population should not be linked unless they are particularly relevant to the topic of the article.
A unit in the SI or accepted for use with the SI, which is in widespread everyday usage among the general population outside of the United Stated, should generally not be linked if each occurrence of it in the article is accompanied by a conversion to a customary unit in widespread everyday usage in the U.S., and vice versa. For example, no links to units are needed in:
The sacks of concrete premix in America can be be as great as 80 pounds (36 kg).
X is a village located 34 kilometres (21 mi) from Y.
Units which are in everyday usage, and hence generally do not need to be linked per the previous point, include:
Units of time such as the second, the minute, the hour, the day, the week, the month, the year, the decade, the century, and the millennium, but not the fortnight, the millisecond, the microsecond, etc.
...
(U.S. liquid) pint, quart, and gallon;
...
Nevertheless, linking pint, quart and gallon may be useful, because there are both imperial and U.S. customary units with these names and different values. A disambiguation should be used the first time one of those units is used:
One imperial pint (0.57 l) of beer can cost as much as five euros.
The capacity of its fuel tank is 10 U.S. gallons (gal) (38 l). (link optional)
U.S. pint, U.S. quart and U.S. gallon should be assumed to refer to the liquid measures, not the dry ones, unless otherwise specified.
[1] Usually, the full name is preferable if it is not too long and the unit is only used a few times throughout the article, whereas the symbol is preferable for units with very long names (e.g. MeV rather than megaelectron volt, km/h rather than kilometre per hour) and units which are used several times in the same sentence.
I could support this proposal, but the example of GB is particularly unsuitable, because of its ambiguity. Should be replaced by a less controversial example, such as: A fuse breaking at 15 ampere (A) is common. −Woodstone (talk) 14:56, 2 January 2009 (UTC)
Comments. This is much more cohesive and better written. It flows much more easily from one part to the next. It states the general rule at the beginning, rather than hiding it two or three screens further down the page. Even when the list is populated, it won't be bogged down in quite as much overspecificity, and it doesn't state exceptions before it states the rule. Furthermore, while the little-ever-used dry gallons and its slightly-more-common pint and quart subdivisions are limited in use to commodities such as grains and oilseeds, the "liquid" gallons aren't limited to liquids. They are also used for gases, for containers including those not primarily used to hold liquids such as garbage bags, etc.
U.S. gallons almost never need to be disambiguated as "liquid" gallons; the U.S. dry gallon is hardly ever used; even in cases where it could be used, it would usually be called a half-peck or the numbers would be expressed as "12 dry quarts" rather than "three dry gallons" or in fractions of a bushel. Furthermore, there aren't likely to be any Wikipedia articles other than those discussing the units in which the U.S. dry gallon is used. Keep in mind that whatever we write will also be used as a rule by example.
Dunno about these specific point about US units, as I'm Italian. (That's why I didn't even try to write down the list myself.) --Army1987 – Deeds, not words. 15:59, 2 January 2009 (UTC)
Your examples of the use of links for disambiguation purposes would be better linked to imperial pint and U.S. gallon rather than pint and gallon. It doesn't matter (yet) in these particular examples; it will matter when someone gets around to anchoring the redirects to point to the appropriate section in the redirect article.
There isn't really any need to use "kilogram (kg)" before using "kg" later in the article, but the way this is written we would need to. That is a special problem because places such as good article and featured article review pages are full of anally retentive editors when it comes to treating the wording of the MoS as gospel.
Well, after all, readers will likely be able to figure that out in sentence such as A foo's mass is 57 kilograms, whereas a bar's mass is 97 kg., but I was thinking about less obvious symbols such as lb for the pound. Which wording would you suggest? --Army1987 – Deeds, not words. 15:59, 2 January 2009 (UTC)
It still suffers from the undue, improper specificity in identifying units as "a U.S. customary unit in widespread everyday usage in the U.S." (emphasis added).
One of the biggest ambiguities is not in the size of a particular unit of mass, but at the higher level of what quantity (in the metrology sense not well explained there, perhaps better distinguished by the use of this term in the table at SI#Units) is being measured. That is especially evident in tons, which include numerous units of mass, numerous units of volume, numerous units of force, numerous units of energy, a few more of power, and whatever. And in the case of pounds, this is the real ambiguity we are most likely to encounter in Wikipedia articles. We have thousands of articles using both pounds as units of mass and pounds-force as well. We ought to be making clear that they are different by our visual disambiguations (different symbols, always identifying pounds-force as such, etc.), and we ought to be providing the appropriate links for any readers interested in delving further into what the actual distinctions between them are.
Considering all the points listed here, especially "need not be linked if each occurrence of it in the article is accompanied by a conversion to a U.S. customary unit in widespread everyday usage in the U.S., and vice versa" how would you copyedit an article using "65 pounds (290 newtons)" and later "85 pounds (380 newtons)"?
First appearance: ______________
Second appearance: ______________
Include both links, wording, use of symbols, the whole shebang.
First appearance: 65 pounds-force (lbf) (290 newtons), second appearance: 85 lbf (380 N) if it occurs in the same paragraph, and maybe even if it's in the same section, 85 pounds-force (380 newtons) if it is farther down below. (Yes, the ) ( looks silly, but I have no better idea.) Rationale: the pound-force and the newton aren't units my grandma is able to understand, even with a conversion, so link on the first occurrence; lbf is a counter-intuitive symbol. (I might do without the symbol in parentheses if that symbol is never used in the article.) --Army1987 – Deeds, not words. 15:59, 2 January 2009 (UTC)
I like what you have above, Army. But the list needs to be fleshed out. I would propose that it be kept very, very short. Attempts to broaden it on the assumption that “everyone knows this ‘n’ that” will undoubtedly prove problematic. I think Gene missed the point with his observation about how links are required because of distinction between pound (force) and pound (mass). If the article talks about The hero lifted a 100 kilogram (220 lb) rock over his head and…, no one is confused even though there exists on Earth the existence of Pound sterling and the pound-force; the context and the pairing make it sufficiently clear. To the extent that the guy can dig up more grey areas, is why we should use the caveats generally in the above div-box; if it is an article where obviousness of what is meant is lacking, then link it. (I just added a “generally” to address this.) Accordingly, here is a sandbox for us to work on and eventually add to your div box. What the below list means, as applied project-wide, is that if one has an article, for instance, on automobile speeds, one need not link km/hr and mph; the context is clear. If one is in a marine-related article and the units are nautical miles per hour v.s. km/hr, then we link. The point here is to sweep up all the common measures in their every-day, real-life units in every-day magnitudes. Greg L (talk)19:23, 2 January 2009 (UTC)
Speed or velocity: the common units kilometer per hour and miles per hour, but not feet per second nor kilometers per second
Temperature: the common units degree Celsius and degree Fahrenheit but not kelvin
Mass/weight: the common units kilogram, pound, gram, and ounce (provided the U.S. customary units are in the avoirdupois context)
Length: the common units meter/metre, foot, yard, centimetre/centimeter, inch, kilometer/kilometre, mile (statute)
Liquid volume: the common units milliliter/millilitre, litre/liter, fluid ounce, quart, and gallon (provided the U.S. customary units are in the 1/32/128 ounce per liquid gallon context), but not cubic meter/metre, cubic feet, cubic inches, etc.
BTW, I added and then stripped out Pressure: the common units kilopascal and pound per square inch because I realized that though men typically have no problem with it, women sometimes do. The downside of leaving off pressure? A one-time occurrence of one word that is blue instead of black—hardly much of a downside. I think we need to ensure the tenor of our crusade against over-linking doesn’t get out of hand and cause the pendulum to swing too far to the other side here. Greg L (talk)19:23, 2 January 2009 (UTC)
As to your last point about linking gallons, remember: my above list is specific that the measure is liquid volume; why screw around with more blue if the context is clear? If one is on an article where dry measurement is the topic, then link it. Note that in the real world in the U.S., the bushel is common; real-world usage of a dry gallon is vanishingly rare, if not extinct. I don’t see the need for the last bullet point. Perhaps it could be revised to explain the point that if one has an article that doesn’t fit squarely within the scope of the short list (British booze), then link. Greg L (talk)19:43, 2 January 2009 (UTC)
I've tried to address that, but, not being an American myself, I'm not sure whether this is the best way to do that. (Feel free to edit my wording to improve it.) --Army1987 – Deeds, not words. 20:35, 2 January 2009 (UTC)
Also, I'd add to the above list at the very least the millimetre, the centilitre, and the tonne/metric ton. Maybe also the hectogram (in very common use, at least in Italy where it's shortened to etto in common speech, and IIRC also in France, for goods such as ham, cheese, etc.), the milligram (the most common unit used for medicinals), and/or the hectolitre (commonly used for olive oil, wine, etc. on wholesale). Maybe someone from metric countries other than Italy can tell which of these units are in common use there, too? --Army1987 – Deeds, not words. 20:55, 2 January 2009 (UTC)
There is still an undesirable double negative: "... units of time ... such as second ... (but NOT millisecond ...) should NOT be linked ..." Perhaps better keep it general (no examples) there and defer all examples to the "list goes here" section. As to content, I think cubic metre is quite common (for water, gas and buildings). −Woodstone (talk) 21:03, 2 January 2009 (UTC)
I'm thinking that where this ends up, we will likely want to have a table of the inclusive cases of when a measurement unit is to be provided with conversion, and with linking, with all other units not linked implicitly implied to be both converted and linked. This avoids the double-negative language and provides explicitly clear guidance for the basic units. --MASEM21:43, 2 January 2009 (UTC)
We should also decide what to do with links to multiples and submultiples of SI units. Some of them redirect to the order of magnitude (e.g. microsecond), some redirect to the base unit (e.g. milliampere) or to the "multiples" section thereof (e.g. milligram), others are stubs (e.g. millimetre). --Army1987 – Deeds, not words. 01:19, 3 January 2009 (UTC)
My proxy issued to Greg L
Can't possibly wade through all this arcane back and forth. This is Greg L's home turf, I trust him implicitly to home in on a good solution. So Greg, you may use my "non-vote" as you see fit.--Goodmorningworld (talk) 20:24, 2 January 2009 (UTC)
Well, thanks. But I do think we’ve got a good thing going here: take input from everyone, throw out a proposal, more input, then someone else—like Army did here—takes the ball and runs with it. I like Army’s organization and writing style in his offering. When I get off my laptop here and get to my main authoring machine (bigger screen, full keyboard, multi-clipboard, macros), I’ll try to tweak what Army gave us—adhering closely to his framework. And I’ll try to not spend too much time at it. That’s one reason my first proposal hadn’t been highly polished for organization, grammar, and syntax: if I invest too much effort getting something just right, it’s harder to accept the criticisms and listen to input. I’ll wait a bit here for feedback on Army’s version; maybe it will gain a clear consensus with a day of input and tweaking. Greg L (talk)21:36, 2 January 2009 (UTC)
Under Pressure
Once more, I read it all. I very much like Army's proposal, but for me, it's still not enough. I still need more instruction. My main area of interest is scuba diving and (as Greg's son will tell him when he finishes his Navy Diver training), the topic is intimately connected with pressure. And there lies the rub. The source material uses a proliferation of units: bars, atmospheres (ATA), pounds-force per square inch (psi or sometimes psig), feet of sea water (fsw - since pressure depends exactly on depth), even millimetres of mercury ! (mmHg), since all of these have been in common usage in the last hundred years. Nobody uses the SI unit, kiloPascals (contrary to what Greg thought!).
I'm interested primarily in making articles understandable to the casual reader and useful to a diver who wants to use them as a reference. In a given article, I can usually settle on bar (linked on first use) with conversions to psi for US readers (or vice-versa for articles that started in psi). I really don't want to use kPa, since (a) most people don't know what it is and (b) nobody in the field uses it, so not even a diver can visualise it. However, when I cite a statement, I am often aware that anyone who reads the source will see pressure in units different from those used in the article.
So I might write in an introduction, "The pressure at 10 metres (33 feet) depth is 2 bar (30 psi)". The other way round would be "The pressure at 33 feet (10 metres) depth is 30 pounds per square inch (psi) (2 bar)", and then use the abbreviations throughout. I can accept the ") (" as ugly, but necessary. But I really need a guideline that I can refer to that produces the above as the natural way of doing it - particularly when I take the article to GA and have to defend not using kiloPascals to all the scientists who've never done a dive in their life. Even then, I still have the problem of the sources using ATA, fsw, etc.
About the only way that I can see to provide an understandable, fully-usable resource, is to create a new article, "Units of Pressure" and explain how each of the possible units relate to each other. Then link to it in the "See also" section of each article that needs it. Just my 2 [[Cent (United States coin)|cents]] (1.3 [[Penny (British decimal coin)|pence]]) --RexxS (talk) 15:58, 3 January 2009 (UTC)
There used to be a section somewhere in the MoS or in one of its subpages, stating that things should be measured in the units which are commonly used for those things. It gave the example of the Hubble constant which should be measured in kilometres per second per megaparsec, rather than in hertz. But I can't find either "hertz" or "megaparsec" on either WP:MOS or MOS:NUM, so, whatever became of that (very reasonable) recommendation? I suggest it should be restored. It should also apply, for example, on display sizes measured in inches, blood pressure measured in mmHg, diamonds measured in carats, and the like (including the case you suggest). --Army1987 – Deeds, not words. 16:32, 3 January 2009 (UTC)
The purpose of that section never was to make sure that those units are used; they will be. The only purpose of that section was to prohibit conversions to other units such as the modern International System of Units, and in several cases it has been used to prohibit conversions to other units which are also used. Gene Nygaard (talk) 17:40, 3 January 2009 (UTC)
And kilopascals (note the proper capitalization) are used in this context, despite the unsubstantiated claims of RexxS. I've been involved in other arguments along those lines; in one case, after lengthy discussion the editor who had been trying to preclude the conversion I was adding to a featured article was forced to admit that not only are those units used, but they are in fact recommended by the professional organization involved. Gene Nygaard (talk) 17:50, 3 January 2009 (UTC)
Encyclopedias are by definition where non-specialists and specialists interact. Specialists are, understandably, authors/readers whereas the ordinary person is merely a reader. There is nothing wrong with saying that specialist terms have a substantial role. But it would be a logical error to say that the presence of specialist terms requires a ban on universal terms just because specialists aren't accustomed to seeing them in a nerds monthly magazine. Lightmouse (talk) 17:04, 3 January 2009 (UTC)
Along those lines, many people fail to consider that the interdisciplinary nature of the SI is as important as its international nature. People who are technically literate in any field will understand the SI units if we present conversions to them, but they might not understand the arcane, not-in-general-use units peculiar to the jargon of some specialized field of activity. Gene Nygaard (talk) 18:31, 3 January 2009 (UTC)
Can't talk for everybody, but as for me, if I am looking up how far a certain star is, I would expect (and prefer) to find that information in light years, rather than in metres. --Army1987 – Deeds, not words. 18:47, 3 January 2009 (UTC)
Sure, but if you believe the astronomers, they never use light years (unless they are converting measurements for the rabble, of course). So according to the beliefs of some of the denizens here, we should never use them either.
Of course, even if some astronomers still think that ergs per second are the cat's meow when it comes to the measurement of the power of a star, most people are more likely to understand watts. And when such measurements are expressed in meters here, it is of course generally done with the appropriate prefix (and for lengths, the existing SI prefixes allow the breadth of the universe to be expressed with no more than three digits to the left of the decimal point). Gene Nygaard (talk) 19:06, 3 January 2009 (UTC)
That was just an example, sorry if I picked the wrong one, but there are many others. Masses of subatomic particles are usually measured in GeV/c2, and those of molecules in atomic mass units, not in yoctograms. (And the parsec isn't a SI unit, either.) --Army1987 – Deeds, not words. 20:37, 3 January 2009 (UTC)
The electronvolt and the unified atomic mass unit are "acceptable for use with the SI". But neither light-years nor parsecs nor ergs per second are. Gene Nygaard (talk) 15:07, 4 January 2009 (UTC)
Comment. I'm rather surprised that someone can claim "I still need more instruction" [emphasis as in the original]. Not even I myself am very convinced of the large amount of feature creep in my proposal (which I tried to keep to a minimum), but the common opinion is that leaving any hole in the MoS is going to generate edit wars on any part of any article which happens to fall in that hole, which would be a worse evil. But really does nobody believe that the current bloat of the MoS (66 kilobytes only in the MOS:NUM subpage) isn't enough? --Army1987 – Deeds, not words. 18:41, 3 January 2009 (UTC)
According to the Weather Network, here near my home in the Front Ranges of the Canadian Rockies. the atmospheric pressure is 102.81 kPa, the temperature is -21°C, and the winds are from the SW at 11 km/h. According to my home weather station, the pressure is 101.8 kPa, the temperature is -18.3°C, and the winds are from the SW at 4 km/h. Of course people use kPa for pressure, it's an SI standard unit for pressure. It's just that a lot of people are rather antediluvian when it comes to units of measure. Atmospheric pressure at sea level is 101.325 kPa. Memorize that number, it's important.RockyMtnGuy (talk) 20:03, 3 January 2009 (UTC)
(The built-in manometer in my watch addresses the problem of bars vs pascals in the most clever way: it gives a number labeling it both as hectopascals and millibars. --Army1987 – Deeds, not words. 01:55, 4 January 2009 (UTC))
But pay attention to what RockyMtnGuy is saying. Neither his weather reports nor his home weather station uses "hectopascals", a pseudo-SI use of an unfamiliar prefix, which the CGPM should have had enough sense to consign to the same fate as the prefix "myria-", just to be able to hang onto an obsolete unit by cloaking it in a new name. They use "kilopascals"—which is what he was syaing. Your watch doesn't address the choice-of-prefixes issue very well. Gene Nygaard (talk) 14:52, 4 January 2009 (UTC)
To all One thing you can count on is that anything I propose won’t be touching upon ‘messy’ measures like pressure.
RexxS: You obviously read my post and then elected to ignore my point, which was to steer clear of the fallacy that certain, messy measures like pressure and its associated units are *universally understood*. Bear in mind that the whole purpose of this proposal is to address when and when not to link. I have no interest in getting into another MOSNUM “Unit Jihad” here over bar and atmospheres and kPa. Besides, a little voice whispering in my ear tells me that you don’t really “still need more instruction”; I think you kinda sorta have an idea of how things should be in your edits. If I’m wrong with that assumption, then I suggest you do more reading here and less preaching.
The point of exempting some combinations of units for some measures in some contexts is that verbiage with a first-occurrence instance such as Samson lifted a 100 kilogram (kg) (220 lb) rock above…, does not need linking because the nature of the measure and its magnitude is understood by all English-speaking cultures due to the accompanying conversion and the fact that these are familiar measures where at least one of the units is exceedingly familiar to the reader. The same goes for an expression like The Navy Diver is 5 foot–10 5⁄8 inches (1.79 m) tall; the nature of the measure and its magnitude is clear from context and the fact that at least one of the units is familiar. If someone wants to raise exceptions such as the ‘quart’ the African tribe in central Congo that speaks in tongue clicks uses when making toad poison for their darts, then one is clearly not referring to “U.S. customary units are in the 1/32/128 ounce per liquid gallon context” and the unit certainly does need to be linked (or entirely explained within the article you are writing). The same goes for the U.S. dry gallon that the farmers’ wives sell their special, blue ribbon-winning blend of grains at the county fair. Since that isn’t the exempted context, link it.
What I propose will steer clear of all this controversial stuff, not dive headfirst into the middle of it; you can count on that. If you want to discuss units of pressure, keep in mind that it is a separate topic from the matter at hand precisely because it results in controversy. Greg L (talk)20:12, 3 January 2009 (UTC)
P.S. As for SCUBA diving, RexxS, and how my son will be telling me things about that fascinating world, I too am a certified SCUBA diver. Moreover, one of my first patents (maybe the first) was for a new computer algorithm to calculate the pressure/temperature/density relationship of highly non-ideal gases. I’ve likely forgotten more about pressure than you will ever learn in your life. Greg L (talk)21:08, 3 January 2009 (UTC)
I'm sincerely sorry, Greg, that I came across as condescending. That was never my intention. If it helps to give some perspective, my degrees (dating back to 1972) are in Natural Sciences (Physics) and Electrical Engineering, and I've been a scuba diving instructor at national level for almost 20 years now. So I don't suppose a pissing contest with you youngsters about who has forgotten most about pressure would be productive <grin>. I did realise after I'd posted that I'd made the assumption that scuba wasn't your field (the comment about kilopascals), but I'm happy to take that back. The point remains (however badly I expressed it) that no diver in the world uses a submersible pressure gauge marked in kilopascals and no diver calculates pressure in those units. For Gene, take a look at the 106 references in Oxygen toxicity. Not one mentions kilopascals anywhere and yet I had to use xx bar (yy kPa) throughout. Greg's right - I do know how I want to show pressure units. I really would prefer to express pressure in psi (for the US readers) and bar (for most others), but not in kPa - and certainly not all three! There is no problem with depth: feet and metres are the familiar units in the field. It's just that one of them happens be an SI unit. Surely I'm not alone in this? There must be other fields where there are two common units (US/non-US) and neither is SI? --RexxS (talk) 23:32, 3 January 2009 (UTC)
Unfortunately, I’m no youngster. And, unfortunately, you weighed in on a subject here that is well beyond the scope of what we’re trying to deal with. The very nature of your post self-referentially made it quite clear that pressure can not to be one of the measures that is exempted from being linked. Further, I appreciate it when editors are as up front as possible with what they mean; your “I still need more instruction” didn’t meet my (nor some others here) *grin tests* given the rest of your post, but then it could simply be that what we’ve got here is "failure to communicate". Water under the bridge now. Can we move on? Greg L (talk)23:49, 3 January 2009 (UTC)
The failure to communicate is my fault entirely and I hope you'll accept my sincere regrets that I don't express myself as well as I would wish. When you get to my age, you'll take being called a "youngster" as a compliment. If you want to move on and just discuss linking, then surely the issue of what is most useful for the reader is paramount. I'm no fan of overlinking and can see that linking only for the first occurrence of an uncommon unit is useful, and of course spell it out in full at that first occurrence. It then merely an issue of the editor deciding what is uncommon. Personally I'd just use a rule of thumb, that if I had to explain the unit when I was teaching the subject, it should be linked on first occurrence. Nevertheless I'd be quite happy to go along with any consensus on a list of either "common" or "uncommon" units. Hope that helps --RexxS (talk) 00:25, 4 January 2009 (UTC)
I like it very much, Greg. I admit I had to look up U.S. customary unit, but having worked through several examples in my mind, it always seems to produce the outcome I would pick as most useful. Kudos to you (and to Army as well, I think). I know it's not in keeping with MoS, but I'd love to see more examples spelled out. I doubt many others would agree with me though. One small point: I assume that the first occurrence of MeV would be linked (as an abbreviation for the reasons given); Am I right to think that it would have to be piped to either MeV#As a unit of energy or MeV#As a unit of mass depending on context? Count me in as Support. Cheers --RexxS (talk) 02:56, 4 January 2009 (UTC)
As for MeV, most articles using it as a unit of mass either explicitly call it MeV/c2, or say a mass corresponding to a rest energy of 0.511 MeV, or Example text, etc., but piping to MeV#As a unit of mass is useful anyway, especially in the first and third case above. As for MeV#As a unit of energy, there's little point, as the first sentence of that article is In physics, the electron volt (eV) is a unit of energy.. --Army1987 – Deeds, not words. 16:29, 4 January 2009 (UTC)
Proposal 11
The premisses underlying this proposal are fourfold:
Units of measure should at first be spelled out and unit symbols formally introduced before being employed. Too many of our articles will state something like The Banana Jr. 9000 computer came with 512 MB of RAM without once writing out what “MB” stands for. It helps to use the full unit name since unit symbols like “lx” and “MB” are ‘pronounced’ in our minds as we read them (“lux” and “megabytes”, respectively here). Requiring readers to click on a link to learn such an elemental point is a frustrating waste of time. Although the exclusive use of unit symbols might be a perfectly acceptable practice for specialty magazines like PC World, such a practice is inappropriate in a general-interest encyclopedia. Knowledge of the symbols representing specialty terminology should not be assumed.
Units should generally be linked. Although it might seem obvious that “all readers know what 2 m and 35 kg means,” (or for that matter, seem like “all readers know what 2 metres and 35 kilogrammes means”), this is not the case. Americans—particularly older Americans—are unfamiliar with the SI and will often not only not understand what the magnitude of the measure is, they will often not even understand the nature of the measure! This is aggravated by the fact that “metre” and “kilogramme” are not the official spellings in the U.S. Further, the term “tonne” is not is not at all recognized in the U.S., where the unit is known as the “metric ton.”
To avoid overlinking, there is no point to linking units that all English-speaking cultures routinely use in daily, non-specialized life, such as “hour” or “minute.” Further, although many Americans might not understand what a kilogram is (or conversely, an Italian primary school child might not know what a “pound” is), the nature and magnitude of certain measures are obvious when the primary unit of measure is accompanied by a conversion; the expression individual sacks of concrete premix in America can be be as great as 80 pounds (36 kg) is always understood because at least one of the units is perfectly familiar and the context is clear.
Our guidelines should do a better job of explaining the rationale underlying them. Some of the examples and verbiage in the following proposal might seem like it is unnecessarily hammering one or more points home. Remember that manuals of style at newspapers and news agencies, like the Associated Press’ manual of style, are written for professional writers and editors, most of whom have journalism degrees. Wikipedia is contributed to by diverse peoples from all over the world, some of whom will be trying their hand at technical writing for their very first time. The logic underlying many of our guidelines that might seem blindingly obvious to some experienced editors (or some of the regulars here on WT:MOSNUM) is not necessarily understood by everyone who comes to MOSNUM (or are referred to MOSNUM) for guidance. Further, it is helpful if the rationale underlying guidelines is clear so that editors can better resolve disputes on the respective article talk pages rather than come here for assistance in resolving conflict.
Linking units of measure and unit symbols
On the first occurrence of a unit of measure in the prose of an article, editors should generally spell out the full name of a unit of measure and, except as exempted below, should link to its respective article; e.g. The NEMA 5-15R duplex receptacle can be wired to deliver a continuous current of 15 amperes via each of its two sockets. Subsequent occurrences can use either the name or the symbol.[1]
If the symbols for units of measures (unit symbols) are later used in an article, it is often useful to parenthetically append the unit symbol after the first occurrence of the full unit name, especially for units with counterintuitive symbols (e.g. lb for the pound) and units which may be unfamiliar to a general audience (e.g. MeV for the megaelectron-volt):
The minimum current a human can feel is thought to be about 1 milliampere (mA), but currents up to 5 mA are typically harmless.
Editors should generally use unit symbols in parenthetical conversions (not the full unit name) and, except as exempted below, the unit symbols in conversions should generally be linked. Write The .450 ACP with factory ball ammunition develops a muzzle velocity of 830 feet per second (ft/s) (250 m/s) before later writing but the lightest bullets can generate velocities as great as 1,060 ft/s (320 m/s).
Exemptions
To avoid overlinking, the first occurrence of very common units should generally not be linked unless they are particularly relevant to the topic of the article. Such units are as follows:
Time There is no need to link common units of time that are extremely familiar to all English-speaking peoples. Editors should not generally link second, minute, hour, day, week, month, and year; but should generally link the first occurrence of units such as millisecond and microsecond.
Plane angle As with common units of time, there is no need to link angles in degrees; e.g. a 90‑degree turn and shot at a 45° trajectory. This advise does not apply to less familiar units for plane angle, such as radians and percent.
Familiar measures with accompanying conversions There is no need to link when a parenthetical conversion accompanies the primary unit of measure, provided the following three conditions have been met: 1) one of the units is part of the SI or is accepted for use with the SI and it is in widespread everyday usage among the general population outside of the United States, and 2) is accompanied by a U.S. customary unit that is in widespread everyday usage in the U.S., and 3) the units are the ones typically used in that context.
These examples: Samson lifted a 100 kilogram (kg) (220 lb) rock above his adversary’s head — U.S. Air Force pilots may be no taller than 6 foot–7 inches (2.00 m) — Sacks of concrete premix in America can be be as great as 80 pounds (36 kg) — By January 2009, retail gasoline prices in the U.S. soon had fallen to $1.499 per gallon (€0.291/L), and Gumpleskirken is a village located 19 kilometres (12 mi) south of Vienna do not need linking because the nature of the measure and its magnitude is clear from the context and at least one of the units is exceedingly familiar to any reader.
Units that are in everyday usage and are exempt from linking when paired with a conversion include the following:
Length: millimeter (or -metre), centimeter, meter, kilometer; inch, foot (international), yard (international), and mile (statute/international); not micrometers, fathoms, etc.
Mass/weight: gram (or gramme), kilogram, metric ton (or “tonne”), ton (short), ounce (avoirdupois), pound (avoirdupois); not grains, carats, etc.
Speed or velocity: kilometer per hour; mile per hour; not feet per second nor kilometers per second, etc.
Volume: milliliter (or -litre), centiliter, liter; ounce (U.S. fluid), quart (U.S. fluid), gallon (U.S. fluid); not cubic meter, cubic feet, cubic inch, U.S. dry measures, etc.
Temperature: degree Celsius; degree Fahrenheit; not kelvin, Rankine, etc.
[1] Usually, the symbol is preferable in formulas, pictures, tables and infoboxes, whereas the name is preferable in prose, unless it is very long or the same unit is used several times in the same sentence.
Support This is a product of Army1987’s efforts and mine so I am no-doubt partial to it. But it seems sensible to me. Further, it is subject to more revisions per discussions, below. 03:22, 4 January 2009 (UTC)
Oppose. Again 738 words to avoid a few blue links. And what's with the abbreviations/units symbols in the parenthesis right next to the spelled out words? Our readers can figure out if 5 feet (1.5 m) was used in one sentence and 10 ft (3.0 m) was used a few sentences later that the "ft" is referring to feet. Really, they can. —MJCdetroit(yak)04:15, 4 January 2009 (UTC)
But not all of them will be able to figure out if we wrote 190 pounds (86 kg) in one sentence and 220 lb (100 kg) five sentences later, or if we wrote 2.3 million electron volts in a section and 0.511 MeV three screenfuls later. --Army1987 – Deeds, not words. 11:55, 4 January 2009 (UTC)
No kidding. The test isn’t to see how much “readers can figure out” when important information is omitted. Our job is to write clearly so there is minimum confusion. It is only common sense to parenthetically explain that (lb) is the symbol for “pound”. How the hell are some readers supposed to divine that L and B are symbols for “pound”(?); neither letter can be found in “pound.” Greg L (talk)07:23, 5 January 2009 (UTC)
Oppose. Still far too much instruction creep, still self-contradictory, still in need of copyediting for parallel construction. Still suffering from improper overspecificity with regard to "U.S. customary units". Now unnecessarily getting into rule by example spelling choices as well. There is no reason to require a parenthetical (kg) before using it; whether or not we should permit it is an open question. But most of all, just too much, period. Gene Nygaard (talk) 15:41, 4 January 2009 (UTC)
I've searched for "always", "never", "shall" and "must", finding no occurrence of any of these words in the gold-bordered div. [I think it should be forbidden to use these words in guidelines.] There also are enough many occurrences of "generally", "usually", etc. in it. What else should be done for it to be "phrased as a suggestion"? --Army1987 – Deeds, not words. 14:25, 6 January 2009 (UTC)
You don't need "always" or "never" for a bot-runner hell-bent on removing any blue from his pages from taking the ball and running with it. You need the explicit indications that it is something that requires the judgment of a live editor.
But let me address some other points necessary for it to be a serious suggestion. These will probably be entirely different from what PMAnderson had in mind:
What does this replace? Or is it just piled on top of everything else?
That is totally absurd, Gene. According to your stated logic, we can’t make progress on anything until you get satisfaction on everything and simultaneously harmonize four venues! That is completely unfeasible (which is precisely why you suggested it). Nothing would get accomplished if everyone here had that sort of attitude. As you have amply demonstrated above, it’s hard enough to get anything accomplished at just one venue. The operative words here are “cooperation” and “compromise.” And pardon me all over the place for believing that your supposed objections, above, are nothing but red herrings intended to impeded progress. The only options you like are *your way* or *no prescribed way* (which are one in the same for you). Face it, you like to edit a particular way, that way is contrary to what most editors belive is wise, and the most frustrating thing—from your point of view—is those damned bots enforcing common-sense guidelines. Wikipedia has 48,464,182 registered users (including one Gene Nygaard). Thank heavens for bots: they’re the only thing that keeps Wikipedia from being mucked to the point our articles cause unnecessary confusion and look like hammered dog shit. Greg L (talk)20:47, 6 January 2009 (UTC)
Support Doesn't feel unnecessarily creepy to me at all — in fact, I think it has just the right amount of creep. Sure, not all editors are going to follow what's proscribed/suggested here. Heck, most of them probably won't. But we need a set style, regardless, if only in the faint hope that it will avert wars that might otherwise develop amongst the people who really care about it. Even if all we'd achieved out of this was consistency amongst the various pages, it would have been a win. Personally, I think we've done a damn sight better than that. Mlaffs (talk) 04:11, 6 January 2009 (UTC)
OpposeFirst, all credit for the fact that this is a heroic attempt at compromize. My objection, however, is not to the specific wording but simply that this is too trivial to justify a specific instruction. I would feel differently if the proposers of this instruction were proposing to cut some other rule. That would demonstrate that they think this advice/instruction/rule is so important that Wikipedia cannot pass over the matter in silence.Dejvid (talk) 11:51, 8 January 2009 (UTC)
Discussion of this proposal
I like it so far. But it no-doubt needs some “double negatives” tweaked and other such stuff. How say we discuss and tweak and address some initial concerns before we vote? Greg L (talk)00:48, 4 January 2009 (UTC)
What is "the context clearly matches the units as they are commonly understood in that context" supposed to mean?
Spelling out kilometre per hour several times in the same sentence is cumbersome even if you don't say "kay-em over aitch" (but that does say Usually making clear that it's not an absolute law). --Army1987 – Deeds, not words. 02:31, 4 January 2009 (UTC)
The statute mile is not simple. An important source indicates on page 43 that within the USA the statute mile is identical to the rarely used U.S. survey mile, and nowhere else mentions the statute mile. We could say "international mile" but unfortunately the exact meaning of that term is not widely understood. --Gerry Ashton (talk) 02:49, 4 January 2009 (UTC)
No, Gerry. The difference between the statute/international mile and the survey mile is at the ppm level and the distinction is only of interest amongst professional surveyors. If the article is talking about survey-related issues, like a survey foot, then clarify and link. But as exempted here, it is simply statute miles (equal to the international mile since 1959 at precisely 5,280 feet, and precisely 0.3048 meter per foot), which is what is used in the real world in the US. Our own Mile article has it correct. There is no need to make it any more complex; 19 km (12 mi) confuses no one since no one measures the distance between cities at a precision of 2 ppm; only survey benchmarks are measured with this precision. I’m certain one would draw blank stares from the auto manufacturers if someone asked them whether they calibrate their odometers to statute/international miles or the survey mile. This is all addressed with the common-sense principle unless they are particularly relevant to the topic of the article as well as with the units are the ones typically used in that context. Greg L (talk)03:16, 4 January 2009 (UTC)
Get over it, Gerry. A "statute mile" is any mile of 5,280 feet. The modern definition based on the 1959 international definition of the yard makes it 1.609344 km; that is one "international statute mile" is one subset of the general term "statute mile". The one retained for use in U.S. surveying, which was the general definition of a statute mile in the United States from 1893 to 1958, is 1/0.999998 times that. The two-parts-per-million difference in particular time-sensitive or location-sensitive particular definitions of a statute mile will never matter if we are linking 36 [[statute mile|miles]] (58 [[kilometer]]s)". Gene Nygaard (talk) 19:59, 4 January 2009 (UTC)
I've tried to reduce the number of words by removing truisms and repetitions (and added a few more everyday units). Hope you don't mind. --Army1987 – Deeds, not words. 11:55, 4 January 2009 (UTC)
It is common to have children as they are growing stand against the edge of a door or a spot on the wall behind a door and memorialize their height as they grow. Foot-long rulers are almost always graduated to a sixteenth of an inch. But we don’t use rulers for measuring height. Height measurements are most commonly done with yardsticks, which are graduated either to an eighth of an inch or a quarter inch. If you were a child and just broke a 3–1⁄4 mark and were half way to 3–1⁄2, don’t you think you’d pipe up that you are 3–3⁄8ths? Sure you would.
This made me think about how the tools we use can influence the precision of loosey-goosey measurements like height. I would expect that in the metric world, one centimeter is as fine as anyone is going to go; dropping down to millimeters would be absurd—you can’t even get repeatability at that level. Having a measuring tool marked at 25 mm increments would be far too coarse for height. Having one divided at 6 or 3 mm increments enables fine precision that exceeds what metric-using cultures can practically use. Surprising, isn’t it? Many Americans might make higher precision measurements because of their archaic system? But then, the same thing happens with digital household thermostats: unless someone owns a thermostat with 0.5 °C resolution, Americans are routinely making decisions on comfort points that are 5⁄9ths the size of metric ones (*sound of audience gasp and woman in the background fainting*)
Nevertheless, I reduced the precision of the example measurement so it doesn’t attract attention to itself. Besides, the conversion lands closer to 1.79 meters. Greg L (talk)19:42, 4 January 2009 (UTC)
Dunno "if I were a child", but nowadays if I needed to mention my height in inches I'd just say 6 ft 2 in, given that lying down/walking for a few hours can temporarily stretch/shrink people by more than 1 cm. In metric units I always have the dilemma between 1.87 m and 1.88 m – rounding to 1.9 m would be way too coarse (and nobody does that, unless giving an eyeball estimate of someone else's height), so I end up choosing the last digit at random. I won't bother to take care to measure myself accurately enough to know whether I'm closer to 1.87 m or 1.88 m, indeed because of the temporary variations I've mentioned. And many thermostats here have 0.1 °C resolution (but I guess not 0.1 °C accuracy.) --Army1987 – Deeds, not words. 21:07, 4 January 2009 (UTC)
That surprises me about 0.1 °C resolution; I would think those would be rather rare? When first formulating a height example several days ago in an earlier thread, I actually had the opposite reaction you metric dudes did: “Wow, these centimeters are one coarse unit: 39% of an entire inch!” I was struck by the range of US customary values that could bin into 1.79 meters. While writing that example, I even pondered for a moment whether it might be a common practice to drop down to the millimeter level. But I didn’t even Google it though, as I realized that millimeters would be absurd. Besides, my vague recollection was to have seen human height only at centimeter-level resolution and never at millimeter precision. This was just one of those areas where powers of 2—even whn in a fractional sense—works better than powers of 10. To my eye, measuring human height at a resolution of 39% of an inch is too coarse and 4% of an inch is too fine.
Lest an SI-Nazi ;·) here jump all over me for being anti-SI, I ain’t. Quite the opposite. I’m simply seeing nothing to dissuade me from my initial impression that MOSNUM has a damn heavy representation of non-Americans who are largely unfamiliar with American practices, and where some of these non-Americans are quite content to leave our American readership in the dust because they made the “poor choice” of electing to be born in a country that uses a barbaric measuring system that ought to be deprecated from the face of this pale blue dot. Greg L (talk)21:23, 4 January 2009 (UTC)
Most digital thermostats I've seen in Italy (and many thermometers, too) have one digit after the point. (Analog ones usually just have a few ticks along with the knob, IIRC I once have seen one with just one tick each 5 °C.) As for people heights, I've seen some of them with four significant figures, but 70% of people would laugh of that, including me. (For various reasons, I've got a peculiar adversion for false precision, and I'm always very suspicious of measurements with more than three sig figs and no errors given. [4]) --Army1987 – Deeds, not words. 00:17, 5 January 2009 (UTC)
Human height: For many purposes 10 mm or 25 mm precision is enough. But a lot of modern anthropometry data about human height uses 5 mm or 1 mm precision. Such precision is important when calculating percentiles and is important to data users.
0.1 °C thermometers': Many thermometers are made for world markets and have basic components that are Fahrenheit-capable. This means that the 1 °C is not enough, it has to be at least 1 °F precision. I suspect that the designers of the Celsius version just add an extra digit 'because they can'. Lightmouse (talk) 12:41, 5 January 2009 (UTC)
You’d almost never see Americans recording their height at 1-inch increments for anything remotely important. Far too coarse. Perhaps when they recall their heights at the drivers licensing bureau when getting their license and other non-critical stuff. The ‘peak of the bell curve’—as far as typical US medical and BMI-calculating purposes go—probably lies at the divisions seen on the integral height gauge on Health-o-Meter doctors’ scales, which is 1⁄4-inch (6 mm). Greg L (talk)01:26, 6 January 2009 (UTC)
Wow. You weigh in on a completely irrelevant, tangential issue and all you accomplished was to demonstrate that you have a profound tendency to spout nonsense on issues you know absolutely nothing about. The height gauges on American doctors’ scales (my wife owns a Health-o-Meter similar to this one she got from a health club that went digital) are marked in increments of a quarter inch, yard sticks are marked at least in quarter inch increments, and here are instructions for measuring the BMI of California school children and it calls for recording to the nearest 1⁄8 inch. Yet you make an absurd statement like You’d almost never see Americans recording their height at more than ½-inch increments for any purpose. “Any purpose,” huh? You could have stuck to issues like “instruction creep” or “it’s over-prescriptive” or something pertaining directly to the issue at hand. It might have made it appear (kinda sorta) that you have a legitimate view. Instead you demonstrate that you have foot-in-mouth disease.
Just because you are highly impassioned about the virtues of the SI, you really should begin to realize how it is futile to oppose Wikipedia’s accommodating our American readership (and doing so without unnecessarily linking the crap out of stuff that is obvious). Greg L (talk)18:26, 6 January 2009 (UTC)
It is certainly not "a completely irrelevant, tangential issue" when you propose adding a totally improper rule by example to the style manual. Especially when you refuse to simply admit that it was a bad idea conceived in haste, and move on from there.
Consider basketball—a sport in which the height of the players is one of their defining characteristics. It is often the first thing people want to know about a player. But look, for example, at the [roster of the Chicago Bulls]; not a single player listed to even half-inch precision, let alone the quarter-inch you wrongly claim to be common (which is more precise than typical variations in any individual in the course of a single day), let alone the eight-inch you proposed for our rules. The Bulls are listed in whole-inch increments, despite your (GregL) claim above that this is "Far too coarse."
Re Lightmouse's comment "Many thermometers are made for world markets and have basic components that are Fahrenheit-capable. This means that the 1 °C is not enough, it has to be at least 1 °F precision." I'd suggest that Lightmouse actually take a look at the zillions of digital thermometers out there. All of them I have seen use for home use in measuring inside or outside air temperature have 0.1 °C precision, not 0.1 °F (and as pointed out above, not 0.1 °C accuracy, either). Sure, you can set them to display temperatures in tenths of a degree Fahrenheit. But they don't do so in tenth of a degree Fahrenheit precision—the degrees Fahrenheit jump up or down in 0.2 °F increments most of the time, and 0.1 °F occasionally. They might read "5.0 °F" or "5.2 °F", but they will never read "5.1 °F", for example. Gene Nygaard (talk) 15:18, 7 January 2009 (UTC)
(outdent) Gene. You are being silly and stubborn and illogical. The issue isn’t whether some Americans are recording (more precisely: “declaring”) heights at one-inch increments; it is whether—as you stated: You’d almost never see Americans recording their height at more than ½-inch increments for *any* purpose. I’ve already shown and linked the fact that the recommended practice for California school children is to record in 1⁄8 increments. So in answer to Army’s question, above (Do you really measure people to within an eight of an inch, in America?): yes.
Further, with regard to your idiotic ‘half-inch is the limit in America’ assertion, I just called my local HMO (Rockwood Clinic in Spokane WA—you can call them yourself if you like) and their standard practice is to record to the nearest quarter inch (6.35 mm). I have no doubt whatsoever that this is the standard practice observed by the vast majority of American medical practitioners—perhaps all of them. This is entirely in keeping with my above post, which was The ‘peak of the bell curve’—as far as typical US medical and BMI-calculating purposes go—probably lies at the divisions seen on the integral height gauge on Health-o-Meter doctors’ scales, which is 1⁄4-inch (6 mm). Accordingly, Gene, your assertion is demonstrably and clearly false.
Once again, your rabid promotion of the SI to the detriment of our (significant) US readership underlies why your arguments here often either evade the central issues or rely upon false declarations such as making statements of fact regarding American practices about which you don’t know your ass from a hole in the ground. Seriously, you come across as too-weird-to-handle because you can’t accept that American doctors and their barbaric measurement system is such that they record heights at a precision that is 57% finer than is typically done with metric. (*sound of audience gasp*)
You should stop digging the hole deeper for yourself (but I really hope you do). A nurse from another HMO is supposed to be returning my call. If you would like to engage in yet another demonstration of “Gene hoof-in-mouth” for our viewing pleasure here, there is ample room below for such, and then I will be pleased to show that yet another American medical facility has a standard practice to record heights at a resolution finer than at which Europeans typically do. Now, please weigh in with more Geneisms; it will be very amusing for us regulars here on WT:MOSNUMGreg L (talk)20:38, 7 January 2009 (UTC)
I didn't say 0.1 °F. I said "1 °C is not enough, it has to be at least 1 °F". Your example of "0.2 °F" is consistent with that. I have seen two mode thermometers where the °C mode has one decimal digit and the °F mode has no decimals (some cars do this). Lightmouse (talk) 15:33, 7 January 2009 (UTC)
Sorry about that; some of the discussion was about 0.1 °C precision, and I failed to note that your point was about whole number precision. Whole degrees Celsius are good enough for many purposes, as are nearest 5 or nearest 10 degrees, whether Celsius for Fahrenheit. Gene Nygaard (talk) 16:08, 7 January 2009 (UTC)
I actually meant that I was surprised, not that I didn't believe that: I thought Greg knew how people were measured in the US, and I didn't think he had any reason to lie about that. BTW, what are the other problems? --Army1987 – Deeds, not words. 14:14, 4 January 2009 (UTC)
I think point 3) above ("the units are the ones typically used in that context") should always apply, not only when we don't link units (and hence removed as obvious). We don't want to state "It's OK to measure screen diagonals in attoparsecs or bulk moduli in british thermal units per imperial quart, so long as we link those units." --Army1987 – Deeds, not words. 16:18, 4 January 2009 (UTC)
The point is to help editors when their minds slosh with “but, but, here’s an exception to the rule as to why you can’t do that”—something like “the King of Siam used a 4,980-foot-long mile in 1885 so ‘mile’ is ambiguous” (when some poor bastard tries to use common sense). It would be nice if editors don’t continually come here asking us to settle some dispute over such-‘n’-such on some backwater article somewhere. Uber-common sense stuff isn’t required in the A.P. manual of style; this isn’t the A.P. and not all Wikipedian’s have journalism degrees. Anything that drives home an important concept (and does so in only a few words) can only do good. Greg L (talk)19:59, 4 January 2009 (UTC)
Shortened segment
The exemptions are using too many words. We might shorten without loss of meaning to:
Exemptions
To avoid overlinking, the first occurrence of very common units should generally not be linked:
There is no need to link units that are familiar to all English-speaking peoples, like:
Time: second, minute, hour, day, week, month, and year (but link millisecond and microsecond)
Angle: degree (but link radians)
There is no need to link US customary or SI units that are familiar to either US or International readers when they are accompanied by a conversion:
The idea is correct, but the tonne, the litre, the hour aren't SI units, they are "units accepted for use with the SI". And we need to emphasize the "each-other-ness" of the conversion requirement, to avoid giving the idea that no link is needed in 0.5 kilograms (500 g). (And who the hell is an "International reader"?) And "very common" and "familiar" is not enough (the atomic mass unit is very common in chemistry and is familiar to whoever studied some chemistry in high school or junior high school, but we don't want to suggest avoiding linking it) – "in widespread everyday use" would be better. So it'd be:
Exemptions
To avoid overlinking, the first occurrence of very common units should generally not be linked:
There is no need to link units that are in widespread everyday use among the general English-speaking population, like:
Time: second, minute, hour, day, week, month, and year (but link millisecond and microsecond)
Angle: degree (but link radians)
There is no need to link a SI unit (or a unit accepted for use with the SI) which in widespread everyday use among the general population of metric countries if it is accompanied by a conversion to a customary unit in widespread everyday use in the U.S., and viceversa. Such units include:
It is bass-ackwards, too. The obscure, ambiguous units such as "ounces" and "gallons" and "quarts" are almost always more in need of linking that cubes of units of length are. Gene Nygaard (talk) 20:02, 4 January 2009 (UTC)
MJC. I find that the term “instruction creep” is a pseudonym for “I don’t do it that way and oppose a guideline that would embolden editors to revise the way I’ve done things.” Perhaps the more up-front approach would be to explain precisely what it is about your practices that is such a good idea and how the above proposed guideline would interfere with that practice.
I've trimmed down the footnote (and added "the prose of" for cases such as Electron where the article begins with an infobox containing many measurements). --Army1987 – Deeds, not words. 00:26, 5 January 2009 (UTC)
The usefulness of linking millisecond and the such will be strongly dependent on what becomes of that title. On the discussion I've started to sort out the messy inconsistence of such stubs/redirects, consensus is emerging that such a title should redirect to second, in which case a link to micrometre won't be very helpful unless the reader bothers to scroll the article to the "multiples section". [I was starting the example as a link to millisecond won't be very helpful to your wife unless, but I decided to check and second happens to mention submultiples in the lead.] I have resolved this problem with 938 million electron volts (MeV) a few times, but this only works with M and k which are also commonly used to informally abbreviate "million" and "thousand", and would be quite awkward with any other prefix. Anyone has any idea on how to handle this problem? --Army1987 – Deeds, not words. 21:07, 4 January 2009 (UTC)
Regarding your separate proposal about existence and naming of articles: Any such change should be done to make those links more useful, not less useful. Gene Nygaard (talk) 10:03, 5 January 2009 (UTC)
Greg, the way that I edit doesn't normally include the linking of common units. If a proposal make sense, I'll support it. You know that I supported you in the "follow the lit" days and Gene knows that I rarely agree with him; hell or even pay attention to him, but this does seem to be an area of agreement because this is overkill. What are we trying to do? We are just trying to avoid a few blue links. It seems like we'd be supplying arming instructions for an MX missile to kill a rat in the trash. Link first occurrence or say nothing at all and leave it to the editors and their common sense. —MJCdetroit(yak)20:59, 4 January 2009 (UTC)
MJC, when you write “[your editing practice] doesn't normally include the linking of common units”, I assume that means you don’t link the first-time occurrence of meters or kilograms when they are not accompanied by a conversion; is that right? Greg L (talk)21:02, 4 January 2009 (UTC)
Rarely are they not accompanied by a conversion. I agree that multiple links are not good, but is avoiding 5 ft (152 cm) worth a mountain of instruction to avoid. Does once really hurt? I don't believe so. Sorry, but I'm not sold. —MJCdetroit(yak)21:31, 4 January 2009 (UTC)
"Does once really hurt?" is a 'thin end of the wedge' argument. If once doesn't, then "Does twice really hurt?", and so on. How many times does it take? I'd rather take the good advice of WP:Overlink and not have any unnecessary links. Ask the question, "Who needs either of the two links in 'His dog was 5 ft (152 cm) long'?" Anyone familiar with feet understands how long his dog was - as does anyone familiar with centimetres; who's left? and so where is the necessity for the links? --RexxS (talk) 22:52, 4 January 2009 (UTC)
Following them backwards can help us find you people who use improper precision in your conversions, and tweak your choice of units. Gene Nygaard (talk) 10:03, 5 January 2009 (UTC)
That's actually a good point Gene. Maybe we need a second-class of "invisible" links for tracking purposes, to keep track of what's related to what without pissing off the plain-text aficionados (we do have hidden categories after all). This would at least make it once again possible to compile a list of things that happened on a specific year/month/day even when no more articles visibly link to it (aside from other date pages). — CharlotteWebb20:10, 5 January 2009 (UTC)
As for the claim of istruction creep, I agree that it's evil and ideally I'd just say "use common sense". But there are many idiots who don't have a common sense and many more trolls who aren't willing to use theirs. But have you taken a look at http://en.wikipedia.org/w/index.php?title=Wikipedia:Manual_of_Style_(dates_and_numbers)&oldid=261478985#Units_of_measurement? It's five screenfuls on my display, which include many absurdities, such as the mandatory use of a middot to multiply units (SI allows both it and the hard space, with the latter being much more common in practice, and some non-SI units are simply justaposed as in mAh and kWh), mandatory slash to divide (it is the correct and most common usage for SI units, but I don't thing mph should be forbidden, which (I think) is much more common than mi/h), forbidden repetition of units in ranges 5.9 kg – 6.3 kg (which is the only reasonable thing to do if boundaries of the range are of different orders of magnitude as in 700 nm – 1 mm), Use kn to abbreviate knot rather than kt (could be confused with kilotonne) or KN (could be confused with kilonewton) (pretending I didn't notice the capitalization of the K in KN, a sentence where you can't understand if we're talking of a speed, a mass or a force would need to be reworded anyway, and any editor could just go to knot (speed) to learn its symbols, no need to mention it on MOS:NUM), and then I got tired of looking for examples. That is instruction creep. --Army1987 – Deeds, not words. 00:54, 5 January 2009 (UTC)
Should the volt be included? After all, I think pretty much everybody knows the AA cells in the remote control of their TV set are 1.5 volts each, and that mains voltage is about 220 V (or about 110 V, depending on their country). --Army1987 – Deeds, not words. 03:20, 6 January 2009 (UTC)
Interesting. I think you are right about it being widely understood; it certainly passes the “wife” test. But is it encountered sufficiently often on Wikipedia (like days and hours and meters and kilograms) to warrant messing with it and dipping into the “electricty” world? If you think this concern is unwarranted, please add it. Greg L (talk)06:55, 7 January 2009 (UTC)
P.S. Even though it is a valid observation, I think others might look at our lead example, where one is supposed to link the ampere, and might be puzzled (and question the advisability our having the same right as anyone else to procreate) if we then say that the volt should generally be exempt from linking. Greg L (talk)19:36, 7 January 2009 (UTC)
Of course volts are common. There shouldn't be any question whatsoever about that.
The problems here include:
A strange, unwarranted assumption that we should be able to look at anything, any unit of measure, any symbol for a unit of measure, whatever, in an abstract out-of-context sense and say that it should not be linked.
Or the corollary that it would be desirable for the manual of style to do so beforehand for any single unit of measure.
An equally stange notion that "commonness" means something should not be linked.
"France" or the "United States" or "Chicago" or "Tokyo" certainly are "common" terms, understood by most people around the world. That doesn't mean we shouldn't have a least some of the zillions of links to them.
The "watt" is also a very common unit of measurement. Yet many people, certainly in the United States and in many other places as well, are going to be left scratching their heads when they read that some one-cylinder gasoline engine is "3,000 watts" or "3 kW" and the like--especially when these are just used as adjectives describing the engine without identifying the quantity being measured, so they might just be some manufacturers branding quirks.
To Greg: If the point is to "dip in the world of electricity", Its tension is 220 volts. usually makes more sense than Its tension is 220 volts., but anyway your point is valid, so I won't add it to the list. To Gene: I've recently made an edit to WP:OVERLINK to address your concern, but I still think that linking countries for linking's sake as in It was developed by Swiss mathematician Leonhard Euler and Italian mathematician Joseph Louis Lagrange in the 1750s. is quite pointless (their nationality is not too relevant to the Euler–Lagrange equation itself and to its significance, and any reader who wants to go from there to Italy can reasonably (and correctly) guess that the first sentence of Joseph Louis Lagrange contains a link to it, so they would go to Joseph Louis Lagrange and from there to Italy. --Army1987 – Deeds, not words. 13:18, 8 January 2009 (UTC)
Here's another — in the exemptions section for units of length that aren't common and ought to be linked, should we include leagues? Mlaffs (talk) 03:58, 6 January 2009 (UTC)
None of the above. The biggest problem is instruction creep, and the unwarranted notion that everything should be determinable from looking at our Style guidelines. Gene Nygaard (talk) 21:24, 31 December 2008 (UTC)
If there is no guidance at all in this situation, how do we prevent inevitable conflict? With pre-existing guidelines to point to, it provides consistant guidance in resolving disputes before they become acrimonious. --Jayron32.talk.contribs21:34, 31 December 2008 (UTC)
Since none of these solutions seem to solve the problem, what guidance do you think should be provided for people trying to decide when to, and when not to, link units in an article? --Jayron32.talk.contribs21:58, 31 December 2008 (UTC)
These proposals fail to distinguish between common units (i.e. basic units of length, weight and volume) and the lesser-known, technical units. Common units (such as inches, millimeters, liters) should almost never be linked, while technical and uncommon units (such as Gross Register Tonnage) should probably be linked a couple times in the article. Dabomb87 (talk) 22:26, 31 December 2008 (UTC)
I have added a 5th proposal based on your suggestion. Indeed, anyone can add new proposals should these be inadequate. Remember, this is not a vote, but a discussion and if anyone has a reasonable solution, PLEASE ADD IT ABOVE. --Jayron32.talk.contribs02:23, 1 January 2009 (UTC)
Before we ever had any voting on the choices, that section should have been filled in, and the wording of the choices to vote on should have been hashed out. There's nothing worse than changing the options in the middle of a vote--so what those options really are should be clearly established before there is any voting whatsoever. Gene Nygaard (talk) 22:21, 31 December 2008 (UTC)
I agree with Gene that a more thorough examination of the possibilities need be made before any vote is initiated. I would not be happy with any of the above proposals as they seem based on what I could only describe as an oversimplification of the issue at hand. I'd like to see a proposal which takes into account the following factors.
whether the unit can be considered common for the given context
whether the unit has any particular relevance to the article/section
whether the a link is being repeated from the introduction, a part of the same section or a completely different section
I disagree. The problem is that there is different wording on at least 3 different guidelines. We can agree on the principle and change any relevent policies later. I linked the 3 I could find that directly addressed this issue. If you know of any more, feel free to add them; but the priniciple still needs to be addressed so all guidelines can be updated correctly. It is entirely possible these are the only three pages that are affected however, with some 500 or so policy and/or guideline pages it is unreasonable to hold up the important discussion until all 500 have been checked for possibly refering to this idea... --Jayron32.talk.contribs02:13, 1 January 2009 (UTC)
I believe that Jimp is talking a lot of sense here: the devil is in the detail. To start with, I want to know the reasons that pro-link editors believe readers would click on a link to metre or stone. Can we have examples that relate to the information provided at those linked articles? Tony(talk)02:28, 1 January 2009 (UTC)
Well, there is a big difference between a term like "meter", which everyone in the English speaking world is likely to know what it is, and more esoteric units like Henry (unit) or Newton (unit) or Rod (unit) or the like. Most people (even us poorly educated and backwards Americans) can roughly hold their hands apart and say "a meter is this big". However, not many people know what a Henry or a Newton or a Rod is. I have added 2 more proposals that hopefully will help address some of these concerns. Please feel free to add any more should the 6 above still fall short. The purpose of this is to get many people proposing and discussing thing so that we can decide how to handle this situation... --Jayron32.talk.contribs02:35, 1 January 2009 (UTC)
Just like English is pretty much spoken by all Europeans under 30 years of age, Europeans can’t assume that everyone knows English; there are plenty of older Europeans who know enough English to interpret an ad for American-labeled cigarettes and that’s about it. Similarly, it is a fallacy to assume that older Americans are generally familiar with kilogram or meter or any of these other units of measure that you assume are universally understood. They are not. Just link the first occurrence; it’s not hard for us to do and. Besides, as it only turns a word or two blue; it has zero footprint.
BTW, when traveling in Austria, I was struck by a poster in Vienna for an American-label cigarette. Vienna is, after all, a city that was bombed by the allies during WWII. Yet the ad showed some big bastards riding some Harleys through the American southwest with a P‑51 Mustang flying right over their heads. Two icons of American power to pitch cigarettes. I found it interesting. Greg L (talk)03:06, 1 January 2009 (UTC)
Two matters, then. It's only in scientific articles where there's consensus not to use US units (that's the rule) that US readers are not provided with a US equivalent. Do readers need to know what a kilogram is where a conversion is supplied on the spot? I'd hazard a guess that the very people you'd be aiming the link at would have zero interest in the Unit article (and wouldn't even suspect they'd encounter Greg's stunning computer generation of the IPK at Kilogram. There, they'd be faced with the opening fact that a kilogram "is almost exactly equal to the mass of one liter of water". Hmmm. Go read it and you'll see that it's pitched to a completely different kind of reader—ironically, one who wouldn't be consulting the link to kg in an article.
This brings me to the wider issue of why WP doesn't have an article tailor-made for older US readers who don't know what a kilogram or kilometre is, and young readers outside the US who don't know what a mile is. I proposed the creation of a centralised article that includes ways of visualising weights and measures of both kinds. This would be the ideal link first-off in an article, at least for the standard units. When it comes to the odd-ball ones, sure, they probably need to be linked ... rods per square newton? Tony(talk)03:37, 1 January 2009 (UTC)
I think that is an outstandingly interesting idea that should be given serious consideration. Perhaps, the centralized article would have “double-equal” section headings that are titled with simply the name of the unit of measure. Each section would begin with the italicized {main} to the actual article. As Tony proposes, each entry would be exceedingly short and simple and would assume that the reader looking at “Kilogram” understood U.S. pounds and needs only plain-speak to relate it to what they are familiar with. Similarly, a reader of “Pound (mass) would be assumed to fully understand what a kilogram is.
Having said all that, I note that the lead paragraph of Kilogram pretty much does that much already. Wikipedia is known for its pithy lead paragraphs. Don’t the majority of our articles on units of measures address the basic “ah HAA” of the nature of the measure and its general magnitude in their first paragraph?
Finally Tony, I realize that you have exposed a logic fart on my part. Indeed, if we provide parenthetical conversions for familiar measures (not the units of measure, such as kilogram or carats, but the measure, such as mass), then there should really be no need for a linked conversion. Older Americans very often will not understand that kilogram is a unit of mass nor have a flying clue as to its magnitude, but accompanying conversions—like “(80 lb)” which is the weight of a sack of concrete—clearly solves that dilemma by instantly and intuitively providing the ah Haa for both the measure and magnitude. So I am inclined to take back what I said above. So…
Perhaps the guideline should be that units of measure for common measures (mass, length, temperature) need not be linked wherever accompanying conversions are provided. In scientific articles, where no conversions are provided, the first occurrence of all units of measure should be linked. For less common measures such as light intensity, viscosity, etc.) we always link the first occurrence regardless of whether it is accompanied by a conversion or not. Does that seem more logical? And isn’t it extremely close to what MOSNUM already says?? If it seems sensible and it is not exactly what we already have on MOSNUM, then we can work on grey areas like “pressure” later. Pressure too is a common measure but only if the units of measure are the psi for Americans and kilopascal (I assume) for the rest of the world. Exotic, engineering-style pressures and stresses like ksi (thousands of psi) ought to be linked. Greg L (talk)05:28, 1 January 2009 (UTC)
A one-litre bottle of cognac
For example, this pic, or one in a better size-context, might appear as an illustration of "litre". I can imagine a mile/km marked off in relation to the NY skyline, and an acre and a hectare marked as a square in an aerial shot of a well-known city centre. This is what would assist the reader much more directly via a link to the "Volume" or "Area" section of the "Weights and measures in everyday terms" article. People need to visualise. I want pics of, say, a thousand-gallon drum, of a line marked on a map from LA to wherever marking off a thousand kilometres, and another showing a thousand miles. That kind of thing. Tony(talk)06:16, 1 January 2009 (UTC)
I can't imagine anybody having a whole lot of difficulty visualizing a one-liter or two-liter bottle. We don't need a picture for that. Sure, there are things for which a picture might be helpful; this is just a particularly bad example. Gene Nygaard (talk) 14:15, 1 January 2009 (UTC)
Well, anyone who doesn't already know what a litre is or how much a litre represents would have a great deal of difficulty visualizing a one-litre or two-litre bottle, which is kind of the point of the exercise. Mlaffs (talk) 16:06, 1 January 2009 (UTC)
Sure, but the question is, where is the world are you going to find these people capable of reading Wikipedia who do not know what a one-liter or two-liter bottle is?
However, this is thread drift totally unrelated to the linking issues at hand here. Let Tony1 and GregL go somewhere else and dream up things like this, without cluttering up an already overbloated discussion. Gene Nygaard (talk) 16:51, 1 January 2009 (UTC)
Gene, I don't mean this as an insult in any way, but I honestly can't tell if you're just being provocative or if you actually believe what you're saying. I'd bet dollars to doughnuts that I could walk out into the main business district of any major U.S. city and within five minutes find more than one person who is computer-literate, educated (at least high school graduate, and probably university), and doesn't have a clue how much a litre is, or a kilometre, or a kilogram. I know for sure that I could step out of my condo here in Toronto onto the main street of the city and find someone matching those characteristics who, while they're certainly familiar with the terms, doesn't know how much a gallon or a mile is. Heck, we probably wouldn't even need to go too deep into the community of people who regularly edit Wikipedia to test this, let alone the people who read the site.
Simple plain-speak that I agree with. Americans don’t use metric. Even though two-liter bottles of pop are a common package size, if your measuring cups aren’t metric, and your bathroom and kitchen scales aren’t, and your tape measures and yard sticks aren’t, then Americans—particularly older ones—don’t automatically know what measure liter, meter, and kilogram are let alone their magnitude. This is especially true if they land on an article that spells them litre and metre—this puts the units entirely out of all experience. Greg L (talk)17:55, 1 January 2009 (UTC)
That's why I think this discussion actually is relevant. What's common to you or me isn't necessarily common to my next-door neighbour, the person down the street, the guy across the border, or User:Manonthestreet. That's why, although they might not strictly be necessary, it's not harmful to link to link to some of these terms at least once. Mlaffs (talk) 17:32, 1 January 2009 (UTC)
I totally agree. Even though I have a Master's degree and am an active Wikipedia contributor, I only have a very vague idea of what a yard is, and if when I encounter such units I am always click on the wikilink and do the math. Nicolas1981 (talk) 18:14, 4 January 2009 (UTC)
Mlaffs and Nicolas1981: We’re talking only about not linking when there is a conversion. To help accommodate editors like Tony who really hates blue links, can we agree that no one is confused by U.S. Air Force pilots may be no taller than 6 foot–7 inches (2.00 m)? Because length is a common measure and one of the units is familiar and the context is clear, no one is confused. There is no point desensitizing readers with yet-more-blue on such every-day stuff. We need to find a middle ground between those who would link everything and those who hate links. Greg L (talk)01:39, 6 January 2009 (UTC)
Wow, Greg, that post was centuries old in Wiki talk page years ;>). I was actually responding to Gene's dismissing the logic of Tony's one litre bottle image, back when the current topic of discussion was the idea of a general article about units of measure, what unit in imperial equals how much in metric and vice versa, etc. I'm pretty much good with where we seem to be getting now. I'd agree that nobody should be confused by the conversion sentence you've shown just above, except for that rare user who reads the m and thinks it means miles instead of metres, and I'm not too interested in helping that reader. A link to either inches or metres in that instance ought to be unnecessary and I certainly wouldn't add one. However, if I came across that linked in an article, would I remove it? Probably not — I don't think that link would be the end of Wikipedia. I'd be even less likely to remove it if, rather than linking directly to either the inch article or the metre article, it linked to Tony's comparison of units of measure article. That's one of the reasons I personally prefer suggestive language — need not — rather than prescriptive — should not. However, as I've said, if consensus lands on should not, I'll line up to defend it when necessary. Mlaffs (talk) 02:19, 6 January 2009 (UTC)
With the latest tweaks, Proposal 11 seems to be quite suggestive (v.s. prescriptive). Are you inclined to vote on it? Greg L (talk)03:05, 6 January 2009 (UTC)
Well, my back's a little sore since the holidays, so I'm actually more reclined than inclined right now. But, yes, I've added my !vote above. To those who did the heavy lifting, nice work. Mlaffs (talk) 04:14, 6 January 2009 (UTC)
Most Europeans won't have a clue of how warm a foo is if we state that the temperature of a foo is 69 °F, and, while the best solution to this would be writing 69 °F (21 °C), in cases where this would be inappropriate, linking degree Fahrenheit would give those readers a way to figure it out. And vice versa for degrees Celsius and American readers. (Yes, these cases should be very rare IMO, but there actually were many people arguing that it was inappropriate to add conversions to degrees Fahrenheit in Mercury (planet).) --Army1987 – Deeds, not words. 14:13, 6 January 2009 (UTC)
Do you believe that people will click on the link just because it is there? Lightmouse (talk)
Army, it's funny that you should mention Mercury. Just yesterday, I commented at this FLC about the lack of conversions to standard units. Apparently, it is the standard to not provide conversions in astronomy articles. I don't disagree with them, just thought it worth noting. Dabomb87 (talk) 13:25, 7 January 2009 (UTC)
Tony, I also love the idea of the basic comparison article that you've suggested, and completely agree that it would be the ideal link in first usage.
As much as we're talking about older Americans not understanding kilogram, kilometre, or litre, I'd say it's a fair bet that the vast number of younger Americans wouldn't have clue one what they are either. That's certainly been my experience. Equally, the vast majority of younger Canadians (for example) will have heard of mile, gallon, and pound, but will have absolutely no frame of reference as to how much one of those represents. Myself, because I grew up in Canada during the metric conversion, I can pretty quickly turn kilometres into miles (and vice versa) or grams into pounds (and vice versa) in my head. I agree with Greg that we have to be careful in describing something as a "common" unit of measure — common is very much age, country, and education specific.
All that being said, I'd completely support the idea that the first occurrence for common measures need not be linked if a conversion is provided. Similarly, I'd also completely support the idea that less common measures, or where no conversion if provided, ought to be linked in the first instance. However, if we were to eventually settle on that as a concept, the wording is important. "Need not be linked" is a very different concept from either "should not be linked" or "must not be linked". While we don't need it to be linked, I don't believe that it does any harm if it is linked, and "need not be linked" should never be an acceptable reason to undertake a mass removal of such links, without regard for context.
I express this last thought because, although I desperately don't want this to be a discussion about a particular series of edits, this RFC began because of exactly that situation — a particular editor interpreting WP:OVERLINK and the wording "It is generally not necessary to link …" as suitable rationale to undertake a mass, automated removal of links, without regard to context. To be clear, in that situation, I don't have an opinion either way about whether or not terms should be linked in specific cases. However, to my mind, "generally not necessary to link" is not the same as "should never be linked".
Again, I really don't want this to be a discussion about a particular series of edits. I mention this only to provide an example of how important it is for us to get the wording right; for it to be as unambiguous as possible, and completely consistent across the multiple relevant policy pages. Mlaffs (talk) 06:56, 1 January 2009 (UTC)
More preliminary matters: Since this was improperly framed as a vote ab initio, the new options added after the voting started don't really belong there either.
Here are some of the existing rules, which were not included above:
Since some disciplines use units not approved by the BIPM, or may format them in a way that differs from BIPM-prescribed format, when such units are used by a clear majority of the sources relevant to those disciplines, articles should follow this (e.g., using cc in automotive articles and not cm3). Such use of non-standard units are always linked on first use.
Articles on scientific topics where there is consensus among the contributors not to convert the metric units, in which case the first occurrence of each unit should be linked.
...
In topics such as the history of maritime law in which imperial units (e.g. miles and nautical miles) are part of the subject, it can be excessive to provide SI conversions at each instance a unit occurs. In such cases, it is best to explicitly mention that this topic will use these units without providing conversion at each instance in the lead or in the introduction, in which case the first occurrence of each unit should be linked.
Avoid the use of unit abbreviations that have conflicting meanings in common units systems such as SI and US customary units:
...
Link such units to their definitions on first use.
...
Use long ton or short ton rather than just ton; these units have no symbol or abbreviation and are always spelled out. The metric unit equal to 1000 kilograms is the tonne and is officially known as the metric ton in the US. Whichever name for the metric unit is used, the symbol is "t".
Use troy or avoirdupoisounce rather than just ounce in articles concerning precious metals, black powder, and gemstones.
Use fluid ounce explicitly to avoid confusion with weight, and specify, if appropriate, Imperial, US or other.
Use US or imperial gallon rather than just gallon (and the same logic applies for quarts, pints, and fluid ounces).
A calorie (symbol cal) refers to a gram calorie while the kilocalorie (symbol kcal) refers to the kilogram calorie (also known as small calorie and large calorie respectively). When used in a nutrition related article, use kilogram unit as the primary unit. For articles with a largely American readership, use dietary calorie(s) with a one-time link to kilogram calorie.
In tables, infoboxes, or within brackets, use a tilde (~) or use approx. (e.g, write The capacity of a ship is sometimes expressed in gross register tons, a unit of volume defined as 100 cubic feet (~2.83 m3)).
... A link that had last appeared much earlier in the article may be repeated, but generally not in the same section. (Table entries are an exception to this; each row of a table should be able to stand on its own.)
<end of quoted rules> .
So there is a whole lot more to the existing rules than what we were told about in the beginning of this discussion--a whole lot more that should have been the first item in the agenda of this discussion, without any solutions ever offered before the existing rules were laid out on the table.
NOTE further: MOSNUM has no credibility whatsoever as long as it continues to insist on violating the standard rules, and our own longstanding (many years long) house rules, that the symbols for units of measure are never italicized. Gene Nygaard (talk) 11:57, 1 January 2009 (UTC)
Gene, when you resort to overblown hyperbole, such as “MOSNUM has no credibility whatsoever”, in an effort to buttress your position, the only credibility that suffers is your own. It would serve you well to realize that even though your proposal may at times make perfect, logical sense by any outside objective measure, your positions may lack the subtleties or convenience necessary for other editors here to feel comfortable with them. Given that this is a collaborative writing environment, you should make more of an effort to read other editors’ posts and understand their positions. Greg L (talk)17:55, 1 January 2009 (UTC)
Tossing out a possible technical solution
Unfortunately, my CSS/JS skills are not great, but I'm wondering how much of the various issues can be dealt with by first wrapping all unit displays in CSS tags (likely distinguished further by their base units such as a CSS class "unit-velocity", "unit-pressure", etc.) and then using whatever tools to allow users to show dates in the format they want, add unit links, and the like. Yes, I know this is suspiciously like date linking above, which is why I'm only throwing it out both as a technical matter and a practical matter to see if it's a possible resolve. Even if done this way, there needs to be a default basic display for unregistered users that is consistent across a page and all pages. --MASEM16:54, 1 January 2009 (UTC)
Even more preliminary matters
That this is framed as a vote is more evident in that we were only given the option of "Support of this proposal" without an accompanying "Objections to this proposal", and with the discussion sections normally used to amplify a short statement of support.
No instructions are given on voting your support for more than one proposal, nor any instructions on voting your opposition to any proposal.
Yet new options are being added in a haphazard manner after the voting has started.
In other words, the whole structure and framework is not conducive to the discussion.
This whole discussion originated from the inconsistencies between various guidelines. This could be solved by simply not having the same point repeated in fifteen different MoS pages. For example, since October there has been a tag on WP:OVERLINK and on MOS:LINK suggesting to merge them, which apparently everybody ignored. If they were merged, there would be no need to repeat the #Dates and #Units section on the current MOS:LINK, as they would already be discussed in #Overlinking_and_overlinking when WP:OVERLINK is merged there. Eliminating the redundancy, and the possibility of inconsistencies. The "including common units of measurement (particularly if a conversion is provided).[2]" would be moved to the last point of the list and changed to "... and common units of measurement for which a conversion is provided (see MOS:NUM for details)." And then in MOS:NUM we could incorporate Greg L's proposal or some tweak thereof.
