Wikipedia talk:Manual of Style/Dates and numbers

Currencies

There are two independently maintained sections regarding Currencies - Wikipedia:Manual of Style#Currencies and Wikipedia:Manual of Style (dates and numbers)#Currencies. The former should be merged into the latter, noting there are some content differences between these two Currencies MoS sections.

{{editprotected}} For this proposal, a {{mergesection}} notice should be added to the WP:MOSNUM#Currencies section. This editprotected request is not to perform the actual merge yet to allow for discussion first, especially to confirm which statements should remain in the merged section. Dl2000 (talk) 00:36, 11 January 2009 (UTC)

 Done Ruslik (talk) 10:06, 11 January 2009 (UTC)

Version comparison

A comparison between the versions would be useful for reference during the discussion:

Serial	A. WP:MOS#Currencies	B. WP:MOSNUM#Currencies	Remarks
1	See also: Wikipedia:WikiProject Numismatics/Style § Article titles	:See also: WikiProject Numismatics: Article titles	Identical result; internal template formatting differences.
Which one to use
2	In country-specific articles, such as Economy of Australia, use the currency of the country.	In country-specific articles, such as Economy of Australia, use the currency of the country.	Identical
3	In non-country-specific articles such as Wealth, use US dollars (US$123).	In non-country-specific articles such as Wealth, use US dollars (US$123), the dominant reserve currency of the world. Some editors also like to provide euro and/or pound sterling equivalents, formatted as described in the next section.
4	(none)	If there is no common English abbreviation or symbol, use the ISO 4217 standard.	Moved from Formatting subsection in WP:MOS to Which currency... subsection in WP:MOSNUM (see serial #8)
Formatting
5	Fully identify a currency on its first appearance (AU$52); subsequent occurrences are normally given without the country identification (just $88), unless this would be unclear. The exception to this is in articles related to the US and the UK, in which the first occurrence may also be shortened ($34 and £22, respectively), unless this would be unclear.	Fully identify a currency on its first appearance (AU$52); subsequent occurrences are normally given without the country identification or currency article link (just $88), unless this would be unclear. The exception to this is in articles related entirely to US- or UK-related topics, in which the first occurrence may also be shortened and not linked ($34 and £22, respectively), unless this would be unclear. Avoid over-identifying currencies that cannot be ambiguous; e.g., do not place EU or a similar prefix before the € sign.
6	Do not place a currency symbol after the value (123$, 123£, 123€), unless the symbol is normally written as such. Do not write $US123 or $123 (US).	Do not place a currency symbol after the figure (123$, 123€, 123£), unless the symbol is normally written thus. Likewise, do not write $US123 or $123 (US).
7	Currency abbreviations that come before the number are unspaced if they end in a symbol (£123, €123), and spaced if they end in an alphabetical character (R 75). Do not place EU or a similar prefix before the € sign.	Currency abbreviations that come before the number are unspaced if they consist of or end in a symbol (£123, €123), and spaced if alphabetic (R 75).
8	If there is no common English abbreviation or symbol, use the ISO 4217 standard.	(none)	Moved up to Formatting subsection in MOSNUM. See serial #4.
9	Ranges are preferably formatted with one rather than two currency signifiers ($250–300, not $250–$300).	Ranges are preferably formatted with one rather than two currency identifiers ($250–300, not $250–$300).	Almost identical wording except for formatting and last word ("signifiers" vs. "identifiers").
10	Conversions of less familiar currencies may be provided in terms of more familiar currencies, such as the euro or the US dollar. Conversions should be in parentheses after the original currency, with the year given as a rough point of reference; for example, 1,000 Swiss francs (US$763 in 2005), rounding to the nearest whole unit.	Conversions of less familiar currencies may be provided in terms of more familiar currencies, such as the US dollar, euro or pound sterling. Conversions should be in parentheses after the original currency, rounding to the nearest whole unit, with at least the year given as a rough point of conversion rate reference; for example, 1,000 Swiss francs (US$763 in 2005).
11	(none)	For obsolete currencies, provide if possible an equivalent, formatted as a conversion, in the modern replacement currency (e.g. decimal pounds for historical pre-decimal pounds-and-shillings figures), or at least a US-dollar equivalent as a default in cases where there is no modern equivalent.
12	Consider linking the first occurrence of a symbol for less well-known currencies (₮146); it is generally unnecessary to link the symbols of well-known currencies.	When possible, always link the first occurrence of a symbol for lesser-known currencies (₮146); some editors consider it unnecessary to link the symbols of well-known currencies, but doing so can often be helpful to readers, as many countries use "dollars" or "pounds" as their base currency, and not all readers are familiar with the euro.
13	The names of currencies, currency subdivisions, coins and banknotes should not be capitalised except where normal capitalisation rules require this (for example, at the start of a sentence).	(none)
14	(none)	The pound sterling is represented by the £ symbol, with one horizontal bar. The double-barred ₤ symbol is ambiguous, as it has been used for Italian lire and other currencies as well as that of the British. For non-British currencies that use pounds or a pound symbol (e.g. the Irish pound, IR£) use the symbol conventionally preferred for that currency.

There seem to be no major contradictions, mainly some wording and formatting differences. Ideally, the priority should be to merge what we have first, then do any debate on these statements later. The Serial number column can be used as a shorthand to refer to each statement. Dl2000 (talk) 03:52, 12 January 2009 (UTC)

Analysis and recommendation from the two versions

Having seen no comments so far, it's time for a proposed merged wording. Some comments on the items, noting that column A represents existing WP:MOS wording, column B for WP:MOSNUM. In the following, the convention "B6" means column B, serial row 6.

• Serial 1: Coding in column A is more concise, so suggest using A1.
• Serial 2: Identical, no evident issues, merge as is.
• Serial 3: Column B text builds on column A without wording contradiction. A has the "{{xt}}" green formatting for US$123. Therefore suggest B3, with US$123 example highlighted as done in A3.
• Serial 4: B4 is mutually exclusive with A8 - ISO 4217 is more a type of formatting than choice of currency, therefore leave this out of the Which one to use section. i.e. go with the empty "A4".
• Serial 5: B5 generally builds on A5, no contradictions seen. However, some extra xt formatting is seen in A5. Also note the last words of B5 about avoiding EU with the € sign are similar to wording in A7. Therefore B5, but xt-format all currency value examples.
• Serial 6: A6 seems the better version to move forward, with xt-formatting and more straightforward wording.
• Serial 7: Since B5 is recommended, this suggests B7 is the better wording, although should do xt-formatting as done in A7.
• Serial 8: Use A8 for reasons indicated in Serial 4.
• Serial 9: Go with "signifiers" for now - therefore use A9, with its xt-formatting. The wording could be revisited after the merge.
• Serial 10: B10 expands on A10, includes the rounding of conversion. Therefore, B10 but with xt-formatted values.
• Serial 11: B11 guideline not found anywhere in A, so use that.
• Serial 12: B12 generally expands on A12, with more explanatory guidance. Go with B12, with xt-formatting.
• Serial 13: A13 does not appear anywhere in B, therefore use A13.
• Serial 14: B14 does not appear anywhere in A, therefore B14.

Proposed wording of merge

Based on the above, the merged wording becomes:

See also: Wikipedia:WikiProject Numismatics/Style § Article titles

Which one to use

• In country-specific articles, such as Economy of Australia, use the currency of the country.
• In non-country-specific articles such as Wealth, use US dollars (US$123), the dominant reserve currency of the world. Some editors also like to provide euro and/or pound sterling equivalents, formatted as described in the next section.

Formatting

• Fully identify a currency on its first appearance (AU$52); subsequent occurrences are normally given without the country identification or currency article link (just $88), unless this would be unclear. The exception to this is in articles related entirely to US- or UK-related topics, in which the first occurrence may also be shortened and not linked ($34 and £22, respectively), unless this would be unclear. Avoid over-identifying currencies that cannot be ambiguous; e.g., do not place EU or a similar prefix before the € sign.
• Do not place a currency symbol after the value (123$, 123£, 123€), unless the symbol is normally written as such. Do not write $US123 or $123 (US).
• Currency abbreviations that come before the number are unspaced if they consist of or end in a symbol (£123, €123), and spaced if alphabetic (R 75).
• If there is no common English abbreviation or symbol, use the ISO 4217 standard.
• Ranges are preferably formatted with one rather than two currency signifiers ($250–300, not $250–$300).
• Conversions of less familiar currencies may be provided in terms of more familiar currencies, such as the US dollar, euro or pound sterling. Conversions should be in parentheses after the original currency, rounding to the nearest whole unit, with at least the year given as a rough point of conversion rate reference; for example, 1,000 Swiss francs (US$763 in 2005).
• For obsolete currencies, provide if possible an equivalent, formatted as a conversion, in the modern replacement currency (e.g. decimal pounds for historical pre-decimal pounds-and-shillings figures), or at least a US-dollar equivalent as a default in cases where there is no modern equivalent.
• When possible, always link the first occurrence of a symbol for lesser-known currencies (₮146); some editors consider it unnecessary to link the symbols of well-known currencies, but doing so can often be helpful to readers, as many countries use "dollars" or "pounds" as their base currency, and not all readers are familiar with the euro.
• The names of currencies, currency subdivisions, coins and banknotes should not be capitalised except where normal capitalisation rules require this (for example, at the start of a sentence).
• The pound sterling is represented by the £ symbol, with one horizontal bar. The double-barred ₤ symbol is ambiguous, as it has been used for Italian lire and other currencies as well as that of the British. For non-British currencies that use pounds or a pound symbol (e.g. the Irish pound, IR£) use the symbol conventionally preferred for that currency.

Comments/poll on the proposed wording of merge

Support/Oppose/further Comment? Dl2000 (talk) 00:20, 17 January 2009 (UTC)

support - Looks good to me. It's clear a merge is needed, and the proposal seems to have preserved all the semantics. Nice work. -Kieran (talk) 04:12, 20 January 2009 (UTC)

It's more than a week and there has been support and no objections for the proposed merge text. It is therefore proposed that the merge occur on or soon after 25 January 2009 00:01 (UTC) unless any objections or concerns are raised by then. Dl2000 (talk) 00:09, 24 January 2009 (UTC)

Conclusion

{{editprotected}} Based on the consensus of the discussion above, it is requested that the merge proceed, namely replacing the existing WP:MOSNUM#Currencies with the Proposed wording of merge text as colour-boxed above. Once an administrator approves and proceeds with this, the redundant material in WP:MOS#Currencies should be deleted. Dl2000 (talk) 03:46, 25 January 2009 (UTC)

 Done--Aervanath (talk) 10:23, 25 January 2009 (UTC)

Exposing the distortions in the "detailed" RfCs on dates

One or two editors seem to be using the responses to a set of RfCs to support claims that various kinds of consensus exist against the community's moves to "smart linking" and the removal of date-autoformatting. When light is shone on these RfCs, I believe claims that they deliver any useful information that amounts to consensus is highly questionable. As advertisers and those who write surveys and questionnaires know well—sometimes to their advantage—the information they present to participants has significant potential to contaminate the data.

RfC1

The first RfC is a good example of this; I regret that this much space is required to get to the nub of why credibility is lacking.

Contamination. The first RfC explicitly sought to reveal the following:

Do you support or oppose retaining the following statement? Dates should not be linked purely for the purpose of autoformatting (even though in the past this was considered desirable).

However, the otherwise NPOV background statement ended with a prominent "Note" claiming that MediWiki has created a new, improved autoformatting system.

[Background statement:] Note: Mediawiki's software developers have created a patch to correct problems with the current method of date autoformatting. It has not been established when or if the patch will be implemented. (For more information on this, please see the discussion on Bugzilla.)

Independent technical opinion. In the opinion of a skilled and experienced programmer (s/he has taken Cole to task about this claim already—and Cole probably knows whom I'm referring to): "That is disingenuous. After three years [of discussion at Bugzilla], I would say that not only isn’t there a patch ready to go, but there is no consensus over what should actually be in that patch.... you could poke the space shuttle through [the claim].... Trust me, I’ve been in the computer industry long enough to see that the recent debate on the page at the link you sent indicates there is no specification for development (let alone implementation). That doesn’t mean a developer hasn't created “something”, but in my experience there is no way known that that “something” is going into production WP any time soon."

Confusion reinforced. The "Note" was followed by no fewer than four rejoinders and a statement during the RfC, mostly in prominent positions towards the top. Under the pretext of stimulating discussion, this appears to have had the unfortunate and predictable effect of significantly blurring the stated issue in the minds of many participants.

[Rejoinder:] You understand that the bugzilla patch would remove the links and provide formatting to all users (logged in or not), yes? Also you need not say "support" as your comment is in a section of the same title. =) —Locke Cole

[Rejoinder:] Removing date links invalidates the work [of developers] done so far and is strictly punitive in nature."—Locke Cole

[Rejoinder:] ... a developer has already created a patch that can address the concerns raised against autoformatting. The developer has indicated that retaining the existing links simplifies the process, as it is more complicated to identify unlinked dates. Furthermore, the new patch - if enabled - would not require a modification to the existing markup for most dates; instead, the autoformatting would remain and be improved, while the links (the most contentious issue) would simply vanish. (Ckatz)

[Rejoinder:] Or maybe Ephebi read the RFC entirely and realizes there's a patch that addresses this concern. —Locke Cole

[Lead to the "Oppose" section:] Note also that the current formatting system (using wikilinks around date fragments) is the method being addressed by the MediaWiki patch at Bugzilla noted in the background above. Removing these links would undermine and harm the work being done by developers to fix these issues. —Locke Cole

A second element of confusion. In addition, the language in the lead inadvertently invited confusion between date-autoformatting and the linking of chronological items to actual pages; this is a great pity.

Conclusion: As as result, a sizeable proportion of the some 48 users who entered "Oppose" showed evidence of either (i) influence by the claim that "son of autoformatting" is at hand, almost ready to go ... or (ii) confusion between two quite different functions. By my reckoning,

• only 25 entered a straight "Oppose" without such contaminating influence or confusion;
• 17 showed that they were influenced by the spectre of some new "son of autoformatting" invention;
• seven confused date-autoformatting with linking to chronological pages;
• one was a confused Oppose.
• one, "Edmund Patrick" appears to have entered his Support in the wrong section.

The confusion is also seen in the seven participants who explicitly made "Neutral" entries.

To be generous—since a few of those in the confused categories probably would have opposed in a pure vote—the 48 claimed Opposes are more likely to boil down to about 30–32 (10–11%) of more than 300 participants, when the contamination of the leads and the rejoinders is taken into account. There is no clear way of determining what the opinion of the others would have been in the absence of confusion. As Anomie said in the discussion section:

"there seem to be at least 6 that assume anons would still see unformatted dates, at least 5 who oppose because it would be a waste of developer time (it's up to the developers, particularly the unpaid volunteers, what they want to spend their time on), at least 7 who assume it would apply to every date rather than just dates marked up with whatever new syntax, at least 2 who seem to think dates would still be linked, and too many to count who think the only reason for date formatting is MDY versus DMY (only 1 comment considered the template issue).

This goes much of the way towards explaining why this RfC yielded a more favorable result for the opposers of deprecation than the other RfC, which asked a straight, binary question without exposing participants to contaminating/confusing text before they made their entries.

The lesson is that RfCs, like all surveys and questionnaires, need to be framed very carefully if their results are to be considered reliable. Unfortunately, the framing of this first RfC set the scene for serious issues that damage the credibility of the subsequent RfCs in this set. I will deal with these in a day or two. Tony (talk) 15:38, 13 January 2009 (UTC)

That is an excellent posting, Tony. I did see that the RFC claimed "Note: Mediawiki's software developers have created a patch..." and the quotes show that some people voted under the influence of that note. Lightmouse (talk) 15:49, 13 January 2009 (UTC)

Interesting indeed. I had been blinded by all the hubbub. Had I looked more closely, perhaps I would have objected to the attempt to surround the questions by 'loading' it with information of questionable validity (ie vapourware). I also took the imminent availability of the patch at face value. Looking at it again like Tony has done, I can see the questions were still the same flawed ones worked on by Masem, but they were given a gift-wrapp in shiny, glossy paper with ribbons and bows by Locke. Ohconfucius (talk) 06:42, 14 January 2009 (UTC)

Eh, I've seen patches applied to MediaWiki in a matter of hours, so this is provably false. Since the rest of your claims rely on that, I won't respond to the rest. —Locke Cole • t • c 15:16, 14 January 2009 (UTC)

There's no evidence of specs or a roadmap. Forgive my caution; it comes from experience. The matter is one of multilayered complexity. Tony (talk) 16:01, 14 January 2009 (UTC)

On at least two occasions I've tried to discuss what type of syntax editors here at MOSNUM would prefer, what concerns they might have with a new system, and in both situations discussion died without reaching a consensus (and in some cases you helpfully responded it was a "waste of time" to discuss it). —Locke Cole • t • c 16:05, 14 January 2009 (UTC)

I'm sorry, but it's not just me: many people here are well aware of what technical, administrative and logistic problems you would be up against. I believe that is why discussion died, not because I said at some stage that it's a waste of time. It is because of the larger, messy issues that you can't achieve worthwhile discussion on specs and a roadmap. After three years at Bugzilla, going around and around in circles, I do not believe it will ever happen. Tony (talk) 16:24, 14 January 2009 (UTC)

I've already explained why it hasn't happened: we haven't come up with a description of what we want here on the wiki for the devs to act on. And I already went over part of the problem (namely your behavior in those discussions, the "waste of time" comments, etc). I'm all for having a discussion on it again if you feel you can discuss it calmly. —Locke Cole • t • c 22:07, 14 January 2009 (UTC)

Interesting to contrast "we haven't come up with a description of what we want here on the wiki for the devs to act on" and "a developer has already created a patch that can address the concerns raised against autoformatting". You are right though—we should try to remain "calm".  HWV 258  22:23, 14 January 2009 (UTC)

Nothing "interesting" about that at all: regulars here seemed to shoot down that patch when it was discussed because they didn't like the way it worked. Again, the issue isn't the devs, the issue is actually deciding what we want. —Locke Cole • t • c 22:31, 14 January 2009 (UTC)

You have "contrasted" exactly one half of my quotes. The "interest" sparks from trying to reconcile both quotes (in the light of the section heading under which they were posted: "RfC1"—specifically "contamination").  HWV 258  22:40, 14 January 2009 (UTC)

I did not add that passage, you'd have to ask the person who did. For my part I think that patch sounds fine, but again, those here turned it down. —Locke Cole • t • c 02:07, 15 January 2009 (UTC)

For a software implementation to be successful, programmers must work to a rigidly-defined specification. Locke, please demonstrate to the community the specifications for the "patch" that could be "applied to MediaWiki in a matter of hours".  HWV 258  21:37, 14 January 2009 (UTC)

When ParserFunctions were first authored by Tim Starling it only took a matter of hours, maybe a day tops, for it to get pushed out to the Wikimedia servers IIRC. ParserFunctions are, comparatively, far more complicated than any date formatting code we're likely going to ask to have added... —Locke Cole • t • c 22:05, 14 January 2009 (UTC)

So that would be a "no" then to producing specifications? Software development and release (even involving complexity) can happen very quickly, but only based on clear and detailed specifications. Please take time considering the issues here—no one is denigrating WP's programmers as being skilled developers and implementers, however no programmer can produce effective code in the absence of specification.  HWV 258  22:14, 14 January 2009 (UTC)

PF wasn't created from any community issued specification, that was Tim going off on his own I believe (but being aware of the demands needed to address the communities desires). And I have no idea exactly how long he worked on it prior to it being submitted, but I don't believe it was long. I misunderstood your question as being how long from the time finished code was completed until it was pushed out to us for use. —Locke Cole • t • c 22:21, 14 January 2009 (UTC)

Thank you HWV. I love the way Cole is constructing much of his argument around "my behaviour"; this is being done both here and at the ArbCom hearing, which strangely allows users to freely post trumped-up and irrelevant accusations, and tittle-tattle, without space limit. If Arbitrators do not see through this smoke screen, we will be witnessing the destruction of the peak judicial process. When you look at the huge tranches of text devoted to smearing me (dear me, I look like a dragon from the headings and amount of text under them), you find that almost all of it is based on diffs to the normal cut-and-thrust of the discourse about date links, yet is loudly drummed out as incivility.

I can't bring myself to play that game. Cole has still not answered HWV's queries. I'm sorry, but we're not stupid around here. Tony (talk) 01:33, 15 January 2009 (UTC)

Don't forget the "258"—people are always forgetting the 258 (there is another user named "HWV").  HWV258  02:00, 15 January 2009 (UTC)

HWV258: "For a software implementation to be successful, programmers must work to a rigidly-defined specification." Er... no. I've spent the last decade largely working agile commercially, and I can tell you that's one of the least accurate statements I've heard in a long time. To then try and claim that Locke has to produce some kind of "specification" to justify himself is absolutely ludicrous. And yes, I can confirm what he said about Tim's implementation of ParserFunctions. I'm guessing that you don't actually have any experience of working on FLOSS to make such a statement. -- Earle Martin [^t/_c] 11:51, 18 January 2009 (UTC)

FLOSS doesn't suggest that software development will work better without a well-defined specification. Without a specification, how does the programmer know what to develop? Think about why the (reopened) debate on exactly what should be in the "patch" has stalled after three years. If it was easy to know what to program, the whole thing would have been concluded long before the first date-delinking took place. On WP it is even more important that (at least) functional requirements are produced as there is a very large community that must adopt the results of the development.

In terms of the quoted statements, I wanted to include in the debate the clear discrepancy between "we haven't come up with a description of what we want here on the wiki for the devs to act on" and "a developer has already created a patch that can address the concerns raised against autoformatting". Please note that the first statement clearly indicates the desire to produce a specification before development (and quite right too!). Nothing "ludicrous" at all ("absolutely" or otherwise).  HWV258  21:57, 18 January 2009 (UTC)

RfC2

As promised, I have examined the second of the set of RfCs at issue, with disappointing conclusions in a technical sense.

The danger that language will funnel users into one option. I believe the language of the RfC has the effect of manipulating users into declaring a "Support". Let's look closely at the opening.

First, users are warmed up for a "Support" declaration by two key positive words: "desirable" in the title ("Is some form of date autoformatting desirable?") and a few seconds later—if they'd forgotten this word—combined with the use of "encouraged" in the official question (my italics):

Do you agree with the following statement: The ability for the Mediawiki to convert dates into a form either appropriate for the page, or to user-defined preferences, is desirable, and the MediaWiki developers should be encouraged to find a solution that works without the problems of the current date autoformatting system.

The subsequent "Background" is a minefield:

Background: ... Currently the MediaWiki developers are discussing methods of improving autoformatting to address these points, including possibly correcting the problems in the current system. To make sure their time is being used effectively, it is necessary to understand if a date autoformatting approach that works correctly is desired on Wikipedia. If not, the developers should be informed of this so they may focus on other aspects of the software that need improving.

Here, the claims in the first RfC above are extended in the assumption that WikiMedia is investing time in the development of a date-autoformatting system that works. The now-moribund three-year-old debate at Bugzilla is dragged out and dressed up as an ongoing, dynamic process. The same unevidenced claim is made that the MediaWiki developers (read User:UC_Bill (aka Bill Clarke)?) are close to delivering a spanking new generation of autoformatting. Just what "correcting" means is not explained, and there is no indication of the significant technical, logistic and administrative issues that would lie in the path of this option—a roadmap and specifications are nowhere to be found. Please see the independent programmer's opinion above on this claim.

Caught between two choices. Users were given a stark choice. By entering a "Support", they were somehow ensuring that developer time will be used effectively ("To make sure [MediaWiki developers'] time is being used effectively")—it seemed like the easy, positive thing to do. By contrast, declaring Oppose was framed as turning down the opportunity to have developers deliver a date-autoformatting approach that works—and worse, as interrupting professional work towards this goal, something that many folk would think twice about doing ("If not, the developers should be informed of this so they may focus on other aspects of the software that need improving"). I'd feel a heel myself at spoiling their ongoing project.

Support responses. A look through them clearly shows that many supporters were influenced by the blue-sky prospect of a new generation of technology, just as in the first RfC; again, many showed a confusion of the issues and technicalities, as would be expected when non-specialists are faced with a complex feature.

Conclusion. Again, writing an RfC is an exercise in trying to avoid bias and contamination, a difficult task indeed; the data are only as good as the NPOV of the stimulus. I submit that the language and choices presented to users rendered the result significantly unreliable, and explains why it generated much higher "Support" numbers than the first RfC above or the more straightforward RfC. Regrettably, this RfC does not deliver useful data.

Tony (talk) 16:24, 14 January 2009 (UTC)

You had no problems !voting that no form of autoformatting is desirable; neither did I. This is a red herring; there is no hope of the sort of consensus against it we would like, for separate reasons, because too many editors actually like it. In any case, this does not matter unless a developer is actually moved to provide a new style of autoformatting, and you should know better than I do how likely a developer is to do anything on this issue. Septentrionalis PMAnderson 19:35, 14 January 2009 (UTC)

• No, Cole and a hard-core unrelenting band of four or five others like it. See Colonies Chris's stats as to the vanishingly small number of complaints he has had after thousands upon thousands of DA removals. Don't be swayed by the loud noise of the few. (Another diff here for my "incivility", Cole?). Tony (talk) 01:38, 15 January 2009 (UTC)
• Wrong again, Anderson. You are not qualified to say all those who voted "had no problems". The statement certainly had an influence, although we will never know to what degree, unless we questioned the respondents all over again. Now that you have openly said so, I will happily share with you what I actually felt: of course, instinctively and emotionally, I would feel very guilty about turning down "the hard work of those poor guys and gals and for no pay so that we could all have some pretty autoformatted dates, and it's nearly ready." That's how it was put. It's just like you arrive home one evening to find that your mother/girlfriend/ significant other had prepared a scrumptious meal - how inclined would you feel to suddenly announce to her/him that you don't like paté de foie gras and pressed duck. I can tell you I was nearly swayed. What made the difference for me is logical reasoning which took place. Looking at the bugzilla thread, I figured it was no where near ready to fly. It was only then, I felt I owed nothing to the little elves, who had not in fact started working all that hard - in fact, they hadn't quite worked out what needed doing: no vision, no mission, no strategy (roadmap). Just talk. Ohconfucius (talk) 02:14, 15 January 2009 (UTC)

Not to derail this, but...

I don't think this exercise is necessary the best of use of time (though WP is volunteering you're free to do so), for a couple reasons:

