Years and dates archives |
---|
|
Proposal for a minor change in the requirement for unit conversions
Conversions clutter the text, making it slightly less readable. While there are reasons for persisting with the requirement to convert main units to the other system in non-scientific articles, I contend that and exception be made for scientific articles. These articles must already use metrics as their main units, and given that:
- US scientific text typically uses metrics;
- US readers who consult scientific articles on WP are likely to be familiar with metrics, or at least are unlikely to be flummoxed by them;
- school students in the US are nowadays introduced to metrics;
- key institutions, including the military, use metrics exclusively;
- a sizeable minority of Americans grew up with metrics (including Latinos);
- links to metric units can easily be provided on their first occurrence.
The current text is:
- Conversions to and from metric and imperial/US units are generally provided, except where inserting a conversion would make a common expression awkward (“The four-minute mile”).
The proposal is that this be:
- Conversions to and from metric and imperial/US units are generally provided. There are two exceptions:
- where inserting a conversion would make a common expression awkward (“The four-minute mile”);
- scientific articles, 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.
We'd need to change the example for precision, two points down, to a non-scientific one, to be consistent with this change.
I seek consensus for this alteration. Tony 14:58, 24 August 2007 (UTC)
- NO, forgive the pun, but you are just trying to "inch" your way toward making wikipedia metric only as you proposed above. The MOS as written is more than adequate and you are just trying to get a license to start removing conversions from articles. And some of your observations from across the ocean on the state of use of metric measurements in the United States are a little off. —MJCdetroit 15:35, 24 August 2007 (UTC)
- While I can see your point, I think that this is a point where it's appropriate to address the suggestion, rather than the editor making it, much as we are enjoined to address contributions rather than contributors. If this is an attempt to inch towards an unacceptable goal, it's not actually likely to help that goal much (see comment below from Wikidemo). On the other hand, taken on its own, it does make sense. SamBC(talk) 18:20, 24 August 2007 (UTC)
- YES, if you remove the comma after "articles" to make clear that is a condition and not an editorial comment. If the article is in a field where metric measurements are universally used and any other source people read even in America would be metric, no point converting. E.g. nobody would ever say that the daily recommended intake of a certain mineral is xx mg (0.0000yy ounce). You may also consider "technical" or "technical and scientific" articles. Proposals like this should be judged on their merit, not the identity or intent of the contributor. Wikidemo 18:11, 24 August 2007 (UTC)
- BTW, it's already the de-facto rule. See, for example, the articles Niacin and Rocket engine. Wikidemo 18:17, 24 August 2007 (UTC)
- I'd support wikidemo's version, partly because it makes sense (coming from a scientific background), and partly because it's a de facto rule already (and policy/guidelines are meant to describe what currently happens, that is, be descriptive rather than prescriptive). SamBC(talk) 18:18, 24 August 2007 (UTC)
- My proposal was/is merely to make an explicit statement that the metric system is encouraged. Frankly, I am surprised that we do not already have this. This might have a minor benefit on FA and other article reviews. It might reduce metric-hostile edits. However, beyond that, the MOS has little influence. The major influences are FA reviews and Wikiprojects (as has been demonstrated by the non-metric FA examples from Wikiproject ships mentioned on this page).
- In addition, I think the rules could be simplified (many current rules appear to address rare and small issues). Thus (using Tony's revision of my wording) I propose that we replace the current 'Which system to use' and 'Conversions' sections with:
- Conversions
- Editors are encouraged to use the metric system.
- Non-metric may be primary and metric secondary where:
- The article is both US-related and non-scientific
- There are compelling historical or pragmatic reasons why metric units should not be the main units.
- In general, spell out the main units and use unit symbols or abbreviations for conversions in parentheses. For example, “a pipe 4 inches (100 mm) in diameter and 10 miles (16 km) long”. By consensus, the main units may also be abbreviated in the main text after the first occurrence.
- Converted values should use a level of precision similar to that of the source value; for example, “the highway is 32 miles (51 km) long”, not “(51.2 km) long”.
- Category:Conversion templates can be used to convert and format many common units, including {{convert}}, which includes non-breaking spaces.
- In a direct quotation, consider providing conversions outside the text of the quotation.
- Conversions
- Lightmouse 19:19, 24 August 2007 (UTC)
- As I said above, I think that the MOSNUM as written is more than adequate and does encourage use of the metric system. However, in certain highly scientific articles (like Wikidemo's drug/vitamin example) I can understand the point that having conversions for drug dosage amounts would not be the norm as all drugs have been standardized to mg globally (even the ones like aspirin that were traditionally weighed in grains). If Tony could reword his statement to in "highly scientific articles"...and maybe use Wikidemo's drug article as an example, I would drop my objection. What I don't want to do is leave the word scientific open to interpretation, whereas articles like Moon, Lake and Ant or even Toluene are striped of any conversions because they involve astronomy, geography and zoology and those are sciences, therefore they are scientific so they should be metric only. —MJCdetroit 19:49, 24 August 2007 (UTC)
(outdent) MJC, I'll insert "highly" ("highly scientific") into the text if it's going to be a deal-breaker, but the epithet is fuzzy—where exactly is the boundary between highly and non-highly scientific, just as where is the boundary between scientific and non-scientific? I reiterate that the word "scientific" (alone) is already used in the section. No one has complained about that distinction. I don't think that the explicit use of the "drug" article will solve the boundary problem, so I'd rather not clutter the text. I put it to you that a case-by-case consensus (which may be easily generated in many cases) is your safeguard.
Let's examine the implications of the short proposal in further detail. The need to treat each article for which this might be an issue (a small minority) separately is why the proposal requires the consensus of contributors, even where it's clearly a scientific article. SandyGeorgia has raised the issue of a volcano in Hawaii: height in metres, or in feet with conversion? Contributors who want unconverted metrics would have to overcome two hurdles:
- First, the article has to be scientific: if it's framed as a geotechnical topic, that's easy. On the other side, if it's the article on Hawaii itself, or its about the religious significance of a volcano to local culture, it's almost certainly not scientific. If that classification is in contention, it comes down to consensus, just like a lot of other things. That would be necessary, but rarely, I suspect.
- Second, there has to be evidence of consensus, even if it is agreed that the article is scientific.
I put to you all that these are significant safeguards. No one will be mass-removing conversions in scientific articles without gaining consensus to do so on the talk page. All of this is implicit in the short text of the proposal.
Wikidemo, you're quite right about the comma—my blooper.
I see no reason to add a point "encouraging" the use of metrics. We've already set out precisely the circumstances where metrics and imperial are the main units. Lightmouse, I now think your proposal is too radical, except that your point about direct quotations has merit. May I offer an alternative wording?
"Conversions required for units cited within direct quotations should appear within square brackets in the quote."
Here's the proposal again. I'm posting a note at MOS with a link to this discussion.
*Conversions to and from metric and imperial/US units are generally provided. There are two exceptions:
- scientific articles 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;
- where inserting a conversion would make a common expression awkward (“The four-minute mile”);
And no, it's not conceived as the start of a slippery slope to ban imperial units from WP; that clearly will not gain consensus. This is an overdue modification for a subgroup of articles. Tony 02:12, 25 August 2007 (UTC) PS Does the addition of "technical and" before "scientific articles" add anything? Needs advice. Tony 02:22, 25 August 2007 (UTC)
I must admit I'm quite amazed about the reaction here. The suggestion that an article must be highly scientific I just don't get. Take the Moon for example. That article should not have imperial units in it at all. The moon is 384,403 km from the earth. Why list it in miles at all? It's a big number and even I cannot visualise how big that is. Listing it in miles doesn't help anyone. Now on the other hand if I need a number to do a calculation then that's a different story - and in that case the number you'll need will be the metric unit. Now other units like light-second and astronomical unit are much more relevant (as they are used by astronomers) and editors may want them there - even though they are not SI (but certainly derived from SI). Any article that is remotely scientific should not have imperial units and any articles on medicines it could be dangerous to. For example, if the maximum dose of some drug is some volume expressed in millilitres and someone from the UK converts that to Fluid ounces then that would be an overdose for someone in the US because the UK Fluid ounce and the UK Fluid ounce differ. By the way - which imperial unit do you use? The UK, the US, troy, avoirdupois, apothecary?
For the average person it takes one hour to get an understanding of the units of the metric system (see http://www.metricationmatters.com). This is quicker than getting to use Wikipedia itself! To say that it is too hard really dumbs down your audience. People come here to learn. If you have links on your metric units people will pick them up very quickly. Jim77742 02:44, 25 August 2007 (UTC)
Yes, didn't a US satellite costing squillions crash into Mars because someone mixed up imperial and metrics? Same for the lens on the Hubble telescope? Tony 03:48, 25 August 2007 (UTC)
- Tony, I accept your modification about direct quotes.
- As MJC says, there are examples of metric-only in the USA. US military personnel use unconverted metric units. Drugs and food use grams (e.g. 'fat grams') and mg. Metric dimensions are accepted in weaponry and the military. Engine capacity is now in liters and cc without converting. Similarly, metric engine bolt dimensions are not converted. Unconverted metric is used in some regulatory situations, i.e. 'tons' of carbon are apparently always metric. We have reached the stage where the US Presidential State of the Union address quotes liters and kilometers without conversion. That would have been unthinkable a few decades back. In summary, it is not just American scientists that accept information when presented in metric-only.
- We also need to note an important distinction: some people accept text in metric (as in the State of the Union example) but would not write in metric. So just because an American might instinctively write BTU/h for power does not mean that they cannot cope with unconverted watts in Wikipedia.
- I look forward to another proposal. Lightmouse 12:34, 25 August 2007 (UTC)
- Watts are metric and imperial. Try again. Tony 12:59, 25 August 2007 (UTC)
- Please try to be polite. I am actually on the pro-metric side, although that should not matter when it comes to civility. Lightmouse 14:43, 25 August 2007 (UTC)
- I was being polite. Now, I really don't understand your conclusion—"accept text in metric ... but would not write in metric"? And then the watts example, which confuses me. And it wasn't clear why you're looking forward to another example, or what kind of modification you had in mind. Can you reword, because I really want to understand what you're saying. Tony 15:03, 25 August 2007 (UTC)
- Please try to be polite. I am actually on the pro-metric side, although that should not matter when it comes to civility. Lightmouse 14:43, 25 August 2007 (UTC)
- I accept now that you did not intend to be rude.
- The first paragraph addresses the idea linking metric and science. It is true that scientists use metric. Unfortunately, some people use 'metric is for science' as an idea that confines metric to science only. The scope of metric usage in America is now well beyond science. I do not think anyone here was suggesting such a constraint but I wanted to make the point. How scope translates into MOS text is another matter.
- The second paragraph makes the point that understanding metric is not the same as using it. Compare language and metric:
- You can often understand a language better than you can speak it. Similarly with metric, many Americans function very well when given information in metric units yet may not be so proficient at writing text in metric units.
- Sometimes people feel a bit silly using a foreign language, particularly when in their home country. Similarly with metric, some people feel a bit silly using metric units when in America.
- The watts example was actually a BTU/h example. Look at the example I gave of the State of the Union address; Americans would not naturally use kilometers but accepted being presented with a distance of 150 kilometers.
- I mentioned another proposal because it looked to me like you and MJC were getting close to agreement. My original proposal was very much less ambitious but the addition of encouragement for metric was an advance. I will support your proposal or any other that advances metrication. Lightmouse 16:26, 25 August 2007 (UTC)
- The second paragraph makes the point that understanding metric is not the same as using it. Compare language and metric:
- No. This is a usability issue disguised as a style concern. Conversions are provided to make articles accessible to readers with limited or no familiarity to an article's primary units. As a result their removal from appropriate locations will reduce the usability of an article while providing no functional improvement in return. --Allen3 talk 12:44, 25 August 2007 (UTC)
- It's both; this is a tradeoff between usability and the clumsiness inherent in conversion, which is why it should not be mandated in either direction. Septentrionalis PMAnderson 17:26, 26 August 2007 (UTC)
- No. This is a usability issue disguised as a style concern. Conversions are provided to make articles accessible to readers with limited or no familiarity to an article's primary units. As a result their removal from appropriate locations will reduce the usability of an article while providing no functional improvement in return. --Allen3 talk 12:44, 25 August 2007 (UTC)
Allen, you seem to have ignored the requirement for the first occurrence to be linked. If that is not good enough, what is? And why do you accuse me of disguising something? Please explain yourself. Tony 12:59, 25 August 2007 (UTC)
- What is, is using both systems - as the Manual states. You really have to understand the lack of depth of understanding of the metric system in the U.S. Yes, we use 2 liter bottles of pop - because that's what they sell. But if you ask how many 500 ml bottles one could fill from a 2 liter most people wouldn't know (and I expect most couldn't immediately answer which is larger a two-liter or a gallon.) Most Americans wouldn't know which had a larger engine - a 2000 cc motorcycle or a 2 L car. Understanding is the key we are trying to give when we write encyclopedia articles. It is not useful to restrict that only to those with knowledge of the metric system. Even medicine in the U.S. does not use metric exclusively (nor does the military). For instance my newborn is measured: weight in pounds, length in inches and head diameter in centimeters while there were metric conversion charts posted around the hospital nursery. Rmhermen 15:18, 25 August 2007 (UTC)
- Most people in metric areas, including me, wouldn't know the difference between 2000 cc and 2 L; that's not a reasonable argument. Most people in the US wouldn't know how many feet there are in a mile, either. First, this involves only readers of scientific articles, so you'd expect a modicum of openness on their part to metric units, if they're interested enough to consult a scientific article here; second, the units would be linked on first occurrence, for full explanation/conversion, if necessary; third, WP has an educational function, doesn't it?, and fourth, only scientific articles where there's consensus to do so would be free of conversion clutter. Are you taking all of these issues into account, and can you use a more reasonable argument? Tony 15:31, 25 August 2007 (UTC)
- What is, is using both systems - as the Manual states. You really have to understand the lack of depth of understanding of the metric system in the U.S. Yes, we use 2 liter bottles of pop - because that's what they sell. But if you ask how many 500 ml bottles one could fill from a 2 liter most people wouldn't know (and I expect most couldn't immediately answer which is larger a two-liter or a gallon.) Most Americans wouldn't know which had a larger engine - a 2000 cc motorcycle or a 2 L car. Understanding is the key we are trying to give when we write encyclopedia articles. It is not useful to restrict that only to those with knowledge of the metric system. Even medicine in the U.S. does not use metric exclusively (nor does the military). For instance my newborn is measured: weight in pounds, length in inches and head diameter in centimeters while there were metric conversion charts posted around the hospital nursery. Rmhermen 15:18, 25 August 2007 (UTC)
(outdent) I came here following Tony's request for input at wikiproject Physics. I support this, it is already the de facto position for many (most?) science articles (because science is metric globally). Also, any changes to MOS to give editors more discretion is a good thing. PaddyLeahy 15:46, 25 August 2007 (UTC)
- The current policy should not be changed. We should strive to make scientific articles accessible to people who are not members of the scientific community and who are not familiar with metric units. Having imperial alternative units helps make articles more accessible at very little cost to readability.
- Wikipedia should not favor one system of units over another. Cultural considerations are as important as technical ones and favoring one system is pushing a point of view about such considerations. The deciding factor on which unit to use in an article should be what units are used significant sources of the article and not the writers' personal preferences.
- By the way, where else were people invited to this discussion? -- Patleahy (talk) 16:21, 25 August 2007 (UTC)
- I invited them at WP:VPR. Chris the speller 20:22, 25 August 2007 (UTC)
- The point is that there are situations where converting to imperial is not helpful and doesn't make the article more accessible. If there are topics where imperial measurements are no longer used, we shouldn't insist on their usage (measuring drugs in mg is one example). Colin°Talk 17:25, 25 August 2007 (UTC)
- There are very few cases where not including alternative units is the better thing to do (I'm not sure if drug articles are one of these cases). We should not write policy that is motivated by such edge cases. Since this is a guideline infrequent exceptions are already allowed where appropriate. -- PatLeahy (talk) 17:49, 25 August 2007 (UTC)
We should simply do whatever is customary in the literature. The metric system is preferred, simply because that's the case in the real world. However, in many fields this is not the case like e.g. in engineering. Also, I've noticed that many wiki science articles use SI units in a way that is i.m.o. not a good reflection of what the real world practice is. E.g., in theoretical physics it is customary to use CGS units and not SI units. The reason is that this simplifies equations for electromagnetism. But in the wiki elecromagnetism and special relativity articles SI units are used. Especially for the special relaivity article this is extremely awkward.
Also, in particle physics it is customary to use natural units (h-bar = c = 1). Masses are almost always given in units of GeV or MeV and not in GeV/c^2. The latter would be dimensionally equivalent to the kg, but in high energy physics people don't care about that. Assigning different dimensions to Length, Time and Mass is ultimately a convention that is not useful in fundamental physics. Count Iblis 18:56, 25 August 2007 (UTC)
- I'd support this idea as it is what we do already. For instance in articles on protein structure or microbiology all measurements are in either angstroms, nanometers or micrometers, not millionths of an inch. Tim Vickers 19:49, 25 August 2007 (UTC)
I believe this proposal would be appropriate. The units that are appropriate to one article are not necessarily appropriate to the next. In some articles, like four minute mile, there is an obvious need for miles and minutes to be the appropriate unit. However, nobody wants to measure the speed of light in miles per minute, even if the conversion could be made. I think conversions should be included on a per-article basis, and the "default" when no consensus has been developed (articles with few active editors) should be as proposed here. --Cheeser1 20:50, 25 August 2007 (UTC)
- Although we should include the figure in furlongs per fortnight; some readers will look for it. ;-> Septentrionalis PMAnderson 22:23, 25 August 2007 (UTC)\
Quite seriously, we should not give more than advice about metric. It's appropriate for some articles to use metric alone. It's not clear to me that the conversion helps four-minute mile, and it may be worse than a link would be. One of the first steps in improving grain (measure) would be to start it with a definition in terms of the Anglo-American system; conversion to metric belongs in the second paragraph. Also, there have been other values, both quite close to this and much further. Septentrionalis PMAnderson 22:31, 25 August 2007 (UTC)
- This whole conversation forgets that MOS is a guideline. It can be, and often should be, ignored by consensus, whether it says so or not. Septentrionalis PMAnderson 23:51, 25 August 2007 (UTC)
I support this proposal as long as it's clear that it's for science articles, determined by talk page consensus. SandyGeorgia (Talk) 23:19, 25 August 2007 (UTC)
Support: As stated above, this is the de facto standard anyway - and I firmly believe that the style guide should reflect current practice. I wrote dozens of new articles on chemical compounds using purely metric units 2-3 years ago, and no one has even suggested adding in non-metric units to any of them - no one reading an article like praseodymium(III) chloride would expect anything non-metric. There must be tens of thousands of articles like this. If an article is likely be read by a non-scientist (e.g., sulfuric acid), it may be appropriate to include some non-metric units, but that's what the "consensus" part allows for IMHO. (I presume that was what was meant by the "scientific vs highly scientific" distinction above.) Walkerma 04:18, 26 August 2007 (UTC)
Like Walkerma says, this has been the de facto rule for years anyway. This is just a tempest in a teapot. In some cases, especially for "popular science" topics, conversions may help. But in others they are utterly unnecessary. Use editorial discretion/common sense/consensus on a case-by-case basis. --Itub 06:44, 26 August 2007 (UTC)
- I agree perfectly; and this page is the teapot. The entire MOS is a guideline; consensus can ignore it whether MOS approves or not. The only reason it's worth making sense out of it is that bullies behave as though the MOS came down from Mount Sinai, and become obnoxious citing it. Septentrionalis PMAnderson 17:26, 26 August 2007 (UTC)
In scientific articles, priority order should be the standard units of the domain (for instance, eV instead of J in nuclear physics, parsec in astronomy, etc.) then the SI system (if universally used in the domain), then the different non-standard commonly used units with conversions (for instance, who would use Kelvin degrees in meteorology? In such a context it would probably preferable to present values both in °F and °C). It seems to me that the problem in Science is different from Imperial vs Metrics, that it will not only appear in the 'English language' context only and that it would be solved by easy consensus on any real example. pom 16:59, 26 August 2007 (UTC)
- I support the change, especially since this is often the case now. Scientific articles should be written differently, and different standards should apply. CRGreathouse (t | c) 20:34, 26 August 2007 (UTC)
I'll support this. However, conversions seem to be one of those inputs that people like to insert (at least in astronomy articles). So it may be difficult to "enforce" consistently. — RJH (talk) 20:35, 27 August 2007 (UTC)
- I pretty much agree with Jim77742's comment some way above: Any article that is remotely scientific should not have imperial units.... Except, I'd say, to the degree that it's historic and quotes texts or remarks in which the units were originally given in an old system. And here, antique anglophone units needn't be privileged over any other (degrees Réamur, etc).
- Quite aside from science, WP's "accessibility" measures for people in/from the US (or Liberia or Burma?) often seem grotesque. Take Borobudur, for example.It's littered with conversions from metric (though we're told that a seven-year restoration project cost 6,901,243 USD of the time, period). Never having lived in the US or Burma, and never having even visited Liberia, I'm unfamiliar with the correlation there of (a) familiarity with the metric system with (b) curiosity about other cultures. But somehow I find it hard to imagine that those people who want to read about Borobudur wouldn't know their way around metres. (Tip: multiply by three and call them feet; tip for elderly Brits: don't multiply at all and call them yards. Bonus: If you encounter "tonnes", call them tons.) Yet metres are repeatedly translated for the reader. True, conversion can get slightly more complicated with areas and volumes. My favorite snippet from the article: Approximately 55,000 m^(3) (almost 2 million cubic feet) of stones were taken from neighbouring rivers to build the monument. Yes, complete with that link: So it's acknowledged that readers might need help to understand the helpful "cubic feet" translation.
- And therefore I'd provide a third exception. A first stab at phrasing this would be articles that are about places, people, things or events outside the US, Burma or Liberia, and whose main text includes numerous measurements, where there is consensus among the contributors not to convert the metric units. -- Hoary 23:57, 27 August 2007 (UTC)
- Hoary, this is a radical step compared with the proposal at hand, which concerns only scientific articles. I am almost certain it wouldn't gain consensus; in any case, it cuts across the scientific criterion (what scientific topics '"don't concern things outside Burma, Liberia and the US?). I'm uncomfortable about the specification of "places, people, things or events". And what is "numerous" is unclear, and I don't think numerousness is a reasonable criterion once editors agree that an article is "scientific". Tony 11:37, 28 August 2007 (UTC)
Support the proposal by Tony. Lightmouse 16:11, 28 August 2007 (UTC)
Support the proposal by Tony. Jim77742 10:17, 29 August 2007 (UTC)
Summary and conclusion
YES:
- Tony1 (local consensus, scientific classification, and the linking of the first occurrences are sufficient safeguards)
- SamBC
- Wikidmo (already de-facto rule)
- Lightmouse (US already partly metricated inter alia)
- Jim77742
- PaddyLeahy (already the de facto position for many/most science articles)
- Colin (often conversions are unhelpful and don't improve accessibility)
- Tim Vickers (it's what we do already)
- Cheeser1
- SandyGeorgia (as long as for science alone and by consensus)
- Walkerma (de facto standard already)
- ltub (has been the de facto rule for years; conversions may help in pop science articles)
- CRGreathouse (often already the case; different standards apply to scientific articles)
- RJH (but fears hard to "enforce" consistently)
- Hoary (however, proposed more radical pro-metric change)
APPEAR NOT TO OBJECT:
- Count Iblis (metric preferred; queried use of SI units in WP)
- Septentrionalis (appropriate for some articles to use metric alone)
- pom (use standard units of the scientific area)
NO:
- MJCdetroit (fears slippery slope to total ban of imperial units, and overly broad interpretations of scientific)
- Allen3 (will reduce usability for no functional improvement)
- Rmhermen (lack of metric understanding in US)
- PatLeahy (very few cases where not converting is better)
- SMcCandlish – I object to most of the rationales raised: US students are aware of metric units enough that they know a cm is kinda like an in., a liter is kinda like a qt., and a km is kinda like a mi., and that's about it - they have not internalized them in any meaningful way with the possible exception of the liter due to soft drink bottles; the US military emphatically does not exclusively use the metric system, though it is using it more and more (I grew up in two military families, on both the officer and enlisted side, and bunch of my social circle are still miltary); US Latinos did not grow up with metrics any more than any other ethnicity here did, since we all used the same school system (I live in a 70% Hispanic area, and not a single Latino I know uses the metric system in ways that any other American would not); and finally, no one actually bothers putting links to metric (or most other) units at first occurrence, and some even revert them, so that is red herring. I agree on the science article points, and agree with some elements of the proposal, but not all of it, nor with the basis for the "package deal". — SMcCandlish [talk] [cont] ‹(-¿-)› 01:43, 15 December 2007 (UTC)
Fifteen editors have declared support, many of them American and some in favour of a more substantial change; three more appear not to object. Four Five are opposed. The participation on opposite sides of a PaddyLeahy and a PatLeahy is strange, but I take it at face value.
Although this is not a raw vote, an 18–45 margin is significant. IMV, the "de facto already" argument is substantive, and I believe that there are sufficient safeguards to allay the fears of those who are uneasy about the change. Unanimity would have been desirable, but I think that WPians would generally consider that this represents reasonable consensus in favour of the proposal.
Unless the situation changes dramatically, I'll implement the change at MOSNUM and MOS next Saturday, after eight days. Tony 13:04, 30 August 2007 (UTC)
- Although I disagree with user:MJCdetroit in general – i.e. I support metric-only with the exception of defining source units –, I indeed consider all artices that are (or, rather, should be) in Wikipedia to be scientific, because science is not just physics and chemistry.
- (By the way, there is no justification for the use of imperial units in WP at all, where they differ from their US counterparts.) Christoph Päper 13:54, 30 August 2007 (UTC)
- Yes, imperial units are obsolete. Disagree on the semantics about "scientific"; Tony clearly means "articles about science", not "articles written based on established facts instead of supposition". "Science" != "scientific". — SMcCandlish [talk] [cont] ‹(-¿-)› 01:43, 15 December 2007 (UTC)
- I think this change is too radical to make without an RfC, as this would affect hundreds of thousands of articles in a significant way, and the wider WP community isn't expecting "sumbarine" changes from MoS, which is supposed to be stable and reliable and unsurprising. The scope of the effects of such a change is far too wide for a "consensus" of less than 3/4 of a mere 23 editors to make it. A bit like only 23 members of the US Congress showing up to vote, and deciding 18-5 that the US henceforth will officially use the metric system. NB: I have nothing against the metric system (it does make more sense), but we are in transitional generations in the US (the bulk of the en.WP readership by probably at least an order of magnitude), where even if we have a notion of what a particular metric unit is, we have no "feel" for it. The average American cannot even vaguely accurately visualize how far away 87 km is or how big something is if it is described as 87cm tall, but they know exactly how long it takes, given favorable conditions, to drive 87 mi. and that 87 in. is just over 1.5 ft. taller than they are if they are 6 ft. talk as in my case, without even having to think about it. (And no I don't do "ft." with a period in articles; I'm not bound by the MoS on talk pages. >;-) — SMcCandlish [talk] [cont] ‹(-¿-)› 01:43, 15 December 2007 (UTC)
The convert template and MOS
There is a bot going around removing {{convert}} templates from articles due to it causing performance problems. See here. Epbr123 07:44, 31 August 2007 (UTC)
- Does it remove the conversion completely? Does this have a bearing on our discussion here? Tony 10:46, 31 August 2007 (UTC)
- Sorry, your highness. Please don't hit me. This seemed the best section to mention it. Epbr123 11:54, 31 August 2007 (UTC)
- Oh, :-( didn't intend to be bossy—sorry, it's the brevity of the wording that appears so. First question related to my concerns over that template (hard to make it comply with MOS); second question of concern to the process here. Tony 12:38, 31 August 2007 (UTC)
- Sorry. The bot coverts "{{convert|10|mi|km|1}}" to "<span style="white-space:nowrap">10 miles (16.1 km)</span>". I'm not certain how it would effect the issues in this discussion, but if users are disuaded from using the convert template, it may discourage some users from adding equivalents due to the extra work in having to convert the units themselves. Also, if users had to convert the units themselves, this may lead to inaccurately calculated equivalents. Epbr123 12:52, 31 August 2007 (UTC)
- The convert template either needs technical fixing or much clearer instructions on how to use it. I've seen examples of MOS breaches from its use, and I'm hoping the experts can work out why this is happening. Tony 13:58, 31 August 2007 (UTC)
- Sorry. The bot coverts "{{convert|10|mi|km|1}}" to "<span style="white-space:nowrap">10 miles (16.1 km)</span>". I'm not certain how it would effect the issues in this discussion, but if users are disuaded from using the convert template, it may discourage some users from adding equivalents due to the extra work in having to convert the units themselves. Also, if users had to convert the units themselves, this may lead to inaccurately calculated equivalents. Epbr123 12:52, 31 August 2007 (UTC)
- Oh, :-( didn't intend to be bossy—sorry, it's the brevity of the wording that appears so. First question related to my concerns over that template (hard to make it comply with MOS); second question of concern to the process here. Tony 12:38, 31 August 2007 (UTC)
- Sorry, your highness. Please don't hit me. This seemed the best section to mention it. Epbr123 11:54, 31 August 2007 (UTC)
The bot has been grounded, apparently indefinitely. Epbr123 may be encouraged to see how my implementation of the convert template corrected the inaccurate equivalents in TT Circuit Assen. This article was a poster child for the template on 3 counts: conversions were needed both ways (and you can't blame the Americans for this one) because records were kept in mph and then in kph; the conversions had been done incorrectly; MoS was not followed. Chris the speller 16:23, 31 August 2007 (UTC)
- I have some comments, I am a *major* user of the convert template in my monobook metrication script.
- 1. I don't much care *how* articles are metricated, as long as it is done widely and correctly. I see nothing wrong in principle with the convert template, plain text conversion, or editors switching between them.
- 2. I am not aware of how the template affects performance and would welcome specialist debate on that.
- 3. Wikipeda text in edit mode is becoming less accessible to the novice. That is a bad thing. I understand the motivation to go back from templates to plain text. I use the template purely because of its convenience to add metric units where none exist.
- 4. The bot doing plain text conversion makes excessive use of 'nowrap' and 'nbsp'. The convert template does too. Line breaks *should* be permitted between metric and non-metric units. Line breaks *should* be permitted between each of the following words: 'seventeen', 'square', 'miles'. The 'nbsp' is another instance of the Wikipedia movement away from simple-to-read plain text. Personally, I would remove/downgrade/caveat the nbsp recommendation from the MOS for all but tables. In body text, the comparatively rare instance of the disease is preferable to the cure.
- 5. Incidentally Chris, the symbol is not 'kph', it is 'km/h'. My monobook corrects that (plus 'kmph', 'km/hr' and other symbolic no-no's). I suppose a good thing about the template is that it guarantees that text gets the correct symbol.
- I recommend people look at my monobook metrication script. Feel free to use it or copy the code for yourself. Thanks to Epbr123 for bringing it here. However, debate about the merits of the template versus plain text probably belong on the template talk page. Lightmouse 18:07, 31 August 2007 (UTC)
- So where's the "how to use it for dummies" page, so I can test whether it does hyphens, ranges, abbreviations, singular/plural and appropriate decimal places, as required by MOSNUM? My problem with convert templates is that they take a lot of learning to get all of these things right, so most editors are better off doing it manually with a calculator (if you can't get simple calculations right, don't edit, or get someone else to check it for you) Tony 01:32, 1 September 2007 (UTC)
- With regard to your first sentence, I am not able to answer those questions. Perhaps people on the talk page can. With regard to your second sentence, I agree with you. This debate is now taking place in three places, can we move non-MOS debate about the template to the template talk page please ? Lightmouse 10:51, 1 September 2007 (UTC)
Improve Extension:UnitsFormatter to solve English WP problems with units! 62.226.129.156 (talk) 11:21, 24 November 2007 (UTC)
Natural numbers
We should not be proscribing natural number; it's idiomatic in both fields concerned. Furthermore, there are cases, such as the construction of the integers out of the naturals, where substituting some form of integer is simply, if subtly, wrong. Septentrionalis PMAnderson 22:35, 25 August 2007 (UTC)
- So why not slow down this wagon and wait a day or two, or three? Then you can change it with greater likelihood of "consensus". Tony —The preceding signed but undated comment was added at 01:19, August 26, 2007 (UTC).
- Because we should not have open error; and the existence of the error is uncontroversial among those who know the subjects concerned. (It is quite glaring from my point of view; but there are those who regard all mathematics as subtle). Septentrionalis PMAnderson 17:15, 26 August 2007 (UTC)
- I must disagree with my esteemed colleague, Septentrionalis; constructing the integers from integers is not subtly wrong, but dramatically wrong. I do agree that the natural numbers are far too important to "write around", as any competent mathematician is expected to know. That's one reason they have their own Unicode code point, U+2115 (a double-struck capital "N"). And I regret to note that the first sentence of our article is misleading: Often the natural numbers are taken to be a model of the Peano axioms, augmented with addition, multiplication, and ordering; we have an algebraic structure, not just a set, contrary to the lead sentence.
- The best resolution is to remove the section; either to say nothing, or leave it to the mathematics manual of style. It is dangerous instruction creep. (If a surgeon needs directions for how to tie off a suture, that surgeon has no business cutting anyone open!) If the consensus is to keep it in spite of my recommendation, it should be reworded as follows:
- The set of natural numbers has two common meanings: {0,1,2,3,…}, which may also be called non-negative integers, and {1,2,3,…}, which may also be called positive integers. Use the sense appropriate to the field to which the subject of the article belongs if the field has a preferred convention. If the sense is unclear, and if it is important whether or not zero is included, consider using one of the alternative phrases rather than natural numbers if the context permits.
- A less awkward wording might be possible, but this cannot be safely abbreviated. For example, we cannot eliminate the phrase "set of", because substitution should not be done for the algebraic structure. We cannot eliminate the word "common", because we have other meanings as well. We do not want to encourage a computer science convention in a number theory article. And so on.
- What are the chances this will be read and understood? (Slim.) Do even the brilliant and highly educated readers of this talk page appreciate the fine points? (Probably not.) If we can't say something helpful for a general audience — and I don't think we can — then we should say nothing. --KSmrqT 09:46, 26 August 2007 (UTC)
- I support removing the paragraph. The concept of naturals precedes the one of integers. Naming the former in terms of the latter is philosophically wrong. −Woodstone 10:47, 26 August 2007 (UTC)
- On the other hand, "a prime is a positive integer which..." is a reasonable phrasing. If the writer is thinking of the primes as a special case of prime ideals in rings, it is natural. (No pun intended.) Septentrionalis PMAnderson 17:15, 26 August 2007 (UTC)
- I support removing the paragraph. The concept of naturals precedes the one of integers. Naming the former in terms of the latter is philosophically wrong. −Woodstone 10:47, 26 August 2007 (UTC)
Direct quotes aren't linked?
A silly and unhelpful rule; sometimes a direct quote, like
- "Whether a little farmer from South Carolina named Tillman is going to rule the Democrat Party in America - yet it is this, and not output, on which the proximate value of silver depends."
contains a proper name which should be linked to so the reader can tell who we're talking about without looking up our source. Please tell me where we put that piece of unhelpful nitpicking so I can go object to it. Septentrionalis PMAnderson 23:49, 25 August 2007 (UTC)
- I strongly agree with the principle; if you link something in a quote you may be changing the intended context or interpretation. WP:MOSLINK#Quotation Altering this guidelie is a slippery slope, and you never know what garbage may be written into the article you link and how that will reflect on the original quote. SandyGeorgia (Talk) 23:56, 25 August 2007 (UTC) Example, you could link to Tillman today, and someone could change it to dab page tomorrow. SandyGeorgia (Talk) 23:56, 25 August 2007 (UTC)
- Both of Sandy's arguments work against linking at all; they have no greater force against links in quotations than elsewhere. She may wish to rephrase the second: this is a piped link to Ben Tillman, who is certainly the primary use of that name. Septentrionalis PMAnderson 17:19, 26 August 2007 (UTC)
By the way, this is edit warring taken to a pathetic extreme. Please remove and discuss. We can't have different MOS pages contradicting each other. SandyGeorgia (Talk) 00:02, 26 August 2007 (UTC)
- Manderson, you're trying the patience of people here, and making the page look unstable. Do what polite, cooperative contributors do: raise all but copy-editing changes here first. Otherwise, I'm not going to bother sorting out your edits—I'll just revert them all as being generally in bad faith. Tony 00:58, 26 August 2007 (UTC)
- Thank you for documenting your intention to revert war.Septentrionalis PMAnderson 17:05, 26 August 2007 (UTC)
Regarding conversions in quotations, how about using the good-old square brackets? For example, 'John Doe said, "I ran six miles [10 km] today!". --Itub 06:48, 26 August 2007 (UTC)
- Thanks; that's in my first green example above. Tony 07:45, 26 August 2007 (UTC)
- It changes emphasis at least as much as wikilinking, and does not help in the example cited; the software will make it [[[Ben Tillman]]]. Septentrionalis PMAnderson 17:05, 26 August 2007 (UTC)
- I was not talking about links, but about conversions, because that was the context where the edit in question occurred. Square brackets are commonly used for clarifications in quotations, and I think that adding a conversion could be a legitimate use. --Itub 08:36, 27 August 2007 (UTC)
- I agree completely. As above, with the use of only metric units in some articles, this should be a matter of editorial discretion. Septentrionalis PMAnderson 15:07, 27 August 2007 (UTC)
- I was not talking about links, but about conversions, because that was the context where the edit in question occurred. Square brackets are commonly used for clarifications in quotations, and I think that adding a conversion could be a legitimate use. --Itub 08:36, 27 August 2007 (UTC)
- I think that the general rule that links should be avoided in quotations is a good and important one. Sometimes there is need for clarification, and links perhaps should be used at such times, but very sparingly. If the surrounding context can make the meaning clear there should be no linking in the quote. Otherwise, it may be the least evil. CRGreathouse (t | c) 12:21, 27 August 2007 (UTC)
- I agree with this too; linking in quotes should be done with extreme caution; but it is one solution to a difficult if minor problem. Septentrionalis PMAnderson 15:07, 27 August 2007 (UTC)
- I think the rule should stay - but occasionally be ignored. The few times I have done this it tends to survive later edits. I would only do so if the alternative is a new sentence after the quote to allow insertion of a link.Johnbod 15:32, 27 August 2007 (UTC)
- A reasonable test. Perhaps it should be added to WP:MOS (links), as guidance. Septentrionalis PMAnderson 15:57, 27 August 2007 (UTC)
- So, CRGreathouse, do you have an example up your sleeve of a rare instance where a link within a quotation is necessary or desirable? Tony 11:27, 28 August 2007 (UTC)
- I'm not really a good one to ask -- I always remove links from quotes, and have never added one. I only concede the possibility. CRGreathouse (t | c) 16:36, 28 August 2007 (UTC)
- Without an example, it's hard to conceive why the existing policy text needs to be changed. Tony 00:54, 29 August 2007 (UTC)
- Of course I don't mind leaving it -- I just didn't want the more extreme version suggested by PMAnderson. CRGreathouse (t | c) 19:17, 29 August 2007 (UTC)
- Without an example, it's hard to conceive why the existing policy text needs to be changed. Tony 00:54, 29 August 2007 (UTC)
- I'm not really a good one to ask -- I always remove links from quotes, and have never added one. I only concede the possibility. CRGreathouse (t | c) 16:36, 28 August 2007 (UTC)
- So, CRGreathouse, do you have an example up your sleeve of a rare instance where a link within a quotation is necessary or desirable? Tony 11:27, 28 August 2007 (UTC)
- A reasonable test. Perhaps it should be added to WP:MOS (links), as guidance. Septentrionalis PMAnderson 15:57, 27 August 2007 (UTC)
- I think the rule should stay - but occasionally be ignored. The few times I have done this it tends to survive later edits. I would only do so if the alternative is a new sentence after the quote to allow insertion of a link.Johnbod 15:32, 27 August 2007 (UTC)
- I agree with this too; linking in quotes should be done with extreme caution; but it is one solution to a difficult if minor problem. Septentrionalis PMAnderson 15:07, 27 August 2007 (UTC)
Units on Astronomy Pages
On the page Goddard High Resolution Spectrograph there has been some thrashing on the units. I'm not an astronomer, but I do work with them and from what I've seen, for that instrument, Angstroms is probably the best choice - they're commonly used for UV and visible light astronomy. IR folks tend to use microns. I don't know about the radio folks. Dfmclean 01:27, 28 August 2007 (UTC)
- As for Angstrom, it has a 10:1 relationship with nano-metres (nm) so the conversion back is easy. anon 2007-08-30 16:45 UTC —Preceding unsigned comment added by 81.179.154.116 (talk)
- What puzzles me is how you measure resolving power in km/s. Doppler effect? But if so, you should say so. WikiProject Physics is more likely to find a radio astronomer than here. Septentrionalis PMAnderson 01:45, 28 August 2007 (UTC)
- Uh, there has been one edit and a revert by me, hardly 'thrashing'. Optical astronomy universally uses angstroms, so we should stick with them. Furthermore, the source lists the numbers in angstroms. IR uses microns (mostly) and radio usually quotes in frequency, so GHz and MHz. Yes the resolutions are quoted in km/s due to the doppler effect (hence they are quoted for a given wavelength), because that's one of the main things high resolution spectrographs are used to measure. I'd pull out the manual and grab some more details, but I doubt anyone is going to be that interested in an obsolete spectrograph that is no longer working! Oh and a quick disclaimer: I'm an optical/IR astronomer who has also worked on a radio telescope.
- Oh and final thought, perhaps there should be a wikiproject astronomy page on units? Modest Genius talk 14:38, 3 September 2007 (UTC)
Really necessary to have a template showing all units of length?
Please look at the use of Template:Unit of length. Somebody apparently believed it was necessary to have a template showing all units of length in terms of ångströms, astronomical units, light years, inches etc. It seems a bit silly to me. From a metric readers point of view, it is just weird. It may derive from the no-longer-amusing joke about furlongs-per-fortnight but Wikipedia articles are not supposed to be internet jokes. The template assumes readers of the kilometre article need to know how many ångströms it contains. Similarly the reader of the millimetre is supposed to be interested in how many light years it is. I would not mind if this silly template were confined to one or two articles, but it has been put on lots.
Please comment at Wikipedia:Templates_for_deletion#Template:Unit_of_length
Lightmouse 15:59, 28 August 2007 (UTC)
- Yes, but the template also tells you how many feet are in a kilometer. It's blatantly obvious that this is useful information. --JayHenry 21:06, 28 August 2007 (UTC)
- Blatently obvious information like that is already in the articles. A fixed template that includes obscure or unlikely conversions makes it not useful. Lightmouse 21:21, 28 August 2007 (UTC)
- Yep, I'd like examples of where some of these obscure unit conversions are useful to justify their retention. Tony 00:55, 29 August 2007 (UTC)
- Oh I agree with that. I'm not arguing to keep the conversion to ångströms, that's a matter for template talk though. Anyways, it's all a discussion at TFD for now, sorry for cluttering things here with it. Cheers! --JayHenry 01:20, 29 August 2007 (UTC)
Links vs. <font color=darkblue>
First of all, I fail to see how using links, with pipes to make sure it shows what is in fact displayed, is bad. There are several problems with the previous markup - for one thing, it doesn't look like a link even in the default theme (real link color is much brighter blue), and the whole point of having it in any color at all is to simulate a link. Second, it won't change if someone has different CSS, say, in the worst case, what if they have a dark blue background and white text? the "links" will be invisible then. But even if they simply have a different color (gray, green, whatever) for links, it won't match. Also, <font> is a bad tag regardless - and whoever made this seems to think the closing tag is </font color>. These are the reasons I made this change, and I think it should stand. --Random832 23:52, 30 August 2007 (UTC)
- I changed the color from "darkblue" to "blue". I suppose a cleaner version would be to set the style so that it would display as if it were a link, but I don't think we want real links. As for </font color>, in some HTML versions, </font color> doesn't end a <font size>, but only a <font color>. I don't know if that's correct HTML, but it seems to work. — Arthur Rubin | (talk) 13:57, 31 August 2007 (UTC)
- That's not how HTML works. There is no, and there has never been any, html version where there are separate "font size" and "font color" tags. Can you explain why we don't want real links? They don't do any harm, and they're the only thing guaranteed to display the same as links on everyone's system (what if I have links underlined? what if I have a stylesheet that makes "blue links" red and "red links" orange?) - can you explain your objection to my change in the first place, and why you reverted it? Regardless of whether a font color tag is an adequate solution, I don't see what's wrong with having them as links. Why don't you think we want real links? It's possible that whoever made the markup that way didn't realize pipe links were a solution so thought he/she needed to make fake links w/ font color tags to get around the autoformatting (since, obviously, we _don't_ want autoformatting here) --Random832 17:17, 31 August 2007 (UTC)
- I would favour the use of links, so that they appear exactly as they would under the relevant preferences. SamBC(talk) 19:01, 31 August 2007 (UTC)
- Are you sure that the pipe links won't be autoformatted in future versions of the Wikimedia software, or automatically removed by reformatting bots? Thinking it over, the real links don't hurt, other than those problems. — Arthur Rubin | (talk) 19:42, 31 August 2007 (UTC)
- Well, I'm sure that if that happens it'll be noticed pretty quickly and worked around again. If there's no problem now (as in the case of autoformatting) or only a worry that there might be a problem (as in the case of bots), then I'd say it makes sense to go ahead, rather than worrying about hypotheticals. SamBC(talk) 19:49, 31 August 2007 (UTC)
- Are you sure that the pipe links won't be autoformatted in future versions of the Wikimedia software, or automatically removed by reformatting bots? Thinking it over, the real links don't hurt, other than those problems. — Arthur Rubin | (talk) 19:42, 31 August 2007 (UTC)
- I would favour the use of links, so that they appear exactly as they would under the relevant preferences. SamBC(talk) 19:01, 31 August 2007 (UTC)
- The correct closing tag to both is </font>. And the best way to implement such a thing is with an inline CSS style, not the deprecated (read: valid but bad) <font> tag. Now, what exactly are we talking about? — Aluvus t/c 05:13, 2 September 2007 (UTC)
- Yeah, I'm not following this either (other than your accurate corrections of the HTML issues). The idea of creating fake links strikes me as very "user-hateful", but maybe I'm missing something here... — SMcCandlish [talk] [cont] ‹(-¿-)› 10:58, 8 December 2007 (UTC)
- That's not how HTML works. There is no, and there has never been any, html version where there are separate "font size" and "font color" tags. Can you explain why we don't want real links? They don't do any harm, and they're the only thing guaranteed to display the same as links on everyone's system (what if I have links underlined? what if I have a stylesheet that makes "blue links" red and "red links" orange?) - can you explain your objection to my change in the first place, and why you reverted it? Regardless of whether a font color tag is an adequate solution, I don't see what's wrong with having them as links. Why don't you think we want real links? It's possible that whoever made the markup that way didn't realize pipe links were a solution so thought he/she needed to make fake links w/ font color tags to get around the autoformatting (since, obviously, we _don't_ want autoformatting here) --Random832 17:17, 31 August 2007 (UTC)
Metric conversions of knots and nautical miles
Although the SI system is used worldwide for most applications, it certainly seems that nautical distances and speeds are still referred to almost exclusively in terms of nautical miles and knots. It seems unnecessary to convert knots to km/h and nautical miles in every instance. Ranges for guns are often expressed in metres or yards, but longer distances are usually nautical miles, and even sources that use kilometres for these distances use knots to represent the speed. Whether this is logical may be debatable, however, it is the standard of many sources. Almost any source for information on warships uses the knot standard. Sacxpert 19:39, 1 September 2007 (UTC)
- Nautical and ordinance measurements should be converted to metric equivalents so that people not familiar with knots can easily appreciate the facts presented.
- I was very tempted to respond to this by suggesting scientists who use metric should learn knots so that they can understand nautical articles. I fear that the recent exception to conversions for scientific articles has created precedence which will encourage more of these proposals. I hope we don't end up with articles which are only accessible by people already familiar with the subject area. -- PatLeahy (talk) 19:56, 1 September 2007 (UTC)
- I'm perfectly comfortable with SI measurements, but I do not convert in several cases:
- Only a traditional measurement is stated within a legal document, especially one under UN or other auspices where it is reasonable to assume that metric-oriented people have had substantial involvement in the text
- Where a traditional measurement is nominative, as the "10 yard line" or "100 meter dash" is customary in a sport
- In cases where several traditional measurement types have a specific interrelation, such as knots, nautical miles, and minutes of latitude
- The BIPM, which is the international authority on SI, includes "knots" as one of a number of non-SI units that will be acceptable within the SI system. Howard C. Berkowitz 20:13, 1 September 2007 (UTC)
- I'm perfectly comfortable with SI measurements, but I do not convert in several cases:
- I would point out that knots and nautical miles are still commonly used in aviation as well. Still, I see no problem with providing metric conversions in parentheses following their use. Askari Mark (Talk) 20:31, 1 September 2007 (UTC)
- Yes, they are "common in aviation". They are not, however, universal in aviation, and how common they are varies in different contexts within aviation (indicated air speed, wind speed in weather reports, military vs. civilian, nationality, etc.). Some in aviation do use SI units, and most Wikipedia readers are not involved in aviation: SI conversions should be included. Gene Nygaard 18:40, 13 October 2007 (UTC)
- Furthermore, statute miles are also "common" in aviation, especially in most contexts before the middle of the 20th century, in others before the last quarter of the century, and in others continuing until the present. Whenever "miles" are used in an aviation context, it is important to specifically identify them as either statute or nautical. 18:48, 13 October 2007 (UTC) —Preceding unsigned comment added by Gene Nygaard (talk • contribs)
- Following this train of thought, can anyone tell me why NASA use nautical miles to measure height? Thunderbird2 18:58, 13 October 2007 (UTC)
- Just in a negative sense. It's not because anybody else in aviation or space uses nautical miles to measure vertical distances. Gene Nygaard 19:53, 13 October 2007 (UTC)
- And continuing on the what-it's-not train, it's not because they are following the recommendations of their own Inspector General following the Mars Climate Crash-Lander, to stick to SI units. Gene Nygaard 19:59, 13 October 2007 (UTC)
(outdent)
In the continuing "edit feuding" over knots and nautical miles, I've noticed some curious abbreviations being touted. For what it's worth, "knots" is most commonly abbreviated "kt" (not "kn"), and "nautical miles" as "nm" – and these are both widely used on Wikipedia. I haven't changed the recent edits, since I think it proper to first develop consensus that "kt" and "nm" are best usage. Askari Mark (Talk) 01:15, 3 September 2007 (UTC)
- I'd definitely agree that kt for knot is probably best usage (although it is similar to kT, which is short for kiloton-TNT-equivalent). I've certainly seen "nm" for nautical mile, but the problem is that nm is also the symbol for nanometre, one thousand-millionth of a metre. Granted, it's unlikely that anyone would confuse the two, but perhaps "nmi" is more precise? According to Wikipedia's own article on nautical miles: "There is no official international standard symbol for the unit nautical mile. The symbols M, NM, nm, and nmi are commonly used in some areas." Of those, it seems that nmi is probably best, to avoid confusion, even if nm is common. Sacxpert 01:25, 3 September 2007 (UTC)
- Sacxpert, you make good points. "kt" seems safe enough since it would be rare to use explosive yield in a context of speed. Kinetic energy weapons are a fairly bizarre edge case, and their energy is often specified in joules. I can certainly live with nmi, if for no other reason than avoiding confusion with nanometers. Howard C. Berkowitz 02:41, 3 September 2007 (UTC)
- The template {{convert}} uses nmi as the abbreviation already. I'm surprised no one mentioned Nm (Newton meters) above. MJCdetroit 03:21, 3 September 2007 (UTC)
- Actually, I was going to. :-) Also, I’ve never seen “M” for nautical miles. Actually, I’ve never seen “nmi” used either; “n.mi.” or “n. mi.”, but not run together. In any case, I have no problem with opting for “nmi”, although “nm” has come to be the modern preference, but if people really think it’s likely to be mistaken for nanometer (which would seem to be most unlikely IMO), then nmi would be okay by me (though less preferable) … although there are a lot of extant “nm” to change. Askari Mark (Talk) 03:34, 3 September 2007 (UTC)
- To be fully honest, I prefer nm to nmi, but I will accept either if that will end the conversion wars in nautical articles and let me focus, again, on content. I would worry very much about someone that measured fishing vessel positions in nanometers. Howard C. Berkowitz 04:12, 3 September 2007 (UTC)
- The IEEE guidelines for authors are clear one this: "nmi" for the nautical mile and "kn" for the knot. The guidelines are generally followed in scientific literature. There is a separate discussion on each at SHIPS. Thunderbird2 17:04, 7 September 2007 (UTC)
- But other authorities differ in both regards, and our standard on Wikipedia is "kt" for knots, explicitly decided on after considerable discussion in the aviation WikiProject, for example. Note also that when it comes to tons, the symbol "kt" should only be used for units of mass, not for units of energy. If we insist on both "kt of TNT" (or "Mt of TNT" when appropriate) when those energy units are used, always, not kt alone, and a conversion to joules when those non-SI units are used, then there is little chance of confusion. A bigger problem with tons, of course, is that the t is ambiguous, being used for both long tons and short tons as well as metric tons. If I had my druthers, we'd have an all-megagrams (gigagrams, teragrams, etc.) encyclopedia! Gene Nygaard 10:20, 17 October 2007 (UTC)
- Forgot to mention that we have very, very few (if any) articles using "kt" as mass units. Hardly anybody uses "kilotons" or "megatonnes" or whatever outside the TNT-equivalent units of energy context; otherwise it is "thousands of metric tons" or "million tons" or "million tonnes" and the like. I don't hear anybody say that Algeria made a deal to "buy 2.5 megatons" of wheat from the U.S., for example, but rather they "buy 2.5 million tons" or whatever precise amount[1] [2] of wheat. (Adding mega- would be clumsy if the U.S. name "metric tons" were used in this context; we'd have people arguing for a hyphen and others insisting on an en dash in mega–metric tons, or whatever. Even adding "million" is clumsy, that's one reason why it is often just "million tons".) Sure would be simpler, and get rid of the ambiguity, if the world's grain traders would start referring to this quantity as 2.5 teragrams. Gene Nygaard 10:52, 17 October 2007 (UTC)
- But other authorities differ in both regards, and our standard on Wikipedia is "kt" for knots, explicitly decided on after considerable discussion in the aviation WikiProject, for example. Note also that when it comes to tons, the symbol "kt" should only be used for units of mass, not for units of energy. If we insist on both "kt of TNT" (or "Mt of TNT" when appropriate) when those energy units are used, always, not kt alone, and a conversion to joules when those non-SI units are used, then there is little chance of confusion. A bigger problem with tons, of course, is that the t is ambiguous, being used for both long tons and short tons as well as metric tons. If I had my druthers, we'd have an all-megagrams (gigagrams, teragrams, etc.) encyclopedia! Gene Nygaard 10:20, 17 October 2007 (UTC)
- The IEEE guidelines for authors are clear one this: "nmi" for the nautical mile and "kn" for the knot. The guidelines are generally followed in scientific literature. There is a separate discussion on each at SHIPS. Thunderbird2 17:04, 7 September 2007 (UTC)
- To be fully honest, I prefer nm to nmi, but I will accept either if that will end the conversion wars in nautical articles and let me focus, again, on content. I would worry very much about someone that measured fishing vessel positions in nanometers. Howard C. Berkowitz 04:12, 3 September 2007 (UTC)
- To MJCdetroit: newton (that's lowercase n) meters are only a problem on Wikipedia links, and here only for two reasons: 1) because some Wikipedia editors fail to include the requisite space or centered dot in N m or N·m, and 2) because initial capitalization is turned on in English Wikipedia, so links to Nm and to nm go to the same place. I've never seen anybody use an uppercase N and a lowercase m for nautical miles, so there is unlikely to be any problem in what people read, and a bad link only takes them to the disambiguation page. Gene Nygaard 20:06, 13 October 2007 (UTC)
Frequency of conversions
Another point: within an article, is there any consensus on how frequently a metric/Imperial conversion should be made? Consider the following: in an article is written about a subject using the metric system, the same numbers might be brought up again and again (for example, gun characteristics in an article about a European battleship). It seems excessive and distracting to repeatedly convert the same number in one article. Isn't it sufficient to convert any particular metric number to Imperial once in the article, once in the infobox, and leave it at that? The same rule would apply to articles about subjects using the Imperial system. The conversion is spelled out for anyone who wants to know, but it needn't intrude every single time the same number is mentioned -- people should be able to remember that 38.1 cm (15") -- or vice-versa -- over the length of a reasonable-length article. I apologise if this issue has already been raised and resolved. Sacxpert 20:00, 1 September 2007 (UTC)
- Yes, it is a clutter, and no, it hasn't been resolved. I would think they should be used chiefly only when the unit is first used in an article, and on all characteristics in a Specifications section, if there is one. As for infoboxes, the associated WikiProject should determine the defaults; I don't think a narrow infobox is the right place to cram in conversions. Askari Mark (Talk) 20:38, 1 September 2007 (UTC)
- I agree—it's worth including this. What about this wording, as a third exception to the "generally provide conversions" rule?
- Conversions to and from metric and imperial/US units are generally provided. There are
twothree exceptions:
- scientific articles 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;
- where inserting a conversion would make a common expression awkward (“The four-minute mile”);
- subsequent appearances of exactly the same value and unit in an article, where a repetition of the conversion appears to be unnecessary.
Tony 06:35, 2 September 2007 (UTC)
- I oppose a guideline limiting a conversion to one per article. Some articles have multiple values of multiple units (square feet, gallons, acre feet, acres, 'cfs', 'fps' 'bcf', 'bbl'). Metric readers should not be given memory work to read an article just because non-metric/domain-specialist readers feel uncomfortable/unfamiliar with multiple metric conversions. I think it would be difficult to come up with a reasonable guideline, nor do I think one is necessary. Lightmouse 10:22, 2 September 2007 (UTC)
- I agree with Tony on his proposal. We should be streamlining units, and using them consistently. I would also point out to Lightmouse that this cuts both ways between metric and Imperial: if an article's subject is within a SI context, there would only be one conversion to Imperial units in the article, for every specific numerical value. The idea here is not to convert only a single incident of, for example, inches to centimetres, but rather to convert the specific value of 10.5 cm to 4.1 inches only once in the article. This seems reasonable, especially since the same numbers can crop up over and over again in the same article; it gets length and tedious. If someone wants to know and can't remember, they can back to the first appearance of the number -- that's not an unreasonable burden. Example:
- The 38 cm (15 in) guns of the "Bismarck" class were a reasonable compromise, delivering superb hitting power, even compared to the 40.6 cm (16 in) guns in use by other navies.... [new paragraph] The 38 cm turrets were arranged fore and aft, supplemented by 15 cm (5.9 in) secondary weapons abeam. A total of eight 38 cm and twelve 15 cm weapons were fitted to the battleship. Sacxpert 19:52, 2 September 2007 (UTC)
- I have no problem with you editing articles in the way you suggest. This is a rare issue that is easily solved without a guideline. However, the guideline as proposed could be abused by metric hostile editors to strip out non-adjacent conversions. Lightmouse 18:36, 3 September 2007 (UTC)
- Please believe me when I say I'd like to get consensus and move on, but I can't help but observe that the particular naval example used here has conflicts even with customary metric usage in the specific field. While I can't immediately find the NATO Standardization Agreement on artillery, which I believe specifies millimeters, virtually any modern military document will speak of artillery (and small arms) calibers in millimeters, not centimeters. The Soviet Union also standardized on millimeters. The most common artillery piece in the world is called the 155mm, not the 15.5cm. Centimeters were used in some older references, which I'd estimate were early 20th century. It worries me that we may be getting into edit wars over metric purity. Apropos of such wars, I am still baffled by the notion that every article will be accessible to a nonspecialist. Surely the article on Covalent bond is not accessible to a reader with a more than trivial knowledge of physical chemistry, the article on Fourier transform is not accessible to a reader unfamiliar with mathematical analysis, and the article on Tumor necrosis factor-alpha is not accessible to a reader not conversant with the foundations of immunology and molecular genetics. Howard C. Berkowitz 18:56, 3 September 2007 (UTC)
- I like Tony's formulation and Sacxpert gives an excellent example why. However, I would also like to point out that "number-rich" sentences, paragraphs and sometimes subsections (chiefly introductions) often become very cluttered and difficult to read, and repetitions of the same number/unit aren't usually the cause. I've been increasingly tempted to propose excluding conversions from at least the intro, since they'll all be encountered in the subsequent text. Askari Mark (Talk) 19:01, 3 September 2007 (UTC)
- Interesting point, Howard. You're right about the earlier-in-the-century centimetre/millimetre usages. Up through the Nazi era, the Germans, for one, described all of their artillery in terms of centimetres, not millimetres. I don't know the practice of most other metric militaries in that era. Parlance should probably follow the standard of the force using it, I suppose, although I think that either cm or mm is an appropriate choice. Your point about non-specialist access is also well-taken: I've come across plenty of astrophysics articles that are off into territory far beyond my ken in just a dozen sentences. This applies to the next section heading, too. I have to say that Lightmouse's perspective about "metric-hostile" editors is perhaps a bit overwrought, and ignores the converse: Imperial-hostile editors. One conversion for each occurrence of any given unit should be enough in the entire article, whether its metric-to-Imperial or vice-versa. As I said before, if someone really wants to know that 15 cm (or 150 mm) converts to 5.9 inches, and can't remember that from the previous section, they can hit the "page up" key a few times; it won't kill them. I also think Askari Mark might be on the right track; the introduction is no place for dozens of conversions, especially if they'll be coming up again. Then again, most introductory sections to Wikipedia articles are far too long, in any case, and better article formatting should reduce that problem, to some degree. Would I be correct in saying that we are approaching a consensus to support Tony's proposal? Sacxpert 21:19, 3 September 2007 (UTC)
- If I might be forgiven a personal anecdote, which is even worse, I suppose, than Original Research, it happens that I've only very recently had occasion to work with customary nautical units. Before some recent business opportunities where I have been working with software for commercial fishing, my nautical experience was much more in how to defend a carrier battle group against a determined Soviet attack, and what I knew about boats was that the pointy end went forward (most of the time). In the former situation, the concern was much more seconds to impact than whether the missile speed was in knots or km/hour. It tended to be more a question of intercept geometry and fuel consumption to know if someone could outrun a torpedo. So, I'm really not coming into metrication with a prejudice, and, as a one-time biochemist, I'm quite comfortable with such units.
- Now, however, I am dealing with such things as international fisheries regulation, and a very basic surveillance rule is that a scallop dredge, for example, will not work if towed at more than 5 knots, and this is a parameter that is set whether it's a French, Russian, American, or German Vessel Monitoring System.
- As far as Tony's proposal, might I get a sense of whether his second point, "**where inserting a conversion would make a common expression awkward (“The four-minute mile”);" applies to situations where non-SI units are customary or indeed explicit, such as knots as a nautical speed, or the 12 nm[i] territorial limit and 200 nm[i] Exclusive Economic Zone as specified in the United Nations Convention on Law of the Sea (UNCLOS)? Is this another way of stating his second point, or is it a fourth that might be added? Howard C. Berkowitz 23:53, 3 September 2007 (UTC)
- I too oppose a once per article guideline. I would like to see Tony's proposal be a less ambiguous. What about: "• subsequent appearances of exactly the same value and unit within the same paragraph in an article"?
- I would also add "Where the same value and unit appears multiple times in a table the value should be converted each time." I added this so that readers don't have to search through columns of figures to find the conversion they are looking for. -- PatLeahy (talk) 00:23, 4 September 2007 (UTC)
- I too am not crazy about giving explicit guidance on the once per article clause. I feel better PatLeahy's proposal above. However, with any proposal above, there should be the clause, "when there is consensus to do so". —MJCdetroit 00:48, 4 September 2007 (UTC)
- (outdent) Not thrilled about the "with consensus" clause, unless really necessary. It's like all of the globally assumed principles (don't mess with quoted material, options by consensus, be consistent within an article)—let's not clutter the MOS where unnecessary. What about the following text, then, after Patleahy's suggestion:
- subsequent appearances of exactly the same value and unit where a repetition of the conversion appears to be unnecessary.
I'm OK about having nothing at all, though.
Tony 04:09, 4 September 2007 (UTC)
- I would like "nothing at all". Sacxpert initially raised this issue on my talk page, I accepted the principle and suggested raising it here. The first metric edits of many articles will inevitably need fine tuning by subsequent edits. This is already permitted by the MOS and there is no new issue for the MOS to resolve. This issue is not a significant cause of edit warring. A guideline would be complicated and probably would have little effect on edits anyway. Worse, it could be misused or misunderstood. Lightmouse 10:40, 4 September 2007 (UTC)
- May I ask, then, Lightmouse, what do you consider the source of edit wars related to metrication, and how may the wars be minimized? I've become sensitized to this issue not because I routinely use Imperial or other non-SI units in articles not related to nautical matters, but because I'm now doing a good deal in the nautical area and, to some extent, I feel under bombardment by 6 inch/152 millimeter howitzers.
- Last night, I was discussing this area with a commercial fisherman colleague, and the term fathometer came up. In Wikipedia, this redirects to Fishfinder, which is incorrect as fathometers may simply be used for finding the depth for navigational purposes, and not be concerned with fish. I'm not being completely facetious to ask how entries with non-metric terms in their very names should be handled. In this case, the depth markings on many nautical charts are not in meters or feet, but in fathoms. Should "fathometer" itself be deprecated, perhaps along with "yardstick?" Please accept my word that I am not looking for a war on this topic, but I feel, to some extent, in an edit war when I write a nautical article and find it quickly edited with conversions.
- As has been mentioned by others, not all articles can be accessible, beyond the first few sentences, to people without at least a grounding in the subject. Metrication is fairly easy to insert although too many conversions make for awkward writing, but articles in astrophysics, molecular pharmacology, mathematics, etc., are not and can never be accessible to the general reader. In the nautical articles, given that charts and other safety-of-life material (see International Convention for the Safety of Life at Sea (SOLAS) and the United Nations Convention on Law of the Sea (UNCLOS); the latter, in which metric nations certainly participated, specified boundaries in nautical miles.Howard C. Berkowitz 11:13, 4 September 2007 (UTC)
- Also, Lightmouse, what this proposal is trying to do is get people to make "first metric edits" (or "first Imperial edits", b/c you keep forgetting about Imperial system users who might want access to general articles on metric subjects) with some common sense, rather than swooping down on every single occurrence of 4 inch (102 mm), when 4 in (102 mm) could come up many times in a row. After all, it gets pretty bloody tedious to see 4 in (102 mm) every other sentence. That way, if articles weren't being swept wholesale for conversion, there wouldn't be anything to clean up in the first place. Tony's guideline is vague, but it presents a general principle: don't repeat a conversion if it's not necessary. Conversely, it specifically states "exactly the same value and unit", which is unambiguous, and should not promote this odd misuse and abuse about which you seem to be so concerned. There's nothing complicated about that, and it sends a good-faith message to editors. Sacxpert 16:23, 4 September 2007 (UTC)
- Howard C. Berkowitz said:
- "what do you consider the source of edit wars related to metrication". I do not know. The phrase 'We fear change' comes to mind. There are few publications quite like Wikipedia.
- Should "fathometer" itself be deprecated. No. I would not ban it on metrication grounds. We do not need to create a guideline for all possible scenarios relating to units. It does appear to be an American term though. You might want to think about that.
- Lightmouse, I'm beginning to wonder if you have a bias about things that are "American" or "US-centric" rather than not metricated. Fathom historically is a British term. Look through histories and historical novels of the "Age of Sail", and you will find many references to fathoms. Before electronics existed, the Sounding line was used to measure depth. Sounding lines essentially were ropes with various markings for number of fathoms, and a weight at the leading end. The line would be tossed overboard and the skilled seaman handling it would feel when it hit bottom, and call out the number of fathoms to the bottom (the weight often had soft wax at the end so it could return a sample of the bottom -- sand, mud, etc.). The unit of fathoms, while I freely admit is archaic and non-metricated, significantly preceded the existence of the United States and is still in worldwide common use in nautical operations. !Howard C. Berkowitz 12:41, 5 September 2007 (UTC)
- Howard C. Berkowitz said:
- I have a bias against regional terminology and that might sound like anti-<region>. I have no bias against American things. Apologies if that is how it came across. Your analysis of the history of the fathom seems reasonable to me.
- depth markings on many nautical charts are not in meters. That appears to be a US-centric statement.
- Again, I am concerned you are calling things US-centric that are also quite common in the UK and elsewhere in the world. Yes, charts are converting to metric depth, but this will happen over a period of quite a number of years. Since the sea bottom changes in depth, charts must be updated based on measurements. The introduction of electronic charts speeds the process of updating. Howard C. Berkowitz 12:41, 5 September 2007 (UTC)
- United Nations Convention on Law of the Sea ... specified boundaries in nautical miles. I am sure that is true. I still think there should be no ban on converting nautical miles into kilometres.
- In no way am I proposing a ban. When citing a formal document that uses a non-metric measurement, especially an international document that was prepared with the involvement of experts from countries that are fully metricated, I would propose a metric conversion at the first mention of something like "200 nmi Exclusive Economic Zone", but no further conversion of the same measurement through the rest of the article.Howard C. Berkowitz 12:41, 5 September 2007 (UTC)
You removed metric conversions from Vessel monitoring system and Fisheries management. These edits made me think you do not want nautical miles or knots converted into kilometres and km/h. MJCdetroit has already disagreed with those metric removal edits. Further comments by yourself and others reinforced the belief that somehow kilometres and km/h were being opposed because of the widespread domain specialist and legal use of nautical miles/knots. This conversation seems a bit theoretical, perhaps we should look at an example where a problem arises that is difficult for editors to solve. Lightmouse 14:38, 5 September 2007 (UTC)
- I don't understand what you mean by "theoretical". Let me be specific. In articles dealing with domains, such as fisheries and marine navigation, where non-metric units are customary, , I am willing to have the first reference to a non-metric unit have a conversion with it, although it may be quite appropriate to mention, as well, that the non-metric unit is the language of a treaty. I don't want further mentions of the same unit to carry conversions, because I think it makes things hard to read while the conversion information has already been given. The problem is especially acute when referring to nautical miles, knots, and latitude, because the three are related and the reader often needs to see the relationship. Again, I don't mind conversion on the first entry. I do object to editors putting conversions on every subsequent mention of the particular unit and quantity. Howard C. Berkowitz 15:15, 5 September 2007 (UTC)
- Thanks for the clarification. I think I understand your position now. Would you mind if those articles Vessel monitoring system and Fisheries management had non-adjacent instances of 5, 12 and 200 nautical miles converted into km? Lightmouse 15:25, 5 September 2007 (UTC)
- Sacxpert said:
- you keep forgetting about Imperial system users who might want access to general articles on metric subjects. That is not true, I do not forget about non-metric issues. I am choosing not to speak on their behalf.
- May I suggest, when you are referring to non-metric measurements, you simply refer to them as non-metric, Imperial, or almost anything other than US-centric? In nautical matters, British mariners were mappng the world, using units such as fathoms and nautical miles, before the US existed as other than a British colony, and perhaps just an oddity discovered by Vikings or Christoper Columbus. Howard C. Berkowitz 12:41, 5 September 2007 (UTC)
- I do indeed use the term 'non-metric' when referring to units that are not metric. My use of 'US centric' was not about units but about issues that you raised. Namely:
- 1. Google suggests that the term 'fathometer' is hardly used today outside North America.
- 2. I said your statement that charts do not use metres appeared to be US centric. It seems incredible to me. If you say that metric countries do not use metres for depth, I will take your word for it. Lightmouse 15:22, 5 September 2007 (UTC)
- I do indeed use the term 'non-metric' when referring to units that are not metric. My use of 'US centric' was not about units but about issues that you raised. Namely:
- May I suggest, when you are referring to non-metric measurements, you simply refer to them as non-metric, Imperial, or almost anything other than US-centric? In nautical matters, British mariners were mappng the world, using units such as fathoms and nautical miles, before the US existed as other than a British colony, and perhaps just an oddity discovered by Vikings or Christoper Columbus. Howard C. Berkowitz 12:41, 5 September 2007 (UTC)
- Sacxpert said:
- what this proposal is trying to do is get people to make "first metric edits" ...[without]... swooping down on every single occurrence. No the proposal does not distinguish between first and subsequent edits.
- I appreciate your reasoned debate. Lightmouse 10:33, 5 September 2007 (UTC)
Recent edit concerning the point about consistent decimal places
I'm transferring a discussion between Coren and me from his/her talk page.
BEFORE:
The number of decimal places should be consistent within a list or context (“The response rates were 41.0 and 47.4 percent, respectively”, not “The response rates were 41 and 47.4 percent, respectively”).
AFTER:
Outside of scientific contexts where numerical error may be significant, the number of decimal places should be consistent within a list or context (“The response rates were 41.0 and 47.4 percent, respectively”, not “The response rates were 41 and 47.4 percent, respectively”).
I don't get it. Why is scientific context at issue here? Tony 04:29, 1 September 2007 (UTC)
- Because significant digits and precision count. 41 is different from 41.0— the former means "some value in [40.5 41.5[" while the latter means "some value in [40.95 41.05[. In a scientific text, changing the number of significant digits changes the meaning. — Coren (talk) 05:32, 1 September 2007 (UTC)
- But in a list of values, we expect that they'll be of equal decimal-place precision, yes? If the list is 36.8, 51.1 and 53 and 54.5, not only does it look odd, it raises the question as to whether the writer intended 53.0 or, as you put it, somewhere in the range 52.5 ≤ x < 53.5 (in most cases, writers do mean 53.0, and even scientists have been known to be sloppy about this. I don't understand why your text exempts scientific contexts where numerical error "counts" (and where does the boundary between counting/not counting lie?). The wording needs tweaking, in any case. Tony 01:15, 2 September 2007 (UTC)
- I suspect that the wording should note that scientific contexts sometimes have requirements for explicit precision that will prevent consistency, rather than implying it is the norm. SamBC(talk) 01:34, 2 September 2007 (UTC)
- The previous (and changed) wording concerns only the same list or context. I'm unsure why you'd want to change the level of precision for only one item. Can we have an example of where this might be the case; otherwise, I think the change should be reverted. Tony 04:49, 2 September 2007 (UTC)
- Items that happen to fall into the same list are not inherently measured to the same precision. If I measure something with a yardstick marked in inches with no finer markings, and you measure some other things with a more precise ruler, our measurements have different precision. If our measurements were listed together, in some contexts it would be undesirable to bludgeon them into the same precision. Scientists tend to be more careful about significant digits than other people are. So yes, there are edge cases where this is a legitimate issue. In general, within the context of Wikipedia, I am not sure how often this would come up. — Aluvus t/c 05:05, 2 September 2007 (UTC)
- The previous (and changed) wording concerns only the same list or context. I'm unsure why you'd want to change the level of precision for only one item. Can we have an example of where this might be the case; otherwise, I think the change should be reverted. Tony 04:49, 2 September 2007 (UTC)
- I suspect that the wording should note that scientific contexts sometimes have requirements for explicit precision that will prevent consistency, rather than implying it is the norm. SamBC(talk) 01:34, 2 September 2007 (UTC)
- But in a list of values, we expect that they'll be of equal decimal-place precision, yes? If the list is 36.8, 51.1 and 53 and 54.5, not only does it look odd, it raises the question as to whether the writer intended 53.0 or, as you put it, somewhere in the range 52.5 ≤ x < 53.5 (in most cases, writers do mean 53.0, and even scientists have been known to be sloppy about this. I don't understand why your text exempts scientific contexts where numerical error "counts" (and where does the boundary between counting/not counting lie?). The wording needs tweaking, in any case. Tony 01:15, 2 September 2007 (UTC)
- So can we solve the issue by inserting "generally"?
The number of decimal places should generally be consistent within a list or context (“The response rates were 41.0 and 47.4 percent, respectively”, not “The response rates were 41 and 47.4 percent, respectively”).
Tony 06:30, 2 September 2007 (UTC)
- It may be worth specifying this one category of potential exceptions to help prevent wikilawyering. It may not. I've just noticed that "generally" doesn't seem to hold much weight with the wikilawyers. SamBC(talk) 08:10, 2 September 2007 (UTC)
- I have trouble getting my brain around this "one category", and why one item in a list would warrant different treatment. Generally is possibly a useful way of allowing editors a little latitude (i.e., do it unless you present a good reason not to). Perhaps someon can come up with an example of this elusive 41 and 47.4. Tony 10:00, 2 September 2007 (UTC)
Can we not make the exception explicit:
Unless they were measured with unequal precision, the number of decimal places should be consistent within a list or context (“The response rates were 41.0 and 47.4 percent, respectively”, not “The response rates were 41 and 47.4 percent, respectively”).
−Woodstone 10:41, 2 September 2007 (UTC)
- Or may I rearrange the text?
The number of decimal places should be consistent within a list or context (“The response rates were 41.0 and 47.4 percent, respectively”, not “The response rates were 41 and 47.4 percent, respectively”), except in the unusual instances where the items were measured with unequal precision.
Tony 13:55, 2 September 2007 (UTC)
I’ve never really understood why dates and numbers are handled on the same MoS subpage. Glancing over the discussions, it seems different people are looking after these parts and much of the archives already has been divided. I’d like to split them up into Wikipedia:Manual of Style (Dates) and Wikipedia:Manual of Style (Numbers). Has anyone serious objections? Christoph Päper 09:31, 2 September 2007 (UTC)
- Or perhaps Wikipedia:Manual of Style (dates) and Wikipedia:Manual of Style (numbers), in order to more closely follow the Manual of Style in other regards? ~ Jeff Q (talk) 09:39, 2 September 2007 (UTC)
- Of course, sorry. Christoph Päper 16:13, 2 September 2007 (UTC)
I have very serious objections to such a major, sudden change without consensus. Remerge them now, please, and raise it in the usual way. Tony 09:50, 2 September 2007 (UTC) Ah, I spoke too quickly. My view is that there are too many MOS submanuals and that the more there are, the harder they are to coordinate. I see expertise here nicely combined in this coverage of dates and numbers. Can you provide an example of how the division would improve things? Tony 10:04, 2 September 2007 (UTC)
- I hope the maintainability would increase. This talk page tends to get rather large, but the groups discussing dates and numbers have a rather small intersection. Christoph Päper 16:13, 2 September 2007 (UTC)
- Why is this page called (dates and numbers)? It is also about units of measurement, not just plain old numbers. Maybe it needs to be split into three parts instead? —Preceding unsigned comment added by 81.179.80.238 (talk) 00:12, 3 September 2007 (UTC)
- And it's about a lot more than dates, which is why the section is now called "Chronological items". Tony 01:24, 3 September 2007 (UTC)
- If the majority prefers so, we could of course settle on Wikipedia:Manual of Style (chronology) and Wikipedia:Manual of Style (metrology) or some such. Numbers and numbers with units are close enough, in my opinion, to be handled in one page, but dates and times only connect to these through durations (e.g. “30 s”). Christoph Päper 16:53, 3 September 2007 (UTC)
- Don't like metrology (too similar to meteorology, and sounds ugly). Unconvinced that the current structure is faulty; I like the way a critical mass of experts contribute here. Tony 22:21, 3 September 2007 (UTC)
- Why? Because dates are numerical, perhaps? — SMcCandlish talk cont 09:51, 19 September 2007 (UTC)
Removal of metric units
Please can people comment on whether metric units are permitted in Vessel monitoring system, Fisheries management and similar circumstances? Lightmouse 10:30, 2 September 2007 (UTC)
- If the editor is not directly quoting the actual treaty itself then I see no problem including the metric conversions. It helps promote understanding of the subject matter. BTW, that editor changed nautical miles to just miles, which also should be changed back but I'll let you handle that. —MJCdetroit 13:35, 2 September 2007 (UTC)
- Since, as noted above, nm and knots are acceptable in SI, why convert in the first place? Knots and nautical miles are standard in shipping and aviation, because of their direct relationship to the curvature of the Earth, even to countries that use the metric system. Secondly, even if the conversion is important enough to be made, from line 198, there's no need to convert 5 nm to km twice in the span of a dozen words; the conversion hasn't changed, and it's not like anyone would forget that quickly. Sacxpert 20:00, 2 September 2007 (UTC)
- I wrote the original article for vessel monitoring system, and used nautical miles when they were clearly the usage of the source material, but miles when that was the specific language of a treaty. With nautical documents, it is usually a fair assumption that nautical miles are meant. Assumptions, of course, are dangerous, and adding a conversion to kilometers, to me, adds further ambiguity to situations where a legal document is not specific.
- There were a few places where a speed was mentioned, such as the 5 knot limit above which a vessel is considered unable to operate a scallop dredge. Fisheries managers monitoring this would typically either see it on a marine radar, or based on calculations from successive GPS-based reports. Nautical navigation tools customarily report in knots, and that is the convention used by mariners from thoroughly metric countries. I really believe that the metrication is gratuitous in these context.
- To turn to an aeronautical example, English is the official language of air traffic control worldwide, even if it were a German aircraft talking to a Brazilian controller. Quite a number of airlines require all cockpit personnel to speak to one another in English, based on an assumption that if someone were switching languages between the cockpit and air traffic control (or other aircraft), they might make a slip and use a language that the receiver didn't understand. In other words, there are strong safety and navigational reasons for using certain traditional units, accepted by the SI oversight organization. Saying the metric conversion is needed "to make it more accessible", I believe, can further confuse a reader who otherwise will not understand the discipline's conventions. In like manner, when I write or edit pharmacology articles, I use only metric units. Howard C. Berkowitz 20:43, 2 September 2007 (UTC)
- A pedantic but important point: You will hear all sorts of languages being used in aviation. English is the common language rather than the official language, although the distinction is sometimes lost on people. ICAO merely says English be made available whenever an aircraft station is unable to make use of the language spoken by the controllers on the ground. Your German pilot and Brazilian controller example is true. However, there is no ICAO regulation that forbids Spanish controllers speaking Spanish to Spanish pilots in Spain. Just thought I would point that out because we should not reinforce the already popular misconception that English communication is mandatory in the air.
- Saying miles when the source says "miles" is a good thing. Attempting to be more precise than our data is a bad thing; we should not convert when it is unclear whether miles or nautical miles is meant. (It does no great harm to say "200 miles" when either could be meant, but do we convert to (320 km) or (360 km)?) Septentrionalis PMAnderson 21:03, 2 September 2007 (UTC)
- As of the 8th (2005) edition of SI, the table containing both the nautical mile and the knot is now entitled "other non-SI units", replacing the titles "units temporarily accepted for use with the SI" (6th) and "other non-SI units currently accepted for use with the International System" (7th) formerly used for that table, thus they are no longer accepted for use with the SI. Instead, the 8th edition states that authors should have the freedom to use those units, but users "should always give the definition of the units they use in terms of SI units." I assume this means a statement like "1 nautical mile = 1852 m" should be included, not that the units be converted. — Joe Kress 05:45, 3 September 2007 (UTC)
- Saying miles when the source says "miles" is a good thing. Attempting to be more precise than our data is a bad thing; we should not convert when it is unclear whether miles or nautical miles is meant. (It does no great harm to say "200 miles" when either could be meant, but do we convert to (320 km) or (360 km)?) Septentrionalis PMAnderson 21:03, 2 September 2007 (UTC)
- You forgot to mention that they use the symbol "M" for nautical mile and "kn" for knot. That doesn't mean that we should follow their lead, IMHO. Gene Nygaard 16:44, 9 October 2007 (UTC)
- Let me make a suggestion here, which perhaps will need to be linked to a Wiki article that covers both "units temporarily associated with the SI" and a category that, for want of a better term (suggestions welcome), might be called "Wiki units for ambiguous situations." The first part will cover, among other things, the nautical/aeronautical units and why they are preserved (i.e., relationship of nmi/nm to latitude, not just tradition).
- A section, however, might include the term (capitalization significant) "Miles", and indicate that this is used when the term "mile", without metric equivalent and without disambiguation as to Imperial or nautical, appears in a legal document. In the latter case, the point would be made explicitly clear that since the type of miles is not known, introducing a metric equivalent could give the sense of greater accuracy than is known. A technical question here: in making a Wiki link, would something on the order of "Non-SI Units Temporarily Accepted#Miles" take the reader directly to the subsection on Miles within a larger article?
- Are there any other examples besides Miles where such ambiguity exists? Tons, perhaps? —Preceding unsigned comment added by Hcberkowitz (talk • contribs) 12:17, 3 September 2007 (UTC)
- I can think of a number of (commonly used) units for which ambiguity exists. Examples include calorie, gallon,
gill, horsepower, kilobyte, mil, ounce, ton and quart. Thunderbird2 20:06, 9 October 2007 (UTC)
- I can think of a number of (commonly used) units for which ambiguity exists. Examples include calorie, gallon,
- And mole. Too bad the CGPM disn't have enough sense to use the kilogram mole in the first place (for consistency with the kilogram as a base unit) and to call it a loschmidt or something named after a person. Gene Nygaard 21:17, 9 October 2007 (UTC)
- The gill (Thunderbird2's link above is to wrong article) is a "commonly used unit"? Commonly used with more than one meaning? Though I have seen it a zillion times in lists of units, but I've never actually heard anybody use it to express a measurement (and most Americans, at least, would likely mispronounce it if they did), and I've seen it used once or twice in a book, maybe by Henry Fielding (1707-1754) or someone like that. Gene Nygaard 07:00, 10 October 2007 (UTC)
- Well, perhaps not any more. During my mis-spent youth it was a standard measure of volume in English pubs (for spirits, not beer). As I no longer frequent these I don't know if that is still the case, so I withdraw it from the list :). Thunderbird2 08:29, 10 October 2007 (UTC)
- British pubs do not use the gill anymore. It was replaced by the ml in the 1990s I think. "Make sure there are no 1/6 or 1/3 gill measures still in use in the bar as they are illegal." Lightmouse 10:58, 11 October 2007 (UTC)
Added bit on consistency
I've put in a note on units consistency, as I've found several places where passages switch back and forth between metric and US units. Please comment/revise. Mangoe 01:49, 4 September 2007 (UTC)
- While it's not a problem in the nautical frame of reference, if I put on my medical hat, there are annoying laboratory values that really are converting between metric and metric. For example, I learned to specify blood glucose values as milligrams per deciliter. The trend is to specify millimoles per liter, and I am rather baffled when I hear people saying the first is "US" and the second "metric". In physical constants, it's hard to argue metre-kilogram-second (mks) system measurements are "US", and the centimetre-gram-second (cgs) "SI".
- I don't have a ready way even to explain this succinctly, much less make it consistent, to say nothing of medical measurements that use different systems of "international units" per weight or volume, the units based on biological activity. There are especially nasty examples, such as the International Normalized Ratio for blood clotting, that applies correction factors for variability in the biological reagents -- and, where there is a measurement of weight, volume, etc., that measurement is metric. Howard C. Berkowitz 02:27, 4 September 2007 (UTC)
- I'm more concerned about nontechnical passages where units are mixed. The example that caught my eye is in Chesapeake Bay, where it says that so many acres are less than two meters deep. It's obvious to me that this sort of inconsistency is confusing, but I fail to find a place where we advise against it. Mangoe 13:44, 4 September 2007 (UTC)
- That's actually a case of mixed units-- simply translating meters to inches doesn't fix the problem. Hmmmmm..... I've gotten rid of part of the problem by going to a percentage for one number, but the problem remains that the primary unit in the clause is the meter, because it's the round number. Someone working in US units would have used a six foot tall man (which is more plausible anyway: how many people do you know are 2m tall?). The whole paragraph needs citation anyway, but at any rate the point is that simply converting and putting the predominant unit first doesn't necessarily get rid of the mixed units. Mangoe 13:05, 6 September 2007 (UTC)
- If we are playing this walk-in-the-water game properly, we can't even use 6 feet. According to the wikipedia article Human height, the average US non-Hispanic white male is only 5 ft 10 in. Walking in water as deep as the average American, would drown 50% of them, of course. Furthermore, Americans are not half-dolphin with breathing holes in the head. Walking in the water needs *chin height*, not the top of the head height. All in all, the article is better off without talking about it in that way. Lightmouse 18:40, 6 September 2007 (UTC)
- If you were talking about the unit order, then sometimes the unit orders are "mixed" due to the units used by the sources being stated first. I personally don't have a problem with switching the unit's order to be consistent (in most cases) as long as there is a reference for the values. I think the exception would be where one would except to see a specific unit of measure always used for a certain topic. The example that comes to mind is ammunition for rifles and handguns, where bullet weight and powder weight are almost always given in grains and not grams; even in metric (mm) cartridges. To swapped the unit order for the bullet weights for the metric weapons would go against what is commonly encountered in the firearms industry.
- Do we need a specific point in the MOS to address this? Probably not. —MJCdetroit 15:16, 4 September 2007 (UTC)
- Traditional units for a particular topic sometimes have a technical basis for their use, and are part of a system, such as knots, nautical miles, and angular measurement of latitude. In other cases, such as your ammunition example, while "early" metrication might make the article more accessible to a complete novice in the subject, but less accessible to a reader looking for further detail, such as a hypothetical student of military ammunition who wanted to compare the .30 caliber 173 and 154 grain bullets.
- I suppose, as well as customary usage, there is an issue of common sense. Does it make sense to call the instrument, on the bridge of a fishing vessel, a fathometer or a 1.829metermeter? Many charts, incidentally, have the depths marked in fathoms, admittedly an archaic measure but one still used. Howard C. Berkowitz 16:05, 4 September 2007 (UTC)
- This sort of argument that says my "fathometer" is now called a "1.829metermeter" seems to surface regularly and it is not appropriate in a reasoned discussion. In Australia you can still talk about mileage or order a pint of Guinness, you just measure it in km and get 500ml respectively. Common phrases do not get converted. They may evolve with time, but they do not convert. "Look after the pennies and the pounds will take care of themselves" is still a valid phrase in Australia - and that country went to decimal currency 41 years ago. Maybe the phrase is used in the US as well - which took the lead in decimalised currency way earlier.
- What's important here is that measurements can be understood. And on the other hand we don't want conversions everywhere because it stuffs up readability - and it's just plain ugly. So where do we draw the line. Some people in some countries somewhere may still use the cubit - do we provide a conversion? No. To communicate in this world the phrase "Speak in English, measure in metric" is used. A metric measurement is something that must mandatorily be provided for every measurement in Wikipedia. For example an article on a planet may talk in Astronomical Units, but a measurement in km needs to be present. Likewise a nautical article that uses fathoms or nautical miles must have a measurement in metres (or km) as well.
- I strongly agree on readability though. If an article continually mentions that Neptune is 29.8 AU (4.6 billion km) from the sun then using 29.8 AU by itself with no conversion is to be recommended in subsequent parts of the article.
- Back to fathoms and nautical miles. Nautical miles are no longer accepted in SI. So a conversion to km must be given. You state that fathoms are used to measure depth, well that may be the case in the US (and some other countries) but I think you will find metres are quite common. Sea charts are certainly in metres in Australia. Also, the Global Positioning System (the way all modern nautical navigation is done) is entirely calculated in metric and only converts to nautical miles and feet in the devices themselves predominantly for US, Myanmar and Liberian users. Jim77742 12:09, 6 September 2007 (UTC)
- I have addressed both your 'fathometer' question and your non-metric chart question where you raised them earlier in the frequency of conversion section.
- Lightmouse 11:05, 5 September 2007 (UTC)
- I have addressed both your 'fathometer' question and your non-metric chart question where you raised them earlier in the frequency of conversion section.
BC/BCE in articles on religious figures
Specifically referring to figures important to both Christianity as well as other religions, is it appropriate and/or acceptable to switch from BC to BCE? In these cases, the religious overtones of the nomenclature are enhanced due to the religiosity of the subject, and I feel if the person is is of significant importance to other religions, the less pointedly Christian terminology should be used. For example, see Isaiah. Thoughts? Thank you. -- Avi 20:57, 4 September 2007 (UTC)
- That makes sense to me. I get the feeling this talk page has 10 thousand pages of debate on this subject. There might already be a policy on this? Jeff Carr 01:36, 5 September 2007 (UTC)
With the overwhelming response (thank you Jeff), is it safe to say that the above suggestion can be added to the MoS for clarification purposes? -- Avi 18:44, 6 September 2007 (UTC)
- I don't think we need to specifically clarify anything in the MOS for you to do this. Do it with a clear edit summary and if someone reverts you, then take it to the article's talk page. When it comes to BC/BCE, editors tend to argue with each other and do what they want anyways. Just look at the Jesus article—one article that should use BC/AD— and what a mess that is in respect in the BC/BCE. —MJCdetroit 20:11, 6 September 2007 (UTC)
- I second that. Tony 01:52, 7 September 2007 (UTC)
- May I make a suggestion for such situations? Many general readers without an academic background do not recognize "BCE/CE". It might be wise to recommend linking the first use in an article to "Common Era", which would not only explain it but also point out that it may be read either as such or as "Christian Era" if the reader so desires. I suspect a lot of those fighting over its use are completely unaware of the latter point. Askari Mark (Talk) 19:50, 7 September 2007 (UTC)
- Agreed. it usually is ala BCE, but where it is not, it should be; as should AD -- Avi 20:37, 9 September 2007 (UTC)
Centuries again
Interesting to see the above discussion recommending spelling out centuries in text, and pointing to a number of external MoS which recommend this (to which one can add the Oxford MoS) resulted in the option to spell out being removed on the basis of existing practice. IMHO "16th century" is fine for notes, but unsuitable for text. We certainly shouldn't be encouraging it's use over "sixteenth century". Any objection to al least reinstating the option on centuries? Rich Farmbrough, 13:44 7 September 2007 (GMT).
- Richard: what don't you like about 16th century? To me, it's much easier to read, and I'm happy to retain the choice. Tony 14:19, 7 September 2007 (UTC)
- Depends on context. "The sixteenth century brought a new cultural openness to England" should be spelled out, and probably capped, as a personification. "The 16th-century musician William Byrd" would be fine by me (but should be hyphenated). Septentrionalis PMAnderson 15:47, 8 September 2007 (UTC)
- I have to concur with Tony's readability point. And I do not understand PMAnderson/Septentrionalis's gist here. For one thing, the first is not an exmaple of personification at all (it is a mistake to think of generic transitive verbs like "bring" as anthropomorphic; contrast "the 20th century murdered American trust in government" – for it to be personifying, it generally has to be verb limited to conscious, human-specific action). There doesn't seem to be a strong contextual difference between the two examples. And "16th century" would only be hyphenated in the 2nd example because it is a compound adjective; "William Byrd was a musician of the 16th century" would not get a hyphen. — SMcCandlish [talk] [cont] ‹(-¿-)› 15:12, 17 September 2007 (UTC)
- Depends on context. "The sixteenth century brought a new cultural openness to England" should be spelled out, and probably capped, as a personification. "The 16th-century musician William Byrd" would be fine by me (but should be hyphenated). Septentrionalis PMAnderson 15:47, 8 September 2007 (UTC)
Linking the first use of common units
Discussion moved from Wikipedia talk:WikiProject Ships. Begin moved text.
I generally try to provide a link to the appropriate article the first time I use a unit, even a very common one. For example, I link ft to Foot (unit of length). Lightmouse has unlinked a few of these. When I asked him about it, he says he doesn't feel it's necessary to link such common units. I see his point, and so I wanted to ask you guys for your opinion. Certainly I think it's important to link specialty units like knot (and Lightmouse is certainly not unlinking those). However, is it a good idea to link the first use of any unit, even if they're as common as feet and inches? I'm not sure, and I'd like to know what WP:SHIPS thinks about it. TomTheHand 19:54, 6 September 2007 (UTC)
- I'd think this is very pertinent for tons - quite often it is quoted in tonnes where it should be tons, and the reader is not sure if we mean long tons or short tons etc. Emoscopes Talk 20:55, 6 September 2007 (UTC)
- (edit conflict) It may be unnecessary to have them, it certainly seems unnecessary to remove them though. Bit of an odd argument from Lightmouse. I don't tend to link them, but it could only be useful to have them there, so taking them out when they're already there seems a backward step to me. --Benea 20:58, 6 September 2007 (UTC)
- I wouldn't bother linking feet and meters, but I wouldn't bother removing links to them, either. Maralia 21:00, 6 September 2007 (UTC)
- Well, Lightmouse does this stuff, along with many other kinds of useful fixes and unit conversions, automatically, so it's not taking him any time to perform this unlinking. So... should we ask him to stop making this particular edit? Are there people on English Wikipedia who look at feet and inches, with a metric conversion next to them, and say "I'd sure like to look at an article and find out just what a 'ft' is"? Or are the links useless to just about anybody, and removing them streamlines the article? TomTheHand 21:05, 6 September 2007 (UTC)
- I would go further than Benea and Maralia. It is not just unnecessary to remove links to a unit like the foot, it is even harmful to do so because it adds ambiguity. (Just because it is common does not make it unambiguous). In a nutshell: link all units except those defined by SI. Thunderbird2 21:12, 6 September 2007 (UTC)
- Just to clarify, there are about 6 different definitions for the foot listed here. Thunderbird2 21:21, 6 September 2007 (UTC)
- Personally, I almost always link the first use of finite, measuring terms like feet, inch, m, knot, nautical mile, ton, tonne, etc. in articles. Not only are the exact definitions of these terms of integral importance to most naval articles, but I would hazard to say that the majority of casual readers are more than a little fuzzy on what exactly some of these terms mean (especially if they are users of the imperial/metric system, and the article they are reading uses the other system). It would be a different story if we were talking about words like ocean, ship, Tuesday, etc. --Kralizec! (talk) 01:42, 7 September 2007 (UTC)
- Just to clarify, there are about 6 different definitions for the foot listed here. Thunderbird2 21:21, 6 September 2007 (UTC)
- I would go further than Benea and Maralia. It is not just unnecessary to remove links to a unit like the foot, it is even harmful to do so because it adds ambiguity. (Just because it is common does not make it unambiguous). In a nutshell: link all units except those defined by SI. Thunderbird2 21:12, 6 September 2007 (UTC)
- Well, Lightmouse does this stuff, along with many other kinds of useful fixes and unit conversions, automatically, so it's not taking him any time to perform this unlinking. So... should we ask him to stop making this particular edit? Are there people on English Wikipedia who look at feet and inches, with a metric conversion next to them, and say "I'd sure like to look at an article and find out just what a 'ft' is"? Or are the links useless to just about anybody, and removing them streamlines the article? TomTheHand 21:05, 6 September 2007 (UTC)
- I wouldn't bother linking feet and meters, but I wouldn't bother removing links to them, either. Maralia 21:00, 6 September 2007 (UTC)
- (edit conflict) It may be unnecessary to have them, it certainly seems unnecessary to remove them though. Bit of an odd argument from Lightmouse. I don't tend to link them, but it could only be useful to have them there, so taking them out when they're already there seems a backward step to me. --Benea 20:58, 6 September 2007 (UTC)
Discussion moved from Wikipedia talk:WikiProject Ships. End moved text.
I have taken the liberty of moving this general discussion about unit links here. Feel free to comment. Lightmouse 16:22, 7 September 2007 (UTC)
- My main thought is that common units are like plain english. A second thought is that the argument for a linking '50 miles' becomes weaker when the metric conversion is provided, as in '50 miles (80 km)'. Thirdly, my metrication script cannot handle linked units, so that is why it delinks them. Depending on feedback here, I can amend the code but it will be much less effective at metrication. If you want to use or copy the metrication script, feel free. Lightmouse 16:38, 7 September 2007 (UTC)
- This explanation changes my position somewhat. The question becomes whether the value in adding metric equivalents outweighs the ambiguity introduced in removing the link. I think it probably does. Thunderbird2 17:12, 7 September 2007 (UTC)
- You can have your cake and eat it too. Although Lightmouse is unable to automatically provide metric conversions when ft is linked, the conversions can still be added manually. On the pages where I noticed ft being de-linked, I had already provided metric conversions; Lightmouse made no changes to that area except removing the link. Lightmouse can provide automatic metrication for subsequent, unlinked uses of ft and in, and allow the first use to remain linked. I don't see the script becoming "much less effective." TomTheHand 19:34, 7 September 2007 (UTC)
- I might agree that "common units are like plain English" if there are units that are indeed universally common. I think it applies to the basic units of time (seconds, hours, days), but are there any others? Perhaps the basic SI units (kg, m, s) as these are taught in secondary schools around the world. For all other units I think it is good practice to link on first use. Thunderbird2 07:54, 8 September 2007 (UTC)
- I don't agree; I'd insert such a link only if absolutely necessary. I don't mind generally if Lightmouse delinks: it usually improves the appearance and readabiliy of the text. But if the locals object, I'd be inclined not to persist, unless, for example, if every occurrence is linked throughout an article—that's excessive and needs to be dealt with. Tony 08:21, 8 September 2007 (UTC)
- Unfortunately, the script is complicated and dumb. It metricates unlinked units only. It is ignorant about the link total per article and link position (1st, 2nd, etc). Blindly delinking all common units is an easy way to apply the metrication code to a *lot* more values. The increase in metrication efficiency is why I added the feature but I can simply remove it again. I may be able to modify the delinking feature so that it tests for a parenthesis so it will not delink 50 miles (80 km). That might reduce some of the false positives noticed by TomTheHand. Lightmouse 11:32, 8 September 2007 (UTC)
- If this modification were possible, my objections would pretty much vanish. I objected to the delinking of units when metric conversions were already present and weren't being modified. It looks like units are being delinked for delinking's sake and I don't really agree with that; I think linking the first use of a unit is a good idea. However, if I noticed a delinking and metrication I wouldn't object in the same way.
- MoS readers may not have had the benefit of seeing exactly what I'm talking about. This is an example. In the text of the article, Lightmouse metricates a yards figure, which I think is great. However, in the article infobox, "ft" (the first use in the article) is delinked without touching anything else in the area. TomTheHand 16:47, 8 September 2007 (UTC)
- Unfortunately, the script is complicated and dumb. It metricates unlinked units only. It is ignorant about the link total per article and link position (1st, 2nd, etc). Blindly delinking all common units is an easy way to apply the metrication code to a *lot* more values. The increase in metrication efficiency is why I added the feature but I can simply remove it again. I may be able to modify the delinking feature so that it tests for a parenthesis so it will not delink 50 miles (80 km). That might reduce some of the false positives noticed by TomTheHand. Lightmouse 11:32, 8 September 2007 (UTC)
- I don't agree; I'd insert such a link only if absolutely necessary. I don't mind generally if Lightmouse delinks: it usually improves the appearance and readabiliy of the text. But if the locals object, I'd be inclined not to persist, unless, for example, if every occurrence is linked throughout an article—that's excessive and needs to be dealt with. Tony 08:21, 8 September 2007 (UTC)
- I looked at TomTheHand's example and noticed that 1000 yd is converted to 1000 m. In my book that should be 900 m. (It would be different if it said "1 kyd", because that implies a degree of rounding that "1000 yd" may not"). Thunderbird2 17:03, 8 September 2007 (UTC)
- I just re-visited USS Segundo and see now that it's easy to get one more significant figure (ie 900 m) just by changing "-3" to "-2" in the convert command. While I was there I linked ft and bhp [and resisted the temptation to change nm to nmi ;-)]. Thunderbird2 21:24, 8 September 2007 (UTC)
- This explanation changes my position somewhat. The question becomes whether the value in adding metric equivalents outweighs the ambiguity introduced in removing the link. I think it probably does. Thunderbird2 17:12, 7 September 2007 (UTC)
The example given by TomTheHand is interesting. I think it shows that almost impossible to check for existing conversions of 'foot'. In the case of mile and km, the parenthesis is within usually 2 characters. However, in the example given by TomTheHand, the parenthesis is not even within 20 characters because it is on the other side of inch. I have decided to stop delinking foot and amended the script accordingly.
The 900/1000 metre example given by Thunderbird2 is also interesting. Unit conversion is part science and part art. Lightmouse 08:29, 9 September 2007 (UTC)
Conversions – recent edit
Anderson, for once it was an improvement. But why "200 miles"? Isn't this intended as an example? As is, it's not. What was wrong with "exactly the same unit and value"? (Is that what is meant, with an "e.g.," for the "200 miles"? Tony 15:18, 8 September 2007 (UTC)
- There are two extremes: provide a conversion for every instance of mile, which would be redundant in an article on maritime law, and simply assume that a link to mile and nautical mile will suffice. In these articles, neither is desirable; it is for editorial judgment to decide what intermediate point is clearest, balancing providing information when wanted against having the reader's eyes glaze over at the mass of parentheses. Such articles may well have several successive sentences of the form: At X conference, limit A was set at 50 miles, limit B at 80 miles, limit C at 200 miles. Y conference revised this to..."
- I reprehend the use of "imperial unit"; "Imperial" is idiomatic.
- I dispute the existence of two exceptions, when there are (at least) three; these are the three that happen to have come here. Septentrionalis PMAnderson 15:42, 8 September 2007 (UTC)
- I didn't have an issue with any of that, so I'm sorry that your effort there was wasted. It's the "but excessive to convert "200 miles" every time it occurs" that is problematic. Some people will take it to be an example; it could theoretically refer to that and only that precise example (doesn't apply to 201 miles), or a number of values, as you are perhaps saying above. If the latter, it would be better not to specify 200 miles, surely? I'm confused, so many readers will be. I won't be back for nine hours. Tony 16:04, 8 September 2007 (UTC)
- I am disappointed to see this new guideline. Edits to the main page are either trivial or have a prior conclusive discussion. Look back at the discussion we had on this one, it was rambling and inconclusive. My metrication script cannot comply with this guideline so that will be the end of all the good work it does. The wording is unacceptable. It is not just biased against metric, it is *only* anti-metric. Furthermore, it takes no account of proximity of conversions. I think it should be removed and if anyone thinks it is necessary, they should allow proper debate with examples of the edit disputes that it is trying to solve. Lightmouse 16:24, 8 September 2007 (UTC)
- Manderson, I see that you've taken to slapping a dispute tag on any section where your sudden, unilateral edits are not accepted. Yet your accomplice, Radiant, told me off pretty rudely when I put one on (something like "one person's disagreement doesn't justify a tag"). You two can't play it both ways. Tony 16:48, 8 September 2007 (UTC)
- I got the same treatment at WP:N, which Radiant was fairly controlling over. I stuck to my guns and got a lot of changes made over several months (I think largely because Centrx acted as something of an informal mediator between us). The point being, this double-standard isn't anything new. However, I think it should be noted that the nature of {{disputedtag}} has changed quite a bit since late 2006, when it was used at WP:N. Last I looked, its once very vague documentation is pretty explicit today that it is not to be used just because someone has a disagreement about something; that's what talk pages are for. The purpose of the template is to annotate for incoming readers that there is a widespread dispute on-going, so that they are aware that the section may not be reliable, and that there's a debate they may wish to participate in. Guidline language that's been stable in its message if not is exact word-for-word language hardly qualifies; a small handful of detractors of a section does not make the section "Disputed" in the sense of that template. Really, my present take on that tag is that it should not actually be applied by anyone who is a party to the debate, but rather only by a neutral one, since it's point is to serve incoming readers/editors relying on the policy page, not to help a party to the dispute get the message across that they don't agree with something or that they think that the community should be disputing it along with them. I.e., the template is for flagging genuine community not individual or mini-cabal disputes about policy. It is definitely being grossly abused on this projectpage. — SMcCandlish [talk] [cont] ‹(-¿-)› 15:33, 17 September 2007 (UTC)
- My dispute is specific: That we have three exceptions and say "two". Fix that and take off the tag. Septentrionalis PMAnderson 17:32, 8 September 2007 (UTC)
- That has absolutely nothing to do with my point. Tony 01:39, 9 September 2007 (UTC)
- Manderson, I see that you've taken to slapping a dispute tag on any section where your sudden, unilateral edits are not accepted. Yet your accomplice, Radiant, told me off pretty rudely when I put one on (something like "one person's disagreement doesn't justify a tag"). You two can't play it both ways. Tony 16:48, 8 September 2007 (UTC)
- I am disappointed to see this new guideline. Edits to the main page are either trivial or have a prior conclusive discussion. Look back at the discussion we had on this one, it was rambling and inconclusive. My metrication script cannot comply with this guideline so that will be the end of all the good work it does. The wording is unacceptable. It is not just biased against metric, it is *only* anti-metric. Furthermore, it takes no account of proximity of conversions. I think it should be removed and if anyone thinks it is necessary, they should allow proper debate with examples of the edit disputes that it is trying to solve. Lightmouse 16:24, 8 September 2007 (UTC)
As for Lightmouse: it is precisely editorial judgment which takes account of the proximity of conversions. The eye of the reader should judge that, not a script. As for it being totally anti-metric, nonsense. There are articles which should use metric overwhelmingly (or natural units, which we have not yet discussed, and should); there are articles which should use US/Imperial overwhelmingly, because it's their subject matter. When both kinds of articles should convert should be decided by editors, not by scripts. (A program that would recognize these exceptions and allow for them would be most useful; a program that worked article by article, with human intervention, would be sensible; but we should not rewrite large patches of Wikipedia on autopilot.)
Please note also that MOS cannot make a script useless, or otherwise; it's a guideline. Septentrionalis PMAnderson 17:32, 8 September 2007 (UTC)
- I have to disagree on a few points here. I think the clause "in topics such as the history of maritime law in which imperial units (for example, miles and nautical miles) are part of the subject" does, perhaps, carry the imprimatur of an anti-metric bias. I will say again, though, that something along the lines of "It is useful to provide metric/Imperial or Imperial/metric conversions, but excessive to convert exactly the same unit and value every time it occurs. No more than one conversion of the exact same unit and value should be made in any given paragraph." (that's my proposal) is appropriate, useful, and necessary.
- I also have to disagree with Lightmouse and agree with Anderson on another point -- edits should not be made on autopilot. I appeciate the value and universality of the SI system, and acknowledge that articles should have both Imperial and metric units, but sweeping edits with bots or scripts is NOT a good solution. As I mentioned on Lightmouse's talk page, his conversions have swapped out phrases like "flew 600 miles" in naval articles, and replaced them with "{{convert|600|mi|km|-2}}, which now specifically implies statute miles and an inaccurate conversion to kilometres, when in fact the original intent was probably nautical miles. Also, that script, without a check by a reasonable editor afterward, repeat conversions of exactly the same unit value occur again and again in single paragraphs. That is plainly ridiculous. Lightmouse's assertion that his "metrication script cannot comply with this guideline so that will be the end of all the good work it does" is not a sufficient reason to prevent some sort of MOS limitation. Pages can be converted manually, with an editor checking for reasonable conversion frequency, and not wholesale markup that only makes a mess of parentheses. It will take longer, but it will be easier to read, require fewer cleanup edits, and will not introduce errors of statute v. nautical miles. If improving Wikipedia, and not eradicating the Imperial system, is the real goal, then this seems like a reasonable position. Sacxpert 20:29, 8 September 2007 (UTC)
- I'm uneasy about this autoscript. Tony 01:39, 9 September 2007 (UTC)
- I'll add my concern about too much automation. When I am reasonably comfortable with the Imperial (or other) units in a particular domain, I don't object to doing a metric conversion the first time the measurement appears. Others may not have had the annoyance, but in Tom Clancy's nonfiction books, AFAIK every measurement is given in both systems, every time. Rather quickly, I find this hard to read -- I'll live with either system, but constant "bilingualism" is simply hard to read.
- Again in the naval/nautical domain, there are cases where treaties used specific units. After Versailles, German warships, were, for a time, limited to 10,000 tons. The article Tonnage will show a great many variations before standardization in 1982, and I think there is historic value to seeing a "round number" as an arbitrary bound. It really wouldn't make that much difference in the combat effectiveness of a 9000, 10000, or 11000 ton vessel, but I think it is important that the reader is aware the treaty drafters were creating an arbitrary line. Metricating that can lose the flavor by inserting what are essentially meaningless digits of precision.
- I have yet to hear arguments, which should logically follow, of metric CGS vs. MKS systems, or biochemical measurements by milligrams rather than millimoles. To me, there's as much pedantic as accessibility flavor in this discussion. Howard C. Berkowitz 01:57, 9 September 2007 (UTC)
- I'm uneasy about this autoscript. Tony 01:39, 9 September 2007 (UTC)
- I am also uneasy about using a script to metricate. I also agree that scripts should not constrain the style. I also agree that editors should be permitted to remove duplicate adjacent conversions. However, the debate keeps drifting into issues of metric exemption. A bit of non-metric suffering is a *good thing* when exchanged for a lot of metric accessibility. I think this debate and demand for new guidelines is partly due to growing pains for people that are unfamiliar/uncomfortable with the needs of metric readers. Editors are always free to edit to improve metrication, we do not need a guideline for each good editorial option.
- The script has been very successful and probably helped more metric readers than any human editor has. The new guideline is for an issue that has caused no edit war. I ask you keep things in proportion. Lightmouse 09:29, 9 September 2007 (UTC)
- I agree with Lightmouse. The automated script is doing monotonous, repetitive work that releases human editors' effort for more challenging and more rewarding enterprises. The fact we are having this discussion at all proves that we are watching the pages we care about. It's much easier to fix small problems that may arise, than to have done all that work by hand. Thunderbird2 10:53, 9 September 2007 (UTC)
- I deny anti-metric bias, again. My bias is against rules which apply generally being stated as through they apply without exception. In general, we should use both measurement systems, and explicitly convert; but there are exceptions on both sides. One major exception, where we should use metric only (with perhaps one link or definition for clarity) is already provided for. There are more: for example, those scientific articles which don't use conventional units, SI or otherwise, but the natural units (for QM: Planck length, not meters, feet or any multiples; for GR, more likely lightsecond). We are now discussing an obvious exception in the other direction. Septentrionalis PMAnderson 17:37, 9 September 2007 (UTC)
- I agree with Lightmouse. The automated script is doing monotonous, repetitive work that releases human editors' effort for more challenging and more rewarding enterprises. The fact we are having this discussion at all proves that we are watching the pages we care about. It's much easier to fix small problems that may arise, than to have done all that work by hand. Thunderbird2 10:53, 9 September 2007 (UTC)
(outdent) I'm a little annoyed with Lightmouse's assertions about "non-metric suffering". I'm quite comfortable with the metric system, and I sometimes use it, but I use the Imperial system, too, and it's worth having both systems available when a major world power still uses the latter. Lightmouse accuses others of anti-metric bias, but yet sometimes seems to demonstrate a clear anti-Imperial bias, which violates the equal-access-to-article principles. It cuts both ways, not just in favour of his preferred system. I say again, this proposal (as reworded) is not an anti-metric issue. Consider, for one example, the article Bismarck class battleship, which has numerous repeats of the same units (the original units are almost all metric, btw, because I rewrote the article from the metric perspective, since Germany used metric). If I had a metric-to-Imperial converter, or if I just mindlessly converted every unit value, it would look a mess, with Imperial units in parentheses all over the place. I would be annoyed with such a page layout, even though I'm primarily accustomed to the Imperial system, because readability is important. The finessed rule I proposed does not outlaw the use of scripts (except when the original units are unclear), and does not have a bias against either system. All it says is that you don't repeat the exact same conversion back to back to back, and provides that guideline for consideration when writing new articles. Someone can still use a script, all I'm asking is that they do a read-through and clean up their own mess if the converter is overzealous, rather than leaving it for someone else to fix later. Please tell me why this is unreasonable. Sacxpert 18:55, 9 September 2007 (UTC)
- I agree that metric is indeed appropriate for German battleships, just as if there had been a discussion of British early battleships, the heart of many design argument was caliber in inches. Without getting into Fisher vs. Beresford examples, it is clearer when one side speaks of wanting a 12 inch battery versus a 15 inch. Contemporary arguments included shell weights in pounds. In a case like this, unless the reader is not just a naval historian but an expert in ammunition characteristics, the exact weight is not as important as the changes in total weight of broadside -- and I'm not getting into efficiency of explosive filler, percent filler, armor penetration, etc.
- Unfortunately, I am finding rapid metrications of nautical articles I write to border on the hostile. Would it kill another editor to ask, on the article or personal talk page, if there is a domain-specific reason to use particular systems of measurement, be they MKS, Imperial, CGS, or archaic? As an example, I don't need Imperial conversions in an article on German warships, but, for mindless consistency, should there not be an Imperial conversion? What about MKS and CGS when talking about metric units? What bothers me most, I suppose, is that the collaborative structure of Wikipedia appears to be broken when an editor seems intent on inserting conversions, rather than dealing with content. Howard C. Berkowitz 19:50, 9 September 2007 (UTC)
- And even there it varies. Description of a particular Germna battleship should probably be in metric, but I have yet to see a description (in English) of the naval race of 1908-14 which did not state caliber and armor in inches, presumably so that the reader can compare the two sides. Septentrionalis PMAnderson 21:11, 9 September 2007 (UTC)
Date formatting
It seems to me that the date section was more clear on using spaces around the ndash in the date. I think it used to state that if the dates on either side of the ndash did not use a space, then use no spaces around the ndash; if the dates have spaces, then space the ndash. Thus 1910–1917 and February 11, 1910 – 22 March 1917. If this is correct, then the current text is not so obvious. --Gadget850 ( Ed) 11:49, 9 September 2007 (UTC)
- This is precisely the sort of thing which we should not bother to standardize; for Heaven's sake, why? Septentrionalis PMAnderson 17:38, 9 September 2007 (UTC)
- Yes, that was the standard I remember. It is standardised to ensure consistency; it is consistent so that this is a professional work. For some editors it is a stylistic issue, for others, just consistency. Think about it, if you saw 1910–1917 in one place, 1924-1926 in another, then 1932 — 1939 and then 1945 – 1952, it would look scrappy. This isn't something people should stress over, unless they're like me and they like details—remember the guide is for articles, not editors. As long as no-one deliberately makes edits which go against it. Neonumbers 01:28, 10 September 2007 (UTC)
- It's precisly the sort of thing MOS should state: readability is at issue. No space where there are internal spaces in the items looks horrible and is confusing. Hyphensa are more readable as en dashes. The spacing point was and is still made in MOS. Tony 02:07, 10 September 2007 (UTC)
- Not to me; I find the readability exactly equal. Neonumber's point seems to me to prove that this is another instance of a frequent case; we should have, but not stress over, consistency within an article. Septentrionalis PMAnderson 02:59, 10 September 2007 (UTC)
- Problem here (with your general poin) is articles share navboxen, tmeplates, infoboxen, and bits get moved betweeen them. Sowhile having articles consistent internally is a (very) good start, it's not really enough. Rich Farmbrough, 19:21 12 September 2007 (GMT).
- PMA, if they are "exactly equal" to you, why are you bothering to go on about it? Its been said here before that you frequently seem to be raising and continuing arguments just for the hell of it. This is a good example of a post that makes people think that. Funny thing is, I remember you being way more reasonable during the WP:ATT debates; why the combativeness here over things you appear to consider totally trivial yourself? — SMcCandlish [talk] [cont] ‹(-¿-)› 15:39, 17 September 2007 (UTC)
- Because forbidding spaced emdashes has in practice, under some reviewers, been made into a FAC criterion - despite Tony's note above that it should not be so read. One solution would be to remove the mention of MOS as a criterion there, and let this page exist as what it was designed to be, a page of advice. I want to keep these trivialities out of FAC, and away from bullies; if some editor is not sure what to do, and comes here to check, fine. Septentrionalis PMAnderson 19:57, 26 September 2007 (UTC)
- Not to me; I find the readability exactly equal. Neonumber's point seems to me to prove that this is another instance of a frequent case; we should have, but not stress over, consistency within an article. Septentrionalis PMAnderson 02:59, 10 September 2007 (UTC)
- It's precisly the sort of thing MOS should state: readability is at issue. No space where there are internal spaces in the items looks horrible and is confusing. Hyphensa are more readable as en dashes. The spacing point was and is still made in MOS. Tony 02:07, 10 September 2007 (UTC)
- Yes, that was the standard I remember. It is standardised to ensure consistency; it is consistent so that this is a professional work. For some editors it is a stylistic issue, for others, just consistency. Think about it, if you saw 1910–1917 in one place, 1924-1926 in another, then 1932 — 1939 and then 1945 – 1952, it would look scrappy. This isn't something people should stress over, unless they're like me and they like details—remember the guide is for articles, not editors. As long as no-one deliberately makes edits which go against it. Neonumbers 01:28, 10 September 2007 (UTC)
Actually, I found the ref I was looking for at WP:DASH:
Spacing: All disjunctive en dashes are unspaced, except when there is a space within either or both of the items (the New York – Sydney flight, the New Zealand – South Africa grand final, 3 July 1888 – 18 August 1940).
--Gadget850 ( Ed) 19:42, 12 September 2007 (UTC)
Capitalisation of SI units?
It is implied by the present wording (Conversions section) that the SI unit of absolute temperature (kelvin) should be written with a capital "K". SI units are written as lower case when written out in full, and the kelvin is no exception. The statement is incorrect. The reason why Celsius is upper case is because the celsius is not an SI unit (it is the degree Celsius). Thunderbird2 17:43, 9 September 2007 (UTC)
- Quite right; but we should phrase to discourage, not forbid, the quite common surviving usage of "degrees Kelvin"; that is merely old-fashioned. Septentrionalis PMAnderson 18:04, 9 September 2007 (UTC)
- Yes the MoS never "forbids". It is a style guide - and we have never expected editors to meet it (althoguh many do), that is for sub-editors. Rich Farmbrough, 19:17 12 September 2007 (GMT).
- Let it be strongly discouraged then. On a related note, some discouragement of the practice of capitalising imperial (as in imperial system) might be worthwhile ... quite a common error. Jɪmp 03:52, 14 September 2007 (UTC)
- A far more important issue, one more worthy of our attention than the debatable one you raise (it does refer to a specific, identifiable "Empire"; we don't often use that term in connection with the units of the Roman Empire or any other empire), is the fact that "imperial" is often used in these contexts when it should not be used, because its context includes units not acceptable in the British Empire in the post-1824 era. Gene Nygaard 14:13, 28 October 2007 (UTC)
- Let it be strongly discouraged then. On a related note, some discouragement of the practice of capitalising imperial (as in imperial system) might be worthwhile ... quite a common error. Jɪmp 03:52, 14 September 2007 (UTC)
- Yes the MoS never "forbids". It is a style guide - and we have never expected editors to meet it (althoguh many do), that is for sub-editors. Rich Farmbrough, 19:17 12 September 2007 (GMT).
The kelvin is a unit that is mostly used only in a scientific context, and as such it is quite wrong to call it a degree (and has been for 40 years). So "strongly discourage" sounds about right. Thunderbird2 13:29, 17 September 2007 (UTC)
- Kelvin is an absolute scale. So it is quite wrong to say "degrees Kelvin". It is twenty Kelvin, or four-hundred Kelvin, etc. 81.178.90.168 (talk) 2007-09-20 00:30 UTC
- They are not all lower case at all. They are especially upper-case when they were named after a real person: Watt, Newton, Kelvin, etc. 81.178.90.168 (talk) 2007-09-20 00:28 UTC
Yes, it is incorrect (in modern usage) to use degrees Kelvin. It is also incorrect to use the person's name (Kelvin) when talking about the unit (kelvin). Similarly the SI units of power (watt) and force (newton) are also lower case. Thunderbird2 05:46, 21 September 2007 (UTC)
- Very useful summary: http://lamar.colostate.edu/~hillger/faq.html (talk) 2007-09-21 11:25 UTC —Preceding unsigned comment added by 81.178.210.249 (talk)
- Their abbreviations are uppercase when named after a person but not the words themselves—that's just how the metric system works. Jɪmp 00:18, 25 September 2007 (UTC)
- From the norm, examples of units starting with an upercase: base SI units: A (intensity), K (temperature), derived coherent SI units: Hz , N, Pa, J, W, C, V, F, S, Wb, T, H, °C, Bq, Gy, Sv,... pom 18:44, 25 September 2007 (UTC)
- Very useful summary: http://lamar.colostate.edu/~hillger/faq.html (talk) 2007-09-21 11:25 UTC —Preceding unsigned comment added by 81.178.210.249 (talk)
Use of place of birth/death
Greetings,
Another user is going around deleting the places of birth and death from the first lines of many bio entries, such as below:
- Lloyd Brown (Lutie, Missouri, October 7, 1901 – Charlotte Hall, Maryland, March 29, 2007)
He claims that including the place of birth and death is a 'violation' of WP: DATE. However, I have not seen a policy forbidding its use. Further, I note that the Encylopedia Britannica uses the above format, which allows for quick skimming. It doesn't make sense to bury the birth/death date info in the main part of the article. The main part of the heading...name, birthplace, birthdate, deathdate, deathplace...allows the reader to quickly establish the parameters (time, area/nation, etc). Thus, my question is of two parts: one, is this against WP:DATE policy and two, if it is, what can we do to change it? Ryoung122 03:10, 14 September 2007 (UTC)
- The first question is easy: the MoS currently says: Locations of birth and death are given subsequently rather than being entangled with the dates. Until July 30, it used to be more strongly worded:
- Locations should be included in the biography portion of the body article. For example, "(12 February 1809 in Shrewsbury, Shropshire, England–19 April 1882 in Downe, Kent, England)" should be separated to "(12 February 1809 – 19 April 1882) … He was born in Shrewsbury, Shropshire, England … and died in Downe, Kent, England".
- The second question is very good. I never completely agreed with this style guideline (not a rule) either. There are many many articles that are in violation; so, there are obviously other editors who feel the same way as well. Neier 08:01, 14 September 2007 (UTC)
- There was never a consensus to soften the wording, but a general overhaul of this guideline resulted in the compression of some instructions. The locations should be separated and placed in the body of the article. Many editors object to adding unimportant details to the opening; look at the talk page for WP:MOSBIO, and this is a recurrent theme. WP is not the Encyclopedia Britannica, has the right to set its own style, and has done so. This seems to surprise some editors who want to copy from the other encyclopedia. Saying that an editor is "going around deleting" sounds like an attempt to paint him or her as a loose cannon. The action was not a deletion, but a move of the information to the body of the article, where it belonged. Chris the speller 00:39, 17 September 2007 (UTC)
- It really needs to be noted that not even close to everyone agrees with this, that birth/death place do not belong in the lead. There are thousands and thousands of bio articles that do put the places in the "(born, died)" lead segment. I prefer it there myself, but my point is that there isn't anything close to actual consensus on that at all. I don't believe this is a matter of sloppiness or "just not thinking about it", either, but rather the product of hundreds, probably thousands of editors' conscious decisions (otherwise I wouldn't bring the matter up). Basically, many of us do not find them to be extraneous or excessive details at all. While birth/death place are less "defining" characteristics than birth/death date, they are nevertheless still defining. Especially when dealing with common names in broad fields (e.g. football (soccer) in which there are many confusable instances of different people with the same given and family names. — SMcCandlish [talk] [cont] ‹(-¿-)› 12:58, 17 September 2007 (UTC)
- Am I right in thinking that there is a consensus to link the dates (day/month and year), if known, in biographies? thanks. Itsmejudith 16:29, 20 September 2007 (UTC)
- Yes for complete dates (July 14, 1968 or 14 July 1968). Partial dates (1999, or July 1832) are disputed. And I'm not certain about longer-than-a-year spans (1960s, 18th century, etc.), but logic would seem to dictate per WP:CONTEXT that they not be linked unless it is genuinely likely to be useful to the reader to do so, as with any other linking being done (e.g. we do not link like this, "The plane crashed around noon, possibly as late as 30:30 pm, during a lightning storm that produced a dark, overcast sky in which the sun was barely visible...") — SMcCandlish [talk] [cont] ‹(-¿-)› 03:54, 21 September 2007 (UTC)
- Very helpful, many thanks. Itsmejudith 15:42, 21 September 2007 (UTC)
- Yes for complete dates (July 14, 1968 or 14 July 1968). Partial dates (1999, or July 1832) are disputed. And I'm not certain about longer-than-a-year spans (1960s, 18th century, etc.), but logic would seem to dictate per WP:CONTEXT that they not be linked unless it is genuinely likely to be useful to the reader to do so, as with any other linking being done (e.g. we do not link like this, "The plane crashed around noon, possibly as late as 30:30 pm, during a lightning storm that produced a dark, overcast sky in which the sun was barely visible...") — SMcCandlish [talk] [cont] ‹(-¿-)› 03:54, 21 September 2007 (UTC)
- Am I right in thinking that there is a consensus to link the dates (day/month and year), if known, in biographies? thanks. Itsmejudith 16:29, 20 September 2007 (UTC)
- It really needs to be noted that not even close to everyone agrees with this, that birth/death place do not belong in the lead. There are thousands and thousands of bio articles that do put the places in the "(born, died)" lead segment. I prefer it there myself, but my point is that there isn't anything close to actual consensus on that at all. I don't believe this is a matter of sloppiness or "just not thinking about it", either, but rather the product of hundreds, probably thousands of editors' conscious decisions (otherwise I wouldn't bring the matter up). Basically, many of us do not find them to be extraneous or excessive details at all. While birth/death place are less "defining" characteristics than birth/death date, they are nevertheless still defining. Especially when dealing with common names in broad fields (e.g. football (soccer) in which there are many confusable instances of different people with the same given and family names. — SMcCandlish [talk] [cont] ‹(-¿-)› 12:58, 17 September 2007 (UTC)
- There was never a consensus to soften the wording, but a general overhaul of this guideline resulted in the compression of some instructions. The locations should be separated and placed in the body of the article. Many editors object to adding unimportant details to the opening; look at the talk page for WP:MOSBIO, and this is a recurrent theme. WP is not the Encyclopedia Britannica, has the right to set its own style, and has done so. This seems to surprise some editors who want to copy from the other encyclopedia. Saying that an editor is "going around deleting" sounds like an attempt to paint him or her as a loose cannon. The action was not a deletion, but a move of the information to the body of the article, where it belonged. Chris the speller 00:39, 17 September 2007 (UTC)
Please archive
This page is getting so long it is causing both IE and Firefox to crash on my system (with 100% reproducibility; it's not a one-time fluke). 68.35.40.113 12:51, 17 September 2007 (UTC)
Change to precision in "Decimal points" section
The text before today's changes was better. There are times when 41.0 actually means 41.0000000 and can be rounded. But there may also be occasions when it should not be rounded. Isn't that what was intended by the old text? Thunderbird2 14:38, 17 September 2007 (UTC)
- Oh dear. I've just read my post again, and it doesn't make sense at all! Concerning this edit, what I meant to say was that there are times when it is appropriate to add more significant figures after a conversion than were used before. For example, 180 degrees is not 3.1 radians, but (approximately) 3.14159 radians. I think that's what the older text was trying to say. Thunderbird2 19:18, 19 September 2007 (UTC)
All dates should be linked
'Wikipedia has articles on days of the year, years, decades, centuries and millennia. Link to one of these pages only if it is likely to deepen readers' understanding of a topic' - I do not think this is a good idea. We should link all dates, partial and full, for enabling the user to browse the almanac section of Wikipedia (ie its collection of articles on years, centuries, etc). It is a great way to enable users to find other events that happened around the same time mentioned in the text. NerdyNSK 03:15, 19 September 2007 (UTC)
- Needless to add, I am a prolific user of Wikipedia's date links and the articles on years, and I use it as a means to browse the wiki to find articles on new topics etc. Many articles do not link all of the dates they contain, and as a user this creates difficulty in my Wikipedia browsing. I believe there must also exist other users who have similar views. NerdyNSK 03:19, 19 September 2007 (UTC)
- This is an age-old issue that has been partially resolved by moving away from the absolute insistence on the linking of every full date, and the active discouragement to the linking of simple years. Decouple the autoformatting and linking functionalities, and I'm all for autoformatting every full date. But we've tried in a very big way, more than once, to be met with a shrug by the developer allocated to the matter. On simple years, I'm sorry, but those who invest time in writing year articles cannot expect that every year be turned bright blue throughout the project. Year pages might be interesting to the minute proportion of readers who have loads of time to follow rabbit tracks to information that has no particular bearing on the subject they've looked up. But most readers want to read the article at hand and be directed to useful, focused, vaguely relevant links, undiluted by year links. Just about every year link I've followed plunges into totally irrelevant information (so and so broke an Olympic record in such and such) in an article on the history of diesel engines. Hello? Tony 03:33, 19 September 2007 (UTC)
- I know about the discouragement of linking simple years; but, when was there a move away from the linking of full dates that allow the date preferences to work? A lot of people have asked for the decoupling; but, I don't recall a concensus that it was acceptable to ignore the date prefs linkage just because of that. Neier 06:17, 20 September 2007 (UTC)
- But, for users like me, having links that lead to irrelevant information is a feature, not a bug. I want to see links to pages that have little or no relevance to the article I'm reading, because I want to be able to discover new information that otherwise I would probably not be able or willing to find it. I have learnt a lot just because some good editors once put a link to a page that is not directly relevant to the article. If all links lead only to other articles that are in the same domain as the one I'm reading, then, as a reader, I feel locked in whatever articles I'm mostly interested in at the moment. The random article link isn't good for various reasons, and the other browsing features (portals, lists) are not as useful as blue links, at least not for the way I am used to surf. Many times I have to copy and paste words from a WP article into the searchbox just because someone thought that no one would ever want to visit article X while reading article Y because in their view they were unrelated. The total solution to the problem, of course, would be a simple software modification to enable links with different importance scores applied on them. 'irrelevant' links could be displayed with the same colour as the article's text by using a simple CSS class. Normal links could be left blue. And very important links could be bold. We could even do this now without software modifications, but software support for importance or relevance scores would make the process much faster. I talked about links in general here, but of course the same apply to dates, as links to dates is the last resort for people who surf in the way I do. Also note that the more links we have, the more we encourage editors to edit new articles. No link = fewer readers = fewer editors. NerdyNSK 04:02, 19 September 2007 (UTC)
- This is an age-old issue that has been partially resolved by moving away from the absolute insistence on the linking of every full date, and the active discouragement to the linking of simple years. Decouple the autoformatting and linking functionalities, and I'm all for autoformatting every full date. But we've tried in a very big way, more than once, to be met with a shrug by the developer allocated to the matter. On simple years, I'm sorry, but those who invest time in writing year articles cannot expect that every year be turned bright blue throughout the project. Year pages might be interesting to the minute proportion of readers who have loads of time to follow rabbit tracks to information that has no particular bearing on the subject they've looked up. But most readers want to read the article at hand and be directed to useful, focused, vaguely relevant links, undiluted by year links. Just about every year link I've followed plunges into totally irrelevant information (so and so broke an Olympic record in such and such) in an article on the history of diesel engines. Hello? Tony 03:33, 19 September 2007 (UTC)
- Not everyone agrees with you; indeed, it is my perception that fewer and fewer do, with a sea change beginning some time around February 2007, and steadily growing since then, against linking bare years (and decades, centuries, etc.) without very clear reasons for doing so. The issue is one of context. Some examples (some real, some made up) and my takes on them (others might disagree somewhat, but I'd bet money that a majority would agree with most of them):
- At Civil rights: "Civil rights activism peaked in the 1960s...", because the 1960s as an "age", a generation, a euhemerized period, is deeply linked with the topic of civil rights activism in Western culture, both ways (mutual interrelation and effect)
- At Jim-Bob Dupree: "Growing up in the 1960s, race car driver Dupree...", because the '60s and a random sportsperson are not inextricably mingled topics.
- At Fluffmosis III: "The king died some time near the end of the 4th century BC, and was entombed at...", because lots and lots and lots of stuff happened in that time period, and a long list of such things is not relevant to readers of this article, and one particular person, even the High King of Numismidia, cannot have had a particularly enormous effect on the period.
- At Sesclo: "The Sesclo culture, ca. 6850–4800 BC...", because the culture straddled the entire span, and was very significant (and using the millennium dates even if specific year articles exist for 6850 and 4800 BC, because they are radiocarbon dating approximations, and as such have no demonstrable relevance to those year articles, or vice versa, at all).
- At Willie Mosconi: "In 1933, Mosconi competed in the Billiard Congress of America (BCA) World Championship tournament. He nearly won the title but lost ... [big snip] ..." into the mid-1950s..." A link to the year as a ding an sich will not provide much if anything of use to a reader of this passage. Same goes for the decade in the later segment. And nothing Mosconi did during those years had a marked effect upon them.
- At Nazi party: "Rising to increased power in the late 1930s...", because Nazism had a major world impact on that time period, and the world impacted back on Nazism.
- Again at Willie Mosconi: "After suffering a stroke in 1956 ... but recovered fully, to win the 1957 BCA World Championship"; again, the 1956 year and Mosconi are not interrelated in any way other than coincidence. However a World Championship victory is significant, and might be worth comparing to related and competing events in the same year as at the 1957 in sports article that the "1957" points to (or something more specific, such as a 1957 in pool, if available), and the title should also be listed in 1957 in sports, such that the two articles, on this particular point of international significance, are in fact inter-related. But not 1957, again because that calendrical article does not help the Willie Mosconi reader, and Mosconi's big win here did not have any serious effect upon the world in that year (though it was certainly notable specifically in the sporting context).
- I could go on, but I think the point is probably pretty clear by now. If there is no particular context or relevance, that runs both ways, then don't link a bare year/decade/century/millennium date (and especially not a day, like Wednesday! A link to that day article woudl be appropriate at something like Woden, but not as part of a date in a random article.) Such linking is a readability problem and offers little value to the reader.
- NB: Anyone should of course feel free to borrow any of the above and rework it if the MOS should say something more specific on this topic than it presently does (I think it should, but I've been involved in enough MOS disputation this week to last me for several months, so I think I may back out for a while after those particular debates calm down).
- — SMcCandlish [talk] [cont] ‹(-¿-)› 09:51, 19 September 2007 (UTC)
- I think Nerdy NSK's comments (particularly "I want to see links to pages that have little or no relevance to the article I'm reading") go against WP:CONTEXT, a WP style guideline. If you feel that guideline is wrong, you may want to discuss it there. I, however, also disagree. If you want to learn things that are irrelevant to what you're looking at, you can look up a random date or use the random article function. Rigadoun (talk) 20:31, 19 September 2007 (UTC)
- There's also, of course, WP:BTW... NerdyNSK —Preceding signed but undated comment was added at 02:04, 20 September 2007 (UTC)
- Hmmm, yes, it's an embarrassment to the project, that one: have you read it? (1) The register is way out of whack with WP's guidelines—comes down to vague musings, suggestions, statements of philosophy, and you're left wondering what exactly it's there for. Should be an essay. (2) There was no consensus on making it a semi-guideline and then a guideline. (3) There appears to be ownership going on there, by a small clique, or worse, one person. (4) It's in contradiction with MOS, MOSLINK and MOSNUM in some respects. Tony (talk) 02:38, 20 September 2007 (UTC)
- Funny how you see WTB as ownership going on there, by a small clique, or worse, one person - the fact is that I am afraid the idea of limiting links is also the work of a clique. I would like to know exactly how many people support either view. NerdyNSK 03:53, 20 September 2007 (UTC)
- Hmmm, yes, it's an embarrassment to the project, that one: have you read it? (1) The register is way out of whack with WP's guidelines—comes down to vague musings, suggestions, statements of philosophy, and you're left wondering what exactly it's there for. Should be an essay. (2) There was no consensus on making it a semi-guideline and then a guideline. (3) There appears to be ownership going on there, by a small clique, or worse, one person. (4) It's in contradiction with MOS, MOSLINK and MOSNUM in some respects. Tony (talk) 02:38, 20 September 2007 (UTC)
- There's also, of course, WP:BTW... NerdyNSK —Preceding signed but undated comment was added at 02:04, 20 September 2007 (UTC)
- I think Nerdy NSK's comments (particularly "I want to see links to pages that have little or no relevance to the article I'm reading") go against WP:CONTEXT, a WP style guideline. If you feel that guideline is wrong, you may want to discuss it there. I, however, also disagree. If you want to learn things that are irrelevant to what you're looking at, you can look up a random date or use the random article function. Rigadoun (talk) 20:31, 19 September 2007 (UTC)
- (outdent) "WTB"? You mean BTW? Please provide a link to the consensus. Fact is, there was none. Now, if there were a way of linking years that didn't splatter more bright underlined blue over the text (thus diluting valuable links and reducing readability and neatness), I wouldn't mind if every year were linked. Just click on any (black) year and up comes the year page: sure. It's feasible, technically, but getting the developers to act on these matters is like trying to push an ocean liner. Until that happens, linking years is a real problem. Tony (talk) 05:22, 20 September 2007 (UTC)
- Sorry, it was WP:BTW. NerdyNSK 05:43, 20 September 2007 (UTC)
- For me, blue links do not detract from readability. Therefore I follow a policy of "if in doubt, link first use". Not for years particularly - I mean quite generally. But this is subjective. How do we find out what *readers* think? Thunderbird2 06:59, 20 September 2007 (UTC)
- Sorry, it was WP:BTW. NerdyNSK 05:43, 20 September 2007 (UTC)
- I first sorted out the issue in my mind shortly after I started on WP, when a friend who was a casual reader of WP queried why every year was blue, and expressed irritation at the feature. Then I delved into the matter and realised that those who invest time and energy into writing year articles were very reluctant to give up the privilege of having many many links to their articles. Thus, factions had formed, and continue, although the matter seems to have been settled in favour of not linking trivial chronological items for the sake of it. I'd love it if the WikiMedia Foundation were lobbied to overhaul the linking and autoformatting systems: they need to be decoupled and made more flexible. There are at least half a dozen issues. Tony (talk) 09:01, 20 September 2007 (UTC)
- I can sort of understand why we would want dates to be linked. It does enable people to quickly figure out if two events coincide. However, this is a large world and events that only coincide temporally are usually not related. I don't think clicking linked dates is common practice. So here's a suggestion: add a configuration option in the preferences called "link dates" that is by default turned off. That way we can have properly autoformatted dates everywhere, the links only show up for people who like them, and everyone is happy. If the developers are too busy or lazy to program this, we can do it ourselves if necessary. I hear it's written in PHP. A scripting language, how hard can it be? And even if we can't get this functionality in MediaWiki, we can still as a last resort use Wikipedia's own site-wide JavaScript to remove link from dates. Shinobu 16:31, 26 September 2007 (UTC)
- And when we finish this discussion, let's submit a feature request. The developers are no mindreaders, and no one can expect them to implement something if no one tells them what we want. Shinobu 18:53, 26 September 2007 (UTC)
- I first sorted out the issue in my mind shortly after I started on WP, when a friend who was a casual reader of WP queried why every year was blue, and expressed irritation at the feature. Then I delved into the matter and realised that those who invest time and energy into writing year articles were very reluctant to give up the privilege of having many many links to their articles. Thus, factions had formed, and continue, although the matter seems to have been settled in favour of not linking trivial chronological items for the sake of it. I'd love it if the WikiMedia Foundation were lobbied to overhaul the linking and autoformatting systems: they need to be decoupled and made more flexible. There are at least half a dozen issues. Tony (talk) 09:01, 20 September 2007 (UTC)
Suggestion for addition to the unit section: artillery calibres
I have stumbled on cases where French battleships were said to have N-inch guns; while the measure might be more or less accurate, the French do not use imperial units, and the guns are named "M-mm gun" (just like it'd be accurate but ridiculous to measure the calibre of the guns of a US battleship in furlongs).
I think that the same is true of German, Italian, Russian and Japanese ships.
We might want to consider setting a rule that calibres must be given in the unit featured in the official name of the gun — hence the Jean Bart had 380 mm (15 inch) guns, the USS Massachusetts had 16 inch (406 mm), the Yamato had 460 mm (18.1 inch) guns, the Vanguard had 15 in /42 (380 mm) guns, the Tirpitz had 380 mm (15 in) guns, and so forth. Rama 10:25, 20 September 2007 (UTC)
- We do not need a special guideline for that. Just be bold and do it. In the unlikely event of an objection, just quote the existing guidelines:
- For US-related articles, the main units are US units
- For other country-related articles, the main units are metric
- ... put the source value first ...
- I would suggest that millimeters can remain unconverted in military applications, since they appear to be universal. Lightmouse 10:34, 20 September 2007 (UTC)
- I would like to note a little nitpick: the official names of WWI and WWII German guns were generally in centimeters, not millimeters, so Tirpitz carried 38 cm guns. TomTheHand 14:28, 20 September 2007 (UTC)
- Modern artillery is indeed universally metric, but this is definitely not the historical case. Even into WWII, the British often described artillery by projectile weight (e.g., 25-pounder on a tank), and this is nearly universal historical practice from the mid-19th century back. Calibers did appear often, but not universally, during the American Civil War. Again, I come back to where you said For US-related articles, the main units are US units, and ask again if you are thinking US versus everyone else. The Battle of Trafalgar, for example, was fought by French and British ships, all of which described their guns and carronades in projectile weight, not metric and not Imperial caliber. At the battle of the Spanish Armada (actually involving multiple countries and principalities), the flagships Ark Royal and São Martinho measured their batteries in pounds. Much of the Dreadnought revolution, of which British Admiral "Jacky" Fisher was the enfant terrible, used calibers of inches to refer to generations of capital ship batteries.
- My fundamental point is that as much as you might like a universal rule, you aren't going to get one and be historically accurate. Please leave some of this to the judgment of writers. Bluntly, simply knowing metric diameters of shells doesn't give solid information alone: a US shell referred to as 16"/45 (406mm), the latter being the length of the barrel in diameters, was indeed a 406mm, but had more penetrating power than a Japanese 460mm (18.1 inch). The US has a series of guns that are 5"/127mm, but there is a significant difference in performance based on barrel length: 5"/38, 5"/54, 5"/62, and 5"/74. I've never seen the barrel lengths metricated, although I suppose they could be -- it's more of a dimensionless constant.
- Note that I put the units but In WWII, while the Soviets were mostly metricated, they made a point (attributed to Stalin himself) that each caliber in millimeters would be different, to avoid the Anglo-American problem of ordering a shipment of 75mm ammunition and getting naval shells instead of light artillery shells. Eventually, there was a technical reason why both a howitzer and rocket needed to be 122mm, so the rockets were always called Katyushkas (and GRAD in their successor), never a caliber, to avoid confusion Howard C. Berkowitz 15:41, 20 September 2007 (UTC)
- Points raised by others (cm, inches, pounds, non-US) seem reasonable. However, please note that my comment was confined to values expressed in *mm* within the source data. Lightmouse 17:34, 20 September 2007 (UTC)
- Well... I'm not sure that I agree that a caliber in mm doesn't require an English/Imperial/U.S. conversion, for two reasons. First, while even the U.S. Army uses gun calibers that are defined in metric, many average Americans will better understand the size of the shell if they see it in inches as well. Second, English units will very often help to explain where the heck such odd calibers came from. For example, 7.62 mm? Why, that's 0.30 inches. 152 mm artillery? Six-inch guns. TomTheHand 18:27, 20 September 2007 (UTC)
- Seconded. It's no burden to convert each value, once or twice, in article, in either direction. Metric is currently almost universal for this, but articles should stick primarily with source information, be it in pounds, inches, or centimetres. Sacxpert 09:37, 1 October 2007 (UTC)
Create list of suggested currency abbreviations?
- [Discussion moved over from WT:MOS as off-topic there.]
I was reading MOS to see how to format Canadian currency, for an article on tips. WP:$ currently has two examples of dollars, in passing; Australian as AU$1 and U.S. as US$1. If interpreted to recommend two capital letters followed by a dollar sign, then Canadian would be CA$, but the Canadian dollar article says the Canadian government and IMF favor C$, while Editing Canadian English advises $Can or $CDN, and its only mention of CA$ is in software packages. My best guess would be to use C$, but whatever is chosen, it seems that a list of recommended currency abbreviations would be helpful in the MOS. If the XX$ format is recommended for dollars, New Zealand NZ$ and Jamaican JA$ are reasonably accepted, but Bahamas or Barbados (both beginning with "ba") also use dollars. ISO's two-letter country codes (that link also includes ISO's standard three-letter currency names) suggest BS and BB as country codes, so BS$ and BB$ (even if never used before) would be a way to follow the two-letter pattern, but B$ and Bds$ are suggested in Bahamian dollar and Barbadian dollar. Three-character ISO currency codes (BSD and BBD) could somehow be used, but that's inconsistent with using US$ and AU$. MOS suggests linking the symbol to a page about an obscure currency (₮146), which helps clarify the intent in any case. Prospect News' style guide has a list of their own recommended currency abbreviations, as a point of comparison. -Agyle 20:56, 19 September 2007 (UTC)
- So why not be bold and create the list? Then we have a place to begin discussion of specific currencies. --JodyB yak, yak, yak 11:58, 20 September 2007 (UTC)
- I'd prefer using the ISO 3 character currency code (CAD) as being the definitive unambiguous version. If use of symbols is desired, I would combine with either 2 or 3 letter country codes as $CA or $CAN. $CDN doesn't lead to any extensible scheme to name world currencies. Mayalld 13:35, 20 September 2007 (UTC)
- Jody, point taken. :-) I'll try to do that. Any guidance on approach (e.g. Mayalld's opinion) would be helpful. -Agyle 17:32, 20 September 2007 (UTC)
- I like the ISO codes too. Inasmuch as that is used by the banking community, or so says the list, it would be an appropriate guide. --JodyB yak, yak, yak 18:39, 20 September 2007 (UTC)
- Some comments: First, "$US" isn't used by much of anyone, and should be advised against. "US$" is more readily understood by most readers than "USD", which many readers will not even recognize as a currency indicator if they do not work in the financial industry. Just because someone somewhere for some context has come up with a standard does not mean that the standard should be applied in all situations (really clear case in point: we write "Juana Ortiz was born in Mexico" not "...in MX", despite MX being the ISO 2-letter code for Mexico, and that system of 2-letter codes is a broadly accepted international standard. — SMcCandlish [talk] [cont] ‹(-¿-)› 01:15, 21 September 2007 (UTC)
- I find it immensly odd that the wikipedia "standard" is to make up an abbreviation that you think the reader will understand, and only if one is not readily to hand or may be ambiguous, then fall back to the international standard three-letter codes. Many people will already have seen those codes anytime they book a flight, or do currency conversion. The ISO lists are readily available and WP should use that standard. Let the standards bodies manitain the list at their expense too. anon 2007-09-21 01:30 UTC
- Huh? That's what I'm arguing against ("$US", "$C", "£UK", etc. are neologistic silliness). If you are referring to "US$", "C$", "GB£", etc., these are not Wikipedia inventions but common parlance; as far as I can tell so far there are used everywhere except in the banking industry and in financial journalism, where USD, CAD, GBP, etc. are preferred, but which few outside of finance recognize. Please do not confuse the existence of one organization's published standard for evidence that all other systems of notation are ergo necessarily random gibberish. It's just isn't so. — SMcCandlish [talk] [cont] ‹(-¿-)› 12:00, 21 September 2007 (UTC)
- Candlish, your Mexico example doesn’t apply, because the discussion was about the choice of which abbreviation or symbol to use, not about whether to use one. In large tables with many country entries, MX would be an accepted substitute for Mexico.
- I didn't get the point across clearly then (on a re-read, I'm certain that I didn't, as I was not very clear); it is: "Wikipedia does not apply a nomenclature standard simply because it exists; an actual rationale for using it (especially versus any competing conventions) must be presented, tested/argued, and agreed upon by consensus." — SMcCandlish [talk] [cont] ‹(-¿-)› 23:39, 21 September 2007 (UTC)
- I’m absolutely fine with ISO abbreviations to avoid any country-centrism, but as a compromise I suggest to allow the replacemnt of the letter standing for the currency name, not the country (or similar issuing body, like the EU), by an established and readily available symbol, thus USD and US$, GBP and GB£ would be fine.
- Anyhow, I find it more distracting that currencies, unlike all other units, are often put before the value (and also unspaced), not after it. — Christoph Päper 18:16, 21 September 2007 (UTC)
- Um, but that's simply how it is done (universally as far as I can tell; Spanish speakers do not write "5,000–USD"; this is not an "Americanism" issue at all, if that is your implication. — SMcCandlish [talk] [cont] ‹(-¿-)› 23:39, 21 September 2007 (UTC)
- I'd prefer using the ISO 3 character currency code (CAD) as being the definitive unambiguous version. If use of symbols is desired, I would combine with either 2 or 3 letter country codes as $CA or $CAN. $CDN doesn't lead to any extensible scheme to name world currencies. Mayalld 13:35, 20 September 2007 (UTC)
Related articles: List of circulating currencies, ISO 4217 and Currency sign. --Gadget850 ( Ed) 09:27, 21 September 2007 (UTC)
This entire discussion is about 90% a waste of time, engery and brain cycles, since as WP:MOSNUM advises, the first occurrence of any currency term should be wikilinked to the article on that currency to begin with, thus obviating any confusion: "2 million dollars", "USD2,000,000", "US$2,000,000". —Preceding unsigned comment added by SMcCandlish (talk • contribs) 12:04, 21 September 2007 (UTC)
- "2 million dollars" is no good: the wikilink won't show in print (such as Wikipedia 1.0). The others are fine, though (if by "USD2,000,000" you mean "2,000,000 USD"), but a little standardization wouldn't be bad. Personally, I like the ISO approach (where spelling the whole thing out is not suitable). -- Jao 18:39, 21 September 2007 (UTC)
- I'm going to say something I've said a few times in the past: context matters. To this tune, SMcCandlish made a good point when he observed that the ISO three-letter codes are barely recognised outside finance. For this reason, I would not support using ISO in all contexts. Most newspapers would us "US$" when talking about US dollars outside their business section. The ISO standard is only appropriate in specialist finance articles, or where there are too many currencies in the same article for US$, NZ$, C$ etc. to be viable.
- To address the original issue, it might be worth having some standard abbreviations (i.e. is Australia A$ or AU$? In New Zealand, we use A$.)—worth a try, anyway, I don't know how workable it'll be though. The principle is clear, though, so don't forget about it in the midst of details: the standard symbol and standard country specifier should be used, be put in the correct place (US$100 not 100 US$) and ISO codes may be used only in specialist finance articles. Neonumbers 01:26, 22 September 2007 (UTC)
- In Australia, it's mostly "A$". Tony (talk) 10:42, 30 September 2007 (UTC)
- Neonumbers said: "To address the original issue, it might be worth having some standard abbreviations". Agreed. So why not just use those in ISO 4217 rather than inventing the wheel, yet again, and making yet another new standard. The idea of standards is that once you have seen something in one place, it will be the same in other places. WP already has a page on ISO 4217 and hundreds of other sites also list the codes. 2007-10-01 11:45 UTC 85.210.15.78 —Preceding unsigned comment added by 85.210.15.78 (talk)
- In Australia, it's mostly "A$". Tony (talk) 10:42, 30 September 2007 (UTC)
Any reason the remaining dispute tag can't be removed?
It's on "Autoformatting and linking". Can't see the point of the continued presence of the tag. Tony (talk) 08:34, 24 September 2007 (UTC)
Abbreviation for nautical mile (M, NM, nm or nmi) and knot (kn, kt or kts)
Moved from Talk:B-2 Spirit (begin)
I don't agree that nm is a "standard" abbreviation for nautical mile. For maritime use, the only internationally accepted abbreviations I know of are nmi and M. Do aviation users have a different standard? Thunderbird2 11:23, 19 September 2007 (UTC)
- Don't you think that the fact you're going around to LOTS of articles and having to change this is a hint? These are airplanes and it's a long-standing abbreviation used for aircraft. Read the article on the Nautical mile and you'll see that this is an accepted abbreviation and the standard abbreviation when used for aircraft.--Asams10 11:39, 19 September 2007 (UTC)
The nautical mile article states that nm is in widespread use, but not that it is a standard in any sense. I do not see anything in it specific to aircraft though, so perhaps I am missing something. I accept the possibility that aviation authorities may use different standards to the maritime ones referred to there, but I would like to see evidence for this. Do you have a verifiable source for your statement that nm is "the standard abbreviation when used for aircraft"? Thunderbird2 12:02, 19 September 2007 (UTC)
- Perhaps I can ask you to provide a verifiable source that says that NMi should be used for Aircraft?--Asams10 12:57, 19 September 2007 (UTC)
The IEEE lists nmi as its preferred abbreviation, regardless of application. I think the American Institute of Physics does so to but I would need to check. I know of no international authority that recommends nm as an abbreviation for nautical mile. Thunderbird2 14:01, 19 September 2007 (UTC)
- Even wikipedia conversion template uses the NM default. Template:NM_to_km --Asams10 14:11, 19 September 2007 (UTC)
The Wikipedia template is not an international authority on aviation terminology. Here are the IEEE guidelines. I will look up the equivalent AIP advice. Thunderbird2 14:21, 19 September 2007 (UTC)
- Last I heard, IEEE didn't dictate distance measurement standards. Try the FAA. They use NM. --Asams10 14:40, 19 September 2007 (UTC)
So the abbreviation/acronym probably should be NM or at least nmi or M. I think the first 2 are clear to most, while M is probably not. If the first use is linked, there's no room for confusion anyway. -Fnlayson 15:03, 19 September 2007 (UTC)
- The FAA is good enough for me. Can we agree on NM then (linked on first use)? Thunderbird2 15:09, 19 September 2007 (UTC)
I'm a little hesitant to use the above FAA document, because every entry in the glossary is capitalized. It may be that the FAA thinks NM should be capitalized, but it may also be that as a formatting issue every entry was capitalized. I think the FAA would be an excellent thing to rely on as long as we could see that the FAA uses NM in contexts in which everything isn't capitalized. *Tom does some Googling* This search seems to show that the FAA uses both "nm" and "NM" frequently. Sorry, I'm not trying to just make trouble; I don't have a definite answer. TomTheHand 17:19, 19 September 2007 (UTC)
- When I see nm, I think nanometer, not nautical mile! 17:55, 19 September 2007 (UTC) —Preceding
unsigned comment added by Rangek (talk • contribs)
- I'm an aerospace worker. I see NM I think Nautical Mile. I doubt very much the two would be confused in use. If the B-2 really had a range measured in nanometers, we'd probably not have bought them.--Asams10 18:04, 19 September 2007 (UTC)
I see no conflict between nm for nanometre and NM for nautical mile. TomTheHand has a good point though about a possible ambiguity in my interpretation of the FAA guidelines. Can anyone confirm that upper case letters are intended throughout (and not just used by default)? Thunderbird2 18:14, 19 September 2007 (UTC)
- The FAA jurisdiction is just US aviation. There is also CASA, CAA, JAA, CAAC etc. By international agreement (Chicago Convention) they all use ICAO standard units or notify deviations from it. So ICAO would be a good place to look. The nautical mile is also used in shipping worldwide. So Wikipedia must address the domains of shipping+aviation and have a worldwide scope. Given the wide scope of this unit of measurement, I propose moving this discussion to Wikipedia talk:Manual of Style (dates and numbers) unless anyone objects within 24 hours. Lightmouse 09:55, 20 September 2007 (UTC)
A discussion on maritime abbreviations was held on the SHIPS talk page. The (cautious) consensus there was for using nmi, but the discussion was archived recently without having reached a clear cut conclusion. I support Lightmouse's proposal to move the discussion to MOS, but then I would ask for its scope to be broadened to include kn vs kt for the knot (see knot talk page). Thunderbird2 10:14, 20 September 2007 (UTC)
- Following Lightmouse's tip, I've been looking for an authoritative ICAO publication. The best I can find is this Australian document that compares their national regulations with ICAO guidelines. Although not the final word, it seems to give the nod (for aviation use) to NM for nautical mile and kt for knot. Am I reading it correctly? Thunderbird2 14:29, 24 September 2007 (UTC)
I'm given to understand that the capitalized NM is used and that the lower case nm is used to denote nanometers. Hmmm, I thought kt denoted kilotons of yield for a nuclear warhead? --Asams10 14:55, 24 September 2007 (UTC)
- Yes, it seems that NM is the preferred abbreviation for aviation, which solves the problem with the nanometre. For the knot both IEEE and AIP prefer kn, presumably for the reason you state. Can we agree on NM at least (for articles related to aviation)? Thunderbird2 17:09, 24 September 2007 (UTC)
I would support the idea of using NM for aviation articles, certainly all the official aviation documents I have seen use either NM or nm and never nmi. Perhaps if contentious this should be brough up on either Wikipedia talk:WikiProject Aircraft or Wikipedia talk:WikiProject Aviation rather than in just one aircraft article. MilborneOne 17:34, 24 September 2007 (UTC)
Moved from Talk:B-2 Spirit (end)
Lightmouse 19:20, 24 September 2007 (UTC)
- @Rangek: funny, I thought the same thing. It was a long journey: 500 nanometer. Shinobu 16:23, 26 September 2007 (UTC)
- The SI authority has a table of old non-SI units. It says:
- nautical mile: "the symbols M, NM, Nm, and nmi are all used; in the table the symbol M is used"
- knot: "There is no internationally agreed symbol, but the symbol kn is commonly used."
- I am sure the SI authority wanted to avoid using 'nm' and 'kt' because they are already used. Several people here also mentioned that issue. Note that a lot of articles use [[Category:Conversion templates|convert templates]], so these should match any decision here. Lightmouse 11:01, 29 September 2007 (UTC)
- The SI authority has a table of old non-SI units. It says:
I wish to summarise the facts and make a proposal. As I understand them, the facts, first for the nautical mile:
- The abbreviation NM is preferred by the ICAO for nautical mile
- The abbreviation nmi is preferred by the IEEE for nautical mile
- The symbol nm is reserved by SI for the nanometre
and for the knot:
- The abbreviation kt is preferred by the ICAO for knot
- The abbreviation kn is preferred by the IEEE and the AIP for knot
- The symbol kt is reserved by SI for the kilotonne
I cannot imagine everyone agreeing to use the same abbreviation, so my proposal is to offer a choice. For the nautical mile:
- permit use of NM and nmi for nautical mile
- discourage use of nm for other than nanometre
and for the knot:
- permit use of kn and kt for knot
- recommend use of kn
Comments anyone? Thunderbird2 23:18, 29 September 2007 (UTC)
- I would like to go one step further and declare one preference for each unit, and strongly discourage any overlap with SI units:
- preferred usage is nmi for nautical mile and kn for knot
- do not use nm for nautical mile and kt for knot, because they conflict with SI units nm (nanometer) and kt (kiloton)
- An exception for NM as alternative to nmi could be made.−Woodstone 09:59, 30 September 2007 (UTC)
- Sounds like a good plan. I'd prefer Woodstone's version, but getting consensus for Thunderbird's "preference" system would probably be easier. Sacxpert 09:52, 1 October 2007 (UTC)
- One issue I'd like to bring up is that English-speaking navies overwhelmingly use nm for nautical miles and kt for knots. I understand the issue of overlap with SI, and I understand that it's important to try to use units with less ambiguity, but I think it's also important to point out that when you're saying that we should not use nm and kt, you're saying we shouldn't do what perhaps the most important professional organizations to use these units do.
- I'm sorry, Thunderbird, I know you and I have discussed this for a long time, and I don't want you to think that I'm suddenly withdrawing from my willingness to compromise. I'm just sometimes bothered by the way we talk about these issues, as I think actual usage is as important as SI's recommendations, if not more so. TomTheHand 14:47, 1 October 2007 (UTC)
- I too would prefer a single recommendation, if this can be realised. Putting aside the knot for a moment, is there any mileage in following ICAO by suggesting NM as the preferred abbreviation for the nautical mile? I don't agree that following navy practice is wise if it conflicts with both aviation authorities and SI. Thunderbird2 10:46, 6 October 2007 (UTC)
Following the deafening silence in support of NM, I return to my previous quest for consensus, and suggest the following specific text to go in 4.3 Unit Symbols and Abbreviations:
- Avoid use of unit abbreviations that have conflicting meanings in common units systems such as SI and US customary units.
- Use NM or nmi to abbreviate nautical mile rather than nm;
- Use kn to abbreviate knot rather than kt or kts;
- Link such units to their definitions on first use.
I imagine that the list of potential clashes is not limited only to the knot and nautical mile, and the proposed text is deliberately written in such a way as to facilitate additional entries. Comments and counter-suggestions are invited. Thunderbird2 12:00, 13 October 2007 (UTC)
- I would still prefer to suggest a single preference. Proposal (in line with "mi" for mile):
- Use nmi (or NM) to abbreviate nautical mile rather than nm;
- −Woodstone 12:37, 13 October 2007 (UTC)
- I've been trying to be consistent with nmi, on the weird chance someone would confuse nautical miles and nanometers. Knots remain a challenge, as I can't think of anything -- perhaps "knots" -- that couldn't be ambiguous, if only pedantically such as kilotons and knots. While I recognize there are formal conventions on when to capitalize a prefix and not, they are so little followed that I'd rather not depend on them.
- I did find that someone had inserted "(370.4 km)", with one decimal point, after I citied the international treaty language of a 200-nautical mile Exclusive Economic Zone. May I note that that was an treaty developed by many nations, including those using SI, and, while they found it appropriate to disambiguate miles versus nautical miles, they did not. Seeing the 0.4 following an integer authoritative measurement, to me, just feels wrong. In such cases, I would recommend the usual rounding practice: truncate if the first decimal point is less than 0.5, and round up the integer if it is 0.5 and above. This is said in the interest of consensus; I really don't think that any other systems should go into treaty or other legal descriptions, except those that were used by the legal drafters. Howard C. Berkowitz 15:48, 13 October 2007 (UTC)
- You are demonstrating a serious deficiency in your understanding of "precision" and significant digits and the like. When somebody talks about a 200 mile EEZ, there is absolutely nothing about the precision of that number that would prevent us from expressing it as 1,215,223.097 ft or with even more precision. That is not a measured quantity; it is a defined quantity. It has infinite precision. It is only practical considerations of what could reasonably be measured that constrain us, and in most cases this distance could in fact be measured to within a tenth of a kilometer. ~!Gene Nygaard —Preceding signed but undated comment was added at 18:56, 13 October 2007 (UTC)
- I just messed up entering the tildes above. But in this particular case, expressing it as 370 km is also problematic. That doesn't show you that in fact it is actually accurate to the nearest kilometer. Rather, it looks like it might only be much rougher, only accurate to the nearest 10 kilometers. Gene Nygaard 19:03, 13 October 2007 (UTC)
Imperial vs Metric: Keeping measured values straight in scientific and technical articles
Many of the sources I use for scientific articles give values in Imperial units. So for those data, I use the cited Imperial units as the primary value in scientific articles I contribute to and give a calculated approximate value for SI/metric following it in parenthesis. But then you have people who just hate Imperial units (I don't much care for those units either, but I keep that to myself when accuracy is concerned) and either switch the calculated approximate value for the cited one or they sometimes delete the Imperial completely. Then somebody else will often come by later and do another conversion and sometimes a switch in priority; now we a significantly incorrect datum.
I find this intolerable because it is replaces a cited value with something that is not in the cite and that can easily lead to something that is less accurate. So while I generally agree that scientific/technical articles should prefer SI/metric, I don't think that should be done to the detriment of article accuracy. So here is what I propose:
- Never remove a cited value simply because it is in an Imperial unit. Instead, add the cited value to the reference while giving properly calculated SI/metric units preference in running text. For example "The tree grows to an average height of 4.6 m (15 ft) during its life cycle.<ref>Given as 15 ft in Doe, John (1995). ''Trees'', page 456</ref>
This would make the article text consistent by always having SI/metric units first, have Imperial in parens as appropriate (for accessibility purposes), while making sure that the original cited (often measured!) value is preserved. --mav 01:39, 26 September 2007 (UTC)
- The MOSNUM clearly states that in scientific articles where there is consensus among the contributors not to convert the metric units...
- That does not say you now have license to remove any and all non-SI values from articles that you deem scientific. Mass removal of conversions is what I stated would happen (here) if we entered this "scientific" clause. Any conversions that were removed should be replaced.
- As for having SI units stated first in scientific articles despite the fact that Imperial units are the cited units, yes we had that discussion before (here) and we were all ok with that too. —MJCdetroit —Preceding signed but undated comment was added at 03:40, 26 September 2007 (UTC)
- We are not all okay with that. And I am not okay with the vagueness of calling something a "scientific article" either. Gene Nygaard 19:45, 9 October 2007 (UTC)
- I never did get round to tossing my tupence-worth into that discussion. Scientific context or otherwise, I'm happy with metric units' being stated first if and only if it is noted using
<ref></ref>
wherever these are not the units given by the source. The case of conversions from metric where context calls for preference's being given to non-metric should be treated similarly. In general, I'd have it a requirement that any conversions either be given as secondary (e.g. in brackets) or duely noted as such. Seems only reasonable to me. Jɪmp 04:26, 26 September 2007 (UTC) ... Yesterday's unfinished sentence finished today in brown. Jɪmp 00:35, 27 September 2007 (UTC)
- I never did get round to tossing my tupence-worth into that discussion. Scientific context or otherwise, I'm happy with metric units' being stated first if and only if it is noted using
- Sorry to appear dumb, but I'm confused. Mav, is your quote about the tree a direct quote or a paraphrase? For direct quotes, an original Imperial unit must be retained, of course, with the conversion in square brackets rather than parentheses. That much, I hope, doesn't need to be spelt out in the guideline.
- Assuming that it's a scientific article, if it's a paraphrase, doesn't it depend on whether consensus has allowed metrics only (in which case, use the metric equivalent unconverted), or not (in which case, use metrics as main with Imperial the converted unit/value, even if the original you're paraphrasing used Imperial)? Please correct me if I've got it wrong. Tony (talk) 04:40, 26 September 2007 (UTC)
- The example is a paraphrase, not a direct quote. I concede (and agree) that priority should be given to SI values. What I would like, is an addition to the guideline that covers situations where the cited (often measured) data are in Imperial units. My simple suggestion was to require that the actual value and units be given in the citation. Simply removing the Imperial units or even giving them lower priority when the cite uses them is not acceptable from an accuracy and maintenance standpoint. --mav 14:08, 26 September 2007 (UTC)
- Comment: I suspect that this issue affects only a minority of articles. Most scientists use SI. Shinobu 16:19, 26 September 2007 (UTC)
- Scientists? That is beside that point for an encyclopedia (which is primarily a tertiary source constructed from secondary sources). This issue affects a high percentage of any articles that rely heavily on secondary sources produced in the United States. --mav —Preceding signed but undated comment was added at 17:29, 26 September 2007 (UTC)
- I'm a scientist and I don't use SI exclusively. In fact, in my field only small "bench batches" (not more than 1,000 g) are weighed in the metric system everything else is done in U.S. Customary.
- Scientists? That is beside that point for an encyclopedia (which is primarily a tertiary source constructed from secondary sources). This issue affects a high percentage of any articles that rely heavily on secondary sources produced in the United States. --mav —Preceding signed but undated comment was added at 17:29, 26 September 2007 (UTC)
- Comment: I suspect that this issue affects only a minority of articles. Most scientists use SI. Shinobu 16:19, 26 September 2007 (UTC)
- The example is a paraphrase, not a direct quote. I concede (and agree) that priority should be given to SI values. What I would like, is an addition to the guideline that covers situations where the cited (often measured) data are in Imperial units. My simple suggestion was to require that the actual value and units be given in the citation. Simply removing the Imperial units or even giving them lower priority when the cite uses them is not acceptable from an accuracy and maintenance standpoint. --mav 14:08, 26 September 2007 (UTC)
- I agree with what Mav was saying, these articles are meant to be read by anyone and not just us scientists. None of the other online encyclopedias like Britannica or Encarta present [scientific] information from a metric-only POV. —MJCdetroit 18:12, 26 September 2007 (UTC)
- I rather like Mav’s recommendation. Ask the average person which appears more correct, and most will say “4.6 m”, not “15 ft”. It’s an illusion of accuracy generated by the decimalization of the conversion. It’s also not uncommon for these conversions to go back and forth a few times as they go from one source to the next. While most editors won’t mess with clearly quoted measurements, it is not at all uncommon for someone to switch “15 ft (4.6 m)” to “4.6 m (15 ft)”, if only for consistency in the article, and thereby creating a false impression of which is the more accurate datum. If the original measurement was in US or imperial units, but the article (scientific or technical or not) chiefly gives preference to SI, then asking for some footnote to “ground” the original and most accurate measurement seems to me to be a very good idea. Askari Mark (Talk) 18:02, 26 September 2007 (UTC)
- Data should be cited as given, with the possible exception of obviously approximate figures (when the source says "roughly 10 miles away", this is sufficient justification for saying "about 15 kilometers" and conversely). If a footnote, or a note on the source ("Data from this book in Imperial units") will help us to do so, then we should. Septentrionalis PMAnderson 18:16, 26 September 2007 (UTC)
- I rather like Mav’s recommendation. Ask the average person which appears more correct, and most will say “4.6 m”, not “15 ft”. It’s an illusion of accuracy generated by the decimalization of the conversion. It’s also not uncommon for these conversions to go back and forth a few times as they go from one source to the next. While most editors won’t mess with clearly quoted measurements, it is not at all uncommon for someone to switch “15 ft (4.6 m)” to “4.6 m (15 ft)”, if only for consistency in the article, and thereby creating a false impression of which is the more accurate datum. If the original measurement was in US or imperial units, but the article (scientific or technical or not) chiefly gives preference to SI, then asking for some footnote to “ground” the original and most accurate measurement seems to me to be a very good idea. Askari Mark (Talk) 18:02, 26 September 2007 (UTC)
- People, you are misreading what I typed. This discussion is about the use of imperial units from scientific sources. Read that again, read the OP's statement and then read my original comment again, please. I also again assert that most scientists use SI. The one or two that don't are what people call "the exceptions that prove the rule", much like the popular story about the grandmother who smoked five packs a day and lives to become 98 years old, still going strong. Shinobu 18:41, 26 September 2007 (UTC)
- I say let's not simply ask for some footnote but insist upon it wherever the source units are not given as the primary units (of course, with the exception noted by Anderson wherein the source is obviously a rough measure). Moreover, wherever those source units are not given in the text at all, require that they be given in the said footnote. This seems only reasonable & therefore propose to have words to this effect added onto the page. Jɪmp 00:32, 27 September 2007 (UTC)
- Eh... I was under the impression that we already had a guideline like that. I didn't actually check, though. *checks* "Where footnoting or citing sources for values and units, identify both the source and the original units." That comes awefully close. Considering all values already have to be source per WP:V, doesn't this essentially insist on what you are asking the styleguide to insist on? Are we by now talking about fixing a problem that does not, actually, exist? Shinobu 15:34, 27 September 2007 (UTC)
- But the problem we have is that some editors are using parts of this guideline to remove or subordinate cited values just because they are in Imperial units. I would like this policy to require them to place those values in a cite. --mav 13:54, 28 September 2007 (UTC)
- Somewhat changing wiewpoint: When referencing standards, please use first the messaurements as originally defined. Case in point "Rail gauge" article where Decauville gauge is given as 598 mm, although it was originally defined as 600 mm. Reason repeated back and forth conversion. Seniorsag 15:58, 4 October 2007 (UTC)
- The guideline currently says "Where footnoting or citing sources for values and units, identify both the source and the original units." If the original units were included in a <ref></ref> they should not be removed.
- The amended guideline says that US units can be removed "where there is consensus among the contributors not to convert the metric units". In the cases you have seen mav did the person who removed the value gain consensus to do so? If not the conversion should not have been removed.
- If the example you give about the rate of growth of trees is a real example of where this occurred then the standard for considering an article "scientific" is much broader than the examples people give when proposing removing such conversions from scientific articles.
- In this example the imperial measure is not only true to the source but actually improves the article by making it easer to read by people who think in imperial units with negligible cost to readability. You can see in the history I had second thoughts about discussing this again but I decided to say this because the arguments made for articles about drugs or astronomical measurements don't apply here. This is a good example of why this is a mistaken policy.
- Shinobu,
- I guess you might say that I am "talking about fixing a problem that does not, actually, exist". Note, though, that you had to check ... and down pretty far in the list and that you had to rely on another piece of policy on another page (albeit a relatively well known and accepted one). So, yeah, you're right, the insistance I was calling for is already made but perhaps there still is a problem to be fixed. I'd call this a pretty important issue. The way it's put now, it's not to hard to overlook or misinterpret. I say give this issue the prominance it deserves: spell it out clearly leaving no room for interpretation.
Can anybody point me to specific scientific articles "where there is consensus among the contributors not to convert the metric units". Gene Nygaard 19:54, 9 October 2007 (UTC)
Three questions
- Why are the numbers ten to twenty not in the standard list of exceptions? I think most people would consider that more natural, and it also goes together well with English grammar/vocabulary and our own hyphenation rule. Made-up example: "The boy band consisted of eleven members." Notice how odd it looks when you substitute 11.
- Why are subscripted radices not used in computer-related articles? Most computer literate people (at least those who know what 0x means) know (or could easily guess) what 16 means too. There are computer languages that use other pre- or postfixes (e.g. &H07C0FFEE, DEADBEEFh) or none at all. Why tie ourselves to the syntax of a specific programming language when there's a perfectly usable, and standard, mathematical notation? Why change it just because it's about computers?
- What to do with things like #1? Do we change them to "number one", or do leave them as is? Example: "Their album Termunterziel flew high in the charts and soon reached #1."
Lots of thanks in advance. Bye, Shinobu 13:54, 26 September 2007 (UTC)
- (1) Doess "11" look odd? Most style guides insist on it, with contextual exceptions. (2) Dunno. (3) IMO, # looks crass; better to use "No." or "Number". Tony (talk) 14:42, 26 September 2007 (UTC)
(1) Are you sure style guides universally recommend against it? The Guardian's may, but Chicago doesn't. There is of course the possibility that this is a cultural thing; I've looked at a few styleguides, and I think I know where I got the "up to twenty" rule of thumb ;-) (3) Okay, "number one" it is then, at least in prose.
Should we perhaps add some clarifying comments (if necessary) after we let this discussion run its course? Shinobu 16:14, 26 September 2007 (UTC)
- Contextual exceptions aside, I'd rather have seen the cap on spelling numbers out bumped up from ten to twenty instead of down to nine.
- I'd much rather we used standard mathematical notation for bases throughout. Making this exception for these articles and that exception for those makes the encyclopædia that much less readable.
- I'd have the word "number" spelt out but allow "No." where the number is written as a numeral.
- Jɪmp 00:18, 27 September 2007 (UTC)
- I doubt you really meant "No.", rather than "no.", but just in case: It should be "no." if abbreviated, unless it's a proper noun in the context, like part of a title of something. — SMcCandlish [talk] [cont] ‹(-¿-)› 00:36, 10 October 2007 (UTC)
- Response to Jim: (1) Why? You'd rather see "seventeenth–nineteenth centuries" than 17th–19th centuries"? The latter is much easier to read, takes less space, and in articles that contain lots of references to centuries, more easily identifiable. It is optional, all the same. (3) I think I agree in most contexts. Tony (talk) 10:40, 30 September 2007 (UTC)
- I don't think I can give any better reason than "I like it." whether to stop at 9 or twenty is more or less a matter of taste. I kind of like the idea that was floating about a few months ago to spell out whatever you can in one or two words. Centuries, I reckon, we can consider seperately (though I'm still a speller-outer there). Jɪmp 03:49, 9 October 2007 (UTC)
- Centuries are already handled separately, so the general recommendation wouldn't affect it, I think. I too would prefer to see it be "write out one through twenty". — SMcCandlish [talk] [cont] ‹(-¿-)› 00:36, 10 October 2007 (UTC)
I would prefer to handle centuries separately, like the style guide currently recommends. Anyway, is there anyone who strongly opposes spelling out ten to twenty? Also, on the 0x question, are there any people elsewhere, on other styleguides for example, that we might wish to contact to get clarity? Bye, Shinobu 18:00, 4 November 2007 (UTC)
The date format in ~~~~
Why don't I use ~~~~ ?
Because the resulting date format is non-compliant with ISO 8601.
When standard date formats are available, I find it highly improper to impose any ugly, illogical, non-compliant format on editors. Personally, I wouldn't bother to complain about the differences between 2007 September 26 and 2007-09-26. The latter is arguably superior, but the former has a point or two in its favor. (In particular, "September" often reminds me of the septentriones, one of the more pleasant parts of the neighborhood). I think both formats incomparably better than the internally inconsistent 26 September 2007. Iccchh.
The Wikipedia:Manual_of_Style_(dates_and_numbers) claim here that "ISO 8601 dates (1976-05-12) are uncommon in English prose, and are generally not used in Wikipedia" is based on at least 2 false premises.
1) There is no such thing as an "ISO date". There are ISO 8601 date formats, yes; but dates are dates. There is no alien species which can be outlawed as inappropriate or unnecessary.
2) Dates are part of language because they are numerical expressions and thus part of mathematics, which is the language of science and technology. Being part of mathematics, dates are thus not subject to grammatical conventions, rules or prohibitions based on "natural linguistic" principles. "English prose" does not intersect dates. Dates are numerical expressions; even when imbedded within prose, where they may be thought of as "foreign language" expressions.
Why should virtually all dates used within Wiki comply with ISO 8601? There are a number of important reasons.
a) It is an international standard. The benefits of consistent usage with authoritative meaning are many and widely recognized. Many very intelligent people have put a lot of thought and effort into crafting the most useful standard possible. It is a reasonable assumption that standard usages will be better understood by more people for a longer time than non-standard usages. Unless you are begging for trouble, it is almost always a good idea to comply with all applicable standards.
b) Ambiguity kills data. Non-compliant formats may be misunderstood. In the case of dates, this is exquisite. As of today, how am I supposed to know whether 10-07-07 is in the past or in the future? Years from now, what date is that?
c) The year must have precedence. If you had a pedometer or odometer that worked like the internally inconsistent formats, it would drive you crazy. Would you mind if your employer used a non-standard format for the amount of your paycheck? Those formats are thus obsolete.
d) It is essentially irrelevant how widely adopted the standard is. In fact, since ISO 8601 provides free sorting and sharply reduces errors, it is already widely used in IT and in astronomy.
The US Congress passed the Metric Act in 1866. There has been a lot of resistance to a few of the metric measures. Even the total loss of the $125,000,000 Mars Climate Orbiter because a NASA contractor used an Imperial unit didn't seem to wake much of anyone up.
It's still a good idea to use international standards. And to be grateful when they exist.
Some points editors may wish to consider before repeating previous comments in objection to these assertions here:
Some Christians object to spelling out the names of months in Western languages because they are, or are based on, the names of what they have the gall to call "pagan" gods. Thus, in records of "monthly meetings" one sees the abbreviation Mo, e.g., 7 Mo or 9 Mo for September (as opposed to mo, which means "married out" (of the church)).
I consider it generally improper, because inconsiderate, to provide a non-compliant value without also providing a standard value.
Because older dates in secondary sources have often become corrupted, the most original date is often the best choice. Footnotes can help immensely by providing details. If necessary, a section titled "Details on Dates" is a good alternative to promulagation of inaccurate or easily misunderstood "information". In an encyclopedia, it's a safe bet most readers won't care about a 5-year error in the placement of a date 100 or 500 years before the present time, and that a few will care deeply about every day, or even every hour.
Standard usages are better understood, not less. One of the goals of standardization is to eliminate repetitive thought about meaning. Confusion arises when people head off on non-compliant excursions. When people use standards consistently, text is more concise and clearer. This has cost implications, including cost implications in education. When parents and taxpayers pay for education about non-compliant practices, they are not receiving good value for their money. Also, people, whose mental ability for detail would marginally qualify them for jobs where they might shine in other ways, may be disqualified when a plethora of non-standard usages becomes too much to comprehend and process.
Brains should freed up for useful or artistic innovation, not tied up processing meaningless variation.
Because ours is an increasingly interconnected world, with more and more linkages between formerly disconnected fiefdoms, there is a crying need for standardization.
There is virtue in being an exemplar.
No amount of carping about dates is likely ever to stop men from embracing ambiguity in telling women, "I'll call you on Tuesday".
Walter Nissen 2007-09-27 01:31
- Forgive Sinebot, he's only a bot. Dates not part of the English language? Anyhow, what do you propose? That all dates on WP be given only in ISO format ... good luck. Jɪmp 02:55, 27 September 2007 (UTC)
- Well, almost all dates, yes. And not limited only to Wiki. In the alternative, what would you offer? That this persistent mess be conserved to throttle our grandchildren?
- Walter Nissen 2007-09-28 00:14
- Just FYI, complaints or suggestions about the date format in signatures cannot be addressed here. Any problem with that will have to be fixed by the developers, so it should be raised at WP:VPT. — SMcCandlish [talk] [cont] ‹(-¿-)› 00:39, 10 October 2007 (UTC)
"U.S." vs. "US" in the text of this guideline
- See also Wikipedia talk:Manual of Style/Archive 81#U.S. & Wikipedia talk:Manual of Style#U.S. vs US.
Apparently, at least one person monitoring this project page thinks there is not a style guideline of this minor issue, but there is such guidance. The Wikipedia:Manual of Style (abbreviations) clearly states that the term "United States" should be abbreviated as "U.S.". First, I think this is the correct style; and second, I strongly suggest that the issue be settled in the MOS:ABB lest we see this be a repeat problem with other Wikipedians just trying to follow the MOS. --Charles Gaudette 07:19, 27 September 2007 (UTC)
- First, this abbreviations submanual merely gives the ungainly and old-fashioned "you dot es dot" merely in a table square as an abbreviation, without further wording or proscription. The table was wrong or questionable in at least two other respects I noticed on a quick scan through: in failing to provide undotted "am" and "pm" as options—see MOSNUM and MOS on that (I've added those now); and in showing the undotted form "PhD", first, no less, against the explicit preference of MOS.
- Second, such a proscription of "US", if it really appeared in explicit wording, would be in conflict with MOS itself, which says the following:
- Periods and spaces
- Many periods and spaces that were traditionally required have now dropped out of usage. For example, PhD is preferred to Ph.D. and Ph. D. Periods are retained in abbreviations that cannot otherwise be clearly identified.
- Third, "US" is all over Wikipedia, possibly because people think it looks silly to have "the U.S. and the UK" together, and because just about every American initialism, including, hold your breath, "USA", has dropped the dots. Indeed, until some dot zealot tampered with it about a month ago, we had "US-registered" at the bottom of every WP page; now, it's "U.S. registered", and it now goes against correct practice, in the US and elsewhere, of hyphenating such an item, since the dots make it look pretty awful "U.S.-registered".
- Fourth, our MOS is not Chicago's poodle, contrary to the clear implication right at the top of MOS:ABB. In any case, Chicago—excellent and authoritative as it (mostly) is—should get over it and change this visually unattractive and inconsistent practice: almost all other English speakers, and many US writers, have have moved with the times (excepting upper-case text, of course, where it may not be clearly identifiable—see MOS wording above). TONY (talk) 10:06, 27 September 2007 (UTC)
- Fifth, there's nothing stopping you from using the dotted version if you want; but mass changes to existing articles for the sake of it may well be considered undesirable, as for other linguistic options. TONY (talk) 10:06, 27 September 2007 (UTC)
- And PS, now you've changed it to "U.S. dollars (US$123)" in MOSNUM's Currencies section. <gives quizzical look> TONY (talk) 10:10, 27 September 2007 (UTC)
- Sounds like a to-do item then: Make WP:MOSABB agree with WP:MOS. — SMcCandlish [talk] [cont] ‹(-¿-)› 16:37, 27 September 2007 (UTC)
- Just a note here on Tony1's PS, the only reason I have "now" changed "U.S. dollars (US$123)" in MOSNUM's Currencies section is because I had not seen Tony1's comments and revert at that point in time. --Charles Gaudette 15:42, 27 September 2007 (UTC)
- It is "U.S." – if you also write "N.A.S.A.", "U.K.", "S.C.U.B.A.", "I.B.M.", "N.Y.S.E.", etc. Which hardly anyone does any more. — SMcCandlish [talk] [cont] ‹(-¿-)› 14:34, 27 September 2007 (UTC)
- ... and L.A.S.E.R.? Thunderbird2 14:57, 27 September 2007 (UTC)
- Sigh. Who edited my heading? Bad people, very bad. --Charles Gaudette 15:27, 27 September 2007 (UTC)
- I did, if you mean addition of the parenthetical. Per WP:REFACTOR; no one owns headings, and they need to make sense in the context and help keep things on-topic per WP:TALK; I figured that would be obvious (and the rationale was given very clearly in the edit summary: This is MOSNUM after all, so the topic of "US" vs. "U.S." is only relevant here inasmuch as it relates to dates and numbers. :-) — SMcCandlish [talk] [cont] ‹(-¿-)› 15:39, 27 September 2007 (UTC)
- The change to the heading does change the meaning of my comment. You are right, of course, I don't "own" anything here, but I do try and say-what-I-mean and mean-what-I-say. I was referring to the prose of the project page as it was reverted by Tony1. My mistake for not being clearer. --Charles Gaudette 15:51, 27 September 2007 (UTC)
- Ah, I see. I misunderstood. Is it better now as ' "U.S." vs. "US" in the text of this guideline'? My goal was simply to prevent incoming editors from mistaking this topic as general discussion of what WP's style guide should recommended with regard to periods and abbreviations, which is already being discussed in too many places instead of centralized and settled (I would suggest that WT:MOS is the place for that, since WP:MOS is the controlling document and its subguidelines simply explorations of subtopics in more detail). — SMcCandlish [talk] [cont] ‹(-¿-)› 16:30, 27 September 2007 (UTC)
- Q: "Is it better now as ' "U.S." vs. "US" in the text of this guideline'? A:Yes. ;-) Further, I am in agreement with your rational, SMcCandlish. I have (re-)read some of those old back-and-forths about "U.S." versus "US" and I don't want to repeat them, (I don't have that sort of free-time). --Charles Gaudette 18:38, 27 September 2007 (UTC)
- Drat, there goes the opportunity for yet another perfectly good (re)edit war! ;-) Askari Mark (Talk) 19:09, 27 September 2007 (UTC)
- I'm very happy with the dot-it-or-don't policy that has been around for a while. I'll buy every Wikipedian a beer if Americans at large haven't dropped the dots, overwhelmingly, by 2015. Tony (talk) 10:35, 30 September 2007 (UTC)
- We haven't done so. That may well be true for USA as pointed out above (but while the U.S. Army omits it when USA means United States Army, the generally public probably doesn't use that very often). Longer acronyms are move easily recognised as such. And we generally have from measurement symbols such as US$ and quite often from US gal for the U.S. gallon, at least for those of us who cringe when we see "lb." and even worse "lbs.", but that doesn't affect the general rule. Gene Nygaard 15:25, 9 October 2007 (UTC)
- I'm very happy with the dot-it-or-don't policy that has been around for a while. I'll buy every Wikipedian a beer if Americans at large haven't dropped the dots, overwhelmingly, by 2015. Tony (talk) 10:35, 30 September 2007 (UTC)
- Drat, there goes the opportunity for yet another perfectly good (re)edit war! ;-) Askari Mark (Talk) 19:09, 27 September 2007 (UTC)
Further to the above, the policy to use "U.S." has been around since at least 2004, with a short break recently when it was commented out, apparently by mistake, restored by me on the 6 September, removed by Tony on 7 September (who thought I was making a unilateral change (despite my edit summary <sigh>)) and restored by me today. Rich Farmbrough, 10:36 5 October 2007 (GMT).
(Outdent) Needs discussion. I've posted on Richard's talk page some reasons that reinstating these rules is of questionable value. Tony (talk) 11:12, 5 October 2007 (UTC)
For information, a compromise guideline now appears in MOS, specifying that the dotted version is more common in AmEng than the undotted, and that in the same variety of English, many authors avoid the abbreviation when the United States appears with other countries in the same sentence. (The second point is a Chicago formality that is widely not observed by Americans themselves). The list of abbreviations at WP:ABB has been updated (by Crissov, I think), to include "US" as an option alonside "U.S.". Tony (talk) 08:36, 8 October 2007 (UTC)
The 29th September
Why does the manual of style say not to use "the"? - Articles written in British english read funny without the "the"... --Fredrick day 23:34, 28 September 2007 (UTC)
- Articles written in American English would read funny with the "the" (unless "of" is also used). Using the "th" (and similar) is discouraged by MOSNUM in favor of using auto-formated dates. — Aluvus t/c 05:30, 29 September 2007 (UTC)
- Agreed. And I would add that this is just one of those things where the formatting and how one says it aloud do not necessarily have a 1:1 relationship. Read aloud "He died 29 September 2007", will be said differently by different people (unless they are making a conscious effort to read precisely what is written before them). Some will say it as written, others will say "29th September", others will say "the 29th of September", etc. Similarly "US$57" is usually read aloud as "fifty-seven U S dollars", despite the way it is formatted, and most (though not all) speakers would audibly render "22 cm" as "twenty-two centimeters", not "twenty-two C M", though the latter version would be permissible and understandable to most. — SMcCandlish [talk] [cont] ‹(-¿-)› 22:56, 1 October 2007 (UTC)
Spacing after the decimal point
Who wants to see 0.249 592 9? Mark Askari has pointed out, when I queried it here before, that it's acceptable in some circles. But on WP I think it's unkind to the readers. I edit science, and until this came up I was unfamiliar with the practice of such spacing. I agree with SMcCandlish's change. Tony (talk) 15:02, 1 October 2007 (UTC)
- I do. It is not just acceptable, but mandatory according to SI guidelines. I am not suggesting that WP be bound to follow all SI rules, but it certainly should not *forbid* good practice. I disagree with the change, which should be reverted anyway because it was made without consensus. Thunderbird2 15:17, 1 October 2007 (UTC)
- Addressing most of this below, but the consensus issue I'll address here: Please read WP:POLICY and WP:CONSENSUS more closely. A change to the wording of a guideline (or anything else at WP for that matter) does not need to establish consensus to make the edit before the edit is made if the edit already reflects consensus. Otherwise, there would be 18,000 discussions per day on talk pages about fixing typographical errors. The overwhelming consensus on how to format decimal fractions on Wikipedia is self-evident simply by reading Wikipedia articles, in which SI notation is virtually totally absent. Per WP:POLICY, which explains that guidelines reflect practice and consensus rather than dictate it, I have simply updated this document to conform to what the consensus already is. — SMcCandlish [talk] [cont] ‹(-¿-)› 23:05, 1 October 2007 (UTC)
- If it looks strange to me, and my eyes to a double-take—still—then it's not good for our generalist readers. You think, WTF, squint, stare, and move on (most people won't know what it is). Please give one good reason, apart from your particular familiarity with this practice, that WP should adopt the SI practice in this case. We have a very different readership from that for which SI is aimed, don't we? Tony (talk) 15:23, 1 October 2007 (UTC)
- I wasn't arguing for adoption. Rather, that the practice should not be forbidden. Nor should it be discouraged even for articles of particular relevance such as kilogram, metre and second. More generally, SI guidelines often have as motivation the wish (or need even) to minimise ambiguity - a desirable goal for an encyclopaedia. Thunderbird2 15:49, 1 October 2007 (UTC)
- SI also says to space groups of three digits before the decimal place, too, doesn't it? WP forbids that, I think. What is the advantage in allowing it in any position, especially since we can't use thin spaces here as we'd like (and which are much more appropriate for this role than normal spaces)—stupid Internet Explorer 6, as usual, screws up the display. It's all very well for SI and hard-copy. Let them. Tony (talk) 16:02, 1 October 2007 (UTC)
- Yes, SI uses spaces every 3 digits, both before and after the decimal point. Here there's no need for them before the point because we use commas instead. They still play a valuable role *after* the point though, to make long sequences of digits easier to read, and thus less likely to be misinterpreted. Thunderbird2 16:44, 1 October 2007 (UTC)
- I find 456,567,234,123.675,345,789 to be very hard on the eye. Where is the decimal point in all that lot? I find 456 567 234 123.675 345 789 or for Central Europe 456 567 234 123,675 345 789 usage, much easier on the eye. 2007-10-02 11:55 UTC 85.210.15.78
- Only valuable if you already know that convention. Otherwise you read it as a string of separate numbers, Less than helpful, it is actually misleading. Rmhermen 22:00, 1 October 2007 (UTC)
- You read 234 567 789 123 567 as a list of separate numbers? No. A list of separate numbers would be written as 234, 567, 789, 123, 567 with a comma after each number. So, you want to use commas both as thousands separators and as list item delimiters too? How do you find this 123,345,123, 345,678,234.678,222, 345,789,234, 678,234.345 for readibility then? That is a list of only FOUR numbers. The SI method would use: 123 345 123, 345 678 234.678 222, 345 789 234, 678 234.345 instead. The eye is guided to the commas as list-item separators. The spaces break the numbers into thousands and thousandths. I much prefer that format. 2007-10-02 12:05 UTC 85.210.15.78
- Moot: No sane editor here would do any of that gibberish – commas or spaces versions – but would put each figure on its own *-bulleted line, and use typical 123,456.7890 notation, not Continental SI spacing, to prevent any ambiguity at all. Please recall that we are talking about en.wikipedia.org, not fr.wikipedia.org, etc. Central Europe's concerns and preferences are not ours; cf. how we do not even bother to discuss the «angle-bracket-style quotation marks» favored by German and a number of Slavic languages (and probably others; I think the French like them too); they simply aren't relevant at this site. — SMcCandlish [talk] [cont] ‹(-¿-)› 06:22, 3 October 2007 (UTC)
- You read 234 567 789 123 567 as a list of separate numbers? No. A list of separate numbers would be written as 234, 567, 789, 123, 567 with a comma after each number. So, you want to use commas both as thousands separators and as list item delimiters too? How do you find this 123,345,123, 345,678,234.678,222, 345,789,234, 678,234.345 for readibility then? That is a list of only FOUR numbers. The SI method would use: 123 345 123, 345 678 234.678 222, 345 789 234, 678 234.345 instead. The eye is guided to the commas as list-item separators. The spaces break the numbers into thousands and thousandths. I much prefer that format. 2007-10-02 12:05 UTC 85.210.15.78
- It will confuse our readers. It should be strongly deprecated (a guideline can't actually "forbid" anything). This is Wikipedia, written for a general audience, not SIpedia. As noted above, SI is also the source of nonsense like "5 033 304.72", which we had already long deprecated. We cannot sanely import half of an SI recommendation and then deprecate the other half of it! The spaces' role is not valuable here, because our readers do not recognize it, it will be woefully inconsistent, it is too ambiguous, it cannot be formatted properly (no thin-space support in world's most popular, still, browser), and attempting to simulate a thin space with HTML <font size="-1"> </font> markup not only depends upon deprecated code it also makes for wikicode that is harder for average editors to edit. The funky spacing does serve a valuable role in SI documents, because the average reader of them is familiar with and expects the notation, and it is used in circumstances (i.e. print journals and the like) in which it actually works as intended. By way of comparison, consider the standard medical term "myocardial infarction"; in a medical journal, the common-parlance term "heart attack" would be inappropriate and out of place, but in a Wikipedia bio article the exact opposite is true. Wikipedia does not use technical jargonistic terminology and formatting without a very good in-context reason. See also above and in archives; this larger issue has been hashed to death and beyond, in years of debating over MB/MiB, where the closest thing to consensus that appears to have emerged is that we don't force the reader to learn the *iB system unless the distinction between *B and *iB in the article in question is very important. Using SI notation for decimal fractions is not important at all on WP, even in scientific articles, as the meaning of the numbers in question does not change and WP is not a science journal. PS: Thunderbird2's point about an encyclopedia's need to minimize ambiguity is the strongest possible argument against using this SI notation, since it introduces the very strong ambiguity about whether what is being shown is one number or several. I'm with Tony and Rmhermen in doing a double-take every time I see this. And I'm university educated. A 12-year-old isn't going to understand this notation at all. — SMcCandlish [talk] [cont] ‹(-¿-)› 22:48, 1 October 2007 (UTC)
- I prefer the SI notation and would have it used everywhere but
- either use it everywhere or nowhere not
- use it on these articles but not those,
- use it in these contexts but not those nor
- use it for these numbers but not those;
- don't use it with an ordinary space (and since IE6 can't hack a thin space, well, that's that) and
- definitely don't use commas before the decimal point and spaces after.
- either use it everywhere or nowhere not
- Commas are what we're using (even such functions as
{{formatnum: }}
are designed around this convention), let's stick with that. But if you think that's bizarre get a load o' pi#Numerical value. Jɪmp 00:24, 2 October 2007 (UTC)- Understood. If even those who prefer SI notation do not like its half-assed implementation in a few places here, I think we can be pretty secure in advising against doing that. :-) PS: It's not so much that the practice is (objectively) bizarre, it is that it is inconsistent and confusing to the majority of our readers, who are not scientists. Making it internally inconsistent and even more confusing, including to those who prefer it (when done properly), by only adopting half of it, will, as Jimp appears to note, be even worse. — SMcCandlish [talk] [cont] ‹(-¿-)› 04:55, 2 October 2007 (UTC)
- I prefer the SI notation and would have it used everywhere but
- In my experience 12 year olds learn quickly and would have no trouble at all with interpreting the spaces for what they are - a device to aid the reader. If there is a problem, it would be with those of us who are more set in our ways. Which of these 3 do you find easiest to read?
- 3.14159265358979323846264338327950288419716939937510
- 3.14159 26535 89793 23846 26433 83279 50288 41971 69399 37510
- 3.141 592 653 589 793 238 462 643 383 279 502 884 197 169 399 375 10
- I see no harm in WP embracing this convention for long strings of digits. Perhaps the length of the string would be a better criterion for its use, rather than by article (there I agree with Jimp). Thunderbird2 07:25, 2 October 2007 (UTC)
- Well I learned pi to 250 decimal places in my teens (and still know most of it) and that printout was a space after every five digits. So to answer your question - that's what I find easier to read. :-) But seriously, spaces and commas prior to the decimal give you a sense of magnitude of the figure - most important (e.g. 5,058,223,172). Spaces after the decimal aren't that important and a lone figure sitting out on its own after a 7 decimal place figure is just awful (e.g. 3.141 592 6). Most figures in WP are probably under 6 decimal places anyway and most would be less than that. If that's the case - have no spaces. But I do agree when it is long it is better to break them up. But to be honest, by fives or even tens are better than three. Jim77742 07:39, 2 October 2007 (UTC)
- I'd prefer threes or even sixes to match the groupings before the decimal point. Which of the three πs do I find easiest to read? The one grouped into threes but who wants to read it anyway? With great long strings of digits like that you'd more likely want to copy and paste it into a spread sheet than actually read it i.e. verbatim. Fives or tens verses threes or sixes ... I call it a moot point on Wikipedia. Jɪmp 08:11, 2 October 2007 (UTC)
- Yep, I find the threes easiest to read, but general readers will find it harder to identify for what it is, when filled with these relatively large normal spaces (as opposed to the thin spaces that we can't use). How often do these long strings appear in WP, anyway? Tony (talk) 11:14, 2 October 2007 (UTC)
- So rarely that it does not deserve a mention here. At least 99 times out of 100 it is not appropriate to quote more than 3 significant figures, so the question doesn't arise. For the remain < 1%, why not leave it to the editor's discretion? Thunderbird2 11:52, 2 October 2007 (UTC)
- I know it's rare. But it happens. And numbers like 3.141 592 6 just look awful when spaced like that (either in text or in an infobox). Spaced out when on a line by themselves with a lot of digits is fine:
- 3.141 592 653 589 793 238 462 643 383 279 502 884 197 169 399 375 105 820 97
- As a resolution can we have no spacing in decimal places except it's optional when the number of decimal places is eight or greater and the number is on it's own line? (A mouthful - can someone word it better?) Jim77742 00:12, 3 October 2007 (UTC)
- "Digits after decimal point are written without spaces with an optional exception for numbers with more than seven decimal places on their own line." How's that? Right, but I'd prefer the rule without exception. I don't want to read such numbers, I might want to use them, in which case I'd have to delete any spaces in order to make it one number. Jɪmp 2007-10-03 01:19 01:19, 3 October 2007 (UTC)
- Have to concur with Jimp and Tony that no one here is literally going to read a 47-place decimal, so the readability point is moot, and further with Jimp that actually using it, e.g. because you need to copy-paste it into a mathematical calculation, makes the spaced variant user-hateful. Further concur with Jimp (not Jim77742) that one standard is better, and we should not make an exception just for the heck of it; doing so would not even satisfy the mainstream of the SI-supporter crowd, only those who think that using the less significant half of the SI recommendations in this area while explicitly rejecting the other half would somehow make sense to our readers. — SMcCandlish [talk] [cont] ‹(-¿-)› 06:10, 3 October 2007 (UTC)
- "Digits after decimal point are written without spaces with an optional exception for numbers with more than seven decimal places on their own line." How's that? Right, but I'd prefer the rule without exception. I don't want to read such numbers, I might want to use them, in which case I'd have to delete any spaces in order to make it one number. Jɪmp 2007-10-03 01:19 01:19, 3 October 2007 (UTC)
- After reading all this I'd agree with no spaces in decimal places. At all. Although there may be places where it is appropriate (e.g. pi) and better for digit memorisers the cut/paste thing has greater weight for me.
- "Digits after the decimal point are written without spaces" Jim77742 07:01, 3 October 2007 (UTC)
- I have no objection to tightening the language of it. It might also be appropriate to invite commentary from Talk:Kilogram since that seems to be the locus of support for SI spacing of decimals. I figure if WP:MOSNUM regulars right now say there is consensus on this, we're likely to have a flamewar result when we fix Kilogram to conform, if the regulars over there do no get to air their (probably already addressed) issues. Procedural point, maybe, but what the heck? — SMcCandlish [talk] [cont] ‹(-¿-)› 07:18, 3 October 2007 (UTC)
- I see plenty of good reasons why the addition needs to be more carefully *formulated* before it is added, and I'd like to be given some time to compose my thoughts. In the meantime, Conversion of units is another example where (good) use is made of the 3 digit grouping. Thunderbird2 07:47, 3 October 2007 (UTC)
- Just a politics point, but it's usually not helpful to respond with sarcasm to concessions in your argument's direction. That said, there is no delineated time limit here. I think I'm the most "hot" editor here to go change the markup at Kilogram (though not the first to report the issue), so I wouldn't worry too much about the clock, unless you figure to disappear from the discussion for a week all of a sudden. :-) If I were overheated to go change it, it would already be changed; instead, I'm actually the one arguing for more input from that direction, so your metaphoric teeth around my ankles seem a bit inappropriate. I did not mean to imply that no other article anywhere on WP used spacing of right-of-decimal numerals; only that no activism on the part of such spacing has been evidenced by anyone so far that I know of except among the regular editors of Kilogram (frankly, I'd be very surprised to find a significantly different editorship at Conversion of units). So, if you think Talk:Conversion of units people should be invited to comment here as well, then by all means do so. I doubt that any arguments could be presented that have not already been addressed. The gist is, it would make no sense, and would be dreadfully confusing to our readers, to adopt half of an SI recommendation yet reject the other half, and consensus has already very strongly rejected that other half. Arguments in support of adopting the right-of-decimal SI preferences have a very uphill battle. No ire intended at all in that statement; I'm simply stating the situation as I see it. Re: "more carefully *forumulated*": What did you have in mind? Even I've hinted that the new text could be shortened, but I do think that the logic represented, however tumidly, in fact actually and accurately represents general WP consensus. There simply isn't support for SI decimal notation here, however much SI thinks it is wonderful. — SMcCandlish [talk] [cont] ‹(-¿-)› 08:48, 3 October 2007 (UTC)
- I see plenty of good reasons why the addition needs to be more carefully *formulated* before it is added, and I'd like to be given some time to compose my thoughts. In the meantime, Conversion of units is another example where (good) use is made of the 3 digit grouping. Thunderbird2 07:47, 3 October 2007 (UTC)
- I have no objection to tightening the language of it. It might also be appropriate to invite commentary from Talk:Kilogram since that seems to be the locus of support for SI spacing of decimals. I figure if WP:MOSNUM regulars right now say there is consensus on this, we're likely to have a flamewar result when we fix Kilogram to conform, if the regulars over there do no get to air their (probably already addressed) issues. Procedural point, maybe, but what the heck? — SMcCandlish [talk] [cont] ‹(-¿-)› 07:18, 3 October 2007 (UTC)
No sarcasm was intended in my remark. My emphasis on the word "formulation" was intended to indicate that I see the logic in having such a statement in principle, but that I disagree with the choice of words. More explicitly my position is this:
- I agree that short lists of digits do not benefit from the spaces (1.2345 is easier to read than 1.234 5);
- I think that longer lists (like pi, or the speed of light) can benefit because it dramatically improves readability;
- and that the wording of the proposed new text can be improved to say this.
In a nutshell, for a situation in which the SI practice improves readability, I say use it, and if it detracts from readability, then not. Like Jim77742, I remember learning pi to N decimal places (though I can't compete with his impressive N=250!), and like him I did so in groups of 5 digits. The main point is not so much whether the digits are grouped in threes or fives, but that grouping them dramatically improves readability. In doing so, the spaces improve editors' ability to check the correctness of long lists, and therefore improves the overall quality of WP. One point I do not agree with is the copy paste argument. Anyone relying on the accuracy of WP to obtain the value of pi (or any other constant) to 50 decimal places needs their head examined (for that purpose there are vandal-free sites, like this one for pi). The purpose of WP should be to make the list *readable*. Thunderbird2 16:20, 3 October 2007 (UTC)
- If we can't rely on WP for calculations, how can we rely on it for memorisations? Indeed, why even read such an unreliable datum? I still value consistancy & useability in calculations over readability. Jɪmp 03:54, 9 October 2007 (UTC)
- There are two attributes I value most in an encyclopaedia. These are accuracy and readability. Consistency is important too, but it's not as if this issue arises on every page (if it did I would be arguing for adopting SI guidelines in their entirety). I believe that both accuracy and readability are compromised by removing the spaces. Here's an example I found in Orders of magnitude (numbers), the editors of which write out some very large and very small numbers long hand. The proposed new wording would require them to write the smallest of these (10-36) as
- 0.000000000000000000000000000000000001
- in preference to
- 0.000 000 000 000 000 000 000 000 000 000 000 001
- I maintain that the second is much easier to read. Consequently it is also much easier to *check*, thus improving accuracy as well (if you don't believe me, try counting the zeroes). Thunderbird2 08:26, 9 October 2007 (UTC)
- Yeah, it's easier to check by counting zeros but you can't do this
{{#expr:0.000 000 000 000 000 000 000 000 000 000 000 001}}
nor copy and paste it into Excel to check it automatically. As for that particular article, I don't understand why they've written the numbers out long-hand in the first place. Jɪmp 08:47, 9 October 2007 (UTC)- I think the purpose is to explain what is meant by the exponential notation (10-36). Thunderbird2 08:54, 9 October 2007 (UTC)
- Yeah, it's easier to check by counting zeros but you can't do this
- There are two attributes I value most in an encyclopaedia. These are accuracy and readability. Consistency is important too, but it's not as if this issue arises on every page (if it did I would be arguing for adopting SI guidelines in their entirety). I believe that both accuracy and readability are compromised by removing the spaces. Here's an example I found in Orders of magnitude (numbers), the editors of which write out some very large and very small numbers long hand. The proposed new wording would require them to write the smallest of these (10-36) as
- I don't see the relavance of age here. It is simply unwise to assume that all who understand decimal notation, will also understand exponential notation. That's why it should be explained. Thunderbird2 08:58, 10 October 2007 (UTC)
- The twelve-year-old I intended merely as an example of one of those who might not understand a give form of notation, no, age is irrelavant. "It is simply unwise to assume that all who understand decimal notation, will also understand exponential notation." absolutely but I argue that it's similarly unwise to assume that all who don't understand exponential notation, will understand SI notation. Commas before and no seperators after the decimal point is, for better or worse, the most common form in English (unless I'm mistaken), thus if we're explaining what is meant by the exponential notation (And why else write such numbers out in decimal form?), is this not the way we should go? Jɪmp 08:43, 11 October 2007 (UTC)
- Yes, I agree that no spaces after the point is more common. The question is whether this standard use of English should be applied to numbers that appear in only a small proportion of texts (in English or any other language). It is only those numbers with more than 3 decimal places that the issue arises at all. And even I agree that up to 5 decimal places we should follow the standard rule. So perhaps we are talking only about articles quoting decimal numbers to 6 or more decimal places. Regardless of your or my preference, reading the whole discussion over, it seems to me that arguments have been made in favour of the following 3 options:
- insist on no spaces at all (standard English rule);
- insist on spaces every 3 decimal places (standard SI rule);
- insist on no spaces at all for up to 5 decimal places and rely on editors' judgement for the rare situations where more are needed.
- Is that a fair summary? I kind of agree with SMcCandlish that all of the arguments have been heard by now. So why don't we just select one of the 3? (by whatever process is considered appropriate) Thunderbird2 09:50, 11 October 2007 (UTC)
- Yes, I agree that no spaces after the point is more common. The question is whether this standard use of English should be applied to numbers that appear in only a small proportion of texts (in English or any other language). It is only those numbers with more than 3 decimal places that the issue arises at all. And even I agree that up to 5 decimal places we should follow the standard rule. So perhaps we are talking only about articles quoting decimal numbers to 6 or more decimal places. Regardless of your or my preference, reading the whole discussion over, it seems to me that arguments have been made in favour of the following 3 options:
Time in astronomy
I suspect that we need to add a bullet point to the Calendar section to cover time in astronomy. For example the articles Julian year (astronomy) and Astronomical year numbering suggest that such articles my need to have exceptions to the general rules in the calendar section. --Philip Baird Shearer 10:32, 4 October 2007 (UTC)
Proposition for the aesthetic format iteration of the date unit of measurement
To assist the Wikpedia online audience with readability, ease of visual cueing, maximizing textual 'texture' for perceptual interest, mnemonic enhancement, deletion of redundant and inefficient separation of space-marker betwixt date proper and unit of measurement (to minimize unnecessary utilization of digital storage resources), and for pure aestheticism: how may I open a voting and/or dialogic process to invite and initate a change in Manual of Style (MOS) guidelines?
- e.g. convention in current MOS: 1008 BCE
- e.g. propositional amendment to MOS: 1008BCE
- this proposition is tendered only in respect of the CE/BCE dating convention and unit of measurement.
In my humble and informed opinion, the proposed convention is beautiful when perceived in the context of the uploaded/retrieved page.
Thanking you in anticipation
B9 hummingbird hovering (talk • contribs) 00:42, 6 October 2007 (UTC)
- Sorry, but I disagree. I think the current style is fine. —MJCdetroit 02:04, 6 October 2007 (UTC)
- Agree with MJC. Tony (talk) 02:48, 6 October 2007 (UTC)
- Note that the proposed amendment requires twelve bytes more than the current convention; the claim that this minimizes storage is patently false. TomTheHand 03:25, 6 October 2007 (UTC)
- Agree with MJC. Tony (talk) 02:48, 6 October 2007 (UTC)
- Double-disagree. Not only are small-caps a typographic convention that is rather archaic and serving no logical purpose (the "aesthetics" argument is entirely subjective), along with numerals like "9" having tails below the baseline like a "g", the usage you propose is simply wrong, from a semantic markup point of view. This would have to be done in CSS with a font-variant:smallcaps, if I remember my more obscure and disused CSS correctly, not with <small> which is not only a misrepresentation of the typographic smallcaps that some publishers use for century and era abbreviations, but is also deprecated in XHTML to begin with. We shouldn't encourage bad coding habits, especially for only subjective reasons of appearance. — SMcCandlish [talk] [cont] ‹(-¿-)› 00:15, 10 October 2007 (UTC)
- PS: Please do not wikilink everyday words; it is distracting and makes parsing your text more difficult. FYI: Doing so is also likely to be perceived as an intelligence insult by other editors.; everyone knows what "beauty" and "humble" mean. :-) — SMcCandlish [talk] [cont] ‹(-¿-)› 00:18, 10 October 2007 (UTC)
- One would use
1080 <acronym>BC</acronym>
or1080 <abbr>BC</abbr>
(and perhaps aclass
attribute) in HTML with styling provided by CSS, but we cannot expect authors to supply that much markup and the software does not automatically generate it (but perhaps may some day). Small caps is an alternative style of lowercase letters (minuscules), not of uppercase ones (majuscules), so one would indeed simply decrease the fontsize. Small caps are seldomly done right (especially in browsers), because, unlike fontsize alterations, they require extra work by the font designer. Neither small capitals nor text figures are really archaic, though, they are just not as well supported by electronic fonts and DTP software and therefore were hardly used. – Christoph Päper 14:51, 10 October 2007 (UTC)
- One would use
Found a bug in date formatting (commas between serial dates being swallowed)
To demonstrate the bug, here's an example shown as edited text:
- ... occurred on [[March 14]] [[1873]], [[April 12]] [[1873]] and [[July 2]] [[1874]].
yielding this displayed text:
Notice how the desired comma between the first two dates disappears.
This can be fixed thus:
- ... occurred on [[March 14]] [[1873]]<nowiki>,</nowiki> [[April 12]] [[1873]] and [[July 2]] [[1874]].
yielding
but that's ugly. (If you want to see something really ugly, look at the edited text for this "fix" in this message!) +ILike2BeAnonymous 07:14, 8 October 2007 (UTC)
- I'm totally confused by this. I see no missing comma. And the fact that there's clearly an issue is further reason that the whole date autoformatting thing is a lost cause, at least until it's completely overhauled. Just so many technical disadvantages that it's not funny. Tony (talk) 08:31, 8 October 2007 (UTC)
- Just to address your first point (not seeing the lost comma), how are your display preferences set? I use the default (American date formatting). If you're using UK date formatting, change it to the default and look at it; the comma after the first date is definitely being removed. I haven't tried this using the UK version. +ILike2BeAnonymous 18:18, 8 October 2007 (UTC)
- Just for the record, at least on my screen there is definitely a comma missing between "1873" and "April". (I checked under Date and Time preferences - I have no preference selected) The sensible solution would be to write it as 14 March instead of March 14. Doesn't the problem go away then? Thunderbird2 18:29, 8 October 2007 (UTC)
- No, that would not be sensible at all. I didn't mention that this bug was discovered in an article on an American city. We use American date formatting there; we don't write "14 March". The formatting stuff should work correctly either way, dontcha think? +ILike2BeAnonymous 18:36, 8 October 2007 (UTC)
- Well, sure a computer can be taught to recognise and present either format correctly, so I guess the bug can be fixed. But I am used to recognising either "14 March" or "March 14" as valid dates. I would use the former if it were followed by a year (14 March 1873) and the latter if preceded by one (1873 March 14). To be honest I don't see this as British vs American. Isn't it just common sense? Thunderbird2 19:03, 8 October 2007 (UTC)
- No, it's incorrect; we (Americans) don't write dates that way. It's that simple. We certainly shouldn't have to change the way dates are written to accomodate some failing in the software here. +ILike2BeAnonymous 19:23, 8 October 2007 (UTC)
Just for the record, to me the original and "fixed" version look identical, both with comma in place. I'm using the ISO preference setting. −Woodstone 20:03, 8 October 2007 (UTC)
- Pardon my ignorance, but which one is the "ISO" setting?
- Also, at the risk of annoying those who already know this, let me remind all that the vast majority of readers here are going to have no preference setting at all, apart from the default setting, so that setting should work correctly. +ILike2BeAnonymous 20:41, 8 October 2007 (UTC)
- I don't understand, why are you removing comma from American dates in the first place (or better yet writing them without commas) :\? Matthew 22:00, 8 October 2007 (UTC)
- Writing them without commas won't matter; when they are linked for preferences, the software will add them in Month DD, YYYY format even if preferences are not set. So even if we do have some people like the original poster here who don't follow normal rules, we do get them when we look at the article. Gene Nygaard 15:00, 9 October 2007 (UTC)
- Christ, how many times does this need to be said: it does matter. Firstly, Wikipedia articles are forked, if the article lacks commas the forked version will lack commas also (and if they're not using the same setup as Wikipedia (MediaWiki) the commas won't be added on page output). Secondly, commas will not be present when using software like popups. Also the fact remains that we shouldn't tolerate bad grammar in the article's source (basically your argument is: the software fixes it, it doesn't matter… the same argument could work for spellings if the software fixed them, haha.) Matthew 15:32, 9 October 2007 (UTC)
- Writing them without commas won't matter; when they are linked for preferences, the software will add them in Month DD, YYYY format even if preferences are not set. So even if we do have some people like the original poster here who don't follow normal rules, we do get them when we look at the article. Gene Nygaard 15:00, 9 October 2007 (UTC)
- This is weird. I just changed my preferences to the January 15, 1975 version and the result I get in the first listing above is "March 14, April 12, 1873, 1873 and July 2, 1874" with the first 1873 moved over. Gene Nygaard 15:08, 9 October 2007 (UTC)
- I believe the date formatting code does in fact expect commas between month-day and year in American format; while it will usually compensate if this is missing, I guess it won't always. Try this version:
- ... occurred on [[March 14]], [[1873]], [[April 12]], [[1873]] and [[July 2]], [[1874]].
- yielding this displayed text:
- — SMcCandlish [talk] [cont] ‹(-¿-)› 00:23, 10 October 2007 (UTC)
- Nope there is definitely a bug here; I just tested it and it didn't work. It appears that the <nowiki>,</nowiki> workaround is the only viable one right now. Agree with Tony above that this is more evidence that the date formatting system now is place is royally hosed. — SMcCandlish [talk] [cont] ‹(-¿-)› 00:26, 10 October 2007 (UTC)
- A semicolon to separate elements which themselves contain commas would fix it and would actually be more correct and easier to read for the March 14, 1873; April 12, 1873 and July 2, 1874 format (the OP didn't include the serial comma after the second 1873), but it would leave you with a semicolon for elements not containing commas in 14 March 1873; 12 April 1873 and 2 July 1874. Gene Nygaard 06:38, 10 October 2007 (UTC)
Level of precision
I have made the following changes.
- old
Converted values should use a level of precision similar to that of the source value; ... The exception is small numbers, which may need to be converted to a greater level of precision where rounding would be a significant distortion; ...
- new
... The exceptions are values with only one significant figure, which, to avoid the introduction of inaccuracy, may need to be converted to a greater level of precision; ...
- Technically speaking they are values rather than numbers.
- It doesn't matter about the size of the "number" (What does this even mean? Which is smaller 0.01 millilitres or 10 nanoseconds?); what's important is the significance of that value.
- It's perhaps a little rough and arbitary but one significant figure seems a fair place to draw a line for general purposes. If you've got at least two significant figures, you've got at most ±5% inaccuracy.
- Rounding to a greater level of precision is still rounding.
- The rounding is not the distortion but that which introduces the distortion—an admittedly somewhat picky grammar point.
- I feel that inaccuracy is a better description of what we're dealing with here than distortion.
Jɪmp 07:28, 9 October 2007 (UTC)
- It is probably important to understand that the precision of a number isn't necessarily determined by looking at any one single measurement, when similar related measurements are included in the same article—or when we are otherwise aware of the precision normally used in the context. The trailing zeros before the decimal point are sometimes significant digits (and normally are when they come after the decimal point, except sometimes in dollars and cents figures and the like). Gene Nygaard 14:55, 9 October 2007 (UTC)
- I'd leave it and avoid instruction creep. Some will know it. The proliferation of conversion templates, which most editors probably won't understand when it comes to the nuances of setting precision (and which employ a number of different methods of doing so, so even those who know it is possible might get it wrong by trying the wrong method) can be a problem in this regard, even if they do provide more formatting consistency and more accuracy (if the right template is being used in the case of ambiguous units). Gene Nygaard 06:45, 10 October 2007 (UTC)
Clarification about when to link to dates? (according to MOS)
I'm looking for some clarification about when dates should be linked. In the Autoformatting and linking section of the MOS, the last bullet reads:
"Wikipedia has articles on days of the year, years, decades, centuries and millennia. Link to one of these pages only if it is likely to deepen readers' understanding of a topic. Piped links to pages that are more focused on a topic are possible (
[[1997 in South African sport|1997]]
), but cannot be used in full dates, where they break the date-linking function."
Does the sentence in boldface (my emphasis) mean:
1. That dates (using any combiations of days, months, and year) should only be linked if the linked date will add to the reader's understanding.
2. That only full dates (i.e. November 1, 2007) should be linked, but not dates like November 2007.
Another Wiki user has been trying to tell me that the latter is the case, while I have been trying to indicate that the first meaning is correct. (The discussion can be viewed here: User_talk:NatureBoyMD.) Which is correct? -NatureBoyMD 21:26, 11 October 2007 (UTC)
- The second is close to correct. Full dates, like November 1 2007, as well as just months and days, like October 14, should always be linked. This allows a user's date display preferences to work. TomTheHand 21:37, 11 October 2007 (UTC)
- "Should always be linked"? No, the wording is "are normally linked", after a lot of tension several months ago about the dysfunctional state of the dateformatting script. See archives here for a discussion of the ?five key disadvantages in using it. As I've loudly trumpeted here and elsewhere, I now actively discourage the use of the autoformatting function, and will continue to do so until it's fixed.
- Number 2 above, second point is a different issue: autoformatting applies only to full dates, not years alone and years and months. Please avoid linking those items unless there's a COMPELLING reason to do so. Tony (talk) 03:46, 14 October 2007 (UTC)
- Agreed with Tony. Wikipedia is awash in pointlessly linked dates. Linking a date for no particular reason is no better than linking to Wiktionary for definitions of every single word in an article. — SMcCandlish [talk] [cont] ‹(-¿-)› 19:35, 14 October 2007 (UTC)
Unit symbols are never italic
It will be damn hard to get the articles to comply with basic rules such as italicizing variables, and having mathematical operators (such as ln, cos, etc.) upright and unit symbols upright, if the Manual of style doesn't follow the basic rules.
For example, here is NIST Special Publicaion 811, Guide for the Use of the International System of Units (SI), 1999, section 6.1.1:[3]
6.1.1. Unit symbols are printed in roman (upright) type regardless of the type used in the surrounding text.
Gene Nygaard 16:30, 12 October 2007 (UTC)
- I would support the adoption of this (SI) rule. It is simple to follow and avoids unnecessary ambiguities. Thunderbird2 18:59, 12 October 2007 (UTC)
- Strongly oppose; it makes utter nonsense of italicized material to anyone who is not intimately familiar with the SI style, especially if the non-italicized item comes at the end of the italicized passage. Look in WP:MOSNUM edit history for Gene Nygaard's recent versions where he changed all of the italicized examples to suit this curious style; the result was confusing and essentially unreadable, losing the syntactic fuctionality of italicization in the first place. See the archives here for extensive debates on various topics that always end up resolved as "WP is not SI, and we don't have to do everything that SI recommends; we are writing a general-audience encyclopedia, not a paper for Nature." Using the SI style would also in many cases necessarily entail altering quoted material, which we studiously avoid. Lastly, it just violates the basic logic of italicization of passages, which follows that of quotation, parentheticalization, etc., of passages - if it belongs inside, it goes inside, and if it doesn't, it doesn't. — SMcCandlish [talk] [cont] ‹(-¿-)› 19:30, 14 October 2007 (UTC)
- PS: The passage Gene quotes is not from SI, it is from NIST, and we don't know whether NIST (a strange organization I won't get into) got this from SI documents or simply made it up for their own internal purposes. And the recommendation is not mirrored elsewhere, e.g. in the Chicago Manual of Style. — SMcCandlish [talk] [cont] ‹(-¿-)› 19:33, 14 October 2007 (UTC)
- A quibble. Nothing is "from SI". SI is a system of units. Not a person, not even in the corporate person sense. Various organizations are involved in its development, such as the CGPM (which deals with the fundamental issues and makes a framework fleshed out by others), CIPM, BIPM, ISO, NIST, NPL, ASTM International, IEC, etc. Gene Nygaard 05:43, 15 October 2007 (UTC)
- Right; I should have said CGPM, which appears to be the SI standardization body/process. Doesn't affect the overal point I'm trying to get across. WP isn't CGPM, and isn't bound to do what CGPM recommends for its target audience which is not our target audience. — SMcCandlish [talk] [cont] ‹(-¿-)› 05:52, 15 October 2007 (UTC)
- The CGPM deals, as I said, with the essential framework; the details of everyday use are fleshed out by various international, professional, and national standards organizations. Especially in the case of a rule that is not SI-specific, but rather borrowed from the general rules of typography, the CGPM isn't going to bother with it. Furthermore, when the CGPM does decide something, it is often couched in legalese. It didn't tell us, for example, to "stop using the term micron to refer to the micrometre". Rather, it "abrogated" (the French term for that is actually the official one) its decision of such-and-such date which included a definition of the micron. Gene Nygaard 15:48, 15 October 2007 (UTC)
- Right; I should have said CGPM, which appears to be the SI standardization body/process. Doesn't affect the overal point I'm trying to get across. WP isn't CGPM, and isn't bound to do what CGPM recommends for its target audience which is not our target audience. — SMcCandlish [talk] [cont] ‹(-¿-)› 05:52, 15 October 2007 (UTC)
- A quibble. Nothing is "from SI". SI is a system of units. Not a person, not even in the corporate person sense. Various organizations are involved in its development, such as the CGPM (which deals with the fundamental issues and makes a framework fleshed out by others), CIPM, BIPM, ISO, NIST, NPL, ASTM International, IEC, etc. Gene Nygaard 05:43, 15 October 2007 (UTC)
- And when I make statements about the non-existence of something, I often turn out to be wrong. In fact, the CGPM did address it, way back twelve years before the International System of Units even existed, Resolution 7 of the 9th CGPM (1948):[4]
- Principles
- Roman (upright) type, in general lower case, is used for symbols of units; if, however, the symbols are derived from proper names, capital roman type is used. These symbols are not followed by a full stop.
- Gene Nygaard 23:33, 15 October 2007 (UTC)
- And when I make statements about the non-existence of something, I often turn out to be wrong. In fact, the CGPM did address it, way back twelve years before the International System of Units even existed, Resolution 7 of the 9th CGPM (1948):[4]
- It isn't "SI" style. It is basic notation general in scienctific literature. It doesn't make a damn bit of difference if it is only ft and lb or whatever. Unit symbois are upright. Variables are italic, or bold or with an arrow on top for vectors. Mathematical operators such as log and sin are upright, not italic. Gene Nygaard 22:07, 14 October 2007 (UTC)
- Here, for example, is the AIP Style Manual, 4th ed. 1990:
- 2. Roman versus italic type
- . . .
- (3) Some latin letters, considered abbreviations of words, are properly roman instead of italic—for example, chemical symbols (O, Ne), most multiletter abbreviations (fcc, ESR, exp, sin) and most units of measure (K, Hz). But the editorial staff of the journal is rained to spot these, and authors need not mark them for roman type unless confusion is especially likely:
- Gene Nygaard 22:30, 14 October 2007 (UTC)
- Here, for example, is the AIP Style Manual, 4th ed. 1990:
- It is supported by, but not totally unambiguous in, U.S. Government Printing Office Style Manual, section 11.12:[5]
- 11.12. All letters (caps, small caps, lowercase, superiors, and inferiors) used as symbols are italicized. In italic matter roman letters are used. Chemical symbols (even in italic matter) and certain other standardized symbols are set in roman.
- Gene Nygaard 22:43, 14 October 2007 (UTC)
- Furthermore, if SMcCandlish doesn't know enough to understand that the NIST SP 811 is a widely recognized authority in this regard, he need look no further than the BIPM current 8th revision of its SI brochure in section 4.2:[6]
- There are many more non-SI units, which are too numerous to list here, which are either of historical interest, or are still used but only in specialized fields (for example, the barrel of oil) or in particular countries (the inch, foot, and yard). The CIPM can see no case for continuing to use these units in modern scientific and technical work. However, it is clearly a matter of importance to be able to recall the relation of these units to the corresponding SI units, and this will continue to be true for many years. The CIPM has therefore decided to compile a list of the conversion factors to the SI for such units and to make this available on the BIPM website at
www.bipm.org/en/si/si_brochure/chapter4/conversion_factors.html.
- [end of quote]Then from that page, click on that last offset link. Then note carefully the url on the page that link takes you to. It isn't in fact on the bipm.org site. Rather, it takes you to nothing other than the appendix of that very same NIST SP811, whose veracity SMcCandlish has had the temerity to challenge. If you don't want to go to the trouble to go to the BIPM site first to click on the link, here is that same url made into a link you can access here, intentionally left visible in its full form, and pay attention to where it takes you: http://www.bipm.org/en/si/si_brochure/chapter4/conversion_factors.html
- Prefix symbols are printed in roman (upright) type, as are unit symbols, regardless of the type used in the surrounding text, and are attached to unit symbols without a space between the prefix symbol and the unit symbol.
- In other words, the BIPM if anything is even more straightforward and direct than NIST is about this. Gene Nygaard 01:32, 15 October 2007 (UTC)
- Please do not engage in straw man arguments with me. I did not challenge the veracity of NIST SP811, as you allege; I challenge its relevance here. (I also noted that the source of NIST's "always upright" recommendation wasn't clear from what you'd written at the time, and as a side point I noted that I'm not particularly impressed with NIST as an organization.) — SMcCandlish [talk] [cont] ‹(-¿-)› 06:31, 15 October 2007 (UTC)
To go along with SMcCandlish's bashing of the U.S. national standards laboratory, maybe she/he would like to take on the national standards laboratory of the UK as well. Here is the National Physical Laboratory, UK page on "SI Conventions":[8]
- "Unit symbols are in roman type, and quantity symbols are in italic type with superscripts and subscripts in roman or italic type as appropriate."
N.B. While the NPL does include this short list of conventions on their website, note who they defer to as the experts on the subject at the bottom of the page:
- NIST have produced a complete 80+ page document covering all aspects of this which can be downloaded at: http://physics.nist.gov/cuu/Units/rules.html
Gene Nygaard 02:12, 15 October 2007 (UTC)
- Gene, you can cite this stuff for 100 years, but the response will remain the same: Wikipedia is not NIST or SI or BIPM or AIP, it is Wikipedia. WP is not bound to use the style preferred by physics PhDs just because they are physics PhDs and they prefer it. Please note that this page has almost 100 archives. Don't you think that this issue has come up before? It's been proposed and rejected here before that SI recommendations be followed to the letter, that the CMOS recommendations be followed to the letter, and so on, and there isn't a compelling reason to do so in any case. This is a general-public work, and we can't adopt every style convention preferred by the science community (but no one else); MOS has adopted as many of them as we collectively think the readership can handle, generally with very specific rationales for every such adoption, and not without opposition even for some of those baseline adoptions. Likewise, we generally do what the CMOS says, modulo conflicts it has with other general-usage style guides, but happily abandon it where it does not make sense for the Wikipedia medium and context.
- One major issue I have with the style you are advocating here is that it was devised for a visual, typographic medium, and does not mesh at all with digital semantic markup. It's just fine and dandy for books and PDF files, and jars radically with XMLish thinking. If you can't see what is conceptually off-kilter, with regard to this medium, with specifying that examples (for example) are italicized and then contradictorily saying one should write examples with units in forms like
for example ''a width of 4.2'' cm, not ''a width of 4.2''cm
, then I really don't know what else to say to you. This not NISTopedia. PS: I'm sorry I gored your sacred cow in being unimpressed with NIST (for reasons that honestly don't relate to this discussion at all, so my dig at them was a non sequitur, I admit), but boosting their support of this "always upright" style by citing other NIST-like sources is missing the point entirely; there could be 100 such sources and it doesn't affect the issue here. — SMcCandlish [talk] [cont] ‹(-¿-)› 05:45, 15 October 2007 (UTC) - One possible compromise on this would be creating a template, for use only in hard-core science articles where this convention could perhaps arguably be reasonably insisted upon, called {{itunit}} for units in italics, the entire transcluded source code of which would read
<span style="font-style:normal;">{{1}}</span>
, used as infor example ''a width of 4.2 {{itunit|cm}}'', not ''a width of 4.2{{itunit|cm}}''
. This would preserve the semantic integrity of the italics (which, remember, are an XHTML construct by the time they reach the reader's browser, enclosing the italicized phrase/passage (i.e., note the placement of the italics, which differs from the similar example given above). — SMcCandlish [talk] [cont] ‹(-¿-)› 06:24, 15 October 2007 (UTC)
- I believe it is wrong to apply a significantly lower (or different) standard to articles in Wikipedia than those in Nature, except where it is about required existing knowledge. Every WP reader can be expected to understand basic units and symbols, which encompasses most if not all of the SI.
- One of the major pros of the International System is the strict and simple style guide it comes with. This is most useful if followed by everyone – the goal of standards is consistency, and consistency is good. The particular case of italics, however, should not be interpreted as strict as, for instance, the composition of the symbols themselves. In mathematic text, formulas and the like, their font style should be selected the same as for the symbols of trigonometric functions etc., i.e. upright, whereas variables are usually italic. In normal text, on the other hand, they should, in my opinion, not be treated special; this includes examples and quotations. Christoph Päper 12:58, 28 October 2007 (UTC)
- The simple style guides don't make such an exception.
- The "do as I do" principle will make it impossible to enforce those guidelines elsewhere, if our own Manual of Style doesn't follow them.
- We can achieve our desired emphasis in a number of ways which will not entail violating these rules. Some possibilities include:
- Using quotes rather than italics
- Setting examples off from the text (bulleted or otherwise)
- Reevaluating the say we use emphasis in the manual:
- Using emphasis on Examples:
- Using emphasis on instructions such as "use this, not that", X is preferred, but Y is acceptable
- A combination of both offset examples and italicized instructions, as in Wikipedia:Manual of Style#Inside or outside.
- There are other areas besides units of measures where this would apply. If anyone put a title of a book or a binomial name of the genus and species of a plant in one of our italicized examples, that title or scientific name would be set upright by some of our editors in pretty quick order, I would bet. But if a symbol for a variable is used in the MoS, it would be set in italics, whether it appeared in normal text or in italic text. The rules are different in the various cases: 1) italic in normal text, upright in italic text 2) always italic, or 3) always upright. Gene Nygaard 13:27, 28 October 2007 (UTC)
- Whatever we actually do in our MoS becomes a rule by example. Gene Nygaard 14:08, 28 October 2007 (UTC)
- But the manual of style is, like all other guidelines, a codification of what is already done at large on the encyclopedia (it is intended mainly so that new articles are not wildly different from existing one, and to advise where practice outside Wikipedia might follow conflicting styles). As the vast majority of articles use upright characters, changing it before practice changes is simply pointless and won't work, and isn't the way it is supposed to work anyway. Circeus 03:55, 29 October 2007 (UTC)
- Circeus, I don't entirely agree with your take on MOS. It's influenced by a number of factors, one of which may be what is already done on WP (that comes especially into play when there are back-compatibility issues), what the experts here think is best for an online encyclopedia, with all of its unique conditions (and gain consensus for), and what is done "out there". I think you're oversimplifiying these factors. Tony (talk) 14:25, 29 October 2007 (UTC)
- That doesn't mean the point I make (virtually no article uses italics unless the unit is supposed to) isn't an important element to take into account. Primum non nocere: I utterly fail to see why a sudden switch to italics can do anything but cause widespread controversy. Circeus 21:24, 29 October 2007 (UTC)
- Circeus, I don't entirely agree with your take on MOS. It's influenced by a number of factors, one of which may be what is already done on WP (that comes especially into play when there are back-compatibility issues), what the experts here think is best for an online encyclopedia, with all of its unique conditions (and gain consensus for), and what is done "out there". I think you're oversimplifiying these factors. Tony (talk) 14:25, 29 October 2007 (UTC)
- But the manual of style is, like all other guidelines, a codification of what is already done at large on the encyclopedia (it is intended mainly so that new articles are not wildly different from existing one, and to advise where practice outside Wikipedia might follow conflicting styles). As the vast majority of articles use upright characters, changing it before practice changes is simply pointless and won't work, and isn't the way it is supposed to work anyway. Circeus 03:55, 29 October 2007 (UTC)
Geez. It seems clear to me that, with the context "Unit symbois are upright. Variables are italic, or bold or with an arrow on top for vectors. Mathematical operators such as log and sin are upright, not italic.", that this is intended to apply _within formulas_ - i.e. of course, unit symbols should be upright, for the same reason digits are upright. But in running text, italic doesn't mean the same as it means within a formula. —Random832 16:51, 2 November 2007 (UTC)
- In other words, in saying 1) italic in normal text, upright in italic text 2) always italic, or 3) always upright. we ignore the trivial case: 0) upright in normal text, italic in italic text. (even if the "italic text" consists solely of the unit symbol itself, which is italicized for emphasis) —Random832 16:54, 2 November 2007 (UTC)
- I have to entirely agree with Random832 that this "always upright for units" thing applies to formulas, not general prose. Regardless, the {{itunit}} template I've provided solves this problem from both Gene's and my perspective: He gets his forced non-italicization of units when they are part of an italicized unit, and I get my semantic integrity of italicized unit. Everybody wins! — SMcCandlish [talk] [cont] ‹(-¿-)› 16:05, 24 November 2007 (UTC)
Date-formatting tool for lists of people
I have developed an external-editor-based tool for standardizing dates of birth and death for lists of people. An example of its successful use is List of jazz musicians. It also flags entries where the dates are exceptionally peculiar, as (b. ce. 1822) [I'm still trying to figure out what that one means], so I can try to edit those by hand. The jazz list took 5 minutes total, including the manual fiddling. Since it relies on cut-and-paste, some special characters get clobbered, especially where the names are Japanese, Scandinavian, Polish or Turkish, so I select lists where these are few and I can restore them by hand. I invite opinions, suggestions and requests. I watch this page, or you can dump them on my talk page. Chris the speller 01:27, 14 October 2007 (UTC)
- Looks good, Chris, except that it would be swimmingly good to make the closing year two digits alone (Louis Armstrong (1901–71) rather than Louis Armstrong (1901–1971). But is that going to be complicated programming to chart a course around changed centuries, and to make it CE only? Tony (talk) 03:40, 14 October 2007 (UTC)
- The "b. ce. 1822" thing: Typo for "b. ca. 1822", surely. — SMcCandlish [talk] [cont] ‹(-¿-)› 19:24, 14 October 2007 (UTC)
- One might think so, but there were two separate entries like this in List of preachers; one could not be easily traced (no article, and searching the Web did not provide an easy answer), and the other led to an article which had an exact year, so who knows what was meant? I left them alone, go have fun.
- It could also, of course, be born Christian Era/Common Era 1822, with no indication of uncertainty. As anybody who was around for the BC/BCE debates should be well aware of. Gene Nygaard 22:54, 14 October 2007 (UTC)
- That doesn't resolve the uncertainty at all, simply shifts it. We'd still have to convert to "ca." because we do not know, short of tracking down the editor responsible for it and asking, whether it meant "Christian Era", "Common Era" or "circa"; thus "ca." would still work just fine pending someone else coming along later with a reliable source showing that the exact year was meant. I find it hard to credit that any editor here would have put "ce. 1822" when they really meant "1822 Christian Era" because they would really write "1822 A.D." or "1822 AD"; meanwhile people who use Common Era know that it goes at the end and is not rendered "ce." So, this is a non-issue - "ca. 1822" includes "exactly 1822" as a subset, and we cannot be certain that "exactly 1822" was intended. — SMcCandlish [talk] [cont] ‹(-¿-)› 05:59, 15 October 2007 (UTC)
- It could also, of course, be born Christian Era/Common Era 1822, with no indication of uncertainty. As anybody who was around for the BC/BCE debates should be well aware of. Gene Nygaard 22:54, 14 October 2007 (UTC)
- One might think so, but there were two separate entries like this in List of preachers; one could not be easily traced (no article, and searching the Web did not provide an easy answer), and the other led to an article which had an exact year, so who knows what was meant? I left them alone, go have fun.
Two-digit years
The 2-digit year thing would be a snap, but I don't favor that format as much in lists as I do in running prose ("coached the Detroit Lions 1943–47 before moving to Bora Bora"). Before Tony's huge overhaul, I think the guideline more or less tolerated 2-digit years at the end of a range, but now it seems to downright favor 2 digits over 4, where allowable. Have I misremembered it? Is this now a case of clear consensus? I think it would be easier to scan a list and find a person who died in 1956 if the list did not look like this:
- Herman Dwizzlebot (1811–56)
- Elmer Fringthorpe (1798–1856)
- Marvin Krummblatt (1922–56)
But if there is clear agreement that 2-digit years are preferred, even in lists, I can easily handle it. Chris the speller 20:52, 14 October 2007 (UTC)
- Abbreviating the years for some people would be ludicrous in any list where some of the people span centuries and could not be abbreviated. And the MoS doesn't require doing so now, and I'm glad of that. As it is, I strongly suspect that the current project page, perhaps because of some of the recent changes in this area, go far beyond what is actually agreed upon as far as using two-digit years. Gene Nygaard 22:54, 14 October 2007 (UTC)
- Concur with Gene. And to me it simply looks lazy and imprecise. I never (that I know of) use "1983-87" but "1983-1987". — SMcCandlish [talk] [cont] ‹(-¿-)› 06:05, 15 October 2007 (UTC)
- To me, it is so much easier to read when only two digits are used, and as a reading psychologist, I'm pretty sure that 1983–1987 makes the readers work harder to determine that it's a five-year range than 1983–87. The two-digit closing year also more clearly indicates that the range lies within a single century. Since there is no clear vertical alignment in a list—the names are all of different lengths—there's no issue of neatness/alignment in using both nine- and seven-character ranges, as you see above (Fringthorpe). Repeating the century (18) helps to focus my eyes on the fact that the range occurs in two centuries. I think there was consensus for the wording on two-digit closing years at the time. I'd prefer that it was extended to include page ranges, which are ridiculous when big closing numbers are rendered in full: 12686–12689 versus 12686–89. The former is not uncommon in reference lists of schorarly/scientific journal articles and conference proceedings, and does no one a favour. Tony (talk) 06:58, 15 October 2007 (UTC)
- Concur with Gene. And to me it simply looks lazy and imprecise. I never (that I know of) use "1983-87" but "1983-1987". — SMcCandlish [talk] [cont] ‹(-¿-)› 06:05, 15 October 2007 (UTC)
- Call me crazy, but to me it's much harder to read ranges such as 1983–87. My thought process goes something like this: "1983 to 87? Hm, that's a range of almost -2000! Wait, this is abbreviated... OK, let's see, the first number starts with 19; 19 times 100 plus 87 is 1987. What was the original number again? Oh, 1983. Ok, they really meant 1983-1987". Sure, it takes only a moment to go through this process, but the momentary confusion it causes makes me severely uncomfortable. I never use abbreviated ranges like this. The same goes for page numbers even if they have five digits. --Itub 14:05, 17 October 2007 (UTC)
- Um ... ok, you're crazy. Tony (talk) 14:30, 17 October 2007 (UTC)
- Crazy doesn't quite fit Tony, however—just a little strange, perhaps weird, not processing information the way others do. Most people aren't going to see his span as five years in any case, whether it is written as 1983-1987 or 1983-87. They'll just subtract the numbers and get four years. Furthermore, while if you are talking about spans covering the complete years (or including seasons in a sport and the like), it is indeed the five separate years 1983, 1984, 1985, 1986, and 1987, when it comes to lifespans most people's intuitive subtraction is more correct. In that case, it can vary from just over 3 years to just under 5 years (3 yr 1 d to 4 yr 365 d), and will average out at about four years. Gene Nygaard 14:43, 17 October 2007 (UTC)
- Um ... ok, you're crazy. Tony (talk) 14:30, 17 October 2007 (UTC)
- Call me crazy, but to me it's much harder to read ranges such as 1983–87. My thought process goes something like this: "1983 to 87? Hm, that's a range of almost -2000! Wait, this is abbreviated... OK, let's see, the first number starts with 19; 19 times 100 plus 87 is 1987. What was the original number again? Oh, 1983. Ok, they really meant 1983-1987". Sure, it takes only a moment to go through this process, but the momentary confusion it causes makes me severely uncomfortable. I never use abbreviated ranges like this. The same goes for page numbers even if they have five digits. --Itub 14:05, 17 October 2007 (UTC)
After processing dozens and dozens of lists, I am slightly surprised that I have not seen a single case where an editor had compressed the date of death to 2 digits (out of respect for the deceased, perhaps?), so I think that for all intents and purposes the question is answered; out of probably hundreds of editors, nobody is using 2 digits for death years in lists, as Tony recommends. But I wholeheartedly agree with his feelings about huge numbers in page ranges. Chris the speller 01:21, 17 October 2007 (UTC)
- I agree. I think there's an unconscious formal standard when addressing lifespans. After all, those were two of the most significant years in any person's life. Outside of that, I think two-digit "end" years are fine, if slightly informal. Askari Mark (Talk) 02:25, 17 October 2007 (UTC)
Bits and bytes
The MOSNUM page includes guidelines for use of the byte and its multiples kilobyte, megabyte etc. Isn't there a similar need for guidance with the bit? For example, is a kilobit to be abbreviated kb or kbit? (The kilobit article contradicts itself in this respect, so I suspect the problem is widespread). Thunderbird2 10:42, 14 October 2007 (UTC)
- I would say "yes". — SMcCandlish [talk] [cont] ‹(-¿-)› 19:23, 14 October 2007 (UTC)
- According to IEEE 1541 the IEC symbol for the bit is b, so presumably a kilobit is kb, a megabit is Mb and so on. Have I got that right? Thunderbird2 19:36, 14 October 2007 (UTC)
- That sounds right to me, but we can probably find an actual source on this. PS: Can someone refresh my memory on the reason for the "k" (lower-case) vs. "M" (upper-case) inconsistency? I suspect this is another of those SI things that is only used in science writing; I certainly detect no such convention in general usage (e.g. computer magazines and such, not that any of them mention kilo-anything very often these days; even RAM is measured in gigabytes now). — SMcCandlish [talk] [cont] ‹(-¿-)› 06:13, 15 October 2007 (UTC)
- The reason for the lower case k, as you rightly guess, is the SI. The exception is made because the symbol for kilogram (kg) was lower case before the SI laid down its rules. I'm not sure of the precise history, but perhaps it was considered too sacred to change. But this is not a "science writing" issue, it as an "unambiguous writing" issue. To be unambiguous, WP simply needs to adopt a convention and stick to it. And where there is a widely accepted (universally accepted in the scientific community) convention already in place, there seems little to be gained in departing from it. Does anyone out there have a copy of IEEE 1541 to check the correct symbol for the bit? Thunderbird2 10:31, 15 October 2007 (UTC)
- According to the bit article, the IEEE prefers b while the IEC prefers bit, which is consistent also with Sec 6.1 of binary prefix. The NIST follows IEC, while BIPM (ie SI) remains silent on the issue. Although I don't have access to either of the two named standards (IEC 60027 or IEEE 1541) , I can confirm that IEEE uses b in the related standard IEEE Standard Letter Symbols for Units of Measurement. On balance I propose we follow IEC and adopt bit, kbit, Mbit etc. Thunderbird2 11:58, 15 October 2007 (UTC)
- I agree. The term 'bit' is unambiguous. It is ironic that binary is inherently precise yet the prefix and the unit symbols cause so much discussion. I have seen lots of misuse of 'b' for byte and 'B' for bit. I support your proposal. Lightmouse 17:27, 18 October 2007 (UTC)
- I am also in favor of the unambiguous 'bit'. Odo Benus 18:52, 24 October 2007 (UTC)
- I have obtained a copy of IEC 60027-2. On p115 it defines the symbol for the bit as bit, and on p120 states (verbatim)
- one kibibit: 1 Kibit = 2^10 bit = 1 024 bit
- one kilobit: 1 kbit = 10^3 bit = 1 000 bit
- Thunderbird2 15:52, 20 October 2007 (UTC)
- I have obtained a copy of IEC 60027-2. On p115 it defines the symbol for the bit as bit, and on p120 states (verbatim)
I’ve composed some text for Sec 4.3, intended to replace the existing bullet "The symbol for the byte is B". I’m sure it can be improved, and is deliberately lacking in advice about the kilobyte, megabyte etc (I thought it wise to steer clear of the megabyte vs mebibyte controversy by sticking mainly to the bit.) The proposed text reads:
- The symbol for the byte is 'B'. The symbol for the bit is 'bit'. Unless explicitly stated otherwise, 1 byte is 8 bits (1 B = 8 bit). Decimal or binary prefix symbols may be added to either unit symbol
but not to the unit names. Thus- the quantity 1000 bits (one kilobit) is represented by 1 kbit (and not 1 kb);
- the quantity 8,000,000 bits (eight megabits) is represented by 8 Mbit (and not 8 Mb or 8 Mbits);
- the quantity 8,192 bits (eight kibibits) is represented by 8 Kibit (and not 8 kbit
or 1 Mbyte); - the quantity 1,048,576 bits (one mebibit, or 1024 * 1024 bits) is represented by 1 Mibit.
Thunderbird2 08:45, 21 October 2007 (UTC)
- I agree that we should have a single symbol 'bit' for bit. Permitting an unambiguous bit symbol solves half of the problem of b/B, we should also permit an unambiguous byte symbol for the other half of the problem. We should tolerate two symbols: either 'B' or 'byte' (e.g. kbyte or kB, Mbyte or MB). For example, the following is the sort of error with bytes: "a 10-megabyte (Mb) hard drive". Lightmouse 09:11, 21 October 2007 (UTC)
The proposal doesn't explicitly rule out Mbyte to mean 10^6 bytes, but I take your point. How about this instead (see minor edits) Thunderbird2 09:34, 21 October 2007 (UTC)
- The first sentence still implies that 'Mbyte' is forbidden in Wikipedia and must be replaced with 'MB'. The authors that make the error with byte are unlikely to be influenced by what we say here. I would be quite happy if you said nothing about the symbol for byte. You could say "Do not use 'b' for byte. Or you could have some other wording like "The byte can be shown as an upper case 'B' or unchanged (e.g. 'MB' or 'Mbyte'). Or something like that. Lightmouse 21:51, 22 October 2007 (UTC)
- But if you are going to use "byte" as a symbol, at least say "never Mbytes". Gene Nygaard 01:00, 23 October 2007 (UTC)
- How about this:
- The symbol for the bit is 'bit'. The byte may be represented by either one of the symbols ‘B’ and ‘byte’. Unless explicitly stated otherwise, one byte is eight bits (1 B = 8 bit), and no 's' is added to either symbol in the case of a plural. Decimal or binary prefix symbols may be added to either unit symbol. Thus
- the quantity
1,000 bits (one kilobit)is represented by 1 kbit (and not 1 kb); - the quantity
8,000,000 bits (eight megabits)is represented by 8 Mbit (and not 8 Mb or 8 Mbits); the quantity 8,192 bits (eight kibibits) is represented by 8 Kibit (and not 8 kbit);the quantity 1,048,576 bits (one mebibit, or 1024 * 1024 bits) is represented by 1 Mibit;- the quantity ten megabytes is represented by either 10 MB or 10 Mbyte (and not 10 Mb or 10 Mbytes).
- the quantity
- The symbol for the bit is 'bit'. The byte may be represented by either one of the symbols ‘B’ and ‘byte’. Unless explicitly stated otherwise, one byte is eight bits (1 B = 8 bit), and no 's' is added to either symbol in the case of a plural. Decimal or binary prefix symbols may be added to either unit symbol. Thus
- Thunderbird2 15:49, 23 October 2007 (UTC)
- How about this:
- The prefixes Kibi~ Mebi~ etc (and their unit representations) are not widely used by most reliable sources whereas the traditional Kbit and Mbit (and other similar variations) are widely used and understood by looking at their context to mean the power of two values or base ten values. I suggest having the established style of the article and the style of the reliable sources used in the article dictate what symbols to use. If there really needs to be disambiguation then place that (once only as per other disambiguation examples) as a specifc number in the article in parenthesis after the symbols used. Then if at some later date the majority of relevant reliable sources changes to use the new prefixes the article can be changed to follow their example. This has parity with other similar MOS guidelines such as English and American spelling where for example the reliable sources use British English style but an American English editor suddenly decides to "spell check" copy-edit. Wikipedia isn't a place for one body to decide how to spell "Colour" for example. Fnagaton 16:12, 23 October 2007 (UTC)
- If the use of these prefixes is controversial, perhaps it is best to omit explicit mention of them. Is it OK like this? Thunderbird2 06:42, 24 October 2007 (UTC)
This discussion is not complete without thinking about how to represent "bits per second", which is the most common way of specifying data transfer rates. This is usually abbreviated to "bps", which is in conflict with declaring "bit" as the only way of writing bit. I cannot see "bitps" being advised. To me it seems more logical to reverse the case and state that the full name is "bit", the standard abbreviation (symbol) is "b". −Woodstone 07:41, 24 October 2007 (UTC)
- I prefer to get consensus on the bit first. Compound units can be added later. I think the objection to using 'b' as a symbol for bit would be that this symbol is too often used (abused?) to mean byte. How would you resolve that conflict? Further, I see no conflict between use of 'bit' for bit and 'bps' for bit/s. Thunderbird2 08:45, 24 October 2007 (UTC)
- I like the version you have now. The 'b/B' confusion exists in compound units too. For example: "Japan’s 30 Gbps (giga-bytes per second) of Internet circuit capacity".
- The unambiguous forms (bit/s, kbit/s, Mbit/s, and Gbit/s) are in significant use outside Wikipedia (perhaps 10% to 50%). They are dominant on Wikipedia (over 90%). Lightmouse 11:15, 24 October 2007 (UTC)
- How sure are you that the Japanese capacity is really in bytes, not bits? It might be a misinterpretation by the editor. I would be for standardising on b=bit, B=byte. Disambiguation can be achieved by a unit conversion like 30 Gbps (=28 Gib/s) or if the editor is mistaken, by 30 Gbps (=28 GiB/s). This is actually a double disambiguation. It indicates wheter the prefix is binary or decimal and how to interpret "b" (or "B"), assuming that the conversion always follows the agreed style rules. −Woodstone 12:06, 24 October 2007 (UTC)
- I do not know what units the Japanese capacity is in. I take it that you don't either. The text does not parse. We have to do more work to check or rely on an educated guess. That is why I gave the example. As you say, somebody has misunderstood the use of the single letter. That is the point. At least the error in the text is visible in this case. It is the tip of the iceberg. Most errors are invisible. You and I can be trusted to use b/B correctly, but I don't 100% trust text from others. You have done sufficient work with units of measurement to know that people can be sloppy. I hope that you can support an unambiguous form. Perhaps that is why many editors here use it. Lightmouse 13:12, 24 October 2007 (UTC)
To summarise:
- 8 bit equal 1 byte except in certain historic contexts where it must be noted explicitly
- bits take the symbol ‘bit’, bytes are either ‘B’ or ‘byte’
- consequently bits or bytes per second are abbreviated ‘bit/s’ and ‘B/s’ or ‘byte/s’
- the use of binary prefixes (Ki) is not mandatory, but not prohibited either, therefore decimal prefixes (k) may be used with a binary meaning, if the context makes this obvious
Some standards bodies – I think I read about this in a text by DIN – deprecate the use of ‘B’ for byte, because the symbol is already taken by the bel, as in ‘dB’. I begin to like the unambiguous French ‘o’ for octet, although it may look too similar to a digit zero in those rare cases where it appears without a prefix. (This is not a proposal of its adoption for WP of course.) Christoph Päper 14:00, 28 October 2007 (UTC)
British meaning of "billion"
The text on large numbers contains the text
- "Where the British meaning [of billion] is required for some reason, a footnote or inline comment is appropriate. For instance, the budget item was several billion pounds (note this is billion in the common British usage).... "
I find this confusing because in my experience the old British use of this word to mean 10^12 is no longer common. In other words there is no longer any difference between common British usage and common American usage. How about rephrasing it along the lines of
- "Where the old British meaning (10^12) is required for some reason, a footnote or inline comment is appropriate. For instance, the budget item was several billion pounds (note this is billion in the traditional British usage).... "
Thunderbird2 20:49, 15 October 2007 (UTC)
- Perhaps "British" should be replaced by long scale ([[long and short scales|long scale]])? After all, it's still used in French.... — Arthur Rubin | (talk) 20:57, 15 October 2007 (UTC)
- Why is the long scale ever required? The only circumstance I can think of is in direct quotations, where an editorial note would be required (I guess the inline replacement by the modern scale in square brackets would also be acceptable. BTW, a budget of several billion pounds, old-speak, would be several times more than a British budget has ever been. (= trillion). Tony (talk) 01:36, 16 October 2007 (UTC)
- Indeed. I don't think the long billion has been used commonly for about the last 50 years - certainly not in my memory, which is nearly as long - and its use other than in direct quotes should be discouraged. -- Arwel (talk) 06:36, 17 October 2007 (UTC)
- Outside of money, the short billion isn't used in British usage either. They generally avoid it, using "thousand million" and "29,000 million" and the like. Furthermore, there is usually one very simple alternative we can all generally use to replace these "billions" in most cases:
- 2.35 billion can be replaced with
- 2,350,000,000
- Just using digits takes up about the same space. Let people call it whatever they like, in their own heads as they read it. That is often the best choice when such numbers only occur once or twice or some other small number of times in an article. Then you don't have to waste a lot of time explaining it, neither in the text nor in a footnote. Gene Nygaard 11:14, 17 October 2007 (UTC)
- Outside of money, the short billion isn't used in British usage either. They generally avoid it, using "thousand million" and "29,000 million" and the like. Furthermore, there is usually one very simple alternative we can all generally use to replace these "billions" in most cases:
The British government adopted American usage for the the billion in the 1970s (as noted in the Long and short scales#History) it has been used by the British financial industry and the British chapter of the dismal science ever since to mean 1,000 million. I think there is no reason to note the British usage for the short scale as that is the norm in the financial industry and government. It should be noted if for some reason the long scale is used (Perhaps in EU comparison tables between France and Italy for example) --Philip Baird Shearer 21:06, 4 November 2007 (UTC)
- I agree entirely with PBS. Let's leave behind the fuss about old-speak. Tony (talk) 23:30, 4 November 2007 (UTC)�
On the meaning of recommend
Sorry for splitting hairs, but my understanding of the connotation of the word is closer to "suggest" than to "must do". Therefore, I've always felt free to ignore the recommendation to use non-breaking spaces between units as I don't like it. However, recently I've seen several FAC's opposed on the grounds that they don't use non-breaking spaces. Give me a break! ;-) I recommend that if we are going to treat style guidelines as if they were The Law, we should at least use clear language. We could do like the IETF and use the words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" as defined in RFC 2119. --Itub 09:06, 18 October 2007 (UTC)
- I agree with you about both points (non-breaking spaces, clarity). Lightmouse 09:24, 18 October 2007 (UTC)
- There is a certain amount of disagreement, here and elsewhere, about how "binding" the MOS and other similar meta-pages are meant to be. It may be impractical to settle on one definitive vision here. I would argue that the most reasonable approach is to take them as "things you should do unless there is a compelling reason not to", where the word "compelling" is very important. For instance, I can't think of a compelling reason not to use non-breaking spaces for numbers with units in prose (my memory was that MOSNUM included an exception for tables and such, but it isn't there now and I can't find that it ever was), other than it looking odd in the edit box (conversely, I think it is a silly thing to hold up a FAC over). But then, I would also say that the current wording of MOSNUM on this issue is too soft and ambiguous; perhaps I more strongly support this usage of nbsp than most. In any event, I would agree that the MOS should be more careful in its use of words like "recommend", and preferably take some of the ambiguity out of them. — Aluvus t/c 10:12, 18 October 2007 (UTC)
- "recommend" is a bit wishy-washy. Fnagaton 11:51, 18 October 2007 (UTC)
- I agree with you on both points, and nonbreaking spaces should not even be recommended as a general rule. They should only be used in unusual situations. They should never be used when the unit names re spelled out in full.
- I may have missed any discussion agreeing on it, but the current wording is far more egregious than it used to be. Did anybody actually agree to the expansion here in the changed wording, from the old wording that talked about a non-breaking space between a number and a unit symbol? If not, that ought to be fixed.
- Does any reputable style guide have anything about using nonbreaking spaces in that case. One thing I do know, is that this is not anything recommended for units of measure in measuement style guides such as the BIPM's SI brochure and NIST's Guide for the Use of the International System of Units (SI).
- It seems as though some of the people who came up with that notion are under he impression that we never use numbers and symbols more complicated than "7 mi" or "40 W".
- On the other hand, nonbreaking spaces rather than regular spaces should always be required within a number itself (e.g., 3 7/12 or 0.453 592 37–a format that occurs quite often, despite being deprecated here in the MoS), and either nonbreaking spaces or centered dots for multiplication within the symbols for a unit of measure (e.g. W/(m K)).
- Note that the latter is not even covered by our current wording about non-breaking spaces, because these spaces are not separating "numerical and non-numerical elements". Yet, while we have a few people running around insisting on those nbsp cluttering up the edit pages where they aren't needed, hardly anybody makes sure they are there where they need to be. Gene Nygaard 04:27, 19 October 2007 (UTC)
- Nor is the one within the numbers covered in the current wording; the spaces between "3" and "5" and between "2" and "3" in 0.453 592 37 is not separating "numerical and non-numerical elements". Gene Nygaard —Preceding comment was added at 13:54, 19 October 2007 (UTC)
Article titles for units
There is inconsistency in article titles for units. We have the following styles:
- metre, kilogram, Tmc ft.
- Sagan (unit of measurement), Line (unit of measurement)
- tina (music), Cent (music), square (building area), Omer (Bible)
- Mark (weight), Stone (weight)
- Pound (mass)
- Stone (Chinese weight)
- Batman (mass measure)
- Oka (measure), Grain (measure)
- Pao (unit of mass), Cana (unit of length), Foot (unit of length)
- Pari (area), Degree (angle)
- Dram (unit)
- Hekat (volume unit)
I came across this when I saw editors using both Knot (speed) and Knot (unit). I could not decide which was better. Should there be more consistency? Lightmouse 11:59, 18 October 2007 (UTC)
- There is a wide variety of how much ambiguity there is in the word without any disambiguation. Furthermore, there are specific prior discussions of the naming in various things such as the move of Pascal to Pascal (unit) and its disambiguation page to Pascal.
- Most of those which represent only one unit do have a redirect from the "(unit)" disambiguation. For knot, the (speed) article is the original disambigation.
- Some of the little-used ones are probably badly named, including the improper dot in Tmc ft., and of dubious reason for existence in the same case (the same example).
- The foot (unit of length) is an ugly hangover from the old days, one that I wouldn't mind seeing changed, leaving the old one as a redirect. The simplest way to avoid that clumsiness is to use the redirect from feet. Its format was apparently emulated in some of the obscure disambiguations you mention.
- Some do need to disambiguate the same name being used for different units, used to measure different quantities.
- Some units are so hopelessly ambiguous that they should be outlawed from use in all Wikipedia articles except those describing them, such as a ton of different tons, many with their own articles in addition to the tonnage article. Let's go with all megagrams, gigagrams, and the like to replace the three or more different mass units masquerading under that ambiguous name for starters! Gene Nygaard 05:03, 19 October 2007 (UTC)
- Well, dammit, when did somebody change the redirect from feet to go to the body part? It used to work as I described it. Gene Nygaard 05:05, 19 October 2007 (UTC) I've changed the last chang back to go to the disambiguation page for now, should eventually go back where it was, see Talk:Feet. Gene Nygaard 05:38, 19 October 2007 (UTC)
- The format knot (speed) is better than knot (unit) because it is more likely to remove ambiguity. For example pound (unit) could mean any one of pound (mass), pound (force) and pound (currency). Thunderbird2 14:02, 20 October 2007 (UTC)
- I have been bold and moved the articles so they use the form suggested by Thunderbird2. Lightmouse 13:23, 24 October 2007 (UTC)
- The format knot (speed) is better than knot (unit) because it is more likely to remove ambiguity. For example pound (unit) could mean any one of pound (mass), pound (force) and pound (currency). Thunderbird2 14:02, 20 October 2007 (UTC)
A space before and after the en dash?
Articles on people have their birth and death dates in parentheses after their name (November 24, 1859 – January 24, 1917) or (November 24, 1859–January 24, 1917). An unanswered question comes up though. Should there be spaces around the en dash? The MoS shows both styles. This isn't a big deal, I hope, but there should be a preference. Also, birth and death places should never be included in the parentheses with the dates, right? Psychless 17:22, 20 October 2007 (UTC)
- If you dig through it thoroughly, it says no spaces around the en dash, unless one or both dates contain any spaces, so (November 24, 1859 – January 24, 1917) is correct, but (1859–1917) if only the years are known. Note the space after "c." in (c. 1859 – 1917), so spaces also go around the en dash. You are right that WP more or less discourages places inside the parentheses of the opening sentence. There was a clear prohibition until recently, when it was softened (despite the absence of a clear consenus to do so). There are a few editors who do not mind having the places in the opening, and might even bite if you move them to the body of the article, but I have moved many places out of the opening; these are mainly articles that have been copied from the 1911 Britannica, or were written by people who grew up reading the 1911 Britannica, so it seems right to them. Chris the speller 19:41, 20 October 2007 (UTC)
- I think i is a wacky distinction. I've seen no reason to change someone else's usage, nor to worry about my own. It is especially so since we are not dealing with fixed printed pages, but rather than dynamic pages with line breaks added on the fly, and because the people who run around changing things like his for us do not think of the consequences such at a very silly-looking and distracting en dash starting a line, because it broke before it (check out Chris the speller's examples in the paragraph above; some of you will likely see that problem with your current screen settings, and if not, you can add or subtract some characters from a line and hit preview to see it for yourself). If you are going to specify such a rule with dynamic line breaks, please fix it to specify that a non-breaking space be placed before the en dash. And not normally after it, perhaps in some unusual circumstances.
- Of course, the whole non-breaking stuff on the project page as it is now is nonsense, as discussed above, and has probably been changed and extended to strange areas without discussion. Gene Nygaard 02:05, 21 October 2007 (UTC)
The en dash looks awful when unspaced between items that have internal spaces. I don't see what the problem is. MOS is quite clear about it, and it's a simple rule to follow (also widely accepted out there). If page breaks are an issue, just insert a non-breaking space, as you're meant to in a host of situations. Tony (talk) 07:37, 24 October 2007 (UTC)
- A spaced en dash would look God-awful ugly in "The non – San Francisco part of the world":
- The non – San Francisco part of the world
- That's an example given at Dash#Compound adjectives—with no spaces around the en dash there, of course. —Preceding unsigned comment added by Gene Nygaard (talk • contribs) 14:26, 28 October 2007 (UTC)
- I wasn't aware that that section had been added to MOS. It's a different context, isn't it, from the date exemplified at the start of this section? On that section, I don't mind non–San Franscisco as an alternative to non-San-Fransisco, but would personally use the latter. I see that Scientific American, a journal that is superbly edited, IMV, tried the (unspaced) en dash in triple compounds for a while, but seems to have dropped it. Takes a while to get used to it. Tony (talk) 14:50, 28 October 2007 (UTC)
- A spaced en dash would look God-awful ugly in "The non – San Francisco part of the world":
- Certainly a compound of spaced items joined by an unspaced en dash is inelegant and awkward to parse.
- As for the hard space (an easier name than non-breaking space), it is often essential in HTML documents because of the unpredictable ways such documents get displayed (affected by browser, viewing settings, size of window, and style and size of font). This problem is compounded at Wikipedia, since our editors are uneven in skill and diligence. Dynamic pages indeed!
- We should, I think, educate editors about hard spaces and similar resources, pressing home the general theory behind them. Merely prescribing specific occasions for their use both looks mindlessly legalistic, and works against acceptance and recall. The theory of hard spaces is not rocket science: let's have a better section showing the techniques and motivations for their use – at WP:MOS where it belongs. We should press for an improved way of inputting hard spaces in Wikipedia editing, too.
- All that said, we can sometimes reduce the need for hard spaces, making life easier for everyone. Why, for example, must there be a space after c. (for "circa") before a date? Not only does it need to be hard itself, it often calls into being other hard spaces – before an en dash, for example (see discussion above). Oxford Guide Style (OGS) wants c. to be set close the number that follows it, presumably for a reason of this sort.
- In the end, I strongly favour pressing more of our guidelines into a central, enhanced, and well-crafted WP:MOS. There are many reasons for this, but the main one is that editors simply will not wade through reams of restrictive legalism in multiple pages – the majority of which are foreign territory even to core editors of WP:MOS. Things can be kept tight yet comprehensive there: but it will, I fear, require protocols for rational development and efficient discussion that so far elude us.
- – Noetica♬♩ Talk 10:04, 24 October 2007 (UTC)
- I'm a centralist, within reason, so I support Noetica's call for conflating this page into MOS. Much of the job has already been done. There are a few issues, though. Do we need the geographical coordinates stuff in the central MOS? The calendar stuff is not there either. I suppose that, as long as MOS is well organised and signposted, there's no particular technical limit to its size, unlike the limits placed on normal articles for the sake of readability. The table of contents, surely, comes into its own in a resource such as a centralised MOS. I note that MOSHEAD has recently been conflated, and the setting out of the information much improved in the process.
- I suppose I'm the user who has brought this on, by adding most of the revamped MOSNUM to MOS several months ago. There was not one objection to this when I flagged my intentions, either here or at MOS. My thinking was that numbers and dates are important enough to be included centrally.
- Again, I support the call for making hard spaces easier to key in, and promulgating the need for greater use of them by WPians. Rob Church, a developer, might have been a good person to contact; but he appears to have left after difficulties with other users. I sent him an email. Tony (talk) 03:26, 29 October 2007 (UTC)
- Some of us do prefer the places in the birth/death parenthetical in the lead, and there are thousands and thousands and thousands of bio articles doing that, so I don't see any clear actual consensus against it. I don't terribly mind it when those places aren't there, but really, the issue is so minor, I don't think the MOS needs to arm-twist either way. As for "non–San Franscisco"/"non – San Franscisco",
that's a no-brainer. That should be a hypen not an en-dash, and we don't space hyphens that way. I don't care if one magazine does it. They're simply being goofy.— SMcCandlish [talk] [cont] ‹(-¿-)› 15:48, 24 November 2007 (UTC)- It's been pointed out to me, out-of-band, that the Chicago Manual of Style actually advocates en dash usage in the SF example. That kind of blows my mind, and I can't find (so far) any other alleged authority agreeing with them, but even so I feel compelled to strike the above comment. MOS could say "there are two ways of doing this and we don't care which as long as it is consistent within the article", but I do not advocate that position myself. I think it looks completely bizarre, and the CMoS seems to conflict with itself, in advising en dash use when and on the basis that the two terms are not a compound but are being compared/contrasted ("the France–Germany border"), and then in not quite the same breath forgetting that there was a logical reason for this usage and then advocating using en dashes for a typographic effect in the genuinely-compound (San Francisco) case in question. But I can't deny that they do so advise. My current position is that this is an outlier, and that MoS is not compelled to agree with CMoS on every minor detail, esp. since that work often conflicts with other style guides on nitpicky points like this. I.e., I'm "almost neutral", in that I won't pitch a fit if MoS is wishywashy on it, but I would strongly prefer that it not be, and not go along with CMoS on a "just because" basis. We defy CMoS on logical bases pertaining to consistency and encyclopedicness here and there, so this could be (I do not at presently insist that it is) one of those exceptional cases. I dislike these "you can do it this way or that way" MoS un-stances for the most part, but actually advocated one myself, so I am not in a position to be a hardliner about this. Argh; I just realized I'm engaging in an off-topic discussion; this should be at MOS not MOSNUM. — SMcCandlish [talk] [cont] ‹(-¿-)› 07:02, 28 November 2007 (UTC)
Units of measurement
As per the consensus at Wikipedia_talk:Manual_of_Style#Units_of_measurement, I will be updating this guideline soon to match the new wording at the main MoS. If you have any comments on this change, please comment on the MoS talk page. Thank you. Tim Vickers 03:05, 29 October 2007 (UTC)
- Nice work, Tim. Tony (talk) 03:27, 29 October 2007 (UTC)
- Now updated. Tim Vickers 17:07, 29 October 2007 (UTC)
Contradiction between WP:MOSDATE and WP:MOSLINK
There seems to be a minor contradiction in the guidance offered by WP:MOSDATE and WP:MOSLINK.
According to Wikipedia:Manual of Style (dates and numbers)#Autoformatting and linking:
Piped links to pages that are more focused on a topic are possible (
[[1997 in South African sport|1997]]
), but cannot be used in full dates, where they break the date-linking function.
According to Wikipedia:Manual of Style (links)#Intuitiveness:
Years should not be linked to articles, such as 2003 in music or 1985 in film, especially when part of a date.
Both guidelines agree that links to "Year in Topic"-type articles should not be used inside full dates; however, whereas WP:MOSDATE suggests that such links are acceptable in some circumstances, WP:MOSLINK discourages them in all cases. Although both pages are guidelines and should be treated with common sense, contradictions can generate confusion.
I have left a notice regarding this discussion at Wikipedia talk:Manual of Style (links). – Black Falcon (Talk) 03:00, 1 November 2007 (UTC)
- Well, I'd much rather go with what is in MOSLINK. One of the problems with piped year-links is that hardly anyone clicks on them, because they look the same as those ridiculous links to plain year articles. Tony (talk) 03:43, 1 November 2007 (UTC)
- I agree. This problem has been addressed in at least one of the projects. See: WP:ALBUM#Dating:
- Quote: Do not use piped links to "years in music" e.g.
[[1991 in music|1991]]
, instead add (see 1991 in music) where you feel it is appropriate.
- Quote: Do not use piped links to "years in music" e.g.
- Lightmouse 15:16, 1 November 2007 (UTC)
- I agree. This problem has been addressed in at least one of the projects. See: WP:ALBUM#Dating:
- My view is that MOSLINK has its head in a dark place; but I address this more fully below in the related topic proposing changed language here. "Year in X" links often have legtimate purposes. — SMcCandlish [talk] [cont] ‹(-¿-)› 15:43, 24 November 2007 (UTC)
Superscript, unicode, html
I thought that there was a Wikipedia preference for a particular version of superscripts and times symbols. Certainly, I always prefer a version that looks wysiwyg in edit mode. Following a recent comment on my talk page, I looked for guidance and can't find any. Perhaps I just picked up the idea of a prefered version by seeing other editors changing the version. I am sure I have seen bots do it.
Can somebody explain what we are supposed to do with superscript, unicode and html characters? Lightmouse 15:09, 1 November 2007 (UTC)
- In some cases, like changing × to a simple symbol, or α to α, the change is innocuous. But changing superscripts like <sup>2</sup> to ² isn't good for math articles. The font comes out different in many cases, so an equation like x²=y75 looks strange. Moreover, when the internal TeX system creates HTML, it uses the <sup> method: <math>x^2</math> is rendered as <span class="texhtml"> <i>x</i> <sup>2</sup></span> by the Mediawiki TeX engine. So it's better, in math articles, not to replace superscripts by Unicode characters. — Carl (CBM · talk) 16:59, 1 November 2007 (UTC)
- There have also previously been complaints that using superscripted-characters instead of <sup> often produces characters that are too small to read, which I have found to be generally true for IE. ² is typically just readable, ³ is typically too small. I would suggest sticking to <sup>. Conversely of course, <sup> screws up the line spacing a bit. — Aluvus t/c 19:20, 1 November 2007 (UTC)
- My practice is to use the superscript characters only for unit symbols, and <sup> otherwise. There is also css code that can mitigate the line spacing issue, that could be added to user stylesheets or the site stylesheets if there is a consensus to do so —Random832 16:27, 2 November 2007 (UTC)
- I'd like to see this get fixed in the site-wide CSS, as it is not a numbers issue alone, but also affects any line with a superscripted inline template like {{fact}}. It would just be a fine adjustment of CSS line-height and would come at the cost of pages being slightly longer, due to using up marginally more whitespace per line. Many would find it more readable with that change anyway, though. Oh, and I agree: Stick with <sup>, not the Unicode chars. — SMcCandlish [talk] [cont] ‹(-¿-)› 15:41, 24 November 2007 (UTC)
- We already use plenty of line-height, we use 1+1⁄2-spacing. - what would fix it would be to reduce that for the <sup> tag, so that the superscripted material occupies the space between lines.—Random832 21:09, 29 November 2007 (UTC)
- I'd like to see this get fixed in the site-wide CSS, as it is not a numbers issue alone, but also affects any line with a superscripted inline template like {{fact}}. It would just be a fine adjustment of CSS line-height and would come at the cost of pages being slightly longer, due to using up marginally more whitespace per line. Many would find it more readable with that change anyway, though. Oh, and I agree: Stick with <sup>, not the Unicode chars. — SMcCandlish [talk] [cont] ‹(-¿-)› 15:41, 24 November 2007 (UTC)
Suggested addition
"Do not use an inappropriately high level of precision in coordinates. In latitude (or, longitude at the equator), one degree is about 110km, one minute 1.85km, and one second 30m. Longitude values are closer together further from the equator: at about 50 degrees latitude, one degree longitude is 72km, one minute is 1.2km, and one second is 20m."
I considered adding this in the section about coordinates, but figured i should get feedback on how to word this and where it should go. Also, maybe there should be additional guidance (large areas like countries, states, etc, should only be specified to degrees, cities only to minutes, but specific points of interest can be specified to seconds, or a fraction of a second, if known) —Random832 16:22, 2 November 2007 (UTC)
- It would need to be more general; this is not a problem with coordinates, its a problem with over-precision more generally. I.e., don't give numbers like 23.349349293249 unless there is a really, really good reason to do so (as there is with pi, with molecular weights, etc., but not with the length of a bridge. Or with geographic coordinates except in some really unusual cases.) — SMcCandlish [talk] [cont] ‹(-¿-)› 15:36, 24 November 2007 (UTC)
Fraction hyphenation
This rule surprised me - this seems like an uncommon way to do things, and while i could think of some circumstances where you would hyphenate ("a three-eighths-inch wrench"), they're generally the ones where the fraction is hyphenated with something else - you (or, at least, I) wouldn't write "One and three-quarters" or "three-quarters of an inch" —Random832 17:01, 2 November 2007 (UTC)
- Your examples of when to hyphenate fall under a different usage: that of compound attributive epithets, which are normally hyphenated (seven-year itch, much-needed break, but the break was much needed). North American writers are a little less likely to hyphenate where the item is unlikely to be ambiguous or unclear, although most do, at least in formal registers; and it must be said that many writers in other varieties of English fail to hyphenate in these circumstances when they should.
- To return to your basic question—three eighths versus three-eighths, the reason for hyphenating is that it's easier to read, and in some cases overcomes ambiguity. The issue is most poignant when broken at line's end: "... three
- eights of the standard measurement ..."
- as opposed to:
ambiguity. The issue is most poignant when broken at line's end: "... three-
- eights of the standard measurement ..."
Tony (talk) 23:35, 2 November 2007 (UTC)
- I don't see any ambiguity. There is a quantity called an "eighth", of which there are three. "three eighths" for 0.375 is no more ambiguous than "three dozen" for 36. What else could it possibly mean?—Random832 21:12, 29 November 2007 (UTC)
Neutrality of disambiguation pages concerning SI vs binary prefixes
It has been suggested here that it would be best to keep disambiguation of units like kb or MB strictly neutral by restricting any mention of the mega vs mebi debate to the articles themselves (kilobit and megabyte for the stated examples). I think it's a good idea, as it avoids unnecessary repetition of the same old arguments. Any thoughts? Thunderbird2 18:48, 4 November 2007 (UTC)
- I'm for it. The disambiguation pages are supposed to be summations anyways, and simply stating that they're a measurement of memory or storage as suggested gives a good summation. --Marty Goldberg 18:57, 4 November 2007 (UTC)
How about this example then (modelled on existing TB page, as suggested by the originator of the proposal):
- Terabit (Tb), a unit of information, commonly used to quantify computer memory or storage capacity
- Terabyte (TB), a unit of information, commonly used to quantify computer memory or storage capacity
Thunderbird2 20:24, 4 November 2007 (UTC)
- This would be better, it gets rid of the "commonly" which for the kibibyte entry would have to be "rarely" or "uncommonly".
Fnagaton 21:36, 4 November 2007 (UTC)
Good point, but the bit especially has other uses too (eg communications). How about "a unit of information used, for example, to quantify ..." Thunderbird2 21:53, 4 November 2007 (UTC)
I have edited the following disambiguations: ZB, EB, PB, TB, GB, MB and KB. Thunderbird2 23:50, 5 November 2007 (UTC)
And now: EIB, TIB, GIB and MIB. Thunderbird2 00:08, 6 November 2007 (UTC)
Proposal to make use of seasons unambiguous
My arguments are outlined here Discussion in Village Pump - Policy —Preceding unsigned comment added by 131.172.4.43 (talk) 01:34, 5 November 2007 (UTC)
- An interesting one. I back the sentiment of this proposal, but not its letter. In other words, the use of "spring 2009" is ambiguous and should be discouraged for that reason. But saying Jan-Mar 2009 is too specific, so that's no good either. A good guideline would be something like
- change to an unambiguous description of the season (but only if you're absolutely sure).
- The trouble is I can't think of a snappy way of saying "spring in the northern hemisphere" without spelling it out in full. Any suggestions? Thunderbird2 12:34, 5 November 2007 (UTC)
- I thought about this one for a while w/r/t Mac OS X v10.5, which for a while had a release date of "Spring 2007". I eventually came to the conclusion that simply putting that phrase in quotes, and attributing it to a company press release or representative, is the most accurate option avaiable to us given the expectations of WP:NOR and WP:V. It's tempting to try and explain hemispheres and such but I think our readers will understand this. -/- Warren 13:20, 5 November 2007 (UTC)
Thing is though, this confuses the hell out of people from the southern hemisphere. They shouldn't have to jump through hoops to find out reliable information just because this place is northern hemisphere-centric. —Preceding unsigned comment added by 131.172.4.43 (talk) 17:33, 5 November 2007 (UTC)
- I've discovered by looking around that often the ambiguity is removed in an article because it is in the context of a specific location (e.g., a named university campus or named city). Where that's not the case, use of a direct quote seems like the best solution if no better information is available, but surely an editor with better information should not be discouraged from making it unambiguous? As an example consider this article. It's nothing to do with IT or video releases, but it illustrates the problem. Essentially, in order to interpret the date "Spring 2007" correctly, the reader needs to know that the Victoria & Albert Museum is in the northern hemisphere. Many British editors and readers would know that, but an average reader in (say) South Africa or New Zealand may not. Isn't that the generic problem behind the proposal? The question is, how to convey that information unambiguously to the reader. There must be people out there who have encountered this problem before - but how did they solve it? Thunderbird2 17:46, 5 November 2007 (UTC)
- This one's gone rather quiet. I offer two more pieces of evidence. First, in Economic history of Brazil there is reference to "spring of 1994" and to "summer of 1998". I honestly have no idea what that means (the equator passes through the middle of Brazil), thus illustrating the need to break the ambiguity in that article at least. Second, in Astronomy on Mars there is reference to (for example) "Northern Spring" and "Southern Summer". Why not adopt this convention in case of (resolvable) ambiguity? Thunderbird2 (talk) 19:16, 18 November 2007 (UTC)
Ahh! Now that is an excellent idea. I fully support it.
-Zaij —Preceding unsigned comment added by 131.172.4.43 (talk) 11:46, 19 November 2007 (UTC)
Well, I see the problem, but not the solution. An article that read 'By the Spring of 1944, the war in Germany ...' would not read well as 'By the Northern Spring of 1944, the war in Germany ...' Hmains (talk) 04:35, 20 November 2007 (UTC)
- Don't leave us hanging in mid-sentence. Go on, what happened next? I can't wait to hear how this turns out. (SEWilco (talk) 04:44, 20 November 2007 (UTC))
- It would be best to avoid seasonal dating, but it is OK when the context makes the meaning apparent. When it is ambiguous the hemisphere should be indicated (when it matters; in gardening "Spring" might be sufficient). (SEWilco (talk) 04:49, 20 November 2007 (UTC))
- The phrase "If it ain't broke, don't fix it" is applicable here. Thus 'By the Spring of 1944, the war in Germany ...' is fine like it is because it's already unambiguous. But if you make that 'By the Spring of 1944, the economy of Brazil ...' then you have a problem. Thunderbird2 (talk) 08:31, 20 November 2007 (UTC)
- I just noticed that WP:SEASON already addresses this. Isn't the problem caused by editors not following the existing guidelines? Thunderbird2 (talk) 17:39, 22 November 2007 (UTC)
- I think you're right Thunderbird2. But I think the problem is very wide spread. Is there any way we can raise editors awareness to this issue? Also I still have a probelm with the fact that people think that because companies are ambiguous and use seasons as release dates (movies and TV season in particular) then it is okay for wiki to be ambiguous. For example 2007-08 United States network television schedule has the US Fall Schedule. I understand that the TV networks use this term a lot and within the USA it is well understood when they are talking about, but with TV shows being showed in Australia (sometimes) within the same week as in the US a lot of people in Aus use wiki to get info on the shows (not to mention people who illegally download the shows). Given this I (as reader from Aus) would not mind pages such as this using Fall frequently BUT there should be a clear note after the first usage that says something to the effect of "Fall schedule typically refers to the months of..." Shniken1 (talk) 23:52, 22 November 2007 (UTC)
- This page can't raise general awareness; too few editors are aware of it. WP:SEASON says all we can reasonably say. (I may be septentriocentric, but attempting to edit for someone who does not clue in that U.S. Fall schedule refers to the hemisphere in which the United States lies is the work of Sisyphus. Leave it to the Simple English wikipedia; that's what they're for.) Septentrionalis PMAnderson 06:38, 23 November 2007 (UTC)
- I think you're right Thunderbird2. But I think the problem is very wide spread. Is there any way we can raise editors awareness to this issue? Also I still have a probelm with the fact that people think that because companies are ambiguous and use seasons as release dates (movies and TV season in particular) then it is okay for wiki to be ambiguous. For example 2007-08 United States network television schedule has the US Fall Schedule. I understand that the TV networks use this term a lot and within the USA it is well understood when they are talking about, but with TV shows being showed in Australia (sometimes) within the same week as in the US a lot of people in Aus use wiki to get info on the shows (not to mention people who illegally download the shows). Given this I (as reader from Aus) would not mind pages such as this using Fall frequently BUT there should be a clear note after the first usage that says something to the effect of "Fall schedule typically refers to the months of..." Shniken1 (talk) 23:52, 22 November 2007 (UTC)
- Speak in terms of quarters, where appropriate if you have specific month ranges and they don't overlap quarters. Doesn't come up often. Use early-mid-late where that works, which is almost any where. I do this stuff all the time. I see a "summer 2008" and change it to mid 2008", a "winter 2006/2007" (which actually isn't ambiguous if you force Aussies to think about it, since their winter doesn't overlap years, but why make them think about this?) to "late 2006 – early 2007", and so on. Trivial, really. I don't think we need to have a huge thing about this in any of the MOS pages. — SMcCandlish [talk] [cont] ‹(-¿-)› 15:31, 24 November 2007 (UTC)
Inconsistent use of binary prefix by MediaWiki
Just recently noticed that MediaWiki is using the IEC prefixes: Search
Inconsistently, though... Image
Isn't that cute... -- mattb 23:49, 5 November 2007 (UTC)
Date linking wording
Currently, the section reads:
- Full dates, and days and months, are normally autoformatted, by inserting double square-brackets, as for linking. This instructs the WikiMedia software to format the item according to the date preferences chosen by registered users. It works only for users who are registered, and for all others (i.e. most) will be displayed as entered.
This is misleading. Someone not familiar with the situation can read it as meaning that dates are autoformatted automatically, with no action by an editor required. Since this page gives guidance towards editors, it should be rephrased to do just that. My suggestion is:
- For full dates, and days and months, autoformatting should be facilitated, by inserting double square-brackets when editing, similar to normal Wikipedia linking. This instructs the WikiMedia software to format the item according to the date preferences chosen by registered users. It works only for users who are registered, and for all others (i.e. most) will be displayed as entered.
The autoformat is not something which is enabled by the editor. Each user sets their own autoformat preferences. However, proper editing facilitates the autoformat, while omitting the square brackets means that autoformat will not work. Neier 12:34, 6 November 2007 (UTC)
- I had no problem with the original wording. The first rewrite by Neier removed the preference for linked dates. I restored that with a modified wording. In my vocabulary, the linking "enables" autoformat, because without it, autoformat cannot work. A user can select a preference or not. The word "facilitate" is not fully correct, since it means "to make easier". So far no reliable method has been found to autoformat without hints from an editor. −Woodstone 12:51, 6 November 2007 (UTC)
- How about: Full dates, and days and months, are autoformatted when double square-brackets are inserted by the editor, similar to normal Wikipedia linking. as the opening line? I definitely didn't intend to remove the preference for linked dates in the first revision, as I regularly correct articles that I notice which don't have the brackets. The current version still seems like it is too lenient, as it is possible to read it and think that no action is required when editing the article because the brackets are inserted by the software. We know that this is not the case, but, since the MoS is written as instructions to the editors, I think the ambiguity should be removed. Neier 13:07, 6 November 2007 (UTC)
- That wording again does not state explicitly that linking is preferred. It just says that "if" linked, the preferences will work. The opening line should be more like:
- "Full dates, and days and months, should preferably be prepared for autoformatting by inserting double square-brackets, similar to linking articles in Wikipedia."
- Woodstone 15:44, 6 November 2007 (UTC)
- Stating that it is done "for autoformatting" is really not needed when the next sentence explains that. I would suggest something like:
- Full dates, and days and months, should be wrapped in double square-brackets ([[ ]]), similar to internal links. This instructs the MediaWiki software to format the date according to the date formatting preferences of registered users. For unregistered users, and registered users that have not set a date format preference, the date will be displayed as entered.
- This also makes it more clear what the actual effect of auto-date-formatting is and tweaks some other wording. "Should generally" may be preferable to "should". Also, I am going to go ahead and correct "WikiMedia" to "MediaWiki". — Aluvus t/c 23:26, 6 November 2007 (UTC)
- Stating that it is done "for autoformatting" is really not needed when the next sentence explains that. I would suggest something like:
- I'm OK with either Woodstone's or Aluvus's version, as they both solve the problem that I see. Neier 23:32, 6 November 2007 (UTC)
- Sorry, "Full dates ... should be wrapped in double square-brackets" is not clear enough; putting double square-brackets around "February 14, 2007" does not work. The month-and-day pair needs to be linked separately from the year. Chris the speller 03:20, 7 November 2007 (UTC)
- I agree that it is somewhat ambiguous, but I couldn't come up with anything better. Do you have any ideas? Merely stating that square brackets should be "inserted" is actually slightly less clear (suppose someone interpreted that as suggesting "Janu]]ary 5, 20]]07", or something similarly odd). The examples of exactly what to do follow shortly after, which substantially reduces any confusion that might result either way. The examples should probably be moved up right after the first paragraph in the section, now that I think about it. — Aluvus t/c 05:24, 7 November 2007 (UTC)
- But, it is neither better nor worse in the ambiguity than the current version; so, that should not distract us from fixing the first problem first. The details for exactly how to place the brackets are spelled out later. Neier 00:06, 8 November 2007 (UTC)
- As someone who actively discourages the use of the dysfunctional autoformatting system (see archives here for a fuller discussion), I'm uncomfortable with wording that implies that it "should" be used. That is why we came to the idea of using "is normally", as a compromise with a few editors who think it should be mandatory. Tony (talk) 05:14, 7 November 2007 (UTC)
- Substituting "are normally" for "should be" in Aluvus's version should alleviate that concern; but, I guess I still disagree with the principle that until the software is modified (if ever) to untangle linkage from date prefs, that we should abstain from encouraging editors to try and make qualified dates (full dates, or day/month pairs) appear as the viewers would want them to. Neier 00:06, 8 November 2007 (UTC)
- The silly entanglement of linking and autoformatting is one thing, but there are a host of other issues. See archives here. On this matter, I haven't received a satisfactory answer from anyone to my question of why the dates on our signatures are autoformatted without being a blue splotch. Surely it's just a matter of nominating a simple code (<< date >>, or the like) that can hook into that signature-date process? Tony (talk) 02:07, 8 November 2007 (UTC)
- I think the signature dates are static, and don't follow the user prefs. My prefs are set for "month day, year", but, signatures on this entire talk page show up as "day month year". The code that writes to the database is separate from the code which formats when the page is viewed; if the dates are written as static text, then there is no formatting to occur. Neier 02:21, 8 November 2007 (UTC)
I share Tony's view. I too would discourage the use of the dysfunctional autoformatting system. In the continuum of forbidding to mandating, the mos is very close to mandating. I support any move back along the continuum away from mandating it. Lightmouse 08:52, 8 November 2007 (UTC)
- Forgive me if I've missed a previous part of this discussion, but telling people to not link (and therefore not autoformat) dates has the first impression upon me of saying to European users "tough! you've got to use US date format" Is that the case or is the request to not link/format part of a campaign to get the WP programmers to actually come up with a solution? - X201 09:12, 8 November 2007 (UTC)
- It's nothing to do with enforcing national date-formats; I'd rather put up with (within-article-consistent) US formats, which I dislike, than a system that spatters bright blue everywhere and is inflexible in ... four, is it? ... ways. Believe me, we've tried to get the WikiMedia developers to do something about it, but it's like trying to move a stationary ocean liner. Tony (talk) 09:58, 8 November 2007 (UTC)
- I'm with you on the "bright blue" and I don't like every date linking to a "date x in history" type page. The code to format the dates obviously exists so it only needs to be disconnected from the linking side of things. What was the developers reason for not changing/fixing it? - X201 10:08, 8 November 2007 (UTC)
- Despite its name, 'autoformatting' does not format automatically. It does not work for unregistered readers (there are lots of those). It does not work for registered readers that do not set a preference (such as myself). Thus many readers see whatever format the original editor used, whether US or non-US.
- Like many good ideas, autoformatting is unsatisfactory because of basic design flaws and inadequate implementation. This brutal cure is worse than the disease. Lightmouse 10:34, 8 November 2007 (UTC)
- Surely date formatting for both registered and unregistered users could be made available with a simple cookie? - X201 10:57, 8 November 2007 (UTC)
- I'm with you on the "bright blue" and I don't like every date linking to a "date x in history" type page. The code to format the dates obviously exists so it only needs to be disconnected from the linking side of things. What was the developers reason for not changing/fixing it? - X201 10:08, 8 November 2007 (UTC)
- It's nothing to do with enforcing national date-formats; I'd rather put up with (within-article-consistent) US formats, which I dislike, than a system that spatters bright blue everywhere and is inflexible in ... four, is it? ... ways. Believe me, we've tried to get the WikiMedia developers to do something about it, but it's like trying to move a stationary ocean liner. Tony (talk) 09:58, 8 November 2007 (UTC)
(Outdent) The response included:
Lack of substantive response means that none of us feels like writing the code, generally. If any of the 70 Wikipedians who were willing to spend a few seconds to sign a petition are willing and able to spend a few days or more writing the appropriate code and revising it in response to criticism, it might (but might not, admittedly) get approved. I'm not willing to commit (no pun intended) to review the patch, but another developer might be.
Gee, thanks. On the WP page that led to this push, there are now 85 signatories. I'm sure more would sign on now. But what's the use?
Full discourse is at http://bugzilla.wikimedia.org/show_bug.cgi?id=4582
BTW, other problems with the system are that, for example, you can't slash ("The air-raids on the night of 30/31 May"), you can't use date ranges ("20–27 August"); there are others I can't recall right now. Tony (talk) 13:54, 8 November 2007 (UTC)
And the archives here. Tony (talk) 13:56, 8 November 2007 (UTC)
- Here is a reminder: it can't cope with "5th November", "September 11th" and "4th of July". Currently, our editors are obliged to use "5 November", "September 11" and "4 July". Human formats are currently subservient to the machine formats. Lightmouse 18:51, 8 November 2007 (UTC)
- But "5th November" is not a format that Wikipedia guidelines permit, so I don't see that last argument as pertaining to this discussion. I understand that Tony and Lightmouse dislike and personally discourage use of the autoformatting, but the consensus has been and still is to link dates that contain month and day. The vast majority of the dates in WP articles are not slashed overnighters or date ranges, and the autoformatting works well in most cases. Chris the speller 21:48, 8 November 2007 (UTC)
- I agree. I notice that neither Tony nor Lightmouse have been editing long enough to recall the date format edit wars of the summer of 2003 which led to the present solution, but I have to strongly disagree that "This brutal cure is worse than the disease", and advocate that mandatory date-linking be encouraged notwithstanding any aesthetic disagreements over the blue links. -- Arwel (talk) 22:09, 8 November 2007 (UTC)
- But "5th November" is not a format that Wikipedia guidelines permit, so I don't see that last argument as pertaining to this discussion. I understand that Tony and Lightmouse dislike and personally discourage use of the autoformatting, but the consensus has been and still is to link dates that contain month and day. The vast majority of the dates in WP articles are not slashed overnighters or date ranges, and the autoformatting works well in most cases. Chris the speller 21:48, 8 November 2007 (UTC)
- I disagree. Links are a universal internet mechanism for jumping to a different page that elaborates, or ties together, a concept on the current page. We are now developing the situation where a click on part of a date is leading to a page that has nothing to do with the page just left. For example, this DVD release section has a linked date of January 15, 2008 (among others). Clicking on 2008 leads to a page that has nothing to do with the television show in question. And, I can just imagine how long the edit that puts a DVD release on the January 15 page would last (in an attempt to tie the two pages together so as to reduce the user's confusion as to where they have actually landed themselves). The cure is worse than the disease, and is aesthetically displeasing.140.168.69.130 00:16, 9 November 2007 (UTC)
- That page also contains: [[September 13]], [[1974 in television|1974]]. Wikipedia is full of such errors due to the inability of users to understand autoformatting. If there were high speed bots cleaning up the multiple and messy side-effects of the cure, it would not be so bad. Furthermore, to clarify for Chris, Wikipedia bans the "5th November" format because human formats are not permitted to supercede autoformatting formats. Lightmouse 13:26, 9 November 2007 (UTC)
- Lightmouse 13:26, 9 November 2007 (UTC)
- I'd rather put up with foreign date formats, just as 99% of readers do, since they don't log in and thus have no autoformatting display. Just as long as they're consistent within each article. Or fix it technically! Not willing to wait for that, however, since I suspect it won't happen for years. Tony (talk) 13:33, 9 November 2007 (UTC)
Spelling out numbers with scientific units
I think this item should be added to "exceptions" in the section "Spelling out numbers":
- Numbers followed by an abbreviated unit of measurement are not spelled out, for example 8 MB rather than eight MB and 4 km rather than four km. However, "eight megabytes" and "four kilometers" are also correct.
This convention is actually used in the section about units of measurement, without being mentioned explicitly. Han-Kwang (t) 22:37, 8 November 2007 (UTC)
- Sounds good to me. Tony (talk) 13:29, 9 November 2007 (UTC)
- I added this to the page: Numbers followed by an abbreviated unit of measurement, such as km for kilometer, are not spelled out. Examples: 4 km, 8 MB, . However, if the unit is spelled out, then the number is also spelled out, for example: four kilometers, eight megabytes. In a less technical context, spelling out both the number and the unit may be preferred. I added the last phrase because it is natural to use '4 km', '7 m/s' in scientific articles, but it would look strange in other contexts. Han-Kwang (t) 12:42, 12 November 2007 (UTC)
- Sounds good to me. Tony (talk) 13:29, 9 November 2007 (UTC)
Well Tony1, if you don't like the wording, how about commenting on the wording here? Han-Kwang (t) 11:33, 13 November 2007 (UTC)
In prose, the unit of measurement should always be spelled out, so this is only relevant to infoboxes, tables, parentheses, and the like, where the numbers are never spelled out anyway. —Centrx→talk • 04:40, 15 November 2007 (UTC)
- In scientific texts it is standard practice to abbreviate units of measurements. You will never find this: "The current density was less than five milliamperes per square centimeter." Rather, it would be written as "The current density was less than 5 mA/cm2." Now within the context of Wikipedia it depends on the article. For a technical article, the conventional scientific style is natural (liquid helium, pressure), while a biographical article describing how the person lived two kilometers from school would spell out both the number and the unit. By the way, WP:MOSNUM#Unit symbols and abbreviations gives more correct examples as well. Han-Kwang (t) 13:07, 15 November 2007 (UTC)
I don't know the conventions of how amendments to MoS pages are supposed to be done. I made a suggestion here, that I think makes reasonable sense, although the exact wording and its dealing with boundary cases might need to be polished. So my fellow Wikipedians, if you generally agree with my proposition, please add it (rephrased or not) to the MoS page. If not, say so, and leave the page as it is. But the ambiguous way the proposal has been dealt with so far looks like a waste of time for me, so I'm removing this page from my watchlist. Han-Kwang (t) 18:04, 18 November 2007 (UTC)
- I can understand your frustration. It's an issue I raised long ago, when the MoS wording probably wasn't as infected with instruction creep as it is now.
- NIST's Guide for the Use of the International System of Units (SI), 1995, NIST Special Publication 811 puts it quite succinctly in section 7.6:[9]
- 7.6 Symbols for numbers and units versus spelled-out names of numbers and units
- This Guide takes the position that the key elements of a scientific or technical paper, particularly the results of measurements and the values of quantities that influence the measurements, should be presented in a way that is as independent of language as possible. This will allow the paper to be understood by as broad an audience as possible, including readers with limited knowledge of English. Thus, to promote the comprehension of quantitative information in general and its broad understandability in particular, values of quantities should be expressed in acceptable units using
- the Arabic symbols for numbers, that is, the Arabic numerals, not the spelled-out names of the Arabic numerals; and
- the symbols for the units, not the spelled-out names of the units.
- Example: the length of the laser is 5 m but not: the length of the laser is five meters
- the sample was annealed at a temperature of 955 K for 12 h but not: the sample was annealed at a temperature of 955 kelvins for 12 hours
- Notes:
- 1. If the intended audience for a publication is unlikely to be familiar with a particular unit symbol, it should be defined when first used.
- 2. Because the use of the spelled-out name of an Arabic numeral with a unit symbol can cause confusion, such combinations must strictly be avoided. For example, one should never write "the length of the laser is five m."
- 3. Occasionally, a value is used in a descriptive or literary manner and it is fitting to use the spelled-out name of the unit rather than its symbol. Thus this Guide considers acceptable statements such as "the reading lamp was designed to take two 60-watt light bulbs," or "the rocket journeyed uneventfully across 380 000 kilometers of space," or "they bought a roll of 35-millimeter film for their camera."
- 4. The United States Government Printing Office Style Manual (Ref. [4], pp. 165-171) gives the rule that symbols for numbers are always to be used when one expresses (a) the value of a quantity in terms of a unit of measurement, (b) time (including dates), and (c) an amount of money. This publication should be consulted for the rules governing the choice between the use of symbols for numbers and the spelled-out names of numbers when numbers are dealt with in general.
- [end of quote]
- Note the citation to the GPO Style Manual rules as well.
- The same rationale for the NIST rule, that they "should be presented in a way that is as independent of language as possible" is especially applicable to the English Wikipedia.
- Han-Kwang was trying to make a point about scientific usage which the flip side of the coin of what NIST talks about in discussing use "in a descriptive or literary manner".
- The measured quantities aren't really "whole" numbers. No measured quantity is ever exact, no measured quantity can ever be exact. That doesn't mean that a definition using units of measurement cannot be exact, but how well any measurement fits that definition is never exact. Part of the problem is the slight vagueness in what is meant by a "whole number". You and I probably have a understanding of whole numbers counting numbers and integers which is different from what many editors will think of when they see "whole numbers". Talking about "five sheep" involves a different kind of number than the one used when talking about "5 km".
- Another part of the problem is, of course, overgeneralization and being prescriptive when it should be permissive. Han-Kwang's proposal suffered from that as much as what was here before. Han Kwang said, "However, if the unit is spelled out, then the number is also spelled out, for example: four kilometers, eight megabyte" but as Tony pointed out, "But not if the number is larger: 12 kilometres, 120 kilometres, 12 km, 120 km." Note also that while the NIST rule says not to use a spelled-out number with a unit symbol (don't use "five m"), it does not say that the converse is unacceptable: Arabic numerals may be used with the spelled out words in the cases where spelling the units out are acceptable (Tony's "120 kilometres"), something that NIST just did not bother addressing.
- My advice to Han-Kwang is to do like everyone else does—argue the MoS when it agrees with you; ignore it when it does not. Fortunately, most of the people who argue for ever-increasing spelled-out numbers don't know beans about science anyway and pretty much stay away from the number-intensive scientific articles and from anything where the units involved are more complex than "miles per hour". If you run into someone insisting on applying these particular rules inappropriately, go look for help in one of the science Wikipedia:WikiProjects; don't come here. Gene Nygaard (talk) 01:02, 19 November 2007 (UTC)
This strikes me as WP:BEANS. The number of editors going around doing "eight km" are near zero; there is no consensus I'm aware of that "8 kilometers" is offensive to anyone who is not so obsessed with grammatical nitpicks that even the MOS regulars think they are insane. I.e., where is the actual problem? That said, I don't mind a one-liner addition to MOSNUM that "eight km" is off-limits; I just don't think it's really necessary. — SMcCandlish [talk] [cont] ‹(-¿-)› 15:24, 24 November 2007 (UTC)
Proposal: Do not use surprise links
The albums project contains the following:
- Quote: Do not use piped links to "years in music" e.g.
[[1991 in music|1991]]
, instead add (see 1991 in music) where you feel it is appropriate.
I propose that we make that generic and include it. Lightmouse 11:09, 15 November 2007 (UTC)
- Any suggestions for generic wording? Lightmouse (talk) 12:35, 18 November 2007 (UTC)
- We could expand further; surprise links masked as single words are as bad as ones masked as years. But this should be a recommendation;
[[1991 in music|1991]]
can make perfect sense in a table, for example. Septentrionalis PMAnderson 06:32, 23 November 2007 (UTC)- It depends on the word that represents the pipe. The problem with years is that because they have been commonly linked but unpiped, readers tend to ignore the piped ones because they can't be bothered to check each blue-spattered year on the off-chance that it's piped to somewhere useful. The same does not generally apply to other words that are piped, although I concede that in some cases the principle is similar ("restaurant" --> "Chinese cuisine" in a recent FA, I seem to remember). Tony (talk) 12:07, 23 November 2007 (UTC)
- We could expand further; surprise links masked as single words are as bad as ones masked as years. But this should be a recommendation;
- Any suggestions for generic wording? Lightmouse (talk) 12:35, 18 November 2007 (UTC)
- If you would like to modify the scope that is fine by me, as long as this date problem is dealt with succinctly and strongly enough to have a real effect on editors. My proposal is to replace the following wording:
- Piped links to pages that are more focused on a topic are possible (
[[1997 in South African sport|1997]]
), but cannot be used in full dates, where they break the date-linking function.
- Piped links to pages that are more focused on a topic are possible (
- with
- Do not pipe a link from "year" to "year <something>" or "<something> year" e.g. [[1991 in music|1991]]. Use "(see [[1991 in music]])" if appropriate. Note that piped links break the date-linking function if used in full dates.
- Lightmouse (talk) 09:40, 23 November 2007 (UTC)
- If you would like to modify the scope that is fine by me, as long as this date problem is dealt with succinctly and strongly enough to have a real effect on editors. My proposal is to replace the following wording:
- I have to strenuously disagree. While I'm aware that somewhere in one of these guidelines there is an old recommendation to never use so-called "surprise links", this advice, which I surmise dates to around 2003 or so, has been completely abandoned in actual practice by the community. E.g. there is no longer any consensus at all that there is anything wrong with "composed of of silica and aloxite". Piped links exist for a reason. I don't see any rationale at all for enshrining a weird date-specific exception, and (Tony are you listening? ;-) I think it would be detrimental to our goals of ending the wikilinking of random bare-year dates, by removing any reader expectation that linked years every go anywhere vaguely useful. Rather, I think that we need to do the exact opposite and recommend not only that bare year dates never be linked as 1996, but also that the only time that such years should be linked is when the do go to a topically-relevant and -specific year article (1996 in baseball, or whatever). For WikiProject Sports I've been been formulating a guideline on when and when not to use such links (e.g.: "won third place in the 1996 World Championship" vs. "won the 1996 World Championshiop"). Agree that mentioning that piped links break the date-linking function if used in full dates is good to mention. Really, I think that proponents of this move simply do not frequently edit articles in which these sorts of links are useful (especially sports and entertainment stats tables come to mind, despite the music project's own advice). If I get shouted down on this, I might be able to compromise on their being permitted in tables, since I don't think they particularly are (or aren't) useful in general article prose, but do find them particularly useful in tables. Cf. WP:MOSFLAG - pretty much the same dividing line (except that the majority of editors, myself included, find flagicon use in main prose genuinely detrimental while sometimes useful in tables.) — SMcCandlish [talk] [cont] ‹(-¿-)› 15:19, 24 November 2007 (UTC)
- PS: Don't mistake me for an overlinker of dates; see my comments at the end of #Clarification about when to link to dates? (according to MOS), above. I don't advocate that "Year in X" date linking be done very much, only when it is truly germane. — SMcCandlish [talk] [cont] ‹(-¿-)› 16:08, 24 November 2007 (UTC)
- OK, I'm all ears; I hear you! Tony (talk) 07:11, 28 November 2007 (UTC)
- I am also listening. My proposed wording was just a suggestion, I would be interested to see other suggestions. Lightmouse (talk) 20:40, 28 November 2007 (UTC)
- SMcCandlish, I think your (compromise) proposal that they be permitted in tables is a good one. I disagree that the existence of piped links justifies these types of links in body copy, as I consider that too much of a "surprise". What if we changed the wording to discourage their use in copy (as above) but encourage their use in infobox and other tables where it makes sense? -- Renesis (talk) 00:49, 29 November 2007 (UTC)
- OK, how about:
- Do not pipe a link from "year" to "year <something>" or "<something> year" e.g. [[1991 in music|1991]] in copy text. Use "(see [[1991 in music]])" if appropriate. In tables, piped links are permitted if they make the table compact. Piped links must never be used in full dates because they break the date formatting function.
- Lightmouse (talk) 09:11, 29 November 2007 (UTC)
- What about links in football articles such as 1987–88? Woodym555 (talk) 11:33, 29 November 2007 (UTC)
- Alt. version:
- Avoid piping links from "year" to "year <something>" or "<something> year" (e.g.,
[[1991 in music|1991]]
) in the main prose of an article. Use "(see [[1991 in music]])", if it is appropriate to link a year to such an article at all. In places where compact presetation is important (some tables, infoboxes and lists), piped links may be useful. Piped links must never be used in full dates (e.g.[[January 1]], [[1991 in music|1991]]
) because they break the date-formatting function. Piped topical year links should only be made when the event in question is genuinely notable in the context of the year article to which would link.
- Avoid piping links from "year" to "year <something>" or "<something> year" (e.g.,
- — SMcCandlish [talk] [cont] ‹(-¿-)› 11:54, 29 November 2007 (UTC)
- OK, how about:
- SMcCandlish, I think your (compromise) proposal that they be permitted in tables is a good one. I disagree that the existence of piped links justifies these types of links in body copy, as I consider that too much of a "surprise". What if we changed the wording to discourage their use in copy (as above) but encourage their use in infobox and other tables where it makes sense? -- Renesis (talk) 00:49, 29 November 2007 (UTC)
- I am also listening. My proposed wording was just a suggestion, I would be interested to see other suggestions. Lightmouse (talk) 20:40, 28 November 2007 (UTC)
- OK, I'm all ears; I hear you! Tony (talk) 07:11, 28 November 2007 (UTC)
- Approve. Lightmouse (talk) 09:41, 6 December 2007 (UTC)
- Q: Any other pro/con on this one? — SMcCandlish [talk] [cont] ‹(-¿-)› 00:49, 12 December 2007 (UTC)
- I don't think my question regarding football dates such as 1987–88 has been answered. If we (Royal "we" of mere mortal WP:FOOTY editors) were to follow the new text, then we would have (See 1987-88 in English football) at the end of every other sentence. My recent WP:DASH sweep through Premier League as part of the FAR highlighted the fact that there are many season links in the article. All of them provide context that would be missed if they were to be "delinked". Woody (talk) 00:56, 12 December 2007 (UTC)
- I think that would indeed be an undesirable result. The point seems to be that such links shouldn't be used at all the main article prose. I'm honestly not sure I can agree with that, so it looks like we are right back to the drawing board. Some are opposed to "surprise links", period, others like me and I think you see them as very useful ways of avoiding redundant clutter wording in ever other sentence. Others think they should only be used in tables/lists of tabular data. I accidentally supported that viewpoint, but don't actually share it. I do think that "surprise" links should be used in such cases, but not that those should be the only cases. Anyway, it strikes me that we don't have consensus on this one way or the other yet. The proposal, and the language in MOSNUM presently both do not adequately deal with the situations that arise. — SMcCandlish [talk] [cont] ‹(-¿-)› 20:48, 12 December 2007 (UTC)
- You read my feelings perfectly. I am currently of the opinion that they do no harm. I don't think that consensus will be very forthcoming, given that peoples views vary differently. Trying to accomadate everyone's views leads to watered down text that actually helps no-one.
Re-proposal
New version to address issue raised by Woody:
*Avoid piping links from "year" to "year something" or "something year" (e.g.,[[1991 in music|1991]]
) in the main prose of an article. Use an explicit cross-reference, e.g.''(see [[1991 in music]])''
, if it is appropriate to link a year to such an article at all. In places where compact presentation is important (some tables, infoboxes and lists), piped links may be useful. Another exception is the main prose of articles in which such links are used heavily, as if often the case with sportsperson biographies that link to numerous separate season articles, in which the''(see ...)''
phrasing would rapidly become repetitive and cluttering; in such a case it is best to make it clear that the link is to such a topical date article, e.g.in [[2007/2008 snooker season|the 2007/2008 season]]
, rather thanin [[2007/2008 snooker season|2007/2008]]
. Piped links must never be used in full dates (e.g.[[January 1]], [[1991 in music|1991]]
) because they break the date-formatting function. Topical date links should only be used when the event in question is genuinely notable in the context of the year (or month, etc.) article to which would link.
Revised version below.
I think this will adequately address the cases that need to be addressed so far, and would actually slightly help advance the growing consensus that a replacement for the date formatting function is needed so that dates are only linked when there is a contextual/informative reason for linking them.
PS: If we wanted to address piped links other than dates, I believe that is a way bigger matter, and should be discussed at WT:MOS, probably with an RfC, since it is bound to be highly controversial.
— SMcCandlish [talk] [cont] ‹(-¿-)› 21:00, 12 December 2007 (UTC)
- I agree with almost all of those points. That addresses all cases brought up so far, but this is a very insular forum for something like this. If the discussion were to be broadcast, I think you would find a wide variety of subjects where these links are useful. The date formatting function is a whole different kettle of fish. (metaphor about barge pole comes to mind). Also agree that "hidden links" is a topic that needs wider discussion. Your text seems fine for what it is, yet to me it seems complicated and too wordy. There are too many exceptions for it to be a useful editing guideline. (IMO of course). Woody (talk) 21:13, 12 December 2007 (UTC)
- It can be made more readable with indented bullet points. The insularity is intended, because we're only trying to address over- and inappropriate date linking without opening a larger can of "hidden links" worms. I'm sure there are other cases where such date links arise, but isn't mentioning both music and sports good enough to get it across that we're speaking in generalities? I wouldn't want to see us list 15 "different" exceptions that aren't really different in a meaningful way. :-) Here's a revised version:
- Avoid piping links from "year" to "year something" or "something year" (e.g.,
[[1991 in music|1991]]
) in the main prose of an article in most cases. Use an explicit cross-reference, e.g.''(see [[1991 in music]])''
, if it is appropriate to link a year to such an article at all. Exceptions:
- Piped links may be useful in places where compact presentation is important (some tables, infoboxes and lists).
- Piped links may also be useful in the main prose of articles in which such links are used heavily, as is often the case with sportsperson biographies that link to numerous separate season articles.
- Avoid piping links from "year" to "year something" or "something year" (e.g.,
- Piped links must never be used in full dates (e.g.
[[January 1]], [[1991 in music|1991]]
) because they break the date-formatting function. When using piped links, it is best to clearly indicate that the link is to such a topical date article, e.g.in [[2007/2008 snooker season|the 2007/2008 season]]
, rather thanin [[2007/2008 snooker season|2007/2008]]
- A topical date link should only be used when the event in question is genuinely notable in the context of the year (or month, etc.) article to which it would link.
- It can be made more readable with indented bullet points. The insularity is intended, because we're only trying to address over- and inappropriate date linking without opening a larger can of "hidden links" worms. I'm sure there are other cases where such date links arise, but isn't mentioning both music and sports good enough to get it across that we're speaking in generalities? I wouldn't want to see us list 15 "different" exceptions that aren't really different in a meaningful way. :-) Here's a revised version:
- How's that? — SMcCandlish [talk] [cont] ‹(-¿-)› 00:44, 13 December 2007 (UTC)
- Looks good to me. Lightmouse (talk) 13:20, 15 December 2007 (UTC)
I think input from more editors is required before removing "surprise links" from every article. It should be discussed at the village pump. --Pixelface (talk) 12:33, 16 December 2007 (UTC)
The fluid ounce
Just a thought - should there be a comment as to the fact that the fluid ounce as a unit has two (and a half) definitions, and should be specified in a manner similar to gallon? Or would that be a case of over-advising when they differ by only about 5%? --Neo 16:40, 16 November 2007 (UTC)
- When editing, one should always try to be specific; U.S. fluid ounce or imperial fluid ounce, not just fluid ounce. However, should we have a specific comment here in the MOS/MOSNUM? No. The examples regarding the gallons, tons, and miles are general examples. Those examples should imply that when a unit has the same name in the imperial system as the U.S. customary system but measure differently then an editor should be specific. —-- MJCdetroit (talk) 17:02, 16 November 2007 (UTC)
100m dash
Phrases like "100m Dash" and "100m Relay" are far more common than their spaced equivalents "100 m Dash" and "100 m Relay", according to Google. Should there be another exception to "Values and unit symbols are spaced (25 kg, not 25kg)" from MOS:NUM#Unit symbols and abbreviations? Art LaPella (talk) 03:54, 18 November 2007 (UTC)
- If you follow google blindly you will end up with a random hotch-potch of exceptions that would defeat any attempt at standardisation, whereas the whole point of the style manual is to promote uniformity. If you don't like "100 m dash" why not hyphenate? (100-m dash). Thunderbird2 (talk) 09:48, 18 November 2007 (UTC)
- I do not care whether the unit is a symbol or written in full. But please don't use a hyphen. The famous quote is: If you take hyphens seriously, you will surely go mad. Lightmouse (talk) 12:51, 18 November 2007 (UTC)
- Do not take it personally. It is only a quote. Lightmouse (talk) 15:00, 18 November 2007 (UTC)
- I agree with Tony; the hyphens belong there with spelled-out units, not with unit symbols. And the spaces belong there. Gene Nygaard (talk) 23:50, 18 November 2007 (UTC)
- Concur with Gene and Tony on the hyphens thing. — SMcCandlish [talk] [cont] ‹(-¿-)› 15:07, 24 November 2007 (UTC)
- I agree with Tony; the hyphens belong there with spelled-out units, not with unit symbols. And the spaces belong there. Gene Nygaard (talk) 23:50, 18 November 2007 (UTC)
- The 'space before units in names' issue has arisen in the Fireams Project. They are considering whether the convention should be '7.62mm' or '7.62 mm'. Please contribute at: WP Firearms.
- Lightmouse (talk) 19:52, 27 November 2007 (UTC)
(outdent) And although we don't have to follow SI, they do say not to hyphenate double-adjective values/units when the unit is abbreviated (i.e., is a symbol). The same applies to measures of time (12-hour shift; 12 hr shift). IMO, it's a good rule. Note that the American Chemical Society prescribes differently, and many journals follow its house style:
Hyphenate a number and a unit of time or measure used as a unit modifier—12-min exposure, 10-mg sample, 20-mL aliquot, 4-mm-thick layer
I don't like the look of it. Tony (talk) 07:22, 28 November 2007 (UTC)
- I concur. Hyphenating an abbreviation seems pedantic to me. Feezo (Talk) 05:32, 29 November 2007 (UTC)
- Don't entirely concur; it is perfectly normal (but optional) to hyphenate compound adjectives. It's part of what helps us determine that they are compound adjectives sometimes. While these examples, in this rather blank context, are not ambiguous, the case could easily be different for the same strings if found in prose that was thick with numerals. It should be left to the discretion of the editor. — SMcCandlish [talk] [cont] ‹(-¿-)› 11:32, 29 November 2007 (UTC)
Terms of art
Hmm... I detect a terms of art conflict here. Definitely in the gun world, "9mm" is a term of art; it is a name for a caliber of bullet and the weapon that fires it, that is derived from a measurement. It isn't really "nine milimeters" (= "9 mm"), nor is it ever spelled out as "nine-milimeter" (unless someone foolishly constructs a sentence that requires this conversion by putting it at the beginning). In fact spacing 9mm would be a very bad idea, because if you write "9 mm pistol" you are talking about the world's smallest firearm (remember, we do not hyphenate the compound-adjective measurements when the unit is abbreviated: 9-mm pistol), not a caliber. And in looking around on this (Google, gun sites, etc.), the spaced spelling is pretty close to astronomically dwarfed by the non-spaced version. I think that "100m dash" is a similar case; it isn't a measurement per se in that context, but the name of an event in athletics competitions that happens to be derived from a measurement. MOSNUM is already making a term-of-art exception or two, so adding a couple more won't kill anyone; it just needs to be unambiguous so it cannot be misinterpreted to permit non-spacing otherwise. — SMcCandlish [talk] [cont] ‹(-¿-)› 11:28, 29 November 2007 (UTC)
Conversions: Confusion and Clarification
I accidentally saved this edit while half way through typing the explanation. Hopefully the edit speaks for itself, but just in case it doesn't, what I meant to say was this:
- The end is ensure comparable precision
- In order to achieve this end, sometimes it is necessary to use more sig figs in the converted number than in the original (the example being 1 mi converted to 1.6 km).
Thunderbird2 (talk) 14:01, 18 November 2007 (UTC)
- That isn't really the problem, nor the solution. Furthermore, it is misleading, becauew 1 mi often ought to be converted to 2 km, and sometimes it has even less precision than that and ought to be converted to 1 km. Gene Nygaard (talk) 14:35, 18 November 2007 (UTC)
- I agree that 1 mi should occasionally be rounded to 1 km, but to say so would have changed the intended meaning of what was already there. To implement your implied suggestion would involve making the advice context sensitive. Do you have a form of words in mind? Thunderbird2 (talk) 14:42, 18 November 2007 (UTC)
- I oppose this clause and would like it removed. It is sometimes totally false. Furthermore, I would be surprised if it makes the slightest difference to what people do for the minority of cases where it occurs. Lightmouse (talk) 14:59, 18 November 2007 (UTC)
- If the 2nd half of the clause is controversial, why not leave it out altogether? ie leave only
- Converted values should use a level of precision similar to that of the source value; for example, the Moon is 380,000 kilometres (240,000 mi) from Earth, not ... (236,121 mi).
- Thunderbird2 (talk) 15:21, 18 November 2007 (UTC)
- If the 2nd half of the clause is controversial, why not leave it out altogether? ie leave only
One of the many factors involved here, something I didn't make clear before, is that this problem more often arises not with numbers such as "one mile" or "1 mi" but rather, more likely, with numbers such as "30 miles" or "600 feet" or whatever. Using "1 mi" as an example is especially bad.
If one mile really should be 1.6 km, maybe that miles figure ought to be expressed as "1.0 mi".
In cases such as "30 miles" or "600 feet", the problem is that we have trailing zeros before the decimal point. Those might be significant zeros; be we don't know by looking at one individual number whether they are or not: "600 feet" might be accurate to the nearest foot, or it might be accurate to the nearest hundred feet or the nearest ten feet. We simply don't know by looking at one number, isolated from any additional clues we might pick up from the context. Furthermore, it isn't necessarily limited to decimal precision; that 600 foot figure might actually be to the nearest 25 feet, or to the nearest 50 feet. Or it might itself be a conversion of an unstated original number expressed as 200 yards, whose precision might be the nearest yard, or the nearest 10 yards, or the nearest hundred yards.
- Note that if the trailing zero follows the decimal point, as in the case of the "1.0 mi" I mentioned above, it should usually be considered significant.
- Sometimes you can tell by comparing to other numbers used in a similar context in the same article.
- Or you can tell from your general knowledge that, for example, heights of mountains are often expressed to either the nearest whole foot or the nearest whole meter (while also recognizing simple common knowledge such as that if you are talking about an active volcano, the numbers often are much more imprecise).
Comparable precision is an admirable goal. Those who ignore one set of measurements ought to get basically the same information as those who ignore the other set of measurements. The problem is that the real world doesn't always help us out, in our efforts to determine how precise (and how accurate as well) these numbers really are. And you aren't going to write a simple rule which will always work for that.
Another factor to consider is that even if our sources of information themselves contain a conversion of a measurement, such conversions are often the least reliable information contained in the source. Often they are added by some innumerate clerical worker quite removed from the whole process, not by someone familiar with the making of those measurements and their actual precision. Wikipedia isn't the only place where people make ridiculously overprecise conversions (and OTOH, underprecise ones as well), nor are we the only place where people misidentify the units being converted and consequently use an improper conversion factor, where people use conversion factors too imprecise for the actual precision of the measurement, or simply transpose some numbers in entering a number into a calculator or in transcribing the results in the text. Gene Nygaard (talk) 15:24, 18 November 2007 (UTC)
- Other clues from the context that are far too often ignored are words such a "roughly", "about", "approximately", "roundly", and a host of others. There are already far too many "roughly 1 mile (1.6 km)" entries in Wikipedia now, we don't need to encourage more of them.
- Some people just don't seem to understand the philosophy of including conversions. We are not trying to provide people with conversion factors by including these conversions. Rather, we are trying to present information that makes sense, even if the number being converted from isn't well understood by a particular reader and is therefore ignored by that reader. Gene Nygaard (talk) 15:40, 18 November 2007 (UTC)
- I hear no defence of the present wording - only criticism. This I interpret as consensus to remove the offending text, in the form of the second sentence. Thunderbird2 (talk) 19:04, 18 November 2007 (UTC)
Frequent links to 1916, 1945 etc because they are war years
The article Andrew Cunningham, 1st Viscount Cunningham of Hyndhope has solitary year links to 1915, 1916, 1939, 1940, and 1945. An editor says that these solitary year links are required to provide 'context of wars'. These years are frequently linked on Wikipedia. What do people think about linking to years for 'context of wars'? Lightmouse (talk) 11:29, 29 November 2007 (UTC)
- Hi, I'm the editor, and I think it is useful to provide these links, they provide context that the reader would not otherwise be able to acquire. Woodym555 (talk) 11:32, 29 November 2007 (UTC)
- I bothered to go to 1916, to find the following information at the start, which really enlightens us on the topic, except for one item buried in the middle. The blood transfusion thing might just be relevant, but really, this is a diversion we don't want when reading the article, which would be very wanting if it needed this entertainment in the middle of concentrating on its account.
- For heaven's sake there's nothing stopping the rare diversion-hungry reader from typing in the four characters and going there manually.
1 January - The Royal Army Medical Corps first successful blood transfusion using blood that had been stored and cooled.
Impressionist painter Monet paints Water Lilies series.
5 January - Rainmaker Charles Hatfield - begins; it will cause flooding around San Diego, California
8 January - Allied forces withdraw from Gallipoli
13 January/14 - A heavy storm sweeps through the Zuiderzee in the Netherlands, causing extensive damage. This storm helped the Dutch parliament to decide to build the Afsluitdijk and build polders in the current IJsselmeer.
17 January - The Professional Golfers Association of America (PGA) is formed
18 January - A 611 gram chondrite type meteorite struck a house near Baxter, Stone County, Missouri.
23 January to 24 January In Browning, Montana, the temperature drops from +6.7°C to -48.8°C (44°F to -56°F) in one day, the greatest change ever on record for a 24-hour period.
24 January - In Brushaber v. Union Pacific Railroad the Supreme Court of the United States upholds the federal income tax
28 January - Louis D. Brandeis becomes the first Jew appointed to the Supreme Court of the United States.
Tony (talk) 11:39, 29 November 2007 (UTC)
Was that a rebuttal? Woodym555 (talk) 15:30, 29 November 2007 (UTC)unhelpful Woodym555 (talk) 15:46, 29 November 2007 (UTC)- That was January Tony, Allied Forces withdraw from Gallipoli is context, Gallipoli was a very important battle. All throughout that page there are lots of links to battles and people within the context of World War One. The argument that they could just type it, could be said for every single wikilink. What is wrong with having it wikilinked? Is it harming the encyclopedia to have 5 years that provide some context, wikilinked? Woodym555 (talk) 15:46, 29 November 2007 (UTC)
- There's nothing special about those years, and the year articles are incomplete (while if encyclopedically complete would be unusable and take 30 minutes to load, so they are screwed no matter which way you look it). They are not useful to anyone other than someone specifically seeking a chronology (e.g. "I wonder what was going on the year I was born"), in which case they are going to be very disappointed, since little if any editorial judgement and effort has been brought to bear on the year articles. They do not provide context, they simply provide a completely random list of entirely unrelated things; that is anti-context. It is what WP:OVERCAT calls a non-defining intersection with regard to the Category namespace; the underlying concept applies just as well here. — SMcCandlish [talk] [cont] ‹(-¿-)› 19:09, 29 November 2007 (UTC)
- If they are incomplete or suffer from a lack of editorial judgement, then improve them, you know, build an encyclopedia? The same could be said for must stubs, they provide little context, so remove them. I am fed up of this kind of reasoning, improve them if you don't like them so much. The years do provide context. If you wanted to know what other battles/incidents that would affect the decision making in 1916 for a particular battle, say Gallipoli, then you would use the 1916 article as a starting point. In that sense, it works. Also, would the person who brought me before this Kangaroo Court care to offer their own opinions on the matter? Woodym555 (talk) 12:35, 30 November 2007 (UTC)
A disambig page 4.5 inch (114 mm) gun has entries for these articles:
- QF 4.5 inch naval gun
- 4.5 inch (114 mm) Mark 8 naval gun
- BL 4.5 inch Medium Field Gun
- 4.5 inch Gun M1
Of course, standard hyphenation would give "4.5-inch gun". Is there some specific exception for hyphens in military and naval specifications of gun bores and similar measurements? If not, there are a lot of articles to be moved, most of them bound to ruffle a few feathers, and then many corresponding corrections in the text and/or infoboxes. Is this worth doing? Chris the speller (talk) 05:43, 30 November 2007 (UTC)
- Those article names look correct to me. I only use the format "40 millimetre gun" and "40 mm gun". I only replace a space with a hyphen if a reasonable reader is likely to be confused otherwise. My guideline is simple to understand, simple to apply and consistent.
- I know that others disagree and have more complicated rules. One rule appears to be 'adjectival forms must have hyphens'. My knowledge of English grammar is unsophisticated so I can't use such abstract rules (I have similar problems with rules that require me to spot prepositions and 'short words' in 'Headline Case'). I can't see why "40 millimetre gun" is adjectival and therefore requires a hyphen and "40 mm gun" is not adjectival and does not require a hyphen.
- Similarly, I never add a hyphen to "20th century" but many people on Wikipedia do. Perhaps the 'adjectival form' question applies there too.
- I am not alone in questioning the hyphen. Others include Winston Churchill, Woodrow Wilson, Sir Ernest Gowers, and Fowler. Unfortunately, I appear to be in the minority in questioning it on Wikipedia. Lightmouse (talk) 12:26, 30 November 2007 (UTC)
- I agree with Lightmouse to the extent that those names "look right" to me too, but I suspect this to be another one of those UK vs US style issues. Where I would normally write "40 mm gun" (or equivalently "40 millimetre gun"), I suspect an American would prefer "40-mm gun" (or "40-millimeter gun"). My reasoning is that in both cases the "40" is an adjective, and Americans love hyphenating adjectives. In my opinion both are correct. Thunderbird2 17:15, 30 November 2007 (UTC)
- Actually, North Americans are less likely to hyphenate double attributive adjectives than other English speakers. See MOS on hyphens. All the same, I encourage NAs to use hyphens where they make it easier for readers, particularly in highly scientific/technical text, where the experts become used to perceiving commonly used double adjectives without hyphens, without realising that in an encyclopedia the text needs to be more accessible. Tony (talk) 04:48, 4 December 2007 (UTC)
- Tony, that section on hyphens is very well written. I assume that you wrote much, if not all, of it. I frequently learn from your contributions. I do use hyphens for many of the cases there even if I do not know how to describe why. I am not convinced of the need for hyphens in *all* of the cases listed there. I would almost certainly not add hyphens to "well meaning gesture", "the turkeys were hand fed" and "the child was well behaved". I do not know what an 'NA' is, but I support your appeal to use the hyphen as a tool to make things easier for readers. Lightmouse 20:04, 4 December 2007 (UTC)
- I would hyphenate the first of those (and am an American). As with other MOS debates in which alleged US vs. UK issues arise, this one does not consistently play out geographically in actual practice. Many people, regardless of where they grew up, drop the hyphens while others prefer them. PS: The second two would not be hyphenated by anyone, vs. "the hand-fed turkeys" and "the well-behaved child". Most who are conscientious of hyphenation of compound adjectives at all, would hyphenate "the hand-fed turkeys", but a somewhat smaller percentage would hyphenate "the well-behaved child" due to some CMoS weirdness on this topic. — SMcCandlish [talk] [cont] ‹(-¿-)› 08:14, 5 December 2007 (UTC)
- I'm guessing NAs is an abbreviation for "North Americans". Thunderbird2 20:01, 4 December 2007 (UTC)
- Tony, that section on hyphens is very well written. I assume that you wrote much, if not all, of it. I frequently learn from your contributions. I do use hyphens for many of the cases there even if I do not know how to describe why. I am not convinced of the need for hyphens in *all* of the cases listed there. I would almost certainly not add hyphens to "well meaning gesture", "the turkeys were hand fed" and "the child was well behaved". I do not know what an 'NA' is, but I support your appeal to use the hyphen as a tool to make things easier for readers. Lightmouse 20:04, 4 December 2007 (UTC)
Coordinates for Rivers
For what part of a river should the title coordinates be? Should it be the mouth, the source, central location, midpoint or what? S♦s♦e♦b♦a♦l♦l♦o♦s (Talk to Me) 20:33, 1 December 2007 (UTC)
- The source is usually not really an identifyable single point. At the mouth it also spreads quite often, making the end point unclear. Very often, in the middle it is a well defined stream. So I would go for a point on the river somewhere in the middle. That should preferably defined as a point equally far from the source and the mouth. Displaying a map centered on that point to a certain scale is then likely to show the whole river. −Woodstone 10:29, 2 December 2007 (UTC)
- If the source is ill-defined, and the mouth is also ill-defined, then surely a point half-way between them is also ill-defined? I would choose the river mouth, which for most rivers is pretty unambiguous. Thunderbird2 10:58, 2 December 2007 (UTC)
- At the source and mouth there is often a wide geographic spread. At the middle, mostly the stream is well defined. Which point exactly to choose still has some one dimensional variablility. Any choice would be a good indicator of the river. A possible choice could be to consider the furthest source and termination points. Still it is theoretically possible that this does not define a unique point for a winding river, but let's check how serious this might be. Still the argument is valid that a map centered on the given coordinate should have a good chance of showing the whole river. −Woodstone 05:04, 3 December 2007 (UTC)
I would suggest that this issue is raised on the Wikipedia talk:WikiProject Rivers page and the results of the conversation reported back here. --Philip Baird Shearer 14:34, 2 December 2007 (UTC)
- Discussion at Wikipedia talk:WikiProject Geographical coordinates recently mentioned there is a {{Geolinks-US-river}} which uses the start and mouth of a river. -- SEWilco (talk) 05:57, 3 December 2007 (UTC)
- That is a template (and a regional one only). Here we were talking about the title coordinate, which has a special role in an article and must be unique. As a refinement of the definition we might use:
- the point on a river, closest to the midpoint of the smallest circle containing all of its up- and downstream branches.
- −Woodstone 05:50, 4 December 2007 (UTC)
- That is a template (and a regional one only). Here we were talking about the title coordinate, which has a special role in an article and must be unique. As a refinement of the definition we might use:
- (Sheesh! Does this talk page need archiving! Glad I've chosen not to wade in here often!) Woodstone, it does my heart good to see such a sensible suggestion put forward. But do please remove that incorrect comma, and preferably adjust the wording a little: a point on the river that lies nearest to the centre of the smallest circle that encloses the river, with all of its upstream and downstream branches. How's that? Use a point, not the point: there might be more than one, equidistant from the centre. Use centre, not midpoint: it's unnecessarily distracting to have an echo of the word point in the same sentence.
- – Noetica♬♩ Talk 07:31, 4 December 2007 (UTC)
Inconsistent
This article states:
- "Wikipedia has articles on days of the year, years, decades, centuries and millennia. Link to one of these pages only if it is likely to deepen readers' understanding of a topic. Piped links to pages that are more focused on a topic are possible (1997), but cannot be used in full dates, where they break the date-linking function."
All dates and years in this article shouldn't be linked, should they? Kameejl (Talk) 16:05, 3 December 2007 (UTC)
- I don't understand what you are asking. Tony (talk) 04:45, 4 December 2007 (UTC)
- Dates and years are linked in this MOS (e.g. 1998 instead of 1998 and 8 November instead of 8 November). The MOS prescribes that dates/years should only link to date/year article "if it is likely to deepen readers' understanding of a topic". Most years/dates in this topic are (formating) examples and are not likely to deepen readers' understanding of this MOS, hence, they should not link to date/year articles. Kameejl (Talk) 09:22, 4 December 2007 (UTC)
- Ah, there are just a couple in the "Dates if birth and death" subsection. Feel like delinking them? If there's a numbered date (8 in 8 November), that's autoformatted. I wouldn't use the autoformatting dysfunction, but I think some folk would object to changing that on the page. Tony (talk) 10:07, 4 December 2007 (UTC)
- Dates and years are linked in this MOS (e.g. 1998 instead of 1998 and 8 November instead of 8 November). The MOS prescribes that dates/years should only link to date/year article "if it is likely to deepen readers' understanding of a topic". Most years/dates in this topic are (formating) examples and are not likely to deepen readers' understanding of this MOS, hence, they should not link to date/year articles. Kameejl (Talk) 09:22, 4 December 2007 (UTC)
- Thanks for bringing this to our attention. Please make the MOS conform to the MOS. Lightmouse 20:08, 4 December 2007 (UTC)
- Definitely. Partial dates shouldn't be linked. — SMcCandlish [talk] [cont] ‹(-¿-)› 08:15, 5 December 2007 (UTC)
- Thanks for bringing this to our attention. Please make the MOS conform to the MOS. Lightmouse 20:08, 4 December 2007 (UTC)
How should we treat dates in general? Per guideline stated above practically all dates and years should be unlinked (f.e. how is 1981 going to deepen a reader's understanding of Metallica? Or December 2 in Britney Spears?). I totally agree with this guideline and tend to remove all unnecessary date and year links I come across. I think those links attract attention - one is more likely to see the blue text when quick scanning an article - but they link to articles generally unrelated to the articles they are in.
So how should we treat days of the year, years, decades, centuries and millennia? Kameejl (Talk) 12:32, 5 December 2007 (UTC)
- They should generally not be linked, but as the guidelines suggest, there might be cases where linking can deepen a reader's understanding. Linking December 2 and 1981 in Britney's article is correct, so that the date can be formatted to suit readers' preferences, not that following either link will deepen understanding. Tony staunchly opposes utilizing this autoformatting, but his opinion is not consensus, as much as we appreciate many of his other contributions. I recommend following the guideline. This guideline could have its own examples corrected where the year alone is linked, as in Genghis Khan, where 1162 should not be linked. Chris the speller (talk) 16:12, 5 December 2007 (UTC)
- I have a script that unlinks all date fragments (solitary years, solitary months etc). It leaves full dates linked in accordance with guidance (although I share Tony's dislike of linking them too). It is easy to use. Feel free to use it directly or take pieces of code from it. Ask at my talk page if you want to know more. Lightmouse (talk) 20:15, 5 December 2007 (UTC)
Proposal to merge this page with MOS
It was only a matter of time since most of MOSNUM was pasted into MOS central that the question of what to do with this submanual should come up. The disadvantage in keeping both separate, or in removing what are, IMO, sections that are too important not to be at MOS, is that regular housecleaning is required to harmonise the duplicated sections; and that valuable discussions here are isolated from the broader MOS community.
There are four options, as far as I can see.
- Delete this page wholly, moving the remaining sections that are not duplicated to MOS. This is the quick and dirty way, except that some of the unduplicated sections might be regarded as too abstruse or, indeed, unstable, for inclusion in MOS.
- Delete this page wholly and create in its place three new submanuals: Magnitude prefixes, Geographical coordinates, and a merger of Old_Style_and_New_Style_dates and MOSNUM's "Calendars" section, with links at MOS to these submanuals. The autoformatting and links section belongs in the newly reorganised Links section at MOS.
- Keep this page and remove the duplication from MOS.
- Keep the status quo.
Comments? Tony (talk) 03:37, 4 December 2007 (UTC)
- You forgot
- 3. Keep this page and remove the duplication from the main page.
- Gene Nygaard 05:02, 4 December 2007 (UTC)
- Note: Proposal was updated to reflect this. — SMcCandlish [talk] [cont] ‹(-¿-)› 19:30, 4 December 2007 (UTC)
- As an editor I like this page the way it is (I do not see myself taking an active interest in MOS - it's too broad for me). On the other hand, I can see the advantage to the *reader* in incorporating the MOSNUM text in the main manual, but maintaining a faithful duplicate in MOS sounds like a thankless task. I suggest the following compromise:
- Keep this page as a master MOSNUM
- Paste its contents at periodic intervals into MOS, discarding any interim edits that may have taken place in the relevant sub-section, which I will call NUM@MOS
- Insert a warning in NUM@MOS to discourage edits made directly there, explaining that the master is held at MOSNUM
- Thunderbird2 18:15, 4 December 2007 (UTC)
- I like Thunderbird2's idea. —MJCdetroit 18:59, 4 December 2007 (UTC)
- Just for the record, the maint.-free way to do that would be with a transclusion. — SMcCandlish [talk] [cont] ‹(-¿-)› 20:15, 5 December 2007 (UTC)
- 3a. Remove the bulk of the duplicated material at MOS, and just summarize the key, most common issues there, and prominently direct people to MOSNUM for more detail. I agree with Tony1 that the MOSNUM content at MOS is just too much, and too hard to maintain in synch with the real MOSNUM (and add a further point that we have generally been treating MOS as trumping its subguidelines, which can present problems when MOSNUM does something smart and MOS isn't updated to go along with it), but I also agree with Thunderbird2 that we need to keep general editors in mind, not just editors of the MOS pages; MOS should cover the basics in sufficient detail to be useful to the average editor of a page about a video game, rock band or feline species. — SMcCandlish [talk] [cont] ‹(-¿-)› 19:22, 4 December 2007 (UTC)
- That’s exactly what should have happened (and I tried in an overly bold way) when MOSNUM content was partly reincorporated into MOS few months ago: only key rules (shoulds, we don’t have musts) without exceptions (mays) and overly specific details. I fear this is not (though hope it is) feasible, because even if we cut it down now, there’ll be people who consider their pet exception to be too important not to be on the main MOS, and so the excerpt will grow back again into an inconsistent twin. Christoph Päper (talk) 22:49, 4 December 2007 (UTC)
- I would prefer it if there were no duplication. Each guideline would only exist in one place. I would be prepared to accept larger pages if we could reduce the number of pages and duplicated content.
- My second preference would be for no double editing. Each guideline would only be editable in one place and read-only in any other place. I do not know if we have the technology to support this but I have seen something like it with a template.
- We could review duplication and large content across the whole of the manual and submanuals. For example, links are addressed in at least two important places.
- If a piece of guidance does not address a significant problem, if it will not have an effect on the editors that cause the problem, or if it would have been eventually solved by the wiki, then it is not adding value. Lightmouse 20:41, 4 December 2007 (UTC)
- I agree that the duplication is undesirable. However, the reason that much of MOSNUM was duplicated in MOS is that its content is so important for general editors. Having information on dates and numbers sequestered over here discourages people from consulting it, and separates expert discussions from the mainstream at MOS talk. I see no problem in making MOS very large—larger than it already is. The normal considerations of size for articles are to do with the readability of a topic. The purpose of MOS is not as an entire read-through document, but as a resource for specific consultation via the ToC. Summarising MOSNUM at MOS will further discourage editors from coming here ("I've looked at numbers in MOS, so that's clearly the important stuff—I don't need to treck to MOSNUM before nominating my FAC"—no, the devil is in the detail for our topic). To provide mere links to MOSNUM downgrades the importance of our topic for those who go to MOS: that is inescapable. Tony (talk) 00:41, 5 December 2007 (UTC)
- Well, we can't just throw up our hands about this. MOSNUM needs to have its most important points summarized in MOS, while having MOS make it very clear, in each place, that people needs to see MOSNUM for the devilish details. — SMcCandlish [talk] [cont] ‹(-¿-)› 08:18, 5 December 2007 (UTC)
- MOSNUM needs to stay since there are many specific details relating to this topic that would bloat MOS if moved there. Fnagaton 12:03, 5 December 2007 (UTC)
- I like SMcCandlish's proposal better than my own. Thunderbird2 (talk) 13:54, 5 December 2007 (UTC)
- Yes I agree. I think that just looking at the edit history for MOSNUM and the talk page shows this isn't a sleepy backwater but is instead a vibrant very much alive section. Fnagaton 16:38, 5 December 2007 (UTC)
- I too like SMcCandlish's thinking on this matter. —MJCdetroit (talk) 17:14, 5 December 2007 (UTC)
- I am a dyed-in-the-wool centralist. That is, I am one who prefers to see guidelines collected in one place, so that they can be maintained efficiently and kept free of inconsistencies, and so that editors can find the guidance they're looking for without a time-wasting chase that may still end in uncertainty. So of course I support moves like Tony's to diminish the role of MOS's "satellites". I support merging some of them into MOS; but reluctantly I accept that this can't be achieved for all of them.
- I therefore agree with SMcCandlish, too. In this case, and perhaps a few others, the satellites need to be brought into a closer orbit around MOS; MOS should summarise recommendations crisply, and where necessary and refer editors to the detail at the relevant satellite. We must then work to coordinate and rationalise discussion at the various talk pages that are involved. This will be much easier if they are few, and if all of them are known about by all editors involved in developing MOS guidelines. This is certainly not how things are right now.
- – Noetica♬♩ Talk 03:42, 10 December 2007 (UTC)
- I too like SMcCandlish's thinking on this matter. —MJCdetroit (talk) 17:14, 5 December 2007 (UTC)
- Yes I agree. I think that just looking at the edit history for MOSNUM and the talk page shows this isn't a sleepy backwater but is instead a vibrant very much alive section. Fnagaton 16:38, 5 December 2007 (UTC)
Linking full dates
There has been a conflict at Talk:Swedish language over the linking of retrieval dates of web references specified in footnotes and has lead to rather pointless low-intensity revert war. The problem in my view is that linking any date that happens to appear in an article, whether it's relevant to the topic or not, isn't helpful to readers. The arguments for linking all dates have thus far concentrated on the wording of the various guidelines and the fact that it has to do with formatting, not linking per se. Personally, I think the general wording of the guidelines (and the fact that they're guidelines, not policy) is enough to allow obvious exceptions, but apparantly some users feel that this might actually require changing the guidelines.
Peter Isotalo 13:01, 7 December 2007 (UTC)
- I'm not exactly sure what point you are trying to make here but my understanding of your position as expressed at Talk:Swedish language is that you are opposed to date wikilinking, EXCEPT where the date has direct relevance to the article in question. That seems like a reasonable principle to me. As I said at SL Talk, when I first came to wiki it took me quite a while to realize the date wikilinks had no relationship to the article, it was pretty annoying, and I think it's bad practice. Date wikilinking for the handful of people who want to use date preferences does not seem to me to be a valid reason to sprinkle every article in wikipedia with useless and irrelevant links.
- BTW Peter I think you'd be better off opening this discussion at Village Pump Policy, as I've found these individual policy pages in general get very little traffic. Gatoclass (talk) 13:12, 7 December 2007 (UTC)
- I have a script that unlinks all date fragments (solitary years, solitary months etc). I think full dates should not be linked either but the script leaves full dates linked in accordance with guidance. It is easy to use. Feel free to use it directly or take pieces of code from it. Ask at my talk page if you want to know more. Lightmouse (talk) 13:56, 7 December 2007 (UTC)
- I think linking full dates so that they auto-format is important. I like having all dates converted to my preferred format, and good God, I don't want to imagine the edit wars between the DD-MM-YYYY and the MM-DD-YYYY camps, not to mention the ISO 8601 YYYY-MM-DD guys, if we stop auto-formatting. TomTheHand (talk) 14:58, 7 December 2007 (UTC)
- While it is unquestionable that auto-formatting provides some benefit, the manner in which is implemented incurs some disadvantages. The vast majority of readers won't see any benefit and can (as have been noted) be confused by the seemingly irrelevant links. As for edit wars, I suspect they could be handled in a similar manner to variations in spelling. Consistency within an article and standardization of the format should be done in any case, since so few users (I suspect no more than a few thousands) will see the dates autoformatted. henrik•talk 15:25, 7 December 2007 (UTC)
- I agree with those that think it is time for a change. The concept of autoformatting is fine but the design and implementation has created a cure that is worse than the disease. Furthermore, those of us that do not have the disease have to take the cure and accept the nasty side-effects.
- Confused editors make many errors (e.g. [[5 November|November 5]]). Some errors make articles unreadable for those that use autoformatting e.g. by creating the format: '15 November-18'. We should abandon this design. In the short term, we need a bot that is fast and comprehensive enough to find and fix the many errors. Lightmouse (talk) 15:44, 7 December 2007 (UTC)
- I doubt that I'm the only editor who frequently goes between languages and countries, where different date formats are used in the different sources I read, so yes, date formatting to allow for user preferences is essential for clarity. SandyGeorgia (Talk) 06:26, 10 December 2007 (UTC)
I disagree that anything needs to be changed until the autoformatting can be implemented without the wikilinks. Confused editors make many errors, and changing guidelines will not help that, nor will confusion or other side effects (whatever they are) be lessened; there will be only a loss of the benefit provided by auto-formatting. (See also WP:OVERLINK#Dates.) -- JHunterJ (talk) 18:38, 7 December 2007 (UTC)
- Either most of the responders here have missed the point of the original post, or maybe I have. It seems to be asking about linking full dates in footnotes, especially those that specify retrieval dates. Although I favor autoformatting of dates in the running text in the body of an article, I am not convinced it's needed in the footnotes. As long as those dates are in a consistent fixed format within that article, I'm happy. People who are analyzing the references will probably not be impeded much by dates that are not autoformatted to their liking. And I don't think the original post here was trying to instigate an uprising against autoformatting in general, so calm down, please. Chris the speller (talk) 18:58, 7 December 2007 (UTC)
- I don't see any disadvantage to autoformatting dates in footnotes (at least, no disadvantages that are footnote-specific). I don't know why footnotes would be an exception. TomTheHand (talk) 22:00, 7 December 2007 (UTC)
- Since Wiki automatically links *most* dates in citation templates, consistent display of dates according to user preferences for all readers requires that those not in cite templates be linked, or you end up with a gibberish of dates in differing formats, which makes a difference when you're reading an article about a country that uses one format with source that use another. SandyGeorgia (Talk) 06:26, 10 December 2007 (UTC)
- Chris, your summary reflects the issues presented in the discussion at Talk:Swedish language, but it does not reflect the way Peter framed the issue when he opened this thread. He did, in fact, raise the more general point here of whether dates should be linked: The problem in my view is that linking any date that happens to appear in an article, whether it's relevant to the topic or not, isn't helpful to readers. I would agree with that assessment if we had an autoformatting mechanism that worked without wikilinking the dates, but we don't. Hell, I would also favor picking a default format and applying it to wikilinked dates when unregistered users are viewing an article. It would be a monumental headache to enforce consistency in date formats without any autoformatting mechanism at all, so I certainly don't see that as a solution, because I do value consistent formatting (not just for dates). --Tkynerd (talk) 23:58, 7 December 2007 (UTC)
- Some months ago, I decided to encourage WPians not to use the autoformatting function, because it is dysfunctional in several key ways. The arguments appear in the archives of this talk page and elsewhere. A move signed by 85 WPians to ask Bugzilla to FIX the biggest problem—the entanglement with the linking functionality—has thus far failed; this is more reason to discourage its use and put up with the several major formattings for dates, just as we do the varieties of spelling. Tony (talk) 00:29, 8 December 2007 (UTC)
- Boycotting the function makes sense for those reasons, but when some dates are formatted, all dates should be formatted for consistency according to user preferences. SandyGeorgia (Talk) 06:26, 10 December 2007 (UTC)
- Boycotting the autoformat feature in order to convince the devs to fix it sounds awfully POINTy to me. TomTheHand (talk) 01:14, 8 December 2007 (UTC)
- Agree with TomTheHand; in addition, I'd like to know more about this move to get developers to fix this, but I don't think their decision (if it's actually a decision rather than just prioritizing other development needs) is a good reason to ignore the guidelines. --Tkynerd (talk) 01:35, 8 December 2007 (UTC)
- No, you're wrong: I'm not trying to make a point in discouraging people from using the dysfunctional system. I'm discouraging people from using a dysfunctional system. MOSNUM says that it is "normally" used. Well, sorry, it's not normal to persist with such a dysfunctional system. End of story. Tony (talk) 04:20, 8 December 2007 (UTC) PS Here are the links to the Bugzilla thing: [10] and [11]. Here is the petition: Wikipedia_talk:Manual_of_Style_(dates_and_numbers)/Archive_D1#A_new_parallel_syntax_for_autoformatting_dates. Tony (talk) 04:29, 8 December 2007 (UTC)
- You are missing the import of the word "normally" in that guideline. It obviously does not mean that using wikilinking to autoformat dates is a "normal" method of doing so, or that it is ideal or functional; it means that full dates should normally be entered by editors in such a way that the MediaWiki software will autoformat them. If the developers change the method by which this is done in the MediaWiki software, the last half of the sentence (which explains the method) will need to change, but the first portion (which includes the word "normally") will not, even if the developers choose to implement date autoformatting that requires editors to precede each date with a random number that will change every day. The point is simply this: full dates are normally autoformatted. Your argument is pharisaical at best. --Tkynerd (talk) 05:14, 8 December 2007 (UTC)
- No, you're wrong: I'm not trying to make a point in discouraging people from using the dysfunctional system. I'm discouraging people from using a dysfunctional system. MOSNUM says that it is "normally" used. Well, sorry, it's not normal to persist with such a dysfunctional system. End of story. Tony (talk) 04:20, 8 December 2007 (UTC) PS Here are the links to the Bugzilla thing: [10] and [11]. Here is the petition: Wikipedia_talk:Manual_of_Style_(dates_and_numbers)/Archive_D1#A_new_parallel_syntax_for_autoformatting_dates. Tony (talk) 04:29, 8 December 2007 (UTC)
- As long as MOS continues to recommend the wikilinking of full dates for user preferences date formatting purposes, this should be done across-the-board, including in reference citations, otherwise it is inconsistent and undermines the concept of date formatting. That is happens to be in a ref citation instead of an infobox or a prose paragraph is irrelevant. — SMcCandlish [talk] [cont] ‹(-¿-)› 06:09, 8 December 2007 (UTC)
- I am with Tony on this. Editors keep adding errors that break autoformatting (e.g. piped year links in full dates, date ranges that become '5 November-6', [[5 November|November 5]], '5th November'). If there was any real enthusiasm for autoformatting, then high speed bots would fix these errors faster than editors make them. I don't believe people actually care much about whether autoformatting breaks, it merely exists as an answer to anyone that complains about dates just as we have an answer to the 'color/colour' conflict. Lightmouse (talk) 10:59, 8 December 2007 (UTC)
- [editconflict] I think we're talking past each other, T. I agree that the autoformatting system sucks, because it operator overloads the wikilinking system to serve an unrelated purpose, with very undesirable results [plus the easy-to-make errors Lightmouse highlights, no pun intended]. Last I looked, MOS (or MOSNUM, rather) advised, or was at least neutral on the idea, that complete dates should be wikilinked for autoformatting. My point above is that we are not making some special exception that reads "except in reference citations". MOS[NUM] does not say that, and until this was posted here I was unaware of anyone making up that non-existent distinction. As with everything else MOSly, "be consistent within an article". If editors at an article have agreed by widespread consensus on its talk page that date autoformatting is hosed, and the article in question should not and does not use it in the article's main prose, then good for them, and don't add that formatting to ref. citations. If, as is much more probable, an article does wikilink full dates, then do so in ref citations too, and if it wikilinks partial dates, remove those links, where ever they are, since they serve no purpose at all. Hope that makes more sense. SMcCandlish (talk) 10:59, 8 December 2007 (UTC)
- I also have always agreed that we should have a better system as Tony proposes, but until we do, dates need to be displayed consistently according to user preferences, which means they need to be linked consistently, including in footnotes. SandyGeorgia (Talk) 06:26, 10 December 2007 (UTC)
- [editconflict] I think we're talking past each other, T. I agree that the autoformatting system sucks, because it operator overloads the wikilinking system to serve an unrelated purpose, with very undesirable results [plus the easy-to-make errors Lightmouse highlights, no pun intended]. Last I looked, MOS (or MOSNUM, rather) advised, or was at least neutral on the idea, that complete dates should be wikilinked for autoformatting. My point above is that we are not making some special exception that reads "except in reference citations". MOS[NUM] does not say that, and until this was posted here I was unaware of anyone making up that non-existent distinction. As with everything else MOSly, "be consistent within an article". If editors at an article have agreed by widespread consensus on its talk page that date autoformatting is hosed, and the article in question should not and does not use it in the article's main prose, then good for them, and don't add that formatting to ref. citations. If, as is much more probable, an article does wikilink full dates, then do so in ref citations too, and if it wikilinks partial dates, remove those links, where ever they are, since they serve no purpose at all. Hope that makes more sense. SMcCandlish (talk) 10:59, 8 December 2007 (UTC)
- I'm thinking along the same lines. While I would prefer if full dates were linked only when they were relevant (which in the case of web reference retrieval dates would mean never), I'm not going to go around campaigning in random articles by reverting the main authors on their choice of style. But this is exactly what happened in Swedish language, and used up far more talkpage space than it was ever worth.
- Peter Isotalo 11:40, 8 December 2007 (UTC)
- Please see WP:OWN. There is no author who has special privileges to decide how an article looks. Lurker (said · done) 15:56, 8 December 2007 (UTC)
- There is however a custom of respecting the initial author's wishes when it comes to certain things with multiple right answers and some stylistic matters, for example things such as spelling variations and measurement systems. henrik•talk 16:26, 8 December 2007 (UTC)
- In the Swedish language article, no one has argued over the stylistic matters that you've mentioned, such as spelling variations and measurement systems. But since you brought it up, the primary author, User:Peter Isotalo, has been inconsistent with which variant of English he uses (AmE spelling vs AmE & BrE dates). –panda (talk) 18:51, 8 December 2007 (UTC)
- There is however a custom of respecting the initial author's wishes when it comes to certain things with multiple right answers and some stylistic matters, for example things such as spelling variations and measurement systems. henrik•talk 16:26, 8 December 2007 (UTC)
- Please see WP:OWN. There is no author who has special privileges to decide how an article looks. Lurker (said · done) 15:56, 8 December 2007 (UTC)
I think the policy should be changed so that dates that have the months spelled out are not wikilinked - because, after all, such dates can never cause confusion. I refer to date formats such as 5 July 1989 or August 9 2004. The ONLY dates that should be wikilinked are the ones in formats that can become confusing such as 05-07-1989 or 2004/08/09. Gatoclass (talk) 15:31, 8 December 2007 (UTC)
- Doing that would result in a mish-mash in the article and in the footnotes. Currently, dates are displayed according to user preferences no matter how they were entered by the original editor. If you link some and not others, you end up with gibberish. SandyGeorgia (Talk) 06:26, 10 December 2007 (UTC)
- There should be no dates with the months spelled out because this means that users cannot choose how these dates are displayed. Using date linking, users can choose whether they see months as numbers or spelled out. We are supposed to be here for the readers, not to impose our own views on how dates should be displayed. Lurker (said · done) 15:56, 8 December 2007 (UTC)
- Exactly, we're here for the readers, which is in my view the strongest argument to remove the date links as excessive linking disrupts the flow of reading. Practically no readers will see anything but what the editor put in the article. As the 8th most popular website in the world, maybe a hundred million people view wikipedia articles every day. There are 5 million accounts, and if 1% has set the date preferences, that's 50 000 people. Assuming 1 in 1000 readers find the links confusing or irritating, that's still twice as many people every day as those who will benefit from the date preferences. henrik•talk 16:26, 8 December 2007 (UTC)
- That is a whole lot of highly speculative reasoning there. Just as with varieties of English, there have been considerable tedious tendentious edits to make dates display "correctly" as judged by the editor. Date preferences short-circuit such pointless disputes. Granted, perhaps there could be a better mechanism for implementing date preferences that did not involve linking, but until such a replacement is available, I don't see any reason to change the current practice. older ≠ wiser 16:58, 8 December 2007 (UTC)
- I don't think it's highly speculative at all, I think that assuming only 1% of casual users find the date links annoying would be a considerable underestimate. I would guess a majority of casual users would find date wikilinking annoying, because they are not privy to the esoteric function behind it. Most people will quite justifiably assume that if there's a link on the page it's because the link goes somewhere useful and relevant, and are bound to be irritated to find it doesn't. By contrast, the number of people who actually know about date preferences, let alone make use of it, must be miniscule by comparison. Gatoclass (talk) 19:15, 8 December 2007 (UTC)
- Well, the figures I used are indeed pure speculation. I could very well be off by an order of magnitude in either direction. But I simply tried to illustrate the point that we have many more readers than editors with date preferences set. henrik•talk 19:20, 8 December 2007 (UTC)
- From the point of view of the casual reader unless a survey is done we will not know if linking dates is annoying. But what we can guarantee is that dates in the form of DD MM YYYY and MM DD YYYY will be misunderstood by a lot of people. What is worse if they have read one article general article with which they have some knowledge that uses MM DD YYYY and contains a date they know and then follow a link to another page, for example a biography of a person mentioned in a general article, and if that uses the other numerical format then they are almost bound to get it wrong. At least with DD MONTH YYY or MONTH DD, YYYY, linked or not they may find one format jarring to look at, but they will not get the date wrong. With spelling one can tell (or assume that those dumb Wikipedia authors don't know how to spell), but with numeric dates readers have no way of knowing at a glance what format the date is in and this can easily be misleading, particularly those who have not had much exposure to English written by those who write in a different English dialect. --Philip Baird Shearer (talk) 07:24, 10 December 2007 (UTC)
- Well, the figures I used are indeed pure speculation. I could very well be off by an order of magnitude in either direction. But I simply tried to illustrate the point that we have many more readers than editors with date preferences set. henrik•talk 19:20, 8 December 2007 (UTC)
- I don't think it's highly speculative at all, I think that assuming only 1% of casual users find the date links annoying would be a considerable underestimate. I would guess a majority of casual users would find date wikilinking annoying, because they are not privy to the esoteric function behind it. Most people will quite justifiably assume that if there's a link on the page it's because the link goes somewhere useful and relevant, and are bound to be irritated to find it doesn't. By contrast, the number of people who actually know about date preferences, let alone make use of it, must be miniscule by comparison. Gatoclass (talk) 19:15, 8 December 2007 (UTC)
- How does linking dates in the notes/references disrupt the flow of reading? They're not included in the normal flow of text that someone would read. –panda (talk) 18:51, 8 December 2007 (UTC)
- In notes/references sections, it creates a huge, ugly blue mess. Tony (talk) 23:13, 8 December 2007 (UTC)
- In notes/references, unlinked dates create an ugly mess of different date formats entered by different editors. You end up with something like:
- Article name, BBC, 2006-01-10. Retrieved on September 5, 2007.
- Article name, BBC, March 5, 2005. Accessed 2006-05-04.
- And, is that October 1 or January 10? SandyGeorgia (Talk) 06:26, 10 December 2007 (UTC)
- In notes/references, unlinked dates create an ugly mess of different date formats entered by different editors. You end up with something like:
- In notes/references sections, it creates a huge, ugly blue mess. Tony (talk) 23:13, 8 December 2007 (UTC)
- That is a whole lot of highly speculative reasoning there. Just as with varieties of English, there have been considerable tedious tendentious edits to make dates display "correctly" as judged by the editor. Date preferences short-circuit such pointless disputes. Granted, perhaps there could be a better mechanism for implementing date preferences that did not involve linking, but until such a replacement is available, I don't see any reason to change the current practice. older ≠ wiser 16:58, 8 December 2007 (UTC)
- Exactly, we're here for the readers, which is in my view the strongest argument to remove the date links as excessive linking disrupts the flow of reading. Practically no readers will see anything but what the editor put in the article. As the 8th most popular website in the world, maybe a hundred million people view wikipedia articles every day. There are 5 million accounts, and if 1% has set the date preferences, that's 50 000 people. Assuming 1 in 1000 readers find the links confusing or irritating, that's still twice as many people every day as those who will benefit from the date preferences. henrik•talk 16:26, 8 December 2007 (UTC)
Here is the bug in which implementing date syntax independent of linking is discussed: [12]. -- PatLeahy (talk) 17:53, 8 December 2007 (UTC)
- For those who treated me as though I had 3 heads for reading the original question as pertaining to dates in references/footnotes, take note of these: 1) The {{Cite web}} template recommends this format: "cite web |url= |title= |accessdate=2007-12-09 |format= |work= ", and this date format does not conform to this guideline. 2) The edit war on the Swedish language article switches between British-style dates (but not linked, as the guidelines call for) and ISO-style dates, which do not conform to this guideline. These 2 editors, after completely ignoring this guideline, come to this talk page for resolution. Here it is: follow the guideline, using wikilinked British-style or American-style dates. Chris the speller (talk) 01:08, 9 December 2007 (UTC)
- Not following, Chris the speller; the cite web template automatically links the accessdate parameter; it does follow this guideline. The full date is automatically linked so user preferences work. It doesn't automatically link the date parameter unless a full date is entered, because the date is not always a full date (could be only a year or a month-year combo). SandyGeorgia (Talk) 07:37, 10 December 2007 (UTC)
- I agree with the spirit of what you've written; I just want to point out that even ISO-style dates are formatted correctly (for registered users) if they are wikilinked. That obviously doesn't solve the problem of formatting for unregistered users, though. --Tkynerd (talk) 02:10, 9 December 2007 (UTC)
- Yes, ISO-style dates do autoformat correctly, but the guideline discourages them, except that they "may be useful in long lists ...", so is a collection of footnotes a list? Apparently the people who maintain the Cite web template think so, but McCandlish feels that dates in footnotes should get the same handling as dates in the running text of the body. I don't think the ISO dates give any advantage, since the elements of the footnotes don't fall into vertical alignment anyway. What I do know is that if the guideline had been followed for all dates in the Swedish article (all as linked British-style dates), there would have been no edit war. Chris the speller (talk) 04:30, 9 December 2007 (UTC)
- Chris, no one has said a single word about any inconsistency between spelling and date standards over at Talk:Swedish language. The arguments have consistently been to link or not to link full dates, including the retrieval dates of web refs. If you think applying American-style dates (without the linkage) would solve the issue, you're welcome to try your hand at it.
- Peter Isotalo 03:56, 10 December 2007 (UTC)
- Peter, what are you talking about? I never mentioned spelling. Perhaps you took my user name too literally. And I didn't mention the discussion that's on that talk page. I mentioned the edit warring, in which I saw Lurker (2 days ago) changing from unlinked British-style dates to linked ISO-style dates. And I don't "think applying American-style dates (without the linkage) would solve the issue". I know that using linked British-style dates (or, if you prefer, American) would solve it. But no, I'm not going to join in the edit war. In one of your edit summaries, you mentioned that there is no consensus on that article to switch formats. If there is no consensus by the editors of an article to depart from the guideline, then there's no reason not to follow the guideline. Chris the speller (talk) 16:45, 10 December 2007 (UTC)
- Actually, consistent formatting of dates was brought up on 27 November 2007 [13] and 28 November 2007 [14] [15] in Talk:Swedish language. –panda (talk) 05:55, 10 December 2007 (UTC)
- Dates should be consistently formatted in the article and in the footnotes so that user preferences work on display. SandyGeorgia (Talk) 06:26, 10 December 2007 (UTC)
- panda, there was not a peep in there about mixing American spelling and British date formatting, but rather the insistance that this should be achieved with wikilinking. No one ever opposed consistent date formats in the article.
- Peter Isotalo 10:50, 10 December 2007 (UTC)
- Actually, consistent formatting of dates was brought up on 27 November 2007 [13] and 28 November 2007 [14] [15] in Talk:Swedish language. –panda (talk) 05:55, 10 December 2007 (UTC)
I just looked at Swedish language, and saw only one problem in the footnotes, here:
- Aronsson, Cecilia Norrländska låter bäst (Swedish) Dagens Industri 2005-05-03. Retrieved on August 24, 2007.
That's ugly; is that all this is about? And is that May 3 or March 5? The external jumps in the text (see WP:EL) are gone, too, so it looks like some progress is being made. SandyGeorgia (Talk) 07:46, 10 December 2007 (UTC)
- Oops, I see I was wrong on the External jumps, and they're still there, making the article look like a blog or a collection of links (see WP:NOT, WP:EL). SandyGeorgia (Talk) 19:37, 10 December 2007 (UTC)
- Yes, I reverted that change because I saw absolutely no point in simply adding an additional click for anyone who wanted to check out those links. They're not sources, but caveats that are clearly explained in the preceding paragraph. Did you even read that paragraph? Did you follow the links? I would really appreciate if you tried not to apply the MoS so darned rigidly all the time. And I find your likening the article to a blog because of a few external links to be pretty darned condescending. Peter Isotalo 09:16, 11 December 2007 (UTC)
- Oops, I see I was wrong on the External jumps, and they're still there, making the article look like a blog or a collection of links (see WP:NOT, WP:EL). SandyGeorgia (Talk) 19:37, 10 December 2007 (UTC)
- Sandy, just like using one variety of spelling consistently within an article, I don't see what is so hard about formatting dates consistently within an article, and dispensing with this ugly, problematic linking entanglement. Don't forget that 99% of readers have to put up with all of the disadvantages of the inflexible bright-blue splotches with no benefit. In fact, they're quite likely to see inconsistent formatting in an article, since when the self-chosen few who set their preference edit articles, they don't care what format they add, forgetting that most readers won't see the autoformatting. Tony (talk) 10:01, 10 December 2007 (UTC)
- Sandy, with all due respect to your efforts to uphold consistency, none of the problems you bring up here have to be solved with wikilinking. It might come as a shock to those favoring this particular solution, but it is actually possible to format dates consistently in the same way you achieve spelling consistency: you simply edit the text like any normal prose without having to resort to template dinkiness and other technocratic methods. As hinted by Tony, Swedish language is now currently displaying the wikilinked ISO-style dates as YYYY-MM-DD to the overwhelming majority of our readers (who logged in). Peter Isotalo 10:50, 10 December 2007 (UTC)
Full dates need to be linked so that readers' preferences will work. Obviously it would be better if another way of correctly doing this could be found, but, until then, what's to argue about? --John (talk) 19:41, 10 December 2007 (UTC)
- Unless I'm completely misreading this, I think that the point is that we are not in a position to necessarily accept what the developers provide if it does not suit what our needs are, and that we can in effect reject a developer-provided solution by deprecating its usage. That said, I think it would be major faux pas to pursue this issue very far along those lines. A certain amount of rebellion gets the point across, while an excessive amount will make us look like shitheads. We need to get the "this just really does NOT work" point across in a way that is not antagonistic to developers who have really worked hard to implement what was in fact asked of them. The WP community, not the coders, is at fault on this one. We collectively asked for a simple but in retrospect rather boneheaded fix. If we are now asking for a better one, some contrition is in order on our part. I.e. Please fix this, like thus, because we didn't ask for the right solution the first time. The MW developers didn't screw this up; we did. — SMcCandlish [talk] [cont] ‹(-¿-)› 09:10, 11 December 2007 (UTC)
- Well, I certainly didn't screw it up, and probably most or all of the developers weren't there at the time this folly was perpetrated. I'm just irritated by the response until recently by Brion Vibber, the developer who seems to have been presiding over the issue (Bug 4582). His original rejoinder was:
[Coupling the linking and autoformatting syntaxes] was done in part to encourage linking of dates so they can be used as useful metadata.(1 December 2006)
- Um ... right. Perhaps Brion is taking the issue more seriously now. His latest post is more encouraging:
My personal recommendation would be to remove all date
autoformatting and let a sane manual of style recommend the fairly standard international English form, eg '4 December 2008'. Of course that's too simple
and obvious for Wikipedia. ;) (4 December 2007)
Tony (talk) 10:29, 11 December 2007 (UTC)
- Another reason to support user preference/autoformatting of dates is WP:CSB. Having an MOS "consensus" decide on one format (be it American, non-American, ISO 8601, or maybe even NATO DTG) would result in some sort of systemic bias and general WP:NPOV problem. Better to fix the user preferences technology than to waste it. Perhaps it's time to raise this at WP:VP/T, and escalate as necessary at other appropriate places. Dl2000 (talk) 03:04, 12 December 2007 (UTC)
- "Systemic bias"? "NPOV"?! We're talking dates, not Gdanzig! The habit of over-linking everything for the sake of a few thousand registered users that actually care about tinkering with their settings is an infinitely more pressing issue than whether a particular editor writes 4 December or December 4. No one of consequence outside of the community gives a damn what we use as long as we're not ambiguious and consistent within the same article.
- Peter Isotalo 10:48, 12 December 2007 (UTC)
All dates should be auto-formatted by the software
The absolute best way to do this would be to have the software do the formatting for us, with no wiki tags or busywork.
Autoformat anything that's unambiguously a date ("4 December 2008", "2008-12-04", but not things like "1/2/3"), and then use nowiki tags for the few exceptions, the same way RFC 1234 and ISBN 1029384758 are auto-linked, but can be overridden for the rare exceptions (RFC 1234). — Omegatron 01:44, 12 December 2007 (UTC)
- Well, certainly not with the current rubbishy output. No way. Tony (talk) 01:58, 12 December 2007 (UTC)
- Yep, that's exactly what we've been getting at. The problem is that the developers don't seem to want to go there, believing they've already provided us with a perfect solution. It will take an active (if gradual) rejection of the provided solution before we get a better one, or we'd already have a better one, because this is hardly a new issue. I think that if MOS begins be making the links optional, and insists on using (in real code, not wiki-autoformatted results) consistent formatting within an article and per WP:ENGVAR, we can later slightly deprecate the autoformatting, then completely deprecate it - let consensus change over time - and then finally get the developers to it right the second time. I doubt they will do it before we've gone through at least most of that process. — SMcCandlish [talk] [cont] ‹(-¿-)› 02:20, 15 December 2007 (UTC)
- The problem is not that the devs are jerks, it's that when this was previously brought to their attention it was done in an unclear and eventually fairly rude way. Given that this is not a matter of core functionality, and that it was not clearly expressed why this bothered people, they were justified in judging this as a minor bug report. They asked if anyone that disliked the status quo was willing to contribute code; no one stepped up. When one of the devs did play with the date formatter and asked for feedback, he didn't get it. Rather than attempting to bludgeon date formatting to death from MOS and creating a big(ger) ungodly mess, it would probably be a good idea to bring this back to the devs with a clearer explanation and perhaps even some prototype code. That would mean hammering out a single course of action first, though. — Aluvus t/c 03:01, 15 December 2007 (UTC)
- The problem was clearly explained to the devs at bugzilla:4582, and they declined to make changes to the software because of the additional mess that would create. Brion, the lead developer, recommended:
- My personal recommendation would be to remove all date autoformatting and let a sane manual of style recommend the fairly standard international English form, eg '4 December 2008'. Of course that's too simple and obvious for Wikipedia. ;)
- The idea (backed by brion) is to put all dates into either "25 December 2007" format for "December 25, 2007" format, with a consistent format used throughout an article. Once that is done, date wikilinking will no longer be necessary because the dates will be consistent and unambigous. I already wrote a script that will do most of the transition, but we need consensus to use it. —Remember the dot (talk) 03:10, 15 December 2007 (UTC)
- Brion Vibber's suggestion was to use one date format (specifically, the "British" format) for the entire project. You may observe on this page what a large fight there is over which is the One True Format. And no, the discussion on the Bugzilla page is anything but clear; it is pulled in several directions at once, with different people putting forward contradictory suggestions. I read that already familiar with what people disliked about the current system, and still found it confusing. It is obvious from reading that page that some of the devs agreed, right from the start, that the current system was problematic; but there was no clear mandate from users to "please do X". That doesn't leave them with a clear way forward. — Aluvus t/c 04:16, 15 December 2007 (UTC)
- Right. There are too many conflicting opinions on what is the best way to technically implement user date preferences. By far the simplest way to do it is at least similar to Brion's suggestion: use either the British "25 December 2007" or the American "December 25, 2007", depending on what the subject of the article would use. There is no One True Format, but there are two equally clear and unambiguous formats. If we switch to using those formats almost exclusively, then it would remove the need for date wikilinking. —Remember the dot (talk) 04:25, 15 December 2007 (UTC)
- Using a single format is the easiest technical solution (other than doing nothing, which of course is the path of least resistance), but no one has yet explained how it would be the easiest social solution. That there was (and is) so much conflict about how to go about this speaks to the lack of meaningful discussion and consensus-building on this whole morass, not to the actual difficulty or complexity of the problem itself. If the original Bugzilla report had said "please make dates not show up as links", we would not be having this discussion now because people's primary complaint would have been resolved some time ago. But to screw up in reviving this on Bugzilla and then decide to throw out the whole system because fixing it is "too hard" is irrational. — Aluvus t/c 07:07, 15 December 2007 (UTC)
- Agree, this does not provide an easy social solution. I personally have no trouble with a British admiral's bio using 25 December 2007, or an American admiral's bio using December 25, 2007, even if autoformatting were not available, but what about Spanish admirals? Picture two Spanish admirals living in the same era, with one bio written by an American and one by a Briton, each using their natural date format. This would look bizarre to a reader comparing the two, unless autoformatting was used. This is another reason for slowing down the drive to kill autoformatting. —Preceding unsigned comment added by Chris the speller (talk • contribs) 18:31, 15 December 2007 (UTC)
- We already do just that when deciding whether to use British or American spelling, and it doesn't bother anyone. —Remember the dot (talk) 18:35, 15 December 2007 (UTC)
- Agree, this does not provide an easy social solution. I personally have no trouble with a British admiral's bio using 25 December 2007, or an American admiral's bio using December 25, 2007, even if autoformatting were not available, but what about Spanish admirals? Picture two Spanish admirals living in the same era, with one bio written by an American and one by a Briton, each using their natural date format. This would look bizarre to a reader comparing the two, unless autoformatting was used. This is another reason for slowing down the drive to kill autoformatting. —Preceding unsigned comment added by Chris the speller (talk • contribs) 18:31, 15 December 2007 (UTC)
- Using a single format is the easiest technical solution (other than doing nothing, which of course is the path of least resistance), but no one has yet explained how it would be the easiest social solution. That there was (and is) so much conflict about how to go about this speaks to the lack of meaningful discussion and consensus-building on this whole morass, not to the actual difficulty or complexity of the problem itself. If the original Bugzilla report had said "please make dates not show up as links", we would not be having this discussion now because people's primary complaint would have been resolved some time ago. But to screw up in reviving this on Bugzilla and then decide to throw out the whole system because fixing it is "too hard" is irrational. — Aluvus t/c 07:07, 15 December 2007 (UTC)
- Right. There are too many conflicting opinions on what is the best way to technically implement user date preferences. By far the simplest way to do it is at least similar to Brion's suggestion: use either the British "25 December 2007" or the American "December 25, 2007", depending on what the subject of the article would use. There is no One True Format, but there are two equally clear and unambiguous formats. If we switch to using those formats almost exclusively, then it would remove the need for date wikilinking. —Remember the dot (talk) 04:25, 15 December 2007 (UTC)
- Brion Vibber's suggestion was to use one date format (specifically, the "British" format) for the entire project. You may observe on this page what a large fight there is over which is the One True Format. And no, the discussion on the Bugzilla page is anything but clear; it is pulled in several directions at once, with different people putting forward contradictory suggestions. I read that already familiar with what people disliked about the current system, and still found it confusing. It is obvious from reading that page that some of the devs agreed, right from the start, that the current system was problematic; but there was no clear mandate from users to "please do X". That doesn't leave them with a clear way forward. — Aluvus t/c 04:16, 15 December 2007 (UTC)
- The problem was clearly explained to the devs at bugzilla:4582, and they declined to make changes to the software because of the additional mess that would create. Brion, the lead developer, recommended:
- I take this "to screw up in reviving this on Bugzilla" as extremely offensive. Have you bothered to read the representation that was made? It was kept as simple as possible, and in essence said EXACTLY what you claime it didn't. It asked for the date autoformatting and the linking systems to be decoupled. Go read it. How dare you frame all of my hard work, and that of others, and the will of the signatories, as a "screw up". Go screw yourself up.
- Now, the fact that such a simple, plain message has been ignored by the developers strongly indicates, as SMcCandlish has said, that we're not going to get a technical solution from them.
- Vibber's and others' suggestions that a single format be used throughout is not on. It would be like enforcing US or British English throughout. I'd leave. That is why allowing one format to evolve, consistently, in each article, just as for the variety of English, is, IMV, the only way to go. Tony (talk) 09:03, 15 December 2007 (UTC)
- I read the entire discussion several times, which is why I am now telling you why it went as it did. "Decouple the systems" and "don't render dates as links" are very, very different requests. As are "don't render as links when the link has a colon in it", "autoformat all unambiguous dates", "autoformat all dates outside the <blockquote> tag", not to mention "autoformat dates and also manipulate them based on the user's IP". None of these are inherently bad solutions (though the IP thing, while neat, is probably very impractical), but they are very contradictory. Repeatedly, I have seen blame placed on the developers for not caring, or not acting quickly enough, or what have you. But the truth is that they were handed a very ambiguous feature request, couldn't hash out what people really wanted (because the people asking didn't know what they wanted), and ultimately the whole process stalled. This has been presented to us here as proof that virtually any technical solution is infeasible, which is not the case.
- Furthermore, I would like to point out that your own emotional attachment to this issue is not helpful. The changes you are seeking to implement would impact the entire project (as well as all projects that use its content) in a substantial way, assuming people outside MOSNUM adhere to them. Such decisions should not be made on the basis that you are pissed at the developers. In your haste to kill a system that you personally don't like, you are pushing us toward a solution that has not been adequately explained or examined, and may be just as bad in the long term. — Aluvus t/c 22:51, 15 December 2007 (UTC)
A way forward
I have a suggestion that may help. Let's agree on a date format that is easy for everyone to understand, regardless of nationality, and start using that format exclusively without the confusing wikilinking. I suggest:
"December 25, 2007" or "25 December 2007" (either is fine) for dates that appear in prose, and
"25 Dec 2007" for dates that appear in footnotes.
Let's not muck around with "12-25-2007" versus "25-12-2007" versus "2007-12-25", or ask that editors add brackets for the extremely small number of users who are staunchly opposed to human-readable dates. Let's keep it fully human-readable and as simple as possible. I know that it will take time to transition articles to consistently use human-readable, non-wikilinked dates, but there's no rush, and in the end it will be worth it. —Remember the dot (talk) 19:03, 12 December 2007 (UTC)
- If you want to follow one standard, what would be more logical than follow the existing world standard ISO 8601, in the form of 2007-12-25. This is not ambiguous or confusing in any way and quite easily human readable. Furthermore it neither favo(u)rs the US or UK preference. −Woodstone (talk) 20:28, 12 December 2007 (UTC)
- Trust me, using the ISO standard can be potentially confusing. Not all countries conform to this standard and I've even heard that this issue has lead to all-out lawsuits between business partners in countries that use different standards when contracts have accidently been breeched. And why on earth would we have have to decide on one standard anyway? Both are completely unambiguous and even less linguistically "political" than "flavour" vs "flavor". Claiming that it actually matters to readers if we place the date before or after the month is pretty much setting up the battle over an issue that has absolutely no encyclopedic consequence.
- Peter Isotalo 20:50, 12 December 2007 (UTC)
- The logical thing to do is to pick the date format that is the easiest for the average reader to understand. "2007-12-25" is not as intuitive as "25 December 2007". That's not to say that "2007-12-25" is a not good date format for some applications (such as computing), but it's not the most human-friendly format. —Remember the dot (talk) 22:53, 12 December 2007 (UTC)
- I like that idea. I think we could initially change the guidelines to either allow an unlinked but clearly unambiguous format, such as the ones you proposed with the month spelled out, or wikilinked dates as they appear today. An article should of course use a consistent format throughout, but it would allow a non-linked format for those who find the links distracting. henrik•talk 22:56, 12 December 2007 (UTC)
Does anyone actually use YYYY-DD-MM? And what would that date system be called? I can imagine DD-MM-YYYY being confused with MM-DD-YYYY but I personally don't know anyone who uses YYYY-DD-MM, which could possibly be confused with YYYY-MM-DD. –panda (talk) 22:07, 12 December 2007 (UTC)
- The idea I suggested is to completely sidestep the issue by spelling out the name of the month, thus making it very clear which part of the date is the day, which part is the month, and which part is the year. I think that this is the simplest solution and the one that is most likely to take hold. Changes to the software would make it hard to see which dates will be autoformatted and which will not, and thus will greatly compound the problem of people not bothering to wikilink the dates. But if we adopt a simple, common date formatting policy, we wouldn't have to wikilink the dates or use any other kind of special wikiformatting. —Remember the dot (talk) 22:26, 12 December 2007 (UTC)
- I was just asking a general question, that's a little off-topic, because Peter brought up in Talk:Swedish language#Date autoformatting is sick and not being fixed that we should use unambiguous dates and he implied that ISO dates were ambiguous. So I was just trying to figure out what can be confused with the ISO format (YYYY-MM-DD). I've probably posted this in the wrong place but I don't know where it should go. –panda (talk) 22:38, 12 December 2007 (UTC)
- The ISO "2007-12-25" style is unfamiliar to most readers, which may lead to confusion. I would like a system that is as clear as possible. "25 Dec 2007" would be a good choice for an abbreviated date format, and "December 25, 2007" is a good choice for dates in prose. Both of these are very clear and easy to understand, as opposed to the unfamiliar and potentially confusing "2007-12-25".
- In other words, it's not a question of ambiguity per se, but rather a question of being in a familiar format that is easy for the reader to understand. —Remember the dot (talk) 22:50, 12 December 2007 (UTC)
- The reality is that any article that has a British, Australian, etc. subject matter generally uses the british date format, "25 December 2007" in the source text. See John Major for example. You aren't going to be able to convince people to change this; like spelling variants, this is something that's deeply ingrained in national culture. It's really not worth fighting. Also, bear in mind that something like [[2007-12-25]] results in Wikilinks being made to the appropriate year and day articles... if the reader is confused, they can click on it. -/- Warren 23:48, 12 December 2007 (UTC)
- Concur with Warren. Also oppose "25 Dec 2007", both because it is missing the dot in the abbreviation and more importantly because we shouldn't abbreviate just for the heck of it. — SMcCandlish [talk] [cont] ‹(-¿-)› 00:31, 13 December 2007 (UTC)
- The goal is to be clear enough that no user has to follow date wikilinks to figure out what the date is. About the "25 Dec 2007" format: that was just a suggestion, and if we'd like to avoid using it then that's fine. I'll respond to the American vs. British date formatting issue below. —Remember the dot (talk) 01:44, 13 December 2007 (UTC)
- It's like enforcing US or UK spelling throughout, rather than consistently within an article. Why not do the same for date formatting? an article uses either one or the other consistently, except in direct quotations. So the same rules apply (see MOS on variants of English, except that connections with a country might be a little looser; but I should imagine that a clearly US-related article would use the most common date formatting in that country, for example). What could be simpler, more consistent with existing practices, and less likely to spark internecine disputes? Tony (talk) 00:43, 13 December 2007 (UTC)
- Yes, that's a good point. This suggestion fits perfectly into existing guidelines for both dates and spelling: use "December 25, 2007" for articles that use American spelling and "25 December 2007" for articles that use British spelling. The only difference is that other date formats, such as "12-25-2007" or "25-12-2007" should be avoided, and as long as we avoid those harder-to-understand formats no date wikilinking should be necessary. —Remember the dot (talk) 01:44, 13 December 2007 (UTC)
- This ignores the fact that many American readers don't want to see 25 December 2007, and many British readers don't want to see December 25, 2007. Americans don't just read American articless, and the British don't just read British articles. Even if they did, there are articles pertaining to other countries where the format is whatever the first editor chose, so plenty of readers will be unhappy. The autoformatting was developed to solve these problems, and it works in the vast majority of cases, or did until the recent missionary activity by Tony, Lightmouse, and a few pals. Chris the speller (talk) 02:22, 13 December 2007 (UTC)
- This really needs to get fixed on the developer side. I think we'll see a big revolt if MOS tries to suddenly deprecate the wikilinking/formatting of full dates. We need a replacement methodology in place. — SMcCandlish [talk] [cont] ‹(-¿-)› 03:04, 13 December 2007 (UTC)
- This ignores the fact that many American readers don't want to see 25 December 2007, and many British readers don't want to see December 25, 2007. Americans don't just read American articless, and the British don't just read British articles. Even if they did, there are articles pertaining to other countries where the format is whatever the first editor chose, so plenty of readers will be unhappy. The autoformatting was developed to solve these problems, and it works in the vast majority of cases, or did until the recent missionary activity by Tony, Lightmouse, and a few pals. Chris the speller (talk) 02:22, 13 December 2007 (UTC)
- How many Americans do you think have such of a problem understanding "25 December 2007" that they would use preferences to force it into "December 25, 2007"? How many British would have a problem with "December 25, 2007"? English speakers have no problem understanding spelling variations, and no problem understanding this kind of date variation either. For this reason, few of those who are regularly logged in to Wikipedia actually use the date preferences.
- And after date preferences are turned on, it creates a disconnect between what date-preference editors see and what other users see. For example, say an American editor is set to use American date preferences and they type "December 25, 2007" into an article that uses British spelling. The American might not care that the date is typed in different format because to them, all the dates are forced into American format. But anonymous users and users without the date preference set would see inconsistent date formatting. This is only one of the many reasons why date formatting does more harm than good. —Remember the dot (talk) 03:17, 13 December 2007 (UTC)
- Pay attention! I did not say that Americans are dullards unable to understand 25 December 2007, I said that they don't want to see dates in that format. I think that hundreds of thousands, perhaps millions, prefer to see dates in the format that they're used to, and a great many use the preference settings to achieve that. Can you prove me wrong? Not for a second do I buy the ridiculously low estimates that Tony and his followers repeatedly claim for utilization of this feature. Even if it were a paltry 100 readers, I don't think that 3 or 4 zealots have any right to take that feature away from 100 readers that are content with it. And your last argument has no teeth; I use the date preference setting for American-style dates, but I manage to fix and clean up mixed-format dates and nonstandard dates in articles of both flavors. Chris the speller (talk) 04:12, 13 December 2007 (UTC)
- I'm glad that you can clean up mixed-format dates even when using date preferences. Still, I think that there may be users who are not so adept. You're right; that's a fairly minor point.
- My question is: is the date preference feature, used by a minority of users, enough of a benefit to outweigh the overlinking, the clogged "What links here" pages for articles like 2007, the confusion of new editors, and the extra time spent making sure that dates are wikilinked? The majority of editors are doing a rather large amount of work compared to the benefit that the minority receives. If we stopped using confusing date formats like "12-11-2007" then we could stop wikilinking (saving a lot of time, effort, and confusion) without significantly impacting the reader's experience or ability to understand the encyclopedia. —Remember the dot (talk) 04:44, 13 December 2007 (UTC)
- (Outdent) Oh really, Chris, why, then, hasn't there been open rebellion by Americans over the autoformatting of the dates we all see by far the most often: in our signatures? They're all in the British/Australian/Irish/NZ/South African format. I'm sure most North Americans haven't even noticed. And to take your argument to its logical conclusion, British readers would take objection to US spelling in WP. We have all happily accepted the varieties-of-English thing, which—aside from a few silly attempts to mass convert articles to different/inappropriate varieties—seems to work just fine, with consistency-boundaries around each article and intelligent rules about country-relatedness and not arbitrarily changing the variety once established. Now give me one good reason that comfortably reading "behavior" if you're British, or "behaviour" if you're Canadian, is in some different category from reading "23 November 1927" or "November 25, 1927" if you're from the other planet. It's just so trivial. Both formats are perfectly—effortlessly—comprehended by all English speakers. Who cares?
- But what I do care about is:
- the ugly blue splotches,
- the inflexibility,
- the cluttering of wiki-edit pages with square brackets,
- the unthinking spill-over into the linking of non-autoformatted chronological items (the 1990s),
- the fact that almost ALL readers of WP have to endure significant inconsistencies in formatting within articles, because they're covered up by the autoformatting, and we don't bother to fix them in the blind belief that they're ironed by autoformatting. They're not. What must appear very sloppy editing practices are exposed for all to see, and WPians are oblivious to it. At least that aspect would be cleaned up if an article is de-autoformatted. In relation to this, User talk:SandyGeorgia has just written on her talk page: "... with all the cleanup I've done at FAC and FAR, I can tell that with the exception of the few articles that are written largely by a single editor using a single style, most articles are a mish-mash mess of different formats added by different editors....".
- Now, let's take an example. Which would you rather read below? US spelling is used, so ... we'll just use US formatting for the full dates. Non-North-Americans, please get out your magnifying glasses and your calculators: take great care translating month and day: it's hard, so WP provides tables and equations to assist you in working it out.
Poe traveled to West Point and matriculated as a cadet on July 1, 1830. In October 1830, John Allan married his second wife, Louisa Patterson. Poe soon decided to leave West Point by purposely getting court-martialed. On February 8, 1831, he was tried for gross neglect of duty and disobedience of orders.
- or this:
Poe traveled to West Point and matriculated as a cadet on July 1, 1830. In October 1830, John Allan married his second wife, Louisa Patterson. Poe soon decided to leave West Point by purposely getting court-martialed. On February 8, 1831, he was tried for gross neglect of duty and disobedience of order.
- Allowing people not to autoformat dates (since, let's face it, there's zilch chance it will be fixed for some time) is entirely reasonable and wouldn't impose obligations on developers to redo the citation templates: leave them as they are in the reference lists at the bottom of articles, at least for the moment. And I'm not suggesting a mass conversion; just a dropping of the insistence on autoformatting. Tony (talk) 13:23, 13 December 2007 (UTC)
- I agree with Remember the dot/Tony. Dates should be treated like words that are spelled differently in American/British English. Use British English in British articles (colour/25 December 2007) and American English in American articles (color/December 25, 2007) . It works for prose and it will work for dates. Dates like 2007-12-25 should not be used because they can be confusing and not instantly comprehensible (e.g 1886-2-4, 1990-12-11, 1982-05-04 versus 4 February 1886, December 11, 1990) as months and days are not always clearly distinguishable. This way, we don't need auto formatting. One thing is clear, dates should not be linked. Kameejl (Talk) 14:17, 13 December 2007 (UTC)
- I cannot comprehend how anyone could see a risk of interpreting 1886-2-4 to be anything else than the second month. That format (even though it only partially conforms to the standard) is never used to mean the fourth month anywhere. The ISO standard also specifies that the incomplete date "October 1830" from the example above should be written 1830-10, so that the quote would read consistently as:
Poe traveled to West Point and matriculated as a cadet on 1830-07-01. In 1830-10, John Allan married his second wife, Louisa Patterson. Poe soon decided to leave West Point by purposely getting court-martialed. On 1831-02-08, he was tried for gross neglect of duty and disobedience of order.
- −Woodstone (talk) 14:54, 13 December 2007 (UTC)
- The problem with the ISO standard, other than the unattractiveness, is that readers may not recognize a month-year combination as such. "December 1910" is perfectly plain to everyone. If we were to use "1910-12" instead, how many readers would interpret this as the years 1910 through 1912? Yes, you should know it's not a date range by my use of a hyphen instead of an en dash, but that's far from common knowledge and I don't expect it from the average reader. Pagrashtak 15:44, 13 December 2007 (UTC)
- Its probably a bigger issue that should be discussed just here, but not linking dates, and having a common style within articles does seem like a reasonable way to go until a 'better' way of achieving auto formatting can be programmed into the media-wiki software. --Neo (talk) 14:30, 13 December 2007 (UTC)
- Woodstone, it's not as straight forward as you might think. Some countries use MM-DD-YYYY (USA) and some others use DD-MM-YYYY (Western Europe). What would you think of 10-03-1990, or 1990-10-03 if you'd have no knowledge of ISO 8601? What would you think of March 10, 1990, or 3 October 1990 if you'd have no knowledge of ISO 8601? Kameejl (Talk) 22:53, 13 December 2007 (UTC)
- If you don't know ISO 8601 then you don't know that nobody uses YYYY-DD-MM. If you don't know ISO 8601, you look at a date in that format and think "I have never seen a date in this format in my life, and I do not know what it means." TomTheHand (talk) 23:05, 13 December 2007 (UTC)
- Yes, readers can figure out what 2001-02-03 means, but "3 February 2001" or "February 3, 2001" is more natural to them. We're trying to make this as easy as possible for the readers. —Remember the dot (talk) 02:23, 14 December 2007 (UTC)
It's important not to underestimate the brouhaha that may result in the community over a simple change to date formatting (once a decision is reached here), and there's the additional issue of the inconsistent mess across the cite templates and how they handle dates. We should bring aboard some bot programmers, or at least ask someone like Gimmetrow for an opinion. I'm not fond of the idea ... "25 Dec 2007" would be a good choice for an abbreviated date format, and "December 25, 2007" for prose ... it introduces two contradictory formats in one article, and may just bug and confuse people. I hate the ISO format (just my 2 cents); it's ugly in prose and I always have to stop and think whether Venezuelan articles might get it wrong, and if you leave off the zero it doesn't format, and so on. I do think some editors on either side of the pond will object to being forced to write dates "the other way", so I like Tony's idea of using dates just as we use varieties of English; each article is either British or America throughout. Remove the linking, expect that each article uses one format consistently, either December 25, 2007 or 25 December 2007, in prose and footnotes alike. I think we could get acceptance for this, but it would need to be carefully presented, as everyone has an opinion. Most of our articles are a mish-mash, so editors not logged in to Wiki are seeing a jumbled mess. SandyGeorgia (Talk) 04:36, 14 December 2007 (UTC)
- For the sake of argument, let's just talk about what will be the best solution here, and then ask for broader community input. After the above discussion, I totally agree that each article should use the same formatting in prose as it does in footnotes. For example, if it uses "December 25, 2007" in the prose, then the footnotes should follow the same convention, no abbreviation.
- I am currently developing a JavaScript tool to assist in the transition. My vision is to have two simple buttons: "Reformat dates in American style" and "Reformat dates in British style". The editor would then click the button, the wikilinked dates would be reformatted, and the wikilinking would be removed. —Remember the dot (talk) 05:26, 14 December 2007 (UTC)
- I just want to be clear what exactly the proposal is for. Is it only about choosing either AmE or BrE style dates or is it about choosing either AmE or BrE for an entire article? For example, there is an article where the text is written in AmE but the dates are in BrE. –panda (talk) 15:18, 14 December 2007 (UTC)
- My proposal, which seems to have at least some support here, is to use a date formatting that is consistent with the variety of English used in the article, dispensing with the autoformatting schmuck and in the process ensuring that 99% of WP's readers, who have no set format in their preferences, are not faced with sloppy inconsistencies that are largely concealed from WPs by their rather exclusive autoformatting system. It's very simple and consistent with other principles of WP. Tony (talk) 15:41, 14 December 2007 (UTC)
- While I think the proposal is a good idea, there is no "international" or ISO English so the proposal would preclude using the ISO date format in all articles. I personally like ISO dates since they're unambiguous (which is not the same as unfamiliar) and short, using the least amount of space when compared with AmE or BrE dates, which is a plus in places like the references. They're also used quite widely in WP, primarily in references. Also, as another editor pointed out, if anyone is not sure what the date means (as long as they are linked), they can always click on the link and find out. If you can fit ISO style dates in there somewhere, then the proposal would be even better. –panda (talk) 17:00, 14 December 2007 (UTC)
- I like the ISO format too in many cases, but I think that the best solution here is to just spell everything out. The ISO format can still be used in some cases per the existing guidelines, but in prose and footnotes everything should just be spelled out for maximum clarity. The added space we take up doing spelling things out is a downside, but the added clarity and consistency makes up for it. —Remember the dot (talk) 17:46, 14 December 2007 (UTC)
If this is decided to go forward, I strongly suggest that we set up templates to do this, instead of spelling it out. {{dam|2007|12|11}} to give American format w/o wikilinks, {{dbr|2007|12|11}} for british no wikilink, {{dsh|2007|12|11}} for short no wikilinks, and each with an additional |l parameter to include wikilinks for day and year. The reasoning four-fold:
- A bot should be able to easily move any existing correct date to one of these formats (two sweeps, first for all dates, second to move to the dsh for any dates within templates).
- We gain more control when we wikilink. Yes, dates that should be wikilinked for sure can be written to take advantage of standard user-prefs, but then you're going to have possibly two different forms on the page.
- Say someone converts dates in an article in good faith in article to American form, but its realized the article should really be in British form. Search and replace of "dam" for "dbr" is very easy to do, and vice versa
- If we ever resolve the bugzilla issue such that auto-wikilinking of user-pref formatted dates can be disabled, we can repurpose the templates to handle those cases without requiring a large project-wide bot changeover. (One is still needed at the start, but this also prevents one at the backend should the problem be resolved.
Just an idea... (and while I'd like the template names to be shorted, "db" is already in use). --MASEM 17:26, 14 December 2007 (UTC)
- It's a good idea, but it's still overly complex. It makes wikitext even harder to understand, and many users are just going to not bother with the template. It also eliminates only one disadvantage of wikilinking: inconsistent formatting, and the JavaScript tool I'm working on will be able to fix that too (using regular expressions), and more easily.
- A bot to force dates into a particular format is not a good idea because there are always things that shouldn't be reformatted, such as dates in quotes. —Remember the dot (talk) 17:46, 14 December 2007 (UTC)
- I've just waded through this lot. I can see only one sensible solution, which is to follow Tony's suggestion: follow the lead of the first main contributor. That principle seems to work well with spelling, so why not with dates? Thunderbird2 (talk) 17:49, 14 December 2007 (UTC)
- I too have to concur with Tony, but I warn that we'd better do this more formally, with an RfC and advertising the proposed change more broadly, or people are going to completely flip out. Also want to echo who ever's comment it was that the numeric style is a no-go, because it is not readily understood by everyone, and the ambiguity of something like 2007-08 vs. 2007–08 simply isn't acceptable. — SMcCandlish [talk] [cont] ‹(-¿-)› 01:20, 15 December 2007 (UTC)
- Problem, sorry, I just noticed this comment from Tony: My proposal, which seems to have at least some support here, is to use a date formatting that is consistent with the variety of English used in the article, ... Venezuela uses American English and British dates; date formatting and variety of English will not always be the same. SandyGeorgia (Talk) 01:22, 15 December 2007 (UTC)
- Thanks for pointing that out. We can clarify the guideline to say to use British dates for articles related to countries that use British dates, and American dates for articles related to countries that use American dates.
- Incidentally, my script to automatically reformat dates now supports wikilinked ISO-format dates, so we now have an easy way to make a (gradual) switchover. We should agree on how to rephrase the guideline, and then get an RfC started to get broader community input. —Remember the dot (talk) 01:29, 15 December 2007 (UTC)
Transitional script now available
I've put together a script that can assist in the transition to unlinked but consistently formatted dates. Try adding the following to your monobook.js:
importScript('User:Remember the dot/Date format unifier.js')
When editing a page, this script adds two new items to the toolbox, "Format dates American style" and "Format dates British style". It will then scan the page for wikilinked dates of either style, and reformat them in the target style without the confusing wikilinking. It does not yet handle ISO-format dates.
If needed, the tool could be modified fairly easily to reformat unlinked dates. However, I do not want the tool doing this by default due to dates in quotes etc.
What do you think? —Remember the dot (talk) 22:17, 14 December 2007 (UTC)
By the way, the script has only been tested on Firefox 2, though it should also work on Internet Explorer 7 and Opera. —Remember the dot (talk) 22:38, 14 December 2007 (UTC)
- Your script didn't seem to work for me. Tested on Chairman of the Central Executive Committee of the All-Russian Congress of Soviets and it didn't change any format, only delinked one repeated date. Ultimately this problem should be addressed the same as how PMID 123456780 and ISBN 0-905715-24-1 work. (I thought ISO did the same thing, but apparently not?) Gimmetrow 00:28, 16 December 2007 (UTC)
- Ah. It doesn't handle [[December 25]] [[2007]]. It's expecting dates in the format [[December 25]], [[2007]] (note the comma separator). I can fix this if you'd like. —Remember the dot (talk) 01:59, 16 December 2007 (UTC)
- You probably should, because date prefs insert the comma and many editors type dates without them. (Yes, it's not ideal for non-logged-in editors...) Gimmetrow 02:15, 16 December 2007 (UTC)
- Ah. It doesn't handle [[December 25]] [[2007]]. It's expecting dates in the format [[December 25]], [[2007]] (note the comma separator). I can fix this if you'd like. —Remember the dot (talk) 01:59, 16 December 2007 (UTC)
- Fixed. Please let me know if you find any other problems with the script. I should have an ISO-only (wikilinked or not) script available shortly. —Remember the dot (talk) 05:17, 16 December 2007 (UTC)
Possibly stupid question (template mechanics)
I know just enough about how templates work on WP to be dangerous in the sense that I'm trying to think that if we can figure this out to make a template {{d|2007-12-14}} and {{dl|2007-12-14}} to produce unlinked but user-pref formatted dates and linked, user-pref formatted dates, respectively (those don't have to be the template names of course). Given that I'm sure someone's looked at this before via templates, I figure I may be reasking an earlier question but it can't hurt. Looking at the Mediawiki help, the extensions seem to be there: we can assign a value to a variable, we can use string manipulation to strip out parts of that text, and we can format a date per user-specifications. It would seem to be that it should be possible to create the standard wiki-linked date from #date and then process it to remove the wikilinks if these aren't desired.
Again, I know the issue has been brought up before at WP:Date Debate though I haven't seen anything that outlines technically why it cannot be done by templates, so I'm sure more experienced eyes have tried to work this possibility out. Is it because some of those MediaWiki extensions are not enabled in WP or something I'm missing in the template mechanics? --
- I think it's possible (I can see a way to do it), but I don't think it's worth the hassle. Once we eliminate the confusing date formats there shouldn't be much of a need to reformat dates at all. As soon as we start talking about a more complicated solution then it's headaches all over again. —Remember the dot (talk) 21:32, 13 December 2007 (UTC)
- I played with this yesterday, and yes, there's no way to do it using templates as WP is currently configured (per Special:Version). The various MediaWiki extensions that allow for string manipulation are not installed, and there's no equivalent aspect from any of the other included extensions. #time gets us to the point of [[2007]] [[December 14]] (in user-pref date format) but I can't remove the square brackets without additional functions. --MASEM 15:26, 14 December 2007 (UTC)
The #time m:ParserFunction doesn't produce wikilinked code: 24 May 2024 vs. May 24, 2024. Gimmetrow 01:20, 16 December 2007 (UTC)
- Unfortunately (for what I was trying to do) #time doesn't adjust for user date prefs; however if you give the format code, say [[d F]] [[Y]] then it gives wikilinked code, when then the auto date formmatting steps in and adjusts it. --MASEM 01:25, 16 December 2007 (UTC)
- Is the thought to make a template which formats dates according to prefs? If it were possible to have a user-defined string available as a Magic Word, you could do something like {{#time: {{USERDATEPREF|d F Y}}|September 11, 2001}}. But this seems like a roundabout way to deal with this problem. And, #time only works for 1970 to 2038. Gimmetrow 01:48, 16 December 2007 (UTC)
- Yet another piece of javascript code could probably remove the links for those who want less blue text. Gimmetrow 01:56, 16 December 2007 (UTC)
BC/AD vs. BCE/CE dating style
Propose changing the manual of style to add the following:
On articles on specifically Christian subjects not shared with other religions (e.g. Jesus, Chrism, Old Testament), the BC/AD dating system may be used. On articles on specifically on non-Christian religions or subjects shared with multiple religions (e.g. Ten Commandments, Hebrew Bible, Pharisees), the BCE/CE dating system is preferred.
Best, --Shirahadasha (talk) 21:23, 10 December 2007 (UTC)
- This has been proposed before. The problem is that BC/AD is used secularly, very widely so. It was even (and occasionally still is!) used in scientific contexts until the rather recent invention of the BCE/CE nomenclature. I vastly prefer BCE/CE, for the same reasons it was invented (i.e. to reduce the pushing of a religious point of view), but I don't always get my way here. <sigh> — SMcCandlish [talk] [cont] ‹(-¿-)› 01:21, 11 December 2007 (UTC)
- I don't think that our fists have healed completely from the last time someone proposed changing this. It is well written at the moment and we should leave well enough alone. —MJCdetroit (talk) 04:32, 11 December 2007 (UTC)
- Strongly concur, on a WP:NOT#BATTLEGROUND basis, even if I would like to see it settled out some day. I firmly predict, and would even lay real money on it, that 5 years from now WP will pretty consistently use the BCE/CE system, but we're just not there yet. I take a Bene Gesserit kind of long view on things like this. — SMcCandlish [talk] [cont] ‹(-¿-)› 09:00, 11 December 2007 (UTC)
- I don't think that our fists have healed completely from the last time someone proposed changing this. It is well written at the moment and we should leave well enough alone. —MJCdetroit (talk) 04:32, 11 December 2007 (UTC)
- I have no wish to spark debate over the merits of either notation, but I must say that I get the feeling that this is a rather uniquely American controversy. To someone who has been raised in a thoroughly secular environment, the suggestion that the modern use of BC/AD instead of BCE/CE would somehow constitute a religious statement (let alone a POV) is highly exaggerated.
- Peter Isotalo 13:44, 11 December 2007 (UTC)
- The proposal does not apply to "thoroughly secular" contexts. It applies specifically to religious contexts where connotations and sensibilities are different and which can use specialized language to reflect this. As an analogy, in an ordinary article there might be no need to be concerned that a statement about charm or flavor would be interpreted as a statement about physics. No doubt a person from a nonscientific environment would similarly think the idea of confusion exaggerated if not silly, and in most article contexts such concern would be inappropriate. But in physics articles this is indeed possible, and a non-physicist can't really tell when physicists would infer a physical meaning and when they wouldn't. Many words have both ordinary and specialized meanings. Caution is appropriate to take into account otherwise ordinary words' specialized meanings in a field for purposes of articles on subjects in that field. Religion is no different from physics in this regard. The proposal is limited to specifically religious subjects. Best, --Shirahadasha (talk) 18:21, 12 December 2007 (UTC)
- Note: The proposal is limited to articles specifically on the subject of religion. Articles on secular subjects remain unaffected. In the specific context of articles on Judaism or Islam, BC/AD dating is often perceived as a religious statement. Best, --Shirahadasha (talk) 14:06, 11 December 2007 (UTC)
Modified proposal
Given the feedback so far, how about we qualify the exception to make clear it is limited to specifically religious subjects:
Exception limited to articles specifically on religious subjects: On articles on specifically Christian subjects not shared with other religions (e.g. Jesus, Chrism, Old Testament), the BC/AD dating system may be used. On articles on specifically on non-Christian religious subjects or subjects shared with multiple religions (e.g. Mohammed, Ten Commandments, Maimonides, Pharisees), the BCE/CE dating system is preferred.
Best, --Shirahadasha (talk) 18:08, 12 December 2007 (UTC)
- Oppose: Sorry, I know you mean well, but I still oppose. If you want to change format from BC/AD to BCE/CE bring it up on the individual talk page, gain consensus and do so. I would think that you would not have any problem doing so on an article about something Jewish or Islamic in nature. —MJCdetroit (talk) 21:05, 12 December 2007 (UTC)
NeutralWeak support, prefer broader solution: I like this in theory, as far as it goes, but fear that in practice it will just big a big battle. I'd rather see us settle on BCE/CE across the board, including for Christian topics, because the consistency would be more important than the POV of keeping Christians who like BC/AD happy. — SMcCandlish [talk] [cont] ‹(-¿-)› 00:50, 13 December 2007 (UTC)- Weak support. I'm actually with SMcCandlish on this. I think Wikipedia should take a stand. It's enough that Christian partisans have calibrated the world's universal dating system at 0 = their God's alleged year of birth. Why can't they be happy with that? Why also rub it in, with a reference to their Christ in dates? Sometimes the obvious needs to be stated, so here goes: The world is large and various, guys. Live with it, and allow the language to be secular and tolerant of difference, by adopting a uniform non-religious system for dates. But in practice we'll never succeed with this one; hence my weak support for the alternative proposal – which also will not succeed.– Noetica♬♩ Talk 03:23, 13 December 2007 (UTC)
- Comment if you look at the Jesus page it says that he was born between 7 and 2 BC where 0 BC is when he was born.... Given this shouldn't all articles especially religious ones use BCE/CE? Otherwise we should have two sets of dates of set by 7-2 years. Shniken1 (talk) 03:55, 13 December 2007 (UTC)
- I can't fully parse your first sentence, but anyway most Christians who are even aware of the fact that most Biblical scholars argue for a BC date for Jesus's birth, simply do not believe it. It's a faith matter. AD one starts right after the birth of Jesus, and that's just that. The fact that they're probably factually wrong isn't going to stop them from insisting on BC/AD dates for Christian and other topics. That's one reason I say MoS should just insist on BCE/CE dates and have done with it, because the types who will demand BC/AD dates on a religion basis will insist upon it more generally as "right". — SMcCandlish [talk] [cont] ‹(-¿-)› 02:12, 15 December 2007 (UTC)
- Weak Oppose - if this is just an issue for religious based articles then surely it can be left to relevant religious wiki-projects to develop their own guidelines on the subject. --Neo (talk) 14:24, 13 December 2007 (UTC)
- Both WP:WikiProject Judaism and WP:WikiProject Islam had done this. It had been argued that religion wikiprojects don't have the authority to establish dating conditions different from the manual of style with its first-to-edit rule. One very simple compromise would be to make clear that Wikiprojects can have a different rule. Best, --Shirahadasha (talk) 22:17, 13 December 2007 (UTC)
- It should not be phrased in terms of WikiProjects; too many WPPs already have inflated ideas of their importance and supremacy over "mere" editors, and this really has to stop. It should be phrased in terms of editorial consensus at the article to which it would apply. In most cases, where a WikiProject is genuinely active and isn't acting like an exclusive private club, what the WikiProject wants and what the editors of in-scope articles want, regardles off their project participation, will align. Where they do not align, the MoS sure as heck should not be giving the project some kind of authoritative edit that it simply doesn't have under policy. — SMcCandlish [talk] [cont] ‹(-¿-)› 02:12, 15 December 2007 (UTC)
- Both WP:WikiProject Judaism and WP:WikiProject Islam had done this. It had been argued that religion wikiprojects don't have the authority to establish dating conditions different from the manual of style with its first-to-edit rule. One very simple compromise would be to make clear that Wikiprojects can have a different rule. Best, --Shirahadasha (talk) 22:17, 13 December 2007 (UTC)
- Oppose. CE and BCE are not widely understood in Britain. They are best avoided. --Zundark (talk) 16:36, 13 December 2007 (UTC)
- Weak support – You don’t need the first sentence, perhaps: “In articles on religious subjects not exclusive to Christianism the common era dating system is preferred.”
- I further propose to rename – for all Wikipedian purposes – the weekdays except for Monday and Sunday, and (at least) the months January, March, May and June, because all of them are not religiously neutral. Christoph Päper (talk) 19:37, 13 December 2007 (UTC)
- I am not suggesting that Wikipedia take its own advocacy position against common usage based on abstract principle and would not recommend doing so. I am only suggesting addressing actual existing perceptions and issues. There may possibly be articles where references to the Sun's day or the Moon's day (or for that matter Tyr's Woden's, Thor's, Fria's or Saturn's days) might be taken religiously as well. But we don't have to deal with it unless it comes up. Best, --Shirahadasha (talk) 22:17, 13 December 2007 (UTC)
- I’ve got an issue with being called German (or Allemand, Niemcy etc.) instead of deutsch, no speaker of English cares about my feelings.
- Yes, you have to deal with the implications of your proposal. What better time than now? Christoph Päper (talk) 03:17, 14 December 2007 (UTC)
- This is getting a bit silly. Hardly anyone knows the actual origin of our weekday names, the religions they derived from died centuries ago (yeah, yeah, I know about Neopaganism), and they don't have anything to do with a world in which radical Christianity is trying to prevent the teaching of science in schools, and radical Muslims are blowing up people all over the place on the basis of them being Christians. More to the point, no such system of replacement weekday names is accepted, which is not the case for the BCE/CE replacement for the BC/AD system. — SMcCandlish [talk] [cont] ‹(-¿-)› 02:12, 15 December 2007 (UTC)
- I am not suggesting that Wikipedia take its own advocacy position against common usage based on abstract principle and would not recommend doing so. I am only suggesting addressing actual existing perceptions and issues. There may possibly be articles where references to the Sun's day or the Moon's day (or for that matter Tyr's Woden's, Thor's, Fria's or Saturn's days) might be taken religiously as well. But we don't have to deal with it unless it comes up. Best, --Shirahadasha (talk) 22:17, 13 December 2007 (UTC)
- Oppose. It's not our job to advocate. Given the vitriol this topic generates, I'm rather inclined to avoid the terms altogether. Feezo (Talk) 00:29, 15 December 2007 (UTC)
- Huh? How would propose to talk about BC/BCE dates then? — SMcCandlish [talk] [cont] ‹(-¿-)› 02:12, 15 December 2007 (UTC)
Proposed MOSNUM text for optional autoformatting
Dear colleagues, pursuant to the discussions above, I propose the following replacement of the opening text (i.e., the five bullet points and table) in MOSNUM's Dates section; this incorporates and thus would replace MOSNUM's Autoformatting and linking section. For the subsection on the non-autoformatted display of dates, I've drawn heavilyl on MOS's Varieties of English section. In this respect, the proposal is merely the logical extension of that long-standing policy to dates.
Here's the proposal, for which I seek your feedback.
Tony (talk) 00:09, 15 December 2007 (UTC)
- On
- Therefore, if autoformatting is used, the raw formatting within the autoformatting syntax must be consistent throughout the main text of each article.
- do we want to say that the raw formatting should be consistent in either case (autoformatting used or not used)? Also, can you emphasize somewhere that this include prose (text) as well as footnotes/references? SandyGeorgia (Talk) 00:38, 15 December 2007 (UTC)
- This proposal really don't solve anything...editors are still going to debate whether or not articles should use wikilinking. We really need to just come out and say that editors should be using unambiguous, unlinked dates. As I mentioned above, I already developed a JavaScript tool to assist in the transition, so editors can quickly and easily get dates into the new format. —Remember the dot (talk) 00:44, 15 December 2007 (UTC)
- Remember the dot: I agree with your goal, but politics is the art of the possible, and I think that banning autoformatting is going to upset a lot of people, who'll end up derailing any change. The proposal allows your bot to work (although it would be diplomatic first to ask contributors if you think they may be sensitive about it). Banning autoformatting immediately makes just about every article in breach of MOS and will require time and application to return to compliance. It's too dramatic.
- On the contrary, I'd be willing to insert a "provided there is consensus on the talk page" clause if people are going to object to the current optional proposal. But I'd rather do that only if it's a deal-breaker. That's how we achieved change WRT the use of unconverted metrics in scientific articles. Tony (talk) 01:36, 15 December 2007 (UTC)
- On
- The use of WikiMedia's date autoformatting system for full dates, and days and months, is optional.
- I want to put my strong opposition to this entire proposal on record. Looking through the debate above, I think I'm correct in saying that none of the proponents of change have been editing (at least under their current account names) much before mid-2005. I was here in mid-2003 and remember the disputes which resulted in the creation of the present date preferences system and can see no reason why they would not restart if routine linking of dates became deprecated. Sure, the present system isn't perfect, but until the developers can be persuaded to produce something better it is not so badly broken that it needs to be thrown out completely. Leave the present MOSNUM text alone. -- Arwel (talk) 01:17, 15 December 2007 (UTC)
- (1) I think you're underestimating the number of problems in the current autoformatting system, the complexity of addressing them, the fact that most of WikiMedia's developers are voluntary and are apparently not thrilled about the prospect of trying to address these problems, and the need to shepherd any new system through an approval process further up the chain once it has been developed.
- (2) As for the disputes nearly five years ago, well, I guess they occurred in the absence of well-drafted rules such as we have now to manage the Varieties of English issue. This proposal embodies an analogous set of rules that are a logical extension of this to date formatting. Your fears, I think, are unfounded. Tony (talk) 01:36, 15 December 2007 (UTC)
- I think you are substantially overestimating the problems with the current autoformatting system, and sensationalizing some of the most minor. I also want to emphasize that a moderate solution (making dates no longer behave as links and perhaps some other fixes) is probably quite technically feasible. In fact, it probably would have already been implemented if the original Bugzilla entry (or any of its various resurrections) had simply asked for this directly. As for the "varieties of English" bit, I would hesitate to call that "well-drafted" and I would point out that I still see edits that change one dialect to another with some frequency. — Aluvus t/c 03:52, 15 December 2007 (UTC)
- OMG, it 'DID' ask for this directly, plainly and simply. You clearly haven't read it. See SMcCandlish's entry below, too. Tony (talk) 14:11, 15 December 2007 (UTC)
- First you say I'm overestimating (I can cope with that accusation), but "sensationalising"? That's rather out of proportion with the reasoned arguments I've put, isn't it?
- Do you really think the system is going to be fixed any time soon? Please let's not kid ourselves about the developers' attitudes or the technical challenges of fixing all of the issues (although the main one, linking entanglement, may be feasible – but I'm suspicious that no one has been able to do it. See Rob Church's and others' attempts, documented at Bugzilla, and Vibber's implication that it was quite a task).
- It appears to me that you're seeing the issue very much from a logged in editor's perspective, whereas all that really counts is our readers' experience, and only a tiny proportion access the autoformatting function. And worse, are you claiming that the autoformatting system is not' associated with inconsistencies in formatting within articles that SandyGeorgia has pointed out from her large sample of clean-ups? Are you claiming that the absence of rules and the masking of the raw formatting by the auto function isn't allowing messy inconsistency for all but the self-selected few WPians who don't see the raw formatting in their display? I see none of these issues addressed in your comments. Tony (talk) 14:11, 15 December 2007 (UTC)
- You've made two sweeping claims about the "National varieties of English" section in MOS without specifying the reasons: just why are you asserting that it is poorly drafted (details, please), and can you provide (recent) examples of imbroglios that remained unresolved despite the application of the guidelines? Please remember that the text underwent an overhaul only six months ago.
- I agree that the disadvantages of the current system are being blown way out of proportion here. I feel that autoformatting is an important feature, and I think its advantages outweigh its disadvantages. TomTheHand (talk) 04:25, 15 December 2007 (UTC)
- Tom, you may feel that it's important and that the advantages outweigh the disadvantages, but others don't share your view. Why do you insist on forcing your view on everyone? What is wrong with enabling you and others to use it not to use it by consensus on an article-by-article basis, given a set of carefully conceived guidelines? Tony (talk) 14:18, 15 December 2007 (UTC)
- How can you say that others don't share Tom's view (with italics, no less)? How many times have I stated the same thing, and how many more times do I have to say so? As many times as you and a few other anti-formatters state (with no evidence) that few readers have specified a preference for date format? Chris the speller (talk) 18:13, 15 December 2007 (UTC)
- Tom, you may feel that it's important and that the advantages outweigh the disadvantages, but others don't share your view. Why do you insist on forcing your view on everyone? What is wrong with enabling you and others to use it not to use it by consensus on an article-by-article basis, given a set of carefully conceived guidelines? Tony (talk) 14:18, 15 December 2007 (UTC)
- I agree that the disadvantages of the current system are being blown way out of proportion here. I feel that autoformatting is an important feature, and I think its advantages outweigh its disadvantages. TomTheHand (talk) 04:25, 15 December 2007 (UTC)
- I see that my statement was ambiguous; I meant that "not all people share that view". Tony (talk) 03:19, 16 December 2007 (UTC)
- I'm not forcing any view on anyone: I want editors to be given the option to use autoformatting or to avoid it by following a set of rules for the choice of format and consistency in an article. The current system forces everyone to use autoformatting. That is what you appear to want to retain. Tony (talk) 03:19, 16 December 2007 (UTC)
- My impression is certainly that you would quite like to force all dates to be de-linked. We keep hearing about the "rubbishy output" of linked dates and the implication that you support a less severe solution only because of the "politics". But set that aside: unlinked dates force people to read dates in a format they may not like (or worse, understand). This is the entire reason for the autoformating system. Ironically, a mixture of linked and unlinked dates would force people with a preference set to see inconsistent dates. Additionally, the general tone of this discussion (and of previous discussions on this topic) is of a few people that quite dislike date autoformating trying to force everyone else to throw it under the bus. — Aluvus t/c 05:31, 16 December 2007 (UTC)
- I am tiring of your accusations that I, or anyone else, would like to "force" people to not to autoformat. You really are brushing against dishonest (or is it consistently careless?) misrepresentation of my views. At the moment, everyone is forced to use the autoformatting. In what way am I forcing all dates to be delinked? Please show me where I've said that. It will soon become acrimonious if you tell lies and distort what I say. And where, pray let us know, do I "keep" talking about the rubbishy output? I wrote that ONCE, and ONCE ONLY. "Keep hearing" means that I say this continually. Now if this is the way you engage in a debate, no one will take you seriously. It really is offensive. Tony (talk) 12:59, 16 December 2007 (UTC)
- The idea behind my JavaScript tool is to eliminate confusing and inconsistent dates. Having this whole date formatting system is not truly necessary in order to have perfectly understandable dates. As for the inconsistency that would stem from transition from wikilinked to unlinked dates, we could ask the devs to just disable date preferences. That request is simple enough that they would probably go for it if we demonstrated consensus to do so. —Remember the dot (talk) 05:45, 16 December 2007 (UTC)
- Please see my comment above, added in my previous edit, as regards the way this was brought to Bugzilla. But as for the rest:
- You have personally made quite a big deal out of the inability to autoformat something like "August 15-16" or "the night of August 15/16", when in fact the former can be solved with "August 15 to August 16" and the latter is an edge case that I have never seen in any article (and can be worked around with "the night of August 15/August 16"). I don't doubt that there are a handful of articles where this may crop up, but I also don't doubt that there are very few of them. Nor that a simple rephrase (or even "the night of August 15") can generally make this a moot point. You keep bringing up edge cases like these even though they are at best very minor limitations.
- Please see my comment above, added in my previous edit, as regards the way this was brought to Bugzilla. But as for the rest:
- The developers' attitude appears to be "we agree that something should be done, what should it be?" Unfortunately they have not been presented with any consensus on what should be done.
- More than 80 WPians asked them to develop a simple syntax for a separate, non-linked autoformatting. During the several weeks in which the petition was open, not one person opposed. I even notified a prominent antagonist to the delinking of chronological items; she did not stand in the way. I don't know why this doesn't represent, in your words, "consensus on what should be done". It was quite clear on Bugzilla, and we left it up to the developers to select the actual syntax, on the advice of several techy participants. Tony (talk) 03:19, 16 December 2007 (UTC)
- Consensus that "something should be done" is not the same as consensus that "exactly this should be done". Again, read the Bugzilla page and look at the wildly different ideas being presented. All of that confusion should have been resolved before the feature request was revived. — Aluvus t/c 05:31, 16 December 2007 (UTC)
- Choosing a site-wide default date format for autoformated dates (and allowing editors to override it with date preferences) would moot any concerns about inconcistency due to autoformating. I am also very confused by your implication that a "self-selected few WPians" use date autoformating, when you have previously claimed the exact opposite.
- I see edits and edit conflicts over national spellings with enough frequency that I do not bother recording specific instances. These are generally fairly brief (because some third party cites WP:ENGVAR and/or temporarily protects the page), because ENGVAR has its positives. But I hesitate to treat it as a model that should be used as a basis for other policies. It is an "OK" policy that works within the limits of Wikipedian culture, but one must not ignore its drawbacks and simply duplicate its thinking. — Aluvus t/c 23:28, 15 December 2007 (UTC)
- Right, and it's become clear that developers aren't going to do anything for us about this, because the consider the matter already solved. What actually happened is that the solution caused more problems than it fixed. The only way to get a better solution appears to be to actively reject the first one. I think this is a perfectly rational thing to do. We gave the solution the benefit of the doubt, tried it for a couple of years, and it has proved unworkable. Consensus can change – the fact that there was a consensus several years ago to try this out does not mean we are stuck with it forever. WP is not a legal system, and is not bound by precedent. I also resent the implication that over two years of near-daily service to Wikipedia is somehow not enough to come to sensible conclusions about what is good for Wikipedia. — SMcCandlish [talk] [cont] ‹(-¿-)› 01:50, 15 December 2007 (UTC)
- I'm sorry if you thought I was denigrating your contributions, that was certainly not the intention. The point I was attempting to make is that those of us who have been here longer can remember why we got to the present situation. Yes, consensus can change - until fairly recently we routinely wikilinked to stand-alone years, and I am glad that we got rid of that pointlessness, but the displayed format of dates is something which is deeply culturally ingrained in the readers, and as we found in 2003 this is something which rubs people up the wrong way to an incredible degree which is why autoformatting was created. When you say the present system is unworkable, I think that you are simply wrong; OK there are difficulties with expressing date ranges, but on the whole autoformatting's advantages outweigh the disadvantages. You can quite justifiably insist on using the same format within an article, for the benefit of people who don't have preferences set, but to remove routine autoformatting for those who have stated a preference will cause one hell of an argument, particularly if it's seen as the hobbyhorse of a dozen or so individuals affecting hundreds of thousands of articles. -- Arwel (talk) 12:37, 15 December 2007 (UTC)
- I'm still sputtering at Arwel Parry's response. I've never had much use for WP:WBE and editcountitis, but considering that a huge portion of mine are in article cleanup, perhaps that list is useful on this occasion. SandyGeorgia (Talk) 01:55, 15 December 2007 (UTC)
- Edit count and time in the project are quite different things. It is very easy to say a solution sucks when you never really experienced the problem it is meant to solve. As someone that was not present at that time, I value the thoughts of those that were there. This is one of those instances where seniority is actually relevant. While I would like to hear from other "old timers" (no offense intended), I am not so eager to dismiss what Arwel Parry has said. — Aluvus t/c 03:52, 15 December 2007 (UTC)
- I support it. Nobody uses the date preferences anyway. Over-linking is confusing. We can handle conflicts about date formatting if it pops up. We don't need a technical kludge to shut up a few noisy people. --Apoc2400 (talk) 16:27, 15 December 2007 (UTC)
- Somebody obviously uses date preferences, because we're arguing about it. And I know of one for a fact - me :-) RossPatterson (talk) 17:56, 15 December 2007 (UTC)
- Can we get statistics on:
- Registered versus unregistered users.
- Registered users that have set a date preference.
- Lightmouse (talk) 16:49, 15 December 2007 (UTC)
- For every one person like me who edits Wikipedia, I see countless others who use Wikipedia but edit anonymously or not at all. Only a couple thousand people have made substantive contributions to Wikipedia articles according to this, compared to the millions of people who read the articles we write. —Remember the dot (talk) 17:48, 15 December 2007 (UTC)
- Well precisely. WP is not for us to read, but for the vast numbers of people all over the world who consult it—millions a day, isn't it? That is what concerns me about this debate: it's as though what WPians see on their screen is much more important than what our readers out there see. I care much more about those people at large, millions of them, who see blue splotches everywhere but no autoformatting—and in many cases have to put up with inconsistent formatting from one paragraph to the next, because for us, this is ironed out. That is why I've received comments from general readers to the effect of "WTF, why are all of the dates blue, and sometimes they're not even formatted consistently?". Tony (talk) 03:01, 16 December 2007 (UTC)
- That still doesn't resolve the problem of editors being thoroughly confused at the inconsistent date formatting they would see when editing articles. It also would still produce inconsistent formatting if some editor didn't bother to wikilink, and would result in a terrible debate over whether the default formatting should be "25 December 2007" or "December 25, 2007". —Remember the dot (talk) 05:39, 16 December 2007 (UTC)
- Do you believe that a great number of editors are "thoroughly confused" by the date formats they currently see in the edit box? I haven't noticed this as a common complaint. I'm not sure this is a matter of "confusion" so much as aesthetics. And yes, dates that aren't linked may be different... but then if the autoformat system dies and someone fails to adhere to whatever date format a specific page uses (and a portion of them won't), you have the exact same problem. Except one that is harder for bots to sort out, because they have to evaluate which format is "right" for a given page. And if you think a debate about what date format is the default (which partisans can simply override and not be affected by) is scary, imagine the same basic debate, spread out over millions of articles. Heck, imagine a debate over whether to keep autoformating that involves people that don't visit MOSNUM. Dropping autoformating has its positives, but "avoiding big horrible debates" is clearly not one of them. — Aluvus t/c 10:14, 16 December 2007 (UTC)
Alvulus, you pontificate in the expectation that the developers will race to do whatever is asked of them. They won't, and we ample evidence of that. Tony (talk) 12:59, 16 December 2007 (UTC)
Let's start small
I propose that we start small. Let's change the citation templates, like Template:cite web and Template:cite news, to discourage use of the ISO format in favor of a format that is more clear. Currently these templates automatically wikilink dates that are in ISO format, in defiance of Wikipedia:Manual of Style (dates and numbers)#Dates which suggests avoiding ISO.
Existing ISO format dates will continue to show up, but will not be automatically wikilinked. I will provide a JavaScript tool that enable users to quickly convert all ISO dates in an article to [[25 December]] [[2007]] or [[December 25]], [[2007]] format. This option leaves open the possibility of delinking those dates at a later time. —Remember the dot (talk) 17:58, 15 December 2007 (UTC)
- Wikilinks to dates in ISO format in the {{cite web}} template are displayed according to a user's date preference. I would not encourage changing all of those ISO dates to one format or the other. --Pixelface (talk) 12:47, 16 December 2007 (UTC)
- How is this "starting small"? Starting small would be agreeing here on a course of action, then getting people that don't read MOSNUM to take a look at it, and then beginning to gradually implement it. Editing high-visibility templates is not "starting small". Additionally, linking ISO format dates is not in disagreement with MOSNUM; MOSNUM simply states that ISO dates are generally not used. They are used in those templates because linking an ISO date is very easy; if you try a different date format, you will find that it is linked improperly (the entire date is a link). If there is wide acceptance for not linking dates, then these templates will eventually just drop linking altogether.
- Getting templates to support arbitrary unlinked dates (which in fact many don't, because they want to link the date) will eventually be important, but is something that should be addressed only once it is clear that there is general support for not linking dates. Changing these templates when there is not even consensus on this page to drop or revise the policy on date linking would be ridiculous. — Aluvus t/c 23:52, 15 December 2007 (UTC)
- The idea behind starting a discussion here was to reach consensus on whether or not to do this. It's not like I just slapped {{editprotected}} on all the templates. And I'm not asking to remove the wikilinking entirely at this point - just to stop using ISO-format dates on templates in favor of using familiar and unambiguous (and wikilinked) formats. —Remember the dot (talk) 01:07, 16 December 2007 (UTC)
- Further investigation indicates that {{cite web}}'s behavior is actually odd and inconsistent. It will pass a non-ISO date in the "date" paramater just as given, even if it is not a proper date format of any kind. ISO dates get linked, other data is passed as given. This matches the behavior of {{cite news}}'s date parameter. For the accessdate, however, it will apparently just turn whatever you give it into a link. This matches the behavior of {{cite}}'s date parameter.
- This means that {{cite web}} would have to be altered before non-ISO dates could be entered into the accessdate parameter, and {{cite}} would need to be altered as well; just changing the documentation to encourage other formats is not adequate. Using your script to change dates out of ISO format (linked or otherwise) would also not be adequate. Other templates mostly seem to be "dumb" as regards dates, so it makes no difference for them.
- In any event, given that the only format they seem able to automatically link correctly is ISO, and your second paragraph indicates that you specifically want them to stop linking ISO (for some reason), yes you are asking for the templates to remove their automatic wikilinking entirely. — Aluvus t/c 04:59, 16 December 2007 (UTC)
- Yes, I'm aware of how the templates work. I was actually the one that got the date parameter to automatically wikilink at all. It hasn't been a month since this behavior was added, so there aren't too many articles that use it. At the time it seemed like a good idea, but now I see that it would be better to encourage more human-friendly dates.
- I recommend that we remove the autolinking function from these templates entirely, and then use a semi-automated script to reformat the ISO dates. The script will add wikilinking per the current guidelines. For example, [[2007-12-25]] would become [[December 25]], [[2007]] if the American formatting style is selected. This shouldn't be as controversial as removing the wikilinking entirely. Most of the users who have commented preferred avoiding the ISO format, which suggests that the community would support this idea. We would still need to advertise the discussion more before making the change. —Remember the dot (talk) 05:16, 16 December 2007 (UTC)
- The script for reformatting ISO dates is now available. Add
- importScript('User:Remember the dot/ISO date format unifier.js')
- to your monobook.js and let me know what you think! —Remember the dot (talk) 05:31, 16 December 2007 (UTC)
Grouping of digits after the decimal point
An issue has arisen in Meter. User:Greg L has quite rightly edited the article so that instead of using a mixture of styles, it now uses commas to group large numbers into groups of 3 digits. However, there is still inconsistency in dealing with digits to the right of the decimal point. One example is:
Consequently, a practical realisation of the metre is usually delineated (not defined) today in labs as 1,579,800.762 042(33) wavelengths of helium-neon laser light in a vacuum.
Another example is "0.03937 inch".
I believe the Chicago Manual of Style says to not use spaces, commas, or anything other grouping symbol to the right of the decimal point, but as far as I can see, Wikipedia's MOS does not address this. So what should we do? --Gerry Ashton (talk) 19:43, 15 December 2007 (UTC)
- The issue of how to deal with the spacing of digits after the decimal point has arisen before. Some advocated leaving spaces every three digits and some leaving no spaces. No consensus was reached, which is why there is no guidance in the MOSNUM. Your views on that discussion are welcome. Thunderbird2 (talk) 20:22, 15 December 2007 (UTC)
- My view isn't of much practical value. My view is that Bill Gates and his cronies should, in the early days of Windows, specified keyboards and software that would allow us to write SI measurements without having a PhD in computer science, which means non-breaking thin spaces, °, μ, and Ω right on the keyboard. Also, all software that accepts numbers should accept them with the agreed-upon digit grouping mark embedded.
- I also believe that without grouping symbols, numbers are very difficult to read. If we can't agree to mix commas and spaces, we should only use spaces and forget about commas. --Gerry Ashton (talk) 21:26, 15 December 2007 (UTC)
- Your second point sounds practical enough. I think it is important to avoid long unbroken lists of digits after the point. I see nothing wrong with mixing commas and spaces, if that's what it takes. Thunderbird2 (talk) 21:53, 15 December 2007 (UTC)
- Advocating that Wikipedia abolish the use of commas to delimit digits in the mantissa would be about as successful as the BIPM trying to abolish the hour, ppm, and percent because they aren’t “part of the SI”: ‘p*ssing in the wind’. We will make better progress if we can focus our efforts on the proper treatment of digits to the right of the decimal point. Greg L (my talk) 00:49, 16 December 2007 (UTC)
Specific proposal
- I would like to weigh in on this issue with this proposal: The overriding principal of the SI with regard to technical writing and general written communications is to unambiguously and easily communicate in a language-independent fashion using internationally and well-recognized units, symbols, and style. For instance, even though percent and its symbol (%) are not formally part of the SI, it is recognized by the BIPM and ISO for use with the SI because it is widely recognized and simplifies communications.
There are currently two practices for delimiting numbers in the mantissa: spaces, and commas. It’s currently a free-for-all in the decimal place and only two practices are observed: 1) delimiting with a space, or 2) no delimiting whatsoever. Clearly, long chains of decimals in a row are extremely hard to parse and demand to be delimited. Trying to get all contributors to provide spaces in the decimal portion of numbers would be difficult but I would hope that official Wikipedia policy would be that the preferred method of numeric notation to the right of the decimal place is to delimit every three digits with non-breaking spaces {exceptions would be 1) where the last group consists of four digits and 2) where a group of five digits is delimited so the last group comprises two digits}. Further, I would propose that Wikipeida would recognize that the best practice is to permit the use of reduced-size non-breaking spaces (i.e. <font size="-1"> </font>), which is an SI-compliant form that observes best typography practices. Examples:
Best typography practices:
3.141 592 6535 and 1,579,800.762 04
Acceptable delimiting:
3.141 592 6535 and 1,579,800.762 04
Further of course, the Euro practice of delimiting the mantissa with non-breaking spaces (preferably reduced-size ones) would also be acceptable.
Clearly, my proposal also holds that practices like “1.414213562373095” should be strongly discouraged or prohibited.
- I would like to weigh in on this issue with this proposal: The overriding principal of the SI with regard to technical writing and general written communications is to unambiguously and easily communicate in a language-independent fashion using internationally and well-recognized units, symbols, and style. For instance, even though percent and its symbol (%) are not formally part of the SI, it is recognized by the BIPM and ISO for use with the SI because it is widely recognized and simplifies communications.
- A minor objection: if someone cuts and pastes a number from Wikipedia (the normal article view, not the view seen when editing an article) to some computer program, there is a small chance the program will parse it properly if it use just commas or just spaces. If it has a mix, the chance of success goes from small to no chance at all. But people probably don't do that often enough to worry about it. --Gerry Ashton (talk) 22:18, 15 December 2007 (UTC)
- Well that was an interesting point Gerry, so I checked it out and you’re right at all levels IMO. And as you further seemed to suggest, that’s not a deal breaker preventing consideration of the above proposal. “Chance” shouldn’t factor heavily into this consideration; effectively the only applications that could be impacted under this proposal are those that must “understand” numeric values. Today, that means Excel in the majority of cases. I entered the following values here in edit view, did a Show preview, and copied and pasted the following into Excel:
1,579,800
1,579,800.762045
1,579,800.762 045
1 579 800
1 579 800.762
1 579 800.762 045
1 579 800.762045
All the spaces are narrow, non-breaking ones coded as <font size="-1"> </font>. Excel only treats the top two entries as numeric values. To see for yourself, just copy all seven entries, select a single cell in Excel, paste, and set up the adjacent column to multiply the pasted values by 2. Excel reports #VALUE! for the bottom five; Excel doesn’t care whether the spaces are regular, full-size spaces or these narrow, non-breaking ones. As you can see though, all the entries using Euro-style delimiting (spaces) in the mantissa (the bottom four entries) already aren’t compatible with Excel.
I think it is clear that the readability benefits of delimiting to the right of the decimal point far outweighs this minor inconvenience. I’ve long edited all my articles this way and have had many occasions to copy the values to Excel. It’s easy enough to hand-delete the spaces after pasting; this paste/edit method best ensures accuracy. Too, I agree with your final conclusion: “people probably don't do that often enough to worry about it.” Note further that the only entries above that would become non-compliant under my proposal are the second one down and the last one (as well as this abomination: 1.414213562373095). Greg L (my talk) 00:27, 16 December 2007 (UTC)
- Well that was an interesting point Gerry, so I checked it out and you’re right at all levels IMO. And as you further seemed to suggest, that’s not a deal breaker preventing consideration of the above proposal. “Chance” shouldn’t factor heavily into this consideration; effectively the only applications that could be impacted under this proposal are those that must “understand” numeric values. Today, that means Excel in the majority of cases. I entered the following values here in edit view, did a Show preview, and copied and pasted the following into Excel: