Wikipedia talk:Manual of Style/Dates and numbers

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 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, your 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)

Substituting the new template Factcheck: The new template is being used at last count on over 2500 articles. The vast majority of these were not substitutions of the old template for the new template.

Is MOSNUM the correct forum? Factcheck: Ease of editing is so crucial to MOSNUM, that the goal is mentioned in its first paragraph:

Consistent standards make articles easier to read, write and edit.

Why then is this not the correct forum for discussing which family of templates makes it easier to edit dates?

Julian vs. Gregorian: Factcheck: If the old templates were able to accurately calculate a Gregorian date from a Julian date in a way that is acceptable to the MOSNUM audience then that would be wonderful. However, the fact is that they don't now, and MOSNUM should state that the old templates cannot be used with Julian dates.

Are any of these facts incorrect? -J JMesserly (talk) 23:34, 2 April 2009 (UTC)

Funny, I recall your stating quite strenuously that you did not convert any templates from the old template to the new one and then did not respond when I posted diffs establishing that is not true. 2500 is a drop in the bucket to the number of biography articles that have infoboxes, however, you also insisted over and over that you were testing things on a few dozen articles and did not comment when I brought up the fact that it was far more than a few dozen. Wildhartlivie (talk) 00:07, 3 April 2009 (UTC)

Your recollection is incorrect. I never stated anything of the kind. You made a case at arbcom that I had been making such changes, and that the new template was a subtle attempt at bypassing the injunction. They didn't buy it, nor should anyone here. You based your assertion on the belief then that I said something that I didn't- that the new template could not be changed to emit linked and or autoformated dates. You were wrong about that too. Or am I mistaken? If so, citations please. -J JMesserly (talk) 00:21, 3 April 2009 (UTC)

I did not try to make a case at arbcom, I posted a concern about what I felt might be, in effect, a violation of the arbcom injunction and also requested advice on where best to broach my concerns. I believe I said twice that I was posting a concern. You did say here that you were "adding the new date templates to articles that were not using a birth or death template". I posted this diff that showed you had changed templates. Did you want me to find links that show that you changed the template being use? It will take a bit of time tomorrow, but I've seen more than the one diff I posted at the arbcom board. Or was it where you assured me you were only wanting to put the new template on a few dozen articles at WT:WikiProject Biography#Template swap for Neuroscientist biography articles (no visual change) or when you said you were testing things and there was no cause for concern? Wildhartlivie (talk) 05:56, 3 April 2009 (UTC)

However you wish to characterize your arguments at arbcom regarding your unfounded assertions, no one there bought your arguments. Simply repeating it here is equally unconvincing. You made the statement "I recall your stating quite strenuously that you did not convert any templates from the old template to the new one". I note that you have declined to substantiate your claim. Admit it. I never made any such statement. -J JMesserly (talk) 08:44, 3 April 2009 (UTC)

Read what was said at arbcom how you wish, the link is there for anyone to read and what it was based on. I gave a link and a quote of your comment - which happened to be at arbcom - where you said you were not changing extant templates in articles, only adding the new one to articles for where none were used. There's an elephant in the room, don't ignore it. Wildhartlivie (talk) 15:49, 3 April 2009 (UTC)

(undent) You made a specific charge of I stated a falsehood and have failed to substantiate your charge. "I recall your stating quite strenuously that you did not convert any templates from the old template". You have not provided the diff or a pointer to a discussion showing where I uttered this falsehood as you recollected. It is a false allegation, as has frequently been the case concerning your assertions concerning this issue.

Choice of venue There has been no response regarding MOSNUM as the correct venue for this discussion. I presume that the introductory statement of goal of MOSNUM to ease editing provides ample justification that this is the correct forum to work out a resolution to the issue.

Non gregorian dates A substantial number of dates on wikipedia are non gregorian, and MOSNUM is recommending use of a template that cannot handle them according to its own documentation (see {{birth date and age}}). Since there was no further comment, I will make a proposal to gather concensus regarding this caveat to the recommendation. -J JMesserly (talk) 16:37, 3 April 2009 (UTC)

Aw geez. Now you're resorting to the "liar, liar, pants on fire" school of logical debate. You said that what you were doing was "adding the new date templates to articles that were not using a birth or death template". I posted this diff that showed you had changed templates. I offered to hunt down more, although one is sufficient.

Meanwhile, you're changing the subject and muddying the water. No one has responded to one point in the lengthy discussions here based on your time schedule? You're going to do what? Gather consensus to add a caveat to the MOSNUM that the template in the guideline doesn't handle non-Gregorian dates? This is the technique you use - throw so many points into the debate that no one can possibly respond to them fast enough for you and then you seize on the one that doesn't get a response and belabor it, so the other issues get cast aside. Wildhartlivie (talk) 17:40, 3 April 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 {{edit protected}}

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)

{{Edit protected}} 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 (see Ja/Ru and No examples), since it's dependent on the #time-conversion that only support the english language.

>>Interjected comment: Translation is a non issue as I showed in an earlier response whose arguments were not addressed by this sort of attempt to sidestep them. First year language students learn the months in their first few months of education, and all translation tools substitute these on the first pass anyway. It is amazing that #time does some translation, but simply because it doesn't handle all languages is like saying a car that flies is flawed because it doesn't work underwater. Besides, most other language wikis don't have infoboxes let alone an analog of the death date and age template. So please show why this is not just a silly canard. -J JMesserly (talk) 23:21, 6 April 2009 (UTC)

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)

>>Interjected comment: This argument is specious. Users cannot write dates however they want in the body of the article because the manual of style specifies that some formats are not acceptable in some contexts (eg ISO dates in non tabular contexts), whether the date has curly brackets around them or not. A Pandora's box unleashes unimaginable and unanticipated evils. Perhaps you could be more specific about what these overwhelming evils are that will be unleashed, and how it is that this Pandora's box is not already open anyway. -J JMesserly (talk) 23:21, 6 April 2009 (UTC)

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.

>>Interjected comment: Ok fine. Fix the old template. If the fix you speculate is possible, then you have an argument. Until then, all you have is conjecture. The new template handles all non gregorian. Not just Julian. -J JMesserly (talk) 23:21, 6 April 2009 (UTC)

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)

 Administrator note I've replaced the paragraph with some language which defers the debate off of this page onto the template talk pages where it belongs. The offending paragraph now reads:

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. See the documentation for those templates in order to use them properly.

I hope that this neutral language will lead to more civil discussion.--Aervanath (talk) 17:54, 27 March 2009 (UTC)

Thank you. Wildhartlivie (talk) 18:11, 27 March 2009 (UTC)

A proper change. Thanks! Nsaa (talk) 18:14, 27 March 2009 (UTC)

I don't understand how the new language is neutral. It recommends the old template. -J JMesserly (talk) 16:56, 1 April 2009 (UTC)

It was asserted in the prior thread that proper consensus was not achieved. If this is true, then how is it that the proposed changed notice never received any protest? Some have tried to minimize the importance of the extensive discussion on free text dates in february. Much have been made of the fact that {{birth-date}} {{death-date}} etc. and other variants were not named so at the time of the discussion. The difference is in name only. Death-date in fact redirects to End-date, and birth date differs only in a single four letter tag- hardly a difference of any significance. The "and age" variant replicated the date calculation which was an uncontroversial feature of the old templates. -J JMesserly (talk) 22:44, 2 April 2009 (UTC)

That is a duck and cover comment. The proposed change notice was posted here, on a Wednesday afternoon in the US, late in the evening in the UK, mostly in the very early hours of the following day in Australia. You waited a sum total of slightly under nine hours, a period of time in which no edits were made to the page whatsoever, to conclude that no one objected and then posted your assertion of consensus here. Perhaps it didn't occur to you that no one had a chance to see it, or perhaps it did. Much has been made that of the fact that your assertion of consensus was not based on discussion concerning the inplementation of a change to the MOSNUM. No one has minimized anything, your discussions in February did not conclude with a consensus to change the MOSNUM. Extensive discussions do not equal achieving consensus. Those extensive discussions basically trailed off and stopped. In contrast, the consensus above was very clearly specified as a request to revert the MOSNUM change you requested. No ambiguity, no making assumptions about the Support poll and what it meant. No looking at comments posted by editors and interpreting what they were saying. It is as simple as black and white. When you make a proposal to call a moratorium on conversion to the old template, that is what you are proposing. A moratorium on conversion to the old template says absolutely nothing about changing templates in the MOSNUM. Yet that discussion is what you indicated was the consensus. Wildhartlivie (talk) 00:34, 3 April 2009 (UTC)

(undent) Many people have MOSNUM on their watchlist, and hundreds saw the change. Hundreds saw the notice. Yet no one responded to that thread with any objections either before or after the change was made. And none of the people objecting now had any input in the prior month long discussion of plain text dates. And that's the fact of the matter. You have not responded to this.

There was ample reason to conclude there was a clear consensus on the matter. However, I understand the alternate POV and would like to move towards reaching common ground regarding the language of the recommendation regarding template use. As I have repeatedly stated, I have no problem with folks continuing to use the old template. What is wrong with allowing contributors to use the template of their choice? -J JMesserly (talk) 00:56, 3 April 2009 (UTC)

Actually, in the 24 hour period of the day that you posted the note about the change here, the page was viewed 24 times and at least three of those were yours when you edited the page, and at the close of that day, you posted your request for edit. The page was viewed 100 times the next day, but a new thread was opened that day and there were 33 separate posts during that time. The page view stats don't specify if a view is counted when someone looks at the page and then again when they save a post that was made, but that would lower the number of individual people viewing the page quite a lot. Sooo, the page view stats don't bear out the statement that hundreds saw the notice when it was posted. It really isn't relevant that people who have now spoken up didn't see or respond to the discussion from February. Except for you, none of the people who took part in that discussion have shown up here to confirm that they supported a change in the MOSNUM or to object to the reversion. And that's the fact of that matter, as well. Wildhartlivie (talk) 05:08, 3 April 2009 (UTC)

Factually wrong again. Tony1 was part of the discussion and posted here.

Note that protest could have been made before or after. The first posting made in opposition to the change was made on March 21, and in response to an inquiry thread that I myself posted. During that time, there were 3000 views of MOSNUM and the talk page. Look it up at Stats.grok.se. And despite these thousands of views of a hotly watched page (due to the arbcom controversy), no one uttered a peep about it. I don't know about you, but when a controversial page pops up on my watchlist, I read the change, and do nothing more if it seems reasonable enough. Only if I disagree with it do I then go to the talk page to investigate. So we can conclude that there were thousands of opportunities to for people to consider whether the change was reasonable. There was in fact consensus for this change, and no one posted any response to the posting opposing the change. There was not even an inquiry. -J JMesserly (talk) 09:35, 3 April 2009 (UTC)

It would be highly helpful for you to actually post diffs on statements to which you refer. Tony1 posted a comment in response to a comment made by Ohconfucius which asked "REQUEST FOR CLARIFICATION: Is this a discussion/proposal to replace our currently 'layman' dates with "computer nerd" dates throughout WP?" with 11 February "Sounds like a recipe for chaos. We have a very good system now—basically a binary one, both formats readily understandable by everyone in the world. The community takes a conservative line now on needless complications in date formatting.". Interestingly enough, when you posted the thread titled "Plain text Date templates" here, you used part of Tony1's response to Ohconfucius to indicate his endorsement of changing the templates. It would be interesting to look deeper into the context of the posts you noted in favor of changing the template. Tony1 posted a series of questions on 20 March here, some of which concerned date linking (a topic in which he is involved) - "Please assure me that it doesn't link the dates", and in which he posed points about age calculation. He did not indicate support or opposition.

You cannot assume that because people look at the actual MOSNUM page, that they are looking for changes. Editors look at MOS pages to get clarification for what guidelines are there. I actually did post the link to http://stats.grok.se regarding views of this page. Since you didn't give a time frame for the thousands of opportunities you reference, that is hard to verify. However, it's a bit presumptuous to conclude that of the 1000 or so views of this page from 19 March to now were to look at your posting. As I noted above, it isn't clear how that tool counts views and there were close to 250 posts on the page in that same time period. If the tool counts the first view and then the view after a posting is saved, that accounts for half the views in that time frame. There were several other threads posted in that time frame as well. Wildhartlivie (talk) 16:59, 3 April 2009 (UTC)

Proposed deferral

I regret I was on wikibreak and could not participate in the recent flurry of notes on this issue. As I considered what people had written prior to the break, it appeared to me that both sides making statements either pro or con on this debate have strong feelings regarding the date linking and autoformatting of dates issues. Given that the upcoming Arbcom ruling is related to both these subjects, it seems to me to be premature to fully evaluate the arguments made on both sides since some of these assertions and interests may be made irrelevant.

Wjemather proposed that there be no recommendation of templates. That seems like a reasonable interim solution to this issue. -J JMesserly (talk) 17:22, 1 April 2009 (UTC)

I would say permanent solution. My feeling is that MOS (and therefore MOSNUM) has no call to be recommending templates either now or in the future. Further discussion as to the merits or otherwise of the new templates still needs to be had with regard to several points (microformats, input syntax, one template per job, etc.). As suggested above, this discussion should not be here, but on the template talk pages. Until such discussion has taken place, the new templates should not be used. _wjemather^bigissue 17:43, 1 April 2009 (UTC)

What people wrote was mostly influenced by the how the discussion kept being sidetracked to try and pin people down regarding specific issues with the template. For my part, I did not make statements regarding my support of, or my objection to, datelinking and autoformatting. My concerns were related to whether the templates violated the arbcom ruling. Meanwhile, the more relevant issue, which was being ignored, was that the change that had been made to the MOSNUM on March 12 was based on what was represented to be a consensus to change the templates when that was not the case. The actual consensus above on March 27 was to revert that change that had been made. There were 4 supporting the reversion to previous to the March 12 change. There were no objections and one who suggested no template being included. Effectively, that consensus can be viewed as a consensus for no change at the present. How productive is it to now propose a deferral to the consensus for reversion that has already been determined? Since you argued down every concern regarding linking, and others berated editors trying to participate in the discussion, how germane is that to the arbcom ruling? Wildhartlivie (talk) 18:01, 1 April 2009 (UTC)

I am not aware of any consensus in favor of recommending either template. Wildhartlivie, are you asserting there is a consensus in support of the MOSNUM recommendation to use the old templates?

Wjemather, do you accept the proposition that it is possible, through use of poor template style, to needlessly introduce complexity that it was wikitext's goal to remove? Is it true that Wikipedia has no interest in quality control of templates? If it does, then why should the quality control mechanism for template style be different than that for article style? Secondly, as a practical consideration, dates have substantial issues requiring input from experts on these issues. Do you believe a template discussion page will reach the audience of contributors that understand and have valuable opinions on these issues? -J JMesserly (talk) 01:54, 2 April 2009 (UTC)

I am stating, quite clearly and based on the very clear listing of "Support" in the section above, that there was a valid consensus to revert the change you had made to the MOSNUM that was based on an invalid claim of consensus back to the section as it existed prior to that change. That was based on the fact that there was no consensus for the change you had made. Please do not attempt to elicit meaning beyond what was stated. I would suggest that putting meaning into something beyond what is on the table is misleading. Once again, you are muddying the facts with tangential arguments and avoiding what is being stated. Are you claiming there was clear consensus to change the template at all or that there was a discussion about actually even changing the template, and if so, please show us clearly where that was proposed and supported. Also, any changes on Wikipedia should rely on the consensus of the community as a whole and not only those editors whom you believe are "contributors that understand and have valuable opinions". That is a disengenuous backhanded insult to anyone who does not agree with you or what is being discussed. Wildhartlivie (talk) 11:14, 2 April 2009 (UTC)

Firstly, to concur with Wildhartlivie, the consensus was to reverse a change that was made due to your bogus claim of consensus from a discussion that had not addressed all the points raised, and completed brushed over some of them including the microformats issue.
Secondly, one the template talk pages is entirely the correct place for the discussion. Notes/invites to participate would then be placed in appropriate places, i.e. the other related template talk pages, talk pages of those who have participated here and elsewhere, WP:WPT, WP:UF, WP:TIME, WP:WPBIO, etc. I expect it would then reach a satisfactorily knowledgeable audience, and would suggest everyone has a valuable opinion regardless of their level of understanding of the subject. _wjemather^bigissue 11:24, 2 April 2009 (UTC)

(undent) Wjemather, please recall that it was I that began this thread to raise the question whether my interpretation of the discussion of start dates was correct. So please assume good faith. I don't want anything in MOSNUM that does not have concensus any more than you.

Undue haste Is three days sufficient to establish concensus? What about Pete's opinion? What about mine? Some have made the case that I was too hasty in proposing the change to MOSNUM. How is this not also true of this claim of consensus?

Common ground Let's try to find where our common ground is. It seems that folks on both sides have voiced support for doing the microformat stuff accurately. Joe Kress is correct that the old templates cannot be used with Julian dates (at least until they are fixed as Nsaa theorized was possible with a future extension, or until the syntax above is added to the old template). Can we agree that some such statement be added to current MOSNUM guidelines? Regarding choice of templates, how about a live and let live policy regarding the two families of templates, eg: language that says contributors should use the "birth date and age" or "birth-date and age" templates...? -J JMesserly (talk) 21:47, 2 April 2009 (UTC)

Re: "Undue haste": The request to revert your change was first posted on 24 March 2009. The revert was not done until 27 March 2009. Consensus does not require that the support be 100%. Just to note, your claim of consensus was based on similar numbers, or at least that is what you said - four in support, one opposed. Just to quote Pete when he finally commented, "Like others, I just got sick of playing this stupid game and stopped responding to you." He was online during this time, he didn't bother to respond when editors posted their Support comments. He was too busy stopping playing the stupid game to even post an objection until after the fact, and then that was to denigrate the editors who supported the reversion as a "handful of editors voicing an opinion" and suggesting that "If some editors are not happy with the way the change was made ... then they should go elsewhere to more relevant forums." The reversion wasn't a claim of consensus, the consensus is clearly established by the list of Support above.

Meanwhile, regarding the "common ground" - why is it not possible that the extension for Julian dates be developed or the syntax be added to the old template? It is pointless to have more than one style of template to do the same thing and efforts have been made in regard to other templates not concerned with this discussion to reduce multiple templates for the same purpose down to one. Wildhartlivie (talk) 01:04, 3 April 2009 (UTC)

Regarding the theoretical upgrade of the old templates to handle Julian, someone might add the syntax. As I pointed out, the syntax will be exceptionally complex (example above). Nsaa theorizes that it might be possible to modify the old template to calculate them. Maybe the community would support an algorithmic approach to converting julian to gregorian. The examples I have seen are table driven, and somehow the template will have to know where the date was declared, because the adoption of Julian spanned a 200 year period. In any case, such a solution would also would only address Julian dates, and not any of the others such as Roman dates. Regardless whether a calculation is possible for julian, you still need a third date specified. So you haven't avoided this problem:

Comparison of proposed non Gregorian 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}}

Undue haste I think you are confusing taking a vote over three days with concensus gathering. I think everyone understands that neither I nor Pete were in favor of the change. I announced that I would be away on wikibreak in this very thread but I was not offered the opportunity to respond to arguments that consensus was not properly achieved. Perhaps others who voiced support would have felt differently if the facts where presented to them. Now, if you look at the february discussion, the only dissent expressed was dissent that the old templates should be deprecated. The MOSNUM language did not include any such deprecation of the old template.

So where do we stand today? Unfortunately, there are strong feelings on both sides regarding use of their favorite template. I agree that it would be nice to unify on one set of templates, but redundancy in templates is nothing new on wikipedia. Perhaps over the next 2 years we can work through towards such a unity. In the meantime, what is the harm of recommending use of age templates, and allow the contributors to choose between the families based on their preference? -J JMesserly (talk) 01:46, 3 April 2009 (UTC)

Actually, I posted quite a detailed comment here, in the early hours of 21 March that discussed my issues with your assertion of consensus. I'd also voiced the same issues at WT:WikiProject Biography on 17 March, at WP:AN/I on 18 March, and at WP:AN/AE on 21 March. It was on the table here prior to your leaving in more than one place, so the opportunity to respond was there. You didn't post your wikibreak note until about 27 hours later here and it did say you would be away until 26 March. The revert didn't occur until 27 March, and you didn't post again until 1 April. Honestly, and no offense intended, I thought perhaps you had left Wikipedia. I won't comment on consensus vs. discussion, one is fairly clear, the other can go on and on. Wildhartlivie (talk) 06:33, 3 April 2009 (UTC)

I would contest that consensus was not required to revert a change that was made without consensus. The responses given to you by Aervanath at his talk page is quite clear: "The old template was recommended by MOSNUM for quite a while, I believe. Therefore it would take a clear consensus to remove it." and "If there's no consensus for a change, then it should be reverted, even if the lack of consensus only became apparent after the change was made." Further discussion and common ground finding should be deferred to the template talk pages as suggested above. _wjemather^bigissue 07:27, 3 April 2009 (UTC)

(undent) Neither of you have explained how hundreds of individuals who have MOSNUM on their watchlists failed to respond to the posting either before or after the change went in. Read the proposal in the achives. No negative responses before or after. Ample opportunity to post such opposition. The suggestion has been made that I was trying to slip something past the community. How could I possibly be aware of any of the opinions of those now posting against plain text dates had these opinions when none of these individuals had contributed to the extensive discussions on the subject in February? The only one who voiced opposition voiced opposition to deprecating the old templates. So please, it is unfair to claim I made the proposal in bad faith. It is also unfair to claim that the proposal did not have consensus. There was ample opportunity to voice opposition to the proposal before or after the change. As it was, so much time had past that the posting went to archives. I cited several voices in support of plain text dates from February. There was no expression of opposition until after the proposal had gone to archives. By virtue of WP:SILENCE, there was consensus for MOSNUM to recommend plain text date templates over the older cryptic templates. With that said, I don't think it is fair that the community be subjected to a wording that a portion strenously object to.

I have not yet heard any response to my proposal for reaching common ground. What is the harm in establishing a live and let live policy on usage of these templates? If common ground is impossible, please state the reasoning. -J JMesserly (talk) 09:07, 3 April 2009 (UTC)

How can you possibly know the opinions of anyone viewing a page that doesn't post a response? Silence does not equal agreement. WP:SILENCE is an essay, a portion of which reads "In wiki-editing, it is difficult to get positive affirmation for your edits (disaffirmation comes with a revert). No matter how many people on a talk page say they support an edit, sometimes it is only when your changes are reverted or substantially changed that you learn that you did not, in fact, have full consensus." Read it again. It is entirely correct to state the proposal did not have consensus. And again, the "extensive discussion" was not to implement a change in the MOSNUM. Please see my comments above about what you presented as agreement with a proposal to change the MOSNUM. The proposal you made in February that garnered the support you assert was to a "moratorium on conversion to the old template". Not the same thing. Wildhartlivie (talk) 17:24, 3 April 2009 (UTC)

I overlooked a point I meant to make in response to your post that said "I agree that it would be nice to unify on one set of templates, but redundancy in templates is nothing new on wikipedia." Redundancy in templates may be nothing new, but introducing more redundancy is pointless. That other stuff exists is a poor reason to further it. Wildhartlivie (talk) 17:51, 3 April 2009 (UTC)

Neither is it true that the current passage any longer enjoys consensus. I personally think we should recommend templates for dates and I think you agree. I think that is our common ground. You do not believe there should be two separate templates. That's water under the bridge. There already are and given the support for plain text syntax, a template delete proposal would never achieve consensus. So the practical thing is to recognize reality and meet each other half way. Allow contributors to choose- adopt a live and let live approach. Proposal to that end follows. -J JMesserly (talk)

I'm not clear at what point it changed from the consensus to return the MOSNUM to its former status into the current passage no longer "enjoying consensus". Did I miss a discussion? And did I miss the discussion that endorsed your version for birth and death templates for inclusion? Where did that take place? No, I do not support the live and let live approach any more today than I did when you suggested it four posts above. As I said, more redundancy is not a step forward. Let's face it, you made a template and you want to use it, but I've yet to see any of the people who were said to be in great support of these templates speak up to say they endorse using them. Wildhartlivie (talk) 22:18, 8 April 2009 (UTC)

Proposed common ground text

There is general consensus that it is proper for MOSNUM to recommend use of templates, such was done with Category:Conversion templates. However, there is no current MOSNUM consensus on whether numeric or plain text date templates should be used. With that in mind, I propose adopting the following amendment that advises contributors to use a date and age template using the same pattern as that used for conversion templates. Point them to a category listing the templates, and allow the contributor to choose. Proposed text:

In biographical infobox templates, birth and death date & age templates should be used to provide age calculation and microformatted dates for birth and death. See the documentation for those templates for restrictions and proper usage. Note that when using the {{birth date and age}} or {{death date and age}} (older templates without the dash in the name) the date must be precisely known in the Gregorian calendar.

How does that sound? -J JMesserly (talk) 20:39, 8 April 2009 (UTC)

In a word, terrible. There is more than just input syntax to this, as you are well aware from the preceding discussion, and where is the consensus that MOSNUM should recommend templates. I feel strongly that there should be only one template for each application, as do many others. It is a fact that the long existing and well used templates could be edited to provide for any eventuality (including wysiwyg inputs) without affecting current usage by means of named parameters. This would also greatly simplify their use for new editors, as having to input data in a specific order between pipes seems to me to add an unnecessary layer of complexity to those unfamiliar with any particular templates use. Please do as suggested earlier and raise the issue at the template and related project talk pages. _wjemather^bigissue 21:34, 8 April 2009 (UTC)

Beyond what Wjemather said above, that the MOSNUM has included the current templates since August 2007, and editors supported reverting the MOSNUM to return to its former wording, it is incorrect to say there is no consensus regarding templates. There was a consensus to revert the change. Specifically, I do not support opening the door to allow for whatever template an editor might choose. That only invites increasing disparity and inconsistency. Wildhartlivie (talk) 22:44, 8 April 2009 (UTC)

No, there is no consensus that only the current template be mentioned, and Aervanath agrees. So the choice is no mention of any date and age templates or some middle ground. Wjemather believes no mention should be made, but it is my understanding that you do not share his opinion Wildhartlivie. If you both agree, then fine, that puts the new template syntax on an equal footing with the old template, so my goal is partly satisfied. However, we need not remain locked in uncompromising positions with such a scorched earth outcome. Pete and Tony are not the only folks that believe that the old template is needlessly complex. Let's let folks decide for themselves which syntax they prefer. Wjemather, if there is no consensus for recommending templates, then please explain why we have recommendations regarding coord and conversion templates. Sorry, but your POV does not represent the general consensus regarding the whether MOSNUM should recommend templates. The consensus is that the practice is proper as evidenced by the recommendations in its current content. -J JMesserly (talk) 02:02, 9 April 2009 (UTC)

Don't put more into things than are actually there. There has never been a specific consensus determination about having any other template than the one that is there now so it is a bit misleading to say that there is no consensus to the very direct statement "that only the current template be mentioned". The observation made by Aervanath was in response to a specific area of inquiry regarding, interestingly enough, conversion of templates in articles from one template to another. However, he also said quite clearly in the same discussion you were having with him, in response to your direct question "Is there a consensus that MOSNUM should recommend the old template?" that "The old template was recommended by MOSNUM for quite a while, I believe. Therefore it would take a clear consensus to remove it." In fact, it isn't necessarily a choice between no template recommendation at all and some middle ground. There is also the simple fact that it will take a consensus to remove the template that is currently in the MOSNUM as well. You can't characterize this as some sort of stalemate because we are the only ones discussing at the moment. I covered my impression of Tony's comments on this page here, and it was not clear at all to me that his responses could be interpreted as support for the template that you made. He said 11 February "Sounds like a recipe for chaos. We have a very good system now—basically a binary one, both formats readily understandable by everyone in the world. The community takes a conservative line now on needless complications in date formatting." in response to the question by Ohconfucius asking for clarification of whether yours was a discussion/proposal to replace our currently 'layman' dates with "computer nerd" dates throughout WP?" So you can confidently say that Pete supported your template, but it isn't clear to me that it was beyond that. I've noted more than once that none of the original people you counted in your consensus have spoken up here since to endorse support for the template at all. Meanwhile, it was fairly clear when the MOSNUM change was reverted that there was objection to the change to the template, for a variety of reasons, from lack of clear consensus to an objection to changing the MOSNUM. You certainly cannot conclude that the remainder of editors who spoke up in support of reverting the change are opinionless regarding this newest suggestion. I see no reason why Nsaa, Arthur Rubin and LaVidaLoca would not have an opinion about removing all template guidance completely, or specifically allowing the editor to choose. That is basing a conclusion once again on something other than what was on the table. Perhaps a request for comment should be opened to establish consensus regarding changing templates in the MOSNUM vs. removing all mention of them vs. leaving it as it currently exists. That would essentially be binding. Wildhartlivie (talk) 04:10, 9 April 2009 (UTC)