• First, after creating the core structure, I did open the pre-RFC to discussion and improvements from editors here. I know you looked at it, along with others. I realize some of the language that is in there now was after I last edited it (the part in the first question about the promised fix in the current system), and that this occurred after you initiated the second RFC and I myself decided not to pursue the other one further, until others decided to put that forward (at which point I tried to make sure both RFCs were acknowledged in watchlist notices). However, still, prior to making it a true RFC the questions were free to be edited by anyone, including yourself. So stating the questions are misleading after the fact seems counterproductive as they could have been fixed at the start.
• Second, we're not marketing - we trying to achieve consensus, so good faith should be assumed that editors responding to the RFCs have read the questions and understand the implications, not responding to a survey question with the first answer that pops into their heads. As long as the core question is clear and understood, anything else around it should have been evaluated personally by every editor, and ignored if they felt it was biased.
• Third, what really should be happening now is seeking a neutral third-party on both RFCs to evaluate and provide conclusions based on the results, which will take in account any apparent biasing the questions may have had. There are some points that are very clear - date autoformatting is dead, for one - but the points on bare day/month and year links are not clear from either. Let that neutral party determine if the questions were truly rigged to get a specific response and declare that consensus is not clear on the answer due to the biasing.

The only reason I state this is that if you want to be pedantic, there are similar problems with your RFC (getting users to bring support on a negative statement, and starting from the assumption that the language of MOSNUM was accepted to begin with), though I'm not going to try to invalid those because the results between the two RFCs pretty much agree when the questions overlap: DA is deprecated, and only select links to day/month and year pages should be made. We shouldn't be trying to argue those points anymore, but instead making sure specifically for the day/month and year links when and where these are acceptable prior to having Lightbot et al run at full bore. Again, you're free to continue this analysis, but it does smack of wikilawyering and being a sore winner/loser, and is not going to be productive to resolving the conflict. --MASEM 16:59, 14 January 2009 (UTC)

I don't see myself as a sore anything here; no, it's clear that the amount of steam being generated from these RfCs at the ArbCom hearing, where they're used as the foundation for all sorts of claims to consensus, required a proper scientific analysis. The lesson to come out of this is that we must be very careful in constructing RfCs.

No matter who contributed to the wording, I can only analyse the wording that ended up being used. Is that not fair enough?

Marketing and soliciting information from people (consumers, WPians, etc) bear a lot of similarities; this is not sinister, but simply a technical observation. Tread carefully, I say, or some bastard will come along later and debunk the results. Tony (talk) 17:21, 14 January 2009 (UTC)

You can analyze these as much as you want, but really either we should get a third, neutral party to review the RFC, or you can raise your concerns that the RFCs were tainted by bad questions at the ArbCom case and let ArbCom evaluate that evidence. You're not neutral in this, nor am I (even if I'm just trying to resolve this, not push for an acceptable answer either way) --MASEM 17:33, 14 January 2009 (UTC)

My methodology is quite open—no secrets. You're free to criticise it. Tony (talk) 17:41, 14 January 2009 (UTC)

Tony you're not neutral in this, at all, and you've shown a continued unwillingness to compromise on issues surrounding this dispute. Why would anyone trust your judgment here? For similar reasons, while I appreciate Dabomb87's efforts, they will still not be as acceptable as getting someone outside the dispute (someone uninvolved) to give a fair opinion of the results. —Locke Cole • t • c 17:46, 14 January 2009 (UTC)

Note that Carcharoth recused himself from the arbitration, and he is far less involved than anyone in this conversation. Septentrionalis PMAnderson 19:58, 14 January 2009 (UTC)

True, we could ask him, but I'd personally prefer three uninvolved (or at least, as involved as Carcaroth) make this decision as a group. This way the decision isn't entirely on one editors shoulders (not a fair burden to ask anyone to take on) and so it receives reasonable consideration. —Locke Cole • t • c 21:45, 14 January 2009 (UTC)

What I did was a general summary of the RFCs; I made that before the Arbcom case had started. I intend to post that here soon. Dabomb87 (talk) 22:21, 14 January 2009 (UTC)

• Masem, I much appreciate the parenthetical in your initial post: I don't think this exercise is necessary the best of use of time (though WP is volunteering [so] you're free to do so). Indeed, Tony is volunteering his efforts to keep working this issue. WT:MOSNUM is a venue devoted exclusively to the exchange of ideas. If Tony has an idea and he wants to rally others to his way of thinking and create an RfC that 1) provides a mechanism for everyone to have a free exchange of ideas, and 2) quantify and qualify the varying opinions, he is certainly free to do so. Date linking and formatting has been a battleground where we’ve been scratching each others eyes out and questioning the parentage of others for over six months now. It must end and Tony thinks he can help. I hope to be second in line on any RfC he develops to register my views on this subject. You are free to do the same. May the editor(s) with the best and most appealing ideas prevail. Wikipedia will be the prime beneficiary when we finally have a clear community consensus on all of this. Greg L (talk) 21:30, 14 January 2009 (UTC)
  • Scientists and scholars are rarely "neutral" in relation to the data they produce: what counts is that their methodology is open and discussed. That is what I have done here, yet zilch, niente, null has been offered in substantive criticism of my analysis or conclusions. Thus, they appear to stand. Sorry people, you have to actually deal with the substance, not trumped-up complaints about "Tony1's behaviour". Tony (talk) 01:41, 15 January 2009 (UTC)
    • Your claims have no basis in fact and are reaching. Further, they're biased, and this isn't science, it's an attempt at consensus. —Locke Cole • t • c 02:08, 15 January 2009 (UTC)
• Masem, I don't think Tony was focussed on your RfC questions. Sure, they were problematic, and I did not hesitate to tell you so. The problem Tony seems to have is the emotionally appealing background to the "son of DA" (based on some unproven premises) which Locke et al had inserted into it in an attempt to influence. Ohconfucius (talk) 02:27, 15 January 2009 (UTC)

