This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 120 | ← | Archive 124 | Archive 125 | Archive 126 | Archive 127 | Archive 128 | → | Archive 130 |
A few weeks ago there was extensive discussion on FAC talk about the vast size, complexity and instability of the Manual of Style. On reviewing the text of the MoS, I agree that the Manual is much larger than necessary to cover the areas it does: about 20 thousand words. In particular:
As a service to featured-content nominators and reviewers, and editors at larger, I've created a new, user-friendly version of the MoS that is only 40% of the size of the full version. There are no intended changes in substantive meaning. The new version has the following features:
Any changes to the full MoS as reflected in the new version will be notified, at the start of each month. Your feedback is welcome on the talk page. Tony (talk) 03:04, 16 September 2009 (UTC)
This section has been moved to Wikipedia_talk:Manual_of_Style_(dates_and_numbers)/Datestempprotectedsection, as this page is more relevant to the request. |
Jc3s5h, your edits were contrary to the results of the RfC you yourself conducted here on Archive 123. The {val} template was the result of very lenghty, months-long discussions by very many editors on both WT:MOS and WT:MOSNUM.
{Val} (originally known as “Delimitnum”) had its functionality described here in WT:MOSNUM Archive 94…
…it was extensively discussed and voted upon here in WT:MOSNUM Archive 94…
…and was well received here on WT:MOS Archive 97…
…where its functionality was tweaked to achieve a compromise solution that made everyone happy on an issue regarding the look of scientific notation.
Then a number of developers and template authors worked on it.
Please don’t presume that you can come along and change it without a proper consensus. Greg L ( talk) 17:17, 18 August 2009 (UTC)
This practice of “your way / my way… it’s all just six of one / half a dozen of the other” doesn’t apply to numbers. Why? Wikipedia has gone through all this before many times, and new editors who come here don’t have the benefit of all that history and discussion. But it comes down to this: English-speaking Europeans are familiar and comfortable with a many different ways of delimiting numbers and the American style causes them no confusion whatsoever. Comma-delimiting might not be the most common practice for English-speaking Europeans, but they recognize what it means and fully understand the numbers. However, Americans are familiar with one and only one method; as a group, they have had no exposure whatsoever to other ways of delimiting numbers. So, especially for general-interest articles, in order to cause the least confusion, the American method of using commas to the left of the decimal point is to be used on Wikipedia. Scientific articles; particularly ones directed to a professional readership, are the only exception.
The argument that “Well, Wikipedia will just start using the Euro/BIPM method and dumb-ass Americans will simply learn” just doesn’t fly and it never will. Wikipedia doesn’t have that kind of influence; all that sort of attitude does is produce confusion. Our aborted attempt to push the world into the adoption of the IEC prefixes (kibibytes and KiB) amply demonstrated that. After three long years, the practice was no more well adopted throughout the world than before. All Wikipedia accomplished by letting itself by hijacked by a handful of editors who wanted to push the world into a new and brighter future with warp drive and membership in the United Federation of Planets™®© was to make our computer-related articles needlessly confusing. We follow the way the world works and can not presume to lead by example.
We can’t have MOSNUM subtly edited in a fashion that tacitly allows numbers in articles, other than science-related ones, to be delimited with thinspaces in place of commas to the left of the decimal point; it is unnecessarily confusing to too many readers. This is the way it has long been done and there has been no decision to change the practice.
As for delimiting with gaps to the right of the decimal point using {val} on high-precision numbers, particularly in engineering and scientific-related contexts where the distinction between numbers is important and the values actually have to be parsed and understood, that confuses absolutely no one—even “sheltered Americans”. A value like 1.6162523625×10−35 meters is no more confusing than the decidedly non-SI-compliant, five-digit delimiting used for mathematical constants (particularly in tables of constants), such as 3.141592653589793238462643383279...; everyone instantly “gets” it. It is a much-appreciated and much-needed touch that makes long strings of digits much easier to parse. Moreover, its technique of using thinspaces to the right is the only possible method that could be employed to solve the problem of long strings without upsetting the apple cart; it was either do nothing (and have absurdly long strings that can’t easily be parsed) or utilize the only logical available technique. Greg L ( talk) 18:28, 18 August 2009 (UTC)
(unindent) When Pmanderson asks whether the present use of may be, I surmise he is asking about this section:
- Numbers with more than four digits to the right of the decimal point, particularly those in engineering and science where distinctions between different values are important, may be separated (delimited) into groups using the {{ val}} template, which uses character-positioning techniques rather than distinct characters to form groups. Per ISO convention (observed by the NIST and the BIPM), it is customary to not leave a single digit at the end, thus the last group comprises two, three, or four digits. Accordingly, the recommended progression on Wikipedia is as follows: 1.123, 1.1234, 1.12345, 1.123456, 1.1234567, 1.12345678, 1.123456789, etc. Note that {{val}} handles these grouping details automatically; e.g.
{{val|1.1234567}}
generates 1.1234567 (with a four-digit group at the end). The {{val}} template can parse no more than a total of 15 significant digits in the significand. For significands longer than this, editors should delimit high-precision values using the {{ gaps}} template; e.g.{{gaps|1.234|567|890|123|45}}
→ 1.2345678901234567.
Let us set aside my objection to the 4046.8564224 format for the moment; whether my interpretation or Greg L's interpretation of consensus prevails will become apparent in due course. The present version of the guideline states, or at least strongly implies, that the Val template conforms to "ISO convention (observed by the NIST and the BIPM)", but the template at present does not conform to the ISO convention. Furthermore, every example in this section has exactly one digit to the left of the decimal, so the non-conformance is concealed.
This is a falsehood. I don't think it has been pointed out until now, so it is an innocent falsehood. But over time, as the falsehood becomes better understood among editors of this guideline, it could ripen into a lie. -- Jc3s5h ( talk) 00:28, 19 August 2009 (UTC)
Per ISO convention (observed by the NIST and the BIPM), it is customary to not leave a single digit at the end, thus the last group comprises two, three, or four digits.
IMHO, the objective on Wikipedia should always, always be about writing in a way that is clearest and causes the least confusion. There are many distasteful practices that come with that philosophy, including using feet and inches and pounds in American-related articles like Boston Red Sox. Too often, editors want to do things a certain way because… well… editors simply like doing it that way and always have done it that way. It ends up being more about writing to please the Wikipedian rather than do what is best for the readership. Greg L ( talk) 04:35, 19 August 2009 (UTC)
To resolve the issue I offer a two part proposal:
Part 1: {{
Val}} is altered so that by default, it produces commas to the left and no separation to the right of the decimal point (customary American style). A parameter is added, BIPM=y or yes
which produces thin space separators on both sides of the decimal point.
Part 2: The "Delimiting (groups of digits)" be altered to read as follows:
- Numbers with five or more digits to the left of the decimal point; i.e. 10,000 or more, should be delimited (separated into groups so they can be easily parsed visually) using commas every three digits; e.g. 12,200 and 255,200 and 8,274,527 etc. Exception: articles containing numbers with five or more digits to the right of the decimal point, e.g. 3.141593 (as such articles should delimit numbers as for scientific articles—described below).
- Numbers with four digits to the left of the decimal point may be delimited with a comma; that is, there were 1250 head of cattle and there were 1,250 head of cattle are both acceptable. The same exception as for five digits to the left of the decimal point applies.
- Numbers are not delimited when they are part of mailing and shipping addresses, page numbers, and years with four or fewer digits. Years with five or more digits (e.g. 10,400 BC) shall use commas.
- In scientific articles, particularly those directed to an expert readership, numbers may be delimited with thin spaces using the {{ gaps}} template. Coding
{{gaps|8|274|527}}
produces 8274527 (note: the thin space character and its HTML entity,, do not render correctly on some browsers). Articles containing numbers with five or more digits to the left of the decimal point should delimit numbers with thin spaces.
- The style of delimiting numbers should be consistent throughout an article.
- Mathematical constants in math-oriented articles may be grouped into groups of five; e.g. 3.141592653589793238462643383279....
- Numbers with more than four digits to the right of the decimal point, particularly those in engineering and science where distinctions between different values are important, may be separated (delimited) into groups using the {{ val}} template, with the BIPM parameter set to "y" or "yes"; {{ val}} uses character-positioning techniques rather than distinct characters to form groups. Per ISO convention (observed by the NIST and the BIPM), it is customary to not leave a single digit at the end, thus the last group comprises two, three, or four digits. Accordingly, the recommended progression on Wikipedia is as follows: 1.123, 1.1234, 1.12345, 1.123456, 1.1234567, 1.12345678, 1.123456789, etc. Note that {{val}} handles these grouping details automatically; e.g.
{{val|1.1234567}}
generates 1.1234567 (with a four-digit group at the end). The {{val}} template can parse no more than a total of 15 significant digits in the significand. For significands longer than this, editors should delimit high-precision values using the {{ gaps}} template; e.g.{{gaps|1.234|567|890|123|45}}
→ 1.2345678901234567. Also note that when the BIPM parameter is omitted, {{ val}} does not conform to the ISO/NIST/BIPM format; instead it uses the customary American format of grouping digits to the left of the decimal with commas, and not grouping digits to the right of the decimal.
-- Jc3s5h ( talk) 03:01, 19 August 2009 (UTC)
P.S. I’ve been to England, Scotland, Wales, Ireland, Antigua, Moroco, Spain, Monaco, France, Italy, Austria, and Hungary—and Canada, if you can count that as not being part of the U.S. ;-). Notwithstanding that I am American, I do all my engineering in hard metric. Have you been to the U.S.A? If so, how long? Because, as an engineer, I can assure you I have keen insight into what causes confusion in Americans. The current practices of Wikipedia were no accident. Greg L ( talk) 03:42, 19 August 2009 (UTC)
As for the proposal, it's on the right track—but let me raise some issues. I think the current text is a bit cumbersome, in that it has a lot of exceptions and places where the text diverges into subcases. I think we can state the exceptions a little more clearly, and make them general in application.
There's also the question of whether to treat the U.S. and BIPM delimiting schemes as similarly-acceptable, or not. I don't buy the idea that Americans don't understand the BIPM format—any literate English speaker ought to be able to figure out the meaning of either the U.S. customary or BIPM formats (or for that matter the meaning of an undelimited number), with minimal effort. (And for subsequent occurances, zero effort.) It's not a significant issue of understanding at all—it is straightforwardly stylistic. And given that an English-speaking Canadian or European would probably default to the BIPM format, and would certainly understand it, it's not appropriate to direct those users to use an unfamiliar method despite the conventions of English-language style that are typically employed in their regions. (It's the same can of worms as telling them to spell it color instead of colour, or vice versa.)
It also follows that there needs to be an exception for special regional contexts that would be unintelligible to the majority of English speakers, but which are still in widespread use. (This particular exception could use further discussion, and might be relevant in so few cases as to be omitted, but I'll suggest something below anyway.) For example: English is a second language of hundreds of millions of Indians, Pakistanis and Bangladeshis, and they often use the Indian numbering system when communicating in English. For articles specifically about an Indian topic, if we're to be faithful to the idea of avoiding regional bias, we have to acknowledge that their method is widespread enough to consider in the MOS.
There's also the matter of splitting the technical details out into their own subsection. I think things were getting a bit convoluted with the mixing of implementation details with stylistic concerns, so I think that we should separate them from the main text.
So with that in mind, I've spliced portions of the various versions of this section (by Greg L, Jc3s5h and myself) together, and come up with this:
===Digit grouping===
- In numbers with many digits, digit grouping symbols (inserted at intervals from the decimal point) are used to subdivide the number into easily readable groups. The acceptable digit grouping schemes are:
- Commas every three digits to the left of the decimal point, and thin, non-breaking spaces every three digits to the right of the decimal point (e.g. 8,274,527 or 0.12345). This is traditional usage in many English-language contexts, and recommended by the U.S. Government Printing Office.
- Thin, non-breaking spaces every three digits (e.g. 8274527 or 0.12345). This format is suggested in BIPM and NIST style guides for scientific and engineering works, and is in common use in interlanguage contexts.
- Mathematical constants in math-oriented articles may be grouped into groups of five digits on both sides of the decimal point; e.g. 3.141592653589793238462643383279....
- Other traditional digit grouping schemes, when relevant to the subject matter of the article; e.g. 82,74,527 in the Indian numbering system. (An explanation of the digit grouping scheme should be provided, typically by way of a link or brief summary. Also or instead, parenthetical conversions to another acceptable scheme may be used.)
- The style of grouping digits within numbers should be consistent throughout an article.
- When grouping digits by threes, and a number has exactly four digits on any side of the decimal separator, those digits may optionally be expressed as a group of four instead of three; e.g. both 9876 and 9,876 are acceptable.
- Digits are not grouped when they are part of addresses, page numbers, and years with four or fewer digits. However, years with five or more digits (e.g. 10,400 BC) are delimited as any other large number.
====Technical implementation====
The {{ gaps}} template uses CSS to output thin spaces (using the syntax
{{gaps|8|274|527}}
). Using HTML entities for this purpose (e.g.or
) may cause rendering problems in some browsers, and should be avoided when practical.
The {{ val}} template handles digit grouping automatically, in the American style (by default) or in the BIPM style (by using the
BIPM=y
parameter). In both cases, CSS is used to output the thin spaces. For example,{{val|1.1234567}}
generates 1.1234567 (with a four-digit group at the end). The {{val}} template can parse no more than a total of 15 significant digits in the significand. For significands longer than this, editors should manually delimit values using the {{ gaps}} template; e.g.{{gaps|1.234|567|890|123|45}}
→ 1.2345678901234567.
(unindent) As one of the guys who take care of the {{
val}} template, the sensible solution as far as the template is concerned is to leave the default behavior of {{
val}} as-is, because otherwise you will screw up a million articles and remove the ease of using {{
val}} in >90% of cases. Then for all those who hate gaps, or hate commas, two parameters can be added, |gaps=no (producing 1,232,345.0023234) and |commas=no (producing 1232345.0023234). You can then write exactly what you want, and you'll have the choice of picking whichever format is best suited for the article.
Headbomb {
ταλκ
κοντριβς –
WP Physics}
15:18, 19 August 2009 (UTC)
|gaps=no
and |commas=no
where appropriate.I'll go along with TheFeds proposal, once one technical issue is ironed out. This bullet:
is not compatible with the example 1.1234567 because the example has exactly seven digits to the right of the decimal, not four.
Also, the style implemented by {{ Val}} should really be called the GPO (Government Printing Office) style, because the prevalent American style is to not group digits to the right of the decimal point. (The Chicago Manual of Style is one publicaton that advocates no separation to the right of the decimal outside the realm of science and technology). -- Jc3s5h ( talk) 22:36, 20 August 2009 (UTC)
The current guideline reads, in part, as follows:
“ | Numbers with more than four digits to the right of the decimal point, particularly those in engineering and science where distinctions between different values are important… | ” |
===Digit grouping===
- In numbers with many digits, digit grouping symbols (inserted at intervals from the decimal point) are used to subdivide the number into easily readable groups. The acceptable digit grouping schemes are:
- Commas every three digits
to the left ofbefore the decimal point, andthin, non-breaking spaces every three digitsno delimitingto the right ofafter the decimal point (e.g. 8,274,527 or0.123450.12345). This is traditional usage in many English-language contexts, and recommended bythe U.S. Government Printing OfficeThe Chicago Manual of Style and the AP Stylebook for non-technical articles.- As above, but with thin, non-breaking spaces every three digits after the point (0.12345). This is recommended by by the United States Government Printing Office.
- Usually there is no difference between the two styles above, because non-technical articles should avoid using excessively precise values: see the second point in § Large numbers, below.
- Thin, non-breaking spaces every three digits (e.g. 8274527 or 0.12345). This format is suggested in BIPM and NIST style guides
for scientific and engineering works, and is in common use inand is in common use in scientific and engineering works and interlanguage contexts.
- In some major English-speaking countries, this format is unfamiliar most persons without advanced scientific or engineering education, so avoid using it when discussing general-interest topics.
- Mathematical constants in mathematics-oriented articles may be grouped into groups of five digits on both sides of the decimal point; e.g. 3.141592653589793238462643383279....
- Other traditional digit grouping schemes, when relevant to the subject matter of the article; e.g. 82,74,527 in the Indian numbering system. (An explanation of the digit grouping scheme should be provided, typically by way of a link or brief summary. Also or instead, parenthetical conversions to another acceptable scheme may be used.)
- The style of grouping digits within numbers should be consistent throughout an article.
- When grouping digits by threes, and a number has exactly four digits on
anyeither side of the decimal separator, those digits may optionally be expressed as a group of four instead of three; e.g. both 9876 and 9,876 are acceptable. Additionally, after the decimal point a final group of four digits can be grouped together, e.g. 0.1234567 or 0.1234567. The latter style is more common, and is recommended on Wikipedia.- Digits are not grouped when they are part of addresses, page numbers, and years with four or fewer digits. However, years with five or more digits (e.g.
10,400 BC10,000 BC) are delimited as any other large number.====Technical implementation====
The {{ gaps}} template uses CSS to output thin spaces (using the syntax
{{gaps|8|274|527}}
). Using the thin space character or its HTML entities for this purpose (e.g.or
) may cause rendering problems in some browsers, and should be avoided when practical.
The {{ val}} template handles digit grouping
automatically, in the American style (by default) or in the BIPM style (by using thein the U.S. GPO style automatically.BIPM=y
parameter)In both cases,CSS is used to output the thin spaces. For example,{{val|1.1234567}}
generates 1.1234567 (with a four-digit group at the end). The {{val}} template can parse no more than a total of 15 significant digits in the significand. For significands longer than this, editors should manually delimit values using the {{ gaps}} template; e.g.{{gaps|1.234|567|890|123|456}}
→ 1.234567890123456.
Differences from TheFeds' version are marked. -- ___A. di M. 11:15, 21 August 2009 (UTC)
The practice of grouping digits in this way is a matter of choice; it is not always followed in certain specialized applications such as engineering drawings, financial statements, and scripts to be read by a computer.
I’ve made this point numerous times, above, and the best counter-argument I’ve yet to see is a demand to see scientific proof or studies showing that alternative numbering formats would be confusing to Americans. Commons sense does not need to be legislated. This is hopeless. This is simply nothing more than an attempt by some Europeans, who are absolutely convinced that their BIPM-endorsed, European way is superior (perhaps it is) and should be adopted here on Wikipedia and dumb ol’ Americans will learn it here, if nowhere else. These editors need to drop this agenda to change what has long worked here. Wikipedia is not to be exploited as a vehicle to promote change by educating Americans to conventions with which they are entirely unfamiliar. The current guidelines are fine.
And, a final note: Just because something is endorsed by the BIPM doesn’t mean it enjoys world-wide adoption. The BIPM wants 75% written 75 %, but Americans (and as far as I know, no one else) don’t do it that way so Wikipedia goes with the flow and ignores the BIPM so we don’t confuse people for God’s sake. Greg L ( talk) 23:35, 21 August 2009 (UTC)
As someone who has lived in France for many years, I am familiar with that convention. It appeared bizarre to me when I first arrived there. Now it is pointed out that this is also adopted in some scientific contexts. Before this is imposed on the unwitting WP public, I would point out that it is a convention I have never seen before in the Anglo-Saxon world. Being able to understand it is one thing, but to insist that this professional technical standard be adopted in any form in a general knowledge encyclopaedia is quite another. - BTW, the French also use the comma in place of the period as the decimal delimiter. Even if we were not to adopt this last 'quirk', it is unlikely to find widespread acceptance. Implementation is likely to meet with bewilderment, and be universally reverted to the comma delimiter which all English-speakers are familiar with. Ohconfucius ( talk) 06:37, 22 August 2009 (UTC)
To consider an analgous case, an American reading about a boot and a bonnet might picture articles of clothing, rather than car parts—yet we would not expect articles to generally defer to the American's preferred vocabulary, even though Britons are somewhat accustomed to American vocabulary (e.g. because of the pervasiveness of American culture and media in Britain, vs. the opposite), and would grudgingly understand "trunk" or "hood" in the context of an automobile. In fact, with numbers, at least there's a contextual clue to the meaning—the numerals are the same, after all. With "boot" vs. "trunk", we have to resort to things like linking the first occurrance, to avoid misunderstandings; the case of dialect is more, not less confusing than numbering style. Yet despite that slight inconvenience, the well-established principle is to accept such regional eccentricities as part of the language, and accomodate them in the interest of avoiding the imposition of one region's style over another. Just because the Swedes often understand either format—to recall Greg's example—does not mean that their preference ought to be be moot.
And let me just point out that I was not the one who demanded a study or scientific proof of the alleged incapacity of Americans to use other formats—I simply expressed my doubt. My common sense appraisal doesn't agree with Greg's, and I suspect that when it's nothing but assertions of common sense on either side, there's nothing in particular to refute. (And of course, repeating something doesn't make it true; neither argument is any stronger upon retelling.)
I've also got to take issue with the idea that Europeanization is the motive. ("This is simply nothing more than an attempt by some Europeans, who are absolutely convinced that their BIPM-endorsed, European way is superior (perhaps it is) and should be adopted here on Wikipedia and dumb ol’ Americans will learn it here, if nowhere else.") I doubt that it was an intentional strawman, but for the sake of keeping this discussion on track, let's drop the idea that there's any effort to force-feed Americans with foreign concepts, because there's no evidence that any editors presently commenting on this matter are attempting to engage in any such scheme.
To me, the convention used by the BIPM is a necessary inclusion in the MOS because it is the dominant English-lanugage usage in some regions—not just in science or engineering, but in any English-language usage. That's the way things tend to work in Continental Europe (and maybe that's why this "Europeanization" allegation arose), where several states and languages have their own incompatible digit grouping schemes, and where English is the de facto language of international commerce and collaboration. There is no ulterior motive: it's simply an acknowledgment of European English style. Consider the European Commission English Style Guide, which calls for BIPM-style digit grouping. That guide is "intended primarily for English-language authors and translators" and "serve[s] a wider readership as well" (speaking in terms of the EC and of EU institutions)
The fact that things like scientific journals and engineering handbooks have also adopted the BIPM convention is a secondary component of the issue—when we say "in common use in scientific and engineering works", that's just an acknowledgment that scientific usage of this convention is worldwide, versus the regional adoption of the convention for general use. If we wanted to capture that reasoning in detail, we could say that BIPM style is limited to topics in the fields of science and engineering, plus topics dealing with Continental Europe and other regions that enjoy significant adoption of that style.
But what's the point of being needlessly precise? It's much simpler to acknowledge that both the U.S. and the BIPM convention are in general use in large regions of the world, and each preferred by major fields of study (as evidenced by style manuals). On balance, the MOS is clearer by just allowing either one (though calling for consistency within an article), without complicating the issue with topic-related stipulations (and the consequent discussion of what belongs to which topic, or what dominates in which region). This is easier to understand, and easier to enforce—that's a useful thing, given the level of complexity of the MOS and Wikipedia policy in general. TheFeds 19:46, 22 August 2009 (UTC)
Frankly, your arguments that we should follow whatever the BIPM says the world ought to do comes right out of the four-year-old playbook used by proponents of the IEC prefixes (see the B0– B16 archives, above). That whole stink (seventeen entire archives dedicated exclusively to that one fiasco) was because a small handful of editors banded together and decided to start using terms like “256 kibibyte (KiB)” instead of the “256 kilobyte (KB)” used by computer manufacturers and computer magazines throughout the rest of the planet. Then one of those editors ran around and changed hundreds of articles over a period of a few weeks and the group blocked anyone from reverting all those edits, citing “lack of consensus”. That this could have occurred that way, that such stupidity lasted for three years, and that it took three months of bickering to put an end to it speaks volumes to how broken MOSNUM can be at times. And all because it was a proposal by some vaunted standards organization. The end result(?): needles confusion in readers who had the misfortune for three long years to come here and read many of our computer articles. I’m sure there were a number of people read up on computers here on Wikipedia and then went into computer stores where they announced they were looking for a computer with “512 mebibytes of RAM.” They were no-doubt met with blank looks (at best) or snickers.
Quoting you again: To me, the convention used by the BIPM is a necessary inclusion in the MOS because it is the dominant English-lanugage usage in some regions. Yeah, I got that much. I figured that bit out in the first four seconds after seeing what you were trying to do. And, as I’ve explained, it unfortunately isn’t a two-way street. There are many ways the Europeans format numbers. In Sweden, the “Swedish1” technique (there’s yet another) is to write the population of America as “285.865.855” so why don’t we just go ahead and let articles here use that system too(?), right along with the BIPM method (which Swedish school children are also taught)? That’s a rhetorical question, please don’t answer it. The answer is because Swedish school children are also taught to recognize the American-style of delimiting numbers. In fact, Europeans by and large are not in the least bit confused when they encounter numbers with American-style delimiting. The trouble is that American’s know of only one way; they’ve been taught no other. Your argument that Americans’ confusion will be short-lived because *Wikipedia* will just teach them using an “oh… didn’t-cha know?”-fashion (and only the galactically clueless and retarded will be left in the dust) is wholly uncompelling.
With regard to how numbers are written here on Wikipedia, it doesn’t matter in the least what the proposal is or who proposed it. When the American style of delimiting numbers is no longer the dominant numbering format universally recognized throughout the English-speaking world, and when Americans have as much familiarity with alternative numbering styles (like “Swedish1” and “BIPM”) as Europeans do with the American style, then Wikipedia can change over. Wikipedia follows the way the world works and never, ever tries to promote change in the way the world works by presuming we can somehow lead by example. Wikipedia wisely decided to use American-style delimiting in our numbers so there is minimal confusion. Greg L ( talk) 21:50, 22 August 2009 (UTC)
Let me stress that there is no implication of "teach[ing] them using an “oh… didn’t-cha know?”-fashion". Readers are free to assume that the formatting was a stylistic error, rather than another valid convention, and be none the wiser. The content of the article still gets across. (In other words, I am absolutely not advocating some sort of patronizing policy that would educate the savages of the world about Europe's genteel ways.)
My concern here that by mandating a convention that represents the preference of a subset of English speakers, we would imply that other accepted English-language usage is inappropriate. It would be like saying "because the British spelling of words like 'harbour' is recognized throughout the world"—despite the American spelling "harbor"—"this spelling convention is mandatory (unless quoting a source or explaining foreign usage)". Wikipedia has not gone this route, instead permitting either form.
Regarding your Swedish example, I assume that Swedish-1 and Swedish-2 are used in Swedish-language works? This being the English Wikipedia, one would expect them to use the style that is typically used in their region for writing in English. (Which is most probably the BIPM style.) If the Swedes don't use their native styles when writing in English, then there's no need to deal with them here.
When you say with certainty that "Wikipedia follows the way the world works and never, ever tries to promote change" by example, I think you're misinterpreting what's going on here. Maybe during the binary prefix debate, some editors advanced the idea of promoting IEC usage to the world. Nobody's said anything of the sort here. Furthermore, we usually follow bits and pieces of what influential parts of the world do, but only because consensus among editors often ends up settling upon that course of action. Sometimes that means following or ignoring a particular standard or widespread convention, but the key is that Wikipedia does what the editors agree upon. It's coincidence rather than design that consensus usually settles upon permitting what's popular in the world.
Lastly: you're definitely mischaracterizing my motives. I'm not waging some promotional campaign that serves to advance the interests of the BIPM, or Europe, or any other entity. Specifically, despite your assertion above, I have not stated or implied that "we should follow whatever the BIPM says the world ought to do". (I have previously stated that I tend to use the BIPM style in my outside work—which is immaterial to your allegation.) TheFeds 00:18, 23 August 2009 (UTC)
{{smiling, very amused emoticon}}
. Perhaps you aren’t. But it seems you are mightily crossing your fingers that mixing things up here and allowing editors to use different types of numbering formatting if they feel like it won’t cause needless confusion with our readership. Better cross two fingers.I’m an American engineer. I do all my design in hard metric. In fact, only a half hour ago, I was busy calibrating a celsius-only thermostat that I’m going to retrofit into my otherwise-gaugeless, Italian-made Rancilio espresso maker. The boiling point of distilled water was 97.8 °C at that moment (barometric pressure) at my altitude (about three meters above the sewer cover outside my house). I’m also installing a pressure gauge calibrated only in bar. I am as “BIPM” as they come for an American. However, as an engineer who has done far more than his share of technical writing (owners manuals, white papers, etc.), I am fully aware of what Americans know and don’t know technically. I am also keenly aware of how utterly stupid it is to needlessly confuse readers.
Here’s how to speed America’s adoption of all-things-BIPM (e.g., their SI (metric) system, their numbering system, etcetera): Just run for elected office while promising that if America adopts BIPM into their way of life, they’ll loose weight while they sleep and their taxes will go down due to less government waste. You’ll get into office. Moreover, you’d stay there; all you’d have to do is repeat the promise each election cycle; they’ll buy into your promise each time.
America is big and homogenous; a drive that would take you clean across the whole of Luxemburg won’t even get you across Harris County, Texas. This is a source of strength and weakness. For one thing, we can drive across Harris County and not require a pocket-full of plug adapters to plug our iPhones into the outlets in the next county (or state for that matter). We could design a big-ass airplane in the late 60s and not get all confused because Californians can’t speak French whereas Oregonians right next door can’t speak German. But this homogeneity also means that Americans would be surprised to get into an elevator on the ground floor and see that they are at floor “0”.
Indeed, Americans are certainly not as “genteel” and worldly as Europeans (that’s a friend of the guy who owns a tool & die shop I frequent); there’s this big-ass pond that shelters us from being exposed to other languages and other ways of doing things. Therefore, it’s a damned-seldom American indeed who is fluent in two or more languages and easily recognizes two—even three—ways that numbers can be delimited. Europeans “get” “285,564,125” in a nanosecond. The typical American would be needlessly confused by “285564125”. So, you Europeans have a leg up on Americans when it comes to understanding other cultures and practices.
Please take note of the following three expressions. The first is “A civilized man can convincingly imitate a barbarian, but a barbarian can not convincingly imitate a civilized man.” The second is “Never try to teach a pig to sing; you only waste your time and annoy the pig.” The third is “The goal of all technical writing is communicate with minimal confusion.” What you are proposing handily ignores all three. Greg L ( talk) 03:52, 23 August 2009 (UTC)
Those English-speaking Europeans who want to come to en.Wikipedia can, while they learn about the subject matter in our articles and brush up on their English-language skills, also get even more comfortable with the accompanying number delimiting technique whereby native speakers of English (U.K., America, Australia, and aothers) use commas to the left of the decimal point.
That is all part of the “experience” for many visitors to en.Wikipedia for whom English is their second language: immersing themselves in the culture, including such nuances as idioms. That approach is much more realistic (when in Rome, do as the Romans do) than assuming that Wikipedia can somehow change the way the English-speaking world works.
While it might be *pretty* to think that we wouldn’t be creating unnecessary confusion in our readership by using a wholly unfamiliar number formatting technique here, such a notion doesn’t seem grounded in reality. Nor is such a confusing change in the least bit necessary.
TheFeds, I ask you to drop the stick and back away from the horse carcass. This issue has been flogged to death and your persistence is becoming tedious. There is clearly not the remotest chance that a consensus might form for adopting the BIPM method of delimiting numbers for use on en.Wikipedia or expanding its mixed use beyond the confines within which it is currently limited. Far from it; it seems the general consensus is to leave things the way they are. Greg L ( talk) 16:13, 26 August 2009 (UTC)
Also, despite prior implementation and positive discussion of a similarly-worded edit to the MOS, you reverted it, and prompted this discussion in the first place. You can't just handwave away a discussion that you caused. How can you assert that "it seems the general consensus is to leave things the way they are", when the discussion on this point has largely been limited to you and I? If anything, the previous discussion about the MOS changes was more representative of consensus than our current conversation.
I'm receptive to your ideas, and have constructively disagreed, but you need to quit mis-stating my position regarding "chang[ing] the way the English-speaking world works" as fodder for your argument.
Given that the Romans use the BIPM convention (in English), why should they avoid using it when describing a Rome-related topic (in English)? As I stated previously, we have the option of writing a complicated regulation that takes into account WP:ENGVAR for articles dealing with regional issues that "belong" to places that recognize the BIPM style, and additionally acknowledges its prevalance in modern science and engineering. I think that my proposed language provides a less complicated policy statement with the same objectives, but it would essentially allow any user to choose to employ the BIPM style, even in new articles absent a topical or regional connection. That's a side effect, but given that that WP:ENGVAR cuts both ways (in that topics with a connection to a region that employs a non-BIPM convention could reasonably be changed to follow local style, even if the article style was initially BIPM), there's clearly nothing that would obstruct the ability of editors to choose an appropriate English-language convention for the article, or write neutrally when no regional or topical connection exists. TheFeds 17:55, 26 August 2009 (UTC)
You two’s change was to a long-standing guideline governing how something as fundamental as the formatting of our numbers are done on en.Wikipedia. It is utterly absurd to start mixing up our numbering style in an encyclopedia geared for our English-speaking readership. As A. di M. pointed out, WP:ENGVAR doesn’t and shouldn’t and can’t be applicable here. You are grasping at straws trying to make a case for what amounts to nothing more than “I like ta and wanna sanctify my practice in MOSNUM by changing MOSNUM.” Please stop. I couldn’t care less if some member of an African tribe that speaks using *!* tongue pops and counts in base-seven numbering system comes here because he or she also happens to know English as a second language. Those countries wherein English is the primary language delimit numbers to the left of the decimal point only with a comma. This practice is memorialized in the U.S. Government Printing Office Style Manual and is what is used here. So it doesn’t matter if the BIPM says it should be “75 %” and not “75%”, nor does it matter if the BIPM says it should be “a population of 285568654”. Why? Because in those countries where English is a primarily the first language, those two things aren’t done the BIPM way. It’s just that simple.
If we headed down the path you and Jc3s5h wanted, which amounts to “let editors use either commas or thinspaces to the left of the decimal point whenever they want if the article is sorta ‘techie’ ”, then Wikipedia would once again be repeating the fiasco of our now-aborted experiment with the use of the IEC prefixes, where some articles said “256 kilobytes (KB)” and still others said “256 kibibytes (KiB)”. Given that readers were entirely unfamiliar with the latter, this accomplished nothing more than to confuse readers. It’s interesting to note that the proponents of the IEC prefixes used exactly the same arguments you two are using: “They’ll figure it out from context and… and, the (totally conjectured and unproven) confusion will be short lived, and… and, a *standards organization* has proposed it, and… and, it solves an ambiguity or shortcoming of some sort, so our use here on Wikipedia is nothing but goodliness and will make us look all futuristic and smart.” Uhm… no. All it did was unnecessarily confuse our readership.
I appreciate your above candor. You’d like to see the use the Euro/BIPM method of delimiting numbers in an article on Rome, since—by your argument—Italian-speaking Romans who also speak English could visit the en.Wikipedia Rome article and feel all warm and fuzzy about seeing the BIPM method of number-delimiting here too. Except your argument falls somewhat flat because in Italy (at least it.Wikipedia), they format numbers like this: “Con i suoi 2.726.539 abitanti distribuiti su una superficie di 1.285 km², è il più popoloso e più esteso d'Italia.” A. di M. will no-doubt be able to flesh in some detail on this. But I have every faith that Italians recognize the method of delimiting seen on it.Wikipedia, and the BIPM method, and the English-speaking method.
I will no longer waste my time arguing this point with you, TheFeds. Count how many editors, above, support what you are proposing. Do you see a consensus for what you desire? Or do you just hope that by not dropping the stick that we will all just come around? I’m going to leave this to Tony, A. di M., and Ohconfucius for a while. Don’t count my absence from this discussion as acquiescence; I simply tired of arguing with you.
Frankly, if I had my way, the use of gap-delimited numbers to the left of the decimal point would be limited strictly to when text is being quoted directly from a scientific paper. The practice has no place in an article like Moon, for text like “The Moon is 384403 km away from the Earth” and MOSNUM should clearly reflect that. Greg L ( talk) 20:57, 26 August 2009 (UTC)
If Wikipedia's policy was to always employ the most popular variety of English uniformly, perhaps it would minimize confusion. And then it might logically follow that the most popular numbering scheme should always be employed as well (despite regional eccentricities). But that's certainly not the way most similar cases were decided, and the policy guidelines reinforce the idea that regional preferences matter.
Greg, I think you missed the point of the Roman example: this is about English-language usage, not Italian-language usage (as I clearly specified). I'll of course defer to A. di M.'s presumed experience with Romans, but in my experience, Continental Europeans writing formal English prose will employ the BIPM style, irrespective of the conventions used in their native language. (And with English being the dominant language for international communication in Europe, there's no shortage of usage.)
With regard to Greg's paragraph citing the IEC prefix dispute, I'm accused of using their arguments ("They’ll figure it out from context", "a *standards organization* has proposed it" and "it solves an ambiguity or shortcoming").
The first argument, as I noted earlier is logically equivalent to Greg's argument that many Americans will struggle to figure it out—both my assertion (that context will make most usage clear) and Greg's are conjecture, though both reasonably well founded. Absent actual evidence, you can't accept one and reject the other on a logical basis.
The second is a strawman, as I reminded Greg prior to his reiteration of it. It's immaterial that the BIPM is a standards organization, just as it's immaterial that the U.S. Government Printing Office authored a standard that encapsulates Greg's preference. Regional usage is at issue.
The third would be a fair point, if it weren't for the inflammatory corollary that Greg appended ("so our use here on Wikipedia is nothing but goodliness and will make us look all futuristic and smart"). Notwithstanding Greg's misrepresentation, it does address a shortcoming. As I noted above, Wikipedia could have solved the question of how to deal with variations in English usage by mandating a fixed house style (for numbers, spellings, synonyms, etc.)—but that was not adopted. Instead, consensus dictated that regional usage was permitted within an appropriate sphere of influence. MOSNUM ought to reflect the outcome of that high-level consensus. As I explained before, my proposal was more permissive than that—but the crux of the issue is that regional English-language styles are appropriate on the English Wikipedia. The additional permissiveness in my proposal reflects my belief that adoption of the BIPM style is sufficiently widespread that the effect of adding it on an equal footing with either of the comma-based styles would be essentially harmless. It's much the same as the difference between the two comma-based styles (listed at the top of A. di M.'s proposal)—readers will understand either one, even if they think one or the other is in error (because they have not been exposed to it).
That additional permissiveness also has the effect of simplifying the MOS regulation—but if that prospect is so abhorrent, the formulation that permits the BIPM style only when regionally or topically appropriate (e.g. Continental Europe, Canada—especially French Canada, science, engineering, etc.) would minimally satisfy the existing guidelines, and would be acceptable. TheFeds 23:21, 26 August 2009 (UTC)
The traditional way to delimit numbers in Italian in handwriting is a superscript dot; but since no-one knows where to get that character, it is approximated with either a period or an apostrophe ("10.000" or "10'000"); the former is more common in Italy and the latter is in Switzerland. Recently the BIPM way is becoming common too; I guesstimate that approx. 70% of stuff published in 2009 use periods and 30% use thin spaces. But I've seen that my cousin's elementary school textbook only mentions the thin space method. There are many Italians who are unfamiliar with the comma as a thousand separator and wouldn't realize that "40,125" can mean anything else than forty and one eighth, but those Italians don't understand English enough to read an encyclopaedia article in it, so I don't see the need to cater with them in the English wiki. As for "continental Europeans writing formal English prose will employ the BIPM style", that's true, but only because an Italian is more likely to write a scientific paper than a novel in English. (And as of 2009 there's no real ground to consider India an English-speaking country; it has fewer native English speakers than Germany, and a smaller percentage of people able to speak English than the whole world.) -- ___A. di M. 12:51, 27 August 2009 (UTC)
But there are still proposals on the table, and we have yet to see any conclusive resolution that approximates a consensus.
So my suggested resolution is as follows:
Please don’t confuse my apparent willingness to engage you on this issue and the relative silence from the others, as signaling that they are somehow in major agreement with you. The words of Tony and Ohconfucius, above, are short and sweet and seem to convey their sentiments clearly enough (unsupportive) as to what you propose. However, I would be exceedingly pleased if you would start an RFC so we can be done with this and I don’t have to periodically check back here, only to discover that you have again reprised this issue.
A consensus is not arrived at by seeing who harps the longest and mostest on a given subject. Nor does one get his or her way on Wikipedia by catching people sleeping, nor by changing the documentation on templates to convey something along the lines of “better not use this template because—boy—is it gonna change soon…” nor by changing templates without having had any real discussion beyond tag-teaming with one other editor where you both go “campy idea—cup of tea?” to each other.
Judging from the reception of me and several others, above, turning Wikipedia into a mix of numbering styles by greatly expanding the use of a number format that isn’t even used by those general-interest readers for whom English is their first language, has pretty much no chance of being adopted. And it shouldn’t, for it ignores the most basic fundamentals of Technical Writing 101. If you have to prove this through an RFC rather than examine the reception your proposal has received so far, by all means.
As for I'm willing to compromise… language, uhm… we all have to accept the consensus of the community—period; it doesn’t much matter what you are I are “willing to compromise” on.
Someone please e-mail me if this goes to an RfC. I don’t make it a practice to keep following TheFeds wherever he goes on Wikipedia with this idea of his. Greg L ( talk) 02:23, 4 September 2009 (UTC)
You might have noticed that while Tony and Ohconfucius both made short comments concerning portions of this discussion, you and I wrote at length—and my post addressed that conflict. You might also have noticed that I also excluded mention of Jc3s5h's comments in support, and did not state that A. di M. disagreed in part and agreed in part.
And when you list several ways in which "A consensus is not arrived at", are you making an accusation, or just introducing examples that are irrelevant? I've repeatedly warned you during the course of this discussion not to jump to inaccurate conclusions about my motivations, and now I feel that I need to warn you to avoid baseless accusations of things like "catching people sleeping" and screwing up template documentation, and to avoid flippantly misrepresenting legitimate discussion as “campy idea—cup of tea?”.
You said "uhm… we all have to accept the consensus of the community—period; it doesn’t much matter what you are I are 'willing to compromise' on"; but I don't see any basis for your objection. When we make proposals, we are free to discuss and make compromises among ourselves, in order to establish mutual support for a compromise proposal. (As an illustrative example, consider how a legislature generally works: mundane issues are discussed in committee, leading to one compromise bill, rather than by taking up-and-down votes on opposing ideologically extreme proposals.) Nothing of that process prevents a "consensus of the community" from existing. TheFeds 17:23, 4 September 2009 (UTC)
One sort of thing that has been the source of spectacular amounts of vitriol on Wikipedia (and the Wikipedia-equivalent of suicide bombers and Turkish butt-stabbings), has been the launching of RfCs by a lead advocate on one side of an issue. This resulted in RfCs that suffered from unconscious bias and were not respected by the other side. If you seriously think your proposal has a snowball’s chance of being accepted with a clear consensus (that’s a big “IF”), then the next step is an RfC. So the proper step, IMO, is to not launch an RfC, but to propose RfC wording, we all discuss the proposal and tweak it until everyone is clear on what is being proposed and how it would change things and are mutually satisfied the “package” wording is sufficiently neutral, and then we launch an RfC.
I have zero interest in starting all that. It’s time-consuming and, ultimately, a waste of time if it goes as I expect. I suggest you seek some assistance from Headbomb and Ryan Postlethwaite (I have no idea if they might be interested) since they both have experience in RfCs.
Perhaps, an even better course of action would be to privately contact an editor or two that you feel are relatively unbiased and whom you have a respect for their opinions. Just ask them if they think there is a fair chance of your succeeding at what you desire. I think that is much fairer given that your persistence at this means that everyone else has to *sigh* and start jumping through hoops once you start things rolling. Greg L ( talk) 18:43, 4 September 2009 (UTC)
As for asking around (less formally), they thought that it could plausibly be well-received elsewhere on Wikipedia, with the main concern being that other venues might not be interested enough in minutiae of style to comment constructively. They figured that it would be harmless enough to just ask, rather than attempting to predict the outcome.
So, we discussed what I had in mind, and through a couple of revisions, we pared the essential question down to something general ("On Wikipedia, should the selection of digit grouping styles depend upon regional and topical conventions used in the English language?"), with a neutrally-phrased explanation of context. The question is posed at WP:VPP, in the section Digit grouping style question (from WT:MOSNUM), and I'm placing notices on some other talk pages directing users to WP:VPP for comment. TheFeds 03:46, 9 September 2009 (UTC)
You clearly want your way, didn’t like what the others had to say, above, on this issue, and you now put us all in the position of having to chase you over to WP:VPP. No. I won’t chase you to some other venue as you hop-scotch across Wikipedia with this agenda to change MOSNUM. I even wrote above Someone please e-mail me if this goes to an RfC. I don’t make it a practice to keep following TheFeds wherever he goes on Wikipedia with this idea of his. Yet, you conveniently elected to not alert me to this “RfC” of yours; I had to do one of my periodic checks on this thread to see what you are up to. This sort of move deprives that RfC discussion from the input of the editors here who have already weighed in on this issue and are no longer paying attention to this thread nor following your every move. You can hop-scotch over to Jimbo’s page and pitch what you want there. But even he doesn’t determine what occurs here on WT:MOSNUM; he has an abiding respect that the “community consensus is always the right thing to do.”
Discussions of how to change WP:MOSNUM must occur here on WT:MOSNUM. Period. Please drop this. You don’t win by being persistent to the point of a fault. When you have a consensus here to change WP:MOSNUM, then WP:MOSNUM will be changed. If you just want to get input from a new group that has less day-to-day familiarity with the goings-on here on MOSNUM and this talk page, then, be my guest. There is nothing wrong with that. But, please don’t commit the colossal error of running off to some other forum, obtaining a result you find favorable with a new audience, and then start making your edits to MOSNUM. Pages have their associated talk pages for a reason and you might well find yourself sanctioned if you try to change MOSNUM as a result of venue-shopping. What occurs over on the Village Pump may be interesting to you, but it is not binding on the content of MOSNUM.
In the end, I think you are wasting your time. If you want to change MOSNUM, you must achieve a clear consensus here. Greg L ( talk) 18:38, 9 September 2009 (UTC)
First, with regard to alerting you: presumably you watch this page and visit often, given your numerous contributions to this talk page? I notified everyone of my action, right where one would expect to see it—in the discussion thread. (Only absent my not-so-stealthy post and link, might you have had a reasonable cause for concern.)
With regard to your concern about venue shopping, the discussion on WP:VPP is a simple and straightforward way to discuss one sticking point (among the many facets of the MOSNUM proposals), without attaching the trappings of our prior argument. The idea is to keep things on-topic, without having to saturate the discussion with refutations of alleged "Europeanization" or the like.
It is also completely proper to ask relevant questions elsewhere, when the discussion here is deadlocked without consensus or compromise. I shouldn't have to explain that that is not a substitute for the detailed proposals at MOSNUM. Rather, it is a way to inform our discussion with the opinions of interested and relevant contributors (who frequent the policy- and science-related forums rather than MOSNUM). Unsurprisingly, that that's exactly the point of the Village Pump. This can lead to a viable consensus on an issue of mutual interest to VPP and MOSNUM, but that consensus would obviously only deal with the specifics of the VPP question, rather than forcing the adoption of a MOSNUM proposal.
As for depriving others of input from this thread: no, I clearly linked to this thread, and advised readers that they could consult it for further information, or comment in it if desired.
The words "pointlessly bureaucratic" were not mine—that's why they're in quotation marks. But I do sympathize with the sentiment. (I think it's overkill to make endless proposals about the question to pose—would you find that discussion particularly enlightening, and do you really foresee anything but a deadlock there as well?)
If you object to the framing of the question, that's fair enough. I made a good faith effort to seek advice (per your suggestion) and work out a concise, neutral phrasing with an uninvolved party. You suggested having a round of discussion to decide the question for a formal RfC, but then stated that you had no interest in participating—you can't really have it both ways. TheFeds 04:34, 10 September 2009 (UTC)
Quoting you again: To me, the convention used by the BIPM is a necessary inclusion in the MOS because it is the dominant English-lanugage usage in some regions. Yeah, I got that much. I figured that bit out in the first four seconds after seeing what you were trying to do. MOSNUM and the editors who comprise it simply don’t care about how things are done “in some regions.” What matters is how things are done for the vast majority of readers for whom English is their first language. Italians, for instance, have their own Wikipedia and en.Wikipedia needn’t be unnecessarily muddling things up for those English-speaking Italians that choose to visit an article here. The whole point of technical writing is to communicate with minimal confusion.
Let’s touch upon why en.Wikipedia shouldn’t be kludged-up with multiple numbering systems in our general-interest articles in order to better accommodate readers for whom English is their second language. As I’ve previously explained, cross-Atlantic (or Pacific) recognition of alternative number-delimiting schemes unfortunately isn’t a two-way street. There are many ways the Europeans format numbers. In Sweden, the “Swedish1” technique (there’s yet another) is to write the population of America as “285.865.855” so why don’t we just go ahead and let articles here use that system too(?), right along with the BIPM method (which Swedish school children are also taught)? That’s a rhetorical question, please don’t answer it. The answer is because Swedish school children are also taught to recognize the American-style of delimiting numbers. In fact, Europeans by and large are not in the least bit confused when they encounter numbers with American-style delimiting. The trouble is that American’s know of only one way; they’ve been taught no other. That is why Wikipedia has long-used the most widely recognized method of delimiting numbers: it causes the least confusion (by far) over other methods that aren’t recognized by many English-speaking readers. The whole point of technical writing is to communicate with minimal confusion.
Quoting you: [Editors are given spelling freedom via] WP:ENGVAR, and choose instead to cater to one region's preferences. Wikipedia is written for an international, English-reading audience. That means that we need to accept that occasionally, a user may encounter a term or convention from elsewhere, and be briefly confused. But this is not a critical flaw… I see you don’t seem to mind (you don’t see it as a “critical flaw”) that readers might be “briefly confused” with multiple numbering systems. I do. And, why would we cause this confusion? So that editors from all walks of life (perhaps some editor from Africa who speaks in *!* tongue pops and also speaks English as his second language) can merrily write The population of Congo in year so ‘n’ so was 66020000 because he was the first major contributor. Given that Wikipedia is has an all-volunteer contributing authorship, allowing “lorry” in some articles and “semi-truck” in another is a reasonable and necessary compromise to address how editors in England spell differently from those in the U.S. and use different words—notably for nouns. Note however, that these are differences within the English language for those editors for whom English is their first language. It is patently absurd to think that an article on the Democratic Republic of the Congo is going to have a different numbering technique that is foreign to many native-English speakers because the first major contributor to the Congo article uses that numbering technique. WP:ENGVAR does not, should not, and can not apply here. Believe it or not, Wikipedia is not about us, the editors of Wikipedia; we write for our readership. The whole point of technical writing is to communicate with minimal confusion.
Even though you might not like to listen to others, please read comments from others, above, such as the words of Ohconfucius (04:13, 26 August 2009 (UTC) post), where he wrote The use of commas as delimiters is pretty much universal – the comma separator is not only American, it's Canadian, British, Australian, Irish, South African, Singaporean - which should take care of about 95% of the native English-speaking population. Things are done on the en.Wikipedia version of MOSNUM for a reason. Even if you don’t understand or agree with those reasons, you must accept the consensus view here. The whole point of technical writing is to communicate with minimal confusion. Is that sinking in yet? Your argument that “brief confusion” is “not a critical flaw” is bizarre and wholly uncompelling. Greg L ( talk) 23:00, 9 September 2009 (UTC)
Your invocation of the Italian Wikipedia seems to me like a fundamental misunderstanding—nobody is proposing using Italian-language style here. As I pointed out above—and you overlooked again—English-language usage is at issue. (Do the Swedes use Swedish dots in English? Probably not. BIPM with spaces? Probably.) And you're stating that English as a first language is the determining factor. That's not what "English-speaking" means. (I've already presented several counterexamples, like India.) If you mean to advance that as a proposition, then do so, but avoid presenting it as axiomatic.
When, in reference to things like "truck" and "lorry", you say "these are differences within the English language", you make a false distinction: consider digit grouping schemes mentioned in the European and American manuals of style—they are obviously both "within the English language". And that fact is not influenced by whether or not some editors have English as a first language, or otherwise.
You're also implying that Wikipedia 101 = Technical Writing 101. Unfortunately, you're wrong. In short, technical writing can often be geared to a specific and generally well-educated audience with easily-ascertained expectations. Wikipedia, because of its diversity of readers and contributors, has chosen (by way of guidelines and precedents) to use regional (or other) styles in some instances. If you disagree with that, it's incumbent upon you to raise that discussion at an appropriate level.
I will, however, grant that your opinions about minimal confusion are a convenient approximation, though not a well-formed universal solution to the issue of how to present text in a manner that is effective and appropriate. If "minimal confusion" was an obvious and infallible dictum, we wouldn't need to have discussions about much of the MoS. The fact that we disagree on certain points of style—just as others have disagreed before on other topics—is ample demonstration that your doctrine does not make conclusions about style self-evident.
So what of the "brief confusion"? Although we both know what a lorry is, you must concede that an American reader might not—he might be briefly confused, until he clicks the wikilink, or figures out from the picture of a truck what is being referred to. That is more confusing than number formatting (a wholly-unfamiliar word vs. groups of digits that might be read as a number), and yet, for good reason, it is permitted on Wikipedia, even in an article that has nothing to do with Britain, but which speaks of lorries in some other context. Minimal confusion would dictate that we prescribe the most common form among our readership—which would probably be "truck" in deference to the plurality of American readers of Wikipedia. Because this is an unacceptable simplification to many readers and editors alike, regional and topical conventions that enjoy wide English-language adoption should likewise be accorded latitude despite the potential to briefly confuse whatever other group might be slightly disadvantaged.
Furthermore, by exclusively requiring one region's style (even granting its greater adoption), you systematically disadvantage the significant set of English speakers who do not employ that convention in properly-constructed English-language usage. That can be construed as a bias, and has been the subject of many arguments. By having MoS guidelines that account for regional or topical conventions, we assure readers that they will receive an acceptable format for the subject of their inquiry, and for the editors, specify a reasonable link between the style and the content to minimize ambiguity. We therefore avoid controversy about why a British subject is described in American style. By extension, this implies that the most interested editors will have justification for employing the conventions that are most appropriate to their area of interest or expertise.
To extend that principle, for the articles that do not have well-defined regional or topical links, one could perhaps prescribe a house style, and still present the topic in an appropriate format and avoid the potential for formatting disputes. (This seems to be what you're suggesting with your Congolese example.) But based on precedent, Wikipedia has specifically chosen not to do that—it instead falls to the first or major contributors to pick formatting conventions for the article. (That precedent and its associated consensus are clear and directly applicable to the present discussion.) This also has the side-effect of allocating bias in rough proportion to the number of major contributions by various groups, rather than biasing all such articles in favour of one popular style.
I'm citing well-founded precedents like WP:ENGVAR, and describing a balance between the competing objectives that must necessarily be considered when policy is at stake. I think that this represents a fairer approach to Wikipedia policy than steadfast and singleminded advocacy for "minimal confusion" as the principal doctrine of the MoS. TheFeds 04:34, 10 September 2009 (UTC)
← I believe TheFeds' question on VPP was way too vague to be of any use, and that discussion doesn't seem to be going anywhere, anyway. I'd go with a two-step schedule as was done on WP:DATEPOLL or WP:IECVOT: in step 1, we create a page (I'd use a subpage of this talk page) where an editor can make a proposal, discuss about other editors' proposals, and tweak his/her proposal to address the points made by other editors. In step 2, no further edit is allowed to the proposal, and editors will be allowed to vote for proposal using a decent voting system (I'd go with the Schulze method). The first step should be advertised here, on WT:MOS, on WP:CENT, on WP:VPP and WP:VPR; the second step should be advertised as widely as possible on Wikipedia, including a watchlist notice. As for the time schedule, I'd go with seven days for each step. After the second step is concluded, the proposal which wins according to the chosen voting system will be incorporated in WP:MOSNUM to stay unchanged for six months. Or something like that. -- ___A. di M. 15:09, 10 September 2009 (UTC)
As for the RfC mechanism you've outlined, that level of formality is—I think—inappropriate for the limited question asked at VPP. The RfC process you outlined tends to be used for votes on fully-formed proposals—and I could support that procedure if we were voting on entire MOSNUM proposals. But for a policy consultation, it's not a good fit. TheFeds 16:33, 10 September 2009 (UTC)
To be perfectly honest, I'm not sure that there's strong enough interest to expect a meaningful RfC result (as in, a response from people other than those who have already clearly expressed their opinions).
I am ambivalent about the need to go through all of that formality over a paragraph in the MOS: I would be weakly opposed on those grounds. But I'm also concerned because I believe it will become mired in meta-debate. And that meta-discussion, especially if conducted by Greg in the style he's employed to date in this thread, will probably be marked by the same incivility, unwillingness to compromise, and tritely-phrased misrepresentations that he employed above. If it's likely to end up like that, I would oppose it.
There's also the broader question of whether we tacitly support a proliferation of RfCs to resolve simple changes that lack clear consensuses. I'd say that this debate is somewhat unique, in that it's lacked widespread input, is not of critical importance, and yet has consumed a lot of text. Are we saying that when mundane proposals go bad, we should proceed to an RfC, rather than first trying less formal tools for advancing the discussion? TheFeds 00:22, 11 September 2009 (UTC)
Back to the point. I come fresh to this debate, and was not aware until now that it was going on. User:Greg L is correct in proposing that numbers (to the left of the decimal point) be delimited by commas. But contrary to what Greg L perhaps assumes, it is not only an American thing, it is normal practice here in Britain too, so covers most of the mother-tongue-English-speaking world, in terms of population (apologies to Canadians and Australians). If it is true as alleged that the BIPM style is dominant in some English-speaking regions, they must be very much in a minority.
BIPM (of which I had never heard until today), based in France, appears to be trying to impose French practice on the rest of the world. I can reveal from personal experience that the only reason the European Commission translation service's English style guide lays down the BIPM policy in this particular respect (it does not do so in many others) is because they are translating thousands of documents every day from French to English, and for purely technical reasons it makes their lives much easier just to leave the numbers in the French format. The people who work there are well aware that this isn't normal British practice, and is a departure from the usual EU policy of using British English, but they have adopted a pragmatic compromise to save time and money in their particular special circumstances.
The Oxford Dictionary for Writers and Editors (a British publication) says:
Use commas to separate each group of three consecutive numerals, starting from the right, when there are four or more, except in math. work and pagination; in scientific and foreign-language work thin spaces are used instead of commas.
-- Alarics ( talk) 13:35, 13 September 2009 (UTC)
Right, so even if we assume that the French-speaking Canadians use the French system, that's another 20 million English-speakers on our side. Can we ask User:TheFeds, when he writes of the BIPM style that "it is the dominant English-language usage in some regions", which regions he has in mind? -- Alarics ( talk) 16:03, 13 September 2009 (UTC)
And at least in my experience, publications written in or translated into English in Europe use the BIPM style. (To cite a particular example, many French graduate schools use English as the language of instruction, and students write their theses in English.)
It might well be that the EU wishes to simplify their transcription of documentation from French to English by prescribing that style—but I suspect that the motivation goes a little beyond economy. In my estimation, because many European regions have their own traditional conventions in their native languages, and just as Europeans have settled upon English as a de facto language of collaboration and commerce (albeit while trying to maintain their regional dialects for culture's sake), they've settled upon the BIPM-style digit grouping to reduce ambiguity in communication. For example: the traditional French convention was commas for the decimal place and periods for digit grouping—the inverse of British usage, and obviously confusing. (In other words, I don't think the EU or BIPM is trying to push French style on everyone.)
Additionally, the BIPM convention is understood in English Canada, and has been taught in their schools for many years. (As well as being universally used in French Canada.) You're quite right about Britain, though; they do prefer the comma-based style. I'm not completely certain about the rates of usage in Australia and New Zealand, but I can scarcely imagine that either convention would be unfamiliar to them—I'd speculate that they are somewhere between Britain and Canada in terms of usage. TheFeds 04:25, 14 September 2009 (UTC)
As for the bigger picture, it's an open question whether Wikipedia should allow regional usage in region-neutral articles, or insist upon a fixed style—but that's not really even the heart of the issue as it relates to MOSNUM. TheFeds 05:47, 14 September 2009 (UTC)
It's pretty apparent that the discussion above has been inconclusive. The discussion ended up as a back-and-forth between myself and Greg L, and my attempt to seek policy advice from WP:VPP didn't shed any light on matters.
If the proposals are stale, then there's only one more order of business: establishing what the consensus was for digit grouping, so that we can revert to it.
Let me preface by saying that this is in no way a personal attack—quoting Greg L:
...One other note: en.Wikipedia adopted the U.S. style and standardized on delimiting to the left of the decimal marker using commas. Let’s please accept that nothing in this debate can change that and limit the discussion to the number of digits per group.
— Greg L, 15:16, 8 October 2008 (UTC), WT:MOSNUM Archive 112
...Now, Gerry, let’s get real shall we? I’ve mentioned several times above that en.Wikipedia adopted the US convention of delimiting to the left with commas. Nothing we’re discussing here is ever going to change that fact. The people over on fr.Wikipedia will keep doing as they like. As I wrote several times above (it would be nice if you actually read some of the goings-on here because I’m way ahead of you here) this practice of comma-delimiting to the left is far too entrenched in the U.S. and across the Internet for you to change that with your above epiphany. None of us here in this debate on this mote of a backwater discussion is going to change the way the U.S. works in this regard nor en.Wikipedia’s adoption of that widespread convention. As I also wrote above, this is an issue of simply adhering to the three-digit practice that is common throughout Europe and which has been standardized for use with the SI....
— Greg L, 18:07, 9 October 2008 (UTC), WT:MOSNUM Archive 112
That is from the discussion that brought about the phrasing that Greg reverted to (kicking off this lengthy discussion). It's focused on the RHS of numbers, rather than both sides of the decimal point. When other users mentioned that SI/BIPM prefer spaces on both sides, there was really only one argument for (what we later discovered to be) the U.S. GPO style—Greg asserted that it was a fait accompli that commas were used on the LHS by Americans, and said that Wikipedia might as well go along with that well-entrenched usage.
But because of that, the thread avoided discussion establishing why commas-on-the-left should (or should not, or should sometimes) be the preferred format. It bypassed the concern that SI compliance would entail spaces on both sides, and instead dealt with the RHS digit grouping to define the behaviour of {{ val}}. As a result, no consensus was formed about what to do with the LHS.
It is, however, where the (permissive) technical usage clause comes from (courtesy of A. di M. as Army1987)—that part seems affirmed by consensus.
To find a discussion that arrived at a consensus on how to group the LHS of numbers, or to find an overarching agreement on both the left and right sides, we're sort of out of luck. Going back much further, MOSNUM used to say to use commas only (without regard to any special cases)—but that was basically just an arbitrary convention that hadn't been extensively discussed, and wasn't uniformly followed. Even in Archive 19, and Archive 74, consensus was absent, and the issue was dropped without formal proposals or major revisions to WP:MOSNUM.
On another note, I'm going to quote Greg L again here:
SI is clearly a wonderful thing, and it is so because it doesn’t unnecessarily push the “Euro” way of doing things over the “U.S.” way, nor visa versa. The SI acknowledges and embraces practical reality. “Full SI writing style” recognizes delimiting via either commas or narrow spaces in the mantissa because that’s the reality of the American style of delimiting numbers. Like it or not, there’s simply no fighting it; that style is extraordinarily common and well entrenched—both in print and on the Web. Wikipedia—like the BIPM and their SI—can’t find itself in the position of trying to promote change in the way the world works by pretending to adopt a single style of numeric notation that isn’t well recognized in the U.S. The whole point of encyclopedias is to unambiguously and clearly communicate. Intuitively easy, familiar writing customs must be observed. There is no “right” or “wrong” with regard to commas or narrow spaces in the mantissa—not according to SI and not according to common sense simply because the English-language version of Wikipedia is read by readers in both Europe as well as the U.S. Accordingly, Wikipedia (and in the SI) recognizes both methods. We don’t have to agree that Wikipedia should adopt one style or the other with regard to delimiting the mantissa…nor should we. We can simply make two versions of a numbering template (or an option to check in a single template). Trying to necessarily link the treatment of the decimal portion to how we delimit the mantissa will only doom to failure any efforts here. We should address only one issue: should a template be made to make it easier to delimit the decimal portions to make long strings easier to read(?). My point would be that narrow spaces are so damn easy to read, that even a novice who has never seen it before instantly understands what it’s all about. And in articles where numbers are important, delimiting is crucial because long strings of non-delimited digits to the right of the decimal point unusable to the point of being barbaric. There should be an easy way for others to do so (rather than hand-coding it all).
— Greg L, 03:59, 20 December 2007 (UTC), WT:MOSNUM Archive 94
Strangely enough, that's a lot like what I was talking about. Yes, there are distinctions, but they are minor; that argument was used in a discussion about how to deal with the RHS of numbers—group in threes, fives, or don't group at all. (I'm wondering what's so false about Greg's previous argument that it doesn't apply any longer.)
In any event, the question of what level of confusion will result, or is acceptable in this case is not settled. And we haven't done justice to weighing the need to limit confusion versus other objectives on Wikipedia.
Later on, when Jc3s5h and I were allegedly trading campy ideas, there was in fact a substantial discussion about digit grouping (related to my edits). After a shaky start, where we got sidetracked over some possibly-misremembered standards, we consulted style guides, got input from a few editors (in addition to the regulars), looked at the archives, and managed to formulate a proposal that was not opposed. Now that's not necessarily the same as a clear consensus—because there were really only three of us commenting upon and implementing the final draft.
But it's certainly better on basing our treatment of delimiting in general on the results of a series of discussions that were specifically framed to deal only with RHS delimiting and templates, or which (going back several years) were more concerned with the thin-space handling in IE6 than digit grouping per se.
The take-home message is therefore this: the long discussions on MOSNUM were primarily based on how to handle {{val}} and its relatives, not to set a policy for numbering styles in general, and certainly not to require a particular convention. The question of regional usage per WP:ENGVAR is not settled—the VPP reference question was split, and we've hardly resolved any of that here. The question of technical usage was agreed upon previously.
Unless someone wants to resurrect the proposals, maybe we should just call this a "dismissal without prejudice": one of these days, when someone works up the courage to propose a resolution (maybe even through an RfC, if that option is more popular than traditional discussion), we can revisit this topic properly, with a more thorough and civil discussion, and buy-in from a sufficient cross-section of editors to establish a clear consensus one way or another.
In the meantime, all we've really got is consensus on how to make the RHS work (especially in templates), and how to use SI-style notation in technical articles. Let's accept that at face value, and move on. TheFeds 06:33, 21 September 2009 (UTC)
Use commas to separate each group of three consecutive numerals, starting from the right, when there are four or more, except in math. work and pagination; in scientific and foreign-language work thin spaces are used instead of commas.
Wasn't there a proposal to do an uplift of the use of {{ xt}} on the MOS/MOSNUM just a while ago? Did that die? Headbomb { ταλκ κοντριβς – WP Physics} 20:12, 9 September 2009 (UTC)
Truth be told, accurate color work is impossible on this 17-inch iMac because the parallax change caused simply by scrolling the above color-swatch from top to bottom of my screen causes the center squares to go from noticeably too-dark to too-light. My really, really good Sony 21-inch CRT monitor is still attached to my old Mac, which will forever be “Peter Pan”ed at OS 7.5.5 so I can continue to use a certain CAD program (I really scream on that old wire-frame application). Now that monitor is for high-fidelity work with color. Greg L ( talk) 18:30, 12 September 2009 (UTC)
Do you agree to add the following:
after the fourth bullet ("Yearless dates ..." in Wikipedia:Manual of Style (dates and numbers)/Datestempprotectedsection? If no-one disagree in 24 hours, I'll post an {{ editrequested}}. (Please do not use this section to discuss any other issue, no matter how close it is to this one; that would defeat the purpose why I'm writing this in the first place. -- ___A. di M. 20:42, 20 September 2009 (UTC)
Propose:
Do not use all-numeric date formats such as 03/04/2005, as they are ambiguous (the example could refer to 3 April or to March 4). For consistency, do not use such formats even if the day number is greater than 12.
(outdent) I would suggest something more along the lines of this, so it follows more cleanly from the preceding bullet point:
Other all numeric date formats, such as 03/04/2005, should be avoided since they are often ambiguous in that the first number could translate to either the day or the month (the example given could refer to 3 April or March 4).
I think it is unnecessary to further clarify with regard to days greater than 12. wjemather bigissue 21:54, 20 September 2009 (UTC)
See WT:Manual of Style#Summary done. -- ___A. di M. 22:55, 20 September 2009 (UTC)
I propose to put to an RfC and centralised discussion the following change:
Present text: YYYY-MM-DD style dates (1976-05-31) are uncommon in English prose, and should not be used within sentences.
Proposed text: YYYY-MM-DD style dates (1976-05-31) are uncommon in English prose, and should not be used in sentences or footnotes.
-- Alarics ( talk) 18:29, 29 September 2009 (UTC)
Having looked at the RfC results so far, it is becoming clear now what the proper solution is: appoint three editors who have journalism degrees to oversee MOS and MOSNUM and kick all the neophytes—including me—out of it. If there is anything that ought to be truly “professional” it is MOS and MOSNUM; all else can suffer from the standard drive-by shootings by youngsters who don’t know what the hell they are talking about. The two things in common to many editors here is they 1) think they know what they are talking about (citing new international standards such as IEC prefixes like “mebibyte” and “kibibyte” or ISO 8601 and how this somehow constitutes an excuse to use them on Wikipedia), and 2) they actually know precious little about technical writing. Wikipedia is just a playground for the galactically clueless to nourish their self esteem. It is just so absurd. I find this phenomenon to be simultaneously amusing and disgusting. Greg L ( talk) 21:28, 30 September 2009 (UTC)
I'm trying to help expand {{ Convert}} & it's standardization of the abbreviations used. We have come to a wall with the torque measurements. As of right now the kilogramforce-meters to Newton meters & foot-poundforce via {{convert|xx|kgm|Nm lb.ft}} as 10 kilogram metres (98 N⋅m; 72 lb⋅ft). Well as of right now we were working on adding Nm to kgm & ft-lb & ft-lb to kgm & Nm, but we have hit a snag of disagreement & we have agreed that we need the MoS communities opinion on this matter. I say we should use kgm for kilogramforce-meters & Jimp says we should use kgfm. I say we should use ft-lb for foot-poundforce & Jimp says we should use ft-lbf. Also I say we should use Nm for Newton meters & Jimp says we should use N.m. The wiki article for Kilogram-force it states for torque it is "meter-kilogram" & the Torque article has it listed as "meter-kilograms-force" or "kilogrammeter". So thoughts? 「 ɠu¹ɖяy」 ¤ • ¢ 21:40, 21 September 2009 (UTC)
Different disciplines have widely different practices. For instance, the cubic centimeter is an old CGS unit for volume. Nevertheless, the long-standing practice with Japanese motorcycles has been—and still is—to use “cc” for engine displacements. Accordingly, Wikipedia follows real-world practices rather than try promote the adoption of the rule of SI via example (which doesn’t work anyway). So, on the subject of antiquated practices, torque wrenches from ten or twenty years ago will often be calibrated in kg‑f‑meters, which was a common torque unit for Japanese-built automobiles; perhaps it still might be, I don’t know. IMO, an article for instance, on the Ford 351 Cleveland engine, which is sold all over the United States (and not so much elsewhere) ought to use ft-lbs as the primary unit of measure and provide a parenthetical conversion to N‑m. Similarly, if the the subject is about a particular Japanese car where the manufacturer still uses kg‑f‑meters, then that is what I would go with. Where there is no consistent industry practice, I would generally use the proper SI unit (newton‑meter). As a final caveat, if the subject pertains to a subject that is about or is closely related to the United States, one should consider using U.S. customary units throughout (including ft‑lbs for torques).
Many Wikipedians, who are prolific and jump from article to article find this practice of using different units in different articles to be disconcerting. They feel that there should be project-wide consistency. However, the practice using the units of measure that are very common to a particular discipline (with parenthetical conversions to a suitable unit) best serves the interests of our readers (which is why we’re really all here). The purpose of any encyclopedia is to educate readers on a subject and properly prepare them for any future studies they may pursue on the subject. We do our readers no service whatsoever if, in the subject of gravimetry, we mention gravity gradients of “3.1×10−6 s–2” (that unit is pronounced “reciprocal seconds squared”) when virtually all text books on the subject use “3.1 µGal/cm” (pronounced “microgal per centimeter”).
In a nutshell, try to stick to the rule of SI unless an industry practice is rather consistently otherwise or if the subject matter is about or strongly associated with the United States.
That’s my 2¢. Now for “unit-of-measure jihad” and suicide bombers from *standards organizations*… (*wheeeee*) Greg L ( talk) 22:18, 21 September 2009 (UTC)
In that case, as to the exact way to write out these units of measure (such as someone’s suggested “foot-poundforce”), I would dispense with arguments over “what technically makes scientific sense and mustn’t be confused with units of energy” and would certainly jettison weird-looking examples like that subscripted form. We’re not doing anyone a favor by pretending to change how the world works. Moreover, such efforts to change the world will fail anyway; Wikipedia is pretty darn good at spreading misinformation, not in changing the very way people communicate. Technical writing works best when the writing techniques being used to convey ideas don’t call attention to themselves. If there is a sound reason to depart from the rule of SI, I would just use what is most typically used in real-world literature on the subject.
Either that, or do whatever the hell you want. Some of the suggested units up there look retarded to me. I now have a sense that you weren’t so much looking for advise as were simply inviting a pile-on against those who would disagree with you. No help here; just go bicker amongst yourselves. And you and the others might try to use common sense for once and not needlessly confuse readers or call attention to one’s writing style. That beats endless arguing in an effort to prove who’s right.©™® Greg L ( talk) 22:46, 21 September 2009 (UTC)
Jimp is correct in that the standard abbreviation for newton-metre is N·m (note use of a half-high dot). Otherwise it may be confused with nm for nanometre or mN for millinewton. The problem with the foot-pound and kilogram-metre is that neither the pound or the kilogram are units of force, so it's not clear how to abbreviate pound (force) and kilogram (force) in some kind of internationally standardized way. You could come up with some local standard, but someone from some other country would always disagree. I'll have to research that issue. RockyMtnGuy ( talk) 00:55, 22 September 2009 (UTC)
Yes, Jimp is correct on the proper way to write the unit symbol for the newton-meter. As for unit symbols like foot·pound (ft·lb) “house solutions“ and “local standards” like “foot-poundforce” are just that: local standards that are not generally found in the real world. Such *Wikipediaisms* are nothing more than just more grist for, as one editor wrote, above, people to “chuckle good-naturedly” at our “foibles.”
Just because a practice that is common in the world has technical or logical shortcomings when one scrutinizes it doesn’t mean that we need super editors to come to the rescue and right every wrong with the technical-writing world. When General Motors specifies a torque of 75 ft·lb, and since torque is, by definition a force moment, it can quite reasonably be assumed that “force suffix” is implied and the unit really means pound-force or kilogram-force. I find that much preferable to (once again) pretending we’re going to show the world how things ought to be done. The expression “75 ft·lb” in the context of torque confuses no one; the expression “75 foot-poundforce” would just make Wikipedia once again look like it’s been infested by space-cadets.
Once again, I would suggest we look to other encyclopedias and other professional publications for guidance here rather than try to set the world on fire by misapplying our *amazing powers of physics acumen* and trying to invent new and better ways to write common things. Greg L ( talk) 01:52, 22 September 2009 (UTC)
Nm
; example: {{convert|32|Nm|kgm ft-lb}}. I prefer Kg·m, but whatever on that one. But still make formatting/typing easier I think the wiki attribute should be kgm
. As for lb-ft vs. ft-lb, in the US ft-lb (or ft. lb) is more commonly used. 「
ɠu¹ɖяy」
¤ •
¢
05:43, 22 September 2009 (UTC)Note that I am using the non-breaking hyphen ({{nbhyph}}
) for this unit symbol. A template should either be slapping a no-wrap around “lb‑ft” or it should use a non-breaking hyphen.
Note also, Woodstone, that you reverted to the exceedingly common practice of referring to the torque as “foot‑lb”, but that form properly refers to the unit of energy that has a magnitude of ~1.3558 joules. Nowadays, it is not uncommon to hear commercials with Mike Rowe’s baritone voiceover on Ford commercials talking about big, masculine diesel torques of “410 pound‑feet of torque”. Certainly, no one in America will be ‘confused’ by “410 lb‑ft”. And, in my opinion, using this form will not unduly distract or draw attention to the writing style when trying to communicate ideas.
Besides the fact that putting the length of moment arm last is more scientifically valid, it is also in conformance with other units like the N·m and kgf·m, which also have their moment arms last. Thus, this should appeal to those editors here who like project-wide consistency.
Does everyone agree then, that it would be best to write them N·m, kgf·m, and lb‑ft ? Greg L ( talk) 16:54, 22 September 2009 (UTC)
If, it is your intention here to be addressing what is strictly the “default” behavior, then—by all means—I agree with you 100%; converting to N·m should clearly be the default setting. Greg L ( talk) 18:43, 22 September 2009 (UTC)
Agree that N·m should be the default and preferred "to"-unit. But as explicitly requested unit I would prefer to write kg-m (no explicit "force", but with dash to avoid confusion with the wrong dimensioned kg times meter) and similarly lb-ft. − Woodstone ( talk) 19:51, 22 September 2009 (UTC)
The template is not meant only for science articles. Only a few articles use this obsolete unit. The template is currently flexible enough to allow the option of "kilogram-metres" and no "f" in the abbreviation.
Changing the default outputs for torque units is a different question. Having them include kilogram (force)-metres would be a bad idea but there's no such proposal at template talk:convert. JIMp talk· cont 20:59, 22 September 2009 (UTC)
(outdent)
I see that you, Jimp, are suggesting that the template is also suitable for science-related articles. If so, then the challenge is to get all the *truly proper* forms in as well as the *real-world industrial* forms and to provide succinct and clear guidance on how to use the template. Greg L ( talk) 21:14, 22 September 2009 (UTC)
So which abbreviations have we come to a consensus to & which approach should we take on this exactly, because I'm not completely clear on the current stance we are at. 「 ɠu¹ɖяy」 ¤ • ¢ 21:33, 22 September 2009 (UTC)
This isn’t even always a “this vs. that” issue; there are shades of gray. Whereas “ft‑lb” might be particularly suitable for automotive and industrial, purposes, if one were discussing motor torques on ski lifts, “lb‑ft” may be more appropriate. In an article on the polar moment of inertia of the Saturn V moon rocket, a torque of “lbf·ft” or something like that might be more appropriate.
I can certainly tell you from having horsed around on 250 kV Mitsubishi circuit breakers that are as big as a VW van (and Hitachi and Siemens, etc.) that there are a wide variety of practices with lots of units of measure. These practices apply also to pressures in a fashion that—once again—drags the kilogram into units of measure where it is employed as a unit of force. You can find “kg/sq cm”, “kg‑f/cm2, and all sorts of things you would find to be abomination unto the eyes of the technology gods. We need to provision for lots of stuff because we can’t become instant experts in every niche discipline by sitting on our butts performing Google searches to prove this point or that. Greg L ( talk) 22:11, 22 September 2009 (UTC)
Then I will propose this, I will break the torque table down into two categories, "Industrial" & "Scientific". Industrial will use ft-lb, kg-m & N·m, while Scientific will use ft-lbf, kgf-m & N·m. I will set it up where it will be different, yet still easy to use. 「 ɠu¹ɖяy」 ¤ • ¢ 22:21, 22 September 2009 (UTC)
BTW: Why is our article on the “foot-pound” unit of energy titled Foot-pound force? Talk about misleading. What they mean is “Foot·pound-force (unit of energy)”. But that title has the connotation of “Foot-pound (force).” Not wise, IMO. I’d suggest simply “Foot-pound (energy)” and provide some redirects.
And, no, gu1dry, you don’t want to be linking to that one, regardless of whether someone fixes that title. It appears Wikipedia might not have a dedicated article on the unit of torque that would be titled something like “Pound-foot (torque)” Greg L ( talk) 00:51, 23 September 2009 (UTC)
Here’s the terminology:
There appears to be widespread but vague sentiment against the duplication of scope in the two style guides, because it's a recipe for contradictions to develop, and fragments dialogue about the overlapping part of the scope.
Again, I put it to you that MOSNUM should deal with specialised guidance alone, in these areas:
I intend to create a draft of this. Tony (talk) 08:48, 23 September 2009 (UTC)
I agree that there's too much duplication, but removing all of it would have the problems which Jc3s5h and Wjemather described. If a section is in MOSNUM, then MOS should have only a short summary of it, addressing only the aspects of it which one needs to look up more often, and possibly should have a clear indication of what is a summary and what is the "master" section: for example
<-- This section is a summary of [[WP:MOSNUM#Currencies]]; make sure that any edit to this section represents the section on WP:MOSNUM faithfully. If you want to change the actual content of the guideline, discuss it at WT:MOSNUM. -->
at MOS, and
<-- [[WP:MOS#Currencies]] is a summary of this section. When making significant edits to this section, please update the summary at WP:MOS accordingly. -->
at MOSNUM. (Now there's such a comment at the top of MOSNUM, but it should be put at the top of every section having a summary at MOS, so that people editing single sections will read it as well. Also, the "summaries" at MOS should be much shorter than they are; here's my take.) -- ___A. di M. 00:10, 24 September 2009 (UTC)
I had a post, above, where I suggested what I wasn’t seriously thinking would really be adopted: Appoint three editors who have journalism degrees to oversee MOS and MOSNUM and kick all the neophytes—including me—out of here. And that started me thinking… who the heck here actually has a four-year degree in journalism? If we can identify three such experts, we could, conceivably, appoint them to special positions here. Anyone… anyone? Before we get bogged down in what special responsibilities they might have, let’s first identify who these editors, if any, might be.
P.S. Please spare the rants about how others with elite privileges might infringe on your God-given right to influence the universe through Wikipedia. Let’s reserve the infinitely expandable white space, below, for those who have journalism degrees to identify themselves. Greg L ( talk) 22:17, 30 September 2009 (UTC)
Oh, well… What outstanding arguments for those with no formal training in journalism to reign supreme; the experts are all screwed up! That’s why we don’t look towards the internationally distributed, English-language Encyclopedia Britannica for guidance, the pros over there don’t inspire “confidence.” Greg L ( talk) 00:18, 1 October 2009 (UTC)
¶ (edit conflict) Qualifications in journalism and formal certificates in journalism vary very greatly between countries and eras. In Germany, you can get a certificate in journalism from a higher technical high school. When I attended the University of California, Berkeley, which has educated hundreds of highly-professional journalists, the School of Journalism wouldn't even grant bachelor's degrees; undergraduates had to major in something else. (It's often thought infinitely more important to get a either sound liberal education that includes English and other languages, or to learn a specific field such as history, political science, economics, natural science, religion, international affairs or regional studies, or both.) And I think that even today, at least in countries where entry isn't governed (as it has been in England) by union and apprenticeship regulations, a large proportion of the best writers in journalism have always been those who never received (or even) sought any formal degree in journalism.
But knowledge of usage, grammar and punctuation is secondary to good writing for publication or broadcast, and good writing is only one of the skills a good reporter or editor must learn. So while I understand the sentiment (without agreeing with it), formal certificates in journalism would only be a peripherally-useful indication of ability to police the Manual of Style. The job, for better or worse, still remains with us. —— Shakescene ( talk) 00:47, 1 October 2009 (UTC)
A similar idea was actually tossed around at WT:FAC this week. That proposal suggested that all MOS pages be locked, and once per quarter gatekeppers (who should not be required to have a particular degree - something we can't verify anyway) would implement any changes that have reached consensus on the various talk pages in that time. This would help make the MOS a lot more stable and actually require consensus for making changes. Karanacs ( talk) 15:55, 1 October 2009 (UTC)
Folks, it's been going on for a while, and we seem to be close. Skomorokh was the admin who last commented that there wasn't yet consensus for him/her as a gatekeeper to make the change. The so-called pink version (not very pink on my monitor) seems to be the final one. Feds and anyone else, will you please state briefly here any concerns you have, and how exactly you'd like the wording to be changed (if at all)? Let's hope we can contact Skomorokh soon. Tony (talk) 04:07, 17 September 2009 (UTC)
I think we have a pretty fair consensus against using all-numeric date formats though perhaps we had better advertise it more widely before we risk a backlash from those who have grown used to the notion that refs should use YYYY-MM-DD. I'm not convinced that we have the issue on whether to allow AP dates or not settled. I'm not the only one who's expressed the opinion that they can be happily done without. A third issue which hasn't really been much discussed is whether to allow three-letter+dot abbreviations (e.g. Apr.). JIMp talk· cont 10:40, 17 September 2009 (UTC)
← (outdent)
It could be that many editors don’t even recognize the common monthly short-form method when they come across it (the one memorialized by the A.P.) and wouldn’t have a clue where to look up the practice; frankly some 90+% of Wikipedia editors don’t own a single print manual of style, so WP:MOS and WP:MOSNUM are the only places they can get proper guidance. The A.P. didn’t just make this stuff up; it is a long-time practice that probably goes back to the 19th century when spittoons littered the floor of every newspaper office in the U.S.
The short-form technique is a compromise of sorts in the effort to always write out months but to shorten the really long-named months in parentheticals; e.g., The magazine Science Week (issue 38, Sept. 15, 2007) referenced the first use of…. It is a technique to which any half-way literate reader has long been exposed and likely never noticed it in their newspaper’s Letters To the Editor section; e.g. I enjoyed your article regarding teacher pay (“Public servants’ pay lagging,” Sept. 28), and feel you…. If it is not one of the longish-looking months, then it isn’t abbreviated and appears like this one, (which is one of my own letters in Aviation Week & Space Technology): Prof. T. Nejat Vezirogluʼs letter “Hydrogen, Future Airline Fuel?” (AW&ST June 23, p. 12) says….
The only basis I know of for not showing our many, would-be, all-volunteer editors from all walks of life how to properly abbreviate months when doing good, encyclopedic writing, would be this argument: “let editors just use common sense.” Given the chronic and obvious shortcomings endemic throughout Wikipedia, that argument makes no sense to me whatsoever as it completely flouts reality. Frankly, I often suspect such arguments from any experienced Wikipedia editor who has to know better, is just a smoke screen for “I like ta do it my way so don’t prescribe any way of doing it.” Either that, or it is being used as an excuse to push a God-awful-looking three-letter practice (that should be strictly limited to fixed-width uses in long tables) because it has “logic” and Wikipedia ought to once again Lead the Way and Show the World How Technical Writing Is Properly Done®™©. Greg L ( talk) 17:48, 17 September 2009 (UTC)
{{Dts}} makes YYYY-MM-DD unnecessary in sort tables nor does it save a great deal of space compared to three-letter abbreviations. Although putting the year first (whether it be numbers or letters for the month) solves the month-day vs day-month problem unambiguously, it's just not usual in English. God-awful-lookingness is in the eye of the beholder. Some would rather behold three letters than AP style. It seems I'm not the only such beholder. However, I would concede that Woodstone is correct in saying that it's too early to speak of consensus for a change which will be as wide reaching as ridding WP of YYYY-MM-DD. Though perhaps we can settle whether to allow Mar., Apr., Jun., Jul. or Sep. (i.e. three letters + dots, as suggested by The Feds, not covered by AP). JIMp talk· cont 18:48, 17 September 2009 (UTC)
¶ Ordinal suffixes actually make US-style dates (e.g. April 11, 1171) easier to read, because commas and spaces don't always come out well or separate numbers clearly. At the end of a sentence, they're better than a simple period (full-stop) in separating a date from the beginning of the next sentence. Although I learned to read about 55 years ago, I still listen to what I read (without moving my lips) because it helps when I have to read or act something out loud, and because it's the best way of grasping the author's logic, rhetoric, grammar and emphasis , so 1st, 14th, 2nd, 23rd, etc. reflect my normal usage. That's not an argument to impose ordinals on anyone else, but I see no reason to forbid ordinal suffixes, either. Once upon a time, ordinal suffixes interfered, I'm told, with date auto-formatting, and print publishers trying to save space chopped them, as they abbreviated months to Aug., Sept., etc, but neither of these considerations need apply. This is just another case where I differ from others on this Talk Page in not seeing great value in uniformity for its own sake, and we are trying to save space and reduce the number of rules that editors need to heed. —— Shakescene ( talk) 20:54, 17 September 2009 (UTC)
My two cents:
BTW, I suggest this:
-- ___A. di M. 10:16, 18 September 2009 (UTC)
Well, I'm afraid that won't do, because it does not ban YYYY-MM-DD, which we've agreed we need to do explicitly. Also, I don't like the idea that it is "not desirable to spell out long month names" in footnotes. Saving a maximum of four characters (yes, that is all the A.P. style achieves) is never going to be critical in a footnote. I thought we had more or less agreed that it was only in tables with narrow columns that dates need not be written out in full. I'm still not clear what is wrong with the proposal in the pink box. --
Alarics (
talk)
11:58, 18 September 2009 (UTC)
BTW, I don't for a moment imagine that in practice we can stop people using YYYY-MM-DD overnight. The point is that once there is an authoritative text clearly deprecating that form, we can point to it if people complain when we change their numerical date to a proper date. -- Alarics ( talk) 12:09, 18 September 2009 (UTC)
And to LeadSongDog, it doesn’t matter if you stridently believe that everyone from Koko to Einstein instantly understands 2009/05/12, it isn’t at all proper, encyclopedic technical writing to use all-numeric dates; one always writes out the name of the month (or an abbreviation). Always. If you don’t understand that yet, it’s beginning to dawn on me that you might never. If you do understand that, but believe (hope) that yours is a *new way and Wikipedia will show all the other encyclopedias and all the other professional publications how to properly write out dates*, you are mistaken; we will just have a second-rate-looking product that looks like it is the product of space cadets with no journalism or technical writing experience whatsoever. Go crack open an Encyclopedia Britannica if you don’t understand any of this. If your response is “well… Wikipedia is written for an *international* (*sound of blair trumpets*) audience,” I’ll respond “yeah, an English-speaking one at that; so go take a look at the language Encyclopedia Britannica is written in.” Greg L ( talk) 15:02, 18 September 2009 (UTC)
I'm unclear where YYYY-MM-DD references the Gregorian Calendar. Maybe I missed it. Anyway, we're mostly talking about normal dates, not ancient ones. Even if we're talking about ancient dates, YYYY can either be zero or blank-filled. OTOH, if you're for some reason talking about Mayan dates or similar unusual calendars, you've lost me. - Denimadept ( talk) 15:04, 18 September 2009 (UTC)
Moreover, if you really wanted to do a ‘proper’ job of citing, I’d point out that Science News, like pretty much all periodicals, has this sort of little diddley thing in the upper right-hand corner: October 13, 2007 so I find arguments that YYYY/MM/DD has some sort of intrinsic virtue in citations (or any other place on Wikipedia, for that matter) to be profoundly uncompelling. You aren’t going to convince anyone here of anything if your arguments crumble so badly and easily in the face of reality.
It’s so profoundly simple: act like any other half-way professional publication and simply write out the month because it reads more naturally and is unambiguous. Besides looking awful, all-numeric dates are especially awkward for European readers and those in other countries where they customarily write out dates like “8 December” and “8/12.” Because of daily reinforcement, these readers are accustomed to seeing the month last and have to mentally flip this order around just because it is preceded by a year. It is of no help if ISO, JIS, ANSI, or IPSO FACTO endorse this or that standard; it’s all BS because the only thing that matters is what is most natural in the daily life of the reader. Any all-numeric date format—even if it is a “standard” (*sound of heavenly female oratorio*) endorsed by Santa Claus and Oprah herself—is inherently ambiguous. Moreover, all-numeric dates don’t look in the least bit professional—they aren’t the least bit professional—which is why quality publications don’t ever use them.
Give it up. Can you not see the handwriting on the wall that all-numeric dates of any sort are toast? Completely burnt toast? Let’s get over this. There is no compelling reason to depart from standard practices observed by any quality publication—including all English-language encyclopedias. It is über‑stupid that so much verbiage has been devoted to something so elementary. Greg L ( talk) 05:04, 19 September 2009 (UTC)
It just struck me yesterday that if one really needed to save space in giving a date while still avoiding ambiguity, you could use what I think of as librarians' abbreviations for the months (because they sometimes appear on due-back rubber stamps and works such as the Readers' Guide to Periodical Literature): Ja, F, Mr, Ap, My, Je, Jl, Au, S, O, N & D. So long as the year is expressed as more than two digits, there's no ambiguity, although of course these abbreviations are hardly universal or intuitive. (And, no, there's no "a" in June or July, no "e" in January or July, no "l" in January or June, no "p" in August, no "u" in April, no "r" in May and no "y" in March; unlike US State abbreviations such as AL, AR, MI or MS which often confound most Americans who don't work for the Post Office, there's no way to mistake which month "Je" refers to.) So all dates after the year 999 could theoretically be compressed to between 6 and 8 digits without dashes as 18S2009, 4Jl1776, 5N1605 or 14Jl1789. As Independence Day and Bastille Day show, however, clarity would dictate, either capitalizing the L in Jl (as with litre), or requiring spaces.
This is not a serious proposal, and, although unambiguous would be hard for the average reader to understand, but probably no more so than YYYY-MM-DD (which is ambiguous to those unfamiliar with it). But I wanted to show that YYYY-MM-DD is not the only possible way to compress dates, nor even the shortest. —— Shakescene ( talk) 20:24, 18 September 2009 (UTC)
¶ That (not Klingon or Julian days) is pretty much the way I abbreviate dates for myself (e.g. 12 Ap 1861 or 4:45 Tu 20 O), so I wasn't being utterly fanciful. But while I think my system might be easier to grasp at first sight and less ambiguous than 2009-09-19, I wouldn't recommend either for Wikipedia because the average reader would be thrown unless the table or list explained the whole dating system. And with the right templates to convert and re-convert dates, Julian days (adjusted for the fact they begin at noon) would be a great way to store dates, far better than the range-limited and notorious systems for Excel in Windows (which thinks there was a 29 Feb. 1900) and Macintosh (which has an equally glaring error that I've forgotten). —— Shakescene ( talk) 19:56, 19 September 2009 (UTC)
There is an international standard and it is YYYY-MM-DD, so why don't we use it? To quote from the ISO site, it's
and ISO 8601 corresponds to the UN Working Party on the Facilitation of International Trade Procedures in its Recommendation 7. -- Cavrdg ( talk) 07:11, 19 September 2009 (UTC)
P.S. At 2009-09-19T1630 I read Recommendation 7. Nice standard… for time-stamping the ticket for going into the Chunnel between England and France. Not to be used in encyclopedias. Greg L ( talk) 16:41, 19 September 2009 (UTC)
The actual reason why we can't seem to get consensus on anything is that we're trying to discuss several related but distinct issues at once. This all started with a suggestion to ban the 12/09/2009 format, and no-one seems to disagree with that; so, why don't we just add to the MoS:
Do not use date formats such as 03/04/2005, as they are ambiguous (it could refer to 3 April or to March 4); for the sake of consistency, do not use them when the day number is greater than 12, either.
meanwhile, and then continue discussing the remaining issues (YYYY-MM-DD, AP abbreviations, three-letter abbreviations) more calmly? -- ___A. di M. 09:00, 19 September 2009 (UTC)
In my book, this phenomenon is akin to walking right up to a party at a house where everyone is heading out the door and saying “No no… everyone back in. I got here late and missed out on it all so everyone start over and begin discussions with me included this time.” (*sigh*)
This seems to be the “Wikipedia way®™©” right now and we might one day establish rules that if debate is wrapping up and someone crashes his damned SUV through the living room wall and yells “start all over with me!” that we’ll just inform said editor that, with thousands of editors, we must cut off debate at some point. Greg L ( talk) 16:06, 19 September 2009 (UTC)
Now, you wrote above I cannot possibly see anything wrong with all-numeric dates in the practically unambiguous from [sic] of 2009-09-17 and strongly oppose banning it. All portions of that position are demonstrably false. As is clearly explained above, all-numeric dates like “2009‑11‑09” are inherently ambiguous. Moreover, they look poor. For these, and probably still other reasons, no English-language encyclopedia uses them; it is not proper journalistic practice. If you want Wikipedia to diverge from standard encyclopedic practices, you’ll need to come up with a really compelling reason for doing so. Ain’t seen one out of you so far. Greg L ( talk) 18:49, 19 September 2009 (UTC)
The fact is, no proper English-language publication of any sort uses all-numeric dates. As I said above, if you want Wikipedia to diverge from standard encyclopedic practices, you’ll need to come up with a really compelling reason for doing so.
Does your argument that Wikipedia should flout these well-established practices amount to nothing more than “you like-ta”? Do you think all-numeric dates are exceedingly modern—even futuristic? Do you believe what some I.P. editor once wrote (fantasized) on ISO 8601? You know, that bit about how ISO 8601 “applies to all written communications … [even] hand written … when communicating … even privately.” Are you seriously asking us to believe that people are being “old-fashioned” when the write a handwritten note to their mother that spells out the name of a month?
Let me know when the rest of the world starts writing notes like this to their mother:
Mom,
I went to Brad’s house to play with his Star Wars collection. Be back at 2009-09-19T1741.
(Unindent) Woodstone asked "why is there any need to proceed to the heavyhanded action of a ban of a specific form that does not create any problems? (Emphasis added.) No specific form has been put forward. The various forms that could be used will create problems due to ambiguity. Writing "dates like 2009-11-09" leaves too much to the imagination and interpretation of editors. If something more specific were written, it would be well-neigh impossible to communicate it to readers. -- Jc3s5h ( talk) 20:47, 19 September 2009 (UTC)
Do not use date formats such as 03/04/2005, as they are ambiguous (it could refer to 3 April or to March 4).
From above by Greg L: "The fact is, no proper English-language publication of any sort uses all-numeric dates". This is simply nonsense. Use of dates written like 9/11/2001 is very common, both in running text, and in isolated places, like headers of articles or in tables. Wikipedia is rightly deviating from that practice, because its international readership would easily be led to mistaken interpretations. However, outside of running text, in some cases a more condensed form is prefarable. For that purpose the form "2001-09-11" is the most suitable, because of its unambiguity and international recognition. And, by the way, vertical alignment cannot be achieved with textual months in the variable size fonts, now almost universally seen, even on computers. − Woodstone ( talk) 22:51, 19 September 2009 (UTC)
As for your Wikipedia is rightly deviating from that practice, because its international readership would easily be led to mistaken interpretations. What an absurd thing to write! No international readership could possibly be confused by either November 9, 2002 or 9 November 2002. Conversely, the very thing your are promoting, all-numeric dates, are precisely the very thing that can cause confusion. Why? Simply because most people in their daily lives write these dates in some parts of the world as 9‑11‑2002 and still others 11‑9‑2002. Then there is this idiotic practice that you’re promoting because it is a *standard* (big whoop, it was never intended for use outside of stuff like airline tickets) that very few people anywhere outside of Star Trek conventions (and Wikipedia editors who have zero formal training in journalism) ever use: 2002‑11‑9, which is particularly confusing to European readers.
As for your tiresome refrain about “international” readerships, are you even reading what you’re writing? Do you think Encyclopedia Britannica is only read by Americans and Britons?.
It simply boils down to the fact that we have yet another “IEC prefix” crowd that is absolutely convinced of the superiority of a new *standard* and feel Wikipedia should be hijacked so we Can take the lead and show the world the path to a brighter and more logical future by adopting and misconstruing every *standard* ever proposed.©™® Uhm… no. As we learned from the IEC prefix experience, Wikipedia simply follows the way the real world works and never tries to promote change by adopting practices that are used only by Trekies, computer programmers, and a handful of Wikipedia editors. If it isn’t in other manuals of style, it’s probably a ratty idea.
I think I’m gonna start an RfC to institute a rule that the only people who can edit MOS and MOSNUM are people who A) have journalism degrees, and B) have multiple resource books and “real” manuals of style such as Chicago Manual of Style and the AP Manual of Style. Then inane suggestions will hopefully evaporate, such as suggestions that Wikipedia is *uniquely* read by international readers (but Encyclopedia Britannica is not) and this is somehow a reason to engage in confusing practices that flout Technical Writing 101 and introduce confusion rather than reduce it (and looks like crap to boot). If adopted, I’d be eliminated from contributing, but so too would about 99% of the people who do drive-by shootings on MOS and MOSNUM because they’re out to show the world how things *oughta* be done. I’d welcome that. My older brother has an advanced journalism degree and taught college-level journalism. Under this proposal, he could contribute to MOS and MOSNUM. But then, he’s too damned smart to waste his time here. Greg L ( talk) 02:23, 20 September 2009 (UTC)
Okay, Woodstone, yes, you're right; dates with three-letter abbreviations won't align (without some fancy adjustments). I wasn't thinking about the variable width of letters in the font used here. Chalk that up as an advantage of YYYY-MM-DD. Weighed against the disadvantages of YYYY-MM-DD, though, alignment hardly counts for much (but if we really must have it, I'll write us a template to align dates with three-letter abbreviations).
How could people think YYYY-NN-NN dates might possibly be YYYY-DD-MM? It defies all logic. This format is never used. It makes no sense ... right? Nonetheless people do make this mistake. That's enough, we don't need to fathom why. The format is unfamiliar.
Wjemather thinks YYYY-MM-DD dates "are apporopriate in certain circumstances such as in citations". Why? What is so special about citations that we have to use a different format than that used in the rest of the article? I've never been able to get this one. We see it all over the place, though. No, the only theory I can come up with is that people have just grown used to seeing this in citations because it was once the required input format for the citation templates. The format is unfamiliar & ambiguous, the only circumstances on WP where it's appropriate is hidden from view. JIMp talk· cont 16:07, 20 September 2009 (UTC)
Woodstone: Let’s attend Real World 101 here for a moment and also get into Woodstone’s mind. Let’s hook up the ol’ EEG to his brain…
As for your …in my view the form yyyy-mm-dd is more natural and flowing, the general consensus here is that it is certainly not and your achievement of providing links to web sites that use all-numeric dates is utterly irrelevant to this discussion.
This should be the end of it. As with the IEC prefix debate, there was one editor who absolutely would not agree that “mebibyte” had no place on Wikipedia since it was *the future*. He ended up just falling on his sword and left Wikipedia. A “general consensus” on Wikipedia does not mean that 100% of editors are in full agreement and it never did. I would hope, Woodstone, that you will just realize what’s in the cards here for all-numeric dates on Wikipedia. No professionally produced, English-language encyclopedia uses them and there is no compelling reason in the world for Wikipedia to do otherwise. Greg L ( talk) 20:17, 20 September 2009 (UTC)
It is clear that you have strong convictions about how it is you edit and nothing will ever change your mind. This is only about adhering to style guidelines that other encyclopedias use but you behave as if it is the end of the world.
It is clearly pointless for me—and probably anyone else here—to further debate you. I will leave it to others to try to deal with you. There is ample electronic white-space, below for you to get in the last word as I will no longer deal with you. Goodbye and happy editing. Greg L ( talk) 20:54, 20 September 2009 (UTC)
I agree. It is mainly footnotes that are still at issue. Most of us think that YYYY-MM-DD is never necessary in citation footnotes, and should therefore be avoided because it can be an obstacle to understanding. A minority disagree, and think we should say that it can be used in footnotes. Can we bring Tony back in to suggest what should happen next? I will go along with whatever he recommends. -- Alarics ( talk) 11:59, 21 September 2009 (UTC)
I like the sound of the discussion here about eliminating ambiguous date formats such as 03/04/2005. Now that date autoformatting is gone, and citation templates now no longer covert ISO dates into dd mmm yyyy or mmm ddd yyyy, so the reference section is often a messy mix of formats. I think we should simplify the section #Format consistency to read:
Dates in article body text and in article references should all have the same format
I also think the exemption for tables and infoboxes can still apply. Ohconfucius ( talk) 12:23, 22 September 2009 (UTC)
Status quo is acceptable. "Slash dates" are an abomination, everyone agrees, we will never get agreement on dmy vs mdy, and Pseudo ISO are good for tables and lists for a number of reasons apart from dynamic sorting. Since we suggest never using pseudo-ISO for dates before 1583 the "ZOMG" scenario "what if someone puts the date 83-12-25, out readers will have brain failure!" doesn't arise. If we were writing 20091225 I might agree that it presents readability problems... Rich Farmbrough, 14:03, 22 September 2009 (UTC).
Headbomb, you can't say "2009-09-06 is unambiguously recognized as meaning "6 September 2009" everywhere on the globe" when we have had people saying on this very page that they didn't recognise any such thing. If there are WP editors who aren't sure what it means, there must be zillions of readers for whom that is even more true. -- Alarics ( talk) 16:24, 23 September 2009 (UTC)
I maintain my position that the ISO has contaminated the YYYY-MM-DD format beyond repair and it should not be used in an uncontrolled environment such as Wikipedia. For those who believe otherwise, I put the following questions:
(By "require" and "allow" I mean that the MOSNUM encourages every editor to edit any article to avoid ambiguous or unexplained use of the format.) -- Jc3s5h ( talk) 16:28, 23 September 2009 (UTC)
(unindent)Then you have no idea how standards work. The only formal standards that are in effect in the absence of a specific adoption by a publication are those that are imposed by law. ISO 8601 is not a law. Some Wikipedia editors might think they are using the ISO 8601 format when they write dates like 2009-09-23, but they are mistaken.
Of course, one could adopt the standard for a single article by explicitly stating in the article this had been done, but I've never seen an article with such a statement. -- Jc3s5h ( talk) 18:55, 23 September 2009 (UTC)
(unindent) There are no criteria to decide if the dates in the following table are written correctly. This table is based on a New York Times article.
Date | Event |
---|---|
1952-09-23 | Richard Nixon's "Checkers" speech |
-62-09-23 | Caesar Augustus born in Rome |
-- Jc3s5h ( talk) 20:39, 23 September 2009 (UTC)
The only method that is abundantly clear and unambiguous is “November 11, 2009” and 11 November 2009. Now those are unambiguous, which is probably why the English-language, internationally circulated encyclopedia known as Encyclopedia Britannica doesn’t use all-numeric dates for anything in its publication.
Having said all that, I’d go along with allowing its use in tables only as long as the header contains a parenthetical legend, such as Date Inducted Into Hall of Fame (dates are Year-month-day). And even that is a darn big compromise given that three-letter monthly abbreviations fit just as nicely in tables as your cursed all-numeric date method. Greg L ( talk) 20:45, 23 September 2009 (UTC)
Name | Date of death |
---|---|
William Shakespeare | 23 April 1616 |
Miguel de Cervantes | 23 April 1616 |
::::::::doesn't stop being misleading just because "April" is spelt out. (Then, if the problem is that some people believe all YYYY-MM-DD dates to be ISO 8601, then the current wording discouraging its use for pre-1583 and non-Gregorian dates already solves it.) -- ___A. di M. 09:42, 24 September 2009 (UTC)
(unindent) I believe Wjemather's claim that "YYYY-MM-DD suffers from no such problems and, by definition, should always be in the (proleptic) Gregorian calendar" is false. Please provide a citation from a book that addresses the entire English language (such as a dictionary, style guide, or grammar book) supporting this claim. Citations from standards are useless, since standards only apply to those who explicitly choose to adopt them, or when the standard is adopted by law.
Alternatively, propose on Village Pump that Wikipedia declare a policy that all numeric dates must adhere to ISO 8601:2004 and see how far you get. -- Jc3s5h ( talk) 22:19, 23 September 2009 (UTC)
How say we just start one of those table-style RfCs (last used on IEC prefixes) where we all just register our opinion on some wording. If I’m reading A. di M.’s recent post correctly, I see he is now supportive of simply using A.P. months for parentheticals and three-letter abbreviations for tables. Why don’t we then have an up/down RfC (or, as wjemather might claim, “a !vote”) on Second pink‑div, above? Greg L ( talk) 23:51, 23 September 2009 (UTC)
Date and time (UTC) |
Time (local) |
Lat. | Long. | Depth | Mag. |
---|---|---|---|---|---|
30 Mar 2009 13:38:39.3 | 15:38:39.3 | 42.33° N | 13.35° E | 2 km (1 mi) | 4.4 (Mw) |
05 Apr 2009 20:48:56.4 | 22:48:56.4 | 42.36° N | 13.37° E | 2 km (1 mi) | 4.0 (ML) |
06 Apr 2009 01:32:41.4 | 03:32:41.4 | 42.38° N | 13.32° E | 2 km (1 mi) | 6.3 (Mw) |
06 Apr 2009 02:27:48.2 | 04:27:48.2 | 42.37° N | 13.23° E | 2 km (1 mi) | 4.3 (mb) |
06 Apr 2009 02:37:05.3 | 04:37:05.3 | 42.41° N | 13.32° E | 2 km (1 mi) | 5.1 (Mw) |
06 Apr 2009 03:56:48.1 | 05:56:48.1 | 42.38° N | 13.34° E | 10 km (6 mi) | 4.5 (mb) |
06 Apr 2009 07:17:16.1 | 09:17:16.1 | 42.47° N | 13.40° E | 30 km (19 mi) | 4.4 (mb) |
06 Apr 2009 16:38:10.7 | 18:38:10.7 | 42.38° N | 13.32° E | 2 km (1 mi) | 4.4 (Mw) |
06 Apr 2009 23:15:37.7 | 01:15:37.7 | 42.48° N | 13.41° E | 2 km (1 mi) | 5.1 (Mw) |
07 Apr 2009 09:26:30.7 | 11:26:30.7 | 42.31° N | 13.35° E | 10 km (6 mi) | 5.0 (Mw) |
07 Apr 2009 17:47:38.3 | 19:47:38.3 | 42.30° N | 13.40° E | 13 km (8 mi) | 5.6 (Mw) |
07 Apr 2009 21:34:30.9 | 23:34:30.9 | 42.34° N | 13.37° E | 2 km (1 mi) | 4.5 (mb) |
08 Apr 2009 04:27:42.5 | 06:27:42.5 | 42.30° N | 13.43° E | 2 km (1 mi) | 4.0 (ML) |
08 Apr 2009 22:56:51.0 | 00:56:51.0 | 42.55° N | 13.34° E | 2 km (1 mi) | 4.1 (Mw) |
09 Apr 2009 00:53:00.6 | 02:53:00.6 | 42.53° N | 13.39° E | 2 km (1 mi) | 5.4 (Mw) |
09 Apr 2009 03:14:52.7 | 05:14:52.7 | 42.35° N | 13.46° E | 2 km (1 mi) | 4.3 (mb) |
09 Apr 2009 04:32:46.0 | 06:32:46.0 | 42.45° N | 13.39° E | 2 km (1 mi) | 4.3 (mb) |
09 Apr 2009 04:43:12.3 | 06:43:12.3 | 42.52° N | 13.34° E | 10 km (6 mi) | 4.0 (ML) |
09 Apr 2009 13:19:35.8 | 15:19:35.8 | 42.33° N | 13.23° E | 40 km (25 mi) | 4.0 (ML) |
09 Apr 2009 19:38:17.4 | 21:38:17.4 | 42.52° N | 13.35° E | 2 km (1 mi) | 5.2 (Mw) |
10 Apr 2009 03:22:23.6 | 05:22:23.6 | 42.49° N | 13.42° E | 2 km (1 mi) | 4.0 (mb) |
13 Apr 2009 21:14:25.7 | 23:14:25.7 | 42.55° N | 13.42° E | 2 km (1 mi) | 5.1 (Mw) |
14 Apr 2009 20:17:28.9 | 22:17:28.9 | 42.55° N | 13.23° E | 10 km (6 mi) | 4.0 (ML) |
15 Apr 2009 22:53:08.7 | 00:53:08.7 | 42.54° N | 13.28° E | 2 km (1 mi) | 4.0 (ML) |
23 Apr 2009 15:14:10.6 | 17:14:10.6 | 42.22° N | 13.44° E | 10 km (6 mi) | 4.0 (ML) |
23 Apr 2009 21:49:01.0 | 23:49:01.0 | 42.24° N | 13.48° E | 2 km (1 mi) | 4.3 (Mw) |
22 Jun 2009 20:58:40.3 | 22:58:40.3 | 42.44° N | 13.29° E | 2 km (1 mi) | 4.7 (Mw) |
03 Jul 2009 11:03:09.0 | 13:03:09.0 | 42.38° N | 13.32° E | 2 km (1 mi) | 4.1 (ML) |
-- Alarics ( talk) 16:34, 24 September 2009 (UTC)
(edit conflict)
Ah… splendid. Some real-world examples. Yes; the cited example is nothing but a sea of data that isn’t intended to instantly communicate a particular thought. It is a table of particular events and attributes that one must inspect and carefully parse if they want to extract anything meaningful. And if ISO / BIPM / IACUC / UFOP-formatted dates were limited to stuff tables this, I could be a peace.
But let’s examine for a moment, whether doing this practice actually best serves the interests of our readers, or if it is nothing more than an method of what best appeals to our inner Jonny Quests. Let’s say that there is a particular whopper of an earthquake that occurred in June that knocked down a childrens’ hospital. Quick… go find it. Ready… set… GO.
Date (YYYY-MM-DD) and time (UTC) |
Time (local) |
Lat. | Long. | Depth | Mag. |
---|---|---|---|---|---|
2009-03-30 13:38:39.3 | 15:38:39.3 | 42.33° N | 13.35° E | 2 km (1 mi) | 4.4 (Mw) |
2009-04-07 17:47:38.3 | 19:47:38.3 | 42.30° N | 13.40° E | 13 km (8 mi) | 5.6 (Mw) |
2009-04-07 21:34:30.9 | 23:34:30.9 | 42.34° N | 13.37° E | 2 km (1 mi) | 4.5 (mb) |
2009-04-08 04:27:42.5 | 06:27:42.5 | 42.30° N | 13.43° E | 2 km (1 mi) | 4.0 (ML) |
2009-04-15 22:53:08.7 | 00:53:08.7 | 42.54° N | 13.28° E | 2 km (1 mi) | 4.0 (ML) |
2009-04-23 15:14:10.6 | 17:14:10.6 | 42.22° N | 13.44° E | 10 km (6 mi) | 4.0 (ML) |
2009-04-23 21:49:01.0 | 23:49:01.0 | 42.24° N | 13.48° E | 2 km (1 mi) | 4.3 (Mw) |
2009-06-22 20:58:40.3 | 22:58:40.3 | 42.44° N | 13.29° E | 2 km (1 mi) | 4.7 (Mw) |
2009-07-03 11:03:09.0 | 13:03:09.0 | 42.38° N | 13.32° E | 2 km (1 mi) | 4.1 (ML) |
Date and time (UTC) |
Time (local) |
Lat. | Long. | Depth | Mag. |
---|---|---|---|---|---|
30 Feb 2009 13:38:39.3 | 15:38:39.3 | 42.33° N | 13.35° E | 2 km (1 mi) | 4.4 (Mw) |
7 Apr 2009 17:47:38.3 | 19:47:38.3 | 42.30° N | 13.40° E | 13 km (8 mi) | 5.6 (Mw) |
7 Apr 2009 21:34:30.9 | 23:34:30.9 | 42.34° N | 13.37° E | 2 km (1 mi) | 4.5 (mb) |
8 Apr 2009 04:27:42.5 | 06:27:42.5 | 42.30° N | 13.43° E | 2 km (1 mi) | 4.0 (ML) |
15 Apr 2009 22:53:08.7 | 00:53:08.7 | 42.54° N | 13.28° E | 2 km (1 mi) | 4.0 (ML) |
23 Apr 2009 15:14:10.6 | 17:14:10.6 | 42.22° N | 13.44° E | 10 km (6 mi) | 4.0 (ML) |
23 Apr 2009 21:49:01.0 | 23:49:01.0 | 42.24° N | 13.48° E | 2 km (1 mi) | 4.3 (Mw) |
22 Jun 2009 20:58:40.3 | 22:58:40.3 | 42.44° N | 13.29° E | 2 km (1 mi) | 4.7 (Mw) |
3 Jul 2009 11:03:09.0 | 13:03:09.0 | 42.38° N | 13.32° E | 2 km (1 mi) | 4.1 (ML) |
I see that the table with the abbreviated form takes up several pixels more. That, of course, is a meaningless difference in an all-digital, adjustable-everything, electronic encyclopedia. The advantages as far as readability when readers are interested in a particular earthquake? Priceless.
When I was doing mechanical engineering at a fuel cell company and these young engineers would get lazy and let their CAD programs automatically dimension an entire print, I used to call the resulting output “data ralphs.” Any good encyclopedia, rather than take a USGS data-ralph and publish it raw, would properly spend a moment and clean up that which can be cleaned up to make it easier for readers to deal with. Greg L ( talk) 16:37, 24 September 2009 (UTC)
I agree that your method too is perfectly fine. You and I think alike. There is no reason in the world to not massage the dates to human-readable form; particularly where the first column of dates is the chronological index organizing the data.
Technical writing is about communicating clearly and easily, not about appealing to a few editors’ notion of what makes sense because this-n-that date format is “unambiguous since one doesn’t need to specify whether or not the date is given in the Gregorian calendar system”. Some things, like how modern dates always use the Gregorian calendar, are a given and no one but a few Wikipedia editors who are busy promoting their favorite all-numeric date format ever question such things. I prefer common sense technical-writing practices, myself. Greg L ( talk) 16:48, 24 September 2009 (UTC)
Analysing all the comments made in the past few weeks (including those now archived at
Wikipedia talk:Manual of Style (dates and numbers)/Archive 125, there appear to be broadly three main strands of opinion:
(A) In favour of YYYY-MM-DD in footnotes and tables.
Cavrdg, Darxus, Denimadept, LeadSongDog, Offliner, RockyMtnGuy,
TheFeds[See below.
TheFeds, wjemather.
Total: 7 editors.
(B) Prepared to see YYYY-MM-DD in some tables, but not in footnotes.
A. di M., Headbomb, HWV258, Ohconfucius, Rich Farmbrough, Septentrionalis, Sssoul, Woodstone.
Total: 8 editors.
(C) Opposed to YYYY-MM-DD anywhere.
Alarics, Dabomb87, Debresser, Greg L, gu1dry, Jc3s5h, Jimp, Pfainuk, Shakescene, Tony1, VMAsNYC.
Total: 11 editors.
So, adding (B) and (C) together, we have 19 editors who oppose the use of YYYY-MM-DD in footnotes, against 8 who are in favour of it. Does that constitute a consensus on that particular point? If so, can we move forward with that, and leave the other, more contentious issues to one side? --
Alarics (
talk)
19:07, 25 September 2009 (UTC)
It seems to me that many of those who oppose total deprecation of the YYYY-MM-DD make assertions that the form is unambiguous, whereas “9 November, 2009” is ambiguous (citing at times, that this is because it somehow doesn’t specify whether it is based on the modern Gregorian calender). Just because absurd arguments can be advanced, doesn’t mean they carry the same weight as common-sense ones.
Another argument is that is endlessly repeated is that YYYY-MM-DD mustn’t be deprecated because it works well in tables and footnotes. But, since “09 Nov 2009” and/or “9 Nov 2009” also work, that argument carries no weight either.
One simply must include an evaluation of the total weight of the logical shortcomings and strengths on both sides of the issue because some editors will endlessly make assertions that make no logical sense for no other reason that they like the way they do their edits and don’t want to change or have someone later change their work. Others (though they will seldom admit it) believe that their particular practice might gain traction with the world if it is used here. But, as was amply demonstrated with Wikipedia’s three-year-long trial with terminology like “kibibyte” and “mebibyte” (which to this day, my spell-checker still flags), stupid technical writing practices don’t become wise technical writing practices that the world starts adopting simply because they appear on Wikipedia.
The final straw that breaks the camel’s back here, IMO, is that some editors cite how Wikipedia is an *international* English-language encyclopedia. But then, so too is Encyclopedia Britannica. Frankly, I think it is wisest to follow the practices of E.B., which always writes out the name of the month and never uses all-numeric dates. Why? Well, E.B. is inhabited by professional copy editors who invariably posses advanced journalism degrees. I therefore place greater credence in the opinion of those editors on this subject than I do with some of the all-volunteer editors who inhabit Wikipedia. Greg L ( talk) 21:19, 25 September 2009 (UTC)
Earth calling LSD: This is en.Wikipedia. It is written and optimized for readers for whom English is their first language. As for those readers for whom English is their second language we’ve got Wikipedias in 271 other languages, all optimized for each language and/or country with their own numbering systems, alphabets, everything. In short: Being that this the English-language version of Wikipedia, we’ll be sticking to the manuals of styles suitable for English—thank you very much—and won’t be running off on some home-baked tangent that flouts common sense on the pretense that you can do a five-minute Google search and find an African tribe that keeps track of dates by counting the scars they carve into their bodies. So…
Just pardon me all over the place for treating en.Wikipedia as an “English-only enterprise.” I’m much obliged for your assistance in proving my point regarding how “one also looks at the consistency of the arguments on both sides and considers the logical ramifications of it all.” Greg L ( talk) 00:14, 26 September 2009 (UTC)
In response to Greg's points:
←outdent (and ignoring wjemather’ rant)
Oh, and quoting LeadSongDog again: Since Britannica keeps coming up as the example to follow, I'll note that they too use descending significance all-numeric dates on their Japanese and Korean websites. Have you not heard of Google “Language tools”? I have. Here’s the English-language translation of the Japanese version of Encyclopedia Britannica. Note that they spell out the months: August 11, 2009; May 14, 2009 ; and another instance of May 14, 2009. Are you trying to help your cause or hurt it? Anyway…
I think we can limit our discussion to Encyclopedia Britannica’s *English-language* practices, can’t we? And, more to the point, I’d like to see you or anyone else advance a plausible sounding argument as to why the English-language version of Wikipedia (which is read internationally) has a compelling need to depart from standard encyclopedic practices observed by World Book and Encyclopedia Britannica both of which can also be found in libraries and homes (*sound of blair trumpets*) “INTERNATIONALLY”. The same goes for the Associated Press manual of style, which is observed by some 99% of the English-language newspapers published throughout the international community. Greg L ( talk) 00:36, 26 September 2009 (UTC)
-- ___A. di M. 12:07, 26 September 2009 (UTC)
Perhaps the practice of “deprecating” the YYYY-MM-DD” form shouldn’t happen because there are editors here who will always think they know better than professionals and get panicked whenever threatened with the prospect of no longer being permitted to do something they “like-ta” do. Isn’t that what en.Wikipedia is for(?): to provide a venue where editors who no advanced training in journalism and technical writing try to advance reasons for not looking towards the manuals of style produced by the professionals because they’ve *got it all figured out* and know better than the pros?
Arguments from some of the above editors are predicated on the false premise that en.Wikipedia presents some sort of unique circumstance and they are applying their amazing powers of astute observation and unflagging logic to deal with the situation. While no-doubt good for their sense of self-esteem, their arguments are illogical and/or unfounded. Many of these absurd arguments are predicated on the earth-shaking realization that some of en.Wikipedia’s readership speaks English as a second language. All these arguments are 100%, utter and absolute nonsense and have no bearing on the discussion since all the top English-language newspapers, magazines, and print encyclopedias also have a vast readership for whom English is their second language. Does that surprise anyone here?
Arguments that some of these readers for whom English is their second language read the English-language version of Wikipedia because it is more comprehensive, and this somehow constitutes a reason for us to depart from standard English-language rules of technical writing style are similarly utter and complete nonsense. Why? For many of the world’s languages, their print encyclopedias also suck in comparison to things like en.Wikipedia and Encyclopedia Britannica (or, in many cases, don’t even exist. At least those who speak Esperanto have eo.Wikipedia).
So, while “deprecation” might be too strong, it would be nice if we didn’t end up completely turning our backs on Technical Writing 101 common sense and *promote* the practice of using three-letter abbreviations for months in tables—as shown in Son of, above. It’s clear to anyone with the common sense that God gave a goose that dates with months written out are easier to read and look better than a sea of numbers in a format that no one in real life uses outside of USGS “data‑ralphs” and attendance forms at Star Trek conventions. Does that much surprise anyone? Or is the electronic white-space provided below going to be used for someone to spout about how 2009-04-07 17:47:38.3 “reads real purdy” and ought to spread like wildfire across the land? Greg L ( talk) 16:03, 26 September 2009 (UTC)
Seriously; I insist that you answer that question about the percent sign before you shovel more of your metric ton of weapons-grade bullonium that is all founded on the false premiss that Wikipedia is somehow unique in its being looked to by non-native English speakers; It isn’t. Greg L ( talk) 19:29, 26 September 2009 (UTC)
Comment. When recommendation are truly absurd, people just ignore them. Once upon a time, MOSNUM said: "Very large numbers may be divided up by commas every three places (e.g.: 2,900,000), starting from the decimal separator in both directions [emphasis added]." That'd mean one should write the number of square metres in an acre as 4,046.856,422,4. Of course, I've never seen such a format, on Wikipedia or elsewhere. I think I have seen other example of obviously silly rules which were just ignored, though I can't recall any one right now. If people are not treating the suggestion to use YYYY-MM-DD in "long lists and tables" the same way as they were treating the suggestion to use commas after the point, that means that they consider it less absurd. -- ___A. di M. 10:03, 27 September 2009 (UTC)
<profound awe>
international standard</profound awe>
that had been washed in unicorn tears and anointed with holy oil from the technology gods. Never mind that the entire computer industry as well as the computer magazine industry as well as all encyclopedias didn’t adopt the IEC prefixes, Wikipedia was going to use terminology that was unfamiliar to readers because (“they’ll learn it easily enough,“ “it’s an *international standard,” “we are electronic and have links,” “it’s logical and everyone can figure out what it means,” etc.).Similarly, there appears to be an editor who was logging out to do I.P. edits on the ISO 8601 article to make it say that the standard was intended to apply to “internal, personal, hand-written notes (“Mom, I’ll be home by 2009-11-09T11:20 after the Star Trek convention lets out”). Such highly *motivated* editors can be exceedingly difficult to revert and the work of a single editor can spread like lung cancer across Wikipedia.
The common theme between the IEC prefix cabal and those who promote “2009-11-09T11:20” for use on Wikipedia is that they are perfectly willing to ignore the common-sense principles of clear technical writing and don’t care what practice is common in the real-world; they are *believers in the cause* and think our use of the practice here will lead to more general adoption in the real world. After three long years confusing readers and making Wikipedia’s computer-related articles look like they had been authored by 15-year-old fools, our experiment with the IEC prefixes proved that this mindset was nothing more than wishful thinking of those who don’t understand the fundamental principles of how to write clear, encyclopedic prose. So…
Though a practice may be stupid and you think few will follow stupid advise on MOSNUM (you might well be right), having any unwise practice sanctified on MOSNUM is just that: unwise. Why? Because, though not too many may follow it, all it takes is a handful of editors to make a lot of crappy looking stuff on Wikipedia; all they have to do is point to MOSNUM to say it is officially sanctified and that the practice has been blessed by the ISO gods. Greg L ( talk) 16:38, 27 September 2009 (UTC)
Analysing all the comments made in the past few weeks (including those now archived at Wikipedia talk:Manual of Style (dates and numbers)/Archive 125, there appear to be broadly three main strands of opinion (this is necessarily a crude measure, but it gives a rough idea of the weight of views):
(A) In favour of YYYY-MM-DD in footnotes and tables.
Cavrdg, Darxus, Denimadept, LeadSongDog, Offliner, RockyMtnGuy, Vegaswikian, wjemather, Woodstone.
Total: 8 9 editors.
(B) Prepared to see YYYY-MM-DD in some tables, but not in footnotes.
A. di M., Headbomb, HWV258, Ohconfucius, Rich Farmbrough, Septentrionalis, Sssoul[see below], Woodstone[see above].
Total: 8 7 6 editors.
(C) Opposed to YYYY-MM-DD anywhere.
Alarics, Dabomb87, Debresser, Greg L, gu1dry, Jc3s5h, Jimp, Pfainuk, Redrose64, Shakescene, Tony1, VMAsNYC.
Total: 11 12 editors.
Clearly, there is no consensus for deprecating YYYY-MM-DD altogether. But, adding (B) and (C) together, we have 19 18 17 18 editors who oppose the use of YYYY-MM-DD in footnotes, against 8 9 who are in favour of it. Does that constitute a consensus on that particular point? If so, can we move forward with that, and leave the other, more contentious issues to one side? I would like to get agreement on just this narrow question -- YYYY-MM-DD in footnotes -- without going over all the arguments again. I'd be grateful if any further discussion beyond this point is about the practicalities of taking the matter forward, not on the substantive issue. If people really want to carry on going over the arguments again on the substantive issue, perhaps they could do so above this subsection. --
Alarics (
talk)
19:07, 25 September 2009 (UTC)
A real-world sample. I did not participate in the above discussion, but (for other reasons, having to do with HTML conformance of citations) I happen to have been reviewing the ten articles most recently nominated for Featured Article status. These are articles that reflect recent activity in article improvement, and by and large they are in pretty good shape (though obviously not featured yet). Of these ten articles, six use YYYY-MM-DD dates in footnotes, and four do not. The six that use YYYY-MM-DD are Well Dunn, Trump International Hotel and Tower (Chicago), Sydney Riot of 1879, Anarchy Online, Ethan Hawke, and John Tavares (ice hockey). The four that do not use YYYY-MM-DD, along with the styles they use in parentheses, are Neverwinter Nights 2: Mysteries of Westgate ("September 24, 2009"), Tiananmen Square self-immolation incident ("4 October 2007"), Bramall Hall ("12 September 2009"), and 1982 British Army Gazelle friendly fire incident ("19 November 2008"). Admittedly this is a small sample, but it was chosen sort-of-at-random from pretty-good recent articles. In this sample of recent articles, YYYY-MM-DD style is used in footnotes by more than half the articles, and it's used by twice as many articles as the next most-popular date style. I therefore suggest that the real-world consensus (as opposed to the consensus on this page) is strongly in favor of allowing YYYY-MM-DD in footnotes, though there is obviously not a consensus in requiring YYYY-MM-DD. Eubulides ( talk) 08:54, 26 September 2009 (UTC)
[PLEASE don't add further comments here on the substantive issue; they go in the previous subsection. I meant THIS subsection to be about the procedural issue of what do we do now.] -- Alarics ( talk) 19:32, 26 September 2009 (UTC)
I think that based on this discussion we may remove any advise to use the YYYY-MM-DD or ISO 8601 (or whatever else looks like it) whereever we find it. With exeption of what it says here on the project page "YYYY-MM-DD style dates (1976-05-31) are uncommon in English prose, and should not be used within sentences. However, they may be useful in long lists and tables for conciseness." That would be a good start and seems uncontroversial for all points of view. Debresser ( talk) 21:27, 26 September 2009 (UTC)
Note: the Google counts above double counts 12/31/08 and 31/12/08 . Note also that Google is too smart. On the first page of 01/01/09 we find "Coney Island Polar Bear Plunge 1-1-09 Philip Kiracofe Video". Rich Farmbrough, 11:39, 27 September 2009 (UTC).
Responding to Debresser's point above: No, the "However, they may be useful in long lists and tables for conciseness." bit is not uncontroversial. A number of us are arguing that YYYY-MM-DD are not useful on WP at all and that the difference in conciseness between them & three-letter dates is insignificant. JIMp talk· cont 15:53, 27 September 2009 (UTC)
Fathers aside, YYYY-MM-DD and YYYY-MMM-DD are both widely used in Canada, particularly on government documents, both geeky and non-geeky. Canada also uses DMY & MDY (each in at least 3 forms), and all checks must now indicate which style is being used-- JimWae ( talk) 20:19, 27 September 2009 (UTC)
{{
dts}}
{{
dts|2009|September|28}}
, {{
dts|2009-09-28}}
, {{
dts|September 28, 2009}}
and {{
dts|28 September 2009}}
are all valid and give identical behaviour when sorted. Therefore, should it be necessary for |accessdate=
to be parsable (and I've yet to see a reason for requiring that), the same code as used by {{
dts}}
to derive <span style="display:none">2009-09-28</span>
could be utilised. Or there's {{
Start date}}
. The point is, that forcing the |accessdate=
to appear in different format to all the other dates is jarring. --
Redrose64 (
talk)
10:51, 28 September 2009 (UTC)
I think it infinitely clear that the professional editors in the editorial rooms of fine encyclopedias, when they are pondering how best to communicate dates to readers, don’t ask “well, what computer-readable, all-numeric format is used on Canadian bank checks?” So… Have we developed a consensus to use machine-readable date formats only where machines (Wikipedia’s servers) need to understand dates, and to ensure dates are rendered in human-readable form for the humans? You know, where…
None of this is technical-writing rocket science. Why is so much discussion transpiring on an issue that is so easily solved? Greg L ( talk) 19:46, 28 September 2009 (UTC)
, Sep 9, 9:26:03.2
. 9 Sep 2009
___A. di M.
11:51, 1 October 2009 (UTC)There is obviously no consensus to ban yyyy-mm-dd formats in citations. Also, many of the above comments seem to be based on incorrect assumptions. Please see #Real world often uses yyyy-mm-dd in citations below. Eubulides ( talk) 09:21, 29 September 2009 (UTC)
Several of the comments in the above thread seem to be based on the incorrect assumption that yyyy-mm-dd dates are a Wikipedia eccentricity, and that such dates do not appear in style guides and by and large do not appear in real-world scholarly sources. This assumption is incorrect.
URL: http://www.healthypeople.gov/Document/tableofcontents.htm#Volume2 [accessed 2008-10-24]
{{
cite journal}}
: CS1 maint: multiple names: authors list (
link)http://www.baltic21. org/ reports/indicators/fo01a.htm (Accessed 2009 04 26)
{{
cite journal}}
: CS1 maint: numeric names: authors list (
link)(http://ecdc.europa.eu/en/Health_Topics/ebola_marburg_fevers/Article_20080805.aspx accessed 2009-01-24)
{{
cite journal}}
: CS1 maint: multiple names: authors list (
link)http://www.nr.no/pages/dart/project_ flyer_mariage, accessed 2009-02-25
{{
cite journal}}
: CS1 maint: multiple names: authors list (
link)International Telecommunications Union, http://www.itu.int/ITUD/ict/newslog/South+Africa+Mobile+Penetration+Edges+Towards+100.aspx (accessed 2009-01-12)
{{
cite book}}
: |journal=
ignored (
help)http://bt.pa.msu.edu/index cosy.htm, accessed 2008-09-13
Eubulides ( talk) 09:21, 29 September 2009 (UTC)
Eubulides, it's nothing to do with WP:IDONTLIKEIT. Several people have said they find YYYY-MM-DD ambiguous. If the thing is an obstacle to understanding (because some people find it ambiguous), then we shouldn't be using it. It's as simple as that. -- Alarics ( talk) 21:19, 29 September 2009 (UTC)
Excuse me. I couldn’t participate in this all day until just now. I spent the day trying to find my copy of ISO 8601. I just couldn’t find it. So I went next door. My neighbor manages a K-mart store and you’d think he’d be sophisticated enough to have a copy. But he didn’t. Not even when he climbed his sideways-rolling ladder in his wood-paneled library to access the top shelves. It just couldn’t be found. Then I called my brother, who taught journalism at a university. Funny… not only did he not have a copy, he didn’t even know anything about ISO 8601, ISO 690 or any of these other international standards that editors here are proudly flaunting with their chests puffed out with immense pride. It appears we’ve got a few editors here debating about proper technical writing practices, but their arguments are predicated upon technical nuances that exceedingly few people have the faintest clue about.
Now, I see editors making the argument that YYYY-MM-DD intrinsically references only Gregorian dates (at least to the extent that any exhibition of YYY-MM-DD can be presumed to be necessarily conforming to the ISO 8601 standard). My question is this: So what? Writing out a date in an all-numeric format of any form doesn’t make anything clearer with regard to the distinction between Gregorian and Julian dates for 99.99% of our readership. In fact, over 99% of our readership doesn’t even know there is a difference between Julian and Gregorian calendars.
If there is a Julian date to some event or document that needs to be cited, just write out the month and place a parenthetical “Julian date” at the end of it. You know… we would actually communicate <audience gasp>
clearly</audience gasp>
and desist with trying to make a rational sounding argument that would require us to pretend that the vast majority of our readership is some sort of
brainiac
George Jetson with a Ph.D. (BTW, I was, of course, joking about going next door to my neighbor and to my brother. But I do invite any of the above editors who are spouting about these standards to please tell us just who amongst their friends, families, and associates has a copy of ISO 8601 and/or ISO 690 and is familiar with their scope and what connotations these *standards* have with regard to Julian and Gregorian dates. All the above debate just proves to me that some editors here are more interested in showing how smart they are about damned standards but have mighty little interest in writing clearly. That’s my honest take; so shoot me.)
Greg L (
talk)
04:37, 30 September 2009 (UTC)
This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 120 | ← | Archive 124 | Archive 125 | Archive 126 | Archive 127 | Archive 128 | → | Archive 130 |
A few weeks ago there was extensive discussion on FAC talk about the vast size, complexity and instability of the Manual of Style. On reviewing the text of the MoS, I agree that the Manual is much larger than necessary to cover the areas it does: about 20 thousand words. In particular:
As a service to featured-content nominators and reviewers, and editors at larger, I've created a new, user-friendly version of the MoS that is only 40% of the size of the full version. There are no intended changes in substantive meaning. The new version has the following features:
Any changes to the full MoS as reflected in the new version will be notified, at the start of each month. Your feedback is welcome on the talk page. Tony (talk) 03:04, 16 September 2009 (UTC)
This section has been moved to Wikipedia_talk:Manual_of_Style_(dates_and_numbers)/Datestempprotectedsection, as this page is more relevant to the request. |
Jc3s5h, your edits were contrary to the results of the RfC you yourself conducted here on Archive 123. The {val} template was the result of very lenghty, months-long discussions by very many editors on both WT:MOS and WT:MOSNUM.
{Val} (originally known as “Delimitnum”) had its functionality described here in WT:MOSNUM Archive 94…
…it was extensively discussed and voted upon here in WT:MOSNUM Archive 94…
…and was well received here on WT:MOS Archive 97…
…where its functionality was tweaked to achieve a compromise solution that made everyone happy on an issue regarding the look of scientific notation.
Then a number of developers and template authors worked on it.
Please don’t presume that you can come along and change it without a proper consensus. Greg L ( talk) 17:17, 18 August 2009 (UTC)
This practice of “your way / my way… it’s all just six of one / half a dozen of the other” doesn’t apply to numbers. Why? Wikipedia has gone through all this before many times, and new editors who come here don’t have the benefit of all that history and discussion. But it comes down to this: English-speaking Europeans are familiar and comfortable with a many different ways of delimiting numbers and the American style causes them no confusion whatsoever. Comma-delimiting might not be the most common practice for English-speaking Europeans, but they recognize what it means and fully understand the numbers. However, Americans are familiar with one and only one method; as a group, they have had no exposure whatsoever to other ways of delimiting numbers. So, especially for general-interest articles, in order to cause the least confusion, the American method of using commas to the left of the decimal point is to be used on Wikipedia. Scientific articles; particularly ones directed to a professional readership, are the only exception.
The argument that “Well, Wikipedia will just start using the Euro/BIPM method and dumb-ass Americans will simply learn” just doesn’t fly and it never will. Wikipedia doesn’t have that kind of influence; all that sort of attitude does is produce confusion. Our aborted attempt to push the world into the adoption of the IEC prefixes (kibibytes and KiB) amply demonstrated that. After three long years, the practice was no more well adopted throughout the world than before. All Wikipedia accomplished by letting itself by hijacked by a handful of editors who wanted to push the world into a new and brighter future with warp drive and membership in the United Federation of Planets™®© was to make our computer-related articles needlessly confusing. We follow the way the world works and can not presume to lead by example.
We can’t have MOSNUM subtly edited in a fashion that tacitly allows numbers in articles, other than science-related ones, to be delimited with thinspaces in place of commas to the left of the decimal point; it is unnecessarily confusing to too many readers. This is the way it has long been done and there has been no decision to change the practice.
As for delimiting with gaps to the right of the decimal point using {val} on high-precision numbers, particularly in engineering and scientific-related contexts where the distinction between numbers is important and the values actually have to be parsed and understood, that confuses absolutely no one—even “sheltered Americans”. A value like 1.6162523625×10−35 meters is no more confusing than the decidedly non-SI-compliant, five-digit delimiting used for mathematical constants (particularly in tables of constants), such as 3.141592653589793238462643383279...; everyone instantly “gets” it. It is a much-appreciated and much-needed touch that makes long strings of digits much easier to parse. Moreover, its technique of using thinspaces to the right is the only possible method that could be employed to solve the problem of long strings without upsetting the apple cart; it was either do nothing (and have absurdly long strings that can’t easily be parsed) or utilize the only logical available technique. Greg L ( talk) 18:28, 18 August 2009 (UTC)
(unindent) When Pmanderson asks whether the present use of may be, I surmise he is asking about this section:
- Numbers with more than four digits to the right of the decimal point, particularly those in engineering and science where distinctions between different values are important, may be separated (delimited) into groups using the {{ val}} template, which uses character-positioning techniques rather than distinct characters to form groups. Per ISO convention (observed by the NIST and the BIPM), it is customary to not leave a single digit at the end, thus the last group comprises two, three, or four digits. Accordingly, the recommended progression on Wikipedia is as follows: 1.123, 1.1234, 1.12345, 1.123456, 1.1234567, 1.12345678, 1.123456789, etc. Note that {{val}} handles these grouping details automatically; e.g.
{{val|1.1234567}}
generates 1.1234567 (with a four-digit group at the end). The {{val}} template can parse no more than a total of 15 significant digits in the significand. For significands longer than this, editors should delimit high-precision values using the {{ gaps}} template; e.g.{{gaps|1.234|567|890|123|45}}
→ 1.2345678901234567.
Let us set aside my objection to the 4046.8564224 format for the moment; whether my interpretation or Greg L's interpretation of consensus prevails will become apparent in due course. The present version of the guideline states, or at least strongly implies, that the Val template conforms to "ISO convention (observed by the NIST and the BIPM)", but the template at present does not conform to the ISO convention. Furthermore, every example in this section has exactly one digit to the left of the decimal, so the non-conformance is concealed.
This is a falsehood. I don't think it has been pointed out until now, so it is an innocent falsehood. But over time, as the falsehood becomes better understood among editors of this guideline, it could ripen into a lie. -- Jc3s5h ( talk) 00:28, 19 August 2009 (UTC)
Per ISO convention (observed by the NIST and the BIPM), it is customary to not leave a single digit at the end, thus the last group comprises two, three, or four digits.
IMHO, the objective on Wikipedia should always, always be about writing in a way that is clearest and causes the least confusion. There are many distasteful practices that come with that philosophy, including using feet and inches and pounds in American-related articles like Boston Red Sox. Too often, editors want to do things a certain way because… well… editors simply like doing it that way and always have done it that way. It ends up being more about writing to please the Wikipedian rather than do what is best for the readership. Greg L ( talk) 04:35, 19 August 2009 (UTC)
To resolve the issue I offer a two part proposal:
Part 1: {{
Val}} is altered so that by default, it produces commas to the left and no separation to the right of the decimal point (customary American style). A parameter is added, BIPM=y or yes
which produces thin space separators on both sides of the decimal point.
Part 2: The "Delimiting (groups of digits)" be altered to read as follows:
- Numbers with five or more digits to the left of the decimal point; i.e. 10,000 or more, should be delimited (separated into groups so they can be easily parsed visually) using commas every three digits; e.g. 12,200 and 255,200 and 8,274,527 etc. Exception: articles containing numbers with five or more digits to the right of the decimal point, e.g. 3.141593 (as such articles should delimit numbers as for scientific articles—described below).
- Numbers with four digits to the left of the decimal point may be delimited with a comma; that is, there were 1250 head of cattle and there were 1,250 head of cattle are both acceptable. The same exception as for five digits to the left of the decimal point applies.
- Numbers are not delimited when they are part of mailing and shipping addresses, page numbers, and years with four or fewer digits. Years with five or more digits (e.g. 10,400 BC) shall use commas.
- In scientific articles, particularly those directed to an expert readership, numbers may be delimited with thin spaces using the {{ gaps}} template. Coding
{{gaps|8|274|527}}
produces 8274527 (note: the thin space character and its HTML entity,, do not render correctly on some browsers). Articles containing numbers with five or more digits to the left of the decimal point should delimit numbers with thin spaces.
- The style of delimiting numbers should be consistent throughout an article.
- Mathematical constants in math-oriented articles may be grouped into groups of five; e.g. 3.141592653589793238462643383279....
- Numbers with more than four digits to the right of the decimal point, particularly those in engineering and science where distinctions between different values are important, may be separated (delimited) into groups using the {{ val}} template, with the BIPM parameter set to "y" or "yes"; {{ val}} uses character-positioning techniques rather than distinct characters to form groups. Per ISO convention (observed by the NIST and the BIPM), it is customary to not leave a single digit at the end, thus the last group comprises two, three, or four digits. Accordingly, the recommended progression on Wikipedia is as follows: 1.123, 1.1234, 1.12345, 1.123456, 1.1234567, 1.12345678, 1.123456789, etc. Note that {{val}} handles these grouping details automatically; e.g.
{{val|1.1234567}}
generates 1.1234567 (with a four-digit group at the end). The {{val}} template can parse no more than a total of 15 significant digits in the significand. For significands longer than this, editors should delimit high-precision values using the {{ gaps}} template; e.g.{{gaps|1.234|567|890|123|45}}
→ 1.2345678901234567. Also note that when the BIPM parameter is omitted, {{ val}} does not conform to the ISO/NIST/BIPM format; instead it uses the customary American format of grouping digits to the left of the decimal with commas, and not grouping digits to the right of the decimal.
-- Jc3s5h ( talk) 03:01, 19 August 2009 (UTC)
P.S. I’ve been to England, Scotland, Wales, Ireland, Antigua, Moroco, Spain, Monaco, France, Italy, Austria, and Hungary—and Canada, if you can count that as not being part of the U.S. ;-). Notwithstanding that I am American, I do all my engineering in hard metric. Have you been to the U.S.A? If so, how long? Because, as an engineer, I can assure you I have keen insight into what causes confusion in Americans. The current practices of Wikipedia were no accident. Greg L ( talk) 03:42, 19 August 2009 (UTC)
As for the proposal, it's on the right track—but let me raise some issues. I think the current text is a bit cumbersome, in that it has a lot of exceptions and places where the text diverges into subcases. I think we can state the exceptions a little more clearly, and make them general in application.
There's also the question of whether to treat the U.S. and BIPM delimiting schemes as similarly-acceptable, or not. I don't buy the idea that Americans don't understand the BIPM format—any literate English speaker ought to be able to figure out the meaning of either the U.S. customary or BIPM formats (or for that matter the meaning of an undelimited number), with minimal effort. (And for subsequent occurances, zero effort.) It's not a significant issue of understanding at all—it is straightforwardly stylistic. And given that an English-speaking Canadian or European would probably default to the BIPM format, and would certainly understand it, it's not appropriate to direct those users to use an unfamiliar method despite the conventions of English-language style that are typically employed in their regions. (It's the same can of worms as telling them to spell it color instead of colour, or vice versa.)
It also follows that there needs to be an exception for special regional contexts that would be unintelligible to the majority of English speakers, but which are still in widespread use. (This particular exception could use further discussion, and might be relevant in so few cases as to be omitted, but I'll suggest something below anyway.) For example: English is a second language of hundreds of millions of Indians, Pakistanis and Bangladeshis, and they often use the Indian numbering system when communicating in English. For articles specifically about an Indian topic, if we're to be faithful to the idea of avoiding regional bias, we have to acknowledge that their method is widespread enough to consider in the MOS.
There's also the matter of splitting the technical details out into their own subsection. I think things were getting a bit convoluted with the mixing of implementation details with stylistic concerns, so I think that we should separate them from the main text.
So with that in mind, I've spliced portions of the various versions of this section (by Greg L, Jc3s5h and myself) together, and come up with this:
===Digit grouping===
- In numbers with many digits, digit grouping symbols (inserted at intervals from the decimal point) are used to subdivide the number into easily readable groups. The acceptable digit grouping schemes are:
- Commas every three digits to the left of the decimal point, and thin, non-breaking spaces every three digits to the right of the decimal point (e.g. 8,274,527 or 0.12345). This is traditional usage in many English-language contexts, and recommended by the U.S. Government Printing Office.
- Thin, non-breaking spaces every three digits (e.g. 8274527 or 0.12345). This format is suggested in BIPM and NIST style guides for scientific and engineering works, and is in common use in interlanguage contexts.
- Mathematical constants in math-oriented articles may be grouped into groups of five digits on both sides of the decimal point; e.g. 3.141592653589793238462643383279....
- Other traditional digit grouping schemes, when relevant to the subject matter of the article; e.g. 82,74,527 in the Indian numbering system. (An explanation of the digit grouping scheme should be provided, typically by way of a link or brief summary. Also or instead, parenthetical conversions to another acceptable scheme may be used.)
- The style of grouping digits within numbers should be consistent throughout an article.
- When grouping digits by threes, and a number has exactly four digits on any side of the decimal separator, those digits may optionally be expressed as a group of four instead of three; e.g. both 9876 and 9,876 are acceptable.
- Digits are not grouped when they are part of addresses, page numbers, and years with four or fewer digits. However, years with five or more digits (e.g. 10,400 BC) are delimited as any other large number.
====Technical implementation====
The {{ gaps}} template uses CSS to output thin spaces (using the syntax
{{gaps|8|274|527}}
). Using HTML entities for this purpose (e.g.or
) may cause rendering problems in some browsers, and should be avoided when practical.
The {{ val}} template handles digit grouping automatically, in the American style (by default) or in the BIPM style (by using the
BIPM=y
parameter). In both cases, CSS is used to output the thin spaces. For example,{{val|1.1234567}}
generates 1.1234567 (with a four-digit group at the end). The {{val}} template can parse no more than a total of 15 significant digits in the significand. For significands longer than this, editors should manually delimit values using the {{ gaps}} template; e.g.{{gaps|1.234|567|890|123|45}}
→ 1.2345678901234567.
(unindent) As one of the guys who take care of the {{
val}} template, the sensible solution as far as the template is concerned is to leave the default behavior of {{
val}} as-is, because otherwise you will screw up a million articles and remove the ease of using {{
val}} in >90% of cases. Then for all those who hate gaps, or hate commas, two parameters can be added, |gaps=no (producing 1,232,345.0023234) and |commas=no (producing 1232345.0023234). You can then write exactly what you want, and you'll have the choice of picking whichever format is best suited for the article.
Headbomb {
ταλκ
κοντριβς –
WP Physics}
15:18, 19 August 2009 (UTC)
|gaps=no
and |commas=no
where appropriate.I'll go along with TheFeds proposal, once one technical issue is ironed out. This bullet:
is not compatible with the example 1.1234567 because the example has exactly seven digits to the right of the decimal, not four.
Also, the style implemented by {{ Val}} should really be called the GPO (Government Printing Office) style, because the prevalent American style is to not group digits to the right of the decimal point. (The Chicago Manual of Style is one publicaton that advocates no separation to the right of the decimal outside the realm of science and technology). -- Jc3s5h ( talk) 22:36, 20 August 2009 (UTC)
The current guideline reads, in part, as follows:
“ | Numbers with more than four digits to the right of the decimal point, particularly those in engineering and science where distinctions between different values are important… | ” |
===Digit grouping===
- In numbers with many digits, digit grouping symbols (inserted at intervals from the decimal point) are used to subdivide the number into easily readable groups. The acceptable digit grouping schemes are:
- Commas every three digits
to the left ofbefore the decimal point, andthin, non-breaking spaces every three digitsno delimitingto the right ofafter the decimal point (e.g. 8,274,527 or0.123450.12345). This is traditional usage in many English-language contexts, and recommended bythe U.S. Government Printing OfficeThe Chicago Manual of Style and the AP Stylebook for non-technical articles.- As above, but with thin, non-breaking spaces every three digits after the point (0.12345). This is recommended by by the United States Government Printing Office.
- Usually there is no difference between the two styles above, because non-technical articles should avoid using excessively precise values: see the second point in § Large numbers, below.
- Thin, non-breaking spaces every three digits (e.g. 8274527 or 0.12345). This format is suggested in BIPM and NIST style guides
for scientific and engineering works, and is in common use inand is in common use in scientific and engineering works and interlanguage contexts.
- In some major English-speaking countries, this format is unfamiliar most persons without advanced scientific or engineering education, so avoid using it when discussing general-interest topics.
- Mathematical constants in mathematics-oriented articles may be grouped into groups of five digits on both sides of the decimal point; e.g. 3.141592653589793238462643383279....
- Other traditional digit grouping schemes, when relevant to the subject matter of the article; e.g. 82,74,527 in the Indian numbering system. (An explanation of the digit grouping scheme should be provided, typically by way of a link or brief summary. Also or instead, parenthetical conversions to another acceptable scheme may be used.)
- The style of grouping digits within numbers should be consistent throughout an article.
- When grouping digits by threes, and a number has exactly four digits on
anyeither side of the decimal separator, those digits may optionally be expressed as a group of four instead of three; e.g. both 9876 and 9,876 are acceptable. Additionally, after the decimal point a final group of four digits can be grouped together, e.g. 0.1234567 or 0.1234567. The latter style is more common, and is recommended on Wikipedia.- Digits are not grouped when they are part of addresses, page numbers, and years with four or fewer digits. However, years with five or more digits (e.g.
10,400 BC10,000 BC) are delimited as any other large number.====Technical implementation====
The {{ gaps}} template uses CSS to output thin spaces (using the syntax
{{gaps|8|274|527}}
). Using the thin space character or its HTML entities for this purpose (e.g.or
) may cause rendering problems in some browsers, and should be avoided when practical.
The {{ val}} template handles digit grouping
automatically, in the American style (by default) or in the BIPM style (by using thein the U.S. GPO style automatically.BIPM=y
parameter)In both cases,CSS is used to output the thin spaces. For example,{{val|1.1234567}}
generates 1.1234567 (with a four-digit group at the end). The {{val}} template can parse no more than a total of 15 significant digits in the significand. For significands longer than this, editors should manually delimit values using the {{ gaps}} template; e.g.{{gaps|1.234|567|890|123|456}}
→ 1.234567890123456.
Differences from TheFeds' version are marked. -- ___A. di M. 11:15, 21 August 2009 (UTC)
The practice of grouping digits in this way is a matter of choice; it is not always followed in certain specialized applications such as engineering drawings, financial statements, and scripts to be read by a computer.
I’ve made this point numerous times, above, and the best counter-argument I’ve yet to see is a demand to see scientific proof or studies showing that alternative numbering formats would be confusing to Americans. Commons sense does not need to be legislated. This is hopeless. This is simply nothing more than an attempt by some Europeans, who are absolutely convinced that their BIPM-endorsed, European way is superior (perhaps it is) and should be adopted here on Wikipedia and dumb ol’ Americans will learn it here, if nowhere else. These editors need to drop this agenda to change what has long worked here. Wikipedia is not to be exploited as a vehicle to promote change by educating Americans to conventions with which they are entirely unfamiliar. The current guidelines are fine.
And, a final note: Just because something is endorsed by the BIPM doesn’t mean it enjoys world-wide adoption. The BIPM wants 75% written 75 %, but Americans (and as far as I know, no one else) don’t do it that way so Wikipedia goes with the flow and ignores the BIPM so we don’t confuse people for God’s sake. Greg L ( talk) 23:35, 21 August 2009 (UTC)
As someone who has lived in France for many years, I am familiar with that convention. It appeared bizarre to me when I first arrived there. Now it is pointed out that this is also adopted in some scientific contexts. Before this is imposed on the unwitting WP public, I would point out that it is a convention I have never seen before in the Anglo-Saxon world. Being able to understand it is one thing, but to insist that this professional technical standard be adopted in any form in a general knowledge encyclopaedia is quite another. - BTW, the French also use the comma in place of the period as the decimal delimiter. Even if we were not to adopt this last 'quirk', it is unlikely to find widespread acceptance. Implementation is likely to meet with bewilderment, and be universally reverted to the comma delimiter which all English-speakers are familiar with. Ohconfucius ( talk) 06:37, 22 August 2009 (UTC)
To consider an analgous case, an American reading about a boot and a bonnet might picture articles of clothing, rather than car parts—yet we would not expect articles to generally defer to the American's preferred vocabulary, even though Britons are somewhat accustomed to American vocabulary (e.g. because of the pervasiveness of American culture and media in Britain, vs. the opposite), and would grudgingly understand "trunk" or "hood" in the context of an automobile. In fact, with numbers, at least there's a contextual clue to the meaning—the numerals are the same, after all. With "boot" vs. "trunk", we have to resort to things like linking the first occurrance, to avoid misunderstandings; the case of dialect is more, not less confusing than numbering style. Yet despite that slight inconvenience, the well-established principle is to accept such regional eccentricities as part of the language, and accomodate them in the interest of avoiding the imposition of one region's style over another. Just because the Swedes often understand either format—to recall Greg's example—does not mean that their preference ought to be be moot.
And let me just point out that I was not the one who demanded a study or scientific proof of the alleged incapacity of Americans to use other formats—I simply expressed my doubt. My common sense appraisal doesn't agree with Greg's, and I suspect that when it's nothing but assertions of common sense on either side, there's nothing in particular to refute. (And of course, repeating something doesn't make it true; neither argument is any stronger upon retelling.)
I've also got to take issue with the idea that Europeanization is the motive. ("This is simply nothing more than an attempt by some Europeans, who are absolutely convinced that their BIPM-endorsed, European way is superior (perhaps it is) and should be adopted here on Wikipedia and dumb ol’ Americans will learn it here, if nowhere else.") I doubt that it was an intentional strawman, but for the sake of keeping this discussion on track, let's drop the idea that there's any effort to force-feed Americans with foreign concepts, because there's no evidence that any editors presently commenting on this matter are attempting to engage in any such scheme.
To me, the convention used by the BIPM is a necessary inclusion in the MOS because it is the dominant English-lanugage usage in some regions—not just in science or engineering, but in any English-language usage. That's the way things tend to work in Continental Europe (and maybe that's why this "Europeanization" allegation arose), where several states and languages have their own incompatible digit grouping schemes, and where English is the de facto language of international commerce and collaboration. There is no ulterior motive: it's simply an acknowledgment of European English style. Consider the European Commission English Style Guide, which calls for BIPM-style digit grouping. That guide is "intended primarily for English-language authors and translators" and "serve[s] a wider readership as well" (speaking in terms of the EC and of EU institutions)
The fact that things like scientific journals and engineering handbooks have also adopted the BIPM convention is a secondary component of the issue—when we say "in common use in scientific and engineering works", that's just an acknowledgment that scientific usage of this convention is worldwide, versus the regional adoption of the convention for general use. If we wanted to capture that reasoning in detail, we could say that BIPM style is limited to topics in the fields of science and engineering, plus topics dealing with Continental Europe and other regions that enjoy significant adoption of that style.
But what's the point of being needlessly precise? It's much simpler to acknowledge that both the U.S. and the BIPM convention are in general use in large regions of the world, and each preferred by major fields of study (as evidenced by style manuals). On balance, the MOS is clearer by just allowing either one (though calling for consistency within an article), without complicating the issue with topic-related stipulations (and the consequent discussion of what belongs to which topic, or what dominates in which region). This is easier to understand, and easier to enforce—that's a useful thing, given the level of complexity of the MOS and Wikipedia policy in general. TheFeds 19:46, 22 August 2009 (UTC)
Frankly, your arguments that we should follow whatever the BIPM says the world ought to do comes right out of the four-year-old playbook used by proponents of the IEC prefixes (see the B0– B16 archives, above). That whole stink (seventeen entire archives dedicated exclusively to that one fiasco) was because a small handful of editors banded together and decided to start using terms like “256 kibibyte (KiB)” instead of the “256 kilobyte (KB)” used by computer manufacturers and computer magazines throughout the rest of the planet. Then one of those editors ran around and changed hundreds of articles over a period of a few weeks and the group blocked anyone from reverting all those edits, citing “lack of consensus”. That this could have occurred that way, that such stupidity lasted for three years, and that it took three months of bickering to put an end to it speaks volumes to how broken MOSNUM can be at times. And all because it was a proposal by some vaunted standards organization. The end result(?): needles confusion in readers who had the misfortune for three long years to come here and read many of our computer articles. I’m sure there were a number of people read up on computers here on Wikipedia and then went into computer stores where they announced they were looking for a computer with “512 mebibytes of RAM.” They were no-doubt met with blank looks (at best) or snickers.
Quoting you again: To me, the convention used by the BIPM is a necessary inclusion in the MOS because it is the dominant English-lanugage usage in some regions. Yeah, I got that much. I figured that bit out in the first four seconds after seeing what you were trying to do. And, as I’ve explained, it unfortunately isn’t a two-way street. There are many ways the Europeans format numbers. In Sweden, the “Swedish1” technique (there’s yet another) is to write the population of America as “285.865.855” so why don’t we just go ahead and let articles here use that system too(?), right along with the BIPM method (which Swedish school children are also taught)? That’s a rhetorical question, please don’t answer it. The answer is because Swedish school children are also taught to recognize the American-style of delimiting numbers. In fact, Europeans by and large are not in the least bit confused when they encounter numbers with American-style delimiting. The trouble is that American’s know of only one way; they’ve been taught no other. Your argument that Americans’ confusion will be short-lived because *Wikipedia* will just teach them using an “oh… didn’t-cha know?”-fashion (and only the galactically clueless and retarded will be left in the dust) is wholly uncompelling.
With regard to how numbers are written here on Wikipedia, it doesn’t matter in the least what the proposal is or who proposed it. When the American style of delimiting numbers is no longer the dominant numbering format universally recognized throughout the English-speaking world, and when Americans have as much familiarity with alternative numbering styles (like “Swedish1” and “BIPM”) as Europeans do with the American style, then Wikipedia can change over. Wikipedia follows the way the world works and never, ever tries to promote change in the way the world works by presuming we can somehow lead by example. Wikipedia wisely decided to use American-style delimiting in our numbers so there is minimal confusion. Greg L ( talk) 21:50, 22 August 2009 (UTC)
Let me stress that there is no implication of "teach[ing] them using an “oh… didn’t-cha know?”-fashion". Readers are free to assume that the formatting was a stylistic error, rather than another valid convention, and be none the wiser. The content of the article still gets across. (In other words, I am absolutely not advocating some sort of patronizing policy that would educate the savages of the world about Europe's genteel ways.)
My concern here that by mandating a convention that represents the preference of a subset of English speakers, we would imply that other accepted English-language usage is inappropriate. It would be like saying "because the British spelling of words like 'harbour' is recognized throughout the world"—despite the American spelling "harbor"—"this spelling convention is mandatory (unless quoting a source or explaining foreign usage)". Wikipedia has not gone this route, instead permitting either form.
Regarding your Swedish example, I assume that Swedish-1 and Swedish-2 are used in Swedish-language works? This being the English Wikipedia, one would expect them to use the style that is typically used in their region for writing in English. (Which is most probably the BIPM style.) If the Swedes don't use their native styles when writing in English, then there's no need to deal with them here.
When you say with certainty that "Wikipedia follows the way the world works and never, ever tries to promote change" by example, I think you're misinterpreting what's going on here. Maybe during the binary prefix debate, some editors advanced the idea of promoting IEC usage to the world. Nobody's said anything of the sort here. Furthermore, we usually follow bits and pieces of what influential parts of the world do, but only because consensus among editors often ends up settling upon that course of action. Sometimes that means following or ignoring a particular standard or widespread convention, but the key is that Wikipedia does what the editors agree upon. It's coincidence rather than design that consensus usually settles upon permitting what's popular in the world.
Lastly: you're definitely mischaracterizing my motives. I'm not waging some promotional campaign that serves to advance the interests of the BIPM, or Europe, or any other entity. Specifically, despite your assertion above, I have not stated or implied that "we should follow whatever the BIPM says the world ought to do". (I have previously stated that I tend to use the BIPM style in my outside work—which is immaterial to your allegation.) TheFeds 00:18, 23 August 2009 (UTC)
{{smiling, very amused emoticon}}
. Perhaps you aren’t. But it seems you are mightily crossing your fingers that mixing things up here and allowing editors to use different types of numbering formatting if they feel like it won’t cause needless confusion with our readership. Better cross two fingers.I’m an American engineer. I do all my design in hard metric. In fact, only a half hour ago, I was busy calibrating a celsius-only thermostat that I’m going to retrofit into my otherwise-gaugeless, Italian-made Rancilio espresso maker. The boiling point of distilled water was 97.8 °C at that moment (barometric pressure) at my altitude (about three meters above the sewer cover outside my house). I’m also installing a pressure gauge calibrated only in bar. I am as “BIPM” as they come for an American. However, as an engineer who has done far more than his share of technical writing (owners manuals, white papers, etc.), I am fully aware of what Americans know and don’t know technically. I am also keenly aware of how utterly stupid it is to needlessly confuse readers.
Here’s how to speed America’s adoption of all-things-BIPM (e.g., their SI (metric) system, their numbering system, etcetera): Just run for elected office while promising that if America adopts BIPM into their way of life, they’ll loose weight while they sleep and their taxes will go down due to less government waste. You’ll get into office. Moreover, you’d stay there; all you’d have to do is repeat the promise each election cycle; they’ll buy into your promise each time.
America is big and homogenous; a drive that would take you clean across the whole of Luxemburg won’t even get you across Harris County, Texas. This is a source of strength and weakness. For one thing, we can drive across Harris County and not require a pocket-full of plug adapters to plug our iPhones into the outlets in the next county (or state for that matter). We could design a big-ass airplane in the late 60s and not get all confused because Californians can’t speak French whereas Oregonians right next door can’t speak German. But this homogeneity also means that Americans would be surprised to get into an elevator on the ground floor and see that they are at floor “0”.
Indeed, Americans are certainly not as “genteel” and worldly as Europeans (that’s a friend of the guy who owns a tool & die shop I frequent); there’s this big-ass pond that shelters us from being exposed to other languages and other ways of doing things. Therefore, it’s a damned-seldom American indeed who is fluent in two or more languages and easily recognizes two—even three—ways that numbers can be delimited. Europeans “get” “285,564,125” in a nanosecond. The typical American would be needlessly confused by “285564125”. So, you Europeans have a leg up on Americans when it comes to understanding other cultures and practices.
Please take note of the following three expressions. The first is “A civilized man can convincingly imitate a barbarian, but a barbarian can not convincingly imitate a civilized man.” The second is “Never try to teach a pig to sing; you only waste your time and annoy the pig.” The third is “The goal of all technical writing is communicate with minimal confusion.” What you are proposing handily ignores all three. Greg L ( talk) 03:52, 23 August 2009 (UTC)
Those English-speaking Europeans who want to come to en.Wikipedia can, while they learn about the subject matter in our articles and brush up on their English-language skills, also get even more comfortable with the accompanying number delimiting technique whereby native speakers of English (U.K., America, Australia, and aothers) use commas to the left of the decimal point.
That is all part of the “experience” for many visitors to en.Wikipedia for whom English is their second language: immersing themselves in the culture, including such nuances as idioms. That approach is much more realistic (when in Rome, do as the Romans do) than assuming that Wikipedia can somehow change the way the English-speaking world works.
While it might be *pretty* to think that we wouldn’t be creating unnecessary confusion in our readership by using a wholly unfamiliar number formatting technique here, such a notion doesn’t seem grounded in reality. Nor is such a confusing change in the least bit necessary.
TheFeds, I ask you to drop the stick and back away from the horse carcass. This issue has been flogged to death and your persistence is becoming tedious. There is clearly not the remotest chance that a consensus might form for adopting the BIPM method of delimiting numbers for use on en.Wikipedia or expanding its mixed use beyond the confines within which it is currently limited. Far from it; it seems the general consensus is to leave things the way they are. Greg L ( talk) 16:13, 26 August 2009 (UTC)
Also, despite prior implementation and positive discussion of a similarly-worded edit to the MOS, you reverted it, and prompted this discussion in the first place. You can't just handwave away a discussion that you caused. How can you assert that "it seems the general consensus is to leave things the way they are", when the discussion on this point has largely been limited to you and I? If anything, the previous discussion about the MOS changes was more representative of consensus than our current conversation.
I'm receptive to your ideas, and have constructively disagreed, but you need to quit mis-stating my position regarding "chang[ing] the way the English-speaking world works" as fodder for your argument.
Given that the Romans use the BIPM convention (in English), why should they avoid using it when describing a Rome-related topic (in English)? As I stated previously, we have the option of writing a complicated regulation that takes into account WP:ENGVAR for articles dealing with regional issues that "belong" to places that recognize the BIPM style, and additionally acknowledges its prevalance in modern science and engineering. I think that my proposed language provides a less complicated policy statement with the same objectives, but it would essentially allow any user to choose to employ the BIPM style, even in new articles absent a topical or regional connection. That's a side effect, but given that that WP:ENGVAR cuts both ways (in that topics with a connection to a region that employs a non-BIPM convention could reasonably be changed to follow local style, even if the article style was initially BIPM), there's clearly nothing that would obstruct the ability of editors to choose an appropriate English-language convention for the article, or write neutrally when no regional or topical connection exists. TheFeds 17:55, 26 August 2009 (UTC)
You two’s change was to a long-standing guideline governing how something as fundamental as the formatting of our numbers are done on en.Wikipedia. It is utterly absurd to start mixing up our numbering style in an encyclopedia geared for our English-speaking readership. As A. di M. pointed out, WP:ENGVAR doesn’t and shouldn’t and can’t be applicable here. You are grasping at straws trying to make a case for what amounts to nothing more than “I like ta and wanna sanctify my practice in MOSNUM by changing MOSNUM.” Please stop. I couldn’t care less if some member of an African tribe that speaks using *!* tongue pops and counts in base-seven numbering system comes here because he or she also happens to know English as a second language. Those countries wherein English is the primary language delimit numbers to the left of the decimal point only with a comma. This practice is memorialized in the U.S. Government Printing Office Style Manual and is what is used here. So it doesn’t matter if the BIPM says it should be “75 %” and not “75%”, nor does it matter if the BIPM says it should be “a population of 285568654”. Why? Because in those countries where English is a primarily the first language, those two things aren’t done the BIPM way. It’s just that simple.
If we headed down the path you and Jc3s5h wanted, which amounts to “let editors use either commas or thinspaces to the left of the decimal point whenever they want if the article is sorta ‘techie’ ”, then Wikipedia would once again be repeating the fiasco of our now-aborted experiment with the use of the IEC prefixes, where some articles said “256 kilobytes (KB)” and still others said “256 kibibytes (KiB)”. Given that readers were entirely unfamiliar with the latter, this accomplished nothing more than to confuse readers. It’s interesting to note that the proponents of the IEC prefixes used exactly the same arguments you two are using: “They’ll figure it out from context and… and, the (totally conjectured and unproven) confusion will be short lived, and… and, a *standards organization* has proposed it, and… and, it solves an ambiguity or shortcoming of some sort, so our use here on Wikipedia is nothing but goodliness and will make us look all futuristic and smart.” Uhm… no. All it did was unnecessarily confuse our readership.
I appreciate your above candor. You’d like to see the use the Euro/BIPM method of delimiting numbers in an article on Rome, since—by your argument—Italian-speaking Romans who also speak English could visit the en.Wikipedia Rome article and feel all warm and fuzzy about seeing the BIPM method of number-delimiting here too. Except your argument falls somewhat flat because in Italy (at least it.Wikipedia), they format numbers like this: “Con i suoi 2.726.539 abitanti distribuiti su una superficie di 1.285 km², è il più popoloso e più esteso d'Italia.” A. di M. will no-doubt be able to flesh in some detail on this. But I have every faith that Italians recognize the method of delimiting seen on it.Wikipedia, and the BIPM method, and the English-speaking method.
I will no longer waste my time arguing this point with you, TheFeds. Count how many editors, above, support what you are proposing. Do you see a consensus for what you desire? Or do you just hope that by not dropping the stick that we will all just come around? I’m going to leave this to Tony, A. di M., and Ohconfucius for a while. Don’t count my absence from this discussion as acquiescence; I simply tired of arguing with you.
Frankly, if I had my way, the use of gap-delimited numbers to the left of the decimal point would be limited strictly to when text is being quoted directly from a scientific paper. The practice has no place in an article like Moon, for text like “The Moon is 384403 km away from the Earth” and MOSNUM should clearly reflect that. Greg L ( talk) 20:57, 26 August 2009 (UTC)
If Wikipedia's policy was to always employ the most popular variety of English uniformly, perhaps it would minimize confusion. And then it might logically follow that the most popular numbering scheme should always be employed as well (despite regional eccentricities). But that's certainly not the way most similar cases were decided, and the policy guidelines reinforce the idea that regional preferences matter.
Greg, I think you missed the point of the Roman example: this is about English-language usage, not Italian-language usage (as I clearly specified). I'll of course defer to A. di M.'s presumed experience with Romans, but in my experience, Continental Europeans writing formal English prose will employ the BIPM style, irrespective of the conventions used in their native language. (And with English being the dominant language for international communication in Europe, there's no shortage of usage.)
With regard to Greg's paragraph citing the IEC prefix dispute, I'm accused of using their arguments ("They’ll figure it out from context", "a *standards organization* has proposed it" and "it solves an ambiguity or shortcoming").
The first argument, as I noted earlier is logically equivalent to Greg's argument that many Americans will struggle to figure it out—both my assertion (that context will make most usage clear) and Greg's are conjecture, though both reasonably well founded. Absent actual evidence, you can't accept one and reject the other on a logical basis.
The second is a strawman, as I reminded Greg prior to his reiteration of it. It's immaterial that the BIPM is a standards organization, just as it's immaterial that the U.S. Government Printing Office authored a standard that encapsulates Greg's preference. Regional usage is at issue.
The third would be a fair point, if it weren't for the inflammatory corollary that Greg appended ("so our use here on Wikipedia is nothing but goodliness and will make us look all futuristic and smart"). Notwithstanding Greg's misrepresentation, it does address a shortcoming. As I noted above, Wikipedia could have solved the question of how to deal with variations in English usage by mandating a fixed house style (for numbers, spellings, synonyms, etc.)—but that was not adopted. Instead, consensus dictated that regional usage was permitted within an appropriate sphere of influence. MOSNUM ought to reflect the outcome of that high-level consensus. As I explained before, my proposal was more permissive than that—but the crux of the issue is that regional English-language styles are appropriate on the English Wikipedia. The additional permissiveness in my proposal reflects my belief that adoption of the BIPM style is sufficiently widespread that the effect of adding it on an equal footing with either of the comma-based styles would be essentially harmless. It's much the same as the difference between the two comma-based styles (listed at the top of A. di M.'s proposal)—readers will understand either one, even if they think one or the other is in error (because they have not been exposed to it).
That additional permissiveness also has the effect of simplifying the MOS regulation—but if that prospect is so abhorrent, the formulation that permits the BIPM style only when regionally or topically appropriate (e.g. Continental Europe, Canada—especially French Canada, science, engineering, etc.) would minimally satisfy the existing guidelines, and would be acceptable. TheFeds 23:21, 26 August 2009 (UTC)
The traditional way to delimit numbers in Italian in handwriting is a superscript dot; but since no-one knows where to get that character, it is approximated with either a period or an apostrophe ("10.000" or "10'000"); the former is more common in Italy and the latter is in Switzerland. Recently the BIPM way is becoming common too; I guesstimate that approx. 70% of stuff published in 2009 use periods and 30% use thin spaces. But I've seen that my cousin's elementary school textbook only mentions the thin space method. There are many Italians who are unfamiliar with the comma as a thousand separator and wouldn't realize that "40,125" can mean anything else than forty and one eighth, but those Italians don't understand English enough to read an encyclopaedia article in it, so I don't see the need to cater with them in the English wiki. As for "continental Europeans writing formal English prose will employ the BIPM style", that's true, but only because an Italian is more likely to write a scientific paper than a novel in English. (And as of 2009 there's no real ground to consider India an English-speaking country; it has fewer native English speakers than Germany, and a smaller percentage of people able to speak English than the whole world.) -- ___A. di M. 12:51, 27 August 2009 (UTC)
But there are still proposals on the table, and we have yet to see any conclusive resolution that approximates a consensus.
So my suggested resolution is as follows:
Please don’t confuse my apparent willingness to engage you on this issue and the relative silence from the others, as signaling that they are somehow in major agreement with you. The words of Tony and Ohconfucius, above, are short and sweet and seem to convey their sentiments clearly enough (unsupportive) as to what you propose. However, I would be exceedingly pleased if you would start an RFC so we can be done with this and I don’t have to periodically check back here, only to discover that you have again reprised this issue.
A consensus is not arrived at by seeing who harps the longest and mostest on a given subject. Nor does one get his or her way on Wikipedia by catching people sleeping, nor by changing the documentation on templates to convey something along the lines of “better not use this template because—boy—is it gonna change soon…” nor by changing templates without having had any real discussion beyond tag-teaming with one other editor where you both go “campy idea—cup of tea?” to each other.
Judging from the reception of me and several others, above, turning Wikipedia into a mix of numbering styles by greatly expanding the use of a number format that isn’t even used by those general-interest readers for whom English is their first language, has pretty much no chance of being adopted. And it shouldn’t, for it ignores the most basic fundamentals of Technical Writing 101. If you have to prove this through an RFC rather than examine the reception your proposal has received so far, by all means.
As for I'm willing to compromise… language, uhm… we all have to accept the consensus of the community—period; it doesn’t much matter what you are I are “willing to compromise” on.
Someone please e-mail me if this goes to an RfC. I don’t make it a practice to keep following TheFeds wherever he goes on Wikipedia with this idea of his. Greg L ( talk) 02:23, 4 September 2009 (UTC)
You might have noticed that while Tony and Ohconfucius both made short comments concerning portions of this discussion, you and I wrote at length—and my post addressed that conflict. You might also have noticed that I also excluded mention of Jc3s5h's comments in support, and did not state that A. di M. disagreed in part and agreed in part.
And when you list several ways in which "A consensus is not arrived at", are you making an accusation, or just introducing examples that are irrelevant? I've repeatedly warned you during the course of this discussion not to jump to inaccurate conclusions about my motivations, and now I feel that I need to warn you to avoid baseless accusations of things like "catching people sleeping" and screwing up template documentation, and to avoid flippantly misrepresenting legitimate discussion as “campy idea—cup of tea?”.
You said "uhm… we all have to accept the consensus of the community—period; it doesn’t much matter what you are I are 'willing to compromise' on"; but I don't see any basis for your objection. When we make proposals, we are free to discuss and make compromises among ourselves, in order to establish mutual support for a compromise proposal. (As an illustrative example, consider how a legislature generally works: mundane issues are discussed in committee, leading to one compromise bill, rather than by taking up-and-down votes on opposing ideologically extreme proposals.) Nothing of that process prevents a "consensus of the community" from existing. TheFeds 17:23, 4 September 2009 (UTC)
One sort of thing that has been the source of spectacular amounts of vitriol on Wikipedia (and the Wikipedia-equivalent of suicide bombers and Turkish butt-stabbings), has been the launching of RfCs by a lead advocate on one side of an issue. This resulted in RfCs that suffered from unconscious bias and were not respected by the other side. If you seriously think your proposal has a snowball’s chance of being accepted with a clear consensus (that’s a big “IF”), then the next step is an RfC. So the proper step, IMO, is to not launch an RfC, but to propose RfC wording, we all discuss the proposal and tweak it until everyone is clear on what is being proposed and how it would change things and are mutually satisfied the “package” wording is sufficiently neutral, and then we launch an RfC.
I have zero interest in starting all that. It’s time-consuming and, ultimately, a waste of time if it goes as I expect. I suggest you seek some assistance from Headbomb and Ryan Postlethwaite (I have no idea if they might be interested) since they both have experience in RfCs.
Perhaps, an even better course of action would be to privately contact an editor or two that you feel are relatively unbiased and whom you have a respect for their opinions. Just ask them if they think there is a fair chance of your succeeding at what you desire. I think that is much fairer given that your persistence at this means that everyone else has to *sigh* and start jumping through hoops once you start things rolling. Greg L ( talk) 18:43, 4 September 2009 (UTC)
As for asking around (less formally), they thought that it could plausibly be well-received elsewhere on Wikipedia, with the main concern being that other venues might not be interested enough in minutiae of style to comment constructively. They figured that it would be harmless enough to just ask, rather than attempting to predict the outcome.
So, we discussed what I had in mind, and through a couple of revisions, we pared the essential question down to something general ("On Wikipedia, should the selection of digit grouping styles depend upon regional and topical conventions used in the English language?"), with a neutrally-phrased explanation of context. The question is posed at WP:VPP, in the section Digit grouping style question (from WT:MOSNUM), and I'm placing notices on some other talk pages directing users to WP:VPP for comment. TheFeds 03:46, 9 September 2009 (UTC)
You clearly want your way, didn’t like what the others had to say, above, on this issue, and you now put us all in the position of having to chase you over to WP:VPP. No. I won’t chase you to some other venue as you hop-scotch across Wikipedia with this agenda to change MOSNUM. I even wrote above Someone please e-mail me if this goes to an RfC. I don’t make it a practice to keep following TheFeds wherever he goes on Wikipedia with this idea of his. Yet, you conveniently elected to not alert me to this “RfC” of yours; I had to do one of my periodic checks on this thread to see what you are up to. This sort of move deprives that RfC discussion from the input of the editors here who have already weighed in on this issue and are no longer paying attention to this thread nor following your every move. You can hop-scotch over to Jimbo’s page and pitch what you want there. But even he doesn’t determine what occurs here on WT:MOSNUM; he has an abiding respect that the “community consensus is always the right thing to do.”
Discussions of how to change WP:MOSNUM must occur here on WT:MOSNUM. Period. Please drop this. You don’t win by being persistent to the point of a fault. When you have a consensus here to change WP:MOSNUM, then WP:MOSNUM will be changed. If you just want to get input from a new group that has less day-to-day familiarity with the goings-on here on MOSNUM and this talk page, then, be my guest. There is nothing wrong with that. But, please don’t commit the colossal error of running off to some other forum, obtaining a result you find favorable with a new audience, and then start making your edits to MOSNUM. Pages have their associated talk pages for a reason and you might well find yourself sanctioned if you try to change MOSNUM as a result of venue-shopping. What occurs over on the Village Pump may be interesting to you, but it is not binding on the content of MOSNUM.
In the end, I think you are wasting your time. If you want to change MOSNUM, you must achieve a clear consensus here. Greg L ( talk) 18:38, 9 September 2009 (UTC)
First, with regard to alerting you: presumably you watch this page and visit often, given your numerous contributions to this talk page? I notified everyone of my action, right where one would expect to see it—in the discussion thread. (Only absent my not-so-stealthy post and link, might you have had a reasonable cause for concern.)
With regard to your concern about venue shopping, the discussion on WP:VPP is a simple and straightforward way to discuss one sticking point (among the many facets of the MOSNUM proposals), without attaching the trappings of our prior argument. The idea is to keep things on-topic, without having to saturate the discussion with refutations of alleged "Europeanization" or the like.
It is also completely proper to ask relevant questions elsewhere, when the discussion here is deadlocked without consensus or compromise. I shouldn't have to explain that that is not a substitute for the detailed proposals at MOSNUM. Rather, it is a way to inform our discussion with the opinions of interested and relevant contributors (who frequent the policy- and science-related forums rather than MOSNUM). Unsurprisingly, that that's exactly the point of the Village Pump. This can lead to a viable consensus on an issue of mutual interest to VPP and MOSNUM, but that consensus would obviously only deal with the specifics of the VPP question, rather than forcing the adoption of a MOSNUM proposal.
As for depriving others of input from this thread: no, I clearly linked to this thread, and advised readers that they could consult it for further information, or comment in it if desired.
The words "pointlessly bureaucratic" were not mine—that's why they're in quotation marks. But I do sympathize with the sentiment. (I think it's overkill to make endless proposals about the question to pose—would you find that discussion particularly enlightening, and do you really foresee anything but a deadlock there as well?)
If you object to the framing of the question, that's fair enough. I made a good faith effort to seek advice (per your suggestion) and work out a concise, neutral phrasing with an uninvolved party. You suggested having a round of discussion to decide the question for a formal RfC, but then stated that you had no interest in participating—you can't really have it both ways. TheFeds 04:34, 10 September 2009 (UTC)
Quoting you again: To me, the convention used by the BIPM is a necessary inclusion in the MOS because it is the dominant English-lanugage usage in some regions. Yeah, I got that much. I figured that bit out in the first four seconds after seeing what you were trying to do. MOSNUM and the editors who comprise it simply don’t care about how things are done “in some regions.” What matters is how things are done for the vast majority of readers for whom English is their first language. Italians, for instance, have their own Wikipedia and en.Wikipedia needn’t be unnecessarily muddling things up for those English-speaking Italians that choose to visit an article here. The whole point of technical writing is to communicate with minimal confusion.
Let’s touch upon why en.Wikipedia shouldn’t be kludged-up with multiple numbering systems in our general-interest articles in order to better accommodate readers for whom English is their second language. As I’ve previously explained, cross-Atlantic (or Pacific) recognition of alternative number-delimiting schemes unfortunately isn’t a two-way street. There are many ways the Europeans format numbers. In Sweden, the “Swedish1” technique (there’s yet another) is to write the population of America as “285.865.855” so why don’t we just go ahead and let articles here use that system too(?), right along with the BIPM method (which Swedish school children are also taught)? That’s a rhetorical question, please don’t answer it. The answer is because Swedish school children are also taught to recognize the American-style of delimiting numbers. In fact, Europeans by and large are not in the least bit confused when they encounter numbers with American-style delimiting. The trouble is that American’s know of only one way; they’ve been taught no other. That is why Wikipedia has long-used the most widely recognized method of delimiting numbers: it causes the least confusion (by far) over other methods that aren’t recognized by many English-speaking readers. The whole point of technical writing is to communicate with minimal confusion.
Quoting you: [Editors are given spelling freedom via] WP:ENGVAR, and choose instead to cater to one region's preferences. Wikipedia is written for an international, English-reading audience. That means that we need to accept that occasionally, a user may encounter a term or convention from elsewhere, and be briefly confused. But this is not a critical flaw… I see you don’t seem to mind (you don’t see it as a “critical flaw”) that readers might be “briefly confused” with multiple numbering systems. I do. And, why would we cause this confusion? So that editors from all walks of life (perhaps some editor from Africa who speaks in *!* tongue pops and also speaks English as his second language) can merrily write The population of Congo in year so ‘n’ so was 66020000 because he was the first major contributor. Given that Wikipedia is has an all-volunteer contributing authorship, allowing “lorry” in some articles and “semi-truck” in another is a reasonable and necessary compromise to address how editors in England spell differently from those in the U.S. and use different words—notably for nouns. Note however, that these are differences within the English language for those editors for whom English is their first language. It is patently absurd to think that an article on the Democratic Republic of the Congo is going to have a different numbering technique that is foreign to many native-English speakers because the first major contributor to the Congo article uses that numbering technique. WP:ENGVAR does not, should not, and can not apply here. Believe it or not, Wikipedia is not about us, the editors of Wikipedia; we write for our readership. The whole point of technical writing is to communicate with minimal confusion.
Even though you might not like to listen to others, please read comments from others, above, such as the words of Ohconfucius (04:13, 26 August 2009 (UTC) post), where he wrote The use of commas as delimiters is pretty much universal – the comma separator is not only American, it's Canadian, British, Australian, Irish, South African, Singaporean - which should take care of about 95% of the native English-speaking population. Things are done on the en.Wikipedia version of MOSNUM for a reason. Even if you don’t understand or agree with those reasons, you must accept the consensus view here. The whole point of technical writing is to communicate with minimal confusion. Is that sinking in yet? Your argument that “brief confusion” is “not a critical flaw” is bizarre and wholly uncompelling. Greg L ( talk) 23:00, 9 September 2009 (UTC)
Your invocation of the Italian Wikipedia seems to me like a fundamental misunderstanding—nobody is proposing using Italian-language style here. As I pointed out above—and you overlooked again—English-language usage is at issue. (Do the Swedes use Swedish dots in English? Probably not. BIPM with spaces? Probably.) And you're stating that English as a first language is the determining factor. That's not what "English-speaking" means. (I've already presented several counterexamples, like India.) If you mean to advance that as a proposition, then do so, but avoid presenting it as axiomatic.
When, in reference to things like "truck" and "lorry", you say "these are differences within the English language", you make a false distinction: consider digit grouping schemes mentioned in the European and American manuals of style—they are obviously both "within the English language". And that fact is not influenced by whether or not some editors have English as a first language, or otherwise.
You're also implying that Wikipedia 101 = Technical Writing 101. Unfortunately, you're wrong. In short, technical writing can often be geared to a specific and generally well-educated audience with easily-ascertained expectations. Wikipedia, because of its diversity of readers and contributors, has chosen (by way of guidelines and precedents) to use regional (or other) styles in some instances. If you disagree with that, it's incumbent upon you to raise that discussion at an appropriate level.
I will, however, grant that your opinions about minimal confusion are a convenient approximation, though not a well-formed universal solution to the issue of how to present text in a manner that is effective and appropriate. If "minimal confusion" was an obvious and infallible dictum, we wouldn't need to have discussions about much of the MoS. The fact that we disagree on certain points of style—just as others have disagreed before on other topics—is ample demonstration that your doctrine does not make conclusions about style self-evident.
So what of the "brief confusion"? Although we both know what a lorry is, you must concede that an American reader might not—he might be briefly confused, until he clicks the wikilink, or figures out from the picture of a truck what is being referred to. That is more confusing than number formatting (a wholly-unfamiliar word vs. groups of digits that might be read as a number), and yet, for good reason, it is permitted on Wikipedia, even in an article that has nothing to do with Britain, but which speaks of lorries in some other context. Minimal confusion would dictate that we prescribe the most common form among our readership—which would probably be "truck" in deference to the plurality of American readers of Wikipedia. Because this is an unacceptable simplification to many readers and editors alike, regional and topical conventions that enjoy wide English-language adoption should likewise be accorded latitude despite the potential to briefly confuse whatever other group might be slightly disadvantaged.
Furthermore, by exclusively requiring one region's style (even granting its greater adoption), you systematically disadvantage the significant set of English speakers who do not employ that convention in properly-constructed English-language usage. That can be construed as a bias, and has been the subject of many arguments. By having MoS guidelines that account for regional or topical conventions, we assure readers that they will receive an acceptable format for the subject of their inquiry, and for the editors, specify a reasonable link between the style and the content to minimize ambiguity. We therefore avoid controversy about why a British subject is described in American style. By extension, this implies that the most interested editors will have justification for employing the conventions that are most appropriate to their area of interest or expertise.
To extend that principle, for the articles that do not have well-defined regional or topical links, one could perhaps prescribe a house style, and still present the topic in an appropriate format and avoid the potential for formatting disputes. (This seems to be what you're suggesting with your Congolese example.) But based on precedent, Wikipedia has specifically chosen not to do that—it instead falls to the first or major contributors to pick formatting conventions for the article. (That precedent and its associated consensus are clear and directly applicable to the present discussion.) This also has the side-effect of allocating bias in rough proportion to the number of major contributions by various groups, rather than biasing all such articles in favour of one popular style.
I'm citing well-founded precedents like WP:ENGVAR, and describing a balance between the competing objectives that must necessarily be considered when policy is at stake. I think that this represents a fairer approach to Wikipedia policy than steadfast and singleminded advocacy for "minimal confusion" as the principal doctrine of the MoS. TheFeds 04:34, 10 September 2009 (UTC)
← I believe TheFeds' question on VPP was way too vague to be of any use, and that discussion doesn't seem to be going anywhere, anyway. I'd go with a two-step schedule as was done on WP:DATEPOLL or WP:IECVOT: in step 1, we create a page (I'd use a subpage of this talk page) where an editor can make a proposal, discuss about other editors' proposals, and tweak his/her proposal to address the points made by other editors. In step 2, no further edit is allowed to the proposal, and editors will be allowed to vote for proposal using a decent voting system (I'd go with the Schulze method). The first step should be advertised here, on WT:MOS, on WP:CENT, on WP:VPP and WP:VPR; the second step should be advertised as widely as possible on Wikipedia, including a watchlist notice. As for the time schedule, I'd go with seven days for each step. After the second step is concluded, the proposal which wins according to the chosen voting system will be incorporated in WP:MOSNUM to stay unchanged for six months. Or something like that. -- ___A. di M. 15:09, 10 September 2009 (UTC)
As for the RfC mechanism you've outlined, that level of formality is—I think—inappropriate for the limited question asked at VPP. The RfC process you outlined tends to be used for votes on fully-formed proposals—and I could support that procedure if we were voting on entire MOSNUM proposals. But for a policy consultation, it's not a good fit. TheFeds 16:33, 10 September 2009 (UTC)
To be perfectly honest, I'm not sure that there's strong enough interest to expect a meaningful RfC result (as in, a response from people other than those who have already clearly expressed their opinions).
I am ambivalent about the need to go through all of that formality over a paragraph in the MOS: I would be weakly opposed on those grounds. But I'm also concerned because I believe it will become mired in meta-debate. And that meta-discussion, especially if conducted by Greg in the style he's employed to date in this thread, will probably be marked by the same incivility, unwillingness to compromise, and tritely-phrased misrepresentations that he employed above. If it's likely to end up like that, I would oppose it.
There's also the broader question of whether we tacitly support a proliferation of RfCs to resolve simple changes that lack clear consensuses. I'd say that this debate is somewhat unique, in that it's lacked widespread input, is not of critical importance, and yet has consumed a lot of text. Are we saying that when mundane proposals go bad, we should proceed to an RfC, rather than first trying less formal tools for advancing the discussion? TheFeds 00:22, 11 September 2009 (UTC)
Back to the point. I come fresh to this debate, and was not aware until now that it was going on. User:Greg L is correct in proposing that numbers (to the left of the decimal point) be delimited by commas. But contrary to what Greg L perhaps assumes, it is not only an American thing, it is normal practice here in Britain too, so covers most of the mother-tongue-English-speaking world, in terms of population (apologies to Canadians and Australians). If it is true as alleged that the BIPM style is dominant in some English-speaking regions, they must be very much in a minority.
BIPM (of which I had never heard until today), based in France, appears to be trying to impose French practice on the rest of the world. I can reveal from personal experience that the only reason the European Commission translation service's English style guide lays down the BIPM policy in this particular respect (it does not do so in many others) is because they are translating thousands of documents every day from French to English, and for purely technical reasons it makes their lives much easier just to leave the numbers in the French format. The people who work there are well aware that this isn't normal British practice, and is a departure from the usual EU policy of using British English, but they have adopted a pragmatic compromise to save time and money in their particular special circumstances.
The Oxford Dictionary for Writers and Editors (a British publication) says:
Use commas to separate each group of three consecutive numerals, starting from the right, when there are four or more, except in math. work and pagination; in scientific and foreign-language work thin spaces are used instead of commas.
-- Alarics ( talk) 13:35, 13 September 2009 (UTC)
Right, so even if we assume that the French-speaking Canadians use the French system, that's another 20 million English-speakers on our side. Can we ask User:TheFeds, when he writes of the BIPM style that "it is the dominant English-language usage in some regions", which regions he has in mind? -- Alarics ( talk) 16:03, 13 September 2009 (UTC)
And at least in my experience, publications written in or translated into English in Europe use the BIPM style. (To cite a particular example, many French graduate schools use English as the language of instruction, and students write their theses in English.)
It might well be that the EU wishes to simplify their transcription of documentation from French to English by prescribing that style—but I suspect that the motivation goes a little beyond economy. In my estimation, because many European regions have their own traditional conventions in their native languages, and just as Europeans have settled upon English as a de facto language of collaboration and commerce (albeit while trying to maintain their regional dialects for culture's sake), they've settled upon the BIPM-style digit grouping to reduce ambiguity in communication. For example: the traditional French convention was commas for the decimal place and periods for digit grouping—the inverse of British usage, and obviously confusing. (In other words, I don't think the EU or BIPM is trying to push French style on everyone.)
Additionally, the BIPM convention is understood in English Canada, and has been taught in their schools for many years. (As well as being universally used in French Canada.) You're quite right about Britain, though; they do prefer the comma-based style. I'm not completely certain about the rates of usage in Australia and New Zealand, but I can scarcely imagine that either convention would be unfamiliar to them—I'd speculate that they are somewhere between Britain and Canada in terms of usage. TheFeds 04:25, 14 September 2009 (UTC)
As for the bigger picture, it's an open question whether Wikipedia should allow regional usage in region-neutral articles, or insist upon a fixed style—but that's not really even the heart of the issue as it relates to MOSNUM. TheFeds 05:47, 14 September 2009 (UTC)
It's pretty apparent that the discussion above has been inconclusive. The discussion ended up as a back-and-forth between myself and Greg L, and my attempt to seek policy advice from WP:VPP didn't shed any light on matters.
If the proposals are stale, then there's only one more order of business: establishing what the consensus was for digit grouping, so that we can revert to it.
Let me preface by saying that this is in no way a personal attack—quoting Greg L:
...One other note: en.Wikipedia adopted the U.S. style and standardized on delimiting to the left of the decimal marker using commas. Let’s please accept that nothing in this debate can change that and limit the discussion to the number of digits per group.
— Greg L, 15:16, 8 October 2008 (UTC), WT:MOSNUM Archive 112
...Now, Gerry, let’s get real shall we? I’ve mentioned several times above that en.Wikipedia adopted the US convention of delimiting to the left with commas. Nothing we’re discussing here is ever going to change that fact. The people over on fr.Wikipedia will keep doing as they like. As I wrote several times above (it would be nice if you actually read some of the goings-on here because I’m way ahead of you here) this practice of comma-delimiting to the left is far too entrenched in the U.S. and across the Internet for you to change that with your above epiphany. None of us here in this debate on this mote of a backwater discussion is going to change the way the U.S. works in this regard nor en.Wikipedia’s adoption of that widespread convention. As I also wrote above, this is an issue of simply adhering to the three-digit practice that is common throughout Europe and which has been standardized for use with the SI....
— Greg L, 18:07, 9 October 2008 (UTC), WT:MOSNUM Archive 112
That is from the discussion that brought about the phrasing that Greg reverted to (kicking off this lengthy discussion). It's focused on the RHS of numbers, rather than both sides of the decimal point. When other users mentioned that SI/BIPM prefer spaces on both sides, there was really only one argument for (what we later discovered to be) the U.S. GPO style—Greg asserted that it was a fait accompli that commas were used on the LHS by Americans, and said that Wikipedia might as well go along with that well-entrenched usage.
But because of that, the thread avoided discussion establishing why commas-on-the-left should (or should not, or should sometimes) be the preferred format. It bypassed the concern that SI compliance would entail spaces on both sides, and instead dealt with the RHS digit grouping to define the behaviour of {{ val}}. As a result, no consensus was formed about what to do with the LHS.
It is, however, where the (permissive) technical usage clause comes from (courtesy of A. di M. as Army1987)—that part seems affirmed by consensus.
To find a discussion that arrived at a consensus on how to group the LHS of numbers, or to find an overarching agreement on both the left and right sides, we're sort of out of luck. Going back much further, MOSNUM used to say to use commas only (without regard to any special cases)—but that was basically just an arbitrary convention that hadn't been extensively discussed, and wasn't uniformly followed. Even in Archive 19, and Archive 74, consensus was absent, and the issue was dropped without formal proposals or major revisions to WP:MOSNUM.
On another note, I'm going to quote Greg L again here:
SI is clearly a wonderful thing, and it is so because it doesn’t unnecessarily push the “Euro” way of doing things over the “U.S.” way, nor visa versa. The SI acknowledges and embraces practical reality. “Full SI writing style” recognizes delimiting via either commas or narrow spaces in the mantissa because that’s the reality of the American style of delimiting numbers. Like it or not, there’s simply no fighting it; that style is extraordinarily common and well entrenched—both in print and on the Web. Wikipedia—like the BIPM and their SI—can’t find itself in the position of trying to promote change in the way the world works by pretending to adopt a single style of numeric notation that isn’t well recognized in the U.S. The whole point of encyclopedias is to unambiguously and clearly communicate. Intuitively easy, familiar writing customs must be observed. There is no “right” or “wrong” with regard to commas or narrow spaces in the mantissa—not according to SI and not according to common sense simply because the English-language version of Wikipedia is read by readers in both Europe as well as the U.S. Accordingly, Wikipedia (and in the SI) recognizes both methods. We don’t have to agree that Wikipedia should adopt one style or the other with regard to delimiting the mantissa…nor should we. We can simply make two versions of a numbering template (or an option to check in a single template). Trying to necessarily link the treatment of the decimal portion to how we delimit the mantissa will only doom to failure any efforts here. We should address only one issue: should a template be made to make it easier to delimit the decimal portions to make long strings easier to read(?). My point would be that narrow spaces are so damn easy to read, that even a novice who has never seen it before instantly understands what it’s all about. And in articles where numbers are important, delimiting is crucial because long strings of non-delimited digits to the right of the decimal point unusable to the point of being barbaric. There should be an easy way for others to do so (rather than hand-coding it all).
— Greg L, 03:59, 20 December 2007 (UTC), WT:MOSNUM Archive 94
Strangely enough, that's a lot like what I was talking about. Yes, there are distinctions, but they are minor; that argument was used in a discussion about how to deal with the RHS of numbers—group in threes, fives, or don't group at all. (I'm wondering what's so false about Greg's previous argument that it doesn't apply any longer.)
In any event, the question of what level of confusion will result, or is acceptable in this case is not settled. And we haven't done justice to weighing the need to limit confusion versus other objectives on Wikipedia.
Later on, when Jc3s5h and I were allegedly trading campy ideas, there was in fact a substantial discussion about digit grouping (related to my edits). After a shaky start, where we got sidetracked over some possibly-misremembered standards, we consulted style guides, got input from a few editors (in addition to the regulars), looked at the archives, and managed to formulate a proposal that was not opposed. Now that's not necessarily the same as a clear consensus—because there were really only three of us commenting upon and implementing the final draft.
But it's certainly better on basing our treatment of delimiting in general on the results of a series of discussions that were specifically framed to deal only with RHS delimiting and templates, or which (going back several years) were more concerned with the thin-space handling in IE6 than digit grouping per se.
The take-home message is therefore this: the long discussions on MOSNUM were primarily based on how to handle {{val}} and its relatives, not to set a policy for numbering styles in general, and certainly not to require a particular convention. The question of regional usage per WP:ENGVAR is not settled—the VPP reference question was split, and we've hardly resolved any of that here. The question of technical usage was agreed upon previously.
Unless someone wants to resurrect the proposals, maybe we should just call this a "dismissal without prejudice": one of these days, when someone works up the courage to propose a resolution (maybe even through an RfC, if that option is more popular than traditional discussion), we can revisit this topic properly, with a more thorough and civil discussion, and buy-in from a sufficient cross-section of editors to establish a clear consensus one way or another.
In the meantime, all we've really got is consensus on how to make the RHS work (especially in templates), and how to use SI-style notation in technical articles. Let's accept that at face value, and move on. TheFeds 06:33, 21 September 2009 (UTC)
Use commas to separate each group of three consecutive numerals, starting from the right, when there are four or more, except in math. work and pagination; in scientific and foreign-language work thin spaces are used instead of commas.
Wasn't there a proposal to do an uplift of the use of {{ xt}} on the MOS/MOSNUM just a while ago? Did that die? Headbomb { ταλκ κοντριβς – WP Physics} 20:12, 9 September 2009 (UTC)
Truth be told, accurate color work is impossible on this 17-inch iMac because the parallax change caused simply by scrolling the above color-swatch from top to bottom of my screen causes the center squares to go from noticeably too-dark to too-light. My really, really good Sony 21-inch CRT monitor is still attached to my old Mac, which will forever be “Peter Pan”ed at OS 7.5.5 so I can continue to use a certain CAD program (I really scream on that old wire-frame application). Now that monitor is for high-fidelity work with color. Greg L ( talk) 18:30, 12 September 2009 (UTC)
Do you agree to add the following:
after the fourth bullet ("Yearless dates ..." in Wikipedia:Manual of Style (dates and numbers)/Datestempprotectedsection? If no-one disagree in 24 hours, I'll post an {{ editrequested}}. (Please do not use this section to discuss any other issue, no matter how close it is to this one; that would defeat the purpose why I'm writing this in the first place. -- ___A. di M. 20:42, 20 September 2009 (UTC)
Propose:
Do not use all-numeric date formats such as 03/04/2005, as they are ambiguous (the example could refer to 3 April or to March 4). For consistency, do not use such formats even if the day number is greater than 12.
(outdent) I would suggest something more along the lines of this, so it follows more cleanly from the preceding bullet point:
Other all numeric date formats, such as 03/04/2005, should be avoided since they are often ambiguous in that the first number could translate to either the day or the month (the example given could refer to 3 April or March 4).
I think it is unnecessary to further clarify with regard to days greater than 12. wjemather bigissue 21:54, 20 September 2009 (UTC)
See WT:Manual of Style#Summary done. -- ___A. di M. 22:55, 20 September 2009 (UTC)
I propose to put to an RfC and centralised discussion the following change:
Present text: YYYY-MM-DD style dates (1976-05-31) are uncommon in English prose, and should not be used within sentences.
Proposed text: YYYY-MM-DD style dates (1976-05-31) are uncommon in English prose, and should not be used in sentences or footnotes.
-- Alarics ( talk) 18:29, 29 September 2009 (UTC)
Having looked at the RfC results so far, it is becoming clear now what the proper solution is: appoint three editors who have journalism degrees to oversee MOS and MOSNUM and kick all the neophytes—including me—out of it. If there is anything that ought to be truly “professional” it is MOS and MOSNUM; all else can suffer from the standard drive-by shootings by youngsters who don’t know what the hell they are talking about. The two things in common to many editors here is they 1) think they know what they are talking about (citing new international standards such as IEC prefixes like “mebibyte” and “kibibyte” or ISO 8601 and how this somehow constitutes an excuse to use them on Wikipedia), and 2) they actually know precious little about technical writing. Wikipedia is just a playground for the galactically clueless to nourish their self esteem. It is just so absurd. I find this phenomenon to be simultaneously amusing and disgusting. Greg L ( talk) 21:28, 30 September 2009 (UTC)
I'm trying to help expand {{ Convert}} & it's standardization of the abbreviations used. We have come to a wall with the torque measurements. As of right now the kilogramforce-meters to Newton meters & foot-poundforce via {{convert|xx|kgm|Nm lb.ft}} as 10 kilogram metres (98 N⋅m; 72 lb⋅ft). Well as of right now we were working on adding Nm to kgm & ft-lb & ft-lb to kgm & Nm, but we have hit a snag of disagreement & we have agreed that we need the MoS communities opinion on this matter. I say we should use kgm for kilogramforce-meters & Jimp says we should use kgfm. I say we should use ft-lb for foot-poundforce & Jimp says we should use ft-lbf. Also I say we should use Nm for Newton meters & Jimp says we should use N.m. The wiki article for Kilogram-force it states for torque it is "meter-kilogram" & the Torque article has it listed as "meter-kilograms-force" or "kilogrammeter". So thoughts? 「 ɠu¹ɖяy」 ¤ • ¢ 21:40, 21 September 2009 (UTC)
Different disciplines have widely different practices. For instance, the cubic centimeter is an old CGS unit for volume. Nevertheless, the long-standing practice with Japanese motorcycles has been—and still is—to use “cc” for engine displacements. Accordingly, Wikipedia follows real-world practices rather than try promote the adoption of the rule of SI via example (which doesn’t work anyway). So, on the subject of antiquated practices, torque wrenches from ten or twenty years ago will often be calibrated in kg‑f‑meters, which was a common torque unit for Japanese-built automobiles; perhaps it still might be, I don’t know. IMO, an article for instance, on the Ford 351 Cleveland engine, which is sold all over the United States (and not so much elsewhere) ought to use ft-lbs as the primary unit of measure and provide a parenthetical conversion to N‑m. Similarly, if the the subject is about a particular Japanese car where the manufacturer still uses kg‑f‑meters, then that is what I would go with. Where there is no consistent industry practice, I would generally use the proper SI unit (newton‑meter). As a final caveat, if the subject pertains to a subject that is about or is closely related to the United States, one should consider using U.S. customary units throughout (including ft‑lbs for torques).
Many Wikipedians, who are prolific and jump from article to article find this practice of using different units in different articles to be disconcerting. They feel that there should be project-wide consistency. However, the practice using the units of measure that are very common to a particular discipline (with parenthetical conversions to a suitable unit) best serves the interests of our readers (which is why we’re really all here). The purpose of any encyclopedia is to educate readers on a subject and properly prepare them for any future studies they may pursue on the subject. We do our readers no service whatsoever if, in the subject of gravimetry, we mention gravity gradients of “3.1×10−6 s–2” (that unit is pronounced “reciprocal seconds squared”) when virtually all text books on the subject use “3.1 µGal/cm” (pronounced “microgal per centimeter”).
In a nutshell, try to stick to the rule of SI unless an industry practice is rather consistently otherwise or if the subject matter is about or strongly associated with the United States.
That’s my 2¢. Now for “unit-of-measure jihad” and suicide bombers from *standards organizations*… (*wheeeee*) Greg L ( talk) 22:18, 21 September 2009 (UTC)
In that case, as to the exact way to write out these units of measure (such as someone’s suggested “foot-poundforce”), I would dispense with arguments over “what technically makes scientific sense and mustn’t be confused with units of energy” and would certainly jettison weird-looking examples like that subscripted form. We’re not doing anyone a favor by pretending to change how the world works. Moreover, such efforts to change the world will fail anyway; Wikipedia is pretty darn good at spreading misinformation, not in changing the very way people communicate. Technical writing works best when the writing techniques being used to convey ideas don’t call attention to themselves. If there is a sound reason to depart from the rule of SI, I would just use what is most typically used in real-world literature on the subject.
Either that, or do whatever the hell you want. Some of the suggested units up there look retarded to me. I now have a sense that you weren’t so much looking for advise as were simply inviting a pile-on against those who would disagree with you. No help here; just go bicker amongst yourselves. And you and the others might try to use common sense for once and not needlessly confuse readers or call attention to one’s writing style. That beats endless arguing in an effort to prove who’s right.©™® Greg L ( talk) 22:46, 21 September 2009 (UTC)
Jimp is correct in that the standard abbreviation for newton-metre is N·m (note use of a half-high dot). Otherwise it may be confused with nm for nanometre or mN for millinewton. The problem with the foot-pound and kilogram-metre is that neither the pound or the kilogram are units of force, so it's not clear how to abbreviate pound (force) and kilogram (force) in some kind of internationally standardized way. You could come up with some local standard, but someone from some other country would always disagree. I'll have to research that issue. RockyMtnGuy ( talk) 00:55, 22 September 2009 (UTC)
Yes, Jimp is correct on the proper way to write the unit symbol for the newton-meter. As for unit symbols like foot·pound (ft·lb) “house solutions“ and “local standards” like “foot-poundforce” are just that: local standards that are not generally found in the real world. Such *Wikipediaisms* are nothing more than just more grist for, as one editor wrote, above, people to “chuckle good-naturedly” at our “foibles.”
Just because a practice that is common in the world has technical or logical shortcomings when one scrutinizes it doesn’t mean that we need super editors to come to the rescue and right every wrong with the technical-writing world. When General Motors specifies a torque of 75 ft·lb, and since torque is, by definition a force moment, it can quite reasonably be assumed that “force suffix” is implied and the unit really means pound-force or kilogram-force. I find that much preferable to (once again) pretending we’re going to show the world how things ought to be done. The expression “75 ft·lb” in the context of torque confuses no one; the expression “75 foot-poundforce” would just make Wikipedia once again look like it’s been infested by space-cadets.
Once again, I would suggest we look to other encyclopedias and other professional publications for guidance here rather than try to set the world on fire by misapplying our *amazing powers of physics acumen* and trying to invent new and better ways to write common things. Greg L ( talk) 01:52, 22 September 2009 (UTC)
Nm
; example: {{convert|32|Nm|kgm ft-lb}}. I prefer Kg·m, but whatever on that one. But still make formatting/typing easier I think the wiki attribute should be kgm
. As for lb-ft vs. ft-lb, in the US ft-lb (or ft. lb) is more commonly used. 「
ɠu¹ɖяy」
¤ •
¢
05:43, 22 September 2009 (UTC)Note that I am using the non-breaking hyphen ({{nbhyph}}
) for this unit symbol. A template should either be slapping a no-wrap around “lb‑ft” or it should use a non-breaking hyphen.
Note also, Woodstone, that you reverted to the exceedingly common practice of referring to the torque as “foot‑lb”, but that form properly refers to the unit of energy that has a magnitude of ~1.3558 joules. Nowadays, it is not uncommon to hear commercials with Mike Rowe’s baritone voiceover on Ford commercials talking about big, masculine diesel torques of “410 pound‑feet of torque”. Certainly, no one in America will be ‘confused’ by “410 lb‑ft”. And, in my opinion, using this form will not unduly distract or draw attention to the writing style when trying to communicate ideas.
Besides the fact that putting the length of moment arm last is more scientifically valid, it is also in conformance with other units like the N·m and kgf·m, which also have their moment arms last. Thus, this should appeal to those editors here who like project-wide consistency.
Does everyone agree then, that it would be best to write them N·m, kgf·m, and lb‑ft ? Greg L ( talk) 16:54, 22 September 2009 (UTC)
If, it is your intention here to be addressing what is strictly the “default” behavior, then—by all means—I agree with you 100%; converting to N·m should clearly be the default setting. Greg L ( talk) 18:43, 22 September 2009 (UTC)
Agree that N·m should be the default and preferred "to"-unit. But as explicitly requested unit I would prefer to write kg-m (no explicit "force", but with dash to avoid confusion with the wrong dimensioned kg times meter) and similarly lb-ft. − Woodstone ( talk) 19:51, 22 September 2009 (UTC)
The template is not meant only for science articles. Only a few articles use this obsolete unit. The template is currently flexible enough to allow the option of "kilogram-metres" and no "f" in the abbreviation.
Changing the default outputs for torque units is a different question. Having them include kilogram (force)-metres would be a bad idea but there's no such proposal at template talk:convert. JIMp talk· cont 20:59, 22 September 2009 (UTC)
(outdent)
I see that you, Jimp, are suggesting that the template is also suitable for science-related articles. If so, then the challenge is to get all the *truly proper* forms in as well as the *real-world industrial* forms and to provide succinct and clear guidance on how to use the template. Greg L ( talk) 21:14, 22 September 2009 (UTC)
So which abbreviations have we come to a consensus to & which approach should we take on this exactly, because I'm not completely clear on the current stance we are at. 「 ɠu¹ɖяy」 ¤ • ¢ 21:33, 22 September 2009 (UTC)
This isn’t even always a “this vs. that” issue; there are shades of gray. Whereas “ft‑lb” might be particularly suitable for automotive and industrial, purposes, if one were discussing motor torques on ski lifts, “lb‑ft” may be more appropriate. In an article on the polar moment of inertia of the Saturn V moon rocket, a torque of “lbf·ft” or something like that might be more appropriate.
I can certainly tell you from having horsed around on 250 kV Mitsubishi circuit breakers that are as big as a VW van (and Hitachi and Siemens, etc.) that there are a wide variety of practices with lots of units of measure. These practices apply also to pressures in a fashion that—once again—drags the kilogram into units of measure where it is employed as a unit of force. You can find “kg/sq cm”, “kg‑f/cm2, and all sorts of things you would find to be abomination unto the eyes of the technology gods. We need to provision for lots of stuff because we can’t become instant experts in every niche discipline by sitting on our butts performing Google searches to prove this point or that. Greg L ( talk) 22:11, 22 September 2009 (UTC)
Then I will propose this, I will break the torque table down into two categories, "Industrial" & "Scientific". Industrial will use ft-lb, kg-m & N·m, while Scientific will use ft-lbf, kgf-m & N·m. I will set it up where it will be different, yet still easy to use. 「 ɠu¹ɖяy」 ¤ • ¢ 22:21, 22 September 2009 (UTC)
BTW: Why is our article on the “foot-pound” unit of energy titled Foot-pound force? Talk about misleading. What they mean is “Foot·pound-force (unit of energy)”. But that title has the connotation of “Foot-pound (force).” Not wise, IMO. I’d suggest simply “Foot-pound (energy)” and provide some redirects.
And, no, gu1dry, you don’t want to be linking to that one, regardless of whether someone fixes that title. It appears Wikipedia might not have a dedicated article on the unit of torque that would be titled something like “Pound-foot (torque)” Greg L ( talk) 00:51, 23 September 2009 (UTC)
Here’s the terminology:
There appears to be widespread but vague sentiment against the duplication of scope in the two style guides, because it's a recipe for contradictions to develop, and fragments dialogue about the overlapping part of the scope.
Again, I put it to you that MOSNUM should deal with specialised guidance alone, in these areas:
I intend to create a draft of this. Tony (talk) 08:48, 23 September 2009 (UTC)
I agree that there's too much duplication, but removing all of it would have the problems which Jc3s5h and Wjemather described. If a section is in MOSNUM, then MOS should have only a short summary of it, addressing only the aspects of it which one needs to look up more often, and possibly should have a clear indication of what is a summary and what is the "master" section: for example
<-- This section is a summary of [[WP:MOSNUM#Currencies]]; make sure that any edit to this section represents the section on WP:MOSNUM faithfully. If you want to change the actual content of the guideline, discuss it at WT:MOSNUM. -->
at MOS, and
<-- [[WP:MOS#Currencies]] is a summary of this section. When making significant edits to this section, please update the summary at WP:MOS accordingly. -->
at MOSNUM. (Now there's such a comment at the top of MOSNUM, but it should be put at the top of every section having a summary at MOS, so that people editing single sections will read it as well. Also, the "summaries" at MOS should be much shorter than they are; here's my take.) -- ___A. di M. 00:10, 24 September 2009 (UTC)
I had a post, above, where I suggested what I wasn’t seriously thinking would really be adopted: Appoint three editors who have journalism degrees to oversee MOS and MOSNUM and kick all the neophytes—including me—out of here. And that started me thinking… who the heck here actually has a four-year degree in journalism? If we can identify three such experts, we could, conceivably, appoint them to special positions here. Anyone… anyone? Before we get bogged down in what special responsibilities they might have, let’s first identify who these editors, if any, might be.
P.S. Please spare the rants about how others with elite privileges might infringe on your God-given right to influence the universe through Wikipedia. Let’s reserve the infinitely expandable white space, below, for those who have journalism degrees to identify themselves. Greg L ( talk) 22:17, 30 September 2009 (UTC)
Oh, well… What outstanding arguments for those with no formal training in journalism to reign supreme; the experts are all screwed up! That’s why we don’t look towards the internationally distributed, English-language Encyclopedia Britannica for guidance, the pros over there don’t inspire “confidence.” Greg L ( talk) 00:18, 1 October 2009 (UTC)
¶ (edit conflict) Qualifications in journalism and formal certificates in journalism vary very greatly between countries and eras. In Germany, you can get a certificate in journalism from a higher technical high school. When I attended the University of California, Berkeley, which has educated hundreds of highly-professional journalists, the School of Journalism wouldn't even grant bachelor's degrees; undergraduates had to major in something else. (It's often thought infinitely more important to get a either sound liberal education that includes English and other languages, or to learn a specific field such as history, political science, economics, natural science, religion, international affairs or regional studies, or both.) And I think that even today, at least in countries where entry isn't governed (as it has been in England) by union and apprenticeship regulations, a large proportion of the best writers in journalism have always been those who never received (or even) sought any formal degree in journalism.
But knowledge of usage, grammar and punctuation is secondary to good writing for publication or broadcast, and good writing is only one of the skills a good reporter or editor must learn. So while I understand the sentiment (without agreeing with it), formal certificates in journalism would only be a peripherally-useful indication of ability to police the Manual of Style. The job, for better or worse, still remains with us. —— Shakescene ( talk) 00:47, 1 October 2009 (UTC)
A similar idea was actually tossed around at WT:FAC this week. That proposal suggested that all MOS pages be locked, and once per quarter gatekeppers (who should not be required to have a particular degree - something we can't verify anyway) would implement any changes that have reached consensus on the various talk pages in that time. This would help make the MOS a lot more stable and actually require consensus for making changes. Karanacs ( talk) 15:55, 1 October 2009 (UTC)
Folks, it's been going on for a while, and we seem to be close. Skomorokh was the admin who last commented that there wasn't yet consensus for him/her as a gatekeeper to make the change. The so-called pink version (not very pink on my monitor) seems to be the final one. Feds and anyone else, will you please state briefly here any concerns you have, and how exactly you'd like the wording to be changed (if at all)? Let's hope we can contact Skomorokh soon. Tony (talk) 04:07, 17 September 2009 (UTC)
I think we have a pretty fair consensus against using all-numeric date formats though perhaps we had better advertise it more widely before we risk a backlash from those who have grown used to the notion that refs should use YYYY-MM-DD. I'm not convinced that we have the issue on whether to allow AP dates or not settled. I'm not the only one who's expressed the opinion that they can be happily done without. A third issue which hasn't really been much discussed is whether to allow three-letter+dot abbreviations (e.g. Apr.). JIMp talk· cont 10:40, 17 September 2009 (UTC)
← (outdent)
It could be that many editors don’t even recognize the common monthly short-form method when they come across it (the one memorialized by the A.P.) and wouldn’t have a clue where to look up the practice; frankly some 90+% of Wikipedia editors don’t own a single print manual of style, so WP:MOS and WP:MOSNUM are the only places they can get proper guidance. The A.P. didn’t just make this stuff up; it is a long-time practice that probably goes back to the 19th century when spittoons littered the floor of every newspaper office in the U.S.
The short-form technique is a compromise of sorts in the effort to always write out months but to shorten the really long-named months in parentheticals; e.g., The magazine Science Week (issue 38, Sept. 15, 2007) referenced the first use of…. It is a technique to which any half-way literate reader has long been exposed and likely never noticed it in their newspaper’s Letters To the Editor section; e.g. I enjoyed your article regarding teacher pay (“Public servants’ pay lagging,” Sept. 28), and feel you…. If it is not one of the longish-looking months, then it isn’t abbreviated and appears like this one, (which is one of my own letters in Aviation Week & Space Technology): Prof. T. Nejat Vezirogluʼs letter “Hydrogen, Future Airline Fuel?” (AW&ST June 23, p. 12) says….
The only basis I know of for not showing our many, would-be, all-volunteer editors from all walks of life how to properly abbreviate months when doing good, encyclopedic writing, would be this argument: “let editors just use common sense.” Given the chronic and obvious shortcomings endemic throughout Wikipedia, that argument makes no sense to me whatsoever as it completely flouts reality. Frankly, I often suspect such arguments from any experienced Wikipedia editor who has to know better, is just a smoke screen for “I like ta do it my way so don’t prescribe any way of doing it.” Either that, or it is being used as an excuse to push a God-awful-looking three-letter practice (that should be strictly limited to fixed-width uses in long tables) because it has “logic” and Wikipedia ought to once again Lead the Way and Show the World How Technical Writing Is Properly Done®™©. Greg L ( talk) 17:48, 17 September 2009 (UTC)
{{Dts}} makes YYYY-MM-DD unnecessary in sort tables nor does it save a great deal of space compared to three-letter abbreviations. Although putting the year first (whether it be numbers or letters for the month) solves the month-day vs day-month problem unambiguously, it's just not usual in English. God-awful-lookingness is in the eye of the beholder. Some would rather behold three letters than AP style. It seems I'm not the only such beholder. However, I would concede that Woodstone is correct in saying that it's too early to speak of consensus for a change which will be as wide reaching as ridding WP of YYYY-MM-DD. Though perhaps we can settle whether to allow Mar., Apr., Jun., Jul. or Sep. (i.e. three letters + dots, as suggested by The Feds, not covered by AP). JIMp talk· cont 18:48, 17 September 2009 (UTC)
¶ Ordinal suffixes actually make US-style dates (e.g. April 11, 1171) easier to read, because commas and spaces don't always come out well or separate numbers clearly. At the end of a sentence, they're better than a simple period (full-stop) in separating a date from the beginning of the next sentence. Although I learned to read about 55 years ago, I still listen to what I read (without moving my lips) because it helps when I have to read or act something out loud, and because it's the best way of grasping the author's logic, rhetoric, grammar and emphasis , so 1st, 14th, 2nd, 23rd, etc. reflect my normal usage. That's not an argument to impose ordinals on anyone else, but I see no reason to forbid ordinal suffixes, either. Once upon a time, ordinal suffixes interfered, I'm told, with date auto-formatting, and print publishers trying to save space chopped them, as they abbreviated months to Aug., Sept., etc, but neither of these considerations need apply. This is just another case where I differ from others on this Talk Page in not seeing great value in uniformity for its own sake, and we are trying to save space and reduce the number of rules that editors need to heed. —— Shakescene ( talk) 20:54, 17 September 2009 (UTC)
My two cents:
BTW, I suggest this:
-- ___A. di M. 10:16, 18 September 2009 (UTC)
Well, I'm afraid that won't do, because it does not ban YYYY-MM-DD, which we've agreed we need to do explicitly. Also, I don't like the idea that it is "not desirable to spell out long month names" in footnotes. Saving a maximum of four characters (yes, that is all the A.P. style achieves) is never going to be critical in a footnote. I thought we had more or less agreed that it was only in tables with narrow columns that dates need not be written out in full. I'm still not clear what is wrong with the proposal in the pink box. --
Alarics (
talk)
11:58, 18 September 2009 (UTC)
BTW, I don't for a moment imagine that in practice we can stop people using YYYY-MM-DD overnight. The point is that once there is an authoritative text clearly deprecating that form, we can point to it if people complain when we change their numerical date to a proper date. -- Alarics ( talk) 12:09, 18 September 2009 (UTC)
And to LeadSongDog, it doesn’t matter if you stridently believe that everyone from Koko to Einstein instantly understands 2009/05/12, it isn’t at all proper, encyclopedic technical writing to use all-numeric dates; one always writes out the name of the month (or an abbreviation). Always. If you don’t understand that yet, it’s beginning to dawn on me that you might never. If you do understand that, but believe (hope) that yours is a *new way and Wikipedia will show all the other encyclopedias and all the other professional publications how to properly write out dates*, you are mistaken; we will just have a second-rate-looking product that looks like it is the product of space cadets with no journalism or technical writing experience whatsoever. Go crack open an Encyclopedia Britannica if you don’t understand any of this. If your response is “well… Wikipedia is written for an *international* (*sound of blair trumpets*) audience,” I’ll respond “yeah, an English-speaking one at that; so go take a look at the language Encyclopedia Britannica is written in.” Greg L ( talk) 15:02, 18 September 2009 (UTC)
I'm unclear where YYYY-MM-DD references the Gregorian Calendar. Maybe I missed it. Anyway, we're mostly talking about normal dates, not ancient ones. Even if we're talking about ancient dates, YYYY can either be zero or blank-filled. OTOH, if you're for some reason talking about Mayan dates or similar unusual calendars, you've lost me. - Denimadept ( talk) 15:04, 18 September 2009 (UTC)
Moreover, if you really wanted to do a ‘proper’ job of citing, I’d point out that Science News, like pretty much all periodicals, has this sort of little diddley thing in the upper right-hand corner: October 13, 2007 so I find arguments that YYYY/MM/DD has some sort of intrinsic virtue in citations (or any other place on Wikipedia, for that matter) to be profoundly uncompelling. You aren’t going to convince anyone here of anything if your arguments crumble so badly and easily in the face of reality.
It’s so profoundly simple: act like any other half-way professional publication and simply write out the month because it reads more naturally and is unambiguous. Besides looking awful, all-numeric dates are especially awkward for European readers and those in other countries where they customarily write out dates like “8 December” and “8/12.” Because of daily reinforcement, these readers are accustomed to seeing the month last and have to mentally flip this order around just because it is preceded by a year. It is of no help if ISO, JIS, ANSI, or IPSO FACTO endorse this or that standard; it’s all BS because the only thing that matters is what is most natural in the daily life of the reader. Any all-numeric date format—even if it is a “standard” (*sound of heavenly female oratorio*) endorsed by Santa Claus and Oprah herself—is inherently ambiguous. Moreover, all-numeric dates don’t look in the least bit professional—they aren’t the least bit professional—which is why quality publications don’t ever use them.
Give it up. Can you not see the handwriting on the wall that all-numeric dates of any sort are toast? Completely burnt toast? Let’s get over this. There is no compelling reason to depart from standard practices observed by any quality publication—including all English-language encyclopedias. It is über‑stupid that so much verbiage has been devoted to something so elementary. Greg L ( talk) 05:04, 19 September 2009 (UTC)
It just struck me yesterday that if one really needed to save space in giving a date while still avoiding ambiguity, you could use what I think of as librarians' abbreviations for the months (because they sometimes appear on due-back rubber stamps and works such as the Readers' Guide to Periodical Literature): Ja, F, Mr, Ap, My, Je, Jl, Au, S, O, N & D. So long as the year is expressed as more than two digits, there's no ambiguity, although of course these abbreviations are hardly universal or intuitive. (And, no, there's no "a" in June or July, no "e" in January or July, no "l" in January or June, no "p" in August, no "u" in April, no "r" in May and no "y" in March; unlike US State abbreviations such as AL, AR, MI or MS which often confound most Americans who don't work for the Post Office, there's no way to mistake which month "Je" refers to.) So all dates after the year 999 could theoretically be compressed to between 6 and 8 digits without dashes as 18S2009, 4Jl1776, 5N1605 or 14Jl1789. As Independence Day and Bastille Day show, however, clarity would dictate, either capitalizing the L in Jl (as with litre), or requiring spaces.
This is not a serious proposal, and, although unambiguous would be hard for the average reader to understand, but probably no more so than YYYY-MM-DD (which is ambiguous to those unfamiliar with it). But I wanted to show that YYYY-MM-DD is not the only possible way to compress dates, nor even the shortest. —— Shakescene ( talk) 20:24, 18 September 2009 (UTC)
¶ That (not Klingon or Julian days) is pretty much the way I abbreviate dates for myself (e.g. 12 Ap 1861 or 4:45 Tu 20 O), so I wasn't being utterly fanciful. But while I think my system might be easier to grasp at first sight and less ambiguous than 2009-09-19, I wouldn't recommend either for Wikipedia because the average reader would be thrown unless the table or list explained the whole dating system. And with the right templates to convert and re-convert dates, Julian days (adjusted for the fact they begin at noon) would be a great way to store dates, far better than the range-limited and notorious systems for Excel in Windows (which thinks there was a 29 Feb. 1900) and Macintosh (which has an equally glaring error that I've forgotten). —— Shakescene ( talk) 19:56, 19 September 2009 (UTC)
There is an international standard and it is YYYY-MM-DD, so why don't we use it? To quote from the ISO site, it's
and ISO 8601 corresponds to the UN Working Party on the Facilitation of International Trade Procedures in its Recommendation 7. -- Cavrdg ( talk) 07:11, 19 September 2009 (UTC)
P.S. At 2009-09-19T1630 I read Recommendation 7. Nice standard… for time-stamping the ticket for going into the Chunnel between England and France. Not to be used in encyclopedias. Greg L ( talk) 16:41, 19 September 2009 (UTC)
The actual reason why we can't seem to get consensus on anything is that we're trying to discuss several related but distinct issues at once. This all started with a suggestion to ban the 12/09/2009 format, and no-one seems to disagree with that; so, why don't we just add to the MoS:
Do not use date formats such as 03/04/2005, as they are ambiguous (it could refer to 3 April or to March 4); for the sake of consistency, do not use them when the day number is greater than 12, either.
meanwhile, and then continue discussing the remaining issues (YYYY-MM-DD, AP abbreviations, three-letter abbreviations) more calmly? -- ___A. di M. 09:00, 19 September 2009 (UTC)
In my book, this phenomenon is akin to walking right up to a party at a house where everyone is heading out the door and saying “No no… everyone back in. I got here late and missed out on it all so everyone start over and begin discussions with me included this time.” (*sigh*)
This seems to be the “Wikipedia way®™©” right now and we might one day establish rules that if debate is wrapping up and someone crashes his damned SUV through the living room wall and yells “start all over with me!” that we’ll just inform said editor that, with thousands of editors, we must cut off debate at some point. Greg L ( talk) 16:06, 19 September 2009 (UTC)
Now, you wrote above I cannot possibly see anything wrong with all-numeric dates in the practically unambiguous from [sic] of 2009-09-17 and strongly oppose banning it. All portions of that position are demonstrably false. As is clearly explained above, all-numeric dates like “2009‑11‑09” are inherently ambiguous. Moreover, they look poor. For these, and probably still other reasons, no English-language encyclopedia uses them; it is not proper journalistic practice. If you want Wikipedia to diverge from standard encyclopedic practices, you’ll need to come up with a really compelling reason for doing so. Ain’t seen one out of you so far. Greg L ( talk) 18:49, 19 September 2009 (UTC)
The fact is, no proper English-language publication of any sort uses all-numeric dates. As I said above, if you want Wikipedia to diverge from standard encyclopedic practices, you’ll need to come up with a really compelling reason for doing so.
Does your argument that Wikipedia should flout these well-established practices amount to nothing more than “you like-ta”? Do you think all-numeric dates are exceedingly modern—even futuristic? Do you believe what some I.P. editor once wrote (fantasized) on ISO 8601? You know, that bit about how ISO 8601 “applies to all written communications … [even] hand written … when communicating … even privately.” Are you seriously asking us to believe that people are being “old-fashioned” when the write a handwritten note to their mother that spells out the name of a month?
Let me know when the rest of the world starts writing notes like this to their mother:
Mom,
I went to Brad’s house to play with his Star Wars collection. Be back at 2009-09-19T1741.
(Unindent) Woodstone asked "why is there any need to proceed to the heavyhanded action of a ban of a specific form that does not create any problems? (Emphasis added.) No specific form has been put forward. The various forms that could be used will create problems due to ambiguity. Writing "dates like 2009-11-09" leaves too much to the imagination and interpretation of editors. If something more specific were written, it would be well-neigh impossible to communicate it to readers. -- Jc3s5h ( talk) 20:47, 19 September 2009 (UTC)
Do not use date formats such as 03/04/2005, as they are ambiguous (it could refer to 3 April or to March 4).
From above by Greg L: "The fact is, no proper English-language publication of any sort uses all-numeric dates". This is simply nonsense. Use of dates written like 9/11/2001 is very common, both in running text, and in isolated places, like headers of articles or in tables. Wikipedia is rightly deviating from that practice, because its international readership would easily be led to mistaken interpretations. However, outside of running text, in some cases a more condensed form is prefarable. For that purpose the form "2001-09-11" is the most suitable, because of its unambiguity and international recognition. And, by the way, vertical alignment cannot be achieved with textual months in the variable size fonts, now almost universally seen, even on computers. − Woodstone ( talk) 22:51, 19 September 2009 (UTC)
As for your Wikipedia is rightly deviating from that practice, because its international readership would easily be led to mistaken interpretations. What an absurd thing to write! No international readership could possibly be confused by either November 9, 2002 or 9 November 2002. Conversely, the very thing your are promoting, all-numeric dates, are precisely the very thing that can cause confusion. Why? Simply because most people in their daily lives write these dates in some parts of the world as 9‑11‑2002 and still others 11‑9‑2002. Then there is this idiotic practice that you’re promoting because it is a *standard* (big whoop, it was never intended for use outside of stuff like airline tickets) that very few people anywhere outside of Star Trek conventions (and Wikipedia editors who have zero formal training in journalism) ever use: 2002‑11‑9, which is particularly confusing to European readers.
As for your tiresome refrain about “international” readerships, are you even reading what you’re writing? Do you think Encyclopedia Britannica is only read by Americans and Britons?.
It simply boils down to the fact that we have yet another “IEC prefix” crowd that is absolutely convinced of the superiority of a new *standard* and feel Wikipedia should be hijacked so we Can take the lead and show the world the path to a brighter and more logical future by adopting and misconstruing every *standard* ever proposed.©™® Uhm… no. As we learned from the IEC prefix experience, Wikipedia simply follows the way the real world works and never tries to promote change by adopting practices that are used only by Trekies, computer programmers, and a handful of Wikipedia editors. If it isn’t in other manuals of style, it’s probably a ratty idea.
I think I’m gonna start an RfC to institute a rule that the only people who can edit MOS and MOSNUM are people who A) have journalism degrees, and B) have multiple resource books and “real” manuals of style such as Chicago Manual of Style and the AP Manual of Style. Then inane suggestions will hopefully evaporate, such as suggestions that Wikipedia is *uniquely* read by international readers (but Encyclopedia Britannica is not) and this is somehow a reason to engage in confusing practices that flout Technical Writing 101 and introduce confusion rather than reduce it (and looks like crap to boot). If adopted, I’d be eliminated from contributing, but so too would about 99% of the people who do drive-by shootings on MOS and MOSNUM because they’re out to show the world how things *oughta* be done. I’d welcome that. My older brother has an advanced journalism degree and taught college-level journalism. Under this proposal, he could contribute to MOS and MOSNUM. But then, he’s too damned smart to waste his time here. Greg L ( talk) 02:23, 20 September 2009 (UTC)
Okay, Woodstone, yes, you're right; dates with three-letter abbreviations won't align (without some fancy adjustments). I wasn't thinking about the variable width of letters in the font used here. Chalk that up as an advantage of YYYY-MM-DD. Weighed against the disadvantages of YYYY-MM-DD, though, alignment hardly counts for much (but if we really must have it, I'll write us a template to align dates with three-letter abbreviations).
How could people think YYYY-NN-NN dates might possibly be YYYY-DD-MM? It defies all logic. This format is never used. It makes no sense ... right? Nonetheless people do make this mistake. That's enough, we don't need to fathom why. The format is unfamiliar.
Wjemather thinks YYYY-MM-DD dates "are apporopriate in certain circumstances such as in citations". Why? What is so special about citations that we have to use a different format than that used in the rest of the article? I've never been able to get this one. We see it all over the place, though. No, the only theory I can come up with is that people have just grown used to seeing this in citations because it was once the required input format for the citation templates. The format is unfamiliar & ambiguous, the only circumstances on WP where it's appropriate is hidden from view. JIMp talk· cont 16:07, 20 September 2009 (UTC)
Woodstone: Let’s attend Real World 101 here for a moment and also get into Woodstone’s mind. Let’s hook up the ol’ EEG to his brain…
As for your …in my view the form yyyy-mm-dd is more natural and flowing, the general consensus here is that it is certainly not and your achievement of providing links to web sites that use all-numeric dates is utterly irrelevant to this discussion.
This should be the end of it. As with the IEC prefix debate, there was one editor who absolutely would not agree that “mebibyte” had no place on Wikipedia since it was *the future*. He ended up just falling on his sword and left Wikipedia. A “general consensus” on Wikipedia does not mean that 100% of editors are in full agreement and it never did. I would hope, Woodstone, that you will just realize what’s in the cards here for all-numeric dates on Wikipedia. No professionally produced, English-language encyclopedia uses them and there is no compelling reason in the world for Wikipedia to do otherwise. Greg L ( talk) 20:17, 20 September 2009 (UTC)
It is clear that you have strong convictions about how it is you edit and nothing will ever change your mind. This is only about adhering to style guidelines that other encyclopedias use but you behave as if it is the end of the world.
It is clearly pointless for me—and probably anyone else here—to further debate you. I will leave it to others to try to deal with you. There is ample electronic white-space, below for you to get in the last word as I will no longer deal with you. Goodbye and happy editing. Greg L ( talk) 20:54, 20 September 2009 (UTC)
I agree. It is mainly footnotes that are still at issue. Most of us think that YYYY-MM-DD is never necessary in citation footnotes, and should therefore be avoided because it can be an obstacle to understanding. A minority disagree, and think we should say that it can be used in footnotes. Can we bring Tony back in to suggest what should happen next? I will go along with whatever he recommends. -- Alarics ( talk) 11:59, 21 September 2009 (UTC)
I like the sound of the discussion here about eliminating ambiguous date formats such as 03/04/2005. Now that date autoformatting is gone, and citation templates now no longer covert ISO dates into dd mmm yyyy or mmm ddd yyyy, so the reference section is often a messy mix of formats. I think we should simplify the section #Format consistency to read:
Dates in article body text and in article references should all have the same format
I also think the exemption for tables and infoboxes can still apply. Ohconfucius ( talk) 12:23, 22 September 2009 (UTC)
Status quo is acceptable. "Slash dates" are an abomination, everyone agrees, we will never get agreement on dmy vs mdy, and Pseudo ISO are good for tables and lists for a number of reasons apart from dynamic sorting. Since we suggest never using pseudo-ISO for dates before 1583 the "ZOMG" scenario "what if someone puts the date 83-12-25, out readers will have brain failure!" doesn't arise. If we were writing 20091225 I might agree that it presents readability problems... Rich Farmbrough, 14:03, 22 September 2009 (UTC).
Headbomb, you can't say "2009-09-06 is unambiguously recognized as meaning "6 September 2009" everywhere on the globe" when we have had people saying on this very page that they didn't recognise any such thing. If there are WP editors who aren't sure what it means, there must be zillions of readers for whom that is even more true. -- Alarics ( talk) 16:24, 23 September 2009 (UTC)
I maintain my position that the ISO has contaminated the YYYY-MM-DD format beyond repair and it should not be used in an uncontrolled environment such as Wikipedia. For those who believe otherwise, I put the following questions:
(By "require" and "allow" I mean that the MOSNUM encourages every editor to edit any article to avoid ambiguous or unexplained use of the format.) -- Jc3s5h ( talk) 16:28, 23 September 2009 (UTC)
(unindent)Then you have no idea how standards work. The only formal standards that are in effect in the absence of a specific adoption by a publication are those that are imposed by law. ISO 8601 is not a law. Some Wikipedia editors might think they are using the ISO 8601 format when they write dates like 2009-09-23, but they are mistaken.
Of course, one could adopt the standard for a single article by explicitly stating in the article this had been done, but I've never seen an article with such a statement. -- Jc3s5h ( talk) 18:55, 23 September 2009 (UTC)
(unindent) There are no criteria to decide if the dates in the following table are written correctly. This table is based on a New York Times article.
Date | Event |
---|---|
1952-09-23 | Richard Nixon's "Checkers" speech |
-62-09-23 | Caesar Augustus born in Rome |
-- Jc3s5h ( talk) 20:39, 23 September 2009 (UTC)
The only method that is abundantly clear and unambiguous is “November 11, 2009” and 11 November 2009. Now those are unambiguous, which is probably why the English-language, internationally circulated encyclopedia known as Encyclopedia Britannica doesn’t use all-numeric dates for anything in its publication.
Having said all that, I’d go along with allowing its use in tables only as long as the header contains a parenthetical legend, such as Date Inducted Into Hall of Fame (dates are Year-month-day). And even that is a darn big compromise given that three-letter monthly abbreviations fit just as nicely in tables as your cursed all-numeric date method. Greg L ( talk) 20:45, 23 September 2009 (UTC)
Name | Date of death |
---|---|
William Shakespeare | 23 April 1616 |
Miguel de Cervantes | 23 April 1616 |
::::::::doesn't stop being misleading just because "April" is spelt out. (Then, if the problem is that some people believe all YYYY-MM-DD dates to be ISO 8601, then the current wording discouraging its use for pre-1583 and non-Gregorian dates already solves it.) -- ___A. di M. 09:42, 24 September 2009 (UTC)
(unindent) I believe Wjemather's claim that "YYYY-MM-DD suffers from no such problems and, by definition, should always be in the (proleptic) Gregorian calendar" is false. Please provide a citation from a book that addresses the entire English language (such as a dictionary, style guide, or grammar book) supporting this claim. Citations from standards are useless, since standards only apply to those who explicitly choose to adopt them, or when the standard is adopted by law.
Alternatively, propose on Village Pump that Wikipedia declare a policy that all numeric dates must adhere to ISO 8601:2004 and see how far you get. -- Jc3s5h ( talk) 22:19, 23 September 2009 (UTC)
How say we just start one of those table-style RfCs (last used on IEC prefixes) where we all just register our opinion on some wording. If I’m reading A. di M.’s recent post correctly, I see he is now supportive of simply using A.P. months for parentheticals and three-letter abbreviations for tables. Why don’t we then have an up/down RfC (or, as wjemather might claim, “a !vote”) on Second pink‑div, above? Greg L ( talk) 23:51, 23 September 2009 (UTC)
Date and time (UTC) |
Time (local) |
Lat. | Long. | Depth | Mag. |
---|---|---|---|---|---|
30 Mar 2009 13:38:39.3 | 15:38:39.3 | 42.33° N | 13.35° E | 2 km (1 mi) | 4.4 (Mw) |
05 Apr 2009 20:48:56.4 | 22:48:56.4 | 42.36° N | 13.37° E | 2 km (1 mi) | 4.0 (ML) |
06 Apr 2009 01:32:41.4 | 03:32:41.4 | 42.38° N | 13.32° E | 2 km (1 mi) | 6.3 (Mw) |
06 Apr 2009 02:27:48.2 | 04:27:48.2 | 42.37° N | 13.23° E | 2 km (1 mi) | 4.3 (mb) |
06 Apr 2009 02:37:05.3 | 04:37:05.3 | 42.41° N | 13.32° E | 2 km (1 mi) | 5.1 (Mw) |
06 Apr 2009 03:56:48.1 | 05:56:48.1 | 42.38° N | 13.34° E | 10 km (6 mi) | 4.5 (mb) |
06 Apr 2009 07:17:16.1 | 09:17:16.1 | 42.47° N | 13.40° E | 30 km (19 mi) | 4.4 (mb) |
06 Apr 2009 16:38:10.7 | 18:38:10.7 | 42.38° N | 13.32° E | 2 km (1 mi) | 4.4 (Mw) |
06 Apr 2009 23:15:37.7 | 01:15:37.7 | 42.48° N | 13.41° E | 2 km (1 mi) | 5.1 (Mw) |
07 Apr 2009 09:26:30.7 | 11:26:30.7 | 42.31° N | 13.35° E | 10 km (6 mi) | 5.0 (Mw) |
07 Apr 2009 17:47:38.3 | 19:47:38.3 | 42.30° N | 13.40° E | 13 km (8 mi) | 5.6 (Mw) |
07 Apr 2009 21:34:30.9 | 23:34:30.9 | 42.34° N | 13.37° E | 2 km (1 mi) | 4.5 (mb) |
08 Apr 2009 04:27:42.5 | 06:27:42.5 | 42.30° N | 13.43° E | 2 km (1 mi) | 4.0 (ML) |
08 Apr 2009 22:56:51.0 | 00:56:51.0 | 42.55° N | 13.34° E | 2 km (1 mi) | 4.1 (Mw) |
09 Apr 2009 00:53:00.6 | 02:53:00.6 | 42.53° N | 13.39° E | 2 km (1 mi) | 5.4 (Mw) |
09 Apr 2009 03:14:52.7 | 05:14:52.7 | 42.35° N | 13.46° E | 2 km (1 mi) | 4.3 (mb) |
09 Apr 2009 04:32:46.0 | 06:32:46.0 | 42.45° N | 13.39° E | 2 km (1 mi) | 4.3 (mb) |
09 Apr 2009 04:43:12.3 | 06:43:12.3 | 42.52° N | 13.34° E | 10 km (6 mi) | 4.0 (ML) |
09 Apr 2009 13:19:35.8 | 15:19:35.8 | 42.33° N | 13.23° E | 40 km (25 mi) | 4.0 (ML) |
09 Apr 2009 19:38:17.4 | 21:38:17.4 | 42.52° N | 13.35° E | 2 km (1 mi) | 5.2 (Mw) |
10 Apr 2009 03:22:23.6 | 05:22:23.6 | 42.49° N | 13.42° E | 2 km (1 mi) | 4.0 (mb) |
13 Apr 2009 21:14:25.7 | 23:14:25.7 | 42.55° N | 13.42° E | 2 km (1 mi) | 5.1 (Mw) |
14 Apr 2009 20:17:28.9 | 22:17:28.9 | 42.55° N | 13.23° E | 10 km (6 mi) | 4.0 (ML) |
15 Apr 2009 22:53:08.7 | 00:53:08.7 | 42.54° N | 13.28° E | 2 km (1 mi) | 4.0 (ML) |
23 Apr 2009 15:14:10.6 | 17:14:10.6 | 42.22° N | 13.44° E | 10 km (6 mi) | 4.0 (ML) |
23 Apr 2009 21:49:01.0 | 23:49:01.0 | 42.24° N | 13.48° E | 2 km (1 mi) | 4.3 (Mw) |
22 Jun 2009 20:58:40.3 | 22:58:40.3 | 42.44° N | 13.29° E | 2 km (1 mi) | 4.7 (Mw) |
03 Jul 2009 11:03:09.0 | 13:03:09.0 | 42.38° N | 13.32° E | 2 km (1 mi) | 4.1 (ML) |
-- Alarics ( talk) 16:34, 24 September 2009 (UTC)
(edit conflict)
Ah… splendid. Some real-world examples. Yes; the cited example is nothing but a sea of data that isn’t intended to instantly communicate a particular thought. It is a table of particular events and attributes that one must inspect and carefully parse if they want to extract anything meaningful. And if ISO / BIPM / IACUC / UFOP-formatted dates were limited to stuff tables this, I could be a peace.
But let’s examine for a moment, whether doing this practice actually best serves the interests of our readers, or if it is nothing more than an method of what best appeals to our inner Jonny Quests. Let’s say that there is a particular whopper of an earthquake that occurred in June that knocked down a childrens’ hospital. Quick… go find it. Ready… set… GO.
Date (YYYY-MM-DD) and time (UTC) |
Time (local) |
Lat. | Long. | Depth | Mag. |
---|---|---|---|---|---|
2009-03-30 13:38:39.3 | 15:38:39.3 | 42.33° N | 13.35° E | 2 km (1 mi) | 4.4 (Mw) |
2009-04-07 17:47:38.3 | 19:47:38.3 | 42.30° N | 13.40° E | 13 km (8 mi) | 5.6 (Mw) |
2009-04-07 21:34:30.9 | 23:34:30.9 | 42.34° N | 13.37° E | 2 km (1 mi) | 4.5 (mb) |
2009-04-08 04:27:42.5 | 06:27:42.5 | 42.30° N | 13.43° E | 2 km (1 mi) | 4.0 (ML) |
2009-04-15 22:53:08.7 | 00:53:08.7 | 42.54° N | 13.28° E | 2 km (1 mi) | 4.0 (ML) |
2009-04-23 15:14:10.6 | 17:14:10.6 | 42.22° N | 13.44° E | 10 km (6 mi) | 4.0 (ML) |
2009-04-23 21:49:01.0 | 23:49:01.0 | 42.24° N | 13.48° E | 2 km (1 mi) | 4.3 (Mw) |
2009-06-22 20:58:40.3 | 22:58:40.3 | 42.44° N | 13.29° E | 2 km (1 mi) | 4.7 (Mw) |
2009-07-03 11:03:09.0 | 13:03:09.0 | 42.38° N | 13.32° E | 2 km (1 mi) | 4.1 (ML) |
Date and time (UTC) |
Time (local) |
Lat. | Long. | Depth | Mag. |
---|---|---|---|---|---|
30 Feb 2009 13:38:39.3 | 15:38:39.3 | 42.33° N | 13.35° E | 2 km (1 mi) | 4.4 (Mw) |
7 Apr 2009 17:47:38.3 | 19:47:38.3 | 42.30° N | 13.40° E | 13 km (8 mi) | 5.6 (Mw) |
7 Apr 2009 21:34:30.9 | 23:34:30.9 | 42.34° N | 13.37° E | 2 km (1 mi) | 4.5 (mb) |
8 Apr 2009 04:27:42.5 | 06:27:42.5 | 42.30° N | 13.43° E | 2 km (1 mi) | 4.0 (ML) |
15 Apr 2009 22:53:08.7 | 00:53:08.7 | 42.54° N | 13.28° E | 2 km (1 mi) | 4.0 (ML) |
23 Apr 2009 15:14:10.6 | 17:14:10.6 | 42.22° N | 13.44° E | 10 km (6 mi) | 4.0 (ML) |
23 Apr 2009 21:49:01.0 | 23:49:01.0 | 42.24° N | 13.48° E | 2 km (1 mi) | 4.3 (Mw) |
22 Jun 2009 20:58:40.3 | 22:58:40.3 | 42.44° N | 13.29° E | 2 km (1 mi) | 4.7 (Mw) |
3 Jul 2009 11:03:09.0 | 13:03:09.0 | 42.38° N | 13.32° E | 2 km (1 mi) | 4.1 (ML) |
I see that the table with the abbreviated form takes up several pixels more. That, of course, is a meaningless difference in an all-digital, adjustable-everything, electronic encyclopedia. The advantages as far as readability when readers are interested in a particular earthquake? Priceless.
When I was doing mechanical engineering at a fuel cell company and these young engineers would get lazy and let their CAD programs automatically dimension an entire print, I used to call the resulting output “data ralphs.” Any good encyclopedia, rather than take a USGS data-ralph and publish it raw, would properly spend a moment and clean up that which can be cleaned up to make it easier for readers to deal with. Greg L ( talk) 16:37, 24 September 2009 (UTC)
I agree that your method too is perfectly fine. You and I think alike. There is no reason in the world to not massage the dates to human-readable form; particularly where the first column of dates is the chronological index organizing the data.
Technical writing is about communicating clearly and easily, not about appealing to a few editors’ notion of what makes sense because this-n-that date format is “unambiguous since one doesn’t need to specify whether or not the date is given in the Gregorian calendar system”. Some things, like how modern dates always use the Gregorian calendar, are a given and no one but a few Wikipedia editors who are busy promoting their favorite all-numeric date format ever question such things. I prefer common sense technical-writing practices, myself. Greg L ( talk) 16:48, 24 September 2009 (UTC)
Analysing all the comments made in the past few weeks (including those now archived at
Wikipedia talk:Manual of Style (dates and numbers)/Archive 125, there appear to be broadly three main strands of opinion:
(A) In favour of YYYY-MM-DD in footnotes and tables.
Cavrdg, Darxus, Denimadept, LeadSongDog, Offliner, RockyMtnGuy,
TheFeds[See below.
TheFeds, wjemather.
Total: 7 editors.
(B) Prepared to see YYYY-MM-DD in some tables, but not in footnotes.
A. di M., Headbomb, HWV258, Ohconfucius, Rich Farmbrough, Septentrionalis, Sssoul, Woodstone.
Total: 8 editors.
(C) Opposed to YYYY-MM-DD anywhere.
Alarics, Dabomb87, Debresser, Greg L, gu1dry, Jc3s5h, Jimp, Pfainuk, Shakescene, Tony1, VMAsNYC.
Total: 11 editors.
So, adding (B) and (C) together, we have 19 editors who oppose the use of YYYY-MM-DD in footnotes, against 8 who are in favour of it. Does that constitute a consensus on that particular point? If so, can we move forward with that, and leave the other, more contentious issues to one side? --
Alarics (
talk)
19:07, 25 September 2009 (UTC)
It seems to me that many of those who oppose total deprecation of the YYYY-MM-DD make assertions that the form is unambiguous, whereas “9 November, 2009” is ambiguous (citing at times, that this is because it somehow doesn’t specify whether it is based on the modern Gregorian calender). Just because absurd arguments can be advanced, doesn’t mean they carry the same weight as common-sense ones.
Another argument is that is endlessly repeated is that YYYY-MM-DD mustn’t be deprecated because it works well in tables and footnotes. But, since “09 Nov 2009” and/or “9 Nov 2009” also work, that argument carries no weight either.
One simply must include an evaluation of the total weight of the logical shortcomings and strengths on both sides of the issue because some editors will endlessly make assertions that make no logical sense for no other reason that they like the way they do their edits and don’t want to change or have someone later change their work. Others (though they will seldom admit it) believe that their particular practice might gain traction with the world if it is used here. But, as was amply demonstrated with Wikipedia’s three-year-long trial with terminology like “kibibyte” and “mebibyte” (which to this day, my spell-checker still flags), stupid technical writing practices don’t become wise technical writing practices that the world starts adopting simply because they appear on Wikipedia.
The final straw that breaks the camel’s back here, IMO, is that some editors cite how Wikipedia is an *international* English-language encyclopedia. But then, so too is Encyclopedia Britannica. Frankly, I think it is wisest to follow the practices of E.B., which always writes out the name of the month and never uses all-numeric dates. Why? Well, E.B. is inhabited by professional copy editors who invariably posses advanced journalism degrees. I therefore place greater credence in the opinion of those editors on this subject than I do with some of the all-volunteer editors who inhabit Wikipedia. Greg L ( talk) 21:19, 25 September 2009 (UTC)
Earth calling LSD: This is en.Wikipedia. It is written and optimized for readers for whom English is their first language. As for those readers for whom English is their second language we’ve got Wikipedias in 271 other languages, all optimized for each language and/or country with their own numbering systems, alphabets, everything. In short: Being that this the English-language version of Wikipedia, we’ll be sticking to the manuals of styles suitable for English—thank you very much—and won’t be running off on some home-baked tangent that flouts common sense on the pretense that you can do a five-minute Google search and find an African tribe that keeps track of dates by counting the scars they carve into their bodies. So…
Just pardon me all over the place for treating en.Wikipedia as an “English-only enterprise.” I’m much obliged for your assistance in proving my point regarding how “one also looks at the consistency of the arguments on both sides and considers the logical ramifications of it all.” Greg L ( talk) 00:14, 26 September 2009 (UTC)
In response to Greg's points:
←outdent (and ignoring wjemather’ rant)
Oh, and quoting LeadSongDog again: Since Britannica keeps coming up as the example to follow, I'll note that they too use descending significance all-numeric dates on their Japanese and Korean websites. Have you not heard of Google “Language tools”? I have. Here’s the English-language translation of the Japanese version of Encyclopedia Britannica. Note that they spell out the months: August 11, 2009; May 14, 2009 ; and another instance of May 14, 2009. Are you trying to help your cause or hurt it? Anyway…
I think we can limit our discussion to Encyclopedia Britannica’s *English-language* practices, can’t we? And, more to the point, I’d like to see you or anyone else advance a plausible sounding argument as to why the English-language version of Wikipedia (which is read internationally) has a compelling need to depart from standard encyclopedic practices observed by World Book and Encyclopedia Britannica both of which can also be found in libraries and homes (*sound of blair trumpets*) “INTERNATIONALLY”. The same goes for the Associated Press manual of style, which is observed by some 99% of the English-language newspapers published throughout the international community. Greg L ( talk) 00:36, 26 September 2009 (UTC)
-- ___A. di M. 12:07, 26 September 2009 (UTC)
Perhaps the practice of “deprecating” the YYYY-MM-DD” form shouldn’t happen because there are editors here who will always think they know better than professionals and get panicked whenever threatened with the prospect of no longer being permitted to do something they “like-ta” do. Isn’t that what en.Wikipedia is for(?): to provide a venue where editors who no advanced training in journalism and technical writing try to advance reasons for not looking towards the manuals of style produced by the professionals because they’ve *got it all figured out* and know better than the pros?
Arguments from some of the above editors are predicated on the false premise that en.Wikipedia presents some sort of unique circumstance and they are applying their amazing powers of astute observation and unflagging logic to deal with the situation. While no-doubt good for their sense of self-esteem, their arguments are illogical and/or unfounded. Many of these absurd arguments are predicated on the earth-shaking realization that some of en.Wikipedia’s readership speaks English as a second language. All these arguments are 100%, utter and absolute nonsense and have no bearing on the discussion since all the top English-language newspapers, magazines, and print encyclopedias also have a vast readership for whom English is their second language. Does that surprise anyone here?
Arguments that some of these readers for whom English is their second language read the English-language version of Wikipedia because it is more comprehensive, and this somehow constitutes a reason for us to depart from standard English-language rules of technical writing style are similarly utter and complete nonsense. Why? For many of the world’s languages, their print encyclopedias also suck in comparison to things like en.Wikipedia and Encyclopedia Britannica (or, in many cases, don’t even exist. At least those who speak Esperanto have eo.Wikipedia).
So, while “deprecation” might be too strong, it would be nice if we didn’t end up completely turning our backs on Technical Writing 101 common sense and *promote* the practice of using three-letter abbreviations for months in tables—as shown in Son of, above. It’s clear to anyone with the common sense that God gave a goose that dates with months written out are easier to read and look better than a sea of numbers in a format that no one in real life uses outside of USGS “data‑ralphs” and attendance forms at Star Trek conventions. Does that much surprise anyone? Or is the electronic white-space provided below going to be used for someone to spout about how 2009-04-07 17:47:38.3 “reads real purdy” and ought to spread like wildfire across the land? Greg L ( talk) 16:03, 26 September 2009 (UTC)
Seriously; I insist that you answer that question about the percent sign before you shovel more of your metric ton of weapons-grade bullonium that is all founded on the false premiss that Wikipedia is somehow unique in its being looked to by non-native English speakers; It isn’t. Greg L ( talk) 19:29, 26 September 2009 (UTC)
Comment. When recommendation are truly absurd, people just ignore them. Once upon a time, MOSNUM said: "Very large numbers may be divided up by commas every three places (e.g.: 2,900,000), starting from the decimal separator in both directions [emphasis added]." That'd mean one should write the number of square metres in an acre as 4,046.856,422,4. Of course, I've never seen such a format, on Wikipedia or elsewhere. I think I have seen other example of obviously silly rules which were just ignored, though I can't recall any one right now. If people are not treating the suggestion to use YYYY-MM-DD in "long lists and tables" the same way as they were treating the suggestion to use commas after the point, that means that they consider it less absurd. -- ___A. di M. 10:03, 27 September 2009 (UTC)
<profound awe>
international standard</profound awe>
that had been washed in unicorn tears and anointed with holy oil from the technology gods. Never mind that the entire computer industry as well as the computer magazine industry as well as all encyclopedias didn’t adopt the IEC prefixes, Wikipedia was going to use terminology that was unfamiliar to readers because (“they’ll learn it easily enough,“ “it’s an *international standard,” “we are electronic and have links,” “it’s logical and everyone can figure out what it means,” etc.).Similarly, there appears to be an editor who was logging out to do I.P. edits on the ISO 8601 article to make it say that the standard was intended to apply to “internal, personal, hand-written notes (“Mom, I’ll be home by 2009-11-09T11:20 after the Star Trek convention lets out”). Such highly *motivated* editors can be exceedingly difficult to revert and the work of a single editor can spread like lung cancer across Wikipedia.
The common theme between the IEC prefix cabal and those who promote “2009-11-09T11:20” for use on Wikipedia is that they are perfectly willing to ignore the common-sense principles of clear technical writing and don’t care what practice is common in the real-world; they are *believers in the cause* and think our use of the practice here will lead to more general adoption in the real world. After three long years confusing readers and making Wikipedia’s computer-related articles look like they had been authored by 15-year-old fools, our experiment with the IEC prefixes proved that this mindset was nothing more than wishful thinking of those who don’t understand the fundamental principles of how to write clear, encyclopedic prose. So…
Though a practice may be stupid and you think few will follow stupid advise on MOSNUM (you might well be right), having any unwise practice sanctified on MOSNUM is just that: unwise. Why? Because, though not too many may follow it, all it takes is a handful of editors to make a lot of crappy looking stuff on Wikipedia; all they have to do is point to MOSNUM to say it is officially sanctified and that the practice has been blessed by the ISO gods. Greg L ( talk) 16:38, 27 September 2009 (UTC)
Analysing all the comments made in the past few weeks (including those now archived at Wikipedia talk:Manual of Style (dates and numbers)/Archive 125, there appear to be broadly three main strands of opinion (this is necessarily a crude measure, but it gives a rough idea of the weight of views):
(A) In favour of YYYY-MM-DD in footnotes and tables.
Cavrdg, Darxus, Denimadept, LeadSongDog, Offliner, RockyMtnGuy, Vegaswikian, wjemather, Woodstone.
Total: 8 9 editors.
(B) Prepared to see YYYY-MM-DD in some tables, but not in footnotes.
A. di M., Headbomb, HWV258, Ohconfucius, Rich Farmbrough, Septentrionalis, Sssoul[see below], Woodstone[see above].
Total: 8 7 6 editors.
(C) Opposed to YYYY-MM-DD anywhere.
Alarics, Dabomb87, Debresser, Greg L, gu1dry, Jc3s5h, Jimp, Pfainuk, Redrose64, Shakescene, Tony1, VMAsNYC.
Total: 11 12 editors.
Clearly, there is no consensus for deprecating YYYY-MM-DD altogether. But, adding (B) and (C) together, we have 19 18 17 18 editors who oppose the use of YYYY-MM-DD in footnotes, against 8 9 who are in favour of it. Does that constitute a consensus on that particular point? If so, can we move forward with that, and leave the other, more contentious issues to one side? I would like to get agreement on just this narrow question -- YYYY-MM-DD in footnotes -- without going over all the arguments again. I'd be grateful if any further discussion beyond this point is about the practicalities of taking the matter forward, not on the substantive issue. If people really want to carry on going over the arguments again on the substantive issue, perhaps they could do so above this subsection. --
Alarics (
talk)
19:07, 25 September 2009 (UTC)
A real-world sample. I did not participate in the above discussion, but (for other reasons, having to do with HTML conformance of citations) I happen to have been reviewing the ten articles most recently nominated for Featured Article status. These are articles that reflect recent activity in article improvement, and by and large they are in pretty good shape (though obviously not featured yet). Of these ten articles, six use YYYY-MM-DD dates in footnotes, and four do not. The six that use YYYY-MM-DD are Well Dunn, Trump International Hotel and Tower (Chicago), Sydney Riot of 1879, Anarchy Online, Ethan Hawke, and John Tavares (ice hockey). The four that do not use YYYY-MM-DD, along with the styles they use in parentheses, are Neverwinter Nights 2: Mysteries of Westgate ("September 24, 2009"), Tiananmen Square self-immolation incident ("4 October 2007"), Bramall Hall ("12 September 2009"), and 1982 British Army Gazelle friendly fire incident ("19 November 2008"). Admittedly this is a small sample, but it was chosen sort-of-at-random from pretty-good recent articles. In this sample of recent articles, YYYY-MM-DD style is used in footnotes by more than half the articles, and it's used by twice as many articles as the next most-popular date style. I therefore suggest that the real-world consensus (as opposed to the consensus on this page) is strongly in favor of allowing YYYY-MM-DD in footnotes, though there is obviously not a consensus in requiring YYYY-MM-DD. Eubulides ( talk) 08:54, 26 September 2009 (UTC)
[PLEASE don't add further comments here on the substantive issue; they go in the previous subsection. I meant THIS subsection to be about the procedural issue of what do we do now.] -- Alarics ( talk) 19:32, 26 September 2009 (UTC)
I think that based on this discussion we may remove any advise to use the YYYY-MM-DD or ISO 8601 (or whatever else looks like it) whereever we find it. With exeption of what it says here on the project page "YYYY-MM-DD style dates (1976-05-31) are uncommon in English prose, and should not be used within sentences. However, they may be useful in long lists and tables for conciseness." That would be a good start and seems uncontroversial for all points of view. Debresser ( talk) 21:27, 26 September 2009 (UTC)
Note: the Google counts above double counts 12/31/08 and 31/12/08 . Note also that Google is too smart. On the first page of 01/01/09 we find "Coney Island Polar Bear Plunge 1-1-09 Philip Kiracofe Video". Rich Farmbrough, 11:39, 27 September 2009 (UTC).
Responding to Debresser's point above: No, the "However, they may be useful in long lists and tables for conciseness." bit is not uncontroversial. A number of us are arguing that YYYY-MM-DD are not useful on WP at all and that the difference in conciseness between them & three-letter dates is insignificant. JIMp talk· cont 15:53, 27 September 2009 (UTC)
Fathers aside, YYYY-MM-DD and YYYY-MMM-DD are both widely used in Canada, particularly on government documents, both geeky and non-geeky. Canada also uses DMY & MDY (each in at least 3 forms), and all checks must now indicate which style is being used-- JimWae ( talk) 20:19, 27 September 2009 (UTC)
{{
dts}}
{{
dts|2009|September|28}}
, {{
dts|2009-09-28}}
, {{
dts|September 28, 2009}}
and {{
dts|28 September 2009}}
are all valid and give identical behaviour when sorted. Therefore, should it be necessary for |accessdate=
to be parsable (and I've yet to see a reason for requiring that), the same code as used by {{
dts}}
to derive <span style="display:none">2009-09-28</span>
could be utilised. Or there's {{
Start date}}
. The point is, that forcing the |accessdate=
to appear in different format to all the other dates is jarring. --
Redrose64 (
talk)
10:51, 28 September 2009 (UTC)
I think it infinitely clear that the professional editors in the editorial rooms of fine encyclopedias, when they are pondering how best to communicate dates to readers, don’t ask “well, what computer-readable, all-numeric format is used on Canadian bank checks?” So… Have we developed a consensus to use machine-readable date formats only where machines (Wikipedia’s servers) need to understand dates, and to ensure dates are rendered in human-readable form for the humans? You know, where…
None of this is technical-writing rocket science. Why is so much discussion transpiring on an issue that is so easily solved? Greg L ( talk) 19:46, 28 September 2009 (UTC)
, Sep 9, 9:26:03.2
. 9 Sep 2009
___A. di M.
11:51, 1 October 2009 (UTC)There is obviously no consensus to ban yyyy-mm-dd formats in citations. Also, many of the above comments seem to be based on incorrect assumptions. Please see #Real world often uses yyyy-mm-dd in citations below. Eubulides ( talk) 09:21, 29 September 2009 (UTC)
Several of the comments in the above thread seem to be based on the incorrect assumption that yyyy-mm-dd dates are a Wikipedia eccentricity, and that such dates do not appear in style guides and by and large do not appear in real-world scholarly sources. This assumption is incorrect.
URL: http://www.healthypeople.gov/Document/tableofcontents.htm#Volume2 [accessed 2008-10-24]
{{
cite journal}}
: CS1 maint: multiple names: authors list (
link)http://www.baltic21. org/ reports/indicators/fo01a.htm (Accessed 2009 04 26)
{{
cite journal}}
: CS1 maint: numeric names: authors list (
link)(http://ecdc.europa.eu/en/Health_Topics/ebola_marburg_fevers/Article_20080805.aspx accessed 2009-01-24)
{{
cite journal}}
: CS1 maint: multiple names: authors list (
link)http://www.nr.no/pages/dart/project_ flyer_mariage, accessed 2009-02-25
{{
cite journal}}
: CS1 maint: multiple names: authors list (
link)International Telecommunications Union, http://www.itu.int/ITUD/ict/newslog/South+Africa+Mobile+Penetration+Edges+Towards+100.aspx (accessed 2009-01-12)
{{
cite book}}
: |journal=
ignored (
help)http://bt.pa.msu.edu/index cosy.htm, accessed 2008-09-13
Eubulides ( talk) 09:21, 29 September 2009 (UTC)
Eubulides, it's nothing to do with WP:IDONTLIKEIT. Several people have said they find YYYY-MM-DD ambiguous. If the thing is an obstacle to understanding (because some people find it ambiguous), then we shouldn't be using it. It's as simple as that. -- Alarics ( talk) 21:19, 29 September 2009 (UTC)
Excuse me. I couldn’t participate in this all day until just now. I spent the day trying to find my copy of ISO 8601. I just couldn’t find it. So I went next door. My neighbor manages a K-mart store and you’d think he’d be sophisticated enough to have a copy. But he didn’t. Not even when he climbed his sideways-rolling ladder in his wood-paneled library to access the top shelves. It just couldn’t be found. Then I called my brother, who taught journalism at a university. Funny… not only did he not have a copy, he didn’t even know anything about ISO 8601, ISO 690 or any of these other international standards that editors here are proudly flaunting with their chests puffed out with immense pride. It appears we’ve got a few editors here debating about proper technical writing practices, but their arguments are predicated upon technical nuances that exceedingly few people have the faintest clue about.
Now, I see editors making the argument that YYYY-MM-DD intrinsically references only Gregorian dates (at least to the extent that any exhibition of YYY-MM-DD can be presumed to be necessarily conforming to the ISO 8601 standard). My question is this: So what? Writing out a date in an all-numeric format of any form doesn’t make anything clearer with regard to the distinction between Gregorian and Julian dates for 99.99% of our readership. In fact, over 99% of our readership doesn’t even know there is a difference between Julian and Gregorian calendars.
If there is a Julian date to some event or document that needs to be cited, just write out the month and place a parenthetical “Julian date” at the end of it. You know… we would actually communicate <audience gasp>
clearly</audience gasp>
and desist with trying to make a rational sounding argument that would require us to pretend that the vast majority of our readership is some sort of
brainiac
George Jetson with a Ph.D. (BTW, I was, of course, joking about going next door to my neighbor and to my brother. But I do invite any of the above editors who are spouting about these standards to please tell us just who amongst their friends, families, and associates has a copy of ISO 8601 and/or ISO 690 and is familiar with their scope and what connotations these *standards* have with regard to Julian and Gregorian dates. All the above debate just proves to me that some editors here are more interested in showing how smart they are about damned standards but have mighty little interest in writing clearly. That’s my honest take; so shoot me.)
Greg L (
talk)
04:37, 30 September 2009 (UTC)