Wikipedia talk:Manual of Style/Dates and numbers

Proposal to unlock MOSNUM

It seems that cool heads, peace, and civility has broken out—completely unchecked—all over the place on the ArbCom and its related subpages. I have this proposal: Why not unlock MOSNUM with the proviso that anything related to date formats, autoformatting, and date linking be left alone. Greg L (talk) 04:40, 17 March 2009 (UTC)

P.S. After MOSNUM is unlocked, maybe we might see that everyone standing around on Wikipedian street corners will have a confused, blank look, and say to their neighbor “Instead of running for our AK‑47s, wanna play a game of checkers or something?” Greg L (talk) 04:47, 17 March 2009 (UTC)

If desired (and for our sanity) one could consider temporarily moving the "Chronological items" section to a sub-page, protect only that sub-page, and then display it in the main page. That way, no-one would be tempted... Thoughts? --Ckatz^chat_spy 05:21, 17 March 2009 (UTC)

• Perfect. By “display”, you mean transclude that page into the relevant section of MOSNUM; yes? That’s a great way restore some sense of normalcy. Greg L (talk) 06:05, 17 March 2009 (UTC)

That's the term I was looking for... sorry for the momentary blank-out. If that sounds reasonable to everyone, I can make the change. Thoughts? --Ckatz^chat_spy 20:14, 17 March 2009 (UTC)

• I, for one, can not possibly imagine any downside. I don’t even perceive a need to transclude the entire Chronological items section since most of it is uncontroversial stuff. I suggest unlocking everything except except the Linking and autoformatting of dates section, which would be moved and transcluded back. If editwarring starts on adjacent material, it will be only too easy to expand the transclusion range.

  Unlocking MOSNUM will help everyone settle into a feeling of normalcy, which has been sorely lacking for a while. Greg L (talk) 03:34, 18 March 2009 (UTC)

All right, per Greg's request (and seeing no objections) I have changed the page's protection level to "semi-protected". The "Dates" subsection has been moved to the sub-page "Wikipedia:Manual_of_Style_(dates_and_numbers)/Datestempprotectedsection" (which is then transcluded back to the main page) and that sub-page remains fully protected until the dispute is resolved. If this works as planned, editors should be able to make necessary changes to the bulk of the guideline, while preventing edit wars in the controversial "Dates" section. Please let me know how this is working, so that we can tweak or revert as needed. --Ckatz^chat_spy 09:11, 19 March 2009 (UTC)

It should also have a dispute tag, or tags, since it is. Septentrionalis PMAnderson 15:32, 19 March 2009 (UTC)

• Even Marvin the Martian knows Wikipedia’s date-related stuff is the subject of a raging dispute. He’s got his telescope focused on the Capitol steps to see if some Wikipedian goes there, douses himself with gasoline, and sets himself alight over date linking. Greg L (talk) 19:59, 19 March 2009 (UTC)

Hallelujah. (I had proposed this on 15 February, but it was ignored.) --A. di M. (talk) 16:37, 20 March 2009 (UTC)

Your suggestion wasn’t being ignored. There wasn’t enough “war fatigue” at that time. Also, key combatants back then were still in “wide-eyed” mode, trying to eat the still-beating hearts of their enemies. What has changed in the interim is there is now a more amicable relationship to hating each other. Greg L (talk) 17:30, 20 March 2009 (UTC)

Compound numbers

As previously discussed (archive), would anyone object to my adding this as the fourth bullet point here on MOSNUM:

• When writing two, or three-digit compound numbers, such as 12 billion lightyears or 420 million metric tons, it is often a good idea to use a non-breaking space, either   or {{nbsp}} between the value and named number (e.g. 12{{nbsp}}billion lightyears). This will improve readability by preventing the expression from breaking at a line-end word-wrap.

Greg L (talk) 22:06, 19 March 2009 (UTC)

I'd rather say "numbers written partly as figure and partly as words" rather than "two, or three-digit compound numbers", as it would also apply to, e.g., 1079 million. But, where we are at it, this could be merged with the bullet starting with "The use of words rather than figures..." like this:

• When expressing large approximate numbers, it is preferable to write numbers in words, or partly in figures and part in words, for example: Japan has the world's tenth largest population, with about 128 million people (it is just an approximation to a number likely to be anywhere between 127,500,000 and 128,500,000), but It grossed $28,106,731 on its opening day (the exact number). When both a figure and a word are used in the same number, it is useful to use a non-breaking space, as in 128 million, to prevent a line break from occurring between them.

What do y'all think? --A. di M. (talk) 18:25, 20 March 2009 (UTC)

• I think what you have here is great. Have you checked the rest of the wording on MOSNUM to ensure we would be adhering to a consistent convention for the terms “numbers”, “words”, “figures”? If what you have is consistent, then I think it’s fab. If the terminology is inconsistent, I trust that you will make the peg fit the hole or the hole fit the peg. Greg L (talk) 20:53, 20 March 2009 (UTC)

No, I haven't. Does that really matter that much? --A. di M. (talk) 21:01, 20 March 2009 (UTC)

• IMO, sure. You and I are very familiar with this stuff and understand the intended meaning of the points. But for some 16-year-old editor trying to make heads and tails of all those guidelines, consistency with naming our nouns should be a high priority. I wouldn’t have a cow about your posting it as is. But I would just be reluctant to do so myself unless I made sure my verbiage was harmonized with what I was imbedding it into (rather than leaving such details for someone else later on). Greg L (talk) 21:13, 20 March 2009 (UTC)

(outdent)
I took the initiative and looked at the existing verbiage. I’ve revised the key nouns to be harmonious with adjacent text and added the following:

• When expressing large approximate quantities, it is preferable to write them spelled out, or partly in figures and part as a spelled‑out named number, for example: Japan has the world's tenth largest population, with about 128 million people (it is just an approximation to a number likely to be anywhere between 127,500,000 and 128,500,000), but The movie grossed $28,106,731 on its opening day (the exact quantity).

• When both a figure and spelled-out named number are used in a quantity, it is useful to use a non-breaking space, as in 128 million or 128{{nbsp}}million to prevent a line break from occurring between them.

Be my guest to tweak and revise to your heart’s content; I’m not stuck on anything—just the basics here. Greg L (talk) 04:31, 21 March 2009 (UTC)

Plain text Date templates redux

As has been pointed out elsewhere, the principle of wikitext was to make editing articles as easy as possible so that "everyone can be an editor". Unfortunately, some templates are needlessly arcane and serve to reintroduce the complexity that wikitext sought to remove. Many of these complex templates have to do with date and number handling.

In late January and early February, on this talk page we had an extensive discussion on whether plain text date templates were preferable over the older date templates. For a full writeup on the family of new templates being discussed and their benefits, please see this village pump thread. The new family of templates are is reliant on the central {{start-date}} and {{end-date}} templates. My understanding from the MOSNUM conversation on the plain text templates was that the consensus favored guidance directing contributors towards plain text oriented templates rather than the numerically oriented date templates. On the 11th, I posted an editprotected request note citing the previous conversation the rationale for the change, and including the suggested new guidance. There has been no comment on that note or change since then, and I know this talk page is heavily watched, so I interpreted the lack of response as agreement. However, some editors believe this change did not achieve proper consensus. I have invited them to comment here, but they so far have declined.

Regarding the earlier conversations of whether the new templates were preferable, to summarize those who chose to respond:

• Gerry Ashton strongly approved based on handling of Julian dates
• Ohconfucius "completely agree"
• Tony1 "The community takes a conservative line now on needless complications in date formatting."
• Pigsonthewing did not favor deprecation of the old template, but did not make the argument that the old template was preferable over the new template.
• Geonick from the discussion before it relocated to MOSNUM: "I support the proposal of J JMesserly and favor the  (0009-11-01): Before all, Wikitext must remain human readable. (BTW: There's in fact currently no chance - even for programmers - to enter a date like "7 December 1941 8AM HST" using  ()."

This talk page has been getting heavy attention to the date linking/ arbcom investigation, so I think it was reasonable to assume many more people than these 6 individuals were aware of the discussion and felt their POVs were being expressed by those who did choose to respond. I don't think it is fair to assume that this was a consensus of only a half dozen contributors. But perhaps there are those that disagree. To give the issue fair airing, I raise the question again.

If anyone feels the old templates are preferable to the new template, please speak up. For the record, here is a side by side comparison of one of the templates (old templates are without the dash):

Comparison of syntax between old and new

	wikitext	article
Old	{{Death date and age|2008|1|11|1934|5|2|df=y}}	11 January 2008(2008-01-11) (aged 73)
New	{{Death-date and age | 11 January 2008 | 2 May 1934 }}	11 January 2008 (2008-01-12) (aged 73)