• The ArbCom will, hopefully, formally declare precisely what has been decided by the RfCs. To the extent that ArbCom doesn’t settle some disputed points, I have every confidence that Tony is perfectly capable of producing a new RfC that is clear as glass to all but the most intransigent of editors (which don’t have to be factored into a consensus in the final analysis). What is clear to me is Tony’s last RfC made it extremely clear that the community consensus was that it was a rare date indeed that should be linked in normal body text. I find it probative and amusing to note which editors here dispute that simple fact. Greg L (talk) 05:21, 15 January 2009 (UTC)
  • Stupid question: What would be the purpose of this RFC? Deprecation of linking per DA was affirmed in both RFCs, and both pointed to highly limited use of date links otherwise. The only thing left on the table is what those limited uses are. (The issue at ArbCom is the race to start the bots before establishing this aspect, which hasn't been discussed in any detail). --MASEM 05:33, 15 January 2009 (UTC)

• So, let me guess, Cole: it's not the methodology of an analysis that counts, but who's doing the analysis. Only people who pass Cole's power of veto may analyse the data from his RfCs. Again, there has been no substantive argument with my analyses and conclusions. That kind of figures. Tony (talk) 12:23, 15 January 2009 (UTC)

• Maybe everyone is tired and no one can be bothered to argue with you any more? Deb (talk) 12:58, 15 January 2009 (UTC)
  • If you're tired, don't log in. Those who are not too tired to write reams of discourse that use the results of these RfCs as supporting evidence have nothing substantive to say to a proper analysis of their language and structure. You don't? Tony (talk) 14:33, 15 January 2009 (UTC)

• Oh, and Cole, if you're going to accuse me at ArbCom of incivility, at least have the courtesy to use the correct word. UNcivil; INcivility. Got it? Tony (talk) 09:53, 20 January 2009 (UTC)

• Well… that reminded me of something. I wonder if G.H.W. Bush (Bush #41) got all hot & bothered when Saddam Hussein accused him of being an infidel and a liar? Now, no one should get all hot and bothered by suspecting that I think for a New York second that anyone here is a really, really bad person like Saddam; he used poison gas on his own people and was responsible for many other very bad things. No indeed, that would be taking the analogy much further than intended; everyone here are clearly splendid, law-abiding citizens and all that. But, what you just wrote, Tony, reminded me of that for some reason. I don’t think I’d let accusations of incivility get under my skin. In fact, since I seem to almost never agree with anything Locke writes here, and since I don’t admire his record of interacting with others and of chronically breaking rules of conduct here on Wikipedia, I think I’d be terribly proud of being on the receiving end of his criticisms. Congratulations. Greg L (talk) 16:32, 20 January 2009 (UTC)

• incivil. —Locke Cole • t • c 08:55, 21 January 2009 (UTC)

Poor old ArbCom

See this section. Tony (talk) 15:05, 15 January 2009 (UTC)

I suggest you leave them to do the arbitrating and leave the rest of us to get on with contributing to the encyclopedia. Deb (talk) 17:46, 15 January 2009 (UTC)

I'll do nothing of the sort. This is an interactive project in which cross-feedback is encouraged. Did you say you were tired? How about logging out? Tony (talk) 18:03, 15 January 2009 (UTC)

Sorry. Too busy creating articles. Deb (talk) 18:07, 15 January 2009 (UTC)

Suggest disengagement. Deb, remember that Tony is a preeminent FAC and FARC reviewer. A healthy bit of calm discussion is always nice. NuclearWarfare _(Talk) 22:00, 15 January 2009 (UTC)

• Well… I was going to ignore this thread until I saw Deb rattling Tony’s cage with this “I’ve got so much more important things to do in life than fret about trivial issues”-stuff. Unfortunately, I think you are both right. Tony should leave that petty name-calling to the arbitrators; they’ll see through it, recognize the fourth-graders responsible for it, and focus on the few salient issues. Tony’s reacting to being personally attacked is perfectly human and understandable; he, at least, gives a crap about his reputation (unlike some, who obviously don’t care what anyone thinks). After Tony has been on the receiving end of so much slander, I’m sure he’d like to cordially invite some of the editors there to do something to themselves that isn’t generally considered to be physically possible. But, Deb, your dismissive, flippant *I’m a big-picture kinda guy who seems to be uniquely alone in improving Wikipedia*-tone, is uhmm… unimpressive (even though I enjoyed your 18:07 post). And finally, Tony is right; the latest ArbCom looks like a bunch of third-graders have run amuck and taken over the place. What Tony needs to understand is this: That’s GREAT! Greg L (talk) 23:05, 15 January 2009 (UTC)

• Time and again my block log is held up in the air like it's the Heisman Trophy. Of course my block log is largely irrelevant. Anyone objectively looking at it will note that most blocks are undone and some of the entries are of a technical nature (autoblock was broken, and one was undone because the admin didn't understand the edit I made, he even noted it shouldn't be held against me). —Locke Cole • t • c 03:41, 16 January 2009 (UTC)

• No, “most” of your blocks (here) were not unblocked. And the portion that were unblocked weren’t because the blocks was in error (as was the sole block for Tony), they were unblocked because you and/or the other editor showed contrition—which I’ve unfortunately never seen from you here. Your block log betrays the whole reason so much bickering has transpired over a practice which has clear community consensus. Your record paints an unambiguous picture of an editor with a chronic propensity of being bullheaded and of being uncivil to others. In short, you don’t “play well with others.” Tell me I’m wrong. Or are you just a “misunderstood genius” and you suffer only from knee-jerk reactions from admins?

  Since the community consensus was so clear with regard to how it should be a (very) rare date that is linked in body text, you decided your only available recourse was to resort to wikilawyering in an attempt to squelch the most effective tool in our arsenal (prolific editors like Lightmouse and his exotic bots).

  Earth calling Locke Cole: It doesn’t matter what happens this week or next; you are fighting a battle in a loosing war. The community consensus on date linking is abundantly clear; your arguments here are unpersuasive and you won’t be able to reverse that. The community consensus that bot operators don’t need permission from you and others to do their thing is also clear; it just might need to be more clearly proven in yet another RfC; ergo, the part about you loosing the war in the final analysis. Greg L (talk) 18:37, 16 January 2009 (UTC)

• All the time, without combing through the entries in Cole's block log, I had been wondering about how he appeared to know so much about the ArbCom process. Then, it became clear that Cole had been there before, and had received a one month block for stalking. About his block record, sure, there were "some of the entries are of a technical nature", but the most illuminating entries were not - and there were a few of these. Most entries were for edit warring, and user harassment. Your record could not be more relevant, for I and a few others had received a good dose of same under your hands. Now he risibly moves on ArbCom as if he was the victim, portraying Tony (predominantly) evil. Can you still defend your block record now, Cole? Ohconfucius (talk) 04:27, 16 January 2009 (UTC)

• My past misbehavior does not excuse Tony (or you, or Greg L) from misbehaving now. —Locke Cole • t • c 04:42, 16 January 2009 (UTC)

Locke is correct here. -- Earle Martin [^t/_c] 11:52, 16 January 2009 (UTC)

• Aw, geez—why don't you give him a paper cut and put lemon juice on it while you're at it. And just when I thought some degree of calmness was sneaking back into things. :-(  HWV258  04:46, 16 January 2009 (UTC)

• Because his block log underlies the whole reason why we are engaged is a pitched battle over a common-sense change. See my above post. Greg L (talk) 18:40, 16 January 2009 (UTC)

• How, pray, am I "misbehaving" now? That is a term usually used reserved for children. In what way have I been childish? Ohconfucius (talk) 06:10, 16 January 2009 (UTC)

My fault, I started this (kind of). Let's try and forget that there's an arb-thingy on, shall we? Deb (talk) 13:01, 16 January 2009 (UTC)

• You mean the "Get Tony Page"? Tony (talk) 14:34, 16 January 2009 (UTC)
  • No, try to see if Tony (and some others) can behave like civilized human beings: a pledge to that effect should still, since ArbCom is not yet coherent after their internal troubles, defeat the proposed sanction against him. Septentrionalis PMAnderson 20:58, 18 January 2009 (UTC)
    • That sounds like a personal attack. Tony (talk) 09:50, 20 January 2009 (UTC)

Yards and metres

Can a value in yards be supported by a value in metres? I tried on two occasions to add a value in metres to the phrase "within 200 yards of the Dudley factory" but it was reverted twice. Please can somebody take a look at Bean Cars and see if I am missing something? Lightmouse (talk) 14:27, 16 January 2009 (UTC)

Should definitely be converted to metres. Tony (talk) 14:32, 16 January 2009 (UTC)

Perhaps you should consider raising the issue with the editor in question at Talk:Bean Cars, rather than fleeing here for backup. -- Earle Martin [^t/_c] 14:39, 16 January 2009 (UTC)

What has happened to everybody lately? Can't we get along anymore? Lightmouse (talk) 14:52, 16 January 2009 (UTC)

It looks to me like the kind of article where the vast majority of readers can be expected to know that within the level of precision used here there is no difference between yards and metres. To such readers it does indeed look silly. Now if this was the article Tower Bridge, the readership would be quite different, and I would argue to include the indication in metres or perhaps to drop the yards altogether. --Hans Adler (talk) 15:17, 16 January 2009 (UTC)

I agree with Tony, put it in. If it was ...200 metres of the Dudley factory, I'd convert to yards. The MOS does back you up on this. However, in my opinion, this type a of discussion probably should have taken place on the Bean Cars article's talk page first before coming here. —MJCdetroit ^(yak) 18:07, 16 January 2009 (UTC)

Some of the international readership may not know what a yard is, since metre is the only unit used in their country. People in the US and UK need to realize that some people in other countries (particularly those who speak English as a second language) may never have used it.RockyMtnGuy (talk) 20:00, 16 January 2009 (UTC)

Hehe - as an amazing example of "small world", the Coseley factory is just a few hundred yards (metres :p) from where I live! I've added a little more info to the article, plus conversions, and mentioned on the talk page that they are a courtesy to readers who are not familiar with yards. Hopefully we'll reach a consensus. --RexxS (talk) 04:30, 19 January 2009 (UTC)

• Some of the "international readership" doesn't know what of means (and edit anyway). The solution to their problem is the Simple English WP. Septentrionalis PMAnderson 04:29, 20 January 2009 (UTC)

Some of the "international readership" has a better command of English than most Englishmen and Americans (at least in my opinion). However, there are several factors which are relevant:

1. The United States is the only country which still recognizes the yard as an official unit of measurement.
2. In English-speaking countries outside of the US, traditional English units such as the yard are no longer being taught in schools.
3. English is becoming a global lingua franca used by educated people world-wide.

As a result, there are increasing numbers of people who have a good command of English as a first or second language, but who may not be familiar with traditional English units of measure such as the yard.RockyMtnGuy (talk) 05:45, 20 January 2009 (UTC)

Agreed with Rocky, I have many European friends who speak excellent English, but would not have good grasp of the distances involved if they were given only in yards. On the other hand, I spent 25 years teaching maths in England and had to recognise the fact that, for general use, miles, yards, feet and inches were what most folk understood. I certainly taught metric units, but also had to teach imperial if the students were to be equipped to deal with the realities outside of the classroom. A school-leaver who was comfortable with both sets of units was far more useful than one who could only deal with one set. The guidance to provide a conversion, wherever possible, seems like eminent good sense to me. --RexxS (talk) 20:35, 20 January 2009 (UTC)

This makes absolutely perfect sense to me; in fact my father told me of a foreign-born colleague many years ago who asked the proctor at a fairly-advanced science or maths exam how many inches were in a foot. It's only a question of what's the most natural, least intrusive, least pompous way of letting metric Anglophones know what "200 yards" means. —— Shakescene (talk) 21:02, 20 January 2009 (UTC)

In most of the former British colonies, the schools no longer teach miles, yards, feet and inches. The students have heard these words from their elders, but can't really visualize them unless you convert them to kilometres, metres, and centimetres. If you say "200 yards (180 m)" it becomes clearer. Also, the schools in some English-speaking countries don't seem to teach grammar any more, which means students couldn't put together a coherent sentence to save their lives. On the other hand, people learning it as a second language often get a lot of grammar. I had a French teacher who met her husband at the Sorbonne in Paris. Being Anglo-Canadian, he thought it would be an easy credit to take English. He failed the course. Just because English is your mother tongue doesn't mean you know how to speak it properly.RockyMtnGuy (talk) 00:51, 21 January 2009 (UTC)

I think that 200 yards has only a trace over one significant digit, so 180 metres might be probably misleadingly over-precise. I go crazy whenever I read something like most blades of some grass or most book margins are 2.54 cm, or that some creature is about 25.4 centimetres long, when the writer obviously intended to say about an inch or about ten inches. ¶ As for English, I'm not that surprised because most of the original grammatical names and categories try to impose Latin or French rules on a fundamentally-Germanic grammar. (French, for example, uses different forms for the conditional and subjunctive where English makes little or no distinction, while most moods and tenses are formed from finely-differentiated auxiliary verbs that fit Latin rules rather badly.) Norwegians learn Norwegian and the Greeks are taught their Greek. —— Shakescene (talk) 02:00, 21 January 2009 (UTC)

You don't know really how many significant digits 200 yards has unless someone tells you, e.g. 200 yards ± 10 yards - the convert utility does its best, but it has to make assumptions. As for the quote from Pygmalion, I've always found it amusing because I understand a little Norwegian and know that the Norwegian language has two different official forms, Bokmål and Nynorsk, and there are hundreds of different Norwegian dialects, with considerable controversy over their grammar and spelling. In other words, it's a linguistic in-joke. However, most Norwegians I have met speak English extremely well - they sound like they come from Minnesota rather than Norway. But when you tell them distances in miles, they think you mean Norwegian miles (10 km).RockyMtnGuy (talk) 06:32, 21 January 2009 (UTC)

That line would have been a great example of devious Shavian wit, because the Greeks were another post-Napoleonic nation who similarly battled endlessly over which Greek to teach: Katharevousa or Demotic (see Greek language question). One example my friends who opposed the Greek military junta of 1967-1974 gave of its repressive backwardness was making the formal and uncolloquial Katharevousa compulsory in schools, which is why the Greeks had to be taught their Greek. (Katharevousa was banned from Greek schools in 1976, after the junta fell.)

It would have thus been a doubly great Shavian line, had it been written by Shaw. But I can't find the line in Pygmalion, only in the lyrics to My Fair Lady by Alan Jay Lerner (of Lerner & Loewe). So render unto Lerner the things which (deliberately or not) are Lerner's, and render unto Shaw the things that are Shaw's. [And while I'm not sure if I'd made the connection to Henry Higgins' outburst, I did know there were two Norwegians, though I'd known them as Landsmål and Riksmål]. The debates engendered by diglossia (cf. classical vs modern Hebrew & Arabic) make Wikipedia's squabbles over (e.g.) MOSNUM look friendly and tame.

And if you look at the Minnesota Star Tribune's recent files, you can see the local puzzlement that Governor Sarah Palin of Alaska, born in Idaho, sounded so Minnesotan. The indirect answer seems to be that FDR's New Deal settled thousands of desperate (and later gratefully Democratic) Minnesota farmers on virgin lands in the Alaska Territory during the Depression, producing the local accent picked up by newer migrants like Sarah Palin. —— Shakescene (talk) 08:44, 21 January 2009 (UTC)

RockyMtnGuy has this spot on. I know many English speakers who are unfamiliar with yards and inches. They should be converted. The appropriate number of significant figures depends on the situation. Thunderbird2 (talk) 19:24, 22 January 2009 (UTC)

Date ranges

I see no decision on date ranges, so I will WP:BB and enter one. Here it goes.

In dmy, if a range of dates occur in one month, 8 – 17 January 2009, 8 January – 17 January 2009, and 8 January 2009 – 17 January 2009 are all acceptable, though the shorter the better. 8 – 7 January 2009, on the other hand by shortening a datum from two significant figures to one, is unacceptable. Similarly for mdy, January 8 – 17, 2009, January 8 – January 17, 2009, and January 8, 2009 – January 17, 2009 are acceptable but January 8 – 7, 2009 is not; the second is most preferable because it leaves at least one full date for searching. When spanning months, dmy users may apply 28 January – 3 February 2009 or 28 January 2009 – 3 February 2009 but not 28 – 3 February 2009; the shorter the better. mdy users may apply January 28 – February 3, 2009 or January 28, 2009 – February 3, 2009 but not January 28 – 3, 2009; the shorter the better. When spanning years, one format alone is used for each. dmy is applied as 8 December 2008 – 17 January 2009 and mdy is applied as December 8, 2008 – January 17, 2009.

How was that? Feel free to edit it to make it 'flow'. :)--Thecurran (talk) 03:43, 17 January 2009 (UTC)

Okay, I cannot WP:BB here because I need admin privileges. Please help, admins! :)--Thecurran (talk) 03:52, 17 January 2009 (UTC)

You wouldn't need a space if the elements separated by the dash have no space (i. e. just the day): e.g. 8 January 2009 – 17 January 2009 but 8–17 January 2009; January 8, 2009 – January 17, 2009 and January 8 – January 17, 2009 but January 8–17, 2009. Also, the suggestion not to write 8 – 7 January 2009 or January 28 – 3, 2009 to mean 8–17 January 2009 and January 28 – March 3, 2009 sounds like WP:Don't stuff beans up your nose: nobody would do that anyway, so, better not to mention that at all. -- Army1987 – Deeds, not words. 09:35, 17 January 2009 (UTC)

i concur with the WP:Don't stuff beans up your nose assessment, which leaves us with something like:

In articles using the dmy format, if a range of dates occurs in one month, 8–17 January 2009, 8 January – 17 January 2009, and 8 January 2009–17 January 2009 are all acceptable; for articles using mdy format, January 8–17, 2009, January 8 – January 17, 2009, and January 8, 2009 – January 17, 2009 are all acceptable; in most cases the shorter forms are better.

When a date spans months, the dmy format is either 28 January – 3 February 2009 or 28 January 2009 – 3 February 2009; in mdy format, either January 28 – February 3, 2009 or January 28, 2009 – February 3, 2009 are acceptable; again, the shorter forms are generally preferred.

When a date spans years, dmy format is 8 December 2008 – 17 January 2009 and mdy is December 8, 2008 – January 17, 2009.

something like that, anyway - i've no doubt messed up the spacing but i trust Army1987 will adjust it as necessary - thanks Sssoul (talk) 10:47, 17 January 2009 (UTC)

OK. Let's give a try:

=== Date ranges ===

For date ranges, the following formats can be used:

	Day before month	Month before day
Dates in the same month	17–24 January 2009 17 January – 24 January 2009 17 January 2009 – 24 January 2009	January 17–24, 2009 January 17 – January 24, 2009 January 17, 2009 – January 24, 2009
Dates in different months of the same year	17 January – 24 March 2009 17 January 2009 – 24 March 2009	January 17 – March 24, 2009 January 17, 2009 – March 24, 2009
Dates in different years	17 January 2009 – 24 March 2010	January 17, 2009 – March 24, 2010

The shorter formats are usually preferred; the exception being the shortest mdy same month format, "January 17–24, 2009", because it obstructs text searches for both start- and end-dates.

-- Army1987 – Deeds, not words. 11:22, 17 January 2009 (UTC)

• None of this is necessary. All that are required are two simple rules, and they're there already.
  • Space the en dash when there's an internal space in one or both elements; otherwise, don't space it.
  • Consider avoiding repetition ("January 3–17" rather than "January 3 – January 17"). Tony (talk) 11:26, 17 January 2009 (UTC)

• Where are those rules Tony? I can't see them in the date ranges section, at least not explicitly. Woody (talk) 12:29, 17 January 2009 (UTC)

• Take a look at WP:Manual of Style#En dashes. Hope that helps. --RexxS (talk) 13:55, 17 January 2009 (UTC)

• In auditing the date ranges in military-history pages, I was aware of how such ranges—which are very important in that field—are poorly formatted, right at the top of articles. I wrote a brief section into the style guide at the MilHist WikiProject, which was well-received. Tony (talk) 15:28, 17 January 2009 (UTC)

With Wikipedia, I have come across the "If I tried to do it, someone else will, too", line of logic many times and it always seems to ring true. Now, if you folks agree that it is explicitly clear on the WP:ENDASH section how all date ranges should be formatted, I think it would be sensible to have a link to that section in MOS:NUM#Other_date_ranges, simply because I came looking for how but could not find it, so others must be doing the same (but probably not WP:BBing and asking why) and will continue to do so.

Personally, I think WP:ENDASH does not have enough information to construct the rules you normally abide to. I wrote the beanish phrases above because only a few subsubsections below, I saw WP:YEAR asking us not to abbreviate a year into three digits or one, which at first glance is beanish, but I have seen it in adult classrooms and community newspapers. Beyond which there is always room for dyslexia and typographical errors, so I tried to think of which "mistakes" would make a well-read person cringe but are likely to be made by someone poorly-versed in English (but with valuable subject knowledge) and tried to prepare for those contingencies. :)--Thecurran (talk) 20:20, 18 January 2009 (UTC)

wikt:BTW, sorry for misusing the endash spacing. between numbers. I find the lack of spaces, visually disturbing but I do not wish to override convention. I seriously have seen it both ways many times (even here) and thought it was up to editor preference. Now I see we have had this rule for a while.

I like User:Army1987's graphical approach. My only qualm is that I think the "January 17–24, 2009" one should be discouraged simply beacuse it cannot be parsed for the start-date, "January 17, 2009", nor the end-date, "January 24, 2009", like each of the other entries can and we are text-searched a lot. What do you guys <gender-neutral in my upbringing> think? :)--Thecurran (talk) 20:35, 18 January 2009 (UTC)

I strongly dislike the <ins> addition. We've gone through that before, and it clearly fails both common usage and common sense. — Arthur Rubin (talk) 01:02, 19 January 2009 (UTC)

I used "ins" and "small" in User:Army1987's graphical approach to address my qualm. The small text has the lowest importance but may solve FAQ's. :)--Thecurran (talk) 20:48, 18 January 2009 (UTC)

There is no need for a huge blow-out of advisory text: just the two principles I entered above, with a few brief examples. Tony (talk) 08:24, 20 January 2009 (UTC)

Sure I am up for that addition. I certainly think something should be entered. Does anyone else think that January 17–24, 2009 should be avoided because it causes problems for parsing? :)--Thecurran (talk) 10:32, 20 January 2009 (UTC)

Just what did the RfC on month-day date-links show?

I've examined the third of the "detailed" RfCs. It has been trumpeted as indicating consensus for "at least some form of month-day linking". Let's look at why this is very misleading, and again why we need to be very careful in the way we frame RfC—indeed surveys of any type. This one is by far the most problematic of the three I've looked at.

Summary

• Allowing only three possible choices significantly swelled the numbers in the middle "certain cases" category.
• The language at the opening may have skewed the results towards the favouring of linking.
• More than 90% of respondents appear to have a very conservative attitude towards the linking of month-day dates.
• There may be consensus to allow the piping of a few annual events to month-day pages, but this RfC demonstrates little public favour for more than a very small amount of month-day linking as exceptional cases.

The available choices distorted decision-making

In their rush to prepare the RfC, the authors did what I might have first thought of doing—giving everyone just three choices: that month-day links should:

1. always be made;
2. be made in certain cases; or
3. never be made.

While on the face of it this seems reasonable, the tripartite choice placed many participants in a difficult position: not wanting to support an inflexible, total ban on the linking of any class of item (Choice 3), they were forced to put themselves in the middle category, that month-day date links be made "in certain cases". There is clear evidence of this conundrum; one of the more explicit pleas was from Pagrashtaki—

I cannot support the phrase "Month-Day links should never be made". I would agree that, in general, Month-Day should not be linked. I cannot quickly think of a high-value Month-Day link (25 December on the Christmas article is not high-value in my opinion) [Pagrashtak]

In good faith, I think, a stated aim of the authors was to encourage feedback and discussion within these three categories; but they may not have been aware of how this aim worked against the drawing of definite conclusions from the survey—witness the difficult task of sorting out within that middle category users' actual attitudes to the question at hand. I've attempted to do this as best I can for the more than 50% of participants who placed themselves in the "in certain cases" category, :

• Very rarely: some 22 participants. Many used these actual words (one said "Very very rarely", and one "Very very very rarely"); the rest I've included in this subcategory because they used equivalent language. Two mentioned exceptions such as "April Fools Day" and "All Saints Day", and two might well have been appropriately classed as "Never" (one of them User:It is we here), although I didn't shift them.
• Rarely: 12 users.
• Specific events: 17 users did specify that annual events such as "All Saints Day" might be linked, and four mentioned dates of birth (one of them death-date as well); three people felt that month-day dates might be linked in infoboxes (one of them in the lead, too). Total of ~ 23.^{Note 1}
• Unclear, leaning towards mostly: Four, but including the remark, "only where of value" [BarkerJr].
• Mostly: two participants, who (conversely) couldn't bring themselves to declare "Always" (Choice 1).

Note 1: Critically, however, the distortions imposed by being funnelled into one of three choices were all too evident in numerous responses – for example, "Otherwise very rarely" [RainbowOfLight] and "But other than that, it's slightly pointless. For example, I sometimes read articles on fictional characters and soaps that link a date. It makes the whole thing seem redundant." [londonsista].

The basic breakdown was presented a while ago:

1. 5 Always [4.2%]
2. 63 In certain cases [52.5%]
3. 52 Never [43.3%].

However, the psychological funnelling of large numbers of users into the middle (Choice 2, "in certain cases") has made such a count highly misleading. Given that the style guides do not speak in terms of total proscription of any links (words such as "normally" and "generally" are used), four or even five categories—more finely graded—would have yielded less distorted results, and these subcategories I've identified would have been much less of a structural feature. It's hard to say exactly, but my reckoning is more like this:

1. 7 – 5 Always, plus 2 probably more appropriate here than in the middle category ([5.8%])
2. 4 – Leaning towards the previous category (3.3%)
3. 23 – Only "All Saints Day", "April Fool's Day", etc ("annual events") [19.2%]
4. 86 – Don't link, with rare or very rare exceptions (52 Never, plus 34 rare/very rare, who were put off by the extreme framing (i.e., "no exceptions") [71.7%]

Conclusions

More than 90% of respondents appear to have a very conservative attitude towards the linking of month-day dates. Typical comments were ""We don't need a world view of what was going on that day in order to better understand the subject of the article." and "These articles are almost trivia collections." It appears that there may be consensus to allow the piping of a few annual events, at editors' behest, but the conclusion that was drawn by more than one editor that this RfC demonstrates a public favouring of the linking of month-day items "in some cases" (vague) needs to be re-examined. I propose that piped links to annual events such as "All Saints Day" be explicitly permitted in the style guides; however, the overwhelming evidence favours no more than this.

Distortions in the opening text

Two other factors may have skewed the results to favour linking.

POV wording: The opening "Background" contained a major error (as far as I can see), and the title and formal question contained a hidden POV assumption. Rather than using NPOV wording, such as:

• "Should month–day links be made in articles; if you believe they should be made, comment on when this should occur."

the formal question encouraged the false assumption that these links are or should be made, by asking only when they should be made:

• "When should Month-day links be made in articles?"

The wording implied when, not if, so it was almost a fait accompli that month-day dates should be linked some of the time.

Apparent error of fact: first-time link rule in guideline? This statement appeared:

• "It should also be noted that per the [[WP:MOSLINK|current style guidelines for linking]], normally an article should link to a date – if at all – only the first time the date appears in the article."

The link was to the top of the MOSLINK page in general; the complete absence of the claimed guideline therefore required the participant to hunt around to try to find the statement referred to. More likely, most participants accepted this apparnetly false claim at face value. This had the distorting effect of encouraging users to believe that the linking of month–day items is already mandated at the top of articles. This was not and is still not mandated in the style guides.

Final comment: This is not a blaming exercise; it is all too easy to unwittingly introduce skew into a survey. Tony (talk) 14:28, 18 January 2009 (UTC)

FWIW, as that question was not edited much beyond my initial draft, my point of the "should, then if" instead of "when" was that for the purposes of a first-run RFC to determine several date linking issues, it did not make sense to try to work out the exact details of when date fragments should be linked in light of trying to strip autoformatting dates, only if the general attitude was always, sometimes, or never; if consensus pointed to either absolute choice, then Lightbot et al would know what to do with those links. I fully expected that further discussion would be needed to establish that if it was "sometimes" there would need to be determination of when. Thus, there was no intended distortion, it was only trying to get clarity per the aim of what Lightbot and others should be getting ready to do. --MASEM 15:25, 18 January 2009 (UTC)

Whatever the claims of "distortion", most of the "sometimes" and some of the "never" said something like rarely, which is the important point. Tony's effort to construe a majority for rarely as consensus for never is curious; it should be obvious that there is no consensus. Masem's further discussion may produce one; but in the meantime, why don't the minority that would like to routinely link, and the minority that is blinded by the sea of blue in linking May 1 in May Day go back to the showers, and decide whether it is worth coming up with better arguments to win so small a prize? Septentrionalis PMAnderson 21:05, 18 January 2009 (UTC)