(undent) There is one way to find out if your speculations are correct. If you wish to press this, I am confident there will be a judgment of no consensus on the current passage. It's current reading could justifiably be used to conduct mass reversions of the new templates. You will not find much consensus for that. But I agree these responses are conjecture as well. Do you wish to proceed? It is actually in my interest since one outcome is that the two templates will be on an equivalent footing. At worst it is status quo. Nonetheless, I don't believe in zero sum struggles as this track that we have been going on is leading. Let's find a third way and compromise so that contributors can judge for themselves which they prefer. It's your call. -J JMesserly (talk) 06:36, 9 April 2009 (UTC)

I say again – there should be only one template for each application. At this point WP:TFD may be the best route to conclusion.
Correct me if I am wrong but your (J JMesserly) main concern is microformat output (you state as much here). As I understand things, the sole purpose of these templates is to emit microformat data. The established templates emit hCard microformat data, and the new ones hCalendar format. There is no consensus for the use of hCalendar format with respect to biographies. As stated above, the established templates could be easily adapted for wysiwyg input, Julian & other calendars, by means of named parameters. As such, I fail to understand why a new set of templates was required, unless you were simply using these other issues to try and further your own cause with regards microformats, which would be too difficult to get changed in an edit protected template? _wjemather^bigissue 10:39, 9 April 2009 (UTC)

Regardless whether microformat events should be used to describe a lifetime, there are many events that wikipedia describes such as military conflicts, political campaigns etc that must be represented as events. Consider what the syntax of a template describing an event must contain.

1. A location (eg latitude/ longitude)
2. A start time
3. An end time

It doesn't take a genius to see where this is going. Do you see why I say numeric representation of time is a house of cards? Start and end times typically require at least 5 separate numeric values and frequently need more (timezone, BCE/CE, seconds). Such templates describing events like the terms of politicians, marriages of people, the duration of conflicts will require at least 12 parameters if they do not employ plain text. What would the parameter count be with plain text dates? Four. That's the motivation, not some petty battle regarding a particular token emitted by one particular metadata scheme. Now, assuming that Wikipedia is to emerge as not just the preeminent source of global knowledge available free via of copy/paste, but free of the constraints of copy/paste, we look to mechanisms by which this knowledge can be freely interchangeable on the internet. Microformats is one such mechanism, and you may have read that I really don't care if microformats itself prevails versus another. I don't. There are some others that probably represent knowledge better and if those push microformats to the side, then fine we just alter our templates to emit those. No big deal. The importance is that Wikipedia emit knowledge in metadata form. Metadata is how the GPS information and time information gets from your camera to Commons to Wikipedia. Ok great. Say your camera was at an event such as the 7 July 2005 London bombings. Well, it so happens that google earth specifies time spans in its markers, and it would be possible to see all images and wikipedia articles associated with a particular time period. Wikipedia will emit this information. There is no question about that.

The issue here is: in reaching out to these other applications, shall wikitext become more computer like to do so, or will it not forget its primary function- to make it as easy as possible for editors to manipulate? Do we build date templates with the foundations for the future or not?

As to technical details of your post:

• Main interest You are pretty close about understanding my main interest. Stated more precisely, my main interest is in metadata emission from Foundation wikis. I don't particularly care that {{Coord}} largely relies on KML metadata and only emits microformat metadata as an afterthought. KML is efficient for what they are doing with it. I'd be a fan of PERSONDATA if anyone was doing anything earth shattering with it, but it has gone nowhere.
• hcard/hcalendar proxy war?: Incorrect. The new templates emit both hcard and hcalendar information. Birth date is emitted both as an Hcard bday (see {{birth-date}} that birth-date and age calls) as well as the start of a lifetime vevent. I do agree the only viable justification of the templates is to emit microformat data. By the way regarding your comment about consensus about whether to use hcalendar or hcard for biography articles, {{death date and age}} doesn't emit any microformat data and to fix it, it would have to do it the way the new template does it using hcalendar. That's because it happens to be the only legal way to do it in microformats at this time. Others wish to block this sort of encoding and wait for some speculated on microformat tag (dday). I am perfectly happy for the template to support this future hcard tag if and when it ever materializes but it is not an either-or: we still will need to represent the span of time as a span of time, and that is the only way to do it in microformats. Eg: what people were alive during this war. You can only do that with vevents. If people want tombstone dates on biographical hcards, that's fine- it has a value, but then what do you do, have an hcard on a building with a special purpose field for the demolition of the building? Then one for decomissioning a ship? It's nuts. These things have generalized start dates and end dates. Without such abstraction, applications will have no expressive power, therefore they won't use them. Anyway, that is the engineering rationale in that sort of lingo. In any case, this is not a mechanism of favoring/ enforcing one or another microformat style as you postulated. If it was, then birth-date would not emit bday. My sincerity is demonstrable. Look at the template- the code has been there since the start. Look at microformats.org then look at what a page using {{birth-date and age}} is emitting using operator. You'll see that both hcards and hcalendars are supported.
• the old templates could easily be upgraded for wysiwyg input: Easy? Really? You asserted this, but we never have shown the specifics of your proposal. Regarding your comment about introducing named parameters, I urge you to write down an example of a death date and age that would have such named parameters. It will be horribly prolix- do you propose birth-year=, birth-month=, death-year= etc.?

Comparison of syntax possibilities for wjemather proposal

	wikitext	article
"wysiwyg"	{{Death date and age|death-year=2008|death-month=1|death-day=11|birth-year=1934|birth-month=5|birth-day=2|df=y}}	11 January 2008(2008-01-11) (aged 73)
"concise	{{Death date and age|dy=2008|dm=1|dd=11|by=1934|bm=5|bd=2|df=y}}	11 January 2008(2008-01-11) (aged 73)
Compared to new template syntax:
plain text	{{Death-date and age | 11 January 2008 | 2 May 1934 }}	11 January 2008 (2008-01-12) (aged 73)

The resulting multiline wikitext for {{death date and age}} is hardly WYSIWYG, nor is it user friendly. You can't be serious, but if you are, propose it yourself at the old template talk pages. As an aside, I note none of the proponents of the old templates have taken any such actions to fix or suggest fixes to the old templates on those talk pages.

Hope this helps in your assessment of the larger issues involved here. If Wildhartlivie is unwilling to compromise on a passage that allows the syntax of the new templates, I am willing to go along with your proposal to remove the passage from MOSNUM until such time as a compromise passage can be agreed to. My motive is completely different than the one you have stated up to now. I simply do not believe it is fair to eliminate occurrences of the new template syntax based on the current MOSNUM wording. -J JMesserly (talk) 18:08, 9 April 2009 (UTC)

Excuse me again, but it is not simply a matter of whether "Wildhartlivie is unwilling to compromise", and it is bad faith to suggest that I am the obstacle over which you must stumble. This absolutely ignores that Wildhartlivie is not the only person besides Wjemather to object to this and it is not the first time that the points I made above concerning, for example, your contention that Tony1 supports your template, have been ignored. This has never been a situation of one or two persons being involved, and I am quite sure I have said multiple times that this is something in which the entire Wikipedia community should participate and decide. It will not be decided in this thread between three people. However, I'd be quite interested in hearing how relevant birth date and death date figures into your example of the 2005 London bombings and why time zones, hours and seconds matter to them. If necessary, I am quite willing to take this all the way to arbitration to prevent it from being talked around long enough or that someone wears down or gives up or grows tired. It is a huge change that has been proposed. If the new template is recommended, it opens the door to the unchallenged changeover of thousands of templates, while you're presently concerned that the relatively small number of new templates being used not be changed. Opening the door to editor options on what templates are used only opens the door to chaos, edit warring and unnecessary arguments if that is successful. I've said before that this is an issue that requires proposal on a Wikipedia wide basis and allowance of input in the manner that any widescale change is determined. Not on this page, not by three people. It's simply come full circle to the concerns that I first brought up. Wildhartlivie (talk) 19:05, 9 April 2009 (UTC)

I entirely agree, this discussion needs a much wider audience than that available here. We are indeed going round in circles, and getting nowhere on our own. _wjemather^bigissue 19:19, 9 April 2009 (UTC)

Wjemather, your previous proposal was a narrowing of venue- that this should be discussed on a template talk page. You now appear to favor a wider venue. I have made such posts, eg: Wikipedia:Village_pump_(miscellaneous)/Archive_19#Announcing Free text time templates and note very little interest in this subject, partly because not many people think of wikipedia as a knowledge base or what it's api is. Nonetheless, the folks at {{coord}} are doing a great job exporting metadata and interoperating with a huge number of internet applications. By the way, there was an edit conflict with your and Wildhartlivie's posts. I clarified and corrected errors I made in the previous response, then noted Wildhartlivie's response and responded to that and now have also responded to you. Anyway, I also added some detail in the addenda refering to your technical points. You might like to look at it again. It be a more clearer explanation, but I also added some illustrations eg illustrating why I don't think named parameters is in any way wysiwyg, and only exacerbates the frankensteinian wikitext.

Wildhartlivie, I'm not suggesting that you are a stumbling block, and obviously we have different understandings of what others have said. Right now, it is just the three of us that appear to have any interest in this. As for the discussion of my options, I am being very clear about my position. My first choice is to work with you as an advocate of the old templates and leave the recommendation of templates in and work out a compromise so that those neither those who favor the numeric syntax or those that favor the plain text syntax are disadvantaged. I think we should allow contributors to choose date templates that use plain text dates. I don't want to force people to use the new templates, and I am not proposing that we deprecate the old templates or proposing that there be any wholesale conversion from the old templates as you fear. Your position seems to be that Wikipedia should to force contributors to use only numerically oriented date templates, and that there should be no mention of the new templates. Further, it seems to be your belief that there is only a tiny minority of wikipedia editors who have the view that the new templates have any merit. I think that's where we stand today.

I am not sure if you were being facetious about how plain text dates are relevant not just to birth dates but to expressing events with spans of time. I think I explained the matter above, and was doing so in response to Wjemather's misunderstanding of why I think moving to plain text dates is necessary. If you have specific inquiries, perhaps it is best to move that portion to a separate section as it is quite involved.