Users can format the date in a wide variety of formats besides month first and day first flavors including the less usual:

• 22 November 1963 1pm CST
• Sunday, December 7, 1941
• 1963
• 1963-11-22

If the contributors prefer to use templates or links they may do so in the final parameter, eg:

• Birth date of James Cook: {{Birth-date| 7 November 1728 |{{OldStyleDate|7 November|1728|27 October}} }}

  produces: 7 November [O.S. 27 October] 1728 (1728-11-07)

These plain text date templates are in use in a few thousand articles and do a number of other things that the old template cannot do (fuller enumeration at Village Pump). Due to the number of variations and parameters required for robust date handling, it will be technically challenging to add these features to the old template without further complicating its already torturous syntax. Any and all comments on this issue are solicited and welcome. -J JMesserly (talk) 03:10, 20 March 2009 (UTC)

One concern is that the existing birth/death templates don't currently have a centralised discussion - the proposal was mentioned in Template talk:Birth date but not in Template talk:Death date or Template talk:Birth date and age. The proposal needs to go on all potentially affected template talk pages, to ensure coverage. The new format seems to be a useful advance in technology, but there are likely to be complications with handling of date formats e.g. if a bot is migrating the templates, what safeguards will prevent inappropriate conversions between mdy/US and dmy/International date formats? Dl2000 (talk) 03:36, 20 March 2009 (UTC)

Actually, I wasn't proposing wholesale conversion, but if such a time comes, the bot transfer is actually trivial. If df appears in the old template, then the bot saves with a subst of #time:j F Y| with a parameter of YYYY-MM-DD extracted from the old template. No big deal. The only exceptions are with extreme dates, with double digit years, but those are invalid anyway because contributors are not supposed to use the old templates with non-gregorian dates (due to microformat rule that dates are emitted as ISO8601, which means everything must be normalized into a gregorian date even if the period predated the gregorian calendar). The new template can handle Julian (see {{birth-date}} gregorian parameter), but having discussed this with Julian experts here, automated conversion of these is problematic, so basically everything prior to 1752 is suspect and needs human attention. -J JMesserly (talk) 03:54, 20 March 2009 (UTC)

JJ Messerly, thanks for this extensive post. I'm a computer dummy, so forgive me if I ask seemingly naive questions.

• Is this template intended for infoboxes alone? Infoboxes are where I've mostly seen these types of template. I've noted that they don't seem to be useful at all in terms of added value to the fixed-text, plain writing out of the dates, with the exception of the calculation of the subject's age, or age at death.
• Please assure me that it doesn't link the dates.
• The table above shows just the death date; but surely you'd want to produce a range: 2 May 1934 – 11 January 2008 (aged 73).
• In the conventional case of expressing only start and end dates, I count a string of 54 characters—which must be copied or learnt by the editor, and provides much scope for error—against the keying in of 28 characters without the template (38 with the age in parentheses).
• I guess it's hard to calculate age, and people were getting it wrong by one year? Is that why this template was developed? Simple rule: subtract death year from birth year, and subtract a further 1 if the death date is earlier than the birth date.
• I note D12000's comments above. Since everything before 1752 won't work, the template is inherently limited. Do users know this fact? Have there been many instances of its use in breach of this limitation?

Thanks. Tony (talk) 07:32, 20 March 2009 (UTC)

There is no need for assurance on the linking of dates for the moment because the arbcom committee has put a temporary hold on date delinking, so if this template does not link the dates it is in contradiction to the determination made by arbcom.--Kumioko (talk) 09:28, 20 March 2009 (UTC)

Kumioko: As I have said before, this template has nothing to do with date linking or delinking. If you do not believe that is the case, Kumioko, then please say so.

Tony: Bulleted responses below:

• Re: Infobox usage. No they are not limited to infoboxes, but in usage, I see the same as you. With the new templates, there is one variant for events that has no analog with the older templates so I didn't mention it. The common usage for that is like a military conflict where this a table of engagements or order of battle at the end of the article. With microformats, you get to see the thousand foot view of each of the engagements through the mapping function. EG: go to USS_Queen_of_the_West and in the gallery section you can click the map of events options and it will launch google or MS maps with all the locations in the gallery. If you use Operator (extension) then you can go to the locations individually or can see all of notes and dates for each of the events depicted in the gallery. The wikitext will reveal all the data that is getting shoved into the microformats to do this stuff. It's not a typical example, I kind of showcase the most you could do with it, so it is kind of cluttered with more detail than I expect people would want to put in.
• Regarding your observations about utility for text, you are too polite. I'll be more brutally honest. If you don't care about microformats, the date templates are completely useless for anything at this point. I suppose there is a remote chance that would change if folks decide they wanted to do autoformatting of some flavor but now there is no such support, and large numbers of people are dead set against it for very understandable reasons. I really don't care which way the autolink autoformat issues blow. I can see both sides. If you want age calculation, contributors can simply use {{age}}. The old templates do format dates, but it's a heckuva lot easier to simply type the date than convert to numbers and then be sure not to forget to add the |df=y flag if you are of that persuasion. It's silly.
• The new templates don't link dates. Full disclosure though: It does allow contributors to place whatever they want in the final parameter. My motivation was to allow templates such as for old style dates, however it does allow contributors to manually put linked dates in there. So it neither links nor delinks. In my edit practice, if the article used a date link for the birth or death date then when adding the new template, I leave the date link as it was, using the final parameter. If it had no date link, I don't add one.
• The old template didn't provide a range (birth date to death date) as you suggested, but as a feature it would be trivial to add that formatting option, or make it default if people really wanted it always to appear that way. I don't care. Some folks probably want to keep the infobox uncluttered, but whatever. If folks want it, it's easy to do. If people want yet different flavors of formatting, they use the final parameter.
• I can figure out ages at death pretty easily too. If we wanted to get pedantic about it, there is an odd case with leap years where you can actually be in the same year and more than 365.25 days have passed, but no one much cares about that level of accuracy. Anyway, folks also use calculators to add 22 plus 44 so ok whatever they can use the age template- besides folks do need it for currently living subjects. Regarding Microformats, it is not so easy. The emitted end dates must conform to ISO8601, and according to microformat rules, the end date is actually +1 whatever the unit of precision is. So if you only know death date is 1934, then the microformat value emitted is 1935. If December, 1935, then emit January 1936 and so on. Pretty weird spec, but I've confirmed with the microformats.org community, and so that's what this template does. The templates stick some junk in spans usually with display off using a class that doesn't do anything but gets recognized by microformats parsers. I don't think most contributors care to know that kind of nonsense, and frankly, for dates, it doesn't offer a whole lot of value except for maybe living people. I suppose those folks can get added to your Yahoo contacts database, but I don't talk to Anthony Hopkins much these days so if I forget his birthday, I don't think he'll notice. The killer app for microformats now is mapping, and the geotagging wikiproject folks have that pretty well covered. As for dates, it is somewhat speculative what the value is. Yes, you can store the date and location of the UK forces engaging the Argentinians at Goose Green. But not many folks need to have that in their Google calendars. It could get interesting with future apps- like a google earth with the 4th dimension of time, and the photos displayed at locations are of civil war events, etc. The only way they would know what dates correspond to the events is if they are encoded somehow in a structured way. That is why the date templates are important.
• It wasn't D12000 who brought up Julian, it was me. The old template does not handle Julian dates, the new one does. The dates may be specified in julian. The user must specify the conversion to a gregorian date if the emitted value is to be valid. The old template has no such provision. It could be added, but then you'd have to add 3 more parameters for the gregorian date conversion. Gets real nasty looking at all those numbers. Anyway, with the new templates, here is an example of a julian date:

Death-date and age examples (colors for emphasis only):

Julian dates demo. Sample below displays 30 May 1672 (1672-06-10) (aged 49), with invisible microformat dtend date: 1692-06-10 {{Death-date and age| 30 May 1672 | 15 May 1623 | gregorian=9 June 1672}}

• Same idea for birth-date and age etc. There are some calculators that figure the gregorian dates accurately, but things get squirrelly around Roman times because, as I had it explained to me, there was a lot of confusion with laws resetting days and for example Augustus's birth day could be off plus or minus a few days due to uncertainties. So fine, the template handles uncertain dates so the user can simply specify the month a battle took place, so long as they are certain it maps to what the gregorian month would have been. So actually, {{start-date}} and end-date currently handle dates from -6999BCE to 6999AD. Anyway, for practical uses most of our old dates are julian and the calculators work fine on those. So long as we make sure contributors cite the source text confirming the date is Julian, we are on solid ground for emitting proper microformat dates. It's a judgment call whether we recommend folk be hard ass about that requirement because there aren't a whole lot of apps that can use such old dates. But formally speaking, if the dates aren't normalized into gregorian time, then they are not conformant to the microformats spec.
• Sorry for the length, but it couldn't be helped. Hope this helps answer your questions. -J JMesserly (talk) 09:48, 20 March 2009 (UTC)