That's gobbledygook. Did you read what I said? I made no claim that there was consensus for "never"? Do not twist my words for your own purposes. Heavens, Anderson, no one will take any notice of what you say, soon. Tony (talk) 01:28, 19 January 2009 (UTC)

If the result is no consensus, as I believe, then what do the details matter? Tony's last post at least half concedes this.

Without consensus, the bots and scripts flying about have no justification for their bulldozing, which is the sole issue actually in question. Septentrionalis PMAnderson 17:47, 19 January 2009 (UTC)

Don't twist my words, Manderson. Read what I said in the analysis. Tony (talk) 08:23, 20 January 2009 (UTC)

This acknowledges that if there is a consensus, it is to link rarely, and a few of the specific categories that several of us think may be worth linking. Other than that, it follows the model of a Bushie report: it comes to the conclusion the reporter wishes the world to believe, even though it is unsupported by the evidence. In particular, Typical comments were ""We don't need a world view of what was going on that day in order to better understand the subject of the article." and "These articles are almost trivia collections." is unsupported, even by Tony's own count; that's one of three views that a significant number of commenters expressed. Septentrionalis PMAnderson 16:12, 20 January 2009 (UTC)

I endorse Tony's summary

And just by the way, I can't wait for mass delinking to be put back on track very soon. I just gave up half way through removing stupid datelinks and other distracting blues from Ernst Nolte because it was turning me into a vegetable. That is work for a machine, not a human.--Goodmorningworld (talk) 00:10, 20 January 2009 (UTC)

Agreed. (I completed the date formatting and linking edits for the article.)  HWV258  00:46, 20 January 2009 (UTC)

Thank you!--Goodmorningworld (talk) 01:19, 20 January 2009 (UTC)

I hope I won't be dragged before ARBCOM for asking this, but isn't there a bot that scans for punctuation marks before <ref> bla bla </ref> and puts the comma or period after the </ref> where it belongs? If there isn't yet then there should be.--Goodmorningworld (talk) 01:27, 20 January 2009 (UTC)

Yes, I've always found it "funny" to see the </ref> after the punctuation, but I've never bothered to investigate the accepted practice. Not sure about a bot that does it either. Sorry. Perhaps I should start ARBCOM procedings on myself for wasting Wiki-ink with this less-than-helpful post?  HWV258  01:56, 20 January 2009 (UTC)

Aaaargh, I meant it the other way around, and what is worse, I just checked and discovered that according to WP:REFPUN (just down the street from Minitrue, and remember: Ignorance is Strength) I did it wrong, either way is okay but now that I abandoned changing around the REFPUN order midway through, Ernst Nolte is stuck in limbo, neither dead nor alive, just as the horrible fate suffered by Monsieur Valdemar! though on 2nd thought, it couldn't have happened to a nicer guy.--Goodmorningworld (talk) 02:15, 20 January 2009 (UTC) Update: request made at WP:BRFA for a bot to clean up after me.

Gruesome! I wonder if "Valdemar" is where Rowling got her charcter name "Voldemort"?

Perhaps the date-delinking evidence page should be handed over to Miniluv?

The Ernst Nolte article is a pretty full-on page. (Personally, I'd prefer to put effort into other topics.)  HWV258  02:49, 20 January 2009 (UTC)

• Tony’s summary seems like an accurate portrayal of the facts to me. Loose the links. Let bot operators prolifically nuke dates as they see fit. Greg L (talk) 04:21, 20 January 2009 (UTC)
  • Fixed that article. Dabomb87 (talk) 13:19, 20 January 2009 (UTC)

The structure of the dates and numbers article concerning BC vs BCE etc..

I sometimes forget the BC vs BCE convention at Wikipedia and frequently have to re-look it up. This is a question of upmost importance regarding style. Unfortunately, the current structure of the document makes the reader spend more time than they should to find the answer and the current outline is logically incorrect. First the BC vs BCE (and of course AD vs CE etc.) issue should be handled under the Dates section and not the "year numbering systems" section. BC, CE, and so on all are used with dates. The section heading should also make it easy to spot that this is the section that deals with this question... something like "BC vs BCE etc." would be a great heading title. The "year numbering systems" should be called something like "Scientific units of time". After time for feedback, I might just make the changes if nobody objects. Jason Quinn (talk) 00:05, 19 January 2009 (UTC)

Yes, BC/BCE/AD/CE are used with dates, but they qualify the year alone. They belong in "year numbering systems" as much as BP, bce and mya do. It is probably a minor matter whether that section is listed as a fourth level heading under "Dates" or as a third level heading as it is now. Optionally, if editors have problems finding the section, perhaps another bullet point in the Dates section could read:

• Guidance on the use of BC/BCE/AD/CE is given at WP:ERA.

Personally, I've never had a problem finding the guidance, but if others have problems, then suggestions for a fix would be welcome. --RexxS (talk) 00:31, 19 January 2009 (UTC)

And since the guidance consists of "we use all four of BC/BCE/AD/CE, in their usual format", why is it hard to remember? Perhaps we should rephrase. Septentrionalis PMAnderson 18:04, 19 January 2009 (UTC)

It's not hard to remember but policies change, so before an editor goes and makes a big change to several articles it is often useful to re-check with the MoS. I recheck the manual of style constantly even for things I'm pretty sure I still remember. Plus sometimes if you haven't fixed any dates in articles for 6, 8, or 12 months, you do forget. This is absolutely one of the most common formatting questions that arises it deserves to be as easy as pie to find. Currently a user trying to find it from the MoS main pages, goes straight to the MoS date and number section, and then goes to the Dates subsection only to spend a minute skimming it only to discover the information they want isn't there. It then takes another moment to realize there's some goofy semi-ambiguously named "Year numbering systems" section outside of the dates section where the info they want is located. All of those prefixes BC/BCE/AD/CE/BP are always part of the formatting for dates and should be under that section, not outside of it. The WP:ERA shortcut should point to a subheading under Dates perhaps still named "Year numbering systems". It is clearly more logically incorrect than correct to have "year numbering systems" outside of the "dates" section. Lastly, I never said I wanted to rephrase the policy language itself, but to reorder the outline and perhaps rename the section titles. "Year numbering system" is a confusing phrase and I promise you that most users that click on it aren't sure what it contains; but if the section title had "BC vs BCE and so on" in it, they would know instantly what the section was about before even clicking. Jason Quinn (talk) 19:46, 19 January 2009 (UTC)

I recheck the manual of style constantly even for things I'm pretty sure I still remember. Dear Heavens, why? Ignore all rules you find on Wikipedia (Wikipedia is not a reliable source) and write English. Septentrionalis PMAnderson 20:36, 19 January 2009 (UTC)

You don't feel inclined to help make it a "reliable source"?

MoS is a guide (not a rulebook).

"Ignore all rules you find on Wikipedia"—could that be the final nail in the coffin for the "civility" evidence?

Just out of interest, will you ignore this one?  HWV258  02:21, 20 January 2009 (UTC)

Tony (and others) appear to believe it's a rulebook which must be followed. —Locke Cole • t • c 02:27, 20 January 2009 (UTC)

I wouldn't have said that, but they are good at implementing its guide.  HWV258  02:48, 20 January 2009 (UTC)

I'm inclined to move article space closer to being a reliable source; we will not succeed before WP:DEADLINE. This page is an impediment to that goal insofar as it takes up editor time or attention. Septentrionalis PMAnderson 03:53, 20 January 2009 (UTC)

In my humble, that's a bit like saying the road-rules handbook is an impediment in getting from A to B. Surely once you've read the "rules" you've become empowered to safely and confidently participate? (Which is not to say that people can't behave like a maniac from time to time.)  HWV258  04:43, 20 January 2009 (UTC)

No. There are two differences

• I said this has nothing to do with reliability (or neutrality, or verifiability); nothing on this page affects any of them. Nor would this page, even if it got things right.
• But it doesn't. This page has the greatest possible flaw in a road-map: It doesn't match the territory. This page does not describe what Wikipedia does, or what good English should do; it describes the prejudices of a handful of underqualified editors.Septentrionalis PMAnderson 06:19, 20 January 2009 (UTC)

• I didn't saw "road-map", I said "road-rules". I don't believe the page is designed to describe what "Wikipedia does". I still believe you could play a valuable part in improving the page to help explain to others what "good English should do".  HWV258  21:15, 20 January 2009 (UTC)
  • That would mean cutting about 90% of it out, where it pointlessly adjudicates between two things, both of which good English does; or, yet worse, requires a rule which good English does not follow. Septentrionalis PMAnderson 21:32, 20 January 2009 (UTC)
    • For any particular example, if both are "good" English, then what troubles you with picking one?  HWV258  21:43, 20 January 2009 (UTC)
  • Because there is no reason to pick one. Both are useful, and we will get editors who reasonably prefer both; quite often each is more useful in some situation than the other. We should allow both editors to edit, because anyone can edit, and not make rules for rules' sake. Septentrionalis PMAnderson 21:55, 20 January 2009 (UTC)

• But there is—consistency across articles—hence improving the casual reader's experience on WP. I really don't know how else to say it, but I'll have another go: both editors are allowed to edit, and therefore make their contribution to WP. The fact that a "worker ant" mops up behind them without changing the semantics of the original edit shouldn't bother anyone (and, in general, it doesn't). MOS is a guideline, so if there is a localised situation where one format should be adopted over another, it can be discussed and adopted by consensus. You are failing to convince me.  HWV258  22:07, 20 January 2009 (UTC)
  • Consistency across articles on 17 vs. seventeen is a Golden Calf. We shall never obtain it, and I have never seen an actual reader complain of its absence; the efforts to obtain it suppress the real occasions where one or the other has some point. We would do better to leave it alone, as we leave honor/honour alone; readers don't boggle at that inconsistency either. Septentrionalis PMAnderson 22:17, 20 January 2009 (UTC)

• I disagree with everything you have written above. WP is an evolving process, and as you have pointed out, there is no deadline. Please remember that the vast majority of readers can't complain as they don't log in. I have pointed out that localised consensus can over-ride MOS in the case where "the other has some point". I don't believe "honor"/"honour" is an inconsistency as there are guidelines as to regional spelling.  HWV258  22:26, 20 January 2009 (UTC)
  • Please remember that the vast majority of readers can't complain as they don't log in. It's news to me that anons can't post; they do regularly, usually to complain. But this seems of a piece with the rest of this "argument". Septentrionalis PMAnderson 23:54, 20 January 2009 (UTC)

• Disingenuous! I would confidently state that the vast majority of readers at WP don't even realise they can edit. I've personally talked to many many people in order to advocate the use of WP, and almost universally I hear a surprised response when I point out that they are free to edit. Your point of "I have never seen an actual reader complain of its absence" is moot.  HWV258  00:17, 21 January 2009 (UTC)
  • De gustibus non disputand' est. Just please confine your taste to the edit wars on this page, and don't inflict it on the rest of Wikipedia. Septentrionalis PMAnderson 22:45, 20 January 2009 (UTC)

• (outdent) Well… I go away for a while and check in here before getting myself a cup of coffee. And what do I find? On a thread that doesn’t even have Tony weighing in, I see you two feeding off each other and busy nipping away at Tony’s heels for seemingly no good reason other than to not miss out on yet another opportunity to get some digs. For one thing, this crap is getting is tedious. So it would be just splendid if you guys did a better job of acting like the grownups I presume your drivers licenses say you are.

  And, FWIW, what MOSNUM eventually ends up doing will ultimately be decided by the community consensus. And that can be influenced only through sound, reasonable, logical arguments that persuades others to a way of thinking. If you guys think that trying to drag down the reputation of one of our most respected editors, then, by all means, keep at it. For I take great pleasure in pronouncing that I rarely agree with anything you write here and am perfectly content to sit back and watch you act like fourth-graders in a vain attempt to influence the community consensus. Greg L (talk) 02:54, 20 January 2009 (UTC)

  • There should be no "MOSNUM community", there should be the community of Wikipedia, which deliberates here or elsewhere as may be most convenient. Underneath the petty squabbles, that's the real point at issue. Septentrionalis PMAnderson 03:50, 20 January 2009 (UTC)
    • Don't you feel that guidelines influencing consistency across articles aid readability? Otherwise you'd end up with (to take some sort of weird hypothetical case) the situation where tennis-based articles have linked dates, but music-based articles don't have linked dates—which could be confusing to the average reader. (And I hope that everyone is welcome at the MOSNUM "community".)  HWV258  04:13, 20 January 2009 (UTC)
      • No, I don't. This page (with all its dicta) has even less influence on readability than the differences in style and vocabulary which are inevitable in a jointly written project, and on which we have long since decided to live and let live. If switching between color and colour doesn't phaze me, none of this will. Septentrionalis PMAnderson 04:20, 20 January 2009 (UTC)
        • When you say "jointly written", are you refering to academic-type articles with less than a handful of authors? If so, do you see a difference when there are thousands of (non-academic-type) authors editing a WP article (over time)? Also if so, do you see a difference based on the target audience being very different for an academic journal versus a WP article?  HWV258  04:34, 20 January 2009 (UTC)
          • No, I mean Wikipedia, which is jointly written by nature. I have no idea, although there must be a study, how many academic papers have one of the joint authors as a drafting committee. Septentrionalis PMAnderson 04:38, 20 January 2009 (UTC)
            • I might have to get someone else to help me here as I can't follow the introduction of "nature" or "drafting committee" into the discussion. Is your previous point something you could reword to help me follow your meaning?  HWV258  04:47, 20 January 2009 (UTC)
              • Done, immediately below. Septentrionalis PMAnderson 06:22, 20 January 2009 (UTC)
      • This page is no service to communication with our readers whatsoever. Being inconsistent from page to page on the issues this page decides (such as date format, or whether to use seventeen or 17) is no impediment to our readers; varying between honor and honour would be a greater impediment, and we have decided to live with that. Septentrionalis PMAnderson 06:19, 20 January 2009 (UTC)
        • I was under the impression that things like honor and honour are consistent—in context with the underlying article's region. I have no problem with regional spellings as they make sense. On the other hand, it would be better to be consistent with "17" versus "seventeen". Not a biggy, but again, I feel you have failed to explain the over-riding problem. (And truth be told, I'm still not overly sure about how "nature" got into the discussion.)  HWV258  21:43, 20 January 2009 (UTC)
          • Many articles don't have an "underlying region"; they happen to be in British or American or Australian English. This is intentional, to permit anyone to edit, without prefering any of the national varieties of English.
          • Similarly, there are people who prefer 17 in spme given context; there are others who prefer seventeen. We should let them both edit, without putting them through the dozen bullet-points on this page, which are both arbitrary and incomplete. Septentrionalis PMAnderson 21:51, 20 January 2009 (UTC)
            • The point is that any one particular editor doesn't have worry about the "dozen bullet-points on this page" as someone else will fix syntax without injuring semantics. And as you've admitted that "17" and "seventeen" are both "good", the original editor shouldn't be dismayed to see the occasional change. Overwhelmingly, it is a system that works well.  HWV258  21:58, 20 January 2009 (UTC)
            • In which case the editors will find their prose tweaked by illiterates who know this page, but can't write English. Articles will be turned down at FA on the grounds that they don't comply with the rules here, even when they are wrong. This page is a source of power-gaming for the lazy, the semi-literate, the bigoted, and the editor who Knows the True System of Metric Prefixes (there are two True Systems; for the slambang between them, see any of the archives labelled B).
            • The alternative is to memorize the incomplete, inaccurate, and ill-phrased guidelines here, instead of trying to write English and be accurate, neutral, and verifiable.
            • In short, this page is a waste of electrons. Septentrionalis PMAnderson 22:10, 20 January 2009 (UTC)
              • You fail to see the bigger picture. The work of the "illiterates" will be addressed in due course. Plenty of articles get FA status, so MOS is not the issue. I keep stating it, but you just can't address the point: there is no need to even know about the existence of MOS to contribute to WP, as someone else will tidy up the syntax without damaging the semantics. The original editor should still be able to log-off tired, but happy after being edited. "In short, this page is a waste of electrons" is dismissive and disappointing, but I guess you are free to unwatch and simply walk away.  HWV258  23:30, 20 January 2009 (UTC)
                • At last, something I can agree with: there is no need to even know about the existence of MOS to contribute to WP. Indeed, WP would be better off without it, and without the incompetent, self-appointed, tidiers, following rules invented by prejudiced ignoramuses. If MOS would keep itself to its own fantasyland, and not impinge on the useful WP, I would indeed unwatch it; but it breaks out, every so often, and does lasting harm. Septentrionalis PMAnderson 23:51, 20 January 2009 (UTC)
                  • I'm no longer sure if you miss the point intentionally or accidentally (but I'll be patient and give you the benefit of the doubt). There is a point to MOS and it is possible to edit without referring to it (the fact you linked your two sentences with "Indeed" clearly indicates that you have not followed the argument). Perhaps at another time you'll be able to rationally address the points I've raised elsewhere on this page today. I hope so.  HWV258  00:10, 21 January 2009 (UTC)
                • Could there be a useful MoS? Of course there could.
                • Could some of this page be part of such a MoS? Yes; the admonition not to date war.
                • Is all of it? By no means. Much of it is not consensus; much of it is not English. Some that is both is nonetheless WP:CREEP. All this should be done away with, or at least not used to bother productive editors.
                • Is working on MOS productive? Only in the negative sense of deterring harm. Septentrionalis PMAnderson 22:14, 21 January 2009 (UTC)
                  • Well, have a go at improving it. Could you pick a small section of it and write the "useful MoS" version (on a temp page somewhere)? I'm not being facetious—I really would like to see what you have in mind. Cheers.  HWV258  22:33, 21 January 2009 (UTC)

Anderson, you can huff and puff, but you won't blow the house down. Too many people here recognise your agenda to considerably reduce the role of the style guidelines, especially their contents that you have decided to take personal objection to. I see that you've spread your campaign to the current ArbCom hate-page, now almost an encyclopedia itself, due in no small way to your input. I'm surprised that you haven't evolved to take on a more positive role here over the past few years; that option is still open to you. I note that your prose on the clause level has improved significantly, probably because of your contact with the guidelines themselves and the experts who contribute to the talk pages. Tony (talk) 13:28, 20 January 2009 (UTC)

No, Tony, only you claim to be able to read my mind. Then again, only you claim this page has <mystic>authority</mystic>. Why do you need it so much? Septentrionalis PMAnderson 19:58, 20 January 2009 (UTC)

Why have MOSNUM? Examine the alternative. Somebody adds "53 BC" to an article. Somebody else changes it to "53 BCE", claiming that "BC" is unduly religious and therefore unacceptable. The first editor disagrees arguing that his history book uses "BC" and therefore "BCE" is unacceptable. After the warring, wiser heads prevail and all agree that either is acceptable as long as the use is consistent throughout the article. Eventually that consensus is codified into MOSNUM. Now, those who wish to scrap MOSNUM are asking for that war/debate to be repeated on every article that contains a date before the year dot. Or asking everybody to read through the archives of talk pages to see if a local consensus was made. The same applies to every piece of collected consensus in every guideline. It would seem to me to be a very heavy price to pay, simply to allow a few editors to have the freedom to write "just as they see fit". Wikipedia is not an anarchy. --RexxS (talk) 20:16, 20 January 2009 (UTC)

That's the really useful part of MOS; the don't edit war over trivialities conduct guidelines. But that's one paragraph, at most; it doesn't need to be here; it could be boiled down and stuck next to WP:ENGVAR where it belongs. Septentrionalis PMAnderson 21:28, 20 January 2009 (UTC)

Yes (to RexxS). Hence the idea that the page provides a skeleton of consistency, upon which articles can be fleshed. Of course editors are free to ignore MOS, but they shouldn't be surprised to see their words subsequently made consistent with other pages (of course without changing the meaning of their writing). I fail to see why that disturbs you?  HWV258  21:43, 20 January 2009 (UTC)

A foolish consistency is the hobgoblin of little minds. Observe the contending SI and IEC rule-mongers above. Septentrionalis PMAnderson 21:58, 20 January 2009 (UTC)

You say it's "foolish", others say it isn't—I guess that's the end of the debating points then. Perhaps you could provide examples of the foolishness of "contending SI and IEC rule-mongers" (I'm keen to learn). "Rule-mongers" is such a pejorative perspective; is it impossible for you to take a step back and see the work of Tony (and a whole heap of others) as aiming towards improving WP? You surely can't rule that out; can you?  HWV258  22:18, 20 January 2009 (UTC)

No, I quoted Emerson; for instances of that foolishness, see #microns and micrometres above, and all the pages in the archive marked with a B, for Binary. Septentrionalis PMAnderson 22:24, 20 January 2009 (UTC)

