![]() | This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 1 | ← | Archive 5 | Archive 6 | Archive 7 | Archive 8 | Archive 9 | Archive 10 |
Mav proposed a required margin of 75% for any option to win. While I sympathize with the general idea, we need to be clear about what this means. This vote was started to determine whether the current MoS policy should be changed. If we set a margin of 75% now, that means that the current MoS recommendation will not be changed if none of the options (including the so-called compromise options) wins by such a margin. This is of course very much in my interest, but Mav will probably argue like this: If none of the options wins, we need to change the MoS to one of the inconsistent options, i.e. "everyone can use their preferred style."
I want to make clear that this is not acceptable nor democratic, since it would basically say "This option, which was never reached through an open consensus or a democratic process, is going to win, unless any of those other options reaches more than the 75% margin." If we can agree that any of the options that propose to change the MoS needs to reach a 75% winning margin, that's fine with me. -- Eloquence 04:43 24 Jun 2003 (UTC)
Ok. I must have mis-understood. I have removed my mis-understanding, least there be any . . um . . misundertanding. :-) wikipeace. FearÉIREANN 05:53 24 Jun 2003 (UTC)
Eloquence: For any option to win there needs to be wide support for it. If, as JT says, most users want to only use their style then let them in the articles they work on when and where it makes sense. And the use of the word "policy" is absurd in this whole matter; never, not once, has the MoS ever been policy; It's only function is to serve as a guidebook on the preferred house style for editing (and then it is not enforced on authors but rather is something that interested copyeditors generally follow). It is a loose agreement, soft conventions if you will, on how Wikipedians as a whole think looks and works best. Therefore these style guidelines are useless if they do not have a great deal of support.
Oh and the argument that the previous MoS guideline is the default fallback (or previous "policy" as you stated) is is logically flawed for this simple reason (pardon for the shouting); WHEN THAT GUIDELINE WAS WRITTEN THERE WERE NO REDIRECTS FROM THE [[DAY MONTH]] STYLE TO THE [[MONTH DAY]] STYLE. So, ''of course'' it was the ''only'' guideline we had at that time because only [[MONTH DAY]] links actually worked! But after the initial part of this discussion started 4 months ago a few users went ahead and made all 366 redirects. The vote went nowhere and became such a confusing mess and joke that people on nearly all sides of the argument were able to logically argue that their choice was the actual winner. Now since the redirects were there (thus finally permitting [[DAY MONTH]] links) then the natural fallback was to allow both and prefer neither. The aborted vote effectively killed the old guideline since it became very clear that a sizable group wanted to link dates in the International style. But another sizable group wanted to link using the American style. So we have both. I'm going to put the margin back in now. If you take it out then I'll take out your date since I don't recall you being given the authority to choose such a date (or even call for a vote, for that matter). --- mav 06:04 24 Jun 2003 (UTC)
This is all becoming rather a moot point. I was quite serious when I said I would code automatic conversion. A basic demostration is now available at http://piclab.com/wiki/wiki.phtml?title=Astronomy_and_astrophysics . The user preferences aren't done yet, so at the moment it just acts as if the user has requested MD,Y format. I think I was a bit ambitious with my spec: I still haven't done yearless conversion (e.g. DM -> MD with no Y around), and I don't capitalise months yet. Do people think these features are necessary?
Some other points for discussion:
-- Tim Starling 10:03 24 Jun 2003 (UTC)
Okay, yearless dates will be implemented. The current code requires links, and I think it's easily worth the inconvenience, to reduce false positives. We don't want to get into parsing sentence structure. Plus I'm biased -- I like articles with lots of links. The "Y,,,DM" format simply demonstrates the fact that my regular expressions allow an arbitrary combination of spaces and commas between DM and Y components. It's a shortcut, but I can't think of any problem with it.
What about the number of supported date formats? 3 may be enough. 4 or 5 may be even better. :)
On an unrelated matter, does anyone know what happened to user:-- April? I last saw April 6 months ago. :) Excuse me while I go think of some more... -- Tim Starling 11:41 24 Jun 2003 (UTC)
Unrelated trivia: did you know that Ershi Huangdi was the 2nd August Emperor of the Qin Dynasty?
If we were to standardise, the custom of Wikipedia seems to be to choose the "most international" choice, which is surely day-month-year:
(BTW note the false logic at the top of this page: day-month-year is not "British style" it's "most-places-other-than-US" style and so by that argument ought to apply to all articles except those about the US.)
So if there was a standard, it ought to be day-month-year. But it's pointless micro-management to look for consistency in this. Now there are day-month redirect pages there is no problem. Let anarchy prevail. Andy G 18:20 24 Jun 2003 (UTC)
The "turnout" seems rather low to justify any sort of mass changing of articles. Besides I can imagine certain types of writing (including discussion of date formats) where automated global changes to date formats would significantly damage articles. -- Paul (Hobgoblins for small minds)
The date/time page is too long for me to edit, but I'd like to put in another plea that Julian/Gregorian and double dates be handled properly! --
Someone else 01:16 1 Jul 2003 (UTC)
The "year in literature" pages are steadily growing, and anyone interested in discussing whether publication dates should link to them or not is invited to have a look at Talk:Hollywood, California. -- KF 04:55 7 Jul 2003 (UTC)
Moved from Wikipedia:Village pump:
What is the convention for listing the day of someone's death, if the time of death would make it ambiguous with respect to UTC? (For example, Bob Hope died at 9:29 pm Pacific time on Sunday, July 27; if I figured it correctly, this would be 4:29 am UTC July 28.) -lee 14:53 28 Jul 2003 (UTC)
Is it acceptable to do the following, especially in a table:
who it is | Aug 12, 1992 |
them is who | Sep 7, 1999 |
It seems much more concise..... ( RayKiddy)
Eclecticology has tried to change these guidelines for some reason. I don't think any of these changes are acceptable and as I can not see that they have been discussed I have reverted the page. The changes were
Angela 22:48, 12 Nov 2003 (UTC)
In response
Excuse me, it's not a "boldfaced lie", it was supported by Phil Bordelon, at the bottom of Wikipedia talk:Manual of Style (dates and numbers)/archive6. There was no proposal at Wikipedia talk:Manual of Style (dates and numbers)/vote to use RFC 3339/ISO 8601 as a visible date format, the proposal there was to use it in the wikitext, and then convert it to a more readable format as the page is rendered. Our software will not convert RFC 3339 dates. Hence there is no reason to mention RFC 3339 in the manual of style, except perhaps to say that it shouldn't be used since it won't be converted. -- Tim Starling 06:00, Nov 13, 2003 (UTC)
I don't see how ISO 8601 is even remotely relevant, and would object to it being used at all, and would change any usage of it. ISO 8601 specifies a format for computer-readable dates, not human-readable dates. It is something used by CS and Engineering people, not encyclopedia writers. You will note that no major manual of style even knows of the existence of ISO 8601, let alone recommends its use. In short, it is wholly unsuitable to an encyclopedia. To see just how uninterested in human readability ISO 8601 is, their allowed encodings for the date/time "13:10:30 on February 14, 1993" are "19930214T131030" or "1993-02-14T13:10:30" (quoted directly from the standard). This is obviously ridiculous for use in written text, which is why people who write encyclopedias don't refer to ISO documents. -- Delirium 08:01, Nov 13, 2003 (UTC)
And apparently the ISO itself agrees with me: the news section of http://www.iso.org/ does not use ISO 8601 dates, instead using dates of the form 4 November 2003 (the only use of ISO 8601 is in a computer context: the last-modified timestamp). -- Delirium 08:12, Nov 13, 2003 (UTC)
These formats were listed on VfD and an overwhelming majority of people wanted them deleted [1]. The point is now moot as Tim is shortly to update the automatic date-munging code to make links in [[YYYY]]-[[MM-DD]] format link to the standard pages, as is now done for [[# Monthname]] [[YYYY]].
There will then be no need for redirects for people who may happen to write date links in that format, and these redirects can then be deleted with no harm done. Only full YYYY-MM-DD dates would be automatically linked to the date pages; a MM-DD or DD-MM link floating alone -- would would be ambiguous -- will not be linked.
The 8 formats, roughly in PHP date() notation, are:
$this->targets[DF_DMY] = "[[F j|j F]] [[Y]]"; $this->targets[DF_MDY] = "[[F j]], [[Y]]"; $this->targets[DF_YMD] = "[[Y]] [[F j]]"; $this->targets[DF_ISO1] = "[[y]]-[[F j|m-d]]"; $this->targets[DF_YDM] = "[[Y]], [[F j|j M]]"; $this->targets[DF_DM] = "[[F j|j F]]"; $this->targets[DF_MD] = "[[F j]]"; $this->targets[DF_ISO2] = "[[y-m-d]]";
But only the first 4 can be selected in user preferences. -- Tim Starling 01:02, Nov 18, 2003 (UTC)
On a different note, isn't 200,300 ambigous (I understand the Brits are supposed to do 200.300 in metric measurements)? And 0.000000304 hard to read? In Australia, the recommended format is the less ambigous and easier-to-read 200 300 and 0.000 000 304. I could live with the comma in big numbers, but I really think the existence of some separator after the decimal point really should be used. -- Kesuari 11:03, 16 Nov 2003 (UTC)
-- Jerzy 21:11, 2003 Nov 18 (UTC)
I realize that dates should always be links so that dynamic dates will work. But do we really have to make every year a link? If I'm writing a biography with a lot of years, in 19xx she did this, in 19yy she did that, it seems silly to make every year a link. There's no point to it, it doesn't go to a page the reader is likely to want, and it makes it harder to read. Opinions? Tualha 16:59, 13 Dec 2003 (UTC)
I did not notice a style guideline for formatting ranges of dates and numbers. Common usage on Wikipedia seems to be to use a simple hyphen for numbers ("refer to pages 2-12") and to use a spaced hyphen for dates ("Jonathan Bruce Postel ( August 6, 1943 - October 16, 1998)").
My personal preference would be to go by the Chicago Manual of Style (14th ed.), which recommends an unspaced en dash in both cases ("refer to pages 2–12", "Jonathan Bruce Postel ( August 6, 1943– October 16, 1998)"). An en dash can be entered by using the HTML character entity –.
— LarryGilbert 01:06, 2004 Mar 13 (UTC)
I understand the distinction between the American meaning of "billion" and the British meaning of "billion". I wonder if the possibility of some kind of auto-formatting (similar to what's done with dates now) has been discussed? Is this more of a software issue, and if so, can someone point me to the best place to discuss such software issues? Thanks. — LarryGilbert 22:33, 2004 Mar 15 (UTC)
One article, 4510, doesn't follow the rule mentioned on this article. See Talk:4510 for what to do with it. 66.32.127.112 02:59, 22 May 2004 (UTC)
![]() | This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 1 | ← | Archive 5 | Archive 6 | Archive 7 | Archive 8 | Archive 9 | Archive 10 |
Mav proposed a required margin of 75% for any option to win. While I sympathize with the general idea, we need to be clear about what this means. This vote was started to determine whether the current MoS policy should be changed. If we set a margin of 75% now, that means that the current MoS recommendation will not be changed if none of the options (including the so-called compromise options) wins by such a margin. This is of course very much in my interest, but Mav will probably argue like this: If none of the options wins, we need to change the MoS to one of the inconsistent options, i.e. "everyone can use their preferred style."
I want to make clear that this is not acceptable nor democratic, since it would basically say "This option, which was never reached through an open consensus or a democratic process, is going to win, unless any of those other options reaches more than the 75% margin." If we can agree that any of the options that propose to change the MoS needs to reach a 75% winning margin, that's fine with me. -- Eloquence 04:43 24 Jun 2003 (UTC)
Ok. I must have mis-understood. I have removed my mis-understanding, least there be any . . um . . misundertanding. :-) wikipeace. FearÉIREANN 05:53 24 Jun 2003 (UTC)
Eloquence: For any option to win there needs to be wide support for it. If, as JT says, most users want to only use their style then let them in the articles they work on when and where it makes sense. And the use of the word "policy" is absurd in this whole matter; never, not once, has the MoS ever been policy; It's only function is to serve as a guidebook on the preferred house style for editing (and then it is not enforced on authors but rather is something that interested copyeditors generally follow). It is a loose agreement, soft conventions if you will, on how Wikipedians as a whole think looks and works best. Therefore these style guidelines are useless if they do not have a great deal of support.
Oh and the argument that the previous MoS guideline is the default fallback (or previous "policy" as you stated) is is logically flawed for this simple reason (pardon for the shouting); WHEN THAT GUIDELINE WAS WRITTEN THERE WERE NO REDIRECTS FROM THE [[DAY MONTH]] STYLE TO THE [[MONTH DAY]] STYLE. So, ''of course'' it was the ''only'' guideline we had at that time because only [[MONTH DAY]] links actually worked! But after the initial part of this discussion started 4 months ago a few users went ahead and made all 366 redirects. The vote went nowhere and became such a confusing mess and joke that people on nearly all sides of the argument were able to logically argue that their choice was the actual winner. Now since the redirects were there (thus finally permitting [[DAY MONTH]] links) then the natural fallback was to allow both and prefer neither. The aborted vote effectively killed the old guideline since it became very clear that a sizable group wanted to link dates in the International style. But another sizable group wanted to link using the American style. So we have both. I'm going to put the margin back in now. If you take it out then I'll take out your date since I don't recall you being given the authority to choose such a date (or even call for a vote, for that matter). --- mav 06:04 24 Jun 2003 (UTC)
This is all becoming rather a moot point. I was quite serious when I said I would code automatic conversion. A basic demostration is now available at http://piclab.com/wiki/wiki.phtml?title=Astronomy_and_astrophysics . The user preferences aren't done yet, so at the moment it just acts as if the user has requested MD,Y format. I think I was a bit ambitious with my spec: I still haven't done yearless conversion (e.g. DM -> MD with no Y around), and I don't capitalise months yet. Do people think these features are necessary?
Some other points for discussion:
-- Tim Starling 10:03 24 Jun 2003 (UTC)
Okay, yearless dates will be implemented. The current code requires links, and I think it's easily worth the inconvenience, to reduce false positives. We don't want to get into parsing sentence structure. Plus I'm biased -- I like articles with lots of links. The "Y,,,DM" format simply demonstrates the fact that my regular expressions allow an arbitrary combination of spaces and commas between DM and Y components. It's a shortcut, but I can't think of any problem with it.
What about the number of supported date formats? 3 may be enough. 4 or 5 may be even better. :)
On an unrelated matter, does anyone know what happened to user:-- April? I last saw April 6 months ago. :) Excuse me while I go think of some more... -- Tim Starling 11:41 24 Jun 2003 (UTC)
Unrelated trivia: did you know that Ershi Huangdi was the 2nd August Emperor of the Qin Dynasty?
If we were to standardise, the custom of Wikipedia seems to be to choose the "most international" choice, which is surely day-month-year:
(BTW note the false logic at the top of this page: day-month-year is not "British style" it's "most-places-other-than-US" style and so by that argument ought to apply to all articles except those about the US.)
So if there was a standard, it ought to be day-month-year. But it's pointless micro-management to look for consistency in this. Now there are day-month redirect pages there is no problem. Let anarchy prevail. Andy G 18:20 24 Jun 2003 (UTC)
The "turnout" seems rather low to justify any sort of mass changing of articles. Besides I can imagine certain types of writing (including discussion of date formats) where automated global changes to date formats would significantly damage articles. -- Paul (Hobgoblins for small minds)
The date/time page is too long for me to edit, but I'd like to put in another plea that Julian/Gregorian and double dates be handled properly! --
Someone else 01:16 1 Jul 2003 (UTC)
The "year in literature" pages are steadily growing, and anyone interested in discussing whether publication dates should link to them or not is invited to have a look at Talk:Hollywood, California. -- KF 04:55 7 Jul 2003 (UTC)
Moved from Wikipedia:Village pump:
What is the convention for listing the day of someone's death, if the time of death would make it ambiguous with respect to UTC? (For example, Bob Hope died at 9:29 pm Pacific time on Sunday, July 27; if I figured it correctly, this would be 4:29 am UTC July 28.) -lee 14:53 28 Jul 2003 (UTC)
Is it acceptable to do the following, especially in a table:
who it is | Aug 12, 1992 |
them is who | Sep 7, 1999 |
It seems much more concise..... ( RayKiddy)
Eclecticology has tried to change these guidelines for some reason. I don't think any of these changes are acceptable and as I can not see that they have been discussed I have reverted the page. The changes were
Angela 22:48, 12 Nov 2003 (UTC)
In response
Excuse me, it's not a "boldfaced lie", it was supported by Phil Bordelon, at the bottom of Wikipedia talk:Manual of Style (dates and numbers)/archive6. There was no proposal at Wikipedia talk:Manual of Style (dates and numbers)/vote to use RFC 3339/ISO 8601 as a visible date format, the proposal there was to use it in the wikitext, and then convert it to a more readable format as the page is rendered. Our software will not convert RFC 3339 dates. Hence there is no reason to mention RFC 3339 in the manual of style, except perhaps to say that it shouldn't be used since it won't be converted. -- Tim Starling 06:00, Nov 13, 2003 (UTC)
I don't see how ISO 8601 is even remotely relevant, and would object to it being used at all, and would change any usage of it. ISO 8601 specifies a format for computer-readable dates, not human-readable dates. It is something used by CS and Engineering people, not encyclopedia writers. You will note that no major manual of style even knows of the existence of ISO 8601, let alone recommends its use. In short, it is wholly unsuitable to an encyclopedia. To see just how uninterested in human readability ISO 8601 is, their allowed encodings for the date/time "13:10:30 on February 14, 1993" are "19930214T131030" or "1993-02-14T13:10:30" (quoted directly from the standard). This is obviously ridiculous for use in written text, which is why people who write encyclopedias don't refer to ISO documents. -- Delirium 08:01, Nov 13, 2003 (UTC)
And apparently the ISO itself agrees with me: the news section of http://www.iso.org/ does not use ISO 8601 dates, instead using dates of the form 4 November 2003 (the only use of ISO 8601 is in a computer context: the last-modified timestamp). -- Delirium 08:12, Nov 13, 2003 (UTC)
These formats were listed on VfD and an overwhelming majority of people wanted them deleted [1]. The point is now moot as Tim is shortly to update the automatic date-munging code to make links in [[YYYY]]-[[MM-DD]] format link to the standard pages, as is now done for [[# Monthname]] [[YYYY]].
There will then be no need for redirects for people who may happen to write date links in that format, and these redirects can then be deleted with no harm done. Only full YYYY-MM-DD dates would be automatically linked to the date pages; a MM-DD or DD-MM link floating alone -- would would be ambiguous -- will not be linked.
The 8 formats, roughly in PHP date() notation, are:
$this->targets[DF_DMY] = "[[F j|j F]] [[Y]]"; $this->targets[DF_MDY] = "[[F j]], [[Y]]"; $this->targets[DF_YMD] = "[[Y]] [[F j]]"; $this->targets[DF_ISO1] = "[[y]]-[[F j|m-d]]"; $this->targets[DF_YDM] = "[[Y]], [[F j|j M]]"; $this->targets[DF_DM] = "[[F j|j F]]"; $this->targets[DF_MD] = "[[F j]]"; $this->targets[DF_ISO2] = "[[y-m-d]]";
But only the first 4 can be selected in user preferences. -- Tim Starling 01:02, Nov 18, 2003 (UTC)
On a different note, isn't 200,300 ambigous (I understand the Brits are supposed to do 200.300 in metric measurements)? And 0.000000304 hard to read? In Australia, the recommended format is the less ambigous and easier-to-read 200 300 and 0.000 000 304. I could live with the comma in big numbers, but I really think the existence of some separator after the decimal point really should be used. -- Kesuari 11:03, 16 Nov 2003 (UTC)
-- Jerzy 21:11, 2003 Nov 18 (UTC)
I realize that dates should always be links so that dynamic dates will work. But do we really have to make every year a link? If I'm writing a biography with a lot of years, in 19xx she did this, in 19yy she did that, it seems silly to make every year a link. There's no point to it, it doesn't go to a page the reader is likely to want, and it makes it harder to read. Opinions? Tualha 16:59, 13 Dec 2003 (UTC)
I did not notice a style guideline for formatting ranges of dates and numbers. Common usage on Wikipedia seems to be to use a simple hyphen for numbers ("refer to pages 2-12") and to use a spaced hyphen for dates ("Jonathan Bruce Postel ( August 6, 1943 - October 16, 1998)").
My personal preference would be to go by the Chicago Manual of Style (14th ed.), which recommends an unspaced en dash in both cases ("refer to pages 2–12", "Jonathan Bruce Postel ( August 6, 1943– October 16, 1998)"). An en dash can be entered by using the HTML character entity –.
— LarryGilbert 01:06, 2004 Mar 13 (UTC)
I understand the distinction between the American meaning of "billion" and the British meaning of "billion". I wonder if the possibility of some kind of auto-formatting (similar to what's done with dates now) has been discussed? Is this more of a software issue, and if so, can someone point me to the best place to discuss such software issues? Thanks. — LarryGilbert 22:33, 2004 Mar 15 (UTC)
One article, 4510, doesn't follow the rule mentioned on this article. See Talk:4510 for what to do with it. 66.32.127.112 02:59, 22 May 2004 (UTC)