Maybe this has been discussed before, but I'm a bit worried. This will complicate reuse by other language Wikipedians year|mont|day with numbers is universal req. by everyone everywhere. A somewhat random English writhing style is not. The second worries is that a single field is (currently) not possible to extract part of it tho manipulate, so yo cannot directly extract the year without going through the #time function. (Mediawiki:Extension:StringFunctions#.23sub: is not supported) Nsaa (talk) 19:30, 20 March 2009 (UTC)

Actually, #time is a lot more versatile than you think. EG: somewhat random english writing date: {{#time:d F Y|February 16, 1356}}

• Japanese
• German
• Russian

Besides, you are saying that the article text is being translated to another language, but the translator's first pass with a translation program failed to translate January -> Janvier? That's a bit of a stretch, isn't it? And then you have the problem that the old templates exist on few other wikis so there is nothing to use the numbers with anyway. Take a look at them. You are imagining a problem that doesn't exist. I tell you what though, I would be happy to port the new template to a half dozen languages, and you know what? They will use en:WP data just fine because #time will do all the work for me.

You lost me on the point that it is "not possible to extract part of it to manipulate". You don't extract a single field with the old template either. You just put in the numbers out out pops the date. Unless you are talking about some external perl or python script, I don't understand the problem you are describing. If you mean an external script, it is trivial to do the date transformations with date functions from those libraries. If you are talking about a WP template perhaps generating input for the new date templates, what's so bad about extracting a field using #time? -J JMesserly (talk) 20:46, 20 March 2009 (UTC)

Look at the Japanese and Russian example and you will see the problem using text insted of the standard numbers year|month|day on other languages. The #time only interprets English written names etc. So on basis of this it's not an good idea to use natural languages. As pointed out below, using of these old templates on the form year|month|day is currently no problem. Nsaa (talk) 08:00, 21 March 2009 (UTC)

I've set up a conversion template at the norwegian language wikipedia, see no:Mal:Birth_date_and_age. This is very usefull for smaller wikis using for example infobox-information from biographies at enwiki. Nsaa (talk) 08:06, 21 March 2009 (UTC)

(outdent) This discussion has more implications than simply presenting another treatise on what is wrong, in J JMesserly's opinion. There are a myriad of issues concerning what on the surface just seems to be a discussion on the templates and presenting the discussion as a re-examination of the change that has already been implemented. I started my discussion on the WPBiography page and then made a request at AN/I for assistance in determining where the overall issues be presented. I saw no point in bringing it back here only to be met with a barrage of technical explanations that avoid the application issues. By reading the introduction to this section, I see my concerns were warranted. This issue has implications concerning almost all of the Wikipedia community of editors.

Since this has moved to here, I have a myriad of issues with what is going on here and I will try to cover them as concisely as possible. If anyone has need for links to discussion, please say so. My issues concern the wider effect of a change to the MOS and the process for that occurring. Also, please note that I am not skilled in discussing smaller coding issues, my post concerns the process by which a change in the MOS has been made and the lack of general community consensus on this change. The change in birth/death templates in biography effects 624,144 articles out of 2,797,421 (as of Wednesday October 18), that is pushing 25% of all Wikipedia content. I have no idea how many other project articles are effected by variations on the start/end templates. However, once a change to the MOS has been made, despite J JMesserly's somewhat naive assertion to the contrary, there is little to no choice for editors to simply "opt" not to use the recommended template. The first line of discussion at that point is "this is what is recommended by the MOS". At that point, the option becomes trying to render a change to the MOS, which is where this all began.

J JMesserly argues most professionally. In fact, to those of us who fall into the non-technical savvy category, his responses are a bit overwhelming and the bottomline issues tend to get lost in his repeated explanations of technicalities. I mostly cannot comment on the finer points of coding language, this is more about the application of a change. That is, in fact, my first issue. It is/was discussed in regard to how the template functions and not in terms of how the discussion went from "here are my new templates, what do you think of them" to a change in the MOS and subsequent changes to a family of infoboxes without the consensus of the wider community as a whole. The templates that were presented here for discussion were the start/end date templates, nothing else. Yes, I recognize that birth/death templates are an extension of that, but that point was never discussed. The merits of time zones/time of day do not apply to the use of birth/death dates. It is inconsequential to that.

Secondly, I take exception to the claim that there was consensus determined on this page for the change to the birth/death template used in articles and a change to the MOS, for which J JMesserly asserts that this discussion or the next was a consensus for changeover. That initial discussion ended with two statements:

• The old template {{start date}} does do autoformatting, I leave it to the champions of that template to respond on their position regarding autoformatting. -J JMesserly (talk) 1:00 pm, 11 February 2009, Wednesday (1 month, 7 days ago) (UTC−5)

• {{Start date}} can have auto-linking/ formatting of dates, or not; whatever the community decides. It used to Auto-link dates, but this was removed recently (not by me). Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 2:42 pm, 11 February 2009, Wednesday (1 month, 7 days ago) (UTC−5)

No further discussion occurred in that section, and it isn't fundamentally good practice to propose something and accept it as fact when all you do is leave the door open for opposing discussion. Opposing discussion was attempted (based on points I don't necessarily understand). However, no response should never be taken for assent.

The discussion then changed to "Moratorium on futher conversions to use older template:Start date." Your statement closed with: "Since there are templates that achieve the same goal and are far more readable, there is no need for conversion to the old {{start date}} template. Presumably if no one comments, this principle is recognized as well supported by the example above."

Two persons agreed with the principle. One said "Completely agree. Such a template should not be used if it can only be understood by persons of an IQ greater than ten" and the other said "I agree for a different reason: the template is incapable of working with non-Gregorian dates, and it is difficult for a bot to tell what calendar a date is in." There was no call for consensus to change the MOS. So we had two people say yes, in principle we agree. Also note, the proposal was a moratorium to conversion - when those templates are being used on tens of thousands of articles and have been for 2 1/2 years now, calling a moratorium on conversion doesn't make much sense to me. Using the agreement of two others to a moratorium to conversion does not translate to changing MOS and pages effected by that, not in any sense.

Based on those discussions, J JMesserly posted this notice on the talk page and gave people 9 hours - on a weekday - to oppose. Note that his request resulted in changing the recommended template in the MOS. He then proceeded to change birth/death date templates in biography project infoboxes (though he missed some). Perhaps I lose something by having worked on Wikipedia for years rather than since November, but I am fairly positive that this is not the process by which large scale changes occur and my feeling is that an endrun was made around normal process. If J JMesserly did not realize that, or he did not realize that this action had such wide implications, fine. However, in application, this does have many ripples.

When I first noticed J JMesserly changing infobox templates, I approached him about it. His reply was My survey is not especially large and has done a few dozen chefs to and a few dozen criminals. I am examining variations in date usage and shall be moving to other person categories. No exhaustive conversion is being conducted, and in fact many have no date encoding. The main reason for existence of these templates is microformat emission, and neither birth date and age nor death date and age do it. Actually, I didn't think anyone really cared. They still do the df versus mf display- in case that is what concerns you. He also asserted somewhere that he wasn't changing extant templates, only adding to those that didn't have templates. However, that isn't quite true. Meanwhile, I'm left with thinking that perhaps I just didn't ask the right question and any further elaboration on what was going on with MOS was certainly and most conveniently not mentioned.

Then I discover that the "consensus" discussion had already occurred by that time. Also I have discovered that, not a few dozen chefs articles and a few dozen criminal articles were using this template, but in fact, over 2500 articles were using the new templates. Implementing use of the template, whether it is being added to bios that don't currently have a template, or changing over to the new template isn't that far removed, and that is a subtle distinction that might get lost in verbal conveyance and in the shuffle. I'm sorry, but this seems a bit deceptive to me and seems to be outside of the process we should be following in implementing a change that has widespread implications. Perhaps a simple Support or Object, a straw poll, a community wide consensus or discussion? But based on a couple agreements to a moratorium on conversion? Nope.

An argument has been made that it only takes a small mistake in entering data for the old template to display dates incorrectly. The fact is, however, if a large mistake is made, the template saves to show an error. If a small mistake is made, the error is noticed when one looks at the product. Going back to the Albert Einstein article linked above, that is no different than if dates were entered incorrectly with the new template, whether that concerns how the date is displayed or what date is displayed. That the {{birth date}} and {{birth date and age}} templates have been in use for 2 1/2 years with little problem, except for new users who have difficulty using any templates correctly, seems to me to minimize concerns that they are too complicated to use. Perhaps it should be considered that it isn't an issue of any significance on the old template or the new. However we dummies who aren't smart enough to enter things into a template have been successfully doing so now since August 2007.