I have no problem with people working out which of "microns" or "micrometres" is preferred. Doesn't change a single point I've raised above.  HWV258  22:49, 20 January 2009 (UTC)

Outside this page, however, we acknowledge that both words exist because they both have uses, and do not call on external style guides to decide for us. Septentrionalis PMAnderson 22:54, 20 January 2009 (UTC)

• I cannot rule out that Tony and his three or four friends intend to improve Wikipedia; that's what WP:AGF means. In practice, however, their efforts result either in a campaign for a New and Improved, politically correct, English, or in preferences for Tony's native dialect over others. When they fail to accomplish that, they resort to obscenity, abuse, and try to blackball editors out of this page, as here. Septentrionalis PMAnderson 22:29, 20 January 2009 (UTC)

• I fear you have taken a worse-case view. I'll let the four or five mentioned take over if they wish.  HWV258  22:49, 20 January 2009 (UTC)

• "Resort to obscenity"—Anderson, a good start would be if you could stop obsessing about my pooh at ArbCom. You appear to have led the writing of paragraphs about it. I wish you would desist now; it is offensive. Tony (talk) 10:30, 21 January 2009 (UTC)
  • You chose to write what I have quoted. If you find a certain blowback from that tactic, you may wish to consider others. You do courtesy rather well when you try; you can appeal successfully to reason and evidence. Do carry on. Septentrionalis PMAnderson 22:08, 21 January 2009 (UTC)

Bits - IEEE 1541 defines b as symbol not bit

• Wikipedia:Manual of Style (dates and numbers)#Units and symbols often written incorrectly: " By extension, the symbols for the units of data rate kilobit per second, megabit per second and so on are kbit/s (not kbps or Kbps), Mbit/s (not Mbps or mbps), etc. Similarly, kilobyte per second and megabyte per second are kB/s (not kBps or KBps) and MB/s (not Mbps or MBps). "
• This contradicts somehow Bit#Abbreviation and symbol: "IEEE 1541 a commonly-quoted relevant standard, specifies "b" to be the unit symbol for bit and "B" to be that for byte. This convention is also widely used in computing."

TechControl (talk) 15:36, 21 January 2009 (UTC)

Maybe somebody needs to tell Microsoft and the computer manufacturors then. If I click on my internet connection it tells me I am connected at 54.0 Mbps and if I download a file it reports the download speeds in the form of Kbps. All of the literatures that came with my PC and laptop also talk in these terms. So where does kbit/s and Mbit/s come from exactly? 21stCenturyGreenstuff (talk) 16:04, 21 January 2009 (UTC)

TechControl does not seem to understand the role of this guideline. It is not necessarily a compilation of how other publications handle style issues; it is a statement of the style choices made by the Wikipedia community. Since some standards use b as a symbol for bit, and other standards always spell out bit, this guideline has chosen to recommend that it always be spelled out. This is not incorrect; it is a choice. --Gerry Ashton (talk) 18:09, 21 January 2009 (UTC)

I am talking about relevant standards, not any arbitrary behind the moon hidden standard. If you have anything more relevant than IEEE 1541 I am happy to see you updating Bit#Abbreviation and symbol. TechControl (talk) 01:36, 22 January 2009 (UTC)

Thing is there are many standards out there. IEEE uses b, IEC uses bit. Confusion can arise when b is used, so the community decided to use bit all accross. So basically what Gerry Ashton said above. Same goes for Mbps vs Mbit/s. When the entire computer industry follows one standard instead of 20 at once, then the community will be more than happy to rank and file. In the meantime, it's a choice. Hennce B for byte, bit for bit. Headbomb {^ταλκ_{κοντριβς} – WP Physics} 05:42, 22 January 2009 (UTC)

I suspect that no active IEC standard defines bit. Which IEC standard do you refer to? TechControl (talk) 22:28, 22 January 2009 (UTC)

Fix/replace date autoformatting