If there is a failure between the two POVs to find common ground, then my only option is to go to the third POV which is to have no recommendation whatever. That's not an ultimatum, it is the only option left to me, and is a direct consequence of our failure to find common ground. To date, you have not made any proposal for common ground, but if you have a proposal, I for one would be eager to hear it. -J JMesserly (talk) 20:38, 9 April 2009 (UTC)

I added a few words to my previous post after Wjemather's to clarify my thoughts, but perhaps the edit conflict was with your post. I have now restored those words I had added. Citing personal issues I've brought up privately to you, I'll be back later this evening to respond here. I just can't concentrate right now, if you'll please understand. I must rest. Wildhartlivie (talk) 21:00, 9 April 2009 (UTC)

(indent out) There are more eyes than those of 3 persons watching this, don't be mistaken about that. There seems to be a need to request dispute resolution here, or am I wrong? What appears to be going on is that one person keeps coming at this from all sorts of angles in trying to keep the plain text templates on the playing field, while two others are firmly against them. It keeps going in circles. Any objection is met with extensive discussion that is never resolved and now I read that the one person has only one other option? That's not true, there is also the option of realizing this template has been considered to be objectionable. It is never a question of stating that there is no other option except the one being offered by the person who wants to retain a certain thing. There also is never a case of having to reach common ground. I've seen suggestions of opening a request for comments, suggestions that this be taken to community at large, which is well beyond this discussion page and I've seen a dogged determination to stick with insinuating the template into the mix somewhere even though no one else is speaking in favor of that. If there is so much concern about so many varied points regarding the use of the newer template, then it obviously still has bugs that others find problematic. This seems to me to be a waste of time to keep debating in circles. It's time for it to go to a higher step. I think the template is both unnecessary and the persistence in arguing for it has led to this talk page consideration being exhausted. I read on some page where the concern in bringing it here was that it would be discussed to death and nothing be accomplished. That certainly seems to be the case. It's time to do something else besides talk in circles and arrive at no conclusion.

One other point, this is the second time I've seen postings by others be changed in some way in these particular discussion threads and that is not allowable. One seems to be contributed to a perceived edit conflict, but why did you go into the post of someone else and number the points that were left? That is an issue that should never happen, even if you have problems with numbering, etc. LaVidaLoca (talk) 18:00, 10 April 2009 (UTC)

Alternative 2: Merge plain text into current template

(outdent) J JMesserly, that is clearly not what I have said at all. Firstly, my position has not changed, you are confusing audience with venue. The discussion can (and should) have only one venue (wherever that may be – my suggestion would be one of the template talk pages). My previous suggestions would not narrow the audience. On the contrary, placing notification messages of the discussion in all the appropriate places, as suggested, would in fact widen the audience.
Secondly, what you have purported as my solution above is far from what I suggested. It would indeed be perfectly possible, and yes easy, really, to have named parameters.
For example: {{Death date and age | death=11 January 2008 | birth=2 May 1934}}
An additional benefit is that there is no requirement to write the parameters in a particular order
i.e. {{Death date and age | birth=2 May 1934 | death=11 January 2008}}
would produce the same result as the first example (unlike your new templates) making it much simpler for the unfamiliar editor, whilst also allowing the current numerical input syntax (unnamed parameters) of the established templates to continue to work.
Finally, my concern regarding microformats comes from the endless discussion at WP:UF which you have taken part in, and the woolly statement on the project page. It would appear that current microformat standards are not entirely satisfactory for this particular application (biographies) whichever route is taken and as such there is no standard. Just because something can be done does not mean it should be, and Wikipedia should probably wait until a proper standard has been set before going down either road, and certainly should not be used to further a movement in either direction. _wjemather^bigissue 00:20, 10 April 2009 (UTC)

I like your suggestion. Very nice. Do you propose that the current numeric syntax be converted to this new syntax? -J JMesserly (talk) 00:39, 10 April 2009 (UTC)

I think it should be pointed out the merge idea did come up earlier. The basic problem is opposition to the very idea of plain text dates for any template. Nsaa made these generic objections here[4], in points one (foreign language) and two (pandora's box). I personally believe these are invalid arguments for the reasons I gave in response to them (see above). If these objections are not sufficient to stand in the way of concensus, then your proposal seems viable, but I'd like to hear from User:Nsaa on that score to confirm he would go along with this sort of approach. Otherwise the exercise would be a waste of time.

• Oh, and by the way, I'd like to know what you propose for the gregorian date parameter. Would there be a numeric equivalent for this feature? -J JMesserly (talk) 17:05, 10 April 2009 (UTC)

This may be a great compromise. As long as the input date follow the MOSNUM guide (d mmmm yyyy, mmmm d, yyyy or yyyy-mm-dd). One problem: As far as I've testet it out it's not possible to restrict input to the two first type of input. But it's possible to restrict the input to yyyy-mm-dd as done in his template (no:Mal:ISOtilNorskdato, it's used t the no-wiki for converting IO-inputdateprameter to the no standard date format d. mmmmm yyyy). By adding the condition {{#ifeq:{{#time:Y-m-d|{{{1}}}}}|{{{1}}}| restricting the input date to be on the ISO format yyyy-mm-dd we avoid both my points about foreign language and pandoras box'. Nsaa (talk) 21:08, 10 April 2009 (UTC)

Units of measurement in general articles.

Section moved from WT:MOS --A. di M. (talk) 01:12, 28 March 2009 (UTC)

At present the Manual of Style gives guidance about which units of weights and measures to use in scientific articles and articles that refer to particular countries. However, there is no guidance about general articles. I propose a small revision of the guidelines.

• For other country-related articles and general articles, the main units are metric: 37 kilometres (23 mi).

It reflects present practice (see Mountain, Lake and Ocean so I don't think it should disturb anyone. I seek consensus to make this small revision (without the bolding, of course).

What do other editors think? Michael Glass (talk) 00:15, 28 March 2009 (UTC)

(I guess that "main units" means the units which appear first, as opposed to that between parentheses.) I would say that the "main unit" should be whatever unit the source for that particular measurement used, whereas any conversion done by Wikipedia editors should be between parentheses. --A. di M. (talk) 01:12, 28 March 2009 (UTC)

In particular, I don't think that the requirement that "[a]n article should only have one set of primary units" is necessary. There would be nothing wrong with writing "a 10-kilogram (22 lb) bag of potatoes and an 11-pound (5 kg) bag of carrots" in the (admittedly unlikely, but not impossible) event that the bag of potatoes were originally weighed in kilograms and the bag of carrots were originally weighed in pounds, and Wikipedia editors had to convert the former to pounds and the latter to kilograms. --A. di M. (talk) 01:24, 28 March 2009 (UTC)

I'm a science tutor in the UK. My tutees have all heard of feet, miles, pints and gallons from everyday speech, but they are all taught in metric only. In my experience, not one of them knows how many pounds are in a stone, let alone in a kilogram, even amongst those who worry about their weight. Sadly, they are also generally poor at arithmetic compared to my generation. Even with inline conversions, inconsistent ordering of metric and imperial often confuses, and if imperial units come first, they find it more difficult to remember as it conflicts with what they're taught in school. In the interests of helping my tutees and their contemporaries, who often use Wikipedia for revision purposes, I would vote for the proposition to add "and general articles" to the MoS wording.

Re. the potatoes and carrots: The purpose of encyclopaedias is to give readers a digest of the topic of interest, and therefore ease of comprehension is paramount. Fidelity to the wording of a source will be irrelevant to the general reader, and using inconsistent units to maintain that fidelity will not aid his or her comprehension of the article.

So, if I were editing an article about potatoes and carrots, I would write:

a 10-kilogram (22 pound) bag of potatoes and a 5-kg (11 lb) bag of carrots

(where I have highlighted the measurements found in the source)Peter Barber (talk) 12:03, 1 April 2009 (UTC)

The words "main units" came from the style guide as it stands. The meaning is clear enough even if it is not ideal. My proposal is only whether or not to add the words and general articles to what is there. Do you agree? Michael Glass (talk) 01:55, 28 March 2009 (UTC)

A. di M.: The purpose of writing an encyclopedia article is to bring together information from scattered sources into a coherent whole. If you are not willing to integrate information from various sources, including selecting one main system of units, you should be writing bibliographies rather than encyclopedia articles. However, in high precision measurements (which are not usually "general" articles) in makes sense to indicate which values are exact. It also makes sense to make it clear if certain values ara a round value because of a deliberate design choice (e.g. 100 yard American football field). --Jc3s5h (talk) 02:50, 28 March 2009 (UTC)

I'd have to know what proportion of the readers of English Wikipedia are in the United States. General readers in the U.S. most definitely are unfamiliar with metric units (the 325-mg [5-grain] aspirin tablet and the 2-liter soda bottle almost the only ones they'd see regularly—while milk is still sold in pints, quarts or gallons and cough syrup by the fluid ounce), so they are certainly not well-served by the general measurement being metric. But whether most En.Wikipedia readers are in the U.S. or outside, this (applied to general rather than technical, athletic or country-specific articles) seems to me a good example of where it's better not to add to the unmanageably vast range of the Manual of Style, and instead leave the choice to the editors who are writing, reading and revising a specific article. (Needless to add, the large number of Anglophone readers in both the U.S. and metric countries is the reason why it's so important, even when tedious, to convert both ways everything that can be conveniently converted.) —— Shakescene (talk) 03:50, 28 March 2009 (UTC)

Somebody with a network analyzer or superuser access to the servers could find out how many readers are in any given country by analyzing the IP addresses, but I don't know if that ever has been done. About half of the people who speaker English as a first language are in the United States, but there are at least another billion people worldwide who speak English as a second language, and they do most of their web browsing in English. As I'm fond of pointing out, there are more people in China who speak English than there are in the United States, and more Chinese have internet access than Americans. The majority of the people who speak English as a second language do not understand American traditional units.

It's interesting that you mention milk being sold in pints in the US, because it's still being sold in pints in the UK. Unfortunately, the UK pint is a different size than the US pint (20% bigger). In fact, none of the units you mentioned (pints, quarts, gallons, and fluid ounces) is the same size in the US as the British imperial system. That's one of the reasons all the Commonwealth countries converted to metric, and one of the reasons we need to baseline everything in SI units.RockyMtnGuy (talk) 12:48, 29 March 2009 (UTC)

Many Americans are familiar with metric: scientists, engineers, medical workers, government employees, teachers, military people. It is hard to go through life in the US without encountering metric units either on the face of things or behind the scenes. It isn't just on soda labels, it is on wine, water, liquor. Almost all packaged goods in a US supermarket have metric units on the label by law (FPLA), just look next time you are there. Lightmouse (talk) 13:11, 29 March 2009 (UTC)

While it might be tedious to provide metric measures, it is necessary. If Americans are unfamiliar with metrics, other people are even less familiar with the traditional measures used in the United States. For an amusing example of what confusion this can cause see the following clip on Youtube: [5]. But how many of the English-medium countries use the metric system? Nigeria has 154 million, South Africa has 48 million, Canada has 33 million,Uganda has 32 million, Ghana has 23 million, Australia has 21 million, Zambia and Zimbabwe each have 12 million, Singapore Ireland and New Zealand each have 4 million, and I haven't even mentioned India or the United Kingdom. Let's just say that a lot of English speaking and English medium countries use metrics. In many of these countries, English is not the first language of most people, so this is barrier enough without an unfamiliar set of weights and measures. Michael Glass (talk) 13:49, 29 March 2009 (UTC)

It's not as if the average American has never heard of a kilo or a centimeter. And within specialized contexts, non-scientists may use metric much more than non-metric measures. But that doesn't mean that a "government worker" (e.g., a postal carrier or a Social Security clerk, even a teacher of history or English) has much intuitive sense of how the whole metric system fits together. An American nurse who uses cc's and mcg's all day still weighs patients in pounds and measures them in inches, while thinking about miles per gallon, Fahrenheit temperatures and pounds of groceries. The metric equivalents are always on grocery labels (e.g. 454 something or other) but rarely considered (price comparisons, for example, are given per pound not per kilo). But since I know that many English speakers (and even more English-readers) live outside the U.S., I know the reverse is true for millions of others. What I don't know is the proportions, not among potential or theoretical readers of Wikipedia, but current ones. And so I completely agree that (wherever practical)†, measures should be given in both metric and non-metric forms. †[An example of where it was difficult to fit useful metric conversions is the table of historic batting distances at Yankee Stadium (1923), although there are conversions almost everywhere else in the article. I imagine the same problem might crop up in a discussion of cricket matches or running distances in American football.] My general feeling right now is that, just as with U.S. and British spellings and punctuation, there's no need to set a standard of measure for general articles, so long as they're properly converted. —— Shakescene (talk) 17:24, 29 March 2009 (UTC)

• If it’s an article closely associated (or more associated) with the U.S., use U.S. Customary units of measure and parenthetically convert to SI. If it’s a general article not closely associated with the U.S., use SI and parenthetically convert to U.S. Customary. If it’s very scientific in nature, use SI only. Greg L (talk) 20:28, 29 March 2009 (UTC)

My apologies for getting a bit sidetracked from the precise proposition. It makes sense to start with kilometres in articles about France and astronomy, and yards in ones about American baseball. The question to me (and as it was originally posed) is this: should there be a general preference as to the starting unit for articles which have no clear tie to science, technology or a particular country?

My response is this: if most of the ordinary English-language readers (not editors) are in the United States, I don't think that they're particularly well-served by making unfamiliar metric/SI measurements the principal ones (followed by conversions to U.S. customary), rather than the other way 'round. But if the bulk of Wikipedia's readers are outside the U.S., it would make just as little sense to have a rule preferring U.S. customary measures. So, both because this is uncertain and because I dislike extending the already-gargantuan reach of the MoS (of which the huge and endlessly-debated MOSNUM is just one sliver) any farther than absolutely necessary, I just don't favour such a suggested rule, well-intended though it certainly is.

Any existing variations and inconsistencies are (like those in U.S. vs British spelling) ones that don't seem to have caused any great difficulty so long as conversions are provided. (If we do find that 70-80% of our readers are either inside or outside the U.S., then some non-prescriptive guidance might well be in order.) —— Shakescene (talk) 21:33, 29 March 2009 (UTC)

• I agree, Shakescene. My above wording encompasses this philosophy, yes? Greg L (talk) 22:03, 29 March 2009 (UTC)

• • Much as I'd like our readings to agree, Greg, I'm afraid they might not. If an article is associated with the U.S., we agree that (normally) U.S. Customary measures should be used (with conversion to metric/SI). We also agree that in technical and scientific articles, the normal preference would be to start with SI (metric) measurements. The same applies to articles about metric countries (including articles dealing with Canada, Britain and Ireland in the present, though not always those about their past). This, as I understand it, follows the Manual of Style as it's currently written.
  • But the specific question is what about non-technical articles that have no particular connection to a specific country? As I read your comment above, you'd want a rule that favours SI (Système International) as a starting system, while I say (at least for the moment or until we find a great disproportion in our readers' base) prescribe nothing. —— Shakescene (talk) 23:04, 29 March 2009 (UTC)