Finally (I think), let me address my concerns regarding the arbcom injunction and the date linking arbitration. I don't have an opinion on the use of or discontinuation of datelinking. That is not a point of concern regarding this, on either my part, or apparently on the part of J JMesserly. But concern or not, it does have an effect that I hadn't really considered in that regard until someone else made a comment and I really thought about the effect of the change. Technically, no, the new templates do not link dates, however they also are not easily changed to do that, should the arbcom decision be to allow datelinking. J JMesserly told me at one point that should linking be allowed, it only takes a small change to the old templates to encode linking again and would take effect immediately on all articles using that template. One small change to two or three templates. J JMesserly's template cannot be reformatted to easily allow linking, should that be determined by arbcom. The only way to use the new templates that would allow linking would be for the user to have to implement additional parameters of the template in order for the template to display linked dates. The new one does not automatically allow for linking to be re-implemented, without an additional parameter in the template that the user must add to link the date. Presently, if the linking parameter is used, then effectively, dates are being linked. If it is not used, linking cannot be used regardless of the outcome. In that, using the template effectively violates the spirit of the injunction against linking or delinking as I understand it. It doesn't really matter about an opinion on datelinking, what seems to me to matter in regard to the injunction is the effect of a change. That this template has already been incorporated into the MOSNUM, which implements and effectively mandates the use of the new template, which includes extended and additional date linking instructions, on a wholesale basis, is what I think may violate the arbcom injunction in practice, if not in word.

Sorry for the length of this, I felt I needed to cover all of my concerns. Please, if anything is unclear to the non-technically minded reading this, ask and I'll try to respond or find the links to confirm anything I've said that is not clear. Wildhartlivie (talk) 06:58, 21 March 2009 (UTC)

Thanks for an excellent outline of why not to implement this change. The old style of giving the dates follow the international standard ISO 8601 both in the format used for each element and the logical sequence outlined in the standard and I think it's a big step backward going for running text formats like 14 februar 2008, February 14, 2008 and a web of other alternatives NOT in accordance with WP:MOSNUM. This is templates that should conform to standards. Adding free form input is a bad idea. Nsaa (talk) 08:17, 21 March 2009 (UTC)

arbitrary break for editing

I don't see it this way at all. The problem with the old templates is that because the input is not in one of our preferred formats, there must be a conversion to one or the other. As the old templates stand, they produce a default to US-format dates, which is inappropriate for most of the world. And of course if they defaulted the other way, that would be inappropriate for US biographical subjects, of whom we have one or two on the books. Forcing a conversion to the non-default format involves entering an arcane code ("df=y") which flies right over the head of the average editor. With the new templates, editors need not worry overmuch about syntax - just enter the dates and the software works out the age. If the dates are not in one of our preferred formats, someone will come along and fix them in due course. Making life easier for editors, rather than running them through an obstacle course of syntax and forms, is something to be applauded. --Pete (talk) 11:29, 22 March 2009 (UTC)

Well, there are two points in that. One has to do with whether or not date-linking is accepted or not by arbcom. The other has to do with what, until earlier this morning, J JMesserly was advocating that in order to link dates [1] one had to add a special parameter to the new template coding, so I see little difference between doing that and adding a special parameter to the old one to force formatting of the date. In fact, it only takes four keystrokes to do so. Depending upon the format of dating that is required to produce the correct view of the date, I'm not so sure that using df=y flies anymore over the head than adding the day before the month. Then if date-linking is endorsed or supported by arbcom, in the old templates with linking enabled, user preferences take over anyway.

Your points have to do with date-linking, not templates. Being able to add dates, whether linked or not, in whatever format the editor wishes, has got to be a benefit over something that forces editors into using a format we don't support and half the time spits out the wrong format. --Pete (talk) 13:10, 22 March 2009 (UTC)

Linking is one thing, but my points also have to do with what is spit out and how it looks when it is. The format that is spit out depends on adding four keystrokes. There is no reason to think that anyone would enter a date in the correct format anymore with one template, which if linking is supported by arbcom, would be spit out the way the reader wants to see it depending on their user preference settings, than the other, which can't be changed by user preferences if it is put in March 22 rather than 22 March. It is still dependent on how the editor enters it, the difference is in how easily it can be converted to appear the way someone wants to see it without going in and changing it in each article. I don't see how the new template makes user error any less likely, anyone who just blanketly asserts that no one can use the template without a post-graduate degree underestimates everyone around him and assumes we can't learn. I'd like to see the stats that say the wrong format is spit out half the time. No template is error proof. Meanwhile, how easily that is corrected on a site wide basis could be an issue if linking were returned. But at the moment, my main issue is still how this became part of the MOS without specific consensus to do so. That is something that effects a whole lot more editors than take part on MOSNUM, and happened without their input, and in a LOT of cases, without their awareness. This is something that I believe needs to be a en.wikipedia wide consensus, not something decided on this page alone because this effects almost every editor who edits a page, in one way or another. Wildhartlivie (talk) 13:45, 22 March 2009 (UTC)