Well, now that there's an injunction in place to put a hold on mass date delinking (or relinking), perhaps it's a good time to discuss how to fix Date Autoformatting (DA). Although I disagree, the majority (not consensus) view is that dates should not, in general, be linked. So, I suggest that we make that into a preference option that logged-in users can specify, and have the default (applied to both anons and logged-in users who haven't otherwise selected a preference) be for autoformatted dates to not be linked. The next most common complaint seems to be the inconsistency in date formats seen by anons (and editors who have selected the "No preference" preference). The simplest way to fix that would be to just use DMY as the default format, while still allowing logged-in users to set a preference if they choose. That way anons would see a consistent format (DMY) and anyone who prefers a different format can create an account, login, and set their own preference. These changes can be implemented very quickly if there's community agreement (and I'll gladly write the code and shepherd it through the approval process on bugzilla) and can certainly be done before ArbCom lifts their injunction. Once in place, all dates on the entire site will instantly be made consistent and de-linked (except dates that have already been delinked, which will need to be edited manually to fix any inconsistencies in format.. or just put back in square brackets to re-enable autoformatting sans-linking).

I'm sure there are a ton of additional features we'd like to see, but for the purpose of building consensus — which should always be thought of as the minimal set of criteria to which (almost) everybody can agree — I thought we should start simple. Most of the people here (and who have spoken up elsewhere) don't like dates being linked — and those that do (including me!) will probably be satisfied with a user-specific preference to turn linking back on. Similarly, most everyone agrees that everybody — including anons — should see a consistent date format. While it would be nice to custom-tailor that format to each target audience, we don't have any good way of doing that. Using the IP address or browser "locale" settings won't work because of the way Wikipedia's servers work (the squid cache issue) and trying to guess at the majority readership of an article based on the "strong national ties" exhibited by the subject of the article is both inefficient and prone to causing arguments (and in many cases simply doesn't apply).

Please keep this conversation on-topic and impersonal; There's no need for "so-and-so is just going to derail this anyway" or "this is pointless" as you can simply choose not to participate in the discussion if you feel that way. Since none of us are supposed to be linking or delinking dates anyway, there's no reason to feel pressured by either side, or to look at this call for discussion as an attempt at delaying tactics. --UC_Bill (talk) 00:29, 22 January 2009 (UTC)

This always did seem like the most reasonable way forward to me (it addresses the concerns of those who dislike the "sea of blue", as well as the objections of those who think date links devalue other links). Especially with regards to making date linking a preference in Special:Preferences. —Locke Cole • t • c 00:40, 22 January 2009 (UTC)

I oppose any form of date autoformatting. However, if it is implemented despite my opposition, I have two requirements and one wish:

• Requirement: The window in which users select the format either will not include the YYYY-MM-DD format, or will clearly state the format is NOT governed by ISO-8601
• Requirement: No style manual and no instructions for any template will state that any date visible to article readers is in the ISO 8601 format (exception: template fields that clearly are only useful for dates with years greater than 1928 [when Nationalist China adopted the Gregorian calendar])
• Wish: separate choices be available in the user preferences for dates appearing in articles and dates appearing in system messages, logs, watchlists, etc. --Gerry Ashton (talk) 00:49, 22 January 2009 (UTC)

There would need to be the ability to form a link, in specific cases, where a link to a specific date or year article is required. Keith D (talk) 01:13, 22 January 2009 (UTC)

This feature seems reasonable but I fear that scope creep may start to occur. Let's be on the look out for scope creep.

Flaviusvulso (talk) 02:03, 22 January 2009 (UTC)

Can you give an example of what you're asking for? —Locke Cole • t • c 02:07, 22 January 2009 (UTC)

Autoformatting never worked with links like [[January 1|January 1]]. Auto-unlinking would probably not work with such links, either, without more rewrite to Mediawiki than it's worth. If any form of auto-format or auto-unlink exists for wikilinked dates, piped dates will be likely to exist as a way to wikicode an exception. Gimmetrow 02:19, 22 January 2009 (UTC)

I endorse the suggestion of UC Bill. I was thinking about exactly the same approach/solution but did not voice but felt uncomfortable voicing this view due to the controversial nature of this debate. I also endorse the reasoning of Locke Cole. This approach is a win-win scenario for both sides of this debate.

Flaviusvulso (talk) 01:25, 22 January 2009 (UTC)

I would strongly endorse having such an option. It resolves the issues expressed by both sides, while allowing personal choice to be the deciding factor. --Ckatz^chat_spy 01:48, 22 January 2009 (UTC)

Comment: Any documentation or examples should explain what to do about BC or BCE. Also, if the YYYY-MM-DD format is offered, dates such as AD 0033-03-21 or 0005-01-13 BC are going to look rather strange (but I suppose people who choose that format can change their preference if they don't like it). --Gerry Ashton (talk) 02:44, 22 January 2009 (UTC)

Is there anyone that seriously prefers this date format? This format is typically only used in CISAM databases and the like to facilitate date sorting.

Flaviusvulso (talk) 03:11, 22 January 2009 (UTC)

I use that format, at least. I don't see that ISO 8601 is really a crucial issue here – exactly the same issue of calendar confusion appears in any date format (autoformatting is simply a rearrangement of what was typed, after all). — Carl (CBM · talk) 03:16, 22 January 2009 (UTC)

I agree. The date format options which are offered are low level requirements and can be determined later.

Flaviusvulso (talk) 03:24, 22 January 2009 (UTC)

CBM wrote "exactly the same issue of calendar confusion appears in any date format" which is false. Every ISO 8601 date is either in the Gregorian calendar or wrong. Of course, a Julian date could be written in the YYYY-MM-DD format, provided it is made clear that the ISO 8601 standard does not apply to the publication in which the date is written. --Gerry Ashton (talk) 03:33, 22 January 2009 (UTC)

Again this is a detail that can be hammered out later. First we need to determine if the consensus is to use autoformatting or not.

Flaviusvulso (talk) 03:51, 22 January 2009 (UTC)

People who knowingly claim to conform to a standard and do not do so are liars. Telling lies is not a minor detail that can be hammered out later. Of course, date autoformatting is currently depricated, and the question of whether ISO 8601 applies to dates in the YYYY-MM-DD format is in a state of confusion, so the English Wikipedia is not currently telling lies on this issue, but the danger of becomming a pack of liars is real. --Gerry Ashton (talk) 04:10, 22 January 2009 (UTC)

It's not really clear to me why a discussion about "Whether or not Wikipedia claims to follow ISO8601" is relevent here.Flaviusvulso (talk) 04:25, 22 January 2009 (UTC)

The ISO 8601 standard requires every date written in accordance with that standard to be in the Gregorian calendar. If the English Wikipedia were to indicate that dates autoformatted into a YYYY-MM-DD format conform to ISO 8601, then the English Wikipedia would also be claiming that all dates that are marked up for autoformatting are Gregorian calendar dates. If that were not in fact true, then we would be reckless, a pack of liars, or both. --Gerry Ashton (talk) 04:32, 22 January 2009 (UTC)

OK, so lets not claim iso8601 conformance. Would that be ok?Flaviusvulso (talk) 04:41, 22 January 2009 (UTC)

In the design process (such as it was) leading up to the existing form of date autoformatting (which I summarize at User:Gerry Ashton/History of ISO 8601 and date autoformatting in Wikipedia) it is clear that date autoformatting was intended to conform to ISO 8601 whenever dates were in the YYYY-MM-DD format. Also, the text used in the existing preference window to choose YYYY-MM-DD format ("2001-01-15T16:12:34") is unmistakably ISO 8601. Given this unfortunate history, it isn't enough to just not mention ISO 8601; it is necessary to actively disclaim conformance with it. --Gerry Ashton (talk) 04:55, 22 January 2009 (UTC)

• Gerry, your concerns are again, duly noted. I dont believe anyone disagrees with you. dm (talk) 04:50, 22 January 2009 (UTC)

1. DMY (if this means numeric) is ambigous. I have frequently seen extension writers on mediawiki.org writing things like 8/7/2005. Is this 8th July or 7th June? From edit history I often determined that it was US style. I know US people are often ignoring international standards, but maybe we can start making a CHANGE (yes we can) and do not allow this ambigous date format.
2. In tables or in other places where space is scarce I prefer YYYY-MM-DD, but in texts this maybe is not so good. If exact days get linked, the WP software should redirect /wiki/1999-08-07 to things like /wiki/June_7,_1999 or vice versa. Or a bot should create redirects. Really YYYY-MM-DD is very much more compact, it should be allowed in tables.
3. If linking is not generally allowed I support the idea of allowing this via preferences. Maybe it would be good to additonally allow some change in display for autolinked dates, so also users who have this preference=ON can see what the default is, without going to edit mode. TechControl (talk) 04:05, 22 January 2009 (UTC)

• Everyone involved wants to use spelled out months, no one disagrees with you. When creating dates with yyyy-mm-dd in tables, you should probably use {{dts}} or {{dts2}} to sort columns properly, but still create unlinked text strings. Check it out. dm (talk) 04:50, 22 January 2009 (UTC)

I'm opposed to anything that requires me to put dates in brackets. For a prolific writer, that is actually a pain. Even when date linking was encouraged, many new users didn't know that they were supposed to do so, leaving a lot of articles bare. Other new users (and many experienced ones) didn't understand how the date-linking was supposed to work, so we got a lot of January 30, 2007 and just plain 2005 because that is how those users thought it was supposed to work. Why confuse people unnecessarily? Just leave off the brackets so it is simpler for everyone. Karanacs (talk) 20:43, 22 January 2009 (UTC)

I think we tend towards using brackets because they're a simple syntax. Anything else we come up with will likely be some HTML/XML-like syntax like <date>January 30 2008</date> which is even harder to use when writing prose. Plus, in this proposal at least, there will be an option to link dates, so using the bracket syntax makes sense with that goal in mind. —Locke Cole • t • c 20:57, 22 January 2009 (UTC)

Karanacs, if using brackets is too bothersome or complicated for a user they don't need worry about it. They can write the dates in plain text. This is a wiki so either a human or a bot can correct the date at another time. Flaviusvulso (talk) 22:11, 22 January 2009 (UTC)

Bots can't fix dates because they can't tell if they are within a direct quotation, which should not be autoformatted. Until a human fixes it, the date will appear inconsistent with the rest of the article for some readers. --Gerry Ashton (talk) 22:18, 22 January 2009 (UTC)

Semi-automated scripts can fix dates though. And nothing on here will ever be perfect, but we can strive towards perfection.. —Locke Cole • t • c 23:52, 22 January 2009 (UTC)

I don't see why it is so important that dates in quotations not be autoformated. If it is really important then the date format can be overridden by using the pipe symbol. Flaviusvulso (talk) 23:52, 22 January 2009 (UTC)

It is always important that quotations be character for character exact; in a digital age, that's how they will be searched for. Septentrionalis PMAnderson 06:40, 23 January 2009 (UTC)

One problem with the existing date autoformatting syntax is that it provides no way to describe a date range. The proposed solution would lead to an anon/no-preference user (they're the same thing, under the proposal) seeing a sentence like "The election was 3 November 2008 and inauguration festivities occurred January 17-22, 2009." --Gerry Ashton (talk) 01:36, 23 January 2009 (UTC)

This is a very very good point - either the date autoformatting functions have to supply the ability to format a date range themselves, or (the better solution) provide as a template magic word/variable/whatever an indicator of what date format to use so that templates can then be used to figure out the right date format. Neither are easy. --MASEM 01:50, 23 January 2009 (UTC)

Date ranges are outside of the scope of this thread. We are only discussing how single dates are rendered. Flaviusvulso (talk) 02:00, 23 January 2009 (UTC)

I agree that single dates are the focus, but he makes a good point about the inconsistency in an article. —Locke Cole • t • c 02:07, 23 January 2009 (UTC)

I don't think this is an insurmountable problem, but I do agree it's likely this should be addressed first. See discussion below where I've mentioned your concerns to UC Bill. —Locke Cole • t • c 02:07, 23 January 2009 (UTC)

Date ranges should not be left out of the scope of the thread—this is one of the blunders made when the current system was put in place. Either propose something that will work or forget it. JIMp _talk·cont 10:24, 23 January 2009 (UTC)

Yes indeed, Jimp. You've emphasised just one of a number of complicated problems that would have to be sorted out if this solution chasing a non-problem were ever to see the light of day. Just one problem of the many that hung around Bugzilla for an extraordinary three years of circular discourse. No one has answered my basic question of why anyone would care about month-day or day-month order, when we're all perfectly used to both. Just a stony silence whenever I take the elephant in the room for a walk. Just on date ranges, en dashes are required, and they must be spaced or unspaced according to whether there are internal spaces within either one or both items. Minimal repetition is important, especially in infoboxes and tables, so we don't want "September 5 – September 8, 1991", or worse, the year twice as well. See the MilHist style guide for the info; it's so important for battles and the like, and I've cleaned up a lot of redundant date expressions in their articles.

So it gets back to: what is wrong with complete editor control over this by manual keying in? It's less work, and highly correctable in both edit and display modes. Why this insistence on a redundant toy that carries risk in so many respects, and is ... pardon me ... likely to make editing WP just a little more exclusive? Tony (talk) 11:08, 23 January 2009 (UTC)

I'll reiterate my opposition to date autoformatting. Furthermore, I don't think the wishes of those who do want it have been fully captured. Some people don't want to see any date links. Some want to see occasional, or rare, links to especially relevant dates. Some seem to want every date to be linked (it isn't clear if this group would want dates that are not to be autoformatted to always be linked, even if the date has no relevance to the article). So it is necessary to modify the user preferences; rather than having a yes/no choice, a choice of never/only identified dates/always is needed. And it is necessary to have four date syntaxes, which I will illustrate by example:

1. January 23, 2009: don't autoformat and don't link
2. [[January 23]], [[2009]]: autoformat and only link if the user chooses "always"
3. [[:January 23]], [[:2009]]: do not autoformat, and only link if the user chooses "only identified links" or "always"
4. New, undefined syntax: autoformat, and only link if the user chooses "only identified links" or "always".

--Gerry Ashton (talk) 15:05, 23 January 2009 (UTC) corrected 17:50 23 January 2009 UT.

I'm not sure about the third option (do not autoformat, link if "only identified links" selected) because there's a question as to whether user preference or editor intention should take priority. I usually favor user (i.e. reader) preferences in which case we'd need to consider whether to ever allow editors to force a link. A similar situation applies to the "undefined syntax" example, for which I'd suggest something like what Sapphic describes below, using [[January 23|link]], [[2009|link]] to indicate that both the month-day and year are "identified" links that should be autoformatted, or [[January 23|link]], [[2009]] to "identify" just the month-day (and similarly for year). I'm certainly not opposed to having three different date linking options in user preferences, but I'm wondering if it's actually necessary. --UC_Bill (talk) 17:06, 23 January 2009 (UTC)

Why the fixation with month-day or day-month?

Whenever I ask this question, no one addresses it. Do we really think our readers and editors are so inflexible (or moronic) that it matters? Why is that people want to go to such extraordinary lengths to fix something that is not a problem in the first place. The primary purpose of the silly date-autoformatting that was so unwisely adopted by us Internet innocents back in 2003 was to "prevent edit-warring over which date format would be used in an article". We have grown up since then, having developed very workable, well-accepted systems for ENGVAR (article-consistent) and article date-format choice (also article-consistent). There were a few little scraps involving User Pete a while ago over the latter (apparently no longer an issue), but generally speaking, what I see is remarkably little debate over which format to use in which article, let alone tension. The edit-warring thing is a complete non-issue, and WPians seem to accept without a blink the absence of a hi-tech toy to mess with the order of month/day; I note that there's still a residual group of computer programmers that cannot bear to see the demise of a programming toy. Sorry, we don't need it, it's not a problem, thanks. Nor do we need autoformatting for colour/or, traveling/lling et al. English-speakers on the Internet find it all rather easy to read these minor, easily recognisable differences.

I can think of a LOT of better things to do with our time; like helping out at WikiProject Years to bring our year-articles out of the doldrums. Tony (talk) 11:09, 22 January 2009 (UTC)

• • I must whole-heartedly concur. We have a behavioral solution in the manner of WP:ENGVAR close at hand. It works; let us employ it. Septentrionalis PMAnderson 06:29, 23 January 2009 (UTC)

Isn't it the case that, because of delinking, various discussions have started about which format to use for articles related to various nationalities? I remember seeing a thread about it on the mailing list. If my memory is correct here, the edit warring thing does seem like a renewed issue.

My personal opinion: if everyone will accept "just leave the format like you found it" then there's no need for autoformatting. But if more than an insignificant number of people insist that broad classes of articles need to be standardized on one format or another, then we should just use autoformatting (which as the advantage that it guarantees standardization and minimizes time wasted on dicussion of which format is appropriate). — Carl (CBM · talk) 14:13, 22 January 2009 (UTC)

Given that there's an insistence to format dates on a page per the page's implied nationality tells me that the date order is important to enough to be an issue, otherwise we'd either be saying "format consistently as you like it" or "format all dates per the One Unified Format", which is clearly not the case. Yes, that means at the same time, we should be asking ourselves why we aren't concerning ourselves with "color/colour" variations of English, because it is pretty much exactly the same thing - we've made it a MOS point to determine a nationality of a page's topic and told people to format to that, which of course leads to edit wars of how that nationality is determined or even once it is, one person feeling it should be the other way. --MASEM 14:24, 22 January 2009 (UTC)

Masem—our readers seem not to care. Anyone who consults the Internet encounters the binary system of spelling, and most are probably not even aware of it (we are here, because we specialise in such matters). The same for date formats: most countries have both in various places; I see no civil unrest throughout the anglophone readership of the Internet on either spelling or date-format issues, do you?

CBM—I think the "leave as you find it" is the basic idea that editors who audit dates have been using; who wants trouble over that? However, it is established (at MOSNUM for some time) that articles related to the UK, Ireland, South Africa, Australia and New Zealand should use international formatting. I've not encountered a single complaint about this when I've changed formats with Lightmouse's excellent script, nor on the rare occasions I've had to change international to US format in US-related articles (there have been a few no-brainers, such as NASA and one of the September 11 group). The only complaints arose from the few occasions when I hit the wrong one by mistake—perhaps three or four times out of thousands—for which I was very apologetic when a grumpy complaint would appear on my talk page.

The situation for articles related to Canada, India and a few other countries is interesting and has sometimes required me to stop and examine the pre-diff carefully, sometimes reversing my initial choice. Frankly, Canada seems almost entirely US format, with just a few exceptions (Canada Post, I think, and a few bios). I'd say more than 95% are US; I wouldn't dare change one, and Canada is officially either at WP. India is more US than international, but more more equal than Canada—at a rough guess, two-thirds/one-third. I don't change them. East Asia is almost entirely US. etc. etc.

As long as US editors want to use US formatting in articles they start or started on non-country-related topics, that's fine by me; I disagree with any attempt to force one system on all, unless there's consensus to do so. Personally, I believe it would save a lot of trouble if all were international (and metric units, too), but that's up to consensus, and way down my list of concerns. BTW, if US military articles use international, I leave as is—fine.

A bigger issue is the more-than-half of articles (before date-auditing began—less now) with messy inconsistencies in the body of the text. Unless the article concerns one of the native anglophone countries outside North America, I do a quick survey of the proportions and go with the bigger one. Only very occasionally is it a hard call, and these are not articles where editors hold strong views, in my experience.

AWBs do not change raw formats; only scripts are capable of this. Since I'm a Mac user, I have no access to AWBs (a source of irritation), so I've concentrated on cleaning up the formats rather than merely removing DA and other clean-ups with the date-format inconsistencies untouched. However, we need AWBs to spare editors of the massive job of complying with WP's guidelines.

I think editors who date audit generally learn to do something similar to the method I've outlined above. It's a minimal-upset practice, and if not, we should be concerned about the editor.

I hope that any tension among local editors is brought to the attention of the experts on this page. It has occasionally happened. Does this answer your concerns? Tony (talk) 14:41, 22 January 2009 (UTC)

Sure, readers may not care, but the fact that this (the specific issue of deciding what date format to use on a page, not DAing) remains contentious among editors means that editors care about it - and by design would be the ones that benefit from a DA system. Yes, it seems like such a trivial issue, but that still doesn't explain why the guideline that states how to select the approach format exists - it seems to be an concession to acknowledges editors have preferred formats they like to see dates in and thus by setting the guideline, it attempts to minimize edit wars over them. The only ways to completely minimize those edit wars is to either require all dates in One Format or to allow editors to have dates displayed in the way they prefer regardless of how they are written. Or we have to acknowledge that editors will editwar over date style of articles of questionable nationality, and live with that. --MASEM 15:04, 22 January 2009 (UTC)

Methinks that it's only policy and guideline wonks who care about it (it's our job, I guess), and that the rest of humanity couldn't give a dump. I think the guidelines seem to be reasonable, I see no edit-wars on format, and would you like to join my WikiProject Years project to concentrate on two specific historical windows in fixing up year articles? We need all hands we can get. Tony (talk) 15:47, 22 January 2009 (UTC)

I'm just pointing what the case is, and as long as we accept that there will be some edit warring on a small scale with the current advice of presuming a date format based on national interest, it should be fine; I'd personally like to see DA (not just for formatting but there's also semantic data to consider) but can tell now's not the time to push for it. and what are you looking for on the WP Years? --MASEM 16:12, 22 January 2009 (UTC)

Um ... where is the evidence of this "edit warring on a small scale", continual, I presume. I hope that this isn't being blown out of proportion to support the introduction of a programmers' toy? Tony (talk) 06:01, 23 January 2009 (UTC)

Tony the sooner you stop disparaging what the community supported by a majority at the RFC as a "programmers' toy", the better off our discussions will be. There's support for this, why not cooperate here and help us find potential issues we should address prior to trying to get this implemented? —Locke Cole • t • c 06:05, 23 January 2009 (UTC)

Mirror. "Disparaging" is your spin-word. The only thing I disparage are claims that the RfC data you are trumpeting are meaningful. Tony (talk) 06:08, 23 January 2009 (UTC)

Enough Tony. You talk of reducing tensions then you proceed to make statements like this (attacking what I've said as "spin", and disregarding the RFC results as not being meaningful). I'll ask again: please stop with this distortion of the results and participate in a helpful manner with the work being done here. —Locke Cole • t • c 06:32, 23 January 2009 (UTC)

I will not reciprocate the bolded "shouting", nor the blunt order that you issue. Nor the spin you use in framing my objection to your line as "an attack"; that word, and "incivility", are being used for political purposes at Arbcom, and now here, in an attempt to censor any resistance to your agenda. Tony (talk) 11:29, 23 January 2009 (UTC)

I prefer to see date formats that harmonize with the rest of the text. "Colour" goes with 5 November 1605, "color" goes with July 4, 1776, and "nuclear submarine" goes with 30 September 1954. --Gerry Ashton (talk) 16:19, 22 January 2009 (UTC)

Nice, here comes Tony with the typical "who cares" / "waste of time" argument. Please stop derailing the threads like this, it isn't helpful. As the RFC made clear there's a majority in favor of some type of auto formatting, so this question seems to be purely rhetorical and the answers useless. It doesn't matter if you feel it's a worthy cause, the community already seems to think it is. —Locke Cole • t • c 20:33, 22 January 2009 (UTC)

Oh, you mean that RfC that you designed to get the result you wanted? The one that funnelled people into the "some" category? See my examination of that. Tony (talk) 06:03, 23 January 2009 (UTC)

I did not design the RFC alone Tony, you (and others) participated and Masem was the overall architect of the questions. Further, attempting to distort the results with your (biased) analysis is not helpful here. Please stop and instead engage in helpful dialog so we can move forward with something that's agreeable to everyone. —Locke Cole • t • c 06:32, 23 January 2009 (UTC)

As I pointed out in the analyses of those RfCs, it's not a blame-game; such distortions may well have been introduced inadvertently, not wilfully, by the authors. It is irrelevant whether you yourself constructed the RfCs or a number of people. There is no need for defensiveness; we simply need to look at these data in the daylight, dispassionately and scientifically. I'm sorry if the results are not to your liking, but the methodology of the analyses is open for all to see. Because of them, the unfortunate skewing of the data is there for all to see. Tony (talk) 11:25, 23 January 2009 (UTC)

• Indeed Tony, why the fixation? Keep it simple. And I certainly wouldn’t try to intertwine date formatting to the dialect of English some volunteer editor used for an article; that is a separate matter. I would propose we simply make the date format as natural as possible for the likely readership. Nothing more.

  Articles not closely associated with American topics such as Italy, Austria, Basilica di Saccargia and Kilogram have a pronounced non-American readership. Regardless of the dialect of English used by the editor of that article, we should be thinking foremost about our readers. So in articles on general or European subjects (articles clearly not associated with the U.S.), we would simply use Euro-style dates.

  Conversely, for articles on, or closely associated with American topics, such as Spokane River Centennial Trail; Coeur d'Alene, Idaho; American Revolution; and New York Yankees, they have a preponderance of American readers and the date format that is most natural for those readers is the American-style date.

  It is an utterly trivial matter to simply use the date format that is most natural for the likely readership. I would propose this simple guideline:

For articles on, or strongly associated with, the following countries and territories: The United States, American Samoa, Guam, Northern Mariana Islands, Puerto Rico, U.S. Virgin Islands, Wake Island, Republic of the Marshall Islands, Federated States of Micronesia, and Republic of Palau; editors should use the U.S.-style date format (“February 2, 2008”), otherwise, editors should use the international date format (“2 February 2008”) in articles.

Greg L (talk) 20:29, 22 January 2009 (UTC)

• Because the community has told us they want a date auto formatting system, and it makes much more sense to fix it than to actively work to go against what the community has told us. —Locke Cole • t • c 20:33, 22 January 2009 (UTC)

• I don't see a broad consensus to have date autoformatting. Just barely over half of people think we ought to have it, and almost half think we should not. That seems a bit more muddled than a clear consensus ought to be. Karanacs (talk) 21:10, 22 January 2009 (UTC)

• You're right, it's at best a majority. But if this settles the issue for everyone (and it would seem to) I don't see why we shouldn't pursue it. —Locke Cole • t • c 21:17, 22 January 2009 (UTC)

• No, it was small minority who said yes. The structure and language of the RfC distorted the result significantly, as I've pointed out in a detailed analysis. Claims based on highly contaminated data should be dismissed. Tony (talk) 06:06, 23 January 2009 (UTC)

• No, it was a small majority, if anything. I will not participate in your attempts to discredit an RFC which you only took issue with after it closed, over a month later. You made no objection during the RFC to the language used. Please stop trying to undermine the progress made with these accusations of distortion. —Locke Cole • t • c 06:35, 23 January 2009 (UTC)

• Actually, reading through a lot of the oppose comments, this proposal does not appear to settle the issue. Many of the opposes thought that date autoformatting was a solution looking for a problem; the opposes were not based on whether or not the dates were linked. Karanacs (talk) 22:08, 22 January 2009 (UTC)

• And those can be discounted because the majority supported some form of auto formatting. Those who don't want it can turn it off. The same can not be said of those who do want it (we can't simply "turn it on", it doesn't exist yet). —Locke Cole • t • c 22:22, 22 January 2009 (UTC)

• Well, so you continue to assert, but on the basis of a highly skewed RfC. Sorry, it cannot be twisted into your purpose here. "Majority" saying what? That is the question; the answer is what you want, in retrospect, to claim. Not buying that one. Tony (talk) 06:11, 23 January 2009 (UTC)

• The questions were simply laid out: a majority voiced opinions support "some form of auto formatting". —Locke Cole • t • c 06:35, 23 January 2009 (UTC)

• Tony, continuous attempts to disparage the results of the detailed RfC will not validate your claims. It is interesting to note that virtually every statement you make about Masem's RfC attempts to question its basic validity, replete with constant insinuations of foul play and hidden motives. At the same time, you insist that the RfC you created unilaterally is intrinsically valid - and that any results differing from your desired outcome are the result of some supposed "contamination" from outside influences. Furthermore, all the rhetoric about "programmer's toys" is just a attempt at diversion. Plain and simply, autoformatting dates is a matter of providing options to the user for customizing the project's interface. This is no different than being able to customize an operating system, a cellphone, or any other such item. You are more than welcome to format and present your own display in any manner you see fit - but there is no reason at all to deny others the right to do the same in their own preferred manner. --Ckatz^chat_spy 06:46, 23 January 2009 (UTC)

• CKatz, the results of the analyses I conducted on the RfCs do not need validation by continual attempts by anyone to disparage anything. They stand per se, open to critical comment. I see little or none, which suggests that the analysis has stood the test. Please do not be upset by someone's willing to expose the RfCs themselves to critical scrutiny: they have a wider message, by the way, in that we need to approach the design and language of RfCs, particularly complicated ones, with NPOV care. These ones were prepared in a rush. Neither should you be shifting blame onto me for the rush; the drafts appeared to be going nowhere when I decided to create simple, binary RfCs which I believed (rightly, it turns out) to be likely to produce meaningful results. Tony (talk) 11:25, 23 January 2009 (UTC)

• Greg, your proposal has two disadvantages:

1. It does not allow for year linking based on user choice.

2. I'm an Australian. When I read an article associated with the USA I do not want to see dates in US-style format, I want to see them in the format I choose. Your suggestion presupposes that the readership of articles associated with the USA predominately prefers MDY dates. I think this assumption is questionable. A wikipedia reader should see dates in a consistent format in all articles unless there is a very good reason such as an article which discusses different date formats. Flaviusvulso (talk) 00:14, 23 January 2009 (UTC)

If you read articles associated with the USA you will see color, honor, gotten, defense. Do you propose changing our language encouraging this? If not, why is "July 4, 1776" worse? Septentrionalis PMAnderson 17:20, 23 January 2009 (UTC)

• More seriously, GregL's proposal, and several others, were discussed ad nauseam a few months ago. See archives D8 through D11, which contain the results; wide publicity was sought, and many editors weighed in. There was no consensus on anything, but his proposal came in last; it relies on the unevidenced and unlikely assumption that readers of an article on the history of complex numbers, or the philosophy of time, are overwhelmingly in favor of 23 January 2008. There is no reason to believe this, no evidence for it, and it violates WP:ENGVAR, the only unquestionably useful contribution MOS has made to the encyclopedia. Septentrionalis PMAnderson 06:49, 23 January 2009 (UTC)

Picked up an Australian newspaper lately? Tony (talk) 06:12, 23 January 2009 (UTC)

I agree that "strong national ties" based on subject matter is a poor way of guessing at what format readers want, but unfortunately it's the best option we have. The Wikipedia servers are configured in such a way that all anon users will see the same content on any given page, which means that we can't do something fancy like use the IP address or the extra information sent along by browsers about language preferences. It's possible to use Javascript to reformat dates on the client side of things, but that's beyond the scope of the software changes we're discussing.

The demo site (linked below) currently displays autoformatted dates in DMY format for all anon users (and "no preference" logged-in users) and I'm working on adding some "magic word" functionality so that a default date format can be specified on a page-by-page basis in a way similar to how {{DEFAULTSORT}} works for categories.

I think that we'll need to resort to the "strong national ties" method for determining the best format to use for anons, and everyone else who wants to see a different format than that will need to login and set a preference. If you can think of a better way, please share it. --UC_Bill (talk) 00:36, 23 January 2009 (UTC)

Perhaps if piped dates are unlinked then that can be used as a way of overrriding date formats for anons. The colon could still be used to render links. Flaviusvulso (talk) 00:59, 23 January 2009 (UTC)

Broken reference

Someone with edit privs: MOS:UNLINKDATES refers to this page via WP:CONTEXT#Dates; the sub-reference has apparently has been renamed over there, to WP:CONTEXT#Chronological_items. Studerby (talk) 21:53, 22 January 2009 (UTC)

Done, thanks for noticing. Karanacs (talk) 22:04, 22 January 2009 (UTC)

Date autoformatting example ready for testing

I have finished a demo version of the new Date Autoformatting code, and made it available for public viewing here:

• http://gdnet-demo.berkeley.edu/testwiki/index.php/Main_Page

IMPORTANT NOTE REGARDING PRIVACY: I have access to the server logs on the above server, which means that (in theory) I can find out the IP address used to access that website. If you create an account on that wiki for testing (which is encouraged) you should NOT use any personally identifying information such as your real name or your Wikipedia username. Also feel free to connect through whatever proxy you like, to further protect your own identity.

The main page of that demo wiki contains examples in all the major date formats. While viewing the page as an anon user, you will note that all of the links in the first section are in a consistent format (DMY with the month spelled out — so-called "International" format) and are not linked. If you create an account and set your "Date and time" preferences you will notice an option for "Date linking" that can be set to "Do not link dates" (the default) or "Link dates" at your choice. I've tested each combination of date format and linking option myself (and haven't noticed any problems) but I'm only human so please check for any mistakes I may have missed. Additional comments are welcome.

Note that I have not (yet) put any disclaimers regarding ISO formatting, nor have I made a separate set of options for in-article dates versus mediawiki dates (i.e. page last updated, etc.) because although those may be desirable features, they introduce more complications than I'd like to deal with in this first round. The separate preferences in particular may prove problematic, since those are actually implemented by two different PHP functions within the code. That said, I recognize the value of those suggestions and will gladly work to incorporate them at a later date.

I'm not sure how long I'll be keeping the demo site active, since I'll eventually need to take it down once I need that server for some projects related to my actual job :) --UC_Bill (talk) 23:38, 22 January 2009 (UTC)

Excellent work. =) The only thing we need at this point is a way to set the date format seen by anons on a per article basis (a magic word like __FORMAT_DATES_MDY__ and __FORMAT_DATES_DMY__). That should be enough to take this live. Later we can add an option in preferences to link or not link dates. —Locke Cole • t • c 23:50, 22 January 2009 (UTC)

Sorry I wasn't clear.. the option to link or not link dates is already in there. It was the ability to have a different format preference for in-article dates vs. mediawiki dates that I left out. I'll look into the magic word thing, but I haven't ever messed with that part of the software before so I don't know how long it'll take. Hopefully it'll be easy.. I'll get back to you on that later. --UC_Bill (talk) 23:54, 22 January 2009 (UTC)

Very nice. I totally missed that too. =) —Locke Cole • t • c 00:44, 23 January 2009 (UTC)

I'm actively working on the site, so if it's broken try back later. --UC_Bill (talk) 00:16, 23 January 2009 (UTC)

I'm going to work on a duplicate copy of the code, so that I won't break the demo site while I'm working. Apologies to anyone who visited the site while it was broken. --UC_Bill (talk) 00:24, 23 January 2009 (UTC)

Looks good. I think this approach represents a win-win scenario. Those that don't want to see a "sea of blue" don't have to. If you want date linking you can have that to. In theory a virtually unlimited array or date formats could be provided for. Anons by default will not get date linking. I see many advantages to this approach and few if any disadvantages. Flaviusvulso (talk) 00:39, 23 January 2009 (UTC)

I've added support for a new magic word that allows you to specify a default format on a particular page. For example, you can make a page use MDY format instead of the default DMY by adding this: {{DATEFORMAT:MDY}}

I'm through editing the site for the day, so there won't be any additional changes. Feel free to play around on the demo site and try to break things, and please share any feedback you have here (not on the demo wiki.. it'll be erased once testing is done.) --UC_Bill (talk) 01:24, 23 January 2009 (UTC)

Great. =) Gerry Ashton (above) made note of one challenge that should probably be addressed: date ranges. I'm of the mind that this shouldn't be that hard especially for day ranges ([[January 17-22]], [[2008]]; it should be simple enough to look for the dash), but it's something we should consider before seeing about getting this added. —Locke Cole • t • c 02:02, 23 January 2009 (UTC)

As somebody who regularly processes wikitext to extract metadata, I can totally agree that date ranges are an issue. Consistency would be nice, and if autoformatting can be made to help out there, then that's a big improvement over the current system. We'd need to build a pretty comprehensive list of valid formats that should be recognized. I'll start:

• [[January 17-22]], [[2008]] — valid (Locke Cole's example from above)
• [[January 17 - 22]], [[2008]] — valid?
• [[January 17 &mdash; 22]], [[2008]] — valid?
• [[January 17&mdash;22]], [[2008]] —
• [[January 17]]-[[22]], [[2008]] —
• [[January 17]]&mdash;[[22]], [[2008]] —
• [[January 17]] &mdash; [[22]], [[2008]] —
• plus the obvious counterparts for DMY format.

What about numeric YYYY-MM-DD format? What about ranges that span more than one month, or more than one year? I can try to find that out from some analysis of the xml dumpfiles, but we can probably come up with a pretty good list ourselves before I'll have a chance to do that (the analysis takes a while to run over the entire database, so test iterations take a long time.) --Sapphic (talk) 02:36, 23 January 2009 (UTC)

I think you mean "–", not "—" (Not very relevant I know, but I mention it anyway). Dabomb87 (talk) 04:35, 23 January 2009 (UTC)

Oh I think it's totally relevant, since it expands the number of possible formats. I bet at least some people make the same mistake I did, so we need to take it into consideration whether we fix it or treat it as a supported format. Thanks for the catch. --Sapphic (talk) 04:50, 23 January 2009 (UTC)

I see a bit of scope creep starting to occur here. Let's get date autoformating made part of the MOS and worry about date ranges later. Until then date ranges can be expressed as "from 17 January 2008 until 23 January 2008" Flaviusvulso (talk) 02:45, 23 January 2009 (UTC)

I was going to say that we shouldn't lose features either, but it seems the current date autoformatting doesn't deal with date ranges correctly either. See: Wikipedia:Date_formattings#Date_ranges

Still.. I know where UC Bill's office is and can bribe him with a delicious sandwich tomorrow to get him to do my bidding, whereas you can probably not. We'll see if he can get it into the demo code before he submits it, or if it'll have to wait for a future iteration. --Sapphic (talk) 03:00, 23 January 2009 (UTC)

Let the bribing begin. =) —Locke Cole • t • c 03:07, 23 January 2009 (UTC)

Yes I can see how this would be a problem. Perhaps writing date ranges like 21-22 June, 2008 should be discouraged since is presupposes all readers view dates in dmy format. Flaviusvulso (talk) 03:47, 23 January 2009 (UTC)

Looks like a fairly complete list of formats we should support, especially the first four. —Locke Cole • t • c 03:07, 23 January 2009 (UTC)

The decision to force everyone to see autoformatting raises the bar. EVERYONE, even those who select "no preference", are force-fed autoformatted dates. Therefore, the autoformatting system must be equal to or better than a well-written article without autoformatting from the very first minute (leaving aside those of us who want to see different formats in different kinds of articles). You would no longer have the excuse that "if you don't like it, you can just turn it off". A system that forces inconsistencies where none existed without autoformatting is a non-starter. A system that forces editors to adjust their writing styles to accommodate limitations in the autoformatting mechanism, such as avoiding date ranges, is also a non-starter. --Gerry Ashton (talk) 03:13, 23 January 2009 (UTC)

Actually, it's "if you want to specify your own date format (which might break date ranges) you can re-enable it" but I do agree with your point about the new autoformatting system being equal to or better than the old one. Whether date ranges get added now or later, what's currently available on UC Bill's demo site is still a huge improvement over what's on the English Wikipedia right now, and it doesn't break anything that's not already broken. After I get a chance to produce some data on what various date range formats are actually in use in articles, we can figure out which ones we should consider valid (maybe based on popularity as well as readability?) and fix the rest. If UC Bill (or somebody else) hasn't already fixed date range autoformatting by then, it should be even easier with some actual parameters to work with. --Sapphic (talk) 03:29, 23 January 2009 (UTC)

(Outdent) I'm sorry Gerry, I misunderstood your point. Different date ranges would be broken with the new DA. But perhaps more importantly, articles that currently have linked dates like [[September 11]], [[2001]] with a clear US emphasis would suddenly appear as 11 September 2001 — which is good in that it gets rid of the bluelink (although in this case I guess the date probably should be linked.. bad example, but you get the idea) but is probably not in the preferred format. On the plus side, the new DA would mean you just add {{DATEFORMAT:MDY}} to the page and all the autoformatted dates would switch to the correct format. But somebody would still need to add it, and until then the format would be "wrong" for anons and "no preference" people. --Sapphic (talk) 03:52, 23 January 2009 (UTC)

Sapphic's writing assumes features that have only been mentioned in the discussion; they have not even been agreed to among those who support the proposal, never mind implemented in the demo. In the absence of an ability to handle date ranges, it is impossible to write a page that will look consistent to everyone, and no choice on the part of the reader can fix it for all the pages a reader might want to read. --Gerry Ashton (talk) 04:21, 23 January 2009 (UTC)

No, I'm describing the demo system for the new DA exactly as it is. It already has support for the {{DATEFORMAT:MDY}} magic word. It deals with date ranges exactly the same way as the current system — badly. The problem is that there are articles where the "correct" formatting depends on the inconsistencies caused by the current DA. So the new DA (by fixing the inconsistencies) would actually put all the dates into the "wrong" (but consistent and not linked) format. It's the same deal with date ranges, although until we have some actual statistics it's a toss-up whether there are more date ranges that will be fixed by being put into DMY format or more that will be broken. They're all "supposed" to be in the longer format that would prevent formatting problems in either the old or the new DA, so it's a question of which mistake is more common and more work to fix. While they're being fixed, we can just add {{DATEFORMAT:MDY}} to the pages that need it, and they'll never break again. --Sapphic (talk) 04:33, 23 January 2009 (UTC)

I don't know that September 11, 2001 would be the best link—the article on the actualy attacks seem more relevant to me (I assume that is what you were referring to). Also, in 99 out of 100 cases, I could care less, but this is one of those cases where I would rather see a date in a specific format: September 11, 2001. It just seems more natural in this case. If a new system of autoformatting is implemented, will there be a way to force a date format in some cases (the prime example being quotes)? If this has already been discussed (I haven't read the entire thread in detail), disregard that question but I was just wondering. Dabomb87 (talk) 04:41, 23 January 2009 (UTC)

It's mentioned above, but it's short so I'll repeat: piped links ([[September 11|September 11]], [[2001]]) and prefixed links ([[:September 11]], [[2001]]) will work like they always have, i.e. without any autoformatting. --Sapphic (talk) 04:46, 23 January 2009 (UTC)

There is no consensus to eliminate date linking entirely. Some editors link dates they think are especially relevant to the article. If the proposed system is adopted, the editor will have the choice of linking it with pipes or a prefix, which will bring it to everyone's attention, but defeat autoformatting, or use regular autoformatting. If the editor does use regular autoformatting, it will not come to anyone's attention; IP users and those with date linking turned off won't see the link at all, and those who chose date autoformatting linking won't be able to distinguish the relevant date from the irrelevant date, because they will all be linked. So the net effect would be that either editors can't actively recommend date articles, or they have to make the linked dates look inconsistent for some readers. Since some editors will no doubt choose to use the piped or prefixed links, all readers will experience some inconsistency within articles, because some of the piped/prefixed links will be day-first and others will be month-first.

A few dates have a unique idiomatic format, like September 11, 2001, and people would expect the inconsistency, but that isn't true for most dates.

I'm seeing a process developing here, which probably isn't intentional on the part of the proposal's advocates, which could come to pass anyway. First, an autoformatting system gets adopted that does not provide the same degree of consistency that can be achieved in an article written with no autoformatting. Since it works better for the day-first format, gradually pressure develops to write all articles in the day-first format. Once that is achieved, somebody says, "well, since the English Wikipedia looks best in the day-first format, and that's how all the articles are written in the source text, let's just eliminate autoformatting". --Gerry Ashton (talk) 05:11, 23 January 2009 (UTC) corrected 14:48, 23 January 2009 (UTC).

• I agree with Gerry's sentiment. I can also sniff trouble among US editors who may be offended by the new bias. We don't want to offend people. BTW, if anyone is feeling led to believe that the entanglement of the old DA system with the linking system was the only problem, tell me and I'll link you to several pages, by me and other editors, explaining at least six significant problems, only one of which is the blue-wash. Tony (talk) 11:34, 23 January 2009 (UTC)

Tony, overcoming the "bias" is as simple as adding {{DATEFORMAT:MDY}} to any page that needs it. Gerry raises a valid point though, with regards to the editors having no way to have both forced-linking and autoformatting at the same time. (Of course the current DA only "allows" this because it forces all marked-up dates to be linked, but still..) This could be fixed by modifying the date markup syntax slightly, by either making it more similar to either category syntax or image syntax. Image syntax would probably be easier to remember, since it's wordier. For example, image syntax is [[Image:Kentikian-hokmi.png|thumb|Kentikian (right) in her rematch with Nadia Hokmi, December 2007]] (note the "thumb") and the equivalent syntax for a date in the new DA could be [[September 11|link]], [[2001]]. This would take away the ability of editors to have a link to a date with the link text of "link" but that's an utterly trivial restriction and is similar to the inability of editors to have an image with a caption of "thumb" as is currently the case. So in that example, the link would be both autoformatted and linked for everyone, and it uses a syntax that people are already familiar with for images. --Sapphic (talk) 15:36, 23 January 2009 (UTC)

Thank you for your response. My mantra I'm sure you're sick of, but my basic question remains unanswered. Tony (talk) 15:47, 23 January 2009 (UTC)

This doesn't work. The standard American sentence

On September 10, 2001, New York was at peace; September 11, 2001, wreaked massive destruction.

translates into British (and Australian)

On 10 September 2001, New York was at peace; 11 September 2001 wreaked massive destruction.

and the other way around.

Note the comma which appears and disappears before wreaked, (but remains in both sentences before New York). The autoformatter does not handle this correctly or tolerably in either direction. I think this is an irremediable defect, since avoiding it would require the autoformatter to parse the sentence. Septentrionalis PMAnderson 16:26, 23 January 2009 (UTC)

I don't follow your example. The first sentence (American version) is wrong. There shouldn't be a comma before "wreaked" in either sentence. The issue around commas is that they're optional in British/Australian English for clauses like "On 10 September 2001" but required in American English. The simple fix is to use them even when they're optional. Alternately, the DA code could be modified to treat a comma inside the square brackets as an "optional" comma, and to only display it when using MDY format. So, the sentence would be:

• On [[September 10]], [[2001,]] New York was at peace.

This would be rendered as "On September 10, 2001, New York was at peace." for people who select the MDY preference, and "On 10 September 2001 New York was at peace." for anons/no-preference/DMY people. I think it's simpler to just have the comma in both cases though, since it's perfectly good English in all varieties. --UC_Bill (talk) 16:46, 23 January 2009 (UTC)

Very well, then commas are variable (in one variety of English) in both clauses; the assertion that September 11, 2001, wreaked massive destruction. is not sound American is nonsense. (I would not omit it after s long a phrase as On 10 September 2001 myself, but tastes differ.) This means many editors will, in all good faith, write the form one language permits and the other doesn't — often in a legitimate search for clarity or euphony. Are we going to blue-pencil them so that this gimmick can work? Please no.

In short, very strongly oppose. Septentrionalis PMAnderson 17:14, 23 January 2009 (UTC)

September 11, 2001, wreaked massive destruction is not sound American English. A comma only follows a date if it's part of a subordinate clause, as in On September 11, 2001, massive destruction was wreaked. In other varieties of English, the comma following the subordinate clause is optional if the clause ends with a date (and maybe other times, I only know about the situation with dates). If we always follow a subordinate clause with a comma, then there's no inconsistency. --UC_Bill (talk) 17:22, 23 January 2009 (UTC)

Do you have evidence for this absurdity? Septentrionalis PMAnderson 17:24, 23 January 2009 (UTC)

Our own example, "Feb. 14, 1987, was the target date.", is from the AP Stylebook. Does it promote unsound AE? -- Jao (talk) 17:28, 23 January 2009 (UTC)

I have evidence that it's actually correct usage (here) which I find to be absurd, since I've never seen anybody write it that way. The page I just referenced claims it's done for "typographical reasons" but doesn't mention anything about it being an American variation. I'll look into it though, to see what the deal is. --UC_Bill (talk) 17:33, 23 January 2009 (UTC)

(Edit conflict) And actually upon closer reading, it does mention "International format" which covers the non-American variants. Apparently it's because surrounding the year with commas on either side is supposed to make it set off from the rest. It only applies to full dates as well, according to that page. Anyway, since it does seem to be an official style guideline it's easy enough to support by putting the comma inside the square brackets. I'll update the demo code accordingly. --UC_Bill (talk) 17:33, 23 January 2009 (UTC)

Oh! I get why they put the comma there. It's because they're treating the mention of the year as an aside, similar to: Bob Smith, my brother, is tall So the comma before the year is actually doing "double duty" by acting as part of the date format and as a way of indicating that the year is a subclause. I think that's overly confusing (especially since they don't do it for DMY format) but like I said, it's easy enough to support in the new DA code so no worries. --UC_Bill (talk) 17:38, 23 January 2009 (UTC)