The wording I proposed would not change the recommendation for US based articles, which are supposed to be US measures first, or for UK based articles, which may be either Imperial first or metric first, as long as the choice is consistent in the individual article. The wording I proposed applies to general articles, that is, articles that are not based on one country, like Mountain, Lake and Ocean, which are already metric first. The wording recognises and accepts the status quo. Do I have consensus for making this change to the Manual of Style? Michael Glass (talk) 01:32, 30 March 2009 (UTC)

Oppose: I dissent from (and thus do not join any consensus for) adding "and general articles" to the text proposed at the top. I hate to be so repetitive or so short, but somehow my point (whether you agree with it or not) gets lost. It's not the subject that concerns me, it's the readers. If most of the readers of a non-technical general article like Oceans are in the U.S. and thus unfamiliar with square kilometers, etc., then I don't think we should be advising (or, given the peremptory way MOSNUM is currently being imposed, all but ordering) editors of such general articles to use SI measurements first. On the other hand — whether or not most readers are in the U.S. — I don't think we should be telling them to start with U.S. Customary (or Imperial) measures either. While I certainly respect the intentions and views of other editors here, I think (at least until we get more information, and perhaps even afterwards), we should leave the Manual's language just the way it is. —— Shakescene (talk) 03:19, 30 March 2009 (UTC)

At the moment there are two policies on weights and measures on Wikipedia. One is to be found at [6] and the other can be found at [7]. Instead of worrying about adding sentences or phrases to either of the policies, our time would be better spent making sure that both policies are consistent. Michael Glass (talk) 20:35, 2 April 2009 (UTC)

km/h or kph?

Should we use km/h or kph? I'd think km/h (by analogy to kbit/s), and was surprised to notice that it's not mentioned in the commonly incorrect units subsection. --SLi (talk) 18:46, 29 March 2009 (UTC)

Is this particular mistake really so "common"? If not, I don't see the point of mentioning it, per WP:BEANS. Brainstorming for all errors which some editors could possibly make is not one of the best uses of one's time. --A. di M. (talk) 19:37, 29 March 2009 (UTC)

Ok, but the point is that it is unambiguously an error? I'm not sure if I've seen it so often in Wikipedia, but elsewhere, sure, all the time. --SLi (talk) 19:47, 29 March 2009 (UTC)

• IMO, follow current, most-reliable literature on the subject. If it is an astronomy-related subject, where it would be “km/hr” (or the even more common “km/s”), then follow that practice. If it is an article, for instance about a German autobahn highway, and *if* the road signs in Germany are marked “km/h”, the write accordingly. If they are marked “kph”, follow that practice. Following current, most-reliable literature is a better practice than having a small cabal of Wikipedians knock heads together for a whole three man-minutes to decide what is the best practice to smooth earth’s admission to the United Federation of Planets. It has the virtue that the prose will look most natural and least confusing for a given readership. Greg L (talk) 19:53, 29 March 2009 (UTC)

• ...and here I thought the German autobahn system was famous for its lack of speed limits. Michael Hardy (talk) 20:01, 29 March 2009 (UTC)

• Oops. Good point. You get the drift though. Corrected. Thanks. Greg L (talk) 20:03, 29 March 2009 (UTC)

Well, generally I disagree. I tend to copyedit a lot, and value consistency. And the best way to consistency is to have reasonable guidelines (after discussion if needed) and to stick to them. Except in cases where there is no reasonable prospect on an agreement, like which variant of English to use. (I tend to consider it a shame that Wikipedia as an encyclopedia has even that much variance in style, but there really is no reasonable way out of it.) I suspect that in this case km/h really is the standard, but honestly I'm not sure. Nobody where I live use kph, but then we never had mph either. --SLi (talk) 20:04, 29 March 2009 (UTC)