Using templates at all is a big step for new users, so get rid of them all. Especially the {{cite web}} templates doing text totally unreadable and completely impossible to edit for anyone not familiar with the (english) Wikipedia setup. So yes there's always a problem getting people to understand the way this wiki works and it's fine to try to adjust that. But adding free form input is not the way as far as I can see. It also adds an interpreting layer (and a req. to use the parse function #time for that) for the templates that may fail.Nsaa (talk) 18:35, 22 March 2009 (UTC)

Can we discuss this without resorting to hyperbole? no one can use the template without a post-graduate degree and get rid of them all are fine examples. Linking dates is a separate issue and using the new templates as a way to beat the linking drum isn't helpful. When I say that the wrong format is spit out half the time using the old templates - that's because we use two date formats and the template outputs only one. This problem doesn't occur with the new templates. --Pete (talk) 03:15, 23 March 2009 (UTC)

My hyperbole was in response to comments J JMesserly has made that the old templates are too hard for editors to use, which is factually his point of view and I've asserted that is incorrect many times. My issue here is not to get into yet another discussion about Julian dates, or how this parameter works or anything else other than the templates were written into the MOS without clear and decisive consensus by the community to do so and has been extended now to insertion into biography infobox templates. This keeps getting ignored in the mix as I feared it would be when it was taken to this page. It's obvious from the discussion above and below that there isn't a final decision about the over-all using of these templates, and far less that the consensus is to put it in the MOS. That is the overriding issue at this point, not continued discussion about the pros and cons of the templates. A MOS change should not have occurred until these other issues were ironed out and yet it has occurred. That needs to be reverted until the other issues are completely addressed and then these templates be presented to the WP project for consensus on use, not put them in and oops - now we have issues. That is the process and is not what has occurred. I'm not quite sure I know why anyone is overlooking that important point. Wildhartlivie (talk) 05:30, 23 March 2009 (UTC)

The new templates are better than the old, for reasons explained above by various editors, and I can't see any valid disadvantages given here in discussion. Just hyperbole and irrelevant points about linking. What's to discuss? If you have some good reason for standing in the way of progress, speak up. --Pete (talk) 10:11, 23 March 2009 (UTC)

Speaking of hyperbole - If you have some good reason for standing in the way of progress. I have noted a lot of issues with this, including the most relevant which is an endrun around proper process for consensus and change approved by the en:WP community. Is there some valid reason why you ignore and refuse to address that? Wildhartlivie (talk) 10:48, 23 March 2009 (UTC)

No it's not better. I've pointed out the following flaws above. 1. it's not possible to reuse the logic on other language projects (#time only understands english), 2. it introduce the possible adding of non WP:MOSNUM dates as parameters, 3. the form yyyy|mm|dd has been established as defacto standard for most of the date parameters used at en-wiki and it's impossible to misinterpret (see ISO 8601). Nsaa (talk) 21:15, 23 March 2009 (UTC)

From an editor's point of view, none of those objections matter a fig. From my point of view, I think the new templates are a good step forward. --Pete (talk) 22:29, 23 March 2009 (UTC)

Using these templates

It's an bad idea to massively starting using this as done on Template:Infobox cricketer biography for example. Nsaa (talk) 08:43, 21 March 2009 (UTC)

What syntax do you propose for {{death date and age}} to handle julian dates? -J JMesserly (talk) 18:32, 21 March 2009 (UTC)

How about a template for articles requiring Julian dating? One that doesn't effect the other tens of thousands of articles that already use a more than adequate template for their purpose. I believe that was proposed somewhere. Wildhartlivie (talk) 04:19, 22 March 2009 (UTC)

You still need three dates. What do you propose the syntax be? -J JMesserly (talk) 08:14, 22 March 2009 (UTC)

It's kind of pointless to ask someone who has said she isn't coding proficient to propose coding syntax. What I do know is it also pointless to implement a template for use on all the tnes of thousands of articles to cover Julian dating, when it is not an issue on them. Wildhartlivie (talk) 08:30, 22 March 2009 (UTC) (added) Then there is the point made by Nsaa regarding translation of text dates and the translations offered above - what are the d F Y if not formatting code? Wildhartlivie (talk) 12:14, 22 March 2009 (UTC)

(undent) I am puzzled. You have told us that the new template cannot be made to emit linked dates should arbcom allow that. If you aren't proficient with coding, on what basis did you make this assertion? Actually, you assertion/assumption is not true. Autolinking could be added back to the new template as easily as it can be added back to the old template.

You didn't understand my point. I was demonstrating that no translation is necessary. The d F Y stuff would be embedded in the birth and date templates on the other language wiki (if they wanted these templates) and users would not see such stuff. So, contrary to Nsaa's assertion, translators could just paste in the date directly, but in reality as I pointed out, their translation program would have switched the month name anyway. -J JMesserly (talk) 17:05, 22 March 2009 (UTC)

No the #time parser function do not translate other languages than English as far as I can see. It doesn't work for Russian, it doesn't work for Japanese, and not for Norwegian, see your own and my examples below

• Japanese
• Russian
• Norwegian

Nsaa (talk) 18:46, 22 March 2009 (UTC)

Now, regarding syntax, you very well understand my question and you very well understand the syntax of the old templates. You don't have to understand anything about coding to propose syntax. Would you not propose a syntax conforming to the syntax of the old set of templates? Wouldn't your prefered syntax for Julian be something like:

Comparison of proposed Julian date syntax- old versus new

	wikitext
Old	{{Death date and age|1672|5|30|1623|5|15|1672|6|9|df=y}}
New	{{Death-date and age| 30 May 1672 | 15 May 1623 | gregorian=9 June 1672}}

One of these is very difficult to manipulate and one is not. One of them conforms to the goal of wikitext, to make it simple enough for anyone to be an editor, and one does not. Which is which? -J JMesserly (talk) 09:09, 22 March 2009 (UTC)

Personal note: I shall be on wikibreak until 26 March, so I shall be silent on any posts until then. -J JMesserly (talk) 10:07, 22 March 2009 (UTC)

Do yourself a favor and stop presuming that you know what I know. I don't understand your question about how syntax would work in a different template, I don't know and I don't do template development coding. I work from the template according to directions. I don't know how to write it otherwise. Because of that, I do not know if there is another way to manipulate the data. This is the explanation you gave regarding how your new template must be used to link dating. I find it interesting that until this moment, you've not said that you can change the development coding to emit date-linking without the use of an additional parameter, so I have to think you've done a lot of work since yesterday's posts in order to suddenly assert that. However, as I said above, no one of whom I am aware who adds birth and death templates on any kind of routine basis has had a bit of difficulty in using the old template, so the addition of one further date isn't too far above anyone's head. Meanwhile, this part of the page does not mean the discussion above about consensus and the events surrounding is moot. I won't be drawn back into a coding and jargon talk-around when my issue regarding consensus has not been addressed as of yet. Wildhartlivie (talk) 10:27, 22 March 2009 (UTC)

You assert I have changed my position. I have not. "Date linking (aka "user preference date formatting") could be trivially restored to both the old and new template families if the community reversed its decision on that matter."[2]

Now to the matter at hand. "Julian" is not jargon. As explained prior to this, the old template cannot be used with Julian dates as they stand today. Even advocates of the old template admit this. What they need is a third date, (the gregorian translation of the julian date), and the only way to get it is with syntax like the above examples.

Which is easier? -J JMesserly (talk) 17:53, 22 March 2009 (UTC)

I've not been in a deep discussion about usage of julian and gregorian dates, but as far as I'm conserned a date parameter at should always refer to the (Gregorian_date#Proleptic_Gregorian_calendar Proleptic) gregorian date. if not the case a clear message should be given saying that the template input is julian (in the above example it should be someting like borndatetype=juliansweden1750, deathdatetype= and the template should add a cobnversion routine (it's always possible to convert, but it should be managed one place (the problem area is But for the period between the first introduction of the Gregorian calendar on 15 October 1582 and its introduction in Britain on 14 September 1752, and dates befor year 1, proleptic uses year 0 (and it's then able to be used in a counting shema like how old. See [3], a full list of changes) Nsaa (talk) 19:04, 22 March 2009 (UTC)

The normal custom for areas where the Julian or Gregorian calendar has been in use for millenia is to use whichever was in force at the time and place being described in an article. (What to do in articles that cover wide geographic areas, or areas where neither calendar was used until the 19th or 20th century is more difficult.) Expecting editors to put the proleptic Gregorian date in templates would be a departure from custom. This would require a brand new template, to avoid falsifying instances of templates that were written using the normal custom for English-language writing. Also, conversions due to departures from Julius Caesar's intentions, August restored the Julian calendar in 8 BC, and the correspondence between the proleptic Julian calendar and the actual calendar observed in Rome is uncertain before 8 BC. Finally, there is no firm correspondence between using the proleptic Gregorian calendar and the method for designating years before 1 BC. The use of 0 and negative years, or the abbreviations "BC" or "BCE" are all possible. --Jc3s5h (talk) 20:06, 22 March 2009 (UTC)

Nsaa's opionion is also in direct contrast to WP:MOSNUM#Calendars, which for many years has stated that the Julian calendar should be used for dates before 15 October 1582, with the additional requirement that such dates "should not be converted into the Gregorian calendar". The Julian calendar was used until 1918 in Russia and until 1923 in Greece, so the problem area is much more extensive than 1582 to 1752. The Julian proleptic calendar must be used before AD 1, because all earlier Roman dates were irregular, including the supposedly 'Julian' dates between 45 BC and 1 BC. In general, this irregularity makes any conversion to the proleptic Julian calendar difficult or impossible (see Julian calendar#Leap year error). Furthermore, the Julian proleptic calendar does not have a year zero—only astronomical year numbering uses a year zero. In the NASA Julian date converter cited by Nsaa, "Julian date" does not refer to a date in the Julian calendar, but to a multidigit contiunous count of days, which is 2454913.47543 as I write this. Nevertheless, this astronomical "Julian date" is preferred for calendar conversion. If a date in one calendar is first converted into an astronomical Julian date, subsequent conversion into a date in any other calendar is simplified. Conversion can even be difficult in modern times—between 1700 and 1712 the Swedish calendar was neither Julian nor Gregorian. — Joe Kress (talk) 22:25, 22 March 2009 (UTC)

Thanks for a great explanation. Although I'm not sure why the Julian date was up for discussion in the first place regarding templates here. If I understand Joe Kress above so is it possible to convert what ever date to a Julian day and then base all calculations on this (for example age). If this is so it should be possible to give any kind of date, but as long as it's not given as an gregorian it must be specified, so the proper konversion mechanism can be applied. But I still don't see why this is a bigger problem for the current style (YYYY|MM|DD) vs. the proposed new one (DD MMMM YYYY/MMMM DD, YYYY and a host of others). Nsaa (talk) 23:54, 22 March 2009 (UTC)

One of the templates under discussion, {{Birth date and age}}, according to its documentation, creates hidden html that contains hCard microformat data about the birth date. However, the hCard spec requires that dates always be given in ISO 8601 format, and ISO 8601 requires that dates always be Gregorian or proleptic Gregorian. Yet, the documentation makes no mention of always entering dates in (proleptic) Gregorian, so naturally editors will use the calendar in force at the time and place of birth. If that date is non-Gregorian, then the hCard data will be erroneous. There is no provision to mark the date as being in the Julian calendar, and no provision to provide a correct Gregorian date just for the hCard data. So that is why Julian dates are relevant. --Jc3s5h (talk) 01:01, 23 March 2009 (UTC)

In response to J JMesserly (talk) 1:53 pm, Yesterday (UTC−4): My reasons for not wanting the discussion to come back to this page is completely borne out. My issue here is not to get into yet another discussion about Julian dates, or how this parameter works or anything else other than the templates were written into the MOS without clear and decisive consensus by the community to do so and has been extended now to insertion into biography infobox templates. This keeps getting ignored in the mix as I feared it would be when it was taken to this page. It's obvious from the discussion that there isn't a final decision about the over-all use of these templates, and far less that the consensus is to put it in the MOS. That is the issue at hand that I have problems with, not continued discussion about the pros and cons of the templates. A MOS change should not have occurred until these other issues were ironed out and yet it has occurred. That needs to be reverted until the other issues are completely addressed and then these templates be presented to the en:WP project as a whole for consensus on use, not put them in and oops - now we have issues. That is the process and is not what has occurred. I'm not quite sure I know why anyone is overlooking that important point. Wildhartlivie (talk) 05:38, 23 March 2009 (UTC)

Why should we change the way things work around here? If enough people hate the new templates there'll be a community backlash. I don't see that happening, just one or two people grumbling a bit. --Pete (talk) 22:33, 23 March 2009 (UTC)

We shouldn't change how things work around here, there is a process for implementing a change, and it wasn't followed. One or two people aren't the only who have complained about the templates, when they stumbled upon the fact it had been done. Messerly doesn't mention that, but there have been more than a couple people questioning the templates in various places, including his own talk page. Meanwhile, most people don't know what he did to get the templates into the MOS, and he pointedly refuses to respond about that. Meanwhile, the ones who have said anything have been told "It's recommended by MOSNUM." That's a roundabout rationale. "Why did you add this?" "The MOSNUM recommends it." That is one of issues with Messerly's more than naive assertion that editors can always opt not to use it. The argument that it is in the MOS effectively renders protest moot. What the editors don't know is that the templates are in the MOS mostly due to Messerly's misrepresentation of a discussion as a consensus to change the MOSNUM templates to the one's under discussion here. That is effectively a unilateral action that undermines the whole concept of community consensus. Wildhartlivie (talk) 23:55, 23 March 2009 (UTC)

I think that WP:BOLD has worked very well here. I'm totally in favour of the new templates on an ease of use basis. You don't need to go looking up the instructions to know how to use them, and you don't need codes. I'm upgrading articles to the new templates as they come up on my watchlist. I'd love to see a bot go through and update the lot. --Pete (talk) 01:12, 24 March 2009 (UTC)

I think snow job works even better. There's a huge difference between consensus and misrepresenting something as consensus in order to pull off a change. And yes, you've made it clear that you like them. How interesting that Messerly has bent over backwards to reassure any questioners that there was no mass changeover was occurring, that the only articles in which his template was being added had no prior template, and that he was "a long way off" from anything like a bot run. the only discussion which seemed to have a consensus was a moratorium on "conversion" to the old template, which was meaningless, since no "conversion" was occurring. I find it disturbing that you have no issue with the total disregard for WP:CONSENSUS and support the overriding of that. In fact, I think what is more important here is Wikipedia:CONSENSUS#Level of consensus which says "Consensus among a limited group of editors, at one place and time, cannot override community consensus on a wider scale. In the case of policies and guidelines, Wikipedia expects a higher standard of participation and consensus than on other pages." Two people agreeing with a third on a moratorium on "conversion" does not equal a higher standard of participation and consensus to change a policy or guidelines, it steps on it. Wildhartlivie (talk) 06:49, 24 March 2009 (UTC)

Calm down, please. Discussion on changing these templates to eliminate the problems has been ongoing for years. It's finally happened. Neither you nor anybody else here has demonstrated any significant practical difficulties with the new templates, and it looks like you are making a fuss for the sake of it. --Pete (talk) 08:40, 24 March 2009 (UTC)

I am calm. Discussion may have been going on for years, but discussion is one thing and community consensus for implementing a change is another. Others have brought objections to the templates and they have been talked down and discounted. Talk long enough and down enough to people and they give up, that's a bad strategy. I am making a fuss for the sake of it? No, I am making a fuss because J JMesserly ran an end-game around proper process and misrepresented that a consensus existed for the implementation and insertion of the template into the MOS. I have asked him repeatedly for the link to the consensus to change the MOS. None has been forthcoming - there's a good reason for that, there was none. I'm still curious as to why that isn't a problem to you, no matter whether you are for the templates or against them. He's stopped responding and you've started. This is an issue for a wider forum than the folks who happen to monitor this page. This is an issue that effects thousands upon thousands of articles, scores and scores of editors. At least J JMesserly gave lip service to not changing out the templates that exist, although he has. Again, the proper widescale forum needs to be determined for where this needs to be. It's certainly not in this project page. Whether the template is kept or rejected, it's not for J JMesserly using the agreement of two to a "moratorium on conversion" to the old templates, which is still a bit off-topic, to just pick up and do it, it is up to the community at large. It's a corruption of the process otherwise, and that is a point of concern. I'm tired of that being ignored and brushed off. Wildhartlivie (talk) 09:21, 24 March 2009 (UTC)

(outdent) Despite my endorsing the reversal of changes made to MOSNUM (see below), I do not think that MOSNUM needs to be recommending any templates, and should steer clear of this kind of discussion – this project is about style, the end result, not how that is achieved. The paragraph regarding templates should be removed altogether.
Anyway, since the discussion is here, I shall have my say. As suggested to J JMesserly, the discussion should have been held (in advance) on one of the existing templates talk page, with pointers to that discussion on all the others. I am entirely sure the existing templates could have been adapted to take account of Julian dates, and perform anything else that was added with the introduction of the new templates. The new templates should have been created in sandbox, and replaced the existing ones once they had been shown to work satisfactorily. Substituting the new template without discussion, or even an edit summary in some cases, on various infobox templates was quite simply not the way things are done.
Having two templates doing the same job, just producing different vcard/vcalendar output, with a barely noticeable hyphen to differentiate between them is not acceptable, and introduces unnecessary confusion. _wjemather^bigissue 12:15, 25 March 2009 (UTC)

Undo the previous change to the MOSNUM section regarding this

Please change the template link in the section Wikipedia:MOSNUM#Dates_of_birth_and_death from as pointed out in the discussion above from

In biographical infobox templates, provide age calculation with {{birth-date and age}} for living people and {{death-date and age}} for the deceased when the full birth or death date, respectively, is known. Death-date and age may be used for Julian dates, but both parameters must be in Julian. With Julian dates, if strict microformat emission is a concern, the gregorian parameter must be used to indicate what the Gregorian date would have been, had that calendar been in existence at the time. See {{death-date and age}} documentation for an example.

to

In biographical infobox templates, provide age calculation with {{birth date and age}} for living people and {{death date and age}} for the deceased when the full birth or death date, respectively, is known. (However, avoid these templates unless both dates are in the Gregorian calendar, due to possibly inaccurate calculations if the birth date is Julian and the death date is Gregorian, or the end of a Julian century intervenes.)

since there's no consensus going for the new syntax, and serious objections have been raised both in terms of usage and the process leading to this change. (i.e. reverting this change) Nsaa (talk) 19:12, 24 March 2009 (UTC)

Undid edit-protect template. I see no consensus to use birth and death date related templates at all, neither the version with the dash nor the version without the dash. --Jc3s5h (talk) 19:45, 24 March 2009 (UTC)

Please don't remove the editprotect. The {{birth date and age}} has been in use for 2,5 year. Nsaa (talk) 20:29, 24 March 2009 (UTC)

The editprotect template does not apply to controversial changes. This change is controversial. --Jc3s5h (talk) 20:48, 24 March 2009 (UTC)

I'm not asking for a change, I'm only asking for a revertion of this change. Please let an administrator take the appropiate action. Nsaa (talk) 21:51, 24 March 2009 (UTC)

Endorse, the previous request made by J JMesserly here to change the templates from {{birth date and age}} and {{death date and age}} stated it had consensus based on discussion here and claimed consensus for the change found here based on the agreement of two other editors of "an indefinite moratorium on any future bot runs converting articles from use of intelligible dates to the far less human readable form that  () uses." That was not consensus to introduce new templates into the MOS and was thus improperly added with no consensus. The original request to change the MOS was itself improper and had no consensus. Wildhartlivie (talk) 01:36, 25 March 2009 (UTC)

Endorse this removal of change made without consensus. The number of editors supporting the now-current version is ... let me see ... somewhere around 1. The number in favor of reverting to the previous version is at least 4. — Arthur Rubin (talk) 01:46, 25 March 2009 (UTC)

Endorse/Support reverting change to MOSNUM without consensus, as requested. Manual of style should not be changed the way this was done. LaVidaLoca (talk) 07:50, 25 March 2009 (UTC)

Endorse. Despite claims by J JMesserly, there was no consensus for their requested change to have been made, so it should be reverted. Remove paragraph. MOSNUM should not be recommending any templates. _wjemather^bigissue 12:19, 25 March 2009 (UTC)

Bringing administrator attention to the above consensus with no opposition voiced in nearly two days to revert the change to the MOSNUM implemented here, done without proper consensus to the change that was made. The previous template, which would be returned to the MOSNUM has been in use since August 2007. Wildhartlivie (talk) 12:17, 26 March 2009 (UTC)

No opposition? Like others, I just got sick of playing this stupid game and stopped responding to you. A handful of users pulling together doesn't make for consensus. See previous discussion for reasons why the new templates are better than the old ones. --Pete (talk) 14:58, 26 March 2009 (UTC)

I'm really quite tired of your patronizing comments and put downs. A discussion where you keep dodging and minimizing the issue that the person who requested the change did so based on a non-existent supposed consensus, which is more than adequately available in the above discussion, isn't a stupid game, nor are the concerns raised by multiple editors both here and on J JMesserly's talk page. "Like others" who have endorsed the request to revert the non-consensus change actual is a consensus, clearly outlined. An opinion from you and J JMesserly, trying to forcefeed the rest a diet of non-consensus, doesn't sit well. Your patronization sits even less well. Wildhartlivie (talk) 15:16, 26 March 2009 (UTC)

I don't think the superiority or otherwise of the templates is the main issue here. Previous discussion (here) did not even mention birth and death date templates, let alone changing MOSNUM, so how could a consensus possibly have been reached? The change was requested here and carried out less than 12 hours later, without any discussion (and complete disregard for anyone in the rest of the world (presumably outside the U.S.) who may have been asleep at that time). There is just J JMesserly's assertion that is was the right thing to do based on the aforementioned non existent consensus. _wjemather^bigissue 19:25, 26 March 2009 (UTC)

Beg pardon, but this is the talk page for MOSNUM, where the words of the Manual of Style are discussed. It's not a forum for personal attacks or behaviour issues. My honest opinion is that the new templates are far better than the old, that biographical articles benefit greatly from having a uniform way of presenting this useful information (namely, current age of living subjects and age of death if late), and that this should be a stylistic guideline. If some editors are not happy with the way the change was made, or they have an axe to grind on date linking or other irrelevant issues, then they should go elsewhere to more relevant forums. Whether I'm seen as patronising or not, a handful of users expressing an opinion is not consensus, not on a page where so many editors contribute. --Pete (talk) 21:50, 26 March 2009 (UTC)

Please don't attack other people like this, and argue in a polite way. There's no consensus what so ever for the change to MOSNUM done here, and the only thing it's asked for is to restore the previous version. Above I've raised some issues by using these new templates (it's only possble to use in an English language content, so reuse is not possible on other language project, it give the user a possibility to use NON MOSNUM date formats, its bad to create new templates when its possible to use the already existing (ex. with the gregorian/julian stuff, that's not done in a good way in the new template, it should convert automatic based on rules govering the given period or land by adding a parameter telling the script what period/country the date is from, and then use the aviable Juliandate conversions implemented at Meta). So again, this should be reverted at once. Nsaa (talk) 23:15, 26 March 2009 (UTC)

Agree that the change should be reverted for procedural reasons (was not discussed properly). No stance ATM on which language is better, but changes like this should not be done without discussion, and hence the ill change should be reverted. --SLi (talk) 23:38, 26 March 2009 (UTC)

There has been years of discussion - just check the discussion pages of the old templates. The new templates overcome the major disadvantage of the old ones in that they are more user-friendly. I honestly can't understand why an improvement is being resisted by a few tireless opponents. If you like doing things the old way, go right ahead. The old templates are still working and there are any number of biographies that need templating, not to mention more information. --Pete (talk) 00:02, 27 March 2009 (UTC)

(outdent) Pete, you are either completely missing the point or simply avoiding it. You are also grossly exaggerating the advantages of the new templates, and failing to see the obvious problems that are inherent with them.
This is more than just a simple syntax issue. As far as I can tell, the new templates were created primarily to change the microformat emission of such templates. J JMesserly: "All I care about is the microformat emission." The flexibility of input syntax would appear to be a sweetener to try and get his way, since there is no consensus to change to hcalendar format with regard to biographies (either on Wikipedia or elsewhere), which is where these templates reside a great deal of the time. See WP:UF and endless discussion there.
To repeat myself again, the change to MOSNUM was done without consensus (anywhere) and should be reverted. If you insist on claiming otherwise, please, as requested many time previously, locate the discussion and link it here. _wjemather^bigissue 01:42, 27 March 2009 (UTC)

And more importantly in regard to reverting, there is a consensus here to do that. It's clearly outlined above - 5 editors agree that the revert should occur, 1 would actually like the entire paragraph removed from the MOSNUM, and then there is Skyring, who wants it to stay. That is a far greater and clear consensus than the alleged consensus that Messerly claimed when he posted the request to change the MOSNUM. For the record, "a handful of users pulling together" who agree to something is precisely what a consensus is on Wikipedia. Consensus is agreement by the group as a whole, but it doesn't mean it is all or nothing. There is consensus here despite one voiced objection. Wildhartlivie (talk) 08:16, 27 March 2009 (UTC)

Looking at the number of regular contributors here over just the past year of very involved discussion on dates, date linking and date formats, including various polls, RfCs and ArbCom involvement, five contributors claiming consensus is risible. As I say, there's been years of discussion aimed at remedying the disadvantages of the old templates, and now somebody has got off their arse and done it. --Pete (talk) 09:12, 27 March 2009 (UTC)

Again, you fail to address the issue at hand. I will spell it out yet again – no consensus was reached with regard to changing MOSNUM.
Your latest arguments are misleading, since date linking and date formats are clearly irrelevant with regard to this discussion, and citing previous entirely unrelated polls, RfCs and ArbCom decisions also does nothing to further your case. Have you read my comments above? _wjemather^bigissue 10:10, 27 March 2009 (UTC)

And again, you are overlooking the fact that the misrepresented consensus was based on the partial agreement of three people about a "moratorium on conversions to the old template", whatever that meant. There was never a consensus to change the MOS. How hard is that? Beyond that, discounting the opinions of interested editors who you don't count amongst the "regular contributors" is disengenuous. Where were they when the supposed consensus was allegedly determined, and why haven't they weighed in now? The idea that if you keep talking around it, the current consensus will go away just won't work. The point here is very simple and very clear. No consensus was determined to change the MOSNUM. There is a consensus here to revert the change implemented by that claim to the version using the template that was there before. Period. Wildhartlivie (talk) 10:29, 27 March 2009 (UTC)

Yes, I'm failing to address your issues. Because they have been addressed before. I just got sick of going round in circles, and irritated that my silence was being counted as agreement. Five people on such an active talk page doesn't make a consensus, no matter how much you wish it did. I'm happily using the new templates. Why? Because why, they are easier to use and understand, and I think fresh editors will be happier about using them, rather than something which has opaque codes like "mf=y" to grapple with. Making Wikipedia easier to use, cutting the jargon, and attracting new editors are all worthwhile objectives. At this point, I'm finding myself making the same points as before. If anyone wants the final word, it's probably already been said about half a page earlier. Just cut and paste, will ya? --Pete (talk) 15:27, 27 March 2009 (UTC)

Pete, you have _NOT_ adddressed my conserns for the new templates and you totaly miosses the point when you say that it's not enough people wanting to do the revert. Remeber this was something that was introduced in an impropper way.

1. Its not possible to use this setup on other languages, since it's dependent on the #time-conversion that only support the english language.
2. You open up Pandora's box by letting people write dates as they want. The #time interprets many many variants, and then people don't learn how dates should be written at Wikipedia (Either d mmmm yyyy, mmmm d. yyyy or yyyy-mm-dd in special cases per WP:MOSNUM)
3. The Julian date sol'n isn't a good solution. Based on meta:Category:Date_computing_template it should be possible to add a parameter converting the given julian date and area to a calculatable version.
4. We shouldn't have two templates covering the same area. Its better to adjust the present one.
5. Changes to MOSNUM should be done by achieving consensus. The change done here, as other has pointed out was done to fast without any consensus reached. Nsaa (talk) 17:44, 27 March 2009 (UTC)

Heads up

I've gotten a positive response at WT:MOS#Which is it (i.e.)? to my request to stop monthly updates of the WP:MOS page for the 4 reasons I gave there. This is the only other page that, conceivably, all 4 reasons apply to; it's too soon to tell. I'll ask for opinions at the end of the month. - Dan Dank55 (push to talk) 22:42, 20 March 2009 (UTC)

So far so good; lots of changes, but that's expected after a long lockdown, and I understand the changes. This page doesn't seem to have the problem that WP:MOS does that people feel a need to change minor details all the way down the page every month. But "1700s ... could refer to either 1700–1709 or 1700–1799"? See Talk:1800–1809 to see how much discussion there's been on that point. I believe someone was able to find a few sources of marginal reliability that used "1900s" for 1900-1909; no one could find any sources for that use of 1800s or any other century, and we asked all over the wiki. - Dan Dank55 (push to talk) 12:38, 23 March 2009 (UTC)

Wikipedia:Date formatting and linking poll

The above link leads to a community poll regarding date linking on Wikipedia. The poll has not yet opened, but the community is invited to review the format and make suggestions/comments on the talk page. We need as many neutral comments as we can get so the poll runs as smoothly as possible and is able to give a good idea of the communities expectations regarding date linking on the project. Ryan Postlethwaite^{See the mess I've created or let's have banter} 19:43, 21 March 2009 (UTC)

Careful with what browser you use for proofing

An aside on browsers. Many of us have tweaked the appearance of our code with thinspaces and whatnot to make rendered pages appear better. This is just a reminder that if something doesn’t look quite right and you are using Internet Explorer 8, that it would be a good idea to try other browsers too. According to ChannelWeb, IE 8 rates a 20 out of 100 on The Web Standards Project’s Acid3 Browser Test, which “is the third in a series of test pages written to help browser vendors ensure proper support for web standards in their products.”

The ChannelWeb article mentioned also that “Apple's Safari 4 browser scores 100 on Acid 3”. Whereas Safari is only third in market share, with nearly 11% of Web activity, it will show you how pages are supposed to look. Greg L (talk) 21:25, 21 March 2009 (UTC)

I'd argue that it's best practice to ensure that any site is designed to support all the major browsers and as such you should ensure that we rely on a subset that works on all the popular browsers (IE7, FireFox 3, IE6, IE8, and Safari in order of market share). I'd also argue that Acid3 shouldn't be used as an excuse for finger-pointing and using it as such is an extremely bad idea: I believe that no current browser has complete implementations of /any/ of the web standards. -Halo (talk) 18:13, 22 March 2009 (UTC)

Uninvolved with this, but I'd like pop in and point out that the Acid test is not a good measure for what you are trying to use it for. Acid tests mainly nonstandard and broken tags, not common and important tags. It's more of a test of robustness rather than proper layout engine functionality. Gigs (talk) 03:10, 26 March 2009 (UTC)

Kilogram calorie

When unit names are combined by multiplication, separate them with a hyphen. A kilogram-calorie (kg·cal) is not the same thing as a kilogram calorie (kcal). Pluralization is achieved by adding an s at the end (e.g., write A force of ten newton-metres).

I don't think kcal is kilogram calorie but kilocalorie, which is different. --SLi (talk) 18:05, 24 March 2009 (UTC)

The official U.S. document on the subject indicates that cal is the symbol for the small (gram) calorie, and that kilogram calorie is an obsolete term for kilocalorie, which is symbolized as kcal. Presumably a kilogram-calorie would be the unit that results when a certain number of calories is absorbed by a mass of a certain number of kilograms. I really think a better example should be found, since this example defies the official advise of the United States government in that it mixes an SI unit, kilogram, with a non-SI unit that is unacceptable for use with SI, the calorie.

I think my emphasis on U.S. policy may be justified here, because my impression is that the calorie is being de-emphasized in other countries in favor of the joule. For example, I understand that UK food labels now use joules to state the energy contained in food --Jc3s5h (talk) 18:36, 24 March 2009 (UTC)

There is the gram calorie based on the energy it takes to increase the temperature of one gram of water by one degree Celsius and the kilogram calorie based on the energy it takes to increase the temperature of one kilogram of water by one degree Celsius. Thus 1000 gram calories (1000 cal) is 1 kilogram calorie but kilo- is 1000 so 1 kcal is equal to one kilogram calorie. So, yes, 1 kcal is one kilocalorie which is defined differently but equal to a kilogram calorie. No "mixing" of SI and unacceptable units: it's an unacceptable unit based on and SI unit. JIMp _talk·cont 12:01, 25 March 2009 (UTC)

The point is to illustrate that you should hyphenate compound units (newton-meter rather than newton meter). The choice of kilogram-calorie vs. kilogram calorie is to give an example of where not using a hyphen introduces an ambiguity, not to say that kcal is officially called kilogram calorie rather than kilocalorie or that kcal is prefered over joules. Use another example if you feel like it.Headbomb {^ταλκ_{κοντριβς} – WP Physics} 09:38, 27 March 2009 (UTC)

I think the usage "out there" is more mixed: you will find both "kilowatt hour" and "kilowatt-hour". The BIPM themselves write "newton metre".[4] Maybe it is a good idea to specify which our house style is, maybe we should just say "just pick one and be consistent within each article", I don't have a strong opinion about which; but ambiguity is not a real concern here. (While we are at it, why do we only allow the middle dot to multiply units? The hard space is also commonly used, and for a few units even justapposition is, e.g. kWh and mAh.)

As for this particular example, who really uses the unit kg·cal? It is a unit of squared momentum, and anybody in their right mind would use, er..., the square of a unit of momentum. On the other hand, if there are a unit "foo baz" and a different unit "foo-baz", both in actual use, with the latter being equal to the product of one foo by one baz, feel free to add such an example.

A. di M. (talk) 15:23, 27 March 2009 (UTC)

I don't like the example, because there are too many different difficulties with it, which distracts from the point being made. However, A. di M.'s point about the kilogram-calorie not being in actual use is only partly true. It is very unlikely that a finished result, such as would be written about in a Wikipedia article, would involve the compound unit kilogram-calorie. It is entirely possible that such a unit would arise in an unpublished calculation that shows every calculation step. But in the latter case, it would almost certainly be written as a symbol (kg·cal) rather than spelled out. --Jc3s5h (talk) 16:47, 27 March 2009 (UTC)

As far as I can tell, the example given is wrong in many respects. A kilogram calorie is the same thing as a kilocalorie, and you should not, in any case, hyphenate the name of either kilogram calorie or newton metre - See the NIST conversion table at http://physics.nist.gov/Pubs/SP811/appenB9.html . The kilogram calorie is, in fact, an obsolete name for the kilocalorie, which is itself an obsolete metric unit, replaced by the kilojoule in the SI system. Some people still use it, but unfortunately it has several different definitions, depending on the application, which is why it was replaced by the joule. The kilogram-calorie might be construed as a kilogram multiplied by a calorie, but I'm not sure why anybody in their right mind would use such a unit, particularly since it is ambiguous in several different obscure ways. Bad example, really bad.RockyMtnGuy (talk) 17:16, 27 March 2009 (UTC)

Problem on Era conversion

This topic has been removed from Wikipedia:Village pump (miscellaneous)

Many writers have converted the years under Buddhist Era (BE) to Christian Era (AD) in an incorrect way for they left one exception behind.

We should take notice that:

1. For Thailand only, BE commenced as of one year following the death of Gautama Buddha; but for another countries adopting BE, the Era commenced as of the death of Gautama Buddha.
2. Converting Thai BE to AD can be made by subtracting 543 from such BE, the outcome is AD. Example: 2552 BE is equivalent to 2009 AD.
3. However, in converting a date prior to 1 January-31 March of 2484 BE (1942 AD), the number to subtract is not 543, but 542.
4. Perversely, converting AD to BE can be made by adding 543 or 542, as the case may be, into such AD.

Article 3 is an exception usually left behind by many people, and this led to a great problem about inaccuracy of year counting or conversion in many Wikipedia articles as to Thailand, Thai persons, Thai stuffs, Buddhist stuffs and any others in connection with the said.

Therefore, I suggest us to lay down a project to check and rectify the said mistakes. I cannot say how to carry out the project, but I can say that checking whether this one is a correctly-converted year or not would be much difficult and we need to seek Thai Wikipedia for cooperation. Thai Wikipedia is also meeting with the same problem as us. ——PORtrait | chit~chat - 24 March BE 2552 (2009), 03:17 hours (GMT+7)

If you don't get any discussion going here, you might want to post at Wikipedia talk:Manual of Style (dates and numbers). -- John Broughton (♫♫) 00:22, 25 March 2009 (UTC)

How about a template to convert automatically? Both years could be displayed & there should be no errors since it's automated. JIMp _talk·cont 11:38, 25 March 2009 (UTC)

Abbreviating months

Is there any standing on the abbreviation of months in an article? Is abbreviation ever acceptable? In what cases can they be accepted? or can not? Is it known as unacceptable in infoboxes? FireCrystal (talk) 16:59, 27 March 2009 (UTC)

The official MOS standard is: Abbreviations such as Feb are used only where space is extremely limited, such as in tables and infoboxes. That is, you spell them out in in full, unless you don't have enough space, which would never occur in the body of the text or in footnotes. If you do have to abbreviate months, a useful guideline is that only the military abbreviates June and July, and nobody abbreviates May. RockyMtnGuy (talk) 17:35, 27 March 2009 (UTC)