Exactly, parenthetical in formal terms. American/International is MDY v. DMY; the Chicago Manual of Style uses April 5, 2001, was just a working day for the crew. as its sole example for full date in American style. (§9.35). without the year it would be April 5 was just a working day for the crew.

But your coding will be harder than you think. It must remove both commas from April 5, 2001, was just a working day for the crew. But it must leave a comma when converting Early in the morning of April 5, 2001, the crew put their boat into the water, for that phrase is too long to omit punctuation, even in British/Australian. When you get a formatter that can do the right thing in all cases, get back to us; you will have solved Wikimedia's financial problems in one fell swoop, by inventing a working proof-reader. Septentrionalis PMAnderson 17:49, 23 January 2009 (UTC)

There's no need for a working proof-reader. The first example could be written "[[April 5]], [[2001,]] was just a working day for the crew" and would be rendered as "April 5, 2001, was just a working day for the crew" in MDY and "5 April 2001 was just a working day for the crew" in DMY. The second example could be written "Early in the morning of [[April 5]], [[2001]], the crew put their boat into the water" and would be rendered as "Early in the morning of April 5, 2001, the crew put their boat into the water" in MDY and "Early in the morning of 5 April 2001, the crew put their boat into the water" in DMY. Very simple. If the comma is supposed to be autoformatted, it goes inside the square brackets. If it's not part of the autoformatting, it goes outside the square brackets. there's no need for proofreading because editors can control how the comma is handled. --UC_Bill (talk) 18:03, 23 January 2009 (UTC)