• Yes, I know. This attitude of desiring project-wide consistency if pervasive. And it’s a problem because it is unrealistic and undesirable because terminology that is suitable for one discipline and a particular level of sophistication will be unsuitable in another. The purpose of an encyclopedia is to educate its readership, properly prepare them for their further studies elsewhere, and help them to be properly conversant with someone skilled in the art. A unit of measurement and how exactly it is written by the Army for the accuracy of an M1 Abrams tank shell might not be suitable for an article about archery or astronomy. As to your have reasonable guidelines … and to stick to them, I couldn’t agree more. We used to have Follow Current Literature (FCL) in Which units to use but it slowly got gutted out when we were stomping “mebibyte (MiB” into the dust. It needs to go back in (and we need to “stick to it”). After all, we should all feel sorry for the poor bastard who walks all fat, dumb, and happy into a computer store after having read about computers in Wikipedia and say “I want a computer with 2 gibibytes of RAM.” I’m sure it’s happened before; and all they got back was (at best) blank looks (or worse of all) laughed clean out of the store. Greg L (talk) 20:22, 29 March 2009 (UTC)

FWIW, I live in a country (Italy) where the kilometre per hour is the only unit in which 99.9% of people would ever measure the speed of a car, and I don't recall ever seeing it abbreviated as anything else than km/h. YMMV. --A. di M. (talk) 20:42, 29 March 2009 (UTC)

As for road signs, they just show the number here (e.g. "50" for 50 km/h), and there is a urban legend circulating in Italy about someone having his driving licence revoked for driving at 177 km/h on a road with a "50" limit, and appealing by claiming that as Italy officially uses the SI per some law, speeds are supposed to be intended to be in metres per second unless otherwise specified, and therefore he was driving 3 km/h below the limit of 50 m/s = 180 km/h. --A. di M. (talk) 20:49, 29 March 2009 (UTC)

• Well good. I wasn’t taking a stand on any particular unit symbol to use. I was simply pointing out that we should be considering is the subject, and then look to current, most reliable literature on that subject for guidance on units of measure and symbology. So in this hypothetical of an article on european road speeds, it would apparently be “km/h”. Note that in America, it is “mph” on road signs. Does that mean the unit symbol for this unit should be “mph” for other subjects? Of course not.

  But just because “mph” isn’t SI compliant and is bad (and has body odor and all that) and having it darken our doorstep in road-related articles will prevent us from gaining admission into the United Federation of Planets for not having project-wide consistency, is no excuse to write out units in odd ways that don’t appear that way in the real world on that particular subject. Greg L (talk) 21:03, 29 March 2009 (UTC)

(outdent)
Speaking of Italy, my wife and I spent three days in Rome and two weeks in Austria (with a one-day excursion to Budapest). As we never once drove and just took mass transit or walked (a lot of walking), I never noticed the speed limit signs. Not once. I do remember this great place to get pizza cooked in a wood-fired oven. It was on Gellért Hill just outside of the Citadel with a great view overlooking Budapest. The prices downtown were great. I just made a quick scan of my street photographs. I apparently didn’t even catch a single photo of a speed limit sign. Greg L (talk) 21:46, 29 March 2009 (UTC)

The standard abbreviation, as agreed upon by the International Bureau of Weights and Measures (BIPM) and the US National Institute of Standards and Technology (NIST) is "km/h". SI units always use "/" for "per". The abbreviation "kph" should never be used because the symbol "p" stands for "pico" (10^-12). RockyMtnGuy (talk) 23:22, 29 March 2009 (UTC)

Agreed with Rocky Mountains Guy. The standard abbreviation in Australia is km/h without exception. See [8] Michael Glass (talk) 00:29, 30 March 2009 (UTC)

Always km/h. kph could be confusing. km/h will never be.Headbomb {^ταλκ_{κοντριβς} – WP Physics} 00:56, 30 March 2009 (UTC)

I second that: always "km/h" if even if some astronomers use something else. JIMp _talk·cont 12:27, 31 March 2009 (UTC)

Agree with "km/h". A reader with limited ability in English will have a better chance of understanding "/" than "p". --Jc3s5h (talk) 16:24, 31 March 2009 (UTC)

Isn't "kps" a common, informal abbreviation for kiloBytes per second (for download speeds, etc.)? At least in theory, a false parallel with "kph" might be another source of possible confusion for the lay reader, especially if non-Anglophone. (If "mph" is miles per hour, and "mpg" is miles per gallon, then ....) —— Shakescene (talk) 20:31, 31 March 2009 (UTC)

Yes, "kps" is a commonly used abbreviation for kilo (something) per second - but we're not sure what. It could mean kilobit per second, kilobyte per second, kilometre per second, kilogram per second, etc. However in the SI system the letter "p" is reserved for "pico", so it actually means "kilopicosecond", a very short interval of time indeed. Kilobit per second is better represented as "kbit/s" and kilobyte per second as "kB/s", if you take the advice of the IEEE, BIPM and NIST. The acronym "mpg" could stand for "millipicogram", a very very small unit of mass, and "mph" could mean "millipicohour", a very very tiny interval on the clock, so you should use all uppercase "MPG" and "MPH" instead. RockyMtnGuy (talk) 18:58, 1 April 2009 (UTC)

Megapetahenry. JIMp _talk·cont 20:47, 1 April 2009 (UTC)

I don't think you can say that p is "reserved" for pico more than you can say m is "reserved" for a metre (it's also a milli). Also in SI the prefixes are never combined, making "millipicogram" even more wrong. And d is both deci- and day (not SI but specifically approved by the authority). --SLi (talk) 22:22, 1 April 2009 (UTC)

Whereas multiple prefixes have been used in the past (in my university there's a chest of drawers containing capacitors, and some of the drawers are still labeled with capacities in "kpF", just to confuse us young people used to "nF"), the potential of confusing "mph" with a unit of time equal to 3.6 ps is nil; furthermore, it seems to me that "mph" is far more common in actual use (but I'm from a metric country, so I wouldn't be 100% sure).--A. di M. (talk) 16:30, 3 April 2009 (UTC)

I think we can make exceptions for "mph" and "mpg" since these are so well known and well established. "1 ft" what's that, one femtotonne? JIMp _talk·cont 10:29, 4 April 2009 (UTC)

Would the real policy on weights and measures please stand up?

In my innocence I proposed what i thought was a small and simple revision of the style manual. To my surprise, it was shunted off to Manual of Style (dates and numbers). That this website even existed was news to me, but what surprised me more was that there is not one policy on the use of weights and measures, but two!

Now these two policies are not mirrors of each other, but each has its own distinctive features as well as some features that they have in common. What one lacks, the other one will often supply, but neither one encompasses all or even most of the differences between them.

I think that it is not a good idea to have two competing style rules for Wikipedia. I therefore suggest that we bring the two together here, and make this version a comprehensive one that covers all the bases. Then we may reconsider the function of the guidance given in the general Manual of Style. Does it supersede the advice given here or is this the last word on style for dates and numbers? But whatever we feel, the idea of two competing style guides is not good. How can Wikipedia provide guidance for editors if it has two different policies for weights and measures?

So what do other editors think? Is this just a glorified sandbox, or does it determine policy? What do other editors think? Michael Glass (talk) 11:46, 1 April 2009 (UTC)

Ideally there would be one such set of guidelines about units of measurement, located at MOS:NUM, with a short summary of the particular guidelines which are relevant to most articles at WP:MOS. --A. di M. (talk) 16:17, 3 April 2009 (UTC)

In for inch often needs a stop

The "Conventions" section says that "inch" should be abbreviated "in" and not "in." or with a ' (prime) or ’ (apostrophe or close-single-quote).

But "in" is one of the commonest words in (there I go!) the English language. There are many times when it's definitely preferable to put a stop on "in." to distinguish it from the preposition. For one hastily-conceived example, "a 10 in nail" (even "a 10-in nail"; cf. "all-in wrestling") takes an unneeded second for an English-speaker to parse, and may completely confuse someone unfamiliar with English.

This is one of the areas where individual editors' discretion should be advised (and copy-editing 'bots-from-nowhere restrained). At least where a stop doesn't come after the last letter of the full word (as in "ft." vs "ft"), I see no good reason to remove the stop on any abbreviation which, without the stop, would have the same form as a common word.

While I have a slight general bias towards British conventions in punctuation (e.g. preferring "ft" to "ft."), this is one area where I prefer the American convention.

—— Shakescene (talk) 21:40, 1 April 2009 (UTC)

How about "a 10 inch nail"? It's just 1 character more than with a stop. --SLi (talk) 22:15, 1 April 2009 (UTC)

There are two options: 10 in nail or 10-inch nail. Dabomb87 (talk) 22:39, 1 April 2009 (UTC)

Having seen "in" for "inches" on WP a greater number of times than I care to attempt ballpark an order of magnitude for, my feeling is that the risk of confusion with the preposition is negligible. Moreover almost any mention of inches should either be a conversion from or be accompanied by a conversion to a metric equivalent. English has quite a few homographs, we deal with it. Let us not scramble to solve this non-problem. JIMp _talk·cont 23:42, 1 April 2009 (UTC)

Indeed, there aren't any guidelines concerning when to use full unit names and when to use symbols. I'd propose to add befote the first bullet in "Convention" the following:

* In places where space is limited, such as infoboxes and tables, in mathematical formulas, and in parenthetical notes, it is preferable to use unit symbols; in prose it is usually preferable to spell out unit names, except when they are very long.

What do you think? --A. di M. (talk) 14:09, 3 April 2009 (UTC)

Sounds reasonable to me. JIMp _talk·cont 10:24, 4 April 2009 (UTC)

The point about abbreviated in almost always coming either before or within a conversion is one that hit me independently before reading Jimp's note, so this particular point now seems less urgent. But then I thought, if one must have a convention, why is it one against indicating abbreviations with stops? I want as few rules as possible, given the fact that instructions (in Parkinsonian fashion) always creep out rather than recede, but if it has to be one way or the other, I think the argument is stronger on the other side: to follow old-fashioned practice and put stops on almost all such abbreviations for clarity's sake (regardless of what standards agencies may say). Is there anything inherently misleading about kg. or mm. ? (And if metric measures somehow work badly with stops, you could confine the advice to Customary measures. The old-fashioned "m.p.h." and "m.p.g." are clear to all who know those units.) I like A. di M.'s language, especially as one who gives conversions of acres to hectares but still thinks "ha" looks (literally as well as figuratively) funny and tries to expand it where feasible. However, perhaps another exception in his wording might be something like "or often repeated in the same sentence". [Otherwise it would recommend spelling out, rather than abbreviating the measures in a sentence like "John's height was 6 feet 5 inches (xx cm.), Mary's 5 feet 8 inches (yy cm), Peter's 6 feet 3 inches (zz cm), and Jane's 4 feet 10 inches (qq cm)."] —— Shakescene (talk) 09:54, 8 April 2009 (UTC)