That may work, although I suspect there is a third case, where BrE uses a comma and AE does not. But I would not call it simple. Simplicity would be acknowledging that we accept editors of all nationalities and therefore will be inconsistent on this matter (as we are on others) from article to article. (Let us know when the new draft is ready. Septentrionalis PMAnderson 18:10, 23 January 2009 (UTC)

...and actually, the comma inside the square brackets is really optional anyway, because full dates in MDY format should apparently always have a trailing comma when displayed on the page. So either "[[April 5]], [[2001,]] was just a working day for the crew" or "[[April 5]], [[2001]] was just a working day for the crew" would work just fine.. as would "[[5 April]] [[2001]] was just a working day for the crew" or even the grammatically incorrect "[[5 April]] [[2001,]] was just a working day for the crew." --UC_Bill (talk) 18:08, 23 January 2009 (UTC)

Not when the next character is a semicolon. Septentrionalis PMAnderson 18:10, 23 January 2009 (UTC)

What are the issues with semicolons? --UC_Bill (talk) 18:15, 23 January 2009 (UTC)

If you always add two commas in converting 10 September 2001 to American, you will get The best of times was 10 September 2001; the worst of times began the next day. wrong. Septentrionalis PMAnderson 19:12, 23 January 2009 (UTC)

I don't follow your example. It might be because of how the current DA system is autoformatting your date. Please re-state what you meant without linking the date, as would be the case in the new system anyway. Mostly I don't understand how two commas, one before the year and one after, are transformed into a semicolon after the date. Is that what you intended? --UC_Bill (talk) 19:27, 23 January 2009 (UTC)

My error. The Br Eng sentence above will be converted to The best of times was September 10, 2001,; the worst of times began the next day. if you always simply add two commas. Septentrionalis PMAnderson 04:38, 24 January 2009 (UTC)

I think maybe I figured out what you were getting at. Did you mean that examples like "The best of times was [[10 September]] [[2001]]; the worst of times began the next day" should be rendered as "The best of times was September 10, 2001; the worst of times began the next day" in MDY and not as "The best of times was September 10,2001,; the worst of times began the next day" as might be the case if the comma was always added after MDY dates? If that's what you were discussing, then rest assured that it works fine on the demo system. Please continue making comments in the new section below, since we're now dealing with an updated version of the software (and this section is way too long). --UC_Bill (talk) 21:07, 23 January 2009 (UTC)

yup. Septentrionalis PMAnderson 04:38, 24 January 2009 (UTC)

As a suggestion, and wherever a specific date is not required, it would be better to use an example date in which the day number is greater than 12. For example, on the demo page, 2009-01-31 would be better as an example than 2009-01-01. In that way, there will never be an example where the resulting day and month can be confused—resulting in a tighter specification.  HWV258  01:19, 24 January 2009 (UTC)

Yes, Anderson, in this case I believe the AP style guide does promote unsound AmEng in the redundant comma. Heaven knows, we have enough commas in text to make the reader's task functionally easier, so why put up with redundant commas? The comma in the middle of the US format, regrettably, is necessary because of the jostling of the numeric items. Like the APA style guide on reference-list formatting (and that of many academic journals), there's a thoughtless acceptance of bumpety-bump commas and dots that are idle. I wouldn't stress about it if some editor wants to insist on the bumpety comma after US date format, but I wouldn't actively encourage it.

The now-iconic phrase "September 11" is not usually "translated" into international format outside North America, reinforced by the internationally known analogue "9/11". This is yet another example of why we should not be resorting to hi-tech toy solutions to a non-problem. Intelligent (manual) control by local editors trumps the many things that would go wrong in some "son of autoformatting" bulldozer mechanism, if WP were foolish enough to agree to this risky business again. Our fingers were burnt in 2003. Let's not fall for it again in 2009. Tony (talk) 13:54, 24 January 2009 (UTC)

Concur. English usage isn't always rational. Dates can't all be treated alike. Some are quotes, some depend on context. Presumably we can depend on literate editors to sort out punctuation. --Pete (talk) 14:05, 24 January 2009 (UTC)

Tony, WP still isn't an institute of language reform. I deny that this is irrational (the year is a parenthetical), but it really doesn't matter. The second comma is in fact what American English does; American editors who have not looked into the bowels of MOSNUM will use it; American readers will expect it. If we attempt to institute this measure, we will fail, and insofar as we succeed, Wikipedia will be dismissed as ungrammatical.

The solution, I agree, is not to autoformat, but we aren't there yet. Septentrionalis PMAnderson 16:14, 24 January 2009 (UTC)

Link to what?

The current autoformat linking system links dates always to the same page, regardless of initial format. So all of the following link the month part to page "January 2":

• [[January 2]]: January 2
• [[2 January]]: 2 January
• [[2008-01-02]]: 2008-01-02

Any new system to have any use, must have the same behaviour. The current test system does not do this. −Woodstone (talk) 19:02, 23 January 2009 (UTC)

Yes it does. It works exactly the same as the current system, in that regard. You're probably being thrown off by links like this: [[:2 January]] which makes a link to "2 January" in both the new system and the current system. I'll remove those examples, since they're misleading. --UC_Bill (talk) 19:18, 23 January 2009 (UTC)

I've updated the text on the demo page so it explains things better. --UC_Bill (talk) 19:29, 23 January 2009 (UTC)

In the test system I still see [[:January 2]] linking to "Januari 2" and [[:2 January]] linking to "2 Januari". Since it is awkward to have an article name starting with a number, the date articles are named like "Januari 2". Even when the format (or source) is in the form "2 Januari", or "2008-01-02", it should still link to "Januari 2". And with the current system, they do. −Woodstone (talk) 20:24, 23 January 2009 (UTC)

Apparently I'm still not being clear. The old system and new system link everything exactly the same way. There's no difference. You're looking at the examples of prefixed links, which are one way of overriding the autoformatting. The old (current) system works the same way: 2 January ([[:2 January]]) is a link to a page named "2 January" just as with the new system. There's probably not any good reason to ever use such links, but the point of the examples was to show that there's no change in behavior between the old and new systems, in that regard. --UC_Bill (talk) 20:31, 23 January 2009 (UTC)

I'm wondering if : prefixed dates shouldn't also be auto formatted. If someone wants to intentionally format a date a certain way they can override that via pipes. For example:

• [[January 1]], [[2009]] should be unlinked and auto formatted.
• [[:January 1]], [[2009]] should be linked and auto formatted.
• [[January 1|January 1]], [[2009]] should be linked and not auto formatted.
• January 1, 2009 should be unlinked and not auto formatted.

Does this make sense? Basically use a full colon (:) to imply an intentional link with auto formatting, and a date without a colon to imply a date that's not linked but is auto formatted as well. For cases where you want the link and a specific date format you can do it by hand with the pipe. —Locke Cole • t • c 00:46, 24 January 2009 (UTC)

Demo site for new DA (version 0.2)

The demo code has been updated to deal with the comma issues pointed out above:

• http://gdnet-demo.berkeley.edu/testwiki/index.php/Main_Page

IMPORTANT NOTE REGARDING PRIVACY: I have access to the server logs on the above server, which means that (in theory) I can find out the IP address used to access that website. If you create an account on that wiki for testing (which is encouraged) you should NOT use any personally identifying information such as your real name or your Wikipedia username. Also feel free to connect through whatever proxy you like, to further protect your own identity.

I've put some comma-related examples on the main page of the demo site, but haven't exhaustively tested every combination of formats with every combination of preferences, so if you notice any misformatting please share it here. Make sure to include the example wikitext that formats incorrectly, as well as the preference settings you were using. --UC_Bill (talk) 19:43, 23 January 2009 (UTC)

UC Bill, I've kept as quiet as can be, since I dislike people popping up and calling me a fool who hasn't been paying attention (more or less, and I don't mean you). This looks really good and could solve a whole bunch of problems at one shot - if the weird cases can be overcome. Please do keep working away at it. I'd suggest solving the date range problem in the first go-round, "January 11-24, 2009". The work you've done is truly an innovation.

I'll contact you elsewhere to ask for a look at your source code. A public link here might be informative also. Keep chugging - technology yields choice, the only remaining limitation is the fallible humans using it! Franamax (talk) 05:58, 24 January 2009 (UTC)

Symbol for bits: bit or b?

Brought to attention by some (good) edits by User:TechControl:

B is the symbol for bytes (as per computer-industry standard IEEE 1541 and IEC 60027), while bit is the symbol for bits (as per WP:MOSNUM). The IEC 60027-2, the only industry standard that recommended bit as symbol has been superseded by ISO/IEC 80000. Per IEEE 1541-2002 b is the symbol for bits.

Should MOSNUM be changed? Shreevatsa (talk) 22:43, 23 January 2009 (UTC)

Thank you Shreevatsa! Additional I would like to point out that SATA-IO uses Gb/s in their specifications "SATA 1.5Gb/s", "SATA 3Gb/s", "SATA 6Gb/s" and have an extra webpage recommending this usage for product names. I think to remember that in the 1980s I already saw B and b. TechControl (talk) 22:53, 23 January 2009 (UTC)

My memory throughout my recorded brain history is that b is a bit, B is a byte. I'm thinking here of 300bps modems and 3MB (yes, really, three-megabyte) fixed disk drives. Especially in the context of data rates, bit/sec or bit/s is rare in my Western-biased viewpoint. "bps" is common for bit-per-second throughput, And kb (or Kb) is common for bit counts. However, for computer-architecture terminology, bit is more common: the 8086 CPU used an 8-bit instruction set, the 80286 was 16-bit; the PC-AT introduced a 32-bit I/O bus; &c. (Forgive my erroneous examples). I'd say that when bit is used as a standalone term, it's bit, when used in conjunction with other terms, it's b. However, I've not read all those standards linked above. Franamax (talk) 05:42, 24 January 2009 (UTC)

Insteasd of "term" it should be "unit symbol". Then: 16-bit - here it is a word. 1Gb/s - here it is a symbol. If used with other unit symbols it should be b. TechControl (talk) 08:06, 24 January 2009 (UTC)

That sounds pretty reasonable. Can you cast that into wording for the guideline that is understandable for the average editor who stumbles across it? And just to be sure, are we talking about wording for the bytes and bits section of MOSNUM, or did I miss something big? Franamax (talk) 09:12, 24 January 2009 (UTC)

Not the quantities of bytes and bits subsection, but elsewhere in the same unit symbols section. I propose changing (marked in red):

# Symbols have no plural form—an s is never appended (e.g., write kg, km, in, lb, not kgs, kms, ins, lbs. Write bit, not bits unless bits used as a word rather than a symbol).

by removing the second sentence (and inserting a different example if appropriate), and changing

* The symbol for the bit is bit, not b. The byte may be represented by either one of the symbols B and byte, but not b or o (French octet). Unless explicitly stated otherwise, one byte is eight bits (see History of byte).

* By extension, the symbols for the units of data rate kilobit per second, megabit per second and so on are kbit/s (not kbps or Kbps), Mbit/s (not Mbps or mbps), etc. Similarly, kilobyte per second and megabyte per second are kB/s (not kBps or KBps) and MB/s (not Mbps or MBps).

to

* The symbol for the bit is b, not bit. The byte may be represented by either one of the symbols B and byte, but not b or o (French octet). Unless explicitly stated otherwise, one byte is eight bits (see History of byte).

* By extension, the symbols for the units of data rate kilobit per second, megabit per second and so on are kb/s (not kbps or Kbps), Mb/s (not Mbps or mbps), etc. Similarly, kilobyte per second and megabyte per second are kB/s (not kBps or KBps) and MB/s (not Mbps or MBps).

[Missing wikitext because I can't see the page's source because it's protected.] Shreevatsa (talk) 14:04, 24 January 2009 (UTC)

I object to basing Wikipedia writing guidelines on expensive standards that are not available for free on the Internet. --Gerry Ashton (talk) 17:25, 24 January 2009 (UTC)

I don't see how that is relevant. (AFAIK, most standards are like that, even the SI.) Do you bring this up because you don't trust that the standard actually recommends "b" (in which case someone with access to them can look them up and confirm) or do you want to base guidelines on some other (which?) standard? Shreevatsa (talk) 17:33, 24 January 2009 (UTC)

The SI documents of BIPM and NIST are available free on the Internet (except that today NIST's servers are undergoing maintainence). IEEE's style guides are also free on the Internet (but don't seem to address the issue at hand clearly). Many other dictionaries and style guides are available free on the Internet, free in libraries, or at much more reasonable prices in bookstores. (That is, a technical writer only needs two or three dictoionaries and one to three style guides, but would a dozen expensive standards to cover just one area of technology (say, computers). Standards bodies are justified in charging hefty prices to engineers who are going to design new hardware that conforms to a standard, but we should not tolerate those prices for standards that are of interest to general writers. --Gerry Ashton (talk) 17:45, 24 January 2009 (UTC)

I completely agree with you that the hefty prices for these standards are intolerable. The question here is: should we choose "bit" or "b"? Why? Shreevatsa (talk) 18:43, 24 January 2009 (UTC)

NIST's Guide for the Use of the International System of Units (SI) (p. 9) shows bit as the symbol for the word bit. It indicates that bit and other information technology units given in ISO 31, its successor ISO/IEC 80000-1—ISO/IEC 80000-15, and IEC 60027 parts 1 through 4 may be used with SI units. --Gerry Ashton (talk) 20:14, 24 January 2009 (UTC)

NIST is only US related, IEEE is international.

5.1.3 Units from International Standards
There are a few highly specialized units that are given by ... ISO or ... IEC
and which in the view of this Guide are also acceptable for use with the SI.
They include the octave, phon, and sone, and units used in information technology, 
including the baud (Bd), bit (bit), erlang (E), hartley (Hart), and shannon (Sh)3.
It is the position of this Guide that the only such additional units NIST authors
may use with the SI are those given in either the International Standards on 
quantities and units of ISO (Ref. [4]) or of IEC (Ref. [5]).

Ref 4 = ISO 31, Ref 5 = IEC 60027. But Bit#Obsolete_definitions says IEC is obsolete. Can we stop referring to these obsolete standards? TechControl (talk) 21:16, 24 January 2009 (UTC)

Shall we have Wikipedia:Manual of Style (dates and numbers)/Proposal on bit symbol ? We now already have two bit symbol threads in this page and lot of talk about date formatting floating around. TechControl (talk) 21:32, 24 January 2009 (UTC)

• Most readers of Wikipedia’s computer articles read computer magazines and read computer advertisements. Most have no familiarity with the BIPM, NIST, IUPAP, or the IEC and haven’t a clue what those standards organizations say on various matters. The IEC, by the way, says we should be writing “kibibyte (KiB)”) but we ignore that advise because the real world doesn’t work that way.

  It doesn’t matter what all these standard bodies say. To minimize confusion and communicate clearly, Wikipedia should follow the practices observed in current, most-reliable literature on the subject. If we wanted to follow what the BIPM says, we’d put a space before a percent symbol,like At least 99 % of readers ignore the BIPM and follow real-world practices, rather than what everyone actually writes: At least 99% of readers ignore the BIPM and follow real-world practices. And MOSNUM, here, follows the real-world practice with respect to the percent symbol and ignores the BIPM on this issue (*sound of audience gasp*).

  We have got to stop acting like Talk:MOSNUM is a venue where the Mr. Spock in us all can glom onto each and every cool proposal that comes along and make Wikipedia ready to join the United Federation of Planets. If we did that, only about 2 centiuno of our readership would understand what is written here.

  It’s simple: Editors should simply look towards current literature on the subject; each and every issue doesn’t have to come here for discussion and debate about “what’s the best way to do something in a utopian world.” We follow the proposals of standard bodies only after they are widely followed in the real world. Always. Greg L (talk) 01:07, 26 January 2009 (UTC)

Son of autoformatting would expose us to an extremely risky experiment

WP burnt its fingers badly in blindly accepting a tech-toy back in 2003. Six years later, we have finally gotten rid of what is now widely regarded as a fault-ridden disaster. If we now sat by passively watching another attempt to introduce an elaborate solution where no one—repeat, no one—can identify the problem (see my two latest pleas on this page), we would have less excuse: as more sophisticated Internet/wiki users, we could not excuse ourselves so easily.

I appreciate the work a few editors seem to be putting into trying to develop another system to shield our precious eyes from corrosion by one or the other month-day/day/month order. However, the community now takes a conservative line on both DA and the linking of chronological items. This much is clear from the RfCs, especially here and here, analyses of the "detailed" RfCs above, and the large body of evidence that has accumulated elsewhere (links supplied on request to anyone who missed the numerous relevant pages).

Gerry and others have already raised the same old dangers that will inevitably accompany a new-fangled experiment that would again wrest from article editors the control and maintenance of date formats by the re-introduction of some kind of tech-bulldozer; it would cause no end of problems for no apparent gain (whether blue-wash or black, underlined or free of underline), and we would be foolish to agree to it.

Witness the circular tap-dance at Bugzilla for three years, trying to move towards a solution to the previous DA mechanism, with diddly-squat progress towards just removing the blue-wash and underlining from the program. These are just two of many problems. I'm not saying "don't program", but why we'd want to expose our project to that kind of disruption quite unnecessarily is beyond my imagination. If a gigantic company such as Microsoft gets so many things wrong with its operating systems and applications (OMG, look at Vista and Word), it points to systemic dangers of programming, in which there is a vanishingly small likelihood that there wouldn't be bugs and bad design. You might do it for Word or LaTeX or OSX—they're essential to many people's lives, and are necessary risks in the commercial world. And those companies employ huge numbers of well-resourced programmers to fix the glitches; they sell to long-suffering consumers who have little choice but to grit their teeth and wait for the design to improve and the bugs to be ironed out with each new wave. By contrast, WP relies on volunteers, and while I appreciate that they're skilled in real-life, expecting the professional dedication over a long period to see us through the inevitable mess is unfair to them, the community, and hundreds of millions of our readers. You wouldn't put yourself through that for fun, or for the kind of satisfaction some people get from doing a crossword puzzle. This crossword puzzle would require pain-killers all-round for an extended period.

May I also point to the fact that WP needs to stay on top of things to retain its privileged ranking on the Internet; there are sharks in the waters, and we must ensure that our wonderful project is not disrupted to this major extent with no clear point. Manually controlled dates are now well-accepted and liked. FAC didn't even blink, and over there, the engine-room of "our very best work", they are probably gobsmacked that this debate is still going on. Tony (talk) 14:51, 24 January 2009 (UTC)

I agree with the main thrust of this post; autoformatting was a bad idea; tolerance of diversity is a better idea.

I cannot agree with the motivation here; the fact that WP is coming in first in Google searches, which is partly an artifact of Google's search algorithm, may be bad for the world (it's too early; we are not a reliable source) and is certainly bad for us. The spammers, the nationalists, the secret services, would largely leave us alone if we were consistently, say, 25th in search ranking. If I thought anything of MOSNUM would lower our rank (and I don't believe it) I might support on that ground alone. Septentrionalis PMAnderson 16:20, 24 January 2009 (UTC)

Tony and PMAnderson basically agree with each other? Wow. If that wasn't sufficient reason to agree with both, there are plenty of other reasons to do so. For instance: We need a technical solution for the date formatting "problem" as much as for any other WP:ENGVAR "problem" – not at all. I suspect the only reason it's being singled out for getting "solution" is because we just got rid of another one. --Hans Adler (talk) 17:20, 24 January 2009 (UTC)

I would like to see the programming effort described above redirected to implement the "magic word" that describes the date format for each article, and develop a method for templates to detect that magic word and format any dates within the template to match the rest of the article. The mental effort required to think about how a date will look in every allowed format, and see if it fits with the surrounding punctuation, is excessive when writing an ordinary date in an article, but is justified for a template that will be used many times in many places. --Gerry Ashton (talk) 17:33, 24 January 2009 (UTC)

I'm not quite sure how this would work; but it sounds like it fails WYSIWYG. Please explain further.Septentrionalis PMAnderson 17:46, 24 January 2009 (UTC)

Consider a template like {{Birth date and age}} which, given a birth date of a living person, computes the age of the person and displays both. Today, the editor must add a parameter to indicate the output format. If there were a magic word on the page, the editor could omit the output format parameter and the output would still be correct. Furthermore, if it were ever decided to change the date format used on the page, the template would follow along without having to be edited. --Gerry Ashton (talk) 17:55, 24 January 2009 (UTC)

OK, that's effectively WYSIWYG. Septentrionalis PMAnderson 18:01, 24 January 2009 (UTC)

• Yes, Tony and I have long agreed that autoformatting was a bad idea; see the edit history of WP:Autoformatting (the actual page, not the shortcut). We have different but overlapping concerns, and disagree sharply on what to do about it now. Septentrionalis PMAnderson 17:46, 24 January 2009 (UTC)

I read the first two sentences and stopped. Tony, is it safe to say you'll be posting a new thread describing a chicken little tale of woe regarding any new system of date auto formatting? Or that you'll continue to deride it as a "tech toy" that's "unnecessary" (despite it being far from a "toy" and obviously useful considering a majority of the community indicated as much at the Date Linking RFC)? I've called for your help and assistance repeatedly, but you've mostly continued your rhetoric by constantly trying to disrupt the work being done.

The community wants some system of auto formatting. That much is clear. Let's work from there rather than trying to fight this battle endlessly. —Locke Cole • t • c 17:49, 24 January 2009 (UTC)

I must disagree. Some of the community wants one; quite possibly a large enough section that there is no consensus never to have one. Others don't. Septentrionalis PMAnderson 17:53, 24 January 2009 (UTC)

You're correct, apologies for overstating things. —Locke Cole • t • c 22:55, 24 January 2009 (UTC)

• Wikipedia's front page has this: "Welcome to Wikipedia, the free encyclopedia that anyone can edit." Last week I was visiting someone who has been using computers as a tool for over 20 years. I was showing him some of the boring articles I have written for Wikipedia. He had considered editing a Wikipedia article but put off by the convoluted syntax. What is wrong with just typing "September 11, 2001" or "8 August 2008"? The "anyone can edit" doesn't include many people who grew up using computers. The Wikimedia Foundation thinks that these non-technical editors would make valuable contributions if Wikipedia was easier to edit.[1] -- SWTPC6800 (talk) 19:07, 24 January 2009 (UTC)

• Keep in mind that - as with any encoding - editors aren't obligated to add coding when they contribute. We don't insist that new editors apply bold or italic formatting, use section breaks, or even fuss over spelling; the emphasis is on content, as there are always more experienced editors who will clean up and format the new material. --Ckatz^chat_spy 20:08, 24 January 2009 (UTC)

When these non-technical potential contributors click on "edit this page" they see a blizzard of Wiki markup syntax and just give up. They don't contribute anything for the crew of experienced editors to clean up and format. -- SWTPC6800 (talk) 20:28, 24 January 2009 (UTC)

I understand your point. However, it is related to all Wiki markup, not just date formatting; any efforts to simplify the interface would (I presume) not require the removal of markup-related features. --Ckatz^chat_spy 21:31, 24 January 2009 (UTC)

• This isn't relevant, we had an RFC to try and settle this and the results point to support for some form of auto formatting. Besides, the syntax being proposed isn't really any more complicated than what we already have. —Locke Cole • t • c 22:55, 24 January 2009 (UTC)

Tony, why the persistent fear-mongering? This is a user-interface enhancement, in line with countless other innovations in technology that allow end users to have some measure of control over their viewing environment. It is being discussed, bugs, flaws, and possible glitches are being weeded out, and the community is fully involved in the development. The developer is eager to assist, and concerns raised in the RfCs and in previous discussions are being addressed. If we were to instead subscribe to the rhetoric in your post ("dangers", "burnt its fingers badly", "inevitable mess" to list but a few) we would never have moved past pen and paper. (How, for example, can you describe a technical feature like date formatting as a "risky experiment" when the entire body of information on this wiki is based on the premise that "anyone can edit"?) Again, if you do not want to use the feature, you can always disable it in your preferences. Meanwhile, those who do value such a feature are free to take advantage of it. --Ckatz^chat_spy 20:11, 24 January 2009 (UTC)

Ckatz's claim that you can always disable it in your preferences is false unless the current proposal is changed. The "no preference" choice is a misnomer; it really means "day-month-year". --Gerry Ashton (talk) 20:36, 24 January 2009 (UTC)

With all due respect, I seem to recall Bill describing an option to display raw date formats. (It may have been on the Bugzilla site, but it would allow users the choice of not having any autoformatting.) Unless that option has disappeared, the "claim" is not "false". --Ckatz^chat_spy 21:31, 24 January 2009 (UTC)

I don't know why you'd want to disable it the way it's designed. —Locke Cole • t • c 21:52, 24 January 2009 (UTC)

Ckatz: Two different versions. The one being discussed here has DMY as a system default, which can be overridden in either user preferences or on a page-by-page basis by using the {{DATEFORMAT:MDY}} magic word / parser function. I'm sure it's easy to switch to "no reformatting" for anons if that's what people agree to, or to add it as another option under user preferences, though. --Sapphic (talk) 21:54, 24 January 2009 (UTC)

... or come to think of it, perhaps the default for anons (and users who select that preference setting) can be "no autoformatting" except on pages where {{DATEFORMAT:MDY}} (or {{DATEFORMAT:DMY}}) have been added. (edit conflict) --Sapphic (talk) 22:00, 24 January 2009 (UTC)

Part of the problem with the current auto formatting was that it didn't function for anons. Turning it off in preferences for logged in editors should disable all auto formatting (even for pages which explicitly state a format with the new DATEFORMAT magic word). —Locke Cole • t • c 21:59, 24 January 2009 (UTC)

• Forget date autoformatting. Such a tool would not benefit 99.9% of our readership: all our non-registered I.P. readers. All these readers would get is a default format. The only people who would benefit with a *special* view would be some of us registered editors. Last time I looked, I didn’t have an *I am so really, really special* license and I don’t think anyone else here has one either. Advocates of “autoformatting” need to stop wasting everyone’s time here debating and fretting over tools that do nothing but mollify a vanishingly small percentage of our readership who insist that they can’t possibly look at the date format that everyone else has to look at. I’m not buying it this notion that any of us here are so damned special that it’s worth the effort.

  For those who vehemently disagree with me on this, please present your *I am so really, really special* license for inspection and then let’s hear your sob story about how developers should make special tools just you can be spared the shock of being exposed to a date written out in your less-than-desired format. Greg L (talk) 01:29, 26 January 2009 (UTC)

Comparable quantities section

The rule exception for comparative quantities has bugged me for a long time. Why does it exist? In my humble view, it serves no purpose other than unnecessarily complicating the writing of sequences of objects. I'm referring to the exception that doesn't allow "32 dogs and five cats" and asks that it be written as "32 dogs and 5 cats". JKBrooks85 (talk) 00:09, 25 January 2009 (UTC)

We state it because style guides recommend it; they recommend it because the reader may wonder why the text is changing from 32 to five for no obvious reason. Septentrionalis PMAnderson 03:28, 25 January 2009 (UTC)

• Which style guides? According to my handy-dandy AP Stylebook, the rule is to apply the appropriate guidelines when considering numbers in a series. JKBrooks85 (talk) 09:13, 25 January 2009 (UTC)

In a long list of items, when the presentation of quantities' formatting randomly changes, it can be quite distracting: "42 apples, 67 oranges, 45 pears, three grapefruits, seven cherries, 56 grapes, and one watermelon." As Pmanderson notes, the reader will be befuddled. Dabomb87 (talk) 04:48, 25 January 2009 (UTC)

See [2]. Dabomb87 (talk) 22:15, 25 January 2009 (UTC)