The shortened form of units are often considered symbols, not abbreviations, and can be operated on in equations as if they were variables (see Dimensional analysis). In the past, when character sets were more limited and no raised multiplication dot was available, multiplication was sometimes indicated by a full stop, as in N.m. So the use of a full stop to indicate an abbreviation conflicts with using it to indicate multiplication. --Jc3s5h (talk) 10:29, 8 April 2009 (UTC)

Reply to Shakescene: Now the page reads "Symbols can also be used in prose when a unit is used many times in the article or has a very long name, but the first instance of each unit in the article prose should be spelled out." Is that OK? —Preceding unsigned comment added by A. di M. (talk • contribs) 11:50, 8 April 2009 (UTC)

Is there anything inherently misleading about kg. or mm. ? No. Can the dot add to confusion? Yes, because it could be mistaken for an end-of-sentence period: at that point she weighed 147 kg. according to reports now known to be fictitious could be misparsed if "kg." happened to come at the end of the line; dotless "kg" has no such ambiguity. ¶ I want as few rules as possible: "Follow BIPM"? ¶ The original question: "a 25 cm nail"? -- Hoary (talk) 12:17, 8 April 2009 (UTC)

'Which units to use'

The main changes are as follows:

• Incorporating material from the "Manual of Style"
• Reducing the use of the passive voice
• Inserting more concise constructions.

The aim is to unify the policy on weights and measures in the two manuals of style. Michael Glass (talk) 12:38, 3 April 2009 (UTC)

I have rearranged this section to bring together those points that directly bear upon the choice of units for articles. The exception for using non-metric measures in US and UK articles now have their own dot points, which have been double indented - thus helping to make them stand out. One slight change in wording states that US customary measures are generally the primary units in US related topics. This qualifying adjective is necessary because of the occasional use of metric measures in US articles. For example, the water quality section in the article on Lake Erie mentions a mussel that filters a litre of water a day. The word generally covers such exceptions. Michael Glass (talk) 14:04, 9 April 2009 (UTC)

Proposed caveat to add to Birth date template passage

The documentation for {{birth date and age}} states "Do not use with non-Gregorian dates because the resulting hCard hidden date will be false."

Since it has been thoroughly demonstrated to me that this matter of template recommendations is a sensitive topic, I am proposing the new text here even though the page is currently unprotected. Proposed passage would instead read:

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 precisely known and occurs after 1752. See the documentation for those templates in order to use them properly.

Rationale: The guidelines refer the user to some rather complex documentation for birth and death dates, and most contributors don't understand what a non Gregorian date is and so rather than telling them not to use with non Gregorian dates, a rule of thumb is provided. I think editors who frequent MOSNUM discussions are familiar with the rationale for the particular rule of thumb I provide. Although there was use of Julian in Eastern Europe and in Asia after 1752, for English texts, chances are pretty good that the date is Gregorian if it is greater than 1752. The caveat of "precisely known" carries the current red letter warning at the beginning of the documentation. This documentation could be mistakenly changed or contributors might not read it, so the insertion of "precisely" covers that weakness. How does that sound? -J JMesserly (talk) 17:18, 3 April 2009 (UTC)

I'd rather call a spade a spade and say "in the Gregorian calendar (adopted in 1752 in most English-speaking countries)" rather than "after 1752". The link is there so that users can figure out which calendar was in use if they are reporting the death date of a Spaniard or a Russian. --A. di M. (formerly Army1987) — Deeds, not words. 09:58, 7 April 2009 (UTC)

I agree, this specific warning is absolutely necessary. --Hans Adler (talk) 11:34, 7 April 2009 (UTC)

I agree. Much nicer wording. Change as I understand it reflected below.

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 precisely known in the Gregorian calendar (adopted in 1752 in most English-speaking countries). See the documentation for those templates in order to use them properly.

Since this does not appear to be controversial, this text will go in tomorrow as above. -J JMesserly (talk) 16:15, 7 April 2009 (UTC)

{{editprotected}} This change appears to be uncontroversial, but I cannot make edit because section is editprotected. Please replace the current birth date passage with that in the second blockquote with the Gregorian calendar link. -J JMesserly (talk) 17:10, 8 April 2009 (UTC)

 Done —  Tivedshambo  (t/c) 18:23, 8 April 2009 (UTC)

Non-breaking spaces: always needed?

The project page says, "Values and unit symbols are separated by a non-breaking space ( ) (e.g., write 10 m or 29 kg, not 10m or 29kg)." I wonder if there's any point in using non-breaking spaces, rather than spacebar spaces, when the item is at the left end of a line, for example, in a table or an information box. In other words, in a place where the space won't break unless the browser's window is exceedingly narrow. This edit got me thinking about it. I don't mind the edit at all; I just wonder if there's much point in it. Can we add an exception for text in places where the space won't break, and so save people the effort of making changes like this one? Maybe just guidance like "Use of a non-breaking space instead of an ordinary space is unnecessary (but acceptable) for text that is sure to appear in the first 30 characters at the left of a line." Fg2 (talk) 21:25, 3 April 2009 (UTC)

If Mediawiki had a feature which converted all underscores to non-breaking spaces (except in template parameter names, URLs and the like, and within <nowiki> tags), one could just write 29_kg for consistency, without worrying "is the risk that 29 kg is broken across lines plausible enough for me to bother typing five extra characters as in 29 kg?" It would also make the source code of article less unreadable than it is today. I've taken a glance at the source codes of the last four days' featured articles, and none of them uses any underscore in the actually displayed text (as opposed to parameter names etc.) except in URLs, so it wouldn't be a great deal to do that, I guess. --A. di M. (talk) 11:02, 4 April 2009 (UTC)

There's no guarantee that it won't get moved or copied to somewhere more likely to have a break, nor is there any guarantee how a user agent (or any other user of wikipedia pages) is going to render any article. It's safer and easier in the long term to use non-breaking spaces in all occurrences. OrangeDog (talk • edits) 21:21, 4 April 2009 (UTC)

As usual, there are reasons both ways: normal spaces make edit space easier to read and edit, and therefore less prone to error; they also make pages format more closely in even line-lengths, which looks better - and in extreme cases can avoid some very ugly formatting. Editors should make up their own minds whether the minor disadvantage of having kg at the start of some lines is worth this minor cost to avoid it.

Ignore anybody who says that we must do it one way or the other. Septentrionalis PMAnderson 23:37, 8 April 2009 (UTC)

I agree about "edit space easier to read", and that's why I'd propose that underscores be interpreted as non-breaking spaces by MediaWiki. As for line lengths, unit symbols are usually narrow enough: "86 kg" takes less space than "pneumonia", so that's usually a non-issue; seeing a line starting with "kg" would be much more awkward IMO (but that's in the eye of the beholder). As for me, I usually use non-breaking spaces in these situations, but I don't bother to use them where normal spaces don't have a snowball's chance in hell of being broken (e.g. before N and E in 2009 L'Aquila earthquake#List of foreshocks and aftershocks); but this is more because I can't be arsed than because I think there's something wrong with them, and wouldn't object if someone replaced them with hard spaces. --A. di M. (formerly Army1987) — Deeds, not words. 00:21, 9 April 2009 (UTC)

As for line lengths, unit symbols are usually narrow enough. True, but by the same token, the normal space rarely breaks, so we are providing against a rare problem. Septentrionalis PMAnderson 19:40, 9 April 2009 (UTC)

Consistency and diversity in weights and measures

Wikipedia rightly strives for both consistency and diversity in usage. In some cases this means making a choice between competing usages; in other cases, the differing usages are accepted. So, the differences between British and American spelling is accommodated, while, sensibly, the rules state that individual articles should be internally consistent. The same rule applies to weights and measures, only here we generally need to supply both SI and Imperial/US Customary units for the sake of readers who often are not familiar with one or the others.

However, there is a problem with inconsistency between similar articles, which can quite arbitrarily swing between metric and Imperial/US Common measures. This may be seen in the following table:

Metric first	Imperial first
Cornwall	Devon
Skye	Lewis and Harris
Shetland	Orkney
Cambridgeshire	Oxfordshire
Staffordshire	Leicestershire
Dorset	Hampshire
Jersey	Guernsey, Alderney, Sark
Niagara River	Niagara Falls
East Falkland, West Falkland	Falkland Islands

Now a certain amount of inconsistency is inevitable when editors have different preferences for weights and measures, but these variations are more Monty Python than encyclopedic. Now I know full well that we can't impose a rigid rule on people. However, I believe that we could put in place guidelines that would nudge editors towards more consistency. I suggest that the following wording be considered:

Add to the principles:

• Consistency of usage, in articles, text boxes, tables and between articles dealing with similar subjects.

Revise this point from this:

• Use units consistently. An article should have one set of primary units (e.g., write A 10 kg (22 lb) bag of potatoes and a 5 kg (11 lb) bag of carrots, not A 10 kg (22 lb) bag of potatoes and an 11 lb (5 kg) bag of carrots.

to this:

• Use units consistently. An article should have one set of primary units.
  • Text boxes and tabular material should be SI first.
  • Where articles dealing with similar subjects are inconsistent, aim for consistency, with SI measures first.

What do other editors think?

It would be nice if Wikipedia were in a condition where we had nothing more important to worry about. That being said, I will always welcome the recognition that we can't impose a rigid rule on people. Septentrionalis PMAnderson 17:24, 10 April 2009 (UTC)